CDI and Bean Validation are Java EE 6 Standard Specifications. Nevertheless, I can use both within Java EE 5 Application Servers (and also within Java SE) by just adding the libraries to the project.
Is this correct?
Are there any disadvantages of using both in Java EE 5 application servers instead of Java EE 6 application servers?
I have to use the Oracle 11 g Suite and JDeveloper. In the meantime, JDeveloper supports JSF 2.0, but I cannot find any support for Bean Validation or CDI. Nevertheless, this is not a problem. There is no IDE support (for code-generation, a step-by-step-guide, or whatever), but I can use these libraries by using the simple java editor. Right?
Java EE 6 is basically a collection of APIs. An application server is Java EE 6 compliant if it implements all those specifications. But you can still use the APIs in an Java EE 5 compliant application server. Some people even put EJBs into Tomcat, so technically that's possible. Still it makes sense to use a compliant AS, as it also provides all the services related to the specs.
I believe that's correct.
The disadvantage is that you're a version behind. You may have to modify your code if and when you decide to upgrade to Java EE 6 (e.g. new imports, etc.)
You can pretty easily add Apache OpenWebBeans or JBoss Weld (choose one of the 2 CDI implementations) to your WEB-INF/lib and register the servlet listeners in your web.xml manually. Voila, then you have CDI support!
For JSR-303 Bean Validation it's a bit more tricky, because only JPA2 and JSF2 makes use of it. So you would need to add Myfaces2 and Hibernate-3.5, EclipseLink2 or OpenJPA2 to your local jars and disable the container provided variants.
Related
I spent the last few days trying to wrap my head around the Java ecosystem, looking at the components (JVM, JRE, JDK, SE, EE, etc.), licensing and others.
As far as I understand, Jakarta EE (formerly Java EE, J2EE) is an API on top of Java SE with lots of enterprise-grade features and lots of (mostly deprecated) web technologies. Spring has similar goals but a different approach and runs on "standard" Java SE.
But then what about Tomcat? Tomcat is defined as an implementation of Jakarta EE features. I understand that TomEE is a "superset" of Tomcat with more Jakarta EE features.
Nevertheless, Spring (needs / requires) Tomcat as a runtime. Does that mean that Spring uses Jakarta EE features? Could you please clarify these differences?
Tomcat 10 offers JakartaEE, but no JEE.
Versions lower than 10 implement JEE but no JakartaEE. Here's the overview
To my knowledge, spring works on JEE, but not JakartaEE (at the time of writing this answer). So if you want to use tomcat with spring, pick version 9 (as of today), or another JEE container.
Spring does not implement most of the JakartaEE/JavaEE specification. One of the Spring project that implements a JSR defined in JavaEE that I can think of is spring-batch (see this).
Instead, Spring mainly provides support to integrate with a carefully selected individual specifications from JavaEE to allow developers to work with the implementation of these specifications using the Spring programming model (See this for more detail.)
Tomcat is the implementation of the Servlet API which is one of the specification that is included in JakartaEE/JavaEE. To me , the most useful and modern support provided by Spring for it is spring-boot allows to package the application using an embeddable Tomcat such that we can simply deploy and run the application as a JAR without install a Tomcat server separately and deploy the WAR to it.
I'm planning to migrate the application from J2EE 1.4 to Java EE 7. The target platform is Eclipse Indigo, JBoss 7.1, Servlet specification 3.0/3.1.
Questions:
What are the issues arises ?
Is just changing the deployment descriptor (web.xml) ?
Does web services features exist in J2EE 1.4 ?
Should I create a new project and copy all the source code is better or there is better approach ?
Please enlighten this. Thanks.
There are many things changed since 1.4, for example, enterprise java beans has new annotations, depreciating some of the JSF old anotations, and many other changes, so, yes, it's a hard work to do, the best you could do is to start a new project and add all the functionality (will be easy, JSF 7 has many, many advantages), then when it's ready replace the old one in production, all the changes will depend on how many features you are using, i really recommend to do the migration, especially after Java EE 5 i love Java EE, but in general and very probably will break a lot of code (xml's, configurations, views and other many things)
I have Websphere 7 server, and it don't support JPA 2.0. So I can't run on WAS 7 JPA 2.0 applications.
But I'm wondering how Spring users run Hibernate on Tomcat or Jetty? This servlet-containers also (as WAS 7) doesn't support Java EE 6.
So it's mean that I can run Hibernate on WAS 7 with the same results as on the Tomcat or Jetty?.
If yes, what are benefits of using app-servers for JPA? Why all developers don't use servlet-containers instead app-servers?
Also I heard about "container-managed" stuff, that allows some additional features and functionality. So it's mean that many developers (who uses Spring on Jetty and Tomcat) don't get benefits of using container-managed features of app-servers?
P.S. I know about available Feature Pack patch for WAS 7 for JPA 2.0 support, but question not about it.
You can bring in a lot of functionality by including the appropriate jars in your WEB-INF/lib folder, but then the servlet container cannot help you in any way with the functionality, and it will most likely not be well integrated with the functionalty actually provided by the container. A typical example is bringing your own JSF 2.0 libraries.
The real advantages of using implementations in the container, is that the container can then help with clustering across multiple hosts, providing JDBC connection pools, etc.
So, you need to be more careful when including e.g. Hibernate yourself, and do all the configuration inside your own deployment, but it can be done.
You could just as well ask an exactly opposite question: "why use bare servlet containers with JPA 2 since it is included in all the Java EE 6 servers?".
Basically it boils down to either:
having a light-weight container and then a heavy application (the Spring way),
having a light-weight application and then a heavy container (the Java EE 6 way).
After years of evolution, the models of building the applications with Spring and Java EE 6 have converged to the point where sometimes you cannot really tell just by looking at a class, whether it's a Spring or a CDI bean. So the real difference is mostly in configuration.
Application servers offer a set of services "out of the box", so they are easier to use if the offered services are the ones you need. You just package and deploy your application and the thing works. Furthermore, most of the technologies are instantiated by the application server, so you avoid a lot of classloader issues.
The problem with application servers is that sometimes (quite often, actually), you need to pick and choose particular versions of particular frameworks, services, etc that are incompatible with those which the application server offers. In those cases, you usually need to fiddle with the application server, and in some cases, what you would like to do might not even be possible with your application server.
For example, Weblogic 10.x is a Java EE 5 application server and so it will offer by default JSF 1.2 and JPA 1. If you want to use something newer, you need to manually deploy some additional libraries (JSF 2.0), or patch the server (JPA 2.0).
Another example: with Glassfish 3.1 I have not been able to use Tomcat EL intead of Glassfish EL. Tomcat EL supports varargs method call while Glassfish EL does not.
That rigidness of Java EE application servers makes a lot of people prefer developing for a standalone servlet container such as Tomcat or Jetty, where you have nothing out of the box but the Servlet and JSP APIs, but you can manually put everything inside. You can also package it with your application, which is more comfortable when you are developing, but can give you problems if you deploy more than one application per container (waste of resources, classloading issues, classloader leaks, ...)
UPDATE:
There are some differences in using JPA in a SE environment (such as Tomcat) when compared to using JPA inside a Java EE container. Basically:
You have to manually manage EntityManagerFactory and EntityManager instances.
Tomcat does not do injection so #PersistenceContext annotation and similar ones do not work.
Note that some containers (such as Spring) can be configured to hide these details, so you can work exactly as if you were inside a Java EE container.
Read the JPA spec for details on running in SE environments instead of EE environments.
Regarding another libraries, in general you will find some minor differences. For example, JAX-WS requires registering a servlet and a listener for your webapp, but anything else should be identical. Usually you can search the documentation for instructions on how to run the thing inside a standalone servlet container.
There is a JPA 2.0 feature pack for WAS 7.0, which may help you.
I have been doing Java SE for some years now and moving on to Java EE. However, I have some trouble understanding some aspects of Java EE.
Is Java EE just a specification? What I mean is: Is EJB Java EE?
Are EJB/Spring different implementations of Java EE?
I am sorry to ask but I have some difficulties to understand what Java EE is.
Could someone explain what Java EE is? And EJB?
(Updated Feb 2022)
First of all, "Java EE" has since Sep 2019 been renamed to "Jakarta EE", starting with version 8. Historically, there was also the term "J2EE" which covered versions 1.2 until 1.4. The term "Java EE" covered versions 5 until 8. See also Jakarta EE, History on Wikipedia.
Is Jakarta EE just a specification? What I mean is: Is EJB Jakarta EE?
Jakarta EE is indeed an abstract specification. Anybody is open to develop and provide a working implementation of the specification. The concrete implementations are the so-called application servers, like WildFly, TomEE, GlassFish, Liberty, WebLogic, etc. There are also servlet containers which implement only the JSP/Servlet part of the huge Jakarta EE API, such as Tomcat, Jetty, etc.
We, Jakarta EE developers, should write code utilizing the specification (i.e. import only jakarta.* classes in our code instead of implementation specific classes such as org.jboss.wildfly.*, com.sun.glassfish.*, etc) and then we'll be able to run our code on any implementation (thus, on any application server). If you're familiar with JDBC, it's basically the same concept as how JDBC drivers work. See also a.o. In simplest terms, what is a factory?
EJB is part of the Jakarta EE specification. Look, it's in the Jakarta EE API. Full-fledged Jakarta EE application servers support it out the box, but simple JSP/Servlet containers don't.
See also:
Where can I find a list of all the reference implementations for Java EE 6?
Java / Jakarta EE web development, where do I start and what skills do I need?
What to learn for making Java web applications in Java EE 6?
Are EJB/Spring different implementations of Jakarta EE?
No, as said, EJB is part of Jakarta EE. Spring is a standalone framework which substitutes and improves many parts of Jakarta EE. Spring doesn't necessarily require Jakarta EE to run. A bare-bones servlet container like Tomcat is already sufficient. Simply put, Spring is a competitor of Jakarta EE. E.g. "Spring" (standalone) competes EJB/JTA, Spring MVC competes JSF/JAX-RS/MVC, Spring DI/IoC/AOP competes CDI, Spring Security competes JAAS/JASPIC, etc.
Back during the old J2EE/EJB2 times, the EJB2 API was terrible to implement and maintain. Spring was then a much better alternative to EJB2. But since EJB3 (Java EE 5), the EJB API was much improved based on lessons learnt from Spring. Since CDI (Java EE 6), there's not really a reason to look at again another framework like Spring to make the developers more easy as to developing among others the service layer.
Only when you're using a bare-bones servlet container such as Tomcat and can't move on to a Jakarta EE server, then Spring is more attractive as it's easier to install Spring on Tomcat. It isn't possible to install e.g. an EJB container on Tomcat without modifying the server itself, you would basically be reinventing TomEE.
See also:
When is it necessary or convenient to use Spring or EJB3 or all of them together?
Java EE 6 vs. Spring 3 stack
Using JSF as view technology of Spring MVC
Java Enterprise Edition (Java EE) is an umbrella specification that references a number of other more detailed specifications, of which Enterprise JavaBeans (EJB) is one of the more important ones.
Read this - it explains the difference between Java EE and Spring
Thanks...
Source -- Java 2 Platform, Enterprise Edition (J2EE) defines the standard for developing component-based multitier enterprise applications. J2EE simplifies building enterprise applications that are portable, scalable, and that integrate easily with legacy applications and data .
Source -- Enterprise JavaBeans (EJB) technology is the server-side component architecture for Java Platform, Enterprise Edition (Java EE). EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology.
Is Java EE just a specification? What I mean is: Is EJB Java EE?
Java EE is a specification.
EJB is server side component architecture for Java EE
Are EJB/Spring different implementations of Java EE?
Both EJB and Spring are different frameworks following Java EE.
J2EE/JEE/Jakarta EE
Java Enterprise Edition (JEE) is used to develop distributed application &
web services.
It’s a component based approach to develop web app.
JEE web apps are considered as 3 tiered apps, since it is divided on 3
different machines/tiers
Client (Presentation)
J2EE sever (Application/Business)
Database (Data Access)
Everything you need to know about Java EE may be found by starting # Oracle official website, among other. You may also find interesting to read the specification APIs for release 8. It is worth taking the time to go through the Java EE 8 tutorial. You may want to start with it actually, because it provides a very good overview of the whole platform.
To put simply - JavaEE is a platform.
It is made up of many specifications which are just APIs. The specific concrete implementations of these APIs are the so called 'Reference Implementation'
EJB is just one specification within the JavaEE platform
No, Spring is a application framework that can allow you/has support for you to develop JavaEE applications
EJB is Enterprise Java Beans
I am facing the decision to abandon Java EE 5 container to use web container instead (with Spring). According to Interface21 Spring Pitchfork allows elements of the Java EE programming model to be used in Spring. Thus, I get a subset of Java EE annotations inside of Spring container. Since I prefer to maintain compatibility with Java EE this looks as attractive option to me. What is your experience with Pitchfork and what did you accomplish by using it?
No experience with Pitchfork, but lots with Spring. Foregoing EJBs hasn't been a problem. POJOs have been more than adequate.
Two other alternatives to consider:
You can use OpenEJB with Tomcat if you need EJBs, want to stick with Tomcat, and don't want to switch to a purchased or open source Java EE app server.
You can try Spring dm Server with OSGi. Eat the shell and the egg - go all the way.
I use pitchfork for unit testing EJB3 and JPA components outside of the container and it works really well. I can wire up everything I need including a transaction manager, a 2nd level caching provider, etc.