JBossDeveloper

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);

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.

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.

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

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.

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());

 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);
 }

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.

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.

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