Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » [classloading] dynamic import / class cast exception
[classloading] dynamic import / class cast exception [message #41071] Fri, 30 April 2004 15:39 Go to next message
Eclipse UserFriend
Originally posted by: sg.removeme.media-style.com

Hi,

I use a custom class-loader for my jboss plugin. The idea is to make it
configurable what kind of jboss
configuration should be loaded. Since each configuration (minimal
| default | all) need different sets of
jar libraries i wish to import the jars dynamically to the plugin
classloader.
I found a posting from February 2003 that osgi support dynamically import
of libraries but at least i
found no API sample or documentation.
So i use a mechanism similar the ant core plugin use for dynamically
loading of libraries it use a
custom classloader.

How ever now i run in trouble since i got ClassCastException.
The interface is loaded by the EclipseClassLoader and the Implementation
is loading by my
classloader.

implementation classloader: net.sf.jstaff.jboss.JbossClassloader@cf5ac5
interface classloader:
org.eclipse.core.runtime.adaptor.EclipseClassLoader@f6b4df

Is there any trick that i can manage witch classloader is used to load a
class?
Or can some one give me a hint how to dynamically import classes to a
eclsipe osgi classloader?

Thanks for any hints.
Stefan
Re: [classloading] dynamic import / class cast exception [message #41194 is a reply to message #41071] Fri, 30 April 2004 23:59 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: pascal.ibm.canada

The dynamic import is a feature of osgi (version R3.0 of the spec) which
works only with exported packages.

For example a bundle A that wants to dynamically import classes from
another a set of exported packages (for example x.y.z, d.f.g) must have
the following header in its manifest:

DynamicImport-Package: x.y.z.*, d.f.g.*

Then the bundle that contains the class should say something like
Export-package:
x.y.z, d.f.g

HTH,

PaScaL

Stefan Groschupf wrote:

> Hi,
>
> I use a custom class-loader for my jboss plugin. The idea is to make it
> configurable what kind of jboss
> configuration should be loaded. Since each configuration (minimal
> | default | all) need different sets of
> jar libraries i wish to import the jars dynamically to the plugin
> classloader.
> I found a posting from February 2003 that osgi support dynamically import
> of libraries but at least i
> found no API sample or documentation.
> So i use a mechanism similar the ant core plugin use for dynamically
> loading of libraries it use a
> custom classloader.
>
> How ever now i run in trouble since i got ClassCastException.
> The interface is loaded by the EclipseClassLoader and the Implementation
> is loading by my
> classloader.
>
> implementation classloader: net.sf.jstaff.jboss.JbossClassloader@cf5ac5
> interface classloader:
> org.eclipse.core.runtime.adaptor.EclipseClassLoader@f6b4df
>
> Is there any trick that i can manage witch classloader is used to load a
> class?
> Or can some one give me a hint how to dynamically import classes to a
> eclsipe osgi classloader?
>
> Thanks for any hints.
> Stefan
>
>
>
Re: [classloading] dynamic import / class cast exception [message #41223 is a reply to message #41194] Sat, 01 May 2004 15:12 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: sg.media-style.removeme.com

> DynamicImport-Package: x.y.z.*, d.f.g.*
>
> Then the bundle that contains the class should say something like
> Export-package:
> x.y.z, d.f.g


Hmm. Sorry i do not understand, do you have a pointer to any code that
use this functionality or is there any documentation about that?

Thanks
Stefan
Re: [classloading] dynamic import / class cast exception [message #41254 is a reply to message #41223] Sat, 01 May 2004 22:46 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: pascal.ibm.canada

If you are looking in the meta-inf folder of org.eclipse.osgi, you will
find a file called manifest.mf.
This manifest.mf (and the manifest.mf in general in osgi) is equivalent
to the runtime section of the plugin.xml (library, requires, plugin id,
etc.). Don't be afraid, it is just the osgi way of declaring the
relations inter bundles.

In the version R3.0 of osgi spec, inter bundle relations were specified
in terms of package. A bundle was exporting a package, and another was
importing it. A bundle was only resolved when all the packages it was
importing were exported by another bundle. This was really similar to
the plugin model and its dependencies.
In this model, when a bundle needed to access packages that were not
always available (because the bundle exporting them could be missing)
they could use specify in the manifest.mf, the dynamicImport statement.

Does this help?

PaScaL

Stefan Groschupf wrote:
>
>> DynamicImport-Package: x.y.z.*, d.f.g.*
>>
>> Then the bundle that contains the class should say something like
>> Export-package:
>> x.y.z, d.f.g
>
>
>
> Hmm. Sorry i do not understand, do you have a pointer to any code that
> use this functionality or is there any documentation about that?
>
> Thanks
> Stefan
Re: [classloading] dynamic import / class cast exception [message #41316 is a reply to message #41254] Sun, 02 May 2004 12:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: sg.removeme.media-style.com

> Does this help?

Sorry, no. May be i was not clear enough. I wish to dynamically add some
jars to the classpath of a plugin until runtime.
Very similar the ant core does it. You can add some jars to ant in a
perference dialog, next time ant will be started this new jars are added
to the classpath. I already tied to do it similar as the ant plugin does
it, but however i go this class cast exception since a interface is loaded
by a other classloader then the implementation of this interface.

I'm seaching for an api like Plugin.getClassloader().addUrl(pathToJar).
May be I'm clearify my problem now?

Thanks for your support.

Stefan
P.S. The code i had done so far is alvailabe in the
http://sf.net/projects/jstaff cvs.
Re: [classloading] dynamic import / class cast exception [message #41377 is a reply to message #41316] Sun, 02 May 2004 16:06 Go to previous messageGo to next message
Erik Wistrand is currently offline Erik WistrandFriend
Messages: 9
Registered: July 2009
Junior Member
Stefan Groschupf wrote:
> Sorry, no. May be i was not clear enough. I wish to dynamically add some
> jars to the classpath of a plugin until runtime.

Well, the OSGi way of doing this is simply to install a new bundle, an
your code can do this itself. If you combine this with
DynamicImport-Package you should get the expected result.

Your plugin:

Manifest:
DynamicImport-Package: foo.* (or even *)

Code:
BundleContext.installBundle(bundleJarURL)


Now, if the newly installed bundle exports package foo (and below foo),
your bundle can use classes in foo.

Installed bundle:

Manifest:
Export-Package: foo

Code:
foo.Bar.class


Hope this helps,

/Erik W

--
Erik Wistrand, wistrand@knopflerfish.org
Re: [classloading] dynamic import / class cast exception [message #41407 is a reply to message #41377] Sun, 02 May 2004 16:39 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: pascal.ibm.canada

Erik has been faster :-)

It is exactly the idea. When you know which jars to use, you "wrap it
up" into a bundle (basically you create a manifest.mf that you either
copy into the code jar, or you put it next to it), install this newly
created bundle, refresh it and here you go.

Ant does not use such a mechanism and has to create itself some
classloaders but it is because they have other constraints.

The model described here is much more preferable.

PaScaL

Erik Wistrand wrote:

> Stefan Groschupf wrote:
>
>> Sorry, no. May be i was not clear enough. I wish to dynamically add some
>> jars to the classpath of a plugin until runtime.
>
>
> Well, the OSGi way of doing this is simply to install a new bundle, an
> your code can do this itself. If you combine this with
> DynamicImport-Package you should get the expected result.
>
> Your plugin:
>
> Manifest:
> DynamicImport-Package: foo.* (or even *)
>
> Code:
> BundleContext.installBundle(bundleJarURL)
>
>
> Now, if the newly installed bundle exports package foo (and below foo),
> your bundle can use classes in foo.
>
> Installed bundle:
>
> Manifest:
> Export-Package: foo
>
> Code:
> foo.Bar.class
>
>
> Hope this helps,
>
> /Erik W
>
Re: [classloading] dynamic import / class cast exception [message #41434 is a reply to message #41407] Sun, 02 May 2004 18:02 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: sg.removeme.media-style.com

> It is exactly the idea. When you know which jars to use, you "wrap it
> up" into a bundle (basically you create a manifest.mf that you either
> copy into the code jar, or you put it next to it), install this newly
> created bundle, refresh it and here you go.

Sorry i know my english is terrible, but i did'nt know that i'm so much
not understandable. I wish to add *DYNAMICALLY* jar files to my plugin
classloader.

Dynamically means i do not know the url of the jar before runtime and
thats why i can't create a such a Text Manifest file before!
Furthure more the jars comes from a third party so i can't add any text
configuration file to them.
I had tried it like you had describe but of course since there is no
manifest file i got an exception that the jar file i wish to add is not a
correct bundle. ;-((

It's really a pain to invest more than 20 hours for such a simple
classloading issue and it's frustrate me more and more. Furthure more the
osgi documentation is not free available, you have to pay with your
contact data, thats really against the eclipse open source idea from my
point of view.
However please, please, please tell me is there any chance to add
dynamically jars to a plugin classloader?? I just wish to get an pointer
to a code location in eclipse that use this mechanism successfully.

Thanks a lot for spending me light in this painfull osgi darkness.

Stefan
Re: [classloading] dynamic import / class cast exception [message #41464 is a reply to message #41434] Sun, 02 May 2004 23:04 Go to previous messageGo to next message
Erik Wistrand is currently offline Erik WistrandFriend
Messages: 9
Registered: July 2009
Junior Member
Stefan Groschupf wrote:


> Dynamically means i do not know the url of the jar before runtime and
> thats why i can't create a such a Text Manifest file before!

But you *can* create the manifest run-time ;)

The BundleContext.install method also accepts an inputstream
as argument, and your code can always:

1) scan the external jar file (without manifest),
using standard classes from the java.util.jar package
2) check which packages are present
3) create a manifest and wrap the entire external jar in a new
JarInputStream with the new manifest.
4) Install with BundleContext.install(stream, ...)

I guess the eclipse code has code to do similar to 3) somewhere, since
it imports old-style plugins. But I'm no eclipse expert. Someone with
exact pointers?

Sorry we didn't understand your problem until now.

/Erik W

--
Erik Wistrand, wistrand@knopflerfish.org
Re: [classloading] dynamic import / class cast exception [message #41482 is a reply to message #41434] Mon, 03 May 2004 00:31 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: pascal.ibm.canada

The osgi spec is available for free. On your comment I double checked.
On the osgi.org website, hover over "Resources" > "Specification
download" click. Then on the left you'll see something about
"specification download". It will only ask you to enter your email and
you are done. Nothing to pay!

I believe this is just a way for them to track how popular is osgi.

PaScaL

Stefan Groschupf wrote:

>>It is exactly the idea. When you know which jars to use, you "wrap it
>>up" into a bundle (basically you create a manifest.mf that you either
>>copy into the code jar, or you put it next to it), install this newly
>>created bundle, refresh it and here you go.
>
>
> Sorry i know my english is terrible, but i did'nt know that i'm so much
> not understandable. I wish to add *DYNAMICALLY* jar files to my plugin
> classloader.
>
> Dynamically means i do not know the url of the jar before runtime and
> thats why i can't create a such a Text Manifest file before!
> Furthure more the jars comes from a third party so i can't add any text
> configuration file to them.
> I had tried it like you had describe but of course since there is no
> manifest file i got an exception that the jar file i wish to add is not a
> correct bundle. ;-((
>
> It's really a pain to invest more than 20 hours for such a simple
> classloading issue and it's frustrate me more and more. Furthure more the
> osgi documentation is not free available, you have to pay with your
> contact data, thats really against the eclipse open source idea from my
> point of view.
> However please, please, please tell me is there any chance to add
> dynamically jars to a plugin classloader?? I just wish to get an pointer
> to a code location in eclipse that use this mechanism successfully.
>
> Thanks a lot for spending me light in this painfull osgi darkness.
>
> Stefan
>
Re: [classloading] dynamic import / class cast exception [message #41503 is a reply to message #41434] Mon, 03 May 2004 01:21 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: pascal.ibm.canada

I understood your problem and thought the explanations were clear :-(

The osgi classloaders implemented in eclipse do not support addition of
jars on the classpath (even using non-API methods). This kind of thing
used to work in eclipse when you were using non-API classes.
However osgi supports something similar with its dynamic imports
capability although it is not exactly like adding a jar on the classpath.

Let me clarify. Suppose you have a bundle A that needs to see classes
from a jar that is not around yet. Because you can not directly add the
jar onto a bundle classpath, the idea consists in adding a bundle
containing the jar as a prerequisite of your bundle A. This will
virtually extends the classpath of your bundle A since the prerequisites
of a bundle are always searched before the actual jars.

To start, A on which you have ownership must have a manifest.mf which
looks like that (the important thing to note is the last line):

Bundle-Name: A
Bundle-SymbolicName: A
Bundle-Description: The bundle A that needs to load classes dynamically
Bundle-Copyright: Stefan
Bundle-Classpath: a.jar
Bundle-Vendor: Stefan
Bundle-Version: 1.0.0
DynamicImport-Package: *

This last line indicates that the bundle A, has on its classpath all the
classes that are exported by all the other bundles available, and that
therefore it can load any of them. It is of course more efficient if you
can restrict this set.

Now, when you know which jar should be added dynamically to A, you take
this jar (put it somewhere on disk), dynamically create a corresponding
manifest.mf for it, put the manifest in a meta-inf folder next to the
jar. With those two steps you just created a bundle. Now you just have
to install the newly created bundle and refresh it and refresh A. It is
best if A has not been started yet.

For example if you had the jar "small.jar", then you would create a
manifest like that

Bundle-Name: generated bundle
Bundle-SymbolicName: RandomName
Bundle-Description: The bundle that wraps the bundle small.jar
Bundle-Classpath: small.jar
Bundle-Copyright: Stefan
Bundle-Vendor: Stefan
Bundle-Version: 1.0.0
Export-Package:
small.package,
small.package2,
small.package3

The list of entries from export-package is generated by running through
the content of the jar. If you don't want to rewrite this code take a
look at the PluginConverterImpl in eclipse.

If we suppose that you copied the small.jar in c:/tmp, then you will
have c:/tmp/small.jar and c:/tmp/meta-inf/manifest.mf. This is your
bundle created on the fly.

Now you have to say somewhere:
Bundle b = bundleContext.install("file:c:/tmp/");
b.start(); //This is the simplest thing for now
which will install the newly created bundle.
You get a bundleContext as a parameter to the start method of a bundle
(for an example, create a dummy plugin with the pde wizard. There is
somewhere an osgi checkbox).

At the end of a session, you probably want to uninstall the bundle
dynamically created.

PaScaL

Stefan Groschupf wrote:

>>It is exactly the idea. When you know which jars to use, you "wrap it
>>up" into a bundle (basically you create a manifest.mf that you either
>>copy into the code jar, or you put it next to it), install this newly
>>created bundle, refresh it and here you go.
>
>
> Sorry i know my english is terrible, but i did'nt know that i'm so much
> not understandable. I wish to add *DYNAMICALLY* jar files to my plugin
> classloader.
>
> Dynamically means i do not know the url of the jar before runtime and
> thats why i can't create a such a Text Manifest file before!
> Furthure more the jars comes from a third party so i can't add any text
> configuration file to them.
> I had tried it like you had describe but of course since there is no
> manifest file i got an exception that the jar file i wish to add is not a
> correct bundle. ;-((
>
> It's really a pain to invest more than 20 hours for such a simple
> classloading issue and it's frustrate me more and more. Furthure more the
> osgi documentation is not free available, you have to pay with your
> contact data, thats really against the eclipse open source idea from my
> point of view.
> However please, please, please tell me is there any chance to add
> dynamically jars to a plugin classloader?? I just wish to get an pointer
> to a code location in eclipse that use this mechanism successfully.
>
> Thanks a lot for spending me light in this painfull osgi darkness.
>
> Stefan
>
Re: [classloading] dynamic import / class cast exception [message #41652 is a reply to message #41482] Mon, 03 May 2004 14:49 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: sg.removeme.media-style.com

> The osgi spec is available for free. On your comment I double checked.
> On the osgi.org website, hover over "Resources" > "Specification
> download" click. Then on the left you'll see something about
> "specification download". It will only ask you to enter your email and
> you are done. Nothing to pay!

Well, from my point of view only get the documentation for a email address
is not for free, you don't
need to pay money but you pay with a address. I really dont like this kind
of webpages where you only
get information if you give your personal information.

My be I had to often read texts from Stallman. By the way I'm still not
sure if the osgi license is
compliant with the eclipse license since OSGI (TM) is a trademark and the
spec is owned by the OSGI
Alliance. But how ever i'm no expert in this issues.
Re: [classloading] dynamic import / class cast exception [message #41684 is a reply to message #41503] Mon, 03 May 2004 15:26 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: sg.removeme.media-style.com

> Now you have to say somewhere:
> Bundle b = bundleContext.install("file:c:/tmp/");
> b.start(); //This is the simplest thing for now

Thanks a lot for investing so much time to help me, how ever this is no
practicable way for me.
Please remember I'm integrating jboss as plugin. You may be not know that
jboss are 60 MB of jar
files. To copy this files to a temp folder and scan the content takes
minutes. ;(

I'm asking my self in case someone will do a database gui plugin with
eclipse 3M8 how he would
dynamically load the jdbc driver? The same way you suggest it?
Everybody using dynamically class-loading have to scan jar files copy them
and do string
manipulation to create a manifest file?

Isn't it very circuitous?

Stefan
Re: [classloading] dynamic import / class cast exception [message #41714 is a reply to message #41652] Mon, 03 May 2004 17:14 Go to previous messageGo to next message
Erik Wistrand is currently offline Erik WistrandFriend
Messages: 9
Registered: July 2009
Junior Member
Stefan Groschupf wrote:
> Well, from my point of view only get the documentation for a email
> address is not for free, you don't need to pay money but you pay with
> a address. I really dont like this kind of webpages where you only
> get information if you give your personal information.

....and, finally, here we go:

http://www.osgi.org/resources/download/spec_download3.asp?Ac cept=Accept

Call it a trick, or whatever you like. But you don't have to provide
anything more than your source IP.

You are however right about the OSGi license text. It's quite untested
how it merges with other licenses. The intentention is however good.

Actually, it's *way* better than the original, pre OSGi-1 JCP license
which was the first attempt. Yes, JSR 8 was intended to define OSGi back
in -98/99.

regards,

/Erik W

--
Erik Wistrand, erik@wistrand.com
Re: [classloading] dynamic import / class cast exception [message #41745 is a reply to message #41684] Mon, 03 May 2004 19:28 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: ifedorenko.rogers.com

Stefan,

You don't need to copy JBoss anywhere, just create manifest somewhere
inside JBoss config directory structure. You don't have to recreate the
manifest every time, just check the timestamps.

To answer second part of your question. There are basically two
classloading scenarios. One scenario, is when your code does not
directly use external classes. This is the case for most JDBC
applications as they usually use java.sql.* and javax.sql.* classes
provided my JDK. Such applications can just create new classloader and
use this new classloader to access JDBC/JNDI/etc drivers. Other scenario
is when your code directly uses external classes. In this case you
cannot use new classloader to load these classes and have to go with
"new bundle" approach. You can read this bug report
https://bugs.eclipse.org/bugs/show_bug.cgi?id=50371 for more detailed
explanation of the problem.

Unfortunately, from my JBoss development days I remember that JBoss
clients fall to the second basket.


Stefan Groschupf wrote:
>>Now you have to say somewhere:
>> Bundle b = bundleContext.install("file:c:/tmp/");
>> b.start(); //This is the simplest thing for now
>
>
> Thanks a lot for investing so much time to help me, how ever this is no
> practicable way for me.
> Please remember I'm integrating jboss as plugin. You may be not know that
> jboss are 60 MB of jar
> files. To copy this files to a temp folder and scan the content takes
> minutes. ;(
>
> I'm asking my self in case someone will do a database gui plugin with
> eclipse 3M8 how he would
> dynamically load the jdbc driver? The same way you suggest it?
> Everybody using dynamically class-loading have to scan jar files copy them
> and do string
> manipulation to create a manifest file?
>
> Isn't it very circuitous?
>
> Stefan
>
>
>
Re: [classloading] dynamic import / class cast exception [message #41775 is a reply to message #41745] Tue, 04 May 2004 09:02 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: sg.removeme.media-style.com

Igor,

thanks a lot this bug describe exactly my problem.
I had vote for the bug and I think it would be good if as much as possible
other people can vote for it.
I really hope a bug fix will be in the next release since RCP without
dynamic class-loading is like a fish
without fins.

Thanks a lot for the light!
Stefan


Igor Fedorenko wrote:

> Stefan,

> You don't need to copy JBoss anywhere, just create manifest somewhere
> inside JBoss config directory structure. You don't have to recreate the
> manifest every time, just check the timestamps.

> To answer second part of your question. There are basically two
> classloading scenarios. One scenario, is when your code does not
> directly use external classes. This is the case for most JDBC
> applications as they usually use java.sql.* and javax.sql.* classes
> provided my JDK. Such applications can just create new classloader and
> use this new classloader to access JDBC/JNDI/etc drivers. Other scenario
> is when your code directly uses external classes. In this case you
> cannot use new classloader to load these classes and have to go with
> "new bundle" approach. You can read this bug report
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=50371 for more detailed
> explanation of the problem.

> Unfortunately, from my JBoss development days I remember that JBoss
> clients fall to the second basket.


> Stefan Groschupf wrote:
> >>Now you have to say somewhere:
> >> Bundle b = bundleContext.install("file:c:/tmp/");
> >> b.start(); //This is the simplest thing for now
> >
> >
> > Thanks a lot for investing so much time to help me, how ever this is no
> > practicable way for me.
> > Please remember I'm integrating jboss as plugin. You may be not know that
> > jboss are 60 MB of jar
> > files. To copy this files to a temp folder and scan the content takes
> > minutes. ;(
> >
> > I'm asking my self in case someone will do a database gui plugin with
> > eclipse 3M8 how he would
> > dynamically load the jdbc driver? The same way you suggest it?
> > Everybody using dynamically class-loading have to scan jar files copy them
> > and do string
> > manipulation to create a manifest file?
> >
> > Isn't it very circuitous?
> >
> > Stefan
> >
> >
> >
Re: [classloading] dynamic import / class cast exception [message #41866 is a reply to message #41775] Tue, 04 May 2004 15:22 Go to previous message
Eclipse UserFriend
Originally posted by: igorf.ca.ibm.com

Stefan,

I guess you got it wrong. Dynamic creation/installation of budles does
solve this problem. It may require more energy than it should, but it
works. The only part that is missing is a nice example that demonstrate
how to do that. I was going to provide one but unfortunately don't have
time.

Stefan Groschupf wrote:
> Igor,
>
> thanks a lot this bug describe exactly my problem.
> I had vote for the bug and I think it would be good if as much as possible
> other people can vote for it.
> I really hope a bug fix will be in the next release since RCP without
> dynamic class-loading is like a fish
> without fins.
>
> Thanks a lot for the light!
> Stefan
>
>
> Igor Fedorenko wrote:
>
>
>>Stefan,
>
>
>>You don't need to copy JBoss anywhere, just create manifest somewhere
>>inside JBoss config directory structure. You don't have to recreate the
>>manifest every time, just check the timestamps.
>
>
>>To answer second part of your question. There are basically two
>>classloading scenarios. One scenario, is when your code does not
>>directly use external classes. This is the case for most JDBC
>>applications as they usually use java.sql.* and javax.sql.* classes
>>provided my JDK. Such applications can just create new classloader and
>>use this new classloader to access JDBC/JNDI/etc drivers. Other scenario
>>is when your code directly uses external classes. In this case you
>>cannot use new classloader to load these classes and have to go with
>>"new bundle" approach. You can read this bug report
>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=50371 for more detailed
>>explanation of the problem.
>
>
>>Unfortunately, from my JBoss development days I remember that JBoss
>>clients fall to the second basket.
>
>
>
>>Stefan Groschupf wrote:
>>
>>>>Now you have to say somewhere:
>>>> Bundle b = bundleContext.install("file:c:/tmp/");
>>>> b.start(); //This is the simplest thing for now
>>>
>>>
>>>Thanks a lot for investing so much time to help me, how ever this is no
>>>practicable way for me.
>>>Please remember I'm integrating jboss as plugin. You may be not know that
>>>jboss are 60 MB of jar
>>>files. To copy this files to a temp folder and scan the content takes
>>>minutes. ;(
>>>
>>>I'm asking my self in case someone will do a database gui plugin with
>>>eclipse 3M8 how he would
>>>dynamically load the jdbc driver? The same way you suggest it?
>>>Everybody using dynamically class-loading have to scan jar files copy them
>>>and do string
>>>manipulation to create a manifest file?
>>>
>>>Isn't it very circuitous?
>>>
>>>Stefan
>>>
>>>
>>>
>
>
Previous Topic:jboss plugin
Next Topic:Customizable parent of classloaders
Goto Forum:
  


Current Time: Fri Apr 26 17:00:06 GMT 2024

Powered by FUDForum. Page generated in 0.04537 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top