db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Serious design flaw
Date Tue, 09 Aug 2005 13:28:04 GMT
Clute, Andrew wrote:
> 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.
>

endorsement:
Be carefully when using HEAD in production environment, because the 
backport of many fixes from 1.0.x (and the refactored odmg-api 
implementation) is still outstanding. I'm currently working on that 
stuff.

regards
Armin

> -Andrew
> 
>  
> 
> 
>>-----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
> 
> 

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


Mime
View raw message