java.lang.NoSuchMethodError using JOOQ - java

I was trying to use JOOQ in glassfish. I used code generator like this:
java -cp jOOQ-lib/jooq-3.3.1.jar:jOOQ-lib/jooq-meta-3.3.1.jar:jOOQ-lib/jooq-codegen-3.3.1.jar:mysql-connector-java-5.1.29-bin.jar:. org.jooq.util.GenerationTool /db.xml
Then imported the generated folder to my project.(I'm not using jooq maven plugin). When I deploy web app in glassfish I see this in server.log
[#|2014-04-06T14:53:37.720+0430|SEVERE|glassfish3.1.2|com.sun.xml.ws.server.sei.TieHandler|_ThreadID=670;_ThreadName=Thread-2;|org.jooq.impl.TableImpl.<init>(Ljava/lang/String;Lorg/jooq/Schema;Lorg/jooq/Table;[Lorg/jooq/Field;Ljava/lang/String;)V
java.lang.NoSuchMethodError: org.jooq.impl.TableImpl.<init>(Ljava/lang/String;Lorg/jooq/Schema;Lorg/jooq/Table;[Lorg/jooq/Field;Ljava/lang/String;)V
I have not changed any maven config just netbeans default config. maven artifact:
<dependency>
<groupId>org.jooq</groupId>
<artifactId>jooq</artifactId>
<version>3.3.1</version>
</dependency>
my db.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration>
<!-- Configure the database connection here -->
<jdbc>
<driver>com.mysql.jdbc.Driver</driver>
<url>jdbc:mysql://127.0.0.1/bulkdb?useUnicode=true</url>
<user>user</user>
<password>pass</password>
</jdbc>
<generator>
<database>
<name>org.jooq.util.mysql.MySQLDatabase</name>
<inputSchema>bulkdb</inputSchema>
<includes>.*</includes>
<excludes></excludes>
</database>
<target>
<packageName>bulkdb</packageName>
<directory>/home/user/jooq</directory>
</target>
</generator>
</configuration>
What is going wrong? Can someone help?
[UPDATE]
Actually there is two version of JOOQ in app server class path: one in lib directory of the domain(domain1/lib/) with version 3.1 and second one is 3.3.1 that is bundled in war file. Does this cause problems?

Actually there is two version of JOOQ in app server class path: one in lib directory of the domain(domain1/lib/) with version 3.1 and second one is 3.3.1 that is bundled in war file. Does this cause problems?
Yes, of course :-)
If you want to use both versions in parallel (do you really?), then you will probably need to resort to something like OSGi to be able to load the same class names in separate class loaders.
In your case, jOOQ 3.1 is loaded first by your application server, and thus jOOQ 3.3 cannot be loaded fully any more. The code generated with jOOQ 3.3 operates on new internal methods in TableImpl, which have been added in jOOQ 3.2 or 3.3, but since you're loading jOOQ 3.1, those methods aren't there. Note that this can happen with any external dependencies.
The solution here is really to remove jOOQ 3.1 from your application server.

Related

Maven lifecycle mapping

I have parent [project] pom which have the
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.4.0</version>
....
</plugin>
In subproject [childpom], I am getting this error on the first line
<?xml version="1.0" encoding="UTF-8"?>
Incompatible lifecycle mapping plugin version 1.4.0
jump to definition in parent pom.
Further env details:
IDE : Jboss jeveloper studio v9.0.0
JDK : java 8 64 bit.
MAVEN : apache-maven-3.3.3
I am new to maven, pls suggest me where I went wrong?
different eclipse depends different lots of locale jar files. so try use the relation version of the eclipse version.
you can find the version number from the installation folder. they should in features or plugins.
maybe is 1.6.2. you can try!

Generating Java classes from XSD maven dependency in maven with JAXB (or others)

I have a data model stored in the Maven repo as an XSD file. My goal is to create a jar with all the Java classes representing this model. I want to use maven and JAXB to do this.
I know about the maven-jaxb2-plugin (codehouse-mojo and java-net, not sure yet how they differ) but I don't see a way to use XSD from the maven dependency as an input. Do I have to write my own plugin to do this?
It doesn't have to be JAXB if there is a better tool to it.
Disclaimer: I'm the author of the maven-jaxb2-plugin.
Check the documentation, it's right there. See Specifying What To Compile - Specifying URLs, filesets and Maven artifact resources.
Example:
<configuration>
<schemas>
<!--
Compiles a schema which resides
in another Maven artifact.
-->
<schema>
<dependencyResource>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin-tests-po</artifactId>
<!-- Can be defined in project dependencies or dependency management -->
<version>${project.version}</version>
<resource>purchaseorder.xsd</resource>
</dependencyResource>
</schema>
</schemas>
</configuration>
You can also use catalogs to rewrite schema URLs to Maven artifact resources.
Example:
REWRITE_SYSTEM "http://schemas.opengis.net" "maven:org.jvnet.ogc:ogc-schemas:jar::!/ogc"
This will rewrite an URI http://schemas.opengis.net/ows/2.0/owsAll.xsd to maven:org.jvnet.ogc:ogc-schemas:jar::!/ogc/ows/2.0/owsAll.xsd. This will reference the ogc/ows/2.0/owsAll.xsd resource in ogc-schemas JAR artifact.
As far as I know, these features are unique to the maven-jaxb2-plugin.

Module not excluded on Wildfly

We want to exclude the modules\system\layers\base\javax\servlet\jstl\api\main\jboss-jstl-api_1.2_spec-1.1.2.Final.jar from our web application deployment (WAR file).
Hence we have the following configuration in src\main\webapp\WEB-INF\jboss-deployment-structure.xml:
<?xml version='1.0' encoding='UTF-8'?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclusions>
<module name="javax.servlet.jstl.api"/>
</exclusions>
<dependencies>
<module name="deployment.my-dependencies.jar"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
In the Wildfly log I see that my-dependencies.jar is added as a ModuleDependency. But when searching for javax.servlet.jstl.api I only see this:
2015-04-03 15:22:11,971 DEBUG [org.jboss.modules] (ServerService
Thread Pool -- 12) Module javax.servlet.jstl.api:main defined by local
module loader #1f7c9157 (finder: local module finder #2b29f6e7 (roots:
C:\Users\me\Documents\wildfly-8.2.0.Final\modules,C:\Users\me\Documents\wildfly-8.2.0.Final\modules\system\layers\base))
Why isn't the module excluded?
Update: It seems that modules that are part of a user dependency can not be excluded.
It seems like the mechanism doesn't work as described in the Wildfly documentation. I was not able to exclude that module.
Yep. I was trying to upgrade to Spring Framework to v4.3. It has upped some minimum dependency requirements. One such example is Jackson min version required is 2.6+
Wildfly loads jackson that comes packaged (v2.4.1 in Wildfly 8.2.1), and it won't be excluded using jboss-deployment-structure.xml.
I was trying to see if the upgrade did not involve making changes to the installed server which takes this upgrade out of source control.

