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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev