objectbridge-jdo-dev — OJB JDO developer list

Re: [Objectbridge-jdo-dev] Introduction

[Joel S. <jo...@ik...>]

On Sun, 2002-04-07 at 04:42, Thomas Mahler wrote:
> > It has some things I don't like though, which is
> > why I started Sparrow instead of just working with Ozone.
> > 
> 
> What exactly is there in Ozone that you don't like?

It's paradigm is everything runs in the db server. Client objects are
only proxies that send all requests to the server. That means every call
has network overhead (unless Ozone is in the same VM--but even then I
think I saw that objects are serialized).

This was one of the fundamental problems I had with entity EJBs. You had
to create separate value objects. You just doing all this work building
an entity bean, and now you have to create another class for a value
object. Crazy. A maintenance nightmare. Eventually you get to the point
of 2-3 classes for every object you want stored in the db.

I want one class and that's it. Let's keep it simple. If you want
business logic to run in a separate server, use a session bean.

> Do you know DB40 (http://www.db4o.com)? it's a commercial OODBMS with a 
> liberal licence for personal use. The db4o people are trying to 
> establish lighweight statndard API for OO data access 
> (http://www.odbms.org). OJB provides support for their S.O.D.A API 
> already. The ultimate aim is to allow free choice of the persistent 
> media (ODBMS or RDBMS).

I've heard of db4o but can't remember what I thought of it. I probably
didn't look at it too close as I was focusing on open source
alternatives.

> > The bare minimum I see is:
> > 
> > 1) JDO front end with pluggable store
> > 2) O/R mapping store
> > 3) Object db store
> 
> 1) and 2) are exactly the scope of OJB-JDO
> So their is really a large potential in joining our efforts!
> 
> This picture also looks very similar to the original JDO RI by sun.
> 
> I have an additional idea: what about using the OJB PersisteneBroker API 
> as the store API? going this way we will have the following picture:
> 
> 1.) JDO and ODMG front ends, both working against a PersistenceBroker 
> kernel internally
> 2.) several PersistenceBroker implementations:
> - for RDBMS (already implemented)
> - for LDAP (partially implemented)
> - for XML storage (some people already working on it)
> - for OODB (to be done by Sparrow)
> 
> This would be a kind of "rosetta stone" of object persistence!

Sounds good... What would be the quickest way for me to digest your
PersistenceBroker API?

> > My goal is to get to as close as:
> >  - Drop in one or two jars and poof, you can now have persistent
> > objects. That's all it takes.
> > 
> > The ideal might not be perfectly attainable, but I think it's possible
> > to come at least very very close.
> 
> With a pure ODBMS approach this should be possible.
> With a O/R approach it won't be that easy. (You must tell the RDBMS 
> about primary keys, foreign keys and indexes which is not so easy to 
> deduce from an object model...)
> But it's not impossible to reach.

Right. I have some crazy ideas about adaptable indexing and stuff so the
data store would handle indexing/tuning/optimization for you. I hope I
have some time eventually to try it out when we get there.
-- 
Joel Shellman
Comprehensive Internet Solutions -- Building business dreams.
[ web design | database | e-commerce | hosting | marketing ]
iKestrel, Inc.  http://www.ikestrel.com/

Re: [Objectbridge-jdo-dev] Introduction

[Joel S. <jo...@ik...>]

> Joel, I just checked out the sparrow code and got it compiled! There are 
> already some points in your code where we could introduce a separation 
> of layers. It looks quite promising.
> 
> So what do you think?

Thank you for the comments. It most certainly can be separated!

The current code is XP's idea of a Spike solution, or "Write one to
throw away"--I think similar to what you're doing based on the RI. I
think some of the code will survive, but the current code base is:

1) To get things moving.
2) To give me a strong understanding of the JDO "way".

-- 
Joel Shellman
Comprehensive Internet Solutions -- Building business dreams.
[ web design | database | e-commerce | hosting | marketing ]
iKestrel, Inc.  http://www.ikestrel.com/

Re: AW: [Objectbridge-jdo-dev] Introduction

[Joel S. <jo...@ik...>]

I apologize for being quiet for a few days. "Real life" got a little
crazy.

On Wed, 2002-04-10 at 01:14, Mahler Thomas wrote:
> > Does everybody here (both communities) want this to work, and 
> > if so, what is
> > the next step?
> > 
> 
> I think it is the best way to go. So we should do it!
> 
> I think we have to clarify responsibilities. These can be easily deduced
> from the tasks we have to accomplish:
> 
> 1) JDO front end with pluggable store interface
> 2) O/R mapping store
> 3) Object db store
> 
> 2 and 3 are simple:
> 3.) is developed by the sparrow team
> 2.) is developed by the OJB team

Maybe... see below.

> We don't need shared or synchronized repositories for these. They can be
> developed quite independently.

Agreed. And that will be a project goal--that "pluggable stores" will be
able to easily evolve separate of the front end JDO impl. I do want to
keep things open for optimizations though. There may be situations where
we specific stores might want to override certain classes or something
to make things extremely fast/optimized. This can be designed in as we
go along, though and is optional.

I guess what I'm trying to say is an elegant modular architecture with
support for a "fasttrack" pipeline for optimized stores.

Modularity is great... but especially for my vision of a JDO object
store, I would really like it to scream.

> 1.) can be decomposed into two subtasks:
> 1a) JDO front end (incl. JDO instance lifecycle, code enhancement, etc.)
> 1b) Defining a Store interface that allows pluggable implementations.
> 
> The OJB team is currently just working on prototypes based on suns RI.
> The sparrow team seems to have at leat some code working.
> SO I would suggest:
> 1a.) is done by the Sparrow team
> 1b.) will be maintained by the SParrow team too, but the OJB team is
> involved in developing this interface.
> 
> So 1.) could also lie in the Sparrow team responsibility.

