(JSF + JPA) - EJB = Bloat

Without an EJB you will need for every EntityManager interaction at least 4 lines of code:

  1. tx.begin
  2. EntityManager interaction
  3. tx.commit
  4. consistent error handling +  tx.rollback

The creation and management of an EntityManager is not even included. The code will look like this:

public class ManufacturerJpaController {

    private EntityManagerFactory emf = null;

    public ManufacturerJpaController() {

        emf = Persistence.createEntityManagerFactory("WithOrWithoutEJBPU");

    }

    public EntityManager getEntityManager() {

        return emf.createEntityManager();

    }

    public void create(Manufacturer manufacturer) throws PreexistingEntityException, Exception {

        EntityManager em = null;

        try {

            em = getEntityManager();

            em.getTransaction().begin();

            em.persist(manufacturer); // the only interesting method

            em.getTransaction().commit();

        } catch (Exception ex) {

            if (findManufacturer(manufacturer.getManufacturerId()) != null) {

                throw new PreexistingEntityException("Manufacturer " + manufacturer + " already exists.", ex);

            }

            throw ex;

        } finally {

            if (em != null) {

                em.close();

            }

        }

    }

With a single EJB 3 you can eliminate all the bloat - the EntityManager will be properly managed and injected by the container. The same code will look like:

@Stateless

public class ManufacturerFacade {

    @PersistenceContext

    private EntityManager em;

    public void create(Manufacturer manufacturer) {

        em.persist(manufacturer);

    }

 

You could even build a generic and reusable CRUD Service. The @Stateless session bean can be directly injected into the backing bean then:

@ManagedBean (name="manufacturerController")

@SessionScoped

public class ManufacturerController {


