EJB 3 callbacks: Feedback wanted


News: EJB 3 callbacks: Feedback wanted

  1. EJB 3 callbacks: Feedback wanted (46 messages)

    Cedric Beust has posted on EJB 3 callbacks, and how they should be implemented. He discusses five techniques, and asks what you think! The techniques are: Magic callbacks, interface, base class, annotations, EntityManager callbacks. What is your poison?

    1. Magic callbacks. Method signature is the same as a container defined
      one. Eg public void ejbPassivate();
      + Very lightweight, no template code, no base class, no interface
              - Easily breakable (developers will mistype), doesn't express container
    2. Interface. Current state in 2.x spec.
      + Clear dependency expression, not breakable.
      Lot of template code (today's code is cluttered with many lines of callback
      template code that does nothing).
    3. Base class. Provide template code in base class, have developers extend from
      + No template code, not breakable.
      - Single inheritance in java makes this base class a no-no.
    4. Annotations. Annotate any method as callback (as the example of "@remove"
      that Linda already showed)
      No template code, not breakable (annotations can be supported in
      IDE/compile), any name.- ?
    5. EntityManager callbacks as opposed to POJO callbacks. e.g.
       (LifeCycleListener listener,
      Class classOfInterest, long lifeCycleEventsOfInterest);
      + No interference with POJO class.
      + Exploits well-known event listener paradigm.
      + Very lightweight, only called if specific class/life cycle event
      happens.+/- "aspect oriented".-
      Not object-oriented (code outside POJO affects POJO).
      - How can we extend this to Session beans?
    Read Cedric Beust in EJB 3 callbacks

    Threaded Messages (46)

  2. EJB 3 callbacks: Feedback wanted[ Go to top ]

    I think interfaces and annotations should both be supported options. Magic callbacks and EntityManager callbacks are extremely awkward to me. I understand the appeal of using the EntityManager to configure a pure POJO, but I don't think it's worth separating so much core component behavior from the object.

    I would be supportive of providing an optional base class in the j2ee.jar for people to extend that provide default implementations of the methods. It would kill a pre-existing class hierarchy, but some people will find it useful for simpler components.
  3. EJB 3 callbacks: Feedback wanted[ Go to top ]

    I think interfaces and annotations should both be supported options. ...
    Completly agree 2 + 4 should be.
  4. EJB 3 callbacks: Feedback wanted[ Go to top ]

    Interfaces, annotations and a utility base class for simple cases (like happens with Thread/Runnable).

    So all of them really !
  5. EJB 3 callbacks: Feedback wanted[ Go to top ]

    How about

    public interface Bla{




    and public class DefaultBla implements Bla{
    ... default implementations

    Not having worked with annotations, can't say whether they're good or bad in practice. Don't see any reason to use them here though...
  6. EJB 3 callbacks: Feedback wanted[ Go to top ]

    "2." Interface it is very clear and common way do define contract, if you need "default" implementation then implement stuff in base class or make this interface optional, but I think contract with container itself is not very usefull for domain object.

    "3" Base class is not broken too, if it is used with "2" then I see no problems, it is very common too, see servlets, portlets, applets, but I do not know how it can be usefull for entities or structs.

    "5." Is a good way too, it helps to reuse code as "aspect" as audit for entities, it can work as dynamic interceptor for session beans, it is possible to design j2ee framework itself this way and to let register custom "aspect" too. As I understant container implementations use it anyway ( it is clear from stack traces ).

    Hibernate supports both ways (2 and 3 is the same), IoC frameworks use both ways too, it works, but I can say nothink good about 1,4.
  7. Comments[ Go to top ]

    A couple of comments:

    - All the whining about having empty implementations of methods because there is only one interface (i.e. SessionBean), rather than an interface per method (i.e. ejbRemovable, ejbActivatable, ejbPassivatable, etc.) is a little bit ludicrous. The people that actually make use of most of the defined methods could just as easily argue that they shouldn't have to implement three interfaces, rather than just one.

    - Options 2 and 3 are more complementary than exclusive. It is very easy to provide an interface, as well as a default empty implementation for those who want it, a la MouseListener / MouseAdapter.

    - The serious contenders seem to me to be 1, (2 + 3) and 4. Magic callbacks are only a serious contender in my mind because that's what was in the draft spec. Otherwise, I don't know why you would pick it. Magic callbacks are something of a midpoint between interfaces / base classes and annotations. The draft spec says they want to move away from explicit dependencies on the container (interfaces / base classes) and torward POJOs with annotations that have meaning only within the context of the container. That being the direction, my money is on annotations.
  8. Given that all options are valid but with different pros and cons, something that might help choosing the best one is defining the main goals of this specification. Like:
    - dependency on the container: which solution would free us to use POJOs, with no (or the fewer) dependencies on the container?
    - container/component simplicity: which solution would result into better, faster and simpler containers/components? It would make it easier to build both servers and systems, with focus on component simplicity over container simplicity, in an either/or situation.

    These are the first ones that came to my head, maybe there are more (or different) goals that could help choosing the best solution.

    IMHO, solutions 4 and 5 seem to be the best ones in light of above goals. One question though is if annotated POJOs can still be considered POJOs...

    Henrique Steckelberg
  9. Greetings,

    I think that specification should require only second section (2. Interfaces), rest of that list should not be part of the EJB 3.0 specification.

    Java is OOP language, so let's stick to that. IDEs become very smart these days. They can generate method templates for you, they can write code for you, they can hide part of code from you. In my opinion, annotations should be only used by IDEs, code generators or deployment tools to simplify/speed-up coding.


  10. Annotation is a good feature, but not to replace interface, both add dependancy on container in the same way, contract by method name is nothing better too. If you need contract then it must be clear (interface), if this contract is useless then drop it without workarounds and compromises.
  11. Annotations serve a very good alternative to the messy Deployment XMLs of EJB2x-- days. Now extending Annotations to play the role of an Interface or a Base class is really asking for too much. And as a biz programming paradigm has all the trappings relating to code readability/maintanability from using AOP. This should strictly be avoided in EJB3.

    The Base class offers avery good solution to having mostly unused template code in EJB2x beans. Supporting interface for backward compatibility and allowing base class for cleaner app code seems like the best approach.

    Fortunately, POJO testing hasnt been played down in this thread. Always felt building generic handling for POJO testability was complicating the platform too much. Instead of simplifying current pain points such as deployment XMLs and template code, to support testability we are creating a parallel programming environment (unintuitively and more complex!) in the annotations!

  12. If you write "real" code first, test it and generate wrappers for EJB contracts later then you do not need to test wrapper generated by tool (it is a good way for many reasons, testability is one of them ). There is no meanings to add some limitations for testability, it is not a problem.
  13. Callbacks are around from C era.

    Why in the first place it was removed in Java, thats a big question. Introduction of Interfaces, provides a structured way, but it's no always required, smart people always have backup.

    Introduce Delegate pattern, as in .Net.

    Callbacks using interfaces is second to delegate in performance.

    All 5 methods are kind of work arounds.
  14. It is classic Observer design pattern, Observer is language feature in C# like decorator design pattern is language feature in AOP.
    Observer is usefull, but it is not motyvated for this uses case ( component life cycle callback ), it can be usefull if you want to be notified about container events ( "container.addListener( this ) " ), but there is no meaning to use it for component itself.
    BTW almost everything in JAVA is from C era and it was one of JAVA design goals ("stripped C++").
  15. "there is no meaning to use it for component itself"
    Sorry, I will corect it myself, Observer is good design pattern for components, but entity is not a component.
  16. Callbacks are around from C era.
    That doesn't make them bad.
    Callbacks using interfaces is second to delegate in performance.
    Raw performance probably, scalability no. Consider multiple N-way SMP machines with tens of thousands of simultaneously active "sessions".
  17. Tom,

    N-Way SMP, Callback doesnot scale ?

    How can you say that?

    We are talking about ejb callback not ejb's.

    Callback happens to something that is stateful, its not stateless callback. Stateless callback doesnot mean anything, callback to whom?

    And Java dropped callback on interfaces, i guess it went too forward. If someone is pragmattic they would keep both features.

    Now there can be whole lot more, to argue,if we take multiple inheritance, inner classes etc. I would say java made it simple. By removing callback it simply cut back on its own ability, it serves no purpose, *it doesnot simplify*, it simply makes us to go one way --- interface, way , and then we have to introduce this kind of work arounds and vote on it. Its kinda silly.
  18. Tom, N-Way SMP, Callback doesnot scale ?How can you say that?
    Misunderstanding. I believe you were saying that delegate was more efficient than callback. I was trying to say that callback scales *better* than naive delegation.

    I note that "stateful" and "stateless" are somewhat ambiguous terms; it is necessary to define the context in which the "state" is being defined. Sometimes "stateless callback" is appropriate, particularly when considering failure containment and recovery.

    Other computational domains have, over the decades, had to deal with similar issues to the ones being considered here. They have solved the issues in a variety of ways, with a variety of tradeoffs. We should learn from previous experience, of course. One of the aspects of Java that really impressed me (when I first looked at it) is that there's nothing new in Java; it has simply reused a set of concepts developed in other languages and environment. The key thing is that it is a harmonious set of powerful, orthogonal concepts.

    We should, of course, try to learn from the experience of the other conmputational domains.
  19. Callbacks are around from C era.Why in the first place it was removed in Java, thats a big question.
    James Gosling doesn't like them:
    Introduce Delegate pattern, as in .Net.
    Microsoft han an different opinion:
  20. This is what James says why sun dropped delegates.

    Our conclusion was that bound method references are unnecessary and detrimental to the language. This decision was made in consultation with Borland International, who had previous experience with bound method references in Delphi Object Pascal.

    We believe bound method references are unnecessary because another design alternative, inner classes, provides equal or superior functionality. In particular, inner classes fully support the requirements of user-interface event handling, and have been used to implement a user-interface API at least as comprehensive as the Windows Foundation Classes.

    Now if you see this is purely a reaction, its not an inovation. You do dirty stuff, we do neat stuff. Thats hurting platform. Java is not only the language. J2ee runs with in java's limit, and j2ee is distributed computing platform. Java should have all features that are required in distributed computing. Java should not exclude some features based on GUI event handling and stuff.
  21. Are annotations "not breakable"?[ Go to top ]

    I'm still an annotations novice... maybe somebody answer this for me...

    Can you enforce that an annotation can only be applied to a method with a *specific* signature?

    Can you prevent 2 of the same annotations being applied to different methods?

    Both seem necessary here, otherwise the annotations option still seems "breakable" if you incorrectly apply your annotations.

  22. Are annotations "not breakable"?[ Go to top ]

    I'm still an annotations novice... maybe somebody answer this for me...Can you enforce that an annotation can only be applied to a method with a *specific* signature? Can you prevent 2 of the same annotations being applied to different methods?Both seem necessary here, otherwise the annotations option still seems "breakable" if you incorrectly apply your annotations.-Tim.

    IMHO, annotations are a bad choice for EJB 3, precisely because of the above points. Annotations are too immature to become part of an evolving spec right now. May be EJB 4 or EJB 5 should see it. As somebody already pointed out (and consider this my humble request too) - Please do not overdesign EJB 3, please.

    My vote goes to (2 + 3), but with more fine grained interfaces than we had in the earlier EJB spec. I like the 'new life' approach.

  23. Are annotations "not breakable"?[ Go to top ]

    I'm still an annotations novice... maybe somebody answer this for me...Can you enforce that an annotation can only be applied to a method with a *specific* signature? Can you prevent 2 of the same annotations being applied to different methods?Both seem necessary here, otherwise the annotations option still seems "breakable" if you incorrectly apply your annotations.-Tim.
    NOBODY ANSWERED THIS. IMHO, annotations are a bad choice for EJB 3, precisely because of the above points. Annotations are too immature to become part of an evolving spec right now. May be EJB 4 or EJB 5 should see it. As somebody already pointed out (and consider this my humble request too) - Please do not overdesign EJB 3, please. My vote goes to (2 + 3), but with more fine grained interfaces than we had in the earlier EJB spec. I like the 'new life' approach.Thanks, aXe!
    JDK 1.5 does include a very useful tool (apt - Annotation Processing Tool) that enables you to do more complex semantic checks of annotations and their usage context as well as code generation driven by annotations.

    With this tool, it is possible to give compile-time errors based upon invalid annotation usage that are every bit as descriptive (file/line #/descriptive text, etc) as those generated by javac for standard java syntax errors.

    See http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html for more details.

    -- Kyle
  24. EJB 3 callbacks: Feedback wanted[ Go to top ]


    To me number 5 seems to be the best. It gives the flexibility to use another class to listen for events, but It allows a developer to say that the EJB itself is going to be the listener. So developers that like to address cross cutting concerns in a few utility classes can put their callback logic in the utility classes and register them as listeners. While developers that like to have their call back logic in their beans can make the beans listeners. The cool thing about this is that developers would be able to add listeners for only the callbacks they were interested in. This would mean that an inheritance structure of listener interfaces would need to be developed, that would contain different types of listeners, similar to the swing callback mechanism for events.

    We could have an interface for a certain callback that is implemented by an abstract adapter. Developers could either extend the adapter for that event interface (so they wouldn't have to implement all of the methods) or they could implement the interface(if they wanted to extend something else).

    We would be able to achieve all of the positive aspects of 2, 3, and 5.

    I agree with annotations, I think that after developers get their head wrapped around annotations, they will be everywhere. I think there should be support for them, but maybe only in the EJB, not in a pojo. I can’t think of a way to annotate a pojo and add it as a listener without violating type safety. So I would support annotations, but only in the EJB themselves. Then under the covers (not seen to the developers), when the annotation runs, we can automatically make the EJB a listener for whatever the annotation is and then using our derived callback in the interface, we can call the method that had the original annotation. With the annotations working, we could have 2-5 working excluding Magic Callbacks.

    I agree with the comments that developers will type the wrong magic callback and then spend hours wondering why their callback didn't work. That is the only one that I really disagreed with.

    Jay :)
  25. #5 event-listener[ Go to top ]

    I vote for #5 and had a comment here http://jroller.com/page/javay/20040810#re_ejb_3_callbacks

    #5 is not uglier than others.
  26. EJB 3 callbacks: Feedback wanted[ Go to top ]

    1: no. I don't like "magic"; it discourages understanding by concealment

    2+3: OK, smiilar to Swing's XListener and XAdaptor pairs

    4: I'm suspicious. Annotations are currently fashionable/sexy, and they could do the job. But that doesn't make them the right tool for the job. (Yes, istis possible to go across the Alps in a child's pedal car...)

    5: OK. Well proven in other fields where performance, scalability and openess is important (e.g. core telecoms network call processing). Does require extra work from implementor, so it is well worth providing a canned solution that is sufficient for 80% of the cases, while leavin it possible for the 20% to be coded specially.

    On balance, I have a preference 5.
  27. No magic methods, please[ Go to top ]

    Magic methods are the worst. They cannot be checked by compiler. IDE cannot learn about them by simply checking "import" section, it should know about all versions of EJB spec.

    Annotations are the second worst. Whatever you say, I do not like them.

    So, my preference order: 2, 3, 5. Base class is not that bad, if interface is supplied as well. This way a developer can choose either to extend an existing class and to override only the needed methods, or to extend some other class and to implement an interface. So, 2 and 3 should be packaged together.
  28. No magic methods, please[ Go to top ]

    Annotations are the second worst.
    Whatever you say, I do not like them.
    Oh well.

  29. Oh, well[ Go to top ]

    Annotations are the second worst.
    Whatever you say, I do not like them.
    Oh well.-- Cedric
    Well, maybe I overreacted :) Truly, I do not know MUCH about annotations ;) but then again: what is the difference between a method marked with @callback annotation and a pointer to a method? That you cannot point to a non-marked method? Is it a real benefit? Maybe instead of using annotations to create callbacks, Java can finally pull this feature from C++ or Object Pascal?
  30. EJB 3 callbacks: Feedback wanted[ Go to top ]

    For non-entity beans, I vote for both 2 & 3. IMO, #3 is the simplest solution. But we should include #2 in case people want to retrofit an existing class to create ejb.

    The #5 for entity bean sounds good, but demands more thoughts as it's really a complex issue.

    However, I feel we have to do more work on selecting the right callback methods for each type of beans rather than simply taking it from ejb2.x
  31. EJB 3 callbacks: Feedback wanted[ Go to top ]


    I'd favor interfaces (2) over annotations (5), and do not like the other options at all.

    The downside of the interfaces option you listed disappears if you consider to design those interfaces as lean as possible. We already discussed the option of fine grained callback interfaces, remember?

    IMHO, semantically there is no real difference between the option (2) and option (4), but I guess that most Java developers will feel more at ease using interfaces as they already know this technique.

    Using a combination of both options (2) and (4) will force you to introduce rules of precedence into the spec, which will complicate matters quite a lot. So whatever you decide, choose wisely, and choose only one option. Please do not overengineer EJB3, we had enough of this already. Less is more.

  32. Cedric, I'd favor interfaces (2) over annotations (5), [...]
    Too early, need coffee. Make that half-sentence:
    "Cedric, I'd favor interfaces (2) over annotations (4), [...]"

  33. other aspects[ Go to top ]

    Persistence is not the only aspect, that affects those POJOs. There are other aspects like deferred validation / undo management / whatever, that cooperate with the EntityManager and might introduce callbacks as well.

    The ValidationManager might register itself with the EntityManager as a listener. Validation cannot be performed by the POJO itself, as the constraints could be time variant (n'th step in a workflow). Thus validation by its nature is something, that is affecting the POJOs from outside.

    If there where callback methods in the POJO, I had to call the ValidationManager from every POJO, making it dependant on the ValidationManager.

    I vote for number 5
  34. EJB 3 callbacks: Feedback wanted[ Go to top ]

    My preference is #2.

    Callback methods and specially those implemented via Observer desing pattern
    are quite dangerous in case of of ordinary classes but in case of components
    when precise contracts are importand they must be really implemnted very, very carfully and it is probably better to avoid them when possible.

    This is well explained in "Beyond Object-Oriented Programming"
    and very briefly resumed here http://www.cs.kuleuven.ac.be/~eddy/Szyperski.html

    So what Cedric is saying is either not so true in case of componets:
    Exploits well-known event listener paradigm.
    or far more serious then that:
    Not object-oriented (code outside POJO affects POJO).
    "Magic callbacks" and such will-nilly contracts are imo not quite serious.

  35. This is well explained in "Beyond Object-Oriented Programming"and very briefly resumed here http://www.cs.kuleuven.ac.be/~eddy/Szyperski.htmlSo what
    Thanks, I found it very brief and clear too.
  36. I think that if the EJB3 EG wants to continue with the idea that this is "persisting POJOs", the only option is 5, using a callback.

    Option 1, using magic method names, is just braindead as the developer will have no idea until runtime if it's even vaguely correct. There's no chance for compiler assistance, for example, to let him or her know that they mistyped the method name.

    Option 3 pushes into the object model in a very intrusive way, and certainly makes a mess if you have existing POJOs you want to reuse as-is.

    I think that option 4 is a little like option 2, except that annotations are a brand new technology for which there is no understanding of good practice and patterns in the Java community and further allows awful things like annotating the wrong or a misleading method, like indicating you want init() called on removal. It also removes the POJO-ness of the POJO, as adding annotations now makes the code for the POJO tailored to the container (and thus a component). What would help is collaboration between the various persistence efforts in Java to standardize on annotations for common functionality.

    Option 2 is better than 4 because I think that interfaces are pretty will understood at this point, but it also removes the POJO-ness and is hard for existing code you wish to persist. For performance reasons, you want more than 1 interface to ensure that a developer isn't forced to implement onRemove() as a empty method, killing the chance for performant bulk deletes, as all objects would have to be instantiated and onRemove() invoked, rather than just deleting.

    Option 5, IMO, is the only one that's consistent with the idea that you are persisting PLAIN OLD Java objects, because you don't need to modify the POJO source to use or reuse in the persistence framework, and allows you to use existing POJOs. Every other option is just a different way of creating a component, and not a POJO. I also don't worry about the concern that "it's not OO" , because you aren't violating the encapsulation of the object, and the notion of lifecycle is outside of the concern of the POJO (because it's a POJO!).

    My $0.02

  37. Yes, I think 5 is a good one, there is nothing bad in 2 too, but it is not usefull.
    BTW this kind of callback exists in JTA, it is TranastionSynchronization, Statefull bean can be a transaction listener. EntityManager can register callbacks too, it can be the same as Hibernate interceptor, it is a good feature.
    BTW do not confuse entities and components, entity is not a component EntityManager is.
  38. No Magic Please, We're British[ Go to top ]

    First of all, No Magic Methods, Please!

    I wonder where this idea ever came from. Horrible.


    1) Magic methods
    No, no, NO! Nooooooooo!

    2) Interface
    It works, it's pure, it's beautiful. You might want to "fine-grain" your interfaces a bit (like in "a new life for EJB's"..). But not too much.

    3) Base class
    Only as a utility in addition to (2).

    4) Annotations
    Hmm.. I really don't like this. I'm afraid that this great concept will be terribly abused in the industry.. I definitely don't want to have deployment descriptors inside the code. But I give this a "maybe"..

    5) Manager callbacks
    Only for entities. And why even for them?

    I agree with a previous poster, that all the "auto-magic wizardry" should be left to the tools, IDE's etc.

    Long live EJB's :)

  39. EJB 3 callbacks: Feedback wanted[ Go to top ]


    I've written a fair number of EJB's and I can't remember all that many times that I have needed to put something in the callback. Normally I've just had a bunch of empty methods sitting at the bottom of my bean file. Putting stuff in the callbacks is overidding the default behaviour and normal usage of that functionality so I dont see why it should be manadated for a bean to implement them as it is with the interface approach.

    The Base class is probabaly the solution most people are using these days with 2.1 but I dont agree with having to extend something in order to get default behaviour.

    As for magic methods I'm not that keen on them. I've made the occasional error with get and set in Struts forms where I've neglected one or other, it will be far worse with ejbs. I hate discovering this kind of thing at runtime. (Hmm makes me think, isn't the java bean an extreme example of magic methods, and its been so useful??)

    The annotation option really doesn't seem any different to a magic method to me. OK so the @remove would be checked but its still seems like you are putting an application together with sticky tape.

    My Vote is for #5 it is the only one that leaves you with clean pojos. Would the registration be moved into an anotation/deployment descriptor?

  40. One way or the other...[ Go to top ]

    It seems to me (IMHO) that the goal of the EJB 3.0 spec is to push the development of EJBs back towards the simpler style of writing POJOs. I think this is a good idea, but as long as these POJOs are only going to have meaning in a given container, i think that by itself implies a dependency that escapes the goal.

    I have never transfered an entire application object set from one container to the other, JBoss only ;), but those of you that can attest with the experience of going from BEA to IBM and back to JBoss might have some added information on that.

    My conclusion is: since the beans are dependent upon the container, the code that represents the callbacks, and bean lifecycle, should not be tied to the native java code with new grammar. AKA - NO MAGIC call backs.
    1. OPPOSED
    2 GOOD b/c it is explicit, which is more like Java than annotations or magic anything.
    3. would be fine, but definitely does not seem like the best option
    4. GOOD - it is fine to annotate, but i agree that it is as much a problem as new reserve words, b/c the annotations are usually as breakable as any magic callback might be.
    5. Not enough experience in managing the development of event listener paradigm for good feedback.
  41. EJB 3 callbacks: Feedback wanted[ Go to top ]

    I vote for option 2 + utility option 3...

    Magic callbacks just sound dangerous:(

    The drawbacks of option 2 are clearly and cleanly address by having a base class. In fact, I having been using such base classes and they work quite well.

    Just option 3 is too limiting...

    Option 4 with annotations is interesting. However, overkill in this case because the code is made non-standard and more work for the application server.

    Option 5 is very powerful. I do see the advantage that the callbacks are removed from the component. However, it is just one more level of indirection:) [All problems can be solved with one more level of indirection:]. Now, same issue has moved to the Listeners (and Adapters). Again option 2 and option 3 have to applied there. Plus, something has to be provided to register the listeners such as EntityManager. For Session Beans, some other class need to be created such as SessionManager. Due to slight complexity, I vote against this option.

    Best regards...
  42. Interfaces are easy[ Go to top ]

    Interfaces are natural for java developers (and IDE's) to understand and use.

    One idea I haven't seen would be to keep the current 2.x aggregated callback interface but change it to extend from new individual callback interfaces so a developer would have the choce to use the aggregate, or one or more of the individual interfaces.

    + No base class required, interfaces are easy to understand, no unused callback implementations (although I always saw this as a minor issue).
    - Adding bloat to J2EE; more interfaces? But it doesn't increase the cost of understanding something new - Like the entity manager or annotations.

    Don't know enough about annotations to know if they'd be perfect for this application or if they are the wrong tool for the job.

    The magic callbacks have some appeal to me only in the sense that I wouldn't have to import J2EE specific interfaces, just implement my class a certain way. But maybe that isn't worth the downsides.
  43. EJB 3 callbacks: Feedback wanted[ Go to top ]

    Clean, well separated interfaces, like Spring, XWork, new life for EJB, and many others have shown, is to me, the best solution.

    #1: is a flawed contract. would you trust in developers? I won't. In some hidden place of our pride, we are still humans.
    #3: Single Inheritance is not an option. Come on, you can do better than this.
    #4: I find annotations a mischievous trick from the JCP to ease the coding of EJB. I won't introduce a new technology to fix a problem just because i wan't able to figure it out how to solve it with all the tools i have in hand. That's an easy way out, and to me, a bad solution that breaks ups compatibility with not a single benefit. XDoclet is by far a better solution. Just because EJB is the star of the J2EE fleet is not an excuse to come up with this kind of "solutions", which, at the end, give nothing new, and introduce complexity.
    Keep it simple.
    #5: i give this approach a partial vote. Lifecycle for a EJB is a different concern, it could be clearly separated into an event listener approach. The document href="https://www.theserverside.com/news/thread.tss?thread_id=27841 New Life for EJB have some interesting insights on this.

    Fernando Racca
  44. EJB 3 callbacks: Feedback wanted[ Go to top ]

    My vote is 2+3, for pretty much the same reasons as everyone else that voted that way. Maybe subdividing the interfaces would be useful, to split off rarely used methods like ejbActivate() and ejbPassivate(), but "one method per interface" would be stupid. No more than two interfaces would be my suggestion.

    #5 might interesting, if done well, or a disaster if done badly. I'd have to see a more detailed proposal before I consider it.

    #1 is terrible. IMHO, the "magic methods" in the current EJB standard like ejbCreate() are one of the major sources of confusion and error; adding more is a bad idea. #4 is not much better.

    If the standard did use magic methods, the first thing I would do is define a utility interface equivalent to #2, the same way I defined a utility class equivalent to #3 for the older EJB standard. It would be nicer, though, if these were in the spec.
  45. EJB 3 callbacks: Feedback wanted[ Go to top ]

    ..but "one method per interface" would be stupid..
    I don't see why it is stupid? Some interfaces have no methods at all(Serializable) and are very handy. If the four or so callback methods are truely separate concepts then a separate interface for each would be ok with one aggregate.

    Again, the aggregate alone hasn't been too much trouble anyway. Not like they are eating away at performance or anything. Having those empty methods also helps a bit in reminding EJB developers to think about life cycle events.

    As I said in a previous post, interfaces are easy and understood by most of the java developer population. That's why it gets my vote.

    One question, would the developer have to implement the interface if no callback methods were going to be implemented? Could it still be an EJB if it is just a POJO in EJB3?
  46. EJB 3 callbacks: Feedback wanted[ Go to top ]

    Im surprised Bill, Cameron and Gavin haven't posted to this Thread. Guys what are your thought on this?
  47. EJB 3 callbacks: Feedback wanted[ Go to top ]

    Im surprised Bill, Cameron and Gavin haven't posted to this Thread. Guys what are your thought on this?
    They'd prefer magic methods and annotations, but are afraid to say so. ;-)