OSGi deployments cause missing Module for other deployment processors?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

OSGi deployments cause missing Module for other deployment processors?

Jaikiran Pai
While looking at a user reported bug in AS7, I noticed that a user
deployment can be missing a MODULE attachment. My understanding so far
was that each deployment will *always* have a MODULE attached to it. But
looking at the code, I see that some deployments are skipped while
creating and attaching the modules. Specifically, if a deployment
contains a OSGi Manifest, then the module creation and attachment is
skipped for that module
https://github.com/jbossas/jboss-as/blob/master/server/src/main/java/org/jboss/as/server/deployment/module/ModuleSpecProcessor.java#L77

Why is that the case? Aren't deployments which contain OSGi Manifest
supposed to be processed by other deployers (for example a EJB
annotation processing deployer)?

-Jaikiran
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: OSGi deployments cause missing Module for other deployment processors?

Thomas Diesler
An OSGi bundle has a lifecycle of

* INSTALLED
* RESOLVED
* ACTIVE
* RESOLVED
* UNINSTALLED

The classloader is created as part of the bundle resolution phase.
Specifically, the OSGi resolver determines on the basis of OSGi metadata
a consistent wiring between the installed bundles. It is therefore
incorrect to create a jboss module definition for an OSGi bundle at
deploy time.

The fundamental question is: Are you deploying an OSGi bundle or not? If
it is an OSGi bundle, it should be treated as such (i.e. it is not an
AS7 module deployment). The OSGi enterprise spec support the notion of
OSGi web application bundles (WAB). A WAB may have file extension *.war,
it would still be a bundle deployment.

#1 Do we have an issue with the OSGi layer not handling a bundle
deployment correctly?
#2 Do we have an issue with some AS7 DUP that does not account for the
possibility that a deployment is an OSGi bundle?

DUPs that cannot handle OSGi bundles should check for the OSGI_MANIFEST
attachment

         if (deploymentUnit.hasAttachment(Attachments.OSGI_MANIFEST)) {
             return;
         }

cheers
-thomas


On 08/21/2011 09:08 AM, Jaikiran Pai wrote:

> While looking at a user reported bug in AS7, I noticed that a user
> deployment can be missing a MODULE attachment. My understanding so far
> was that each deployment will *always* have a MODULE attached to it. But
> looking at the code, I see that some deployments are skipped while
> creating and attaching the modules. Specifically, if a deployment
> contains a OSGi Manifest, then the module creation and attachment is
> skipped for that module
> https://github.com/jbossas/jboss-as/blob/master/server/src/main/java/org/jboss/as/server/deployment/module/ModuleSpecProcessor.java#L77
>
> Why is that the case? Aren't deployments which contain OSGi Manifest
> supposed to be processed by other deployers (for example a EJB
> annotation processing deployer)?
>
> -Jaikiran
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: OSGi deployments cause missing Module for other deployment processors?

Jaikiran Pai
On Monday 22 August 2011 12:58 PM, Thomas Diesler wrote:

> An OSGi bundle has a lifecycle of
>
> * INSTALLED
> * RESOLVED
> * ACTIVE
> * RESOLVED
> * UNINSTALLED
>
> The classloader is created as part of the bundle resolution phase.
> Specifically, the OSGi resolver determines on the basis of OSGi
> metadata a consistent wiring between the installed bundles. It is
> therefore incorrect to create a jboss module definition for an OSGi
> bundle at deploy time.
>
> The fundamental question is: Are you deploying an OSGi bundle or not?

 From those couple of JIRAs which have been raised, I see that the
deployment contains a MANIFEST.MF which has some OSGi specific manifest.

Is it valid case to have a deployment which has OSGi MANIFEST and at the
same time contains EJBs? If yes, how do we handle those?


> #2 Do we have an issue with some AS7 DUP that does not account for the
> possibility that a deployment is an OSGi bundle?
>

Yes, we do have DUPs (atleast I can think of a EJB3 one) which have no
idea of OSGi and don't even check if it's a OSGi bundle.

> DUPs that cannot handle OSGi bundles should check for the
> OSGI_MANIFEST attachment
>
>         if (deploymentUnit.hasAttachment(Attachments.OSGI_MANIFEST)) {
>             return;
>         }

I'm not sure we should be doing that in individual DUPs. For example,
why should EJB3 deployers be worried about OSGi?

I mean if at all we need to skip such "post module" deployment unit
processors then that should be done outside of the DUP, since the DUP
already states (by setting its Phase as Phase.POST_MODULE) that it
requires a module to function correctly. If a module isn't present in a
DU then I don't think passing on the control that "post module"
deployment processor makes sense.

Thoughts?

-Jaikiran


>
> cheers
> -thomas
>
>
> On 08/21/2011 09:08 AM, Jaikiran Pai wrote:
>> While looking at a user reported bug in AS7, I noticed that a user
>> deployment can be missing a MODULE attachment. My understanding so far
>> was that each deployment will *always* have a MODULE attached to it. But
>> looking at the code, I see that some deployments are skipped while
>> creating and attaching the modules. Specifically, if a deployment
>> contains a OSGi Manifest, then the module creation and attachment is
>> skipped for that module
>> https://github.com/jbossas/jboss-as/blob/master/server/src/main/java/org/jboss/as/server/deployment/module/ModuleSpecProcessor.java#L77 
>>
>>
>> Why is that the case? Aren't deployments which contain OSGi Manifest
>> supposed to be processed by other deployers (for example a EJB
>> annotation processing deployer)?
>>
>> -Jaikiran
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: OSGi deployments cause missing Module for other deployment processors?

