--- Thomas Dudziak <[EMAIL PROTECTED]> wrote:
> 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. We have to ask qdox guys though. And they are hard to get by :) > 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. In this case you can omit templating engine, but still benefit from all the ant/maven integration & firing up qdox etc. Since plugins are instantiated by picocontainer, it as easy as remove constructor argument. But some integration of resulting XML validation would be also nice, and XML generating plugins support this. This would be not so heavy though. > 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). Whom do you say this :) I'm developing XD1 since 2001, and first templating engine was much much worse :) Now however ( at XD2 ) there is sane and line accurate error reporting, and also tag usage validation ( "you put his tag on method, but it shall be on class" ) And of course plugins are covered by unit tests. > > > 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 ? Yes, of course. But I also use CDI in entities ( with a help of interceptor ) - and it would be nice if this step coud be bypassed. Say - entity receives some manager / utility object upon creation. > > 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. Exactly my use case. I do not like my DAO to know where the children ( pardon, sessions ) come from and what to do with them is there is an exception :) ( I handöed this with a help of delegator ) I think there could be better solution. regards, ----[ Konstantin Pribluda http://www.pribluda.de ]---------------- Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
