[jboss-dev-forums] [Design the new POJO MicroContainer] - ServiceMetaData parsing needs to be pulled out of

[scott.stark@jboss.org]

An issue I have run into with testing deployment and editing of data sources via the profile service is that the metadata attachments associated with a service deployment is not getting parsed unti the real deployer is run during the component traversal. The ServiceDeployment attachment services is not being populated until here:


  | Thread [main] (Suspended (breakpoint at line 98 in ServiceDeploymentDeployer$ServiceDeploymentVisitor))	
  | 	ServiceDeploymentDeployer$ServiceDeploymentVisitor.deploy(DeploymentUnit, ServiceDeployment) line: 98	
  | 	ServiceDeploymentDeployer$ServiceDeploymentVisitor.deploy(DeploymentUnit, Object) line: 75	
  | 	ServiceDeploymentDeployer(AbstractRealDeployer<T>).deploy(DeploymentUnit) line: 89	
  | 	ServiceDeploymentDeployer(AbstractComponentDeployer<D,C>).deploy(DeploymentUnit) line: 72	
  | 	ServiceDeploymentDeployer(AbstractSimpleDeployer).commitDeploy(DeploymentUnit) line: 52	
  | 	DeployerWrapper.commitDeploy(DeploymentUnit) line: 165	
  | 	MainDeployerImpl.commitDeploy(Deployer, DeploymentContext, Set<DeploymentContext>) line: 557	
  | 	MainDeployerImpl.process(int, int) line: 495	
  | 	ProfileServiceBootstrap.loadProfile(String) line: 352	
  | 	ProfileServiceBootstrap.bootstrap() line: 248	
  | 	ProfileServiceBootstrap(AbstractBootstrap).run() line: 89	
  | 	ServerImpl.doStart() line: 403	
  | 	ServerImpl.start() line: 342	
  | 	Main.boot(String[]) line: 210	
  | 	Main$1.run() line: 508	
  | 	Thread.run() line: 595	
  | 

In order for the profile service to be able to build a pojo metadata model of a deployment that can be overriden by tool edits, all metadata that is subject to admin edits needs to be available before the Deployer.CLASSLOADER_DEPLOYER level of deployers have processed the deployment. The basic logic is:


  |       // Associate the raw deployment with the profile
  |       VirtualFile deployment = (raw deployment pushed by the user)
  |       AbstractDeploymentContext ctx = new AbstractDeploymentContext(deployment);
  |       profile.addDeployment(ctx, phase);
  | 
  |       // Process the base deployment to obtain the pojo metadata view
  |       mainDeployer.addDeploymentContext(ctx);
  |       Collection<DeploymentContext> ctxs = mainDeployer.process(-1, Deployer.CLASSLOADER_DEPLOYER);
  |       checkIncomplete();
  |       for (DeploymentContext d : ctxs)
  |       {
  |          // Save the pojo metadata view of the raw deployment in the profile
  |          profile.updateDeployment(d, phase);
  |       }
  | 
  |       // Determine the pojo metadata properties that can be edited
  |       Map<String, ManagedObject> mos = mainDeployer.getManagedObjects(ctx);
  |       // ManagedObject edits map an override set of pojo metadata stored in the profile via an update interceptor aspect
  | 

Subsequent deployment of deployment with edits starts at the Deployer.CLASSLOADER_DEPLOYER level of deployers, bypassing all of the metadata processing deployer as the associated DeploymentContext.getPredeterminedManagedObjects() has been populated from the admin edits store in the profile.

There is also another issue with the granularity of the Map<String, ManagedObject> for a deployment like a service descriptor. For this you have a single attachment of type ServiceDeployment which contains the ServiceMetaData for the mbeans, which contains the attributes that correspond to the ManagedProperty objects one would edit. The simplest view of a datasource would just have the jndi name and jdbc url as ManagedPropertys. What the admin tool needs to see is an inverted view where it gets a set of ManagedPropertys to edit, and these changes get mapped onto the attachment settings. While this can be setup inside the server via aspects, when a remote tool queries the properties and edits them, the aspects are lost. Essentially the same issue as entity beans becoming detached. Either I need to leverage logic similar to what hibernate does, or have an xpath like attribute in a ManagedProperty that allows the tool to submit a set of changed ManagedPropertys that can be applied to the deployment attachment attribute by navigating from the attachment root to the correct attachment property.

For now I'm going to create a fake datasource deployer to allow all of the profile service usecases to be fleshed out to finalize the apis.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000718#4000718

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000718