    @EJB private ManufacturerFacade ejbFacade;

There is no additional XML, libraries or additional frameworks needed. You can just jar everything in a WAR and you are done. Btw. the whole EJB 3 container in Glassfish v3 is < 1MB. The project WithOrWithoutEJB was pushed into: http://kenai.com/projects/javaee-patterns/. An average, incremental deployment takes < 1 second.

[See Chapter 1 (the basics), page 27, 37, 46 in "Real World Java EE Patterns Rethinking Best Practices" for state / transactions, dependency injection and JPA+EJB synergies]

Comments:

improvement you can put the transaction code in a template class...

or use spring for transaction handling then the code will look like this:

public class ManufacturerFacade {

@PersistenceContext
private EntityManager em;

@Transactional
public void create(Manufacturer manufacturer) {

em.persist(manufacturer);

}

But I get your point, with EJB no dependency like spring in the project is need ... but you get a big depenency to an EJB Container on runtime...

Posted by Christian on October 01, 2009 at 01:14 PM CEST #

@Christian,

but the EJB 3 container is already there - there is no need to install something else.

There is no difference whether you are dependent at runtime on Spring, Guice, HiveMind, PicoContainer, EJB or any other IoC container.

Do you need some configuration - or is your example complete?

thanks for the sample & feedback!

thanks,

adam

Posted by Adam Bien on October 01, 2009 at 01:59 PM CEST #

Yes you need a spring configuration for sample.

But you can run the application autside a JEE container thats for example important for database integration testing in a Java SE enviroment. Or how can you do integration testing with the EJB sample?

Example Config:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">

<tx:annotation-driven transaction-manager="transactionManager"/>

<bean id="manufacturerFacade" class="ManufacturerFacade">
</bean>

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName">
<value>???</value>
</property>
<property name="url">
<value>???</value>
</property>
<property name="username">
<value>???</value>
</property>
<property name="password">
<value>???</value>
</property>
</bean>

<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource">
<ref bean="dataSource"/>
</property>
</bean>

<bean id="transactionManager"
class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory">
<ref bean="entityManagerFactory" />
</property>
</bean>

</beans>

Posted by Christian on October 01, 2009 at 02:53 PM CEST #

Christian's point doesn't make any sense. His example code is exactly the same as Adam's EJB code, except it has Spring's proprietary @Transactional annotation instead of a EJB's @Stateless annotation, which implies transactions are enabled.

Big dependency on an EJB container? As Adam pointed out in one of his earlier blog posts, EJB 3.1 container is smaller and lighter than the Spring CONTAINER, plus you don't need any Sping DEPLOYMENT DESCRIPTORS or .jar dependencies when used in an application server.

For a long time there have been ways to fully unit test EJBs outside of the application server. For example, OpenEJB and ejb3unit.

Add the nearly finalized JSR299 to EJB 3.1 and you get the industry's latest generation of DI capabilities.

Posted by Ryan de Laplante on October 01, 2009 at 04:18 PM CEST #

We already know that the Spring container is going to become an EJB 3.1 Lite implementation, which means it won't support remoting, asynchronous method calls, timers, and JMS. I think it is crazy to not implement the full EJB 3.1 spec (minus EJB 2.x backward compatibility) because the Spring 3.x container already supports these features.

I would be very surprised if the Spring 3.x container doesn't become a JSR 299 implementation since JSR 299 now implements the same DI annotations as the Spring container (JSR 330), matches all of the Spring container's DI capabilities (I hear the Spring container implemented ideas from JSR299 before the spec was complete to look like they were first), and does what the Spring container's Web Flow addon does.

I realize SpringSource has consistently said that JSR 299 will likely not make it into Java EE6, but of course they are going to spread FUD to prevent Java EE 6 developers from shedding their use of the Spring container for better DI. I think JSR 299's recent move to use JSR 330 annotations might change SpringSource's opinion of it.

I think the industry is going to prefer JSR 299/330 and EJB 3.1 annotations over proprietary Spring/Guice/Pico container annotations, and only use proprietary features where the spec lacks. This has already happened with JPA. I think the majority of developers now prefer JPA's standard annotations and configuration, and only use Hibernate or TopLink specific annotations, classes and configuration where JPA is lacking a feature until JPA 2.0 comes out.

Posted by Ryan de Laplante on October 01, 2009 at 04:50 PM CEST #

EJB3 + Wicket = dream environment.

I hope that we will be better integration efforts for EJB3 in Wicket. I just don't understand the reluctance to fold this into the core of the framework. Maybe more of us need to 'speak up' on this before it will come to pass. Count me in.

Posted by Jeff on October 01, 2009 at 05:18 PM CEST #

@Christian,

I would say: the needed configuration slightly outweigh the source code :-).

For Java SE tests see: http://www.adam-bien.com/roller/abien/entry/embedding_ejb_3_1_container

thank you very much for your example!,

adam

Posted by Adam Bien on October 01, 2009 at 05:43 PM CEST #

Ryan,

@Transactional is not really relevant here. Spring can easily wrap the example class, or a higher level class (i.e. higher up the call stack), transactionally, using a number of mechanisms, including the use of Spring's @Transactional annotation, including the use of EJB's somewhat weaker @TransactionManagement annotation, and including the use of externalized AspectJ expression language. Transactionality can be applied via either proxies, or AspectJ bytecode weaving, the latter having significant advantages over what is going to happen (proxy based) in most EJB containers, as there is no self invocation issue.

But as I said, transactionality is not really relevant here. The point is, the Spring code can look like this:

public class ManufacturerFacade {

@PersistenceContext
private EntityManager em;

public void create(Manufacturer manufacturer) {

em.persist(manufacturer);

}

As anybody can see, this is even less verbose than the EJB 3 sample (no need to declare this an @Stateless bean.

And this runs in any Java environment, including a standalone daemon application if you want.

>> We already know that the Spring container is going to become an EJB 3.1 Lite implementation
>> I would be very surprised if the Spring 3.x container doesn't become a JSR 299 implementation
>> I hear the Spring container implemented ideas from JSR299 before the spec was complete to look like they were first

Yes, a little bird told me lots of things too, but I don't go writing them on the Internet as fact.

I don't even know where to begin with the stuff in this post. We don't in fact already know that Spring is going to become an EJB 3.1 Lite implementation, because no such fact has been officially announced in any way. Something like this is a standard pure product management decision, and if it happens, will happen when it's clear that it adds value to the average Spring user. Your speculation about Spring 3 becoming a JSR-299 container doesn't make it any more likely. FWIW, almost everybody involved with JSR-330, including the Spring developers, the Guice developers, and pretty much anybody not actually already involved with JSR-299, does not believe in the value of JSR-299. This is why JSR-330 exists.

Putting out speculation, as fact, and putting out speculation, as speculation, when there's no real basis for it, adds no value for anybody, and makes it harder for people to make decisions on an informed basis.

Colin

Posted by Colin Sampaleanu on October 01, 2009 at 07:41 PM CEST #

@Colin,

but you neither need @Transactional, nor any XML configuration. Actually - I didn't wanted to compare Spring with EJB - it wasn't my intention.

I wouldn't consider an annotation as being verbose, even in that case Spring needs one annotation more + some XML configuration :-),

thanks for your insides!,

adam

Posted by Adam Bien on October 01, 2009 at 11:03 PM CEST #

Adam,
Thank you for the clarifying post. I'm new to JEE and I've been doing things like the first part of your post, 4 lines of code everytime. I'm going to start using the cleaner method.

Thanks,
Mike

Posted by Hoit on October 02, 2009 at 01:25 AM CEST #

@Hoit,

yes - many samples use the first strategy. Just by introducing a single EJB 3 can save you a lot of typing.

Enjoy Java EE!

adam

Posted by Adam Bien on October 02, 2009 at 01:36 AM CEST #

@Jeff, I agree with you fully! Although sometimes I sense that the Wicket community is quite anti-EJB and very pro-Spring, even sometimes to it's detriment.

Posted by Alan Garfield on October 02, 2009 at 04:47 AM CEST #

@Colin

> We don't in fact already know that Spring is going to become an EJB 3.1 Lite implementation because no such fact has been officially announced in any way. Something like this is a standard pure product management decision, and if it happens, will happen when it's clear that it adds value to the average Spring user. <

* September 2008 - Minute 23:20 Rod Johnson says that Spring framework will implement EJB 3.1 Lite to achieve Java EE 6 Web Profile certification for the Spring Application Platform.
http://weblogs.java.net/blog/van_riper/archive/2008/09/rod_johnsons_sv.html

* SpringOne December 2008 - "No, Spring will never support the full EJB spec, but they're supporting things like JAX-WS already, they plan to support WebBeans, and EJB 3.1 Lite, among others when they pass the vote."
http://www.jroller.com/Solomon/entry/spring_one_themes

* August 2008 - "Indeed, I am curently working with SpringSource on an EJB 3.1 Lite implementation for the Spring framework/platform that should make such integration even easier (essentially a follow-up to the Spring Pitchfork project intiated by BEA but not followed through)." - Reza Rahman, EJB 3.1 expert group member.
http://java.dzone.com/articles/ejb-30-and-spring-25#comment-6184

> And this runs in any Java environment, including a standalone daemon application if you want. <

Correct me if I am wrong, but the same applies to POJOs intended for EJB. Use them without a container and do all the transaction management, injection, etc. yourself like in Adam's first example, or use an embeddable EJB container like OpenEJB. EJB 3.1 standardizes APIs for initializing and shutting down Java SE embeddable containers.

>> I hear the Spring container implemented ideas from JSR299 before the spec was complete to look like they were first <<
> Yes, a little bird told me lots of things too, but I don't go writing them on the Internet as fact. <

I hate to put words in someone's mouth, but I'm almost certain it was someone from the JSR-299 expert group that said this on their blog, or maybe in comments somewhere, with a specific example. I can't find the link.

> FWIW, almost everybody involved with JSR-330, including the Spring developers, the Guice developers, and pretty much anybody not actually already involved with JSR-299, does not believe in the value of JSR-299. This is why JSR-330 exists. <

... which strikes me as odd because JSR-330 annotations directly map to JSR-299 draft annotations but with different names, and JSR-330 is a subset of what JSR-299 has to offer.

@Qualifier is equivalent to @BindingType,
@Scope is equivalent to @ScopeType,
@Singleton is equivalent to @ApplicationScoped,
@Named is just a built-in binding type, and
Provider<X> interface is equivalent to Instance<X>.

http://in.relation.to/11211.lace

When SpringSource does not believe in the value of major JSR-299 features that do not overlap JSR-330, I get the impression that SpringSource also does not believe in the value of Spring WebFlow.

Posted by Ryan de Laplante on October 02, 2009 at 05:25 AM CEST #

@Colin

Also to your point on JSR 330 vendors not believing in the value of JSR 299:

"Over the past few weeks, we've had a number of conversations between the major Java EE vendors regarding the inclusion of Web Beans (JSR-299) in the Java EE 6 platform."

...

"The really good news is that there is now unanimous agreement between the folks involved in these discussions that:

* the EE platform needs a contextual dependency injection solution with capabilities that match the capabilities of existing proprietary solutions
* the approach taken by JSR-299 is, overall, a good one
* that the goal of this work is inclusion of JSR-299 in all Java EE 6 profiles, and in the "embedded" EJB Lite environment"

http://in.relation.to/Bloggers/NewsOnTheJSR299PublicReview

Posted by Ryan de Laplante on October 02, 2009 at 06:13 AM CEST #

Not sure why you can't create an EJB3 integration module for Wicket using the existing extension points already in core. If your extension became very popular, it could be folded into wicket-extensions (which IS a part of the official Wicket distribution right along with the core proper), but a specific technology integration like this simply doesn't fit into Wicket's minimalist core which is really focused on programmatic manipulation of markup and as little else as possible. It's a matter of design philosophy, as described in my original vision statement on the Apache Wicket site.

Posted by Jonathan Locke on October 02, 2009 at 07:54 AM CEST #

PART 1 OF 2 - THE BLOG SOFTWARE IS LIMITING POSTING LENGTH TO 5000

---

Ryan,

> * September 2008 - Minute 23:20 Rod Johnson says that Spring framework will implement EJB 3.1 Lite to achieve Java EE 6 Web Profile certification for the Spring Application Platform.
http://weblogs.java.net/blog/van_riper/archive/2008/09/rod_johnsons_sv.html

If you actually listened to this, you would have figured out that he was talking about the "SpringSource Application Platform", aka the name for the SpringSource dm Server, before it was finally released in the 1.0 version as dm Server. He was not talking about Spring Framework. What Rod said was "... when a little further down the track we expect to make the SpringSource Application Platform implement EJB 3.1 lite so it can get Profile A and B certification for Java EE 6."

> * SpringOne December 2008 - "No, Spring will never support the full EJB spec, but they're supporting things like JAX-WS already, they plan to support WebBeans, and EJB 3.1 Lite, among others when they pass the vote."
http://www.jroller.com/Solomon/entry/spring_one_themes

I presume Solomon is also talking about the "plan" to support EJB 3.1 Lite in dm Server. Again, not Spring Framework.

> * August 2008 - "Indeed, I am curently working with SpringSource on an EJB 3.1 Lite implementation for the Spring framework/platform that should make such integration even easier (essentially a follow-up to the Spring Pitchfork project intiated by BEA but not followed through)." - Reza Rahman, EJB 3.1 expert group member.
http://java.dzone.com/articles/ejb-30-and-spring-25#comment-6184

Figuratively speaking, Reza is smoking some serious crack. From memory, he emailed Rod at some point and suggested that he (Reza) wanted to do an EJB container on top of Spring, and Rod encouraged him to go ahead and do it. This is not "working with SpringSource". There has never been any work or agreement or any actual collaboration with Reza. People who actually know Spring, and who have listened to Reza, know that Reza, while he may know EJB, is not an authority on anything related to Spring. Reza has been visiting JUGs for 2+ years doing presentations espousing the benefits of EJB over Spring, while not having the time to actually learn Spring properly. Mark Fisher, in this post here, http://blog.springsource.com/2007/11/09/a-response-to-ejb-3-and-spring-comparative-analysis/, gets into some of the issues, although having seen Reza's presentation myself, I think Mark is much too kind.

What is troubling is that this all builds up. When you and other people post speculative, erroneous, or unsubstantiated statements as facts, other people start reading that as the truth, and keep on spreading it on and on. At some level it's also essentially a feedback loop as it's the same group of people.

CONTINUED BELOW...

Posted by Colin Sampaleanu on October 02, 2009 at 08:08 AM CEST #

PART 2 OF 2 - CONTINUATION OF THE ABOVE COMMENT

---

>> And this runs in any Java environment, including a standalone daemon application if you want. <

>Correct me if I am wrong, but the same applies to POJOs intended for EJB. Use them without a container and do all the transaction management, injection, etc. yourself like in Adam's first example, or use an embeddable EJB container like OpenEJB. EJB 3.1 standardizes APIs for initializing and shutting down Java SE embeddable containers.

Your logic is flawed. Why should you ever have to do everything yourself? So you can run those EJBs without a container, and do everything yourself. Or you could use OpenEJB, a little known and little used embeddable container, to get a minor subset of what you get in Spring. Or you could wait up to 2 or 3 years for your major container vendor (WebSphere, JBoss) to put out a supported version that does Java EE 5. Or you could have all along used rock solid, supported, Apache Licensed Spring, that runs in any Java 1.4+ VM such as a simple daemon, a servlet engine, or even one of the full Java EE app servers, get access to way more features (including access to all Java EE features you care about), and pick and chose exactly what you need...

>>> I hear the Spring container implemented ideas from JSR299 before the spec was complete to look like they were first <<
>> Yes, a little bird told me lots of things too, but I don't go writing them on the Internet as fact. <

>I hate to put words in someone's mouth, but I'm almost certain it was someone from the JSR-299 expert group that said this on their blog, or maybe in comments somewhere, with a specific example. I can't find the link.

"I heard" statements that can't be backed up mean nothing. On top of which, even if you could point to who said, it, what does that mean, of any value? One person saying, in unsubstantiated fashion, that JSR-299 thought of something first doesn't mean Spring didn't actually do it first, or the stuff wasn't developed in parallel. Frankly, I don't even care who implemented something first. Spring implemented tons of things first. There are lots of things in JSR-299, EJB 3.1, EJB 3, etc., that Spring did first. Does this really matter? No. What matters is that Spring, an Apache Licensed open source product that has become a de-facto standard, is a rock-solid product that has been providing value to people since 2004, has had each release add new functionality while continuing to simplify the usage model and maintain backwards compatibility. At the same time, JSR-299 is another convoluted design by committee mess that will take years for container vendors to implement, and will probably, based on past history, get limited usage...

>> FWIW, almost everybody involved with JSR-330, including the Spring developers, the Guice developers, and pretty much anybody not actually already involved with JSR-299, does not believe in the value of JSR-299. This is why JSR-330 exists. <

>... which strikes me as odd because JSR-330 annotations directly map to JSR-299 draft annotations but with different names, and JSR-330 is a subset of what JSR-299 has to offer.

The fact that a subset of JSR-299 maps to JSR-330 at some level (and the mapping was not that actually that clean) does not make JSR-330, by extension, a good thing. The whole point is that a group of people representing the products (such as Spring, Guice, etc.) used by the vast majority of end users for dependency injection, are the people who created JSR-330. This same group felt that there was and is a bunch of stuff in JSR-299 that doesn't make sense, and shouldn't be in a standard. This is why JSR-330 exists. I should also add that one of the two main initiators of JSR-299, Bob Lee (of Guice), gave up on JSR-299, and helped create JSR-330...

Regards,
Colin

Posted by Colin Sampaleanu on October 02, 2009 at 08:10 AM CEST #

Colin,

You are the first to point out that none of the information about SpringSource's EJB 3.1 Lite implementation is correct. At least acknowledge that I'm not spreading _baseless speculation_ on this point. I'm sure that I'm not the only person who listened to Rod's entire video presentation, the SpringOne 2008 keynote(?), or who read Reza's comments about working with SpringSource on an EJB 3.1 Lite implementation, and understood this information to be fact. If you saw mis-information being spread around and around the web by the same few people, why didn't you speak up sooner? Now that you have clarified this point, I will no longer help to spread it.

I think you are missing my point about OpenEJB. You pointed out that the Spring container is usable in the Java SE environment and made it seem as if EJBs cannot. Sure not many people use EJB outside of an application server, but that doesn't change the fact that they CAN. That's all I was trying to say.

I'll end with my perspective on Java EE standards. I don't currently and never have looked to the JCP for innovation. The industry finds problems that need solving, many companies put out a solution, and over a period of years these solutions are refined. The job of the JCP is to get the people involved in all of these solutions and come up with a standardized API moving forward. JPA 1.0/2.0, JSR-310 (Date & Time API), JSR-303 (Beans Validation), JSR-224 (JAX-WS), JSR-311 (JAX-RX), JSF *2.0*, and even JSR-299 are examples of this. All of them brought together the industry experts (at least those that would participate) and created a standardized API based on existing technologies. Evidence that SpringSource sees some value in JCP standards is their desire to certify the Spring Application Platform as Java EE 6 Web Profile, their involvement in JSR-330, and Rod's position on the executive committee. I've heard Rod say on many occasions (more online videos and interviews) that it is not the JCP he doesn't like, it is specific JSRs like EJB. Up until Java EE 6 I've been using the Spring framework and agreed about it's superiority to EJB because of the DI capabilities. I still think that EJB 3.1 + JSR-299 will be a game changer, regardless of Bob Lee abandoning JSR-299. You don't have to agree. That is just my opinion, and I'll try to be less brash about it in the future.

Ryan

Posted by Ryan de Laplante on October 02, 2009 at 09:54 AM CEST #

@Jonathan Locke,

I'm using right now the existing Java EE extension and works perfectly for injection of EJB 3 session beans into WebPages.

It is also minimalistic - you can deploy a plain WAR, without any additional frameworks or libraries required.

The only caveat - you have to specify a reference to an EJB in web.xml, what is actually not needed.

EJB 3 + Wicket = the leanest possible solution,

thanks!,

adam

Posted by Adam Bien on October 02, 2009 at 11:37 AM CEST #

@Ryan,

SpringSource already implemented an EJB 3.0 container: http://www.springsource.com/pitchfork

Your statements that SpringSource will support EJB are interesting - see slide 32 (Rod's Future Of Enterprise Java Keynote): http://blog.springsource.com/wp-content/uploads/2008/04/JAX%20Keynote%20-%20Future%20of%20enterprise%20Java.pdf

Would SpringSource invest in a "dead" technology :-)?

The future will be really interesting,

thanks for the great comments!,

adam

Posted by Adam Bien on October 02, 2009 at 11:55 AM CEST #

@Adam

re: @Jeff, I agree with you fully! Although sometimes I sense that the Wicket community is quite anti-EJB and very pro-Spring, even sometimes to it's detriment.

You take the words right out of my mouth, Adam. Yes, I believe you are right. I sense the same reluctance and anti-EJB sentiment. I believe, though, it isn't so much the wicket community but rather the core committers to the project. They project the appearance of being just anti EE. When you consider how interfacing support for Spring and other containers have been folded into the core wicket libraries it makes me scratch my head in amazement that EE support has been delegated and left to add-ons whose support and reliability are questionable at best.

I think it is in part driven by perceptions of EE that may have been formed prior to EE2 and when it was considered overly complex and over weight. If I am correct then those who still believe this need to reexamine EE in its current state.

I recently spoke with a company CIO who told me that they rulled out using Wicket just because of its lack of support for EE. They were aware that addons were available but they weren't satisfied with going this route. They expressed concern that a great framework like wicket could become a non entity in corporate environments due to this fact. As someone who wants to see wicket embraced in the corporate environment I find this situation alarming to say the least and I share their concern.

But I am a believer in positive thinking so I believe that eventually the core wicket project committers will see the light of day and embrace supporting EE as they have other containers. Hopefully that day will be sooner rather than later.

Best regards,
Jeff
http://jeff-schwartz.blogspot.com/

Posted by Jeff Schwartz on October 02, 2009 at 05:51 PM CEST #

Collin,

* Figuratively speaking, Reza is smoking some serious crack.

- OK, I think you are more than a little out of line here and are misinformed. Last I checked, Rod was open to hosting this project on SpringSource and offered his full cooperation. We even went so far as to discuss a team structure and schedule. In fact, I am trying to initiate this project via Caucho right now and will approach you guys once again.

As to your comments about essentially my not knowing what I am talking about, I think I'll let my material speak for itself, including my comments to the SpringSource objections to my talks. I've worked on Spring for quite a few years now on quite a few projects. I think that's experience enough to be able weigh the comparative benefits of a technology...

If you don't think that is sufficient, I am happy to address whatever other concerns you have right now...

Calm down my friend,
Reza

Posted by Reza Rahman on October 02, 2009 at 06:57 PM CEST #

Folks,

Reading over this post, I feel I should say everything that I know in as much detail as I can about Spring EJB 3 implementation I have been trying to work on for a long while now.

As Adam already mentioned, SpringSource and BEA started project Pitchfork for better support of EJB 3.0 on the Spring framework. Being the author of EJB 3 in Action, this caught my immediate interest. To my disappointment, this project never went very far and looked to be dead in the water for a while. Asking around, I found out that it may have been abandoned from the BEA side (I don't know this for sure).

After considering these factors and talking to a few people (including the OpenEJB and JBoss folks) I decided to approach Rod about restarting the project and I asked him about it at JavaOne, including sending him a detailed written proposal. Rod responded that he was indeed interested and could possibly allow me to lead the project and offer any support that I would need, including hosting the project. We talked about implementing the project, including EJB 3.1 vs. EJB 3.1 Lite. Specifically, his concerns were around EJB 2.x backwards compatibility and CORBA support. It is true that Rod was reluctant to extend EJB 3.1 Lite support to the Spring framework proper. The weird part here is that Collin was one of the people Rod wanted me to work on for this project!! So the statements above are really confusing and personally disappointing to me as to the personal integrity of some of these people...

On my end, I was having serious trouble finding time for the project in the midst of consulting assignments, speaking engagements, etc. So I finally asked Rod for direct financial support for the project so that I could devote my time, full-time to it. He was initially interested but then told me at TSSJS that they are de-emphasizing the project and would not fund it but would still be interested in hosting it and providing any support I would need.

In the meanwhile, I got the opportunity to work with Caucho on Resin instead, which was an opportunity just to good to pass up. However, I have spoken about the project with Caucho as well and thankfully they did show real interest in it once I complete the work on Resin. I am really hoping I'll be able to start the project as soon as I can and approach Rod/SpringSource/VMWare again, asking for their support and cooperation. If not, I will try to launch the project with Caucho alone. Very honestly, I believe I am being nicer than I really need to be in doing so...

Other than time for the project, the other reason to try to get support/financial backing from a Java EE licensee is legal problems in creating an EJB container, an issue I've taken up with Sun without good results. If someone reading this thread has a good answer to these questions, please let me know. I am happy to hand over the project, including all of the initial research I've done into this to them if they believe they have the freedom and financial bandwidth to execute on it better than I can, even if it means a competing effort when I can get things aligned the best I can...

Kind regards,
Reza

Posted by Reza Rahman on October 02, 2009 at 07:56 PM CEST #

Ryan,

I agree with you (and many others like Gavin) about JSR 330 not being about technology but about self-serving FUD from SpringSource. Nevertheless, I supported it in Java EE 6 because I believed it is best to work with the likes of SpringSource so as to not give them more excuses for claiming the JCP doesn't work with them, etc. It is a shame (but not really a surprise) to see exactly that going on despite a show of good will from the members of the EG.

I for one, would actually like to hear a few engineering based objections to JSR 299 instead of self-serving political FUD.

Cheers,
Reza

Posted by Reza Rahman on October 02, 2009 at 08:13 PM CEST #

I know Spring is very popular. But my personal experianse is as follows:

I've read "EJB 3 in Action" and I like it (the EJB3 too :)).
I've started with "Spring in action" and after more than 20 pages of XML and after that <working> "Hello World" application I've stopped. I've decided that this is not my framework (or whatever name you give).

The main difference is that EJB3 is simple and understandable, EJB3.1 - better; Spring - not.

Sorry.

Posted by Emil Hurmuzov on October 03, 2009 at 12:51 AM CEST #

Thanks so much for your kind words on EJB 3 in Action and I am very glad you find EJB 3 useful. We'll continue to try to do our best to keep Java EE useful for all rank-and-file developers of all stripes.

That all being said, I really do hope that server-side Java remains a mixed environment going forward. As much as I don't like the needlessly antagonistic attitudes from some of the Spring framework proponents, Java EE owes a lot to Spring (and I believe the opposite is true as well).

My core viewpoint has always been to give developers a real choice not to have to choose between the two. That was and still is the driving motivation for my efforts to work with the Spring framework leadership to create true native support for Java EE in the Spring framework.

Cheers,
Reza

Posted by Reza Rahman on October 03, 2009 at 01:37 AM CEST #

I relate to many of the comments I've read here regarding Spring. I refuse to work with JSF for the same reason I refuse to work with Spring or any other product that requires an arm and a leg of xml.

Why on earth would I want to spend time debugging Spring when clients are paying me to create solutions for their business needs that they can understand and maintain. Try invoicing them for a few hours spent researching and debugging Spring. They would throw you out on your ear if you tried that.

No thank you - been there and done that and I will never do it again.

Jeff
http://jeff-schwartz.blogspot.com/

Posted by jeff schwartz on October 03, 2009 at 04:15 PM CEST #

Jeff--JSF 2.0 does NOT require "an arm and a leg of XML". You can now use annotations for managed beans (or just use web beans in an EE6 container), and a navigation handler is optional. The only XML you now need is web.xml (until the implementations embrace Servlet 3.0 yet) and the declaration of a message bundle in faces-config.xml--you can't put an annotation into a .properties file.

Posted by Cay Horstmann on October 03, 2009 at 05:18 PM CEST #

Reza,

I'd like to apologize for my choice of words, "Figuratively speaking, Reza is smoking some serious crack.". I wrote that comment after midnight at the end of a long day (and a long month) when pretty much anything would have been a better use of my time than having to come in here to explain this stuff.

But I will stand by the message I was trying to get across, that you misstated SpringSource involvement in any EJB 3.1 Lite implementation effort (with you, or anybody else). What is somebody supposed to think, when you write, "Indeed, I am curently working with SpringSource on an EJB 3.1 Lite implementation for the Spring framework/platform that should make such integration even easier (essentially a follow-up to the Spring Pitchfork project intiated by BEA but not followed through)."?

The simple fact of the matter is that SpringSource has never invested any engineering resources towards working with you (or anybody else) to implement EJB 3.1 Lite in Spring Framework, and SpringSource has no ongoing relationship or agreement with you towards this end. This is not what your statement implied.

It's pretty clear that your statement was inappropriate, just by the fact that Ryan de Laplant took it as one of the bases that _SpringSource_ is putting EJB 3.1 Lite support in Spring. I have seen others quote you too.

Let me be really clear: there is nothing wrong with you working on an EJB 3.1 Lite container built on Spring. There is a huge bunch of products out there built on top of Spring, that SpringSource and the core Spring developers are not involved in. Power to the community. It sounds like you haven't actually written any code (?), but power to you, when or if you want to do this stuff.

W/respect to my statement about your JUG presentations comparing EJB and Spring, I think Mark's blog post speaks for itself, I've got really nothing more to add. It's funny that you mention "personal integrity". Integrity is fundamentally about adherence to certain ethical principals, and honesty. Integrity is about carefully stating things as they are (e.g. any ongoing work with SpringSource), and with respect to your JUG talks, doing your homework to make sure that what you are putting out is accurate and balanced. There were serious issues with your JUG talk (I encourage anybody interested in just some of the details to read Mark's post via the link above), with frankly no excuse for a talk with that level of inaccuracy to be delivered in the first place, never mind on an ongoing basis. Anybody going away from your "comparative analysis" would have had a seriously flawed view of how Spring and EJB 3 compare.

Regards,
Colin

Posted by Colin Sampaleanu on October 03, 2009 at 05:23 PM CEST #

Colin,

It's good that you have a strong enough sense of self-awareness to see some of your own problems. I can certainly forgive passion for once's work, but not when it reaches a point when one fails to have any real respect for a viewpoint that does not coincide with their own...

I think agreeing to host a project and providing support (including engineering support) passes the qualifier for collaboration, not to mention serious consideration for financial support. As I've already stated, Rod never said he would include the work in the Spring framework, but he was very interested in including the project in the Spring application platform. I could include his correspondence with me here but will not as I see it as a violation of trust to keep correspondence confidential.

It's also good to see you are inclined to leave be your comments around my JUG talks instead of engaging in yet another futile flame war. For my part, I am willing to defend my personal integrity/work anywhere, with anyone, on any issue. It was my fault that I was too soft on Mark. My comments to his post should have had a lot more teeth than it did. Part of the motivation was not to alienate you and give you the benefit of the doubt. The other part of the problem was, has been and is my chronic shortage of time in doing all the things that I think are valuable...

Your collective actions since have proven to me without a shadow of a doubt that the benefit of the doubt was sadly misplaced, as your comments unequivocally reinforce yet once again (especially if they are endorsed by people like Rod and Adrian). I can promise you one thing - my personal interaction with antagonistic Spring proponents that choose to needlessly make things personal will have no reason for restraint going forward...I won't make that mistake again...

Best wishes,
Reza

Posted by Reza Rahman on October 03, 2009 at 08:13 PM CEST #

Folks,

To round out some of the comments above, here is a link to an updated version of the talk SpringSource has such objections about: http://www.redhat.com/f/pdf/jbw/rrahman_320_spring_framework.pdf. It was recently presented in JBossWorld 2009. Personally, I think every server-side Java developer should look at this presentation, read the comments by SpringSource as well as responses I made years ago. If there are questions to answer, I am happy and very proud to address them first hand...

Cheers,
Reza

PS: I've even gone to the length of getting this reviewed by a "spring expert" that SpringSource probably approves of before finalizing the slides...

Posted by Reza Rahman on October 04, 2009 at 01:00 AM CEST #

Reza,

It's a little bit ironic that you talk of defending your integrity. You had no problem attacking mine a little bit earlier :-)

> Your collective actions

Ahh, really? Feel free to call me anything you want, but I will stand up for Mark any day of the week. He is one of the most reasoned, professional individuals I have ever worked with. I can actually say the same for the vast majority of the people I've had the pleasure to work with at SpringSource. I guess Mark's crime was pointing out some real problems in your presentation. Understandable I guess; criticism never feels good.

> needlessly make things personal

There is nothing personal here. There are only some facts:

- you are not "working with SpringSource" on an EJB 3.1 Lite implementation for the Spring framework". That statement implies a heck of a lot, with respect to our involvement. I appreciate that you apparently emailed or talked with Rod about something at some point in the past. However, when any such discussion is so "confidential" that it gets to nobody else outside of you and Rod, does not result in any sort of ongoing agreement or collaboration that is visible to anybody, does not result in any engineering effort being expended on our part, does not result in anything being produced by us (or by you, apparently), it basically amounts to a bunch of hot air... And it is potentially damaging hot air because it helps people (Ryan is a great case in point) to have a mistaken opinion on some strategy we might take.

W/respect to you JUG presentation, again, I think Mark's blog entry speaks for itself. You presentation, done in Nov 2007, had serious issues. You had been doing similar presentations for quite a while; I saw a similar version in June or so of that year. When you are influencing hundreds or thousands of developers on an ongoing basis, there is just no excuse.

If the updated presentation from earlier this year fixes some of these issues, that's great. I'm happy at the thought that people will get a more accurate/balanced view on the topic.

Anyway, I have no doubt you'll come back with something, but I think this is probably it for me. Too much time wasted already. I should not have gotten involved in this whole brouhaha, but I can not stand to see people putting out statements and speculation about SpringSource or Spring, that are inaccurate.

I encourage anybody reading this thread to do their homework when making technology decisions: ignore speculation and hyperbole, ideally dig deep yourself to form informed opinions in important areas, but otherwise focus on balanced opinions by true subject matter experts, and consider multiple viewpoints.

Regards,
Colin

Posted by Colin Sampaleanu on October 04, 2009 at 06:51 AM CEST #

Colin,

You are right, I will come back with something...

All of the comments made about my JUG talks by anyone at SpringSource is pure self-serving FUD. You're inability to engage me on specific issues proves that beyond vague references to issues I've already addressed. That says volumes about whats this is really about. I have no problems with valid criticism, as long as it is actually based on reality and not marketing for the gullible or the ignorant.

I never said the project content itself is confidential, just the specific email communication verbatim - so you have another bogus argument there. I'd like to see what Rod has to say about it himself here. Why not get it right from the horses mouth? That would end the "speculation" right?

More importantly, it is irrelevant at this point. SpringSource support for the Spring-Java EE 6 bridge project does not need your support anymore. Matter of fact, it isn't even desired with Caucho on board with it. The only reason I really needed you was the Java EE license, that's it.

Sorry that talking about real issues is not something you have time for but clearly you have time for denigrating anyone that doesn't sign up for whatever you are serving up...

Cheers,
Reza

Posted by Reza Rahman on October 04, 2009 at 07:33 AM CEST #

Folks,

For completeness, here is a copy of the early presentation being referred to: http://phillyjug.jsync.com/meetings/ejb3springhibernate-comparison-by-reza-rahman.

The *only* changes made to this is the fact that it compares Java EE 6 to Spring 3, not EJB 3.0 to Spring 2.0 and Hibernate. All the other so-called criticisms offered by the angelic and selfless SpringSource people that can do no wrong were pure Red Herrings that I responded to in a timely fashion and did not effect any changes to the presentation. *Period*. And that includes the review by the "Spring expert".

There is one thing I do agree on Colin's statements. Make your own judgments, don't let anyone pull one over you - not me, not SpringSource, not the next snake-oil salesman that knocks on your door. I'd even say statements from so called "domain experts" are especially suspect...

Cheers,
Reza

Posted by Reza Rahman on October 04, 2009 at 08:00 AM CEST #

Colin,

Honestly want to know what your crime is?

Your crime is accusing a man that had no ill will towards you and made every sincere attempt to be fair; your crime is failing to acknowledge the hard work and dedication of people who contribute to a community but don't care to be in your particular ranks; your crime is failing to do what would really benefit the community the most and not yourselves; your crime is pursuing a monopolist's agenda; your crime is not respecting someone that reached out to you to work together to produce something useful...

Does that make things clearer for you?

Good luck and good riddance,
Reza

Posted by Reza Rahman on October 04, 2009 at 10:14 AM CEST #

Colin,

> I can not stand to see people putting out statements and speculation about SpringSource or Spring, that are inaccurate. <

That is why you got involved in this discussion. I got involved because I cannot stand to see people putting out statements and speculation about EJB or JSR-299, that are inaccurate. I will admit that I should have backed up my initial comments with the facts I used to base them on (like I did later in this thread) so that readers wouldn't perceive them as speculation (except my belief that EJB 3.1 Lite + JSR 299 is a game changer.) Lesson learned.

At this time (Oct 4 2009), JSR-316 / Java EE 6 Public Review requires EJB 3.1 Lite in the Web Profile (section WP.2.1). I knew that when posting my comments earlier this week, and I know that now. Rod Johnson talked about wanting Java EE 6 Web Profile certification for the Spring Application Platform in the video I linked to, and unless that has changed, or the Web Profile requirements change, SpringSource will have to implement EJB 3.1 Lite. Yes I misquoted Rod when saying EJB 3.1 Lite will be implemented *in the Spring framework*, and I'm sorry about that. Like some of your comments, I was writing late in the night too.

According to your comments above, the Spring Application Platform became the GPL licensed SpringSource dm Server. I know that SpringSource was previously engaged in an EJB 3.0 implementation on top of the Spring framework (not built-in) called Pitchfork, which is also GPL licensed. Will they use Pitchfork for their EJB 3.1 Lite implementation? I don't know. Will the EJB 3.1 Lite implementation also be GPL licensed? I don't know. I speculate that SpringSource will fight hard to remove EJB 3.1 Lite from the Web Profile requirements before EE 6 goes final so that they don't have to implement it, and that this is the reason you are denying everything I say about it.

I forgot to highlight an interesting quote from the JSR 299 spec lead's blog entry about the unanimous agreement between major Java EE vendors regarding the inclusion of Web Beans (JSR-299) in the Java EE 6 platform. One of the points they agreed on is:

"* that the goal of this work is inclusion of JSR-299 in all Java EE 6 profiles, and in the "embedded" EJB Lite environment"

.. the inclusion of JSR-299 in EJB 3.1 Lite. So, it is plausible that SpringSource will implement JSR-299 if the spec is accepted into the Java EE 6 platform and becomes an EJB 3.1 Lite requirement, and/or if JSR-299 becomes a Java EE 6 Web Profile requirement.

Ryan

Posted by Ryan de Laplante on October 04, 2009 at 05:14 PM CEST #

Ryan,

I should add what I know about this here too. Rod was indeed interested in getting Java EE 6 certified as far as the Spring application platform goes. Indeed, that was his major motivation for having an EJB 3.1 Lite implementation based on Pitchfork. He specifically inquired multiple times if EJB 3.1 Lite will be in the Web Profile.

You shouldn't apologize for anything you did as I see it. As far as I know, everything you said is (or was in the very near past) true and I have the proof to back it up if it comes down to that...

I also agree with you that SpringSource is likely plotting away to have JSR 299 and EJB 3.1 removed from the Web Profile. I can also tell you that won't succeed because JSR 299 already has backing from Oracle, Sun, Apache and Red Hat (not sure about IBM). The irony I think is that their stunt with JSR 330 is really what changed people's minds about JSR 299 - it certainly did for me.

And you are dead on about the pot calling the kettle black. They are the indisputable grand champions when it comes to spreading FUD and launching vicious personal attacks against people that stand in their way. You and I are hardly alone in that. They've done that to Bill Burke, Gavin and numerous others over the years. That's exactly why I think this is a dangerous, malevolent monopolist bent on a profit motive that needs a serious counter-weight, as opposed to more benign open source projects like Linux, the Apache web server and Tomcat.

Best,
Reza

Posted by Reza Rahman on October 04, 2009 at 08:24 PM CEST #

>And you are dead on about the pot calling the kettle black. They are the indisputable grand champions when it comes to spreading FUD

Right you are! The community is starting to notice this too. Some quotes from around the net:

"I do agree with you but most of the companis generally present salient features of their products rather than using FUD which, sadly seems to be the way of the spring community to respond to any criticism. It just shows their desperation on their part as coomunity is movin forward but Rod & co stil seem to be hung up on spring legacy. "
See: http://www.infoq.com/presentations/SpringOne-Keynote-Rod-Johnson#view_44060

"In the Netherlands we have a famous commercial featuring a salesman, clearly representing the company WC Duck, supposedly giving the audience an independent and unbiased advice of which toilet cleaning product they should use. It goes without saying that this incorruptible salesman gives the advice to buy... WC Duck products.
See: http://www.infoq.com/presentations/SpringOne-Keynote-Rod-Johnson#view_44033

Somehow Rod reminds me of this salesman."

"Their [Spring's] strategy is interesting. Instead of starting a completely new platform from scratch and trying hard to attract people to it, they piece by piece trap existing Java developers on this platform. Of course, this only works to some degree. If Spring is sufficiently separated from Java, then they really have to attract new people on their own merits.

Seen in this light the culture of bashing standard Java libraries is an understandable part of the strategy and might explain why Spring 'fans' are so eager to never miss such an opportunity. Although the strategy might be questionable, the end result of having 3 major platforms: Java EE, .NET and Spring might not be bad for the industry as a whole. "
See: http://www.theserverside.com/news/thread.tss?thread_id=54346#307734

Posted by Robert Tuinman on October 04, 2009 at 10:16 PM CEST #

Another (rather lengthy) quote on the same topic:

"I agree with you. The problem is that Spring zealots have been VERY focal in the past. I heard stories where hordes of Spring zealots where instructed to build up a number of 'digital lives' in the blogosphere and post on blogs and forums about the merits of Spring and the badness of Java. I know other organizations do this too (mostly those obscure SEO ones), but it's an indication to what length those zealots went.

Now if nobody listened, then they would be just zealots. But at some point of time they got some critical mass in the blogosphere. I started to notice when more than a few developers who were new to Java, started using Spring for their projects. I asked them in all honesty why they choose Spring. After all, there definitely are good reasons for using it. They told me however that they googled around a little and that it was clear from reading blogs and forum posts that Spring was the best. I asked them why they didn't use Java EE and EJB3 and they immediately responded that they read that Java EE was bad. When I them asked them WHY, all they could say is that it was because Spring was lightweight and EJB3 was a container (???). When I asked them WHY a container is supposedly bad, they said it was because it wasn't lightweight. When I then finally asked what they thought lightweight actually meant they really couldn't give me an answer. After some lengthy debate it usually boiled down to them saying that lightweight means it's Spring.

At that point it became clear to me those people where falling in the traps of the Spring zealots.

Lately more people have become aware of this though, and the entire scheme is backfiring a little, but it did bring a lot of new people into the Spring camp up till a year orso ago."
See: http://www.dzone.com/links/240033.html#98704

I'm absolutely not saying there's any truth in these quotes, but it does show a certain sentiment. Google around for Rod Johnson, lying, fud and you'll find more of these kinds of results.

Personally, I love to use Spring. It was one of my first loves on the Java platform. Although I still like Spring the technology, I'm not sure I like Spring the people. Spreading all of that FUD, as if EJB2 was still the latest and greatest tech pushed by Sun. We now have EJB3 and very soon EJB3.1, but Spring folks often seem to be ignoring that and keep on ranting and bashing that containers are bad, that EJB is bad. In reality EJB3 is here now and IMO is a VERY elegant and lightweight stack.

Posted by Robert Tuinman on October 04, 2009 at 10:32 PM CEST #

try using hibernate/jpa + spring

its more powerful than JPA+EJB.

Posted by sj on October 04, 2009 at 10:40 PM CEST #

I have used JPA+EJB its ok. I used it because I was using it for resume driven programming.

Posted by scootx on October 04, 2009 at 10:44 PM CEST #

And here we have the attack of the Spring zombies (probably the ones with the multiple digital lives)...

So you think Spring is more powerful? How so? Have you taken a look at JSR 299 and Seam? Have you considered a Spring/EJB 3 hybrid solution?

What exactly do you get with a Spring centric stack other than needless lock-in to a non-standard solution from a commercial vendor?

This is where your reasoning will begin to fall apart. Spring is resume-driven programming, not Java EE. Take a look at this analysis: http://www.jsfcentral.com/listings/A21078?link. That's another FUD argument aimed at J2EE, not Java EE 5+. The people who are adopting Java EE and/or Seam today are doing it because they believe its the best solution, not what adds value to a resume. Make your case why you believe Java EE 5 is resume driven programming instead of making meaningless unsupported statements.

Cheers,
Reza

Posted by Reza Rahman on October 04, 2009 at 10:59 PM CEST #

@Reza,

just a pragmatic suggestion:

1. Start with EJB 3(1). It is lighter, simpler - no configuration or setup required.
2. If you miss something - just move to Spring, Guice, HiveMind, NanoContainer etc. In worst case you will have to remove few annotations.
See: http://www.adam-bien.com/roller/abien/entry/what_happens_if_you_start

thanks for the comments - I will have to increase the max comment size next time:-),

adam

Posted by Adam Bien on October 04, 2009 at 11:34 PM CEST #

I read book by mr rahman (ejb in action) and its very good. In this book mr rahman talks about spring also. he sais spring has uses also. more power in some areas he said for spring.

For me mr rahman very honest man... when did mr johnson say this nice words for ejb?

for me and fellow students. we use the ejb3 to write simple and powerful application ! for learning is very easy as mr bien tells here! spring is good also. but for us ejb3 more easy and no xml is very good

Posted by Fangni lee on October 05, 2009 at 12:01 AM CEST #

Thanks for the kind words guys, I try my best...one of the prime motivations for me writing the book was to bring a more balanced discussion to the table instead of all of us developers nodding away like mindless robots to what some self proclaimed "saviors of Java EE" say...

I do very much agree with the approach of starting with pure Java EE 5 and adding Seam, Spring, Guice as needed. I think it's very smart and stops you from painting yourself into a corner that only serves vendors, not developers. I've successfully used this approach for a number of clients with great success, do talk about it in the book and at conferences and JUGs: http://www.shaunabram.com/spring_ejb3/.

Cheers,
Reza

PS: Just call me Reza, man. I'm no big shot like Rod, just a schmuck with a big mouth and decent sized brain. LOL.

Posted by Reza Rahman on October 05, 2009 at 04:02 AM CEST #

It's a pity that a harmless post by Mr Adam Bien has turned into an ugly EJB 3 Vs Spring contest and emotions running really high at the moment.

It would have been so much better if we all just agreed that Spring provides an alternative useful way to tie it with JPA, in the absence of EJB 3.

Anyway, thanks to Adam for the enlightenment, I'll be sure to keep JPA with EJB 3, as far as possible.

Reza, your sample application in your book "EJB 3 in action" doesn't include any source code for Websphere. Do you plan to provide one in future?

Posted by Shaw on October 05, 2009 at 08:33 AM CEST #

Shaw,

No I wasn't planning on it simply because it took WebSphere the usual eon to finally get Java EE 5 certified because they honestly believe they are immune to all market conditions (and maybe they are to a degree)...

Do you need it? I can whip it up really quick since I've already done a Seam/Java EE 5 project on WebSphere 7 a few months ago. Is that what you need? How soon do you need it? How mission-critical is this really? I do have to juggle quite a bit on a daily basis and it all seems ever important to someone...

I'm actually a pretty unemotional individual as they come (but I am by all means passionate about my craft). I meant absolutely everything I said. Someone needs to stand up to the endless stream of self-serving SpringSource BS. If I have to be one of those people, so be it.

I've stood up for what I see as the right thing all my life, this is no different and certainly not the most adverse situation I've ever faced. I'm a firm believer in Edmund Burke's timeless statement - "all that is necessary for the triumph of evil is that good men do nothing". I don't know if I'm really a good man or not or even if SpringSource really all that evil or if any of this is really all that important in the scheme of things, but I've always tried my best to hold myself to sound principles and do think SpringSource is capable of serving the Java community a lot better than what I see it doing...

Cheers,
Reza

Posted by Reza Rahman on October 05, 2009 at 09:23 AM CEST #

"How soon do you need it? How mission-critical is this really? I do have to juggle quite a bit on a daily basis and it all seems ever important to
someone.."

It is nice to have for someone who has set up a development environment like RAD 7.5 that has a WAS 7 test environment. It's not a must have for me. So, don't bother. I was just asking, that's all.

Reg. Spring, I think it presents some good scenario's to use it. For example, we started off with a project using plain JDBC and a simplified DAO layer. We were handling all transactions with in the DAO (not a good idea, but the project scope was pretty small). The project scope increased (maybe we don't do the BA part that well), and we had to go to Service layer for managing transactions, and quickly the whole thing became very complex. With less effort, we could introduce Spring to handle the JDBC & the transactions for us, and we could just continue.

If I had to use EJB 3 will it be effective? I can't use ORM in this project, as there are too many select queries for generating report type data. I looked for some forum, and the answer was I need to use JPA because there is little reason to not use it. Go to Spring forum, and they would say, no problem at all!

At this point I'm not sure if I can use JDBC with EJB 3 and achieve less coding overall, like the way you can do with Spring.

IMHO, when it comes to EJB 3, there is only one way to do it. Sure, I find that a lot simpler to do things when the project suits its style of thinking, and on any day I'll go for EJB 3 if it works. After all, why waste the investment someone made on getting a Jave EE server?

I think there is a lot of close minded attitude that exists in both Spring and EJB 3 community, and unfortunately either of that is interesting to customers. They really don't care if a developer thinks EJB 3 sucks or Spring sucks, as long as the solution they deliver doesn't suck, the customer is fine.

Hope the Java community moves on.

Posted by Shaw on October 05, 2009 at 10:55 AM CEST #

mr shaw. we are but students and not experts in ejb3. but regarding jdbc in ejb3 this is what we have done exactly!

teacher made sql query for us to use. this is not jpa. then in the session bean we execute this sql with entity manager using execute native method.

entity manager is injected in session bean and ejb3 does transaction for us. like example from mr bien our code is now very clean. with jdbc more problems came to us, like connection and statement and transaction very difficult. with ejb3 executing given sql is very easy (em.executenative()). in same project we also use jpa and for read, native query result can be mapped to entity also, but this is optional.

sorry we just students and no professional coder yet. maybe we did wrong but execute native in entity manager worked realy good for us

Posted by Fangni lee on October 05, 2009 at 12:55 PM CEST #

"IMHO, when it comes to EJB 3, there is only one way to do it. Sure, I find that a lot simpler to do things when the project suits its style of thinking, and on any day I'll go for EJB 3 if it works"

I must admit, I was ignorant while making that statement. I haven't read up on EJB 3 sufficiently to make that kind of a statement. Shame on me :-)

Thanks Fangni, JDBC is quite usable with EJB 3's transaction management facility and injection.

Posted by Shaw on October 05, 2009 at 01:36 PM CEST #

@Cay Horstmann

Thanks for the update on JSF. That it now requires no xml other than a deployment description file is a good thing for those who have to work with it.

My criticisms were based on my experiences with older implementations.

Jeff
http://jeff-schwartz.blogspot.com

Posted by Jeff Schwartz on October 05, 2009 at 03:47 PM CEST #

Shaw,

I've heard this criticism of EJB 3 before and it is not unreasonable to think this way. I would have you look into three more things:

1. JPA native queries are designed to handle this exact scenario and still give you all (or most) of the productivity/maintainability benefits of ORM. It is far more concise and powerful than any other native query processing API IMO - including Spring JDBC and iBATIS - and I've done projects with both of these. I know many beginning JPA developers are too wrapped up in JPQL, ORM etc. But the truth is that JPA was developed by people like Mike Keith and Linda DeMicheal, people who have made persistence their life's work. Rest assured, they have some thought to this use case :-). One frustrating thing for me is that the existing books specializing in JPA don't cover this case enough. I would say if you had just started as a Java EE 5 project with JPA native queries, you would probably have experienced no pain, even if you chose to go full ORM at some point.

2. One of the very nice use-cases for Spring-EJB 3 integration is using the Spring JDBC template inside EJB 3 beans. I have example code for this on my Spring-EJB 3 integration talk: http://www.shaunabram.com/spring_ejb3/. This would be for the case where you truly do feel more comfortable in the perhaps more familiar JDBC API and don't have the bandwidth to learn JPA quickly.

3. It is entirely true the ORM capabilities in JPA 1 were too rigid for any arbitrary legacy database. This has changed a bit in JPA 2: http://java.dzone.com/articles/looking-forward-jpa-20. I would say JPA 2 enables 85%-90% of databases to be mapped via ORM only.

I'm not suggesting the Spring forum folks deliberately misled you (although I can't rule out an element of self-servitude). After all, there is a thing called an honest mistake or an error in judgement. They probably just gave you the solution that was within their skill set and experience.

The problem with the apathy you mentioned is that like anything else in life, it can lead to profoundly bad results long term. For example, I don't think it is in the long term best interests of the Java community for middleware to be ultimately controlled by a very small number of people with vested interests in achieving a return on their investment as opposed to a vast consortium of people that are essentially forced to work together to preserve the maintain the best interests of the community.

However, for that to work the standard needs true participation from people who have a minimum vested interest. In Java EE, this is the role that I, Adam Bien, Cay Horstmann and many others play...

I hope this is not lost on you....

Cheers,
Reza

Posted by Reza Rahman on October 05, 2009 at 09:47 PM CEST #

Shaw,

Just in case it isn't obvious, I agree with you wholeheartedly on your point about leaving behind needless and mindless antagonism. It is high time the Spring vs Java EE debate reaches a point of healthy competition and peaceful co-existence.

Despite what I think of SpringSource's past and present, I continue to hope that they begin to see that at some point going forward too...

Cheers,
Reza

Posted by Reza Rahman on October 06, 2009 at 01:17 AM CEST #

Reza,

Thanks for taking your time to write a detailed explanation. I'll take a look at the suggested approach, and go through your book in detail.

If EJB 3 + JPA could solve a lot of common use cases, then nothing like it!

Thanks once again.

Regards,
Shaw

Posted by Shaw on October 06, 2009 at 06:36 AM CEST #

Shaw,

It is my pleasure and privilege entirely.

You may also want to check out Java EE 6, specifically the GlassFish preview: https://glassfish.dev.java.net/downloads/v3-preview.html. As a WebSphere user, one way to look at things is that you can get the core benefits of Java EE 6 by using Seam on top of WebSphere 7 today. That is how some of my WebSphere customers have chosen to look at things instead of continuing to go the Spring route.

Also, please feel free to reach out to me personally any time. All my contact info, including my phone numbers are on my website. I make it a point to do anything I can for folks that reach out...even if it is a Spring question :-).

