[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] question about composite persistence unit
|
Hello,
On Tuesday 06 March 2012 - 15:25:50, Tom Ware wrote:
> On 03/03/2012 1:39 AM, Geronimo Ma. Hernandez wrote:
> >
> > I don't need Assistance on how to write a MetaDataSource. The point is, I
> > don't know how to bring it into play.
>
> The extended XML is used any time a new EntityManagerFactory is created or
> on a call to EntityManagerFactory.refreshMetadata() - that method is
> EclipseLink-specific, so you'll have to unwrap your factory to use it.
That call hits the right direction, but I fear it is not what I'm looking for.
I looked at the source of refreshMetadata and if I got it right, entity-names
will not be read from given properties.
So may I ask for an extension, where a provider for the list of entities may
be injected?
> Note: The refreshMetadata() method is on EntityManagerFactory and not
> EntityManager. If you are dynamically extending your entities, you won't
> be able to use the same EntityManager to operate on the extended entities.
> Instead, you call refreshMetadata() and from then on every EntityManager
> you obtain from the EntityManagerFactory will use the extended entities.
> Previously created EntityManagers will use the old mappings.
That behavior is quite ok.
I could take the entities from old EntityManager and "merge" them into a new
one.
> > Persistence (in my app) is an application service, coded in core app and
> > published as a service - so all extensions will use the same application-
> > session from authentication.
> >
> > I dived into the eclipselink sources and found a
> > EntityManagerSetupImpl.updateDescriptorCacheSettings(...) - I know,
> > that's internal stuff, but is there a way to trigger that call (or
> > similar action) from application?
>
> What is your goal in calling this method?
Not especially this method, but I believe, a way to provide the list of
entities on refreshMetadata would be the right way in RCP-environments.
I think, the url-way is not appropriate for RCP-environments. Even if that app
would use networking, the list of entities to support is a local question, so
no webservice can give the right answer.
Using urls in RCP-environment is not appropriate for local information. Better
would be a possibility, where a provider could be injected to
EntityManagerFactory, which gets asked for the list of entities each time
refreshMetadata is executed.
If no Provider has been injected, the current behavior can serve as a
fallback.
> > I could imagine a Properties instance in my app, which gets extended by
> > extension-plugin activation and for so always holds the pool of known
> > entity- names.
> > Binding that PropertyMap to a Handler of the EntityDescriptorCache,
> > dynamic change of supported classes could be established.
> >
> > Don't know how weaving interferes this game, but using static weaving
> > should make the binaries fit into dynamic play. Can I trigger weaving at
> > build- process?
>
> I'm not sure I understand the two paragraphs above.
Well, in OSGi or Eclipse-RCP environments the activation of plugins is not
determined. They got loaded on demand and the only trigger is a possibly
registered Activator.
If I use an Activator, that registers the provided entities of that plugin to
a central EntityRegistry, the ApplicationSession (which holds the
EntityManagerFactory and is used to decouple app from persistence) can use
timestamps to check, whether a refresh of metadata would be necessary.
If that EntityRegistry implements the interface "ListOfEntityProvider" (or the
like) it could be injected to EntityManagerFactory and each time a refresh is
triggered, it will be called for the current list of supported Entities.
I think, this could be a pragmatic way to handle dynamic changes of known
entities.
I additionally vote for extending the EntityManager to allow the usage of
ConnectionPools in Client-environments too.
In RCP-apps it would be very nice, if a long running persistence job could be
run in background and the app continue without any restrictions.
kind regards
Gero
