[jboss-as7-dev] NPE in POST_MODULE processors

[Stuart Douglas]

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