I currently trying to migrate an application to Maven. Since the previously, the application was mix of web projects (with JSPs and JSs) and other "normal" projects. I am having a hard time packing all those modules into one. For the web projects, I chose the packaging as WAR and others I chose JAR. Now I am trying to make a master WAR file, that I can eventually deploy to Tomcat. But from I read, packaging a WAR in another WAR is not possible. And also I read that making the packaging as a JAR is doable. I just wanted to know is the first option totally out of the question? If JAR and a WAR is the only option, where do I put all the web stuff (JSP, JS, images etc.). Currently the WAR+JAR combo creates a final WAR file that is only 3KB big, which hardly looks realistic. I know I am missing something, but not sure where to look. The application is about 14 years old, so doesn't really conform to any framework that I can think of. EAR is not an option either, as the application has to be deployed on Tomcat. I wish TomEE was an option! :(
All your "JSP, JS, images etc" should go in a WAR file.I have an application packed in a WAR file that is running with all this in a hosted Tomcat. You can package the entire application as Java EE except there are Desktop applications.
Just take your 20 wars and deploy them on the Tomcat. There is no need to bundle them into another artifact.
Related
We extensively use Java ServiceLoaders as a plugin infrastructure for our application components. We define interfaces, and then use the loader to load them at run time. Adding additional jars with extensions and service files are fine for our use cases.
However, i'm struggling to understand how we would be able to continue this approach while deploying an application within Wildfly. The intent is as stated above, the ability to add "extension" jars to the web-application class path without having to
Stop the server
Unzip the war
Add additional jar
Zip war
Start the server
In Tomcat, we could deploy web application folders instead of a war. So stopping the server, dropping in a jar, and starting the server worked fine. Within Wildfly (latest), it appears to not like the deployment of a folder vs war.
I've read about the modules approach, but have not been successful using this approach to get the deployed application to see the module from the service loader implementations.
Would like to know if there is an alternative solution or perhaps we are doing something wrong?
Thanks
WildFly supports exploded deployments with the deployment scanner or using the explode command with jboss-cli. Using the jboss-cli you can even update files remotely.
I'm trying to deploy .EAR on Liferay (running on JBoss), I put .EAR to JBoss deployments folder. My structure is:
lib (some libraries/modules)
META-INF
WAR (it contains all Liferay specific libraries from auto deploy)
JAR
According to console, deploy is correct. JAR is running (I have some methods with Timers and they are working properly). But I don't see any portlets from WAR that I can add, but according to console WAR is deployed. They are simply not exposed to Liferay. I know that the .EAR is like a closed structure.
I am wondering how to make portlets available to Liferay?
I would appreciate any ideas, thank you.
Currently there is no standard way to deploy portlets (WAR) inside EAR. Liferay won't detect them. Your WAR with portlets must be deployed separately.
I have jars in the main webapp of a WAR. They are being deployed as the dependencies of a Java Web Start app client, along with a JNLP.
I get a lot of class loader exceptions in Glassfish when I try to deploy it.
Is there a way to tell the WAR to ignore those jars?
Or even better, to have the JNLP work with a zip of the dependencies? (If I zip them, it deploys fine).
Turns out the jars deploy just fine. It was just one jar that caused problems. Glassfish doesn't like when you deploy glassfish-embedded-all to it. Which makes sense in hindsight. Taking that jar out made everything deploy just fine. I just replace the resource link in my JNLP with a central download location for it.
I have a web application which consist of JSP pages, Servlet and Consumes Web Services.
It also references apache axis and excel libraries.
Now I want to deploy my application directly in Weblogic server
How do i do that.Whcih archive shud i make WAR or JAR??
ALso how to ensures that it covers all the referenced libraries.
I have made my application in Jdeveloper, but I dont want to deploy it using Jdevelper..
I would package my solution as a .war file, containing all dependent .jar files.
That way your solution is self-contained. You can deploy to an app server containing other apps with their own versions of your libraries (dependent or developed). If you put the dependent jars directly into the app server (as you can do), then you're forcing those versions on all applications deployed, and that could well cause you grief.
The downside is that your developed .war file can become sizable. It's not normally a major problem, and I wouldn't worry about it until it's identified as an issue.
A JAR-file cannot contain a JAR-file, so that option is out. Since you mention JSPs and servlets a WAR would seem the appropriate option, although an EAR with a WAR and several JARs could also be a way forward...
Cheers,
Consider a WAR with your JAR files in WEB-INF/lib. Or, create an EAR with APP-INF/lib folder.
I have a Java EE web application that does not make use of EJBs. I am targeting Jetty/Tomcat for deployment some of the time and thus need a WAR packaging. However, I am also target JBoss and Websphere some of the time.
My understanding is that full-blown Java EE application servers can take either EAR or WAR formats. When would I use one over the other and why? I understand they are both standard compressed file formats and I have read 10 different snippets that try to explain them (including this one), but am no closer to understanding the pros and cons of each.
If you have only web modules - use WAR file.
If you have different Java EE modules - use EAR. Though you can deliver only web modules in EAR - there is no point in doing this (and you will need to do more complex deployment configuration)
The crucial point is if you need anything provided in an EAR file (which may contain said WAR file). If so, then it makes sense to deploy as an EAR.
It can also wire up some of the configuration you need to do manually in Tomcat etc. A typical example is the URL bound to the web application, where you need to override the default heuristic with a container specific configuration file for a WAR, but you can put it directly in the EAR configuration file.
Also, during development WARs can frequently be hotdeployed directly in exploded form, where EARs must be unpacked and deployed. For Glassfish from Eclipse the difference is quite noticeable.
In J2EE application, modules are packaged as EAR, JAR and WAR based on their functionality
If You are using only Servlet, JSP, GIF and HTML files. Then use .WAR
WAR:(Web ARchive) Web modules which contain Servlet class files, JSP
Files, supporting files, GIF and HTML files are packaged as JAR file
with .war (web archive) extension.
If you are using different different JAVA EE modules like (EJB + Servlet, JSP, GIF and HTML files + Other technology). Then use .EAR
EAR: (Enterprise ARchive) All above files (.jar and .war) are packaged
as JAR file with .ear (enterprise archive) extension and deployed into
Application Server.