Hello Armin,
> -----Original Message-----
> From: Armin Waibel [mailto:[EMAIL PROTECTED]
> > Yes, I see. I have missed that a call setClosed(false) will
> > not close the PersistenceBroker, but only refresh() it.
> > Strange method name, isn't it?
> >
>
> PBState#setClosed(true/false) used to indicate the
> state of the used PB instance and to do
> cleanup/init stuff. Any alternative method names?
I do not see the need to have a boolean parameter here.
I would rename 'setClosed(false)' to 'open()' and
'setClosed(true)' to 'close()'
Besides, I would expect setClosed(false) to do nothing in case
the broker is already open.
But let's stop this discussion, it is unimportant.
[snip: switch between different DescriptorRepositories
using MetaDataManager.setDescriptor(...) at the rigt places]
> You can try to encapsulate this stuff (implement your own PBF, ...).
Implement my own PBF - that is a good idea.
> But you are right, this behaviour isn't smart and can be problematic
> when using OJB within j2ee container, e.g. bean A calls bean B,
> each bean use PB instances and bean B runs in a different
> cluster node !?! Which DR does bean B use?
I am no expert for j2ee. I guess if the beans potentially run
on different machines, it will be difficult to participate in the
same database transaction unless you use some persistence
mechanism provided by the AppServer/EJB Container. In any case,
I do not know how to pass a PB and a DR from A to B.
> > (1) the current solution maps threads to DescriptorRepositories.
> > That thread-related stuff is always unconvenient for testing
> > and in environments in which you do not fully control these
> > threads.
> > I would prefer to have a mapping from PersistenceBrokers to
> > DescriptorRepositories.
> >
> can you explain this more detailed? Sounds like a change of OJB
It is a large effort to write Multi-threaded junit tests, in
particular if you need to to test a feature that is not related
to concurrency in any way (namely toggling of DescriptorRepository)
The scenario I had on my mind is that potentially different threads
share one PersistenceBroker. I know that PB are not thread-safe,
but it does make sense if you can control that these threads do
not run concurrently.
In such a situation, it would be nice if the method
MetaDataManager.getDescriptorRepository()
returned a different DR depending on the calling PersistenceBroker.
In other words, I would prefer to add a parameter of
type PersistenceBroker to that method.
Besides, there would have to be some method to control
the mapping from PersistenceBrokers to DescriptorRepositories.
> architecture. Do you want to ask DescriptorRepository (DR) for
> PB instances? or do want to set up a PB pool for each
> used DR?
Your suggestion is a drastic alternative.
> > (2) the current solution does not offer a convenient API for
> > doing clever mappings. Whenever new stuff is added, such as the
> > addProfile() / loadProfile() methods, this spoils
> > the code even in case only few people need it.
>
> I think (currently) only a few people using this feature.
> MetadataManager was
> introduced end of last year, thus it's now in 'beta testing' ;-)
That is what I mean. If this is a sophisticated non-standard feature,
it should not spoil the standard code but should be hidden behind
some interface.
> > What I like so much about OJB is that in other parts
> > of the architecture (SequenceManager, PersistenceBroker, ...)
> > you have an interface that you can implement and configure
> > in OJB.properties.
> > Can't we find a similar way to do that here?
> >
> > For example, I could write my own MetaDataManagerImpl
> > that replaces the existing one.
>
> I agree this can be useful for some special cases. But if we start to
> make MetadataManager pluggable, why not rework the complete
> Metadata handling? Listener for metadata events (e.g. add remove
> FieldDescriptor in ClassDescriptor), better separation of DR and
> ConnectionRepository, smarter version of RepositoryPersistor, ...
o.k., does not sound bad. But for the moment, I am just facing
the problem of toggling the proxy-settings ...
> > Thomas, if you read this: A few days ago you mentioned in another
> > thread that it would be possible to use OJB without a file such
> > as repository.xml. But the method MetadataManager.init() seems to
> > try to read that file in any case, am I right?
> >
> yes, you need an 'empty' repository to start up OJB.
> see http://db.apache.org/ojb/faq.html
I think the current behaviour is acceptable, it is not painful
to put that file somewhere. It is just a matter of beauty.
O.K., to summarize: With your two hints to use the profiles
and my own PMF, I can encapsulate that toggling sufficiently well,
so I am satisfied. I still think that the architecture
could be improved here, but there it is not important to me.
Thank you again for your help,
Olli
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
