Tim Quinn wrote:
> 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.
I think Justin was working on the DTD generation, would be interesting
to converge on a simple in-memory model + visitor APIs and let him to
the DTD part.
>> 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?
everywhere really, type, attributes and elements.
>> 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.
yes I think this is the perfectly fine, perfect example of something
that can be done independently later.
>
> - 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>