Best wishes,
Reza

Posted by Reza Rahman on October 06, 2009 at 09:42 PM CEST #

Thanks for the GlassFish v3 plug Reza. We're fast approaching a final release of v3 with full Java EE 6 support indeed.

Posted by Alexis MP on October 07, 2009 at 01:32 AM CEST #

"Personally, I love to use Spring. It was one of my first loves on the Java platform. Although I still like Spring the technology, I'm not sure I like Spring the people. Spreading all of that FUD, as if EJB2 was still the latest and greatest tech pushed by Sun. We now have EJB3 and very soon EJB3.1, but Spring folks often seem to be ignoring that and keep on ranting and bashing that containers are bad, that EJB is bad. In reality EJB3 is here now and IMO is a VERY elegant and lightweight stack."

Yes, I noticed that smell, too and this lead me to dislike Spring people.
We once had a company event with a SpringSource guy who used to work as a developer in our company before.
It was the worst kind of FUD I've ever heard of. It made me sit there with my mouth open how someone known as a good developer can have the Chuzpe of spreading such marketing BS and blatant lies among a group of 100+ developers.
Nobody bought it, though. Although we had some Spring people here, Spring was dead from that moment on as a strategical framework in our consulting company. Which means, we never recommended it to our customers anymore and the Spring people moved to JEE5.

