Hi Jamie,
Unfortunately what you want to do isn't part of the JPA spec (as I'm sure
you've noticed) and so there is no nice, simple way to make this
work.
Of the four options you outline:
1) This is an unpleasant solution, and realistically you would need to name all
of the persistence units the same, picking the right persistence bundle for the
platform based on the provider. I don't recommend doing this.
2) This is what most people do, you can rely on the provider ignoring
properties it doesn't understand so it is safe, though occasionally there are
problems if different versions of the same provider need different values for
the same property.
3) Unfortunately this is not possible. The DataSource elements are spec defined
to be JNDI names, the property values are just Strings to be interpreted by the
provider, this would need fixes in every JPA provider.
4) This is possible if you write yourself a plugin to the Aries JPA container.
You can provide a fragment that attaches to the JPA container bundle and
provides a new ManagedPersistenceUnitInfoFactory implementation. If you have a
"org.apache.aries.jpa.container.properties" file in the root of your fragment
containing the line
"org.apache.aries.jpa.container.ManagedPersistenceUnitInfoFactory=<your impl
name>" you can provide a new implementation. I recommend delegating to the
existing implementation, and simply wrapping the ManagedPersistenceUnitInfo
that comes out so you can add your own entries to "getContainerProperties".
This will let you add whatever properties you want to your persistence unit. Be
careful that your fragment only attaches to the 0.3 or 0.4 incubating bundles.
We reserve the right to make breaking implementation changes until we release
1.0!
Essentially I would say, don't do 1), you can't do 3), 2) is simple but a
little unpleasant, 4) is hard to do but gives you the power to do pretty much
anything.
In answer to your other question: (am I remembering correctly that an Aries JPA
environment has to have just one provider? Otherwise I guess third party stuff
could stick with whatever provider they were already using).
The Aries JPA container can cope with multiple persistence providers (or
multiple versions of the same provider), but we only test with the latest
OpenJPA release. OpenJPA 1.x is known to work with some repackaging and effort,
OpenJPA 2.x works out of the box. EclipseLink had some issues a while ago, I
raised a bug but don't know if they have fixed it yet. In order to work the
provider must register their PersistenceProvider implementation as per the JPA
service specification, and let us call createContainerEntityManager().
Let me know how you get on :)
Tim
----------------------------------------
> Date: Tue, 15 Feb 2011 15:49:28 -0600
> From: ja...@parit.ca
> To: user@aries.apache.org
> Subject: persistence.xml : provider-specific extensibility?
>
> I would like to be able to create persistence bundles which have their
> schema created when/if the database is created (or simply when the
> tables are missing). OpenJPA has a provider-specific property to
> support this, and I believe Hibernate does as well, but I would like to
> be able to create bundles which are not tied (at build time, anyway) to
> a specific provider. Clearly, when the persistence unit finishes
> construction, the bundle becomes tied to a specific provider, and cannot
> jump around again during the same session, and that part is fine.
>
> 1) The kludgiest way I can come up with to do this is one bundle for
> every provider, which would work but has a ton of duplication (aka
> 99.999%) and would result in quite a lot of bundle proliferation for my
> situation (lots of distinct persistence bundles).
>
> 2) Next up on the kludgometer is just to stick in all the
> provider-specific properties I *might* need (or, that I will need if the
> relevant provider is selected), and rely on my understanding of the jpa
> specs that unknown properties must be ignored (thus making this approach
> safe, at least in situations where providers make good namespace
> selections). This avoids bundle proliferation but makes the designer
> part of me that likes elegance cringe. It also means that if a new
> provider is to be supported, ALL existing persistence bundles,
> separately, would need to be build-time extended for whatever properties
> might be needed. A bigger problem with this is that with the system I'm
> dealing with, third party persistable extensibility is a real
> possibility (am I remembering correctly that an Aries JPA environment
> has to have just one provider? Otherwise I guess third party stuff
> could stick with whatever provider they were already using).
>
> 3) Only a bit kludgy would be if the provider-specific functionality is
> along the same functional lines, whether some sort of jndi resolvability
> might work. It's already demonstrated on the value side, for data
> source resolution (eg osgi:service/javax.sql.DataSource with or without
> filter, eg in the blog example) so the question would be whether or not
> sensible xml could be constructed where even the property name itself is
> jndi-resolved (eg
> name="osgi:service/aStringTypeForBuildSchemaPropertyName"
> value="osgi:service/aStringTypeForBuildSchemaPropertyValue">). The
> slight kludginess is that you'd still have to have properties that some
> providers won't support, so you might still end up with some
> persistence.xml noise.
>
> 4) Seemingly least kludgy but maybe impossible is some kind of mechanism
> for run-time persistence unit property injection, which would leave the
> persistence.xml files clean of provider specific stuff until it's pushed
> in. I would guess you'd need some sort of way of speedily doing the
> update before the persistence definition consumer (which makes the
> emf-factory available) gets to it, and I'm not sure how, if possible,
> one would do that.
>
> Are there other viable options I haven't considered? For now I'm going
> to proceed along the path of #2 , but I'm hoping for better suggestions :)
>
> -Jamie
