JBossDeveloper

Just for the bundle headers.

"alesj" wrote:

"johnbailey" wrote:
Just for the bundle headers.

That is an OSGi detail. And that's why there is a facade.
For plain manifest.mf, with OSGi headers, we'll use that, to map things to out CLMD model.
But the real stuff will be hidden underneath with CLMD, Modules, Domains, CLPolicys, ...

"alesj" wrote:

The new CLMD with Requirements/Capabilities has everything we need.
Along with Module and Domain they have been rewritten to have all the OSGi notions.

For OSGiMetaData, there should just be deployers that transform Manifest.MF --> OSGiMetaData --> ClassLoaderMetaData.

John,

Can you create different threads for different issues.
This thread is already three pages long. :-)

Ales,

You're getting confused, because ClassLoadingMetaData used to be
called ClassLoaderMetaData, but that conflicted with a class of the same
name in the MC (which is what John is talking about), so I changed it. :-)

The use of DeploymentControllerContext and DeploymentContext in the bundle
facade is wrong. It should not be using these classes directly, they are implement details.

The clue is the name of the class. If it doesn't contain spi then it is implementation
detail that you shouldn't use directly.
"import org.jboss.deployers.plugins.deployers.DeploymentControllerContext;"

Ok the DeploymentContext does contain spi in the package name,
but that's a mistake that will go away:
http://jira.jboss.com/jira/browse/JBMICROCONT-189

For a lot of what you are doing, you should be using the DeploymentUnit anyway.
e.g. DeploymentUnit.getClassLoader()

For the state changing, we obviously need to add methods to the MainDeployer
interface (which will delegate to the DeployersImpl)
such that you can move the deployment to different states.

You shouldn't be doing your own "housekeeping" work on the deployments.
That's not a facade. ;-)

I started by using the ControllerContext, but wasn't actually able to complete the state change correctly. If we are going to delegate to the MainDeployer, this will be no issue. I will move it back to the ControllerContext, and remove all references to the DeploymentContext as well. I just saw reference in our discussions to the Bundle being a different veiw of the DeploymentControllerContext, and I took it too literally, I often do that :). Just because the ControllerContext is a DeploymentControllerContext, that doesn't mean we should reference it as such.

Any idea on when the MainDeployer will have the correct interface to move the deployment to a different state?

"johnbailey" wrote:

Any idea on when the MainDeployer will have the correct interface to move the deployment to a different state?

"adrian@jboss.org" wrote:

"johnbailey" wrote:

Any idea on when the MainDeployer will have the correct interface to move the deployment to a different state?

I'm doing it now. I've already added a getMainDeployer() to the deployment unit.
I'm just adding a MainDeployer.change(deploymentName, DeploymentStage);

DeployerClient main = unit.getMainDeployer();
main.change(unit.getName(), DeploymentStages.CLASSLOADER);

"alesj" wrote:
When mapping Controller states to bundle states, you should consider DeploymentStages, since those are probably the one's we're after.
Those mentioned before are POJO centric.

I would do something like this:
ERROR --> UNINSTALLED
NOT_INSTALLED --> INSTALLED (this one looks funny, but it's technically ok :-)
CLASSLOADING --> RESOLVED
REAL --> STARTING / STOPPING
INSTALLED --> ACTIVE

DeploymentControllerContext deploymentControllerContext = (DeploymentControllerContext) context;
 String stageName = toState.getStateString();

 DeploymentContext deploymentContext = deploymentControllerContext.getDeploymentContext();
 try
 {
 List<Deployer> theDeployers = getDeployersList(stageName);
...

What you are struggling with is that we don't expose the MC api
through the deployer api. The MC is an implement detail.

The DeploymentStages create extra ControllerStates that are mostly different
from the POJO states. But it does this "on the fly". If you don't have the deployers
installed these states don't exist.

See DeployersImpl.

Equally, some of the controller states don't have deployer stages,
they only relate to POJO/JMX/etc.

We can add a
DeploymentStage DeployerClient::getDeployerStage(String deploymentName);
which will probably give you what you want?

I don't know what you do if a deployment moves to **ERROR**
or POST_CLASSLOADER, etc? :-)

"adrian@jboss.org" wrote:

We can add a
DeploymentStage DeployerClient::getDeployerStage(String deploymentName);
which will probably give you what you want?

I don't know what you do if a deployment moves to **ERROR**
or POST_CLASSLOADER, etc? :-)