[GLASSFISH-19249] @OSGi causes ClassCastException when used from EJB deployed as EAR Created: 26/Oct/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.2.2
Fix Version/s: 4.1

Type: New Feature Priority: Critical
Reporter: cplaetzinger Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have a stateless session bean packaged and deployed as OSGi hybrid bundle. I want to access this EJB from another EJB packaged in an EAR file. So I used the following annotations:

@Inject
@OSGiService( dynamic = true )
private QueueRegistryInterface queueRegistry;

Deployment works fine but on runtime I got the following exception:

[2012-10-26 11:30:13,695] [ERROR] [org.glassfish.osgicdi.impl] [p: thread-pool-1; w: 7] [#1] Expected annotated element java.lang.ClassCastException to be within an OSGi Bundle.
[2012-10-26 11:30:13,695] [ERROR] [com.macd.xconnect.messageprocessor.base.MessageProcessor-OmsReceiver] [p: thread-pool-1; w: 7] failed to return failure message back: routeMessage: Error routing message: null
com.macd.xconnect.messageprocessor.base.MessageRouterBeanException: routeMessage: Error routing message: null
        at com.macd.xconnect.ejbeans.implementation.messagerouter.MessageRouterBean.routeMessage(MessageRouterBean.java:132)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
        at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
        at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:49)
        at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
        at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:89)
        at $Proxy207.routeMessage(Unknown Source)
        at com.macd.xconnect.messageprocessor.base.MessageProcessor.processAndRouteMessage(MessageProcessor.java:201)
        at com.macd.xconnect.messageprocessor.base.MessageProcessor.onMessage(MessageProcessor.java:126)
        at com.macd.xconnect.ejbeans.messageprocessor.MessageProcessorBean.onMessage(MessageProcessorBean.java:155)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
        at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4180)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5368)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
        at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1099)
        at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
        at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
        at $Proxy314.onMessage(Unknown Source)
        at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260)
        at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.ClassCastException
        at java.lang.Class.cast(Class.java:2990)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory.getBundleContext(OSGiServiceFactory.java:191)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory.lookupService(OSGiServiceFactory.java:127)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory.access$100(OSGiServiceFactory.java:72)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory$DynamicInvocationHandler.invoke(OSGiServiceFactory.java:232)
        at $Proxy315.find(Unknown Source)
        at com.macd.xconnect.messageprocessor.base.MessageRouter.sendMessage(MessageRouter.java:113)
        at com.macd.xconnect.messageprocessor.base.MessageRouter.sendMessage(MessageRouter.java:178)
        at com.macd.xconnect.messageprocessor.base.MessageRouter.routeMessage(MessageRouter.java:96)
        at com.macd.xconnect.ejbeans.implementation.messagerouter.MessageRouterBean.routeMessage(MessageRouterBean.java:130)
        ... 50 more

Please let me know if any further information or examples are required.



 Comments   
Comment by TangYong [ 06/Mar/13 ]

The exception is right because in this case, the EJB packaged in an EAR file can not obtain osgi related classloader and casues

BundleReference.class.cast(annotatedElt.getClassLoader()) will throw ClassCastException.

About how to fix the problem has the following considerations

1. Considering Hybrid EAR deploying

AFAIA, Hybrid EAR deploying is not still supported. Please paying attention to GLASSFISH-6741

2. Considering not using @OSGiService in the EAR

Whether can using JNDI or @EJB although I have not tried, if you can offer further information?

3. Spliting the EAR into WAB and another EJB Bundle in order to use @OSGiService

Thanks
--Tang

Comment by cplaetzinger [ 06/Mar/13 ]

I would like to see hybrid EAR deploying too. We have a huge JEE application packaged and deployed as EAR. So we tried to split it up into several modules using the Glassfish hybrid bundle approach. Since we can not refactor the whole application at once it is necessary to access the beans deployed within a hybrid bundle from the beans deployed in the EAR.

I also tried to access the EJB via JNDI lookup and @EJB annotation but it ends up with other exceptions.

Comment by TangYong [ 06/Mar/13 ]

>I also tried to access the EJB via JNDI lookup and @EJB annotation but it ends up with other exceptions.
I suggest that you can create a more litter case to mock your real JEE application and thus, you can narrow the problems domain into more litter domain. Then, giving me your mocked sample and exception, I will help you analyse and debug it and see how to fix it. Then, once OK, you can apply it into your real case.

If you have more time, please do it and send sample to me(www.tangyong.gf@gmail.com).

Thanks
--Tang

Comment by cplaetzinger [ 06/Mar/13 ]

Hi Tang,

thanks for your help and effort so far. I will try to get an example running next week.

