[starksm64]

Your right, the string needs to be wrapped in a ServiceTextValueMetaData. The value type is a ServiceValueMetaData, so we would need a new ServiceValueMetaData that accepted the raw value.

[weston.price]

Even using the ServiceTextValueMetaData, it's still not setting the attribute. Am I doing something wrong:

 ServiceAttributeMetaData cd = new ServiceAttributeMetaData();
 cd.setName("Version");
 cd.setValue(new ServiceTextValueMetaData(Integer.toString(10)));
 attributes.add(cd);

Doing this I would expect the attribute to be set prior to the call to startService(). This isn't happening. As a result, the attributes that I depend on being set aren't there and things blow up. Am I misunderstaning the purpose of the API?

The XSLDeployer has no problem with this of course.

[starksm64]

That should be correct. This is the default attribute value type for all properties so its certainly being used this way. What is an example of an mbean your trying this with?

[weston.price]

The horribly named, org.jboss.resource.connectionmanager.RARDeployment. This is the ManagedConnectionFactory deployment for RARs. Like the JBossManagedConnectionPool and ConnectionManager it's just a standard MBean.

[weston.price]

In looking at more of the API, should I be using the ServiceDeployment as a wrapper for all the MBeans generated via the DSXMetaData as opposed to the ServiceMetaData directly? This is what the ServiceXSLDeployer does and would seem to make some sense since all my MBeans are interdependent and should deployed in one shot.

[starksm64]

I don't see a reason why you should not use ServiceDeployment.

[weston.price]

Cool. Thanks Scott. I will take a look at modifying what I have.

[weston.price]

Note, because I abstracted the actual building of the underlying services, it should be relatively trivial to 'swap out' both the MetaDataParser as well as the builder. This will become more important as we port JCA over to using the MC.

[weston.price]

Ugh...this won't work either.

In the ServiceXSLDeployer

ServiceDeployment parsed = new ServiceDeployment();

 List<ServiceDeploymentClassPath> classPaths = parseXMLClasspath(document);
 parsed.setClassPaths(classPaths);

 LoaderRepositoryConfig repository = parseLoaderRepositoryConfig(document);
 if (repository != null)
 parsed.setLoaderRepositoryConfig(repository);

 // We can't parse the services yet, because it requires the classloader
 parsed.setConfig(document.getDocumentElement());

In the ServiceDeploymentDeployer

 List<ServiceMetaData> services = deployment.getServices();
 if (services == null)
 {
 Element config = deployment.getConfig();
 if (config == null)
 {
 log.debug("Service deployment has no services: " + deployment.getName());
 return;
 }

 ServiceMetaDataParser parser = new ServiceMetaDataParser(config);
 services = parser.parse();
 deployment.setServices(services);
 }

So, basically the ServiceXSLDeployer is parsing the *-ds.xml file. Using XSLT this creates the typical MBean configuration. Once this is done, the resulting ServiceDeployment is passed off to the ServiceDeploymentDeployer. He simply parses the XML configuration generated by the XSLT. The new stuff won't have this because being that no XML is created, it's all MetaData at that point.

Damnit...back to square one.

[starksm64]

Right, so the ServiceDeploymentDeployer sees a non-null/non-empty services list and then adds these as components to be deployed without doing any parsing:

 if (services == null || services.isEmpty())
 return;

 for (ServiceMetaData service : services)
 addServiceComponent(unit, service);

If you populate the ServiceDeployment services and bypass the xml config this should still work. I don't see why it would not.

[weston.price]

I've broken up the DSX stuff into two deployers

DSXParserDeployer -- Responsible for parsing the *-ds(x).xml files to generate the JCADeploymentMetaData which wraps this in DSXMetaData

DSXDeployer -- Receives the DSXMetaData, builds the ServiceDeployment/ServiceMetaData and then adds the result as an attachment to the DeploymentUnit.

Taking a step back, is this how the stuff is supposed to work? Something just doesn't feel right. This is how the RARDeployer is built and I was using that as a working example, but I am not entirely familiar with the new deployment architecture. Shouldn't the RARDeployer and all JCA related stuff be moved over to the Structure type deployers. The RAR stuff as it is today seems pretty hackish.

[starksm64]

Structure deployers do not produce metadata attachments. They only build a deployment structure with classpath info from the vfs view of a deployment archive. They handle the aspect of recognizing a deployment given a uri pointer to it.

The only hacky thing I see about the RARDeployer is use of the old mbeans.

[weston.price]

Ok, thanks for the clarification.

Well, the RARDeployer doesn't use the old MBeans, it's the XSL and DS deployers and that's not going away anytime soon, at least until I start migrating things over to MC/AOP. The programmatic deployment stuff was supposed to be an interim step along the way but once I started really looking at it things were not as straightforward as I initially thought.

[weston.price]

Ok, this is working in rough draft form. This still requires quite a bit of testing but at this point a new

org.jboss.resource.deployers.ManagedConnectionFactoryDeployer

has been created to read/parse the *-ds.xml file and create the MBeans. One thing I did have to do was leverage the ServiceMetaDataParser to manage MBean definitions within the *-ds.xml file. Rather that simply redo all this work I just leveraged the existing API.

The parser is JAXP based and is optimized for JDBC based deployments. The underlying MetaData model is straightforward. Note, all meta data generated is now kept in the RARMetaDataRepository and associated with the ConnectorMetaData pointing to the actual RAR.