If you don't mind I'd like to move this dicussion to the dev list.
Just thinking out loud... the Fediz IDP should become an application but might
still require to deploy the WAR into your favorite servlet container.
When the new feature (FEDIZ-3) is completed we're close for 1.1.0 release. But
Thanks for the reply.
What I've seen in last test is that moving the GenCmdDescr class in the same
package with IModel interface the exception doesn't occurs anymore.
But I am not clear what can be the reason: also the other package was visible
and loading the ws as soap there aren't problems;
On 08/05/13 10:18, eanbiso wrote:
Thanks for the reply.
What I've seen in last test is that moving the GenCmdDescr class in the same
package with IModel interface the exception doesn't occurs anymore.
But I am not clear what can be the reason: also the other package was visible
and loading the
Ok, I've found the problem.
I was using cxf (version 2.5.0) like an imported Project with its MANIFEST.MF
file.
In the MANIFEST.MF I have added, under the DynamicImport-Package:
section, the packages containing the classes that generated the exception
NoClassDefFoundError during the
Glen, the last example does not work because the 3rd test expects the
exception message contain the name of exception class removed from CXF
2.7.x, instead of CXF specific ClientWebApplicationException a JAX-RS
m10 ClientException is returned. Note, in the latest 2.0 API that will
become
Hi,
To make it work I installed jboss-ep-ws-cxf-5.1.0 installer and downgrade
the cxf version to 2.2.12-patch02.
Now as per our undersatnding we need not to include cxf related jars in EAR
deployment So I removed these jars from my EAR and deployed to jboss but on
deployment its giving error as
Hi
Redirecting to the users list,
Thanks for reporting the issue
This NPE has been fixed starting from CXF 2.7.4, or, without the update:
remove WS-Discovery libs from the CXF distro
Please update and give it a try
Thanks, Sergey
On 08/05/13 16:09, ced_benoit wrote:
Hi,
I wanted a
Dan, as you suggested, I put various break points in
org.apache.cxf.configuration.spring.ConfigurerImpl. What I discovered is
that if I put my cxf HTTPConduit definitions in the main spring
configuration, when configureBean() is called the application context is in
a different bundle than
Giving this a bump.
--
View this message in context:
http://cxf.547215.n5.nabble.com/Customize-JAXB-unmarshalling-error-messages-tp5727021p5727446.html
Sent from the cxf-user mailing list archive at Nabble.com.
