OnJava Article: Spring vs. EJB 3.0

Discussions

News: OnJava Article: Spring vs. EJB 3.0

  1. OnJava Article: Spring vs. EJB 3.0 (52 messages)

    OnJava recently published an article by Michael Yuan on "POJO Application Frameworks: Spring Vs. EJB 3.0," comparing the approaches that the two frameworks take to persisting Java objects - so far as Spring can be considered to focus on the specific capability of persistence.
    Although Spring and EJB 3.0 both aim to provide enterprise services to loosely coupled POJOs, they use very different approaches to archive this goal. Dependency Injection is a heavily used pattern in both frameworks.

    With EJB 3.0, the standards-based approach, wide use of annotations, and tight integration with the application server all result in greater vendor independence and developer productivity. With Spring, the consistent use of dependency injection and the centralized XML configuration file allow developers to construct more flexible applications and work with several application service providers at a time.
    Is this comparison valid? Spring's authors focus on dependency injection rather than persistence, so is a comparison of a persistence framework to a dependency injection framework even useful?

    Threaded Messages (52)

  2. not only persistence[ Go to top ]

    Is this comparison valid? Spring's authors focus on dependency injection rather than persistence, so is a comparison of a persistence framework to a dependency injection framework even useful?

    You forget Session, MDBs, Timer Service, etc...There's also nice integration with the new EJB 3 persistence manager for automatic persistence context management and things like that...

    I think the value of non-Entities is the ability to avoid XML if possible and make deployment and enterprise programming feel like a part of the Java language (through annotations).

    That being said, dependency injection frameworks like Spring still compliment EJB 3.0 EJBs and Persistence entities quite nicely. Until EJB 3.0/J2EE in general gains an ability to provide consistent, flexible configuration, frameworks like Spring will still be needed.

    Bill
  3. not only persistence[ Go to top ]

    That being said, dependency injection frameworks like Spring still compliment EJB 3.0 EJBs and Persistence entities quite nicely.

    Bill, I'm glad to see you publicly saying so. A lot of developers that I run into (not just customers) are using Spring, and almost all of the ones that are using it really like it, even if for the smallest little reasons (e.g. nice helper classes and libraries). There are a lot of projects using Spring with Hibernate, Spring on jBoss and Spring on Tomcat; it's a good opportunity for you (jBoss company), and it is not really competition.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  4. not only persistence[ Go to top ]

    That being said, dependency injection frameworks like Spring still compliment EJB 3.0 EJBs and Persistence entities quite nicely.
    Bill, I'm glad to see you publicly saying so. A lot of developers that I run into (not just customers) are using Spring, and almost all of the ones that are using it really like it, even if for the smallest little reasons (e.g. nice helper classes and libraries). There are a lot of projects using Spring with Hibernate, Spring on jBoss and Spring on Tomcat; it's a good opportunity for you (jBoss company), and it is not really competition.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

    You act like this is new from me....
  5. Confused[ Go to top ]

    It was my understanding that Spring itself does not handle persistence, but rather provides hooks and what not (e.g. common exception handling strategy) to existing persistence mechanisms (like JDO, hibernate, and so on).

    In this sense, there is no comparison. Spring compliments EJB 3, but does not compete with it. Or am I missing some overlapping behavior (I am not too familiar with EJB 3, which I assume is strictly related to persistence)...
  6. Confused[ Go to top ]

    It was my understanding that Spring itself does not handle persistence, but rather provides hooks and what not (e.g. common exception handling strategy) to existing persistence mechanisms (like JDO, hibernate, and so on). In this sense, there is no comparison. Spring compliments EJB 3, but does not compete with it. Or am I missing some overlapping behavior (I am not too familiar with EJB 3, which I assume is strictly related to persistence)...

    Pico, I'm of the same frame of reference. In my own world EJB3=Persistence, and therefore I see all the threads on "EJB3 VS SPRING" almost like "Chocolate Cake vs Milk" (i.e., the both are excellent things that work well together or on their own)...

    But, in most peoples' mind (and more accurately I'll agree), EJB3 means the entire container, and any legacy perceptions that go with that. I.e., servlet engines, session beans, mdbs, txn semantics, yadda, yadda). And hence where the debates can come into play.

    Personally I think it's all a healthy discussion to have, and seeing how much fun and productive it's been for my team to be working with Rod and Jurgen on the Spring-TopLink support, there will only be more benefits to continuing this onto EJB3 (persistence at least)... But the bottom line, there will always be those using attention grabbing headlines with legacy inflections to seek attention for personal gain.

     - Don
  7. Confused[ Go to top ]

    But, in most peoples' mind (and more accurately I'll agree), EJB3 means the entire container, and any legacy perceptions that go with that. I.e., servlet engines, session beans, mdbs, txn semantics, yadda, yadda).

    FTR, none of servlet engines, transaction semantics, yadda, and yadda are part of EJB3, nor were they part of prior EJB releases. The EJB 1, 2, and 3 specs do discuss transactions from the standpoint of declarative transaction demarcation, but don't really define transaction semantics per se -- that's up to JTA and the other transaction-related specs. Similarly, servlets are J2EE (and will soon be Java EE), but are not part of EJB, 3 or otherwise.

    EJB just includes the stuff in the javax.ejb package (session beans, message-driven beans, timers, and old-school entity beans) and the javax.persistence package (new-school entities).

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
  8. Confused[ Go to top ]

    ...thanks for the clarification Patrick, hopefully with EJB3, these distinctions become clear, even with the FUD trying to continue the history forward...

    My point was "peoples' perceptions" to lump "EJB == CONTAINER == BAD", and that's definitely not the case.

     - Don

    PS - Anyone else suddenly having a craving for chocolate cake?
  9. Spring and EJB3 persistence[ Go to top ]

    Personally I think it's all a healthy discussion to have, and seeing how much fun and productive it's been for my team to be working with Rod and Jurgen on the Spring-TopLink support, there will only be more benefits to continuing this onto EJB3 (persistence at least)...

    Yes, it's been fun to work with Jim and Shaun, and we even got some very decent Spring-TopLink support out there :-)

    Using EJB3 persistence in a Spring context will be very straightforward as well, both in a "managed" environment (with the EntityManager coming from a J2EE server's JNDI environment) and in a "non-managed" environment (with an EJB3 persistence provider set up locally within the Spring context).

    All of this will be fully integrated with Spring's transaction management, of course. And the setup details will be fully transparent to the application: DAOs will simply receive an EntityManager through dependency injection and not care about where it came from or which kind of transactions it is running in.

    Juergen
  10. EJB3 scope[ Go to top ]

    It was my understanding that Spring itself does not handle persistence, but rather provides hooks and what not. ... am I missing some overlapping behavior (I am not too familiar with EJB 3, which I assume is strictly related to persistence)...

    Yes; EJB3 includes persistence (in the EJB3 Persistence API, or the javax.persistence package) and also session beans, message-driven beans, and timers (in the javax.ejb package, as with prior releases of EJB).

    The EJB3 Persistence API is the piece that is under constant debate whenever any of the various ORM hot-topics come up. The session beans etc. are considerably less-discussed here on TSS, but are still there in EJB3, and have undergone significant simplification.

    In brief, the new EJB3 session bean / MDB contract strives for increased developer simplicity, and relies heavily on dependency injection to achieve this. As such, it is inspired by Spring and the other DI frameworks out there today. Essentially, it is a tune-up of EJB2 session beans / MDBs mainly with DI instead of resource lookup in mind. As a result, your enterprise beans don't to implement the various infrastructure interfaces that you needed in EJB2 and prior, but instead you will use various annotations / XML markup to describe the behavior of your session beans and MDBs.

    (I'm blatantly ignoring some other new additions, such as interceptors, in part because they're still being worked on by the EG and in part to keep this post short.)

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
  11. Confused[ Go to top ]

    Yes, it confuses. Probably there are no technical arguments to sell this trivail suff if authors confuse developers and try to sell it as something more usefull than wrapper for standard API.
  12. Spring has a future for a long time even after EJB 3.0 arrives. EJB 3.0 has injection and so the comparison isn't really about persistence.

    Customers are running on EJB 1.0/1.1/2.0/2.1 and will be for quite a while to come. Spring allows them to take advantage of this style of programming in those apps and with frameworks like Hibernate/TopLink get the same OR mapping. Nothing (and I do mean nothing) pisses a customer off like telling em that they need to upgrade the application server just to get a feature thats critical for a production problem they are having.

    Non invasive or viral componentized middleware (I like the term viral here but the marketing guys would hate it) thats backwards compatible is the way to go. I wrote a blog entry on this previously.

    Personally while annotations are cool, I predict problems for any framework that prereqs them as it limits the usage of the framework to J2SE 1.5 or higher. Customers using viral middleware will demand backwards compatibility with older JDKs. We'll still need xml based descriptors for a long time to come.

    Billy
    http://www.billy.newport.com
  13. Old news[ Go to top ]

    This Article has been posted 06/29/2005.
  14. Spring gives me flexibility[ Go to top ]

    Spring gives me the ability to choose everything. I can choose my transaction management. I can choose my persistence. I can even choose my configuration. I can choose, for instance to use annotations to determine my transactional boundaries, but XML to define the relationships between components in my backend logic. [The article gives the impression that Spring is tied to XML configuration. This is not true. You can use annotations, JDBC, properties files, XML, or anything else since there is an open interface]

    The entire Spring framework consistently allows users to pick and choose the parts that they like with virtually no lock in.

    When I used EJB containers, I routinely encountered inefficiencies or outright bugs for which there was no practical work around. I have some particularly frustrating memories of discovering bugs in Weblogic and being told they would be fixed in the next release.

    I will never have this problem with Spring, because I can just swap out the components which aren't implemented to my satisfaction.

    Even an open source EJB server still has to adhere to the specification which, unless history suddenly stops repeating itself, will contain elements that under certain circumstances give containers the choice of complying with the standard or being efficient.

    By the time EJB3.0 actually achieves wide distribution, somebody will probably have written a set of Spring classes that emulates the entire set of useful EJB3.0 annotations.

    True, extra flexibility creates extra opportunity for mistakes. But if you don't trust your developers to use the advanced functionality [like AOP], put all references to it in the configuration files, and then make them off limits.
  15. Spring configuration[ Go to top ]

    This article could be interpreted to say that XML configuration = Spring. While this is completely incorrect, I really don't understand what's so bad about using XML for configuration. I really do like having all of my configuration information in one central location, and easy to change if the need arises... I like this much better than using annotations for configuration that are scatted across many different java source files. I believe annotations are better suited for AOP code that would change the behavior of the object - for example the hibernate mappings and such.

    But the beauty of Spring is you can configure objects any way you'd like. Even directly in Java code. While EJB3-like configuration annotations aren't yet supported out of the box, you can bet they will be. I wouldn't be surprised at all to see EJB3-like annotations for configuration in a production release of Spring before there's a production-ready release of an implmentation of the EJB3 spec...

    I'm excited about both EJB3 and future releases of Spring. Where's the love?

    Joe
  16. Standards is not equal to great[ Go to top ]

    This article kind of indicates standards are always good. We have plethora of examples Struts, Spring, Hibernate which all have become very popular with no support technical or marketing from big vendors (who mostly make up standards bodies). We also have several examples on standards which have never taken off or downright bad. JAXB 1.0, JAXM and of course EJB 2.1 etc. are all classic examples. Patricks own JDO has been a standard in making for years with little success and hibernate just took off. Its time vendors stop professing about how applications are built. Vox populi matters - not what JCP thinks is good.
  17. Proprietary is not equal to great[ Go to top ]

    This article kind of indicates standards are always good. We have plethora of examples Struts, Spring, Hibernate which all have become very popular with no support technical or marketing from big vendors (who mostly make up standards bodies).

    You also have a plethora of specifications that were very successful: JTS/JTA, XA, JMS, Servlet, Web Services, JNDI, even CORBA in its time.
    We also have several examples on standards which have never taken off or downright bad....EJB 2.1 etc. are all classic examples.

    You need to have some perspective. EJBs were the shiznet compared to what we used to have to do.
    Vox populi matters - not what JCP thinks is good.

    I've said this before in blogs and posts. Innovate outside of the standards process. Bring back those successful innovations to a standards body. This is what EJB3 spec is doing. Hibernate and Toplink and KODO innovated, now they are joining up to standardize.

    Bill
  18. Spring configuration[ Go to top ]

    I'm excited about both EJB3 and future releases of Spring.

    I fully agree. I'm excited that we will finally have a standardized persistance spec that is based on best of breed tools. I'm also excited by the fact that Spring can bring new features and ideas to market so quickly.
  19. I'm excited about both EJB3 and future releases of Spring.
    I fully agree. I'm excited that we will finally have a standardized persistance spec that is based on best of breed tools. I'm also excited by the fact that Spring can bring new features and ideas to market so quickly.

    This ability to bring new features to market quickly is very important. It's one of the benefits of being your own standard. If an EJB vendor provides an extension you want to use you must be concerned about vendor lock in. Or you have to wait until EJB 3+ comes out, that is if the committee agrees to append the standard with the feature you want. Isn't there lock in with Spring? I guess it all depends on your definition. If I have access to the source code and can run as many copies as I want without paying any license fees then I don't consider it lock in.
  20. Spring configuration[ Go to top ]

    I like this much better than using annotations for configuration that are scatted across many different java source files.
    Cannot agree more
    I believe annotations are better suited for AOP code that would change the behavior of the object
    Agree too
    - for example the hibernate mappings and such.
    This is not good example. OR mapping metadata should go to configuration file, rather then to annotations.
    Good candidates for annotations are transaction demarcation, declarative security (but much more fine grained then in EJB), lazy load...

    The problem with current Spring XML configuration is that it contains a lot of stuff that does not belong to the configuration but rather to annotations. When this stuff migrate to annotations, Spring XML config will be much more compact.
  21. to each his own[ Go to top ]

    OR mapping metadata should go to configuration file, rather then to annotations.

    That is your opinion and particular taste. Others prefer annotations (the XDoclet crowd).
  22. to each his own[ Go to top ]

    OR mapping metadata should go to configuration file, rather then to annotations.
    That is your opinion and particular taste. Others prefer annotations (the XDoclet crowd).

    The semantics of XDoclet are slightly different than annotations however, since XDoclet does not introduce a runtime depdendency. Using Hibernate doclets in my code, does not tie my domain objects to Hibernate at runtime, whereas using annotations introduces a runtime dependency. This is, IMHO, the biggest problem with using annotations for ORM mappings.

    Rob
  23. to each his own[ Go to top ]

    OR mapping metadata should go to configuration file, rather then to annotations.
    That is your opinion and particular taste. Others prefer annotations (the XDoclet crowd).
    The semantics of XDoclet are slightly different than annotations however, since XDoclet does not introduce a runtime depdendency. Using Hibernate doclets in my code, does not tie my domain objects to Hibernate at runtime, whereas using annotations introduces a runtime dependency. This is, IMHO, the biggest problem with using annotations for ORM mappings.Rob

    Agreed - plus your code will not work on anything other than Java 5 or later JVMs.

    James
    LogicBlaze
  24. to each his own[ Go to top ]

    whereas using annotations introduces a runtime dependency. This is, IMHO, the biggest problem with using annotations for ORM mappings.Rob

    This is partially true. It does introduce a runtime dependency in the ORM mapper's VM obviously, but not on the client's VM. Try it.
  25. to each his own[ Go to top ]

    whereas using annotations introduces a runtime dependency. This is, IMHO, the biggest problem with using annotations for ORM mappings.Rob
    This is partially true. It does introduce a runtime dependency in the ORM mapper's VM obviously, but not on the client's VM. Try it.

    Sorry, I'll elaborate...Even if the annotation is marked as RetentionPolicy.RUNTIME, you do not need the annotation in your classpath if you don't access it. Obviously, the ORM mapper needs to access the annotation at runtime, but if you switch ORM tools, or serialize the entity bean to a client that does not have the Hibernate annotations in their classpath, this does not blow up.

    Try this simple example:

    @Retention(RetentionPolicy.RUNTIME)
    public @interface ann {
        Class[] value();
    }

    @ann(String.class)
    public class UseAnn
    {
        public static void main(String[] arg) {
            System.out.println("HelloWorld");
            new UseAnn();
        }
    }


    Compile this, then remove ann.class from your filesystem. UseAnn runs fine.

    Bill
  26. to each his own[ Go to top ]

    whereas using annotations introduces a runtime dependency. This is, IMHO, the biggest problem with using annotations for ORM mappings.Rob
    This is partially true. It does introduce a runtime dependency in the ORM mapper's VM obviously, but not on the client's VM. Try it.
    Sorry, I'll elaborate...Even if the annotation is marked as RetentionPolicy.RUNTIME, you do not need the annotation in your classpath if you don't access it. Obviously, the ORM mapper needs to access the annotation at runtime, but if you switch ORM tools, or serialize the entity bean to a client that does not have the Hibernate annotations in their classpath, this does not blow up.Try this simple example:@Retention(RetentionPolicy.RUNTIME)public @interface ann {
       Class[] value();
    }

    @ann(String.class)public class UseAnn{
        public static void main(String[] arg) {
           System.out.println("HelloWorld");
           new UseAnn();
       }
    }

    Compile this, then remove ann.class from your filesystem. UseAnn runs fine.Bill
    Of couse, the only problem then is what happens when you try to access other annotations on the class. If all annotations on the class are not present on the classpath, then you will get a TypeNotPresentException when attempting to access an annotation that is on the classpath.

    So for instance:

    @MyAnnotation
    @MyOtherAnnotation
    public class MyClass {
        public static void main(String[] args) {
            System.out.println("Hello World!");
            Annotation a = MyClass.class.getAnnotation(MyOtherAnnotation.class);
            System.out.println(a.toString());
        }
    }

    Will not work when MyAnnotation does not exist at runtime but MyOtherAnnotation does.

    Rob
  27. to each his own[ Go to top ]

    whereas using annotations introduces a runtime dependency. This is, IMHO, the biggest problem with using annotations for ORM mappings.Rob
    This is partially true. It does introduce a runtime dependency in the ORM mapper's VM obviously, but not on the client's VM. Try it.
    Sorry, I'll elaborate...Even if the annotation is marked as RetentionPolicy.RUNTIME, you do not need the annotation in your classpath if you don't access it. Obviously, the ORM mapper needs to access the annotation at runtime, but if you switch ORM tools, or serialize the entity bean to a client that does not have the Hibernate annotations in their classpath, this does not blow up.Try this simple example:@Retention(RetentionPolicy.RUNTIME)public @interface ann {
    Class[] value();
    }
    @ann(String.class)
    public class UseAnn{
       public static void main(String[] arg) {
           System.out.println("HelloWorld");
           new UseAnn();
       }
    }
    Compile this, then remove ann.class from your filesystem. UseAnn runs fine.Bill
    Of couse, the only problem then is what happens when you try to access other annotations on the class. If all annotations on the class are not present on the classpath, then you will get a TypeNotPresentException when attempting to access an annotation that is on the classpath.So for instance:
    @MyAnnotation@MyOtherAnnotationpublic class MyClass {
    public static void main(String[] args) {
    System.out.println("Hello World!");
    Annotation a = MyClass.class.getAnnotation(MyOtherAnnotation.class);
    System.out.println(a.toString());
    }
    }

    Will not work when MyAnnotation does not exist at runtime but MyOtherAnnotation does.Rob
    Then maybe vendor specific annotations are better declared with RetentionPolicy.CLASS. It is still possible to obtain CLASS declared annotations at runtime using javassist or asm. In our EJB3 and also AOP implementations we provide an abstraction for annotation lookup to facilitate this sort of thing.

    Still, its also not such a big deal to ship with the annotation jars for each vendor to rectify your extremely fringe usecase.
  28. to each his own[ Go to top ]

    whereas using annotations introduces a runtime dependency. This is, IMHO, the biggest problem with using annotations for ORM mappings.Rob
    This is partially true. It does introduce a runtime dependency in the ORM mapper's VM obviously, but not on the client's VM. Try it.
    Sorry, I'll elaborate...Even if the annotation is marked as RetentionPolicy.RUNTIME, you do not need the annotation in your classpath if you don't access it. Obviously, the ORM mapper needs to access the annotation at runtime, but if you switch ORM tools, or serialize the entity bean to a client that does not have the Hibernate annotations in their classpath, this does not blow up.Try this simple example:@Retention(RetentionPolicy.RUNTIME)public @interface ann {
    Class[] value();}
    @ann(String.class)
    public class UseAnn{
    public static void main(String[] arg) {
    System.out.println("HelloWorld");
    new UseAnn();
    }
    }
    Compile this, then remove ann.class from your filesystem. UseAnn runs fine.Bill
    Of couse, the only problem then is what happens when you try to access other annotations on the class. If all annotations on the class are not present on the classpath, then you will get a TypeNotPresentException when attempting to access an annotation that is on the classpath.So for instance:@MyAnnotation@MyOtherAnnotationpublic class MyClass {
    public static void main(String[] args) {
    System.out.println("Hello World!");
    Annotation a = MyClass.class.getAnnotation(MyOtherAnnotation.class);
    System.out.println(a.toString());
    }
    }
    Will not work when MyAnnotation does not exist at runtime but MyOtherAnnotation does.Rob
    Then maybe vendor specific annotations are better declared with RetentionPolicy.CLASS. It is still possible to obtain CLASS declared annotations at runtime using javassist or asm. In our EJB3 and also AOP implementations we provide an abstraction for annotation lookup to facilitate this sort of thing.Still, its also not such a big deal to ship with the annotation jars for each vendor to rectify your extremely fringe usecase.
    I wouldn't say that the use case I described (keeping my domain objects decoupled from the underlying persistence mechanism) is 'fringe'. I would have thought that this would be common place.

    Rob
  29. to each his own[ Go to top ]

    whereas using annotations introduces a runtime dependency. This is, IMHO, the biggest problem with using annotations for ORM mappings.Rob
    This is partially true. It does introduce a runtime dependency in the ORM mapper's VM obviously, but not on the client's VM. Try it.
    Sorry, I'll elaborate...Even if the annotation is marked as RetentionPolicy.RUNTIME, you do not need the annotation in your classpath if you don't access it. Obviously, the ORM mapper needs to access the annotation at runtime, but if you switch ORM tools, or serialize the entity bean to a client that does not have the Hibernate annotations in their classpath, this does not blow up.Try this simple example:@Retention(RetentionPolicy.RUNTIME)public @interface ann {
    Class[] value();
    }@ann(String.class)
    public class UseAnn{
    public static void main(String[] arg) {
    System.out.println("HelloWorld");
    new UseAnn();
    }
    }
    Compile this, then remove ann.class from your filesystem. UseAnn runs fine.Bill
    Of couse, the only problem then is what happens when you try to access other annotations on the class. If all annotations on the class are not present on the classpath, then you will get a TypeNotPresentException when attempting to access an annotation that is on the classpath.So for instance:@MyAnnotation@MyOtherAnnotationpublic class MyClass {public static void main(String[] args) {System.out.println("Hello World!");
    Annotation a = MyClass.class.getAnnotation(MyOtherAnnotation.class);
    System.out.println(a.toString());
    }
    }

    Will not work when MyAnnotation does not exist at runtime but MyOtherAnnotation does.Rob
    Then maybe vendor specific annotations are better declared with RetentionPolicy.CLASS. It is still possible to obtain CLASS declared annotations at runtime using javassist or asm. In our EJB3 and also AOP implementations we provide an abstraction for annotation lookup to facilitate this sort of thing.Still, its also not such a big deal to ship with the annotation jars for each vendor to rectify your extremely fringe usecase.
    I wouldn't say that the use case I described (keeping my domain objects decoupled from the underlying persistence mechanism) is 'fringe'. I would have thought that this would be common place. Rob
    You're back to opinion and taste...
  30. to each his own[ Go to top ]

    whereas using annotations introduces a runtime dependency. This is, IMHO, the biggest problem with using annotations for ORM mappings.Rob
    This is partially true. It does introduce a runtime dependency in the ORM mapper's VM obviously, but not on the client's VM. Try it.
    Sorry, I'll elaborate...Even if the annotation is marked as RetentionPolicy.RUNTIME, you do not need the annotation in your classpath if you don't access it. Obviously, the ORM mapper needs to access the annotation at runtime, but if you switch ORM tools, or serialize the entity bean to a client that does not have the Hibernate annotations in their classpath, this does not blow up.Try this simple example:@Retention(RetentionPolicy.RUNTIME)public @interface ann {    Class[] value();}@ann(String.class)public class UseAnn{    public static void main(String[] arg) {        System.out.println("HelloWorld");        new UseAnn();    }}Compile this, then remove ann.class from your filesystem. UseAnn runs fine.Bill
    Of couse, the only problem then is what happens when you try to access other annotations on the class. If all annotations on the class are not present on the classpath, then you will get a TypeNotPresentException when attempting to access an annotation that is on the classpath.So for instance:@MyAnnotation@MyOtherAnnotationpublic class MyClass {    public static void main(String[] args) {        System.out.println("Hello World!");        Annotation a = MyClass.class.getAnnotation(MyOtherAnnotation.class);        System.out.println(a.toString());    }}Will not work when MyAnnotation does not exist at runtime but MyOtherAnnotation does.Rob
    Then maybe vendor specific annotations are better declared with RetentionPolicy.CLASS. It is still possible to obtain CLASS declared annotations at runtime using javassist or asm. In our EJB3 and also AOP implementations we provide an abstraction for annotation lookup to facilitate this sort of thing.Still, its also not such a big deal to ship with the annotation jars for each vendor to rectify your extremely fringe usecase.
    I wouldn't say that the use case I described (keeping my domain objects decoupled from the underlying persistence mechanism) is 'fringe'. I would have thought that this would be common place. Rob
    You're back to opinion and taste...

    As I stated before, many developers I've talked to prefer to see metadata and code in one place. If you do not have a need to entirely decouple your domain objects, annotations are far easier to maintain and enable than writing an XML DD. If the need pops up later, you can always override with XML.
  31. Must have choice[ Go to top ]

    Of course everyone has preferences, therefore everyone must have choice. Correct me if I'm wrong, but EJB 3.0 does not give you the choice of using central, XML, configuration. Spring gives you the choice of using either/both central configuration and annotations.

    I personally do not like annotation-based configuration, either...
  32. Must have choice[ Go to top ]

    Spring gives you the choice of using either/both central configuration and annotations.I personally do not like annotation-based configuration, either...
    Annotations are designed for metadata, metadata is not configuration, it enhances declarations in code. It is not a good idea to mix configuation and metadata in XML file too (it is as wrong as configuration in JAVA code)
  33. Must have choice[ Go to top ]

    Of course everyone has preferences, therefore everyone must have choice. Correct me if I'm wrong, but EJB 3.0 does not give you the choice of using central, XML, configuration. Spring gives you the choice of using either/both central configuration and annotations.I personally do not like annotation-based configuration, either...

    You are mostly wrong. EJB 3.0 does not require annotations. You can specify everything in XML. Although env-entries allow you to inject primitive types into your EJBs, it does lack a full XML externalization of a plain Java bean. This is where I think Spring can compliment EJB 3. I have somebody looking into integrating Spring and EJB3.

    EJB 3.0 also allows you to override annotations with partial XML. For example, if you used the @TransactionAttribute annotation, you could override it in the XML DD by only. specifying an assembly descriptor.

    EJB 3.0 also offers the old strengths of J2EE, that you can componentize your work and provide a standard packaging for for these components so that individual pieces can be reused and even hot-deployed in your environment. I have a volunteer contributor working on this very thing for Spring+JBoss as well.

    Bill
  34. Spring doesn't have to be XML[ Go to top ]

    I have cooked up this little library that does something unusual: use Java syntax to declare object dependecies so I now enjoy the power of modern IDEs for seamless Spring programming.

    http://jacn.sourceforge.net/

    ... A shameless plug.

    Bing Ran.
  35. OnJava Article: Spring vs. EJB 3.0[ Go to top ]

    Spring's authors focus on dependency injection rather than persistence, so is a comparison of a persistence framework to a dependency injection framework even useful?

    This is the words of TSS editors. But the "POJO application framework" side of EJB3 is a persistence framework, is it not?
  36. Pavel Grushetzky[ Go to top ]

    Just some personal thoughts on the article.

    - Spring and EJB are not mutually exclusive and therefore it is probably not correct to put them "vs" each other.

    There is a very little dependency on Spring API, and it is not difficult at all to isolate this dependency with abstraction layer. Indeed, there is not much to isolate with Spring.

    * Another misunderstanding of Spring is that one should refactor code to change service implementation.
    The whole point here is to avoid refactoring and rather allow reconfiguration. Just like a DAO pattern - you do not refactor, you configure for another implementation.

    * Standards are good (and thanks god they exist), but something not covered by standard does not automatically become "bad".
    There is no standard for Dependency Injection for example, but here it is.

    So, my view is that this is quite good article to outline EJB3 perspectives and simplicity, but Spring side is not always correct.

    Anyway thanks Michael for efforts spent for writing this article.
  37. The Spring framework is a popular but non-standard open source framework.

    To me the risk of using a product which is "open-source" and "popular" is better than a product which is "standard".
  38. I am convinced?[ Go to top ]

    Spring went out to and did make J2EE development easier.

    As a reply the EJB3 group has made a realy nice package for the business/persistence tier. It contains about everything I need, it plays together and is straight forward and easy to use.

    However how do I get the stateless beans in my Struts-Actions, Tapestry-, Swing- or Wicket-Components. I think I'll use Spring for that (DI). And than I'll think why go/learn further and do not stick to Spring in the first place.

    Is there an easy maybe DI way to get business beans out of the container?

    Christian
  39. From the article the author doesn' tseems to be really objective and seems to have a hidden agenda of promoting EJB3.
    When he compares the Spring configuration against (in his opinion) much simler EJB3 way he's biased and this is really a case of comparing one framework represented in the best possible way against another represented in the worst possible way. The Spring xml configuration could have been way more simple and succint just by using autoproxying and autowiring.

    Don't blindly buy into the EJB3 propaganda. *Really* learn Spring and then judge for yourself.

    just my 2 cents...
  40. Don't blindly buy into the EJB3 propaganda. *Really* learn Spring and then judge for yourself.

    I'm not sure I understand. I don't think I've ever met someone in the EJB3 community who doesn't have a lot of respect for Spring. Moreover, all I see are opportunities for Spring and EJB3 (persistence especially because it's my domain) to leverage each other's strengths. The only propaganda I see is from people who have a TSS posting history of using JDO as a leverage point to bash EJB3 now desparately trying to use Spring as a leverage point to bash EJB3. But it's just laughable.

     - Don
  41. Author's home page: http://www.enterprisej2me.com/

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  42. First, every so often, I need two screens next to each other in order to read a post. I don't.

    Second, more often than not, the message header layer is misplaced low enough to completely cover two rows of text.

    Is my Firefox the reason? Am I the only one?

    Please do something about that.

    Florin
  43. 3 screens wide on Opera 8.02
    Build 7680
    Platform Win32 and its Mozilla facade.
    Is the problem CSS, XSLT or what?
  44. TSS editors added them![ Go to top ]

    comparing the approaches that the two frameworks take to persisting Java objects - so far as Spring can be considered to focus on the specific capability of persistence.

    This is also the words of TSS editors, not mine. Thanks, TSS.
  45. OnJava Article: Spring vs. EJB 3.0[ Go to top ]

    To summaries, there are three controversies in the article, i.e.

    - call "EJB3" a POJO framework
    - accuse Spring for XML configuration
    - accuse Spring for non-standard
  46. OnJava Article: Spring vs. EJB 3.0[ Go to top ]

    there are three controversies in the article,i.e.
    - call "EJB3" a POJO framework
    ...

    The full EJB 3.0 requires a Java EE 5.0 server.
  47. To summaries, there are three controversies in the article, i.e.
    - accuse Spring for XML configuration

    The question is not XML versus annotations, the question is complex versus simple.
    The XML DD of EJB is quite complex but
    XML allows to write ellegant and simple frameworks,
    think in Apache Ant, for example.

    Old EJB are ugly not only because XML DD, but also by Java. How many classes for a component in EJB2?

    You can take away XML to simplify, but
    you can also take away Java to simplify and use only XML
    (as in OpenXava).
  48. To summaries, there are three controversies in the article, i.e.
    - accuse Spring for non-standard

    Maybe 15 years ago we have Standard vs Propietary dilema.

    But now we have Open Source, Propietary and Standard, and overlapped.

    Open Source software is not exactly as Propietary software.

    I think the important is if the product is a 'de facto' standard not an official standard.

    CORBA, C++, COBOL are official standard.
    Ant, JUnit, Eclipse and Java are not official standard.

    What do you use?

    Now Spring is a 'de facto' standard.
    And EJB3 does not exist.
    Maybe in the future EJB3 will be a 'de facto' standard.
  49. And EJB3 does not exist.

    Except
    Here: http://www.oracle.com/technology/tech/java/ejb30.html
    Here: http://www.jboss.org/products/ejb3
    and Here: http://www.solarmetric.com/kodo/beta/4.0.0EA

    Nope doesn't exist, fudder fudder. LOL.

     - Don
  50. EJB3 does not exist as 'de facto' standard.

    EJB3 exists, and easily will be 'de facto' standard for persistence in the future.

    But about that some questions arise:
    - Will the Hibernate community migrate to EJB3?
    - Will the JDO community migrate to EJB3?
    - Will IBM and BEA promote EJB3?
  51. EJB3 does not exist as 'de facto' standard.EJB3 exists, and easily will be 'de facto' standard for persistence in the future.

    The availability and popularity of standalone "EJB 3.0 POJO persistence" implementations,
    complimented by the Spring framework, will make "EJB 3.0 proper" irrelevant in the future.
    That is why I say "EJB 3.0 is no longer EJB".
  52. OnJava Article: Spring vs. EJB 3.0[ Go to top ]

    And EJB3 does not exist.
    Except Here: http://www.oracle.com/technology/tech/java/ejb30.htmlHere: http://www.jboss.org/products/ejb3and Here: http://www.solarmetric.com/kodo/beta/4.0.0EANope doesn't exist, fudder fudder. LOL. - Don

    A rather harsh comment, as JSR 220 is still 'in progress', and those implementations, even though they are likely to be very close to the final version of EJB 3.0, are therefore previews and betas.
  53. The only good thing about EJB so far has been it being a standard specification that a lot of vendors adher to in providing their implementation. Nobody wants to take the risk of having their application fate determined by the quarterly financial performance of the vendors of the software stack. These vendors go out of business frequently as we know of so many J2EE vendors that have disappeared from the scene. Spring (Hibernate/Toplink) definitely proved that we didn't need a complicated framework like EJB at the first place. Things could be accomplished by much simpler framework(s). However, they are all proprietary solutions. They did help to wake up the JSR folks. I think we all agree EJB3 is a lot of improvement over EJB2.1. The fact that it can be standard specification and deliver all the current needs is wonderful. I have been bashing EJB myself (esp. Entity beans) for their complexity but I didn't want to use something proprietary and went the home grown solution way. The POJO model has made it much simpler and desirable. It should have been like that at the first place. It is the desired solution that took 5 years too many to arrive. Well, I guess time to market is tradeoff for the standard specification. As a software manager, I know how difficult is sometimes to come up with a solution agrreable to all developers and we are talking big bureaucratic companies here. The question is to ask is not if EJB3 is better but is it too late ? . Who will migrate back to EJB having chosen other solutions. For new applications, it may be a no brainer. I strongly believe it is once again going to be the J2EE server vendors that will pump up the hype as they start supporting EJB. They have to because that is the only value preposition they bring to the table. Anyway, time will tell. I am personally excited to see the EJB3 esp. the new persistence framework. At least I will not have to create another of the home grown persistence frameworks. -Pankaj Grover