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? 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.
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
>