[jbossws-issues] [JBoss JIRA] (JBWS-3378) JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB component interceptor

Thu Sep 6 05:53:32 EDT 2012

    [ https://issues.jboss.org/browse/JBWS-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716275#comment-12716275 ] 

Richard Opalka commented on JBWS-3378:
--------------------------------------

[09:32:44] <ropalka> asoldano, BTW solving JBWS-3378 & JBWS-3441 is really challenging task
[09:32:48] <ropalka> asoldano, it's not that easy and I'm still not sure if doable
[09:33:14] <ropalka> asoldano, there are few clarification questions I still need to ask myself (analyzing the code)
[09:34:04] <asoldano> ropalka, quite frankly, I'm not going to force you on working on 3378 :-) IOW, as long as we don't have problems with users/customers we can probably leave stuff as is
[09:34:31] <ropalka> asoldano, do you want to describe the problem?
[09:35:18] <asoldano> ropalka, I remember something around the relative execution order of jaxws handlers and ejb3 interceptors...
[09:35:41] <ropalka> asoldano, I'll state the problem to you so you can think about it too.
[09:35:48] <asoldano> ropalka, ok..
[09:36:12] <ropalka> asoldano, first problem is in CXF everything is executed in Interceptors chain - WSDL retrieval, SOAP invocations
[09:36:49] <ropalka> asoldano, we need to "merge" this Apache CXF processing chain with EJB component processing chain
[09:37:09] <ropalka> asoldano, there are two ideas how to fix it I have ATM
[09:37:24] <ropalka>  * move all CXF processing chain to EJB interceptor chain
[09:37:48] <ropalka>  * move just SOAP handlers processing interceptor to EJB interceptor chain
[09:38:23] <ropalka> asoldano, first one (moving all) is not doable IMO
[09:39:02] <ropalka> asoldano, because ServiceInvokerInterceptor is part of that chain and it calls our JBossWS invoker which then calls EJB
[09:39:25] <ropalka> asoldano, without executing most of the Apache CXF interceptor chain we don't know which method to call (with what arguments)
[09:39:59] <ropalka> asoldano, so it seems only second idea is doable
[09:40:04] <ropalka> asoldano, but it has similar problems
[09:40:16] <asoldano> ropalka, we defintely need to keep on using the apache cxf interceptors, otherwise each time cxf changes something in them we're broken
[09:41:00] <ropalka> asoldano, I'll comment on it later, let me finish my brain dump :)
[09:41:01] <ropalka> ---
[09:41:13] <ropalka> asoldano, if we'll just move SOAP handlers processing part to EJB interceptors chain
[09:41:15] <asoldano> ropalka, sure
[09:41:51] <ropalka> asoldano, we have similar problem because SOAP handlers can modify the SOAP message significantly.
[09:42:36] <ropalka> asoldano, for example it can change some method parameters that are later used for invocation
[09:42:44] <ropalka> asoldano, we have some tests like this in our test suite
[09:42:56] <asoldano> ropalka, sure
[09:43:06] <ropalka> asoldano, IOW if we'll move SOAP handlers to the EJB AS7 interceptor chain
[09:43:49] <ropalka> asoldano, then parameters that CXF deserialized from SOAP message are not holding changes did by SOAP handlers (that will be executed later in EJB interceptor chain)
[09:43:57] <ropalka> asoldano, it's kinda chicken & egg problem :(
[09:44:59] <ropalka> asoldano, that was the problem description. Let's discuss it now.
[09:45:35] <ropalka> asoldano, First of all let me say this is the drawback of the fact Red Hat decided to use thirdparty SOAP stack.
[09:45:59] <ropalka> asoldano, If we used our own, we would have more options how to solve it - also moving some part of JBossWS to AS 7
[09:46:28] <ropalka> asoldano, but with CXF you need to do some compromises - and this JIRA is one of them ATM IMO
[09:47:00] <asoldano> ropalka, yeah, I know this
[09:47:09] <ropalka> asoldano, As you said we shouldn't break CXF interceptor chain
[09:47:13] <asoldano> ropalka, it's an integration problem
[09:47:16] <ropalka> asoldano, and I agree with you.
[09:47:40] <ropalka> asoldano, for example consider situation we'd decided for Native
[09:47:49] <asoldano> ropalka, I'm re-reading your comments on the jira...
[09:48:00] <ropalka> asoldano, in that case I'd rewrite JBossWS invocation process in the way
[09:48:19] <ropalka> asoldano, that would be more AS7 friendly
[09:48:35] <ropalka> asoldano, for example Native didn't have concept of interceptors for everything like CXF has.
[09:48:50] <ropalka> asoldano, Native only had PRE, ENDPOINT & POST interceptors
[09:49:27] <ropalka> asoldano, but let's forget about Native
[09:51:21] <ropalka> asoldano, IMO this is also the spec shade area problem.
[09:51:43] <asoldano> ropalka, definitely
[09:51:53] <ropalka> asoldano, let's have a look to WSIntegrationProcessorJAXRPC_EJB.JAXRPCHandlersInterceptor
[09:52:07] <asoldano> ropalka, I'm probably still missing part of the problem... let me ask few questions:
[09:52:23] <ropalka> asoldano, it tries to deal with the same problem with modified SOAP message
[09:52:26] <ropalka> asoldano, there's comment
[09:52:27] <ropalka> ---
[09:52:43] <ropalka>  // The SOAPContentElements stored in the EndpointInvocation might have changed after
[09:52:43] <ropalka>  // handler processing. Get the updated request payload. This should be a noop if request
[09:52:43] <ropalka>  // handlers did not modify the incomming SOAP message.
[09:52:43] <ropalka>  final Object[] reqParams = wsInvocation.getArgs();
[09:52:43] <ropalka>  context.setParameters(reqParams);
[09:52:43] <asoldano> ropalka, the problem is that for ejb3 endpoints. the jaxws handlers needs to be executed after ejb3 authorization...
[09:52:45] <ropalka>  final Object resObj = context.proceed();
[09:52:49] <ropalka> ---
[09:52:55] <ropalka> asoldano, ejb3 method authorization
[09:53:01] <ropalka> asoldano, if configured
[09:53:02] <asoldano> ropalka, which is done when we hook into the ejb3 layer in our invoker
[09:53:21] <ropalka> asoldano, yes, it runs in EJB AS7 interceptor chain - somewhere in the beginning
[09:53:28] <asoldano> ropalka, but we don't know which method to call before that and the handlers can influence that?
[09:54:24] <ropalka> asoldano, if we'll move just SOAP handlers processing to EJB interceptor chain we know which method to call, but parameters may be out of date - because will be modified in SOAP handlers
[09:54:58] <ropalka> asoldano, see my copy/past of JAXRPC interceptor above
[09:55:06] <asoldano> ropalka, it's like saying that the ejb3 interceptor processing needs to be split into 2 phases
[09:55:38] <ropalka> asoldano, WDYM - can you elaborate your idea?
[09:57:12] <asoldano> ropalka, just in theory, what I'm saying is that we might need the to have the ejb3 auth interceptors be executed first, then we go on with the cxf interceptors (handler ones) and finally get back to the ejb3 interceptors running when the cxf invoker is called
[09:58:45] <asoldano> ropalka, do you see what I mean?
[09:58:47] <ropalka> ropalka 's compiling the statement ...
[09:59:25] <ropalka> asoldano, I see what you mean and let me describe the problem
[10:00:19] <ropalka> asoldano, first how CXF processing chain looks like
[10:00:20] <ropalka> ---
[10:00:21] <ropalka>  receive [PolicyInInterceptor, EndpointAssociationInterceptor, AttachmentInInterceptor]
[10:00:21] <ropalka>  pre-stream [CertConstraintsInterceptor]
[10:00:21] <ropalka>  post-stream [StaxInInterceptor]
[10:00:21] <ropalka>  read [WSDLGetInterceptor, ReadHeadersInterceptor, SoapActionInInterceptor, StartBodyInterceptor]
[10:00:23] <ropalka>  pre-protocol [EnableDecoupledFaultInterceptor, MEXInInterceptor, MustUnderstandInterceptor]
[10:00:25] <ropalka>  pre-protocol-frontend [SOAPHandlerInterceptor, LogicalHandlerInInterceptor]
[10:00:27] <ropalka>  post-protocol [CheckFaultInterceptor, JAXBAttachmentSchemaValidationHack]
[10:00:29] <ropalka>  unmarshal [URIMappingInterceptor, DocLiteralInInterceptor, SoapHeaderInterceptor]
[10:00:31] <ropalka>  pre-logical [NsCtxSelectorStoreInterceptor, OneWayProcessorInterceptor]
[10:00:33] <ropalka>  post-logical [WrapperClassInInterceptor]
[10:00:35] <ropalka>  pre-invoke [SwAInInterceptor, HolderInInterceptor]
[10:00:37] <ropalka>  invoke [ServiceInvokerInterceptor]
[10:00:39] <ropalka>  post-invoke [OutgoingChainInterceptor]
[10:00:41] <ropalka> ---
[10:00:52] <ropalka> asoldano, the most important phases we need to move to EJB interceptor chain are
[10:00:54] <ropalka> ---
[10:01:31] <ropalka> pre-protocol, pre-protocol-frontend, post-protocol
[10:01:57] <ropalka> ---
[10:02:07] <ropalka> asoldano, not sure about pre-logical & post-logical but let's continue
[10:03:14] <ropalka> asoldano, let's say we'll move these phases to EJB interceptor chain
[10:03:55] <ropalka> asoldano, the invocation goes to our transport, then through CXF interceptor chain through all the passes except those we moved
[10:04:21] <ropalka> asoldano, at ServiceInvokerInterceptor we'll call JBossWS invoker which calls EJB invoker which calls EJB interceptor chain
[10:04:32] <ropalka> asoldano, EJB authorization interceptor is called first
[10:05:48] <asoldano> ropalka, ok, and that's not good, because we need that to run before the jaxws handlers...
[10:05:57] <ropalka> asoldano, then our SOAP handlers (logical and/or soap)
[10:06:03] <ropalka> asoldano, yes (U already see it)
[10:06:30] <asoldano> ropalka, I'm proposing a different approach
[10:06:37] <ropalka> ropalka 's listening ...
[10:07:52] <asoldano> ropalka, basically, to me we'd need to add one (few?) cxf interceptor in the chain and have that execute the EJB3 auth interceptor only, then we go on with the usual cxf chain and finally have the rest of the ejb3 interceptor chain executed when it's the turn of the invoker
[10:08:54] <ropalka> ropalka 's compiling statement ...
[10:09:24] <asoldano> ropalka, instead of moving the cxf interceptors, we need to split the ejb3 chain and execute it in parts
[10:09:37] <asoldano> ropalka, at the proper times
[10:10:34] <ropalka> asoldano, note that we're executing that EJB interceptor chain at ServiceInvokerInterceptor which know which EJB, which EJB method & what params to use
[10:10:55] <ropalka> asoldano, and it relies on some information obtained from some interceptor that does XML -> Java deserialization
[10:11:20] <asoldano> ropalka, yeah, but I'm assuming we plug this new interceptor at a point where we have all the required info
[10:11:42] <asoldano> ropalka, and that point should be before the handlers interceptor are run, otherwise this problem has no solution
[10:12:02] <asoldano> ropalka, regardless of the cxf architecture
[10:12:52] <ropalka> asoldano, U mean to hook EJB3 interceptor to Apache CXF interceptor chain?
[10:13:13] <ropalka> asoldano, or you mean first part of EJB3 interceptor chain to hook to Apache CXF interceptor chain somehow?
[10:13:52] <ropalka> asoldano, or (finally) you mean to merge CXF interceptor chain with EJB3 interceptor chain?
[10:14:25] <asoldano> ropalka, probably the 2nd; basically, afaiu we need to execute the first part (auth) of the ejb3 interceptor chain earlier in the cxf chain, then finish the rest of the ejb3 chain at the usual point in the cxf chain (service endpoint invoker)
[10:15:23] <ropalka> asoldano, to clarify the best solution would be 3-rd
[10:15:41] <ropalka> asoldano, IOW to have just one processing chain and order interceptors according to our needs
[10:16:01] <ropalka> asoldano, the problem is method discovery, method params discovery are done in CXF interceptor chain
[10:16:33] <ropalka> asoldano, I was thinking about solution to "automagically" detect EJB, EJB method name and it's params from SOAP message
[10:17:07] <ropalka> asoldano, but in case I'd be able to do it, WS-Security would kick our ass again, because if SOAP message is encoded, we cannot automagically detect :(
[10:18:11] <ropalka> asoldano, IOW what I'm trying to say it's probably JSR spec problem
[10:18:13] <asoldano> ropalka, we should not reinvent the wheel here, cxf does find out the name of method, etc at the right point of the chain (where exactly btw?), that's when we're allowed to call the ejb3 layer
[10:19:09] <asoldano> ropalka, if that's only at the service invoker interceptor and there's no way for that to happen earlier, there's no solution
[10:19:12] <ropalka> asoldano, i'd guess some interceptor in 'unmarshal' phase
[10:19:35] <asoldano> ropalka, so after the handlers stuff?
[10:20:17] <ropalka> asoldano, it must be after hanlders stuff, because you can modify SOAP body - e.g. WS security or modify SOAP params
[10:20:41] <ropalka> asoldano, in order to see everything up 2 date, you have to execute user handlers - and later see the modified SOAP message
[10:21:03] <asoldano> ropalka, ok, then how can we tell ejb3 layer to check security for a given method before jaxws handlers if those can change the method that will be run?
[10:21:23] <ropalka> asoldano, this is what I'm claiming - JSR spec problem
[10:21:41] <ropalka> asoldano, this spec omits e.g. WS security encoded SOAP messages
[10:21:43] <asoldano> ropalka, ok, then is not an integration issue, it's a non-sense ;-)
[10:22:11] <ropalka> asoldano, I'm sorry but here's my +1
[10:22:45] <ropalka> asoldano, it would be doable if
[10:23:06] <ropalka> asoldano, all the method discoveries would be SOAPAction based
[10:23:19] <ropalka> asoldano, in that case you would know which EJB to call (request path in URL)
[10:23:29] <ropalka> asoldano, and which method to call (SOAPAction information)
[10:23:53] <ropalka> asoldano, then you would be able to call EJB authorization interceptors first somehow
[10:24:10] <ropalka> asoldano, but world isn't perfect and SOAPAction is taken as hint and not used everytime
[10:24:17] <asoldano> ropalka, but we can have invocations with SOAPAction = ""...
[10:24:25] <ropalka> asoldano, and we have
[10:25:16] <asoldano> ropalka, so this is the key point of the problem
[10:26:45] <ropalka> asoldano, yes, because of optional SOAPAction information and WS-Security may be used in SOAP message that might prevent to automagically detect EJB method early in the processing
[10:27:09] <ropalka> asoldano, as I said earlier kinda chicken & egg problem :)
[10:27:50] <asoldano> ropalka, ws-security is not part of the problem imho
[10:28:09] <asoldano> ropalka, as you already decrypt message before dealing with jaxws handlers
[10:28:28] <asoldano> ropalka, but message routing depending on message payload contents is a problem
[10:28:39] <asoldano> ropalka, as basically a jaxws handler might change routing
[10:28:50] <ropalka> ropalka 's checking spec ...
[10:29:04] <asoldano> ropalka, but I'm still not sure about this yet...
[10:32:28] <ropalka> asoldano, copy/paste from Webservices13 spec.
[10:32:30] <ropalka> ---
[10:32:30] <ropalka> Server side Handlers run after container services
[10:32:31] <ropalka> have run including method level authorization, but before demarshalling and dispatching the message to the
[10:32:31] <ropalka> endpoint.
[10:32:31] <ropalka> ---
[10:33:01] <ropalka> asoldano, but it doesn't say you cannot change message routing.
[10:33:29] <ropalka> asoldano, IMO it is allowed to:
[10:33:30] <ropalka> ---
[10:33:43] <ropalka> asoldano, let's say there's no SOAPAction provided in HTTP header field
[10:33:56] <ropalka> asoldano, and bar() method is encoded in SOAP request
[10:34:21] <ropalka> asoldano, I have "custom" handler that removes bar() encoded information and adds foo()
[10:34:52] <ropalka> asoldano, then our JAXB deserializer detects foo() to be executed (although bar() was executed by client)
[10:35:18] <ropalka> asoldano, then my handler translates foo() response back to bar() response and
[10:35:34] <ropalka> asoldano, client gets bar() response - but didn't see foo() was executed
[10:35:43] <ropalka> asoldano, this usecase is allowed IMO - didn't find it's forbidden
[10:36:00] <asoldano> ropalka, it's probably even related to https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3451
[10:36:00] <ropalka> asoldano, and because message routing is based on SOAP body discoveries
[10:36:31] <ropalka> asoldano, I'm not authorized to see the issue content
[10:36:38] <ropalka> asoldano, can U send it to me via e-mail?
[10:37:12] <asoldano> ropalka, yeah, it's that CVE about soap action spoofing that's been solved recently
[10:37:25] <ropalka> asoldano, aha
[10:37:41] <ropalka> asoldano, yes, this is not allowed if SOAPAction is provided
[10:37:50] <ropalka> asoldano, but if it isn't you can route as you wish
[10:37:58] <asoldano> ropalka, iow, to me it still make sense to check the actual authorization for the method that is *really* being executed
[10:38:16] <ropalka> asoldano, WYM?
[10:38:33] <asoldano> ropalka, that the current situation is at least safe
[10:38:43] <ropalka> asoldano, yes, it is
[10:39:08] <asoldano> ropalka, the problem we have is that according to the jsr, we're probably running the jaxws handlers in some circumstances when we should not run them
[10:39:42] <ropalka> asoldano, I see what you mean
[10:39:47] <asoldano> ropalka, ie. when we have an ejb3 endpoints, we have handlers, there's security on, and the calling user is not allowed to call the method he wants
[10:40:31] <ropalka> asoldano, i see, the intent is not to execute user handlers at all if security denies its access
[10:40:57] <asoldano> ropalka, so, what we might do is
[10:41:41] <asoldano> ropalka, figure out if there's a way to hook into ejb3 for knowing if user is allowed according to the info we have when running the jaxws handler and still leave stuff as is in the service invoker
[10:42:07] <asoldano> ropalka, as the handlers might change the method, etc.
[10:43:44] <ropalka> asoldano, it's a solution proposal or you're just thinking loud?
[10:44:01] <asoldano> ropalka, thinking loud
[10:44:13] <ropalka> asoldano, ok
[10:44:21] <ropalka> ropalka 's compiling the statement again ...
[10:44:52] <ropalka> asoldano, you mean to introduce CXF interceptor that is able to detect this somehow?
[10:46:48] <asoldano> ropalka, well, we still need to verify how and where the method is actually decided in cxf... and introduce a new cxf that does that early and use the info for calling ejb3 auth checks
[10:47:02] <asoldano> ropalka, if and only if there're jaxws handlers
[10:49:27] <ropalka> asoldano, I'll have a look where method is decided ...
[10:50:25] <ropalka> asoldano, here's EJB3 code - jboss-as/ejb3/src/main/java/org/jboss/as/ejb3/security/AuthorizationInterceptor.java
[10:50:25] <asoldano> ropalka, this said, is it actually possible to call the auth part only of the ejb3 chain?
[10:50:41] <ropalka> asoldano, ATM no
[10:51:03] <ropalka> asoldano, wait. It's doable if U'll configure custom interceptor
[10:51:18] <ropalka> asoldano, that we will insert just after authorization & transaction interceptor
[10:51:40] <ropalka> asoldano, but transaction interceptor might start transaction
[10:51:47] <ropalka> ropalka 's thinking loud if that might be the problem
[10:52:24] <ropalka> asoldano, this is part of that JIRA
[10:52:24] <ropalka> ---
[10:52:25] <ropalka> JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
[10:52:25] <ropalka> Handlers run under the transaction context of the component they are associated with.
[10:52:26] <ropalka> ---
[10:53:06] <ropalka> asoldano, thus I'm thinking loud if executing just first part of EJB interceptor chain (that would include Authorization & Transaction interceptors)
[10:53:19] <ropalka> asoldano, and then executing it again - but this time fully isn't a transaction problem?
[10:53:29] <asoldano> ropalka, it is
[10:54:05] <asoldano> ropalka, so we're back at the beginning
[10:54:36] <ropalka> asoldano, yes, until we'll have all the CXF interceptors part of EJB3 interceptor chain we're still in trouble :(
[10:54:36] <asoldano> ropalka, we start a transaction believe we're executing a given ejb3 method and after the handlers we figure out we should have run a different one? ;-)
[10:54:51] <asoldano> ropalka, again, it's not a cxf specific issue afaics
[10:55:10] <ropalka> asoldano, not cxf specific, but CXF integration specific
[10:55:19] <ropalka> asoldano, if you would own the code base you can do everything ...
[10:55:35] <asoldano> ropalka, forget about cxf for a second them
[10:55:38] <asoldano> s/them/then
[10:55:54] <asoldano> ropalka, what you do in the case above? you rollback the transaction and start another one?
[10:56:11] <ropalka> ropalka 's not tx expert
[10:56:22] <ropalka> asoldano, I have no idea. Maybe maestro may help here
[10:57:03] <ropalka> asoldano, if transaction EJB interceptor is ordered after authorization interceptor
[10:57:27] <ropalka> asoldano, we'd execute only part of the EJB interceptor chain where authorization interceptor chain is the last element
[10:57:27] <asoldano> ropalka, what I'm saying that this tx issue, as well as the security issue, is related to the fact we don't have final info on the ejb3 method to run until the jaxws handlers processing is over
[10:57:44] <ropalka> asoldano, right
[10:58:14] <ropalka> ropalka 's going to debug Apache CXF to identify where method & params are detected
[10:58:19] <ropalka> asoldano, give me few minutes ...
[10:58:22] <asoldano> ropalka, OK
[10:59:29] <ropalka> ropalka 's staring IDE ...
[10:59:35] <ropalka> s/staring/booting/
[10:59:52] <asoldano> asoldano often stares at the IDE :-P
[11:00:06] <ropalka> asoldano, me daily :)
[11:00:16] <ropalka> LOL
[11:00:20] <asoldano> :)
[11:12:30] <ropalka> asoldano, SOAPHandlerInterceptor
[11:12:52] <ropalka> asoldano, there's method identified
[11:13:09] <ropalka> asoldano, and it's also the same interceptor that is executing SOAP handlers
[11:15:55] <asoldano> ropalka, ah, really...
[11:16:21] <asoldano> ropalka, so cxf detects the final info on method just before or just after handlers execution?
[11:16:40] <ropalka> asoldano, before, according to SOAP message
[11:16:54] <ropalka> asoldano, the method discovery code is at
[11:17:22] <ropalka> asoldano, AbstractJAXWSHandlerInterceptor.setupBindingOperationInfo()
[11:17:32] <ropalka> asoldano, this method is inherited in SOAPHandlerInterceptor
[11:18:36] <ropalka> asoldano, and this is a bug IMO :)
[11:18:57] <ropalka> asoldano, I mean that method discovery is before handlers are executed - considering there may be routing handler :)
[11:19:13] <asoldano> ropalka, either a bug or the handler is not actually allowed to change routing
[11:19:28] <asoldano> ropalka, either ways, this would probably be good for us
[11:27:18] <ropalka> asoldano, right
[11:27:36] <ropalka> asoldano, I'd say routing shouldn't be possible.
[11:27:42] <ropalka> ropalka 's checking the spec. again ...
[11:27:56] <asoldano> ropalka, if this is not a bug, there's likely a way (in theory) for solving this, but that would imply running the ejb3 chain in 2 parts and also dealing with transaction issues
[11:28:13] <asoldano> ropalka, basically, you just discovered that we're also running the jaxws handlers out of transactions
[11:28:24] <asoldano> ropalka, while we should run them in the same tx of the ejb3 invocation
[11:28:33] <ropalka> asoldano, we don't need to deal with transaction issues if TX interceptor is after Authorization interceptor
[11:28:35] <asoldano> ropalka, afaiu
[11:28:45] <ropalka> asoldano, in first round we'd run EJB3 interceptor till Authorization one
[11:28:49] <ropalka> asoldano, next round we'll run it all
[11:29:01] <asoldano> ropalka, I'm referring to the JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions you quoted above
[11:29:16] <ropalka> asoldano, this applies to SOAP & Logical handlers only
[11:29:27] <ropalka> asoldano, which we plan to move to EJB3 interceptor
[11:29:37] <asoldano> ropalka, how?
[11:30:27] <ropalka> asoldano, I have an idea - it's identical to what we have in Native JAXRPC
[11:30:38] <ropalka> asoldano, via HandlerDelegate SPI
[11:31:04] <asoldano> ropalka, here is where we most likely have a cxf requirements preventing that:
[11:31:16] <ropalka> asoldano, sorry HandlerCallback
[11:32:01] <asoldano> ropalka, cxf chain has interceptors which are meant to be executed *after* the jaxws handler interceptors, so we should not delay the handlers execution till the invoker
[11:32:30] <asoldano> ropalka, this is really configuring as a discussion topic for the ws meeting btw
[11:32:44] <asoldano> ropalka, with a whiteboard support, etc
[11:32:45] <ropalka> asoldano, I planned to discuss it there :)
[11:33:07] <ropalka> asoldano, I saw it in the same light on yesterday when diving in this problem ...
[11:35:08] <ropalka> asoldano, I'm heading to lunch now. TTYL
[11:35:17] <asoldano> ropalka, just a sec
[11:35:20] <ropalka> asoldano, sure
[11:35:35] <asoldano> ropalka, at the end of the day, I still believe we need to have a way of running the ejb3 interceptor chain in 2 parts
[11:35:49] <ropalka> asoldano, WDYT so?
[11:35:54] <asoldano> ropalka, both for security and tx reasons
[11:36:18] <asoldano> ropalka, we should probably finish gathering info before the meeting
[11:36:20] <ropalka> asoldano, because IMO cxf interceptor chain & EJB3 interceptor chain should be merged.
[11:36:29] <ropalka> asoldano, I plan to
[11:36:43] <asoldano> ropalka, and discuss this there, possibly also getting in touch with the ejb3 guys there
[11:36:54] <ropalka> asoldano, that would be great
[11:37:13] <ropalka> asoldano, mainly Stuart & Jaikiran
[11:37:32] <asoldano> ropalka, so this means that
[11:37:38] <ropalka> asoldano, you should let them know to count with WS meeting
[11:37:46] <ropalka> asoldano, so they'll book hotel accordingly
[11:37:56] <asoldano> ropalka, this jira is going out of 4.1 schedule

> JAXWS handlers (like JAXRPC handlers are) have to be executed in EJB component interceptor
> ------------------------------------------------------------------------------------------
>
>                 Key: JBWS-3378
>                 URL: https://issues.jboss.org/browse/JBWS-3378
>             Project: JBoss Web Services
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: jbossws-cxf, jbossws-integration
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: jbossws-cxf-4.1
>
>
> JSR 109 - Version 1.3 - Chapter 6.2.2.4 Security
>  
> Handlers associated with a Port component run after authorization has occurred and before the business logic
> method of the Service Implementation bean is dispatched to. For JAX-RPC or JAX-WS Service endpoints,
> Handlers run after the container has performed the security constraint checks associated with the servlet
> element that defines the Port component. For EJB based service implementations, Handlers run after method
> level authorization has occurred.
> JSR 109 - Version 1.3 - Chapter 6.2.2.5 Transactions
> Handlers run under the transaction context of the component they are associated with.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira