Stuart says
/In that case we will need two manifest attachment processors, as we
also need to pick up the manifests of resource roots that are added
by other processors, (e.g. WEB-INF/ lib jars)
/
Currently, there is at most one Manifest attachment to the
DeploymentContext. The OSGi Manifest Processor checks if that Manifest
exists and contains valid OSGi metadata. This qualifies a deployment as
OSGi bundle.
Manifests that come from nested artefacts, could perhaps be added under
a different key (i.e. not the Manifest for the deployment root). DUPs
should either be able to process OSGi bundle deployments or
alternatively ignore them if they cannot do that (just yet).
Perhaps a processor order like this would work
public static final int STRUCTURE_MANIFEST = 0x0100;
public static final int STRUCTURE_OSGI_MANIFEST = 0x0200;
public static final int STRUCTURE_NESTED_MANIFEST = 0x0300;
public static final int STRUCTURE_RAR = 0x0400;
public static final int STRUCTURE_WAR_DEPLOYMENT_INIT = 0x0500;
...
cheers
-thomas
On 03/16/2011 10:11 AM, Thomas Diesler wrote:
Folks,
an OSGi bundle deployment is fundamentally different from an EE
deployment and must be handled by the OSGi subsystem. DUPs that are
not targeted for OSGi bundle deployments must ignore these. Currently
the recommended approach to ignore an OSGi deployment in a DUP is
DeploymentUnit deploymentUnit = phaseContext.getDeploymentUnit();
if(deploymentUnit.hasAttachment(Attachments.OSGI_MANIFEST)) {
return;
}
If you work on some other type of marker attachment, make sure that
this marker is not attached for an OSGi deployment. For the above
check to work, the OSGi manifest processor must come early in the
chain. I changed the order of structure processors to
// STRUCTURE
public static final int
STRUCTURE_MOUNT = 0x0000;
public static final int
STRUCTURE_MANIFEST = 0x0100;
public static final int
STRUCTURE_OSGI_MANIFEST = 0x0200;
public static final int
STRUCTURE_RAR = 0x0300;
...
This relates to a bug related to WAB (Webapp Bundle) deployments
https://issues.jboss.org/browse/JBAS-8940
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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx