I run wsdl2java -u -uri on a wsdl file and java classes it generates throws error xxx must implement the inherited abstract method adbbean.getpullparser. I don't think I encountered this issue before.
Why is that?
That means that you are generating code with Axis2 1.7.x, but then try to build it with Axis2 1.6.x or earlier. As explained in the Axis2 1.7.0 release note, that is not supported.
Related
Getting this error when try to generate java classes from wsdl file.
WSDL File Path : https://files.developer.sabre.com/wsdl/sabreXML1.0.00/TDSServices/GetReservationRQ/GetReservation_1.19.16.wsdl
Using axis2 1.7.2 for generating classes
Command used to generate is axis2/bin/wsdl2java.sh -uri https://files.developer.sabre.com/wsdl/sabreXML1.0.00/TDSServices/GetReservationRQ/GetReservation_1.19.16.wsdl
ADB does not support multiple type , i.e ADB does not provide a way to represent mixed content in the generated Java classes, so it is not able to handle this type of schema.
After adding "mixed=false" problem is resolved for me.
Example
<complexType name="ObjectType" mixed="false">
I am trying to use ActiveMQ 5.10.0 with SoapUI 4.6 and Hermes 1.14. I get the error below when I try and add a queue. I presume Hermes can't find the type IdGenerator in any of the loaded jars. Which are:
activemq-client-5.10.0.jar
geronimo-j2ee-management_1.1_spec-1.0.1.jar
geronimo-jms_1.1_spec-1.1.1.jar
Does anyone know where this class is defined? I looked for activemq-util.jar in the binary distribution but I did not find such a file.
Error:
java.lang.NoClassDefFoundError: Could not initialize class org.apache.activemq.util.IdGenerator
at org.apache.activemq.ActiveMQConnectionFactory.getClientIdGenerator(ActiveMQConnectionFactory.java:969)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:363)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:331)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:303)
at org.apache.activemq.ActiveMQConnectionFactory.createQueueConnection(ActiveMQConnectionFactory.java:260)
at hermes.impl.jms.ConnectionManagerSupport.createConnection(ConnectionManagerSupport.java:147)
at hermes.impl.jms.ConnectionManagerSupport.createConnection(ConnectionManagerSupport.java:92)
at hermes.impl.jms.ConnectionSharedManager.reconnect(ConnectionSharedManager.java:81)
at hermes.impl.jms.ConnectionSharedManager.connect(ConnectionSharedManager.java:91)
at hermes.impl.jms.ConnectionSharedManager.getConnection(ConnectionSharedManager.java:104)
at hermes.impl.jms.ConnectionSharedManager.getObject(ConnectionSharedManager.java:142)
at hermes.impl.jms.ThreadLocalSessionManager.connect(ThreadLocalSessionManager.java:190)
at hermes.impl.jms.ThreadLocalSessionManager.getSession(ThreadLocalSessionManager.java:570)
at hermes.impl.jms.AbstractSessionManager.getDestination(AbstractSessionManager.java:460)
at hermes.impl.DefaultHermesImpl.getDestination(DefaultHermesImpl.java:367)
at hermes.browser.tasks.BrowseDestinationTask.invoke(BrowseDestinationTask.java:141)
at hermes.browser.tasks.TaskSupport.run(TaskSupport.java:175)
at hermes.browser.tasks.ThreadPool.run(ThreadPool.java:170)
at java.lang.Thread.run(Unknown Source)
This is very old but in case anyone else is trying to get this spun up... don't use the built in HermesJMS that comes with SoapUI. Apparently there's a bug in it that doesn't play nice with ActiveMQ v5.8 and following [I tried 5.11 & 5.13 and had the issue. The cheating fix is to install the standalone [I had to get it from sourceforge].
The sourceforge jar is installed with [assuming version 1.14]: java -jar hermes-installer-1.14.jar
Once installed you can tie this version to soapui or launch it with the bat/sh file. I still had issues with ActiveMQ version 5.13 but version 5.11 worked for me.
The IdGenerator class is located in the activemq-client jar. Here is the result of a search in the source tree:
/activemq-client/src/main/java/org/apache/activemq/util/IdGenerator.java
There's been no recent changes so I'd guess that the error is misleading and that it's actually some other missing dependency that's being loaded when the class is created. Is there more information in the log or a 'caused by exception' ?
For whom it may interest. This is kind of common issue I come accross from time to time. I call it jar version incompatibility. I was getting exception in title and other funny exceptions when using latest (but not actively developed) hermes 1.14 and currently latest Apache Active MQ 5.14. I've found out after a long struggle that it is fixed by using an older version of Active MQ - like 5.3.
Validation framework which has been rolled up as part of the JEE6 spec (WL12). Both the WL10 and WL12 versions of our application were deployed with the following open source libraries:
JSR-303 / validation-api.jar (version 1.0)
Hibernate Validator (version 4.2.0)
However, the libraries are also bundled with WL 12 (modules directory). Note that the Hibernate Validator version is slightly different.
modules.javax.validation_1.0.0.jar
hibernate.validator_4.1.0.jar
With our WL12 run we are getting below exception:
javax.validation.ValidationException: Unable to get available provider
Attempted Solutions
Our next attempt was to use the WebLogic FilteringClassLoader to prefer the libraries from our application (APP-INF/lib directory) by specifying them in the weblogic-application.xml file (i.e. choose our versions over WebLogic’s). We were already doing this for several other open source libraries in WL10:
<prefer-application-packages>
<package-name>com.google.common.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.apache.commons.logging.*</package-name>
<package-name>org.apache.commons.beanutils.*</package-name>
<package-name>org.apache.commons.collections.*</package-name>
<package-name>antlr.*</package-name>
<package-name>javax.validation.*</package-name>
<package-name>org.hibernate.validator.*</package-name>
</prefer-application-packages>
After making that change, our application experienced the following run-time error trying to process any request that makes use of the validation framework:
javax.validation.ValidationException: Unable to get available provider resolvers.
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:259)
at web20.hibernate.validation.ValidatorFactoryConfigurator.getValidatorFactory(ValidatorFactoryConfigurator.java:39)
at web20.hibernate.validation.ValidationHandlerImpl.handleHibernateValidations(ValidationHandlerImpl.java:180)
at web20.hibernate.validation.ValidationHandlerImpl.performValidation(ValidationHandlerImpl.java:255)
at web20.hibernate.validation.ValidationHandlerImpl.validateAndFormatMessages(ValidationHandlerImpl.java:302)
at web20.hibernate.validation.ValidationHandlerImpl.validateUsingHibernateGroups(ValidationHandlerImpl.java:113)
at service.serviceapp.performValidations(serviceapp.java:392)
at service.serviceapp.performValidations(serviceapp.java:379)
at service.TransactionalServiceImpl.search(TransactionalServiceImpl.java:300)
Given that Bean Validation is part of the EE standard, I assume there is some code Bean Validation integration code which causes the problem. I see two potential solutions:
Patch the WL instance and upgrade to the Validator version you want to use
Try writing your own ValidationProvider. Internally it could just delegate to the Hibernate Validator classes. If you then add a validation.xml to your application, specifying your custom provider, WL should bootstrap this one. TBH, I don't know whether this will work. There are many unknowns and I don't know enough about the integration of WL and Bean Validation.
Personally, I think I would just try to upgrade the Validator version used in WL.
I'm on TCL 8.5 (can't upgrade) and running version 2.7.7 of the HTTP package. I'm calling a library which appears to be using the following http::geturl command to download an image which has been gzipped:
http::geturl $url -headers {Accept-Encoding gzip}
and I'm getting this error:
invalid command name "zlib"
Searching on the web, I could only find this reference to the bug which basically recommends stopping sending Accept-Encoding gzip, which I can't do (nor can I upgrade to 8.6) http://sourceforge.net/p/tcl/bugs/4784/
My question is: is there any 8.5 workaround for this issue? Is there a way to stop this library from sending the "Accept-Encoding gzip" header?
The issue is that the code believes you've got the zlib package (which supplies the zlib command) available, and so turns on support for gzip-compressed streams. The simplest fix in your code is to do:
package require zlib
So long as this happens before you call into the code that does the http::geturl, this should be enough.
If you don't have the package (in which case you'll get a clear failure from the package require) then you've hit a bug either where the soft dependency code in the http package is getting it wrong when building the request headers, or in the server which is sending gzipped data despite not being asked for it. The code pointed to from TIP #234 (i.e., the SVN repository at http://svn.scheffers.net/zlib) contains the source for a version of the zlib package, in particular it's the version that formed the starting point for the built-in support in Tcl 8.6, but I think it only uses Tcl 8.5 APIs.
Unhelpfully, there are several versions of the zlib package around; this is one of the messiest Tcl packages to acquire, alas.
I am trying to test an axis2 service by creating a client using wsdltocode and using adb databinding.
While testing it I get the following error. qname not fond for the package: org.hibernate.collection. Not sure what it means.
Also, is it possible to step through the service code using a IDE debugger
The class had a List. Adding the list attribute to excludeProperties in services.xml fixed the problem.