Ejb 2.0?

David Hoag
2002-05-07
2002-05-09
  • David Hoag
    David Hoag
    2002-05-07

    With EJB 2.0 J2EE servers can finally have effective, high performance persistence. JGrinder could become a J2EE, EJB 2.0 CMP solution without requireing too much work. Is this something worth pursuing?
    Or should JGrinder focus more attention on non-j2ee applications. For example, reduction of the 'intrusiveness' has been suggested. Any thoughts?

     
    • Calvin Loh
      Calvin Loh
      2002-05-08

      Don't most J2EE servers have their own
      persistence frameworks/tools bundled in?

      Or are you saying that JGrinder cannot
      currently support JSPs/Servlets?

      Unless the above is the case, I would
      prefer to reduce the intrusiveness. A
      recent discussion at theserverside
      threw up several different kinds of
      intrusiveness (byte code modification,
      table modification, source code
      modification, etc).

      Of course, lazy dog that I am, my first
      preference is always to improve the
      existing documentation - especially of the
      various code generators :)

      Another option is to make JGrinder
      compliant with the new Sun JDO specs.

       
    • David Hoag
      David Hoag
      2002-05-08

      JGrinder, as is, works in any java application - J2EE, JSP, anything. By conforming to the J2EE EJB 2.0 spec you could us JGrinder in a way that would allow one to switch from a JSP implementation to a J2EE implementation without extensive code modification.
      Additionally, JGrinder would be a CMP like solution that would not be specific to any app server, providing app server independence.

      I saw the discussion on intrusiveness. With a couple of simple strategies, you could greatly reduce the instrusive of JGrinder as it is currently implemented. For exapmle, instead of extending DomainObject, go the other route. Create subclasses of your 'clean' objects that actually define implement the Persistence interface. Simply override the get and set methods, duplicate the initializeXXX methods in each subclass, and Voila - clean, non intrusive implementation. Perhaps I should create an example detailing this strategy.

      Of course, documentation is always nice to have - by the way, did you know any one can submit documentation on SourceForge? :)

      As far as JDO goes, well, I'm going to wait and see what type of traction it gets. Sun seems to be backing off from JDO, and to date none of my clients have requested this capability.

      Thanks for the feedback,
      - Dave

       
    • Calvin Loh
      Calvin Loh
      2002-05-09

      I can probably put up a simple tutorial
      (on using JGrinder with MySQL, with some
      other field other than DATABASEIDENTIFIER
      as the PK) by the end of next week.

      But I wanted to consolidate a few other
      things first, such as using the code
      generators, as well as experiment with
      FK and aggregates when DATABASEIDENTIFIER is
      not the PK.