felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: using eclipse extension points with felix
Date Sun, 28 Jan 2007 08:15:39 GMT
On Wednesday 24 January 2007 17:50, Erik Bengtson wrote:
> Elaborate a bit more what you mean by mediocre and greater care.

I am getting my guys to compile a list from the problems they had. So, I hope 
to return with more details later.

From memory, though;

 - No version information on imports nor exports. This is important.

 - I can't understand what the Ant dependency (although optional) is doing in
   the JPox bundle.

 - To me it looks like the intent is to export all classes, irregardless if
   they are internal to Jpox or not. (Side-note:
   org.jpox.store.rdbms.expression is the only package not exported, which is
   probably a mistake.)

All of the above we could fix easily ourselves. Then;

 - JDBC driver is a general problem. No standard mechanism for supplying that.
   I hope this will be addressed by the Enterprise Expert Group asap,
   hopefully through a whiteboard pattern.
Finally, I know there was plenty of classloading problems that we could not 
overcome easily without hacking source code. I think the guys located the 
problems in Jpox, but not sure. End of the day, we went back to Kodo, which 
we can package for OSGi without those classloading issues.

Concrete suggestions;

 - Kill the use of Eclipse Extension Points altogether. Not needed.

 - Create an Activator that actively look for a java.sql.Driver instance in
   the service registry, possibly with a LDAP search expression configurable
   for Jpox.

 - Break out the different supported databases into their own bundles, to 
   be loaded on demand as well as showcase for those who need to create their
   own support.

 - Fix versioning and 'uses' clauses in manifest.

 - Take a close look at what constitutes the official API, and what are
   internal classes that noone should touch. Move the internal classes to
   "impl" or "internal" packages, whilst the API packages are exported,
   Define the SPI (probably org.jpox.store.rdbms) for those who need to
   create support of other RDBMSes in its own package.

 - The JDOClassLoaderResolver probably needs some overhaul. Will look into
   that when I am back from Dublin.

Mind you, it was quite some weeks ago we were working on this, and I was only 
consulted as "last resort" and wasn't personally very deeply involved, so my 
memory could be inaccurate. So, sorry if this is perceived as FUD. I would 
really like JPox to improve both in terms of OSGi friendliness as well as 
performance, so we can stop using the BEA product on which we now depend so 
heavily ;o)


View raw message