Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » provide mappings that are not on the classpath
provide mappings that are not on the classpath [message #491417] Wed, 14 October 2009 09:24 Go to next message
thomas menzel is currently offline 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 #492229 is a reply to message #491417] Mon, 19 October 2009 10:24 Go to previous messageGo to next message
James Sutherland is currently offline James Sutherland
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

If you need to customize your platform you can just subclass it with your own platform and override as required.

The latest DerbyPlatform uses 2g as the max blob size.


James : Wiki : Book : Blog : Twitter
Re: provide mappings that are not on the classpath [message #492242 is a reply to message #492229] Mon, 19 October 2009 11:03 Go to previous messageGo to next message
thomas menzel is currently offline 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 11:12]

Report message to a moderator

Re: provide mappings that are not on the classpath [message #493146 is a reply to message #492229] Fri, 23 October 2009 07:47 Go to previous messageGo to next message
thomas menzel is currently offline thomas menzel
Messages: 81
Registered: July 2009
Member
> The latest DerbyPlatform uses 2g as the max blob size.

i guess i misread that, i thought you said that 2GB is now default...

well, also in v1.3 the above problem exists when wanting to subclass the DatabasePlatform and needing to define custom mappings!

What shall i do now?


thomas menzel aka tom
Re: provide mappings that are not on the classpath [message #493484 is a reply to message #491417] Mon, 26 October 2009 09:47 Go to previous messageGo to next message
James Sutherland is currently offline James Sutherland
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

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
Re: provide mappings that are not on the classpath [message #494041 is a reply to message #493484] Wed, 28 October 2009 17:42 Go to previous message
thomas menzel is currently offline thomas menzel
Messages: 81
Registered: July 2009
Member
indeed with 1.2 the default is 2 GB


thomas menzel aka tom
Previous Topic: java.sql.SQLException: ORA-00900 calling StoredProcedure
Next Topic:Mapping of Collection of Base class objects
Goto Forum:
  


Current Time: Sun Apr 20 19:38:33 EDT 2014

Powered by FUDForum. Page generated in 0.02261 seconds