I'm going to respond to the rest of the conversation at this time as
well. Again, sorry for the delay.

I would like to second your suggestion that Sparrow do #1 because... #3
might not be part of the Sparrow project after all. For example, I
mentioned Ozone. Sparrow could be the front JDO with pluggable stores
architecture, and Ozone or other object databases could then do their
own work to conform to that pluggable architecture.

Thus... let's call Sparrow the front end JDO architecture and if I
decide to do a new optimized object storage for it (which I would really
like to but don't know if I'll have time), that could be the third
project.

How does that sound?
-- 
Joel Shellman
Comprehensive Internet Solutions -- Building business dreams.
[ web design | database | e-commerce | hosting | marketing ]
iKestrel, Inc.  http://www.ikestrel.com/

AW: [Objectbridge-jdo-dev] Introduction

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

> 
> See...if he cuts your pay, then he's tampering with the other 
> tiers, and
> that is just a bad idea....
> 
Mhh, this even sounds like a good argument for requesting better payment...
I will try this in my next interview... ;-)

-- Thomas

Re: [Objectbridge-jdo-dev] Introduction

[Andy L. <aj...@as...>]

>> If both communities (ORB and Sparrow) were to agree that creating a
>> third project (provided it could be done successfully) would be ideal,
>> then it is a question of who provides that leadership, and how does
>> that community get built....
>>
>
>
> Being a "Maslow self-atualization junkie" I might volunteer for this
> job  ;-)
>

Whoever does it has to be ready to push it forward...

>
>>
>> Joel? Comments please...I am not trying to cause problems here, just
>> get some consensus momentum built...
>>
>
>
>
>>>
>>
>> Of course...volunteers are the best, because they operate at the
>> highest tier of Maslow's hierarchy - self-actualization....
>
>
> Don't tell my boss. He will cut my salary if he notices that I'm
> working  for self-actualization... :-)
>

See...if he cuts your pay, then he's tampering with the other tiers, and
that is just a bad idea....

> Thomas


"The heights of genius are only measurable by the depths of stupidity."

Re: [Objectbridge-jdo-dev] Introduction

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

Hi Andy,


> 
> I would hope some of the ORB community (and Sparrow) currently interested
> in JDO would become active on this project as well...
> 


sure !


> 
>>But: My practical experience with OpenSource projects tells me that it
>>will be somewhat difficult to set up an additional project.
>>OS projects are initiated and driven by people who feel responsible for
>> "their" project. Who feels responsible for this additional project?
>>
> 
> It certianly takes time and effort to build a community. And volunteers.
> I would hope that both you (Thomas) and Joel would have a vested interest
> in the success of this effort. You are right though, a project needs a
> primary driver to get off the ground and maintain momentum.
> 
> If both communities (ORB and Sparrow) were to agree that creating a third
> project (provided it could be done successfully) would be ideal, then it is
> a question of who provides that leadership, and how does that community get
> built....
> 


Being a "Maslow self-atualization junkie" I might volunteer for this job 
;-)


> 
> Joel? Comments please...I am not trying to cause problems here, just get
> some consensus momentum built...
> 



Joel, I just checked out the sparrow code and got it compiled! There are 
already some points in your code where we could introduce a separation 
of layers. It looks quite promising.

So what do you think?


> I really just want to see this happen!!!! One way or another....
> 
> 
>>It's good to reflect about optimal project organization etc.
>>But we must not forget that you'll rely on volunteers doing all the
>>work.
>>
> 
> Of course...volunteers are the best, because they operate at the highest
> tier of Maslow's hierarchy - self-actualization....


Don't tell my boss. He will cut my salary if he notices that I'm working 
for self-actualization... :-)

Thomas

Re: [Objectbridge-jdo-dev] Introduction

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

Hi again Andi,

<snip intro>


> 
> This could also be done by creating a third "project" specifically focused
> on the JDO front end. This would prevent either the ORB community or the
> Sparrow community from diluting at all in thier primary focus, and would
> make the JDO effort itself more visible. Initial governance of that group
> could be joint betwen the current leadership of the two exisitng
> communities. It might also make the role of each project more easily
> defined. Just a thought here...not trying to push a direction, or fragment
> in any way...
> 


In a way you are right: having a third project responsible for the jdo 
front end would be the clearest solution WRT. to responsibilities.

It could be launched as a clean room OpenSource JDO implementation project.

The OJB team won't object to such a project organization as this will 
save us a lot of work ;-)


But: My practical experience with OpenSource projects tells me that it 
will be somewhat difficult to set up an additional project.
OS projects are initiated and driven by people who feel responsible for 
"their" project. Who feels responsible for this additional project?

It's good to reflect about optimal project organization etc.
But we must not forget that you'll rely on volunteers doing all the work.

cu,

Thomas

Re: AW: [Objectbridge-jdo-dev] Introduction

[Andy L. <aj...@as...>]

>> Does everybody here (both communities) want this to work, and
>> if so, what is
>> the next step?
>>
>
> I think it is the best way to go. So we should do it!
>
> I think we have to clarify responsibilities. These can be easily
> deduced from the tasks we have to accomplish:
>
> 1) JDO front end with pluggable store interface
> 2) O/R mapping store
> 3) Object db store
>
> 2 and 3 are simple:
> 3.) is developed by the sparrow team
> 2.) is developed by the OJB team
>
> We don't need shared or synchronized repositories for these. They can
> be developed quite independently.

