DSDotXML XSD

[weston.price]

Would it make sense to consider moving the current *-ds.xml DTD to an XSD? This would make the use of JBossXB easiers, as well as give us some form of validation support.

[adrian.brock]

The issue is that it also accepts MBean definitions:
http://jira.jboss.com/jira/browse/JBAS-2048
+ http://jira.jboss.com/jira/browse/JBAS-460

[weston.price]

Right, a practice I think we should discontinue. In terms of the XSLT deployer it made sense just to pass these along, but moving forward do we really want to allow for this?

[weston.price]

Note, this is a major reason why the programmatic deployment stuff is unecessarily complicated because *-ds.xml allows for arbitrary MBean definitions for which constructing MetaData is challening.

I know in terms of jms-ds.xml, hsqldb-ds.xml this is an issue because of the 'other' stuff included. What would be the issue with breaking this stuff up and having the *-ds.xml stuff in it's own file, and the other stuff in a normal *-service.xml file?

[weston.price]

Let me frame it in different terms:

Currently the *-ds.xml deployment scheme is at best functional, at wost unweildy, cumbersome and error prone being that, as you have pointed out Adrian, it is almost impossible to validate a *-ds.xml file prior to deployment. Constructing MetaData from the *-ds.xml file alleviates some of this, but we always are going to come smack dab back into the arbitrary MBean definition in the file. If we remove this, this no longer is an issue. Further, removing this would allow XML->Model->XML (say in the case of taking a *-ds.xml file and creating something that could be deployed by the MC) much easier.

Maybe I am missing something (probably), but it would seem to be time to cut bait and get this MBean yoke off our shoulders in terms of JCA deployments.

[adrian.brock]

Compatibility.
We need to support it for old configurations.

JBossXB supports "wildcard" binding so it should just be case
of proxying the xml to the SAR deployer.

Further down the road, we want to move the proper schema
based deployment where the parser can properly validate these
complicated deployments using "use case schemas and parsing",
e.g.

<deployment xmlns="urn:jboss:bean-deployer:2.0">
 <bean .../>
 <local-tx-datasource xmlns="urn:jboss:datasource:1.0" .../>
 <mbean xmlns="urn:jboss:mbean:1.0" .../>
 <queue xmlns="urn:jboss:jms:1.0" .../>
 etc.
</deployment>

That doesn't mean that we shouldn't encourage simpler
deployments, but it is really the user's choice of what makes sense.

[weston.price]

See, that is what I am saying...the 'proxying the xml to the SAR deployer' basically sublimates everything the programmatic deployment is supposed to fix in the first place. We still have 'raw' XML elements being passed to deployers that we cannot validate up front, but are forced to rely on a seperate deployer to do for us.

Further, I don't want to get on a XB bashing thread here, but a binding constructed from arbitrary XML using XB is not ideal. Technically, if XB really implemented JAXB I shouldn't have to write any *MetaData objects at all. That should be driven from the schema and generated at compilation time (ie Castor, JAXB). Why do I even need to write a ObjectModelFactory? The binding framework should do this rather than relying on the developer to provide one. If the schema is well defined, unmarshalling should be a managed *solely* by the binding framework. Unfortunately, this brings us back to the XSD for *-ds.xml deployments :-)

At the very least, I think we should reconsider some of our deployment models for JCA.

Of course, I assuming the following:

The MC deployment model is radically different. However, what is not clear to me is if we are planning on supporting deploying a *-ds.xml file to 5.0 and have it deploy the MC.

Maybe IRC when you get a chance?

[adrian.brock]

We have to live with this crappy xml like it or not.
People have working deployments that use it.
The biggest problem is that all the xml is in the global namespace.

This does not affect the programmatic datasource at all.
You aren't going to deploy mbeans through that factory.

It affects the datasource deployer which needs to create a proper model
for the datasource/connection factory before creating it
programmatically and then pass
whatever xml it doesn't recognise to the SAR Deployer.

It's a hack and not a very nice one, until we can fix the xml
to something nicer and easier to manage (both for us and the user)
i.e. in JBoss5.

[weston.price]

That's fine. Again, I had assumed that in JBoss 5.0, we were targeting reworking a lot of this stuff, I didn't mean for you to assume that I wanted this done for 4.0.x.

The programmatic stuff for 4.0.x is affected somewhat being that the DsDeployer is going to have to account for XML based deployment, versus MetaData deployments simultaneously.

Consider:

*-ds.xml file with 2 datasources and 1 MBean.

2 MetaData blobs are constructed and the appropriate MBeans are generated from the MetaData (basically turning the MetaData *back" into XML that the SAR deployer can work with, or devising another way to deploy the MBean constructs).

The MBean is passed unaltered to the SAR deployer, or the xml is proxied to the SAR deployer as you put it.

Both of these things have to go through the DsDeployer, in the first case, the *-ds.xml file is pased, meta data constructed and again, turned back into XML for deployment. I don't see any reason to not to generate XML since this works today. For the MBean, the XML is just passed right along to the SAR deployer unaltered.

Is this what you had in mind? Or do you want to devise a scheme to programatically deploy datasources/connection factories without converting them to MBean XML and passing them to the SARDeployer?

Along the lines of XML->Model->MBean Binding (no XML, no SAR Deployer).

[weston.price]

If anything, this discussion alone should be used as an answer to the 'Why should I use the Microcontainer' question...much easier, cleaner etc, etc.