[jboss-as7-dev] NPE in POST_MODULE processors

Wed Aug 15 04:59:39 EDT 2012

 > Why would the OSGI bundle not be able to resolve, is it because is 
waiting for another OSGI bundle to be installed?

This is by virtue of the API - BundleContext.install() does not resolve 
the bundle. As the method name suggests, it just installs the bundle.

In the hot-deployment case it is debatable whether bundle resolution and 
later bundle activation should be attempted or not. By design, the order 
of bundle deployment is not the responsibility of the user but that of 
the framework. For a complex graph of interdependent bundles the user 
cannot possibly be asked to deploy them in the "right order". Instead 
the API allows to INSTALL the complete set (i.e. make the metadata 
available to the resolver) and later activate the bundles as needed. 
There are other triggers for bundle resolution too (e.g. resource access)

We currently do resolve/activate during DUP processing on a trial basis. 
For a bundle that only has dedependencies on already installed bundles 
the resolve/activation works fine and the services become available. I 
guess this is the expected hot-deploy behaviour. A bundle that cannot 
resolve - for various reasons, one being the user says so - we dont 
attempt to start the bundle either. It would still run through all 
remaining DUPs but does not have a module attached.

Non-OSGi deployments that use jboss-modules metadata to define their 
dependencies (i.e. Dependencies clause in the manifest) have that 
problem too, but worse. A complex system of interdependent module 
deployments is likely not manageable because of this ordering issue. 
Even if the user gets the ordering right the first time, on server 
restart the notion of deployment order is lost and very likely initial 
deployments will fail with no osgi involved. Granted that this describes 
a use case that is not intended to be used for user deployments.

 > the classic one is deployment of JDBC drivers that have an OSGI manifest

We already removed the hack that disables OSGi for this case. The JDBC 
driver *is* an OSGi bundle because it contains valid OSGi metadata. It 
gets processed as such and should work as expected. All DUP processing 
is identical as before except the way module dependencies are computed 
and how the Module service is created. The only case where an OSGi 
bundle gets treated as a library jar is when it is located in an EAR/lib 
directory. Bundles contained in EARs are otherwise processed as OSGi sub 
deployments.

 > we should not be allowing the presence of the OSGI subsystem to 
provide a different experience for users that are only after EE 
functionality

Agreed, EE deployments should not be effected - and I don't think they 
are. The OSGi subsystem is not activated unless #1 you do so by 
management op #2 you deploy a bundle #3 some component is an injection 
target for the system BundleContext

 > We remove OSGI from the default profile, and provide a 
standalone-osgi.xml for users that wish to use OSGI

AFAICS this would remove a few services that are already lazy and a few 
DUPs that deal with bundle deployments. We already have the 
configuration for a pure OSGi runtime as you suggest. Removing the OSGi 
subsystem from the default profile would not solve the need for DUP 
authors to be aware of OSGi deployments and code for the case of 
unresolved bundle deployments.

 > OSGI deployment that cannot be resolved pause the deployment process 
until such time as they can be

Yes, this is very much in line with what I think how it should work. The 
management API should allow the user to specify whether a deployment 
should get resolved/activated too. As a desired side effect this could 
introduce life cycle for any AS7 deployment (i.e. start/stop decoupled 
from deploy/undeploy). I already did some work in this direction related 
to in "Add notion of start/stop for deployments 
<https://issues.jboss.org/browse/AS7-2777>". It builds on top of "Allow 
management client to associate metadata with DeploymentUnit 
<https://issues.jboss.org/browse/AS7-3694>", which is waiting to get 
pulled <https://github.com/jbossas/jboss-as/pull/2790>.

 > which means that there will always be a Module available

YES ;-)

cheers
--thomas

On 08/15/2012 07:26 AM, Stuart Douglas wrote:
> Why would the OSGI bundle not be able to resolve, is it because is waiting for another OSGI bundle to be installed? And if so, wouldn't it make more sense to pause the deployment process until the bundle can be resolved? Otherwise the behaviour will be different depending on when the bundle is resolved (e.g. if a bundle is resolved late it will not have EJB's deployed, if it is resolved early it will).
>
> I really hate the way that OSGI takes over and prevents the module being created, I am pretty sure that the number of users that this has caused problems for is larger than the number of users that actually use OSGI (the classic one is deployment of JDBC drivers that have an OSGI manifest).
>
> I think we really need a solution for this for AS 7.2, because as it currently stands we are primarily an EE app server, and we should not be allowing the presence of the OSGI subsystem to provide a different experience for users that are only after EE functionality.
>
> To this end, I propose the following:
>
> - We remove OSGI from the default profile, and provide a standalone-osgi.xml for users that wish to use OSGI, this way OSGI cannot affect users that simply want EE functionality
> - OSGI deployment that cannot be resolved pause the deployment process until such time as they can be, by making the POST_MODULE DeploymentUnitPhaseService passive, which means that there will always be a Module available.
>
> What do you think?
>
> Stuart
>
> On 15/08/2012, at 3:05 PM, Thomas Diesler <thomas.diesler at jboss.com> wrote:
>
>> Folks,
>>
>> a quick reminder that you cannot assume a valid Module attachment in
>> Phase.POST_MODULE or after.
>>
>> An OSGi deployment that cannot resolve won't have a Module attached to
>> the DU. There is talk about aligning the deployment phase names with
>> Bundle life cycle terminology. IMHO Phase.POST_MODULE and Phase.INSTALL
>> are not so lucky names because they imply meaning that may not be true.
>> For suggested improvement see https://issues.jboss.org/browse/AS7-3585
>>
>> This is related to: https://issues.jboss.org/browse/AS7-5376
>>
>> cheers
>> --thomas
>>
>> -- 
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Thomas Diesler
>> JBoss OSGi Lead
>> JBoss, a division of Red Hat
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20120815/6b969e29/attachment.html 