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?
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
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.
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,
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.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.