Hi again Robert,
Robert Simmons wrote:
Interesting your replies. I actually looked at OJB in consideration of a
book I am working on in which I use JDO. What I donate want to have to do is
allot of complex configuration and initialization to get it to work.
Although I am interested in writing JDO code, at this moment I'm a pure
user. In the end, I opted to use a commercial product that I could basically
just drop into my JBoss directory and have it magically go. I had to edit
one properties file and I was off and running.
with OJB you'll have to deploy some jars and two config files. Sounds
not that difficult for me.
So with OJB there are two possibilities.
1) It has this ability but the documentation is cryptic enough to not be
easily locatable.
2) It doesn't have this ability.
Mhh, our latest release contains a tutorial JDO application. It can be
set up with two simple steps.
The setup is documented in the tutorial4.html document.
Other issues:
A) When I deploy a JDO broker, I want it to use JCA to connect to my
application server. I don't believe OJB does this.
OJB *does* support JCA, JTA, JNDI, EJB and every other relevant J2EE spec.
B) I donate believe OJB is fully JDO spec compliant (correct me if I'm
wrong)
As the OjbStore Storemanager is implemented as a plugin to the JDO
reference implementation, the JDO compliance is maintained by the JDO
RI, not by OJB! AFAIK the JDO RI is fully JDO 1.0 compliant.
C) When I deploy the broker, I donate want to muddle my classloader up with
5 classes I will never use. If there was a way to build OJB stripped of
all the ODMG mapping stuff, it might be more appealing to me.
The ODMG layer consists of 59 classes. If you don't access those classes
a good classloader won't load them.
But it's of course possible to remove the org.apache.ojb.odmg packages
from the OJB jar!
Currently as it is, OJB is not going to attract the freewheeling JDO
*USER*.
This is where the gravy lies. Without the user base, there
is no product. Either they need to change the documentation or change the
product.
Ojb has a large and growing user base. OJB is a mature product. A full
JDO implementation is in the scope of the 2.0 release.
Ojb already provides a fully compliant JDO solution with JDO RI plugin.
This solution is documented and can be easily configured.
Until I finish my book, however, I am a pure end user and cannot be
concerned with the complexities of layering and architecture. I want to
configure the broker, run an ant task to enhance the classes and sprint off
to the races.
After reading through the first section of my JDO tutorial you will see
how this can be done with OJB.
IMO further questions regarding OJB should be discussed on the OJB user
mailing list.
cheers,
Thomas
-- Derisor
- Original Message -
From: Mahler Thomas [EMAIL PROTECTED]
To: 'Jakarta General List' [EMAIL PROTECTED]
Sent: Tuesday, January 21, 2003 5:05 PM
Subject: AW: Light Weight JDO Implementation?
Hi Robert,
Greetings,
I was wondering if there was a JDO implementation in the
planning stages.
OJB provides a plugin to the JDO reference implementation. By using this
plugin you can write JDO compliant applications running against the OJB O/R
mapping.
See here for a sample application:
http://jakarta.apache.org/ojb/tutorial4.html.
The OJB projects is also planning to provide a clean room JDO transaction
manager on top of the existing OJB layers.
I know, you are probably going to answer, Go look at OJB.
However, to face reality, OJB was started and an OMG data
mapping implementation.
That's not correct. OJB started to write a generic O/R mapping tool that
provides multiple personalities or APIs.
It is far too big to be warped into a
world class JDO implementation.
Not correct. Have a look at my OjbStore Plugin. It consists of 5 classes and
1 exception!
And still provides full JDO functionality (by pluggin into JDORI)!
The code volume alone is
rather staggering.
not correct. It has a cleanly designed layering. It is designed to build
high level transaction managers like ODMG and JDO on top of its core API.
It was build with JDO in mind! The existing ODMG layer is in fact quite
thin!
Hence the reason I suggest that Jakarta
start a project into developing a clean, fast, and
über-compliant JDO implementation.
Id rather suggest to join efforts with the OJB team. We have even started to
talk with SUNs JDO team to join efforts...
cheers,
Thomas
Thoughts?
-- Derisor
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
