Eclipse Community Forums: Equinox » Change exported packages at runtime

Help

Home

Home » Eclipse Projects » Equinox » Change exported packages at runtime

Show: Today's Messages :: Show Polls :: Message Navigator

Change exported packages at runtime [message #69172]

Thu, 29 June 2006 08:18

Alexander Bieber

Messages: 44
Registered: July 2009

Member

Hi all,

I wondered if there is a way to (re)define the exported packages of a
bundle at runtime?

My usecase: I've installed a ClassLoadingHook that sets a subclass of
DefaultClassLoader for a certain bundle. This classloader will load
classes and resources remotely from a J2EE server if not found by the
parent implementation. This is done in the findLocal* methods.
It works if I add the packages coming from the server at designtime to
the manifest (although PDE reports errors), but these can change any
time and I dont want to maintain them manually (even without PDE's
help). I have a list of packages coming from the server. Can I
reinitialize the exported packages of a bundle?

Best regards
Alex

Report message to a moderator

Re: Change exported packages at runtime [message #69976 is a reply to message #69172]

Thu, 13 July 2006 21:52

Thomas Watson

Messages: 503
Registered: July 2009

Senior Member

Hi Alex,

In your usecase do the packages have to be exported or are you just
using them privately for the given bundle? If you are only using them
privately then you do not need to worry about exporting the packages.

If you really need them exported then one way I can see how to add
Export-Packages dynamically is to install a fragment bundle to the host
that specifies the Export-Package.

Your ClassLoadingHook could create a bundle manifest and ZipInputStream
in memory and install that inputstream (using
BundleContext.installBundle(String location, InputStream input). You
would then have to use the PackageAdmin service to call
PackageAdmin.resolveBundles to force the newly installed bundle to
attach to the host bundle you are loading the package for. Keep in mind
that your generated fragment will remain installed on the next session
of eclipse (on a restart). Hopefully your ClassLoadingHook can detect
this and does not dynamically create a new fragment each session for the
same package.

Side question. Do you go to the network each session or do you have a
caching mechanism to prevent a network access each session for the same
class?

HTH

Tom.

Report message to a moderator

Re: Change exported packages at runtime [message #70076 is a reply to message #69976]

Mon, 17 July 2006 06:47

Alexander Bieber

Messages: 44
Registered: July 2009

Member

Hello Tom,

thanks for your reply.

> In your usecase do the packages have to be exported or are you just
> using them privately for the given bundle? If you are only using them
> privately then you do not need to worry about exporting the packages.

We need to export the packages in our usecase because our bundle serves
as "gateway" for others to access remote classes.

> If you really need them exported then one way I can see how to add
> Export-Packages dynamically is to install a fragment bundle to the host
> that specifies the Export-Package.
>
> Your ClassLoadingHook could create a bundle manifest and ZipInputStream
> in memory and install that inputstream (using
> BundleContext.installBundle(String location, InputStream input). You
> would then have to use the PackageAdmin service to call
> PackageAdmin.resolveBundles to force the newly installed bundle to
> attach to the host bundle you are loading the package for. Keep in mind
> that your generated fragment will remain installed on the next session
> of eclipse (on a restart). Hopefully your ClassLoadingHook can detect
> this and does not dynamically create a new fragment each session for the
> same package.

Thanks for your suggestion. We will try this for our case.
I hope I did understand correctly, especially for the installment and
restart: When exiting and restarting the eclipse workbench (exiting with
IPlatformRunnable.EXIT_RESTART), a bundle/fragment that was created
dynamically will still be available, but not after "shutdown" with
IPlatformRunnable.EXIT_OK?

> Side question. Do you go to the network each session or do you have a
> caching mechanism to prevent a network access each session for the same
> class?
>

We cache an index of the classes exported by the server and the
corresponding class data on the client. This is also how we solved the
problem by now. On user login we check for changes in the index. If
changes were found we simply rewrite the manifest of the bundle and
restart the workbench. Not very nice, but works for now.

Best regards
Alex

Report message to a moderator

Re: Change exported packages at runtime [message #70116 is a reply to message #70076]

Mon, 17 July 2006 14:24

Thomas Watson

Messages: 503
Registered: July 2009

Senior Member

Alexander Bieber wrote:
> Thanks for your suggestion. We will try this for our case.
> I hope I did understand correctly, especially for the installment and
> restart: When exiting and restarting the eclipse workbench (exiting with
> IPlatformRunnable.EXIT_RESTART), a bundle/fragment that was created
> dynamically will still be available, but not after "shutdown" with
> IPlatformRunnable.EXIT_OK?
>

Any bundle installed in the framework should be persistently installed
on a restart regardless of the exit code used when the platform is
shutdown. As long as the platform was shutdown and the framework had a
chance to persist its data then the dynamically installed fragment
should still be installed. The framework will read the InputStream you
supplied in BundleContext.installBundle(String location, InputStream in)
and will persist that content to its local storage.

From your scenario description I think this is what you want so that
you do not have to keep creating dynamic fragments each time the
framework is started. On a restart your host (gateway) bundle will
still have the dynamically created fragment bundles attached to export
the "network" class packages. When one of the "network" classes is
loaded your classloading hook will look in your cache and find the class
if it was loaded in a previous session or it will go to the network.

HTH

Tom

PS if your work is public can you post a URL. This sounds interesting
and I would not mind seeing this in action. Thanks.

Report message to a moderator

Re: Change exported packages at runtime [message #73216 is a reply to message #70116]

Mon, 18 September 2006 09:04

Alexander Bieber

Messages: 44
Registered: July 2009

Member

Hi Tom,

sorry for the late reply ...

>
> PS if your work is public can you post a URL. This sounds interesting
> and I would not mind seeing this in action. Thanks.

I still haven't changed to a dynamic bundle, unfortunately, but still
would like to point you to the project this is used in.
The remote classloading is part of the JFire ERP suite
(http://jfire.org) whose client application is a RCP app. You can
download the client and use it with the demo server at demo.jfire.org
(https://www.jfire.org/modules/content/id_31.html).

If you want to have a look at the sources, they're in SVN at
https://svn.jfire.org/svn/main, the projects related to this topic are:

https://svn.jfire.org/svn/main/trunk/DelegatingClassLoader/
(Classloader used by the classloading hook, these sources are copied
into the bundle that gets hooked by an ant script)

https://svn.jfire.org/svn/main/trunk/JFireRCLBackend/
(RemoteClassLoading Backend (publishing and indexing))
https://svn.jfire.org/svn/main/trunk/JFireRCLBackendBean/
(EJB providing published the classes)

https://svn.jfire.org/svn/main/trunk/org.nightlabs.jfire.bas e.j2ee/
(This bundles manifest is re-written at the moment, see
JFireJ2EEPlugin#updateManifest())

https://svn.jfire.org/svn/main/trunk/org.nightlabs.jfire.bas e.j2ee.osgi/
(Gets hooked as Classloading hook)

Best regards
Alex

Report message to a moderator

Previous Topic:	unable to load class using sample.http.registry
Next Topic:	Equinox and Tomcat

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Nov 09 05:03:41 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter