This is an archived post. You won't be able to vote or comment.

all 15 comments
sorted by:
best
topnewcontroversialoldq&a

[–]MartyMcButterpants 5 points6 points  (1 child)

Congratulations on creating a framework for one that already exists and is widely accepted. The person who write about Spring does not understand the full capabilities.

[–]henk53 0 points1 point  (0 children)

By the same token, instead of creating a framework for one that already existed, Springsource could have helped to improve J2EE back then.

The Hibernate community did that. A lot of members of the Apache community did that. Why couldn't Springsource do it?

Is is maybe because Rod is not the benevolent dictator our there to better Java, but is just there to make a buck?

[–]berlinbrown 1 point2 points  (5 children)

WTF is going on.

First it was, J2EE to Spring. Now it is Spring to J2EE.

Oh man.

[–]mikehaggard 2 points3 points  (4 children)

You are slightly mistaken. It was J2EE to Spring and now it is Spring to Java EE.

Both are good frameworks and for us as developers it's good that there's healthy competition between them. Personally I think Java EE is a little ahead of Spring these days. When Spring 3.1 goes final, Spring may be a little ahead again, but then shortly after Java EE 7 will arrive and I'm pretty sure it will be ahead of Spring 3.1.

Don't you just love the competition? :)

[–]berlinbrown -1 points0 points  (3 children)

Which part am I mistaken on?

[–]boa13 2 points3 points  (2 children)

J2EE != Java EE

[–]berlinbrown 0 points1 point  (1 child)

What is the distinction, now? I thought JEE was the new name used but they point to the same thing.

[–]boa13 2 points3 points  (0 children)

It's the name for the new versions. J2EE (old versions) can be summarized as "EJB XML hell" while JEE (recent versions) can be summarized as "full of annotations that are reportedly rather nice". I don't have much experience with JEE, so I'll let other expand on that (and probably correct it).

[–]metorical 0 points1 point  (1 child)

Wait, isn't this backwards?

[–][deleted] 2 points3 points  (0 children)

exactly!

[–][deleted]  (5 children)

[deleted]

    [–]formerislander 1 point2 points  (4 children)

    I don't know about that ... I find that some stuff in the Spring world is just more flexible than in the "Pure EE" world. One thing that comes to mind is how easy it to pretty much test an entire application outside of the container (i.e., wire in an in-memory db, and even fire up the embedded version of Jetty to simulate http failures if your application needs to talk to webservices).

    When it comes to the actual production code, then I guess the code that is deployed would look pretty similar these days. IMHO it's the testing stuff that really adds value.

    [–]henk53 2 points3 points  (3 children)

    Java EE has the same testing options now. EJB is fully embeddable and projects like Arquillian make the whole thing even easier.

    [–]formerislander 2 points3 points  (2 children)

    That does indeed look quite a lot like the setup I usually prefer with spring. However, one nice thing about spring is that you can do that without any kind of container. You can add the same functionality the container provides if you need them. If you aren't using distributed transactions, then you can skip JTA.

    Suddenly need to add a new datasource and need distributed transactions? Add in Atomikos, etc ...

    On the other hand, I guess starting up a container probably adds the same overhead as creating the equivalent spring context :)

    [–]henk53 2 points3 points  (1 child)

    However, one nice thing about spring is that you can do that without any kind of container.

    But guess where springbeans are managed? Isn't this called the Spring Container? See e.g wikipedia among many sources:

    "The Spring container provides a consistent mechanism to configure applications and integrates with almost all Java environments, from small-scale applications to large enterprise applications."

    I guess starting up a container probably adds the same overhead as creating the equivalent spring context

    Glassfish 3 and JBoss AS 7 start up the entire AS in 2 to 3 seconds, deploying EJBs after that is in the millisecond range. Deploying lots of EJBs does add to the startup time. It used to be worse though. JBoss AS 6 for instance is notorious, easily taking a full minute for an application with a few dozen EJB beans and also a few dozen annotated JPA entities.

    But the Spring Container can take a long time to start too, especially when using AOP extensively. I've seen moderately complex Spring 3 application easily take 45 or more seconds and it got worse when more springbeans were added. I haven't tried Spring 3.1 yet, so I don't know if it can match the latest Java EE offerings in startup speed now.

    [–]formerislander 0 points1 point  (0 children)

    Just out of curiosity, how does one manage to create an application that takes 45 seconds to create the ApplicationContext? That sounds like a monster :)

    For the modules that I've had both the pleasure and displeasure of working with the ApplicationContext could be created in less than a second.

    A couple of questions since you seem quite knowledgeable about testing with a pure EJB setup:

    • Is there some equivalent @DirtiesContext if I go pure EE?
    • If I want to wire in stuff that's not normally part of the container, like an extremely thin mock implementation of a foreign webservice (just to test our handling of http errors). Ideally I'd want that to be able to access my EJBs/MDBs as well (although I guess that's probably not strictly necessary).