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
>