| provide mappings that are not on the classpath [message #491417] |
Wed, 14 October 2009 09: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
|
|
|
] 
Search
Help
Register
Login
Home
