Moving forward with the profile service mgmt api

[ccrouch]

In the JBAS5 call this morning Adrian and I discussed how best we could proceed with fleshing out/writing tests for the management aspects of the profile service in parallel with Adrian developing the new managed object api and implementation. The conclusion that we came to was that the interface to Adrian's new managed objects would look quite similar to the ManagedObject/PropertyInfo interfaces we currently have. Therefore it should be possible to push ahead and build out the api's the profile service needs using the existing interfaces, and then refactor them when Adrian has committed his revised version. It should also be feasible to do the same with testcases, i.e. we write tests now and try to mock up/stub out interfaces that we require to get the tests going then come back and refactor later.

There is definitely going to be rework needed when Adrians stuff lands but at least this approach should enable forward progress to be made in related areas in the meantime. The plan is in the JBAS5 call next week for Adrian to provide an estimate on when the new managed object api and impl would be available.

Scott, does this approach make sense too you? Is it something you can push ahead with?

Thanks

[starksm64]

Yes, but I need to get the PS using a deployment repository that holds the modified deployment metadata to effectively test this. That is what I hope to get done this weekend.

[starksm64]

Still too many distractions to get this done this weekend. I have checked in the current state. The two things to complete are getting the attachments for the base deployments stored in the repository, and then obtaining the attachments for a ManagedObject update to store as overrides. The profile repository notion I'm working with is defined by this spi:

package org.jboss.profileservice.spi;

import java.io.IOException;
import java.io.InputStream;
import java.net.URI;
import java.util.Collection;
import java.util.zip.ZipInputStream;

import org.jboss.deployers.spi.attachments.Attachments;
import org.jboss.deployers.spi.structure.DeploymentContext;
import org.jboss.virtual.VirtualFile;

/**
 * An interface for managing the contents of a Profile.
 *
 * @author [e-mail]
 * @version $Revision:$
 */
public interface DeploymentRepository
{
 public URI getBootstrapURI();
 public void setBootstrapURI(URI uri);
 public URI getDeployersURI();
 public void setDeployersURI(URI uri);
 public URI getDeploymentURI();
 public void setDeploymentURI(URI rootURI);

 // Upload a raw deployment
 public VirtualFile addDeploymentFile(String name, ZipInputStream contentIS)
 throws IOException;
 // Get the raw deployment
 public VirtualFile getDeploymentFile(String name);

 // Bootstrap
 public void addBootstrap(String vfsPath, DeploymentContext ctx)
 throws IOException;
 public DeploymentContext getBootstrap(String vfsPath);
 public Collection<DeploymentContext> getBootstraps();
 public void removeBootstrap(String vfsPath)
 throws IOException;

 // Deployers
 public void addDeployer(String vfsPath, DeploymentContext ctx)
 throws IOException;
 public DeploymentContext getDeployer(String vfsPath);
 public Collection<DeploymentContext> getDeployers();
 public void removeDeployer(String vfsPath)
 throws IOException;

 // Deployments
 public void addDeployment(String vfsPath, DeploymentContext ctx)
 throws IOException;
 public DeploymentContext getDeployment(String vfsPath);
 public void removeDeployment(String vfsPath)
 throws IOException;
 public Collection<DeploymentContext> getDeployments();

 // Managed object attachments for a deployment
 public void addManagedObject(String vfsPath, Attachments edits)
 throws IOException;
}

[adrian.brock]

FYI:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=97599

[ccrouch]

So we've got a new ManagedObject api from Adrian. The underlying implementation is still being worked on
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/managed/src/main/org/jboss/managed/api/

Also I understand that the meta data repository notion continues to be fleshed out:
From Scott: "The two things to complete are getting the attachments for the base deployments stored in the repository, and then obtaining the attachments for a ManagedObject update to store as overrides."

Questions about next steps:

1) Does the additional work on the repository outlined above prevent progress on writing tests for the use cases we're going to need wrt basic DataSource management? I presume that the work remaining would actually prevent the tests from passing, but thats the next step :-). I guess we could stub out aspects of the repository to get the test to pass, but at the moment I'm more interested in the tests being written than having them pass.

2) Should the org.jboss.deployers.spi.management.ManagementView be updated to use the new ManagedObject api?

3) The tests for the DataSource use cases should go in here?
http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/tests/org/jboss/test/profileservice/test/

Presumably the idea is that we can create our own mock impls or use the one Adrian has provided:
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/managed/src/main/org/jboss/managed/mock/MockDataSourceManagedObject.java

Cheers

[starksm64]

Questions about next steps:

1) Does the additional work on the repository outlined above prevent progress on writing tests for the use cases we're going to need wrt basic DataSource management? I presume that the work remaining would actually prevent the tests from passing, but thats the next step :-). I guess we could stub out aspects of the repository to get the test to pass, but at the moment I'm more interested in the tests being written than having them pass.

2) Should the org.jboss.deployers.spi.management.ManagementView be updated to use the new ManagedObject api?

It can be. 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 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.

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.

3) The tests for the DataSource use cases should go in here?
http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/tests/org/jboss/test/profileservice/test/

Presumably the idea is that we can create our own mock impls or use the one Adrian has provided:
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/managed/src/main/org/jboss/managed/mock/MockDataSourceManagedObject.java

[ccrouch]

It can be. 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 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.

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.

Ok, is this something you are going to looking at, or Adrian?

[starksm64]

Its something I'm looking at.

[adrian.brock]

2) Should the org.jboss.deployers.spi.management.ManagementView be updated to use the new ManagedObject api?

The ManagementView looks more like a profile service api than a deployers
or a managed object api?

[adrian.brock]

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.

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.

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. :-)

[adrian.brock]

Further to the FYI, I've updated the ManagedObject api to implement the AOP skeleton.

So it should be possible for Scott to intercept changes to the ManagedObject
and persist them according to whatever required. e.g.

* Persist on every change (simple)
* Persist when the user clicks "apply" (implemented a bit like transactions in JavaEE)
* Versioning (create a new version on every change or more lazily, e.g. only when
the user chooses to save the changes)
* etc.

In fact, I have a feeling that some of the simpler processing has a lot in
common with what POJO Cache does in terms of intercepting changes
and allowing atomic updates/rollbacks?

[ccrouch]

2) Should the org.jboss.deployers.spi.management.ManagementView be updated to use the new ManagedObject api?

The ManagementView looks more like a profile service api than a deployers
or a managed object api?

So are you advocating moving it or changing it?

[ccrouch]

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.

Adrian,
The new thread you started:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=97767
seems aimed at the more complicated use cases for this mapping. For Beta2 I would prefer us to concentrate on implementing and testing the simpler mapping cases first and then come back and revisit this in light of the more complicated ones. I think having a working implementation out there, even for just the simple case, will help us and others to think about this problem more concretely. If that means interfaces/impls need to change between Beta2 and the next release then so be it.

Does the ManagedObject to metadata object/properties mapping for DataSources fall into the "trivial" category?

[adrian.brock]

If I understand what it does from the javadoc then yes, I'd say
it should be moved to the profile service api?

The actual implementation would probably delegate most of the work
to the deployer(s), but the deployers or managed object api don't know
what a profile or version is.

The deployers and managed objects api are primitives used by the profile service.

It does bring up one "todo" which is to flesh out the
deployment/managed object/attachment identity notions.
I haven't come across anything that uses this yet, but I imagine Scott might
have to deal with the issue in what he is working on?

[adrian.brock]

For Beta2 I would prefer us to concentrate on implementing and testing the simpler mapping cases first and then come back and revisit this in light of the more complicated ones.

That was my conclusion as well, if you read the last paragraph.

It was Scott that brought up the issue of more complicated structures.
The DataSource isn't that complicated (at least at the front end management level :-)