Jerome Dochez wrote:
>
> 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.
I will experiment with Bean Validation and get back.
http://musingsofaprogrammingaddict.blogspot.com/2009/01/getting-started-with-jsr-303-beans.html
-Kedar
>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>