I currently set up a Java EE project for a new business application using CDI. The application is a pure server application (using jms, webservices and such, but has no frontend).
Since we are using Java EE 6, I would like to use the new WAR packaging instead of the former EAR, which seems to be a simpler packaging mechanism to me and was recommended to use if one has no special modularization needs.
My problem in understanding is now, that I am still thinking of a WAR as a web application. How is the project layout in my case, do I still have for example a WEB-INF folder even though I don't have any frontend and there's no need to publish the application under a context? Or is there a better way to structure a pure server application?
The 'new WAR' has the same layout as the 'old WAR', the only difference is that the EJB JAR(s) can now be placed inside the WEB-INF/lib folder of the WAR. In the 'old WAR' you could not place EJBs inside the WAR.
Related
What I understand is we can deploy a spring-boot application as a jar and as a war as well. What I don't understand is when should we go with a jar and a war ? I am talking about spring-boot web apps.
stack overflow
Both ways are equivalent technological wise.
JAR is a preferable way of deploying spring boot application, so consider it it as a first bet.
WAR is required if you already have java web servers (tomcats) managed by people who don't want/need to adopt a new / another way of deployment.
Usually this happens in large organizations or organizations with a dedicated IT / adminstration/ops department (many names exist for this), but essentially these are people who are responsible for deployment of the application.
We're deploying our JavaEE 7 application on Wildfly 8. Previously, we've packaged all of our enterprise applications (WAR, multiple EJB JAR files) as an EAR. However, with JavaEE now allowing you to package EJBs in a WAR file (or as a JAR within the WAR's WEB-INF/lib) we're wondering if there is any benefit in deploying an EAR rather than going with WAR packaging.
Does an EAR provide something that a WAR does not? It certainly reduces packaging complexity to make use of a WAR. Is there any difference in terms of deployment? EJB naming? Anything?
Easier to deploy (only one package instead of multiples).
Some server (example Weblogic, but not wildfly) allow shared session for an entire EAR.
In general, EAR provide more option to configure with AS.
Special folder (APP-INF) that let you define a config file application.xml.
If your application would consist only of multiple WARs then you may not find it such a big deal to maintain multiple deploy. However, consider an application which use WARs, EJBs, JMS etc. It will be a lot easier to mananage the interaction between all these components in an EAR.
You might want to read the packaging application part of the Java EE tutorial.
Setup of deployment of an EAR is painfully hard work (especially under Weblogic). Deployment of a WAR is simpler. Deployment as EAR has two benefits:
You can aggregate several unlinked applications in one file (whole eggs in one basket).
You can reduce size of this file with help of skinny war technology.
Your devops can deploy only one application instead of several.
Links restoring is not needed.
You can setup a well build barrier between in\out ear modules.
And many many others.
In other words one-war pattern in most of cases is devoted only for test and training purposes.
I am currently compiling a list of third-party libraries used in a web application. The application is deployed in tomcat. I am wondering which of the third-party jars actually must or should be included in the distribution. In particular, I am currently wondering how to best use javax-libraries.
For instance, I would assume the javax.annotation-3.1.1.jar can be used in some standardized way, e.g., downloading it as an extension, without me including it into the distribution of my own piece of software. However, I have it included as a transitive dependency from jaxws-api which I need for web services and therefore it is included in the application's lib directory.
I understand I could use the Extension-List manifest entry to cause the target machine to download and install such jars. However, then they are visible for other applications on the same machine as well which may require other versions of the same libraries.
So, I have some questions about 3rd party libs and I would be very glad if someone could give me some hints:
What is the best practice to use third-party libraries?
Is there some best practice for the javax-libraries?
Can and should I avoid redistribution without imposing a large burden on the person installing the application?
I have to admit, I haven't understood the notion of "redistribution" here, maybe you're using some concrete application server terminology, so I'll try to provide a common answer here, assuming you have a war.
WAR (stands for Web Archive) should include all third-parties used by the application.
These reside in WEB-INF/lib folder.
Now, each Java EE server should "understand" javax libraries, because it contains the relevant interfaces. "javax" libraries usually provide interfaces and the implementation/code that works with these interfaces are provided by the application server developers.
For example for servlets technology, Tomcat (or name any web server) will contain HttpServlet abstract class inside its internal libs, it will scan your war and find where do you implement/extend it, this is how it recognizes your servlets actually.
Now, you shouldn't include servlet-api jar into your war, because its already exists in the application server.
If you're using build tools like maven, they allow to build your war so that some thirdparties will be used for compilation but won't be packed up into war.
I didn't understand why is it so difficult to install the application - in the easiest case - you throw the war into the web server and that's it.
Hope this helps
I created a project(in netbeans) where all my gui part(used swings) is in java application-1.The data from java application-1 is passed to servlets in WebApplication-1 where the details are stored to the database.The project is working fine.
I was asked to create jar/war for my project..so that it can used any where...
I have gone through creation of jar and war(also tested with sample applications).My question is how can I link java application-1(jar) to WebApplication-1(war)??
For suppose jar is imported in another system it has to use war(since servlets are there in Webapplication).How can I do this??Is there a way to bind all the project into one library??
You can't access a war directly from the outside since according to the Java EE spec wars have to be isolated. Thus any communication between the GUI app and the web app must use other channels, the most obvious being http-based communication, like webservices.
Another option might be to create an ear and put the database code (moving it out of the war) as well as the GUI app and the war into that.
I have a JavaEE6 application, consisting of Web stuff and EJBs and which is deployed as WAR-only (using EJB3.1). The build is based on Maven. I just read about a new possibility to order the module initialization in Java EE 6 here which i also need for my application. Also, i would like to have an option to define some EJB properties in XML.
Since the example is deployed as an EAR-project the order is defined in the application.xml. But in a WAR-deployed project, there is no application.xml. Now i wonder where i can define such informations? Or is it possible to use an application.xml somehow in a WAR-deployed-app?
EDIT:
Oops i didn't read the module-order-example right, in the first moment i thought it was about in which order the EJBs in my app are loaded. Of course i have only one module in my WAR-app, so ordering makes no sense.
Ok, but as i'm at it, one big question remains (also altered the question title to reflect the change): What about the ejb-jar.xml? Can i somehow define stuff about my EJBs in XML (as its useful for some settings, to avoid recompilation)?
In short, it is not possible with a WAR based deployment.
The module initialization feature of Java EE 6 is meant for initializing different modules of an application in a specific order. The moment you have a WAR based EJB application, you no longer have separate modules for your EJB and Web application. There is just one module - the web application module in a WAR based deployment.
Therefore, if you have to achieve the same feature as the module initialization order, offered in Java EE 6, you'll have to do either of the following:
Separate the EJB into a separate module, and use a EAR based deployment.
This is more or less trickery, as was done in Java EE 5, and you would want to be avoiding it. You might want to code in logic to ensure that the singleton EJBs have been created (assuming that this is due to the use of singletons in your application), before they're utilized in code.
Location of the ejb-jar.xml in a WAR file
The EJB 3.1 specification (in the chapter on Packaging) addresses the issue of the location of the ejb-jar.xml file when deployed in a WAR:
In a .war file, the deployment
descriptor is stored with the name
WEB-INF/ejb-jar.xml.
PS: I haven't tried this style of deployment yet. YMMV.
Side note on EJBs in .wars and ejb-jar.xml processing. As already noted the location is WEB-INF/ejb-jar.xml, but also note that is the only location checked even if there are ejbs jars inside WEB-INF/lib/ -- via standard rules any META-INF/ejb-jar.xml files there are ignored.
The Expert Group was rather split on that one, so if you have a preference it's not too late to send feedback to the EJB 3.1 expert group list for consideration in EJB.next.
My vote was to still allow individual jars to have META-INF/ejb-jar.xml files just as these jars can now have persistence.xmls, beans.xmls, web fragments etc. The larger issue for me was that it is at odds with the Embedded EJB Container API which supports an EAR-style classpath which allows several jars/modules each possibly containing a META-INF/ejb-jar.xml file. The result being if you do use the Embedded API to test a multi-jar ejb app that is composed into a single .war file, you are then faced with the task of merging any ejb-jar.xml data you have into a single ejb-jar.xml for the webapp. Sort of a pain for users.