Home » Eclipse Projects » Equinox » Loading from 3rd party / user written jars, class not found exception
| Loading from 3rd party / user written jars, class not found exception [message #64413] |
Mon, 03 April 2006 16:44  |
Eclipse User |
|
|
|
This is a multipart message in MIME format.
--=_alternative 0071EE5985257145_=
Content-Type: text/plain; charset="US-ASCII"
Hi,
I've looked for a while trying to find a clean solution to the following
problems of loading classes.
We have a piece of code (a rule processor) that is a generic set of code
that can run either in a standard J2SE environment or it can be packaged
up and run in an Eclipse environment. This code has the capability of
loading and invoking java code was separately compiled and serialized into
a set of objects. These serialized objects can also have code which calls
or invokes other methods, either written by products that invoke us or by
end users of those products.
In a J2SE environment, the loading and running of the classes is easily
resolved via the definition of the classpath, but we are running into a
problem running this code in an Eclipse / OSGi environment
In Eclipse, we have packaged the core code into a plugin (A) that is a
common part for a series of other plugins, some of which are not produced
by our team or company.
The dependency order for this example is
pluginC (other product ) -> pluginB (our team) -> pluginA (our team).
When our plugin A attempts to load the java serialized objects (classes)
that reference code in pluginC, we experienced a class not found
exception, as pluginA is not dependent on pluginC so the plugin class
loader could not find the class reference.
We resolved that problem by coding the following MANIFEST.MF entry, "
Eclipse-BuddyPolicy : dependent" on plugin A. This option seems to
resolve the basic problem when the code is well-defined by a using
product and the jar file can be predefined and packaged in a plugin.
However, the problem we are running into is that pluginC also allows an
end user to define their own set of methods or classes that may need to
be invoked by pluginA. The names of the user written jar files or how
many jar files are created cannot be predicted in advance by pluginC .
These methods may be developed in the same Eclipse as pluginC, or they may
simply be prebuilt code or 3rd party jars. These methods are cleanly
compiled into the java code and serialized by a separate compiler (part of
pluginA / pluginB) because this compiler has a defined classpath in an
Eclipse Preference setting. However, when we go to invoke the code we
get a class not found exception. This is because the additional classes,
which were written by the end user, are not in our dependency chain, nor
are they defined on a classpath of a plugin that is dependent on us.
Asking the end user to create a separate plugin just to be able to import
the defined jar files and create the dependency link is not acceptable to
the products that are using us.
I've seen the "bundling by reference" discussions in this forum and wasn't
sure if that might be a possible solution. It might be an acceptable
solution if it can be defined a single environment variable and have a
list of jars in that environment variable (as long as each jar file
doesn't need to have individual entry in the MANIFEST.MF).
What we are looking for is a way to either define external 3rd party or
user jar files, or ideally, to update the bundle classpath to be able
to reference 3rd party or user written jars in the similar manner to how
we pass them thru to the compiler.
Thanks for any help.
Mack Phelps
--=_alternative 0071EE5985257145_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">I've looked for a while trying to find
a clean solution to the following problems of loading classes.</font>
<br>
<br><font size=2 face="sans-serif">We have a piece of code (a rule processor)
that is a generic set of code that can run either in a standard J2SE
environment or it can be packaged up and run in an Eclipse environment.
This code has the capability of loading and invoking java code
was separately compiled and serialized into a set of objects. These
serialized objects can also have code which calls or invokes other
methods, either written by products that invoke us or by end users of those
products. </font>
<br>
<br><font size=2 face="sans-serif">In a J2SE environment, the loading
and running of the classes is easily resolved via the definition of the
classpath, but we are running into a problem running this code in an Eclipse
/ OSGi environment</font>
<br>
<br><font size=2 face="sans-serif">In Eclipse, we have packaged the core
code into a plugin (A) that is a common part for a series
of other plugins, some of which are not produced by our team or company.
</font>
<br>
<br><font size=2 face="sans-serif">The dependency order for this example
is </font>
<br>
<br><font size=2 face="sans-serif">pluginC (other product ) ->
pluginB (our team) -> pluginA (our team). </font>
<br>
<br><font size=2 face="sans-serif">When our plugin A attempts to load the
java serialized objects (classes) that reference code in pluginC,
we experienced a class not found exception, as pluginA is not
dependent on pluginC so the plugin class loader could not find the class
reference. </font>
<br>
<br><font size=2 face="sans-serif">We resolved that problem by coding the
following MANIFEST.MF entry, " Eclipse-BuddyPolicy : dependent"
on plugin A. This option seems to resolve the basic
problem when the code is well-defined by a using product and the
jar file can be predefined and packaged in a plugin.</font>
<br>
<br><font size=2 face="sans-serif">However, the problem we are running
into is that pluginC also allows an end user to define their
own set of methods or classes that may need to be invoked by pluginA.
The names of the user written jar files or how many jar files are created
cannot be predicted in advance by pluginC . These methods may be
developed in the same Eclipse as pluginC, or they may simply be prebuilt
code or 3rd party jars. These methods are cleanly compiled into
the java code and serialized by a separate compiler (part of pluginA /
pluginB) because this compiler has a defined classpath in an Eclipse Preference
setting. However, when we go to invoke the code we get a
class not found exception. This is because the additional classes,
which were written by the end user, are not in our dependency
chain, nor are they defined on a classpath of a plugin that is dependent
on us.</font>
<br>
<br><font size=2 face="sans-serif">Asking the end user to create a separate
plugin just to be able to import the defined jar files and create the dependency
link is not acceptable to the products that are using us. </font>
<br>
<br><font size=2 face="sans-serif">I've seen the "bundling by reference"
discussions in this forum and wasn't sure if that might be a possible solution.
It might be an acceptable solution if it can be defined a single
environment variable and have a list of jars in that environment
variable (as long as each jar file doesn't need to have individual entry
in the MANIFEST.MF).</font>
<br>
<br><font size=2 face="sans-serif">What we are looking for is a way to
either define external 3rd party or user jar files, or ideally,
to update the bundle classpath to be able to reference 3rd party
or user written jars in the similar manner to how we pass them thru to
the compiler. </font>
<br>
<br><font size=2 face="sans-serif">Thanks for any help.</font>
<br>
<br><font size=2 face="sans-serif">Mack Phelps</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif"> </font>
<br>
<br>
--=_alternative 0071EE5985257145_=--
|
|
| |
| Re: Loading from 3rd party / user written jars, class not found exception [message #64529 is a reply to message #64461] |
Tue, 04 April 2006 09:50  |
| Eclipse User |
|
|
|
This is a multipart message in MIME format.
--=_alternative 004C112685257146_=
Content-Type: text/plain; charset="US-ASCII"
Harold,
Thanks for your response.
I guess I viewed "Eclipse-BuddyPolicy : dependent " and
"DynamicImport-Package : *" as being very similar in functionality, but
with the "Eclipse-BuddyPolicy: dependent" I was scoping the search of
bundles / plugins to a limited subset of the plugins that are dependent on
my pluginA, and possibly without quite the performance penalty of
DynamicImport-Package : *.
My issue is the user-written or 3rd party jars would not be defined in a
MANIFEST.MF (i.e., not packaged in a plugin), so I didn't think
"DynamicImport-Package: *" would have any way to resolve the classes.
I would like to see if there is any way to programatically or dynamically
add to a bundles classpath definition based on user input thru a form or a
preference setting, rather than require the jars all be predefined in the
bundle.
Sincerely,
Mack Phelps
--=_alternative 004C112685257146_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Harold,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for your response. </font>
<br>
<br><font size=2 face="sans-serif">I guess I viewed "Eclipse-BuddyPolicy
: dependent " and "DynamicImport-Package : *"
as being very similar in functionality, but with the "Eclipse-BuddyPolicy:
dependent" I was scoping the search of bundles / plugins to
a limited subset of the plugins that are dependent on my pluginA, and
possibly without quite the performance penalty of DynamicImport-Package
: *.</font>
<br>
<br><font size=2 face="sans-serif">My issue is the user-written or 3rd
party jars would not be defined in a MANIFEST.MF (i.e., not
packaged in a plugin), so I didn't think "DynamicImport-Package:
*" would have any way to resolve the classes. </font>
<br>
<br><font size=2 face="sans-serif">I would like to see if there is any
way to programatically or dynamically add to a bundles classpath
definition based on user input thru a form or a preference setting, rather
than require the jars all be predefined in the bundle.</font>
<br>
<br><font size=2 face="sans-serif">Sincerely,</font>
<br>
<br><font size=2 face="sans-serif">Mack Phelps</font>
--=_alternative 004C112685257146_=--
|
|
| |
Goto Forum:
Current Time: Fri Oct 31 11:25:03 EDT 2025
Powered by FUDForum. Page generated in 0.17721 seconds |
Home