Re: Questions about CXF WS-RM
Hi Eoghan, see in lined comments below: Richard Eoghan Glynn wrote: Hi Richard, Apologies for the delay in replying. NP Please see my comments in-line. 2009/6/15 Richard Opalka : what's the current state of CXF WS-RM? See below. I'm asking because we'd like to integrate probably WS-RM in our JBossWS CXF integration. Great that you're thinking of using CXF WS-RM. The main questions are: * Which WS-RM specs are supported now (I know about 1.0, is 1.1 supported already)? Only WS-RM 1.0 (2005/02) is supported as yet. This was the current version of the spec when the original RM implementation was done as part of the Celtix project (the precursor to CXF). We've had some interest in WS-RM 1.1 and I intend to do a costing on the implementation effort soon, and hopefully will get the time to implement support for it in the CXF 2.3 timeframe. IMHO WS-RM 1.1 is the right way to do WS-RM, because this spec. addresses unacknowledged anonymous messages use case (see WS-MakeConnection) This usecase wasn't addressed in WS-RM 1.0 and so I consider this old RM spec. broken. * Is QoS (Quality of Service) ensured in CXF WS-RM implementation? Well yes, in so far as the qualities of service envisaged by the WS-RM spec as concerned. So for example the policy with regard to ordering and duplicates may be asserted via the /ws-rm-policy:RMAssertion/ws-rm:deliveryAssurance element in config (see schema[1]). However other QoS typically available in the MOM world, such as message expiration/TTL and priority, are not part of WS-RM. I'm asking about 2.4 Delivery Assurances (see WS-RX 1.1 specification) Thus I consider you respond "yes" from this point of view ;) * Is current CXF WS-RM implementation tightly coupled with Endpoint? Well, CXF WS-RM can be configured on a per-endpoint basis, or for the entire Bus. I don't see the relevant source code for CXF bus integration? Could you give me the pointer to impl or test? However, internally the WS-RM layer creates an RMEndpoint for each org.apache.cxf.endpoint.Endpoint with which a reliable exchange occurs. So that sense there is a certain one-to-one-ness going on. Is that what you meant by being tightly coupled? Or were you more thinking of using WS-RM to mediate message exchanges with something other than CXF endpoints? And how is the integration with other WS-* technologies? I mean do CXF WS-RM support e.g. WS-RM with WS-Security? * Is there some API for client side when receiving undelivered messages? By undelivered messages, do you mean un-acknowledged messages that have been resent? If the original client is still running, then the retransmitted response message will be delivered to the application in the normal way (either by virtue of the invoking client thread being blocked, or via a callback or pollable for an asynchronous invocation). If I have two RM responses comming from the server (I mean RM responses with real SOAP response). How this is handled? User should take care of that there can be more than just one async SOAP response? What if client will use synchronous JAX-WS api? However, if the client application has been restarted since the original request was sent, then there is no way currently for the resent message to rendez-vous with the application logic. This deficiency was clear to us when the original RM implementation was done, and we had at the back of our mind the intention to do something about it, via some sort of persistent callback mechanism. Any ideas you might have in this regard would be welcome. Well this should be addressed in JAX-WS spec otherwise this would leave to proprietary client side API for manipulating the client RM store. Let's see what will come out with next metro release. AFAIK the Sun folks are working on RM 1.1 at the moment there. Where I could find it? * Is there some detailed architecture documentation about CXF WS-RM? No, unfortunately. Hmm :( Hope this helps, Eoghan [1] http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/rm/src/main/resources/schemas/configuration/wsrm-manager-types.xsd -- Richard Opalka JBoss Software Engineer Mail: ropa...@redhat.com Mobile: +420 731 186 942
Re: How to implement the SOAP Fault for JMS Transport?
Hi, Forward this mail to the dev mail list. 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. SOAP Binding deals with the SOAP relates business logical, and I don't think it's a good idea to put soap-jms soap relates business logical into the transport layer. > 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? Maybe we can declare these constants in the cxf-api module, so jms-transport and the soap-binding module can use them at the same time without introducing the dependencies. > 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. We could do it in the soap-jms interceptor which the help of jms transport layer. JMS transport layer just need to put the property into an entry of the message map, and the interceptor can check the entry to throw a soap:jms fault. > > best regards, > liu > Willem
Re: CXF WS-security Signing not working - "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
Sorry Dan, sometimes I am a a really loser.you are 100% right, the guilty
party was old AXIS stuff server side. After that, I pushed the SAAJ stuff
into the stupid endorsed directory (who came up with that brilliant idea
anyway it is like the JBoss windows registry ha ha ha).
anyway, then I added bouncy castle stuff to my class path and voila.
Speaking of which, I don't remember needing bouncy castle before
either..in fact, i think i have working in-production web services
without bouncy castle.which is a little weird.anyway, no big deal,
once i put it in, it works like a champ.
thanks Dan, I would never have realized with was AXIS stuff without you...
rajla wrote:
>
> Hello, I am getting the exception
> "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
> when implementing signature secruity with WS-Security in CXF. What does
> this mean? Anyone have any insights on what I can do to resolve this
> issue?
>
>
> Honestly, I don't remember this being so difficult to implement in older
> CXF and I don't think I have ever seen this error before. I tried to to
> google it a lot today and by the looks of it, not many other people have
> seen this before either. I am on version 2.2 now.
>
> Could anyone please describe to me what this error means? What process do
> I need to resolve it? P.S. The web service works fine without the
> interceptors when I don't try and use WS-security. I followed the
> WS-Security instructions listed here:
> http://cwiki.apache.org/CXF20DOC/ws-security.html
>
> That is, I generated a keystore for my server side, generated a public key
> for my client. Imported the public key for my client into the keystore.
>
> Any assistance anyone can give me in regards to resolving this issue is
> greatly appreciated.
>
> Below is the whole message and exception, including the SOAP exchange and
> stuff.:
>
> log4j:WARN No appenders could be found for logger
> (org.apache.cxf.bus.spring.BusApplicationContext).
> log4j:WARN Please initialize the log4j system properly.
> Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
> getConfigResources
> INFO: No cxf.xml configuration file detected, relying on defaults.
> Jun 16, 2009 11:00:14 AM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromClass
> INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
> com.ea.teams.EATeamsWS
> Jun 16, 2009 11:00:26 AM
> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
> INFO: Outbound Message
> ---
> ID: 1
> Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
> Encoding: UTF-8
> Content-Type: text/xml
> Headers: {SOAPAction=[""], Accept=[*/*]}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soap:mustUnderstand="1"> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; Id="Signature-1">
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"; />
> http://www.w3.org/2000/09/xmldsig#rsa-sha1";
> />
>
>
> http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
> http://www.w3.org/2000/09/xmldsig#sha1"; />
> 9ugq2OUuSZq3m5dk2pchTf+XSNA=
>
>
>
> ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2q74o
> 2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy3dwd
> js2fRIuc9g7AvpC7KX0=
>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="STRId-327383FBE9F26CE8EF12451752261753">
>
> CN=teams
> 1245171677
>
>
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="id-2"> xmlns:ns1="http://teams.ea.com/";>sysadmin4ealabels
> --
> Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
> logging
> INFO: Inbound Message
>
> ID: 1
> Encoding: UTF-8
> Content-Type: text/xml; charset=utf-8
> Headers: {Content-Length=[225], Server=[Jetty(6.1.18)],
> content-type=[text/xml; charset=utf-8]}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>soap:ServerNo
> such Localname for SOAP
> URI
> --
> javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141)
> at $Proxy47.retrieveAllFields(Unknown Source)
> at test.ea.ws.WebServiceClient.main(WebServiceClient.java:46)
> Caused by: org.apache.cxf.binding.soap.SoapFault: No such Localname for
> SOAP URI
> at
> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:75)
> at
> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.han
Re: GSoC projects for CXF
On Wed June 17 2009 7:20:09 pm Krzysztof Wilkos wrote: > I've got some busy days at university (exams etc.) but I'm close to > get session initialization working. I should finish this before the > end of this week. To initiate a session I have to call service method > so there is short way from session initialization to complete conduit > for soap over tcp protocol. Thanks for the update. Definitely don't let work on this affect your studying for exams. Keeping grades up is higher priority. > BTW To send a message I have to know its length which I have to send > in frame header. I'm planning to make buffer and ByteArrayOutputStream > which I put into Message object and than in close method I'll send > buffer content into real stream. With this solution I will not have to > change existing cxf code which assumes that after prepare method call > there is outputstream in Message object. For small messages this > should be ok but with bigger one ByteArrayOutputStream can reallocate > buffer few times. Can I do that this way? Doesn't the SOAP/TCP protocol allow the message to be split across several frames? Basically, send a "chunk" of the message at a time? If so, your output stream would just need a fixed size buffer of some sort (like 4K or something). When the buffer fills, write out a frame and reset the buffer back to 0. That way, it would avoid having the whole message in a block. The other option is to use our CachedOutputStream. It uses a ByteArrayOutputStream for a while (64K by default), but then will change to using a temporary file for storage to avoid having huge blocks in memory. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: JAXRS : issues with AegisProvider
Sergey,
My memory of how all this is supposed to work isn't good enough.
In your failing test case, the problem starts with ...
WARNING: xsi:type="{http://fortest.jaxrs.cxf.apache.org}AegisTestBean"; was
specified, but no corresponding Type was registered; no default.
For this to work, somehow the Aegis context has to be aware of this type. As
the test case is structured, the only type it has access to is Map. No
annotations, no generic arguments.
You can't get a class reference for a generic type due to type erasure.
Aegis handles parameterized types by using reflection on parameters and
fields. The null 'type' argument is going to have to have something in it.
On Wed, Jun 17, 2009 at 10:24 AM, Sergey Beryozkin wrote:
> I created two JIRAs - please have a look at them whenever you get a chance
> - they don't block me at the moment
>
> https://issues.apache.org/jira/browse/CXF-2296
> https://issues.apache.org/jira/browse/CXF-2297
>
> thanks, Sergey
>
>
>
> - Original Message - From: "Sergey Beryozkin" <
> sbery...@progress.com>
> To:
> Sent: Wednesday, June 17, 2009 2:42 PM
>
> Subject: Re: JAXRS : issues with AegisProvider
>
>
> Hi Benson - I just sent a followup email at the same time you replied :-),
>> I'll create a JIRA shortly,
>>
>> thanks, Sergey
>>
>> - Original Message - From: "Benson Margulies" <
>> bimargul...@gmail.com>
>> To:
>> Sent: Wednesday, June 17, 2009 2:10 PM
>> Subject: Re: JAXRS : issues with AegisProvider
>>
>>
>> Like I said. Given my current level of load, if you tee it up, I'll try
>>> to
>>> knock it down. But I need something that misbehaves. I'm sorry to have to
>>> ask for that silver platter.
>>>
>>> On Wed, Jun 17, 2009 at 8:43 AM, Sergey Beryozkin >> >wrote:
>>>
>>> For the purpose of the demo I introduced a wrapper around the
Map and it works nicely, but I'd appreciate any
help
in getting to the bottom of the problem I described below.
thanks, Sergey
- Original Message - From: "Sergey Beryozkin" <
sbery...@progress.com>
To:
Sent: Wednesday, June 17, 2009 1:19 PM
Subject: JAXRS : issues with AegisProvider
Hi,
I'm seeing problems with the JAXRS AegisElementProvider
producing/consuming
complex types like Maps.
I'm nearly done with making a basic end to end JAX-RS demo working n
DOSGi,
the immediate problem is that
a client proxy fails to consume the following somewhat complicated
Aegis-produced response (Map) :
>>> xmlns:ns1="urn:org.apache.cxf.aegis.types" xmlns:ns2="
http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance";
ns3:type="ns2:GreetingPhrase">Bonjour>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2="
http://www.w3.org/2001/XMLSchema-instance";
ns2:type="xsd:string">Fred>>> xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org";
xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance";
ns3:type="ns2:GreetingPhrase">Hoi>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2="
http://www.w3.org/2001/XMLSchema-instance";
ns2:type="xsd:string">Fred>>> xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org";
xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance";
ns3:type="ns2:GreetingPhrase">Hola>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2="
http://www.w3.org/2001/XMLSchema-instance";
ns2:type="xsd:string">Fred>>> xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org";
xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance";
ns3:type="ns2:GreetingPhrase">Hello>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2="
http://www.w3.org/2001/XMLSchema-instance";
ns2:type="xsd:string">Fred
it complains no type mapping is found
I've run a simple frontend based demo and the same Map is serialized as
http://greeter.samples.dosgi.cxf.apache.org/
" xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org
">BonjourFred>>> xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org
">HoiFred>>> xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org
">HolaFred>>> xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org
">HelloFred
So is it possible to simplify the serialization somehow when Aegis is
used
by JAXRS ? If not then how can I make the above map being deserialized
on
the client side ? Benson, do you reckon it is even possible for Map ?
thanks, Sergey
>>>
>>
>
Re: JAXRS : issues with AegisProvider
Sergey, I have a pretty good idea of the nature of the problem. When Aegis is run with good-old-soap, various types from the SEI are pushed into its view to start the process. We're not doing anything like this for JAX-RS yet, I bet. --benson On Wed, Jun 17, 2009 at 9:42 AM, Sergey Beryozkin wrote: > Hi Benson - I just sent a followup email at the same time you replied :-), > I'll create a JIRA shortly, > > thanks, Sergey > > - Original Message - From: "Benson Margulies" < > bimargul...@gmail.com> > To: > Sent: Wednesday, June 17, 2009 2:10 PM > Subject: Re: JAXRS : issues with AegisProvider > > > > Like I said. Given my current level of load, if you tee it up, I'll try to >> knock it down. But I need something that misbehaves. I'm sorry to have to >> ask for that silver platter. >> >> On Wed, Jun 17, 2009 at 8:43 AM, Sergey Beryozkin > >wrote: >> >> For the purpose of the demo I introduced a wrapper around the >>> Map and it works nicely, but I'd appreciate any >>> help >>> in getting to the bottom of the problem I described below. >>> >>> thanks, Sergey >>> >>> - Original Message - From: "Sergey Beryozkin" < >>> sbery...@progress.com> >>> To: >>> Sent: Wednesday, June 17, 2009 1:19 PM >>> Subject: JAXRS : issues with AegisProvider >>> >>> >>> >>> Hi, >>> >>> I'm seeing problems with the JAXRS AegisElementProvider >>> producing/consuming >>> complex types like Maps. >>> I'm nearly done with making a basic end to end JAX-RS demo working n >>> DOSGi, >>> the immediate problem is that >>> a client proxy fails to consume the following somewhat complicated >>> Aegis-produced response (Map) : >>> >>> >> xmlns:ns1="urn:org.apache.cxf.aegis.types">>> xmlns:ns2=" >>> http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" >>> http://www.w3.org/2001/XMLSchema-instance"; >>> >>> ns3:type="ns2:GreetingPhrase">Bonjour>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" >>> http://www.w3.org/2001/XMLSchema-instance"; >>> ns2:type="xsd:string">Fred>> xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" >>> http://www.w3.org/2001/XMLSchema-instance"; >>> >>> ns3:type="ns2:GreetingPhrase">Hoi>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" >>> http://www.w3.org/2001/XMLSchema-instance"; >>> ns2:type="xsd:string">Fred>> xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" >>> http://www.w3.org/2001/XMLSchema-instance"; >>> >>> ns3:type="ns2:GreetingPhrase">Hola>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" >>> http://www.w3.org/2001/XMLSchema-instance"; >>> ns2:type="xsd:string">Fred>> xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" >>> http://www.w3.org/2001/XMLSchema-instance"; >>> >>> ns3:type="ns2:GreetingPhrase">Hello>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" >>> http://www.w3.org/2001/XMLSchema-instance"; >>> >>> ns2:type="xsd:string">Fred >>> >>> it complains no type mapping is found >>> >>> I've run a simple frontend based demo and the same Map is serialized as >>> >>> http://greeter.samples.dosgi.cxf.apache.org/ >>> ">>> xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org >>> ">BonjourFred>> xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org >>> ">HoiFred>> xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org >>> ">HolaFred>> xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org >>> >>> ">HelloFred >>> >>> So is it possible to simplify the serialization somehow when Aegis is >>> used >>> by JAXRS ? If not then how can I make the above map being deserialized on >>> the client side ? Benson, do you reckon it is even possible for Map ? >>> >>> thanks, Sergey >>> >>> >>> >> >
Re: GSoC projects for CXF
2009/6/16 Daniel Kulp : > > Just a reminder that July 13th (the date when Mid-term evaluations are due) is > now less than a month away. We definitely should start seeing some visible > progress sometime soon. More importantly, for mid-terms, we should be seeing > more interaction with the communities. > > Anyway, I just wanted to remind everyone about that milestone in the GSoC > timeline. > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog > I've got some busy days at university (exams etc.) but I'm close to get session initialization working. I should finish this before the end of this week. To initiate a session I have to call service method so there is short way from session initialization to complete conduit for soap over tcp protocol. BTW To send a message I have to know its length which I have to send in frame header. I'm planning to make buffer and ByteArrayOutputStream which I put into Message object and than in close method I'll send buffer content into real stream. With this solution I will not have to change existing cxf code which assumes that after prepare method call there is outputstream in Message object. For small messages this should be ok but with bigger one ByteArrayOutputStream can reallocate buffer few times. Can I do that this way? -- Krzysztof Wilkos
Re: CXF WS-security Signing not working - "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
Actually, that error message seems to come from an OLD Axis SAAJ
implementation. Definitely check the server side parts for any leftover Axis
SAAJ things and replace them with a modern implementation. (Sun's SAAJ is what
we test with)
Dan
On Wed June 17 2009 3:21:58 pm rajla wrote:
> Hey Dan, the problem must be something with Spring 3.0+ and CXF
> compatibility. That is all I can think of What sort of server logs?
> All the server really does is throw the exception I posted below after it
> chokes and pukes. Other than that I don't see anything else in stdout.
>
> Thanks
>
> dkulp wrote:
> > Since that error message is coming back in the Fault, that is something
> > on the
> > server side. Thus, we'd need to see the logs for the server side.
> >
> > I've never seen that error before either. Bizarre.
> >
> >
> > Dan
> >
> > On Tue June 16 2009 5:12:17 pm rajla wrote:
> >> Hello, I am getting the exception
> >> "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
> >> when
> >> implementing signature secruity with WS-Security in CXF. What does this
> >> mean? Anyone have any insights on what I can do to resolve this issue?
> >>
> >>
> >> Honestly, I don't remember this being so difficult to implement in older
> >> CXF and I don't think I have ever seen this error before. I tried to to
> >> google it a lot today and by the looks of it, not many other people have
> >> seen this before either. I am on version 2.2 now.
> >>
> >> Could anyone please describe to me what this error means? What process
> >> do
> >> I need to resolve it? P.S. The web service works fine without the
> >> interceptors when I don't try and use WS-security. I followed the
> >> WS-Security instructions listed here:
> >> http://cwiki.apache.org/CXF20DOC/ws-security.html
> >>
> >> That is, I generated a keystore for my server side, generated a public
> >> key
> >> for my client. Imported the public key for my client into the keystore.
> >>
> >> Any assistance anyone can give me in regards to resolving this issue is
> >> greatly appreciated.
> >>
> >> Below is the whole message and exception, including the SOAP exchange
> >> and stuff.:
> >>
> >> log4j:WARN No appenders could be found for logger
> >> (org.apache.cxf.bus.spring.BusApplicationContext).
> >> log4j:WARN Please initialize the log4j system properly.
> >> Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
> >> getConfigResources
> >> INFO: No cxf.xml configuration file detected, relying on defaults.
> >> Jun 16, 2009 11:00:14 AM
> >> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> >> buildServiceFromClass
> >> INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
> >> com.ea.teams.EATeamsWS
> >> Jun 16, 2009 11:00:26 AM
> >> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
> >> INFO: Outbound Message
> >> ---
> >> ID: 1
> >> Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
> >> Encoding: UTF-8
> >> Content-Type: text/xml
> >> Headers: {SOAPAction=[""], Accept=[*/*]}
> >> Payload: >> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> >>e:S ecurity
> >> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
> >>cur ity-secext-1.0.xsd" soap:mustUnderstand="1"> >> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; Id="Signature-1">
> >>
> >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"; />
> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1";
> >> />
> >>
> >>
> >> http://www.w3.org/2001/10/xml-exc-c14n#"; />
> >>
> >> http://www.w3.org/2000/09/xmldsig#sha1"; />
> >> 9ugq2OUuSZq3m5dk2pchTf+XSNA=
> >>
> >>
> >>
> >> ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2
> >>q74 o
> >> 2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy
> >>3dw d js2fRIuc9g7AvpC7KX0=
> >>
> >>
> >> >> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
> >>cur ity-secext-1.0.xsd"
> >> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
> >>uri ty-utility-1.0.xsd"
> >> wsu:Id="STRId-327383FBE9F26CE8EF12451752261753">
> >>
> >> CN=teams
> >> 1245171677
> >>
> >>
> >>
> >> >> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
> >>uri ty-utility-1.0.xsd" wsu:Id="id-2"> >> xmlns:ns1="http://teams.ea.com/";>sysadmin
> >>4ea labels
> >> --
> >> Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
> >> logging
> >> INFO: Inbound Message
> >>
> >> ID: 1
> >> Encoding: UTF-8
> >> Content-Type: text/xml; charset=utf-8
> >> Headers: {Content-Length=[225], Server=[Jetty(6.1.18)],
> >> content-type=[text/xml; charset=utf-8]}
> >> Payload: >> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> >>Fau lt>soap:ServerNo such Localname
> >> for
>
> SOAP
>
> >> URI
> >> --
> >> javax.xml.ws.soa
Re: CXF WS-security Signing not working - "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
On Wed June 17 2009 3:21:58 pm rajla wrote:
> Hey Dan, the problem must be something with Spring 3.0+ and CXF
> compatibility.
Interesting. I haven't tried anything with Spring 3.0 yet.
> That is all I can think of What sort of server logs?
> All the server really does is throw the exception I posted below after it
> chokes and pukes. Other than that I don't see anything else in stdout.
That's a client side stack trace. I'd need to see any stack traces or logs
or anything on the receiving end of the original message. Basically, the
message going out of the CXF client looks OK. I'd like to see the logs from
the server side (assuming CXF server) to see where it's failing which may help
figure out what's going on.
Dan
> Thanks
>
> dkulp wrote:
> > Since that error message is coming back in the Fault, that is something
> > on the
> > server side. Thus, we'd need to see the logs for the server side.
> >
> > I've never seen that error before either. Bizarre.
> >
> >
> > Dan
> >
> > On Tue June 16 2009 5:12:17 pm rajla wrote:
> >> Hello, I am getting the exception
> >> "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
> >> when
> >> implementing signature secruity with WS-Security in CXF. What does this
> >> mean? Anyone have any insights on what I can do to resolve this issue?
> >>
> >>
> >> Honestly, I don't remember this being so difficult to implement in older
> >> CXF and I don't think I have ever seen this error before. I tried to to
> >> google it a lot today and by the looks of it, not many other people have
> >> seen this before either. I am on version 2.2 now.
> >>
> >> Could anyone please describe to me what this error means? What process
> >> do
> >> I need to resolve it? P.S. The web service works fine without the
> >> interceptors when I don't try and use WS-security. I followed the
> >> WS-Security instructions listed here:
> >> http://cwiki.apache.org/CXF20DOC/ws-security.html
> >>
> >> That is, I generated a keystore for my server side, generated a public
> >> key
> >> for my client. Imported the public key for my client into the keystore.
> >>
> >> Any assistance anyone can give me in regards to resolving this issue is
> >> greatly appreciated.
> >>
> >> Below is the whole message and exception, including the SOAP exchange
> >> and stuff.:
> >>
> >> log4j:WARN No appenders could be found for logger
> >> (org.apache.cxf.bus.spring.BusApplicationContext).
> >> log4j:WARN Please initialize the log4j system properly.
> >> Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
> >> getConfigResources
> >> INFO: No cxf.xml configuration file detected, relying on defaults.
> >> Jun 16, 2009 11:00:14 AM
> >> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> >> buildServiceFromClass
> >> INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
> >> com.ea.teams.EATeamsWS
> >> Jun 16, 2009 11:00:26 AM
> >> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
> >> INFO: Outbound Message
> >> ---
> >> ID: 1
> >> Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
> >> Encoding: UTF-8
> >> Content-Type: text/xml
> >> Headers: {SOAPAction=[""], Accept=[*/*]}
> >> Payload: >> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> >>e:S ecurity
> >> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
> >>cur ity-secext-1.0.xsd" soap:mustUnderstand="1"> >> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; Id="Signature-1">
> >>
> >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"; />
> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1";
> >> />
> >>
> >>
> >> http://www.w3.org/2001/10/xml-exc-c14n#"; />
> >>
> >> http://www.w3.org/2000/09/xmldsig#sha1"; />
> >> 9ugq2OUuSZq3m5dk2pchTf+XSNA=
> >>
> >>
> >>
> >> ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2
> >>q74 o
> >> 2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy
> >>3dw d js2fRIuc9g7AvpC7KX0=
> >>
> >>
> >> >> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
> >>cur ity-secext-1.0.xsd"
> >> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
> >>uri ty-utility-1.0.xsd"
> >> wsu:Id="STRId-327383FBE9F26CE8EF12451752261753">
> >>
> >> CN=teams
> >> 1245171677
> >>
> >>
> >>
> >> >> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
> >>uri ty-utility-1.0.xsd" wsu:Id="id-2"> >> xmlns:ns1="http://teams.ea.com/";>sysadmin
> >>4ea labels
> >> --
> >> Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
> >> logging
> >> INFO: Inbound Message
> >>
> >> ID: 1
> >> Encoding: UTF-8
> >> Content-Type: text/xml; charset=utf-8
> >> Headers: {Content-Length=[225], Server=[Jetty(6.1.18)],
> >> content-type=[text/xml; charset=utf-8]}
> >> Payload: >> xmlns:soap="http://sch
Re: CXF WS-security Signing not working - "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
Hey Dan, the problem must be something with Spring 3.0+ and CXF
compatibility. That is all I can think of What sort of server logs?
All the server really does is throw the exception I posted below after it
chokes and pukes. Other than that I don't see anything else in stdout.
Thanks
dkulp wrote:
>
>
> Since that error message is coming back in the Fault, that is something on
> the
> server side. Thus, we'd need to see the logs for the server side.
>
> I've never seen that error before either. Bizarre.
>
>
> Dan
>
>
> On Tue June 16 2009 5:12:17 pm rajla wrote:
>> Hello, I am getting the exception
>> "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
>> when
>> implementing signature secruity with WS-Security in CXF. What does this
>> mean? Anyone have any insights on what I can do to resolve this issue?
>>
>>
>> Honestly, I don't remember this being so difficult to implement in older
>> CXF and I don't think I have ever seen this error before. I tried to to
>> google it a lot today and by the looks of it, not many other people have
>> seen this before either. I am on version 2.2 now.
>>
>> Could anyone please describe to me what this error means? What process
>> do
>> I need to resolve it? P.S. The web service works fine without the
>> interceptors when I don't try and use WS-security. I followed the
>> WS-Security instructions listed here:
>> http://cwiki.apache.org/CXF20DOC/ws-security.html
>>
>> That is, I generated a keystore for my server side, generated a public
>> key
>> for my client. Imported the public key for my client into the keystore.
>>
>> Any assistance anyone can give me in regards to resolving this issue is
>> greatly appreciated.
>>
>> Below is the whole message and exception, including the SOAP exchange and
>> stuff.:
>>
>> log4j:WARN No appenders could be found for logger
>> (org.apache.cxf.bus.spring.BusApplicationContext).
>> log4j:WARN Please initialize the log4j system properly.
>> Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
>> getConfigResources
>> INFO: No cxf.xml configuration file detected, relying on defaults.
>> Jun 16, 2009 11:00:14 AM
>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
>> buildServiceFromClass
>> INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
>> com.ea.teams.EATeamsWS
>> Jun 16, 2009 11:00:26 AM
>> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
>> INFO: Outbound Message
>> ---
>> ID: 1
>> Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
>> Encoding: UTF-8
>> Content-Type: text/xml
>> Headers: {SOAPAction=[""], Accept=[*/*]}
>> Payload: > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>>ecurity
>> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
>>ity-secext-1.0.xsd" soap:mustUnderstand="1">> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; Id="Signature-1">
>>
>> > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"; />
>> > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1";
>> />
>>
>>
>> http://www.w3.org/2001/10/xml-exc-c14n#"; />
>>
>> http://www.w3.org/2000/09/xmldsig#sha1"; />
>> 9ugq2OUuSZq3m5dk2pchTf+XSNA=
>>
>>
>>
>> ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2q74
>>o
>> 2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy3dw
>>d js2fRIuc9g7AvpC7KX0=
>>
>>
>> > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
>>ity-secext-1.0.xsd"
>> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
>>ty-utility-1.0.xsd"
>> wsu:Id="STRId-327383FBE9F26CE8EF12451752261753">
>>
>> CN=teams
>> 1245171677
>>
>>
>>
>> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
>>ty-utility-1.0.xsd" wsu:Id="id-2">> xmlns:ns1="http://teams.ea.com/";>sysadmin4ea
>>labels
>> --
>> Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
>> logging
>> INFO: Inbound Message
>>
>> ID: 1
>> Encoding: UTF-8
>> Content-Type: text/xml; charset=utf-8
>> Headers: {Content-Length=[225], Server=[Jetty(6.1.18)],
>> content-type=[text/xml; charset=utf-8]}
>> Payload: > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>>lt>soap:ServerNo such Localname for
SOAP
>> URI
>> --
>> javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
>> at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141)
>> at $Proxy47.retrieveAllFields(Unknown Source)
>> at test.ea.ws.WebServiceClient.main(WebServiceClient.java:46)
>> Caused by: org.apache.cxf.binding.soap.SoapFault: No such Localname for
>> SOAP URI
>> at
>> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalF
>>ault(Soap11FaultInInterceptor.java:75) at
>> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.h
Re: WSSecurityEngine: Callback supplied no password for: null when using useReqSigCert for encryptionUser in multiple client scenario.
Log a JIRA with a patch? :-)
Dan
On Tue June 16 2009 1:05:01 pm Jim Hansen wrote:
> I did some debugging and discovered that the RECV_RESULTS are not found in
> the right place. My fix (probably not the best fix) is to override
> getProperty() on the WSS4JOutInterceptor class as follows:
>
>
> @Override
> public Object getProperty(Object msgContext, String key)
> {
> // use the superclass first
> Object result = super.getProperty(msgContext, key);
>
> // handle the special case of the RECV_RESULTS
> if (result == null && key == WSHandlerConstants.RECV_RESULTS)
> {
> result = ((Message)
> msgContext).getExchange().getInMessage().get(key);
> }
>
> return result;
> }
>
> So it appears that the RECV_RESULTS are present, but they are in the
> Exchange.getInMessage(), which is not being searched by
> WSS4JOutInterceptor.getProperty().
>
> I’m using CXF 2.2.2 and wss4j-1.5.7.jar.
>
> santhosh00724 wrote:
> > Did any tried it. I am trying but not able to make any progress. The code
> > that is throwing exception is in
> >
> > WSS4JOutInterceptor.java Line:220
> >
> > doSenderAction(doAction, doc, reqData, actions, Boolean.TRUE
> > .equals(getProperty(mc,
> > org.apache.cxf.message.Message.REQUESTOR_ROLE)));
> >
> > Or can one suggest other alternatives for using multiple clients.
> >
> > dkulp wrote:
> >> The RECV_RESULTS is the vector of result things that should have been
> >> saved
> >> from the INCOMING message. Basically, the WSS4JInInterceptor should
> >> have
> >> saved that someplace where the OUT interceptor can grab it.
> >>
> >> Dan
> >>
> >> On Wed April 1 2009 9:31:52 am santhosh00724 wrote:
> >>> I was debugging the code with WSS4J 1.5.6 version. When the control
> >>> goes into the WSHandler's function
> >>>
> >>> private void handleSpecialUser(RequestData reqData) {
> >>> if
> >>> (!WSHandlerConstants.USE_REQ_SIG_CERT.equals(reqData.getEncUser())) {
> >>> return;
> >>> }
> >>> Vector results =
> >>> (Vector) getProperty(reqData.getMsgContext(),
> >>> WSHandlerConstants.RECV_RESULTS);if (results == null) {
> >>> return;
> >>> }
> >>>
> >>>
> >>>
> >>> I am getting results vector as null and the function is not executed
> >>> properly. Can any one from CXF dev explain what this results vector
> >>> should
> >>> contain and why is it returning null. I am trying to fix it if there is
> >>> no
> >>> patch for cxf to handle multiple clients .. please help..
> >>>
> >>> Santhosh.
> >>>
> >>> santhosh00724 wrote:
> >>> > Thank you for reply,
> >>> >
> >>> > This is what I am getting now. I am using CXF 2.1.3. is this a
> >>>
> >>> problem. I
> >>>
> >>> > tried using CXF 2.2 & 2.1.4 I am getting :
> >>> > java.lang.ClassNotFoundException:
> >>> > org.springframework.context.support.AbstractRefres
> >>> > hableConfigApplicationContext
> >>> >
> >>> > Santhosh.
> >>> >
> >>> > Original Exception with CXF 2.1.3:
> >>> > org.apache.ws.security.WSSecurityException: Error during encryption:
> >>> > ; nested exception is:
> >>> > org.apache.ws.security.WSSecurityException: General security
> >>> > error (No certificates for user useReqSigCert were found for
> >>>
> >>> encryption)
> >>>
> >>> > at
> >>>
> >>> org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction
> >>>.j
> >>>
> >>> >ava:64) at
> >>>
> >>> org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:
> >>>20
> >>>
> >>> >1) at
> >>>
> >>> org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor.access$200(WSS4JOu
> >>>tI
> >>>
> >>> >nterceptor.java:47) at
> >>>
> >>> org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutIntercepto
> >>>rI
> >>>
> >>> >nternal.handleMessage(WSS4JOutInterceptor.java:219) at
> >>>
> >>> org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutIntercepto
> >>>rI
> >>>
> >>> >nternal.handleMessage(WSS4JOutInterceptor.java:107) at
> >>>
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>>Ch
> >>>
> >>> >ain.java:220) at
> >>>
> >>> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outgo
> >>>in
> >>>
> >>> >gChainInterceptor.java:74) at
> >>>
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>>Ch
> >>>
> >>> >ain.java:220) at
> >>>
> >>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiat
> >>>io
> >>>
> >>> >nObserver.java:78) at
> >>>
> >>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDesti
> >>>na
> >>>
> >>> >tion.java:92) at
> >>>
> >>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(Se
> >>>rv
> >>>
> >>> >letController.java:285) at
> >>>
> >>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletContro
> >>>ll
> >>>
> >>> >er.java:168) at
> >>>
> >>> org.apache.cxf.tran
Re: CXF WS-security Signing not working - "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI"
Since that error message is coming back in the Fault, that is something on the
server side. Thus, we'd need to see the logs for the server side.
I've never seen that error before either. Bizarre.
Dan
On Tue June 16 2009 5:12:17 pm rajla wrote:
> Hello, I am getting the exception
> "javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI" when
> implementing signature secruity with WS-Security in CXF. What does this
> mean? Anyone have any insights on what I can do to resolve this issue?
>
>
> Honestly, I don't remember this being so difficult to implement in older
> CXF and I don't think I have ever seen this error before. I tried to to
> google it a lot today and by the looks of it, not many other people have
> seen this before either. I am on version 2.2 now.
>
> Could anyone please describe to me what this error means? What process do
> I need to resolve it? P.S. The web service works fine without the
> interceptors when I don't try and use WS-security. I followed the
> WS-Security instructions listed here:
> http://cwiki.apache.org/CXF20DOC/ws-security.html
>
> That is, I generated a keystore for my server side, generated a public key
> for my client. Imported the public key for my client into the keystore.
>
> Any assistance anyone can give me in regards to resolving this issue is
> greatly appreciated.
>
> Below is the whole message and exception, including the SOAP exchange and
> stuff.:
>
> log4j:WARN No appenders could be found for logger
> (org.apache.cxf.bus.spring.BusApplicationContext).
> log4j:WARN Please initialize the log4j system properly.
> Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
> getConfigResources
> INFO: No cxf.xml configuration file detected, relying on defaults.
> Jun 16, 2009 11:00:14 AM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromClass
> INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
> com.ea.teams.EATeamsWS
> Jun 16, 2009 11:00:26 AM
> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
> INFO: Outbound Message
> ---
> ID: 1
> Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
> Encoding: UTF-8
> Content-Type: text/xml
> Headers: {SOAPAction=[""], Accept=[*/*]}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>ecurity
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
>ity-secext-1.0.xsd" soap:mustUnderstand="1"> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; Id="Signature-1">
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"; />
> http://www.w3.org/2000/09/xmldsig#rsa-sha1";
> />
>
>
> http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
> http://www.w3.org/2000/09/xmldsig#sha1"; />
> 9ugq2OUuSZq3m5dk2pchTf+XSNA=
>
>
>
> ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2q74
>o
> 2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy3dw
>d js2fRIuc9g7AvpC7KX0=
>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
>ity-secext-1.0.xsd"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
>ty-utility-1.0.xsd"
> wsu:Id="STRId-327383FBE9F26CE8EF12451752261753">
>
> CN=teams
> 1245171677
>
>
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
>ty-utility-1.0.xsd" wsu:Id="id-2"> xmlns:ns1="http://teams.ea.com/";>sysadmin4ea
>labels
> --
> Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
> logging
> INFO: Inbound Message
>
> ID: 1
> Encoding: UTF-8
> Content-Type: text/xml; charset=utf-8
> Headers: {Content-Length=[225], Server=[Jetty(6.1.18)],
> content-type=[text/xml; charset=utf-8]}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>lt>soap:ServerNo such Localname for SOAP
> URI
> --
> javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141)
> at $Proxy47.retrieveAllFields(Unknown Source)
> at test.ea.ws.WebServiceClient.main(WebServiceClient.java:46)
> Caused by: org.apache.cxf.binding.soap.SoapFault: No such Localname for
> SOAP URI
> at
> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalF
>ault(Soap11FaultInInterceptor.java:75) at
> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMess
>age(Soap11FaultInInterceptor.java:46) at
> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMess
>age(Soap11FaultInInterceptor.java:35) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
>n.java:236) at
> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(Ab
>stractFaultChainInitiatorObserver.java:96) at
> org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage
Re: How to implement the SOAP Fault for JMS Transport?
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 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 Specificat
Re: Progress GSOC 2009-WSDL2java tool based on CXF codeEngine.
On Mon June 15 2009 10:15:54 pm Pradeep Fernando wrote: > we are using CXF code engine to generate artifacts. CXF currently supports > JAX-WS compatibility, one of our main requirements. > Other than that in databinding perspective it supports , > > JAXB- primary requirement > XMLBeans > aegis (dont knw weather it is useful for tuscany people) Actually, we don't have code generation for Aegis. That's a "java first/runtime only" databinding. > SO we have to support SDO & AXIOM databinding in addition to above features > to make it really useful. > > I have gone through databinding code of CXF and did similar work in > *Dynamic SDO databinding*. Note that Im only adding databinding support to > only the tool and not to whole CXF. There is a GSOC project that adding SDO > databinding to whole CXF(CXF framework + tooling) but i dont no their > progress (couldnot see any discussions in CXF dev list). I wish I knew as well. :-( I think he's gone on vacation as I haven't been able to get a hold of him in a couple weeks. > So i created a maven module for group hooking up classes. (implementing the > databinding tooling interface of the CXF). > Now as my mentor suggested Im trying to come up with a series of test cases > that would test & exercise my implementation. > That would be really helpful in adding other databindings too. > > since CXF have xmlbeans databinding for tooling there should be similar > sort of test cases written already to exercise their implementation. I sent > a mail regarding this & it takes time to get replies. Well, the "testing" that is done for this is really part of the systests module. In the generate-test-sources phase, we run the code generator on a couple of wsdl's and then we run clients/servers with them to make sure the message exchanges work with xmlbeans. This is definitely an area we need more (well, any) unit tests. You COULD look in the cxf tools/wsdlto/test/ module. Particularly org/apache/cxf/tools/wsdlto/jaxws/CodeGen*Test.java. Those classes invoke code generators, compile the output, use reflection to make sure the compiled classes have the right methods, etcMight be a good starting point. Dan > another thing i looked at is, there is wsdl2java maven module in tuscany > code(I think based on Axis2 codegen engine) .So there should be a similar > sort of test cases to test it behaviour, but I found none. Can anyone of > you please explain the progress of that project > > please give comments & suggestions & you are welcome to ask questions if im > not clear. > > Pradeep Fernando. > > > *Im working on SDO & Axiom(ADB) at the same time. any pointers regarding > SDO code generation would be helpful. > *though I have written code for dynamic SDO databinding it is not fully > tested. should i submit it as a patch or wait untill all the things in a > working stage & well tested. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: JAXRS : issues with AegisProvider
I created two JIRAs - please have a look at them whenever you get a chance - they don't block me at the moment https://issues.apache.org/jira/browse/CXF-2296 https://issues.apache.org/jira/browse/CXF-2297 thanks, Sergey - Original Message - From: "Sergey Beryozkin" To: Sent: Wednesday, June 17, 2009 2:42 PM Subject: Re: JAXRS : issues with AegisProvider Hi Benson - I just sent a followup email at the same time you replied :-), I'll create a JIRA shortly, thanks, Sergey - Original Message - From: "Benson Margulies" To: Sent: Wednesday, June 17, 2009 2:10 PM Subject: Re: JAXRS : issues with AegisProvider Like I said. Given my current level of load, if you tee it up, I'll try to knock it down. But I need something that misbehaves. I'm sorry to have to ask for that silver platter. On Wed, Jun 17, 2009 at 8:43 AM, Sergey Beryozkin wrote: For the purpose of the demo I introduced a wrapper around the Map and it works nicely, but I'd appreciate any help in getting to the bottom of the problem I described below. thanks, Sergey - Original Message - From: "Sergey Beryozkin" < sbery...@progress.com> To: Sent: Wednesday, June 17, 2009 1:19 PM Subject: JAXRS : issues with AegisProvider Hi, I'm seeing problems with the JAXRS AegisElementProvider producing/consuming complex types like Maps. I'm nearly done with making a basic end to end JAX-RS demo working n DOSGi, the immediate problem is that a client proxy fails to consume the following somewhat complicated Aegis-produced response (Map) : http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Bonjourhttp://www.w3.org/2001/XMLSchema"; xmlns:ns2=" http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredhttp://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Hoihttp://www.w3.org/2001/XMLSchema"; xmlns:ns2=" http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredhttp://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Holahttp://www.w3.org/2001/XMLSchema"; xmlns:ns2=" http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredhttp://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Hellohttp://www.w3.org/2001/XMLSchema"; xmlns:ns2=" http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fred it complains no type mapping is found I've run a simple frontend based demo and the same Map is serialized as http://greeter.samples.dosgi.cxf.apache.org/";>http://greeter.samples.dosgi.cxf.apache.org";>BonjourFredhttp://greeter.samples.dosgi.cxf.apache.org";>HoiFredhttp://greeter.samples.dosgi.cxf.apache.org";>HolaFredhttp://greeter.samples.dosgi.cxf.apache.org ">HelloFred So is it possible to simplify the serialization somehow when Aegis is used by JAXRS ? If not then how can I make the above map being deserialized on the client side ? Benson, do you reckon it is even possible for Map ? thanks, Sergey
Re: JAXRS : issues with AegisProvider
Hi Benson - I just sent a followup email at the same time you replied :-), I'll create a JIRA shortly, thanks, Sergey - Original Message - From: "Benson Margulies" To: Sent: Wednesday, June 17, 2009 2:10 PM Subject: Re: JAXRS : issues with AegisProvider Like I said. Given my current level of load, if you tee it up, I'll try to knock it down. But I need something that misbehaves. I'm sorry to have to ask for that silver platter. On Wed, Jun 17, 2009 at 8:43 AM, Sergey Beryozkin wrote: For the purpose of the demo I introduced a wrapper around the Map and it works nicely, but I'd appreciate any help in getting to the bottom of the problem I described below. thanks, Sergey - Original Message - From: "Sergey Beryozkin" < sbery...@progress.com> To: Sent: Wednesday, June 17, 2009 1:19 PM Subject: JAXRS : issues with AegisProvider Hi, I'm seeing problems with the JAXRS AegisElementProvider producing/consuming complex types like Maps. I'm nearly done with making a basic end to end JAX-RS demo working n DOSGi, the immediate problem is that a client proxy fails to consume the following somewhat complicated Aegis-produced response (Map) : http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Bonjourhttp://www.w3.org/2001/XMLSchema"; xmlns:ns2=" http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredhttp://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Hoihttp://www.w3.org/2001/XMLSchema"; xmlns:ns2=" http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredhttp://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Holahttp://www.w3.org/2001/XMLSchema"; xmlns:ns2=" http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredhttp://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Hellohttp://www.w3.org/2001/XMLSchema"; xmlns:ns2=" http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fred it complains no type mapping is found I've run a simple frontend based demo and the same Map is serialized as http://greeter.samples.dosgi.cxf.apache.org/";>http://greeter.samples.dosgi.cxf.apache.org";>BonjourFredhttp://greeter.samples.dosgi.cxf.apache.org";>HoiFredhttp://greeter.samples.dosgi.cxf.apache.org";>HolaFredhttp://greeter.samples.dosgi.cxf.apache.org ">HelloFred So is it possible to simplify the serialization somehow when Aegis is used by JAXRS ? If not then how can I make the above map being deserialized on the client side ? Benson, do you reckon it is even possible for Map ? thanks, Sergey
Re: JAXRS : issues with AegisProvider
Like I said. Given my current level of load, if you tee it up, I'll try to knock it down. But I need something that misbehaves. I'm sorry to have to ask for that silver platter. On Wed, Jun 17, 2009 at 8:43 AM, Sergey Beryozkin wrote: > For the purpose of the demo I introduced a wrapper around the > Map and it works nicely, but I'd appreciate any help > in getting to the bottom of the problem I described below. > > thanks, Sergey > > - Original Message - From: "Sergey Beryozkin" < > sbery...@progress.com> > To: > Sent: Wednesday, June 17, 2009 1:19 PM > Subject: JAXRS : issues with AegisProvider > > > > Hi, > > I'm seeing problems with the JAXRS AegisElementProvider producing/consuming > complex types like Maps. > I'm nearly done with making a basic end to end JAX-RS demo working n DOSGi, > the immediate problem is that > a client proxy fails to consume the following somewhat complicated > Aegis-produced response (Map) : > > xmlns:ns1="urn:org.apache.cxf.aegis.types">http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" > http://www.w3.org/2001/XMLSchema-instance"; > ns3:type="ns2:GreetingPhrase">Bonjour xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" > http://www.w3.org/2001/XMLSchema-instance"; > ns2:type="xsd:string">Fred xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" > http://www.w3.org/2001/XMLSchema-instance"; > ns3:type="ns2:GreetingPhrase">Hoi xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" > http://www.w3.org/2001/XMLSchema-instance"; > ns2:type="xsd:string">Fred xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" > http://www.w3.org/2001/XMLSchema-instance"; > ns3:type="ns2:GreetingPhrase">Hola xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" > http://www.w3.org/2001/XMLSchema-instance"; > ns2:type="xsd:string">Fred xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" > http://www.w3.org/2001/XMLSchema-instance"; > ns3:type="ns2:GreetingPhrase">Hello xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" > http://www.w3.org/2001/XMLSchema-instance"; > ns2:type="xsd:string">Fred > > it complains no type mapping is found > > I've run a simple frontend based demo and the same Map is serialized as > > http://greeter.samples.dosgi.cxf.apache.org/";> xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org";>BonjourFred xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org";>HoiFred xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org";>HolaFred xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org > ">HelloFred > > So is it possible to simplify the serialization somehow when Aegis is used > by JAXRS ? If not then how can I make the above map being deserialized on > the client side ? Benson, do you reckon it is even possible for Map ? > > thanks, Sergey > >
Re: JAXRS : issues with AegisProvider
For the purpose of the demo I introduced a wrapper around the Map and it works nicely, but I'd appreciate any help in getting to the bottom of the problem I described below. thanks, Sergey - Original Message - From: "Sergey Beryozkin" To: Sent: Wednesday, June 17, 2009 1:19 PM Subject: JAXRS : issues with AegisProvider Hi, I'm seeing problems with the JAXRS AegisElementProvider producing/consuming complex types like Maps. I'm nearly done with making a basic end to end JAX-RS demo working n DOSGi, the immediate problem is that a client proxy fails to consume the following somewhat complicated Aegis-produced response (Map) : xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Bonjourhttp://www.w3.org/2001/XMLSchema"; xmlns:ns2="http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredxmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Hoihttp://www.w3.org/2001/XMLSchema"; xmlns:ns2="http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredxmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Holahttp://www.w3.org/2001/XMLSchema"; xmlns:ns2="http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredxmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Hellohttp://www.w3.org/2001/XMLSchema"; xmlns:ns2="http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fred it complains no type mapping is found I've run a simple frontend based demo and the same Map is serialized as http://greeter.samples.dosgi.cxf.apache.org/";>xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org";>BonjourFredxmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org";>HoiFredxmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org";>HolaFredxmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org";>HelloFred So is it possible to simplify the serialization somehow when Aegis is used by JAXRS ? If not then how can I make the above map being deserialized on the client side ? Benson, do you reckon it is even possible for Map ? thanks, Sergey
Re: JAXRS : issues with AegisProvider
The 'any' in the map means that somehow Aegis is not finding type information for the map element type. If you set up some sort of test case and check it in with @Ignore, and make a JIRA, and assign it to me :-) I can probably fix it. On Wed, Jun 17, 2009 at 8:19 AM, Sergey Beryozkin wrote: > Hi, > > I'm seeing problems with the JAXRS AegisElementProvider producing/consuming > complex types like Maps. > I'm nearly done with making a basic end to end JAX-RS demo working n DOSGi, > the immediate problem is that > a client proxy fails to consume the following somewhat complicated > Aegis-produced response (Map) : > > xmlns:ns1="urn:org.apache.cxf.aegis.types">http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" > http://www.w3.org/2001/XMLSchema-instance"; > ns3:type="ns2:GreetingPhrase">Bonjour xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" > http://www.w3.org/2001/XMLSchema-instance"; > ns2:type="xsd:string">Fred xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" > http://www.w3.org/2001/XMLSchema-instance"; > ns3:type="ns2:GreetingPhrase">Hoi xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" > http://www.w3.org/2001/XMLSchema-instance"; > ns2:type="xsd:string">Fred xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" > http://www.w3.org/2001/XMLSchema-instance"; > ns3:type="ns2:GreetingPhrase">Hola xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" > http://www.w3.org/2001/XMLSchema-instance"; > ns2:type="xsd:string">Fred xmlns:ns2="http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3=" > http://www.w3.org/2001/XMLSchema-instance"; > ns3:type="ns2:GreetingPhrase">Hello xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:ns2=" > http://www.w3.org/2001/XMLSchema-instance"; > ns2:type="xsd:string">Fred > > it complains no type mapping is found > > I've run a simple frontend based demo and the same Map is serialized as > > http://greeter.samples.dosgi.cxf.apache.org/";> xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org";>BonjourFred xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org";>HoiFred xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org";>HolaFred xmlns:ns2="http://greeter.samples.dosgi.cxf.apache.org > ">HelloFred > > So is it possible to simplify the serialization somehow when Aegis is used > by JAXRS ? If not then how can I make the above map being deserialized on > the client side ? Benson, do you reckon it is even possible for Map ? > > thanks, Sergey >
JAXRS : issues with AegisProvider
Hi, I'm seeing problems with the JAXRS AegisElementProvider producing/consuming complex types like Maps. I'm nearly done with making a basic end to end JAX-RS demo working n DOSGi, the immediate problem is that a client proxy fails to consume the following somewhat complicated Aegis-produced response (Map) : http://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Bonjourhttp://www.w3.org/2001/XMLSchema"; xmlns:ns2="http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredhttp://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Hoihttp://www.w3.org/2001/XMLSchema"; xmlns:ns2="http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredhttp://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Holahttp://www.w3.org/2001/XMLSchema"; xmlns:ns2="http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fredhttp://rest.greeter.samples.dosgi.cxf.apache.org"; xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"; ns3:type="ns2:GreetingPhrase">Hellohttp://www.w3.org/2001/XMLSchema"; xmlns:ns2="http://www.w3.org/2001/XMLSchema-instance"; ns2:type="xsd:string">Fred it complains no type mapping is found I've run a simple frontend based demo and the same Map is serialized as http://greeter.samples.dosgi.cxf.apache.org/";>http://greeter.samples.dosgi.cxf.apache.org";>BonjourFredhttp://greeter.samples.dosgi.cxf.apache.org";>HoiFredhttp://greeter.samples.dosgi.cxf.apache.org";>HolaFredhttp://greeter.samples.dosgi.cxf.apache.org";>HelloFred So is it possible to simplify the serialization somehow when Aegis is used by JAXRS ? If not then how can I make the above map being deserialized on the client side ? Benson, do you reckon it is even possible for Map ? thanks, Sergey
Re: Questions about CXF WS-RM
Hi Richard, Apologies for the delay in replying. Please see my comments in-line. 2009/6/15 Richard Opalka : > what's the current state of CXF WS-RM? See below. > I'm asking because we'd like to integrate probably > WS-RM in our JBossWS CXF integration. Great that you're thinking of using CXF WS-RM. > The main questions are: > * Which WS-RM specs are supported now (I know about 1.0, is 1.1 supported > already)? Only WS-RM 1.0 (2005/02) is supported as yet. This was the current version of the spec when the original RM implementation was done as part of the Celtix project (the precursor to CXF). We've had some interest in WS-RM 1.1 and I intend to do a costing on the implementation effort soon, and hopefully will get the time to implement support for it in the CXF 2.3 timeframe. > * Is QoS (Quality of Service) ensured in CXF WS-RM implementation? Well yes, in so far as the qualities of service envisaged by the WS-RM spec as concerned. So for example the policy with regard to ordering and duplicates may be asserted via the /ws-rm-policy:RMAssertion/ws-rm:deliveryAssurance element in config (see schema[1]). However other QoS typically available in the MOM world, such as message expiration/TTL and priority, are not part of WS-RM. > * Is current CXF WS-RM implementation tightly coupled with Endpoint? Well, CXF WS-RM can be configured on a per-endpoint basis, or for the entire Bus. However, internally the WS-RM layer creates an RMEndpoint for each org.apache.cxf.endpoint.Endpoint with which a reliable exchange occurs. So that sense there is a certain one-to-one-ness going on. Is that what you meant by being tightly coupled? Or were you more thinking of using WS-RM to mediate message exchanges with something other than CXF endpoints? > * Is there some API for client side when receiving undelivered messages? By undelivered messages, do you mean un-acknowledged messages that have been resent? If the original client is still running, then the retransmitted response message will be delivered to the application in the normal way (either by virtue of the invoking client thread being blocked, or via a callback or pollable for an asynchronous invocation). However, if the client application has been restarted since the original request was sent, then there is no way currently for the resent message to rendez-vous with the application logic. This deficiency was clear to us when the original RM implementation was done, and we had at the back of our mind the intention to do something about it, via some sort of persistent callback mechanism. Any ideas you might have in this regard would be welcome. > Where I could find it? > * Is there some detailed architecture documentation about CXF WS-RM? No, unfortunately. Hope this helps, Eoghan [1] http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/rm/src/main/resources/schemas/configuration/wsrm-manager-types.xsd
