db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <tom...@gmail.com>
Subject Re: XDoclet-2 module & Introducing Myself to the list.
Date Mon, 10 Oct 2005 14:32:58 GMT
On 10/10/05, Konstantin Priblouda <kpriblouda@yahoo.com> wrote:

> Correct me if I'm wrong ( did not grokked your
> cedebase yet ):
> You plan to parse source annotated wuth @tags, and
> then play round with model?  Cheapest way to buy this
> would be XD2 plugin  - you create interfaces
> describing your tags, annotate it with @qtags tags and
> then you receive
> self-validating implementation beans ( with
> line-accurate error reporting ).

I was thinking of adding the ability to use Java5 annotations (not
necessarily OJB-specific ones), either directly or - if qdox is able
to do that - via qdox.

> You also have choice of 3 template engines ( jelly,
> velocity, freemarker  - but jelly would be natural
> choice for XML output )
> We also got some nice accompanying plugins generating
> documentation  ( in our release process we
> automatically upload tag & plugin docs to confluence )

Actually that part is something I'd rather drop. OJB's model already
has the ability to be written to XML, so it would be natural to
generate a model instance from the XDoclet tags, apply the model
checking, and then use the model's ability to write it to XML rather
than duplicating this functionality with a template engine. Btw, this
would make debugging and testing so much easier (debugging XDoclet 1
modules are a pain in the ... if you ask me, and so is unit testing).

> > The 1.1 branch already uses Pico internally for IoC.
> > And it should not
> > be difficult to make OJB accept an external
> > container that it then
> > uses as the parent container like so:
> >
> > OJB ojbInstance = new OJB(new
> > PicoComponentContainer(parentPicoContainer));
> >
> > I havn't had a use for something like that yet,
> > though.
> I did hibernate suport for nanocontainer, and
> it ed to inject session into interested objects
> ( DAOs ). This proved to be really nice feature
> becase it decouples session management from DAO
> code - thing are implified by this.

But that is not internal, right, but rather in applications using Hibernate ?

> Though Hibernate itself is not really pico-friendly,
> so adapter subproject ( nano-persistence ) was
> necessary. If you use pico internally, it may be
> easier to adapt OJB to this enironment.

Yep, the main idea of exposing this was to be able to configure OJB
externally, eg. in Spring via the application context. And with that
it is eg. possible to inject components for OJB to use, eg. a
separately created connection factory or object creator.


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message