objectbridge-jdo-dev — OJB JDO developer list

[Objectbridge-jdo-dev] RE: JDO compliant object/relational mapping

[Mahler T. <tho...@it...>]

Hi Rong,

thanks for your offer to help!

Rong Sang wrote:
>Hi, there. I noticed your group is looking for some java 
>developers. I'm interested in the opportunity.

great!

>I've worked using Java for more than three years. I used 
>c/c++ before jumping to Java. I had a good understanding of 
>OOD, UML and design patterns. Particularly JDO is one of my 
>favorite projects that I'd like to put my hands on.

>However, I don't have any open source development 
>experience. I don't know how much effort needs to be put in 
>by everyone. However, if by any chance I can help, I am 
>glad to do so. Also I think I will learn a lot from other 
>team members. Please explain your management style and team 
>members' responsibility at your convenience. Thanks.

>I look forward to hearing from you soon.

>Rong

We have not yet started designing or coding. We are currently beginning to
organize the work and to discuss design issues and other stuff.

an archive of the objectbridge-jdo-dev discussionlist can be found here:
http://www.geocrawler.com/lists/3/SourceForge/18443/0/

You should register to  the objectbridge-jdo-dev discussionlist here:
http://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev

The work is coordinated through this list. Currently there is not that much
traffic as we are not yet that organized...

To get started you should read my proposal:
http://objectbridge.sourceforge.net/jdo/jdo-proposal.html,
study the JDO specification and 
study the architecture of the OJB ODMG implementation.

that's all for the moment!

cu,

Thomas 

AW: [Objectbridge-jdo-dev] Re: Objectbridge-jdo-dev digest, Vol 1 #5 - 3 msgs

[Mahler T. <tho...@it...>]

> -----Urspr=FCngliche Nachricht-----
> Von: Lu Xun [mailto:fas...@eu...]
> Gesendet: Donnerstag, 10. Januar 2002 23:48
> An: obj...@li...
> Betreff: [Objectbridge-jdo-dev] Re: Objectbridge-jdo-dev digest, Vol =
1
> #5 - 3 msgs
>=20
>=20
> I have not finished reading the JDO spec yet but have a question:
>=20
> JDO requires that each persistable class implement the=20
> IPersistable interface.=20

The JDO name for this interface is "PersistenceCapable"

>As Thomas points out, this seems to=20
> be quite a burden.  When my colleague and I were evaluating=20
> different OR mapping solutions, we like the style of=20
> ObjectBridge: no specific requirement for the persistable=20
> class.  We especially did not like the idea of having some=20
> tool alter the class file to make it persistable as this will=20
> make debugging a lot more difficult.
>

Commercial products like TOPLink also don't require persistent classes =
to
implement a special interface!
=20
> However, since the JDO spec made such a decision, I think=20
> they must have their reasons.  Does any one know the story=20
> behind it? =20
> I think this is a huge difference between the=20
> architecture of a normal JDO implementation and OJB, although=20
> we can probably put a layer on top on OJB to make it look=20
> like JDO.  However, is there anything fundamental that we are=20
> missing from OJB by not having something like IPersistable?
>=20

The comment in interface PersistenceCapable explains it's =
responsibilities:
/**
 * A class that can be managed by a JDO implementation.
 *
 * <P>Every class whose instances can be managed by a JDO =
PersistenceManager
must=20
 * implement the PersistenceCapable interface.
 *
 * <P>This interface defines methods that allow the implementation to =
manage
 * the instances.  It also defines methods that allow a JDO aware
 * application to examine the runtime state of instances.  For example,
 * an application can discover whether the instance is persistent,
transactional,
 * dirty, new, or deleted; and to get its associated
 * PersistenceManager if it has one.
...

There is an interesting remark in the JDO spec. regarding the design
decision to have a PersistenceCapable interface.
It can be found in appendix B2, page 153 f.
It goes like follows:

"B.2 PersistenceCapable
The PersistenceCapable interface could be eliminated entirely in favor =
of
having all inter-rogatives
operate via the PersistenceManager, not directly on the JDO instance. =
This
would make the JDO instance entirely user-written. However, the impact =
would
be that in
order to find out which PersistenceManager, if any, was responsible for =
the
JDO instance,
a new singleton would have to be provided. The singleton would have to
register all Per-sistenceManager
instances and ask each if it managed a specific JDO instance.
This was deemed too complex to manage, as well as too slow to find =
simple
information
that should be easily available."

The current OJB-ODMG implementation uses the mentioned approach to do
everything done through a PersistenceManager.
I don't believe that we are loosing anything by this approach. I also =
don't
believe that it is that complex to navigate to all neccessary =
information in
our approach.

To be JDO compliant we will of course have to use the =
PersistenceCapable way
of life.
But I suggest that we are not doomed to bytecode modification.
As the JavaDoc comment of the interface PersistenceCapable clearly =
states:
=20
 * <P>In the Reference Implementation, the JDO Enhancer modifies the =
class
 * to implement PersistenceCapable prior to loading the class into the
runtime
 * environment.  The Reference Enhancer also adds code to implement the
 * methods defined by PersistenceCapable.
 *
 *<P>The extra methods in the PersistenceCapable interface might be
generated
 * by pre-processing a .java file, or might be generated from a tool
directly.
 * The exact technique for generating the extra methods is not =
specified by
 * JDO.

So we can "inject" the necessary code also with a pre- or =
postprocessor,
force the user to code it manually or provide a transparent wrapper
mechanism similar to the ojb.odmg.ObjectEnvelope idea...

cu,

Thomas


> Cheers
>=20
> Faster
> =20
=20

[Objectbridge-jdo-dev] Re: Objectbridge-jdo-dev digest, Vol 1 #5 - 3 msgs

[Lu X. <fas...@eu...>]

I have not finished reading the JDO spec yet but have a question:

JDO requires that each persistable class implement the IPersistable interface. As Thomas points out, this seems to be quite a burden.  When my colleague and I were evaluating different OR mapping solutions, we like the style of ObjectBridge: no specific requirement for the persistable class.  We especially did not like the idea of having some tool alter the class file to make it persistable as this will make debugging a lot more difficult.

However, since the JDO spec made such a decision, I think they must have their reasons.  Does any one know the story behind it?  I think this is a huge difference between the architecture of a normal JDO implementation and OJB, although we can probably put a layer on top on OJB to make it look like JDO.  However, is there anything fundamental that we are missing from OJB by not having something like IPersistable?

Cheers

Faster
 
--

On Wed, 09 Jan 2002 12:25:11   objectbridge-jdo-dev-request wrote:
>Send Objectbridge-jdo-dev mailing list submissions to
>	obj...@li...
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
>or, via email, send a message with subject or body 'help' to
>	obj...@li...
>
>You can reach the person managing the list at
>	obj...@li...
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Objectbridge-jdo-dev digest..."
>
>
>Today's Topics:
>
>   1. let's go ! (Mahler Thomas)
>   2. Re: let's go ! (Christian Sell)
>   3. Re: let's go ! (Thomas Mahler)
>
>--__--__--
>
>Message: 1
>From: Mahler Thomas <tho...@it...>
>To: "Jdo-Dev (E-Mail)" <obj...@li...>
>Date: Wed, 9 Jan 2002 15:11:43 +0100 
>Subject: [Objectbridge-jdo-dev] let's go !
>
>This message is in MIME format. Since your mail reader does not understand
>this format, some or all of this message may not be legible.
>
>------_=_NextPart_000_01C19917.90F3AA30
>Content-Type: text/plain;
>	charset="iso-8859-1"
>
>Hi all,
>
>I just had a look at the subcription list of the jdo-dev mailing list. I was
>quite impressed: there are already 19 registered subscribers!
>
>That should be enough to get started.
>
>How to start?
>
>First of all I want to invite you to comment on my proposal.
>
>A. Strategy
>
>1. I am proposing to start with a rapid prototype to get a feeling what
>implementing JDO based on the PersistenceBroker kernel is all about. We can
>try to reuse things from the ODMG implementation (e.g LockManagement or
>state transition).
>
>2. factor out all things that the JDO and the ODMG implementation have in
>common and put it in a separate package ojb.otm.
>
>3. refactor the JDO and the ODMG implementations to use the OTM internally.
>
>I believe this implementation strategy will reduce risks and allow to get
>first results quickly.
>What do you think? 
>
>If there are no objections we should fix this as our chosen strategy.
>
>B. responsibilities.
>I believe it's important to have fixed responsibilities. People should
>commit themselves to be resonsible for certain tasks.
>- Frido offered to work as our documentator
>- I'm offering to work as code integrator and release manager 
>
>Of course we also need people doing "the real" work i.e designing and
>coding.
>May be we need someone working as Quality Assurance manager, etc.
>
>What would you like to do? What are you willing to commit yourself to?
>
>Once we have agreed on responsibilities we can start with the real work!
>
>C. Decisions
>How to come to decisions? I'm not a friend of formalizing such things but
>maybe we need a transparent way of handlig conflicting ideas and come to
>comppromises all can agree on.
>Maybe we need some kind of "steering comittee" for such cases? What do you
>think?
>
>-- Thomas 
>
>
>------_=_NextPart_000_01C19917.90F3AA30
>Content-Type: application/octet-stream;
>	name="Mahler Thomas.vcf"
>Content-Disposition: attachment;
>	filename="Mahler Thomas.vcf"
>
>BEGIN:VCARD
>VERSION:2.1
>N:Mahler;Thomas
>FN:Mahler Thomas
>ORG:ITELLIUM SYSTEMS&SERVICES GMBH;ENTWICKLUNGSTECHNIKEN
>TEL;WORK;VOICE:0201/727-5288
>TEL;CELL;VOICE:-
>ADR;WORK:;;THEODOR-ALTHOFF-STR.2;ESSEN;;45133;D
>LABEL;WORK;ENCODING=QUOTED-PRINTABLE:THEODOR-ALTHOFF-STR.2=0D=0AESSEN 45133=0D=0AD
>EMAIL;PREF;INTERNET:tho...@it...
>REV:20011026T091531Z
>END:VCARD
>
>------_=_NextPart_000_01C19917.90F3AA30--
>
>
>--__--__--
>
>Message: 2
>From: "Christian Sell" <chr...@ne...>
>To: "Mahler Thomas" <tho...@it...>,
>   "Jdo-Dev \(E-Mail\)" <obj...@li...>
>Subject: Re: [Objectbridge-jdo-dev] let's go !
>Date: Wed, 9 Jan 2002 18:44:05 +0100
>
>Hmm, I wonder whether everyone has really read the JDO spec through from
>cover to cover yet? I think that is an indispensable prerequesite, as the
>spec is quite extensive and rather specific about what has to be done and
>how.
>
>My recommendation then would to have some discussion about the conceptual
>issues and implications, and pick an important area for prototypical
>exploration. My suggestion for such an area would be the implementation of
>the "Life Cycle of JDO Instances" as described in chapter 5 of the spec and
>the StateManager interface as in chapter 21.
>
>My prediction is you will not be able to implement JDO as just another thin
>API layer on top of OJB as it is.
>
>----- Original Message -----
>From: "Mahler Thomas" <tho...@it...>
>To: "Jdo-Dev (E-Mail)" <obj...@li...>
>Sent: Wednesday, January 09, 2002 3:11 PM
>Subject: [Objectbridge-jdo-dev] let's go !
>
>
>> Hi all,
>>
>> I just had a look at the subcription list of the jdo-dev mailing list. I
>was
>> quite impressed: there are already 19 registered subscribers!
>>
>> That should be enough to get started.
>>
>> How to start?
>>
>> First of all I want to invite you to comment on my proposal.
>>
>> A. Strategy
>>
>> 1. I am proposing to start with a rapid prototype to get a feeling what
>> implementing JDO based on the PersistenceBroker kernel is all about. We
>can
>> try to reuse things from the ODMG implementation (e.g LockManagement or
>> state transition).
>>
>> 2. factor out all things that the JDO and the ODMG implementation have in
>> common and put it in a separate package ojb.otm.
>>
>> 3. refactor the JDO and the ODMG implementations to use the OTM
>internally.
>>
>> I believe this implementation strategy will reduce risks and allow to get
>> first results quickly.
>> What do you think?
>>
>> If there are no objections we should fix this as our chosen strategy.
>>
>> B. responsibilities.
>> I believe it's important to have fixed responsibilities. People should
>> commit themselves to be resonsible for certain tasks.
>> - Frido offered to work as our documentator
>> - I'm offering to work as code integrator and release manager
>>
>> Of course we also need people doing "the real" work i.e designing and
>> coding.
>> May be we need someone working as Quality Assurance manager, etc.
>>
>> What would you like to do? What are you willing to commit yourself to?
>>
>> Once we have agreed on responsibilities we can start with the real work!
>>
>> C. Decisions
>> How to come to decisions? I'm not a friend of formalizing such things but
>> maybe we need a transparent way of handlig conflicting ideas and come to
>> comppromises all can agree on.
>> Maybe we need some kind of "steering comittee" for such cases? What do you
>> think?
>>
>> -- Thomas
>>
>>
>
>
>
>--__--__--
>
>Message: 3
>Date: Wed, 09 Jan 2002 20:46:16 +0100
>From: Thomas Mahler <tho...@ho...>
>Organization: OJB Headquarters
>To: "Jdo-Dev (E-Mail)" <obj...@li...>
>Subject: Re: [Objectbridge-jdo-dev] let's go !
>
>Hi Christian, hi all,
>
>
>Christian Sell wrote:
>
>> Hmm, I wonder whether everyone has really read the JDO spec through from
>> cover to cover yet? I think that is an indispensable prerequesite, as the
>> spec is quite extensive and rather specific about what has to be done and
>> how.
>
>
>You are right. I forgot to mention that everyone has to have a copy of 
>the JDO spec under his pillow :-)
>Of course! If we are to implement a spec we have to know it!
>
>
>> 
>> My recommendation then would to have some discussion about the conceptual
>> issues and implications, and pick an important area for prototypical
>> exploration. My suggestion for such an area would be the implementation of
>> the "Life Cycle of JDO Instances" as described in chapter 5 of the spec and
>> the StateManager interface as in chapter 21.
>> 
>
>
>Yes that may be a central part to start with.
>
>Maybe it's a good idea to define isolated tasks that individuals or 
>small groups could work on. E.g.:
>- StateTransitions
>- JDOQL (the JDO Query language)
>- The Identity concept
>- Transaction coordination (incl. optimistic locking)
>- J2EE integration (CMT, BMT, etc.)
>...
>
>
>> My prediction is you will not be able to implement JDO as just another thin
>> API layer on top of OJB as it is.
>> 
>
>
>Hmm, I designed the ojb.odmg.states stuff with the JDO lifecycle and 
>StateTransition concept in mind.
>OK, it's not exactly conforming with the JDO stuff. But is it really 
>THAT different?
>
>The ODMG Implementation is also not a thin layer (think only of things 
>like Transaction coordination, LockManagement, etc.).
>I also don't believe that we will have finished JDO by next week ;-)
>
>
>cu,
>
>
>Thomas
>
>
>
>
>--__--__--
>
>_______________________________________________
>Objectbridge-jdo-dev mailing list
>Obj...@li...
>https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
>
>
>End of Objectbridge-jdo-dev Digest
>


Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

Re: [Objectbridge-jdo-dev] let's go !

[Thomas M. <tho...@ho...>]

Hi Christian, hi all,


Christian Sell wrote:

> Hmm, I wonder whether everyone has really read the JDO spec through from
> cover to cover yet? I think that is an indispensable prerequesite, as the
> spec is quite extensive and rather specific about what has to be done and
> how.


You are right. I forgot to mention that everyone has to have a copy of 
the JDO spec under his pillow :-)
Of course! If we are to implement a spec we have to know it!


> 
> My recommendation then would to have some discussion about the conceptual
> issues and implications, and pick an important area for prototypical
> exploration. My suggestion for such an area would be the implementation of
> the "Life Cycle of JDO Instances" as described in chapter 5 of the spec and
> the StateManager interface as in chapter 21.
> 


Yes that may be a central part to start with.

Maybe it's a good idea to define isolated tasks that individuals or 
small groups could work on. E.g.:
- StateTransitions
- JDOQL (the JDO Query language)
- The Identity concept
- Transaction coordination (incl. optimistic locking)
- J2EE integration (CMT, BMT, etc.)
...


> My prediction is you will not be able to implement JDO as just another thin
> API layer on top of OJB as it is.
> 


Hmm, I designed the ojb.odmg.states stuff with the JDO lifecycle and 
StateTransition concept in mind.
OK, it's not exactly conforming with the JDO stuff. But is it really 
THAT different?

The ODMG Implementation is also not a thin layer (think only of things 
like Transaction coordination, LockManagement, etc.).
I also don't believe that we will have finished JDO by next week ;-)


cu,


Thomas

Re: [Objectbridge-jdo-dev] let's go !

[Christian S. <chr...@ne...>]

Hmm, I wonder whether everyone has really read the JDO spec through from
cover to cover yet? I think that is an indispensable prerequesite, as the
spec is quite extensive and rather specific about what has to be done and
how.

My recommendation then would to have some discussion about the conceptual
issues and implications, and pick an important area for prototypical
exploration. My suggestion for such an area would be the implementation of
the "Life Cycle of JDO Instances" as described in chapter 5 of the spec and
the StateManager interface as in chapter 21.

My prediction is you will not be able to implement JDO as just another thin
API layer on top of OJB as it is.

----- Original Message -----
From: "Mahler Thomas" <tho...@it...>
To: "Jdo-Dev (E-Mail)" <obj...@li...>
Sent: Wednesday, January 09, 2002 3:11 PM
Subject: [Objectbridge-jdo-dev] let's go !


> Hi all,
>
> I just had a look at the subcription list of the jdo-dev mailing list. I
was
> quite impressed: there are already 19 registered subscribers!
>
> That should be enough to get started.
>
> How to start?
>
> First of all I want to invite you to comment on my proposal.
>
> A. Strategy
>
> 1. I am proposing to start with a rapid prototype to get a feeling what
> implementing JDO based on the PersistenceBroker kernel is all about. We
can
> try to reuse things from the ODMG implementation (e.g LockManagement or
> state transition).
>
> 2. factor out all things that the JDO and the ODMG implementation have in
> common and put it in a separate package ojb.otm.
>
> 3. refactor the JDO and the ODMG implementations to use the OTM
internally.
>
> I believe this implementation strategy will reduce risks and allow to get
> first results quickly.
> What do you think?
>
> If there are no objections we should fix this as our chosen strategy.
>
> B. responsibilities.
> I believe it's important to have fixed responsibilities. People should
> commit themselves to be resonsible for certain tasks.
> - Frido offered to work as our documentator
> - I'm offering to work as code integrator and release manager
>
> Of course we also need people doing "the real" work i.e designing and
> coding.
> May be we need someone working as Quality Assurance manager, etc.
>
> What would you like to do? What are you willing to commit yourself to?
>
> Once we have agreed on responsibilities we can start with the real work!
>
> C. Decisions
> How to come to decisions? I'm not a friend of formalizing such things but
> maybe we need a transparent way of handlig conflicting ideas and come to
> comppromises all can agree on.
> Maybe we need some kind of "steering comittee" for such cases? What do you
> think?
>
> -- Thomas
>
>

[Objectbridge-jdo-dev] let's go !

[Mahler T. <tho...@it...>]

Hi all,

I just had a look at the subcription list of the jdo-dev mailing list. I was
quite impressed: there are already 19 registered subscribers!

That should be enough to get started.

How to start?

First of all I want to invite you to comment on my proposal.

A. Strategy

1. I am proposing to start with a rapid prototype to get a feeling what
implementing JDO based on the PersistenceBroker kernel is all about. We can
try to reuse things from the ODMG implementation (e.g LockManagement or
state transition).

2. factor out all things that the JDO and the ODMG implementation have in
common and put it in a separate package ojb.otm.

3. refactor the JDO and the ODMG implementations to use the OTM internally.

I believe this implementation strategy will reduce risks and allow to get
first results quickly.
What do you think? 

If there are no objections we should fix this as our chosen strategy.

B. responsibilities.
I believe it's important to have fixed responsibilities. People should
commit themselves to be resonsible for certain tasks.
- Frido offered to work as our documentator
- I'm offering to work as code integrator and release manager 

Of course we also need people doing "the real" work i.e designing and
coding.
May be we need someone working as Quality Assurance manager, etc.

What would you like to do? What are you willing to commit yourself to?

Once we have agreed on responsibilities we can start with the real work!

C. Decisions
How to come to decisions? I'm not a friend of formalizing such things but
maybe we need a transparent way of handlig conflicting ideas and come to
comppromises all can agree on.
Maybe we need some kind of "steering comittee" for such cases? What do you
think?

-- Thomas 

WG: [Objectbridge-jdo-dev] JDO

[Budde, F. <fri...@vi...>]

Sorry, I used the wrong email adress.

-----Ursprungliche Nachricht-----
Von: Budde, Frido 
Gesendet: Montag, 7. Januar 2002 21:51
An: 'Thomas Mahler '
Cc: 'obj...@li...'
Betreff: AW: [Objectbridge-jdo-dev] JDO


Hi Thomas,
You wrote:
>Is it running under Linux too, or only under Windows?

At least the user guide contains a section "installing on unix" (hope unix
includes linux). The editor requires jdk1.3. What's the current version of
the jdk for linux?

 HTH
  Frido

Re: [Objectbridge-jdo-dev] JDO

[Thomas M. <tho...@ho...>]

Hi Frido, hi all,

Budde, Frido wrote:
<snip>

> 
> What do you think about this kind of documentation?
>   Frido
> 

I like the idea to have documentation in XML format to allow easy 
rendering of various formats.

I have only one question regarding the editor you mention:
Is it running under Linux too, or only under Windows?

I prefer tools that are available on multiple platforms.

just my 2 cents,

-- Thomas

[Objectbridge-jdo-dev] JDO

[Budde, F. <fri...@vi...>]

Hi,
Thomas sent me his proposal about developing a jdo implementation on top
of the objectbridge persistence kernel. I don't know how much time I'll
be able to spend on this project but I'd like to take part. 
I'd try to contribute to the documentation. I'd like to suggest docbook (a
special dtd for writing technical documentations). Here is why:
- It's a (widely-used) publishing standard supported by oasis.
- I found an editor XXE from XMLmind which allows styling a dtd 
  with css and editing the styled version of the file instead of
  raw XML. It looks like editing a word document (almost :-) ).
  As far as I have understood the licence we'd be able use it free of
charge.
    >The milestone releases of XXE, 
    >which are subject to the XMLmind Standard XML Editor License, 
    >can be used at no charge
  On their website they announce the release of a kind of community edition
  after the product is completed.
    >The commercial product will be available in two editions:
    >Standard edition 
    >  Can be used at no charge with a very liberal license. This 
    >  edition, a really usable one (i.e. not crippled in any way), 
    >  should be sufficient for many users. 
    >Professional edition 
    >  Adds a lot of goodies to the standard edition. Available at 
    >  a very reasonable price. 
- N. Walsh has published XSL stylesheets which can be used to
  generate HTML and FO. With Apache FOP we'd be able to generate
  PDF (although the FOP implementation is far from complete).
  With different renderers other file formats can be generated.
- I've tried the editor and the stylesheets and it worked quite
  well (I had some trouble with tables but it is easily fixed). 
  As soon as the FOP implementation is completed we'd be
  able to publish a well formatted printed documentation.

What do you think about this kind of documentation?
  Frido

F. Budde
viadee UNTERNEHMENSBERATUNG GmbH
Email: fri...@vi...
Phone: +49 251/77777-20

[Objectbridge-jdo-dev] [Fwd: Re: JDO compliant object/relational mapping]

[Thomas M. <tho...@ho...>]

-------- Original Message --------
Subject: Re: JDO compliant object/relational mapping
Date: Wed, 01 Jan 1997 00:27:13 +0100
From: Thomas Mahler <tho...@ho...>
Organization: NOORG
To: Todd Johann <tod...@re...>
References: <E16...@us...>

Hi Todd,

thanks for your quick reply to my request!
The work has not started yet. For the time being you might have a look
at the already developed OJB stuff, work through all tutorial etc.

Of course you should also register to the objectbridge-jdo-dev
mailinglist.

I want to wait about 1 - 2 weeks until more interested developers have
registered themselves to the list and then have some kind of project
kickoff.

thanks, and all the best for 2002,

Thomas

Todd Johann wrote:
> 
> Tom,
> 
> I might be interested in helping out with the
> Object/Relational Bridge project.  I've been developing
> Java applications for 4 years now.  I am also planning on
> using Object/Relational on some projects of my own.
> 
> Todd
> tod...@re...

[Objectbridge-jdo-dev] Re: ObjectBridge

[Thomas M. <tho...@ho...>]

Hi Faster,

Thanks for you interest!

Lu Xun wrote:
> 
> Hi,
> 
> I am quite interested in joining the JDO implementation for ObjectBridge.  About half year ago I did a search and comparison for OR-mapping tools (both commercial and non-commercial ones) and read some code of ObjectBridge and wrote some test programs and I think it is a quite project.
> 

The work on JDO has not yet started. I want to wait 1 or 2 weeks to get
more developers subscribed. I will make a further announcement on the
JDO developer list.

For the time beeing you should work through my proposal
(http://objectbridge.sourceforge.net/jdo/jdo-proposal.html), work
through the OJB Tutorials and make yourself familiar with the OJB
design...

Of course you should also join the objectbridge-jdo-dev mailinglist (see
link in the proposal)

> I'd also like to know whether you have support for con-currency control in the current release?  I think that is an important feature that seems to be missing from the release I studied.

Yes we a distributed Lockmanagement Facility (see
http://objectbridge.sourceforge.net/system/lockmanager.html).

best regards,

Thomas

> 
> Cheers,
> 
> Faster
> 
> Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

[Objectbridge-jdo-dev] OJB

[Simon H. <har...@ya...>]

Thomas,

I must commend you on the way you handle the development process for =
OJB. As an architect I see so much rubbish that is refreshing to finally =
see someone working towards truly good quality code. I am eager to =
assist in any way possible.

Regards,

Simon