[GLASSFISH-13513] CDI Interceptor + EJB 3.1 + OSGi doesn't work Created: 16/Sep/10  Updated: 20/Nov/10  Resolved: 20/Nov/10

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: chaoslayer Assignee: marina vatkina
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Attachments: Text File client.zip     Zip Archive client.zip     Zip Archive interceptor-osgi-test-modified-tobuild.zip     GZip Archive interceptor-osgi-test.tar.gz     HTML File README     Text File server.log     Java Archive File xpp3-1.1.4.c.jar    
Issuezilla Id: 13,513

 Description   

This issue is similar to issue 11491 but differs as we use a highly modular
enterprise application here using OSGi bundles.

When trying to use an interceptor by using the annotation the following
exception occurs during EJB access (called by a web service on top):

WARNING: A system exception occurred during an invocation on EJB UserServiceImpl
method public java.lang.Long
org.glassfish.cditest.user.impl.UserServiceImpl.addUser(org.glassfish.cditest.user.api.model.User)
throws javax.ejb.EJBException
javax.ejb.EJBException
at
com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5184)
at
com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5082)
at
com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4870)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2037)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1988)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:203)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy219.addUser(Unknown Source)
at
org.glassfish.cditest.user.impl.ws.UserServiceWS.addUser(UserServiceWS.java:47)
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.webservices.InstanceResolverImpl$1.invoke(InstanceResolverImpl.java:141)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
at
com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
at
com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:95)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:637)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:596)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:581)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:478)
at
com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:112)
at org.glassfish.webservices.MonitoringPipe.process(MonitoringPipe.java:142)
at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:637)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:596)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:581)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:478)
at
com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:112)
at
com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:199)
at
com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:131)
at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:637)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:596)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:581)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:478)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:310)
at
com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:600)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:264)
at
com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:144)
at org.glassfish.webservices.JAXWSServlet.doPost(JAXWSServlet.java:159)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at
org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1522)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:824)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:721)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1014)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: Singleton not set for
WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
at
org.glassfish.weld.ACLSingletonProvider$ACLSingleton.get(ACLSingletonProvider.java:110)
at org.jboss.weld.Container.instance(Container.java:58)
at
org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:45)
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
com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
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.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
com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5329)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5317)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:195)
... 62 more

The whole test setup is made up of four bundles:

  • security.api (containing a "Secure" annotation + interceptor binding)
  • security.impl (containing the interceptor implementation)
  • user.impl (containing a local ejb)
  • user.ws (containing a simple web service for remote testing)


 Comments   
Comment by Sanjeeb Sahoo [ 16/Sep/10 ]

Which build of glassfish are you using? Can you please supply a test case else I
will have to write one?

Thanks,
Sahoo

Comment by chaoslayer [ 16/Sep/10 ]

Created an attachment (id=4910)
Test case (maven reactor build including 4 projects/bundles)

Comment by chaoslayer [ 16/Sep/10 ]

I'm currently using promoted b20. As we are currently developing a rather big
application with many bundles I'd like to stay "on the edge".

Comment by Sanjeeb Sahoo [ 16/Sep/10 ]

Thanks for the test case. Looks impressive use of technology stack. I don't
think this is an issue with OSGi/JavaEE integration code. I can summarize the
use case like this:

Servlet based webservice, which is part of a war file, is injected with a local
Stateless EJB which has some interceptors and the interceptors are called with
Thread's context class loader still set to war file's class loader. Since the
war file does not (and should not) know about CDI, CDI implementation module is
throwing an exception. I think the same would have happened if everything were
part of an ear file as well. I will ask our EJB container team to understand why
the EJB is invoked with thread's context classloader set as war file's class loader.

Sahoo

Comment by chaoslayer [ 17/Sep/10 ]

Is there some workaround I could try?

Comment by Sanjeeb Sahoo [ 11/Oct/10 ]

It's confirmed to be a bug in ejb container.

