| provide mappings that are not on the classpath [message #491417] |
Wed, 14 October 2009 13:24  |
 thomas menzel
Messages: 81
Registered: July 2009 |
Member |
|
|
hi,
i was wondering if there is way to change the mapping at runtime or at least from a location that is not on the classpath.
our use case in SMILA is such that we use OSGI and declarative services.
the bundles in question shall be configurable and all our configs are stored in a central configuration folder which is itself configurable via a java system property (-D....) and hence cannot be added to the MANIFEST.
the goal is that customers can spec all relevant information pertinent to their environment in that configuration area, e.g.
- DB type/platform
- jdbc driver, URL, credentials
we do this with a normal properties file that is loaded and passed to Persistence.createEntityManagerFactory().
now, as it turns out: the default mappings of native types to the DB type wont cut it for us in all circumstances. for instance, we may store very large BLOBs: since we use per default the Derby(Platform) and this specs for byte[] a BLOB(64k) we had to modify its mapping to just BLOB in the META-INF/orm.xml.
however, this now wont work OOB for other DBPlatforms such as MSSQL which doenst understand BLOB as a type and hence the user needs to change it in the orm.xml. further, default mappings for other platforms may not be sufficient either.
the problem here, albeit not a big one, is that any mapping.xml, according to JPA spec, must be on the CP (in our case the default META-INF/orm.xml) and we would like to have it in the config folder where all the other settings to provide a concise user experience.
to work around this i thought of implementing
- a wrapper that inherits from DatabasePlatform
- instantiates per reflection the desired base platform such as derby
- delegate to all its methods
- except for the method buildFieldTypes()
this method would read a config file from our config folder and that would override any of the default mappings. in this case BLOB for byte[]
so far so good the idea. it fails, however, since i cannot delegate to a lot of superclass methods as they are on an internal class which is not exported.
so any suggestions you can give us on how to accomplish our goal?
ATM i guess we just have to live with the fact the user needs to edit 2 places and for convenience sake unpack the bundle always.
thx
thomas menzel aka tom
|
|
|
|
| Re: provide mappings that are not on the classpath [message #492242 is a reply to message #492229] |
Mon, 19 October 2009 15:03  |
thomas menzel
Messages: 81
Registered: July 2009 |
Member |
|
|
hi,
i was just trying that, but unfortunately the code below wont work/compile, because FieldTypeDefinition is internal and not accessible under OSGi -- at least with the version that we are using (.core_1.0.2).
/** {@inheritDoc}
* @see org.eclipse.persistence.platform.database.DerbyPlatform#buil dFieldTypes()
*/
@Override
protected Hashtable buildFieldTypes() {
Hashtable buildFieldTypes = super.buildFieldTypes();
buildFieldTypes.put(byte[].class, new FieldTypeDefinition("BLOB"));
}
going to check the latest stable/released version now, as 2GB will do it in the general case
thomas menzel aka tom
[Updated on: Mon, 19 October 2009 15:12] Report message to a moderator |
|
|
|
| Re: provide mappings that are not on the classpath [message #493484 is a reply to message #491417] |
Mon, 26 October 2009 13:47 |
|
Our manifest seems to export every package, so you should be able to access any class (at least in the 2.0/1.2 version I am looking at). Make sure you are importing it.
Worst case you could always stuff your new platform class into the EclipseLink jar.
You might want to upgrade to 1.2, which seems to already have the blob default you are looking for.
James : Wiki : Book : Blog : Twitter
|
|
|
|
Powered by
FUDForum. Page generated in 0.03762 seconds
] 
Search
Help
Register
Login
Home
