[jbossws-issues] [JBoss JIRA] Created: (JBWS-3171) Fix WebServiceContext injection into EJB3 beans

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) 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(a)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(a)vpn2-11-241.ams2.redhat.com) has joined #jbossas * istudens is now known as istudens_wfh * mschoene (~mschoene(a)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(a)dhcp-1-10.fab.redhat.com) has joined #jbossas * mlinhard (~mlinhard(a)vpn-11-2.rdu.redhat.com) has joined #jbossas * tkimura has quit (Ping timeout: 612 seconds) * tkonishi has quit (Quit: Leaving) * tkimura (~tkimura(a)dhcp-193-208.nrt.redhat.com) has joined #jbossas * rhusar (~rhusar(a)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(a)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(a)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(a)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(a)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(a)dhcp-1-142.fab.redhat.com) has joined #jbossas * jhalliday (~jhalli(a)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/or... <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(a)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... * 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