You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by chakras <su...@yahoo.com> on 2011/02/24 20:42:49 UTC
SOAP header wsdl2java issue?
I have a CXF web service running that prints out a WSDL. Taking this WSDL and
running it through CXF version of wsdl2java generates me the stub,
wsdl2java -verbose -p mypackage.base -sn Myservice -client %1
When I invoke it, I always get a SOAP fault in my interceptor. My
interceptor is SecurityInterceptor given below,
read [ReadHeadersInterceptor, SecurityInterceptor, SoapActionInInterceptor,
StartBodyInterceptor]
On investigating further I find that the 'SOAPAction', is passed as
Soapaction - so when I do this
(reqHeaders.get(SoapBindingConstants.SOAP_ACTION);) - I don't get any
Action defined. The work around for now that I could do is this,
// Fall back on parsing headers (we get Soapaction instead of
SOAPAction also)
if (action.length() == 0) {
Map<String, List<String>> reqHeaders =
CastUtils.cast((Map)message.get(Message.PROTOCOL_HEADERS));
for (Map.Entry<String, List<String>> entry :
reqHeaders.entrySet()) {
String key = entry.getKey();
List value = entry.getValue();
if (SoapBindingConstants.SOAP_ACTION.equalsIgnoreCase(key))
{
if (value != null && value.size() > 0)
action.append(value.get(0).toString());
}
}
}
Is this how it is supposed to work?
--
View this message in context: http://cxf.547215.n5.nabble.com/SOAP-header-wsdl2java-issue-tp3399058p3399058.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: SOAP header wsdl2java issue?
Posted by chakras <su...@yahoo.com>.
Hi Aki - it is the same one. here is the batch I used (it has the CXF version
that I used),
@echo off
REM set PATH=%PATH%;C:\Apps\Java\axis2-1.5.2\bin
set PATH=C:\Apps\Java\apache-cxf-2.3.1\bin
set JAVA_HOME=C:\Apps\Java\jdk1.6
set AXIS2_HOME=C:\Apps\Java\axis2-1.5.2
set CXF_HOME=C:\Apps\Java\apache-cxf-2.3.1
wsdl2java -verbose -p my.package.base -sn Myservice -client %1
REM wsdl2java -l java -ss -sd -g --noBuildXML -p my.package.base -uri %1
%1 is the WSDL that I saved from CXF service using SoapUI. Hope that helps.
--
View this message in context: http://cxf.547215.n5.nabble.com/SOAP-header-wsdl2java-issue-tp3399058p3400684.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: SOAP header wsdl2java issue?
Posted by Aki Yoshida <sa...@googlemail.com>.
Hi Suvendra,
If you are using the generated class with a CXF client, you should be
getting the CXF's default casing, which is "SOAPAction" because it
uses the same constant. Is your client really a CXF client?
But in any case, the server must expect to get the action header in
several combinations, as the headers must be treated
case-insensitively and there are some clients that do not use the
CXF's default form.
Regards, aki
On Fri, Feb 25, 2011 at 3:09 PM, chakras <su...@yahoo.com> wrote:
>
> Thanks Aki - I was thinking it may be because my interceptor is sitting in
> front of SoapActionInInterceptor - and should move it further down in the
> queue. But since my workaround is working fine and I am also setting this
> action back to the headers after I extract it (same code as the sample
> SoapActionInIntterceptor), everything seems to be happy.
>
> I was wondering why I am receiving SOAPAction header in a non-standard
> casing. Does this have something to do with the wsdl2java stub code
> generated? Or do I need to set it manually on the headers before invoking
> the stub methods?
>
> Appreciate your help Aki - thanks again.
>
> - Suvendra
> --
> View this message in context: http://cxf.547215.n5.nabble.com/SOAP-header-wsdl2java-issue-tp3399058p3400179.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
Re: SOAP header wsdl2java issue?
Posted by chakras <su...@yahoo.com>.
Thanks Aki - I was thinking it may be because my interceptor is sitting in
front of SoapActionInInterceptor - and should move it further down in the
queue. But since my workaround is working fine and I am also setting this
action back to the headers after I extract it (same code as the sample
SoapActionInIntterceptor), everything seems to be happy.
I was wondering why I am receiving SOAPAction header in a non-standard
casing. Does this have something to do with the wsdl2java stub code
generated? Or do I need to set it manually on the headers before invoking
the stub methods?
Appreciate your help Aki - thanks again.
- Suvendra
--
View this message in context: http://cxf.547215.n5.nabble.com/SOAP-header-wsdl2java-issue-tp3399058p3400179.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: SOAP header wsdl2java issue?
Posted by Aki Yoshida <sa...@googlemail.com>.
Hi,
Normally, if your interceptor is sitting after the
SOAPActionInInterceptor, you can get the aciton value by
message.get(SoapBindingConstants.SOAP_ACTION) because this interceptor
is supposed to extract the action from the transport headers and put
it into the message's property. But when I looked into this
SOAPActionInInterceptor, it seems to have the same problem as your
example and not extracting the soapaction header if it has different
casing.
I can create a jira ticket.
regards, aki
On Thu, Feb 24, 2011 at 8:42 PM, chakras <su...@yahoo.com> wrote:
>
> I have a CXF web service running that prints out a WSDL. Taking this WSDL and
> running it through CXF version of wsdl2java generates me the stub,
>
> wsdl2java -verbose -p mypackage.base -sn Myservice -client %1
>
> When I invoke it, I always get a SOAP fault in my interceptor. My
> interceptor is SecurityInterceptor given below,
>
> read [ReadHeadersInterceptor, SecurityInterceptor, SoapActionInInterceptor,
> StartBodyInterceptor]
>
> On investigating further I find that the 'SOAPAction', is passed as
> Soapaction - so when I do this
> (reqHeaders.get(SoapBindingConstants.SOAP_ACTION);) - I don't get any
> Action defined. The work around for now that I could do is this,
>
> // Fall back on parsing headers (we get Soapaction instead of
> SOAPAction also)
> if (action.length() == 0) {
> Map<String, List<String>> reqHeaders =
> CastUtils.cast((Map)message.get(Message.PROTOCOL_HEADERS));
> for (Map.Entry<String, List<String>> entry :
> reqHeaders.entrySet()) {
>
> String key = entry.getKey();
> List value = entry.getValue();
> if (SoapBindingConstants.SOAP_ACTION.equalsIgnoreCase(key))
> {
> if (value != null && value.size() > 0)
> action.append(value.get(0).toString());
> }
> }
> }
>
> Is this how it is supposed to work?
> --
> View this message in context: http://cxf.547215.n5.nabble.com/SOAP-header-wsdl2java-issue-tp3399058p3399058.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
Re: SOAP header wsdl2java issue?
Posted by chakras <su...@yahoo.com>.
Thanks Daniel and Aki for your help.
Right now I created a POC only - using the inbuilt Jetty that comes bundled
with CXF. While calling through SoapUI - it works fine.
I created a client (Java application) - using wsdl2java, created the stubs.
So, it does not have a Application Server on the client side (and really no
CXF involvement - apart from the generated Stubs with JAX-WS bindings). This
client version sends a bad Action header. It *is the* Java implementation of
JAX-WS that is sending the bad action header.
Here is the simplified class annotation generated,
@WebService(targetNamespace = "Gateway/", name = "Gateway")
@XmlSeeAlso({ObjectFactory.class})
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
Simplified one method annotation looks like this,
@WebResult(name = "gatewayServiceResponse", targetNamespace =
"http://Gateway/", partName = "parameters")
@Action(input = "GatewaySvc", output = "http://gatewayServiceResponse")
@WebMethod(action = "GatewaySvc")
Thanks,
Suvendra
--
View this message in context: http://cxf.547215.n5.nabble.com/SOAP-header-wsdl2java-issue-tp3399058p3400866.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: SOAP header wsdl2java issue?
Posted by Aki Yoshida <sa...@googlemail.com>.
Hi Dan,
After looking into this for a while, actually it looks simple to fix
the behavior of this PROTOCOL_HEADERS map. In addition, it seems that
there will be similar problems with other headers if we do not change
the map's behavior. So, I am in favor of fixing this problem at this
map and not at SOAPActionInInterceptor. I will update the JIRA ticket
accordingly.
Thanks.
Regards, aki
On Fri, Feb 25, 2011 at 10:14 PM, Aki Yoshida <sa...@googlemail.com> wrote:
> Hi Dan,
> I was creating a bug ticket some hours ago but JIRA was not responding
> and could just submit it earlier
> CXF-3367.
>
> I thought also why the PROTOCOL_HEADERS were not storing headers using
> e.g., the lowercased key names. But if we change the keys now into the
> lower or upper case, we will probably have to change many classes that
> are expecting the current names.
>
> I was not sure if this change would then feasible in 2.3.x. We would
> probably need to introduce a custom map that uses the lowercase key
> name mapped to a header name value-list pair intead of the current
> simple map because people expect the behavior to remain the same
> (i.e.., a lookup works fine with the current constants as long as the
> original headers names match the constants and for the outbound case,
> the header names are serialized in the given inserted case and not
> suddenly turned into lower or uppercase).
>
> So, I thought we would rather change SOAPActionInInterceptor so that
> it looks for the soap action header by itereating through the list.
>
> regards, aki
>
> On Fri, Feb 25, 2011 at 8:52 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>> What App server or servlet engine are you using? I've seen this type of
>> thing with various servlet engines. Some of them mangle the case of the
>> headers pretty bad.
>>
>> The "real" bug is that the PROTOCOL_HEADERS map should use a case insensitive
>> key set. That's what i would log as the bug.
>>
>> Dan
>>
>>
>> On Thursday 24 February 2011 2:42:49 PM chakras wrote:
>>> I have a CXF web service running that prints out a WSDL. Taking this WSDL
>>> and running it through CXF version of wsdl2java generates me the stub,
>>>
>>> wsdl2java -verbose -p mypackage.base -sn Myservice -client %1
>>>
>>> When I invoke it, I always get a SOAP fault in my interceptor. My
>>> interceptor is SecurityInterceptor given below,
>>>
>>> read [ReadHeadersInterceptor, SecurityInterceptor, SoapActionInInterceptor,
>>> StartBodyInterceptor]
>>>
>>> On investigating further I find that the 'SOAPAction', is passed as
>>> Soapaction - so when I do this
>>> (reqHeaders.get(SoapBindingConstants.SOAP_ACTION);) - I don't get any
>>> Action defined. The work around for now that I could do is this,
>>>
>>> // Fall back on parsing headers (we get Soapaction instead of
>>> SOAPAction also)
>>> if (action.length() == 0) {
>>> Map<String, List<String>> reqHeaders =
>>> CastUtils.cast((Map)message.get(Message.PROTOCOL_HEADERS));
>>> for (Map.Entry<String, List<String>> entry :
>>> reqHeaders.entrySet()) {
>>>
>>> String key = entry.getKey();
>>> List value = entry.getValue();
>>> if (SoapBindingConstants.SOAP_ACTION.equalsIgnoreCase(key))
>>> {
>>> if (value != null && value.size() > 0)
>>> action.append(value.get(0).toString());
>>> }
>>> }
>>> }
>>>
>>> Is this how it is supposed to work?
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>>
>
[ANN]VTD-XML 2.10
Posted by Jimmy Zhang <cr...@comcast.net>.
VTD-XML 2.10 is now released. It can be downloaded at
https://sourceforge.net/projects/vtd-xml/files/vtd-xml/ximpleware_2.10/.
This release includes a number of new features and enhancement.
* The core API of VTD-XML has been expanded. Users can now perform
cut/paste/insert on an empty element.
* This release also adds the support of deeper location cache support for
parsing and indexing. This feature is useful for application performance
tuning for
processing various XML documents.
* The java version also added support for processing zip and gzip files.
Direct processing of httpURL based XML is enhanced.
* Extended Java version now support Iso-8859-10~16 encoding.
* A full featured C++ port is released.
* C version of VTD-XML now make use of thread local storage to achieve
thread safety for multi-threaded application.
* There are also a number of bugs fixed. Special thanks to Jozef Aerts, John
Sillers, Chris Tornau and a number of other users for input and suggestions
Re: SOAP header wsdl2java issue?
Posted by Daniel Kulp <dk...@apache.org>.
On Friday 25 February 2011 4:14:04 PM Aki Yoshida wrote:
> Hi Dan,
> I was creating a bug ticket some hours ago but JIRA was not responding
> and could just submit it earlier
> CXF-3367.
>
> I thought also why the PROTOCOL_HEADERS were not storing headers using
> e.g., the lowercased key names. But if we change the keys now into the
> lower or upper case, we will probably have to change many classes that
> are expecting the current names.
What I was thinking was when the Map is created, instead of using a normal
HashMap, to use something like:
Map<String, ...> map = new TreeMap<String, ...>(String.CASE_INSENSITIVE_ORDER)
That way, the get/put's on the map are insensitive. We would just need to
make sure that where ever we CREATE the maps, we make sure we use that
symantic.
Dan
> I was not sure if this change would then feasible in 2.3.x. We would
> probably need to introduce a custom map that uses the lowercase key
> name mapped to a header name value-list pair intead of the current
> simple map because people expect the behavior to remain the same
> (i.e.., a lookup works fine with the current constants as long as the
> original headers names match the constants and for the outbound case,
> the header names are serialized in the given inserted case and not
> suddenly turned into lower or uppercase).
>
> So, I thought we would rather change SOAPActionInInterceptor so that
> it looks for the soap action header by itereating through the list.
>
> regards, aki
>
> On Fri, Feb 25, 2011 at 8:52 PM, Daniel Kulp <dk...@apache.org> wrote:
> > What App server or servlet engine are you using? I've seen this type of
> > thing with various servlet engines. Some of them mangle the case of the
> > headers pretty bad.
> >
> > The "real" bug is that the PROTOCOL_HEADERS map should use a case
> > insensitive key set. That's what i would log as the bug.
> >
> > Dan
> >
> > On Thursday 24 February 2011 2:42:49 PM chakras wrote:
> >> I have a CXF web service running that prints out a WSDL. Taking this
> >> WSDL and running it through CXF version of wsdl2java generates me the
> >> stub,
> >>
> >> wsdl2java -verbose -p mypackage.base -sn Myservice -client %1
> >>
> >> When I invoke it, I always get a SOAP fault in my interceptor. My
> >> interceptor is SecurityInterceptor given below,
> >>
> >> read [ReadHeadersInterceptor, SecurityInterceptor,
> >> SoapActionInInterceptor, StartBodyInterceptor]
> >>
> >> On investigating further I find that the 'SOAPAction', is passed as
> >> Soapaction - so when I do this
> >> (reqHeaders.get(SoapBindingConstants.SOAP_ACTION);) - I don't get any
> >> Action defined. The work around for now that I could do is this,
> >>
> >> // Fall back on parsing headers (we get Soapaction instead of
> >> SOAPAction also)
> >> if (action.length() == 0) {
> >> Map<String, List<String>> reqHeaders =
> >> CastUtils.cast((Map)message.get(Message.PROTOCOL_HEADERS));
> >> for (Map.Entry<String, List<String>> entry :
> >> reqHeaders.entrySet()) {
> >>
> >> String key = entry.getKey();
> >> List value = entry.getValue();
> >> if
> >> (SoapBindingConstants.SOAP_ACTION.equalsIgnoreCase(key)) {
> >> if (value != null && value.size() > 0)
> >> action.append(value.get(0).toString());
> >> }
> >> }
> >> }
> >>
> >> Is this how it is supposed to work?
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: SOAP header wsdl2java issue?
Posted by Aki Yoshida <sa...@googlemail.com>.
Hi Dan,
I was creating a bug ticket some hours ago but JIRA was not responding
and could just submit it earlier
CXF-3367.
I thought also why the PROTOCOL_HEADERS were not storing headers using
e.g., the lowercased key names. But if we change the keys now into the
lower or upper case, we will probably have to change many classes that
are expecting the current names.
I was not sure if this change would then feasible in 2.3.x. We would
probably need to introduce a custom map that uses the lowercase key
name mapped to a header name value-list pair intead of the current
simple map because people expect the behavior to remain the same
(i.e.., a lookup works fine with the current constants as long as the
original headers names match the constants and for the outbound case,
the header names are serialized in the given inserted case and not
suddenly turned into lower or uppercase).
So, I thought we would rather change SOAPActionInInterceptor so that
it looks for the soap action header by itereating through the list.
regards, aki
On Fri, Feb 25, 2011 at 8:52 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> What App server or servlet engine are you using? I've seen this type of
> thing with various servlet engines. Some of them mangle the case of the
> headers pretty bad.
>
> The "real" bug is that the PROTOCOL_HEADERS map should use a case insensitive
> key set. That's what i would log as the bug.
>
> Dan
>
>
> On Thursday 24 February 2011 2:42:49 PM chakras wrote:
>> I have a CXF web service running that prints out a WSDL. Taking this WSDL
>> and running it through CXF version of wsdl2java generates me the stub,
>>
>> wsdl2java -verbose -p mypackage.base -sn Myservice -client %1
>>
>> When I invoke it, I always get a SOAP fault in my interceptor. My
>> interceptor is SecurityInterceptor given below,
>>
>> read [ReadHeadersInterceptor, SecurityInterceptor, SoapActionInInterceptor,
>> StartBodyInterceptor]
>>
>> On investigating further I find that the 'SOAPAction', is passed as
>> Soapaction - so when I do this
>> (reqHeaders.get(SoapBindingConstants.SOAP_ACTION);) - I don't get any
>> Action defined. The work around for now that I could do is this,
>>
>> // Fall back on parsing headers (we get Soapaction instead of
>> SOAPAction also)
>> if (action.length() == 0) {
>> Map<String, List<String>> reqHeaders =
>> CastUtils.cast((Map)message.get(Message.PROTOCOL_HEADERS));
>> for (Map.Entry<String, List<String>> entry :
>> reqHeaders.entrySet()) {
>>
>> String key = entry.getKey();
>> List value = entry.getValue();
>> if (SoapBindingConstants.SOAP_ACTION.equalsIgnoreCase(key))
>> {
>> if (value != null && value.size() > 0)
>> action.append(value.get(0).toString());
>> }
>> }
>> }
>>
>> Is this how it is supposed to work?
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
Re: SOAP header wsdl2java issue?
Posted by Daniel Kulp <dk...@apache.org>.
What App server or servlet engine are you using? I've seen this type of
thing with various servlet engines. Some of them mangle the case of the
headers pretty bad.
The "real" bug is that the PROTOCOL_HEADERS map should use a case insensitive
key set. That's what i would log as the bug.
Dan
On Thursday 24 February 2011 2:42:49 PM chakras wrote:
> I have a CXF web service running that prints out a WSDL. Taking this WSDL
> and running it through CXF version of wsdl2java generates me the stub,
>
> wsdl2java -verbose -p mypackage.base -sn Myservice -client %1
>
> When I invoke it, I always get a SOAP fault in my interceptor. My
> interceptor is SecurityInterceptor given below,
>
> read [ReadHeadersInterceptor, SecurityInterceptor, SoapActionInInterceptor,
> StartBodyInterceptor]
>
> On investigating further I find that the 'SOAPAction', is passed as
> Soapaction - so when I do this
> (reqHeaders.get(SoapBindingConstants.SOAP_ACTION);) - I don't get any
> Action defined. The work around for now that I could do is this,
>
> // Fall back on parsing headers (we get Soapaction instead of
> SOAPAction also)
> if (action.length() == 0) {
> Map<String, List<String>> reqHeaders =
> CastUtils.cast((Map)message.get(Message.PROTOCOL_HEADERS));
> for (Map.Entry<String, List<String>> entry :
> reqHeaders.entrySet()) {
>
> String key = entry.getKey();
> List value = entry.getValue();
> if (SoapBindingConstants.SOAP_ACTION.equalsIgnoreCase(key))
> {
> if (value != null && value.size() > 0)
> action.append(value.get(0).toString());
> }
> }
> }
>
> Is this how it is supposed to work?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com