[jbossws-issues] [JBoss JIRA] Updated: (JBWS-3171) Fix WebServiceContext injection into EJB3 beans
Richard Opalka (JIRA)
jira-events at lists.jboss.org
Mon Nov 29 05:27:09 EST 2010
[ https://jira.jboss.org/browse/JBWS-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Opalka updated JBWS-3171:
---------------------------------
Component/s: jbossws-integration
> Fix WebServiceContext injection into EJB3 beans
> -----------------------------------------------
>
> Key: JBWS-3171
> URL: https://jira.jboss.org/browse/JBWS-3171
> Project: JBoss Web Services
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: jbossws-integration
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Fix For: jbossws-cxf-3.4.1, jbossws-native-3.4.1
>
>
> <Jaikiran> ropalka: hi
> <ropalka> Jaikiran, I found one regression
> <ropalka> Jaikiran,
> <ropalka> ---
> <ropalka> tests-ws:
> <ropalka> [junit] Running org.jboss.test.ws.jaxws.ejb3Integration.WebServiceTestCase
> <ropalka> [junit] Tests run: 5, Failures: 0, Errors: 1, Time elapsed: 12.337 sec
> <ropalka> [junit] Test org.jboss.test.ws.jaxws.ejb3Integration.WebServiceTestCase FAILED
> <Jaikiran> what's that?
> <ropalka> ---
> <Jaikiran> what's the error?
> <ropalka> Jaikiran, NPE
> <ropalka> Jaikiran, This test http://fpaste.org/iK7w/
> * istudens_wfh has quit (Read error: Connection reset by peer)
> <ropalka> Jaikiran, don't get injected @Resource :(
> * jpechane (~jpechane at dhcp-1-171.brq.redhat.com) has joined #jbossas
> <Jaikiran> let me check
> <ropalka> Jaikiran, This is the NPE - http://fpaste.org/3fZc/
> <ropalka> Jaikiran, U need to update webservices AS module and rebuild it (or whole AS first)
> <Jaikiran> ropalka: is this committed in AS trunk? I just tried running this test but see a different error
> <Jaikiran> ok, one sec
> <ropalka> Jaikiran, U can rebuild just webservices module
> <ropalka> Jaikiran, and created artifact rename to jbossws-jboss60.jar and copy to AS/common/lib
> <ropalka> Jaikiran, this is the fastest way to go
> <carlo> do we still have a working internal pastebin?
> <Jaikiran> ropalka: can you enable trace level logs of org.jboss.switchboard and send me the logs?
> <ropalka> carlo, I didn't try, why?
> <ropalka> Jaikiran, give me a sec
> <carlo> for a completely other problem :-)
> <ropalka> carlo, aha, ok
> <ropalka> Jaikiran, How can I run just this one particular test?
> <ropalka> Jaikiran, I'm using
> <ropalka> ---
> <Jaikiran> ropalka: ./build.sh one-test -Dtest=org.jboss.test.ws.jaxws.ejb3Integration.WebServiceTestCase
> <ropalka> [nucleus][/home/opalka/svn/jbossas/trunk/testsuite]>./build.sh -Dnode0=localhost tests-ws
> <ropalka> ---
> <carlo> FYI: pastebin.test.redhat.com :-)
> <Jaikiran> ah, looks like the url changed
> <ropalka> Jaikiran, thanks
> <ropalka> Jaikiran, Where should I enable logging?
> <ropalka> Jaikiran, in jboss-6.0.0-SNAPSHOT/server/all/deploy/jboss-logging.xml?
> <Jaikiran> ropalka: yes
> <ropalka> Jaikiran, what level, DEBUG?
> <ropalka> Jaikiran, or TRACE?
> * pbravo has quit (Ping timeout: 240 seconds)
> <Jaikiran> ropalka: trace should be better. enable for both org.jboss.switchboard and org.jboss.injection
> <ropalka> Jaikiran, OK
> * istudens (~istudens at vpn2-11-241.ams2.redhat.com) has joined #jbossas
> * istudens is now known as istudens_wfh
> * mschoene (~mschoene at vpn1-7-138.ams2.redhat.com) has joined #jbossas
> <ropalka> Jaikiran, I'm sending U trace log via e-mail
> <Jaikiran> ok
> <ropalka> Jaikiran, sent
> <Jaikiran> ropalka: looking at the logs, the injection seems to be happening.
> <Jaikiran> ropalka: are you sure the getMessageContext() returned by the context here http://fpaste.org/iK7w/ is not null?
> <ropalka> Jaikiran, will debug
> * shaun (~sappleto at dhcp-1-10.fab.redhat.com) has joined #jbossas
> * mlinhard (~mlinhard at vpn-11-2.rdu.redhat.com) has joined #jbossas
> * tkimura has quit (Ping timeout: 612 seconds)
> * tkonishi has quit (Quit: Leaving)
> * tkimura (~tkimura at dhcp-193-208.nrt.redhat.com) has joined #jbossas
> * rhusar (~rhusar at vpn1-7-197.ams2.redhat.com) has joined #jbossas
> <ropalka> Jaikiran, I confirm the problem is returned wsctx is null
> * bgeorges has quit (Remote host closed the connection)
> <ropalka> Jaikiran, I'm having a look ...
> <Jaikiran> ropalka: wsCtx is null or messagecontext?
> <Jaikiran> looking at the logs i did notice that it was picking up the value for injection from env/org.jboss.test.ws.jaxws.ejb3Integration.HandlerContextEndpoint/wsCtx for injecting into targetclass class org.jboss.test.ws.jaxws.ejb3Integration.HandlerContextEndpoint targetname wsCtx
> <ropalka> Jaikiran, messagecontext, sorry for confusion
> <Jaikiran> oh ok :)
> <ropalka> Jaikiran, ;)
> <ropalka> Jaikiran, I found the reason but I'd like to discuss the fix with you
> <Jaikiran> ropalka: sure
> <ropalka> Jaikiran, I'd like to know EJB3 impl details
> <ropalka> Jaikiran, The problem is I don't set message context for EJB3 beans (just JAXWS POJO beans)
> * emuckenhuber (~emuckenh at dhcp-144-239.gva.redhat.com) has joined #jbossas
> <ropalka> Jaikiran, I can set it up for EJB3 beans
> <ropalka> Jaikiran, But I need to be sure
> <Jaikiran> ropalka: so it was EJB3 which was setting this up so far?
> <ropalka> Jaikiran, EJB3 beans are not executed using ThreadPools or staff like that
> <ropalka> Jaikiran, Before yes
> <ropalka> Jaikiran, Since SB changes no.
> <ropalka> Jaikiran, But this is fixable in our AS integration layer
> <Jaikiran> hmm i think this is related to that pending jira we have
> <ropalka> Jaikiran, Which one?
> <Jaikiran> ropalka: EJBTHREE-2161 i guess
> * mnovotny (~mnovotny at dhcp-27-205.brq.redhat.com) has joined #jbossas
> <JiraBot> [#EJBTHREE-2161] Implement @WebService support for @Singleton EJB3 beans [Coding In Progress, Critical, jaikiran pai] https://jira.jboss.org/jira/browse/EJBTHREE-2161
> <ropalka> Jaikiran, This is @Stateless bean
> <ropalka> Jaikiran, Maybe JIRA description needs review ;)
> <ropalka> Jaikiran, No
> <ropalka> Jaikiran, This is JIRA I created
> <ropalka> Jaikiran, This is correct description
> <ropalka> Jaikiran, As I said earlier
> <Jaikiran> ok, so it's a different thing then
> <ropalka> Jaikiran, This is fixable in our integration layer
> <ropalka> Jaikiran, But I need to be sure that if I set thread local
> <Jaikiran> sure. some background on the issue would be helpful, please :)
> <ropalka> Jaikiran, EJB3 isn't using custom thread pool (so it will be visible to EJB3 layer too)
> <ropalka> Jaikiran, OK
> <ropalka> Jaikiran, Do U have time now?
> <Jaikiran> ropalka: yep
> <ropalka> Jaikiran, very good
> <ropalka> Jaikiran, The problem is
> <ropalka> Jaikiran, This was before handled in EJB3 component
> <ropalka> Jaikiran, and seems the proper place to fix it now is in WS integration layer (at least IMHO)
> <ropalka> Jaikiran, How it works for JAXWS POJO beans
> <ropalka> Jaikiran, There's InvocationHandler abstraction in JBossWS SPI
> <ropalka> Jaikiran, JAXWS POJO invocation handler (org.jboss.wsf.common.invocation.InvocationHandlerJAXWS)
> <ropalka> Jaikiran, implements org.jboss.wsf.common.invocation.AbstractInvocationHandlerJSE
> <ropalka> Jaikiran, which provides the following template methods
> <ropalka> ---
> <ropalka> protected void onBeforeInvocation(final Invocation invocation) throws Exception
> <ropalka> protected void onAfterInvocation(final Invocation invocation) throws Exception
> <ropalka> ---
> * darran (~darran at vpn1-7-205.ams2.redhat.com) has joined #jbossas
> <ropalka> Jaikiran, these template methods are implemented in JAXWS POJO invocation handler (org.jboss.wsf.common.invocation.InvocationHandlerJAXWS)
> <ropalka> ---
> <ropalka> @Override
> <ropalka> protected void onBeforeInvocation(final Invocation invocation)
> <ropalka> {
> <ropalka> final WebServiceContext wsContext = this.getWebServiceContext(invocation);
> <ropalka> ThreadLocalAwareWebServiceContext.getInstance().setMessageContext(wsContext);
> <ropalka> }
> <carlo> ropalka: this goes back to EAP 4 where I did a proper fix for WebServiceContext
> <ropalka> @Override
> <ropalka> protected void onAfterInvocation(final Invocation invocation)
> <ropalka> {
> <ropalka> ThreadLocalAwareWebServiceContext.getInstance().setMessageContext(null);
> <ropalka> }
> <ropalka> ---
> <ropalka> carlo, ???
> <carlo> This whole before invocation and after invocation is horseshit
> <ropalka> carlo, listening ...
> <carlo> WebServiceContext needs to be injected before @PostConstruct
> <carlo> And then be done with it.
> <ropalka> carlo, stop
> <ropalka> carlo, This is not our problem
> <ropalka> carlo, I'm installing ThreadLocalAwareWebServiceContext before @PostConstruct is called
> <ropalka> carlo, So U have it available
> <ropalka> carlo, Then onBeforeInvocation() and onAfterInvocation() just use thread locals to set proper context before/after method invocations
> <ropalka> carlo, In order to have it working in EJB3 as well (this is working for POJOs)
> <ropalka> carlo, I need to be sure EJB3's not using custom thread pools (iow my thread local changes will be visible there)
> <ropalka> carlo, Is it clear now how it works for you?
> * maeste has quit (Ping timeout: 622 seconds)
> <ropalka> carlo, If not, as questions ;)
> <ropalka> s/as/ask/
> * eko (~eko at dhcp-2-223.brq.redhat.com) has joined #jbossas
> <ropalka> Jaikiran, carlo
> <ropalka> Jaikiran, carlo I propose the same fix for EJB3
> <ropalka> Jaikiran, carlo I mean the one we're using for JAX-WS POJOs
> <carlo> ropalka: where is onAfterInvocation ?
> <carlo> What I want to get rid of is BeanContextLifecycleCallback
> <ropalka> carlo, This would be called after EJB3 method invocation
> * tkobayas has quit (Quit: Leaving)
> <ropalka> carlo, In webservices AS integration module
> <ropalka> carlo, concretely in finally block of method invoke in org.jboss.webservices.integration.invocation.InvocationHandlerEJB3
> <carlo> ropalka: where is that code?
> <ropalka> carlo, jbossas/trunk/webservices/src/main/java/org/jboss/webservices/integration/invocation/InvocationHandlerEJB3.java
> <ropalka> carlo, This code isn't there yet (WS context injection population)
> <ropalka> carlo, I'm now proposing fix and need to verify with U (EJB3) this is proper one ;)
> * stliu has quit (Quit: Leaving)
> <carlo> ropalka: the problem is that you are not allowed to inject anything after @PostConstruct, is that fixed?
> <ropalka> carlo, Yes
> <ropalka> carlo, This is impl. detail
> <ropalka> carlo, As I said earlier
> <ropalka> carlo, Our jbossas/trunk/webservices/src/main/java/org/jboss/webservices/integration/injection/WebServiceContextResourceProvider.java
> <ropalka> carlo, installs factory object
> <ropalka> ---
> <ropalka> @Override
> <ropalka> public Resource provide(final DeploymentUnit unit, final JBossResourceEnvRefType resEnvRef)
> <ropalka> {
> <ropalka> return new WebServiceContextResource(ThreadLocalAwareWebServiceContext.getInstance());
> <ropalka> }
> <ropalka> ---
> <ropalka> carlo, The staff we're discussing now is about proper setup of message context (which is always unique for each invocation)
> <ropalka> carlo, this default WS context factory uses thread locals (impl. detail)
> <carlo> ropalka: just make it a theadlocal
> <ropalka> carlo, what?
> <carlo> the current MessageContext
> <ropalka> carlo, yep
> <ropalka> carlo, The WS context factory is singleton
> <ropalka> carlo, using thread locals for message context propagation
> <ropalka> carlo, is it clear now?
> <carlo> Yes, so we don't need any after or before invocation
> <ropalka> carlo, EJB3 team not
> <ropalka> carlo, But I need to fix it in webservices AS trunk module
> <ropalka> carlo, because this is not propagate now
> <ropalka> carlo, as i said message context is unique per invocation
> <carlo> There is one tricky issue though: JBPAPP-4429
> <JiraBot> [#JBPAPP-4429] Calling getContextData() on InvocationContext passed to EJB3 Interceptor should return the JAX-WS MessageContext for JAX-WS Calls. [Open, Major, Carlo de Wolf] https://jira.jboss.org/jira/browse/JBPAPP-4429
> * ropalka 's having a look
> * lami (~lakagwu at dhcp-1-142.fab.redhat.com) has joined #jbossas
> * jhalliday (~jhalli at ovpn-113-66.phx2.redhat.com) has joined #jbossas
> * bbelovic is now known as bbelovic-lunch
> <ropalka> carlo, OK, what the question U wanna ask?
> <ropalka> s/what/what's/
> <carlo> ropalka: nothing, just get rid of these weird callbacks :-)
> <ropalka> carlo, so U like my proposal fix?
> * pskopek is now known as pskopek|otl
> <carlo> ropalka: yes
> <ropalka> carlo, OK, now question of the day I need to know answer for.
> <ropalka> carlo, If I set thread local before invoking EJB3 method
> <carlo> ropalka: but in future we may switch threads
> <carlo> but I'm not sure whether that's worth pondering upon now
> <ropalka> carlo, "Is it true EJB3 AS6 impl. don't use custom thread pools, so my change will be visible to EJB3?"
> <carlo> Yes, use ThreadLocal
> <ropalka> carlo, Jaikiran thanks for confirmation ;)
> <carlo> You may need ThreadLocalStack though
> <ropalka> carlo, ???
> <ropalka> carlo, This is some EJB3 impl?
> <ropalka> carlo, I googled http://docs.jboss.org/jbossaop/docs/1.5.0.GA/docs/aspect-framework/api/org/jboss/aop/util/ThreadLocalStack.html
> <carlo> picture the following scenario: 1. call A. 2. call B. 3. back in A
> <carlo> We got a 1000+ impls :-)
> * ropalka 's listening ...
> <carlo> the one in ejb3-context is the fastest :-)
> <ropalka> carlo, ;) Could U give me the pointer?
> <carlo> Anyway in A I have MessageContext A in the ThreadLocal, now I call B
> <ropalka> U mean U call B from A?
> <carlo> In B I have MessageContext B, now I return to A
> <carlo> Yes
> <ropalka> carlo, ok, go on ...
> <carlo> If I use a regular ThreadLocal I would be staring at MessageContext B, instead of A
> <ropalka> carlo, Let me clarify scenario first before continuing in discussion
> <ropalka> ---
> <ropalka> WS servlet -> A EJB3 (msgCTX A) -> B EJB3 (msgCTX A)
> <ropalka> ---
> <ropalka> or U would like to have
> <ropalka> ---
> <ropalka> WS servlet -> A EJB3 (msgCTX A) -> B EJB3 (msgCTX B)
> <ropalka> ---
> <ropalka> carlo, What's the proper/expected behavior?
> <carlo> I mean: WS Servet A -> A EJB 3 (msgCtx A) -> WS Servlet B -> B EJB (msgCtx B)
> <ropalka> carlo, WS can set just msgCTX A, because this is related to current invocation
> <ropalka> carlo, OK, this should be correct
> * jcosta (~jcosta at dhcp-27-223.brq.redhat.com) has joined #jbossas
> <ropalka> carlo, What's the problem U're trying to discuss here?
> <carlo> Right, then I come back in A (after B call)
> <carlo> I would see msgCtx B instead of A when using ThreadLocal
> <ropalka> carlo, ok, go on
> <ropalka> carlo, I don't think so?
> <ropalka> carlo, Tomcat container uses thread pols
> <carlo> why not?
> <ropalka> s/pols/pools/
> <ropalka> carlo, Each servlet invocation should use unique thread AFAIK
> <carlo> impl detail
> * Devang|Training is now known as Devang
> <ropalka> carlo, U mean this is impl. detail I shouldn't rely on?
> <carlo> Yes
> <ropalka> carlo, I don't think so. AFAIK this is covered with Servlet spec.
> <ropalka> carlo, Or it changed in Servlet 3.0 spec?
> <carlo> I don't know, nor want to know :-)
> * ropalka didn't read Servlet 3.0 spec yet
> <ropalka> carlo, Well, IMHO this is something in servlet spec since 2.x version
> <carlo> If you say you can get away without ThreadLocalStack, then go for it :-)
> <ropalka> carlo, I think so ;)
> <ropalka> carlo, Just for clarification
> <ropalka> carlo, What U mean with "without ThreadLocalStack"?
> <ropalka> carlo, I need to understand what U mean ;)
> <carlo> ThreadLocalStack is meant to solve scenarios which I outlined
> <carlo> We use it over local (/ same thread) invocations.
> <ropalka> carlo, So it isn't InheritableThreadLocal related thing
> <carlo> No, InheritableThreadLocal is meant for child thrads
> <carlo> threads
> <ropalka> carlo, Could I have a link for your ThreadLocalStack impl. to see how it looks like?
> <ropalka> carlo, right
> <carlo> https://github.com/jbossejb3/jboss-ejb3-context/blob/master/base/src/main/java/org/jboss/ejb3/context/util/ThreadLocalStack.java
> * liweinan has quit (Read error: Connection reset by peer)
> * ropalka 's having a look ...
> <ropalka> carlo, aha
> <ropalka> carlo, I see what U meant now ;)
> <ropalka> carlo, U mean "STACK" behavior based on top of thread locals ;)
> <carlo> Yes
> <carlo> A piece of code says a thousand words :-)
> <ropalka> carlo, exactly. For me this way works the best ;)
> <ropalka> carlo, Thanks for clarification!
> <ropalka> carlo, I don't think I'll need it for WS msg ctx injection. It should work IMHO in the way I proposed it ;)
> <carlo> Yes, looks good
> <ropalka> carlo, Jaikiran Thanks for chat folks. I'm going to fix it ;)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbossws-issues
mailing list