You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Jakob Braeuchi <jb...@gmx.ch> on 2003/06/07 21:56:18 UTC
Re: OJB 2.0
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)
>
>
>> 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.
>
>>
>> Please add more features/architecture modifications !
>>
>>
>
jakob
Re: OJB 2.0
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
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