Announcement Announcement Module
Collapse
No announcement yet.
EJB 3 Listeners / Callbacks and Spring replacement Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • EJB 3 Listeners / Callbacks and Spring replacement

    Hi,
    I am currently in the process of replacing an EJB3 layer with a lightweight POJO alternative and I am interested to know what the best approach is to implementing the equivelant of @PostPersist? (Current app running on JBOSS 4)

    I suspect that this might be handled with AOP but would be interested in hearing any suggestions.

    thanks in advance.

  • #2
    Isn't EJB3 a lightweight POJO framework already? You can run it outside of JBoss, since JBoss's EJB3 container is embeddable. Unless there is functionality that Spring is going to provide, I don't see the reason to put EJB3 aside. Especially since Spring integrates with EJB3 just fine.

    Comment


    • #3
      Originally posted by wpoitras View Post
      Unless there is functionality that Spring is going to provide, I don't see the reason to put EJB3 aside. Especially since Spring integrates with EJB3 just fine.
      I will leave someone else to argue the benefit of Spring over EJB3 but suffice to say if you *are* going to use EJB3, or any other framework, please please *please* only use it as an adapter, i.e. keep all your business objects in POJOs (which EJB(3)s are most definately not) and make the 3rd party integration code (i.e. the EJB) simply delegate to the POJO.

      Whenever code depends on a 3rd party, keep that code as small as possible.

      Comment


      • #4
        Thanks for replying!

        Pros and cons of EJB aside, we are trying to develop our solution as the simplest pojo version possible to be run in a simple container environment e.g tomcat, say. Our preference is for the non-ejb solution configured using spring. And no matter what, an EJB is still an EJB inside.

        So, we are looking now for ways to duplicate the post persist event callback scenario. Any suggestions on this front would be appreciated.

        cheers

        Comment


        • #5
          I imagine "PostPersist" event is part of the JPA spec? Spring2.0 (I believe) has integration with JPA so it should still work....?

          I have never even looked into JPA integration with Spring so no idea I am afraid

          What do you need to do?

          Comment


          • #6
            Some more references which might be useful:

            http://blog.interface21.com/main/200...encing-spring/
            http://blog.interface21.com/main/200...-in-spring-20/

            Comment


            • #7
              Hi,
              I basically need to be notified in the event of a successfull DB operation. Current Impl using @PostPersist on an @EntityListener Impl. Would like to remove annotations but the version of the sw we are using does not support xml config (hibernate pre- version 3.2)

              I am thinking of using a around advice in addition to a txManager which would be 'wrapped' around the particualar business method.

              Comment


              • #8
                Sure you could. If you are using hibernate as the JPA implementation why not register a hibernate event listener?

                Comment


                • #9
                  Originally posted by yatesco View Post
                  I will leave someone else to argue the benefit of Spring over EJB3 but suffice to say if you *are* going to use EJB3, or any other framework, please please *please* only use it as an adapter, i.e. keep all your business objects in POJOs (which EJB(3)s are most definately not)
                  Why aren't EJB3s not POJOs? As far as I can tell you can take an EJB3 and run it unmodified as a POJO in unit tests and even use it in a Spring environment that ignores its annotations. I'm actually not a proponent of EJB3, just wanted to understand them.

                  Comment


                  • #10
                    Well, a class which depends on a third part framework is not a POJO.....while EJB3 beans no longer depend on interfaces, they still have a dependency via all those annotations.

                    is a java class with annotations which describe behaviour a POJO? That is the question.... I don't think a Java class with framework specific annotations is any more a POJO than a Java class with framework specific interfaces. So no, I don't think they can be classed as POJOs.

                    I was also under the *mistaken* belief that EJB3 could only do dependency injection via field level access, as it turns out that is just FUD and EJB3 can do setter injection.

                    I keep meaning to blog about this as a way of forcing my random thoughts into a cohesive argument, but I think there is a bit of smoke and mirrors involved with the "POJO"ness of the EJB3....they are still just as heavyweight both in terms of programming and in terms of deployment, it is just you have much nicer syntactical sugar (annotation over XML).

                    I think the more interesting question is why use EJB3? It is still the same old question. It *isn't* a better programming model than POJOs and an agile development. For me, it isn't so much a question of whether EJB3 is as easy to use as POJO, it is still, why should I use EJB3.....

                    Hardly a compelling argument I grant you, I really need to sit down and process this stuff first

                    Comment


                    • #11
                      See the pitchfork project - it offers EJB3 semantics on top of Spring. Also, JPA is fully supported by Spring (both through annotations and XML).
                      However, as Colin pointed out, and depending on your requirements I would advice against tyeing your objects to particular frameworks (including Spring). With EJB3/JPA this comes down to the annotation vs XML argument in the end .

                      Comment


                      • #12
                        Originally posted by yatesco View Post
                        Well, a class which depends on a third part framework is not a POJO.....while EJB3 beans no longer depend on interfaces, they still have a dependency via all those annotations.
                        So any object that uses Spring annotations (like @Transactional) aren't POJOs? Even if they are never interpretted? I guess it depends on what you mean by depends. Certainly classes with EJB3 annotations require those annotations to be present to load that class. But if they are executed in an environment where those annotations have no meaning (like a vanilla Spring container) aren't they still POJOs?

                        I don't think annotations specify functionality. Much like a marker interface doesn't. They are just there. They need an execution environment to interpret them. The fact you can port a EJB3 annotated object to Spring-based Pitchfork sort of highlights this. Also you could port such an object using XML and the presence of the annotations wouldn't mean anything. You could delete the annotations and merely limit the objects ability to properly execute in an EJB3 container, but would still execute in environments which didn't depend on them (like the mentioned XML and the unit test)

                        Comment


                        • #13
                          This is a whole other debate about annotations, but @Transactional is arguably providing meta data about the project, it is not instructing the container on how to execute it, merely what services it requires. The EJB annotations (@Stateless, for example) provide instructions on how to implement the object, and the POJO is incomplete without it. It is a subtle, but important difference. @Transactional does not belong to any framework....OK, it is defined by Spring, but it is not referring to Spring specifically, it is describing a characteristic of the bean. The EJB ones on the other hand are absolutely depending on a 3rd part framework; the ejb framework.

                          Another way of looking at it is that you are writing an EJB which can arguably be used outside an EJB container....POJOs are all about the POJOs.

                          Can you "new up" an EJB and provide all the dependencies via setter inject....yes. Does that make that EJB a POJO, absolutely not. Is it re-usable, encapsulated etc. Can that EJB be re-used in different environments, etc. Not at all, using annotations to specify runtime conditions/environment is just a fundamental mistake.

                          Also, bear in mind that an EJB3 bean assumes that all the annotations will be processed and honoured, you could re-use the bean outside of the container, but what would it's behaviour be? Proper use of annotations (I believe) do not add any extra functionality to the POJO, they merely describe meta data about the bean....loosing those annotations should not prevent the bean being used for it's original purpose.

                          Like I said, if people started writing POJOs and then decorated them into EJB3s that wouldn't be so bad, but people won't do that, they will write EJB3s and then consider them POJOs as a secondary (if at all) concern.
                          Last edited by Colin Yates; Oct 10th, 2006, 03:16 PM.

                          Comment


                          • #14
                            I should also put a big disclaimer on all of my thoughts....I really haven't thought these things through that much, they are at the level of "gut feelings" so feel free to shoot me down in flames

                            Comment


                            • #15
                              Annotated POJOs are still POJOs !?

                              Originally posted by yatesco View Post
                              I should also put a big disclaimer on all of my thoughts....I really haven't thought these things through that much, they are at the level of "gut feelings" so feel free to shoot me down in flames
                              Hi Collin,
                              I just see your argumentations about annotations in POJOs and I wanted to share my opinions with you and others Spring Team and users.

                              I am fully with what Bill (wpoitras) explain concerning annotation and marker interface: they dont specify functionnality. But you can use it to add or change POJO functionnalities, or ignore it.

                              The real debate is Annotation vs XML binding... I prefer Annotation and I am still waiting Spring team to put that in his top priority.
                              You said:
                              Like I said, if people started writing POJOs and then decorated them into EJB3s that wouldn't be so bad, but people won't do that, they will write EJB3s and then consider them POJOs as a secondary (if at all) concern.
                              That is wrong from smart java developers. They give precedence to model design before looking at the persistence constraint/model. If you consider an EJB3 Entity bean, it is a POJO (with or without annotation). You add annotation, to give enough information, to do the crud operations behind the POJO, by the Persistence manager(PM). If there is no PM in your environment, your EJB3 entity POJO can still be used as any other POJO with no constraint on the environment. This is also true for the EJB3 sessions.

                              So, what we developers need, is support for specialized operations on those POJOs:
                              - DI
                              - Persistence
                              - Transaction
                              - other specialized services
                              SpringFramework2.0 is potentially the best container, for those needs. But it lacked java oriented interface, at the beginning, and the new solutions Spring Team are taking out today (Pitchfork, spring-javaconfig packages) are the way to go, without a doubt. They are very timid in that offer and they are continuing to market the fact that XML binding is the best way to achieve the needs of java developers. I think XML binding is usefull and complementary for infrastructure configuration. But can't in my feeling be the preference of smart java developers.

                              Spring have demonstrated the way to simplify the JEE development process, but don't forget that before Spring, IOC was for long time handled by Apache offer named Avalon, and other IOC-like framework. But their environment was so tedious and difficult to implement and use until Spring offer. So many java developers sense what they want to benefit from those IOC containers.

                              If the Spring Team don't give quickly all the support for their actual java developers to integrate spring artifacts via annotation, they will loose the community interrest in favor of solutions like glassfish, geronimo, and JBoss.

                              There are many reasons for that :
                              1. For java developer, coding by XML is a constraint, and they are more confortable in java code.
                              2. They don't want to manage 2 sources of specification. Annotation is the way to centralize all the specs in on source
                              3. XML binding is more complex for java programmers than the Spring Team may think. There is a learning curve to master the spring xml config files
                              4. The springframework 2.0 is builted on a dying java 1.3 1.4 plateform, to support big corporations unable to switch quickly to java1.5+. That code can't be as optimal as a code written exclusivelly for java 1.5+.
                              5. Open source Developpers will prefer to select new containers to take avantage quickly of new technology.

                              In conclusion, It must be left to developers to say if annotated POJOs is POJOs or not. Their judgement will come from the expected runtime behavior of their favorite container.

                              Today My preferences have moved from:
                              - Hibernate, Spring, Tomcat
                              to
                              - glassfish, Toplink-essentials, [Spring]

                              but I hope to end with functionnal (in full EJB3 container)
                              - Spring(Pitchfork+JavaConfig) + Toplink-essentials

                              regards.

                              Comment

                              Working...
                              X