I am creating a new web application where I am using JPA, EJB and all the goodnes from JavaEE. However, I have been doing some JSF in the past (yes the latest version) and I personally don't like that much. So I have been introduced to Play Framework which is pretty awesome from what I have read so far. Now I want to use the Java EE backend with the Play framework. How would you do that? In order to use EJBs etc you need a EJB container and all that is provided by servers such as Glassfish, JBoss etc and Play framework use Netty (if I am correct). So how would you make these technologies talk together? Webservice (REST), RMI...?
And would the performance/lag be very high? I will have both servers running on the same VPS.
If you are using Play 1.x (which I suspect that you would be since it sounds like you are looking to use Java, not Scala?), then you could use the Play Spring Module.
I have not personally used this module with Play, I have stuck with the out-of-the-box structure (which uses JPA, btw).
AFAIK, you'll have two options:
Use an embeddable EJB container and start it in the Play 2.0 Global.onStart(). It exists these kinds of containers for various Java EE servers (JBoss, Glassfish etc...)
Use webservices served from your Java EE app, but it will add a new "layer", and it should be slower.
Related
I am learning JAVA EE through oracle documentation(which i feels is great BTW), but i am not able to understand diagram on below link can someone throw some light on this?(what does it mean?)
https://docs.oracle.com/javaee/7/tutorial/img/jeett_dt_007.png
It just shows you the APIs available in the web container. So primary components that run in the web container are Servlets and JSF, however you may have also JAX-WS or JAX-RS services running there. These components may utilize various APIs, like for example JPA to access data layer, or EJB lite to use EJBs included in the application etc. And it all relies on Java SE, so you can use any class available there.
I would like to take a doubt about the container to run a "Spring Application", in my opinion one of many features who Spring Framework offer is a possibility to create application without container EE. Is right use this type of container ("WildFly", "GlassFish") with a spring project ? In my option is wrong but i'm open to listening more people.
i saw a article where the author are showing the features of Spring 4 with the WildFly, but i didn't agree, so i would like to take more opinions about this topic here.
Considering Spring Web and Web MVC you will typically use a lightweight container like Tomcat, Jetty or any other servlet container - maybe embedded like Spring Boot does.
Spring Web is designed to work without a full JEE container but will also work deployed inside one.
With Spring without JEE you have much more control about the features you use. A full appserver has a bundled feature list, you get all or none. Spring offers you to pick what you need resulting in a more slim application.
Well, first of all it is a little tricky to say that "something" is wrong or right in software development, mainly in this type of subjective question. As always, that really depends on what you need and on the EE Container that that you are using.
Let's get Widlfly as example. Since JBoss 7 (and now Wildfly) I do not think we can say that JBoss is a "heavy" Server, as it starts in just a few seconds, much faster than in the earlier versions. While it is true that Wildfly comes with a lot of services that you may not use, it is not correct to say that you get "all or none", for at least 2 reasons:
You can disable the services you do not need.
Wildfly works with the concept of lazy-loading for its services, which means that it will only load the services that are required to run a given application.
Having said that, we can not forget that Spring also uses some EE services, if you want to. So, if you need to use Spring with JMS, for example, you still need a JMS container. In this case, you can use an EE Server without needing to install additional services or you can start a JMS container in your Tomcat.
Besides the EE features, there is also the question of features related to the server, such as configurability/manageability (Web interface, CLI), HA, scalability... that really varies from server to server and I think Jboss 7/Widfly does a good work on these points.
I am looking for a powerfull up to date Java OSGI framework for WEB,
which would allow
Modular architecture (OSGI)
Flexible Views (JavaScript, HTML, Templates...)
String MVC separation
Maybe preimplemented CMS modules?
Is developed actively and open source
What I found was
ZEND for PHP. Does the Java world offer something comparable?
Spring Spliced may be the solution
Eclipse RAP, can OSGI but does not offer Views which are flexible enough
... ?
Take any std. framework of your choice and deploy it on top of Karaf (if you don't want to hassle with building your own OSGi runtime environment), or if you want to build everything up from scratch take also Pax-Web into account it also supports Servlet 3.0 and OSGi take a look at the home page of Pax-Web.
I'm quite fond of Vaadin, it plays nice with OSGi, and it's quite active.
It's a UI toolkit, based on Google GWT.
Mind you, you still have quite some decisions to make: You can use an OSGi framework 'straight up', like Felix or Equinox, but perhaps you'll be better off using an application server, like Apache Karaf or Eclipse Virgo.
You should look at Apache (Felix) Sling or its commercial version CQ5 (formerly Day Software). It is fully based on OSGi.
I'm developing OSGi based web applications on a daily base. We have a slightly alternative approach which works very well:
RESTful web services implemented using OSGi services
Modular AngularJS based user interface, packaged in OSGi bundles
Although AngularJS is obviously not a Java web framework, it fits modern web development perfectly. If you are familiar with Java MVC web frameworks it's also easy to understand Angular.
The main question is how to modularize your code. At the backend we implement everything as OSGi services. RESTful webservices are implemented with JAX-RS using the Amdatu (amdatu.org). With Amdatu you can use JAX-RS in a way that fits OSGi well. Each RESTful resource and lower level services are packaged in separate bundles as well, so the backend is fully modular.
To modularize the UI itself we separate functional different parts of the application as different Angular applications. Each Angular application is packaged in separate bundles as well, using the Amdatu resource provider.
You could test Konekti a Open Source OSGi business platform powered by Eclipse Virgo OSGi Container developed by Thingtrack.
Vaadin.
Spring.
JasperReport.
Quartz.
JBoss JBmp, drools.
Apache Camel, ActiveMQ.
And many more
http://www.konekti.org
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 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.