-
1. Re: Facade Questions
adrian.brock Feb 22, 2008 4:24 AM (in response to alesj)"johnbailey" wrote:
Am I making any sense? I am getting a really good understanding of
the MC and deployments, but I guess I need a clearer understanding of
how a client would use the Facade? Is there a client type we are
looking to support?
The use case is people wanting to use the OSGi api to control deployments
which is spec defined rather than the JBoss specific api. -
2. Re: Facade Questions
johnbailey Feb 22, 2008 9:02 AM (in response to alesj)Ok. I will start on the facade assuming there will be at least a DeploymentUnit available. If the Unit has an attached ControllerContext, it will delegate to the attached version, otherwise it will create a DeployentContollerContext. Does this seem like the correct approach?
It seems like the BundleContext will need access to the DeploymentUnit in order to create ServiceReferences, which I see as components of the Deployment. Make sense? -
3. Re: Facade Questions
adrian.brock Feb 22, 2008 9:17 AM (in response to alesj)"johnbailey" wrote:
Ok. I will start on the facade assuming there will be at least a DeploymentUnit available. If the Unit has an attached ControllerContext, it will delegate to the attached version, otherwise it will create a DeployentContollerContext. Does this seem like the correct approach?
They will always be available. The only time you need to create them
in the OSGi layer is in the BundleContext::installBundle() methods
which you will do indirectly by delegating to the main deployer.
It seems like the BundleContext will need access to the DeploymentUnit in order to create ServiceReferences, which I see as components of the Deployment. Make sense?
Yes, ServiceReferences are deployment components that
are installed as "ServiceReferenceControllerContexts" into the MC.
They're really just facades on top of any ControllerContext.
This allows us to expose MBeans and POJOs (using the same facade)
as OSGi services and also potentially dependency inject OSGi
services into mbeans and pojos.
Ales can tell you which parts are already done and what the classes
are really called, the devil is always in the details. ;-) -
4. Re: Facade Questions
johnbailey Feb 22, 2008 10:06 AM (in response to alesj)Great. Thanks for the info. I will focus on the initial work with the Bundle facade first, and then move on to the ServiceReference registration once the basic Bundle work is complete.
-
5. Re: Facade Questions
johnbailey Feb 24, 2008 8:55 PM (in response to alesj)Assuming the DeploymentControllerContext is always available to the Bundle, can we also assume the DeploymentControllerContext has also been installed into the Controller? Looking through the DeployersImpl the DeploymentControllerContext is created, installed into the controller, attached to the DeploymentContext, and moved through all known states for the DeployersImpl.
So if the Bundle.start method delegates to the DeploymentControllerContext.changeState(...), would it look something like this:public void start() throws BundleException { DeploymentControllerContext deploymentControllerContext = getControllerContext(); DeploymentContext deploymentContext = deploymentControllerContext.getDeploymentContext(); // Go through the states in order List<ControllerState> states = getControllerContext().getController().getStates(); for (ControllerState state : states) { if (DeploymentState.ERROR.equals(deploymentContext.getState()) == false) { try { deploymentControllerContext.getController().change(getControllerContext(), state); } catch (Throwable t) { deploymentContext.setState(DeploymentState.ERROR); deploymentContext.setProblem(t); } } } }
Also, I have completed some other work on the Facade, should I document it on the existing 'OSGI Facade' JIRA http://jira.jboss.com/jira/browse/JBOSGI-8, or create a more detailed task? -
6. Re: Facade Questions
alesj Feb 25, 2008 5:05 AM (in response to alesj)"johnbailey" wrote:
So if the Bundle.start method delegates to the DeploymentControllerContext.changeState(...), would it look something like this:
I don't think you need to move step-by-step.
Simply change the state to INSTALLED.
And in the code, you need to rethrow the caught Throwable as a BundleException."johnbailey" wrote:
Also, I have completed some other work on the Facade, should I document it on the existing 'OSGI Facade' JIRA http://jira.jboss.com/jira/browse/JBOSGI-8, or create a more detailed task?
First post your findings here on the forum.
And we'll see if they need more detailed JIRAs. -
7. Re: Facade Questions
johnbailey Feb 25, 2008 9:14 AM (in response to alesj)Makes sense. I wasn't sure if it would be in a state that would allow it to move directly to INSTALLED.
The getState method will simply map the ControllerState to an equivelent Bundle State. Are the following resonable?ControllerState controllerState = getControllerContext().getState(); if (ControllerState.ERROR.equals(controllerState)) { bundleState = Bundle.INSTALLED; // Seems strange, but see javadoc } else if (ControllerState.NOT_INSTALLED.equals(controllerState)) { bundleState = Bundle.UNINSTALLED; } else if (ControllerState.PRE_INSTALL.equals(controllerState) || ControllerState.DESCRIBED.equals(controllerState)) { bundleState = Bundle.INSTALLED; } else if (ControllerState.INSTANTIATED.equals(controllerState) || ControllerState.CONFIGURED.equals(controllerState) || ControllerState.CREATE.equals(controllerState)) { bundleState = Bundle.RESOLVED; } else if (ControllerState.START.equals(controllerState)) { bundleState = Bundle.STARTING; } else if (ControllerState.INSTALLED.equals(controllerState)) { bundleState = Bundle.ACTIVE; }
Want to make sure I get this correct. -
8. Re: Facade Questions
johnbailey Feb 25, 2008 9:22 AM (in response to alesj)Couple more questions:
1. What is the best way to get the location of the deployed asset (jar, etc..). I see the name of the VFSFile in the name of the DeploymentContext, but I want to make sure the location returned will always be a valid path to the asset. The Bundle Facade needs to return the location as well as search for entries without a classloader (Bundle.getEntry, Bundle.getEntryPaths)
2. Will we be supporting the OSGI AdminPermission checks?
3. Is there an existing Id that can be used for the Bundle ID? It needs to be unique, and I don't want to create a new scheme if there is something in place to use. -
9. Re: Facade Questions
alesj Feb 25, 2008 9:35 AM (in response to alesj)"johnbailey" wrote:
Makes sense. I wasn't sure if it would be in a state that would allow it to move directly to INSTALLED.
You can always try to move it to any state from any state (except error state).
But it doesn't mean it will actually move there - e.g. still some unresolved dependencies 'blocking' the transition."johnbailey" wrote:
The getState method will simply map the ControllerState to an equivelent Bundle State. Are the following resonable?ControllerState controllerState = getControllerContext().getState(); if (ControllerState.ERROR.equals(controllerState)) { bundleState = Bundle.INSTALLED; // Seems strange, but see javadoc } else if (ControllerState.NOT_INSTALLED.equals(controllerState)) { bundleState = Bundle.UNINSTALLED; } else if (ControllerState.PRE_INSTALL.equals(controllerState) || ControllerState.DESCRIBED.equals(controllerState)) { bundleState = Bundle.INSTALLED; } else if (ControllerState.INSTANTIATED.equals(controllerState) || ControllerState.CONFIGURED.equals(controllerState) || ControllerState.CREATE.equals(controllerState)) { bundleState = Bundle.RESOLVED; } else if (ControllerState.START.equals(controllerState)) { bundleState = Bundle.STARTING; } else if (ControllerState.INSTALLED.equals(controllerState)) { bundleState = Bundle.ACTIVE; }
Let's make this more OO. ;-)
e.g.List<BundleState2ControllerState> states ... ... for(BundleState2ControllerState bs2cs : states) { if (bs2cs.getControllerState().equals(state)) return bs2cs.getBundleState(); } throw new IllegalArgumentException("No such matching BS2CS.");
-
10. Re: Facade Questions
alesj Feb 25, 2008 9:47 AM (in response to alesj)"johnbailey" wrote:
1. What is the best way to get the location of the deployed asset (jar, etc..). I see the name of the VFSFile in the name of the DeploymentContext, but I want to make sure the location returned will always be a valid path to the asset. The Bundle Facade needs to return the location as well as search for entries without a classloader (Bundle.getEntry, Bundle.getEntryPaths)
The DeploymentContext should really be VFSDeploymentContext.
And that one has all the hooks you need."johnbailey" wrote:
2. Will we be supporting the OSGI AdminPermission checks?
We should. But it's not a priority.
I still need to look at that more thoroughly."johnbailey" wrote:
3. Is there an existing Id that can be used for the Bundle ID? It needs to be unique, and I don't want to create a new scheme if there is something in place to use.
Underlying context name should do.
That's how module's get their name.private static String determineContextName(DeploymentUnit unit) { if (unit == null) throw new IllegalArgumentException("Null unit"); ControllerContext context = unit.getAttachment(ControllerContext.class); if (context == null) throw new IllegalStateException("Deployment has no controller context"); return (String) context.getName(); }
-
11. Re: Facade Questions
alesj Feb 25, 2008 10:48 AM (in response to alesj)"johnbailey" wrote:
Are the following resonable?ControllerState controllerState = getControllerContext().getState(); if (ControllerState.ERROR.equals(controllerState)) { bundleState = Bundle.INSTALLED; // Seems strange, but see javadoc }
Can you post javadoc?
Not that I don't trust you, but just lazy to do own lookup. ;-)
Other look OK.
And since the controller states to bundle states mapping is 'growing function', you can do a simple function which will determine bundle state according to the controller state index value.
Hence not needing that List impl that I proposed earlier. -
12. Re: Facade Questions
johnbailey Feb 25, 2008 10:58 AM (in response to alesj)"alesj" wrote:
Can you post javadoc?
Not that I don't trust you, but just lazy to do own lookup. ;-)public static final int INSTALLED The bundle is installed but not yet resolved. A bundle is in the INSTALLED state when it has been installed in the Framework but is not or cannot be resolved. This state is visible if the bundle's code dependencies are not resolved. The Framework may attempt to resolve an INSTALLED bundle's code dependencies and move the bundle to the RESOLVED state.
Should we thrown an Exception instead? From the possible states (UNINSTALLED,INSTALLED,RESOLVED, STARTING, STOPPING, ACTIVE), INSTALLED seems to be the default. I was origionally thinking UNINSTALLED, but it is valid only after the Bundle has been uninstalled.public static final int UNINSTALLED The bundle is uninstalled and may not be used. The UNINSTALLED state is only visible after a bundle is uninstalled; the bundle is in an unusable state but references to the Bundle object may still be available and used for introspection.
-
13. Re: Facade Questions
alesj Feb 25, 2008 11:19 AM (in response to alesj)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 -
14. Re: Facade Questions
johnbailey Feb 25, 2008 11:27 AM (in response to alesj)I was looking at that as well. That seems a cleaner fit knowing the mappings you posted. I will use this moving forward.
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?