You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by mlavwilson <ml...@yahoo.com> on 2008/11/20 19:23:19 UTC
The order of the Content-Type matters?
I have a service hosted in CXF.
Client A (java) makes a successful request. The header contains:
...
Content-Type: application/soap+xml; action="formats"; charset=utf-8
...
Client B (.net) makes fail's to make a request. The header contains:
...
Content-Type: application/soap+xml; charset=utf-8; action="formats"
...
The order is what is causing Client B to fail. Is this a issue with cxf or
the .net proxy code?
--
View this message in context: http://www.nabble.com/The-order-of-the-Content-Type-matters--tp20607230p20607230.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: wsdl2java tool limitation (package naming for JAXB entities + passing additional arguments to CJX)
Posted by "Rao, Sameer V" <SR...@amfam.com>.
Hi Dan,
The JAXB defect mentions only about -npa option. I am not sure if the
defect also applied for other parameters like -nv? I will run a testcase
to see if wsdl2Java support passing -nv.
Thanks,
Sam
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Thursday, December 18, 2008 1:08 PM
To: users@cxf.apache.org
Cc: Rao, Sameer V
Subject: Re: wsdl2java tool limitation (package naming for JAXB entities
+ passing additional arguments to CJX)
On Wednesday 17 December 2008 4:09:27 pm Rao, Sameer V wrote:
> CXF 2.1.3. I have two observation regarding the wsdl2java plugin-
>
> 1. In wsdl2java, for a JAXWS front-end usecase, the -p parameter
> (package name for service interface) also is getting passed to XJC, so
> Service interface and JAXB classes get generated in the same package.
Is
> that expected behaviour or is just a byproduct of the fact that both
XJC
> and wsdl2Java use -p as a argument for Package? Will it be possible
for
> wsdl2java to accept a separate parameter like
> "-bindgingpackage" that can be passed to XJC instead of the passing
the
> pacakge name of the service interface.
Personally, I'd like to deprecate/remove the -p option entirely. It's
too
easy to shoot yourself in the foot with it and produce code that won't
work.
Either that or require it to use the namespace=package flags to specify
a
unique package for each namespace. In general, I suggest using
binding
files.
> 2. wsdl2java has feature to only pass XJC plugins through the
wsdl2java
> but no way to pass "XJC arguments".
> e.g. -npa (this is to suppress the generated of
> package-info.java) , -nv.
Theres a bug in JAXB that prevent this from working:
https://jaxb.dev.java.net/issues/show_bug.cgi?id=576
> Is there any chance these could be implemented/supported in future
> release?
Please go vote on that issue. If the JAXB folks could fix that
problem, then
we could get them to work.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: wsdl2java tool limitation (package naming for JAXB entities + passing additional arguments to CJX)
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 17 December 2008 4:09:27 pm Rao, Sameer V wrote:
> CXF 2.1.3. I have two observation regarding the wsdl2java plugin-
>
> 1. In wsdl2java, for a JAXWS front-end usecase, the -p parameter
> (package name for service interface) also is getting passed to XJC, so
> Service interface and JAXB classes get generated in the same package. Is
> that expected behaviour or is just a byproduct of the fact that both XJC
> and wsdl2Java use -p as a argument for Package? Will it be possible for
> wsdl2java to accept a separate parameter like
> "-bindgingpackage" that can be passed to XJC instead of the passing the
> pacakge name of the service interface.
Personally, I'd like to deprecate/remove the -p option entirely. It's too
easy to shoot yourself in the foot with it and produce code that won't work.
Either that or require it to use the namespace=package flags to specify a
unique package for each namespace. In general, I suggest using binding
files.
> 2. wsdl2java has feature to only pass XJC plugins through the wsdl2java
> but no way to pass "XJC arguments".
> e.g. -npa (this is to suppress the generated of
> package-info.java) , -nv.
Theres a bug in JAXB that prevent this from working:
https://jaxb.dev.java.net/issues/show_bug.cgi?id=576
> Is there any chance these could be implemented/supported in future
> release?
Please go vote on that issue. If the JAXB folks could fix that problem, then
we could get them to work.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
wsdl2java tool limitation (package naming for JAXB entities + passing additional arguments to CJX)
Posted by "Rao, Sameer V" <SR...@amfam.com>.
CXF 2.1.3. I have two observation regarding the wsdl2java plugin-
1. In wsdl2java, for a JAXWS front-end usecase, the -p parameter
(package name for service interface) also is getting passed to XJC, so
Service interface and JAXB classes get generated in the same package. Is
that expected behaviour or is just a byproduct of the fact that both XJC
and wsdl2Java use -p as a argument for Package? Will it be possible for
wsdl2java to accept a separate parameter like
"-bindgingpackage" that can be passed to XJC instead of the passing the
pacakge name of the service interface.
2. wsdl2java has feature to only pass XJC plugins through the wsdl2java
but no way to pass "XJC arguments".
e.g. -npa (this is to suppress the generated of
package-info.java) , -nv.
Is there any chance these could be implemented/supported in future
release?
Re: The order of the Content-Type matters?
Posted by Daniel Kulp <dk...@apache.org>.
I just changed the CXF clients to send them in the other way and everything
passed. Thus, I don't think the order is the nature of the problem. Is
there any stack traces or other errors printed in the server side log?
Dan
On Monday 24 November 2008 4:04:54 pm mlavwilson wrote:
> I have upgraded to cxf-2.0.9 and the problem still exists. Has anyone used
> CXF to host a service that is being called by a .NET proxy class?
>
> mlavwilson wrote:
> > I have a service hosted in CXF.
> >
> > Client A (java) makes a successful request. The header contains:
> > ...
> > Content-Type: application/soap+xml; action="formats"; charset=utf-8
> > ...
> >
> >
> > Client B (.net) makes fail's to make a request. The header contains:
> > ...
> > Content-Type: application/soap+xml; charset=utf-8; action="formats"
> > ...
> >
> > The order is what is causing Client B to fail. Is this a issue with cxf
> > or the .net proxy code?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: The order of the Content-Type matters?
Posted by mlavwilson <ml...@yahoo.com>.
I have upgraded to cxf-2.0.9 and the problem still exists. Has anyone used
CXF to host a service that is being called by a .NET proxy class?
mlavwilson wrote:
>
> I have a service hosted in CXF.
>
> Client A (java) makes a successful request. The header contains:
> ...
> Content-Type: application/soap+xml; action="formats"; charset=utf-8
> ...
>
>
> Client B (.net) makes fail's to make a request. The header contains:
> ...
> Content-Type: application/soap+xml; charset=utf-8; action="formats"
> ...
>
> The order is what is causing Client B to fail. Is this a issue with cxf
> or the .net proxy code?
>
--
View this message in context: http://www.nabble.com/The-order-of-the-Content-Type-matters--tp20607230p20669829.html
Sent from the cxf-user mailing list archive at Nabble.com.