[jboss-dev-forums] [Design of POJO Server] - Re: Moving forward with the profile service mgmt api

[adrian@jboss.org]

"scott.stark at jboss.org" wrote : 
  | The piece that is missing is how does the profile service take a ManagedObject populated with a set of changes, and then merge that into the base DeploymentContext metadata attachments to create the predetermined attachments that override the raw deployment values.
  | 

The initial construction of DeploymentContexts from the profile
is a problem for the profile service (with or without predetermined attachments).

Of course the managed object will provide a method to
turn a managed object into its wrapped attachment (metadata object)
for serialization by the profile service.

The piece that is missing outside the profile service
will be an extension to the deployers api where there will be two links:

1) You are a "parsing deployer", tell me what your managed object looks like.
i.e. construct a managed object for this attachment you created.

2) You want to support runtime updates (not just redeployment), 
then the server side support of the managed object needs a link to the 
"real deployer' for the attachment.

anonymous wrote : 
  | The missing mapping is the attachment name, and the corresponding metdata object property(s). In general a ManagedObject properties are going to map to several different metadata objects/properties.
  | 

Correct, in fact I'll talk about this in a seperate thread, because this is
my major stumbing block. Most of the other stuff I know how to do
and it is just a case of doing it, but this requires some extra thought.

anonymous wrote : 
  | The ManagementView also needs to be updated to support applying a ManagedObject change. I don't see that the ManagedObject returned from the ManagementView is hooked up to the attachments it overrides, therefore, this needs to be a write step.
  | 

To repeat what I said above (in pseudo code):

  | ManagedObject mo = parsingDeployer.getManagedObject(Attachment);
  | 

Only each deployer/subsystem really knows how it wants to be managed.

With the usual caveats of providing implements/helpers for the deployer to choose
from and allowing overrides to fix up what the programmer of the deployer did (or did not) do. :-)

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

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