Article: The New Features in EJB 3.1

Discussions

News: Article: The New Features in EJB 3.1

  1. Article: The New Features in EJB 3.1 (193 messages)

    "The New Features in EJB 3.1" is a preview of the changes the EJB 3.1 expert group is working on for the next version of the Java EE specification. The idea is to give you a head's up on the changes as well as gather your feedback early so the expert group has the best chance of getting it right. EJB 3.0 brought simplicity to Java EE 5 by moving away from a heavyweight programming model. EJB 3.1 aims to build on those successes by moving further down the path of simplicity as well as adding a handful of much-needed features. In each article in this series, Reza Rahman lets you know about the progress made by the expert group over the next few months. The first article covers the two features that have been discussed in detail so far—making interfaces optional for EJBs and Singleton Beans. You'll also get a look-ahead into the possible features yet to be discussed. Remember, none of this has been finalized yet; all of this is really just a peek into the inner workings of the JCP so that you have a chance provide early feedback.

    Threaded Messages (193)

  2. The concurrency annotations look interesting, but don't make special annotations for each of them.
    Just adding attribute values is simple and clear enough, don't complicate by adding lots of variants.
  3. Christophe, Would you mind sending this comment to the expert group at jsr-318-comments at jcp dot org? That would make it "real" for the committee members and the spec lead. It would help me out too so I don't have to be the second-hand source (which I don't mind at all, it's just less effective). Cheers, Reza
  4. I agree with Christophe; please use parameters, otherwise you have to work out all values of all parameters in all permutations. With only one parameter and only a few values this seems doable, but it probably will cascade into unmanagability pretty quick... component.setAlignment(SwingConstants.LEFT); or component.setAlignmentLeft(); component.setAlignmentCentered(); component.setAlignmentRight(); The latter also can make sense, but you combine the property being set and its value.
  5. We ported 75% of project written in ejb to light weight programming using spring. We are planning to convert the remaining ejb project after 2 months. Is ejb still necessary in this day and age?
  6. Re: Article: The New Features in EJB 3.1[ Go to top ]

    We ported 75% of project written in ejb to light weight programming using spring. We are planning to convert the remaining ejb project after 2 months.
    Is ejb still necessary in this day and age?
    Yes, I actually like EJB 3. In comparison, I would prefer not to use Spring, even though it is one of most popular framework. I like what spring can do and its concept. But I don't like to program in XML. Spring turns java programming into XML configuration (or programming depending how do you look at it), which turns me off. I have followed Spring from very beginning, even before the Spring becomes the spring, read Rod Johson's 1st book several times and incorporate the JDBC template into one of the project (before Spring becomes a project). Not so closely recently. I think Spring can use Annotation instead of XML now, but I rather use EJB 3 and JPA. Our old project is EJB 2.x and our new project is EJB 3 with JDK 1.6. I like it a lot. In case we need AOP, I just directly programming in AspectJ, which is pretty easy to do (except Intellij doesn't like it). There may still some short comings in EJB 3, but so far I can still tolerate them. I might change my positions, but this is my current state of the mind. Chester
  7. There may still some short comings in EJB 3, but so far I can still tolerate them.
    Chester, Mind sharing your thoughts? What would you like to see? Reza
  8. There may still some short comings in EJB 3, but so far I can still tolerate them.


    Chester,

    Mind sharing your thoughts? What would you like to see?

    Reza
    Reza, here are few things on my mind, Disclaimer: Since I never exactly sure the clear boundaries between EJB3 and JPA, so comments and wish lists are mixed for both EJB 3 and JPA. Also, If you found something wrong, I would be glad that you point out to me. The list is a bit long, hope you don't mind. Chester 1) For EJB 3, I wish there is a startup class that allows me to do application-wide initialization before any Session Bean is used. Currently, what I do is to make an abstract Base Session Bean and make sure all SessionBean (Stateless) extends from the Base Session Bean. In this abstract base session bean, we use @PostConstruct method to do the initialization. And we carefully make sure the initialization is only done once. Perhaps @Singleton will help here. But I still want start up class so that nothing got initialized before start up class is called. 2) Dealing with Cached Entity Beans. EntityManager.merge() method acts more like add() instead of merge(). I am not sure this is intension of the spec or due to the specific vendor’s implementation. This is not desirable. In some cases, we cache the resulting entities from finder method or search. The cached entities, when we ready to use them, has to be “merged” with EntityManager.merge() method to put back to the persistence context in order to use JPA‘s query language. Since merge() is more like add(), the next JPQL select query may cause entity manager to “persist” an “new entity” in the context. This becomes really problematic under concurrent multi-threaded situation. So far, we are able to avoid this problem by reducing the use of JPQL and use native query instead. With native query, we don’t need to call merge() method. But In general, how do one use Cached Entity Bean with Entity Manager ? 3) Entity model doesn’t seem to support certain modeling: Suppose I have two tables in database: CREATE TABLE NODE ( NODE_ID NUMBER(38), -- CONSTRAINT PK_NODE PRIMARY KEY(NODE_ID) ); CREATE TABLE SUB_NODE ( SUB_NODE_ID NUMBER(38), SUB_NAME VARCHAR(125), -- CONSTRAINT PK_SUB_NODE PRIMARY KEY(SUB_NODE_ID), CONSTRAINT FK1_SUB_NODE FOREIGN KEY(SUB_NODE_ID) REFERENCES NODE ); In this case, table Sub_node is “derived” from table Node: sub_node’s PK is the also FK to Node Table. I would like to model the objects with Node and SubNode objects. When A SubNode is created, Node must be inserted first into NODE table to satisfy the relational constraint; but I would also be able to create Node Object independently without Sub_node. To do above, I would hope to to do something like this: @Entity @Table(name=”NODE”) class Node { } @Entity @Table(name=”SUB_NODE”) class SubNode extends Node { } But this is not allowed. One can @SuperClass annotation for Node, that would be ok for SubNode object; but it can not create Node object independently. 4) Validation Support EJB 3.x should enable EntityManager support validation out of box. For example, we have the following table and entity for Node with node Name column. @Entity @Table(name=”NODE”) class Node { @Column(name=”node_name”) private String nodeName; public String getName() { return this.nodeName; } } During the EntityManager.persist() call: entityManager.persist(new Node(“this is a very long node name”)); EntityManager should automatically validation the name value size and make sure the size is not longer than the column size of the Node table. This can be easily done by extract Entity’s table name, and get the table’s metadata (column infos) and cached them. Then use reflection or other methods to get String field value and compare the size with cached column size. We did it use reflection. In this case we have to add additional annotation to make sure we can get the public accessible field value. Something like : @Column(name=”node_name”) @FieldMapping(getter = “getName”) private String nodeName; @FieldMapping is our own customized annotation. The validation should not limited to String fields, but also to numbers (MAX VALUE, MIN VALUE), TIME (BEFORE, AFTER) etc. Additional annotation or other mechanism would be needed to provide the properties for the fields. 5 EntityManager should add more supports for createNativeQuery. EnityManager uses createQuery(sql) to create a JPQL Query. The SQL is a JPQL string which allows parameter place holder “?” or named parameter in the format “:”. Since the JPQL already know the Entity’s class by parsing the JPQL string, the query’s getResultList() or getSingleResult() methods require no class cast. On the other hand, EntityManager.createNativeQuery(sql, Class) only support “?” and doesn’t support named argument “:”; and the results from the query in getResultList() and getSingleResult() requires one to do class cast. List results = (SubNode) query.getResultList(); As result,in every method having such use, we have to add @SuppressWarning("unchecked") annotation. This is a bit of shame. As one can easily change EntityManager to supports both functions. We actually did on our own. But I thought EntityManger should support this out of box. Query q = EntityManager.createNativeQuery(sql, Class); List results = q.getResultList(); And named arguments can be easily supported as well. 6.Query should be able to access underline meta data of the database, table and column just like what we can do in JDBC. Otherwise, we have to part in JPA query, another part in JDBC. 7.Query should support Map results with column name as the key. JPA currently supports getResultList() method to return query results. For native query, this requires one to know the position of the each column such as “ select a, b, c from mytable”. But one can not use “Select * from mytable” in native query. As now I would not know if the 1st column is “a” or “b” or “c” anymore. Map results = Query.getResultMap() would solve this problem. 8. Query doesn’t support JDBC Batch query. In many cases, batch update/insert is much faster for large amount of insert/update. This is not the “Batch” in JPQL, which is really simply set operation. I am referring the following: String sql = "INSERT INTO CUSTOMERS VALUES (?,?,?)"; PreparedStatement stmt = con.prepareStatement(sql); stmt.setInt(1,1); stmt.setString(2, "J Smith"); stmt.setString(3, "617 555-1323"); stmt.addBatch( ); stmt.setInt(1,2); stmt.setString(2, "A Smith"); stmt.setString(3, "617 555-1132"); stmt.addBatch( ); int[] upCounts = stmt.executeBatch( ); con.commit( );
  9. Chester
    1) For EJB 3, I wish there is a startup class that allows me to do application-wide initialization before any Session Bean is used.
    I agree. This is a very important point and I hope it's addressed in future versions of the spec. Your other points all concern JPA, which is now a separate specification. I suppose you should send them to that expert group's email alias... Rgds Rod
  10. Chester

    1) For EJB 3, I wish there is a startup class that allows me to do application-wide initialization before any Session Bean is used.

    I agree. This is a very important point and I hope it's addressed in future versions of the spec.

    Your other points all concern JPA, which is now a separate specification. I suppose you should send them to that expert group's email alias...

    Rgds
    Rod
    Although I didn't dive into the details of it in the article, this is actually one of the intended uses for Singleton Beans. You can mark methods on Singetons with @Startup and @Shutdown. These methods will be called when the container starts-up and shuts-down respectively. Is this what you were looking for? Reza
  11. Although I didn't dive into the details of it in the article, this is actually one of the intended uses for Singleton Beans. You can mark methods on Singetons with @Startup and @Shutdown. These methods will be called when the container starts-up and shuts-down respectively.

    Is this what you were looking for?

    Reza
    Why not just add a well-known @Observes event for startup and shutdown, like javax.ejb.StartupEvent and javax.ejb.ShutdownEvent?
  12. Why not just add a well-known @Observes event for startup and shutdown, like javax.ejb.StartupEvent and javax.ejb.ShutdownEvent?
    Scott: Can you kindly elaborate on this? Thanks, Reza
  13. Event handling[ Go to top ]

    Why not just add a well-known @Observes event for startup and shutdown, like javax.ejb.StartupEvent and javax.ejb.ShutdownEvent?


    Scott:

    Can you kindly elaborate on this?

    Thanks,
    Reza
    Startup and Shutdown are really system-wide events, so they should be handled like events. The WebBeans API has a very nice general event-handling system based on an @Observes parameter annotation. To listen for a StartupEvent, you'd write: import javax.ejb.*; import javax.webbeans.*; @Singleton public class MySingleton { public void startup(@Observes StartupEvent event) { ... } public void shutdown(@Observes ShutdownEvent event) { .. } } The beauty of that system is that its totally general, simple, and type-safe (in the sense of only sending events to receivers that understand StartupEvent.) Plus, you could theoretically add data to the StartupEvent (I don't think I'd recommend doing that in the spec, though.) So instead of creating a aspect with @Startup or @Shutdown, you would just be creating a new Event class, i.e. it would be a simpler solution (since aspects are intrinsically more complicated than event classes.)
  14. There may still some short comings in EJB 3, but so far I can still tolerate them.


    Chester,

    Mind sharing your thoughts? What would you like to see?

    Reza


    Reza,
    here are few things on my mind,
    Disclaimer:
    Since I never exactly sure the clear boundaries between EJB3 and JPA, so comments and wish lists are mixed for both EJB 3 and JPA.

    Also, If you found something wrong, I would be glad that you point out to me.

    The list is a bit long, hope you don't mind.

    Chester



    1) For EJB 3, I wish there is a startup class that allows me to do application-wide initialization before any Session Bean is used.

    Currently, what I do is to make an abstract Base Session Bean and make sure all SessionBean (Stateless) extends from the Base Session Bean. In this abstract base session bean, we use @PostConstruct method to do the initialization. And we carefully make sure the initialization is only done once. Perhaps @Singleton will help here. But I still want start up class so that nothing got initialized before start up class is called.

    Chester, Instead of creating an abstract session bean and extending it, couldn't you use default interceptors?
  15. It's indeed very nice to see the ejb spec leaders are willing to listen from the community. And it's really very painful to see the spring folks are disrupting the entire thread. If you just analyze every single reply in this thread, almost 80% of the replies were comparing spring and ejb. Yes, it's true that ejb was over engineered and was very complex to use. But one needs to really admire the effort put by the spec leaders to give a much better solution in ejb 3.0. We use ejb 3.0 in some of our projects and we are pretty much satisfied with it. Let spring be the best framework out there. But what prevents you all from providing suggestions to improve the ejb spec? So it really looks like, most of you don't want the ejb spec to improve. Or on the other hand, looks like you don't like competition. Like many web frameworks ranging from JSF, Wicket, GWT etc.. why not there be many application frameworks? Or why not try to make spring a "Java EE" standard like seam is doing with "web beans" JSR? It would be very interesting if the guys who thump "spring is the best" can list down the features which spring has now which has no equivalent in ejb. That would be very helpful for the spec leaders to collect much more valuable information. And i personally feel that ejb is going in the right direction. And any product/project which listens to the community has been successful. Keep up the good work ejb team. And it's really heartening to see Reza responding to most of the replies. And i would like to add some suggestions on my behalf. (Though it may look non-trivial) I still find the JNDI lookups (especially for remote ejbs) still a bit complex. And i would like to see the ejbs running in servlet containers (as proposed in the ejb 3.1 spec)
  16. And one more thing.... (please correct me if i'm wrong) Since ejb uses RMI-IIOP underhood, there is no way (atleast to me!!) to define the ports used for communication. I would like to see something like: lookup "MySessionBean" which is deployed on "ServerName:port number", from this "local port". Also i would like to know, if there is a way to have "secure" lookups, say, using ssh or similar techonologies?
  17. If EJB3 is no longer EJB (i.e. EJB 1 & 2), why are you insisting calling it EJB? Will the Java community be better served if the baggage of EJB 2.1 is thrown out of the window? When that happens, I don't think there can be disruption/distraction from Spring any more. And Spring couldn't have become so popular and widely used without (the help of) EJB 1 & 2. Just look at .NET people. Let's put another nail on the coffin.
  18. George:
    If EJB3 is no longer EJB (i.e. EJB 1 & 2), why are you insisting calling it EJB?
    While the look, feel and implementation of EJB has changed drastically, EJB still remains what it started out as - a middleware platform for developing application components. That's why it's a cheap marketing gimmick to rename it. Can you understand why this might be distasteful to a bunch of mostly engineers sitting on a technical committee? It's also disrespectful to all the early EJB adopters who have stuck by it through good times and bad.


    Will the Java community be better served if the baggage of EJB 2.1 is thrown out of the window?
    Could you kindly specify what features you are talking about? Thanks, Reza
  19. While the look, feel and implementation of EJB has changed drastically, EJB still remains what it started out as - a middleware platform for developing application components. That's why it's a cheap marketing gimmick to rename it.
    I would think it is the the other way around. Keep the EJB brand (since it was such a big brand) is cheap marketing.



    Will the Java community be better served if the baggage of EJB 2.1 is thrown out of the window?

    Could you kindly specify what features you are talking about?

    Thanks,
    Reza Reza, even the most popular and widely used EJB - SLSB still has the same semantics in EJB3 as in EJB1 and EJB2, e.g. single threaded, coming from a pool, going back to a pool etc. That is not POJO! I think the Spring people have a more comprehensive list and they publish it here and there.
  20. I would think it is the the other way around. Keep the EJB brand (since it was such a big brand) is cheap marketing.
    Is there a point here? You just contradicted yourself by stating that EJB is indeed a useful brand? Then why bother renaming it if the fundamental goals+concepts of the framework have not changed? I am confused...are we just arguing for arguments sake? I don't want to be rude, but I just don't have the time for pointless p!ss!ng competitions.
    Reza, even the most popular and widely used EJB - SLSB still has the same semantics in EJB3 as in EJB1 and EJB2, e.g. single threaded, coming from a pool, going back to a pool etc. That is not POJO!
    FYI, what you are talking about is really just an implementation detail. Much like the Spring prototype model, vendors can simply instantiate new objects instead of using an actual pool (I think JBoss AS does this, but I am not sure). According to your thought process, sounds like you have trouble with byte-code injection or code generation too (essentially the only two underlying ways of providing declarative services in Java). Container interception is really no different than either of these techniques, it's just that it doesn't monkey with the actual bean class and uses a proxy model instead. The point is that you don't need to do anything else to a Java object other than add metadata to it to get the framework to get you declarative services and scoping. I'd call that a POJO. If you want to split hairs, knock yourself out! Reza
  21. Is there a point here? You just contradicted yourself by stating that EJB is indeed a useful brand?
    "It was a big brand" does not mean it is a useful brand anymore. In fact, I think it is dying brand and you are spliting your hair try to revive it.
    Then why bother renaming it if the fundamental goals+concepts of the framework have not changed?
    We finally see some truth here.
  22. Then why bother renaming it if the fundamental goals+concepts of the framework have not changed?


    We finally see some truth here.
    Are you sure it has not changed? I think it has. All this talk about POJOs boils down to doing Object construction in an OO fashion in Java. By this I mean not tying Object construction to a specific Class (implementation). The original goals of EJB were very different. It was meant to be a component model. The idea was that you could by third-part EJB components off the shelf. In the same way that you could buy OLE components. It didn't work. The reason? Well class loader hell to start off with, and a bunch of other (language related) issues. It appears to me that EJB3.x is trying to drop this original goal, in which case EJB will become just another DI framework just like Spring or Guice but using standardised annotations. Paul.
  23. The original goals of EJB were very different. It was meant to be a component model. The idea was that you could by third-part EJB components off the shelf. In the same way that you could buy OLE components.
    Paul: With all due respect, I think you are talking about the idea behind JavaBeans, not EJB. Or if we stretch things around a bit, maybe that's true of EJB 1.x. EJB 2.x clearly is about declarative platform services built on a basic component model. While the components in the model and the services are evolving (such as adding DI), EJB is still essentially a server-side business-logic development platform. I'm still note sure all this semantic hair splitting actually matters to most developers... Reza
  24. The original goals of EJB were very different. It was meant to be a component model. The idea was that you could by third-part EJB components off the shelf. In the same way that you could buy OLE components.


    Paul:

    With all due respect, I think you are talking about the idea behind JavaBeans, not EJB. Or if we stretch things around a bit, maybe that's true of EJB 1.x. EJB 2.x clearly is about declarative platform services built on a basic component model.

    While the components in the model and the services are evolving (such as adding DI), EJB is still essentially a server-side business-logic development platform.

    I'm still note sure all this semantic hair splitting actually matters to most developers...

    Reza
    I think it matters a lot. Especially if you took the Sun "J2EE best practices" at its word. Remember the j2EE roles of bean assembler, deloyer etc? Well I actually tried to do this stuff. We bought a third party EJB (2.1) and tried to integrate it into our Enterprise Application (EAR), and hit a bunch of class loader problems inherent in the J2EE specs. I believe OSGi solves a lot of these problems, AFAIK they still exist in EJB. The term "Bean" means component, and EJBs are meant to be enterprise components that are either co sited (local interface) or remote (remote interface). If all this has changed, then Sun should just come out plain and say it. Paul.
  25. I believe OSGi solves a lot of these problems, AFAIK they still exist in EJB.
    I agree and the problem is at the Java EE packaging and deployment level. There was some talk of straightening out class-loading requirements, but I don't think that went anywhere really (I'm on the Java EE 6 committee too)...honestly though, I haven't had any serious problems with this for a long time...
    The term "Bean" means component, and EJBs are meant to be enterprise components that are either co sited (local interface) or remote (remote interface). If all this has changed, then Sun should just come out plain and say it.
    Yes, the component and interface demarcation still exists (kind of, as local interfaces have been made optional too). Basic component types (essentially mapping to various service/scoping models prevalent in server-side apps) remain the same with a few additional ones added. The metadata model has changed radically, so have the declarative and programmatic APIs. A lot has changed. Little has changed. Ultimately I guess it's in the eye of the beholder... Is Kitty Hawk and the F-16 both planes? Yes, they both perform the same function under the same basic principles. Are they different? Yes, that's true as well - they are implemented pretty differently and look pretty d@mn different too. Reza
  26. I believe OSGi solves a lot of these problems, AFAIK they still exist in EJB.


    I agree and the problem is at the Java EE packaging and deployment level. There was some talk of straightening out class-loading requirements, but I don't think that went anywhere really (I'm on the Java EE 6 committee too)...honestly though, I haven't had any serious problems with this for a long time...

    The term "Bean" means component, and EJBs are meant to be enterprise components that are either co sited (local interface) or remote (remote interface). If all this has changed, then Sun should just come out plain and say it.


    Yes, the component and interface demarcation still exists (kind of, as local interfaces have been made optional too). Basic component types (essentially mapping to various service/scoping models prevalent in server-side apps) remain the same with a few additional ones added. The metadata model has changed radically, so have the declarative and programmatic APIs.

    A lot has changed. Little has changed. Ultimately I guess it's in the eye of the beholder...

    Is Kitty Hawk and the F-16 both planes? Yes, they both perform the same function under the same basic principles. Are they different? Yes, that's true as well - they are implemented pretty differently and look pretty d@mn different too.

    Reza
    Hi Reza, I read this to mean that the programming API has changed some, but it is still the same old EJB2.1 under the covers. So nothing has been done on the fundamental packaging and deployment flaws. Not surprising really since this was always going to be the hard part to fix! Thanks for clarifying. Not wanting to be derogatory, but the phrase "lisptick on a pig" comes to mind. Good luck with the spec. Paul.
  27. I read this to mean that the programming API has changed some, but it is still the same old EJB2.1 under the covers.
    Kind of depends what you mean by "same old". Let me be more specific. The basic concept of stateless, stateful and message driven beans still exists. Among other bean types, Singletons have been added. Entity beans have morphed into JPA as well as JPA Entities and are no longer managed by the container. The other programmatic API, metadata, service lookup, packaging, deployment changes are too many to outline. In summary, the stuff that 95% folks complained about in the old programming model is gone. The stuff folks will probably most likely continue to complain about is DI and AOP, neither of which require a change in the basic programming model (quite honestly, I'm not even sure how many people will really even complain about that. Few of the large number of folks sending in comments have actually asked for it. It just seems like a complaint originating from the very core of the Spring crowd but not going much farther, but I could be wrong. The largest number just want to be able to inject EJBs into non-managed components instead of having to do lookups). Really, you'd have to look at it and judge for yourself. Again, it's all in the eyes of the beholder.
    So nothing has been done on the fundamental packaging and deployment flaws. Not surprising really since this was always going to be the hard part to fix!

    Thanks for clarifying.
    Again, kind of depends on what you are talking about. The old deployment descriptors are optional. Packaging is being simplified right now. If you are talking about class-loading, that remains a problem, but a problem for Java EE applications in general.
    Not wanting to be derogatory
    No offense taken. It's not like you're calling my kid ugly, me stupid or a liar...it's just a technology that I (and many others) think is worth salvaging. I'd do the same for any other Java standard technology that I thought could use my help...EJB was on top of the list...
    Good luck with the spec.
    Thanks, I'll need it!
  28. Re: Article: The New Features in EJB 3.1[ Go to top ]

    Is Kitty Hawk and the F-16 both planes?
    No? :) http://en.wikipedia.org/wiki/Wright_Flyer But your meaning is understood ... :)
  29. The original goals of EJB were very different. It was meant to be a component model. The idea was that you could by third-part EJB components off the shelf. In the same way that you could buy OLE components.


    Paul:

    With all due respect, I think you are talking about the idea behind JavaBeans, not EJB. Or if we stretch things around a bit, maybe that's true of EJB 1.x. EJB 2.x clearly is about declarative platform services built on a basic component model.

    While the components in the model and the services are evolving (such as adding DI), EJB is still essentially a server-side business-logic development platform.

    I'm still note sure all this semantic hair splitting actually matters to most developers...

    Reza
    I don't usually agree with Paul Beckford, but he is on the money about this one. EJB, *Enterprise* JavaBeans, was an attempt to do for the java enterprise what VB did for the Windows market, namely the creation of third-party components fit for server-side consumption The numerous reasons why this failed are, I think, very well understood by now.
  30. The original goals of EJB were very different. It was meant to be a component model. The idea was that you could by third-part EJB components off the shelf. In the same way that you could buy OLE components.


    Paul:

    With all due respect, I think you are talking about the idea behind JavaBeans, not EJB. Or if we stretch things around a bit, maybe that's true of EJB 1.x. EJB 2.x clearly is about declarative platform services built on a basic component model.

    While the components in the model and the services are evolving (such as adding DI), EJB is still essentially a server-side business-logic development platform.

    I'm still note sure all this semantic hair splitting actually matters to most developers...

    Reza


    I don't usually agree with Paul Beckford, but he is on the money about this one. EJB, *Enterprise* JavaBeans, was an attempt to do for the java enterprise what VB did for the Windows market, namely the creation of third-party components fit for server-side consumption

    The numerous reasons why this failed are, I think, very well understood by now.
    David, I agree with the failure of EJB as a component model, but I don't agree that the reasons are very well understood. If they were people would not be comparing Spring with EJBs. Spring and EJBs are two very different things. EJBs purposes is a lot closer to OSGi, yet OSGi has hardly had a mention here. On the contrary, I believe the issues aren't very well understood at all. And they stem from the Java language. If people could look beyond their bigoted attitudes then perhaps we could correctly identify the problem and start talking about solutions. PS. Groovy offers potential answers here. I mention this, because perhaps groovy is a bit more palatable to Java folk, who knows :) Paul.
  31. If people could look beyond their bigoted attitudes then perhaps we could correctly identify the problem and start talking about solutions.
    Paul: I don't know about other folks but I don't really have anything against Ruby at all. In fact, I like RoR. As you've noted, most people at Sun agree too. In the meanwhile though, we really do need to work on Java EE given the sheer number of Java server-side developers out there. Will it change? I'm sure some day it will. Is it likely in the next five years or so? Probably not. I'd certainly love to learn a few RoR ideas that can be applied to Jave EE (and EJB specifically) as it stands today... Reza
  32. The original goals of EJB were very different. It was meant to be a component model. The idea was that you could by third-part EJB components off the shelf. In the same way that you could buy OLE components.


    Paul:

    With all due respect, I think you are talking about the idea behind JavaBeans, not EJB. Or if we stretch things around a bit, maybe that's true of EJB 1.x. EJB 2.x clearly is about declarative platform services built on a basic component model.

    While the components in the model and the services are evolving (such as adding DI), EJB is still essentially a server-side business-logic development platform.

    I'm still note sure all this semantic hair splitting actually matters to most developers...

    Reza


    I don't usually agree with Paul Beckford, but he is on the money about this one. EJB, *Enterprise* JavaBeans, was an attempt to do for the java enterprise what VB did for the Windows market, namely the creation of third-party components fit for server-side consumption

    The numerous reasons why this failed are, I think, very well understood by now.

    David,

    I agree with the failure of EJB as a component model, but I don't agree that the reasons are very well understood. If they were people would not be comparing Spring with EJBs. Spring and EJBs are two very different things. EJBs purposes is a lot closer to OSGi, yet OSGi has hardly had a mention here.

    On the contrary, I believe the issues aren't very well understood at all. And they stem from the Java language. If people could look beyond their bigoted attitudes then perhaps we could correctly identify the problem and start talking about solutions.

    PS. Groovy offers potential answers here. I mention this, because perhaps groovy is a bit more palatable to Java folk, who knows :)

    Paul.
    Well, the honeymoon's over. :-) I disagree. I think I understand the reasons. I thought that say, Rod Johnson did, and in fact, his reasons matched at least some of my experiences. I DON'T think the answer lies in dynamic languages, which is where I believe you are heading. The Dynamic vs. Static languages debate has been beaten to death. Lack of Java syntax or tight Java integration are not the reasons why I don't feel that DLs are inappropriate *for me*. I understand my current needs pretty well and DLs are not a solution that I find necessary or practical, *for me*. For others, knock yourselves out. ;-)

  33. Well, the honeymoon's over. :-)
    Yes. It shows.
    I disagree. I think I understand the reasons. I thought that say, Rod Johnson did, and in fact, his reasons matched at least some of my experiences.

    Well enlighten the rest of use, what are they?
    I DON'T think the answer lies in dynamic languages, which is where I believe you are heading. The Dynamic vs. Static languages debate has been beaten to death.
    Agreed. You could choose to use a DL as glue code between your components. I know that pico container supported this idea in the early days (before RoR). But OK I'm happy to drop this option if the idea hurts so :)
    Lack of Java syntax or tight Java integration are not the reasons why I don't feel that DLs are inappropriate *for me*.
    OK. You do see the language issues. Scala is an attempt at fixing some of them. I don't know enough about Scala to say ow well it lends itself to components though
    I understand my current needs pretty well and DLs are not a solution that I find necessary or practical, *for me*.

    For others, knock yourselves out. ;-)
    Good. Don't use a DL. How about OSGi or have you given up on components completely? Having read this thread I think that the people left using EJBs don't build components at all and don't need EJB. From the arguments raised it sounds as though they could get away with a Servlet and a DI framework like Guice or Spring. No one has mentioned the class loader issues, which implies that no one is re-packaging off the shelf components. Not surprising really since there isn't an EJB component market to speak of and it looks like there never will be. Which begs the question, why EJB? BTW. When I spell these things out on TSS it is not only for the likes of you. In the back of my mind is always the plight of the young twenty something programmer about to invest months of his life learning this stuff (just like I did back in the day). Beyond the hype are sound technical arguments, and some one has to lay out all the options so that he/she can make an informed choice. I'm just sorry it displeases you so :) Paul.
  34. Guys: I hate to resort to definitions for things but here is a definition for EJB: "Enterprise Java Beans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications." This definition has remained unchanged pretty much throughout the evolution of EJB...kind of like the definition of a car. Hope this clarifies matters... Reza
  35. Guys:

    I hate to resort to definitions for things but here is a definition for EJB: "Enterprise Java Beans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications."

    This definition has remained unchanged pretty much throughout the evolution of EJB...kind of like the definition of a car.

    Hope this clarifies matters...

    Reza
    Right. No one is disputing that. And those modular components were to come from a thriving 3rd-party market that never materialized.
  36. And those modular components were to come from a thriving 3rd-party market that never materialized.
    Kind of depends on how much you want to read into it. I think the 3rd-party market bit was a side-effect that was blown out of proportion by the marketing folks. Nothing in the programming model really encourages third-party integration. If anything, it makes it pretty darn hard. If that's the point, it's a good one and one that I support in terms of an pluggability and extensibility SPI contract for EJB. Ironically, on one's asked for that either...
  37. We finally see some truth here.
    Whatever floats your boat, dude...
  38. The point is that you don't need to do anything else to a Java object other than add metadata to it to get the framework to get you declarative services and scoping. I'd call that a POJO. If you want to split hairs, knock yourself out!

    Reza
    OK. I got your point. Since you are no longer required to implement an (EJB) interface and instead you have annotations, you are POJO.
  39. OK. I got your point. Since you are no longer required to implement an (EJB) interface and instead you have annotations, you are POJO.
    George: Thank you. No one said you had to agree with me, though...but there is a point when arguments become a waste of everyone's time because no-one cares but the people arguing... Reza
  40. OK. I got your point. Since you are no longer required to implement an (EJB) interface and instead you have annotations, you are POJO.


    George:

    Thank you. No one said you had to agree with me, though...but there is a point when arguments become a waste of everyone's time because no-one cares but the people arguing...

    Reza
    No worries. I am preparing a presentation to the managers :-)
  41. Positif[ Go to top ]

    Or why not try to make spring a "Java EE" standard like seam is doing with "web beans" JSR? It would be very interesting if the guys who thump "spring is the best" can list down the features which spring has now which has no equivalent in ejb. That would be very helpful for the spec leaders to collect much more valuable information.
    Well said! that was my point about being positif in the community. :) Best Regards Daoud AbdelMonem Faleh
  42. Re: Positif[ Go to top ]

    Or why not try to make spring a "Java EE" standard like seam is doing with "web beans" JSR?

    It would be very interesting if the guys who thump "spring is the best" can list down the features which spring has now which has no equivalent in ejb. That would be very helpful for the spec leaders to collect much more valuable information.


    Well said! that was my point about being positif in the community. :)

    Best Regards
    Daoud AbdelMonem Faleh
    Unfortunately, Rod would never do this. He's too interested in protecting his little fiefdom than doing anything truly beneficial to the EE community. Here's why I think this a bad move.
  43. Re: Positif[ Go to top ]

    Or why not try to make spring a "Java EE" standard like seam is doing with "web beans" JSR?

    It would be very interesting if the guys who thump "spring is the best" can list down the features which spring has now which has no equivalent in ejb. That would be very helpful for the spec leaders to collect much more valuable information.


    Well said! that was my point about being positif in the community. :)

    Best Regards
    Daoud AbdelMonem Faleh


    Unfortunately, Rod would never do this. He's too interested in protecting his little fiefdom than doing anything truly beneficial to the EE community. Here's why I think this a bad move.
    Bill, Your article was quite informative. So, is IoC is what we need to take from spring and standardize in ejb 3.1?

  44. Chester,
    Instead of creating an abstract session bean and extending it, couldn't you use default interceptors?
    That probably is another way doing this. I haven't thought of that. But both ways are not ideal, as it would be invoked when first used and invoked multiple times unnecessarily. Chester
  45. Spring with Annotations[ Go to top ]

    We ported 75% of project written in ejb to light weight programming using spring. We are planning to convert the remaining ejb project after 2 months.
    Is ejb still necessary in this day and age?



    Yes, I actually like EJB 3. In comparison, I would prefer not to use Spring, even though it is one of most popular framework. I like what spring can do and its concept. But I don't like to program in XML. Spring turns java programming into XML configuration (or programming depending how do you look at it), which turns me off. I have followed Spring from very beginning, even before the Spring becomes the spring, read Rod Johson's 1st book several times and incorporate the JDBC template into one of the project (before Spring becomes a project). Not so closely recently. I think Spring can use Annotation instead of XML now, but I rather use EJB 3 and JPA.

    Our old project is EJB 2.x and our new project is EJB 3 with JDK 1.6. I like it a lot. In case we need AOP, I just directly programming in AspectJ, which is pretty easy to do (except Intellij doesn't like it).

    There may still some short comings in EJB 3, but so far I can still tolerate them. I might change my positions, but this is my current state of the mind.

    Chester
    The current Spring Version supports Annotations and I believe there is a book that focuses on how to use Annotations to configure a Spring App instead of using a lot of XML. http://blog.interface21.com/main/2007/05/14/annotation-driven-dependency-injection-in-spring-21/ I have not used the latest EJB 3.0 Spec and therefore can't really bash it but I have been working with Spring for a while and enjoy using it way more then I enjoy doing the old EJB 2.1 using heavy tools like WSAD and Websphere at my old company. You say you like working with JPA and again the latest Spring version allows you to make working with JPA even better. http://dev2dev.bea.com/pub/a/2006/03/jpa-spring-medrec.html Hope that helps Chester. -Andrew P.S. I do not work for SpringSource. :-)
  46. Sounds nice! EJBs in the servlet container are my personal favourite! Holger
  47. I think that the whole “container” emphasis is very damaging to the brains of many many developers. With all the talk about “Servlet” container “EJB” container we forget that upon close examination we actually need “connectors”. I mean that decent applications usually needs more layers and scopes than it is defined by J2EE spec. My colleagues are shocked when I say that objects in our application need to live in scopes other than request and session - they simply do not get it. I think that at large we should start to talk more and emphasize more the generic containers like OSGI and lessen emphasis on the Servlet cartridge and Persistence cartridge. No doubts they are important and complex beasts - but they are NOT goals - they are means. Unfortunate emphasis on the Servlet vs EJB container and such shifts collective focus from seeking solutions to the ‘business’ problems to the seeking solutions for the problems of ‘means’.
  48. Can they learn from Spring and Guice, nope! That is what committees do, they make things complicated Still complicated and weird, and couldn't they allow EJBs to run in a servlet container many years ago, but no, no, they had to make it very complicated, you need a container, you need special deployment descriptors for different types of containers, you need to implement interfaces, even now, DI in ejb crippled! Just call it the POJO spec from your friends at SUN and their friends, the JCP memebers, get rid of the container all-together, drop backward compatibility, call it a day. I think this will happen when EJB 7.1 comes out.
  49. EJB 3.1: the answer to the question nobody asked.
  50. EJB 3.1: the answer to the question nobody asked.
    Seriously, the most funniest thing I've heard all day !!! ROTFLMAO !!! p.s: Go Grails!!!
  51. KISS[ Go to top ]

    Adding @Singleton (good), but loading it up with transactions, a giant instance lock, and who knows what else by default (bad). Why not keep @Singletons simple by default like Spring or Guice or basically anybody else?
  52. Re: KISS[ Go to top ]

    Adding @Singleton (good), but loading it up with transactions, a giant instance lock, and who knows what else by default (bad). Why not keep @Singletons simple by default like Spring or Guice or basically anybody else?
    In theory I agree with you that things should be left simple. But considering almost every EJB application I have seen has transactional EJB's it might make sense to have the Singleton EJB be transactional by default.
  53. Re: KISS[ Go to top ]

    In theory I agree with you that things should be left simple. But considering almost every EJB application I have seen has transactional EJB's it might make sense to have the Singleton EJB be transactional by default.
    Then EJB remains a heavyweight, specialized use and Spring or Guice replace JavaEE as a general framework. @Stateful and @Stateless are heavyweight by design, and all the documentation and tutorials encourage heavyweight use. So, of course, they're mainly used only in heavyweight situations. If you have a lightweight use, you use Spring instead.
  54. Re: KISS[ Go to top ]

    encourage heavyweight use
    Heavyweight is an abstract term. Can you describe what heavyweight specifically means to you.
  55. Re: KISS[ Go to top ]

    Heavyweight is an abstract term. Can you describe what heavyweight specifically means to you.
    lightweight = as light as possible, i.e. pure java call with no interception at all. You can add heavier operations as necessary, but the defaults should be light. If EJB makes singletons with zero overhead, they can be used everywhere, without worrying about the cost, because they have no additional cost. It would be awesome. If you do want transactions on your class, it's trivial to add a @TransactionAttribute on the class, which also serves as documentation for the class behavior. I don't see any value at all to enabling transactions and concurrency by default on a @Singleton, and see several disadvantages.
  56. Re: KISS[ Go to top ]

    I don't see any value at all to enabling transactions and concurrency by default on a @Singleton, and see several disadvantages.
    I think the expert group is still trying to decide weather or not to make singleton Beans transactional by default. You should send the EJB3 JCP an email with your comments on the subject. I have heard the group is very open to suggestions. I personally find Spring and EJB3 "heavy" to some extent, just in different ways.
  57. Re: KISS[ Go to top ]

    I don't see any value at all to enabling transactions and concurrency by default on a @Singleton, and see several disadvantages.


    I think the expert group is still trying to decide weather or not to make singleton Beans transactional by default. You should send the EJB3 JCP an email with your comments on the subject. I have heard the group is very open to suggestions.

    I personally find Spring and EJB3 "heavy" to some extent, just in different ways.
    They are very open to suggestions... It would be cool if Reza, et al. could post links to their blogs. TSS isn't the best place in the world to get feedback on new features for EJB because of the Spring disruptions.
  58. Re: KISS[ Go to top ]

    I don't see any value at all to enabling transactions and concurrency by default on a @Singleton, and see several disadvantages.


    I think the expert group is still trying to decide weather or not to make singleton Beans transactional by default. You should send the EJB3 JCP an email with your comments on the subject. I have heard the group is very open to suggestions.

    I personally find Spring and EJB3 "heavy" to some extent, just in different ways.


    They are very open to suggestions...

    It would be cool if Reza, et al. could post links to their blogs. TSS isn't the best place in the world to get feedback on new features for EJB because of the Spring disruptions.
    Bill: I don't see it as a disruption as such. The constructive comments are worth it, right? Given EJB's past, I think a little hostility is understandable. I think in a way it is a good thing. It might "keep it real" for us on the committee... Reza
  59. Re: KISS[ Go to top ]

    I don't see any value at all to enabling transactions and concurrency by default on a @Singleton, and see several disadvantages.


    I think the expert group is still trying to decide weather or not to make singleton Beans transactional by default. You should send the EJB3 JCP an email with your comments on the subject. I have heard the group is very open to suggestions.

    I personally find Spring and EJB3 "heavy" to some extent, just in different ways.
    Matt, It's not that big a deal. A lot of them are watching this thread, so it is OK to post comments here. Reza
  60. Re: KISS[ Go to top ]

    encourage heavyweight use


    Heavyweight is an abstract term. Can you describe what heavyweight specifically means to you.
    Whatever requires more than the necessary to accomplish a certain job (assuming that some job is even accomplished, but should not be taken for granted). Guido
  61. Whata about criteria API[ Go to top ]

    I thought there was suppose to be some sort of query criteria API?
  62. Re: Whata about criteria API[ Go to top ]

    I thought there was suppose to be some sort of query criteria API?
    That's a separate spec (JPA 2.0) and expert group.
  63. Re: Whata about criteria API[ Go to top ]

    That is being addressed by the JPA 2.0 spec.
  64. I don't believe that EJB has a future, if they keep the name EJB. See also Spring Overtakes EJB as a Skills Requirement.
  65. I don't believe that EJB has a future, if they keep the name EJB.

    See also Spring Overtakes EJB as a Skills Requirement.
    Heh...OK, let me get this straight. The president of the company that produces and sells the proprietary Spring product publishes an article on his blog that talks up his product and talks down his competition. Pure marketing....
  66. Randy
    Heh...OK, let me get this straight. The president of the company that produces and sells the proprietary Spring product publishes an article on his blog that talks up his product and talks down his competition. Pure marketing....
    Ok, I'll bite :-) My blog was published on the SpringSource web site. I've never made any secret of my affiliation. I believe that you work for a large application server vendor (IBM), which still promotes the use of EJB. While I am not suggesting you make any secret of that, I suspect most readers of this thread were unaware of it, and it would have been wise to make your own affiliation clear before casting aspersions on others. Second, wrt to my alleged vested interest; I was a long-term critic of EJB before Spring or SpringSource existed. It is a matter of public record that I have been extremely consistent on my views on this matter, regardless of my affiliation at any time. Second, wrt "proprietary Spring product." Spring is Apache License open source. That is about the most liberal license available. It is simply misleading to call an open source product a "proprietary product." In any case, since you work for a company that produces countless proprietary products, this is clearly a cheap shot. As for "company that produces and sells the proprietary Spring product", again this is pure FUD: Spring is free to use. We do not sell Spring. Third, with respect to "pure marketing": my post extensively quoted factual information which you and anyone else can verify. Your post merely insulted me without citing any information whatever. Rgds Rod CEO, SpringSource Founder, Spring Framework
  67. Randy

    Heh...OK, let me get this straight. The president of the company that produces and sells the proprietary Spring product publishes an article on his blog that talks up his product and talks down his competition. Pure marketing....

    Ok, I'll bite :-)

    My blog was published on the SpringSource web site. I've never made any secret of my affiliation. I believe that you work for a large application server vendor (IBM), which still promotes the use of EJB. While I am not suggesting you make any secret of that, I suspect most readers of this thread were unaware of it, and it would have been wise to make your own affiliation clear before casting aspersions on others.

    Second, wrt to my alleged vested interest; I was a long-term critic of EJB before Spring or SpringSource existed. It is a matter of public record that I have been extremely consistent on my views on this matter, regardless of my affiliation at any time.

    Second, wrt "proprietary Spring product." Spring is Apache License open source. That is about the most liberal license available. It is simply misleading to call an open source product a "proprietary product." In any case, since you work for a company that produces countless proprietary products, this is clearly a cheap shot. As for "company that produces and sells the proprietary Spring product", again this is pure FUD: Spring is free to use. We do not sell Spring.

    Third, with respect to "pure marketing": my post extensively quoted factual information which you and anyone else can verify. Your post merely insulted me without citing any information whatever.

    Rgds
    Rod
    CEO, SpringSource
    Founder, Spring Framework
    Randy gave a valid opinion. Far from a cheap shot. The thing is, Spring, although open source, *is* proprietary as it isn't standardized and is controlled by one vendor. Spring is a commercial product no matter how you try to spin it. Not that there is anything wrong with being commercial, open-source, and proprietary, but really Rod, this spin has become tiresome over the years. I'm glad people are *finally* calling you on it and realizing that SpringSource is a commercial vendor trying to make a buck just like the rest of us. -- Bill Burke JBoss, a division of Red hat http://bill.burkecentral.com
  68. The thing is, Spring, although open source, *is* proprietary as it isn't standardized and is controlled by one vendor.
    I think "proprietary" is the wrong word here. I would call it de facto standard. Just like hibernate is also a de fatco standard and is not proprietary.
  69. The thing is, Spring, although open source, *is* proprietary as it isn't standardized and is controlled by one vendor.
    I think "proprietary" is the wrong word here. I would call it de facto standard. Just like hibernate is also a de fatco standard and is not proprietary.
    IBM does not have exclusive control over branded distributions of EJB. Hence, their EJB implementation is not proprietary. On the other hand, AFAIK, SpringSource has exclusive control over the branded Spring distribution. This is the very definition of "proprietary". If I'm wrong and SpringSource does not own the Spring trademark, then SpringSource is pretty fucked as a business. I think CDN's Elba and Oracle's Unbreakable have shown how truly useless source code is in a business sense... As far as de facto, a de facto what? A de facto EJB? I think Rod's blog pretty much proves it is far from being a de facto anything based on EJB job numbers being pretty much even with Springs. Not that I really care... -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  70. Not that I really care...
    You're right, it's time for the weekend...
  71. The thing is, Spring, although open source, *is* proprietary as it isn't standardized and is controlled by one vendor. Spring is a commercial product no matter how you try to spin it. Not that there is anything wrong with being commercial, open-source, and proprietary, but really Rod, this spin has become tiresome over the years. I'm glad people are *finally* calling you on it and realizing that SpringSource is a commercial vendor trying to make a buck just like the rest of us.
    Bill: Could not agree more. Like yourself, the increasing tolerance towards a particularly dangerous form of creeping vendor lock-in is what worries me most about Java EE bashing, and I can speak as someone who has nothing to do with any products or frameworks, commercial, open source or otherwise. Reza
  72. I believe that you work for a large application server vendor (IBM), which still promotes the use of EJB.
    Hey Randy, are you responsible for my daily Webspshere pleasure???
  73. Randy

    Heh...OK, let me get this straight. The president of the company that produces and sells the proprietary Spring product publishes an article on his blog that talks up his product and talks down his competition. Pure marketing....

    Ok, I'll bite :-)

    My blog was published on the SpringSource web site. I've never made any secret of my affiliation. I believe that you work for a large application server vendor (IBM), which still promotes the use of EJB. While I am not suggesting you make any secret of that, I suspect most readers of this thread were unaware of it, and it would have been wise to make your own affiliation clear before casting aspersions on others.

    Second, wrt to my alleged vested interest; I was a long-term critic of EJB before Spring or SpringSource existed. It is a matter of public record that I have been extremely consistent on my views on this matter, regardless of my affiliation at any time.

    Second, wrt "proprietary Spring product." Spring is Apache License open source. That is about the most liberal license available. It is simply misleading to call an open source product a "proprietary product." In any case, since you work for a company that produces countless proprietary products, this is clearly a cheap shot. As for "company that produces and sells the proprietary Spring product", again this is pure FUD: Spring is free to use. We do not sell Spring.

    Third, with respect to "pure marketing": my post extensively quoted factual information which you and anyone else can verify. Your post merely insulted me without citing any information whatever.

    Rgds
    Rod
    CEO, SpringSource
    Founder, Spring Framework
    Both of you are unnecessarily harsh and unfair in this thread, though I agree with the point in Rod’s original blog. I knew Randy is from IBM. He might just forgot to put the famous signature “Work for IBM but not speak for IBM”.
  74. Well obviously I kicked over a hornet's nest but looking over the ensuing dialog it hasn't been all bad. My post was specifically responding to the EJB-basher who'd cited Rod's blog entry as "evidence" that the EJB brand name was so damaged that it should be tossed. As Rod himself mentions, he's been an anti-advocate of EJB from the beginning, so using Rod's anti-EJB marketing piece as evidence of how the EJB brand name is worthless was, in my personal view, humorous and ludicrous. As always, I don't speak for my employer IBM. And actually when I wrote the posting I was responding more as a member of the EJB 3.1 expert group, not anything in relation to where I happen to work. On the points of proprietary, etc. I was using the definition "a single implementation whose API and behavior is controlled by a single vendor or entity." Bill and Reza subsequently made good posts that I completely agree with, so I don't have anything to add there. Randy
  75. On the points of proprietary, etc. I was using the definition "a single implementation whose API and behavior is controlled by a single vendor or entity." Bill and Reza subsequently made good posts that I completely agree with, so I don't have anything to add there.
    Randy: To be completely honest, I think the word "proprietary" is a little bit of a stretch in this particular context. While I understand what is meant, I think using less loaded terms might be best to avoid needless provocation. I agree the dialog was not all bad. I am breathing a sigh of relief that things didn't spin too far out of control into a completely unproductive mess... It's all great stuff we could take back to the group...the email comments from various folks have been great too... Reza
  76. While I understand what is meant, I think using less loaded terms might be best to avoid needless provocation.
    Fine, in the future I'll be careful to say "a single implementation whose API and behavior...." :-)
  77. Fine, in the future I'll be careful to say "a single implementation whose API and behavior...." :-)
    Please don't get me wrong...it's not like I don't lose my temper on this stuff and regret it later too... Just think we can all do a little better...
  78. My post was specifically responding to the EJB-basher who'd cited Rod's blog entry as "evidence" that the EJB brand name was so damaged that it should be tossed.
    I don't like you attitude, but at least you got my point...
  79. I don't like your attitude, but at least you got my point...
    Nothing personal, but I guess I was put off by the "Spring Overtakes EJB" title of your original posting, in a discussion that was ostensibly on how we could make EJB 3.1 better. FWIW... If we renamed it to "XYZ 3.1" instead, that would mean (at least for awhile) that it would not show up on skills requirements lists. :-) Peace, Randy
  80. Nothing personal, but I guess I was put off by the "Spring Overtakes EJB" title of your original posting, in a discussion that was ostensibly on how we could make EJB 3.1 better.
    Actually I didn't realize that title thing, it was just in the clipboard...
  81. FWIW... If we renamed it to "XYZ 3.1" instead, that would mean (at least for awhile) that it would not show up on skills requirements lists. :-)

    Peace,
    Randy
    You are absolutely right. JPA is not showing up on skills requirements lists very often yet. It is still mostly Hibernate in the lists.
  82. FWIW... If we renamed it to "XYZ 3.1" instead, that would mean (at least for awhile) that it would not show up on skills requirements lists. :-)

    Peace,
    Randy


    You are absolutely right. JPA is not showing up on skills requirements lists very often yet. It is still mostly Hibernate in the lists.
    In fact, Hibernate has been on the rise since the introduction of JPA. You wouldn't know if EJB will rise again if XYZ 3.1 is introduced, would you?
  83. Randy Frankly, it would seem wiser to consider the implications of the evidence than to try to shoot the messenger. Or do you think that the job trends don't matter? Note that IBM has previously engaged with Spring and SpringSource in various ways, so fortunately many of your colleagues don't seem to share your attitude. We share many users and customers with IBM, and I think they definitely expect a positive engagement from the two companies. Rgds Rod
  84. Promoting Spring[ Go to top ]

    Rod, I know this is a bit of topic, but why do you bother to continue playing the ejb vs Spring game? You are the front runner of one of the most popular (successful) frameworks in Javaland. You have already proven yourself and Spring. If I was in your position I would not bother writing baited articles about ejb vs spring job trends, etc... Why do you bother? ~Matt *** I personally have been moving more towards developing in Flex/Guice/JPA, but at my company I still support a 50/50 mix of EJB and Spring applications.
  85. ....Or do you think that the job trends don't matter?...
    Job trends ? Hmm, in my (very little) experience tons of developers simply jump on the next bandwagon. Following pseudo-technicians (see http://www.cs.wustl.edu/~schmidt/editorial-5.html for a description of who I'm talking about) guidelines built with googled buzzword put in a blender. Those who think a little different (see http://zeroc.com/newsletter/issue22.pdf editorial) are normally flamed because they have always said (since the beginning) that EJB 1-2 were totally crazy (don't know about 3, but I really don't care, I am tired and getting old) and SOAP is an unuseful (and stupid) step backward. IMHO. Guido
  86. I don't believe that EJB has a future, if they keep the name EJB.

    See also Spring Overtakes EJB as a Skills Requirement.

    Heh...OK, let me get this straight. The president of the company that produces and sells the proprietary Spring product publishes an article on his blog that talks up his product and talks down his competition. Pure marketing....
    Rod's blog actually surprised me. Given the way I21, Spring zealots, and TSS talk, I thought the numbers would have been *WAY* worse. I actually think his blog was a positive one for EJB. EJB usage remained constant in the graphs he provided over time, leading me to believe this was an upper bound. Spring has only matched it recently. On a related note, my EJB 3.0 book is also selling very well. About 1700 copies last quarter and its been out since May 2006. So, EJB's demise is greatly exaggerated it seems... -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  87. On a related note, my EJB 3.0 book is also selling very well. About 1700 copies last quarter and its been out since May 2006. So, EJB's demise is greatly exaggerated it seems...
    I'm happy to say we are seeing similar success with EJB 3 in Action despite many doubters.
  88. On a related note, my EJB 3.0 book is also selling very well. About 1700 copies last quarter and its been out since May 2006.

    So, EJB's demise is greatly exaggerated it seems...


    I'm happy to say we are seeing similar success with EJB 3 in Action despite many doubters.
    Amazon Java bestseller list BTW: Yesterday "Enterprise JavaBeans 3.0" was on position 40 something!? We should have more book reviews on TSS!!!
  89. Rod's blog actually surprised me. Given the way I21, Spring zealots, and TSS talk, I thought the numbers would have been *WAY* worse. I actually think his blog was a positive one for EJB.
    LOL. I was not surprised by numbers at all given that EJB was very much overused from day one (neearly every project uisng JEE used EJB in the early days). Given that EJB3 has been out for more than two years, how can it be positive for EJB?
  90. I don't believe that EJB has a future, if they keep the name EJB.

    See also Spring Overtakes EJB as a Skills Requirement.
    Hm, interesting. And are you sure that only a small minority of the Spring users are using EJB as a sideline? I'll not be to fast on that. In a lot of projects where I saw Spring used, it is just added to the software stack. However, that mastering an (excellent) configuration framework becomes a prime job requirement leaves me somewhat astonished. In about the same number of projects, everything is done with spring (would you actually consider it wise to use spring as a factory of good old DAOS??) creating massive XML repositories that are by no means easier to manage than good old EJB 2.1 configurations. Really, given EJB3, spring is obsolete as an end user framework. You might of course argue that EJB did nothing but copy a lot of concepts already in spring (and elsewhere) and you probably right. Still there is zero need to use two frameworks if one suffices. Entropy kills codebases faster than anything else.
  91. Really, given EJB3, spring is obsolete as an end user framework.
    [scratch head] Really? Where in EJB is IoC? Not just for persistance. Where is Remoting? Web Flow? Batch? Spring .Net? etc. Or do you just mean Spring FrameWork? To be honest, I have never used Spring with EJBs (1-3). But it has still been very valuable.
  92. be trendy, bash a standard[ Go to top ]

    Still complicated and weird .. JB 3.1: the answer to the question nobody asked .. I don't believe that EJB has a future, if they keep the name EJB.
    I'm really tired of the bashing that EJB and JSF are getting. If any normal framework is criticized without giving proper arguments and examples the critique is seen as unfounded and childish, and the criticizer gets flamed. If a standard is bashed with sweeping statements and without any kind of concrete arguments the only thing that happens is half a dozen others join in to bash some more, even though usually they haven't even used the technology in production. Ps. I use GWT and Spring, and have absolutely no vested interests in EJB or JSF. /Henri Karapuu
  93. Re: be trendy, bash a standard[ Go to top ]

    If a standard is bashed with sweeping statements and without any kind of concrete arguments the only thing that happens is half a dozen others join in to bash some more, even though usually they haven't even used the technology in production.
    I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic. EJB 1-2 were the most over-complicated and over-sold standards I've ever had the displeasure of working with. 3+ might be better but the reality is that it's like putting a sticker on Chinese toothpaste that says "now without antifreeze".
  94. Re: be trendy, bash a standard[ Go to top ]

    I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.
    Right. And that isn't mindless bashing. At all. Obviously. In any way....
  95. Re: be trendy, bash a standard[ Go to top ]

    I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.

    Right. And that isn't mindless bashing. At all. Obviously. In any way....
    No it's not. There's not one thing in that statement that says anything about whether EJB is good or bad. If you can't understand that or refuse to, you should consider that perhaps you are not thinking objectively. Passive aggressive sarcasm is a poor substitute for meaningful arguments.
  96. Re: be trendy, bash a standard[ Go to top ]

    I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.

    EJB 1-2 were the most over-complicated and over-sold standards I've ever had the displeasure of working with. 3+ might be better but the reality is that it's like putting a sticker on Chinese toothpaste that says "now without antifreeze".
    Your view is outdated. There were certainly complexity issues in EJB 1-2. However, EJB 3.0 and JPA have simplified things significantly. EJB 3.1 and JPA 2.0 moves that effort forward further. It will take a while for EJB to completely over come the perception scars it suffered from the complexities of the earlier releases of the specification. However, I have no doubt it will do so.
  97. Re: be trendy, bash a standard[ Go to top ]

    I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.

    EJB 1-2 were the most over-complicated and over-sold standards I've ever had the displeasure of working with. 3+ might be better but the reality is that it's like putting a sticker on Chinese toothpaste that says "now without antifreeze".


    Your view is outdated.

    There were certainly complexity issues in EJB 1-2.
    You say it's outdated to think that EJB 1-2 are complex but you agree with the assertion. Are you calling your own views outdated?
    However, EJB 3.0 and JPA have simplified things significantly. EJB 3.1 and JPA 2.0 moves that effort forward further.
    I didn't suggest anything to the contrary.
    It will take a while for EJB to completely over come the perception scars it suffered from the complexities of the earlier releases of the specification. However, I have no doubt it will do so.
    And this is where we disagree. I think it will not. That was my point. These are called opinions. There is no correct or wrong (or outdated) opinion.
  98. Re: be trendy, bash a standard[ Go to top ]

    I didn't bash it. I implied that no one cares about it. Of course that's an exaggeration IMO, improvements to the EJB spec now are just rearranging the deck chairs on the Titanic.

    EJB 1-2 were the most over-complicated and over-sold standards I've ever had the displeasure of working with. 3+ might be better but the reality is that it's like putting a sticker on Chinese toothpaste that says "now without antifreeze".


    Your view is outdated.

    There were certainly complexity issues in EJB 1-2. However, EJB 3.0 and JPA have simplified things significantly. EJB 3.1 and JPA 2.0 moves that effort forward further.

    It will take a while for EJB to completely over come the perception scars it suffered from the complexities of the earlier releases of the specification. However, I have no doubt it will do so.
    Thanks a lot for the encouraging words. We'll certainly try our best, whatever the odds...
  99. Re: be trendy, bash a standard[ Go to top ]

    I'm really tired of the bashing that EJB and JSF are getting.
    I think EJB could be much more successful, if they would change the name. Sorry, I think that's a valid point, not bashing.
  100. Re: be trendy, bash a standard[ Go to top ]

    Well said...
  101. This simply surreal, how can anybody defend EJBs, a technology that requires a specialized container to make it work! Why would you through so much trouble of configuring and maintaing this type of infrastructure. Spring has proved that it can be done without it. If EJB's to survive, there should be no need for a heavyweight container. Any servlet container should suffice.
  102. This simply surreal, how can anybody defend EJBs, a technology that requires a specialized container to make it work! Why would you through so much trouble of configuring and maintaing this type of infrastructure. Spring has proved that it can be done without it. If EJB's to survive, there should be no need for a heavyweight container. Any servlet container should suffice.
    That can easily be reworded as such: This is simply surreal, how can anybody defend Spring, a technology that requires a specialized container (Spring) to make it work! Why would you go through so much trouble of configuring and maintaining this type of infrastructure? Spring IS a container. Spring beans have to be configured. Just like EJB. EJB containers can work in Tomcat and unit tests (see OpenEJB). The dependency injection of EJBs isn't that great, and the interceptors don't have sophisticated pointcuts but that may change in 3.1. These day's you don't have to decide between spending big bucks on a commercial app servers or using Tomcat. There's JBoss, GlassFish, Geronimo, etc. EJB, JTA, JPA, JAX-WS, and the rest of Java EE come with these app servers and you can plug your program right in without needing a bunch of extra jar files and configuration. I don't understand what is so hard about that. It's so easy and powerful. And what are you guys talking about, EJB 3.0 is heavyweight? Can you please be more specific. It's based on POJOs like Spring, and uses a container bundled with the app server instead of requiring you add and configure an external container such as Spring.
  103. Re: Article: The New Features in EJB 3.1[ Go to top ]

    This simply surreal, how can anybody defend EJBs, a technology that requires a specialized container to make it work! Why would you through so much trouble of configuring and maintaing this type of infrastructure. Spring has proved that it can be done without it. If EJB's to survive, there should be no need for a heavyweight container. Any servlet container should suffice.


    That can easily be reworded as such:

    This is simply surreal, how can anybody defend Spring, a technology that requires a specialized container (Spring) to make it work! Why would you go through so much trouble of configuring and maintaining this type of infrastructure?

    Spring IS a container. Spring beans have to be configured. Just like EJB. EJB containers can work in Tomcat and unit tests (see OpenEJB). The dependency injection of EJBs isn't that great, and the interceptors don't have sophisticated pointcuts but that may change in 3.1.

    These day's you don't have to decide between spending big bucks on a commercial app servers or using Tomcat. There's JBoss, GlassFish, Geronimo, etc. EJB, JTA, JPA, JAX-WS, and the rest of Java EE come with these app servers and you can plug your program right in without needing a bunch of extra jar files and configuration. I don't understand what is so hard about that. It's so easy and powerful.

    And what are you guys talking about, EJB 3.0 is heavyweight? Can you please be more specific. It's based on POJOs like Spring, and uses a container bundled with the app server instead of requiring you add and configure an external container such as Spring.
    Well said...
  104. If EJB's to survive, there should be no need for a heavyweight container. Any servlet container should suffice.
    That's precisely what is being done in the OpenEJB, EasyBeans and Embedded JBoss solutions, not to mention the graviton towards a "lite" version of EJB (discussed in a later article).
  105. This simply surreal, how can anybody defend EJBs, a technology that requires a specialized container to make it work! Why would you through so much trouble of configuring and maintaing this type of infrastructure. Spring has proved that it can be done without it. If EJB's to survive, there should be no need for a heavyweight container. Any servlet container should suffice.
    Have you really tried EJB3.0? I used Spring for about 2 years and found it easier and more flexible compared to EJB2.1. However my main concern has been always its verbose configuration which really becomes a nightmare for large scale projects. Nowadays I'm using EJB3 and really found it more cleaner and easier framework for development compared to Spring. IMHO, JavaEE 5 did a good job in listening to the community and learning from open source (thanks to Spring and Hibernate).
  106. Have you really tried EJB3.0?
    I think his point is that with "J2EE" you need a container offering a large number of services the majority of which your average application doesn't use or need. He proposes a much simpler setup using servlet container, and indeed this is adequate for the many. There is no "one size fits all" however much the J2EE/EJB crowd want to purvey their environment as being fit for all. When EJB (4?) grasps this key fact (which it allegedly is going to do) and doesn't require all components/services in a downloadable product (unlike EJB3 which still does impose this) so developers can download and utilise just what they need ... then your beloved EJB will be fit for purpose for the majority.
  107. Have you really tried EJB3.0?

    I think his point is that with "J2EE" you need a container offering a large number of services the majority of which your average application doesn't use or need. He proposes a much simpler setup using servlet container, and indeed this is adequate for the many. There is no "one size fits all" however much the J2EE/EJB crowd want to purvey their environment as being fit for all.

    When EJB (4?) grasps this key fact (which it allegedly is going to do) and doesn't require all components/services in a downloadable product (unlike EJB3 which still does impose this) so developers can download and utilise just what they need ... then your beloved EJB will be fit for purpose for the majority.
    Raul: Actually, you can use EJB 3.0 today in a Servlet container. Check out OpenEJB, EasyBeans and JBoss embedded. In addition, we are working on a lite version of EJB 3.1 that is specifically geared for use in lightweight containers. I'll talk about this in a later article. Hope this clarifies things. Reza
  108. Have you really tried EJB3.0?

    I think his point is that with "J2EE" you need a container offering a large number of services the majority of which your average application doesn't use or need. He proposes a much simpler setup using servlet container, and indeed this is adequate for the many. There is no "one size fits all" however much the J2EE/EJB crowd want to purvey their environment as being fit for all.

    When EJB (4?) grasps this key fact (which it allegedly is going to do) and doesn't require all components/services in a downloadable product (unlike EJB3 which still does impose this) so developers can download and utilise just what they need ... then your beloved EJB will be fit for purpose for the majority.
    And my point is ease of use of EJB3 compared to Spring. If this ease of use requires downloading and installing a free, open source app server like JBoss, Glassfish, Geronimo, OpenEJB and... I don't mind doing so. BTW, as you might have heard, nowadays there are embed-able ejb containers that you can run inside your servlet container, if you wish so.
  109. "Your Help is Needed"[ Go to top ]

    What's wrong with the java community? The EC members are asking feedbacks. Make your voice heard and tell them what's wrong with EJB, tell the feature you need being it DI, Interception or aspects! Everyone those days seem to criticise EJB and the containers, can someone tell me what's a definition of a container? If Spring isn't a container what would it be? Lightweight VS Heavy? OpenEJB, EasyBeans, Embedded JBoss with tomcat. Plans (after users request) are to make Glassfish, JBoss modular so you "deactivate" (if that's the word) the unneeded feature. Folks who are deeming EJB to failure are dreaming, attacking the specs (lows) and EG members (leaders) make a good marketing and that's a reason that kept me away from being a Spring enthusiast (and I've used it for real world projects!). It's about ETHIC! I'll *may* change my mind about I21 or SpringSource (and their owners) when they'll change their attitude in the JEE community. One last question when did Spring adopted annotations and stop being an XMLish crap (what we all hated in struts)? in 2.5 after the EJB3 Big Bang (another marketing argument against EJB.. would you mind?). JEE folks! Please try to be POSITIF and stop TROLLING over and over misleading the beginners devs that take you for java gods! It's really sucking with those kind of arguing! PS: Best ever JEE framework? Drop ALL JEE!! signature A mad JEE Lover!
  110. Re: "Your Help is Needed"[ Go to top ]

    What's wrong with the java community? The EC members are asking feedbacks. Make your voice heard and tell them what's wrong with EJB, tell the feature you need being it DI, Interception or aspects!
    Everyone those days seem to criticise EJB and the containers, can someone tell me what's a definition of a container? If Spring isn't a container what would it be?
    Lightweight VS Heavy? OpenEJB, EasyBeans, Embedded JBoss with tomcat. Plans (after users request) are to make Glassfish, JBoss modular so you "deactivate" (if that's the word) the unneeded feature.
    Folks who are deeming EJB to failure are dreaming, attacking the specs (lows) and EG members (leaders) make a good marketing and that's a reason that kept me away from being a Spring enthusiast (and I've used it for real world projects!). It's about ETHIC! I'll *may* change my mind about I21 or SpringSource (and their owners) when they'll change their attitude in the JEE community.
    One last question when did Spring adopted annotations and stop being an XMLish crap (what we all hated in struts)? in 2.5 after the EJB3 Big Bang (another marketing argument against EJB.. would you mind?).

    JEE folks! Please try to be POSITIF and stop TROLLING over and over misleading the beginners devs that take you for java gods! It's really sucking with those kind of arguing!

    PS: Best ever JEE framework? Drop ALL JEE!!

    signature
    A mad JEE Lover!
    Daoud: Your sentiments are definitely appreciated. Honestly though, I think pretty much anyone in the EJB expert group expects a little hostility, whether deserved or not. We consider it a privilege to be given the opportunity to win people back. Talk about a great technology comeback story! Bad marketing had a lot to do with the problems with EJB 1.x and 2.x. This time we can really focus on the technology instead... Reza
  111. Re: "Your Help is Needed"[ Go to top ]

    What's wrong with the java community? The EC members are asking feedbacks. Make your voice heard and tell them what's wrong with EJB, tell the feature you need being it DI, Interception or aspects!
    Everyone those days seem to criticise EJB and the containers, can someone tell me what's a definition of a container? If Spring isn't a container what would it be?
    Lightweight VS Heavy? OpenEJB, EasyBeans, Embedded JBoss with tomcat. Plans (after users request) are to make Glassfish, JBoss modular so you "deactivate" (if that's the word) the unneeded feature.
    Folks who are deeming EJB to failure are dreaming, attacking the specs (lows) and EG members (leaders) make a good marketing and that's a reason that kept me away from being a Spring enthusiast (and I've used it for real world projects!). It's about ETHIC! I'll *may* change my mind about I21 or SpringSource (and their owners) when they'll change their attitude in the JEE community.
    One last question when did Spring adopted annotations and stop being an XMLish crap (what we all hated in struts)? in 2.5 after the EJB3 Big Bang (another marketing argument against EJB.. would you mind?).

    JEE folks! Please try to be POSITIF and stop TROLLING over and over misleading the beginners devs that take you for java gods! It's really sucking with those kind of arguing!

    PS: Best ever JEE framework? Drop ALL JEE!!

    signature
    A mad JEE Lover!


    Daoud:

    Your sentiments are definitely appreciated. Honestly though, I think pretty much anyone in the EJB expert group expects a little hostility, whether deserved or not. We consider it a privilege to be given the opportunity to win people back. Talk about a great technology comeback story!

    Bad marketing had a lot to do with the problems with EJB 1.x and 2.x. This time we can really focus on the technology instead...

    Reza
  112. Re: "Your Help is Needed"[ Go to top ]

    The bazaar is EJB cannot re-invent itself as “POJO”. EJB3.1 or EJB4.0 has to be something else such as ABC or XYZ to be successful.
  113. Re: "Your Help is Needed"[ Go to top ]

    What is POJO? See http://www.martinfowler.com/bliki/POJO.html
  114. why waste time Rod[ Go to top ]

    ejb has some value but its diminished in last few years . spring has definitely taken a big share of the ejb market. ejbs are very complex to develop and maintain. its a bitter truth about ejbs although its still robust from XA etc. The worst part of this thread is people like bill and rod locking horns on some silly argument. most of the threads on TSS are filled with emotions, frustrations, egoistic comments and some irritating(this thread may be it :) ). Rod - spring is awesome ! Dont waste time responding to folks who could never achieve the success you have. they just want to take their frustration out on someone smart like you. just read the headlines on tss and leave it at that. dont read the threads unless you are the author of the article :-).
  115. Re: why waste time Rod[ Go to top ]

    Dont waste time responding to folks who could never achieve the success you have.
    they just want to take their frustration out on someone smart like you. just read the headlines on tss and leave it at that. dont read the threads unless you are the author of the article :-).
    Frankly, you could use some of your own advice about not polluting a potentially valuable discussion forum with supercilious rants. Rod and Bill have both contributed quite a bit for all of us and are worthy of at least basic courtesy.
  116. agenda[ Go to top ]

    These guys from JBoss really like to spread FUD. If Spring is not open source project, then I don't know which one is. Calling it not based on standard API would be ok, but saying its proprietary, wow dude. That even beats the old timer when some JBoss guys went to AspectJ training and claimed later how they invented AOP or something.
  117. Re: agenda[ Go to top ]

    These guys from JBoss really like to spread FUD.

    If Spring is not open source project, then I don't know which one is. Calling it not based on standard API would be ok, but saying its proprietary, wow dude.

    That even beats the old timer when some JBoss guys went to AspectJ training and claimed later how they invented AOP or something.
    Afu: I think we should all be holding ourselves to a higher standard of discussion here. Mutual respect never hurts. Bill's comments were albeit needlessly harsh, but not completely off-base. Here is a definition for the word "proprietary":
    The word "proprietary" indicates that a party exercises control over an item, usually to the exclusion of other parties.
    . In other words, "proprietary" != "closed source". I think it is a perfectly valid observation to say that the Spring framework is currently controlled by a very small group of people with vested financial interests and things are likely to stay that way in the foreseeable future. Have you ever tried to fork a non-trivial open source project? It is more or less an impractical proposition. Things have gone so far as to implicitly express this control in terms of the very name of a commercial organization. I am glad you've at least observed that open source != standard. I think that much is obvious. Reza
  118. Dead parrot[ Go to top ]

    Everytime I hear EJB I think of Monty Pythons "Dead Parrot sketch". We decided to use EJB3 on my current project, two months on, we spent a week refactoring it out, only leaving JPA (which is a subset of Hibernate really) in the mix. EJB3 was a massive step forward compared to previous incarnations, but it is still weighed down by too much past bagage which creates coding and deployment complexities. That all renders EJB somewhere in between "useless" and "pointless". Personally, beyond the Servlet spec, there are really only two parts of the JEE spec worth their salt: JPA and JMS, and any three of those can be used individually or altogether without the pain of a full JEE server. So to summarize EJB: "'E's not pinin'! 'E's passed on! This parrot is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies!"
  119. Re: Dead parrot[ Go to top ]

    EJB3 was a massive step forward compared to previous incarnations, but it is still weighed down by too much past bagage which creates coding and deployment complexities.
    Your experience honestly seems strange. What container were you using? What time-frame? Was it a beta or Java EE 5 certified?
  120. Re: Dead parrot[ Go to top ]



    Your experience honestly seems strange. What container were you using? What time-frame? Was it a beta or Java EE 5 certified?
    JBoss 4.0.5 patched for EJB3 (we used stateless session beans and JPA). We used it from November up until around last week. EJB3 pulls a lot of trick on you (some JBoss related): - Having to manage deployment into EJB container AND servlet container - adds a great deal of configuration and deployment complexity. - Characteristic of two containers: having to bend over backwards to share objects and dependencies without throwing in the kitchen sink. - The EJB container more or less swallowing and obfuscating issues, so it is hard to know whether it is deployment, configuration or code that is the problem (no doubt a JBoss issue). ..the list goes on. The fact is, as long as you need to deploy EJB's in a separate container even for the simplest of use cases to access the services it will always be a pain and add more headaches than it solves.
  121. Re: Dead parrot[ Go to top ]



    Your experience honestly seems strange. What container were you using? What time-frame? Was it a beta or Java EE 5 certified?

    JBoss 4.0.5 patched for EJB3 (we used stateless session beans and JPA). We used it from November up until around last week.

    EJB3 pulls a lot of trick on you (some JBoss related):
    - Having to manage deployment into EJB container AND servlet container - adds a great deal of configuration and deployment complexity.
    - Characteristic of two containers: having to bend over backwards to share objects and dependencies without throwing in the kitchen sink.
    - The EJB container more or less swallowing and obfuscating issues, so it is hard to know whether it is deployment, configuration or code that is the problem (no doubt a JBoss issue).
    ..the list goes on.

    The fact is, as long as you need to deploy EJB's in a separate container even for the simplest of use cases to access the services it will always be a pain and add more headaches than it solves.
    This is why I keep saying the whole effort of EJB is a waste of time at this point. 3.1 or whatever comes after it. On the surface the embeddable EJB container like a good solution but in real life it will still require a lot of configurations and tinkering. What is worse form a marketing perspective is the EJB LIGHT solution which Reza is talking about. It almost sounds like Vista Ultimate and Vista Enterprise!
  122. I would aprechiate if any container was embeddable, especially for automated testing it's very useful and during deployment it shortens deployment cycle a lot.
  123. I would aprechiate if any container was embeddable, especially for automated testing it's very useful and during deployment it shortens deployment cycle a lot.
    Peter: Give OpenEJB, EasyBeans and Embedded JBoss a spin. A lot of folks really like these solutions. Reza
  124. I would aprechiate if any container was embeddable, especially for automated testing it's very useful and during deployment it shortens deployment cycle a lot.
    JBoss has an embedded EJB3 container which we used on my project for unit-testing. Unfortunately, it was pretty much useless: hard to configure (harder than a standalone container), swallowed Exceptions completely, and wasn't particularly friendly to integrate into a maven build.
  125. I would aprechiate if any container was embeddable, especially for automated testing it's very useful and during deployment it shortens deployment cycle a lot.


    JBoss has an embedded EJB3 container which we used on my project for unit-testing. Unfortunately, it was pretty much useless: hard to configure (harder than a standalone container), swallowed Exceptions completely, and wasn't particularly friendly to integrate into a maven build.
    Was it the old Embeddable EJB3 container? Or the newer Embeddable JBoss one? Please email me your problems. I'm sure you can find my address... Bill


  126. JBoss has an embedded EJB3 container which we used on my project for unit-testing. Unfortunately, it was pretty much useless: hard to configure (harder than a standalone container), swallowed Exceptions completely, and wasn't particularly friendly to integrate into a maven build.


    Was it the old Embeddable EJB3 container? Or the newer Embeddable JBoss one? Please email me your problems. I'm sure you can find my address...

    Bill It was embedded Jboss as found here: http://wiki.jboss.org/wiki/Wiki.jsp?page=EmbeddedJBoss The problems where primarily three-fold: - Configuration and documentation: I could not much documentation, but eventually got it running semi-smoothly by copy-pasting the the conf, log, deploy directories from some sample embedded apps I found. I realize that configuring embedded JBoss is very close to configuring full JBoss, but nonetheless some clearer documentation and smoother running out of the box would be nice. - Classpath issues when integrating into Maven: worked fine in Eclipse, but running embedded JBoss from a Maven2 script for normal unit-tests was a carwreck: EJB classes could not be found and a bunch of other issues that ended up being more of a pain to resolve than just work around. - Deployment issues got very obfuscated, for instance an Entity might be invalidly mapped or something along those lines, but from the trace it was not immediately apparent that this was the case. Better, more detailed error messages would be helpful. it's been a while now, so I don't remember more in detail than that: at the moment we just deploy WAR files into JBoss and use JPA (with Hibernate as the provider) for the persistence, with an Open Session In View pattern implemented with Wickets RequestCycle for the transaction management (which is actually quite a nice little setup). I think Embedded JBoss and embedded EJB servers are a wonderful idea, and potentially the thing that can save EJB from complete irrelevance (EJB3 has a lot of nice ideas, but is still dragged down by the bagage of history), but unfortunately, we were not too happy with what we got out of it at the time. Maybe I'll reevaluate my stance once things are more straightforward and robust.
  127. Configuration and documentation: I could not much documentation, but eventually got it running semi-smoothly by copy-pasting the the conf, log, deploy directories from some sample embedded apps I found. I realize that configuring embedded JBoss is very close to configuring full JBoss, but nonetheless some clearer documentation and smoother running out of the box would be nice.
    Apologies. I thought I made that clear in the doco, that goal was to have exact configuration steps as the app server. To be consistent with config between app server and embedded.
    Classpath issues when integrating into Maven: worked fine in Eclipse, but running embedded JBoss from a Maven2 script for normal unit-tests was a carwreck: EJB classes could not be found and a bunch of other issues that ended up being more of a pain to resolve than just work around.
    I found that Maven doesn't set java.class.path properly. Was this the problem?
    Deployment issues got very obfuscated, for instance an Entity might be invalidly mapped or something along those lines, but from the trace it was not immediately apparent that this was the case. Better, more detailed error messages would be helpful.
    Only excuse I have is the immaturity of the JBoss 5 kernel at the time. We're getting there, things just take time. The goal is to be able to morph JBoss to the environment you want to run it within. As we move things to the JBoss 5 architecture things *should* get smaller, faster, easier.
  128. Re: Dead parrot[ Go to top ]

    Moh:
    On the surface the embeddable EJB container like a good solution but in real life it will still require a lot of configurations and tinkering.
    Not quite. Give OpenEJB a try. One could argue it is easier to configure than Spring. The point in working towards EJB is that a lot of us have observed that it has a number of good fundamental ideas (as someone already alluded, some of these ideas have been adopted by Spring). Not to mention many EJB 3 customers will attest to the fact that it does make server-side component development due to heavy defaulting, minimal configuration and annotations adoption. Reza
  129. Re: Dead parrot[ Go to top ]



    Not quite. Give OpenEJB a try. One could argue it is easier to configure than Spring.
    If that is really true, I'd be prepared to try it out. As I mentioned in another comment, we tried using Embedded JBoss for unit-testing, but it ended up almost being a bigger pain than the actual "real" JBoss server.
  130. Re: Dead parrot[ Go to top ]

    The fact is, as long as you need to deploy EJB's in a separate container even for the simplest of use cases
    to access the services it will always be a pain and add more headaches than it solves. Willie: Two comments here - 1. Try the code examples for EJB 3 in Action on JBoss. It was honestly a breeze to write and deploy apps. A number of our own customers who use JBoss AS can independently comment on this. 2. As mentioned in the article, one of the changes in EJB 3.1 is support for deploying directly to a Servlet container without a separate JAR (which is I'm guessing what you are referring to as "separate container"). FYI, OpenEJB will let you do this today. In fact, the OpenEJB folks were helpful in putting together this proposed change. Hope this helps, Reza
  131. Re: Dead parrot[ Go to top ]



    Your experience honestly seems strange. What container were you using? What time-frame? Was it a beta or Java EE 5 certified?

    JBoss 4.0.5 patched for EJB3 (we used stateless session beans and JPA). We used it from November up until around last week.

    EJB3 pulls a lot of trick on you (some JBoss related):
    - Having to manage deployment into EJB container AND servlet container - adds a great deal of configuration and deployment complexity.
    - Characteristic of two containers: having to bend over backwards to share objects and dependencies without throwing in the kitchen sink.
    - The EJB container more or less swallowing and obfuscating issues, so it is hard to know whether it is deployment, configuration or code that is the problem (no doubt a JBoss issue).
    ..the list goes on.

    The fact is, as long as you need to deploy EJB's in a separate container even for the simplest of use cases to access the services it will always be a pain and add more headaches than it solves.
    yeah, I hate to say it, but it is your JBoss EJB container (or should I say Sevrer? Another blog :). We would think that all companies would have certified JEE 5 available by now. It is a much more elegant model than J2EE 1.4. Annotations POJO's, Session Beans/ Message Driven beans / JPA Entities, and yes JSF/AFAX capabilities. If I would suggest, in a JBoss Environment, Jboss's Seam Framework addresses alot of these issues, and Dependency Injection (bi-directional), Jboss AOP, and it bridges the gap between Web application and EJB much smoother than anything I have seen so far. Funny, for each server in today's world, there is a default configuration that works best for it. Jboss Sevver has Jboss's Seam, Sun's Glassfish has Netbeans Visual Web projects, BEA's Studio (Based on Eclipse). Because the vendors have not implemented the full JEE standard, I feel less comfortable that I can port my application. or use the standard as a known base that will work on all App Servers. Hope that helps
  132. Keep up the good work![ Go to top ]

    I really like what's happening with the EJB spec. To me its clear that open source initiatives like Spring et cetera have had their impact as to where the standard is going - and that is a good thing. That's also quite normal when you think of the kind of relative 'greenfield' these initiatives start out with. Once successful, things are bound to be standardized and that is something we're seeing now (to some degree). POJO driven development is clearly one of the most important factors, along with the Java language maturing that will help getting a JEE platform which could have a bright future.
  133. Re: Keep up the good work![ Go to top ]

    POJO driven development is clearly one of the most important factors, along with the Java language maturing that will help getting a JEE platform which could have a bright future.
    We certainly hope so!
  134. I was curious about the recently launched certification program on Spring Framework Professional from SpringSource. I was flabbergasted to read the requirements one has satisfy to be able to take this exam. I quote this directly from their site:
    To become a certified Spring Framework Professional, you must successfully complete a certification exam. A person is eligible to take the certification exam if that person has recently attended the Four Day Core Spring course, is a significant contributor within the Spring community ...
    Rod Johnson, tell me. Do you think this is the only way one could gain Spring knowledge? Do you believe after that 4 days one can gain sufficient knowledge and experience to pass that exam? Is this really fair? Is Spring really going proprietary? Assume Sun imposes similar requirements for taking the Java programmer certification. Or IBM imposes such requirements for it's certification. The whole industry would jump on them and bash them. This is really not fair of SpringSource. It is a shame SpringSource is gradually turning into the dirty and greedy Microsoft we all saw exposed in the 90's. This is pure robbing. It's absurd. It's abuse of power. It's greediness to the power 100. I know some of you would say the guys have to generate some revenues to survive. I agree but there should be some other way. Sun is also giving Java away for free but doesn't impose such dirty and silly requirements for taking their certifications. If Spring is going to choose this way, lets all gradually abandon it, after all EJB has gotten amazingly better from 3.0. I'm starting to hate Spring!!! Jan
  135. I was curious about the recently launched certification program on Spring Framework Professional from SpringSource. I was flabbergasted to read the requirements one has satisfy to be able to take this exam. I quote this directly from their site:

    To become a certified Spring Framework Professional, you must successfully complete a certification exam. A person is eligible to take the certification exam if that person has recently attended the Four Day Core Spring course, is a significant contributor within the Spring community ...

    Rod Johnson, tell me. Do you think this is the only way one could gain Spring knowledge? Do you believe after that 4 days one can gain sufficient knowledge and experience to pass that exam?
    Is this really fair? Is Spring really going proprietary? Assume Sun imposes similar requirements for taking the Java programmer certification. Or IBM imposes such requirements for it's certification. The whole industry would jump on them and bash them.
    This is really not fair of SpringSource. It is a shame SpringSource is gradually turning into the dirty and greedy Microsoft we all saw exposed in the 90's. This is pure robbing. It's absurd. It's abuse of power. It's greediness to the power 100.
    I know some of you would say the guys have to generate some revenues to survive. I agree but there should be some other way. Sun is also giving Java away for free but doesn't impose such dirty and silly requirements for taking their certifications.
    If Spring is going to choose this way, lets all gradually abandon it, after all EJB has gotten amazingly better from 3.0.

    I'm starting to hate Spring!!!

    Jan
    Jan: While I agree with a lot of your observations, can I earnestly beg you to take this discussion to a Spring forum instead? I put a lot of hard work to try to put together this article (all my personal time since I work for a small/local Philly consulting company). It really hurts to see this get horribly derailed from its original intent and turn into a flame-fest instead of discussion about the article. Thanks, Reza
  136. Reza
    I put a lot of hard work to try to put together this article (all my personal time since I work for a small/local Philly consulting company). It really hurts to see this get horribly derailed from its original intent and turn into a flame-fest instead of discussion about the article.
    Yes, I know you did and I think you did a good job on the article. Such discussion around JSRs is healthy and I applaud you for initiating it. Rgds Rod
  137. <blockquoteYes, I know you did and I think you did a good job on the article. Such discussion around JSRs is healthy and I applaud you for initiating it.</blockquote> Rod: Thanks for the kind words. I'm trying to do my best (as is the rest of the expert group) to make EJB all that it could and should be. In fact, I would urge you to send your comments to the JSR if time permits. Although there is a lot of information out there, it is often outdated, full of hyperbole or comments on Java EE instead of EJB... Reza
  138. "While I agree with a lot of your observations, can I earnestly beg you to take this discussion to a Spring forum instead? I put a lot of hard work to try to put together this article (all my personal time since I work for a small/local Philly consulting company). It really hurts to see this get horribly derailed from its original intent and turn into a flame-fest instead of discussion about the article." Great point. It turned into a flame fest because Rod Johnson had to post his blog about how Spring is taking over EJB. He also generically says "EJB" rather than drawing the distinction between EJB 2.x and EBJ 3.0 (deliberately confusing people so that they still associate the complexity and heaviness of the 2.1 version with 3.0 version, which is in fact much easier and lighter). This kind of behavior from Rod Johnson indicates that he is worried that, if people take a serious look at EJB 3.0 and JPA, the need or desire from them to use Spring becomes much less. Spring became hugely popular because of the huge complexity and heaviness of EJB 2.x. But EJB 3.0 makes Spring not as desirable or relevant. Thus, in a forum that's simply about new EJB 3.1 features and soliciting feedback, Rod feels the need to post his standard "EJB sucks and Spring is the only way to go" stance, and shamelessly plug his own framework, and get people diverted away from a constructive discussion about improving EJB 3.x and get into a yet another useless "Spring vs JEE" flame fest. Based on this kind of behavior, I'm much less inclined to use Spring. But on a technical note, EJB 3.0 makes me less inclined to use Spring. EJB 3.0 is a fantastic spec, and is a huge improvement over 2.1. It fully embraces the POJO model, and makes wiring services simple via annotations, and greatly reduces XML configuration hell (a bane to the existence of every Java Enterprise developer, including Spring developers - heck especially Spring developers). As far as feedback - the ability to run regular session or message driven beans outside the container, so that they can be tested (or unit-tested) without firing up the big container, would be awesome. You can already do that with Entity beans (JPA). But to be able to do it with the others would be great.
  139. He also generically says "EJB" rather than drawing the distinction between EJB 2.x and EBJ 3.0 (deliberately confusing people so that they still associate the complexity and heaviness of the 2.1 version with 3.0 version, which is in fact much easier and lighter).
    So, wouldn't it be better to rename it?
  140. Jeff
    It turned into a flame fest because Rod Johnson had to post his blog about how Spring is taking over EJB.
    Please read the thread. I did not post that link. It was posted by someone without any connection to Spring. I merely posted in this thread to counter a specific attack. Rgds Rod
  141. Jeff
    It turned into a flame fest because Rod Johnson had to post his blog about how Spring is taking over EJB.

    Please read the thread. I did not post that link. It was posted by someone without any connection to Spring. I merely posted in this thread to counter a specific attack.

    Rgds
    Rod
    I did post that link and I have no connections to Spring.
  142. Re: Benz Town Citizen[ Go to top ]

    "I did post that link and I have no connections to Spring." I stand corrected and my apologies go to Rod Johnson. And I can't blame Rod Johnson for promoting Spring in his own blog, and saying it's taking over EJB in the job market. But I disagree with Rod's stance somewhat. What I think is happening is that people are increasingly leaving behind the old EJB 2.x model, and moving more towards POJO frameworks in general, including Spring, EJB3.0/JPA, Hibernate, iBatis, Toplink, and so on. Spring is certainly increasing in popularity, but EJB, thanks to 3.0 and JPA, still remains relevant (and desirable to use, I think). I also think that Spring benefited immensely from the extreme heaviness and complexity (and overselling) of EJB 2.x. Now that EJB 3.0 fully embraced a more lightweight POJO model, Spring desirability goes down somewhat (people don't have to escape the "complex beast" into the "Spring sanctuary" anymore). One things for sure, the existence of Spring sure shook up the Java enterprise world, and caused the committee to wake and smell the coffee, and come up with something better than the 2.x abomination. That is a very good thing indeed. That said, Benz Town Citizen, you should not have posted Rod's blog. It was not relevant to the thread. And I reacted to it because all the Spring vs EJB (whether 2.x or 3.0) grows very tiresome. And Spring supporters making proclamations stating that "JEE is dead and Spring has won" (or something along those lines) grows tiresome as well.
  143. Re: Benz Town Citizen[ Go to top ]

    Jeff
    I stand corrected and my apologies go to Rod Johnson.
    Thank you. I appreciate it. Rgds Rod
  144. Re: Benz Town Citizen[ Go to top ]

    That said, Benz Town Citizen, you should not have posted Rod's blog. It was not relevant to the thread.
    I respect your opinion and it seems like you're not the only one who thinks that way. But to me the post is relevant.
  145. "So, wouldn't it be better to rename it? " Yes. I think it should be renamed to something like "JEE POJO Beans", something else along those lines. There is a lot of negative baggage attached to the name "EJB" (and deservedly so).
  146. "So, wouldn't it be better to rename it? "

    Yes.

    I think it should be renamed to something like "JEE POJO Beans", something else along those lines. There is a lot of negative baggage attached to the name "EJB" (and deservedly so).
    No, no more POJO. Use EJO.
  147. "So, wouldn't it be better to rename it? "

    Yes.

    I think it should be renamed to something like "JEE POJO Beans", something else along those lines. There is a lot of negative baggage attached to the name "EJB" (and deservedly so).


    No, no more POJO. Use EJO.
    Or EEJO or XYZJO
  148. "So, wouldn't it be better to rename it? "

    Yes.

    I think it should be renamed to something like "JEE POJO Beans", something else along those lines. There is a lot of negative baggage attached to the name "EJB" (and deservedly so).
    Please get over it. EJB3 is fine with me.
  149. When is a POJO not a POJO?[ Go to top ]

    I worry that what we're calling a POJO isn't really a POJO. Your EJB 3.1 POJO littered with EJB 3.1 annotations isn't plain -- it depends on EJB annotations. This isn't that much different than extending an EJB base class or implementing an EJB interface. Your "plain" old Java object is coupled to the annotaitons, making it... not plain. Now maybe you can start compiling your "POJOs" with such annotations disabled. But suppose you want to now use your POJO in another annotation-driven environment. Do you go and add those annotations to your POJO? Your POJOs source now becomes littered with annotations from any framework you hope to use it in. I actually like it better than the annotations are external to the POJO (whether in XML descirptor, XML config file, or even purpose-built hard-coded decoration/wrapper classes).
  150. Re: When is a POJO not a POJO?[ Go to top ]

    I worry that what we're calling a POJO isn't really a POJO. Your EJB 3.1 POJO littered with EJB 3.1 annotations isn't plain -- it depends on EJB annotations. This isn't that much different than extending an EJB base class or implementing an EJB interface. Your "plain" old Java object is coupled to the annotaitons, making it... not plain.

    Now maybe you can start compiling your "POJOs" with such annotations disabled. But suppose you want to now use your POJO in another annotation-driven environment. Do you go and add those annotations to your POJO? Your POJOs source now becomes littered with annotations from any framework you hope to use it in.

    I actually like it better than the annotations are external to the POJO (whether in XML descirptor, XML config file, or even purpose-built hard-coded decoration/wrapper classes).
    FYI, it is perfectly OK to use 100% XML metadata using EJB 3.x if that's what you prefer... Reza
  151. Re: When is a POJO not a POJO?[ Go to top ]

    I couldn't recall for certain if that were the case, so thank you for confirming. Still, I stand by my suggestion that we not call POJOs with EJB 3.1 annotations POJOs, as they aren't plain. Using an XML descriptor alongside a POJO leaves the POJO itself plain, with no dependencies to classes, interfaces nor annotations. I'm not against EJB 3.1 annotations -- just against trying to say such a class is a POJO.
  152. Re: When is a POJO not a POJO?[ Go to top ]

    Using an XML descriptor alongside a POJO leaves the POJO itself plain, with no dependencies to classes, interfaces nor annotations.

    I'm not against EJB 3.1 annotations -- just against trying to say such a class is a POJO.
    Everything that you can describe with EJB-related annotations, you can also do via an XML descriptor...even in EJB 3.0 (don't have to wait for 3.1). You can choose to have all annotations, all XML, or a mix of anywhere between those two ends of the spectrum (in that case, attributes defined via XML override any matching annotations). So if you feel that adding annotations to a POJO makes it not a POJO, that's cool...then just use the XML form of descriptor alongside your POJO rather than annotations.
  153. First, I agree with Reza that this is not a thread about Spring. Please note that I only posted here to respond to an attack which I did not think should be left unanswered.
    Is Spring really going proprietary?
    No.
    Assume Sun imposes similar requirements for taking the Java programmer certification. Or IBM imposes such requirements for it's certification. The whole industry would jump on them and bash them. This is really not fair of SpringSource. It is a shame SpringSource is gradually turning into the dirty and greedy Microsoft we all saw exposed in the 90's. This is pure robbing. It's absurd. It's abuse of power. It's greediness to the power 100.
    Jan, this is a gross overreaction. Furthermore, you are of course free not to take the SpringSource Certification, in just the same way as you are free to continue to use Spring without paying anything--which is obviously not true with IBM or Microsoft. Requiring completion of a training course is not an unusual requirement. Consider, for example, BEA requirements for many certifications. Or Red Hat certification information. In fact, I believe it's rather unusual--and in the spirit of open source--for us to provide the "grandfathering" provision, which exempts candidates for the exam from completing a training course. Please read it. Why would you not take this up, if you feel you have made a sufficient contribution? Our goal is to provide a certification which provides a strong endorsement of the necessary skill level. We have seen a very positive reaction to our announcement in the Spring community. The discussion in this thread should be about EJB 3.1... I have no wish to hijack it. If people would stop making inaccurate statements about Spring and SpringSource, I would be very happy to bow out, unless I want to say something about EJB 3.1. Rgds Rod
  154. Requiring completion of a training course is not an unusual requirement. Consider, for example, BEA requirements for many certifications. Or Red Hat certification information.

    In fact, I believe it's rather unusual--and in the spirit of open source--for us to provide the "grandfathering" provision, which exempts candidates for the exam from completing a training course. Please read it. Why would you not take this up, if you feel you have made a sufficient contribution
    Rod
    Not that I really care. But you guys wrote books about your stuff, and now you are actually telling people reading the book(s) is not sufficient to take up the certification, but taking a four day training course is? At least the Sun people are decent enough to acknowledge that reading the spec and working through their how-tos is sufficient to gain the necessary knowledge to sit the test.
  155. My 2 cents.[ Go to top ]

    1. I think the singleton attribute should really be the default behavior for stateless session beans. In 90% of the cases, they should be considered as "Classes with static methods that use transactions". Sorry for over-simplifying, but thats the reality, :) An alternative would be to offer transaction attribute support for Servlets or any classes representing some kind of facade, :) 2. Pluggable injection support (for any kind of class) is a real plus. 3. (out of scope but heck, lets use the chance) Criteria API for JPA will be cool. 4. An out of the box generic DAO implementation for JPA will be nice. 5. Explicit support for entity instance based security is required (which user can update what entity) 5. Caching/Data refresh annotations for business logic methods (like in Spring).
  156. Give Credit Where It is Due[ Go to top ]

    All these flames are missing the point...and that is the progress that has been made in enterprise Java. It took Spring to really shake things up enough for those responsible for EJB to really gut the spec and come up with something new. I haven't really used EJB 3.0 yet (we run WebSphere here...), but it is an entirely different beast than the old EJB, in a good way. The spec has really leveraged annotations in Java 5 to the hilt and come up with something fairly lightweight and POJO-based. Criticizing the spec based on bad experiences with the older EJB is just wrong. Spring is a great framework (what the original EJB should have been), but it is also not without its faults. I'll echo (Crazy) Bob Lee's comments here that typing in Java class names into an XML file is a step backward. Hopefully the newer 2.5+ versions of Spring address some of these weaknesses. What I'd like to see...: 1) You shouldn't have to run in an application server to use EJB. One of the nice things about Spring is that it has always been environment-agnostic. (Is this the EJB "Lite" Reza was referring to?) 2) The multiple @ConcurrencyXXX annotations are a mistake, as is the suggestion to break up @TransactionAttribute. One annotation with multiple properties will suffice. Annotations are nice, but too many of them on a given element reduces readability.
  157. Re: Give Credit Where It is Due[ Go to top ]

    2) The multiple @ConcurrencyXXX annotations are a mistake, as is the suggestion to break up @TransactionAttribute. One annotation with multiple properties will suffice. Annotations are nice, but too many of them on a given element reduces readability.
    Well, I guess only one of the multiple transaction annotations would be used on a given element. However, I would have thought that breaking up @TransactionAttribute doesn't make sense as EJB 3.0 already defines it, and it doesn't make sense to chop and change in successive versions of the spec.
  158. Re: Give Credit Where It is Due[ Go to top ]

    However, I would have thought that breaking up @TransactionAttribute doesn't make sense as EJB 3.0 already defines it, and it doesn't make sense to chop and change in successive versions of the spec.
    I think there is enough emphasis on this for me to try to follow this up on the committee. This was my own gut reaction too... Reza
  159. Re: Give Credit Where It is Due[ Go to top ]

    1) You shouldn't have to run in an application server to use EJB. One of the nice things about Spring is that it has always been environment-agnostic. (Is this the EJB "Lite" Reza was referring to?)
    As to the discussion so far, yes...I'll try to get more details on it soon since there is so much interest on it... Reza
  160. Re: Give Credit Where It is Due[ Go to top ]

    makes wiring services simple via annotations, and greatly reduces XML configuration hell (a bane to the existence of every Java Enterprise developer, including Spring developers - heck especially Spring developers).
    I'll echo (Crazy) Bob Lee's comments here that typing in Java class names into an XML file is a step backward. Hopefully the newer 2.5+ versions of Spring address some of these weaknesses.
    Indeed, you really need to check out Spring 2.5! You'll be surprised. A Spring/EJB3 discussion based on Spring 2.0 (like in this thread) is effectively outdated. We go pretty far with our annotation-based support options in 2.5... certainly beyond what you would expect. You may for example use XML bean definitions that consist of nothing more than id/class pairs, with everything else expressed in annotations. Or you'll avoid XML bean definitions completely, autodetecting components in the classpath based on stereotype annotations. If you prefer to have it that way, your XML application context will merely define core resources, instructions on where to find components in the classpath, as well as some policies. Pretty similar to JPA's persistence.xml when using JPA entity detection in the classpath. For an overview, check out Rod's introduction to Spring 2.5 on TSS, in particular the section "Beyond XML" with its coverage of @Autowired and : http://www.theserverside.com/tt/articles/article.tss?l=IntrotoSpring25 For a comprehensive overview of Spring-supported dependency injection annotations, including common Java EE 5 annotations and Spring's JMX annotations, see my recent blog post: http://blog.springsource.com/main/2008/01/28/spring-25s-comprehensive-annotation-support/ Juergen
  161. RE: Juergen Hoeller[ Go to top ]

    "Indeed, you really need to check out Spring 2.5! You'll be surprised. A Spring/EJB3 discussion based on Spring 2.0 (like in this thread) is effectively outdated. We go pretty far with our annotation-based support options in 2.5... certainly beyond what you would expect." Good point. Just like confusing EJB 2.x with EJB3 is wrong, one should consider the new annotations feature in Spring 2.5, and not state the Spring is all XML hell. As far as I'm concerned, the less XML configuration, the better, and annotations present a very pleasant and viable alternative. Also, the less app server or container dependency (for testing purposes), the better. I will say this, however. EJB3 delivered us out of XML configuration hell before Spring did. So that's one feather in EJB's cap. ;-)
  162. Re: RE: Juergen Hoeller[ Go to top ]

    EJB3 delivered us out of XML configuration hell before Spring did. So that's one feather in EJB's cap. ;-)
    Juergen: Glad to hear this from you. Just because Spring and EJB 3 are competing technologies doesn't mean the people around both cannot have healthy respect for each other or say good things about competing technologies when it is warranted. Personally, I make a conscious effort to point out what's good about Spring, even if it doesn't favor EJB in every case...I think anything short of that is just a poor show :-). Reza
  163. Re: Give Credit Where It is Due[ Go to top ]

    Juergen, Sorry, wasn't trying to post on old versions. Annotations of course weren't around when Spring was written, so hard to fault the framework for not including them until recently. I am also not trying to posit annotations as being the end-all-be-all, either. Annotations lack the ability to be centralized at anything above the package level(witness the "classpath scanning" technique), so my gut feeling is that a hybrid approach using the best of both is probably the best approach. You, Rod, and the whole Spring crew deserve a ton of credit for really turning enterprise Java on its head. Yes, and competition is a healthy thing...
  164. Re: Give Credit Where It is Due[ Go to top ]

    Annotations of course weren't around when Spring was written, so hard to fault the framework for not including them until recently.
    Glad to see someone point this out. What Spring was doing with XML in 2003 was no different than what we've been doing in web.xml and ejb-jar.xml for years, or what countless app servers have been doing for their own configuration. There's no doubt that Spring XML is verbose, but I've seen far worse in Struts 1.x and Axis 1.x config files. I don't think anyone would say putting classnames in an XML file is a good idea, but it can't be called a "step backward" when nearly EVERYONE was doing this before annotations arrived. And to echo other posters - the competition between Spring/EJB3/Guice/etc. is good. We'd be worse off without it.
  165. Re: Give Credit Where It is Due[ Go to top ]

    It took Spring to really shake things up enough for those responsible for EJB to really gut the spec and come up with something new.
    This is precisely why I believe it is vital that Spring and EJB 3 continue to co-exist as competitors. Any mono-culture is bad for innovation and bad for customers. Somewhat perversely, this applies to the Java EE spec itself too. Non-standard solutions, whether commercial, not-for-profit, closed-source or open-source are all part of a healthy Java server-side ecosystem.
  166. Hi All, I wrote a blog entry about a six months ago saying that J2EE is dead long live J2EE. This discussion has just proven my words. What is EJB meant to be anayway? Initially it was a late-bound component model, but died under its own complexity. It is not the only static language component model to suffer this fate, CORBA and COM suffered the same fate too. I also hate to pop the bubble of the Spring lovers, but all Spring is is a DI framework. No different from Pico-Container, Hivemind and a bunch of other DI frameworks that came out at about the same time. Incidentally Guice looks as though it is a more powerful DI then Spring and it comes without the associated fanfare. I know that Spring Inc. as done a great job at marketing Spring as the answer to everything, but Spring is not a late-bound component model. So where does that leave J2EE? Well as a component model - dead, and as a bunch of services - mixed. As a bunch of services the Servlet API, JMS, JDBC and one or two others have been very successful as a earlier poster rightly pointed out. But as an application container J2EE is dead in the water. What are the alternatives? Well OSGi has been making some good noises for a while. It would be interesting to hear from some one using OSGi in a production environment. The simple truth is that Java does not have a component model. The reasons are based in the language. Objective-C and Ruby do. All you need to do is look at the Rails plug-ins to see that the EJB third party component dream as been realised elsewhere. Personally, I wouldn't touch either EJB3.x or Spring. There is something distasteful about Commercial Open Source Companies fighting over what use to be the J2EE App. Server market. If I needed late-binding in Java I would look to Guice and a bunch of j2EE services and role my own. If I wanted to re-use components written by others then the only option in Java appears to be OSGi. The interesting thing is that the need for Guice, OSGi etc goes away with a dynamic language, so if you are not a Java devotee then you can get real components (plug-ins) for free with Rails. Paul.
  167. RoR?[ Go to top ]

    I had an open mind when I started looking into Ruby/RoR a while ago, but got stopped dead by some fundamental flaws in both. 1. Green threading. All threads in Ruby are serviced by a single OS-level thread with a 10-ms time slice. The recommended approach on the Ruby wiki is forking new processes instead. 2. RoR is not thread-safe. Scalability is generally achieved by running multiple instances of Mongrel. 3. RoR does not support prepared statements. This means the DB has to recompile the SQL every time it runs. 4. Dynamic languages are generally more difficult to develop on a large scale because of the lack of refactoring/tooling support. Have to make a change that affects 100+ classes in Ruby? Hmm... Some may make arguments as to programmer productivity vs. refactoring, but the other arguments are show-stoppers. Ruby and RoR may eventually fix these problems, but until then I cannot see either as being suitable for an real enterprise development. So please refrain from declaring J2EE or Java dead until you can fix fundamental problems in your own house.
  168. Re: RoR?[ Go to top ]

    So please refrain from declaring J2EE or Java dead until you can fix fundamental problems in your own house.
    Own house? Java is my house, so is Ruby. I am a programmer and these are programming languages. I choose to program in both (and a few others actually). I take your point, that Ruby could do with better tool support. It would be nice to see Smalltalk like IDE support for Ruby sometime soon. But Ruby and Rails is a legitimate choice for many. Perhaps it's time to move beyond "the golden hammer" mentality, and perhaps then every problem won't look like a nail. Even Sun as seen the light so why can't you? Paul.
  169. Re: RoR?[ Go to top ]

    Actually, I kind of like Ruby as a language (at least on paper). There are some interesting things there to recommend it, and I genuinely hope that it moves beyond its current limitations (I think that Sun is wishing the same thing). But lack of good concurrency handling is simply a non-starter for a language in a multi-processor world, especially in web applications. Sorry, but that's true. OK, I'll stop here and let the conversation return to EJB...
  170. RE. Paul Beckford[ Go to top ]

    Ahh, the obligatory RoR plug. Some good points there about late bound components. However ... J2EE/JEE isn't dead, and won't die, so long as IBM, Oracle, BEA (via Oracle now), JBoss, Sun, SpringSource, et al, keep selling their wares. Java, by all surveys, is still the number one language in use today. And by far the biggest chunk of usage is on the server side - yes J2EE / JEE / Spring / Whatever framework. Current job skill search at Dice: Java: 16646 postings Ruby: 718 posting Kind of a big difference there, don't ya think?? And come back and post that RoR is the bomb and JEE is dead when RoR skills are actually in demand. Tell us how great RoR is when a fortune 500 adopts en masse, or when it's used for a large scale banking app, or something on the scale of Amazon.
  171. Re: RE. Paul Beckford[ Go to top ]

    Ahh, the obligatory RoR plug.

    Some good points there about late bound components.

    However ...

    J2EE/JEE isn't dead, and won't die, so long as IBM, Oracle, BEA (via Oracle now), JBoss, Sun, SpringSource, et al, keep selling their wares.

    Java, by all surveys, is still the number one language in use today. And by far the biggest chunk of usage is on the server side - yes J2EE / JEE / Spring / Whatever framework.

    Current job skill search at Dice:

    Java: 16646 postings
    Ruby: 718 posting

    Kind of a big difference there, don't ya think??

    And come back and post that RoR is the bomb and JEE is dead when RoR skills are actually in demand.

    Tell us how great RoR is when a fortune 500 adopts en masse, or when it's used for a large scale banking app, or something on the scale of Amazon.
    As far as marketing is concerned you are right, but I weren't talking about marketing I was talking about technology. As for all this Ruby knocking, it may of missed your attention, but Ruby is a Sun supported JVM language just like Java. If the Java community can get beyond tribalism, then perhaps then they will begin to look at the technical issues. The initial purpose of EJB is being addressed by Rails today, this is just a fact and no re-targeting of EJBs will change this... Paul.
  172. Re: RE. Paul Beckford[ Go to top ]

    Hi Paul, I wonder, if there is a community site like TSS for Ruby?
  173. Re: RE. Paul Beckford[ Go to top ]

    Hi Paul,

    I wonder, if there is a community site like TSS for Ruby?
    Good idea. Ruby programmers use C all the time. So I could mention languages other then Ruby without getting flamed :) You guys really need to grow up! Paul.
  174. Re: RE. Paul Beckford[ Go to top ]

    Hi Paul,

    I wonder, if there is a community site like TSS for Ruby?


    Good idea. Ruby programmers use C all the time. So I could mention languages other then Ruby without getting flamed :)

    You guys really need to grow up!

    Paul.
    I should add a "this is not bashing" note to all my posts. I really wonder if there is a Ruby community page like TSS. (this is not bashing)
  175. I also hate to pop the bubble of the Spring lovers, but all Spring is is a DI framework. No different from Pico-Container, Hivemind and a bunch of other DI frameworks that came out at about the same time. Incidentally Guice looks as though it is a more powerful DI then Spring and it comes without the associated fanfare. I know that Spring Inc. as done a great job at marketing Spring as the answer to everything, but Spring is not a late-bound component model.
    Stop the presses. Spring is a DI framework! Thanks for the history lesson. Just because you just came to that conclusion, doesn't mean the rest of us using the thing didn't realize this 4yrs ago. Sheesh.
  176. Enter Rails[ Go to top ]

    The interesting thing is that the need for Guice, OSGi etc goes away with a dynamic language, so if you are not a Java devotee then you can get real components (plug-ins) for free with Rails.

    Paul.
    Leave it to Paul to bring up Rails in an EJB3 thread.
  177. time to work together[ Go to top ]

    I thought Rod was part of ejb 3+ jcp's. Pity to see people talking abt Spring vs EJB [vs JBoss] even now.
  178. Re: time to work together[ Go to top ]

    I thought Rod was part of ejb 3+ jcp's. Pity to see people talking abt Spring vs EJB [vs JBoss] even now.
    I'm involved in Java EE 6 and SpringSource has reps on a number of expert groups (notably, JSF, Servlet, JMX, and JPA). We're also involved in standards efforts at OASIS and the OSGi Alliance. I'm not on the EJB 3.1 expert group and made it clear when I was invited onto the EE6 expert group that I'm an EJB skeptic.
  179. time for feedback to Sun[ Go to top ]

    I am an average developer who has been using SLSB for quite sometime. EJB3.1 will make my life a lot simpler. Though I like the power of Spring [exporters], many times I simply want to meet the client's demands for appserver. I understand you are skeptical. But help the JCP to bring a reasonable spec [and make ee6 a success].
  180. Re: time to work together[ Go to top ]

    I'm involved in Java EE 6 and SpringSource has reps on a number of expert groups (notably, JSF, Servlet, JMX, and JPA).
    Rod: Being on the Java EE 6 committee means that you could help solve some of the problems that cannot really be solved in the scope of a lower level spec like EJB 3.1: 1. Once and for all standardizing JNDI naming for all parts of Java EE. 2. Defining a much better dependency injection model for all parts of Java EE, including EJB, JSF, JPA and non-managed components. 3. Significantly simplifying packaging and deployment for Java EE applications. 4. Defining third-party pluggability+extensibility contracts for all parts of Java EE. What are your thoughts? All of these features have a direct impact on how simple EJB (and Java EE) development can be. Reza
  181. Re: time to work together[ Go to top ]

    Reza Good, constructive suggestions.
    Being on the Java EE 6 committee means that you could help solve some of the problems that cannot really be solved in the scope of a lower level spec like EJB 3.1: 1. Once and for all standardizing JNDI naming for all parts of Java EE.
    I would definitely favor this.
    2. Defining a much better dependency injection model for all parts of Java EE, including EJB, JSF, JPA and non-managed components.
    I've already tried and failed. I proposed a JSR for DI a few months ago, but it got bogged down in politics. I agree that what's there now is inadequate (and in the wrong place) and would like to help improve it.
    3. Significantly simplifying packaging and deployment for Java EE applications.
    I get the feeling that this is out of scope, but I would certainly favor it. I believe it's important that the Java EE group look at OSGi here--it's an existing and proven standard.
    4. Defining third-party pluggability+extensibility contracts for all parts of Java EE.
    I've brought up various issues. The Servlet API seems one of the most important areas here. I'm not sure there's a lot that needs to be done at EE level technically; it's more a question of ensuring that the extensibility goal is met, which I've done. Rgds Rod
  182. Re: time to work together[ Go to top ]

    it's more a question of ensuring that the extensibility goal is met, which I've done.
    ...which I've tried to do. Whether the goal is met isn't up to me.
  183. Re: time to work together[ Go to top ]

    Reza

    Good, constructive suggestions.
    Being on the Java EE 6 committee means that you could help solve some of the problems that cannot really be solved in the scope of a lower level spec like EJB 3.1:

    1. Once and for all standardizing JNDI naming for all parts of Java EE.

    I would definitely favor this.

    2. Defining a much better dependency injection model for all parts of Java EE, including EJB, JSF, JPA and non-managed components.

    I've already tried and failed. I proposed a JSR for DI a few months ago, but it got bogged down in politics. I agree that what's there now is inadequate (and in the wrong place) and would like to help improve it.

    3. Significantly simplifying packaging and deployment for Java EE applications.

    I get the feeling that this is out of scope, but I would certainly favor it. I believe it's important that the Java EE group look at OSGi here--it's an existing and proven standard.

    4. Defining third-party pluggability+extensibility contracts for all parts of Java EE.

    I've brought up various issues. The Servlet API seems one of the most important areas here. I'm not sure there's a lot that needs to be done at EE level technically; it's more a question of ensuring that the extensibility goal is met, which I've done.

    Rgds
    Rod
    That's a shame...let's hope things change sooner rather than later... Reza
  184. Re: Congratulations[ Go to top ]

    Reza, That was an impressive management effort on this thread, especially considering some disgraceful attempts to co-opt the debate...this post and article on EJB 3.1 will live-on, as will Rod's attempt to discredit a spec. via a blog entry that only re-iterates what Solomon Duskis did some months back with job figures... As I have said to the WebLogic apologists, job numbers are barely relevant point-in-time reflections of what is being reported for past technologies...the fact that Spring was considered a more healthily growing technology base than EJB 2.x is documented, but does not reflect the current state of EJB 3, with Glassfish, in particular.... More proponents will do well to study this thread to understand how to make a case for a particular technology, I am appreciative of your efforts, and frankly embarassed by Spring punters who continue to drum up the debate, even as Rod makes claims that are the opposite... Being a "critic", a "skeptic", and a participant on JEE6, though not willing to work for EJB 3.1 with Spring as a background, is 1 thing, to make a continued case 4 it on this thread does more to harm Javaness than u realize, and the analogy with Nati and Gigaspaces is a relevant, and desperate one.... apologies for a seeming flame, but this whole anti-EJB, anti-JEE, anti-app server thing on this forum has run its course...
  185. Re: Congratulations[ Go to top ]

    Reza,

    That was an impressive management effort on this thread, especially considering some disgraceful attempts to co-opt the debate...this post and article on EJB 3.1 will live-on, as will Rod's attempt to discredit a spec. via a blog entry that only re-iterates what Solomon Duskis did some months back with job figures...

    As I have said to the WebLogic apologists, job numbers are barely relevant point-in-time reflections of what is being reported for past technologies...the fact that Spring was considered a more healthily growing technology base than EJB 2.x is documented, but does not reflect the current state of EJB 3, with Glassfish, in particular....

    More proponents will do well to study this thread to understand how to make a case for a particular technology, I am appreciative of your efforts, and frankly embarassed by Spring punters who continue to drum up the debate, even as Rod makes claims that are the opposite...

    Being a "critic", a "skeptic", and a participant on JEE6, though not willing to work for EJB 3.1 with Spring as a background, is 1 thing, to make a continued case 4 it on this thread does more to harm Javaness than u realize, and the analogy with Nati and Gigaspaces is a relevant, and desperate one....

    apologies for a seeming flame, but this whole anti-EJB, anti-JEE, anti-app server thing on this forum has run its course...
    Doug: Thank you for the kind words. Honestly though, it's all good. This might seem a little ugly, but if you look at the biggeer picture, it's really a unique strength of Java we should all be pretty proud of. I think it shows the underlying strength and resilience of the platform. Seriuosly though, we could all stand to tone down the us/them mentality a little. It's great, but we seems to be reaching a point of diminishing returns far too often/far too fast than we really should... In the meanwhile, at least it's colorful, right? :) Cheers, Reza P.S.: Thanks to all who continue to send in comments. Obviuosly, I can't promise anything, but I'll tally them up and work with the spec lead and the rest of the group to try my best that you are heard!
  186. Apples VS Oranges[ Go to top ]

    In Wednesday morning green apples tastes sour than oranges does not really make any sense. Spring is neither designed nor intends to nor can replace EJB. If you are good developer can manage without of any. Again if you are a good developer can take advantage of using both. If you close yor eye towards one definitely can not see good / bad of either or the situations where it can be useful. Just a question how many really spent time in going through the specs of both, In an optimistic estimate less than 30%.... may be wrong dont know...But can say thow who work on JSRs are NOT idiots....
  187. As much as there are parts of Spring I don't like - Spring along with Hibernate drastically transformed the JEE landscape. Their core concepts are what is standard today regardless of which framework you use. The real question in my mind is should Spring fold under the umbrella of EJB-3 as Hibernate did - or should Spring continue to be rewarded for its contributions and allowed to maintain its independence (by the public picking Spring over EJB-3). The former can mean Spring gets lost in a sea of similar commodities - though I think Hibernate is holding its own - while the latter means a fracture in standards adoption. Personally, I think Spring can continue to innovate under the EJB-3 umbrella (and i don't just mean annotation support) and still continue to keep EJB-3 playing catch-up but garner an even wider audience because its standards compliant.
  188. EJB-3 playing catch-up
    With all due respect, this is a perception problem, not reality. There are genuine innovations in EJB 3 that Spring 2.5 has not yet caught up to, let alone the features being introduced in EJB 3.1... Reza
  189. With all due respect, this is a perception problem, not reality. There are genuine innovations in EJB 3 that Spring 2.5 has not yet caught up to
    Reza, With all due respect, such comments are usually followed by examples :) Mark SpringSource

  190. With all due respect, this is a perception problem, not reality. There are genuine innovations in EJB 3 that Spring 2.5 has not yet caught up to, let alone the features being introduced in EJB 3.1...

    Reza
    Huh? What innovations? Please enlighten us.

  191. With all due respect, this is a perception problem, not reality. There are genuine innovations in EJB 3 that Spring 2.5 has not yet caught up to, let alone the features being introduced in EJB 3.1...

    Reza


    Huh? What innovations? Please enlighten us.
    Already mentioned in the previous post: minimal configuration, full annotation support, maximum defaulting. Honestly, I think this is enough if one is to be respectful of my time. Many folks have spoken about this extensively and almost anyone can evaluate the merit of this on their own by picking up a good book on EJB 3 and comparing it to their current Spring application (or by looking through the latest Spring documentation). In any case, I'm preparing a presentation on EJB 3.0 (not EJB 3.1) and a Spring 2.5 comparison soon. This is an update from my Spring 2.0 comparison, which is already pretty widely available (as is the critique offered by SpringSource folks like Mark Fisher above). As another quick reference, here is Rod Coffin's excellent comparison of EJB 3.0 and Spring 2.0: http://www.devx.com/Java/Article/32314/0/page/1. Sorry this is the best in terms of a detailed example my personal time will allow right now. Reza
  192. I'm sorry Reza, but I honestly think you owe it to the people following this thread to take the time to back up your claims. Over the period of 6 days, you managed to find time to make dozens of posts here (and also here) - many of which suggest that Spring is "not caught up" with the "genuine innovations" of EJB3. Now that you have been asked on both threads to supply examples, you suddenly don't have the time. I personally spent a lot of time on my recent response to your "comparative analysis". I found the time to do that, because I frankly considered the presentation to grossly misrepresent the facts. My initial reaction was that it was intentionally biased, but I was willing to give you the benefit of the doubt when you said that you hadn't had time to update it to include Spring's annotation support. However, above you explicitly refer to Spring 2.5 and are making claims about the present, so I assume that you have now "caught up" on your own knowledge of Spring's latest features. Therefore, I hope that you can find just enough time to provide something more concrete to support this claim.

  193. With all due respect, this is a perception problem, not reality. There are genuine innovations in EJB 3 that Spring 2.5 has not yet caught up to, let alone the features being introduced in EJB 3.1...

    Reza


    Huh? What innovations? Please enlighten us.


    Already mentioned in the previous post: minimal configuration, full annotation support, maximum defaulting. Honestly, I think this is enough if one is to be respectful of my time. Many folks have spoken about this extensively and almost anyone can evaluate the merit of this on their own by picking up a good book on EJB 3 and comparing it to their current Spring application (or by looking through the latest Spring documentation).

    In any case, I'm preparing a presentation on EJB 3.0 (not EJB 3.1) and a Spring 2.5 comparison soon. This is an update from my Spring 2.0 comparison, which is already pretty widely available (as is the critique offered by SpringSource folks like Mark Fisher above). As another quick reference, here is Rod Coffin's excellent comparison of EJB 3.0 and Spring 2.0: http://www.devx.com/Java/Article/32314/0/page/1.

    Sorry this is the best in terms of a detailed example my personal time will allow right now.

    Reza
    Annotation support is hardly innovative and Spring got AT LEAST as quicky as EJB did. The EJB spec borrowed their most intersting approaches from the concepts popularized by Spring, Hibernate, and Xdoclet. EJBs are to innovation what MS is to...innovation.
  194. ReallyusefulNewFeatures.jee[ Go to top ]

    I make bold to say EJB/JEE is heading towards the bus stop MS left years back(yes you read that right). As a long time .Net/COM+ developer who had to migrate to J2EE because of the EJB hype, I find it funny that most developers on the J2EE platform can't just see that the current J2EE spec sucks!A test of the ease of use of any product/frameworks/whatever is the relative ease with which a new user can get an app up and running.The whole array of confusing specs,frameworks,APIs that one has to learn to implement the simplest functionality in J2EE is at best annoying.My current impression of a J2EE project now is it really gives you the feel of an academic exercise.What with over-engineered APIs and frameworks in the name of OOP purism, ardent refusal to implement complementary technologies from competitors(why were the JSR guys afraid of including the .Net style delegate in the specs when they picked on annotations?),proliferation of crappy specs and a mountain of frameworks/APIs/specs to learn just to get one single thing done. The good news for me is that SpringSource has finally caught the hint-I don't have to know the raw details before I use it- and hopefully they are on the right track.The real trick is the container does the plumbing and I do my bizlogic. The current offers by SpringSource as of release 2.5 are on the right track(IMO), but what is lacking is a managed host container- an appserver/container for hosting managed services that a managed bean subscribes to at runtime or programmatically. MS got AOP-style development right a long time ago thru COM+, it's all about context and interception. Think of a scenario where JDBC connections,JMS resources,or about any resource to be used in application code can be configured for use by ALL apps running in the container without using local XML descriptors for each app or at worst minimal declarative resource acquisition thru DI via annonations.And this can even be done from a management console-u should be able manage services used by a deployed bean thru a console! The only dependency would be on the service client libraries referenced in the calling code-which can either be 1.auto-generated( by the container) JARs containing service interface definitions and the necessary proxy/stub pairs 2.auto-generated( by the container) WSDL files that can be run thru a tool to generate the necessary proxy/stub pairs 3. Or even better- a service-invocation framework(can't elaborate on this now) All this if u have'nt guessed it requires a managed framework or a managed container not a suite of over-engineered specs that only looks good on paper. PS: If u have'nt realised it, MS has done it again-LINQ.It's called "ORM for the real world". Long live entity beans and JPA!