I'm using:
Wildfly 21
Java 11
I've just went through the pain of modularizing (with Java 9 modules) an Jakarta EE EAR application of mine that runs on Wildfly 21. This application has a war jar, ejb jars, utility jars (all have a module-info.java now) and other third party libraries. The whole application compiles well, without errors.
But I noticed that when I run it in Wildfly, althought it runs without problems as before when it wasn't modular, it seems that the application server is not considering that it is now a modular application and is not using the modulepath to run the application, but the classpath. So, at runtime, the modular nature of the application is being ignored.
Is there a way to instruct the application server to run the application as a modular one, using the modulepath instead of the classpath?
It's a pity that we have to be locked by application servers like Wildfly blocking us from using such an important Java feature (modules) at runtime in our applications.
While Wildfly doesn't support running modular wars, you can take a look at Piranha Cloud.
The Piranha Server itself can run in the module path and can deploy WARs in a new JPMS layer, respecting the module-info.class provided.
https://piranha.cloud/blog/2021/20210128_Modular_applications_with_JPMS
PS: I'm a Piranha Cloud developer
Related
I need your help to understand what's the best way to organize our Ecplise environment since it's getting complicated.
We have 7 large multi-projects units which are deployed as distinct EARs on different servers. We use WildFly on all of them however some are older whereas others are newer (they span from WildFly 10 Runtime to WildFly 12 Runtime)
Every EAR contains war/jar from other projects, some projects are common and they end up as a jar in every EAR. For instance let's say Project Common is a plain Java project which is included as a jar in all the 7 EARs.
The build path of Project Common is my problem, for example if Project Common requires Servlet api as a build path dependency, we used to add the Wildfly server runtime libraries to solve the problem but
the actual version of the Wildfly server runtime libraries is different depending on the EAR you're dealing with (as I said they span from WildFly 10 Runtime to WildFly 12 Runtime).
When it will be deployed & running, Project Common will run within a specific WildFly server Runtime but in its buildpath (as an Eclipse project) which server-runtime are we supposed to enter? All of them are good and yet WildFly 12 Runtime might come with a Servlet API version which is different from the one provided by WildFly 10 Runtime.
Ideally what you want is to build Project_Common.jar with the very same server-runtime library it will have when running in a specific EAR but as I said that depends on which EAR you're working on at the moment.
In other words, the build path dependencies of Project_Common.jar are dynamic depending on the EAR it will be packged to run into (because it will be running on a different WildFly version)
So far we used a single giant workspace and 7 different Eclipse working-sets
however what I'm thinking is to have 7 different workspaces with Classpath variables that are different from workspace to workspace.
For example if Project Common requires javax.persistence API in its build path, instead of including a specific WildFly server runtime version (which will ship a specific version of javax.persistence), we might have just a classpath variable JAVAX_PERSISTENCE in every workspace that will be defined to point to the specific javax.persistence jar (specific to the WildFly Runtime it will be running).
What do you think? The "disadvantage" of this approach is that the 7 workspaces will all have their own copy of Project Common which will have to be kept up-to-date.
Is there a better/easier way?
Is it possible to make a Java EE 6 application deployable on any Java EE 6 Container (like JBoss or GlassFish, etc) without using their modules / libraries?
If for example I want Hibernate or Weld then add these in my Maven pom.
In other words, is there any "vanilla" container or can JBoss or GlassFish be made "vanilla"?
I´m sorry... but to be honest I don´t understand your question.
Java EE applications are in most cases deployable an all containers - as long as they are not using packages or configurations which are specific to the chosen container.
Even if you add libraries in your POM and the applications are packaged as WAR or EAR this should work.
Weld is not needed because the API is part of Java EE 6. If you want to use JPA you also don´t need hibernate.
I have a Java EE 6 application developed on Netbeans 7 and try to deploy it on a JBoss 6 instance. The application makes use of JAX-RS but I am not using any Jersey specific aspects, just standard JAX-RS features.
Deployments as a WAR fails because of some missing Jersey classes and deployment as an EAR fails due to org.jboss.deployers.spi.DeploymentException: Only one JAX-RS Application Class allowed
Any idea what the cause of this might be?
What I do not want to do is disable RESTEasy in JBoss, I'd rather produce an application that runs on any Java EE 6 container without tweaks.
Glassfish silently adds Jersey JAX-RS packages to the build. If you uncheck the 'Package' checkbox in the project's lib configuration, the application is packaged without Jersey.
This makes sense, because after all, the target of the deployment might be a non-Java EE 6 container such as Tomcat.
When I develop an Axis2 web service on Eclipse, I noticed that Eclipse is automatically copying the classes from the lib folder of Axis2 to the lib folder of the new project. However, not all classes from the lib folder of Axis2 are being copied. Interestingly, the web service runs without any problem when deployed to Tomcat via Eclipse even if some the jars from Axis2 were not copied. Also, when I viewed the temp file of Tomcat, Tomcat seems to generate the jars for the listed modules on modules.list of the web service.
Can someone enlighten me regarding what is happening on this? Why Eclipse doesn't copy all the jars from Axis2? Why can the web service run on Tomcat even without the other jars from Axis2? What are those temp files for? When and why is it being generated?
I tried to run the same project on WebSphere and I am encountering a ClassDefNotFound exception because of the missing jars. My problem was solved when I copied all the Axis2 jars that was not copied by Eclipse to my project. But I'm not comfortable with my solution because Tomcat can run my project even without those jars. Is my solution really the right solution? Or am I missing a configuration setting?
This is just for clarification:
My web service is already running in Axis2. My class loading policy is set to PARENT_LAST. I know that since WebSphere has its own Axis2 configuration, the class loading policy must be set to PARENT_LAST so that WebSphere will use the Axis2 from the project itself. Aside from setting the class loading policy, I did something to make my web service run on WebSphere. I describe what I did above. My question is why such method must be taken?
WebSphere has it's own axis2 configuration as part of its Java EE server spec for JAX-WS. Change your class loading policy to PARENT_LAST and check if that solves your problem.
Edit:
As the original post already states: WebSphere is a Java EE server depending on version it supports its the standard Java JAX-WS web services. Actually web services became part of the standard jdk.
If you use JAX-WS like mentioned in Introduction to JAX-WS or building web services then you don't have to add any 3rd party library for getting your web services running. As soon as you use the non JDK implementation like axis2 you have to package it with your application.
IBM didn't just pack the axis2 into their WAS/JDK, they modified it. I'm not sure what Tomcat delivers, however as long as you use JAX-WS it shouldn't matter. With JAX-WS you don't have any direct import of the org.apache.axis packages. If you use these imports you have to supply the libraries and make sure that yours are loaded.
If client of the system is on the web there are no advantages JBossAS+Seam over Tomcat+Seam?
Your questions suggests you're confused about what is what.
Seam is a framework for building web applications in Java.
JBoss AS is a Java EE application server.
Tomcat is a Java servlet container.
You can run Seam on either JBoss or Tomcat.
Since JBoss is a full EE app. server, you get certain features like Enterprise Java Beans out of the box with JBoss.
With Tomcat, you don't, but this isn't usually a big concern since, for example, Spring framework can replace Java EE if you need that functionality.
It does matter what you use, since the majority of your system will be probably coded in the back end (server side Java).
If you want the minimum amount of hassle when using Seam, I'd suggest using JBoss since that company made Seam.