You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Zarar Siddiqi <za...@gmail.com> on 2008/04/03 23:25:28 UTC
Parameters not being resolved - broken going from 2.0.3 -> 2.0.4 and still broken in 2.0.5
I had a very simple webservice running very nicely until I upgraded to
2.0.4.
I was using a Java-first service using an Aegis binding:
@WebService(targetNamespace="http://domain.com/PersonService")
public interface PersonService {
. . .
}
@Component
@WebService(serviceName="PersonService",
targetNamespace="http://domain.com/PersonService",
endpointInterface="PersonService")
public class PersonSoapService implements PersonService {
public Email getEmail(Credentials credentials) throws
WebServiceException {
// get email stuff
}
}
This was being called and working fine in 2.0.3 but since I upgraded to
2.0.4, the "credentials" parameter on the getEmail(..) method never gets
populated, it's always null. Always!
Any idea what the problem might be before I dive into CXF code?? Or maybe
you can tell me what interceptor it is that converts a soap message to the
actual parameters and I can dig deeper on my own.
Any help is appreciated.
Thanks,
Zarar
Re: Parameters not being resolved - broken going from 2.0.3 -> 2.0.4 and still broken in 2.0.5
Posted by Daniel Kulp <dk...@apache.org>.
One more note: the default for the simple frontend is to use QUALIFIED
schemas. Thus, if you are doing java first stuff and use JAX-WS on the
server and simple on the client, if you don't reconfigure one or the
other, you will have problems as the client will send qualified, but the
server will expect unqualified.
Dan
On Friday 04 April 2008, Daniel Kulp wrote:
> Most likely, it's an element qualification issue. In 2.0.4, we had
> to fix a bunch of issues with improper soap messages being
> produced/consumed due to elements that should have been qualified not
> being qualified and vice/versa. There were cases with <2.0.3 where a
> VALID soap message (according to the schema) would not be accepted,
> but the invalid message would be. Killed some interop scenarios
> pretty badly. 2.0.4 fixed a bunch of that to make sure the valid
> messages are produced/consumed.
>
> The thing to look at would be the raw soap message (use wireshark or
> the logging interceptors) to see the raw elements and compare that to
> the schema in the wsdl (from ?wsdl) to make sure they are consistent.
> Most likely, the ?wsdl will say elementFormDefault=unqualified, but
> the message is coming in qualified (or vice versa). (by default,
> schema generated for JAX-WS wrappers are unqualified)
>
> That said, in 2.0.4/5, if you are doing a "java first" case like you
> are, there are ways to control the generated schema to make it
> qualified. There are configuration options on the JaxWsServiceFactory
> (in spring) for that or you can just add a package-info.java to the
> package containing the interface with an appropriate filled in
> @XmlSchema thing. (Note: doing these would not be portable to other
> jaxws implementations)
>
>
> Dan
>
> On Thursday 03 April 2008, Zarar Siddiqi wrote:
> > I had a very simple webservice running very nicely until I upgraded
> > to 2.0.4.
> >
> > I was using a Java-first service using an Aegis binding:
> >
> > @WebService(targetNamespace="http://domain.com/PersonService")
> > public interface PersonService {
> > . . .
> > }
> >
> > @Component
> > @WebService(serviceName="PersonService",
> > targetNamespace="http://domain.com/PersonService",
> > endpointInterface="PersonService")
> >
> > public class PersonSoapService implements PersonService {
> > public Email getEmail(Credentials credentials) throws
> > WebServiceException {
> > // get email stuff
> > }
> > }
> >
> > This was being called and working fine in 2.0.3 but since I upgraded
> > to 2.0.4, the "credentials" parameter on the getEmail(..) method
> > never gets populated, it's always null. Always!
> >
> > Any idea what the problem might be before I dive into CXF code?? Or
> > maybe you can tell me what interceptor it is that converts a soap
> > message to the actual parameters and I can dig deeper on my own.
> >
> > Any help is appreciated.
> >
> > Thanks,
> > Zarar
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Parameters not being resolved - broken going from 2.0.3 -> 2.0.4 and still broken in 2.0.5
Posted by Zarar Siddiqi <za...@gmail.com>.
Thanks Dan, this was the problem. I was using JAX-WS and by default
the elementFormDefault for the service namespace was "unqualified".
Adding the package-info.java file with the following worked:
@XmlSchema(namespace = "http://domain.com/PersonService",
elementFormDefault= XmlNsForm.QUALIFIED)
package my.package;
import javax.xml.bind.annotation.XmlNsForm;
import javax.xml.bind.annotation.XmlSchema;
The service is working fine but my tests which previously worked are
still failing. I'm using the LocalTransportFactory and
AbstractCXFTest. The parameters are still not being resolved in the
test environment, I'm guessing the same unqualified/qualified
distinction needs to be made there, any idea how to do this? I'm
defining my test bean like this:
<bean id="localTransport"
class="org.apache.cxf.transport.local.LocalTransportFactory"
lazy-init="false">
<property name="transportIds">
<list>
<value>http://cxf.apache.org/transports/local</value>
<value>http://schemas.xmlsoap.org/soap/http</value>
<value>http://schemas.xmlsoap.org/wsdl/soap/http</value>
</list>
</property>
</bean>
<bean class="org.apache.cxf.frontend.ServerFactoryBean"
init-method="create">
<property name="serviceBean" ref="personSoapService"/>
<property name="serviceClass" value="my.package.PersonService"/>
<property name="address" value="local://PersonService"/>
<property name="dataBinding" ref="aegisBean"/>
<property name="transportId"
value="http://cxf.apache.org/transports/local"/>
</bean>
And later I modify the LocalTransportFactory to add some factories and such...
DestinationFactoryManager dfm = // get from bus
LocalTransportFactory localTransport = // get from spring context.
dfm.registerDestinationFactory("http://schemas.xmlsoap.org/soap/http",
localTransport);
dfm.registerDestinationFactory("http://schemas.xmlsoap.org/wsdl/soap/http",
localTransport);
dfm.registerDestinationFactory("http://cxf.apache.org/transports/local",
localTransport);
Any help is appreciated.
Thanks,
Zarar
On Fri, Apr 4, 2008 at 11:03 AM, Daniel Kulp <dk...@apache.org> wrote:
>
> Most likely, it's an element qualification issue. In 2.0.4, we had to
> fix a bunch of issues with improper soap messages being
> produced/consumed due to elements that should have been qualified not
> being qualified and vice/versa. There were cases with <2.0.3 where a
> VALID soap message (according to the schema) would not be accepted, but
> the invalid message would be. Killed some interop scenarios pretty
> badly. 2.0.4 fixed a bunch of that to make sure the valid messages are
> produced/consumed.
>
> The thing to look at would be the raw soap message (use wireshark or the
> logging interceptors) to see the raw elements and compare that to the
> schema in the wsdl (from ?wsdl) to make sure they are consistent. Most
> likely, the ?wsdl will say elementFormDefault=unqualified, but the
> message is coming in qualified (or vice versa). (by default, schema
> generated for JAX-WS wrappers are unqualified)
>
> That said, in 2.0.4/5, if you are doing a "java first" case like you are,
> there are ways to control the generated schema to make it qualified.
> There are configuration options on the JaxWsServiceFactory (in spring)
> for that or you can just add a package-info.java to the package
> containing the interface with an appropriate filled in @XmlSchema thing.
> (Note: doing these would not be portable to other jaxws implementations)
>
>
> Dan
>
>
>
>
> On Thursday 03 April 2008, Zarar Siddiqi wrote:
> > I had a very simple webservice running very nicely until I upgraded to
> > 2.0.4.
> >
> > I was using a Java-first service using an Aegis binding:
> >
> > @WebService(targetNamespace="http://domain.com/PersonService")
> > public interface PersonService {
> > . . .
> > }
> >
> > @Component
> > @WebService(serviceName="PersonService",
> > targetNamespace="http://domain.com/PersonService",
> > endpointInterface="PersonService")
> >
> > public class PersonSoapService implements PersonService {
> > public Email getEmail(Credentials credentials) throws
> > WebServiceException {
> > // get email stuff
> > }
> > }
> >
> > This was being called and working fine in 2.0.3 but since I upgraded
> > to 2.0.4, the "credentials" parameter on the getEmail(..) method never
> > gets populated, it's always null. Always!
> >
> > Any idea what the problem might be before I dive into CXF code?? Or
> > maybe you can tell me what interceptor it is that converts a soap
> > message to the actual parameters and I can dig deeper on my own.
> >
> > Any help is appreciated.
> >
> > Thanks,
> > Zarar
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer, IONA
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Parameters not being resolved - broken going from 2.0.3 -> 2.0.4 and still broken in 2.0.5
Posted by Daniel Kulp <dk...@apache.org>.
Most likely, it's an element qualification issue. In 2.0.4, we had to
fix a bunch of issues with improper soap messages being
produced/consumed due to elements that should have been qualified not
being qualified and vice/versa. There were cases with <2.0.3 where a
VALID soap message (according to the schema) would not be accepted, but
the invalid message would be. Killed some interop scenarios pretty
badly. 2.0.4 fixed a bunch of that to make sure the valid messages are
produced/consumed.
The thing to look at would be the raw soap message (use wireshark or the
logging interceptors) to see the raw elements and compare that to the
schema in the wsdl (from ?wsdl) to make sure they are consistent. Most
likely, the ?wsdl will say elementFormDefault=unqualified, but the
message is coming in qualified (or vice versa). (by default, schema
generated for JAX-WS wrappers are unqualified)
That said, in 2.0.4/5, if you are doing a "java first" case like you are,
there are ways to control the generated schema to make it qualified.
There are configuration options on the JaxWsServiceFactory (in spring)
for that or you can just add a package-info.java to the package
containing the interface with an appropriate filled in @XmlSchema thing.
(Note: doing these would not be portable to other jaxws implementations)
Dan
On Thursday 03 April 2008, Zarar Siddiqi wrote:
> I had a very simple webservice running very nicely until I upgraded to
> 2.0.4.
>
> I was using a Java-first service using an Aegis binding:
>
> @WebService(targetNamespace="http://domain.com/PersonService")
> public interface PersonService {
> . . .
> }
>
> @Component
> @WebService(serviceName="PersonService",
> targetNamespace="http://domain.com/PersonService",
> endpointInterface="PersonService")
>
> public class PersonSoapService implements PersonService {
> public Email getEmail(Credentials credentials) throws
> WebServiceException {
> // get email stuff
> }
> }
>
> This was being called and working fine in 2.0.3 but since I upgraded
> to 2.0.4, the "credentials" parameter on the getEmail(..) method never
> gets populated, it's always null. Always!
>
> Any idea what the problem might be before I dive into CXF code?? Or
> maybe you can tell me what interceptor it is that converts a soap
> message to the actual parameters and I can dig deeper on my own.
>
> Any help is appreciated.
>
> Thanks,
> Zarar
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog