You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2010/09/16 17:22:56 UTC

CXF versus Java builtins in 1.6

We've got some code that works fine with a JAX-WS client via wsdl2java
materials when run in isolation. Dropped into open office (don't ask), we
end up with an error and a non-CXF backtrace. Another JAR of ours included
in the classpath works fine. What possible pranks could OO be playing to
prevent CXF from setting up shop?

Re: CXF versus Java builtins in 1.6

Posted by Alessio Soldano <as...@redhat.com>.

  Might be something related to endorsing?

Alessio

On 09/16/2010 05:22 PM, Benson Margulies wrote:
> We've got some code that works fine with a JAX-WS client via wsdl2java
> materials when run in isolation. Dropped into open office (don't ask), we
> end up with an error and a non-CXF backtrace. Another JAR of ours included
> in the classpath works fine. What possible pranks could OO be playing to
> prevent CXF from setting up shop?
>


-- 
Alessio Soldano
Web Service Lead, JBoss

Re: CXF versus Java builtins in 1.6

Posted by Daniel Kulp <dk...@apache.org>.

On Thursday 16 September 2010 11:22:56 am Benson Margulies wrote:
> We've got some code that works fine with a JAX-WS client via wsdl2java
> materials when run in isolation. Dropped into open office (don't ask), we
> end up with an error and a non-CXF backtrace. Another JAR of ours included
> in the classpath works fine. What possible pranks could OO be playing to
> prevent CXF from setting up shop?

The only thing I can really think of is if they already have some ancient 
versions of some of our 3rd party jars on their classpath which is causing 
issues with us.   Or maybe one of our jars is newer and is being placed BEFORE 
theirs and that's causing some issues in things OO is trying to do.

Good luck.  :-)

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog