4:11 a.m.
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
4:22 a.m.
As I already commented on the JIRA issue, this approach just won't fly in the long
run.
Imagine every similar sub-system as OSGi that would need to be excluded all over the
place.
I'm also not saying this should be done immediately,
but I hope you have a long term vision where this kind of approach won't be needed.
Imo, this is what OSGi EE should be all about, to be able to run side-by-side, properly
integrated, not explicitly excluded.
On Mar 16, 2011, at 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
4:46 a.m.
New subject: Account for OSGi bundles in DeploymentUnitProcessors
Yes, I totally agree. In the long run the webapp subsystem should be
able to process WAB deployments.
Here is an entry point https://issues.jboss.org/browse/JBAS-8956
Currently, we deploy WABs on PAX-Web, which internally uses Jetty.
cheers
-thomas
On 03/16/2011 10:22 AM, Ales Justin wrote:
As I already commented on the JIRA issue, this approach just
won't fly
in the long run.
Imagine every similar sub-system as OSGi that would need to be
excluded all over the place.
I'm also not saying this should be done immediately,
but I hope you have a long term vision where this kind of approach
won't be needed.
Imo, this is what OSGi EE should be all about, to be able to run
side-by-side, properly integrated, not explicitly excluded.
On Mar 16, 2011, at 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 <mailto:jboss-as7-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
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
5:02 a.m.
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
9:16 a.m.
On 03/16/2011 04: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
I think this is the wrong approach. Instead we need to make these
deployments compatible. There are many other deployers for example
which are not necessarily EE specific which should work with OSGi.
If you look at the common contract for OSGi and EE there is actually
more that can be shared than you might think. OSGi really should only
take over class loading and structure processing. In particular, when
OSGi creates the module for the deployment it should create it in the
standard location and if possible it should respect additional
dependencies specified by other deployers (however, processing of
Class-Path at least should probably be skipped in this case, unless it's
possible to make it work cleanly with OSGi).
Then the service-type deployers should be allowed to run - in
particular, deployers which process META-INF/services and probably most
deployment descriptor types should work just fine as far as I can see.
Is there any specific reason why we cannot do this?
--
- DML
5029
days inactive
5029
days old
4 comments
3 participants
participants (3)
-
Ales Justin -
David M. Lloyd -
Thomas Diesler