[JBoss JIRA] Created: (JBWS-3171) Fix WebServiceContext injection into EJB3 beans
by Richard Opalka (JIRA)
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
13 years, 4 months
[JBoss JIRA] Created: (JBWS-3169) Remove dependency on JBossXB
by Alessio Soldano (JIRA)
Remove dependency on JBossXB
----------------------------
Key: JBWS-3169
URL: https://jira.jboss.org/browse/JBWS-3169
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: jbossws-integration
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
The removal of jbossxb dependency from jbossws-spi component implies:
a) providing proper abstraction for retrieval of HandlersChainsMD and WebservicesMD (currently a JBossXB based object factory is accessed directly from metadata-common, AS, native / cxf stack)
b) providing StAX based parsers for webservices.xml, handlers-chain.xml, jbossws-cxf.xml (JMS stuff)
c) refactoring AS WSDescriptorDeployer which is currently a JBossXB based deployer, while we could have a simple parse deployer that installs the WebservicesMD obtained using proper call as described in a) [to be evaluate if it's worth spending time on this on AS6, given we're targeting AS7 for JBWS4]
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBWS-3143) SubjectCreatingInterceptor incompatible with PolicyBasedWSS4JInInterceptor
by Willem Salembier (JIRA)
SubjectCreatingInterceptor incompatible with PolicyBasedWSS4JInInterceptor
--------------------------------------------------------------------------
Key: JBWS-3143
URL: https://jira.jboss.org/browse/JBWS-3143
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Affects Versions: jbossws-cxf-3.4.0.Beta2
Reporter: Willem Salembier
Fix For: jbossws-cxf-3.4.0
1. Create a web service with an embedded SecurityPolicy https + usernametoken.
2. Configure JAAS authentication as explained here: http://community.jboss.org/wiki/JBossWS-StackCXFUserGuide#Authentication_...
Because org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingInterceptor inherits from WSS4JInInterceptor and sets the SECURITY_PROCESSED attribute, the checks in the PolicyBasedWSS4JInInterceptor are skipped. Result is a lot of policy failures.
These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportBinding
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}IncludeTimestamp
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Layout
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedSupportingTokens
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}UsernameToken
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months