Posted by Matthias Fraass on October 08, 2009 at 12:55 PM CEST #

Hey everyone, check out this announcement about the Java EE 6 Proposed Final Draft:

http://weblogs.java.net/blog/robc/archive/2009/10/08/java-ee-6-platform-specification-reaches-proposed-final-draft-stage

JSR-299 (CDI/WebBeans), JSR-330, and JSR-303 (Beans Validation) were added to the Web Profile. If Spring Application Platform/dm Server still wants Java EE 6 Web Profile certification, then SpringSource will need to implement EJB 3.1 Lite and JSR-299 like I said in my original comments that started this trainwreck. That's assuming this proposed final draft goes final.

What's also interesting is a new document about the concept of managed beans.

"At a high level, the direction we're going in is one where the services made available by EE containers can be mixed and matched on any single bean, breaking down any rigid barriers, such as the traditional one between the "EJB world" and the "web world"."

Sounds a lot like what the Spring framework has given us for years. It will be nice to see Java EE finally mature.

Posted by Ryan de Laplante on October 09, 2009 at 06:24 AM CEST #

EJB lite is a bad idea, web profile is complicated enough without adding extra crap.

If they need to add ejb, then add full ejb version .. it sounds like they are trying to replay jsf history.

Posted by sj on March 28, 2010 at 08:26 AM CEST #

@SJ,

If EJB lite is too complicated - what can be simplified? Really interesting in your constructive feedback.

thanks for your comment!,

adam

Posted by 192.168.0.24 on March 28, 2010 at 01:32 PM CEST #

That's great, but what happens if we want to do thinks like this:

public void someBiz() {
...
em.persist(someEntity);
...
em.merge(anotherEntity);

}

How does the EntityManager knows if 1 or 2 transactions (1 for persist and 1 for merge) have to be used?

Posted by Optimus on August 22, 2013 at 12:01 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments
License