Skinny war and log4j - maven

We are using log4j for application logging and maven for application packaging.
As we have 3-4 application being deployed as a part of an EAR the size of the EAR is large.
We were trying to go with the 'Skinny War's' approach but faced a problem with log4j. We used to log application logs in different file for each application but with Skinny WAR's as the classes of log4j are being loaded only once, only one log file is being created and log of each application is being appended to the same log file.
We thought of the famous solution of packaging log4j.jar in each WAR but then we'll have to move every jar file which needs the log4j in WAR ex. spring jar's this essentially will increase the EAR size.
Is there any alternate solution to this problem ?
Any suggestion would be a great help.
Thanks.

Resolved the issue with RepositorySelectors.
Check this

see if log4j 1.3 / log4j2 helps you fix the init - google ContextJNDISelector
http://logging.apache.org/log4j/2.x/manual/webapp.html
To compare
logback - JoranConfigurator it does exactly that, custom context based config
http://logback.qos.ch/manual/configuration.html

Related

IntelliJ : how to verify log4j2.xml is on the classpath?

I'm working on a spring boot/maven project that I created with SpringIntializr. If I add all the necessary dependencies to my pom, and if I add my log4j2.xml to MyApp/src/main/resources,
and if after a build I see my log4j2.xml file in MyApp/target/classes, does that mean that the log4j config has been successfully added to the classpath?
I asked a more comprehensive question here, but thought this issue might merit a standalone question
Basically yes, what gets to the classes, later on, gets handled by the spring-boot maven plugin and should be available in the artifact that you build.
At this point it doesn't really matter whether it was originally in the src/main/resources folder or not.
Having said that, log4j2 is not used by spring boot by default (it uses logback), so you should set it up
For such a setup see this example

Spring Boot Migration Issue on Packaging JAR and WAR using Maven

We are trying to migrate our existing Spring MVC applications to Spring Boot application. Our existing applications are using 3.2.9, so tons of XML configurations. All the beans are defined in the XML files. What we have done is first we have upgraded our existing applications to Spring 4.2.5 version since Spring Boot will work only with Spring 4 versions.
Our requirement is to have both FAT JARs and WAR files from the build. Most of our existing customers would prefer Application Server deployment, so we have to create WAR file for them. Also for our internal testing and new deployments, we are planning to use FAT JARs.
How can we achieve them in the Maven file, we are able to provide separately as below. Is there any maven plug-in to generate both in single build?
<packaging>jar</packaging>
or
<packaging>war</packaging>
We are publishing our artifacts into Nexus repository. So, we want to have the separate repository location for JAR files and WAR files. Can we do that using the single pom.xml file?
Also another question, we have all the XML configurations under WEB-INF folder. When we are moving to the Spring Boot application, it has to be under the resources folder. How can we handle them easily. When we build FAT jars, the resources are not looked under WEB-INF because it simply ignores the webapp project.
I am looking forward for some guidance to complete the migration. Infact, we have already done that changes and it is working fine, but we are confused on this WAR / JAR generations.
Update:
I have got another question in mind, if we are converting our existing applications to spring boot, do we still have to maintain WEB-INF folder in the web-app or can move everything to the resources folder?. While building the WAR file, whether spring boot takes care of moving the resources to WEB-INF? How spring boot would manage to create the WAR file if you are putting all the resources under the resources folder.
Building WAR and FAT JAR is very easy with Gradle.
With Maven, I would try multi module setup, where one sub-module will build fat JAR and second will build WAR file.
Application logic can be as third sub-module and thus being standalone JAR with Spring configuration and beans. This application logic JAR would be as dependency for fat JAR and WAR module.
WAR specific configuration can be placed in Maven WAR sub-module.
I didn't have such requirement before, so don't know what challenges may occur. For sure I wouldn't try to integrate maven-assembly-plugin or other packaging plugins with spring-boot-maven-plugin.
Concerning location of config files, just place them into src/main/resources or it's sub-folders according Spring Boot conventions. Spring Boot is opinionated framework and will be most friendly to you if you don't try to resist defaults.
Maven does not handle this gracefully, but its far from difficult to solve. You can do this with 3 pom files. One parent pom that contains the majority of the configuration, and one each for the packaging portion of the work. This would neatly separate the concerns of the two different assembly patterns too.
To clarify -- I'm not recommending a multi-module configuration here, just multiple poms with names like war-pom.xml and fat-jar-pom.xml, along with parent-pom.xml.

Spring Boot Maven Plugin keeps duplicate jars -- is there a fix?

We are seeing very large jar files created by Spring Boot Maven Plugin and upon examining them we found that there are many duplicate jars inside of it due to the structure of our multi-module project. We were able to reduce the size by excluding jars in the plugin config section, but this is a tedious and error-prone approach.
We did not find any options to de-dupe the output jar, but maybe we missed something. Any advice is appreciated.

Deploying a 'JAR' file instead of 'WAR' file for Spring-MVC and Maven

I am working on a Spring-MVC application which uses Maven. In the POM.xml I noticed that I can denote the file-type in which I can select if I want to deploy the project as a JAR or WAR.
Mostly I select a WAR file and then deploy it in Apache tomcat. My question is, If the application is Spring-MVC based, with Spring-Security, Hibernate and other libraries, can I package it as JAR by simply denoting it in POM.xml and deploy it in Apache webserver instead of using Apache tomcat? Or do I need to make some modifications somewhere for this to work. Kindly let me know. Thank you.
No, you can't. Apache httpd knows nothing about how to handle jar files.
What you can do though is to provided an embedded webserver (such as jetty) in your package and define in your MANIFEST.MF file a main class that will launch it and register your application to it.
That way you can package is a an auto-executable jar, or as a war that can be run on his own or deployed in a classical webserver.

StatusLogger Unable to locate a logging implementation, using SimpleLogger. MavenEJBModule in an EAR

I am fairly new to java and classpaths..
I have an EJB project which has a dependency on log4j2 in it's POM. It runs within an EAR and therefore is an EJBModule within the EAR POM. I also have a parent POM which both the EAR and the EJB project derive from. I am getting the error "StatusLogger Unable to locate a logging implementation, using SimpleLogger" when attempting to retrieve the logger using the LogManager. My log4j2.xml file sits in the src/main/resources folder of the EJB Project.
I have tried putting the log4j2.xml in the root of the project, and in the EAR. I have tried putting the log4j2 core and api dependecies in the EAR and in the parent POM. I have tried changing the manifest.mf file to include log4j. But none of these things have worked.
I also noticed that the "java.class.path" returns jboss-modules.jar. What does this mean? In my War modules this is different.
I need to know how I can use Maven to provide the log4j jars to the EJBmodule.
Thanks,
Jen
Someone else recently raised a similar issue on the log4j-user mailing list. I believe it was eventually tracked down to a JBoss issue. AFAIK, this is not resolved yet. Raising this issue to the JBoss team may speed up resolution.

Resources