You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Johan Karlberg <jo...@ifsworld.com> on 2012/01/03 11:55:09 UTC
Regression in 2.5.1?
I was forced to revert back to 2.5.0 after encountering the following: (partial stacktrace)
< local code stacktrace removed >
Caused by: java.lang.NullPointerException
at org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:203)
at org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:236)
at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:88)
at org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontConduitSelector.java:71)
at org.apache.cxf.endpoint.ClientImpl.getConduit(ClientImpl.java:842)
<local code stacktrace removed>
At fault seems to be the dereferencing of a null AttributedURIType, which previously was a String, at the very top of SoapTransportFactory.java's getConduit override.
The calling pattern that triggered it is as follows:
((BindingProvider)port).getRequestContext().put("soap.env.ns.map", topLevelNamespaces);
((BindingProvider)port).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpoint);
// chunking interferes with NTLM
final HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(HTTP_TIMEOUT_IN_MILLISECONDS);
httpClientPolicy.setAllowChunking(false);
final Client client = ClientProxy.getClient(port);
final HTTPConduit httpConduit = (HTTPConduit)client.getConduit(); // triggers the stacktrace
httpConduit.setClient(httpClientPolicy);
The code works well under 2.5.0 and a significant number of earlier releases. Is there something I am forgetting to do to make sure said Address component is never null (taking into account that the WSDL does not declare the endpoint, it is dynamic configuration), or should it go into JIRA?
// Johan Karlberg
------------------------------------------------------------------------------
CONFIDENTIALITY AND DISCLAIMER NOTICE
This e-mail, including any attachments, is confidential and for use only by
the intended recipient. If you are not the intended recipient, please notify
us immediately and delete this e-mail from your system. Any use or disclosure
of the information contained herein is strictly prohibited. As internet
communications are not secure, we do not accept legal responsibility for the
contents of this message nor responsibility for any change made to this
message after it was sent by the original sender. We advise you to carry out
your own virus check as we cannot accept liability for damage resulting from
software viruses.
RE: Regression in 2.5.1?
Posted by Johan Karlberg <jo...@ifsworld.com>.
Hi,
I can confirm the issue as fixed in maven snapshot cxf-2.5.2-20120105.060926-13
For 2.5.1, your fix to my wsdl also solves the issue, and I will add this fix from now on.
Thank you for your help, It will be nice to be able to continue to refresh CXF when our project refreshes it's dependencies. Keep up the good work.
// Johan Karlberg
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: den 4 januari 2012 16:22
To: users@cxf.apache.org
Cc: Johan Karlberg
Subject: Re: Regression in 2.5.1?
Ah. OK. No <soap:address location=""/> thing in the WSDL. Most likely, if
you update the wsdl to just have something like:
<soap:address location="https://localhost:8080"/>
or something (even if nothing is there), it would work. The
ENDPOITN_ADDRESS_PROPERTY would just override that at runtime. That said, fix
should be in last nights snapshots. Would be great if you could test that.
Dan
On Wednesday, January 04, 2012 10:49:06 AM Johan Karlberg wrote:
> Hi,
>
> The port object is a thin adapter (only providing default values for a
> number of overly verbose operations exposed on the generated port) on top
> of a port type generated by wsdl2java, if you need the WSDL (around 8k
> lines) or generated client (around 500 files, at about 2MB worth of
> generated source that I thankfully do not have to poke in) it could be
> arranged, but I suspect it is not relevant.
>
> The code requested is as follows:
>
> final URL wsdlURL = ClassLoader.getSystemResource("services.wsdl");
>
> final ExchangeWebService exchangeWebService = new
> ExchangeWebService(wsdlURL, new QName(
> "http://schemas.microsoft.com/exchange/services/2006/messages",
> "ExchangeWebService"));
>
> final ExchangeServicePortType port =
> exchangeWebService.getExchangeWebPort();
>
> /*
> setting these namespaces on the soap envelope
> prevents them from being added separately to each new soap header.
> */
> final ImmutableMap topLevelNamespaces = ImmutableMap
> .of("m",
> "http://schemas.microsoft.com/exchange/services/2006/messages", "t",
> "http://schemas.microsoft.com/exchange/services/2006/types");
>
> The ExchangeServicePortType and ExchangeWebService are part of the generated
> client, and contain no magic or alterations on my part.
>
> The BindingProvider.ENDPOINT_ADDRESS_PROPERTY is the only point at which my
> client provides an endpoint address to CXF. The WSDL for the service (the
> service type specifically, there is as previously mentioned a plethora of
> operations, messages and types defined) Is as barren as:
>
> <wsdl:service name="ExchangeWebService">
> <wsdl:port name="ExchangeWebPort"
> binding="tns:ExchangeServiceBinding"> </wsdl:port>
> </wsdl:service>
>
> The WSDL needs to be loaded from a local source as it needs significant
> modification from what Microsoft exports (on Exchange server 2007 SP1 in
> this particular case) in order for CXF to produce a working client.
>
> The URL once deployed will likely end up looking something like
> "jar:file:/C:/installdir/product/lib/module.jar!/services.wsdl", which the
> JRE will have no problem with but perhaps CXF does.
>
> // Johan Karlberg
>
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: den 3 januari 2012 23:00
> To: users@cxf.apache.org
> Cc: Johan Karlberg
> Subject: Re: Regression in 2.5.1?
>
>
> It should definitely go into JIRA. I can see the problem and have a fix
> for it. However, can I also see the code you are using to create your
> "port" object? I'm kind of surprised to see it's letting that be created
> without a URL of some sort.
>
> Dan
>
> On Tuesday, January 03, 2012 11:55:09 AM Johan Karlberg wrote:
> > I was forced to revert back to 2.5.0 after encountering the following:
> > (partial stacktrace)
> >
> > < local code stacktrace removed >
> > Caused by: java.lang.NullPointerException
> >
> > at
> >
> > org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransp
> > ortFa
> > ctory.java:203) at
> > org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransp
> > ortFa
> > ctory.java:236) at
> > org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(Abs
> > tract
> > ConduitSelector.java:88) at
> > org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontCo
> > nduit
> > Selector.java:71) at
> > org.apache.cxf.endpoint.ClientImpl.getConduit(ClientImpl.java:842)
> > <local code stacktrace removed>
> >
> > At fault seems to be the dereferencing of a null AttributedURIType,
> > which previously was a String, at the very top of
> > SoapTransportFactory.java's getConduit override.
> >
> > The calling pattern that triggered it is as follows:
> >
> >
> > ((BindingProvider)port).getRequestContext().put("soap.env.ns.map",
> > topLevelNamespaces);
> > ((BindingProvider)port).getRequestContext().put(BindingProvider.ENDPOI
> > NT_AD
> > DRESS_PROPERTY, endpoint);
> >
> > // chunking interferes with NTLM
> > final HTTPClientPolicy httpClientPolicy = new
> > HTTPClientPolicy();
> > httpClientPolicy.setConnectionTimeout(HTTP_TIMEOUT_IN_MILLIS
> > ECONDS); httpClientPolicy.setAllowChunking(false);
> >
> > final Client client = ClientProxy.getClient(port);
> > final HTTPConduit httpConduit =
> >
> > (HTTPConduit)client.getConduit(); // triggers the stacktrace
> > httpConduit.setClient(httpClientPolicy);
> >
> > The code works well under 2.5.0 and a significant number of earlier
> > releases. Is there something I am forgetting to do to make sure said
> > Address component is never null (taking into account that the WSDL
> > does not declare the endpoint, it is dynamic configuration), or should
> > it go into JIRA?
> >
> > // Johan Karlberg
> >
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
------------------------------------------------------------------------------
CONFIDENTIALITY AND DISCLAIMER NOTICE
This e-mail, including any attachments, is confidential and for use only by
the intended recipient. If you are not the intended recipient, please notify
us immediately and delete this e-mail from your system. Any use or disclosure
of the information contained herein is strictly prohibited. As internet
communications are not secure, we do not accept legal responsibility for the
contents of this message nor responsibility for any change made to this
message after it was sent by the original sender. We advise you to carry out
your own virus check as we cannot accept liability for damage resulting from
software viruses.
Re: Regression in 2.5.1?
Posted by Daniel Kulp <dk...@apache.org>.
Ah. OK. No <soap:address location=""/> thing in the WSDL. Most likely, if
you update the wsdl to just have something like:
<soap:address location="https://localhost:8080"/>
or something (even if nothing is there), it would work. The
ENDPOITN_ADDRESS_PROPERTY would just override that at runtime. That said, fix
should be in last nights snapshots. Would be great if you could test that.
Dan
On Wednesday, January 04, 2012 10:49:06 AM Johan Karlberg wrote:
> Hi,
>
> The port object is a thin adapter (only providing default values for a
> number of overly verbose operations exposed on the generated port) on top
> of a port type generated by wsdl2java, if you need the WSDL (around 8k
> lines) or generated client (around 500 files, at about 2MB worth of
> generated source that I thankfully do not have to poke in) it could be
> arranged, but I suspect it is not relevant.
>
> The code requested is as follows:
>
> final URL wsdlURL = ClassLoader.getSystemResource("services.wsdl");
>
> final ExchangeWebService exchangeWebService = new
> ExchangeWebService(wsdlURL, new QName(
> "http://schemas.microsoft.com/exchange/services/2006/messages",
> "ExchangeWebService"));
>
> final ExchangeServicePortType port =
> exchangeWebService.getExchangeWebPort();
>
> /*
> setting these namespaces on the soap envelope
> prevents them from being added separately to each new soap header.
> */
> final ImmutableMap topLevelNamespaces = ImmutableMap
> .of("m",
> "http://schemas.microsoft.com/exchange/services/2006/messages", "t",
> "http://schemas.microsoft.com/exchange/services/2006/types");
>
> The ExchangeServicePortType and ExchangeWebService are part of the generated
> client, and contain no magic or alterations on my part.
>
> The BindingProvider.ENDPOINT_ADDRESS_PROPERTY is the only point at which my
> client provides an endpoint address to CXF. The WSDL for the service (the
> service type specifically, there is as previously mentioned a plethora of
> operations, messages and types defined) Is as barren as:
>
> <wsdl:service name="ExchangeWebService">
> <wsdl:port name="ExchangeWebPort"
> binding="tns:ExchangeServiceBinding"> </wsdl:port>
> </wsdl:service>
>
> The WSDL needs to be loaded from a local source as it needs significant
> modification from what Microsoft exports (on Exchange server 2007 SP1 in
> this particular case) in order for CXF to produce a working client.
>
> The URL once deployed will likely end up looking something like
> "jar:file:/C:/installdir/product/lib/module.jar!/services.wsdl", which the
> JRE will have no problem with but perhaps CXF does.
>
> // Johan Karlberg
>
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: den 3 januari 2012 23:00
> To: users@cxf.apache.org
> Cc: Johan Karlberg
> Subject: Re: Regression in 2.5.1?
>
>
> It should definitely go into JIRA. I can see the problem and have a fix
> for it. However, can I also see the code you are using to create your
> "port" object? I'm kind of surprised to see it's letting that be created
> without a URL of some sort.
>
> Dan
>
> On Tuesday, January 03, 2012 11:55:09 AM Johan Karlberg wrote:
> > I was forced to revert back to 2.5.0 after encountering the following:
> > (partial stacktrace)
> >
> > < local code stacktrace removed >
> > Caused by: java.lang.NullPointerException
> >
> > at
> >
> > org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransp
> > ortFa
> > ctory.java:203) at
> > org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransp
> > ortFa
> > ctory.java:236) at
> > org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(Abs
> > tract
> > ConduitSelector.java:88) at
> > org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontCo
> > nduit
> > Selector.java:71) at
> > org.apache.cxf.endpoint.ClientImpl.getConduit(ClientImpl.java:842)
> > <local code stacktrace removed>
> >
> > At fault seems to be the dereferencing of a null AttributedURIType,
> > which previously was a String, at the very top of
> > SoapTransportFactory.java's getConduit override.
> >
> > The calling pattern that triggered it is as follows:
> >
> >
> > ((BindingProvider)port).getRequestContext().put("soap.env.ns.map",
> > topLevelNamespaces);
> > ((BindingProvider)port).getRequestContext().put(BindingProvider.ENDPOI
> > NT_AD
> > DRESS_PROPERTY, endpoint);
> >
> > // chunking interferes with NTLM
> > final HTTPClientPolicy httpClientPolicy = new
> > HTTPClientPolicy();
> > httpClientPolicy.setConnectionTimeout(HTTP_TIMEOUT_IN_MILLIS
> > ECONDS); httpClientPolicy.setAllowChunking(false);
> >
> > final Client client = ClientProxy.getClient(port);
> > final HTTPConduit httpConduit =
> >
> > (HTTPConduit)client.getConduit(); // triggers the stacktrace
> > httpConduit.setClient(httpClientPolicy);
> >
> > The code works well under 2.5.0 and a significant number of earlier
> > releases. Is there something I am forgetting to do to make sure said
> > Address component is never null (taking into account that the WSDL
> > does not declare the endpoint, it is dynamic configuration), or should
> > it go into JIRA?
> >
> > // Johan Karlberg
> >
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
RE: Regression in 2.5.1?
Posted by Johan Karlberg <jo...@ifsworld.com>.
Hi,
The port object is a thin adapter (only providing default values for a number of overly verbose operations exposed on the generated port) on top of a port type generated by wsdl2java, if you need the WSDL (around 8k lines) or generated client (around 500 files, at about 2MB worth of generated source that I thankfully do not have to poke in) it could be arranged, but I suspect it is not relevant.
The code requested is as follows:
final URL wsdlURL = ClassLoader.getSystemResource("services.wsdl");
final ExchangeWebService exchangeWebService = new ExchangeWebService(wsdlURL, new QName(
"http://schemas.microsoft.com/exchange/services/2006/messages", "ExchangeWebService"));
final ExchangeServicePortType port = exchangeWebService.getExchangeWebPort();
/*
setting these namespaces on the soap envelope
prevents them from being added separately to each new soap header.
*/
final ImmutableMap topLevelNamespaces = ImmutableMap
.of("m", "http://schemas.microsoft.com/exchange/services/2006/messages", "t",
"http://schemas.microsoft.com/exchange/services/2006/types");
The ExchangeServicePortType and ExchangeWebService are part of the generated client, and contain no magic or alterations on my part.
The BindingProvider.ENDPOINT_ADDRESS_PROPERTY is the only point at which my client provides an endpoint address to CXF. The WSDL for the service (the service type specifically, there is as previously mentioned a plethora of operations, messages and types defined) Is as barren as:
<wsdl:service name="ExchangeWebService">
<wsdl:port name="ExchangeWebPort" binding="tns:ExchangeServiceBinding">
</wsdl:port>
</wsdl:service>
The WSDL needs to be loaded from a local source as it needs significant modification from what Microsoft exports (on Exchange server 2007 SP1 in this particular case) in order for CXF to produce a working client.
The URL once deployed will likely end up looking something like "jar:file:/C:/installdir/product/lib/module.jar!/services.wsdl", which the JRE will have no problem with but perhaps CXF does.
// Johan Karlberg
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: den 3 januari 2012 23:00
To: users@cxf.apache.org
Cc: Johan Karlberg
Subject: Re: Regression in 2.5.1?
It should definitely go into JIRA. I can see the problem and have a fix for
it. However, can I also see the code you are using to create your "port"
object? I'm kind of surprised to see it's letting that be created without a
URL of some sort.
Dan
On Tuesday, January 03, 2012 11:55:09 AM Johan Karlberg wrote:
> I was forced to revert back to 2.5.0 after encountering the following:
> (partial stacktrace)
>
> < local code stacktrace removed >
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransp
> ortFa
> ctory.java:203) at
> org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransp
> ortFa
> ctory.java:236) at
> org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(Abs
> tract
> ConduitSelector.java:88) at
> org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontCo
> nduit
> Selector.java:71) at
> org.apache.cxf.endpoint.ClientImpl.getConduit(ClientImpl.java:842)
> <local code stacktrace removed>
>
> At fault seems to be the dereferencing of a null AttributedURIType,
> which previously was a String, at the very top of
> SoapTransportFactory.java's getConduit override.
>
> The calling pattern that triggered it is as follows:
>
>
> ((BindingProvider)port).getRequestContext().put("soap.env.ns.map",
> topLevelNamespaces);
> ((BindingProvider)port).getRequestContext().put(BindingProvider.ENDPOI
> NT_AD
> DRESS_PROPERTY, endpoint);
>
> // chunking interferes with NTLM
> final HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
> httpClientPolicy.setConnectionTimeout(HTTP_TIMEOUT_IN_MILLISECONDS);
> httpClientPolicy.setAllowChunking(false);
>
> final Client client = ClientProxy.getClient(port);
> final HTTPConduit httpConduit =
> (HTTPConduit)client.getConduit(); // triggers the stacktrace
> httpConduit.setClient(httpClientPolicy);
>
> The code works well under 2.5.0 and a significant number of earlier
> releases. Is there something I am forgetting to do to make sure said
> Address component is never null (taking into account that the WSDL
> does not declare the endpoint, it is dynamic configuration), or should
> it go into JIRA?
>
> // Johan Karlberg
>
>
> ----------------------------------------------------------------------
> ------
> --
>
> CONFIDENTIALITY AND DISCLAIMER NOTICE
>
> This e-mail, including any attachments, is confidential and for use
> only by the intended recipient. If you are not the intended recipient,
> please notify us immediately and delete this e-mail from your system.
> Any use or disclosure of the information contained herein is strictly
> prohibited. As internet communications are not secure, we do not
> accept legal responsibility for the contents of this message nor
> responsibility for any change made to this message after it was sent
> by the original sender. We advise you to carry out your own virus
> check as we cannot accept liability for damage resulting from software viruses.
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
------------------------------------------------------------------------------
CONFIDENTIALITY AND DISCLAIMER NOTICE
This e-mail, including any attachments, is confidential and for use only by
the intended recipient. If you are not the intended recipient, please notify
us immediately and delete this e-mail from your system. Any use or disclosure
of the information contained herein is strictly prohibited. As internet
communications are not secure, we do not accept legal responsibility for the
contents of this message nor responsibility for any change made to this
message after it was sent by the original sender. We advise you to carry out
your own virus check as we cannot accept liability for damage resulting from
software viruses.
Re: Regression in 2.5.1?
Posted by Daniel Kulp <dk...@apache.org>.
It should definitely go into JIRA. I can see the problem and have a fix for
it. However, can I also see the code you are using to create your "port"
object? I'm kind of surprised to see it's letting that be created without a
URL of some sort.
Dan
On Tuesday, January 03, 2012 11:55:09 AM Johan Karlberg wrote:
> I was forced to revert back to 2.5.0 after encountering the following:
> (partial stacktrace)
>
> < local code stacktrace removed >
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFa
> ctory.java:203) at
> org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFa
> ctory.java:236) at
> org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(Abstract
> ConduitSelector.java:88) at
> org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontConduit
> Selector.java:71) at
> org.apache.cxf.endpoint.ClientImpl.getConduit(ClientImpl.java:842) <local
> code stacktrace removed>
>
> At fault seems to be the dereferencing of a null AttributedURIType, which
> previously was a String, at the very top of SoapTransportFactory.java's
> getConduit override.
>
> The calling pattern that triggered it is as follows:
>
> ((BindingProvider)port).getRequestContext().put("soap.env.ns.map",
> topLevelNamespaces);
> ((BindingProvider)port).getRequestContext().put(BindingProvider.ENDPOINT_AD
> DRESS_PROPERTY, endpoint);
>
> // chunking interferes with NTLM
> final HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
> httpClientPolicy.setConnectionTimeout(HTTP_TIMEOUT_IN_MILLISECONDS);
> httpClientPolicy.setAllowChunking(false);
>
> final Client client = ClientProxy.getClient(port);
> final HTTPConduit httpConduit = (HTTPConduit)client.getConduit(); //
> triggers the stacktrace httpConduit.setClient(httpClientPolicy);
>
> The code works well under 2.5.0 and a significant number of earlier
> releases. Is there something I am forgetting to do to make sure said
> Address component is never null (taking into account that the WSDL does not
> declare the endpoint, it is dynamic configuration), or should it go into
> JIRA?
>
> // Johan Karlberg
>
>
> ----------------------------------------------------------------------------
> --
>
> CONFIDENTIALITY AND DISCLAIMER NOTICE
>
> This e-mail, including any attachments, is confidential and for use only by
> the intended recipient. If you are not the intended recipient, please notify
> us immediately and delete this e-mail from your system. Any use or
> disclosure of the information contained herein is strictly prohibited. As
> internet communications are not secure, we do not accept legal
> responsibility for the contents of this message nor responsibility for any
> change made to this message after it was sent by the original sender. We
> advise you to carry out your own virus check as we cannot accept liability
> for damage resulting from software viruses.
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com