New Article: EJB 3.1 - A Significant Step Towards Maturity

Home

News: New Article: EJB 3.1 - A Significant Step Towards Maturity

  1. The EJB 3.1 Proposed Final Draft has been recently released and we are now close to its final version. Paulo Moreira goes through the specification in deatil and describes most of the new features, and explains their use and value in actual development. Read article

    Threaded Messages (49)

  2. The link is broken !!
  3. Paulo, Sorry to be so late in the game. I have been busy with a client release for quite a few weeks. Congratulations on writing the article and hope you continue to be involved in the Java EE community/TSS going forward. It's great to see some of the excellent feedback on EJB 3.1. We put a lot of hard work behind it and do believe it is a high quality specification, especially in conjunction with other Java EE 6 innovations such as the Web Profile, JSF 2.0, JPA 2.0 and JCDI (JSR 299). Some of the anti-EJB/Java EE comments are regrettable, but not really unexpected and useful to see regardless. Cheers, Reza ----------------------------------- Expert Group Member, EJB 3.1 and Java EE 6 Author, EJB 3 in Action Independent Consultant
  4. This looks so good[ Go to top ]

    I like pretty much everything I see here. EJB 3.1 Lite is going to be a rock star.
  5. Here We Go Again[ Go to top ]

    I like pretty much everything I see here.

    EJB 3.1 Lite is going to be a rock star.
    Folks, I think we are missing an important point here. I feel it is all well and good that EJB 3.1 encompass more Spring DI capabilities. At the end of the day, EJB in whatever form is a distributed access framework. I ask the question. How many application requirements actually need them to be truly distributed? My experience has been not many. All fine and dandy that EJB 3.1 has many or all of what Spring offers. What if I fundamentally DO NOT need to be distributed? What then do I use? As for me I will us Spring and deliver on time and on budget.
  6. Re: Here We Go Again[ Go to top ]

    At the end of the day, EJB in whatever form is a
    distributed access framework.
    Eh...wut? EJB is a COMPONENT framework that CAN BE distributed. Yea, EJB 1.0 was only distributed, but that was, umm, what, back before we had color television I think. Today, we have the option of distribution, and many folks don't avail themselves of that option. And, of course, EJB Lite doesn't have the distributed option at all. It's a packaging and distribution option for WARs and to make lighter weight EJB containers.
  7. Well, EJB 3.1 are cool and better than 3.0, and finally have some features that were already in Spring for long long time. That's nice. But I must say: I have SCBCD cert for EJB 3.0, I know EJBs, and I tried to imagine the case where I would use it in year 2009, instead of (or with) Spring. But actually, I can find no such case. Let's say 8, or even 4 years ago, the situation was different. But now? Who on earth needs EJB any longer? So why so many people waste their time creating specifications nobody needs? Why don't they simply let this dinosaur die in peace?
  8. I tried to imagine the case where I would use it in year 2009, instead of (or with) Spring. But actually, I can find no such case.
    Exactly what does spring now offer that JEE can't do? Which are the cases where Spring is still better - what features/situations compel you to feel so strongly about having to use spring (instead of or with JEE)? Shouldn't the question be - why should I now use spring instead of standards based JEE? Pooling, clustering, load-balancing - EJBs are still the way to go.
  9. I tried to imagine the case where I would use it in year 2009, instead of (or with) Spring. But actually, I can find no such case.


    Exactly what does spring now offer that JEE can't do? Which are the cases where Spring is still better - what features/situations compel you to feel so strongly about having to use spring (instead of or with JEE)?

    Shouldn't the question be - why should I now use spring instead of standards based JEE? Pooling, clustering, load-balancing - EJBs are still the way to go.
    First of all, I think you are missing the scope of Spring. "Pooling, clustering, load-balancing": Spring does none of these, but will use the standards in a seamless and transparent way. Sounds better? An other typical example on the scope: you have JDBC or JPA in the standard. Spring offers JdbcTemplate as a middle ground, and a lot project is just happy with it (simple, but efficient API that doesn't requires the full-blown JPA). I don't feel the need to enlist all the features Spring offers, please check it for yourself. But don't check it as an either-or choice, check it as a 'use the more appropriate tool for the job'. You can use Spring and JEE together, and actually I think this is the encouraged way now...
  10. Exactly what does spring now offer that JEE can't do? Which are the cases where Spring is still better - what features/situations compel you to feel so strongly about having to use spring (instead of or with JEE)?

    Shouldn't the question be - why should I now use spring instead of standards based JEE? Pooling, clustering, load-balancing - EJBs are still the way to go.
    Imho EJB3 is a programming model, whereas Spring is a framework. Spring is a great framework for creating great frameworks. For example, I can't imagine Mule ESB implemented in EJB3. A big shortcoming of EJB3 atm is that it's hard to create frameworks which are deployable on top of different app servers, from Tomcat all the way up to Websphere. EJB3 is implemented differently in all of these servers, and if you really want to support all these servers then you have to use something like Seam and the JBoss microkernel and bypass the host EJB3 environment, which makes it quite similar to the way you'd use Spring, but then Spring is more mature and offers more bells and whistles and that's why most such frameworks are built on top of Spring. But EJB3 is fine if you're not trying to build such a cross-server framework/product. Ara.
  11. Who on earth needs EJB any longer? So why so many people waste their time creating specifications nobody needs? Why don't they simply let this dinosaur die in peace?
    Maybe because it's a very useful and light-weight technology? With EJB3 it's very easy to declaratively add transactions to methods. Better yet, methods of a session bean are transactional by default. It's also a breeze to expose methods remotely, via either a binary protocol (RMI) or a text protocol (web services). Messaging support for asynchronous processing is also extremely useful in more than a number of occasions. I would like to ask the question the other way around. Why NOT use EJB? If you use Java EE then EJB is simply already there. It makes very little sense not to use it. Just because some guy who offers a proprietary stack that tries to duplicate everything Java EE already has says so? What's next, avoiding EJB because Steve Balmer says you should not use it? I think its time to look at this reasonably. EJB2 had its problems, but for the love of god, get over it. You're talking about something that was a problem in 2002! We're living in 2009 now. EJB3 is a modern, agile and light-weight technology. If you don't need transactions or remoting, don't use it. Not every application needs it. But don't spread FUD just because some people actually need those things (and don't kid yourself, a lot of applications actually do need at least transactions).
  12. Spring fans always do that[ Go to top ]

    Everytime I see anything posted about EJB3.x, someone from the Spring camp always chimes in with "oh yeah, Spring is better, can do more, there's no reason to use EJB, etc etc". Don't get me wrong, I think Spring has it's uses. It was particularly useful during the EJB2.x days, and truly the best way to go. But, IMHO, EJB3 learned valuable lessons from Spring, built on them, and leapfrogged past Spring in a lot of ways. The Spring camp always retors with "well, AOP support isn't as good in EJB3", to which the obvious answer is "so what? - EJB3 allows to declaritively wire in cross cutting concerns, and the really the concerns that matter". Then the Spring camp always retorts with "oh yeah, but you have to test session beans in the container, making it harder to unit test", to which the response is "there are tools that allow you to unit test within the container, and you write session beans as POJOs, which means you can strip 'em out and test them independently of the container. Anyway, I have always found EJB3 very attractive - sensible defaults, configuration with annotations, minimal xml, everything any enterprise app could need easily and immediately available (no reams of ugly XML, integration of third party frameworks to get that stuff), JPA, and so on. Thus, the real question is - now that we have EJB3, and soon EJB 3.1, what's the purpose of Spring? EJB3 has made everything easy again, and supports the POJO model, and the dependency injection model, and easily integrates the entire JEE stack, and with containers like Glassfish and JBoss, it has lazy loading. It's the complete package, and it lightweight, and easy. And it's standard, and has competing implementations. With all that in mind, perhaps Spring has seen it's time pass on.
  13. Thus, the real question is - now that we have EJB3, and soon EJB 3.1, what's the purpose of Spring?
    In the context of EJB3, there is hardly any purpose for Spring. I think Spring is basically just a competitor to Java EE. They started of with wrapping some popular opensource frameworks. Then they started an attempt to be an alternative for a lot of Java EE libraries, specifically EJB2 and later on JSF too. Recently they started their attempt to be a replacement for the AS itself. I won't be surprised if their next move was official support for alternative JVM languages, and then a little after that support for alternative VMs. In effect, it seems that Spring intends to become a completely independent platform, just as C#/.NET is an independent platform. Their 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.
  14. In the context of EJB3, there is hardly any purpose for Spring. I think Spring is basically just a competitor to Java EE.
    A their web site says, Spring is for "Eliminating Enterprise Java Complexity". Not _replacing_. It's not interesting for how many years I'm using Spring, but rather how it solved many of my day-to-day Java problems. Spring opponents say that it's risky to depend on "proprietary" Spring APIs. But look at Maven repositories and find me e.g. spring-core-2.5.6.jar. Whatever repo you choose, you'll end with the same JAR. Now find me JTA api JAR... Believe me - it's not that easy - what version? (1.0.1, 1.0.1B, 1.1, ...), what artifact ID? (javax.transaction, jta, geronimo-jta_1.0.1B_spec, ...), where are the sources? It's really annoying that every App Server has its own version of servlet, jsp, el, saaj, jaxrpc APIs. The same concerns the sources - Spring has clean CVS (Spring 2.5.x) or SVN (Spring 3.0, other) repository - you know what tag is for what version. Now try and fetch sources for JAX-WS 2.1.5 - there are at lease 150 tags in CVS. Have you ever looked at e.g. spring-core? Try some of it's "non-standard" but "real needs driven" classes:
    • FileCopyUtils
    • GenericCollectionTypeResolver
    • ServletRequestUtils
    • BeanWrapper
    • DataBinder
    • StringUtils
    • ...
    I don't imagine working without these classes...
    They started of with wrapping some popular opensource frameworks.
    Tell me - what they are wrapping that should not be wrapped? Hibernate? I don't see that org.hibernate.Session is hidden from me - when I want Session, I can access it. When I don't - I can use very elegant HibernateTemplate. Eeee - what other frameworks do you think of?
    Then they started an attempt to be an alternative for a lot of Java EE libraries, specifically EJB2 and later on JSF too.
    Transactions? Spring's transaction management is the most elegant solution of transaction management (JTA and single resource) - with both XML and annotation configuration. EJB2? Yes - that was the key point of Starting Spring in the first place. EJB3? Sorry - too late. Springs "components" are way ahead of EJB3 - have a look at @Autowired, @Qualifier, yes, AOP (AspectJ, annotations). Servlets 3.0? Tell me - what are Servlet annotations for? When was the last time you have written a javax.servlet.HttpServlet implementation? I'm using Spring MVC and configure Spring's DispatcherServlet in web.xml. My controllers are annotation Driven with e.g. @RequestMapping("service1/*"). Other? Just have a look at Spring-WS or Spring-Integration - these are breeze of fresh air after, respectively, Axis1/Axis2 and Mule. Spring-WS' SoapMessageDispatcher is so similar to DispatcherServlet that knowing Spring MVC it's zero footprint to start using Spring-WS! With Spring-Integration I just started to "integrate". With Mule/JBossESB it was often fighting. JSF? I don't think so. Yes - Spring WebFlow is ana laternative to flows from JSF, but much better designed. JSF for me should be a view technology when you need a component oriented web applications (or rather parts of web application) and JSF views are nicely integrated with Spring-MVC.
    Recently they started their attempt to be a replacement for the AS itself.
    Especially after failure of JavaEE 6 Web Profile it's a reasonable move.
    I won't be surprised if their next move was official support for alternative JVM languages, and then a little after that support for alternative VMs.
    They officially support JSR-223 - "Scripting for the Java Platform".
    In effect, it seems that Spring intends to become a completely independent platform, just as C#/.NET is an independent platform.

    Their 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.
    Because it's getting too long, I'll conclude - Java EE is a specification. Spring portfolio is great, pragmatic collection of products making work with Java EE implementations a lot easier. regards Grzegorz Grzybek
  15. I think Spring is basically just a competitor to Java EE.
    That's the point! So many people to doing JEE vs Spring, but remember that JEE is a specfication about how to implement. It had a part of EJB 3, EJB 3.1 etc. just a implement guide. Beware you write anything, it must running in container (JEE Application Server). If you agree this standard, what Spring can do? Spring, it seems beark this standard. Yes, you should doing anything you want but in application server level, what application server can handle the Spring? When you using full Spring product, it may be Spring's DM server. In this time, please do not said anything about JEE, because you are using and running Spring standard! And one day you using Spring standard, no any change again in application server, when using JEE, at least you can choose you application server product, you can doing a little bit fine tune, you can customzie a little bit. For more imagine that you can write once running anywhere :)
  16. Some finer points are missed by the article and discussion. Primarily, what's the cost of going with either approach and what are the benefits. A pet peeve of mine is also displayed by artical... not including the imports at the top of each class, as you can't see what you'll be coupling you business logic to clearly without all the imports fully enumerated (You may end up depending on several packages/jars). EJB 3.1 does appear to be simpler to read than Spring's dependency injection and AOP support (let alone all the Spring Platform) but that simplicity comes with several trade-offs. Primary among them are the constraints placed on the developer by EJB Session beans and there annotations. You wire your business logic once with these annotations and that is the only way these classes may be used, ever. Depending on the spec. annotations at compile and run time is a dependency in the truest sense, when using those annotations you couple your business logic with your control code ( annotations ). It is possible to make this same trade-off with Spring annotations or Guice annotations. Trading flexibility and decoupling for readability. This is a trade-off I personally reject, particularly because of how easy it is to not make this trade off with Spring or Guice and still have the same readability with Spring's Eclipse plugins.
  17. Who on earth needs EJB any longer? So why so many people waste their time creating specifications nobody needs? Why don't they simply let this dinosaur die in peace?
    Amen brother! I'm hearing ya!
    Maybe because it's a very useful and light-weight technology?
    Maybe it was useful in a the days prior to the maturity of transparent persistence but now ORM standards like JDO/JPA are commonplace I'm trying to work out why a technology that was designed to manage transactions/persistence would be of any help when that problem was solved has been solved in a much more clever and transparent way years ago. EJB1/2 inflicted so much pain and frustration on those that used it that it's hard to imagine anyone "voluntarily" using anything new from the EJB camp. I think your best chance of success is to rename EJB3 to something that makes no reference to the term EJB. Maybe foobar 1.0 or something. Without the negative EJB street cred it might actually be something people might consider.
    I would like to ask the question the other way around. Why NOT use EJB? If you use Java EE then EJB is simply already there. It makes very little sense not to use it.
    Let me introduce you to a concept called learning curve. Just because something is available and free doesn't mean we all should use it. Aren't most Java frameworks free and available these days? If I adopted your approach I'd be using all 27 Java UI frameworks (all free and available) and 7 different persistence frameworks (all free and available). Sorry, but I'm not in the habit of just using things because they are there.
    What's next, avoiding EJB because Steve Balmer says you should not use it?
    There you go making fun of a man of integrity, a beacon of light in our dark industry ;) Shame on you! :)
  18. I did not follow EJB 3.1 closely. I am a bit confused with the no-interface views feature. The article states that:
    This feature will allow to avoid writing interfaces, simplifying development. It might be that the future will bring remote no-interface views.
    I thought its a good practice to have an interface as the contract between EJB consumer and provider. I did not feel an interface "complicate" the deployment. Do I missed something important ? can someone enlighten me on this ?
  19. I thought its a good practice to have an interface as the contract between EJB consumer and provider. I did not feel an interface "complicate" the deployment.


    Do I missed something important ? can someone enlighten me on this ?
    You did not miss anything. Interfaces are indeed a good practice. It's quite similar to how you 'normally' build your code. You don't code against ArrayList, but code against List. EJB3 enforces this best practice by requiring an interface to be used. For most programmers this is an extremely good idea, but for the absolute beginners who don't have the luck to be supervised by some experienced programmer, this can be seen as a hurdle. So in order to attract the lowest of the lowest of programmers, EJB 3.1 seems to have lifted this requirement. Next to the beginners argument, there is the argument that very small programs don't necessarily benefit from using an interface for their business classes. I think this is the official argument used by the EG. In no way however is it recommended to not use an interface. This is really only for beginners / very small apps. Everything else should just continue the best practice of coding against interfaces (IMHO).
  20. I thought its a good practice to have an interface as the contract between EJB consumer and provider. I did not feel an interface "complicate" the deployment.


    Do I missed something important ? can someone enlighten me on this ?


    You did not miss anything. Interfaces are indeed a good practice. It's quite similar to how you 'normally' build your code. You don't code against ArrayList, but code against List.

    EJB3 enforces this best practice by requiring an interface to be used. For most programmers this is an extremely good idea, but for the absolute beginners who don't have the luck to be supervised by some experienced programmer, this can be seen as a hurdle.

    So in order to attract the lowest of the lowest of programmers, EJB 3.1 seems to have lifted this requirement.

    Next to the beginners argument, there is the argument that very small programs don't necessarily benefit from using an interface for their business classes. I think this is the official argument used by the EG. In no way however is it recommended to not use an interface. This is really only for beginners / very small apps. Everything else should just continue the best practice of coding against interfaces (IMHO).
    If this is for the beginner programmers, then I think it is counter productive. I rather EJB 3.1 promote good practice than bent to adopt some less optimal practice for the sake of ease of use. In case of very small application, it might be tedious to write a interface for every little business objects exposed as EJB. But that begs the question weather you should expose such small objects as EJB. A more corse grained interface should be used to group these tiny objects into a general service interface. I am not sure I agree with such argument. This feature seems trying too hard or too much. This reminds me an old Chinese proverb: add feet to a perfectly painted snake. (Snake, of course, has no feet).
  21. Next to the beginners argument, there is the argument that very small programs don't necessarily benefit from using an interface for their business classes. I think this is the official argument used by the EG. In no way however is it recommended to not use an interface. This is really only for beginners / very small apps. Everything else should just continue the best practice of coding against interfaces (IMHO).
    *sigh* Using an EJB in practice is used as an interface. Here's how you use an EJB without an interface: @EJB HelloBean bean; public void method() { bean.hello(); } And here's how you use an EJB WITH an interface: @EJB HelloBean bean; public void method() { bean.hello(); } The difference? HelloBean in the first example is an EJB class. In the second example, HelloBean is an interface. So, for the 80-90+% use case of a single local interface that's identical to your actual implementation, interfaces buy you what? Exactly? An unnecessary abstraction. If you later find you need this abstraction, create a HelloBeanImpl and change HelloBean to an interface. Big deal. This feature eliminates Yet More cruft and makes EJB easier to use for everyone, big and small projects, experienced and beginners alike.
  22. Using an EJB in practice is used as an interface.
    Okay, I stand corrected. Since you don't instantiate an EJB bean with the new operator anyway, the difference in this case is negligible. In both cases your code is injected with an (invisible) proxy anyway, instead of the real implementation. On the other hand, you could still argue that the interface abstraction allows for a very clean distinction between public client methods and internal implementation methods, right from the start. It also makes it very clear for the client that it is talking to an interface. Looking up the implementation via an IDE will clearly reveal the interface, which is all the client should expect. If the IDE reveals the implementation class, programmers might make assumptions based on that implementation. Still, I do agree with you that its a bit of a mood point and that with EJB 3.1 the best practice of coding against an interface is far less important than in 'regular' Java.
  23. Missing what's important[ Go to top ]

    In the comparison between Spring and EJB 3.x people are missing what's important: I can solve the problems I have today using Spring. When will EJB 3.1 be available and supported by the usual vendors? In my opinion EJB 3.0 was too little, too late. Spring had conquered the market where choice was available between the rigid EE standards and Spring. For me, EJB 3.0 was just too restrictive and was guilty of "not invented here" syndrome where SUN just had to do things their own way. Standards are seen as important to some (usually large and beaurocratic) organizations, so I expect EJB 3.1 to have some measure of success in the corporate market, but if you already decided to use Spring with or as a replacement for EJB, then I don't see why you'd drop it.
  24. I'm not "from Spring camp". I'm just pragmatic. My point was clear: if I start new project, and have to choose: EJB 3.x vs Spring, I cannot find any argument for EJB. For me, EJB are dinosaurs, because they are old, artificial creates: the distinction between "normal beans" and EJB is no longer needed. This "magic" behind EJB container makes me always worry: I don't know what's going on inside. On the other hand I can easily imagine what's going on inside Spring-based application: it's transparent, so I trust it. Then: I run Spring app on every server, like Tomcat, or even without any server at all, as simple standalone application. For EJB I need this crazy, heavy EJB container. Compare GlassFish or JBoss server startup time to Tomcat, and multiple by hundreds of restarts during development. What a waste of time. Then: compare naive dependency injection capabilities of EJB to Spring. Compare configuration options. Then: who needs JNDI any longer for dependency lookups? But you must use it with EJB. With Spring, I can let it die in peace too. Then: transactions - you must use JTA with EJB, and you can forget it with Spring. And, as Grzegorz mentioned, try building JTA-dependent app with Maven. Sun was not able to provide JTA jar to maven repos for years. And the most funny argument: "EJB is a standard" - so what? JDO was a standard too. But then Sun decided to throw JDO out of the window, and replace it with JPA. EJB Entity Beans was also a standard - and you know the rest of this story. Finally, as Sun is dying now, I guess its EJB heritage will do the same. But we shall see.
  25. Let me get this straight: you don't trust the container but rather choose a framework where everyone uses injection like crazy?
  26. Yes, I do (whatever "framework where everyone uses injection like crazy" means: actually for me it sound like compliment).
  27. I'm not "from Spring camp". I'm just pragmatic. My point was clear: if I start new project, and have to choose: EJB 3.x vs Spring, I cannot find any argument for EJB. For me, EJB are dinosaurs, because they are old, artificial creates: the distinction between "normal beans" and EJB is no longer needed. This "magic" behind EJB container makes me always worry: I don't know what's going on inside.
    That's nonsense. Implementations like Jboss AS, Glassfish and Geronimo come with full sources. I can perfectly well step through EJB3 core classes and see exactly what's happening. I really don't understand your point here.
    On the other hand I can easily imagine what's going on inside Spring-based application: it's transparent, so I trust it.
    Are we talking about imagining what's going on or knowing what's going on? Since Java EE has a carefully crafted specification I can look up what the intended behavior of something should be. Limitations for EJB3 beans are precisely specified. On top of that, since most Java EE implementations are open source, I can look up the source and drill down to some very specific function to see what is -exactly- happening. Now with Spring, the Spring container absolutely imposes its own limitations on your code. The difference? It's not documented. You have to find out yourself, either by running into some limitation or by looking in the source code, scanning it for possible "dos and don'ts". I'm sorry, but I really prefer the Java EE way.
    Then: I run Spring app on every server, like Tomcat, or even without any server at all, as simple standalone application. For EJB I need this crazy, heavy EJB container.
    And what do you need for running Spring applications? Don't you need something like, uhm... a Spring container? Last time I checked the 6MB Tomcat distribution didn't come with Spring capabilities. So I do have to download at least the 30MB or so that makes up the core Spring framework, but then I only have the core. Of course I also need the web services stack, which is another 30MB. If I want a web framework (and be honest, who codes bare JSP pages today) I need to download Spring MVC, which is another 50MB. At this point I still don't have an ORM mapper, so I need to download Hibernate separately which is another 30MB. I probably need security support too, so let's download Spring security, weighing in at another 15MB. If you have been paying attention, I'm already well over 150MB now. Don't even mind the trouble of doing all those separate downloads. When I want to use Java EE for my applications, I download Glassfish (75 MB) or Jboss AS (110 MB) and I have everything at one go. If I really don't need something I just disable it. Both Glassfish and Jboss are very flexible there. Your argument can be easily reversed: "I run [a] Java app on many implementations, like Glassfish, Geronimo, Jboss AS or even without any server at all, as [a] simple standalone application via e.g. OpenEJB or embeddable Glassfish. For Spring I need this crazy, heavy Spring container and tons of separate downloads."
    Then: transactions - you must use JTA with EJB, and you can forget it with Spring.
    You don't even notice transactions are there in Java EE. EJB3 adheres to the well known mantra convention over configuration. For this specific situation this means that any method of a session bean is transactional by default and it uses the most common and sensible default: TRANSACTION_REQUIRED (which means the method either joins an existing transaction or starts a new transaction). In case you want something else than the default kind of transaction, you just put a small annotation on your method or bean. You are really spreading FUD. There is no need to manually interact with the JTA API at all. It's possible, but I have never seen an EJB3 bean that does.
    And, as Grzegorz mentioned, try building JTA-dependent app with Maven. Sun was not able to provide JTA jar to maven repos for years.
    I don't understand this argument at all. What are you trying to say here? Multiple vendors and parties have created an open source JTA implementation. Any of those, or you yourself can take such an implementation and make it available.
    Finally, as Sun is dying now, I guess its EJB heritage will do the same. But we shall see.
    You are basically saying that you hope Java EE will die. Unfortunately for you, Java EE was one of the main reasons Oracle bought Sun at all. Needless to say of course there is also still Apache (Geronimo), RedHat (Jboss AS) and IBM (Websphere), so I wouldn't keep my hopes up if I were you. Of course, I can understand that users from another platform wish the competing platform to die. Most likely, a number of .NET users also want Java EE to die, and most likely they want Spring to die too. As I said before, Spring is 'just' a competing platform. It has its own merits and it's good to see that the professional server market has a choice between at least 3 major offerings.
  28. Now with Spring, the Spring container absolutely imposes its own limitations on your code. The difference? It's not documented. You have to find out yourself, either by running into some limitation or by looking in the source code, scanning it for possible "dos and don'ts". I'm sorry, but I really prefer the Java EE way.
    What limitations? I mean other than some imports which are not different than e.g. import java.util.Map? And I don't think the "limitations" are undocumented - EJB3 spec also doesn't tell you that it won't make you breakfast.
    And what do you need for running Spring applications? Don't you need something like, uhm... a Spring container? Last time I checked the 6MB Tomcat distribution didn't come with Spring capabilities. So I do have to download at least the 30MB or so that makes up the core Spring framework, but then I only have the core. Of course I also need the web services stack, which is another 30MB. If I want a web framework (and be honest, who codes bare JSP pages today) I need to download Spring MVC, which is another 50MB. At this point I still don't have an ORM mapper, so I need to download Hibernate separately which is another 30MB. I probably need security support too, so let's download Spring security, weighing in at another 15MB.

    If you have been paying attention, I'm already well over 150MB now. Don't even mind the trouble of doing all those separate downloads.
    Hmm. I don't remember it is necessary to deploy Spring Distribution with your WAR. I (maybe not alone) am using Maven and SpringFramework + SpringWS + Hibernate JARs weight 6.479.446 bytes total. Spring MVC alone is 402.396 bytes. And wait - is Spring a container? Does it manage the lifecycle of your application? Spring is partly framework (DI container - yes, here it is a container + MVC Framework) and partly a library. I use it just like commons-logging and hibernate - by including it in my classpath.
    And, as Grzegorz mentioned, try building JTA-dependent app with Maven. Sun was not able to provide JTA jar to maven repos for years.


    I don't understand this argument at all. What are you trying to say here? Multiple vendors and parties have created an open source JTA implementation. Any of those, or you yourself can take such an implementation and make it available.

    We are talking about API JARs - jars containg API classes. I know of one JAR containg Spring's ApplicationContext class and at least ten JARs containing javax.xml.QName - this is where standards (generally they're most valuable) meet real life. Spring works. Spring MVC works (great), EJB3? I don't know - code samples look simple, even elegant, but I don't know the roadmap of EJB3 (did you expect EJB3 when EJB 2.1 was "cool"?). Spring has JIRA - you know what's going to happen (lets skip over recent SpringSource's plans with "enterprise" versions...). And what about JPA - I don't use it. I know that Hibernate is official implementation of JPA. But is this the reason to not use Hibernate? "Java Persistance with Hibernate" book says that some Hibernate features are not required/enforced by JPA - is THIS the reason to use JPA instead of Hibernate? JAX-WS? Sorry - have a look at Spring-WS - it's brilliant! And guess what - I like how it uses JAXB2. There is now Spring-XML-Binding framework. JBI? Sorry - I'm using Spring Integration (earlier - Mule). Security - what gives me Java EE? A statement that security details are "implementation dependent"? Try WAR with LDAP security on Tomcat/JBoss/Websphere with and without Spring-Security... Try map LDAP roles in WebSphere.... best regards - it's Spring time! Grzegorz Grzybek
  29. There is now Spring-XML-Binding framework.
    Sorry, of course there is no Spring-XML-Binding framework!
  30. What limitations? I mean other than some imports which are not different than e.g. import java.util.Map? And I don't think the "limitations" are undocumented - EJB3 spec also doesn't tell you that it won't make you breakfast.
    It won't, but it does specify specific limitations (or perhaps restrictions is a better word) like not being allowed to spawn your own threads or read and write from files. In Spring there are numerous similar pitfalls - things that your application code should not do since it messes up the control that Spring has over your application.
    Hmm. I don't remember it is necessary to deploy Spring Distribution with your WAR.
    Hey, and guess what? I don't have to deploy any Java EE standard classes with my application either if I deploy it to a Java EE server. Since all those classes are already provided by the Java EE server, since that is what makes it a Java EE server in the first place. This is really a silly line of reasoning. I don't deploy e.g. java.util.HashMap with my Java SE .jar either, since every Java SE implementation already provides that. Likewise, I don't deploy something like javax.ejb.EJBContext with my application, since every Java EE implementation already provides that. Your assumption seems to be that Java EE applications are always deployed to a bare Tomcat, so they must include things like jsf, jta, jpa, ejb themselves. But for Spring you assume all required implementation classes for Spring are already included with Tomcat or magically obtained by Maven somehow and thus your application only has to include your own classes? Don't you see the apples and oranges in that comparison?
    And wait - is Spring a container? Does it manage the lifecycle of your application? Spring is partly framework (DI container - yes, here it is a container + MVC Framework) and partly a library.
    Spring is a container too. Sorry to burst your bubble, but it is. I know you Spring people have worked hard to taint the word 'container', but in the process Spring has become a container itself. I hope you at least have the wits to see the irony in that ;) I do like the alternative terminology 'proposed' by Panda, Rahman and Lane in EJB in action, where they explain a container to be a kind of extended VM from the code's point of view. Just like the basic VM handles memory management for you, the 'extended VM' handles transactions for you.
    but I don't know the roadmap of EJB3
    http://jcp.org/en/jsr/detail?id=318 ? http://jcp.org/aboutJava/communityprocess/pfd/jsr318/index.html ? I do want to stress that EJB3 is a part of Java EE and as such it's probably better to look at the roadmap for Java EE as a whole too. Thanks to the early feedback requested by the EG, numerous blog postings (see e.g. http://jdevelopment.nl/open-source/java-ee-6-progress-page/) and the periodic release of specification documents long before a new version is released, it's quite easy to see where all of this is going. If you don't know anything about the roadmap of EJB3, then you just aren't looking.
    I know that Hibernate is official implementation of JPA.
    I think you mean "I know that Hibernate is THE official implementation of JPA.". Please stop omitting articles, they actually have a function. But besides that, the statement is wrong. There is no 'official' implementation. There is a reference implementation though. Even if you meant to say that, you are still wrong since TopLink happens to be the reference implementation for JPA 1.0.
    "Java Persistance with Hibernate" book says that some Hibernate features are not required/enforced by JPA - is THIS the reason to use JPA instead of Hibernate?
    The reason is that coding against a standardized API has certain benefits. For instance, the ability to switch to another provider. Now you might want to ask, when does that happen? Well, it happens for instance when your initial provider goes out of business or stop caring. A lot of people had this happening to them when Ironflare stopped releasing new versions of Orion (which at one time was a very popular J2EE implementation). Instead of rewriting all their code from scratch, these people could switch to another J2EE implementation with minimal effort. Sure, there still is some effort involved, but this is absolutely not comparable to the amount of work one faces when having to rewrite an application from scratch for a completely different platform.
  31. What limitations? I mean other than some imports which are not different than e.g. import java.util.Map? And I don't think the "limitations" are undocumented - EJB3 spec also doesn't tell you that it won't make you breakfast.


    It won't, but it does specify specific limitations (or perhaps restrictions is a better word) like not being allowed to spawn your own threads or read and write from files. In Spring there are numerous similar pitfalls - things that your application code should not do since it messes up the control that Spring has over your application.
    I know these restrictions in the name of portability. And Spring pitfalls? I'm almost sure, that Spring's reference documentation (I mean every Spring product) doesn't say: "this class/module does not do XXX". After reading the docs, I know what Spring does. What it doesn't is just opposite. When there's something missing, I create a JIRA issue, when there's a bug - I create JIRA bug. I know of JCP, early drafts and community review, but like entire EJB3, it's just about 10% of what Spring has to offer (in terms of funcionality and time).

    Hmm. I don't remember it is necessary to deploy Spring Distribution with your WAR.


    Hey, and guess what? I don't have to deploy any Java EE standard classes with my application either if I deploy it to a Java EE server. Since all those classes are already provided by the Java EE server, since that is what makes it a Java EE server in the first place. This is really a silly line of reasoning. I don't deploy e.g. java.util.HashMap with my Java SE .jar either, since every Java SE implementation already provides that. Likewise, I don't deploy something like javax.ejb.EJBContext with my application, since every Java EE implementation already provides that.

    Your assumption seems to be that Java EE applications are always deployed to a bare Tomcat, so they must include things like jsf, jta, jpa, ejb themselves. But for Spring you assume all required implementation classes for Spring are already included with Tomcat or magically obtained by Maven somehow and thus your application only has to include your own classes? Don't you see the apples and oranges in that comparison?
    First - it was my response to your suggestions, that Spring weights 150MB. Second - I said, that every App Server (particularily Tomcat) has it's own e.g. servlet-api.jar. I like to look at how AS works (and yes - I've traced how JBoss invokes my EJB 2.1 beans), but why does it have to be so hard to attach servlet-api sources to running application? Tomcat has its own, Maven repos has it own and "reference J2EE 1.4 implementation" just another...



    And wait - is Spring a container? Does it manage the lifecycle of your application? Spring is partly framework (DI container - yes, here it is a container + MVC Framework) and partly a library.


    Spring is a container too. Sorry to burst your bubble, but it is. I know you Spring people have worked hard to taint the word 'container', but in the process Spring has become a container itself. I hope you at least have the wits to see the irony in that ;) I do like the alternative terminology 'proposed' by Panda, Rahman and Lane in EJB in action, where they explain a container to be a kind of extended VM from the code's point of view. Just like the basic VM handles memory management for you, the 'extended VM' handles transactions for you.

    I agree. I said that Spring is a DI Container.

    but I don't know the roadmap of EJB3


    http://jcp.org/en/jsr/detail?id=318 ?

    http://jcp.org/aboutJava/communityprocess/pfd/jsr318/index.html ?

    I do want to stress that EJB3 is a part of Java EE and as such it's probably better to look at the roadmap for Java EE as a whole too. Thanks to the early feedback requested by the EG, numerous blog postings (see e.g. http://jdevelopment.nl/open-source/java-ee-6-progress-page/) and the periodic release of specification documents long before a new version is released, it's quite easy to see where all of this is going.

    If you don't know anything about the roadmap of EJB3, then you just aren't looking.
    Too slow, too closed. And what happened to Java EE 6's Web Profile? Why JSR-299 (WebBeans) changed it's name to something that is strangely similar to what Spring provides at its core?



    I know that Hibernate is official implementation of JPA.


    I think you mean "I know that Hibernate is THE official implementation of JPA.". Please stop omitting articles, they actually have a function. But besides that, the statement is wrong. There is no 'official' implementation. There is a reference implementation though. Even if you meant to say that, you are still wrong since TopLink happens to be the reference implementation for JPA 1.0.


    "Java Persistance with Hibernate" book says that some Hibernate features are not required/enforced by JPA - is THIS the reason to use JPA instead of Hibernate?


    The reason is that coding against a standardized API has certain benefits. For instance, the ability to switch to another provider.
    Sorry, I'm from Poland and the/a articles still are difficult to me :). "Switching provider" was attractive. But now it's much more productive to stick with proven solution.


    Now you might want to ask, when does that happen? Well, it happens for instance when your initial provider goes out of business or stop caring. A lot of people had this happening to them when Ironflare stopped releasing new versions of Orion (which at one time was a very popular J2EE implementation). Instead of rewriting all their code from scratch, these people could switch to another J2EE implementation with minimal effort. Sure, there still is some effort involved, but this is absolutely not comparable to the amount of work one faces when having to rewrite an application from scratch for a completely different platform.
    It's dangerous to stick with a product, that's not supported anymore. However - is Struts 1 supported? Has it ever been supported? I don't care. I'm maintaining Struts 1 application (version 1.1) - I have docs, I have sources and I want to switch to Spring MVC, but nothing is hurrying me. Another example with standards - A few years ago I've choosen XForms standard and Chiba implementation. The standard was (is) so unreal that I've had to hack Chiba so I can use it's new versions. The same with EJB3 (maybe in slightly smaller scale) - standard is not real-life-problems driven - it's app-server-vendors-future-profits driven... best regards Grzegorz Grzybek
  32. but like entire EJB3, it's just about 10% of what Spring has to offer (in terms of funcionality and time).
    Well, it's okay if that happens to be the case for you. For me it's the other way around mostly. Don't get me wrong, I don't intend to say that Spring itself is a bad platform. Far from it, but to be honest I also see a lot of attractive things in .NET. My main point is that we should just accept that Spring has become its own platform and live with that.
    but why does it have to be so hard to attach servlet-api sources to running application? Tomcat has its own, Maven repos has it own and "reference J2EE 1.4 implementation" just another...
    I'm not sure I follow, but let me try. It seems to me you are confusing a number of concepts. You can't really attach sources for the reference implementation of any aspect of Java EE unless you happen to be running on exactly that reference implementation. If your application is running on Tomcat 6.0.18 and you want to be able to step into the source code, download the source code for Tomcat 6.0.18 and attach that. This basically gives you the ability to step into the Servlet, JSP and some of the JNDI APIs. If your application is running on Jboss AS 5.0.1, download the sources for Jboss AS 5.0.1 and attach that. Likewise for any particular version of Glassfish or Geronimo. The whole idea is that your source code attachment and the server on which you are running your application should exactly match. Java EE doesn't have a single implementation, and every implementation (by definition) implements the API classes in its own way. Having said that, the public API should be constant for every implementation for a particular version of Java EE. E.g. for Java EE you could have an ejb3.jar containing -only- the public API classes. In practice, these would consist 99.9% of only interfaces. An implementation can choose whether to bundle API interfaces into a separate .jar, or just include them in the .jar that also has the code that implements said interfaces. I do agree that Java EE implementations could do better by providing a ready-to-attach source.jar. In a lot of cases you have to untar some .tgz file first, cd into the src directory and jar up its content. If you are really out of luck then a project provides you with dozens of src directories which you all have to assemble and jar up to get an easy source attachment. This is however not something particular to Java EE implementations. Many projects suffer from this problem. Given the importance of source attachments, I'm really surprised how few Java projects provide ready-to-attach source code jars.
    Too slow, too closed. And what happened to Java EE 6's Web Profile? Why JSR-299 (WebBeans) changed it's name to something that is strangely similar to what Spring provides at its core?
    Well I agree that its slow, but the entire design phase is not at all closed. Feedback is often requested and its possible to track the design phase. Quite a number of other open source parties do give you the source code, but they don't give you any insight in their design phase. They just release code and say: "here is the code, here is the source, be happy with it". There is a difference between open source, open development and open design. There are various reasons why WebBeans changed its name, but I don't feel I'm very qualified to comment on that. Undoubtedly other people are better at that. I do want to comment on the statement that its similar to what Spring provides at its core. This by itself isn't that awkward at all. Why shouldn't Java EE offer it? If Spring offers things that are convenient, why shouldn't other platforms provide such functionality? .NET has something called ASP.NET, which happens to be quite similar to what Java EE has with JSF. Just because .NET already has something, doesn't mean Java EE shouldn't offer it anymore. It's also true the other way around, Java EE started with very convenient annotations for cross-cutting concerns. These annotations can be overridden by XML if necessary. This combination of annotations and XML allows for extremely powerful, yet utterly simple programming paradigms. My bean can provide some very sensible defaults for something with an annotation. When another application uses this bean, it's of course not a good practice to unjar the archive, change the annotation, recompile the bean and jar it again. So, in that case a simple external XML file can easily override the annotation. Compare this with Spring, which insisted for a long time on doing everything in XML. I had to work with Spring occasionally, and even though the XML Spring uses is elegant (especially the inheritance and the choice between tags and attributes), on the whole it becomes quite bulky. Now just because Java EE started with this annotation/xml hybrid, should Spring be forbidden to follow the same path?
    Sorry, I'm from Poland and the/a articles still are difficult to me :).
    Okay, I understand that ;)
    standard is not real-life-problems driven
    Well, I think it does help in quite a number of situations. Java SE itself is a standard, so my Java SE apps work everywhere. C/C++ for instance is also a standard, so the bare code compiles everywhere. This really is an advantage. I can't imagine coding in a different language for every different computer platform I came across. As I mentioned, for the Orion use case it actually was an incredible advantage. I too was working on several Orion applications and am very happy that I could continue working on them and adopting new technology after I trivially ported these to Jboss AS. Sure, I could have just let them run on Orion and they would have kept running for quite some while, but I would have been unable to take advantage of modern technologies. That means no EJB3, no Seam, no Facelets, no nothing. These applications would basically be frozen in time. Not something I look forward to.
  33. I'm not sure I follow, but let me try. It seems to me you are confusing a number of concepts. You can't really attach sources for the reference implementation of any aspect of Java EE unless you happen to be running on exactly that reference implementation.

    If your application is running on Tomcat 6.0.18 and you want to be able to step into the source code, download the source code for Tomcat 6.0.18 and attach that. This basically gives you the ability to step into the Servlet, JSP and some of the JNDI APIs. If your application is running on Jboss AS 5.0.1, download the sources for Jboss AS 5.0.1 and attach that. Likewise for any particular version of Glassfish or Geronimo.

    The whole idea is that your source code attachment and the server on which you are running your application should exactly match. Java EE doesn't have a single implementation, and every implementation (by definition) implements the API classes in its own way. Having said that, the public API should be constant for every implementation for a particular version of Java EE. E.g. for Java EE you could have an ejb3.jar containing -only- the public API classes. In practice, these would consist 99.9% of only interfaces. An implementation can choose whether to bundle API interfaces into a separate .jar, or just include them in the .jar that also has the code that implements said interfaces.

    I do agree that Java EE implementations could do better by providing a ready-to-attach source.jar. In a lot of cases you have to untar some .tgz file first, cd into the src directory and jar up its content. If you are really out of luck then a project provides you with dozens of src directories which you all have to assemble and jar up to get an easy source attachment. This is however not something particular to Java EE implementations. Many projects suffer from this problem. Given the importance of source attachments, I'm really surprised how few Java projects provide ready-to-attach source code jars.

    You're right. Servlet API may be implemented by anyone. But Tomcat is THE (thanks for short articles lesson :)) reference implementation (or was?). And I've pointed out that stepping through servlet-api.jar code should be easy with servlet-api-sources.jar attached. And the sources are different in Tomcat SVN and Maven repo. It's not EJB3 fault of course. The point is: I trust spring-core-xyz.jar and its spring-core-xyz-sources.jar - they match. It's not true with some of Java EE API jars (jax-rpc, stax, jaxb, servlet-api, el-api, jaxp, jta, mail, activation - I used all of them).
    Compare this with Spring, which insisted for a long time on doing everything in XML. I had to work with Spring occasionally, and even though the XML Spring uses is elegant (especially the inheritance and the choice between tags and attributes), on the whole it becomes quite bulky. Now just because Java EE started with this annotation/xml hybrid, should Spring be forbidden to follow the same path?
    I agree. Maybe the XML was too verbose at some time (when RoR has shown us first Convention over Configuration apps?). But take a look at Spring now. You said what others forget - XML is for ready-to-use components, annotations are for your source - then why so much noise about annotations in Servlets 3.0 spec? With modern frameworks (not only Spring MVC) it's hardly required to write servlets... Now Spring (and Spring-WS, Spring-Integration) has great annotation support allowing to write elegant and clean code.

    standard is not real-life-problems driven


    Well, I think it does help in quite a number of situations. Java SE itself is a standard, so my Java SE apps work everywhere. C/C++ for instance is also a standard, so the bare code compiles everywhere. This really is an advantage. I can't imagine coding in a different language for every different computer platform I came across. As I mentioned, for the Orion use case it actually was an incredible advantage. I too was working on several Orion applications and am very happy that I could continue working on them and adopting new technology after I trivially ported these to Jboss AS.

    Sure, I could have just let them run on Orion and they would have kept running for quite some while, but I would have been unable to take advantage of modern technologies. That means no EJB3, no Seam, no Facelets, no nothing. These applications would basically be frozen in time. Not something I look forward to.
    I agree. I can't tell that Spring will always be there and Rod & Co. will provide us with fresh, modern products. Some day it could just disappear. But now we're experiencing something similar with entire Java. Sun has been acquired and no one knows what future brings to JCP. Does Oracle have interest in development of free, open standards, when there are only competitors left? Sun said - have a free, open EJB3 spec - make some implementations. And Oracle may say - have our products - buy them. regards Grzegorz Grzybek
  34. So I do have to download at least the 30MB or so that makes up the core Spring framework, but then I only have the core. Of course I also need the web services stack, which is another 30MB. If I want a web framework (and be honest, who codes bare JSP pages today) I need to download Spring MVC, which is another 50MB. At this point I still don't have an ORM mapper, so I need to download Hibernate separately which is another 30MB. I probably need security support too, so let's download Spring security, weighing in at another 15MB.

    If you have been paying attention, I'm already well over 150MB now.
    From this I see you've never used Spring, so it would be better if you don't criticize something you don't even know. I'm really interested how did you invent those numbers. Spring core 30M? Spring MVC 50M??? And also Hibernate 30M? All together 150M? What the f...? Man, this is the most ridiculous thing I have heard for a long time. I now have the webapp build with Spring, Hibernate, Spring Security, dozen of Commons-Xxx, and some other libraries. Spring-core jar: 260K, all spring framework jars together: 3M, all libs used in web app (with Hibernate etc) together: 13M. I'm not sure about you, but for me 13M and "well over 150M" makes a difference.
  35. I'm really interested how did you invent those numbers. Spring core 30M? Spring MVC 50M??? And also Hibernate 30M? All together 150M? What the f...?
    WTF!? to you. These numbers come straight from the Spring download pages. Spring Framework Latest: 3.0.0.M2 spring-framework-3.0.0.M2-with-docs.zip (sha1) 27.0 MB spring-framework-3.0.0.M2.zip (sha1) 15.9 MB Spring Web Flow Latest: 2.0.7.RELEASE spring-webflow-2.0.7.RELEASE-with-dependencies.zip (sha1) 48.2 MB spring-webflow-2.0.7.RELEASE.zip (sha1) 10.7 MB Spring Web Services Latest: 1.5.6 spring-ws-1.5.6-minimal.zip (sha1) 1.3 MB spring-ws-1.5.6-with-dependencies.zip (sha1) 27.7 MB spring-security Latest 2.0.4 Notes (2008-10-02 16:03) spring-security-2.0.4.zip 14878133 Platform-Independent etc...
  36. Ok so it was misunderstanding, you meant the _distributions_, including documentations, samples, all optional dependencies, etc, not pure jars. This makes a difference. From my point of view, it doesn't matter that much if Spring distribution is of 10M, 50M, or 150M. I download it once, or even not at all, since I need only jars retrieved by maven, and documentation is online. I meant heavy web EJB-capable servers in terms of startup time and memory footprint, when compared to lightweight Tomcat.
  37. Have you seen startup time for glassfish or even jboss? Glassfish and Jboss perform lot faster on our dev amchines and test VM's compared to tomcat and tomcat does NOT even have comparable management/monitring/clustering features. Spring had its place and time but honestly it is now over. If for building something more than a simple web app, one ends up assembling the whole stack . In the end is it worth the effort considering we can get everything preassembled? the answer is no. Spring does have lot of usable modules (e.g. spring-ldap which we heavily use) but as a platform it is no longer relevant. I agree with Brian Silberbauer, that some people have perhaps invested too heavily into spring which makes it difficult for them to move on to a better platform.
  38. you meant the _distributions_, including documentations, samples, all optional dependencies, etc, not pure jars. This makes a difference. From my point of view, it doesn't matter that much if Spring distribution is of 10M, 50M, or 150M. I download it once, or even not at all, since I need only jars retrieved by maven
    That's true, but your application does need those jars retrieved by Maven eventually. So if Maven starts downloading 40MB total of jars, then your application still uses that. It's a little deceiving to say that Spring only requires 115KB orso of jars, since that probably only contains the interfaces. As you might know, an interface doesn't contain any executable code, so in order for Spring to actually -do- anything, an implementation jar is still needed. Whether you download that upfront, let Maven download it, or deploy to a readily available Spring AS doesn't make any difference and doesn't make the code go away.
    I meant heavy web EJB-capable servers in terms of startup time and memory footprint, when compared to lightweight Tomcat.
    Dear adgsa, lightweight Tomcat doesn't run Spring applications. lightweight Tomcat runs bare Servlets and JSP pages with scriptlets, nothing more. If you want Tomcat to run Spring applications, you have to add Spring libraries. If you do that, it's not lightweight anymore. A bare Tomcat starts up pretty fast, but if you only add Hibernate/JPA then the startup time already increases a lot. Add additional stuff like JSF, JTA, Quartz, and the difference in startup time between Tomcat and Jboss becomes much less. Now disable things you don't need in Jboss and startup times are fairly equal. What was your point again? Do you advocate using JSP and Servlets and nothing more?
  39. Spring and EJB (again)[ Go to top ]

    I think a lot of people are going off the deep end on this one and I suppose one does when you invest heavily in a particular framework. I think this is an important consideration when comparing JEE and Spring or any other framework (there are others): If nothing else JEE provides some standardization and dumbs down your choices to a degree (and this can be a good thing). I've been following EJBs since early in their inception, but never use them until EJB3, in fact I had been vocally opposed to them and welcomed the Spring Framework with open arms. That was until I created a new project in Spring after a few months distance: It took me a good few days figuring out all the configuration issues, documentation was fragmented between versions and once I'd got it all working I was not comfortable with the end result. It feels like there is just too much being added into Spring and you are never sure what libraries are necessary for your project and which versions of libraries you can upgrade etc.. With EJBs there is now a standard stack, it is easier to set up and use than Spring, it is well supported and there are a lot of documentation and tutorials. Spring played an important role and still had an important role to play, but they need to make some radical changes similar to the changes in the new JEE specs. Is it agile enough to accommodate those changes?
  40. Well the post was about JEE 6 and it turned out to be a Spring merits VS Everyone else! Well for me it tells much about the ethics and health of such community... We all know the old story... I won't take it back again. If you're happy with your springenousty stick with it :) Opensource is all about choices! Let me know what others have to offer and make my own choice! Please don't interfere and make noise when all I need is clarity about some other topic outside of your ApplicationContext! Next time when you want to make some poor marketing for your cherished do it in a separate thread! Daoud AbdelMonem Faleh.
  41. I don't think startup time, size of the files or even the time to complete the first request after start to really matters. The most inexpensive server disk still has a gigabyte size and the server gets restarted maybe each few weeks. A gain in start time of 50% is less important than a 1% improvement in transaction speed, since the server spends most of its time with the transactions. I find the EJB technology only usable for a limited type of applications. It would be impossible to imagine an EJB application working with terabyte size bioinformatics data, or returning a million elements XML as a Web Service response. EJB does even not allow the simple pattern of a task started that is expected to take from a few minutes to a few hours (such as an analysis query or a report), of which the user should be able to see the progress status and to cancel the task. Even in its traditional range of usage, the applications handling a lot of small fast transactions, i find a lot of place to improve. I am wondering if somebody imagined to unify the presentation, application and storage layer in a single server entity, spawn on a cluster of networked workstations. Such a system may beat on performance/price factor the current server architecture with one or two orders of magnitude, while assuring an almost linear horizontal scalability. Also it is improvable the amount of code a developer has to write for "plumbing" compared with the actual "business logic" code. Still the current EJB paradigm balances 95-98% of the code to plumbing with the rest if 5-2% of business logic. EJB 3 was a great simplifier by reducing the redundancy in code and descriptors, but it is far form being perfect.
  42. I don't understand why some people are so angry about the enhancements in an existing specification/programing model. If you are happy with framework X and it fulfills all your requirements then go for it. Nobody forces you to switch. These are different approaches for solving the same type of problems. This is a common practice in all domains and usually most consumers welcome having multiple choices instead of one-size-fits-all approach. To me, saying that we don't need framework/solution X because framework/solution Y already is there is like saying we don't need cars from company A because company B already making similar cars.
  43. Enterprise OSGi[ Go to top ]

    The new features in EJB 3.1 are very good but I am not sure that this will save Java EE from crash. I am using Java EE from many years (8+) and in the same time I am already familiar with Enterprise OSGi. Comparing both technologies, I definitely assert that Enterprise OSGi is better. There are many advantages and no disadvantages (because only the good ideas are taken from Java EE). The most important advantage for me is the possibility to separate one big library (Web, EJBs, etc.) in many small parts and started dynamically as bundles. The Distributed OSGi gives more extra advantages also.
  44. RE: Enterprise OSGi[ Go to top ]

    The new features in EJB 3.1 are very good but I am not sure that this will save Java EE from crash. I am using Java EE from many years (8+) and in the same time I am already familiar with Enterprise OSGi. Comparing both technologies, I definitely assert that Enterprise OSGi is better. There are many advantages and no disadvantages (because only the good ideas are taken from Java EE). The most important advantage for me is the possibility to separate one big library (Web, EJBs, etc.) in many small parts and started dynamically as bundles. The Distributed OSGi gives more extra advantages also.
    Am also eager to see something done in this area but I think better to come from D-OSGi part as stated in Eric Newcomer Blog: here Enterprise OSGi is not: - Java EE - but EE components are being mapped to OSGi
  45. Now we have to wait EJB 4 to have Singleton bean per User session. As idea the Stateful bean is similar but not exactly. For example if one Stateful bean is used inside of the EJB Container there is no guarantee that all calls from the same user session will use the same bean instance. The specification guarantee that only if the Stateful bean is called outside of the EJB Container (from Web Container or Application Client). For example if my application need to store some data which is specific for the user session this can be done using ThreadLocal (but in this case this is not good idea for load-balance or distributed servers) or in the Web container. Unfortunately if the client is Application Client where the network traffic and security are critical issues then to store that information in the client is not good idea. So, are there any plans for Singleton bean for User session?
  46. Now we have to wait EJB 4 to have Singleton bean per User session. As idea the Stateful bean is similar but not exactly. For example if one Stateful bean is used inside of the EJB Container there is no guarantee that all calls from the same user session will use the same bean instance.
    The specification guarantee that only if the Stateful bean is called outside of the EJB Container (from Web Container or Application Client). For example if my application need to store some data which is specific for the user session this can be done using ThreadLocal (but in this case this is not good idea for load-balance or distributed servers) or in the Web container. Unfortunately if the client is Application Client where the network traffic and security are critical issues then to store that information in the client is not good idea.
    So, are there any plans for Singleton bean for User session?
    Store the reference to the SFSB in your user session or go for web beans (jsr 299).
  47. I like this from the article ...[ Go to top ]

    "we fist clean and rearrange the house, and only then we bring the new furniture"- even though there were some new features as well, like the support for interceptors. Now that the cleaning is done, it is time to benefit from it and to go one step beyond." And I like the forthcoming option of having Session beans without interfaces (although in most cases it's good practice to have them anyway). Adding spec for singletons is good, as is Asynchronous Invocations. Really EJB3, and the full JEE stack, is improving quite nicely. I like that with EJB3, and a JEE app server, everything that any enterprise app might need is just there, and that it they various libraries are lazy-loaded (for efficiency sake), and that it has interceptors, and DI via annotations (which can be overriden by XML config), and sane defaults (like transactional support) - convention over configuration. And in my experience with both Glassfish and JBoss, developing and deploying an EJB3 oriented app was relatively painless, and the start up times and memory usage of the app servers were not exorbitant. All in all a very pleasant experience. Contrast that with Spring, in my experience, I had to work a lot harder getting everything set up - a lot more configuration, needed functionality had to be downloaded and configured (wired in), compiling/building/setting up ant or maven was more complicated, and deploying was more complicated. Now, back in the day, Spring was a total breath of fresh air as compared to EJB2.x. Using Spring over EJB2.x was an absolute no-brainer. But now with EJB3, Spring isn't such a no-brainer anymore. In fact, at least in my experience, EJB3 is much more pleasant. And please, Spring camp, cease and disist posting about how you think Spring is still better, in threads that are merely talking about new EJB features. There's no point in doing so. It ends up being a pissing match, and it only makes you look insecure about the virtues of Spring vs EJB3. In other words, if Spring is better for you, just go about your business happily. You don't do yourself or anyone else any good posting "oh yeah, Spring is still much better", or "there's no need for EJB3", or whatever, in EJB3 threads.
  48. Excelent![ Go to top ]

    For me, EJB 3.1 fixes all that was missing from EJB 3.0 Singleton, Async calls, more powerful Timers, standardization on Global JNDI, EJB Lite. I was missing all these when I used EJB 3.0 Now I'm sure that when I'll use EJB 3.1 I'll find something else missing :) but I must say at this point EJB 3.1 looks great for me. ps: I think I spotted a mistake in the article. "The spec defines that with asynchronous invocations the control must return to the client before the container dispatches the invocation to the bean instance." But then in the code example: public void invokeSayBye() { try { Future futStr = byeEjb.sayBye(); } catch(ExecutionException ee) { String originalMsg = ee.getCause().getMessage(); System.out.println("Original error message:" + originalMsg); } } I believe that byeEjb.sayBye() should not throw an exception. Calling futStr.get() would.
  49. Spring users should welcome this[ Go to top ]

    As a Spring user since 2003, I think EJB 3.1 looks very promising. And I think if you're a satisfied Spring user, you should be very pleased to see how EJB 3.1 looks. A couple years ago, I had to work on an EJB 2.x system, and it was painfully difficult to develop/build/deploy/test/you name it. I'd hate to have to go work on an EJB 2.x system. But a couple years from now, if I had to go work on an EJB 3.1 system, I'd look forward to doing so. Assuming Spring wasn't present at all in the system, I know I'd miss some of the goodies provided by the core Spring framework, but I'm sure there'd be some other nice benefits provided by the EJB 3.1 container that I miss out on when using Spring. It is ridiculous to think that either the EJB spec or Spring should "go away". While Spring still complements the standard (in fact, you could probably implement EJB 3.1 using the Spring framework), it continues to provide an excellent alternative to the standard. And standards need alternatives - without them, standards will fail to innovate as quickly as users need them to. Think about it - if you're a Java developer, and you'd like to keep developing Java for as long as possible, you NEED EJB 3.1, and you NEED Spring, and you NEED Seam, and you need everything else that furthers innovation in the Java language. You don't need to actually use them, but when these standards and alternatives stop innovating, you're going to need to find another language to develop in, and that'll be a much more difficult change (e.g. you may not be able to find a job) than simply switching from Spring to EJB 3.1, for example.
  50. Great post! I agree with everything you said. All camps keep inovating, and leapfrogging each other. That great for Java! And it's great to have multiple, viable (and similar in approach) solutions, that learn from each other, all built on Java.