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
>