This could also be done by creating a third "project" specifically focused
on the JDO front end. This would prevent either the ORB community or the
Sparrow community from diluting at all in thier primary focus, and would
make the JDO effort itself more visible. Initial governance of that group
could be joint betwen the current leadership of the two exisitng
communities. It might also make the role of each project more easily
defined. Just a thought here...not trying to push a direction, or fragment
in any way...

>
> 1.) can be decomposed into two subtasks:
> 1a) JDO front end (incl. JDO instance lifecycle, code enhancement,
> etc.) 1b) Defining a Store interface that allows pluggable
> implementations.
>
> The OJB team is currently just working on prototypes based on suns RI.
> The sparrow team seems to have at leat some code working.
> SO I would suggest:
> 1a.) is done by the Sparrow team
> 1b.) will be maintained by the SParrow team too, but the OJB team is
> involved in developing this interface.
>
> So 1.) could also lie in the Sparrow team responsibility.
>
>> >
>> > 1.) JDO and ODMG front ends, both working against a
>> PersistenceBroker
>> > kernel internally
>> > 2.) several PersistenceBroker implementations:
>> > - for RDBMS (already implemented)
>> > - for LDAP (partially implemented)
>> > - for XML storage (some people already working on it)
>> > - for OODB (to be done by Sparrow)
>> >
>> > This would be a kind of "rosetta stone" of object persistence!
>> >

Again, a third projhect would be ideal here, and make it easier to get help
from other communities for integrating thier work.

>> > I believe we can save a lot of work with such a joint venture.

I agree....

"The heights of genius are only measurable by the depths of stupidity."

AW: [Objectbridge-jdo-dev] Introduction

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

Hi Andy, Hi Joel,

> 
> THis threasd begs several questions...most of them having to do with
> tactical issues. Where would primary CVS fro the JDO core 
> reside? What group
> would govern it's progress and development?
> 
> (Joel is probalby tired of me asking questions like this...) 
> One of the
> things that irs critical to making most (if not all) open 
> source communities
> thrive is a clarity of basic governing procedures. 

I really agree with you!
This is one of the largest problems I see for OS development. 
I have tried to establish some more formal procedures and a decicison making
board. But without much success.
(see: http://objectbridge.sourceforge.net/jdo/jdo-proposal.html,
http://objectbridge.sourceforge.net/team.html)

> I'm not 
> familiar enough
> with ORB to know how it has been done in the past...
> 
> I've been watching open source projects around JDO for quite 
> a while, and
> really want to see a good implementation....
> 

So do I!

> Does everybody here (both communities) want this to work, and 
> if so, what is
> the next step?
> 

I think it is the best way to go. So we should do it!

I think we have to clarify responsibilities. These can be easily deduced
from the tasks we have to accomplish:

1) JDO front end with pluggable store interface
2) O/R mapping store
3) Object db store

2 and 3 are simple:
3.) is developed by the sparrow team
2.) is developed by the OJB team

We don't need shared or synchronized repositories for these. They can be
developed quite independently.

1.) can be decomposed into two subtasks:
1a) JDO front end (incl. JDO instance lifecycle, code enhancement, etc.)
1b) Defining a Store interface that allows pluggable implementations.

The OJB team is currently just working on prototypes based on suns RI.
The sparrow team seems to have at leat some code working.
SO I would suggest:
1a.) is done by the Sparrow team
1b.) will be maintained by the SParrow team too, but the OJB team is
involved in developing this interface.

So 1.) could also lie in the Sparrow team responsibility.

What do you think?

CU,

Thomas

> 
> 
> > Hi Joel,
> >
> > Joel Shellman wrote:
> >
> > <snip intro>
> >>
> >>>What are your ideas?
> >>>Do you also focus on O/R mapping or do you want to build a JDO
> >>>compliant OODB?
> >>>
> >>
> >> I'd like to see both done, though I see a huge advantage 
> to having a
> >> JDO compliant OODB. It would make life so easy. That's why 
> I've been
> >> working with Ozone (object db).
> >
> >
> > I know Ozone a little. They also provide a ODMG Api, though not very
> > complete.
> >
> >> It has some things I don't like though, which is
> >> why I started Sparrow instead of just working with Ozone.
> >>
> >
> >
> > What exactly is there in Ozone that you don't like?
> > Do you know DB40 (http://www.db4o.com)? it's a commercial 
> OODBMS with a
> >  liberal licence for personal use. The db4o people are trying to
> > establish lighweight statndard API for OO data access
> > (http://www.odbms.org). OJB provides support for their S.O.D.A API
> > already. The ultimate aim is to allow free choice of the persistent
> > media (ODBMS or RDBMS).
> >
> >
> >> The bare minimum I see is:
> >>
> >> 1) JDO front end with pluggable store
> >> 2) O/R mapping store
> >> 3) Object db store
> >>
> >
> >
> > 1) and 2) are exactly the scope of OJB-JDO
> > So their is really a large potential in joining our efforts!
> >
> > This picture also looks very similar to the original JDO RI by sun.
> >
> > I have an additional idea: what about using the OJB PersisteneBroker
> > API  as the store API? going this way we will have the following
> > picture:
> >
> > 1.) JDO and ODMG front ends, both working against a 
> PersistenceBroker
> > kernel internally
> > 2.) several PersistenceBroker implementations:
> > - for RDBMS (already implemented)
> > - for LDAP (partially implemented)
> > - for XML storage (some people already working on it)
> > - for OODB (to be done by Sparrow)
> >
> > This would be a kind of "rosetta stone" of object persistence!
> >
> >
> >> Might also need to be a separated pluggable transaction manager and
> >> there's a good chance we would want to get a little more 
> fine grained
> >> with the above.
> >>
> >
> >
> > We are currently working on JTA and JCA support in OJB.
> >
> >
> >> My goal is to get to as close as:
> >>  - Drop in one or two jars and poof, you can now have persistent
> >> objects. That's all it takes.
> >>
> >> The ideal might not be perfectly attainable, but I think 
> it's possible
> >> to come at least very very close.
> >
> >
> > With a pure ODBMS approach this should be possible.
> > With a O/R approach it won't be that easy. (You must tell the RDBMS
> > about primary keys, foreign keys and indexes which is not so easy to
> > deduce from an object model...)
> > But it's not impossible to reach.
> >
> > I believe we can save a lot of work with such a joint venture.
> >
> > best regards,
> >
> > Thomas
> >
> >
> >
> >
> >
> > _______________________________________________
> > Objectbridge-jdo-dev mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
> 
> 
> "The heights of genius are only measurable by the depths of 
> stupidity."
> 
> 
> 
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
> 

