Can't you use getByContract() or getByType() off of Habitat to get all
the @Configured elements? Granted, at runtime, an OSGi module might
come or go, but you could recalcuate the "schema" when those events occur...
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
>>