You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agsoftware.dnsalias.com> on 2003/09/26 09:10:56 UTC
[VOTE] Proposal a new OJB block
hi:
Please vote about this proposal:
PROPOSAL
========
Create a new block for OJB integration with Cocoon, called OJB block.
INTRO
=====
In order to fill the gap of the Model in a MVC model and the new way that
Cocoon is taking. I think we need to implement a better Database
integration with Cocoon. In this area I propose to create a new block that
will allow us to use OJB.
WHY START A NEW BLOCK RIGHT NOW?
================================
Sharing an initial code is the first step to start a integration. Between
us are people with valuable experience in Cocoon and Databases that can
helps us to improve this initial effort for the good of the Cocoon project
and his new vision: "a web development framework built around the concepts
of separation of concerns". If we really want to have the separation of
concerns, then we must think in how to separate the Database stuff, is
really here where OJB block fill the gap.
Currently the new component is a full working PersistentManagerFactory for
OJB as a Avalon Component.
WHY ANOTHER DATABASE BLOCK?
===========================
We prefer to build a total new block, because the current database block
have many technologies that people using OJB will not use at all: ESQL,
Tranformer, Database Actions, etc. Then if we just need OJB we can build
our Cocoon without the other database technologies of the database block
WHAT IS OJB?
============
ObJectRelationalBridge (OJB) is an Object/Relational mapping tool that
allows transparent persistence for Java Objects against relational
databases.
OJB has 3 methods for access to Databases: PersistentBroker, ODMG and JDO.
Website: http://db.apache.org/ojb/
FEATURES:
=========
http://db.apache.org/ojb/features.html
ADVANTAGES:
===========
The main advantage of using OJB in Cocoon are:
1-Flexibility: support for multiple persistence API's
2-scalability: designed for a large range of applications, from embedded
systems to rich client application. Integrates smoothly into J2EE
Application servers.
3-Functionality: OJB uses an XML based Object/Relational Mapping.
WHAT IS DONE?
=============
As I posted at wiki about my first experiments:
http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO
I already done a PersistentManagerFactory for OJB as a Avalon Component
that allow us to start a the new development for Database integration with
Cocoon.
We are currently working on a functional demo using Woody and Flow.
END WORDS
==========
I hope it is enough to "sell" this new block, that Cocoon really need! ;-D
Best Regards,
Antonio Gallardo
Re: [VOTE] Proposal a new OJB block
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Antonio Gallardo dijo:
> hi:
>
> Please vote about this proposal:
>
> PROPOSAL
> ========
> Create a new block for OJB integration with Cocoon, called OJB block.
+1
Antonio Gallardo
Re: [VOTE] Proposal a new OJB block
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Gianugo Rabellino dijo:
> Antonio Gallardo wrote:
>> hi:
>>
>> Please vote about this proposal:
>
> Antonio,
>
> there's no need to vote in order for you to add code into CVS. Just go
> ahead and commit. :-)
Thanks Gianugo for the support. :-D
>
> This said, this is not a vote but a few questions:
>
> 1. I still don't see why it shouldn't be part of the database block. I
> understand that dealing with databases directly (manual SQL) or through
> a persistence layer is somewhat different, but then again, with the
> _current_ blocks, I don't quite see the need for "balkanization" of
> database handling stuff;
Hmm. I dont see that as you. People prefer to include in applications just
the code they really need. The current (and future) blocks allow us put
into our local (customized) build of cocoon just the blocks we really need
and nothing more. Based on this idea, I think there will be very little
cases (if no cases at all) when people building new applications will use
both blocks at once.
Also, we are not using any code of the database block.
Also, this is not alkanization, because currently, Cocoon is weak in
database support for complex applications. I think people working with
database will welcome a new database block that allow us to go to the J2EE
arena.
> 2. in case such need exists, I'd rather see a "persistence" block with a
> set of different implementations (OJB being just one of those).
Same as above.
Thanks for the comments, this type of comments is what I was waiting for.
Before do any post I prefer to discuss about this in the community....
As Descartes said: "Let's measure twice and cut one time". :-D
Best Regards,
Antonio Gallardo.
Re: [VOTE] Proposal a new OJB block
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Sylvain Wallez dijo:
> Gianugo Rabellino wrote:
>
>> Antonio Gallardo wrote:
>>
>>> hi:
>>>
>>> Please vote about this proposal:
>>
>>
>> Antonio,
>>
>> there's no need to vote in order for you to add code into CVS. Just go
>> ahead and commit. :-)
>
>
> Yeah. Just do it ;-)
>
>> This said, this is not a vote but a few questions:
>>
>> 1. I still don't see why it shouldn't be part of the database block. I
>> understand that dealing with databases directly (manual SQL) or
>> through a persistence layer is somewhat different, but then again,
>> with the _current_ blocks, I don't quite see the need for
>> "balkanization" of database handling stuff;
>
>
> Mmmh... the current database block is related to direct SQL-access,
> which is what OJB wants to hide. So I would go for another block, even
> more considering that it brings new jars that you don't need when using
> e.g. ESQL.
Yep. You answer this better than me! :-D
The same apply when we will use Hibernate or other related technology.
Best Regards,
Antonio Gallardo
Re: [VOTE] Proposal a new OJB block
Posted by Steven Noels <st...@outerthought.org>.
Sylvain Wallez wrote:
> Mmmh... the current database block is related to direct SQL-access,
> which is what OJB wants to hide. So I would go for another block, even
> more considering that it brings new jars that you don't need when using
> e.g. ESQL.
Also, in a distant future, blocks categorization can be based on license
compatibility. I can imagine a Hibernate block being hosted from
cocoondev.org.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [VOTE] Proposal a new OJB block
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Gianugo Rabellino wrote:
> Antonio Gallardo wrote:
>
>> hi:
>>
>> Please vote about this proposal:
>
>
> Antonio,
>
> there's no need to vote in order for you to add code into CVS. Just go
> ahead and commit. :-)
Yeah. Just do it ;-)
> This said, this is not a vote but a few questions:
>
> 1. I still don't see why it shouldn't be part of the database block. I
> understand that dealing with databases directly (manual SQL) or
> through a persistence layer is somewhat different, but then again,
> with the _current_ blocks, I don't quite see the need for
> "balkanization" of database handling stuff;
Mmmh... the current database block is related to direct SQL-access,
which is what OJB wants to hide. So I would go for another block, even
more considering that it brings new jars that you don't need when using
e.g. ESQL.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] Proposal a new OJB block
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Sep 26, 2003, at 10:42 Europe/Rome, Reinhard Poetz wrote:
>> 2. in case such need exists, I'd rather see a "persistence"
>> block with a
>> set of different implementations (OJB being just one of those).
>
> I would really like to see this too. The problem is that AFAIK the
> other
> possible ORB frameworks are either commercial or don't have a ASF
> compatible licence. Although +1 for "persistence" instead of OJB.
-1
I would suggest you start with describing the 'implementation' of the
block (so OJB) and later (when we have the real block setup in place)
we start creating the behavioral abstractions.
So +1 to OJB, -1 to "persistence" as the name of block.
This is a general rule: if you want to do some block, first you start
with the implementation, then, would the need emerge (say another block
implements more or less the same features but in a different way), a
block behavior will be created.
Starting with defining the interfaces before the classes is the root of
all evil overcomponentization anti-patterns. And it's only asking for
trouble in the solidity of that behavioral contract.
--
Stefano.
RE: [VOTE] Proposal a new OJB block
Posted by Reinhard Poetz <re...@apache.org>.
> From: Gianugo Rabellino
>
> Antonio Gallardo wrote:
> > hi:
> >
> > Please vote about this proposal:
>
> Antonio,
>
> there's no need to vote in order for you to add code into
> CVS. Just go
> ahead and commit. :-)
>
> This said, this is not a vote but a few questions:
>
> 1. I still don't see why it shouldn't be part of the database
> block. I
> understand that dealing with databases directly (manual SQL)
> or through
> a persistence layer is somewhat different, but then again, with the
> _current_ blocks, I don't quite see the need for "balkanization" of
> database handling stuff;
I don't like this because after Antonio's checkin the database block
wouldn't be "stable" anymore (of course I don't mean the code but the
community behind the new code)
>
> 2. in case such need exists, I'd rather see a "persistence"
> block with a
> set of different implementations (OJB being just one of those).
I would really like to see this too. The problem is that AFAIK the other
possible ORB frameworks are either commercial or don't have a ASF
compatible licence. Although +1 for "persistence" instead of OJB.
Reinhard
Re: [VOTE] Proposal a new OJB block
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Sep 26, 2003, at 10:26 Europe/Rome, Gianugo Rabellino wrote:
> Antonio Gallardo wrote:
>> hi:
>> Please vote about this proposal:
>
> Antonio,
>
> there's no need to vote in order for you to add code into CVS. Just go
> ahead and commit. :-)
>
> This said, this is not a vote but a few questions:
>
> 1. I still don't see why it shouldn't be part of the database block. I
> understand that dealing with databases directly (manual SQL) or
> through a persistence layer is somewhat different, but then again,
> with the _current_ blocks, I don't quite see the need for
> "balkanization" of database handling stuff;
>
> 2. in case such need exists, I'd rather see a "persistence" block with
> a set of different implementations (OJB being just one of those).
eheh, block polymorphism starts to be asked explicitly. this is good,
the concepts are starting to percolate thru.
Antonio, you don't need a vote for creating a new block, just a
proposal where people can submit suggestions on the best way to move
forward (like gianugo is doing right now).
Gianugo, separation is not necessarely showing balkanization (it would
be if the different communities started to act against one another, but
this isn't the case) and block behaviors will generate a taxonomy, and
taxonomies are notoriously hard to find because categorization is the
first form of politics.
I would suggest to follow a KISS principle: start with the ojb block
today and create a 'persistence block behavior' later.
Is this part of the database block? don't think so. the database block
behavior is about accessing databases *explicitly* and *willingly*
(because your data resides there). the persistence block behavior is
about storing your data in a persistent way, the fact of using a
database is simply an implementation detail (the concept of databases
as we know them might not be there anymore, look at prevailer or all
the new ram-only + disk log database architectures).
but again, database is not only RDBMSonDisk, and here the taxonomy fun
begins ;-)
--
Stefano.
Re: [VOTE] Proposal a new OJB block
Posted by Gianugo Rabellino <gi...@apache.org>.
Antonio Gallardo wrote:
> hi:
>
> Please vote about this proposal:
Antonio,
there's no need to vote in order for you to add code into CVS. Just go
ahead and commit. :-)
This said, this is not a vote but a few questions:
1. I still don't see why it shouldn't be part of the database block. I
understand that dealing with databases directly (manual SQL) or through
a persistence layer is somewhat different, but then again, with the
_current_ blocks, I don't quite see the need for "balkanization" of
database handling stuff;
2. in case such need exists, I'd rather see a "persistence" block with a
set of different implementations (OJB being just one of those).
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [VOTE] Proposal a new OJB block
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Sylvain Wallez dijo:
> Upayavira wrote:
>
>> Nicolas Toper wrote:
>>
>>> why don't we use hibernate?
>>
>> Because it is LGPLd, and we cannot have LGPL code in our CVS
>> repository.
>>
>> Someone did mention getting the hibernate guys to change their
>> licence, and IIRC suggested that they were prepared to do so. If
>> someone did get them to adopt a BSD style licence, we would be able to
>> include it in a 'persistence' block, which would be great.
>
>
> Unfortunately, Hibernate recently moved under the JBoss umbrella, which
> makes me strongly doubt about a possible licence change :-(
Why are you sad? We (happily) have OJB under the Apache umbrella! Let's do
OJB better than any other O/R mapping techno in the world! :-D
Join us!
Best Regards,
Antonio Gallardo.
Re: [VOTE] Proposal a new OJB block
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Upayavira wrote:
> Nicolas Toper wrote:
>
>> why don't we use hibernate?
>
> Because it is LGPLd, and we cannot have LGPL code in our CVS repository.
>
> Someone did mention getting the hibernate guys to change their
> licence, and IIRC suggested that they were prepared to do so. If
> someone did get them to adopt a BSD style licence, we would be able to
> include it in a 'persistence' block, which would be great.
Unfortunately, Hibernate recently moved under the JBoss umbrella, which
makes me strongly doubt about a possible licence change :-(
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] Proposal a new OJB block
Posted by Ugo Cei <u....@cbim.it>.
Upayavira wrote:
> Nicolas Toper wrote:
>> why don't we use hibernate?
> Because it is LGPLd, and we cannot have LGPL code in our CVS repository.
>
> Someone did mention getting the hibernate guys to change their licence,
> and IIRC suggested that they were prepared to do so. If someone did get
> them to adopt a BSD style licence, we would be able to include it in a
> 'persistence' block, which would be great.
This is what Gavin King wrote last June:
> So, unless someone can show some concrete and immediate benefit to the
> project by going BSD ... like, for example, that the
> LGPL is the only thing keeping Microsoft from bundling Hibernate with
> Windows ... I'm not inclined to change anything now.
>
> You *can* use Hibernate in a commercial, closed-source product. As was
> always my intent. If you _modify_ Hibernate and then
> redistribute your modifications, you must make those modifications
> (only)
> available according to the terms of the LGPL.
>
> If anyone has ANY doubt that their usage is compliant, I am quite
> happy to
> send them an email stating wether what they are doing complies with
> the LGPL
> as we are interpreting it. Lawyers take such emails very seriously.
Moreove, now that Hibernate has joined JBoss, I don't think it very
likely that Gavin will change the license or even publish it under a
dual license.
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
RE: [VOTE] Proposal a new OJB block
Posted by Nicolas Toper <nt...@jouve.fr>.
thanks for your answer.
I hope they do the license change quick :=) b/c hibernate as a cocoon block
would be great
-----Message d'origine-----
De : Upayavira [mailto:uv@upaya.co.uk]
Envoyé : vendredi 26 septembre 2003 10:52
À : dev@cocoon.apache.org
Objet : Re: [VOTE] Proposal a new OJB block
Nicolas Toper wrote:
>why don't we use hibernate?
>
>
Because it is LGPLd, and we cannot have LGPL code in our CVS repository.
Someone did mention getting the hibernate guys to change their licence,
and IIRC suggested that they were prepared to do so. If someone did get
them to adopt a BSD style licence, we would be able to include it in a
'persistence' block, which would be great.
Regards, Upayavira
>-----Message d'origine-----
>De : Antonio Gallardo [mailto:agallardo@agsoftware.dnsalias.com]
>Envoyé : vendredi 26 septembre 2003 10:36
>À : dev@cocoon.apache.org
>Objet : RE: [VOTE] Proposal a new OJB block
>
>
>Reinhard Poetz dijo:
>
>
>>>WHAT IS OJB?
>>>============
>>>ObJectRelationalBridge (OJB) is an Object/Relational mapping
>>>tool that allows transparent persistence for Java Objects
>>>against relational databases.
>>>
>>>OJB has 3 methods for access to Databases: PersistentBroker,
>>>ODMG and JDO.
>>>
>>>
>>Which one do you use?
>>
>>
>
>Currently, JDO, but we will try also ODMG.
>
>
>
>>>END WORDS
>>>==========
>>>I hope it is enough to "sell" this new block, that Cocoon really need!
>>>
>>>
>>;-D
>>
>>I buy it!
>>
>>AFAIK we don't need votes for new 'unstable' blocks - a proposal that
>>can be discussed is enough. A vote is only necessary for moving from
>>unstable --> stable.
>>
>>
>
>Thanks for the info. I thought it was necesary.
>
>
>
>>If I'm wrong I you have my +1 (I'm really pleased to see it - I started
>>an OJB block on my harddisk but it's not so easy to figure out how OJB
>>works ... so I can finally decide if I like OJB or Hibernate more)
>>
>>
>
>Thanks for the vote. I think this could help us to look better at OJB.
>
>Best Regards,
>
>Antonio Gallardo
>
>
>
>
>
>
>
Re: [VOTE] Proposal a new OJB block
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Sep 26, 2003, at 10:52 Europe/Rome, Upayavira wrote:
> Nicolas Toper wrote:
>
>> why don't we use hibernate?
>>
> Because it is LGPLd, and we cannot have LGPL code in our CVS
> repository.
>
> Someone did mention getting the hibernate guys to change their
> licence, and IIRC suggested that they were prepared to do so. If
> someone did get them to adopt a BSD style licence, we would be able to
> include it in a 'persistence' block, which would be great.
or a hybernate-based implementation of a 'persistent' block behavior
can be developped and distributed from another site (cocoondev.org
comes to mind).
the block deployer will need to have the ability to connect to multiple
block librarians. (one, the official, will be on
http://cocoon.apache.org/blocks/) but there could exist more and
http://www.cocoondev.org/blocks/ might be another one, distributing
components that are not compatible with the distribution policies of
the ASF.
Note that the *GPL is reciprocal (aka viral) only when we are talking
about 'redistribution'. if the user doesn't redistribute, he is
perfectly fine in mixing and matching BSD and GPL code because their
incompatibility emerges only as "combined redistribution".
I expect very few users to use block deployment to create something
that they later have the need to redistribute combined.
--
Stefano.
Re: [VOTE] Proposal a new OJB block
Posted by Upayavira <uv...@upaya.co.uk>.
Nicolas Toper wrote:
>why don't we use hibernate?
>
>
Because it is LGPLd, and we cannot have LGPL code in our CVS repository.
Someone did mention getting the hibernate guys to change their licence,
and IIRC suggested that they were prepared to do so. If someone did get
them to adopt a BSD style licence, we would be able to include it in a
'persistence' block, which would be great.
Regards, Upayavira
>-----Message d'origine-----
>De : Antonio Gallardo [mailto:agallardo@agsoftware.dnsalias.com]
>Envoyé : vendredi 26 septembre 2003 10:36
>À : dev@cocoon.apache.org
>Objet : RE: [VOTE] Proposal a new OJB block
>
>
>Reinhard Poetz dijo:
>
>
>>>WHAT IS OJB?
>>>============
>>>ObJectRelationalBridge (OJB) is an Object/Relational mapping
>>>tool that allows transparent persistence for Java Objects
>>>against relational databases.
>>>
>>>OJB has 3 methods for access to Databases: PersistentBroker,
>>>ODMG and JDO.
>>>
>>>
>>Which one do you use?
>>
>>
>
>Currently, JDO, but we will try also ODMG.
>
>
>
>>>END WORDS
>>>==========
>>>I hope it is enough to "sell" this new block, that Cocoon really need!
>>>
>>>
>>;-D
>>
>>I buy it!
>>
>>AFAIK we don't need votes for new 'unstable' blocks - a proposal that
>>can be discussed is enough. A vote is only necessary for moving from
>>unstable --> stable.
>>
>>
>
>Thanks for the info. I thought it was necesary.
>
>
>
>>If I'm wrong I you have my +1 (I'm really pleased to see it - I started
>>an OJB block on my harddisk but it's not so easy to figure out how OJB
>>works ... so I can finally decide if I like OJB or Hibernate more)
>>
>>
>
>Thanks for the vote. I think this could help us to look better at OJB.
>
>Best Regards,
>
>Antonio Gallardo
>
>
>
>
>
>
>
RE: [VOTE] Proposal a new OJB block
Posted by Reinhard Poetz <re...@apache.org>.
> From: Nicolas Toper
>
>
> why don't we use hibernate?
hibernate is LGPL - we can't add their libraries to our CVS. Not even
mocks are allowed. Check the archives to find more about the reasons and
the "problems" with LGPL.
Reinhard
RE: [VOTE] Proposal a new OJB block
Posted by Nicolas Toper <nt...@jouve.fr>.
why don't we use hibernate?
-----Message d'origine-----
De : Antonio Gallardo [mailto:agallardo@agsoftware.dnsalias.com]
Envoyé : vendredi 26 septembre 2003 10:36
À : dev@cocoon.apache.org
Objet : RE: [VOTE] Proposal a new OJB block
Reinhard Poetz dijo:
>> WHAT IS OJB?
>> ============
>> ObJectRelationalBridge (OJB) is an Object/Relational mapping
>> tool that allows transparent persistence for Java Objects
>> against relational databases.
>>
>> OJB has 3 methods for access to Databases: PersistentBroker,
>> ODMG and JDO.
>
> Which one do you use?
Currently, JDO, but we will try also ODMG.
>> END WORDS
>> ==========
>> I hope it is enough to "sell" this new block, that Cocoon really need!
> ;-D
>
> I buy it!
>
> AFAIK we don't need votes for new 'unstable' blocks - a proposal that
> can be discussed is enough. A vote is only necessary for moving from
> unstable --> stable.
Thanks for the info. I thought it was necesary.
> If I'm wrong I you have my +1 (I'm really pleased to see it - I started
> an OJB block on my harddisk but it's not so easy to figure out how OJB
> works ... so I can finally decide if I like OJB or Hibernate more)
Thanks for the vote. I think this could help us to look better at OJB.
Best Regards,
Antonio Gallardo
RE: [VOTE] Proposal a new OJB block
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Reinhard Poetz dijo:
>> WHAT IS OJB?
>> ============
>> ObJectRelationalBridge (OJB) is an Object/Relational mapping
>> tool that allows transparent persistence for Java Objects
>> against relational databases.
>>
>> OJB has 3 methods for access to Databases: PersistentBroker,
>> ODMG and JDO.
>
> Which one do you use?
Currently, JDO, but we will try also ODMG.
>> END WORDS
>> ==========
>> I hope it is enough to "sell" this new block, that Cocoon really need!
> ;-D
>
> I buy it!
>
> AFAIK we don't need votes for new 'unstable' blocks - a proposal that
> can be discussed is enough. A vote is only necessary for moving from
> unstable --> stable.
Thanks for the info. I thought it was necesary.
> If I'm wrong I you have my +1 (I'm really pleased to see it - I started
> an OJB block on my harddisk but it's not so easy to figure out how OJB
> works ... so I can finally decide if I like OJB or Hibernate more)
Thanks for the vote. I think this could help us to look better at OJB.
Best Regards,
Antonio Gallardo
RE: [VOTE] Proposal a new OJB block
Posted by Reinhard Poetz <re...@apache.org>.
> From: Antonio Gallardo
>
> hi:
>
> Please vote about this proposal:
>
> PROPOSAL
> ========
> Create a new block for OJB integration with Cocoon, called OJB block.
>
>
> INTRO
> =====
> In order to fill the gap of the Model in a MVC model and the
> new way that Cocoon is taking. I think we need to implement a
> better Database integration with Cocoon. In this area I
> propose to create a new block that will allow us to use OJB.
>
>
> WHY START A NEW BLOCK RIGHT NOW?
> ================================ Sharing an initial code is
> the first step to start a integration. Between us are people
> with valuable experience in Cocoon and Databases that can
> helps us to improve this initial effort for the good of the
> Cocoon project and his new vision: "a web development
> framework built around the concepts of separation of
> concerns". If we really want to have the separation of
> concerns, then we must think in how to separate the Database
> stuff, is really here where OJB block fill the gap.
>
> Currently the new component is a full working
> PersistentManagerFactory for OJB as a Avalon Component.
>
>
> WHY ANOTHER DATABASE BLOCK?
> ===========================
> We prefer to build a total new block, because the current
> database block have many technologies that people using OJB
> will not use at all: ESQL, Tranformer, Database Actions, etc.
> Then if we just need OJB we can build our Cocoon without the
> other database technologies of the database block
>
>
> WHAT IS OJB?
> ============
> ObJectRelationalBridge (OJB) is an Object/Relational mapping
> tool that allows transparent persistence for Java Objects
> against relational databases.
>
> OJB has 3 methods for access to Databases: PersistentBroker,
> ODMG and JDO.
Which one do you use?
>
> Website: http://db.apache.org/ojb/
>
>
> FEATURES:
> =========
> http://db.apache.org/ojb/features.html
>
>
> ADVANTAGES:
> ===========
>
> The main advantage of using OJB in Cocoon are:
>
> 1-Flexibility: support for multiple persistence API's
> 2-scalability: designed for a large range of applications,
> from embedded systems to rich client application. Integrates
> smoothly into J2EE Application servers.
> 3-Functionality: OJB uses an XML based Object/Relational Mapping.
>
>
> WHAT IS DONE?
> =============
>
> As I posted at wiki about my first experiments:
>
> http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO
>
> I already done a PersistentManagerFactory for OJB as a Avalon
Component that allow us
> to start a the new development for Database integration with Cocoon.
>
> We are currently working on a functional demo using Woody and Flow.
Cool.
>
>
> END WORDS
> ==========
> I hope it is enough to "sell" this new block, that Cocoon really need!
;-D
I buy it!
AFAIK we don't need votes for new 'unstable' blocks - a proposal that
can be discussed is enough. A vote is only necessary for moving from
unstable --> stable.
If I'm wrong I you have my +1 (I'm really pleased to see it - I started
an OJB block on my harddisk but it's not so easy to figure out how OJB
works ... so I can finally decide if I like OJB or Hibernate more)
Reinhard