I'm using CXF WSDL2Java (using JAXB to generate Java classes). I now have everything generating my classes fine, but I get INFO messages of the form;
Jun 15, 2016 4:39:16 PM org.apache.cxf.wsdl11.WSDLServiceBuilder checkForWrapped
INFO: Operation <--my operation--> cannot be unwrapped, its wsdl:part/#element reference must match xs:complexType/xs:sequence.
I understand why it can't be unwrapped and don't have the option to "fix" the WSDL, it's already in use as is.
I'd like to pass something in so that I don't see these INFO messages during my build, as it just creates noise for something that's really OK.
How can I run WSDL2Java to avoid this message?
Related
I am creating a SOAP client that runs in a Java 11 Spring Boot server and makes requests to a Java 8 server. I'm using cxf-rt-frontend-jaxws:3.4.3 and cxf-rt-transports:3.4.3 in a Gradle 6.9 build with the com.github.bjornvester.wsdl2java Gradle plugin version 1.1.
My client can call a simple echo test SOAP operation with no problem. That service passes a request object containing a single String and gets a response object containing the String. So I know the basic connection is working and the other end is responding.
My problem arises when I call an operation that has no input and returns a list of objects in the response. I get this error:
org.apache.cxf.interceptor.Fault: Unmarshalling Error: unexpected element (uri:"", local:"ProposalInfo"). Expected elements are <{http://V2.pub.proposal.server.ws.cayuse.com/}ProposalInfo>
I am told that other systems call these operations with no problem.
I have stepped through the cxf and JAXB code and notice that the IntelliJ shows this text associated with a BranchingReaderSource. Not sure if this is a true error or just a side-effect of the debugger trying to call toString() on this class (which has no such method).
Method threw 'java.lang.NullPointerException' exception. Cannot evaluate com.ctc.wstx.io.BranchingReaderSource.toString()
I also notice that a class called ValidationEventLocatorImpl gets a NullPointerException on this line because "toURL" is null. I think this is because toURL comes from the empty prefix of in the response.
this.url = toURL(loc.getSystemId());
I have tried using wrapping-style "false" but that does not change anything.
I also tried to use TransformInInterceptor to map elements with no prefix to the desired prefix, but that did not work. It seems the unmarshalling error gets thrown before the interceptor runs.
Here is the WSDL used for this service; the operation that I am calling is getUnpairedProposals. I also attach a copy of the response to this operation -- the operation that is not getting unmarshalled properly. My reading of this response is that the namespace defined on the ns2:getUnPairedProposalsResponse tag should apply to the child elements such as .
Additional info:
I made several attempts to use TransformInterceptor to map the elements:
Added a map entry for "getUnPairedProposalsResponse -> {http://V2.pub.proposal.server.ws.cayuse.com/}getUnPairedProposalsResponse". This did nothing.
Inserted the TransformInterceptor at Phase.PRE_STREAM. Also had no effect.
Changed the mapping from #1 to the same but added a prefix {}, as in {}getUnPairedProposalsResponse -> {http://V2.pub.proposal.server.ws.cayuse.com/}getUnPairedProposalsResponse. This got me a null pointer exception in cxf at TransformUtils line 128 in the convertToQnamesMap method.
We are getting following below error when we deploy any application in Liferay DXP 7.
When we clean the Liferay DXP and then redeploy the below issue gets fixed.
But the problem with this approach is that all the caches gets deleted after cleaning and when we redeploy and access the site , the caches gets recreated but it takes lot of time to access any page on the site.
[2018-05-17 10:58:33,113] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.service.common.ProgramFilterPopulator] - Retrieving logged in user
[2018-05-17 10:58:33,137] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Portlet mode view and debug mode = false
[2018-05-17 10:58:33,137] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Checking to see if invalid filter view should be shown
[2018-05-17 11:07:40,859] [DEBUG] [] [] [http-nio-5443-exec-2] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Entering
[2018-05-17 11:07:40,859] [WARN] [] [] [http-nio-5443-exec-2] [org.springframework.web.portlet.DispatcherPortlet] - Handler execution resulted in exception - forwarding to resolved error view
java.lang.ClassCastException: com.fsvps.clientPortal.domain.common.UserContext cannot be cast to com.fsvps.clientPortal.domain.common.UserContext
at com.fsvps.clientPortal.domain.common.UserContext$$FastClassBySpringCGLIB$$818d2483.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:738)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:133)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:121)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:673)
at com.fsvps.clientPortal.domain.common.UserContext$$EnhancerBySpringCGLIB$$830ac420.setIpAddress(<generated>)
at com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor.preHandle(UserContextInitializationInterceptor.java:93)
at org.springframework.web.portlet.handler.HandlerInterceptorAdapter.preHandleRender(HandlerInterceptorAdapter.java:72)
at org.springframework.web.portlet.DispatcherPortlet.doRenderService(DispatcherPortlet.java:739)
at org.springframework.web.portlet.FrameworkPortlet.processRequest(FrameworkPortlet.java:537)
The exact cause is impossible to pinpoint with the information you give. However, the class of problem is easy to identify:
java.lang.ClassCastException:
com.fsvps.clientPortal.domain.common.UserContext cannot be cast to
com.fsvps.clientPortal.domain.common.UserContext
(separated to lines to illustrate the identical class name)
Whenever a class can't be typecasted to itself or a legitimate superclass/interface, you're dealing with duplicate code: There are two versions of the class with the same name available to the classloader, and the system is choosing both.
As the error message just contains the name of the class, not its classloader, a first glance at the error message doesn't make sense. Knowing that a class is uniquely described by its package, name, and its classloader leads you to the root cause.
Identify your modules and make sure that there's only one option for com.fsvps.clientPortal.domain.common.UserContext available.
Edit: Answering to your comments - without knowing your deployment details, there's no way to help you other than wild guesses. Please add more information to your question if the next wild guess doesn't help:
The name of the class, UserContext, suggests that you might store it somewhere, e.g. in a session. Doing so will prevent the original class from unloading when you're undeploying your plugin. Note that there is a huge difference between undeploying code and garbage collecting objects: GC can only happen, when there is no more reference.
If you deploy an updated version of your plugin, the old and existing objects still are referencing the previously loaded UserContext class, while the new code is trying to assign it to a new UserContext reference. Even though, both might be identical in implementation, they are different classes that just share the name.
You can't keep long living references to code that might undeploy, and expect them to stay usable. A quick fix (if you're deploying OSGi modules) might be to extract stable and long-used classes into its own bundle that you won't redeploy. Or replace session stored objects (assuming that this is it) with Java runtime classes, e.g. Map of built-in types, and build a UserContext object from those types whenever you need it.
At https://stackoverflow.com/a/35443723/1031689
setting the system property com.ibm.xml.xlxp.jaxb.opti.level=0 in
WebSphere. Using this setting will cause the JAXB reference
implemenation to be used for unmarshalling and marshalling instead of
the WebSphere JAXB implementation.
I set this at Application servers > server1 > Process definition > Java Virtual Machine > Custom properties in WebSphere 9.0.0.4,then stopped and restarted the server, and in my webapp:
System.getProperty("com.ibm.xml.xlxp.jaxb.opti.level")
now returns 0, as expected.
However,
context.getClass().getName().startsWith("com.ibm.xml.xlxp2.jaxb")
still returns true.
and
Marshaller m=org.docx4j.jaxb.Context.jc.createMarshaller();
System.out.println(m.getClass().getName());
returns:
com.ibm.xml.xlxp2.jaxb.marshal.MarshallerProxy
(actually, that returns MarshallerProxy irrespective of whether com.ibm.xml.xlxp.jaxb.opti.level is set or not)
When level=0, does MarshallerProxy invoke the reference implementation? Is that how it works?
Answer: only if it can't load com.ibm.jtc.jax.xml.bind.v2.runtime.JAXBContextImpl (which is in com.ibm.jaxb.tools.jar)
To see this, invoking toString() on your context object is useful:
Primary JAXBContext:
bundleresource://138.fwk797973828/com/ibm/xml/xlxp2/jaxb/JAXBContextImpl.class,
Version: 1.6.2-jaxb,
Timestamp: Tue, 18 Oct 2016 17:08:48 EDT,
Classes known to this context:
[NONE] (Fallback JAXBContext will be used to process any requests.)
Fallback JAXBContext:
bundleresource://11.fwk797973828/com/ibm/jtc/jax/xml/bind/v2/runtime/JAXBContextImpl.class Build-Id: null
So XLXP uses com.ibm.jtc.jax.xml.bind.v2.runtime.JAXBContextImpl.
Now, with com.ibm.xml.xlxp.jaxb.opti.level=0 set:
Primary JAXBContext:
bundleresource://138.fwk-1179731101/com/ibm/xml/xlxp2/jaxb/JAXBContextImpl.class,
Version: 1.6.2-jaxb,
Timestamp: Tue, 18 Oct 2016 17:08:48 EDT,
Classes known to this context:
[NONE] (Fallback JAXBContext will be used to process any requests.)
Fallback JAXBContext:
bundleresource://11.fwk-1179731101/com/ibm/jtc/jax/xml/bind/v2/runtime/JAXBContextImpl.class Build-Id: null
That is, no change! IBM JAXB is still being used.
Two ways to try to change that:
com.ibm.ws.prereq.xlxp.jar/META-INF/services/com.ibm.xml.xlxp.jaxb.fallback.context contains com.ibm.jtc.jax.xml.bind.v2.ContextFactory; we could put something else in there
remove com.ibm.jaxb.tools.jar
I tried removing com.ibm.jaxb.tools.jar. After restarting WAS:
Primary JAXBContext:
bundleresource://138.fwk-218185936/com/ibm/xml/xlxp2/jaxb/JAXBContextImpl.class,
Version: 1.6.2-jaxb,
Timestamp: Tue, 18 Oct 2016 17:08:48 EDT,
Classes known to this context:
[NONE] (Fallback JAXBContext will be used to process any requests.)
Fallback JAXBContext:
jar:file:/home/jharrop/IBM/WebSphere/AppServer/java/8.0/jre/lib/rt.jar!/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.class Build-Id: 1.8.0
So interestingly, if you remove com.ibm.jaxb.tools.jar, com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl is there (at least in my installation) and used! So I guess you could instead specify it in com.ibm.ws.prereq.xlxp.jar/META-INF/services/com.ibm.xml.xlxp.jaxb.fallback.context
If you do play around with removing com.ibm.jaxb.tools.jar, when you add it back in, remember to clear the class cache so WAS finds it again (stop the server, run bin/clearClassCache): http://www-01.ibm.com/support/docview.wss?uid=swg21607887
WebSphere 8.5.5.13 (using IBM Java 1.8.0_151 - what a pain to install!) seems similar.
I recently changed my domain objects from LocalDate to ZonedDateTime. I also created a brand new play JHipster application and one play entity choosing ZonedDateTime for two class members. The test application (new) works while my existing application does not, even after going through all the code twice. I loaded CSV data using Liquibase and my listing code shows the dates properly. Here's what the data looks like in my Maven output, e.g. entrydate='2017-02-23T19:53:18-05:00[America/New_York]', transaction='Initial Balance',
When I choose to update the date-time value with the "datetime-picker" in the dialog.html, a string date time is shown in the text box but when I push "Save" I get an "Internal Server Error" and the Maven output shows:
.HttpMessageNotReadableException: Could not read document: Text '2017-02- 26T00:53:18.000Z' could not be parsed at index 23 (through reference chain: org.ciwise.blackhole.domain.GenLedger["entrydate"]); nested exception is com.fasterxml.jackson.databind.JsonMappingException: Text '2017-02-26T00:53:18.000Z' could not be parsed at index 23 (through reference chain: org.ciwise.blackhole.domain.GenLedger["entrydate"])]
Does anyone have an idea why the picker would produce String text in the text box that isn't acceptable when the HTTP PUT occurs (edit)?
My application does use Service classes but they handle the same Java domain objects as the JPA Repository classes do.
One more thing, the schema for the API shows e.g. "entrydate": "2017-02-23T21:44:04.859Z", but the actual JSON return is "entrydate": "2017-02-23T19:53:18.000-0500",
I'm hoping someone else has encountered this before.
Thanks
David
The answer here was to re-introduce application.yml. Inside this file it defines some Spring profiles but of most importance, it provides an option for Jackson serialization into JSON e.g.
jackson:
serialization.write_dates_as_timestamps: false
This resolved my issue.
I am not sure whether it is relevant but We are using in our system axis2 and JAXB for xml parsing and soap for communication(On tomcat).
Everything works well, however, I receive in my logs the following debug message repeatedly after each incoming message and I am not sure whether we are missing something.
2013-01-30 23:41:44,727 [http-8081-1] DEBUG org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl - Could not close builder or parser due to:
2013-01-30 23:41:44,727 [http-8081-1] DEBUG org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl - builder is null
Does it make sense to anyone ? Was I supposed somehow to initialize the builder to configure it ?
Thanks
This is not an error, but a debug message. In can be safely ignored.