Database layer via ExtensionPoint, classloading issues [message #985557] |
Thu, 15 November 2012 08:45  |
Eclipse User |
|
|
|
Hello,
i am using the eclipse RCP to build some plugins. Now i wanted to have a plugin that
is responsible for saving and loading objects to a persistent storage.
I plan to have a plugin offer a service for saving and loading, that will take care of some things
above simple loading and saving.
I used db4o as a database with the acording OSGI Plugin ,that i slightly modified to incorporate
Eclipse BuddyLoading. That modification was necessary to dodge classloading issues.
My plan was to "inject"the conrete implementation of a database in an extra plugin via extension points.
So that conrecte implementation could be changed later.
Now i found that the EclipseBuddyPolicy makes it necessary to have the concrete database(db4o) in dependencies.
That would hinder my plans as a dependency would not make the component exchangeable.
So desired structure would be:
MyDatabasePlugIn(offers ExtensionPoint) -//-> ConcreteDatabasePlugIn.
There should not exist a dependency between those too, but this would be necessary for db4o
to access classloading via EclipseBuddyPolicy.
Is there a way to solve this?
|
|
|
Re: Database layer via ExtensionPoint, classloading issues [message #986427 is a reply to message #985557] |
Tue, 20 November 2012 06:53  |
Eclipse User |
|
|
|
Hi,
could you elaborate on the usage of BuddyPolicy? The BuddyPolicy should be used with care and should be avoided if possible. It is seldomly necessary. For the architecture you describe above it is not necessary.
1. Write your plugin, that exports the extension point
2. Write onother plugin that implements this extension point and imports the db4o bundle. The implementation of your extension point can then use db4o. This plugin might as well be a fragment to the db4o bundle.
3. (optional) Write yet another plugin/fragment that implements the extension point while importing another db implementation.
Regards,
Thorsten
|
|
|
Powered by
FUDForum. Page generated in 0.17832 seconds