Re: [Objectbridge-jdo-dev] Introduction

[Andy L. <aj...@as...>]

THis threasd begs several questions...most of them having to do with
tactical issues. Where would primary CVS fro the JDO core reside? What group
would govern it's progress and development?

(Joel is probalby tired of me asking questions like this...) One of the
things that irs critical to making most (if not all) open source communities
thrive is a clarity of basic governing procedures. I'm not familiar enough
with ORB to know how it has been done in the past...

I've been watching open source projects around JDO for quite a while, and
really want to see a good implementation....

Does everybody here (both communities) want this to work, and if so, what is
the next step?



> Hi Joel,
>
> Joel Shellman wrote:
>
> <snip intro>
>>
>>>What are your ideas?
>>>Do you also focus on O/R mapping or do you want to build a JDO
>>>compliant OODB?
>>>
>>
>> I'd like to see both done, though I see a huge advantage to having a
>> JDO compliant OODB. It would make life so easy. That's why I've been
>> working with Ozone (object db).
>
>
> I know Ozone a little. They also provide a ODMG Api, though not very
> complete.
>
>> It has some things I don't like though, which is
>> why I started Sparrow instead of just working with Ozone.
>>
>
>
> What exactly is there in Ozone that you don't like?
> Do you know DB40 (http://www.db4o.com)? it's a commercial OODBMS with a
>  liberal licence for personal use. The db4o people are trying to
> establish lighweight statndard API for OO data access
> (http://www.odbms.org). OJB provides support for their S.O.D.A API
> already. The ultimate aim is to allow free choice of the persistent
> media (ODBMS or RDBMS).
>
>
>> The bare minimum I see is:
>>
>> 1) JDO front end with pluggable store
>> 2) O/R mapping store
>> 3) Object db store
>>
>
>
> 1) and 2) are exactly the scope of OJB-JDO
> So their is really a large potential in joining our efforts!
>
> This picture also looks very similar to the original JDO RI by sun.
>
> I have an additional idea: what about using the OJB PersisteneBroker
> API  as the store API? going this way we will have the following
> picture:
>
> 1.) JDO and ODMG front ends, both working against a PersistenceBroker
> kernel internally
> 2.) several PersistenceBroker implementations:
> - for RDBMS (already implemented)
> - for LDAP (partially implemented)
> - for XML storage (some people already working on it)
> - for OODB (to be done by Sparrow)
>
> This would be a kind of "rosetta stone" of object persistence!
>
>
>> Might also need to be a separated pluggable transaction manager and
>> there's a good chance we would want to get a little more fine grained
>> with the above.
>>
>
>
> We are currently working on JTA and JCA support in OJB.
>
>
>> My goal is to get to as close as:
>>  - Drop in one or two jars and poof, you can now have persistent
>> objects. That's all it takes.
>>
>> The ideal might not be perfectly attainable, but I think it's possible
>> to come at least very very close.
>
>
> With a pure ODBMS approach this should be possible.
> With a O/R approach it won't be that easy. (You must tell the RDBMS
> about primary keys, foreign keys and indexes which is not so easy to
> deduce from an object model...)
> But it's not impossible to reach.
>
> I believe we can save a lot of work with such a joint venture.
>
> best regards,
>
> Thomas
>
>
>
>
>
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev


"The heights of genius are only measurable by the depths of stupidity."

Re: [Objectbridge-jdo-dev] Introduction

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

Hi Joel,

Joel Shellman wrote:

<snip intro>
> 
>>What are your ideas?
>>Do you also focus on O/R mapping or do you want to build a JDO compliant
>>OODB?
>>
> 
> I'd like to see both done, though I see a huge advantage to having a JDO
> compliant OODB. It would make life so easy. That's why I've been working
> with Ozone (object db). 


I know Ozone a little. They also provide a ODMG Api, though not very 
complete.

> It has some things I don't like though, which is
> why I started Sparrow instead of just working with Ozone.
> 


What exactly is there in Ozone that you don't like?
Do you know DB40 (http://www.db4o.com)? it's a commercial OODBMS with a 
liberal licence for personal use. The db4o people are trying to 
establish lighweight statndard API for OO data access 
(http://www.odbms.org). OJB provides support for their S.O.D.A API 
already. The ultimate aim is to allow free choice of the persistent 
media (ODBMS or RDBMS).


> The bare minimum I see is:
> 
> 1) JDO front end with pluggable store
> 2) O/R mapping store
> 3) Object db store
> 


1) and 2) are exactly the scope of OJB-JDO
So their is really a large potential in joining our efforts!

This picture also looks very similar to the original JDO RI by sun.

I have an additional idea: what about using the OJB PersisteneBroker API 
as the store API? going this way we will have the following picture:

1.) JDO and ODMG front ends, both working against a PersistenceBroker 
kernel internally
2.) several PersistenceBroker implementations:
- for RDBMS (already implemented)
- for LDAP (partially implemented)
- for XML storage (some people already working on it)
- for OODB (to be done by Sparrow)

