|Justin Lee||Jan 23, 2009 8:16 am|
|Justin Lee||Jan 23, 2009 8:17 am|
|Oleksiy Stashok||Jan 23, 2009 8:45 am|
|Lloyd Chambers||Jan 27, 2009 12:56 pm|
|Justin Lee||Jan 28, 2009 7:41 am|
|Lloyd Chambers||Jan 29, 2009 10:58 am|
|Justin Lee||Jan 29, 2009 1:01 pm|
|Justin Lee||Jan 30, 2009 12:09 pm|
|Lloyd Chambers||Jan 30, 2009 3:32 pm|
|Lloyd Chambers||Jan 30, 2009 3:40 pm|
|Kedar Mhaswade||Jan 30, 2009 3:46 pm|
|June...@Sun.COM||Jan 30, 2009 3:51 pm|
|Kedar Mhaswade||Jan 30, 2009 3:54 pm|
|Lloyd Chambers||Jan 30, 2009 3:55 pm|
|Kedar Mhaswade||Jan 30, 2009 4:40 pm|
|Justin Lee||Jan 30, 2009 5:04 pm|
|Jerome Dochez||Feb 2, 2009 9:20 am|
|Kedar Mhaswade||Feb 2, 2009 10:53 am|
|Jerome Dochez||Feb 2, 2009 11:22 am|
|Kedar Mhaswade||Feb 2, 2009 2:15 pm|
|Tim Quinn||Feb 2, 2009 3:05 pm|
|Kedar Mhaswade||Feb 2, 2009 3:17 pm|
|Jerome Dochez||Feb 3, 2009 12:50 pm|
|Kedar Mhaswade||Feb 3, 2009 1:19 pm|
|Subject:||Re: Comments on grizzly config one pager|
|From:||Jerome Dochez (Jero...@Sun.COM)|
|Date:||Feb 2, 2009 9:20:54 am|
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.
On Jan 30, 2009, at 4:40 PM, Kedar Mhaswade wrote:
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.
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.
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).