Set JARs to skip in order to speed up Tomcat 7 maven plugin startup

Is there a simple way (e.g., directly from tomcat7-maven-plugin configuration) to specify which JARs should be skipped during Tomcat startup in order to speed it up?
The Tomcat 7 documentation encourages to use a system property org.apache.catalina.startup.ContextConfig.jarsToSkip (see http://wiki.apache.org/tomcat/HowTo/FasterStartUp#JAR_scanning), but when set from maven configuration, it does not work.
After inspecting the sources of tomcat7-maven-plugin, I found a workaround to achieve jars skipping. (It may however stop working with future releases of Maven Tomcat 7 plugin.)
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<configuration>
<path>/${project.artifactId}</path>
<port>8080</port>
<systemProperties>
<org.apache.catalina.startup.ContextConfig.jarsToSkip>*</org.apache.catalina.startup.ContextConfig.jarsToSkip>
<!-- work around .. see: https://issues.apache.org/jira/browse/MTOMCAT-281 -->
<catalina.config>${project.baseUri}/target/tomcat/logs</catalina.config>
</systemProperties>
</configuration>
</plugin>
As described in a related bug (https://issues.apache.org/jira/browse/MTOMCAT-281), the problem is that Tomcat blindly overrides all system properties with properties from tomcat-embed-core-7.0.47.jar!/org/apache/catalina/startup/catalina.properties. As a result, the value of org.apache.catalina.startup.ContextConfig.jarsToSkip system property specified in plugin configuration is overridden.

In EAR project EJBs appear twice when deployng

When I deploy EAR project, I noted that same EJBs appear twice - in WAR and JAR(EJB) modules. Where can be problem?
I build project using Maven. And didn't explicitly define any ejb-jar.xml.
In pom.xml of EJB project I added maven-ejb-plugin:
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.3</version>
<configuration>
<ejbVersion>3.0</ejbVersion>
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
<generateClient>true</generateClient>
<clientExcludes>
<clientExclude>**/core/</clientExclude>
<clientExclude>**/utils/</clientExclude>
</clientExcludes>
</configuration>
</plugin>
And from client I refer to generated EJB-client:
<dependency>
<groupId>orgstructure</groupId>
<artifactId>orgstructure-ejb</artifactId>
<version>1.0.4-SNAPSHOT</version>
<type>ejb-client</type>
<scope>compile</scope>
</dependency>
P.S. I deploy project to WebSphere 8.
UPDATE
Generated .ear file have standard layout:
-project.ear
--web-module.war
--ejb-module.jar
--lib
--META-INF
And generated applcation.xml:
<display-name>orgstructure-ear</display-name>
<module>
<web>
<web-uri>orgstructure-web-1.0.3.war</web-uri>
<context-root>/orgstructure</context-root>
</web>
</module>
<module>
<ejb>orgstructure-ejb-1.0.3.jar</ejb>
</module>
<library-directory>lib</library-directory>
Are you building (except for the EJB and web modules) a standalone Java application that is going to use your EJB? I'm guessing not, since you don't mention it anywhere.
If I'm guessing right, don't generate the EJB client. Remove the option
<generateClient>true</generateClient>
from your POM, and all configuration related to it.
An EJB client in this context means an application deployed outside the application server that wants to use your EJBs directly and therefore it needs a client jar to handle remote calls to the beans on the server.
If I'm guessing wrong, you still should not include a dependency to your a client jar in your web archive, Java EE web applications connect to EJBs using built-in app server mechanisms, not generated client stubs. In that case, remove the option
<type>ejb-client</type>
from your WAR's dependency.

Categories