This would be a kind of "rosetta stone" of object persistence!


> Might also need to be a separated pluggable transaction manager and
> there's a good chance we would want to get a little more fine grained
> with the above.
> 


We are currently working on JTA and JCA support in OJB.


> My goal is to get to as close as:
>  - Drop in one or two jars and poof, you can now have persistent
> objects. That's all it takes.
> 
> The ideal might not be perfectly attainable, but I think it's possible
> to come at least very very close.


With a pure ODBMS approach this should be possible.
With a O/R approach it won't be that easy. (You must tell the RDBMS 
about primary keys, foreign keys and indexes which is not so easy to 
deduce from an object model...)
But it's not impossible to reach.

I believe we can save a lot of work with such a joint venture.

best regards,

Thomas

Re: [Objectbridge-jdo-dev] Legal issues with JDORI

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

Hi Joel,

Joel Shellman wrote:

 > I was surprised when I heard you delving into the JDO RI.


Yes that's right. Here is why:
There had been some discussion on the mailinglist if a OJB based JDO
implementation is really possible.

To give a motivating impetus I suggested to build a quick-and-dirty
proof-of-concept prototype that reuses parts of the RI.

The leading idea is:
Use the RI facade and replace the FOStore StoreManager implementation by
a OjbStoreManager implementation.

  >

 > Aren't there
 > legal problems with using concepts/code/anything from it in an open
 > source project?
 >


Once we have something coded that's worth publishing I will contact the

JDO team and talk with them about the legal aspects.


The RI based implementation is meant only as a first step prototype.
As you can see from my initial jdo-proposal.html we aim at a clean-room
JDO implementation that shares as much as possible with the ODMG
implementation.


cu,

Thomas

[Objectbridge-jdo-dev] Legal issues with JDORI

[Joel S. <jo...@ik...>]

I was surprised when I heard you delving into the JDO RI. Aren't there
legal problems with using concepts/code/anything from it in an open
source project?
-- 
Joel Shellman
Comprehensive Internet Solutions -- Building business dreams.
[ web design | database | e-commerce | hosting | marketing ]
iKestrel, Inc.  http://www.ikestrel.com/

[Objectbridge-jdo-dev] Introduction

[Joel S. <jo...@ik...>]

I just noticed your project on sourceforge today. I think it's because
you recently altered your summary to include JDO.

