JBossDeveloper

This thread is getting too tangled. We need to spawn child threads
to deal with single issues.

"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?

"adrian@jboss.org" wrote:

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.

I've updated the Deployers with support for retrieving ManagedObjects.

See org.jboss.test.deployers.managed.test.DeployerManagedObjectUnitTestCase
which includes some TODOs (I've included some TODOs where I added the new api).

This means that jboss-managed.jar and jboss-metatype.jar need to be included
in the next mc snapshot for JBossAS. Although there isn't anything using this api
at runtime yet, the MainDeployer and DeployerWrapper import the ManagedObject interface.

Now you can retrieve the corresponding ManagedObjects for a deployment's
Attachments if the deployer has been coded to implement
org.jboss.deployers.spi.managed.ManagedObjectBuilder

I also updated the ManagedObject api with a

String getName();
Serializable getAttachment();

Where the getName() is the name of the attachment in the Attachments map(s)
of the DeploymentContext.

So there are some basic links between the
Deployer, DeploymentContext, Attachment and ManagedObject
but no real code (besides mock tests) that construct ManagedObjects

The rest of the basic Attachment/ManagedObject handling
(excluding non-redeployment runtime changes) should be handled by the profile service?

I'm going to go back to working on the ManagedObject generation now. :-)
Though you probably first need a "hand-written" ManagedObjectBuilder implementation
in the datasource deployer to complete the basic end-end tests?

Ok, I need to rethink how what I was doing fits into the ManagedObjectBuilder and ManagedProperty/Fields notion.

Thanks for fixing the build.

This SVN client in Eclipse is getting really annoying.

For some reason it had forgotten that my microcontainer/tools project
was managed by SVN?
This isn't the only problem with this buggy software. :-(
e.g. In the workspace where I'm doing the EJB metadata changes
I can't even resynchronise with SVN (it is totally broken).

Ironcially, I only started using Eclipse because it told me what I had changed
so I didn't break the build with partial checkins. :-)

This generally occurs because the file attributes in SVN changed in 1.4 and breaks backwards compatibility with the 1.3 and older clients. Either your client is too old, or your plugin is in a wonky state.

What version of the svn plugin are you using? Since I switched to the 1.1.8 (now 1.1.9) version for eclipse 3.2.1 I have not seen any issues with not seeing what has been modified. The only workspace that was still showing a problem like that had the label decoration settings disabled in the preferences.

1.1.8 - I have label decorations turned off for performance reasons.