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