I have understood that if I use EJB in Spring context, I get all the same benefits as if I was using it in "pure" EJB3 environment, is this true? I have googled but can't find a definitive, clear answer.
For example, let's say I have a session bean that updates some tables in the database and it throws a System Exception. In "pure" EJB3 environment the transaction is rolled back. What if I for example #Autowire this bean using Spring, does Spring take care of the transaction handling same way as does the EJB3 container? Or what? Does it maybe require some specific configuration or is it fully "automatic"?
I have understood that if I use EJB in
Spring context, I get all the same
benefits as if I was using it in
"pure" EJB3 environment, is this true?
You usually use either POJO + Spring or EJB3. I'm a bit confused by what you mean by "EJB in Spring"...
POJO + Spring and EJB3 are quite close now, and have the same facilities when it comes to declarative transaction management.
I don't know all the details about security, but I would say that both technologies are also very similar.
Actually both Spring and EJB3 rely on other specifications. The important ones are: JPA (persistence), JTA (distributed transaction), JMS (messaging), JDBC (data sources). Good support for that exist in the two technology stacks.
Both technologies have become very flexible and you can choose what to use or not. So you can have EJB3 in an app. server and be very light. Or you can use Spring with all modules which is almost as heavy as a full-fledged app. server.
I think the EJB3 model is still a bit richer, with things like remoting, stateful session beans (SFSB), container-managed transactions, and extended persistence context. Plus the possible support of clustering depending on the app. server. But these are advanced features which are use seldom (and IMO require expertise).
See EJB3 vs Spring
spring has many features, one of which is transaction management, which uses a common abstraction accross all different orm implementations (jpa, raw hibernate, jdbc, jdo etc). The default behavior is that in a transactional method, a runtime exception causes a rollback (which is probably what you want), but you can also fine-tune the rollback rules.
However, none of this requires EJB. If you don't use EJBs (stateless, stateful, mdbs), JPA will be enough for that, and the spring jpa support is excellent. In 90% of the cases spring will provide everything you need without EJBs.
EDIT:
read this about Spring EJB integration
You can have Spring handle transactions and roll back accordingly. You have to configure it to do so, but that's also true of EJBs.
Nothing in life is truly "automatic". You have to tell the code what you want sometime.
The real question is: Why do you think you need both EJBs and Spring? Anything you can do with EJBs can be done using POJOs with Spring. What are EJBs buying you here?
I got very good answers with links to articles, and from those I compiled my understanding that yes, the session beans work the same way regardless of if they are used with Spring or without, as long as the beans are defined in the Spring context with <jee:jndi-lookup>. Also found a good, simple article about this: http://java.dzone.com/articles/ejb-30-and-spring-25
However I can't accept just one answer because to me they are all equally good, but none of them exactly in point :) Could be that my question was not clear enough to start with...
(It was suggested that I post this as an answer to my own question)
Related
I was wondering, Should I know EJB as a prerequisite for CDI ? for I've read few CDI samles, found a punch of EJB annotations mixed up with CDI code, If not, Would studying EJB simplifies CDI studying ?
looking forward to reading your awesome answers, thank you .
No EJB is not a prerequisite for CDI but it will help. Refer to this
CDI article for clear distinction.
CDI is a technology you would use to avoid having to manually figure out the dependencies between your objects. With CDI, you only declare that your objects (classes) is dependent on some other objects (classes). The 'CDI container' will create and inject this dependency for you on the runtime
EJB is a technology that focuses on helping you implementing some common enterprise programming problem (storing & retrieving data, invoking remote method etc.).
As of latest version of Java EE, the recommended way to create/obtain reference to EJB is via CDI, but CDI is also applicable for other resources such as datasources, JMS etc
So yes a little knowledge about EJB would help, but I'd say just limit to the basics, don't go too deep. There are vast amount of technologies within Java landscape. They change very fast, and often overlaps each other, so it's easy to get lost when you're trying to learn one. Just focus on CDI itself for time being.
Haven't used EJB3, but by reading a tutorial, EJB3 looks like mostly for manipulating data in database through JPA (of course, it contains other business logic). Just curious, if no database is quired, is it still beneficial to use EJB3 or it just adds complexity to an application? Will POJO be a better choice for implementation?
Big part of EJB benefits is coming from transactions and persistence.
But even without them you may benefit from EJBs. It can give you a proven clustering and balancing model. It can give you the declarative security. It can give you MDBs which are a convenient way to listen to JMS queues/topics and timers.
All above can be done using third-party libraries, such as Spring. EJBs though are highly consistent, while to get, for instance, clustering and security you may need to combine two products, and it's not guaranteed they will work together well and won't need much glue.
EJBs are transactional, distributed components deployed on an app server that manages lifecycle, threading, and other services. Persistence is just one type of EJBs. You still might find stateless, stateful, or message EJBs useful, even if you don't want to use entity beans.
With that said, you can create POJO components that are stateful, stateless, persistent or message-driven. You don't need EJBs; something like Spring can be a good alternative.
I need to implement a simple DAO bean, which also caches data read from the database. This DAO bean is used by stateless beans.
Because EJB3.0 doesn't support singleton beans, what would be the correct way to implement such a DAO bean? Is it ok to just use static variable to keep the cache?
We are using Oracle AS and not going to use clustering.
The "correct" way to do this in a somewhat cross-appserver way is to use a jmx mbean for the caching behavior. mbeans are singletons (per-app server) and can do things like threading and locking. depending on the appserver you use, of course, mbeans can be more or less difficult to work with in practice.
Most Application servers and JPA implementations offer some sort of built-in caching mechanism which is controllable by the user. It might be worthwhile investigating ways of accomplishing what you want without having to build a singleton.
One of the major issues with singletons and J2EE is that there is no easy way to handle them in a clustered environment.
That all said, I did find an article which makes some suggestions for possibly doing what you want under JBoss, and mentions a new #Singleton annotation for EJB3.1 so that may be a possibility. If that works for you, you should write up what you did as another answer to this question.
If you are running on Weblogic server, it is actually possible to implement a singleton bean that is also cluster-aware. I don't believe this feature exists on other application servers though.
I am a newbie to Java Web Application development. So far all I have used are plain old servlets, jdbc and jsps. I started to read about all the frameworks and I am totally confused and lost in the swarm of frameworks? So here are some questions I have:
Are EJB3 and Hibernate competing technologies or can they be used together.
If I used JBoss Seam, do I still need to use Hibernate for my ORM needs or Seam + EJB3 takes care of that?
What are the typical frameworks I will need to learn if I have to develop a webapp using JBoss Seam? Is it some or all of the following:
Seam (ofcourse)
JSF
EJB3
Hibernate
Spring Inversion of control container
Can I use JBoss Seam to develop an application on JBoss Portal?
thanks
Vikas
1. Are EJB3 and Hibernate competing technologies or can they be used together.
They have competing APIs (JPA is different from Hibernate's API) but Hibernate can be plugged in underneath JPA, just don't expect interoperability with things coded for Hibernate - notably jBPM (3.2) does not entirely interoperate even under Seam (2.1.1).
2. If I used JBoss Seam, do I still need to use Hibernate for my ORM needs or Seam + EJB3 takes care of that?
As I understabnd it, you can do either.
3. What are the typical frameworks I will need to learn if I have to develop a webapp using JBoss Seam? Is it some or all of the following: Seam (ofcourse) JSF EJB3 Hibernate Spring Inversion of control container
JSF - essential for Seam to really make sense afaict - I recommend focusing on facelets as a primary way of creating JSF pages. The syntax is nice and familiar - plain old namespace qualified XHTML with server side components sitting within separate namespaces. Utterly trivial and clean, unlike pretty much anything else I've tried.
EJB3 - if you like, or not, up to you. Heading this way drags you into Java EE which still scares me a little, though it has many benefits.
Hibernate - if you like, up to you. JPA entity managers provide the alternative.
Spring IoC, er... yeah sure if you like, again its up to you. Seam takes care of stateful session and conversation scoped beans (generally part of your presentation logic tier) and Spring is best for the stateless context, such as interfaces to back end services such as databases and any SOA clients.
I've found Seam + JSF (facelets) + Hibernate + Spring to be quite a good combination for creating UIs over jBPM and also on another project for delivering content pages, though that is not really what Seam is for.
Can I use JBoss Seam to develop an application on JBoss Portal?
Sorry, can't help you there.
Yes and no. EJB3 (or rather JPA) is a specification for declaring OR mappings via Java5 annotations, and for interfaces to query them. You still need an implementation. Hibernate Annotations would be an implementation of the mapping, and Hibernate EntityManager is an implementation of the query interfaces - they use the "main" Hibernate to do their work. You should be able to mix and match those - it's possible to use JPA annotations, and use Hibernate's APIs like HQL and Criteria.
Depends, mostly on the appserver. A full-featured application server could deal with the JPA stuff for you and you'd configure things through web.xml and the appserver console. Of course, that excludes mix-and-match. You can still roll your own regardless of the appserver though, accessing the query API programatically / using Spring / whatever.
JSF is a prerequisite for using Seam. As for EJB3/JPA versus Hibernate - matter of preference. You don't really need to know much / any Hibernate to use it as a JPA implementation. JPA is strongly based on Hibernate's APIs, so the difference is likely to be fairly small either way. Spring is not strictly necessary, JBoss is trying its darnedest to get some of its market share with Web Beans. Some features of Seam overlap with some features of Spring. Spring is highly modular though and covers a lot, so you should be able to cherrypick Spring features you want.
Wouldn't know.
JBoss Seam is a meta-framework that combines the EJB3 and JSF frameworks, and wraps them with a form of dependency injection. As a J2EE technology, you usually deploy it inside an application server - this is where JBoss Portal comes in.
JBoss Portal is a commercial offering from the JBoss organisation. It bundles various J2EE components together in the form of "modules", These components will include EJB3, JSF, and the JBoss Application Server.
Check out this link, and scroll to the bottom to find out where Seam and Portal fit together. The Portal site describes the modules that it provides (I assume there is a pricing model attached to them), Seam support is provided by the Portlet module.
EJB3 and Hibernate are complementing technologies. EJB3 defines JPA (API) and Hibernate can be used as persistence provider for JPA.
You still need to use one of persistence providers which could be Hibernate, OpenJPA, etc.
JSF and EJB3.
Regarding Seam and Portal development: better question would be is how well JSF and Portal work together?
They do work together of course - here is relevant tutorial: Developing Portlets using JSF, Ajax, and Seam
Regarding question #4.
JBoss Seam can be used inside of JBoss Portal if a bridge is used.
There is currently a JBoss Portlet Bridge project that is in CR stage and approaching release.
I have a large application that uses EJB 2.x entity beans (BMP). This is well-known to be a horrible persistence strategy (I can elaborate if necessary).
I'd like to start migrating this application to use a much more expressive, transparent, and non-invasive persistence strategy, and given my company's previous experience with it, Hibernate 3.x is the obvious choice.
Migrating to Hibernate is going to take a while, as over 100 tables in the application use entity beans. So I'm looking at a phased approach where the two persistence strategies run in parallel, ideally on the same tables at the same time, if possible.
My question is, what are the pitfalls (if any) of combining these two persistence strategies? Will they get in each other's way?
As said jodonnel, you have to pay attention to caching, because if you use second-level caching in Hibernate and a table is modified outside of Hibernate, then Hibernate has no way to know that its cache entry is stale.
For the transactions, they should both use JTA provided by the container, so for that it should be safe.
I guess the thing to really be careful with is working with the Hibernate sessions. Hibernate caches stuff, and that might get in the way.
Frankly I would recommend that if you adopt Hibernate, drop the Entity beans entirely. Do your Hibernate work within session beans and let the session beans manage your transactions.
Or alternately use EJB 3, which is Hibernate standardized into the Java Persistence API.