Comment by chaoslayer [ 14/Oct/10 ]

Thanx for looking into this issue.

Comment by marina vatkina [ 09/Nov/10 ]

What are the steps to build the test?

% mvn install
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

Project ID: org.glassfish.cditest:security.api:bundle:1.0-SNAPSHOT

Reason: Cannot find parent: org.glassfish:interceptor-osgi-test for project:
org.glassfish.cditest:security.api:bundle:1.0-SNAPSHOT for project
org.glassfish.cditest:security.api:bundle:1.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
org.glassfish:interceptor-osgi-test for project:
org.glassfish.cditest:security.api:bundle:1.0-SNAPSHOT for project
org.glassfish.cditest:security.api:bundle:1.0-SNAPSHOT
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find
parent: org.glassfish:interceptor-osgi-test for project:
org.glassfish.cditest:security.api:bundle:1.0-SNAPSHOT for project
org.glassfish.cditest:security.api:bundle:1.0-SNAPSHOT
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
... 11 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM
'org.glassfish:interceptor-osgi-test' not found in repository: Unable to
download the artifact from any repository

org.glassfish:interceptor-osgi-test:pom:1.0-SNAPSHOT

from the specified remote repositories:
central (http://repo1.maven.org/maven2)
for project org.glassfish:interceptor-osgi-test
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:603)
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1366)
... 18 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable
to download the artifact from any repository

org.glassfish:interceptor-osgi-test:pom:1.0-SNAPSHOT

from the specified remote repositories:
central (http://repo1.maven.org/maven2)

at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:212)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:556)
... 19 more
Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to
download the artifact from any repository
at
org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:331)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:200)
... 21 more

Comment by Sanjeeb Sahoo [ 09/Nov/10 ]

Yes, I had the same problem building it myself, so I had to modify the pom.xmls.
PFA a modified test. Unzip the attached
interceptor-osgi-cdi-test-modified-tobuild.zip. It already contains all the jars
and wars. Follow the instructions found in the README inside the zip file. I am
forgetting how I tested the web service end point. Let's wait for the submitter
to tell that part.

Comment by Sanjeeb Sahoo [ 09/Nov/10 ]

Created an attachment (id=5399)
Modified the pom.xmls of the original tests so that they can be built

Comment by Sanjeeb Sahoo [ 12/Nov/10 ]

Since the submitter has not replied with a client to test, I am attaching a
simple web service client to exercise the web service and demonstrate the
problem. Unzip client.zip, cd ./client, java Main to see the following exception:
Caused by: java.lang.IllegalStateException: Singleton not set for
WebappClassLoader (delegate=true; repositories=WEB-INF/classes/).

Comment by Sanjeeb Sahoo [ 12/Nov/10 ]

Created an attachment (id=5441)
Simple web service client to demonstrate the problem

Comment by chaoslayer [ 15/Nov/10 ]

Sorry for providing an incomplete test case. Next time I'll take the time to
provide a complete setup.

But nice to see that you're already working on this issue.

Comment by marina vatkina [ 16/Nov/10 ]

Sahoo, there are no readme files in the test cases. And there are several
jar/war (even a bar?) files in your zip:

./interceptor-osgi-test/security.api/target/security.api-1.0-SNAPSHOT.jar
./interceptor-osgi-test/security.impl/target/security.impl-1.0-SNAPSHOT.jar
./interceptor-osgi-test/user.impl/target/user.impl-1.0-SNAPSHOT.jar
./interceptor-osgi-test/user.ws/target/user.ws-1.0-SNAPSHOT.war
./interceptor-osgi-test/xstream-1.3.1.bar

What is to be deployed?

Comment by Sanjeeb Sahoo [ 16/Nov/10 ]

Created an attachment (id=5491)
README file explainining the modofied test case.

Comment by marina vatkina [ 17/Nov/10 ]

