Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Subject: Re: OJB 2.0
From: Leandro Rodrigo Saad Cruz <leandro@ibnetwork.com.br>
To: OJB Developers List <ojb-dev@db.apache.org>
In-Reply-To: <3EE24362.3000002@gmx.ch>
References: <1054050256.6094.50.camel@zacarias> <3ED45966.4070807@web.de>
	<3EE24362.3000002@gmx.ch>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 10 Jun 2003 18:21:46 -0300
Message-Id: <1055280106.9531.20.camel@zacarias>
Mime-Version: 1.0

On Sat, 2003-06-07 at 16:56, Jakob Braeuchi wrote:
> hi,
> 
> Thomas Mahler wrote:
> 
> > Hi Leandro,
> >
> > Leandro Rodrigo Saad Cruz wrote:
> >
> >> Hi all. I'd like to start a discussion about ojb 2.0
> >> features/architecture needed for OJB evolution and acceptance by users
> >> and other developers. 
> >
> >
> > That's a good idea!
> >
> >> 1 - Component model
> >>
> >> One of the things I *really* think OJB should use is a component model
> >> (see http://avalon.apache.org). OJB should be assembled from components
> >> developed and tested individuality. The main components are already
> >> defined in OJB.properties, like SequenceManager and
> >> PersistenceBrokerImpl. This approach enables a a higher level of 
> >> reuse, maintainability and quality. 
> >
> >
> > From the user input I see I doubt that we need a finer granularity of 
> > components. Many users are already having troubles with selecting the 
> > right combination of components (e.g. in AppServer environments)
> >
> > I like the idea of having "kits" that assemble meaningful combinations 
> > of components.
> >
> > I'm also in doubt that replacing the existing component/configuration 
> > model by Avalon components add any real value. But I'm not against 
> > such a refactoring. 
> 
> imo we should try to split up PersistenceBroker  in some smaller 
> components (i do not yet know which :( ).  another  refactoring
> could be to use jakarta.commons whereever possible (i'm thinking about 
> logging)

Oh yes... we *really* need this I think !
xingu.sourceforge.net has a LoggerFactory that wrapps commons-logging.

> 
> >
> >
> >> 2 - Object-to-Table mappings.
> >>
> >> AFAIK, as it's written today, OJB doesn't support some types of mapping
> >> that should be considered depending on the application type
> >> (please see http://citeseer.nj.nec.com/keller97mapping.html )
> >>
> >> Coupled with the use of components, OJB could provide different
> >> strategies for Object-to-Table mapping !
> >
> >
> > We are supporting
> > "One Inheritance Tree One Table", "One Inheritance Path One Table" and 
> > for a long time now (see 
> > http://www.objectarchitects.de/ObjectArchitects/orpatterns/)
> >
> > By using the new anonymous fields feature it's now also possible to 
> > map "One Class One Table".
> > I don't see how using components could help here.
> > (Of course it's alsways possible to factor some behaviour out as a 
> > component, but where is the benefit).
> >
> we currently have a problem when mixing the two supported mappings :(
> 
> >
> >>
> >> 3 - API implementations
> >>
> >> ODMG, JDO, etc, etc. You decide ! I use only PB.
> >
> >
> > +1
> 
> 
> imo jdo is the most important (after  pb of course) i don't know about odmg.
> 
> >
> >>
> >> 4 - JMX
> >>
> >> If OJB components were managed externally using JMX they could be used
> >> OTS into applications using JMX. There is no point in using another
> >> management infrastructure or not beeing part of one !
> >
> >
> > +1 JMX is a must these days.

Is there any JMX specialist ?

> >
> >>
> >> Please add more features/architecture modifications !
> >>
> >>
> >
> jakob
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sourceforge.net