I am spearheading the Sparrow project on Sourceforge--which is also a
JDO implementation. We have made some progress. In fact I had completed
an Enhancer and was able to persist objects but my work was lost when my
hard drive crashed (I thought I had a backup but can't find it).

However, we can go back to the enhancer that we had contributed which
was mostly complete.

Anyway, I wanted to propose a collaboration between our two projects so
that work is not duplicated.

Thank you,
-- 
Joel Shellman
Comprehensive Internet Solutions
[ web design | database | e-commerce | hosting | marketing ]
iKestrel, Inc.  http://www.ikestrel.com/

AW: [Objectbridge-jdo-dev] JDO

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

Hi Juozas,
=20
Coding has not yet started. That's why there is nothing to see in CVS =
yet.
We hope to get a JDO RI based prototype published within the next =
weeks!
=20
But I have to check with the JDO team at sun about publishing details =
of the
JDORI code before we can publish anything!
=20
cu,
=20
Thomas

-----Urspr=FCngliche Nachricht-----
Von: Juozas Baliuka [mailto:ba...@ce...]
Gesendet: Mittwoch, 27. M=E4rz 2002 23:27
An: obj...@li...
Betreff: [Objectbridge-jdo-dev] JDO


Hi,
It is good idea to implement JDO.
I use ObjectBridge in my project and want to contribute.
Is some coding started ? I don't see it in CVS.
I have some expirence in persitence and some with JDO .

AW: [Objectbridge-jdo-dev] JDO

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

Hi Juozas,
=20
This is a known Problem. I guess Sun still maintains the old IP-Filters =
from
the COCOM era!
I think JDO will have an enourmous influence in the field of Java
Persistence.
You should not feel discouraged by this restriction.
Just contact the JDO people directly via mail and ask if they can =
provide
you with the JDO RI sources.
=20
Thomas
=20
=20

-----Urspr=FCngliche Nachricht-----
Von: Juozas Baliuka [mailto:ba...@ce...]
Gesendet: Mittwoch, 27. M=E4rz 2002 23:43
An: Juozas Baliuka; obj...@li...
Betreff: Re: [Objectbridge-jdo-dev] JDO


Sorry,
I tried to download RI from SUN, but it says Lithuanians are enemies =
for
SUN.
JDO is not interesting for anymore.

Countries Authorized to Receive Source Code =09
  =09


*	Australia=20

*	Austria=20

*	Belgium=20

*	Brazil=20

*	British Virgin Islands=20

*	Canada=20

*	Colombia=20

*	Czech Republic=20

*	Denmark=20

*	Dominican Republic=20

*	Egypt=20

*	Finland=20

*	France=20

*	Germany=20

*	Greece=20

*	Hong Kong=20

*	Hungary=20

*	Iceland=20

*	India=20

*	Ireland=20

*	Israel=20

*	Italy=20

*	Japan=20

*	Korea, South=20

*	Luxembourg=20

*	Malaysia=20

*	Mexico=20

*	Netherlands=20

*	New Zealand=20

*	Norway=20

*	Panama=20

*	Philippines=20

*	Portugal=20

*	Singapore=20

*	Slovak Republic=20

*	South Africa=20

*	Spain=20

*	St. Kitts & Nevis=20

*	Sweden=20

*	Switzerland=20

*	Taiwan=20

*	United Kingdom=20

*	United States=20

*	Uruguay=20

*	Venezuela=20


=20

----- Original Message -----=20
From: Juozas  <mailto:ba...@ce...> Baliuka=20
To: obj...@li...
<mailto:obj...@li...> =20
Sent: Wednesday, March 27, 2002 11:27 PM
Subject: [Objectbridge-jdo-dev] JDO

Hi,
It is good idea to implement JDO.
I use ObjectBridge in my project and want to contribute.
Is some coding started ? I don't see it in CVS.
I have some expirence in persitence and some with JDO .

Re: [Objectbridge-jdo-dev] JDO

[Juozas B. <ba...@ce...>]

Sorry,
I tried to download RI from SUN, but it says Lithuanians are enemies for =
SUN.
JDO is not interesting for anymore.
      Countries Authorized to Receive Source Code =20
        =20
        a.. Australia=20
        b.. Austria=20
        c.. Belgium=20
        d.. Brazil=20
        e.. British Virgin Islands=20
        f.. Canada=20
        g.. Colombia=20
        h.. Czech Republic=20
        i.. Denmark=20
        j.. Dominican Republic=20
        k.. Egypt=20
        l.. Finland=20
        m.. France=20
        n.. Germany=20
        o.. Greece=20
        p.. Hong Kong=20
        q.. Hungary=20
        r.. Iceland=20
        s.. India=20
        t.. Ireland=20
        u.. Israel=20
        v.. Italy=20
        w.. Japan=20
        x.. Korea, South=20
        y.. Luxembourg=20
        z.. Malaysia=20
        aa.. Mexico=20
        ab.. Netherlands=20
        ac.. New Zealand=20
        ad.. Norway=20
        ae.. Panama=20
        af.. Philippines=20
        ag.. Portugal=20
        ah.. Singapore=20
        ai.. Slovak Republic=20
        aj.. South Africa=20
        ak.. Spain=20
        al.. St. Kitts & Nevis=20
        am.. Sweden=20
        an.. Switzerland=20
        ao.. Taiwan=20
        ap.. United Kingdom=20
        aq.. United States=20
        ar.. Uruguay=20
        as.. Venezuela=20

    =20


  ----- Original Message -----=20
  From: Juozas Baliuka=20
  To: obj...@li...=20
  Sent: Wednesday, March 27, 2002 11:27 PM
  Subject: [Objectbridge-jdo-dev] JDO


  Hi,
  It is good idea to implement JDO.
  I use ObjectBridge in my project and want to contribute.
  Is some coding started ? I don't see it in CVS.
  I have some expirence in persitence and some with JDO .

[Objectbridge-jdo-dev] JDO

[Juozas B. <ba...@ce...>]

Hi,
It is good idea to implement JDO.
I use ObjectBridge in my project and want to contribute.
Is some coding started ? I don't see it in CVS.
I have some expirence in persitence and some with JDO .

[Objectbridge-jdo-dev] JDO Finally approved by JCP participants

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

Hi all,

JDO is currently stepping to a final release!


The proposed final draft has been accepted by all voting members of the 
PCP committee. ( see: http://jcp.org/jsr/results/12-15-1.jsp )

There is now also a JDO lobbying site: http://www.jdocentral.com/

And they are mentioning OJB already: 
http://www.jdocentral.com/JDO_Links_Body.html#readup4

cu,

Thomas

Re: [Objectbridge-jdo-dev] Instrumentation/Enhancement pros and cons

[g <it...@ge...>]

Thomas,

The reference enhancer is the tool that some developers on
theserverside.com complained about. Their posts indicated that after
enhancement they encountered some problems. I will try to locate the
discussion that I am referring to and post a link for your perusal. If I
have misremembered those statements I apologize in advance.

George Coles


On Mon, 4 Mar 2002, Thomas Mahler wrote:

> Hi again George,
>
> g wrote:
>
> > Hi all,
> > 	I have been reading up on the controversy over some of JDO's
> > features, and have reaqd some of the postings on this list regarding JDO.
> > I understand and agree with the concerns of some people who have found
> > that classees that have been enhanced through byte code instrumentation
> > may behave unpredictably, for example when debugging information is lost,
> > mangled, or not properly inserted into an instrumented class file.
> > The seemingly mysterious nature of this instrumenting process does evoke a
> > sense of worry, but I have not seen any discussions of what the
> > alternatives are.
> >
> > Have we as a group had any discussion about how we might avoid choosing
> > the abovementioned approach? Perhaps a compromise like inserting just
> > enough code into the enhanced class to provide proper identity attributes,
> > which would enable us to use metadata accessed from behind the facade of
> > the PersistenceManager?
>
>
> This has been one of my first ideas. I thought that something like the
> ObjectEnvelope as we are using it in the ODMG impl might work as an
> adapter between business objects (with little or no enhancements) and
> the JDO implementation that needs a lot of navgitaional etc.
> infrastructure for each persistent instance.
>
>
> I thought that this was a legal approach as there are comments in the
> JDO docu saying that one is *not* forced to do byte code enhancements.
>
> But there are other parts in the spec clearly stating that we must
> 1. enhance our classes. They must even be enhanced in a way that they
> may well work with other JDO implementations
> 2. Our Jdo Implementation must be able to use classes enhanced by other
> JDO vendors!
>
>
> IMHO these rules are very strict and there is not much space for
> argumentation.
> (Of course there are lots of people saying that the JDO spec is not
> rigid enough to provide this kind of interoperability of enhanced classes).
>
> I hope that it will be possible to use the byte code enhancer from the
> JDO RI ("reference enhancer").
>
> cu,
>
> Thomas
>
>
> >
> > I have some experience with the BCEL byte code libraries, and have some
> > code that traverses compiled code and can do analysis or make changes.
> > This code uses BCEL. It's pretty straightforward.
> >
> > Thanks,
> >
> > George Coles
> >
> >
> > _______________________________________________
> > Objectbridge-jdo-dev mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
> >
> >
> >
> >
>
>
>

Re: [Objectbridge-jdo-dev] Instrumentation/Enhancement pros and cons

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

Hi Jim,

Jim Hughes wrote:

> Hi.  My name is Jim Hughes, and I hope to be able to contribute in some
> way to this project.
> 
> Anyway, my understanding is that if we do enhancement, the way we do it
> is pretty well specified, if we want to comply with the spec, that is.
> Classes need to be modified to implement PersistenceCapable, etc.  The
> spec even states that enhanced classes must be portable between
> different JDO impls, which really constrains us.  E.g., we couldn't do
> this:
> 
> // way pseudo!
> package org.objectbridge.jdo;
> interface PersistenceCapable extends javax.jdo.PersistanceCapable
> {
> 	void persistYourself() ;
> }
> 
> public class PersistenceManager implements javax.jdo.PersistanceManager
> {
> 	void makePersistent(Object o)
> 	{
> 		PersistenceCapable pco =
> (org.objectbridge.jdo.PersistenceCapable)o;
> 		pco.persistYourself();
> 	}
> }
> 
> because this code would not work with PersistenceCapable class enhanced
> by other impls.


I totally agree with you !


> 
> I would be interested in working on the enhancer.  Is anyone working on
> it yet?


No, there is not much real work going on just now.
Christian Rath and I had some plans on writing a first prototype based 
on the JDO RI.

The RI has a clear layered architecture with a StoreManager interface 
that allows to abstract from implementations (as the default FOStore 
implementation).
Our idea was just to provide simply a OJB PersistenceBroker based 
StoreManager.

But we have been so busy with other things that we did not yet start on 
this !

cu,

Thomas


> Jim
> 
> 
> -----Original Message-----
> From: obj...@li...
> [mailto:obj...@li...] On Behalf Of g
> Sent: Monday, March 04, 02 10:48 AM
> To: obj...@li...
> Subject: [Objectbridge-jdo-dev] Instrumentation/Enhancement pros and
> cons
> 
> 
> Hi all,
> 	I have been reading up on the controversy over some of JDO's
> features, and have reaqd some of the postings on this list regarding
> JDO. I understand and agree with the concerns of some people who have
> found that classees that have been enhanced through byte code
> instrumentation may behave unpredictably, for example when debugging
> information is lost, mangled, or not properly inserted into an
> instrumented class file. The seemingly mysterious nature of this
> instrumenting process does evoke a sense of worry, but I have not seen
> any discussions of what the alternatives are.
> 
> Have we as a group had any discussion about how we might avoid choosing
> the abovementioned approach? Perhaps a compromise like inserting just
> enough code into the enhanced class to provide proper identity
> attributes, which would enable us to use metadata accessed from behind
> the facade of the PersistenceManager?
> 
> I have some experience with the BCEL byte code libraries, and have some
> code that traverses compiled code and can do analysis or make changes.
> This code uses BCEL. It's pretty straightforward.
> 
> Thanks,
> 
> George Coles
> 
> 
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
> 
> 
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
> 
> 
> 
> 

RE: [Objectbridge-jdo-dev] Instrumentation/Enhancement pros and cons

[g <it...@ge...>]

You are correct, Jim, I looked over the spec again. I guess Thomas' post
that I read that contemplates not utilizing enhancement implies that we
would be willing to selectively conform to the spec.

It does seem like the kind of feature that can be added or subtracted
to the project without a great deal of disruption.

George


On Mon, 4 Mar 2002, Jim Hughes wrote:

>
> Hi.  My name is Jim Hughes, and I hope to be able to contribute in some
> way to this project.
>
> Anyway, my understanding is that if we do enhancement, the way we do it
> is pretty well specified, if we want to comply with the spec, that is.
> Classes need to be modified to implement PersistenceCapable, etc.  The
> spec even states that enhanced classes must be portable between
> different JDO impls, which really constrains us.  E.g., we couldn't do
> this:
>
> // way pseudo!
> package org.objectbridge.jdo;
> interface PersistenceCapable extends javax.jdo.PersistanceCapable
> {
> 	void persistYourself() ;
> }
>
> public class PersistenceManager implements javax.jdo.PersistanceManager
> {
> 	void makePersistent(Object o)
> 	{
> 		PersistenceCapable pco =
> (org.objectbridge.jdo.PersistenceCapable)o;
> 		pco.persistYourself();
> 	}
> }
>
> because this code would not work with PersistenceCapable class enhanced
> by other impls.
>
> I would be interested in working on the enhancer.  Is anyone working on
> it yet?
>
> Jim
>
>
> -----Original Message-----
> From: obj...@li...
> [mailto:obj...@li...] On Behalf Of g
> Sent: Monday, March 04, 02 10:48 AM
> To: obj...@li...
> Subject: [Objectbridge-jdo-dev] Instrumentation/Enhancement pros and
> cons
>
>
> Hi all,
> 	I have been reading up on the controversy over some of JDO's
> features, and have reaqd some of the postings on this list regarding
> JDO. I understand and agree with the concerns of some people who have
> found that classees that have been enhanced through byte code
> instrumentation may behave unpredictably, for example when debugging
> information is lost, mangled, or not properly inserted into an
> instrumented class file. The seemingly mysterious nature of this
> instrumenting process does evoke a sense of worry, but I have not seen
> any discussions of what the alternatives are.
>
> Have we as a group had any discussion about how we might avoid choosing
> the abovementioned approach? Perhaps a compromise like inserting just
> enough code into the enhanced class to provide proper identity
> attributes, which would enable us to use metadata accessed from behind
> the facade of the PersistenceManager?
>
> I have some experience with the BCEL byte code libraries, and have some
> code that traverses compiled code and can do analysis or make changes.
> This code uses BCEL. It's pretty straightforward.
>
> Thanks,
>
> George Coles
>
>
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
>
>
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
>

Re: [Objectbridge-jdo-dev] Instrumentation/Enhancement pros and cons

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

Hi again George,

g wrote:

> Hi all,
> 	I have been reading up on the controversy over some of JDO's
> features, and have reaqd some of the postings on this list regarding JDO.
> I understand and agree with the concerns of some people who have found
> that classees that have been enhanced through byte code instrumentation
> may behave unpredictably, for example when debugging information is lost,
> mangled, or not properly inserted into an instrumented class file.
> The seemingly mysterious nature of this instrumenting process does evoke a
> sense of worry, but I have not seen any discussions of what the
> alternatives are.
> 
> Have we as a group had any discussion about how we might avoid choosing
> the abovementioned approach? Perhaps a compromise like inserting just
> enough code into the enhanced class to provide proper identity attributes,
> which would enable us to use metadata accessed from behind the facade of
> the PersistenceManager?


This has been one of my first ideas. I thought that something like the 
ObjectEnvelope as we are using it in the ODMG impl might work as an 
adapter between business objects (with little or no enhancements) and 
the JDO implementation that needs a lot of navgitaional etc. 
infrastructure for each persistent instance.


I thought that this was a legal approach as there are comments in the 
JDO docu saying that one is *not* forced to do byte code enhancements.

But there are other parts in the spec clearly stating that we must
1. enhance our classes. They must even be enhanced in a way that they 
may well work with other JDO implementations
2. Our Jdo Implementation must be able to use classes enhanced by other 
JDO vendors!


IMHO these rules are very strict and there is not much space for 
argumentation.
(Of course there are lots of people saying that the JDO spec is not 
rigid enough to provide this kind of interoperability of enhanced classes).

I hope that it will be possible to use the byte code enhancer from the 
JDO RI ("reference enhancer").

cu,

Thomas


> 
> I have some experience with the BCEL byte code libraries, and have some
> code that traverses compiled code and can do analysis or make changes.
> This code uses BCEL. It's pretty straightforward.
> 
> Thanks,
> 
> George Coles
> 
> 
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
> 
> 
> 
> 

RE: [Objectbridge-jdo-dev] Instrumentation/Enhancement pros and cons

[Jim H. <je...@hu...>]

Hi.  My name is Jim Hughes, and I hope to be able to contribute in some
way to this project.

Anyway, my understanding is that if we do enhancement, the way we do it
is pretty well specified, if we want to comply with the spec, that is.
Classes need to be modified to implement PersistenceCapable, etc.  The
spec even states that enhanced classes must be portable between
different JDO impls, which really constrains us.  E.g., we couldn't do
this:

// way pseudo!
package org.objectbridge.jdo;
interface PersistenceCapable extends javax.jdo.PersistanceCapable
{
	void persistYourself() ;
}

public class PersistenceManager implements javax.jdo.PersistanceManager
{
	void makePersistent(Object o)
	{
		PersistenceCapable pco =
(org.objectbridge.jdo.PersistenceCapable)o;
		pco.persistYourself();
	}
}

because this code would not work with PersistenceCapable class enhanced
by other impls.

I would be interested in working on the enhancer.  Is anyone working on
it yet?

Jim


-----Original Message-----
From: obj...@li...
[mailto:obj...@li...] On Behalf Of g
Sent: Monday, March 04, 02 10:48 AM
To: obj...@li...
Subject: [Objectbridge-jdo-dev] Instrumentation/Enhancement pros and
cons


Hi all,
	I have been reading up on the controversy over some of JDO's
features, and have reaqd some of the postings on this list regarding
JDO. I understand and agree with the concerns of some people who have
found that classees that have been enhanced through byte code
instrumentation may behave unpredictably, for example when debugging
information is lost, mangled, or not properly inserted into an
instrumented class file. The seemingly mysterious nature of this
instrumenting process does evoke a sense of worry, but I have not seen
any discussions of what the alternatives are.

Have we as a group had any discussion about how we might avoid choosing
the abovementioned approach? Perhaps a compromise like inserting just
enough code into the enhanced class to provide proper identity
attributes, which would enable us to use metadata accessed from behind
the facade of the PersistenceManager?

I have some experience with the BCEL byte code libraries, and have some
code that traverses compiled code and can do analysis or make changes.
This code uses BCEL. It's pretty straightforward.

Thanks,

George Coles


_______________________________________________
Objectbridge-jdo-dev mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev

[Objectbridge-jdo-dev] Instrumentation/Enhancement pros and cons

[g <it...@ge...>]

Hi all,
	I have been reading up on the controversy over some of JDO's
features, and have reaqd some of the postings on this list regarding JDO.
I understand and agree with the concerns of some people who have found
that classees that have been enhanced through byte code instrumentation
may behave unpredictably, for example when debugging information is lost,
mangled, or not properly inserted into an instrumented class file.
The seemingly mysterious nature of this instrumenting process does evoke a
sense of worry, but I have not seen any discussions of what the
alternatives are.

Have we as a group had any discussion about how we might avoid choosing
the abovementioned approach? Perhaps a compromise like inserting just
enough code into the enhanced class to provide proper identity attributes,
which would enable us to use metadata accessed from behind the facade of
the PersistenceManager?

I have some experience with the BCEL byte code libraries, and have some
code that traverses compiled code and can do analysis or make changes.
This code uses BCEL. It's pretty straightforward.

Thanks,

George Coles