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

[bill.burke@jboss.com]

anonymous wrote : 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. 

Ok.  I'm commenting based on reading just this thread and looking a bit at your code in org.jboss.test.profileservice.p0, so don't be too annoyed if I'm missing something....


IMO, an admin tool is going to need a complete structural view of  ManagedObjects/DeploymentContexts to be able to display a generic UI to the user.  For example, the UI might look like this:


  | <DeploymentContext name="MyApp.ear">
  |       <!-- default security domain for ear -->
  |       <ManagedObject name="Security">
  |           <ManagedProperty name="SecurityDomain" value="other"/>
  |       </ManagedObject>
  |       <DeploymentContext name="MyEjb.jar">
  |          <!-- default security domain for application -->
  |          <ManagedObject name="Security">
  |              <ManagedProperty name="SecurityDomain" value="UNMODIFIED"/>
  |          </ManagedObject>
  |          <DeploymentContext name="jboss.ejb:ejbName=BankDAOBean">
  |             <!-- default security domain for application -->
  |             <ManagedObject name="Security">
  |                 <ManagedProperty name="SecurityDomain" value="UNMODIFIED"/>
  |             </ManagedObject>
  |          </DeploymentContext>
  |       </DeploymentContext>
  | </DeploymentContext>
  | 

Since the admin tool would have knowledge of structure, why not have a set of management deployers or another specific management() callback on the Deployer SPI?  The admin tool would send back a list of ManagedProperties with structural information attached.

Lets use the modification of a security-domain of an EJB on the above as an example.  Admin tool would change the name of the ManagedProperty and send this back to the MainDeployer:


  |  
  | <DeploymentContext name="MyApp.ear">
  |       <DeploymentContext name="MyEjb.jar">
  |          <DeploymentContext name="jboss.ejb:ejbName=BankDAOBean">
  |             <ManagedObject name="Security">
  |                 <ManagedProperty name="SecurityDomain" value="CorporateDomain"/>
  |             </ManagedObject>
  |          </DeploymentContext>
  |       </DeploymentContext>
  | </DeploymentContext>
  | 
  | 

MainDeployer would navigate to the specific DeploymentContext and push the Update object to a set of deployers.  Each deployer decides what it wants to do with the update.  The EjbSecurityDeployer would be in this list.  It would take the change, lookup the specific SecurityDomain and reset it on the EJBContainer.  

The maindeployer would also attach the Update to the  DeploymentContext.  If an Update with the same ManagedObject and Property is there, the old one is removed.  If the UPdate is persistable, the mainDeployer adds it to the Profile.

At server restart, the EjbDeployer would merge any persisted Updates into its metamodel.

Now what if the admin tool updated the EAR's default security domain?


  |  
  | <DeploymentContext name="MyApp.ear">
  |    <ManagedObject name="Security">
  |       <ManagedProperty name="SecurityDomain" value="CorporateDomain"/>
  |    </ManagedObject>
  | </DeploymentContext>
  | 
  | 

The way this would work would be that the MainDeployer would see that there are child DeploymentContexts and try to "deploy" the change to each and every child context.  The EjbSecurityDeployer would do something like this:


  | {
  |    public void managementEvent(ManagedUpdate update, DeploymentContext context) {
  |       if (update.getName() != "Security) return;
  | 
  |       boolean isThisContextUpdated = update.getDeploymentContext == context;
  | 
  |       EJBDeployment deployment = context.getMetaData(EJBDeployment.class);
  |       if (deployment != null) 
  |       {
  |          // we are at the "ejb.jar" context deployment level.
  |          deployment.setSecurityDomain(update.getProperty("security-domain").getValue());
  |          return;
  |       }
  | 
  |       EJBContainer container = context.getMetaData(EJBContainer.class);
  |       if (container != null) {
  |         String newSecurityDomain = update.getProperty("security-domain").getValue();
  |         // we are at the EJBContainer level
  | 
  |         if (isThisContextUpdated)
  |         {
  |            // the admin tool has updated the same DeploymentContext as the EJBContainer
  |            container.updateSecurityDomain(newSecurityDomain);
  |         }
  |         else
  |         {
  |            // the admin tool has updated the ejb.jar context or the EAR's context, so only
  |            // set if our securitydomain is null
  |            if (container.getSecurityDomain() == null) container.updateSecurityDomain(newSecurityDomain);
  |         }
  |      }
  | }
  | 
 
 
        


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

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