Eclipse Community Forums: EclipseLink » provide mappings that are not on the classpath

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

Eclipse User

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

Re: provide mappings that are not on the classpath [message #492229 is a reply to message #491417]

Mon, 19 October 2009 10:24

Eclipse User

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.

Re: provide mappings that are not on the classpath [message #492242 is a reply to message #492229]

Mon, 19 October 2009 11:03

Eclipse User

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

[Updated on: Mon, 19 October 2009 11:12] by Moderator

Re: provide mappings that are not on the classpath [message #493146 is a reply to message #492229]

Fri, 23 October 2009 07:47

Eclipse User

> 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?

Re: provide mappings that are not on the classpath [message #493484 is a reply to message #491417]

Mon, 26 October 2009 09:47

Eclipse User

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.

Re: provide mappings that are not on the classpath [message #494041 is a reply to message #493484]

Wed, 28 October 2009 17:42

Eclipse User

indeed with 1.2 the default is 2 GB

Previous Topic:	java.sql.SQLException: ORA-00900 calling StoredProcedure
Next Topic:	Mapping of Collection of Base class objects

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 12 00:37:59 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter