I followed this NetBeans guide here on RESTful web services using JPA - http://netbeans.org/kb/docs/websvc/rest.html
I thought JPA was supposed to be a specification and you would use something like Hibernate as the actual implementation in your application. But this guide doesn't make any mention of an implementation at all. So where is the implementation coming from, is NetBeans providing its own JPA implementation?
That tutorial uses Glassfish as the Application Server. It provides the implementations for the JavaEE Apis, and in the case of JPA, it is EclipseLink. The idea is that your application does not ship with those libraries (JARs) and instead rely on the ones provided by the Application Server
Once you have it working, if you wish to learn about different JPA implementations, or different Application Servers, then you can try running the same application on JBoss, which has Hibernate as its JPA implementation.
Presumably it is the JPA provided by the container (probably Glassfish).
Related
I've been doing Java standard edition development for awhile, and the frameworks and solutions have been fairly obvious to me (Swing for GUI, etc). I've recently begun the task of building a server for my own needs and to host a web page (things the server will be doing in addition to hosting a web page would include personal SVN hosting and integrating more web functionality into existing and future applications). For coding for only a single computer (that is, distributed computing, etc. is not really a concern)- I'm not entirely certain between Spring, Hibernate and EJB and am not very knowledgeable as to the capabilities of each. Information would be appreciated. I know Spring is an alternative to EJB, and Hibernate is an object-relational mapping library, so does EJB combine the two?
EJB3 in summary consists of 3 bean types; Message Driven Beans, Stateless/Stateful Session Beans and Entity Beans or JPA (Java Persistance Architecture). Hibernate can be used as a JPA provider, but it doesn't have to be used that way.
Spring has functionality that is roughly similar to Message Driven Beans and Stateless/Stateful session beans but it does not have an equivalent to JPA. Instead it allows you to utilize JPA or hibernate directly but if you do combine Spring with JPA you'll need an EJB container.
Another difference is that EJB is provided by 'containers' whereas spring is a framework that can be deployed into a java se application or a java servlet container web application like jetty or tomcat. Its an important distinction to make. Tomcat is not an EJB container, only a servlet container, hence if you were to only use basic tomcat, you couldn't use EJBs but you could use spring by including the required spring jar files in your web application (WEB-INF/lib). In that case you wouldn't use JPA either but you could use hibernate.
Some java servers that ARE EJB containers include weblogic, websphere, jboss, geronimo, and glassfish. Tomcat can become an EJB container if you combine it with OpenEJB.
In an application i'm developing at the moment, I'm using tomcat + openejb so I have an EJB container so I can use JPA with OpenJPA as the persistance provider. I'm using Spring MVC to do the web application development and will most likely use spring security as well down the track. I probably will also use Stateless Session EJBs as well to encapsulate business functionality but i could just as easily use Spring service/dao beans instead of statless session ejbs as well.
Its pretty confusing sometimes to work out what parts of which framework or container you should use and really comes down to either preference or using functionality in one that doesn't exist in the other or ease of use. Another consideration is memory utilization. Some of the ejb containers consume large amounts of memory just starting up with no applications running. This is one reason I ended up using tomcat + openejb. Hope this helps.
I am gonna implement web service in Java but before implementation I will decide which framework I should use. Simplicity and running on JBoss 4.2.3 Platform are the requirements.
What is your suggestions?
Instead of using an additional technology stack component, why not use the #WebService annotation introduced in EJB3. JBoss 4.2.3 supports EJB3
Two examples
Using EJB3 Web Services guarantees that you web services will run on any Java EE compliant server without any modifications to the server.
Since JBoss provides JavaEE features, you can simply take a look at JAX-WS, annotate your EJBs, and let JBoss handle everything from there.
Otherwise you can look at Apache CXF and for JBoss + CXF see here
Axis2 on Tomcat 6
JAX-WS on Tomcat 6
Quick, Fast and Easy
Can i use Spring Webflow/MVC and Spring Security and Hibernate on Google App Engine?
Is there a list/summary of java frameworks that can be used on the GAE?
Will it Play In Java lists frameworks, languages and libraries that work (or not) in Google App Engine. At present, the information listed is:
Spring MVC
Version 2.5.6
Status COMPATIBLE
To see Spring's MVC framework running on App Engine, check out the autoshoppe sample application. If you're using Spring forms (e.g. using the spring-form.tld tag library and subclassing SimpleFormController), you will need to register custom editors for your properties. This is covered in http://groups.google.com/group/google-appengine-java/browse_thread/thread/d93fd7385bf85bf7.
Spring ORM
Version 2.5.6
Status COMPATIBLE
To get Spring working with the App Engine-provided JPA interface, follow the instructions at http://objectuser.wordpress.com/2009/05/19/spring-jpa-in-google-app-engine/, which discusses a workaround to the dependency on javax.naming needed for #PersistenceContext. A more complex workaround is available at http://groups.google.com/group/google-appengine-java/browse_thread/thread/187d41712ec1d394.
Spring Security
Version(s) ?
Status SEMI-COMPATIBLE
To work around a ClassNotFoundException, you can use a re-compiled version of the library which adds a StringInsensitiveComparator class -- the download is provided at http://www.google-app-engine.com/blog/post/Spring-security-fix-for-google-app-engine.aspx. See http://www.dotnetguru2.org/bmarchesson/index.php?p=1100 for tips on how to get Spring Security running with App Engine and GWT (in French). See http://groups.google.com/group/google-appengine-java/browse_thread/thread/964e7f5e42840d9c for discussion on the integration.
Hibernate
Versions All
Status INCOMPATIBLE
You cannot currently use Hibernate directly. The differences between the App Engine datastore and SQL were too great to get the standard Hibernate up and running under App Engine. App Engine does support JDO and JPA, so you may be able to convert your Hibernate code to use one of these ORM interfaces.
I suppose that it should work with Spring 3.0 too, I will try soon and share the results.
UPDATE: I tried a Spring MVC Hello World with Spring 3.0.6 with Google App Engine and it worked perfectly, both locally and in the cloud. The drawback though, is longer load time when a new instance starts.
As far as I know, no third party libraries are supported (at least none are listed), and JRE classes are limited to this list. But I guess if a library only makes use of the listed jre classes, they should be fine. However, finding out if they do would have to be based on trying it out.
Since EJB 3 we have embeddable EJB containers, JPA implementations can be used without an application server, there is Weld for contexts and dependency injection and so on. Since on many systems is only Tomcat available, I wonder, if Java EE could be used without an application server but with a Servlet container like Tomcat.
What would I have to do to set up an Java environment? What drawbacks do you see?
Note that Tomcat is an Application Server. That said, in October we released Apache TomEE which is Tomcat with the missing JavaEE parts added, then Java EE 6 certified using the official TCK from Oracle.
The stack evolved from what used to be simply called "OpenEJB/Tomcat", which was a useful stack with a bad name :) Commonly overlooked because of the "EJB" part, meanwhile it also delivered Transactions, JMS, WebServices and more to Tomcat. The new name is far better and now it's officially certified like JBoss or GlassFish. We're pretty excited about its future.
If I understand well, you want to use EJB3/JPA within a servlet container.
There are not only stand-alone implementations of JPA, but also embeddable EJB3 container, such as OpenEJB or Glassfish embeddable container. So nothing prevents you from starting such an embeddable container from the Servlet container to use EJB3.
(Note: I don't know all the details about transactions. In a full-blown app. server, you have JTA and a distributed transaction manager. You don't have that in a Servlet container such as Tomcat. JPA works with JTA and plain JDBC, but I don't know exactly how an embeddable container work without JTA. Still, I guess that would work given that such embeddable containers are also meant for unit-testing where I guess there is no JTA distributed transaction manager.)
Another approach would be to use Spring. Spring and EJB3 have indeed become very similar. You can start the Spring DI container within the Servlet container and benefit more or less from the same facilities as EJB3 (declarative transactions, etc.). See this post about Spring vs. EJB3.
All these technologies have become pretty modular, especially with Java EE profiles. You can use Sevlets, EJB3, JMS, JPA, even JTA somehow independently of one other. You can also create an environment where you cherry pick the ones you would like, either with Spring or with Java EE. The question is when does it stop to make sense and rather use an app. server with everything available and easily manageable. I think Servlet/EJB3/JPA is the limit, if more is needed go for an app. server.
You will generally require some kind of container, even if that container doesn't provide Java EE-related services. After all, you do need a long-lived JVM process to host the code that you're executing. Tomcat and Jetty will do the job nicely, and in addition to basic servlet services, provide a few useful extras that will be relevant, like connection pooling.
J2EE without application server was introduced years ago by me (Guy Pardon, from Atomikos), with this seminal article: http://www.onjava.com/pub/a/onjava/2006/02/08/j2ee-without-application-server.html - focused on JMS and JDBC at the time.
In general it's easy to setup thanks to Spring and Hibernate. Actually, I got inspired to do this after doing a Java EE project and being confronted with the XML hell associated with app servers and EJBs. Without application server things suddenly became a lot simpler and more testable.
If you need a Tomcat installation then can be a bit more of a hassle to configure, but recently Atomikos has introduced out-of-the-box Tomcat integration as part of its commercial offering at http://www.atomikos.com.
HTH
Where I'm working the guys that are sitting across from me are working on a project. This is a JavaEE app which uses Struts, Spring, EJB 3.0, JPA, and Hibernate 3.0. They are using EJB 3.0 entity beans with annotations. I've been asking them why Hibernate 3.0 is in this mix and noone can seem to tell me. It feels like they've included Hibernate 3.0 because they were told to but are not using it for anything that they can't get from EJB 3.0 entity beans/JPA. They're using CMP and accessing all of the database functions via EJBs.
Can Hibernate give you anything in this setup that can't be provided by EJB 3.0/JPA?
Hibernate does have a JPA implementation but it can also be used standalone. It is possible to use Hibernate as the persistence provider in JavaEE. The JBoss application server for example uses Hibernate for its persistence. So if you are using Hibernate to provide the persistence in the app server, it may make sense.
If you are using an app server that does not use Hibernate for the persistence, then it sounds like you might not need it. Hibernate does have some extensions and things that are not available in JPA. Many other persistence providers also have these extensions (like Toplink or Eclipselink). Check with your app server provide to see if they have the extensions you might need or something similar to what you might have used in Hibernate.
JPA itself is just a specification, not a product, it cannot perform persistence or anything else by itself. JPA is just a set of interfaces and requires an implementation (a persistence provider). There are open source and commercial JPA implementations (Toplink Essentials, EclipseLink, Hibernate EntityManager, OpenJPA, Kodo, etc) and any Java EE 5 (or Java EE 6) application server must provide support for its use (JBoss uses Hibernate EntityManager, GlassFish v2 uses Toplink Essentials by default, GlassFish v3 uses EclipseLink by default, WebLogic uses Kodo by default, etc)1.
Now, one of the nice things with JPA is that it can be used outside a container, for example in a Java SE application or in a testing context (that was one of the big problems with EJB 2.x). But in that case, you need to provide an implementation as you won't get the one provided by the container. As we saw, Hibernate EntityManager - which is build on top of Hibernate Core - is one of them and this may explain why you see it.
1 Note that most (all?) containers offer a way to replace the default implementation that they provide. It is for example possible to use Hibernate instead of Kodo with Weblogic or instead of EclipseLink with GlassFish. This may be another reason why you see it in the mix.