Home » Eclipse Projects » Equinox » [classloading] dynamic import / class cast exception
| [classloading] dynamic import / class cast exception [message #41071] |
Fri, 30 April 2004 11:39  |
Eclipse User |
|
|
|
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 #41254 is a reply to message #41223] |
Sat, 01 May 2004 18:46  |
| Eclipse User |
|
|
|
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 #41407 is a reply to message #41377] |
Sun, 02 May 2004 12:39 |
| Eclipse User |
|
|
|
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 14:02 |
| Eclipse User |
|
|
|
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 #41482 is a reply to message #41434] |
Sun, 02 May 2004 20:31 |
| Eclipse User |
|
|
|
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] |
Sun, 02 May 2004 21:21 |
| Eclipse User |
|
|
|
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 #41714 is a reply to message #41652] |
Mon, 03 May 2004 13:14 |
| Eclipse User |
|
|
|
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 #41866 is a reply to message #41775] |
Tue, 04 May 2004 11:22 |
| Eclipse User |
|
|
|
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
>>>
>>>
>>>
>
>
|
|
|
Goto Forum:
Current Time: Mon Apr 28 03:38:44 EDT 2025
Powered by FUDForum. Page generated in 0.31663 seconds |
Home