regards,
Christian

Comment by TangYong [ 11/Apr/13 ]

Christian,

Pl. whether can send me an example about the issue.
My email: tangyong@cn.fujitsu.com

Comment by Sanjeeb Sahoo [ 12/Apr/13 ]

I have made it a new feature, because we don't support osgi bundles as part of ear files.

Comment by jthoennes [ 12/Apr/13 ]

Thanks, Sanjeeb. Do you have any plans when you could implement this feature?

Comment by cplaetzinger [ 12/Apr/13 ]

@Sanjeeb: Do you require any input from me?

Comment by Sanjeeb Sahoo [ 12/Apr/13 ]

No, I don't need any further input now. I will get back when we try to implement this.

Comment by jthoennes [ 12/Apr/13 ]

@Sanjeeb: Is there any chance to expedite this implementation by filing a service request in order to increase the priority for your management?

Comment by TangYong [ 16/Apr/13 ]

Sahoo,

I am confirming whether or how to integrate only Apache Aries Application(EBA) into Glassfish?
About supporting for ear in OSGi, I have evaluated many vendors's solution as following,

1 JBOSS 7
Having such a support.
1)
After the discussion with JBOSS OSGi's leader, he gives a test sample[1](However, I have not still tried the sample).
[1]https://github.com/jbossas/jboss-as/blob/7.2.0.Final/testsuite/integration/osgi/src/test/java/org/jboss/as/test/integration/osgi/ear/EnterpriseArchiveTestCase.java

2)integrating Apache Aries Application(EBA) into JBOSS OSGi[2]
Having been available.
[2]: https://issues.jboss.org/browse/JBOSGI-529

3) integrating Apache Aries Subsystem into JBOSS[3]
Will be done on 8.0.0.Beta1
[3]: https://issues.jboss.org/browse/AS7-5921

2 Apache Geronimo 3
Having such a support.
Using Apache Aries Application(EBA).

3 Apache Aries
Having such a support.
1) Apache Aries Application(EBA)
Having been in available status.

2) Apache Aries Subsystem(ESA)
Being in develop status. However, this will become RI of OSGi R5 Subsystem in the future.

4 Spring Source
Having such a support.
1) using PAR file
2) Spring Plan
However, I have not tried Spring related supports.

5 Apache Karaf
Having such a support
1) using Karaf feature
2) integrating Apache Aries into karaf[4]
[4]: http://repo2.maven.org/maven2/org/apache/karaf/assemblies/features/enterprise/2.3.1/enterprise-2.3.1-features.xml

So, based on the above results, we should have three implementation ways:

  • Considering a private solution
    eg. asadmin deploy --type=osgi xxx.ear

ear's structure:
--EAR
├ application.xml
├ lib/... (share lib)
├ ejb bundle
├ war bundle
├ other bundles

  • Integrating Apache Aries Application into Glassfish
    I am doing
  • Integrating Apache Aries Subsystem into Glassfish
    Waiting Subsystem's release

In any way, in the future, Subsystem should replace current private solutions from each vendor.

Thanks
--Tang

Comment by jthoennes [ 16/Apr/13 ]

Hello Tang,

thanks for your detailed about comment about OSGi support for EARs.

As we are in transition from the classic JEE modules to OSGi modules we are looking
for the support of hybrid applications (i.e. mixed OSGi and non-OSGi modules).

Would this be also covered by the Apache Aries integration?

Many thanks, Jörg

Comment by TangYong [ 16/Apr/13 ]

jthoennes,

For mixing OSGi and non-OSGi modules, Sahoo has done much.

>Would this be also covered by the Apache Aries integration?
I am investigating it. Pl. give me some time,

There are some things needing to notice:

1) my consideration is that we only integrate apache aries application(eba)(including part of blueprint) rather than all aries functions, because glassfish
osgi-javaee has offered many features(eg. osgi jpa, osgi jta...), I must select minimized set while integrating eba.

2) we must not influence current gf starting performance while integrating eba

3) so far, I felt that we need to make a bridge between deployment and eba.

Thanks
--Tang

Comment by TangYong [ 16/Apr/13 ]

jthoennes
CC: Sahoo

Initial investigation has been ended. and I have an integration plan. However, can not check in the plan because having some issues.

OK, I fistly said the integration plan.

1) creating three new directories in glassfish\modules

  • third-party\aries\application
  • third-party\aries\blueprint
  • third-party\aries\pre-requisites

