On 10/10/05, Konstantin Priblouda <[EMAIL PROTECTED]> 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. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
