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:[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
