Ok, thanks. I got code working and ready to be committed once latest OpenEJB snapshot is published.
Jarek On 3/30/07, David Blevins <[EMAIL PROTECTED]> wrote:
Alright, the web-service address information is ported over from the old plan. There is now a <web-service-binding> list in the geronimo- openejb.xsd which is now available in that set of XmlBeans objects in the EjbModule. -David On Mar 28, 2007, at 3:49 PM, David Blevins wrote: > > On Mar 28, 2007, at 10:29 AM, Jarek Gawor wrote: > >> David, Dain, >> >> I've been looking more into the OpenEJB and JAX-WS integration and I >> think I identified a few things that I will need from the OpenEJB >> code >> in order to get this integration done. >> >> 1) Handlers and security >> >> After looking at EJB interceptors and JAX-WS handlers and realizing >> that they are not quite the same I decided to let the JAX-WS >> engine to >> invoke its handlers and EJB engine to invoke its interceptors >> (instead >> of somehow wrapping a JAX-WS handler into an EJB interceptor). > > If you could shed some of your insights on how they are the same > and how they are different, that'd be really helpful. Some spec > references would great if you have them. > > I know the data returned from InvocationContext is different but > that part doesn't have an direct affect on the handlers > themselves. Not sure if there are any differing rules on handler > ordering or flow. > >> The >> only thing that I need to do for handlers is ensure that method-level >> authorization is performed before any JAX-WS handlers are executed. >> For that, I believe I need to perform the following check in the very >> first handler: >> >> getSecurityService().isCallerAuthorized(callMethod, null); > > We are already performing an authorization check before invoking > handlers of any kind (i.e. we could never invoke your ws-hanlder- > chain ejb interceptor without a security check). But I do know the > check needs to contain the MessageContext rather than method args, > which is pretty much the same difference in how InvocationContext > works for a ws call vs. an rpc call. There's also a method in > javax.ejb.SessionContext for getting the MessageContext only usable > on a web service call. > > What I can't remember is what JACC permission we're supposed to > construct. Do you know? > >> 2) InvocationContext and delaying deserialization/serialization >> of parameters >> >> If OpenEJB allowed Geronimo to pass a custom implementation of the >> InvocationContext object (e.g. maybe an extension of >> ReflectionInvocationContext) I could modify it so that: >> >> a) getContextData() would return the same object as MessageContext >> (as per spec) >> b) getParameters() would deserialize the SOAP message (delay >> deseralization) >> c) setParameters() would update the SOAP message >> d) proceed() would keep the object returned and the SOAP message >> in synch > > We definitely need to do something along these lines and a new > InvocationContext is not an entirely bad idea. The gotchas that > may prevent us from taking that route exactly are that I'm pretty > sure the full ejb interceptors apply to all calls, not just rpc, > and would need to get invoked too. Would have to verify that, so > any info you have about ejb interceptors as they may differ from > ejb web service handler chains would help. Also there are some > very complex exception handling rules for ejb which might make that > hard -- app exception vs system exception and now in the ejb3 spec > ejbs can throw runtime exceptions as app exceptions on any call if > they've marked them in the deployment descriptor and this directly > affects how interceptors are processed. We also need to handle the > java to xml marshaling of the bean method's return value or > exception. Not sure how that would fit in. > > It's definitely clear we need the MessageContext itself passed in > from the web service layer as it's required in at least three > different places that i can think of. We might be able to get by > with a CXF or Axis Interceptor that we insert into interceptor > stack right before the bean method call. It's job would be to > unmarshall the data in the MessageContext into some known place in > the ContextData so we can invoke the bean, then it would marshal > the return value or exception so it can be passed up the chain > normally. > > That would be assuming of course that ejb rpc and ejb ws handlers > are the same and only the InvocationContext needs to be different. > So I guess that's really the question of the day. > > Will dig around. > > -David >
