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.
Related
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
Why Eclipse Glassfish does not support Eclipse Microprofile ?
And I am confused about Eclipse Microprofile Application,
Eclipse Microprofile Application can be a servlet application(war) nor ony a jar application?
I think servlet-api not nessary for Eclipse Microprofile Application.
I'll start with your last question and work backwards.
You are correct. The Servlet API is not part of Eclipse MicroProfile. So an implementation of the MicroProfile spec need not support servlet. If you take a look at the various MicroProfile implementations you'll see that some of them are derived from application servers, and some are not. Those that have roots in an application server might support servlet, but others might not.
The MicroProfile spec does not specify application packaging or deployment. Just the APIs that must be supported. So some MicroProfile implementations might support war files (likely those with roots in application servers) but others won't. Most of them will support some form of an executable jar and runtime dependency management so that you can create a self-contained, immutable Docker image of your application and its runtime dependencies. In this scenario the value of war packaging is questionable.
Eclipse GlassFish is a Jakarta EE implementation, and the focus has been to deliver a Jakarta EE 8 release. MicroProfile is part of Eclipse, but it is not part of Jakarta EE (at least not yet). So there is no requirement for Eclipse GlassFish to implement MicroProfile (at least not yet).
I need to create a java ee 6 project which contains:
JSF
EJB
JPA
The Web-things should be compiled to a .war file, the ejb to the ejb-jar and overall into an ear file. The application will be deployed to a Glassfish v3.
I was looking for a maven archetype which I can use and integrate into Eclipse. However I haven't found one. Can you help me?
I consider Andy Gibson's Knappsack Archetype as a good starting point for what you are looking for. It gives you certain levels of working projects from a very basic setup to one filled with examples.
Alternatively, Adam Bien's Weblog is always a good place for finding simple solutions as for example a minimal project setup.
The Java EE MVC Security Archetype is a quickstart for websites that want user self registration and security configuration.
You can try it out on Openshift, though sometimes you have to wait a couple of minutes for openshift to load and start the application.
The archetype includes the following technologies:
Java EE MVC web application for Wildly 9 environment
JSF 2.2 and Bootstrap
JPA 2.1
H2DB (H2 Development Database)
JUnit/Arquillian/Drone/Graphene for testing
Java EE SecuritySupported by JBoss/Wildfly Database Module
Please note: This post is self-promotional.
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.
I am trying to setup a new Netbeans project with JPA. The Java SDK version is 1.5.0_22-b03 and J2EE version is J2EE 1.4.I am using TOPLINK Essentials for JPA.
Going by javadoc javax.transaction.UserTransaction interface comes with J2EE 1.4.
Then why it's not able to find javax.transaction.UserTransaction?
The JPA 1.0 specification is meant to cater to Java EE 5 containers and not J2EE 1.4 containers (unless the same also support EJB 3.0 like the erstwhile OC4J containers from Oracle). Likewise JPA 2.0 caters to Java EE 6 containers.
I would suggest using Netbeans with Java EE 5 or Java EE 6, instead of heading for a wild goose chase on getting your JPA 1.0/2.0 provider to work amicably with a J2EE 1.4 container. This isn't merely about placing some JARs in your compile time classpath; your runtime classpath will require classes that are available only in a Java EE 5/6 container.
Either you have an incorrect classpath or you are missing a required jar. What are you using to build?
You have not correctly included the j2ee-1.4.jar in your project classpath. Otherwise you can reference to it. Perhaps you meet problem in setting classpath of your java project in netbeans.
Please check your jar to ensure it is correctly downloaded.
Maybe this is an old question but since no other answer has been posted, I post what I was able to do to make it work.
I found a file at:
C:\Program Files (x86)\NetBeans 8.1\java\modules\ext\hibernate4
Right-click your project >Libraries >Add jar > find your Netbeans installation directory...
usually => C:\Program Files (x86)\NetBeansXXX
find java\modules\ext\hibernate4 and choose jboss-transaction-apixxxxx.jar
hope it helps everyone else,