[JBoss Microcontainer Development] - New features in classloading
by adrian＠jboss.org
I've started committing some work on adding the missing OSGi features to jboss-cl.
The first couple are complete:
JBCL-127 - adds a notion of ClassNotFoundHandler. This allows a handler to intercept
a dynamic classloading request and resolve (or even install - see below) the missing classes.
JBCL-128 - adds some notifications. The most important of these is the class found
notification used in the "lazy start" - see below.
The others are still prototypes and need to properly integrated with the deployers/osgi
As part of this, I've introduced the notion of a LifeCycle to the classloading Module.
This allows us to invoke callbacks (when requested) on the Deployment or whatever
is the component model for the classloader.
JBCL-130 - lazy start - is a generalisation of lazy activation from osgi
where a deployment can be left in the classloader stage until somebody loads
a class from it
JBCL-131 - lazy resolve - implements the osgi feature where a classloader is not
even constructed unless someone "imports" one of its packages
JBCL-132 - resolver - this is a general api that will allow things like OBR to be
hooked it. But it could also be used to for example to download dependencies from
a maven repository when they are requested.
Part of the LifeCycle includes notification of ClassLoader create/destroy
which was something missing in our OSGi Bundle resolve notifications.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266362#4266362
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266362
16 years, 4 months
[JBoss OSGi Development] - Re: Service integration with MC
by adrian＠jboss.org
I'm not following what you are talking about?
Anything you getTarget() during the install() phase should have
a corresponding ungetTarget() during the uninstall() of the lifecycle.
If somebody is using the api manually (either the MC api directly or the OSGi api)
then it is up to them to make sure they don't have stale references.
With OSGi the references can go stale at anytime anyway, which is why the
service notification mechanism exists (in principle we should automatically
respond those if IOC is used and "redeploy" whatever it was injected into?)
Even if they do, they will/should be tidied up at Deployment/Bundle.stop()
when the ServiceTracking for that context should be disabled/cleaned up.
The ServiceFactory is just a lazy version of the service. i.e. you only construct it
if somebody wants to use it. Its still a singleton. It only controls when the object
is constructed (first access instead of upfront).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266345#4266345
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266345
16 years, 4 months
[JBoss OSGi Development] - Re: Service integration with MC
by alesj
"alesj" wrote :
| But that still leaves the problem of actual service usage at undeploy:
| "alesj" wrote :
| | whereas service could still hold onto the ref - which might be an issue if that ref is ServiceFactory,
| | as ServiceFactory::unget could modify the actual created service.
| |
Actually SF::unget is called at service unregister,
so this is a bit different, but doesn't change the problem that much.
We could still end up with "illegal" service,
but that's also the case right now - any install/uninstall that keeps injected service ref,
would be unwinded to appropriate state, but the ref would still be there,
once it's re-winded.
e.g.
| public someInstall(@Inject Foo bar)
| {
| if (this.bar != null) // which is true after unwind/re-wind
| ... // do some crazy stuff on it
|
| this.bar = bar;
| }
|
But I guess that's the problem of encapsulation,
where we go beyond plain java beans.
So, the problem just remains with the ugliness,
but I guess we can cope with that.
| try
| {
| // do some uninstall on CC:getTarget
| }
| finally
| {
| // invoke CC:ungetTarget
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266340#4266340
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266340
16 years, 4 months
[JBoss OSGi Development] - Re: No explicit control over bundle.start()
by adrian＠jboss.org
"alesj" wrote : "thomas.diesler(a)jboss.com" wrote :
| | The MC Framework incorrectly uninstalls the bundle if there is a failure in bundle.start()
| |
| No, that is / should be the right behavior, as you don't wanna have broken service stuck in some middle state.
|
| The is a notion of ErrorHandler in Controller, which might be useful,
| if we decide to go down this path.
|
That is the correct way to handle it. As we discussed when designing the
ErrorHandler, the default behaviour is to assume an error during the lifecycle
is fatal. We don't know whether the object that threw the exception
is still in a consistent state, so we throw it away.
This rule comes from the EJB spec and it is a very safe assumption.
The OSGi spec takes a different (and probably incorrect :-) view.
anonymous wrote :
| Imho, the real problem is how we handle this Bundle::start.
|
| "thomas.diesler(a)jboss.com" wrote :
| | The controller context reached its required stage DESCRIBED after bundle install. A subsequent call to bundle.start() is supposed to transition to stages CLASSLOADER and then INSTALLED, which corresponds to the Bundle states RESOLVED and ACTIVE respectively.
| |
| Bundle::start should only be called after we're past CLASSLOADER stage.
| At least in automated mode. If the user wants to do this before, it's his choice and potential fault.
|
No bundle.start() is no different to
change(deploymentContext, ControllerState.INSTALLED);
If the deployment was only in the DESCRIBE state, it should transistion through
all the intermediate states.
Of course, it might not be able to do it if there are missing classloading dependencies
meaning the bundle cannot be resolved.
So the solution is to add an ErrorHandler to the DeploymentControllerContext
if it is an OSGi deployment, although I'd prefer it if this was an api on the
DeploymentUnit using DeploymentStages rather than working against the
implementation details.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266338#4266338
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266338
16 years, 4 months
[JBoss OSGi Development] - Goals of OSGi integration - Using a Standard spi for deploym
by adrian＠jboss.org
Beyond the obvious goal of implementing the OSGi spec the other part to having the
OSGi framework implemented on top of the MC/Deployers is so you can control
other types of deployments using the Bundle/Service api.
This is a standardised api. Which means some people are much more confortable
writing to it than for example the JBoss MainDeployer api.
There's also the reverse requirement that the OSGi components
should work properly from the MC/Deployers.
Some typical use cases:
1 ) INSTALLATION
I want to deploy a webapp. I do:
Bundle myWar = someBundle.installBundle(myWarURL);
Since this is not an OSGi bundle it will automatically move to the ACTIVE state
(unlike normal bundles which which require a bundle.start() unless there
is some other rule to do it, e.g. start level service or persistent state, etc).
This worked until the latest changes.
1a) It should be possible to deploy OSGi bundles using the MainDeployer, e.g.
via hot deployment.
AFAIK this works?
2) CONTROLLING LIFECYCLE
I can use the OSGi api to control the lifecycle of non-osgi deployments.
e.g.
Bundle tomcat = ...;
tomcat.stop();
// do stuff
tomcat.start();
This also worked until the latest changes.
2a) In reverse you should be able to control the OSGi bundles and services
using the MC/Deployers api.
This works for deployments, but it isn't going to understand things like the
AUTO_START_PROPERTY which is unknown to the MC code.
3) ACCESSING SERVICES
I should be able to use the OSGi api to access jboss services, e.g.
ServiceReference[] dataSources = bundleContext.getServiceReferences(javax.sql.DataSource.class.getName(), null);
Those services should look like they are associated with a Bundle (the BundleState
associated with the DeploymentUnit that created the datasource) and do all
the notifications, security checks etc. that OSGi requires.
This doesn't work. See the "ServiceTracking" thread where Ales and I discussed
how to implement this.
3a) In reverse, OSGi deployed services should be available to the MC
for use in dependency injection.
4) INTEGRATED CLASSLOADING
I should be able to import classes from JBoss deployments.
e.g.
ImportPackage: javax.ejb;version=3.0
This doesn't work for the reasons described on the "resolver is wrong" thread.
4a) In reverse OSGi bundle classes should be available
to non-osgi deployments.
This works, but the rules will likely be inconsistent to what the
ResolverPlugin is doing, leading to classloading problems?
5) MANAGEMENT
Other deployments and services that are not OSGI deployments should still
appear in things like the package admin.
5a) In reverse, OSGi bundles and services should be available to JBoss
management tools, e.g. the management console
6) OTHER OSGI FEATURES
Other OSGi features, like lazy start should work for other non-osgi deployments.
Or you should be able to add a war to an osgi start level.
etc.
6a) You can use JBoss specific features to augment/change the standard behaviour of an
osgi-bundle. e.g. adding a META-INF/jboss-classloading.xml to change the
classloading requirements without touching the manifest. (This would be essentially
what the management console will do if you modify the classloading rules there).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266334#4266334
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266334
16 years, 4 months