db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clute, Andrew" <Andrew.Cl...@etech.ohio.gov>
Subject RE: Serious design flaw
Date Tue, 09 Aug 2005 13:14:44 GMT
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.



> -----Original Message-----
> From: Dr. Michael Lipp [mailto:Michael.Lipp@danet.de] 
> Sent: Tuesday, August 09, 2005 8:49 AM
> To: ojb-dev@db.apache.org
> 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: ojb-dev-unsubscribe@db.apache.org For 
> additional commands, e-mail: ojb-dev-help@db.apache.org

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

View raw message