We're working with a very large EJB application that is built and deployed using Maven to a TomEE server. Currently we pack everything into one EAR file, but this means even minor changes by our developers require extensive build and deploy times to try out.
Is it possible to split an EJB application into multiple EAR files (I assume it must be) and if so how can we have TomEE know which EAR files to load?
Splitting up large EAR application to smaller EAR application doesn't have anything to do with "TomEE knowing which EAR files to load" . Basically it deploys EARs that you have published to the container.
If your application is already modularized then you can think of making each/set of modules to be a EAR. Only catch is you'll have to modify the EJB look-up in the code to include module name.
If this is purely about packaging and deployment issue then it should be easy to do. If it is about highly coupled application with lot of inter-dependencies then you are standing at the point of re-organizing/re factoring your "big" application
Related
I need to create a Spring MVC web application where each of the services should be created as a separate JAR file. Some of the docs suggest that multiple Maven modules can be used for this. But what I understood is, that each module also needs to be created as a separate Eclipse project.
Can I have all the controllers, service and DAOs in the same Eclipse project, while still creating separate jars for each service (and a war file for the whole application) with Maven?
Short answer:
Yes, you could create multiple build targets (jar files) out of single project by using maven-jar-plugin (profiles, executions).
https://maven.apache.org/plugins/maven-jar-plugin/
Should you do it?
I believe most people will agree with me that you should not do it, you should stick to one of the most important core concepts of Maven: modularity.
Now, Have you asked yourself the question, Do I really need to create multiple modules (jar Files) for my application? Can I manage all pieces of code in one single project?
Maybe you just need some guidance about how to organize your java packages in one single project.
https://dzone.com/articles/layered-architecture-is-good - Using layered architecture
http://www.javapractices.com/topic/TopicAction.do?Id=205 - Packages by feature vs Layers
NOTE: If you think that your project will grow fast and the number of classes will be a large number, it is probably a good candidate to be a multi module application.
If you still have the feeling that you have to create multiple modules, there are several interesting posts about how to address modularity in the design of applications, in these posts they provide very interesting reasons/criteria why you should split your application into modules.
How to decompose a system into modules?
Spring Java Maven Project + Module Design
Good Luck!
What is the problem of separate modules and hence separate Eclipse projects? If you declare a Maven dependency between the modules, you'll be able to have compile dependencies between the classes in the corresponding Eclipse projects.
So I suppose that it is possible to force multiple Maven modules into one Eclipse project, but I don't know any good reason to do so.
As part of cost cutting, management want to cease usage of websphere application servers in developer systems.
I was given task to convert the EAR file to one fat OSGI bundle and deploy it in equinox container. if successful, this set up will be shared among developers and will only be used in developer machines and not in higher enviroments.
I have searched many websites but didn't find any concrete solution.
Kindly share your ideas if any to solve the problem.
I strongly encourage you look at Open Liberty: https://openliberty.io
Open Liberty is an open source project launched by IBM last year at Java One. The goal of the project is simple: get awesome Java EE technology into the hands of developers.
Open Liberty supports Java EE 7 and MicroProfile as well as other technologies.
Unless you have a strong technical reason to convert the EAR into an OSGi bundle, you can use Open Liberty in your development environment. The install is easy:
unzip openliberty-18.0.0.1.zip
Give it a try. I think you'll be pleasantly surprised.
If you have questions, Open Liberty has a very active community and twitter or hit me up on twitter #barecode.
An EAR file is simply a JAR file that contains nested JAR files. Those nested JARs form the classpath of the application.
Converting to an OSGi bundle should be as simple as writing a META-INF/MANIFEST.MF for the top-level JAR containing the header Bundle-ClassPath header that lists the contained JARs, e.g.:
Bundle-ClassPath: a.jar, b.jar, c.jar, ...
If the EAR file also directly contains classes that are part of the application classpath, then the new bundle's JAR file should be prepended to the Bundle-ClassPath as an entry named '.' (dot), e.g.:
Bundle-ClassPath: ., a.jar, b.jar, c.jar, ...
Note that the manifest also needs to contain the mandatory OSGi headers, Bundle-Manifest: 2 and Bundle-SymbolicName: .... There is plenty of information available about this online.
I'm fairly unexperienced and all new to the whole world of build tools so here's my situation: I am developing a webapp with JSF, PrimeFaces and Hibernate on wildfly-9.0.2-final. All java files (incl. ManagedBeans, DAOs, Model classes, etc.) are currently in a regular eclipse java project called MyApp-CORE. There is no html or any other resources in that project, but all the third-party libraries like PrimeFaces, commons-xy, etc. Then I got two dynamic web projects with all the .xhtml files and stuff. Both web projects include the CORE in their build path (all done via eclipse built-in tools). Basically I followed Structure for multiple JSF projects with shared code so far. All projects are versioned using Git. I was now asking myself how to mavenize the whole thing and also how to properly include tests. The final result should be:
I want a build file for each web project that includes the CORE dependency and all of it's transitive dependencies, creates a .war file and deploys it either on the production system or locally (Depending on some parameters I want to be able to maintain).
This buildfile could then for instance test and build the CORE and then the .war file.
Since I'm using JSF, mostly the only option for testing is JSFUnit. Should I test each web project individually and put all the test cases there (which would be highly redundant because they're mostly the same, just a few features are different) or should I rather create a separate web project called MyApp-TEST which tests the CORE.jar and also - depending on some configuration - each web project.
I've already created a structure that makes it possible to include the core in the web project but unfortunately I loose the perks of hot deployment in wildfly when just including it as a dependency from my local maven repository.
So, to summarize it:
What would be a best practice for this setup, eventually leading to a continuous integration scenario?
How should I include the test cases (full integration tests that test actual UI behaviour)?
Which Tool (Maven, Gradle, Ant, etc.) would be best for that task?
Keep using hot deployment for smooth development?
Thanks in advance for any comments, hints or shared experience!
I have more than 20 ears files and I take a lot of time to deploy each ear alone using Websphere portal, so I'm looking for a solution to deploy all ears only one time.
You can try wsadmin scripting http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.0.0/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/trun_app_set_dragdrop.html
I never tried it, but it seems you can create special directory, copy ears into and all ears will be deployed automatically
WebSphere Portal has a packaging formate for many artefacts and it includes ear files as well. If you package your files based on the Portal Application Archive (PAA) definition you can use the Solution Installer to have them all installed in one shot and do more.
The ear file deployment would be simple by putting all ear files into a directory inside of the PAA named installableApps/ear. You need to follow some configuration steps but at the end you have a method to install and remove your full solution at once (or build multiple packages and install them as you want)
For reference the Infocenter link
http://www-01.ibm.com/support/knowledgecenter/SSYJ99_8.5.0/config/si_paa_spec_compdir.dita
A Java EE application consists of different components in own ear files, each being quite large. This allows to disable or install only parts of the application. They contain redundant jar library files and also the war files share many library files in the lib folder.
Does this negatively impact the PemGen space and performance? Is there a better practice like using one ear file containing all shared libraries?
App server mainly used is Weblogic. Installation should work by just deploying files.
One common practice is to place them in the (assuming tomcat)
$TOMCAT_HOME/common/lib
Or in any container place them in the classpath. I wouldn't go the way of the ear.
About the PermGen every ear, as an independent application, would have its own class loader. Depending on the configuration of you application (all the ears) one cannot access to the classes of the another. Since they are different applications.
So If you cannot place your shared libs where they are supposed to go I would ship every ear with the librarys.