Jaikiran Pai
For everyone's reference, the JIRAs that show up this issue are:

https://issues.jboss.org/browse/AS7-1551
https://issues.jboss.org/browse/AS7-1601

-Jaikiran
On Monday 22 August 2011 01:16 PM, Jaikiran Pai wrote:

> On Monday 22 August 2011 12:58 PM, Thomas Diesler wrote:
>> An OSGi bundle has a lifecycle of
>>
>> * INSTALLED
>> * RESOLVED
>> * ACTIVE
>> * RESOLVED
>> * UNINSTALLED
>>
>> The classloader is created as part of the bundle resolution phase.
>> Specifically, the OSGi resolver determines on the basis of OSGi
>> metadata a consistent wiring between the installed bundles. It is
>> therefore incorrect to create a jboss module definition for an OSGi
>> bundle at deploy time.
>>
>> The fundamental question is: Are you deploying an OSGi bundle or not?
>
>    From those couple of JIRAs which have been raised, I see that the
> deployment contains a MANIFEST.MF which has some OSGi specific manifest.
>
> Is it valid case to have a deployment which has OSGi MANIFEST and at the
> same time contains EJBs? If yes, how do we handle those?
>
>
>> #2 Do we have an issue with some AS7 DUP that does not account for the
>> possibility that a deployment is an OSGi bundle?
>>
>
> Yes, we do have DUPs (atleast I can think of a EJB3 one) which have no
> idea of OSGi and don't even check if it's a OSGi bundle.
>
>> DUPs that cannot handle OSGi bundles should check for the
>> OSGI_MANIFEST attachment
>>
>>          if (deploymentUnit.hasAttachment(Attachments.OSGI_MANIFEST)) {
>>              return;
>>          }
>
> I'm not sure we should be doing that in individual DUPs. For example,
> why should EJB3 deployers be worried about OSGi?
>
> I mean if at all we need to skip such "post module" deployment unit
> processors then that should be done outside of the DUP, since the DUP
> already states (by setting its Phase as Phase.POST_MODULE) that it
> requires a module to function correctly. If a module isn't present in a
> DU then I don't think passing on the control that "post module"
> deployment processor makes sense.
>
> Thoughts?
>
> -Jaikiran
>
>
>>
>> cheers
>> -thomas
>>
>>
>> On 08/21/2011 09:08 AM, Jaikiran Pai wrote:
>>> While looking at a user reported bug in AS7, I noticed that a user
>>> deployment can be missing a MODULE attachment. My understanding so far
>>> was that each deployment will *always* have a MODULE attached to it. But
>>> looking at the code, I see that some deployments are skipped while
>>> creating and attaching the modules. Specifically, if a deployment
>>> contains a OSGi Manifest, then the module creation and attachment is
>>> skipped for that module
>>> https://github.com/jbossas/jboss-as/blob/master/server/src/main/java/org/jboss/as/server/deployment/module/ModuleSpecProcessor.java#L77
>>>
>>>
>>> Why is that the case? Aren't deployments which contain OSGi Manifest
>>> supposed to be processed by other deployers (for example a EJB
>>> annotation processing deployer)?
>>>
>>> -Jaikiran
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: OSGi deployments cause missing Module for other deployment processors?

jtgreene
Administrator
In reply to this post by Jaikiran Pai
On 8/22/11 2:46 AM, Jaikiran Pai wrote:

> On Monday 22 August 2011 12:58 PM, Thomas Diesler wrote:
>> An OSGi bundle has a lifecycle of
>>
>> * INSTALLED
>> * RESOLVED
>> * ACTIVE
>> * RESOLVED
>> * UNINSTALLED
>>
>> The classloader is created as part of the bundle resolution phase.
>> Specifically, the OSGi resolver determines on the basis of OSGi
>> metadata a consistent wiring between the installed bundles. It is
>> therefore incorrect to create a jboss module definition for an OSGi
>> bundle at deploy time.
>>
>> The fundamental question is: Are you deploying an OSGi bundle or not?

Originally the solution we were all planning on for this problem was to
better align the DUPs to the OSGI dep phases and use PASSIVE phase
contexts (for everything PAST the OSGI Install [1]) to allow for the
deployment process to complete when the bundle is finally resolved. We
deferred this refactor though due to scheduling.

>
>    From those couple of JIRAs which have been raised, I see that the
> deployment contains a MANIFEST.MF which has some OSGi specific manifest.
>
> Is it valid case to have a deployment which has OSGi MANIFEST and at the
> same time contains EJBs? If yes, how do we handle those?

Ideally yes this should be possible, although we have had some
disagreement on this in the past. I personally think that if an EE
deployment uses OSGi metadata, then we should just treat that as if it
were extra module configuration

[1] NOTE THAT OSGI "INSTALL" is not the same as DUP "INSTALL" phase.
OSGI install is PRE module (no classloader yet).

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev