-
1. Re: Moving forward with the profile service mgmt api
starksm64 Dec 16, 2006 9:06 AM (in response to ccrouch)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.
-
2. Re: Moving forward with the profile service mgmt api
starksm64 Dec 18, 2006 3:11 AM (in response to ccrouch)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 Scott.Stark@jboss.org * @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; }
-
4. Re: Moving forward with the profile service mgmt api
ccrouch Dec 19, 2006 11:22 AM (in response to 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 -
5. Re: Moving forward with the profile service mgmt api
starksm64 Dec 19, 2006 3:05 PM (in response to ccrouch)"charles.crouch@jboss.com" wrote:
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."charles.crouch@jboss.com" wrote:
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 -
6. Re: Moving forward with the profile service mgmt api
ccrouch Dec 20, 2006 11:33 AM (in response to ccrouch)"scott.stark@jboss.org" wrote:
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? -
7. Re: Moving forward with the profile service mgmt api
starksm64 Dec 20, 2006 1:41 PM (in response to ccrouch)Its something I'm looking at.
-
8. Re: Moving forward with the profile service mgmt api
adrian.brock Dec 21, 2006 8:05 AM (in response to ccrouch)"charles.crouch@jboss.com" wrote:
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? -
9. Re: Moving forward with the profile service mgmt api
adrian.brock Dec 21, 2006 8:21 AM (in response to ccrouch)"scott.stark@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.
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. :-) -
10. Re: Moving forward with the profile service mgmt api
adrian.brock Dec 21, 2006 9:15 AM (in response to ccrouch)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? -
11. Re: Moving forward with the profile service mgmt api
ccrouch Dec 21, 2006 9:40 AM (in response to ccrouch)"adrian@jboss.org" wrote:
"charles.crouch@jboss.com" wrote:
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? -
12. Re: Moving forward with the profile service mgmt api
ccrouch Dec 21, 2006 9:53 AM (in response to ccrouch)"adrian@jboss.org" wrote:
"scott.stark@jboss.org" 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.
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? -
13. Re: Moving forward with the profile service mgmt api
adrian.brock Dec 21, 2006 10:01 AM (in response to ccrouch)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? -
14. Re: Moving forward with the profile service mgmt api
adrian.brock Dec 21, 2006 10:04 AM (in response to ccrouch)"charles.crouch@jboss.com" wrote:
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 :-)