Hi, Jerome.
Jerome Dochez wrote:
> Hi Tim
>
> This is really cool, there is no limit on how far this tool can go. I
> talked with June and Abhijit few months back how we could autogenerate
> a lot of the domain configuration from the config model using a tool
> like you wrote.
>
> I understand this was a week end hack but I have a few RFEs if this is
> not already implementated.
>
I'm laughing to myself ;-). This was my one "fear" in publicizing the
tool but of course I expected it. Thanks for the suggestions.
> 1. would it be possible to plug an output adapter, so we can generate
> DTDs, wiki page and tables with cross-referencing.
Absolutely. This was also my first RFE; I did not want to take the time
to generate proper DTDs or XSDs but I thought others might want those.
The API might well be event-driven, along the lines of the SAX approach
for XML parsing, to insulate the output adapter from the internal
implementation details (which are not too pretty, being a weekend
hack!). I'll take a look and see if I can do this quickly.
> 2. could you add the notion of @Documentation to the hk2 framework,
> Jane could use this @Documentation annotation to enter information
> like the one we find today in the administration guide.
As you said, anything is possible. Would this be at the @Configured
interface level?
> 3. out of this @Documentation, guess what you would start generating...
> 4. is this purely a reporting tool or are there possible ways of
> adding verification semantics to check the config interfaces are
> consistent ?
Currently it only reports, but with an event-driven adapter approach
like above the tool would not care what the adapter did with the events
- reporting, consistency checking, GUI display of the data for browsing,
etc.
Given how close we are getting to the soft code freeze I have limited
time to work on the tool now, bu I can probably get the output adapter
stuff working fairly quickly.
- Tim
>
> Jerome
>
> Tim Quinn wrote:
>> From time to time there have been requests for DTDs or XSDs for the
>> v3 domain.xml. But because the content of domain.xml is variable,
>> depending on what modules are installed, this is not really feasible.
>>
>> Over the weekend I hacked together a small tool that will generate a
>> simple text file describing the format, based on the interfaces
>> annotated with @Configured that are defined in the GlassFish module
>> JARs.
>>
>> This wiki page
>>
>> http://wiki.glassfish.java.net/Wiki.jsp?page=DomainXMLv3Structure
>>
>> describes the tool, how to download and run it, and how to interpret
>> the output (it's pretty simple, I hope). I have alrso recorded a few
>> possible errors I've seen in the @Configured interfaces as defined
>> currently, based on the tool's output.
>>
>>
>> Action Item:
>> Module owners, please review the sections of the generated output
>> related to your modules. Make sure that the structure (attributes,
>> subelements, etc.) is correct for your areas of the system. There is
>> a table on the wiki page to record errors in other areas.
>>
>>
>> This is not a supported part of GlassFish but might be useful for
>> people interested in the domain.xml format. If you find errors in
>> the tool itself please add a row in the tool issue list at the bottom
>> of the wiki page.
>> - Tim
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>