I'm try to configure maven jetty plugin to start my war application, but it has some complications like as follow descriptions:
1º - It has dependencies with a ejb jar;
2º - It has dependencies with war (tag jstl:import context="nscl");
3º - The classloader between wars must be shareded.
So, I need some help to resolve the third problem. Looks my jetty plugin configuration in pom.xml:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.4.1.v20170120</version>
<configuration>
<useProvidedScope>true</useProvidedScope>
<useTestScope>true</useTestScope>
<webApp>
<contextPath>/nscl/cntr</contextPath>
</webApp>
<contextHandlers>
<contextHandler implementation="org.eclipse.jetty.maven.plugin.JettyWebAppContext">
<war>${contexto.war.path}</war>
<contextPath>/nscl</contextPath>
</contextHandler>
</contextHandlers>
<systemProperties>
<systemProperty>
<name>spring.profiles.active</name>
<value>test</value>
</systemProperty>
</systemProperties>
</configuration>
</plugin>
The problem is, when jetty is starting the second war (context-path = nscl), I receive problems saying the classes used to start first war not exist to second, a sample is classes of spring framework.
Thanks !!!!
You are hitting Standard Servlet Spec behavior.
Your WebApp's cannot share the same ClassLoader.
That is a fundamental part of being a Servlet Spec WebApp, the ClassLoader isolation.
Attempting to force it will just create mysterious problems with the ClassLoader hierarchy (InvalidClassChange errors, memory leaks, GC failures, etc)
Perhaps you can detail why you think you need this.
As there's likely already a standard way to accomplish it using the features of the Servlet spec (and not fighting it).
Related
I have successfully deployed alfresco community 4.2.f in a Tomcat 7.0.59 with a database MySQL5.6 and jdk1.8.0_141
No problems thus far, now, I got a module developed by our company which I need to be deployed in alfresco. This module invokes a WS which will send a PDF to some place.
I got this module in a jar compiled with jdk1.8.0_141
I tried to put it inside the alfresco.war before deployment in Tomcat in WEB-INF/lib but when I do that and deploy with startup.bat from Tomcat it pops in the console
instantiation of bean failed; nested exception is java.lang.NoClassDefFoundError: org/codehaus/xfire/XFireRuntimeException
I understand this exception is caused by putting the jar inside the war.
I was told that the jar was compiled also in jdk8.
Also, tell you that if instead of this jar I put inside the alfresco.war in WEB-INF/classes a properties file to get our database in deployment it works fine.
The problem is when I try to deploy the module.
I saw there are quite tutorials pointing to do something like:
java -jar bin/alfresco-mmt.jar
I can't do that because this is done installing alfresco with its wizard I assume. I did it deploying alfresco in a fresh tomcat installation.
Does anyone know how to deploy our module with the way we deployed alfresco? Thank you.
You have two ways to install your amp :
The first traditional one :
This is the one installed with the apply amp procédure (alfresco-mmt).
To me, this is not true that it is not compatible with your installation. You can easily find the bin folder (containing the alfresco-mmt.jar file) here in the alfresco packaging : https://download.alfresco.com/release/community/4.2.f-build-00012/alfresco-community-4.2.f.zip
When you have it, you can follow the documentation : http://docs.alfresco.com/4.2/tasks/amp-install.html
And apply your amp for example following this way :
java -jar alfresco-mmt.jar install <AMPFileLocation> <WARFileLocation>
The second one :
You can recreate the war with the alfresco sdk and include in the build the module you created.
If you follow this documentation : http://docs.alfresco.com/4.2/tasks/dev-extensions-maven-sdk-tutorials-all-in-one-archetype.html
the war produced in the target folder of the repo part will contain your module, since the pom of this module will contains a dependency to the amp module :
...
<dependencies>
<dependency>
<groupId>${alfresco.groupId}</groupId>
<artifactId>alfresco</artifactId>
<type>war</type>
</dependency>
<!-- Demonstrating the dependency on the repo AMP developed in the 'amp'
module -->
<dependency>
<groupId>x.y.z</groupId>
<artifactId>my-amp</artifactId>
<version>${my-amp.version}</version>
<type>amp</type>
</dependency>
</dependencies>
...
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<!-- Here is can control the order of overlay of your (WAR, AMP, etc.)
dependencies | NOTE: At least one WAR dependency must be uncompressed first
| NOTE: In order to have a dependency effectively added to the WAR you need
to | explicitly mention it in the overlay section. | NOTE: First-win resource
strategy is used by the WAR plugin -->
<overlays>
<!-- Current project customizations -->
<overlay />
<!-- The Alfresco WAR -->
<overlay>
<groupId>${alfresco.groupId}</groupId>
<artifactId>alfresco</artifactId>
<type>war</type>
<!-- To allow inclusion of META-INF -->
<excludes />
</overlay>
<!-- Add / order your AMPs here -
<overlay>
<groupId>x.y.z</groupId>
<artifactId>my-amp</artifactId>
<type>amp</type>
</overlay>
</overlays>
</configuration>
</plugin>
</plugins>
</build>
I am migrating EJB 3.0 application from jboss AS 6 to wildfly AS 8.
Is it possible to deploy EJB 3.0 application to wildfly as ease in wildfly? After updating the EJB spec as per wildfly EJB modules in pom.xml, I am getting compilation error that below symbols are not found as the related APIs are not available in wildfly.
org.jboss.ejb3.annotation.LocalBinding;
org.jboss.ejb3.annotation.Depends;
org.jboss.ejb3.annotation.Management;
org.jboss.ejb3.annotation.Service;
The above annotations are found in jboss-ejb3-ext-api.jar and it is a part of jBoss 6 AS.
javax.annotation.security.PermitAll
The above annotations are found in jboss-annotations-api_1.1_spec.jar and it is a part of jBoss 6 AS.
From the documentation, I understood that wildfly support EJB3.2 and EJB3.2 does not support #LocalBinding / #RemoteBinding.So how will I do the same in wildfly using standalone.xml / ejb-jar.xml / any other configuration.
I tried following the blog: JBoss: Binding values into JNDI in JBoss EAP 6 similar to JNDIBindingServiceMgr
but could not link where I tried to lookup EJB bean based on jndi name but did not work.
Please help. Many Thanks.
Annotate you bean interface with #Remote and or #Local.
Annotate you bean implementation with #Stateless.
Build the project with maven to generate EJB JAR and the client JAR (exclude your server implementation if it is used outside of your EAR).
<build>
<plugins>
<!-- maven-ejb-plugin -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<configuration>
<clientExcludes>
<clientExclude>**/ejb/*</clientExclude>
</clientExcludes>
</configuration>
</plugin>
</plugins>
</build>
Package the EJB in a EAR. (This is optional, but I deploy the web module as one .ear file).
To be able to know the JNDI Name of you EJB, Wildfly follow the standard naming convention.
`java:global///
For example ear has the name my-ear, ejb name my-ejbs and the bean interface a.b.c.MyBeanRemote and the implementation a.b.c.ejb.MyBean : Remote JNDI path will be java:global/my-ear/my-ejbs/MyBean or more verbose java:global/my-ear/my-ejbs/MyBean!a.b.c.MyBeanRemote.
To generate this structure of deployment I use the following configuration in my ear project:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
<version>7</version>
<applicationId>my-ear</applicationId>
<applicationName>my-ear</applicationName>
<defaultLibBundleDir>/lib</defaultLibBundleDir>
<jboss>
<version>5</version>
<unauthenticated-principal>guest</unauthenticated-principal>
<security-domain>ABC</security-domain>
</jboss>
<modules>
<webModule>
<groupId>a.b.c.my-group</groupId>
<artifactId>my-web-app</artifactId>
<uri>my-web-app.war</uri>
<contextRoot>/my-web-app</contextRoot>
</webModule>
<ejbModule>
<groupId>a.b.c.my-group</groupId>
<artifactId>my-ejbs</artifactId>
<uri>my-ejbs.jar</uri>
</ejbModule>
</modules>
</configuration>
</plugin>
</plugins>
</build>
<applicationName>my-ear</applicationName> will set the right name used by my application EAR (without the version).
<uri>my-ejbs.jar</uri> will remove the version of my ejb module, so it is not reflected in the JNDI path.
Hints: The JNDI name of your bean is printed in the log file when the EAR is deployed.
If you want to access the bean from outside the application server, you must use the JNDI path that begin with java:jboss/exported
I'm having trouble getting Eclipse to properly publish overlayed WARs locally to a weblogic server. Running a maven clean package correctly assembles the EAR with the proper webapp content imported. I've found several similar questions but none appear to be recent or the same issue.
Looking in my org.eclipse.wst.common.component file, the dependent-module for the overlay resource is correctly generated, as well.
I'm using m2e-wtp 1.0.1.20130911-1545
Is there additional configuration that I need to do to get the server publishing to read that overlay?
Editing with more info:
Here is the excerpt from the WARs pom.xml
<dependencies>
<dependency>
<groupId>com.abc</groupId>
<artifactId>core-webcontent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<overlays>
<overlay>
<groupId>com.abc</groupId>
<artifactId>core-webcontent</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
</plugins>
</build>
Here is the excerpt from the component file
<dependent-module deploy-path="/" handle="module:/overlay/prj/core-webcontent?includes=**/**&excludes=META-INF/MANIFEST.MF">
<dependency-type>consumes</dependency-type>
</dependent-module>
<dependent-module deploy-path="/" handle="module:/overlay/slf/?includes=**/**&excludes=META-INF/MANIFEST.MF">
<dependency-type>consumes</dependency-type>
</dependent-module>
I tried doing an export on the EAR locally so that I could view the EAR and see if the files are being added to a different location, but it seems that does not work at all from this type of setup.
I tried on JBoss AS 7.x/Wildfly 8.w without any problem. I downloaded Weblogic to try (I never used it) and I can confirm the behavior you see.
The problem is caused by Weblogic serving files directly from the workspace location. This is the same problem that prevents overlay from working for Tomcat's "Serve without publishing" mode. Basically the overlay components provided by m2e-wtp are ignored when serving the webapps directly from source.
JBoss Servers and Tomcat's default mode support overlays because the webapp is published to another location and served from there. That publishing step allows to add, then serve, the overlaid files.
The following changes allow Weblogic to do the same :
* in the servers view, remove the EAR from your weblogic server
* right-click on the weblogic server and open the Properties dialog
* Go to Weblogic > Publishing
* Select "Publish as an exploded archive" and press OK
* Re-deploy your EAR on the weblogic server
It should now be served from [workspace/path]/.metadata/.plugins/org.eclipse.core.resources/.projects/[earproject]/beadep/[domain]/[earproject]/
One thing I noted though, is changes from the overlaid project are not published immediately. You need to do some dummy change in the main webapp to see the overlay files be deployed.
at this point, if you want to see better support for overlays in weblogic tooling, you need to reach out to Oracle.
I have a rest endpoint used to return information about application (so far only app version)
But so far this info is hardcoded, and it's pretty easy to forget to change it.
I will be better to retrieve app version from pom or manifest file. Is there any project that brings such functionality?
Spring Boot can refer to the project version defined in pom.xml and expose it via REST using Actuator:
# application.properties
endpoints.info.enabled=true
info.app.version=#project.version#
Then accessing the /info URL (e.g. http://localhost:8080/info) will return:
{"app": {"version": "<major.minor.incremental>"}}
See also: spring boot/spring web app embedded version number
You better use build-in manifest.
new Manifest(Application.class.getResourceAsStream("/META-INF/manifest.mf"))
For the concrete impl-version:
new Manifest(Application.class.getResourceAsStream("/META-INF/manifest.mf"))
.getMainAttributes()
.get(Attributes.Name.IMPLEMENTATION_VERSION)
Using maven do not forget to create the manifest using:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
</project>
There is amazing project named Appinfo, please use it and enjoy! (It has an ugly page, I know - but it works :)
AppInfo allows to automatically feed your application with a current version number, build date or build number.
Also excellent Spring Boot Actuator provides feature named Info Endpoint which can publish version information to web or REST.
By default the Actuator adds an /info endpoint to the main server. It contains the commit and timestamp information from git.properties (if that file exists) and also any properties it finds in the environment with prefix "info".
You could use the resource filtering of maven or something like the maven-substitute-plugin.
Im using maven with tomcat7-maven plugin and its working quite well. Recently I noticed a message saying
At least one JAR was scanned for TLDs yet contained no TLDs.
Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them.
So I did some reasearch and realised I need to set the jarsToSkip property for the jars that dont contain TLDs. I have been looking into how to find which jars it is that is causing the problem but with little luck it seams tomcat7-maven-plugin is nott passing my loggersettings that are required for output of names of the jars.
Also I do not know where I set the jarsToSkip property when I have found the jars.
Any help would be appreciated.
Believe the property jarsToSkip is a "catalina.properties" entry. Where ever your Tomcat conf folder is look at file "catalina.properties" and you should see a property like this around line 90 or so:
tomcat.util.scan.DefaultJarScanner.jarsToSkip=\
You should be able to add jars to that list to prevent them from being scanned.
As far as finding which jars are causing the issues, that would be a little more difficult to determine. Probably some trial and error work to be done there.
When using the Tomcat 7 Maven Plugin, anything you would otherwise have put in catalina.properties can go in your plugin config. i.e.
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.0</version>
<configuration>
<useTestClasspath>true</useTestClasspath>
<path>/</path>
<systemProperties>
<tomcat.util.scan.DefaultJarScanner.jarsToSkip>
myjar.jar
</tomcat.util.scan.DefaultJarScanner.jarsToSkip>
</systemProperties>
</configuration>
</plugin>
There seems to be a bug with the maven tomcat plugin prior to 2.2 (ie 2.0) where the <systemProperties> don't seem to be propagated. Also in 2.2 a config option called<jarScanAllDirectories> was added which seems to improve performance even more (I think it ignores WEB-INF/classes).
Ignoring port and path I found the following configuration to greatly improve Maven Tomcat performance.
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<port>9090</port>
<path>/</path>
<jarScanAllDirectories>false</jarScanAllDirectories>
<systemProperties>
<org.apache.catalina.startup.ContextConfig.jarsToSkip>*.jar</org.apache.catalina.startup.ContextConfig.jarsToSkip>
<tomcat.util.scan.DefaultJarScanner.jarsToSkip>*.jar</tomcat.util.scan.DefaultJarScanner.jarsToSkip>
</systemProperties>
</configuration>
</plugin>
There is this open bug # https://github.com/psi-probe/psi-probe/issues/348
Just pointing out.