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.
Related
Migrating an existing project to maven and wildfly and had to move some files around creating the following situation.
core.jar
ejb1.jar
ejb2.jar
With the ejb-jar.xml for ejb1.jar having the following:
<ejb-jar>
<enterprise-beans>
<session id="Value">
..
<home>path.to.ejb1Home</home>
<remote>path.to.ejb1</remote>
...
The classes referenced in the home and remote tags have moved to be inside core.jar
Meanwhile ejb2.jar has dependencies on other parts of core.jar.
What looked like the easiest resolution was to create a global module and place core.jar in it, creating the appropriate module.xml and entry in standalone.sh to make it accessible to all deployments.
module.xml
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="path.to">
<resources>
<resource-root path="core-1.0.jar"/>
</resources>
<dependencies>
</dependencies>
</module>
With this setup, ejb2.jar deploys as expected but ejb1.jar throws the following error:
Caused by: java.lang.NoClassDefFoundError: Failed to link path.to.ejb1
(Module "path.to" from local module loader #4c40b76e (finder: local
module finder #2ea6137 (roots: /opt/wildfly/modules,
/opt/wildfly/modules/system/layers/base))): javax/ejb/EJBObject
You should carefully think about your requirement. Usually, you don't need to provide common resources, especially application interfaces, as module, especially as global module. Choose the right solution for your requirements, not a solutions that looks easy at first sight without knowing the implications.
I would recommend these possibilities in the order given (see the Class Loading in Wildfly Documentation for more information):
Reconsider your requirement for different EARs. Provide the core jar as library with your EAR.
Even with more than one EAR: provide the core.jar as library. This is no redundancy, this is just separation.
Consider not using a global module. Just install your custom module. Provide a jboss-deployment-structure.xml file, adding this module as additional dependency. If the module contains annotated classes or interfaces, which should be considered upon deployment, set the attribute annotations=true with the module dependency configuration.
Add a global module to your configuration file. Probably you can even use the `annotations' property, but this is something I don't know and I didn't check.
An example for the jboss-deployment-structure.xml file:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.3">
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<dependencies>
<module name="my.custom.module" export="true" annotations="true"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
EDIT:
When installing modules, don't forget to provide transitive module dependencies to other modules your own module depends on. User your module.xml file to do so. In your case, you probably need at least a dependency to the javax.ejb.api module.
am trying to deploy my java/spring based web application to google app engine using maven following below steps
1) In pom.xml added appengine-maven-plugin
<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>1.9.42</version>
<configuration>
<version>1</version>
<oauth2>false</oauth2>
</configuration>
</plugin>
2) added appengine-web.xml
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
<application>XXX-XXX-14807</application>
<version>1</version>
<threadsafe>true</threadsafe>
<env-variables>
<env-var name="env" value="prod" />
</env-variables>
</appengine-web-app>
3) deployed application using mvn appengine:update command
the application deployed successfully,welcome page getting displayed,but
services failing throwing errors like
"The requested URL XXX-XXX-14807.appspot.com/serach.do was not found on the server"(working in my local tomcat).
PS: not used google app engine eclipse plugin for deployment, trying to deploy java project from maven followed https://cloud.google.com/appengine/docs/java/tools/uploadinganapp.
do we need any other configuration?
This is what I would like to achieve:
1 ear-package: all.ear
The ear-package contains two war's (A.war, B.war in the root of the ear)
The ear-package contains 1 self-made jar C and a lot of third party jars (under APP-INF\lib)
This package needs to be deployed on JBoss WildFly 8.2.1
I'm using maven's ear plugin (maven-ear-plugin, version 2.10.1). My configuration in the pom looks like this (this is the 'parent'-project which combines three other projects):
<configuration>
<finalName>All</finalName>
<defaultLibBundleDir>APP-INF/lib</defaultLibBundleDir>
<includeLibInApplicationXml>true</includeLibInApplicationXml>
<version>6</version>
<displayName>All</displayName>
<modules>
<jarModule>
<groupId>project</groupId>
<artifactId>C</artifactId>
<bundleFileName>C.jar</bundleFileName>
<uri>APP-INF/lib/C.jar</uri>
<bundleDir>APP-INF/lib</bundleDir>
</jarModule>
<webModule>
<groupId>project</groupId>
<artifactId>A</artifactId>
<uri>A.war</uri>
<bundleFileName>A.war</bundleFileName>
<contextRoot>/a</contextRoot>
<bundleDir>/</bundleDir>
</webModule>
<webModule>
<groupId>project</groupId>
<artifactId>B</artifactId>
<uri>B.war</uri>
<bundleFileName>B.war</bundleFileName>
<contextRoot>/b</contextRoot>
<bundleDir>/</bundleDir>
</webModule>
</modules>
<archive>
<manifestEntries>
<Implementation-Version>1.0</Implementation-Version>
</manifestEntries>
</archive>
</configuration>
My META.INF/application.xml file loos like this:
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="6"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/application_6.xsd">
<display-name>All</display-name>
<initialize-in-order>true</initialize-in-order>
<module>
<java>APP-INF/lib/C.jar</java>
</module>
<module>
<web>
<web-uri>B.war</web-uri>
<context-root>b</context-root>
</web>
</module>
<module>
<web>
<web-uri>A.war</web-uri>
<context-root>a</context-root>
</web>
</module>
<library-directory>APP-INF/lib</library-directory>
</application>
The ear package is made. All third-party jars are under APP-INF/lib, but C.jar is in the root directory.
I have messed around a lot and got different errors when trying to upload the package to JBoss:
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS016703: Module may not be a child of the EAR's library directory. Library directory: APP-INF/lib, module file name: APP-INF/lib/[SomeThirthPartyLib].jar"
When I placed every library under root (don't use APP-INF), I've got a ClassNotFoundError for B.war (can't find the classes from C.jar).
I've already tried adding the 'jboss'-tags to the maven-ear-plugin (configuration), but those are not supported for JBoss 8+.
I want a .ear package which can be deployed in JBoss and contains 2 wars and 1 jar, which is referenced from both the wars.
What am I missing? (specific Manifest configuration? specific pom.xml settings for A, B or C? JBoss settings? ...?)
solution for the error "WFLYEE0097: Module may not be a child
of the EAR's library directory": the error is becuase of tag APP-INF/lib in application.xml. If library jars are inside EAR/lib then application.xml will work fine Since it is under EAR/APP-INF/lib, jboss or wildfly will not understand this(appication.xml) deployment descriptor. So use jboss-app.xml which wildfly understands even if the library directory is different. Solution : Simply copy complete content of application.xml to jboss-app.xml and place it META-INF folder (Also make sure to delete application.xml file or not making this get generated through pom.xml)
According to the JAVA EE specs, the container will not scan any deployment descriptors of any jar that is included in the library directory of the ear.
But what I presume you want to do is have access from the WARs to those ejb's you declared in C.jar. Again, according to specs, any ejb-jar sitting in an ear is visible to any other module:
Components in the web container may have access to the following classes and resources. Portable applications must not depend on having or not having access to these classes or resources.
•The classes and resources accessible to any other web modules included in the same ear file, as described above.
•The content of any EJB jar files included in the same ear file.
So, just put the C.jar anywhere else but in the lib directory and you're fine.
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.
When I published a war file for an application that works locally with Eclipse WTP, I had a FileNotFoundException for the bean.xml file with my beans definitions.
SEVERE: Exception sending context initialized event to listener instance of
class org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanDefinitionStoreException:
IOException parsing XML document from class path resource
[META-INF/spring/beans.xml]; nested exception is java.
io.FileNotFoundException: class path resource [META-INF/spring/beans.xml]
cannot be opened because it does not exist
at Caused by: java.io.FileNotFoundException: class path resource
[META-INF/spring/beans.xml] cannot be opened because it does not exist
...
I created the war file with mvn war:war and copied in the webapps folder of Tomcat 7.
beans.xml is located in src/main/resources/META-INF/spring/beans.xml and I've the following in my pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<webResources>
<resource>
<directory>src/main/resources</directory>
</resource>
</webResources>
</configuration>
</plugin>
In the war file beans.xml gets packaged in META-INF/spring/beans.xml
In my web.xml I've:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:META-INF/spring/beans.xml</param-value>
</context-param>
However the file is not found. How to solve the problem?
UPDATE: as Matthew Farwell suggested, is bean.xml is not packaged in the right location, so it's not in the class path, I think it's specified with maven-war-plugin parameters, now I try to look at its documentation. If someone knows it would be helpful.
UPDATE 2: As explained in maven-war-plugin documentation, there is an optional parameter called targetPath. I tried and after changing maven-war-plugin configuration adding targetPath it gets packaged correctly.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<webResources>
<resource>
<directory>src/main/resources</directory>
<targetPath>WEB-INF/classes</targetPath>
</resource>
</webResources>
</configuration>
</plugin>
UPDATE 3: About Ryan Stewart's suggestion, I started my initial pom setup using roo, but after that I've done many changes and I'm not using roo any more. The directory src/main/resources is not mentioned in any other places in pom.xml (I've used grep), however the only setting that looks suspicious to me is:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.5</version>
<configuration><encoding>UTF-8</encoding></configuration>
</plugin>
I've commented out that plugin, but nothing changed, then I commented out the configuration part of maven-war-plugin, but src/main/resources was not added to the war anymore, so for now I've added it back and I'm uploading it to test it online (it's still a staging server actually, not the final one anyway).
UPDATE 4 Ryan Stewart suggested that the problem was that I was running "mvn war:war" instead of "mvn package", and that was indeed the problem. With my targetPath, the resources appeared in WEB-INF/classes, but there weren't any classes there.
I was fighting an uphill battle, while instead the simpler solution was to remove the configuration part as in update 3, and use "mvn package" to build the war file. Thank you to both of you Ryan and Matthew, not only I solved my problem, but I've also learnt something more about Maven.
I have to assume you have another part of the POM that's excluding the file in question from being processed as a classpath resource, else it should be working. Either
Stop doing that, and it'll work fine--the content of src/main/resources becomes classpath resources by default--or
remove the classpath: from your path. Without that prefix, the path given in contextConfigLocation will be resolved against the root of the WAR file, and it will correctly find your file in META-INF/spring.
If you take path 1, then you should remove the webResources section, or you'll end up with the file in two places--not problematic, but potentially confusing.
In a war, / is not part of the classpath for a webapp. The classpath includes /WEB-INF/classes and all of the jars in /lib. See Apache Tomcat 6.0 - Class Loader HOW-TO
WebappX — A class loader is created for each web application that is
deployed in a single Tomcat instance. All unpacked classes and
resources in the /WEB-INF/classes directory of your web application,
plus classes and resources in JAR files under the /WEB-INF/lib
directory of your web application, are made visible to this web
application, but not to other ones.
The other web servers will have similar rules. If you wish to reference something as part of the classpath, put it in WEB-INF/classes.