On Tue June 16 2009 10:12:54 pm liucong wrote: > Hi, > I have added a simple interceptor in the SOAP binding. If the > transport uri is http://www.w3.org/2008/07/soap/bindings/JMS/, the jms > interceptor will be added. But I have some question for that: > 1. I feel a little weird to add a transport-related interceptor here.
Well, depends on how you look at it. :-) I don't regard the SOAP/JMS spec as a "transport". It describes how SOAP binds to JMS. Thus, it's an extension to the SOAP spec, not JMS. Thus, most of it goes into the SOAP binding. (our JMS transport should be a generic JMS transport, SOAP/JMS describes how the SOAP binding maps onto it) HOWEVER, some of the "ideas" in SOAP/JMS (like the URL mapping) are perfect additions to the JMS transport and thus it's good to put them there. We do have a "SOAP" transport where it COULD have been implemented to make it purely in the "SOAP" world, (the transport usually just uses the transportId to lookup a real factory and then delegates to it), but adding that to the JMS transport directly is good as it can benefit the non SOAP over JMS cases. (like XML over JMS) > 2. Program Problem. I have declared some constants in the > jms-transport module. I need use some of these constants in the jms > interceptor. I think it is a little weird to add project dependency to > jms-transport for soap-binding module. Do I need to declare these > constants again in the soap-binding module? Hmm... good question. How many are we talking? It MIGHT be acceptable to use a <scope>provided dependency on the jms transport from SOAP, but we'd have to be careful to make sure everything works fine if the jms transport isn't there. > 3. How to deal with soapjms:isFault property. If the soapjms:isFault > is true, it indicates that the response is a SOAP fault. How to deal > with this property. In general, ignore it. (obviously set it on the sending side since it's required per spec, but ignore it on the receiving side.) With SOAP/HTTP, faults are SUPPOSED to have response code 500. However, a bunch of broken stacks don't do so. Thus, we pretty much don't bother even looking at it and just check the soap:body at parse time to see if there is a fault there and if so, flip to the in fault chain. Dan > > best regards, > liu > > Daniel Kulp Writes: > > On Wed June 10 2009 4:38:37 am liucong wrote: > >> So, the JMS transport just copy JMS message properties to somewhere(For > >> example, Message.PROTOCOL_HEADERS map). Then the SOAP binding add some > >> extra interceptors (How to add these interceptors?) to deal with these > >> properties (check the properties, throw some SOAP Faults, and so on). > >> > >> Does it work? Is it Ok? > > > > Yep. That seems right. > > > > To add your interceptors, it would be in the SoapBindingFactory class. > > The createBinding(BindingInfo) method is where the interceptors for the > > SOAP stuff is setup. That would be the starting place to look. > > > > Dan > > > >> Daniel Kulp Writes: > >>> Ideally, to me, this type of fault mapping needs to be in the SOAP > >>> binding, not the JMS transport. The JMS transport needs to be > >>> somewhat independent of soap so that it's usable for things like XML > >>> over JMS and possibly even some resty things. > >>> > >>> Basically, the SOAP binding should examine it's transportId and if it's > >>> the SOAP/JMS spec defined ID, it should add some extra interceptors to > >>> handle the mapping of the "soap specific" things into the non-soap > >>> specific things in the transport. > >>> > >>> For example: all the funky JMS headers that the SOAP/JMS spec requires > >>> should be done from an interceptor provided by the SOAP binding (put > >>> them in the Message.PROTOCOL_HEADERS map) that the JMS transport would > >>> just copy across. > >>> > >>> That said, I really haven't read the SOAP/JMS spec in very much detail > >>> so I'm not sure if it's completely possible. :-) > >>> > >>> Dan > >>> > >>> On Mon June 8 2009 10:54:18 pm liucong wrote: > >>>> Hi, > >>>> > >>>> Willem Jiang Writes: > >>>>> Hi, > >>>>> > >>>>> I think you mean how to throw the fault from the JMS transport. > >>>>> Basically , if you throw the fault from a CXF interceptor, CXF's > >>>>> interceptors chain will take care of it and build the fault message > >>>>> and throw it out. > >>>>> > >>>>> If you want to check the Content type , you could write an > >>>>> interceptor and load it with your soap jms transport. > >>>> > >>>> How to load an interceptor with my soap jms transport? Is there any > >>>> material for help? > >>>> > >>>> Thank you. > >>>> > >>>>> But I think you could take > >>>>> the soap binding (SoapBindingFactory) as an example, and put this > >>>>> kind of checking as a work of soap jms binding. > >>>>> > >>>>> Just my 2 cents, > >>>>> > >>>>> Willem > >>>>> > >>>>> liucong wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> When I implement the SOAP Over JMS Specification, I don’t know how > >>>>>> to implement SOAP fault for it. > >>>>>> > >>>>>> I use the org.apache.cxf.interceptor.Fault to record the Fault > >>>>>> information. For example, I create a Fault instance for SOAP fault > >>>>>> subcode contentTypeMismatch > >>>>>> (http://www.w3.org/TR/2008/WD-soapjms-20080723/#binding-faults). If > >>>>>> I check the fault the cxf-rt-transports-jms module, I don’t know how > >>>>>> to deal with the fault which is checked out. > >>>>>> > >>>>>> If I added an Interceptor for JMS transport, I can use the > >>>>>> interceptor to deal with the fault. Is It right? > >>>>>> > >>>>>> If it is Ok, how is the interceptor added to the interceptors > >>>>>> according to whether the jms transport is used or not? > >>>>>> > >>>>>> Are there any materials for interceptors, phases, and phase order? > >>>>>> > >>>>>> Thank you very much! > >>>>>> > >>>>>> Best regards, > >>>>>> > >>>>>> Liu -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog