On Feb 2, 2009, at 2:15 PM, Kedar Mhaswade wrote:
>
>
> Jerome Dochez wrote:
>> I would like to see the DTD for overall domain.xml validation more
>> than field validation which as you mention will be preferably
>> handled by the beans validation framework.
>
> Is that (Bean Validation) happening in time for us for JavaOne?
yes.
> I am
> not so sure. The current framework we have for field validation works
> well, IMO. We can enhance it a bit and that buys us some "time". For
> now, there are several @Configured interfaces that do not even do
> basic
> field validation, which is rather unpleasant.
>
no I think we just should delegate to bean validation, even if it
limits what we can do for v3 final. I think we have enough to do than
throw away code.
> For a schema validation kind of requirement, yes, I agree, DTD will
> come in handy.
>> right now, the errors that we generate when fed with an incorrect
>> domain.xml can be cryptic to the user, a xsd or dtd validation
>> would ensure domain.xml structural validity in a more predictable
>> manner.
>> I don't think we *have* to do it, but I can see value.
>
> Let me see if I can plan for it.
>
> -Kedar
>
>> jerome
>> On Feb 2, 2009, at 10:53 AM, Kedar Mhaswade wrote:
>>> I agree. It's possible.
>>>
>>> But now that we have resorted to alternate ways of doing things like
>>> validation (e.g. using data-type annotation field on attributes), we
>>> have less and less motivation to reinstate a DTD for such
>>> purposes. Unless
>>> there is a tremendous advantage of reinstating a DTD, I wouldn't
>>> vote for
>>> it. My basic idea is for documentation purpose and that's why
>>> doing it at
>>> compile time would suffice. Of course, generating DTD at runtime is
>>> attractive.
>>>
>>> -Kedar
>>>
>>> Jerome Dochez wrote:
>>>> Even if modules are not loaded, you can still get an exhaustive
>>>> list of all @configured interfaces (costly operation as you end
>>>> up starting all related modules) as long as modules are installed
>>>> (meaning residing in the modules directory for instance). So I
>>>> don't think it's more difficult to generate this at runtime than
>>>> at compile time, although you might be missing access to the
>>>> javadoc's for documenting the DTD itself.
>>>> generating at runtime is interesting as it would indeed allow us
>>>> to validate the domain.xml once again... probably not a mode by
>>>> default considering the startup cost it would incur but very
>>>> interesting for the more elaborated distributions.
>>>> Jerome
>>>> On Jan 30, 2009, at 4:40 PM, Kedar Mhaswade wrote:
>>>>> Lloyd,
>>>>>
>>>>> Yeah. As you can see, this can't give you an idea of modules/
>>>>> interfaces
>>>>> that are not loaded and as such it is of not much value from a
>>>>> documentation perspective. And yes, it is because server's
>>>>> configuration
>>>>> and runtime both are dynamic in nature.
>>>>>
>>>>> -Kedar
>>>>>
>>>>> Lloyd Chambers wrote:
>>>>>> Kedar,
>>>>>> As I haven't looked into it, you might be right. I thought
>>>>>> there might be a way to traverse all module, find all
>>>>>> @Configured interfaces, build a graph (tree), then emit a DTD.
>>>>>> In concept it seems easy enough, but of course the details
>>>>>> might prove otherwise.
>>>>>> Lloyd
>>>>>> On Jan 30, 2009, at 3:46 PM, Kedar Mhaswade wrote:
>>>>>>> Generating a DTD at runtime is hard problem to solve. It will
>>>>>>> be nice if we can at least get a DTD from config elements
>>>>>>> which are known at compile time.
>>>>>>>
>>>>>>> -Kedar
>>>>>>>
>>>>>>> Lloyd Chambers wrote:
>>>>>>>> Justin,
>>>>>>>> Generating a DTD would be terrific, it's something on "the
>>>>>>>> list". Ideally it would be built at runtime based on the
>>>>>>>> loaded modules, not compile time.
>>>>>>>> Lloyd
>>>>>>>> On Jan 29, 2009, at 1:01 PM, Justin Lee wrote:
>>>>>>>>>> There is no provision in V3 for a DTD as the source of the
>>>>>>>>>> interfaces. Java interfaces are the source at this point,
>>>>>>>>>> the @Configured interfaces. A DTD does not work for a
>>>>>>>>>> pluggable system; it would have infinite variation, never a
>>>>>>>>>> fixed thing.
>>>>>>>>>>
>>>>>>>>> I'm actually in the process of making sure the DTD(s) and
>>>>>>>>> the interfaces are in sync and then I'll probably just
>>>>>>>>> remove the DTDs for good measure and work from the
>>>>>>>>> interfaces. I'm debating writing an hk2/maven mojo to
>>>>>>>>> generate a DTD/XSD for basic validation (largely for my own
>>>>>>>>> benefit).
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: admin-
>>>>>>>> unsubscribe_at_glassfish.dev.java.net
>>>>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: admin-
>>>>>> help_at_glassfish.dev.java.net
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>