2) putting the following aries related bundles into the above three directories

  • third-party\aries\application
    org.apache.aries.application.api-1.0.0.jar
    org.apache.aries.application.default.local.platform-1.0.0.jar
    org.apache.aries.application.deployment.management-1.0.0.jar
    org.apache.aries.application.install-1.0.0.jar
    org.apache.aries.application.management-1.0.0.jar
    org.apache.aries.application.modeller-1.0.0.jar
    org.apache.aries.application.resolver.noop-1.0.0.jar
    org.apache.aries.application.resolver.obr-1.0.0.jar
    org.apache.aries.application.runtime-1.0.0.jar
    org.apache.aries.application.utils-1.0.0.jar
  • third-party\aries\blueprint
    org.apache.aries.blueprint.api-1.0.0.jar
    org.apache.aries.blueprint.core-1.0.0.jar
  • third-party\aries\pre-requisites
    org.apache.aries.proxy-1.0.0.jar
    org.apache.aries.util-1.0.0.jar
    org.apache.felix.bundlerepository.jar
    slf4j-api-1.5.11.jar
    slf4j-simple-1.5.11.jar

3) add/modify the following into config\osgi.properties
glassfish.osgi.auto.install=\
$

{com.sun.aas.installRootURI}modules/endorsed/ \
${com.sun.aas.installRootURI}

modules/osgi-resource-locator.jar \
$

{com.sun.aas.installRootURI}modules/ \
${com.sun.aas.installRootURI}

modules/autostart/ \
$

{com.sun.aas.installRootURI}modules/third-party/aries/pre-requisites/ \
${com.sun.aas.installRootURI}

modules/third-party/aries/blueprint/ \
$

{com.sun.aas.installRootURI}modules/third-party/aries/application/

aries.bundles=\
${com.sun.aas.installRootURI}

modules/third-party/aries/pre-requisites/ \
$

{com.sun.aas.installRootURI}modules/third-party/aries/blueprint/ \
${com.sun.aas.installRootURI}

modules/third-party/aries/application/

glassfish.osgi.auto.start=\
$

{core.bundles}

\
$

{autostart.bundles} \
${aries.bundles}

glassfish.osgi.auto.start.level.2=${autostart.bundles}

\
$

{aries.bundles}

4) start-domain

5) putting your eba into glassfish\domains\domain1\autodeploy\bundles

6) using asadmin osgi lb to see whether the bundles in your eba have been deployed.

I will give an detailed steps in my blog about how to play with it including an eba sample.

[Analise]
I said that I can not check in the above plan because,

1) influence gf starting performance

  • Sahoo has removed org.apache.felix.bundlerepository.jar, however, I must put it back because of aries.
  • should not start these third-party bundles while starting gf, more reasonable doing is to start them while deploying eba.

2) deployment can not recognize eba's deployment
Currently, only executing "asadmin deploy --type=osgi .../xx.eba" has not any effect and causes failed deployment.So, must investigate
how to make a bridge between deployment and aries eba deployment. Thus, we can resolve 1)'s issue.
However, I have more urgent things, so I said this is my initial result.

Thanks
--Tang

Comment by TangYong [ 18/Apr/13 ]

jthoennes
CC: Sahoo

>I will give an detailed steps in my blog about how to play with it including an eba sample.
You can see concrete steps and test sample in the following:

http://osgizone.typepad.com/tangyong/2013/04/glassfish-osgi-integration-part1-integrating-apache-aries-application-into-glassfish-v4.html

Thanks
--Tang

Comment by jthoennes [ 05/Sep/13 ]

Hello,

this issues is planned for release 4.0.1. Is anybody working on this right now? When is this release due?

Thanks, Jörg

Comment by TangYong [ 05/Sep/13 ]

If exactly speaking, EAR OSGi Deployment has not a uniform standard, although OSGi EE has published a SubSystem Spec.
For the feature, there are three ways:

1. let us wait SubSystem Spec Implementation
The Subsystem Spec Implementation is charged by Apache Aries.

2. Using Apache Aries Application Feature
Just as what I said in my blog, however, this way has a backback that we need to arrange right bundles related to the feature.
Indeedly, we need some function liking Apache Karaf Feature to provision such feature automaticlly. However, this will change
GlassFish Kernel. You knonw , this will need more effort and also need to discuss with Sahoo carefully.

3. Implmenting a new Hybrid Application Bundle related to EAR.
This also needed to be dicuss with Sahoo. Eg. whether needing to implement it currently?

So, for your scene, I suggest that you can do it based on my blog.

If having any problem,

giving me your sample (pl. adding your sample into github or others which I can acess)

In the future, we will implement OSGi/CDI Spec firstly, however, once we felt your scene is most important, we will change plan and maybe firstly
implement the feature you mentioned.

Of Course, also pl. listening Sahoo's suggestion.

Thanks
Tang

Generated at Wed May 27 20:32:05 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.