It doesn't work and no error messages are printed to the server.log (I'll attach
it). The URL mentioned in the attached README gives 404 error and the 'java
Main' from the client/ fails with
Exception in thread "main" javax.xml.ws.WebServiceException: Failed to access
the WSDL at: http://sahoo:8080/user-ws/UserServiceWSService?wsdl. It failed with:
Operation timed out.
at
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:151)
at
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:133)
at
com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:254)
at
com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:217)
at
com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:165)
at
com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:93)
at javax.xml.ws.Service.<init>(Service.java:56)
at foo.UserServiceWSService.<init>(UserServiceWSService.java:42)
at Main.main(Main.java:4)
Caused by: java.net.ConnectException: Operation timed out

Comment by marina vatkina [ 17/Nov/10 ]

Created an attachment (id=5509)
server log

Comment by Sanjeeb Sahoo [ 17/Nov/10 ]

Marina,

Looking at the attached server.log, I see that the bundles do deploy correctly.
The web service end point is available at
http://marina-vatkinas-macbook-pro.local:8080/user-ws/UserServiceWSService. But,
if you look at the error you have encountered while running the client, you
shall see that it is trying to connect to a url with host name sahoo. That's
because wsdl compiler encodes the hostname in generated code. You can do any of
the following to circumvent the problem:
a) create an alias in your tcp configuration so host "sahoo" resolves to your
local host. This is the easiest one I would guess.

b) Modify client/Main.java to do the following:
UserServiceWSService s = new UserServiceWSService(new
java.net.URL("http://localhost:8080/user-ws/UserServiceWSService?wsdl"));
instead of
UserServiceWSService s = new UserServiceWSService();
, Add throws Exception clause in main method signature, and recompile like this:
(cd ./client, javac Main.java)

c) Regenerate the web service stubs by doing this:
(cd ./client, glassfish/bin/wsimport -d . -p foo -keep
http://marina-vatkinas-macbook-pro.local:8080/user-ws/UserServiceWSService?wsdl)

After doing any of the above, you can run "(cd ./client, java Main)"

Can you attach the patch to this issue, so that I can verify it.

Comment by marina vatkina [ 18/Nov/10 ]

Created an attachment (id=5525)
client version that does not depend on the url hardcoded in the wsdl

Comment by marina vatkina [ 19/Nov/10 ]

Fixed with rev 42981.

Note that with the fix the test still fails. The server.log contains what seems
to be the correct log message, followed by an exception:

[#|2010-11-18T17:39:46.384-0800|INFO|glassfish3.1|org.glassfish.cditest.user.api.UserService|_ThreadID=17;_ThreadName=Thread-1;|Returning
user UserImpl [id=0, emailAddress=test@test.org, firstName=John, gender=UNISEX,
lastName=Doe, username=john-123]|#]

[#|2010-11-18T17:39:46.491-0800|SEVERE|glassfish3.1|com.sun.xml.ws.server.sei.EndpointMethodHandler|_ThreadID=17;_ThreadName=Thread-1;|Unable
to copy bean data (target type UserClient)
javax.xml.ws.WebServiceException: Unable to copy bean data (target type UserClient)
at
org.glassfish.cditest.user.impl.ws.UserServiceWS.findById(UserServiceWS.java:31)
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.webservices.InstanceResolverImpl$1.invoke(InstanceResolverImpl.java:143)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:150)
at
com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:261)
at
com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at
com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
at org.glassfish.webservices.MonitoringPipe.process(MonitoringPipe.java:142)
at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at
com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
at
com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:199)
at
com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:131)
at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:314)
at
com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:615)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:269)
at
com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:148)
at org.glassfish.webservices.JAXWSServlet.doPost(JAXWSServlet.java:145)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.IllegalArgumentException: XPP3 pull parser library not
present. Specify another driver. For example: new XStream(new DomDriver())
at com.thoughtworks.xstream.io.xml.XppDriver.loadLibrary(XppDriver.java:62)
at com.thoughtworks.xstream.io.xml.XppDriver.createReader(XppDriver.java:43)
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:853)
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:845)
at
org.glassfish.cditest.user.impl.ws.UserServiceWS.clientToWS(UserServiceWS.java:77)
at
org.glassfish.cditest.user.impl.ws.UserServiceWS.findById(UserServiceWS.java:29)
... 59 more

