The configuration issue that you mention -- specifically the dependency on singletons and Static classes is a known issue.
The goal of the 1.1 release is to remove all singleton and static configurations and place it into an IoC-model configuration. There is no planned release date for 1.1 -- however most of the work to refactor the configuration has been completed and can be used. If you build a release off HEAD from CVS, you should probably be able to accomplish exactly what you want. -Andrew > -----Original Message----- > From: Dr. Michael Lipp [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 09, 2005 8:49 AM > To: [email protected] > Subject: Serious design flaw > > Hi, > > I have spent quite some time now with OJB and found a serious > problem that will -- I'm afraid -- prohibit me from using it. > > The problem comes up when OJB is used in a framework (Jetspeed2 in my > case) and the application (read portlet) wants to use OJB as > well -- but with a different configuration. Specifically, the > framework uses some ConnectionFactoryClass that comes with > Spring and looks for Spring Beans with names identical to the > JCD-Alias. I'm not using Spring in my application and > therefore need another ConnectionFactoryClass (I would have > created the Spring Beans as a workaround, if only I could > reach the Spring BeanFactory used by Jetspeed; but of course, > I cannot get this; and even if I could it would make my > program depend on Jetspeed2 which I do not want it to be). > > Now, due to the fact that OJB uses a lot of static classes > and singletons, I cannot use an alternate OJB configuration > for my persistence. What OJB lacks -- and this I consider a > design flaw -- is the possibility to create a > ConnectionFactory instance, configure it, use this to > configure a PersistenceBrokerFactory instance and use this to > obtain a PersistenceBroker. This would enable me to use > different OJB configurations in parallel (without doing > classloader tricks which is not really an option in the J2EE > environment). > > I have looked at the code. I could write a PersistenceBroker > wrapper that overrides the serviceConnectionManager() method. > But all ConnectionManager implementations obtain the > ConnectionFactory -- again > -- from using something static and they have no "setConnectionFactory" > method. So I'd end up implementing my own ConnectionManager. > While, of course, I can copy the code, this is really not > what I expect from a well designed framework. > > Regards, > > Michael > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
