JBossDeveloper

The parsing of the *-ds.xml file is not trivial as the format has been butchered through the years to include things that probably should have never been allowed and no one ever seemed to draw a line in the sand to make people stop.

Using AOP for the parsing of the *-ds.xml format would seem to make some sense for a few reasons

a) Element name definitions can be injected into the parsing aspects rather than being hardcoded. By element name defintions, I mean the actual mapping of things like <min-pool-size>, <driver-class>. Anyway you look at it, the elements from the DTD have to be mapped somehow, someway to something.

Before you say it, I know that this can be done via simple MC injection or can simply be thrown it in a properties file for reference, but this just doesn't seem to me to be the best approach. I could be wrong.

b)As new elements get added to the *-ds.xml (see above), new aspects can just be added to support this. Also, new file formats can be accomodated via aspects since there would be no real behavior in the actual class itself.

The correct approach is
xml -> metadata model
metadata model -> components (jmx/pojo)

This simply involves the parsing/binding of the *-ds.xml file. I was just throwing out an idea to break up the actual parsing into aspects. Example:

ConnectionPoolParsing aspect knows about the specific elements that make up the ConnectionPoolMetaData.

ServiceDependency aspect knows about the specific elements that constitute ServiceMean dependencies in the *-ds.xml file.

These aspects would form a parsing chain that gets applied on parse. Nothign more than that.

Again, this would be an alternate approach (refactoring) as I have already written the JAXP based parser of the *-ds.xml file to construct the MetaData which works, but is not as elegant/clean as I would have liked.

Sorry, I am not sure I follow. Right now what I do is simply parse the *-ds.xml file using straight JAXP. While this works, is quick and has no dependencies on any binding framework (JAXB, JBossXB) I started thinking about it a bit more. The problems I see with this are

1) The element name mappings have to be hardcoded somewhere. Example:

<min-pool-size/>
<max-pool-size/>
<connection-url/>
<xa-datasource-property/>

All of this stuff has to resolve to something in the MetaData, and then applied correctly to ServiceMetaData instances to construct and deploy the MBeans for a MCF. Right now I simply have a helper class that maintains a map of these values that the parser consults when processing the *-ds.xml file. It's this mess that I thought about replacing with something more extensible, ie, an aspectized parser where each aspect in the chain knows enough about the *-ds.xml format to construct the MetaData. As new elements get added to the *-ds.xml file, these aspects can be extended to accomodate this.

2) The parsing itself looks pretty ugly.

Again, JAXP was used more as a convenience than anything else. It was *simple* from the perspective that I could get something up and running, but now I am rethinking the design.

I would like to get away from using XSL at all (the original point of the task). The approach you mention could work, but if I was going to go down that route, I would be more inclinded to

1) Create a MCF XSD and deprecate the DTD

2) Eliminate the problematic elements from the *-ds.xml deployment (ie MBean definitions) that get in the way of making the unmarshalling a simple process, or at least find someway to work around this.

This was actually my initial approach but the MBean definitions inside the *-ds.xml got in my way.

Right, this is definitely a valid approach. It's pretty much the way the MetaData has already been structured. I optimized a bit for datasource deployments, but the structure is essentially the same as what you proposed it just does use JAXB or JBossXB at this point.

The generic *-ds.xml stuff, (MCF crap and whatnot) is the easy part. It's the embedded MBean stuff that I can't quite seem to get my head around in the context of JAXB/JBossXB. My approach up to this point is simply to leverage the ServiceDataParsers to manage this but I am sure there is a better way to do this.

Sorry, I posted before reading your latest message about the MBeans. Disregard.

1) Junk the -ds.xml and move to a -cf.xml which either doesn't support
embedded mbeans or does it via a namespace