-
15. Re: Facade Questions
alesj Feb 25, 2008 1:48 PM (in response to alesj)"johnbailey" wrote:
On another note, if we are going to support using the facade for any deployment even ones not originating in a OSGI Bundle, we can not assume the OSGIMetaData will be attached to the DeploymentContext. In this case, we will need to create the headers given the other MetaData available, correct?
First, OSGIMetaData should only be used for a Describe phase, to construct matching ClassLoaderMetaData.
And CLMD can be attached from where ever; jboss-classloading.xml, programmatically, ...
Or why do you think we need OMD?
If you mean the services that can be used inside particular bundle, via ServiceRegistry, that's shouldn't be a problem.
MC already has a contextual awareness. -
16. Re: Facade Questions
johnbailey Feb 25, 2008 2:00 PM (in response to alesj)Just for the bundle headers.
-
17. Re: Facade Questions
alesj Feb 25, 2008 4:31 PM (in response to alesj)"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, ... -
18. Re: Facade Questions
johnbailey Feb 25, 2008 4:41 PM (in response to alesj)"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, ...
Sounds good. I will drop the reference to the OSGIMetaData attachment and pull it from the CLMD. -
19. Re: Facade Questions
alesj Feb 25, 2008 4:48 PM (in response to alesj)"johnbailey" wrote:
Sounds good. I will drop the reference to the OSGIMetaData attachment and pull it from the CLMD.
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. -
20. Re: Facade Questions
johnbailey Feb 25, 2008 11:15 PM (in response to alesj)"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.
It seems like the ClassLoadingMetaData is the correct choice. It has the Requirements and Capabilities representing the imports/exports. I will develop against that, as the ClassloaderMetaData only contains the ClassLoader. -
21. Re: Facade Questions
alesj Feb 26, 2008 5:04 AM (in response to alesj)"johnbailey" wrote:
as the ClassloaderMetaData only contains the ClassLoader.
The ClassLoader? -
22. Re: Facade Questions
adrian.brock Feb 26, 2008 6:28 AM (in response to alesj)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. :-) -
23. Re: Facade Questions
adrian.brock Feb 26, 2008 6:54 AM (in response to alesj)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. ;-) -
24. Re: Facade Questions
johnbailey Feb 26, 2008 9:02 AM (in response to alesj)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? -
25. Re: Facade Questions
adrian.brock Feb 26, 2008 9:22 AM (in response to alesj)"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);
This also requires a small tweak to the DeployersImpl so that it understands
that deployments may not be in the state where it last put them. :-) -
26. Re: Facade Questions
adrian.brock Feb 26, 2008 9:44 AM (in response to alesj)"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);
Ok this is done. I also had to move the DeploymentStage(s) class to the client api
and make it Serializable.
So you should now be able to do something like:DeployerClient main = unit.getMainDeployer(); main.change(unit.getName(), DeploymentStages.CLASSLOADER);
If you find any problems, then update the test case in the deployers-impl package,
to show the issue.
org.jboss.test.deployers.main.test.DeployerChangeStageTestCase -
27. Re: Facade Questions
johnbailey Feb 26, 2008 11:02 PM (in response to alesj)"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
It seems like the DeploymentStage isn't available through the DeploymentUnit or Controller context. I checked all the references of the DeploymentStage and didn't see it attached. It looks like the DeployersImpl translates the ControllerState into a DeploymentStage, which determines the Deployer to use.DeploymentControllerContext deploymentControllerContext = (DeploymentControllerContext) context; String stageName = toState.getStateString(); DeploymentContext deploymentContext = deploymentControllerContext.getDeploymentContext(); try { List<Deployer> theDeployers = getDeployersList(stageName); ...
Am I missing something? I will use the corrisponding ControllerStates for now, and we can move to the DeploymentStage if there is a way to get it. The only thing I don't see is the ControllerStates is the CLASSLOADING stage.
-
28. Re: Facade Questions
adrian.brock Feb 27, 2008 4:55 AM (in response to alesj)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? :-) -
29. Re: Facade Questions
adrian.brock Feb 27, 2008 7:14 AM (in response to alesj)"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? :-)
I've added this. **ERROR** is mapped to the NOT_INSTALLED deployment stage.