#]
Comment by chaoslayer [ 19/Nov/10 ]

The error message you see is because you don't have the XMPP OSGi bundle
deployed (and yes I know it's not appropriate for a test case).

So the real problem might not been hit yet. I'll attach an OSGi bundle for that
library.

Comment by chaoslayer [ 19/Nov/10 ]

Created an attachment (id=5549)
XPP3 OSGi Bundle

Comment by marina vatkina [ 19/Nov/10 ]

With your jar, 'java Main' prints 'foo.UserClient@69fe571f' and server.log
contains only the log message above:

[#|2010-11-19T17:20:51.266-0800|INFO|glassfish3.1|org.glassfish.cditest.user.api.UserService|_ThreadID=17;_ThreadName=Thread-1;|Returning
user UserImpl [id=0, emailAddress=test@test.org, firstName=John, gender=UNISEX,
lastName=Doe, username=john-123]|#]

Comment by chaoslayer [ 20/Nov/10 ]

Well, shortly before that log message it should also print something from the
interceptor method:

@AroundInvoke
protected Object invoke(final InvocationContext ctx) throws Exception
{
Principal p = ejbCtx.getCallerPrincipal();
Method interfaceMethod = ctx.getMethod();

LOG.log(Level.INFO, "EJB Method called [Full]:\"

{0}\" by " +
"Principal:{1}", new Object[]{ getFullEJBClassName(interfaceMethod), p.toString()});
LOG.log(Level.INFO, "EJB Method called [Methodonly]:{0}

by " +
"Principal:

{1}

", new Object[]

{interfaceMethod.getName(), p.toString()}

);

return ctx.proceed();
}

Comment by Sanjeeb Sahoo [ 20/Nov/10 ]

I have the fix that Marina has checked in and I see exactly the behavior Marina
observes. I am not very familiar with interceptors, but whatever little I know,
I can confirm that it should work. It seems to me that at runtime, interceptors
are not getting bound to your EJB, which will be a different bug. I doubt it has
anything to do with OSGi now. Since the test uses InterceptorBinding, here
GlassFish CDI integration layer could play a role. In fact, I just made a simple
plain war with your ejbs and interceptors and saw the same behavior. I have
filed issue 14831 against cdi module in glassfish. You are most welcome to try
the test case as well. Let's see what the cdi engineer has to say.

To make others' life easier, let me explain how your test case is set up:

@WebService
public class UserServiceWS {

// @Resource resolves to an OSGi service backed by an EJB reference in GF.
@Resource UserService svc;
@WebMethod
public UserClient findById(long arg0) throws UserServiceFaultException

{ return svc.findById(arg0); }

}

@Stateless
@Secure // interceptor binding
@Local
public class UserServiceImpl implements UserService {

public User findById(long userId) throws EJBException {
...
LOG.log(Level.INFO, "Returning user

{0}", u);
}
}

@Inherited
@Target({ TYPE, METHOD })
@Retention(RUNTIME)
@InterceptorBinding
public @interface Secure
{}

@Secure
@Interceptor
public class SecurityInterceptor implements Serializable
{
@AroundInvoke
protected Object invoke(final InvocationContext ctx) throws Exception
{
...
LOG.log(Level.INFO, "EJB Method called [Full]:\"{0}

\" by Principal:

{1}",
new Object[]{getFullEJBClassName(interfaceMethod), p.toString()});
LOG.log(Level.INFO, "EJB Method called [Methodonly]:{0} by
Principal:{1}

", new Object[]

{interfaceMethod.getName(), p.toString()}

);

return ctx.proceed();
}
}

Generated at Wed Dec 07 22:50:19 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.