Home » Eclipse Projects » Equinox » Bundles, classloaders and the Factory Pattern
| Bundles, classloaders and the Factory Pattern [message #47970] |
Fri, 13 May 2005 17:39  |
 Luis
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
I hope I am wrong, but I think that the Factory Pattern does not work when
the factory and object to create are in separate plugins / bundles /
classloaders.
If that is so, then, does this mean that the Factory Pattern cannot be used
out of the implementing plugin?
I have done a very simple test with two plugins:
pluginA contains two classes:
- Factory, which provides method "public ClassA create(String className)
throws Exception"
(the factory simply does a Class.forName(className).newInstance())
- ClassA, which provices method "public String hello()" (returning
"Hello from A")
pluginB contains two classes:
- ClassB, which extends from ClassA and re-implements hello() by
returning "Hello from B"
- RCPApplication, which is the plugin product entry point by
implementing method "public Object run(Object args) throws Exception"
What I am trying to model is that a given framework is provided as a plugin
and uses the factory pattern in order to create framework objects, which can
be extended and provided by the application code. This is a very typical
usage of this pattern, so it is very frequent for the factory to end up
instantiating classes that do not belong to the framework, but are extended
from the framework by the application code, which is in another plugin.
In a real scenario, the create() method would probably go to an XML file and
match the component ID with its class name.
So when, from RCPApplication.run() I do:
Factory f;
ClassA obj;
f = new Factory();
obj = f.create("test.classloader.plugin.a.ClassA");
System.out.println(obj.hello());
This successfully prints "Hello from A"
BUT, when I do:
obj = f.create("test.classloader.plugin.b.ClassB");
System.out.println(obj.hello());
I get:
java.lang.ClassNotFoundException: test.classloader.plugin.b.ClassB
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader
..java:404)
(etc...)
If you have read so far, I guess you see what I mean.
So... should I forget about using the factory pattern at all? This looks
very restrictive and drastic!!! And what do I do if I am trying to
"pluginize" an existing framework that has the factory method as its main
way of working?
Is there a way to avoid this problem, or even a workaround?
Of course there are drastic ways of getting rid of the problem, such as
merging the two plugins or forgetting about plugins at all and simply use
good old JARs, but then I would loose all the advantages of using plugins
such as the possibility of self-provisioning, etc.
I think this restriction looks so big that there MUST be a solution to it
within Eclipse. ...But it would not be the first time I find this problem:
in WAS, if I place the framework (with its factory) in the system classpath,
so that it can be shared by all applications, then I get the same problem as
it cannot find classes defined in the application classpath. In that case
the only workaround I know of is the brute-force approach of placing the
framework JAR in each and every application classpath.
And anyway, it's easy to say "each plugin has its own class loader", but
this is not so simple... otherwise, plugin B would have not been able to
instantiate the Factory class in the first time!! How does that get solved?
If pluginA is added to pluginB classpath, then the Factory is loaded by
pluginB classloader and then it would find ClassB!!!
This is very contradictory, now I am really confused! Argh!
I hope that someone can help me see the light... I have been searching both
eclise help and the web, but only found very dispersed statements here and
there.
Thanks in advance for your help,
Luis.
|
|
|
| Re: Bundles, classloaders and the Factory Pattern [message #48001 is a reply to message #47970] |
Fri, 13 May 2005 22:47  |
Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
If you are using eclipse, you should look into extension and extension
point. In your case the plugin A will provide an extension point, and
the plugin B will provide an extension to this extension point where it
will indicate the name of the class.
When A needs to create the instance of B, then it consults the
extensionRegistry (IExtensionRegistry) and use createExecutableExtension
on the configuration element.
It is really simple and makes the management much nicer.
PaScaL
Luis wrote:
> I hope I am wrong, but I think that the Factory Pattern does not work when
> the factory and object to create are in separate plugins / bundles /
> classloaders.
>
> If that is so, then, does this mean that the Factory Pattern cannot be used
> out of the implementing plugin?
>
> I have done a very simple test with two plugins:
>
> pluginA contains two classes:
> - Factory, which provides method "public ClassA create(String className)
> throws Exception"
> (the factory simply does a Class.forName(className).newInstance())
> - ClassA, which provices method "public String hello()" (returning
> "Hello from A")
>
> pluginB contains two classes:
> - ClassB, which extends from ClassA and re-implements hello() by
> returning "Hello from B"
> - RCPApplication, which is the plugin product entry point by
> implementing method "public Object run(Object args) throws Exception"
>
> What I am trying to model is that a given framework is provided as a plugin
> and uses the factory pattern in order to create framework objects, which can
> be extended and provided by the application code. This is a very typical
> usage of this pattern, so it is very frequent for the factory to end up
> instantiating classes that do not belong to the framework, but are extended
> from the framework by the application code, which is in another plugin.
> In a real scenario, the create() method would probably go to an XML file and
> match the component ID with its class name.
>
> So when, from RCPApplication.run() I do:
>
> Factory f;
> ClassA obj;
>
> f = new Factory();
> obj = f.create("test.classloader.plugin.a.ClassA");
> System.out.println(obj.hello());
>
> This successfully prints "Hello from A"
>
> BUT, when I do:
>
> obj = f.create("test.classloader.plugin.b.ClassB");
> System.out.println(obj.hello());
>
> I get:
> java.lang.ClassNotFoundException: test.classloader.plugin.b.ClassB
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader
> .java:404)
> (etc...)
>
> If you have read so far, I guess you see what I mean.
> So... should I forget about using the factory pattern at all? This looks
> very restrictive and drastic!!! And what do I do if I am trying to
> "pluginize" an existing framework that has the factory method as its main
> way of working?
> Is there a way to avoid this problem, or even a workaround?
>
> Of course there are drastic ways of getting rid of the problem, such as
> merging the two plugins or forgetting about plugins at all and simply use
> good old JARs, but then I would loose all the advantages of using plugins
> such as the possibility of self-provisioning, etc.
>
> I think this restriction looks so big that there MUST be a solution to it
> within Eclipse. ...But it would not be the first time I find this problem:
> in WAS, if I place the framework (with its factory) in the system classpath,
> so that it can be shared by all applications, then I get the same problem as
> it cannot find classes defined in the application classpath. In that case
> the only workaround I know of is the brute-force approach of placing the
> framework JAR in each and every application classpath.
>
> And anyway, it's easy to say "each plugin has its own class loader", but
> this is not so simple... otherwise, plugin B would have not been able to
> instantiate the Factory class in the first time!! How does that get solved?
> If pluginA is added to pluginB classpath, then the Factory is loaded by
> pluginB classloader and then it would find ClassB!!!
> This is very contradictory, now I am really confused! Argh!
>
> I hope that someone can help me see the light... I have been searching both
> eclise help and the web, but only found very dispersed statements here and
> there.
>
> Thanks in advance for your help,
>
>
> Luis.
>
>
|
|
|
| Re: Bundles, classloaders and the Factory Pattern [message #48122 is a reply to message #48001] |
Tue, 17 May 2005 08:40 |
Luis
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Pascal, thanks for your help.
This allows solving the problem in cases where one has the source code of
the framework, but what happens when only the binaries are available? In
such a case, as far as I know there is no other option than to throw that
framework away.
And even if you have access to the framework source code, then you may need
to create two versions of the framework: one for Eclipse environments and
another one for the rest of normal environments. Not a nice solution...
On the other hand, I was thinking on how can plugin B load a class from
plugin A, from a class loader that plugin B does not know. I think it works
because the two plugins share the same parent classloader, which is
responsible of routing class loading to the appropriate plugin's
classloader. Can anyone confirm that?
Thanks,
Luis.
"Pascal Rapicault" <pascal@ibm.canada> wrote in message
news:d63bba$8uh$1@news.eclipse.org...
> If you are using eclipse, you should look into extension and extension
> point. In your case the plugin A will provide an extension point, and
> the plugin B will provide an extension to this extension point where it
> will indicate the name of the class.
>
> When A needs to create the instance of B, then it consults the
> extensionRegistry (IExtensionRegistry) and use createExecutableExtension
> on the configuration element.
>
> It is really simple and makes the management much nicer.
>
> PaScaL
>
> Luis wrote:
> > I hope I am wrong, but I think that the Factory Pattern does not work
when
> > the factory and object to create are in separate plugins / bundles /
> > classloaders.
> >
> > If that is so, then, does this mean that the Factory Pattern cannot be
used
> > out of the implementing plugin?
> >
> > I have done a very simple test with two plugins:
> >
> > pluginA contains two classes:
> > - Factory, which provides method "public ClassA create(String
className)
> > throws Exception"
> > (the factory simply does a
Class.forName(className).newInstance())
> > - ClassA, which provices method "public String hello()" (returning
> > "Hello from A")
> >
> > pluginB contains two classes:
> > - ClassB, which extends from ClassA and re-implements hello() by
> > returning "Hello from B"
> > - RCPApplication, which is the plugin product entry point by
> > implementing method "public Object run(Object args) throws Exception"
> >
> > What I am trying to model is that a given framework is provided as a
plugin
> > and uses the factory pattern in order to create framework objects, which
can
> > be extended and provided by the application code. This is a very typical
> > usage of this pattern, so it is very frequent for the factory to end up
> > instantiating classes that do not belong to the framework, but are
extended
> > from the framework by the application code, which is in another plugin.
> > In a real scenario, the create() method would probably go to an XML file
and
> > match the component ID with its class name.
> >
> > So when, from RCPApplication.run() I do:
> >
> > Factory f;
> > ClassA obj;
> >
> > f = new Factory();
> > obj = f.create("test.classloader.plugin.a.ClassA");
> > System.out.println(obj.hello());
> >
> > This successfully prints "Hello from A"
> >
> > BUT, when I do:
> >
> > obj = f.create("test.classloader.plugin.b.ClassB");
> > System.out.println(obj.hello());
> >
> > I get:
> > java.lang.ClassNotFoundException: test.classloader.plugin.b.ClassB
> > at
> >
org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader
> > .java:404)
> > (etc...)
> >
> > If you have read so far, I guess you see what I mean.
> > So... should I forget about using the factory pattern at all? This looks
> > very restrictive and drastic!!! And what do I do if I am trying to
> > "pluginize" an existing framework that has the factory method as its
main
> > way of working?
> > Is there a way to avoid this problem, or even a workaround?
> >
> > Of course there are drastic ways of getting rid of the problem, such as
> > merging the two plugins or forgetting about plugins at all and simply
use
> > good old JARs, but then I would loose all the advantages of using
plugins
> > such as the possibility of self-provisioning, etc.
> >
> > I think this restriction looks so big that there MUST be a solution to
it
> > within Eclipse. ...But it would not be the first time I find this
problem:
> > in WAS, if I place the framework (with its factory) in the system
classpath,
> > so that it can be shared by all applications, then I get the same
problem as
> > it cannot find classes defined in the application classpath. In that
case
> > the only workaround I know of is the brute-force approach of placing the
> > framework JAR in each and every application classpath.
> >
> > And anyway, it's easy to say "each plugin has its own class loader", but
> > this is not so simple... otherwise, plugin B would have not been able to
> > instantiate the Factory class in the first time!! How does that get
solved?
> > If pluginA is added to pluginB classpath, then the Factory is loaded by
> > pluginB classloader and then it would find ClassB!!!
> > This is very contradictory, now I am really confused! Argh!
> >
> > I hope that someone can help me see the light... I have been searching
both
> > eclise help and the web, but only found very dispersed statements here
and
> > there.
> >
> > Thanks in advance for your help,
> >
> >
> > Luis.
> >
> >
|
|
|
| Re: Bundles, classloaders and the Factory Pattern [message #48288 is a reply to message #48122] |
Sat, 21 May 2005 12:08 |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
If you don't have the code or can't modify it, then you should use the
buddy classloading mechanism described in bug 87775.
It has been introduced especially to solve the kind of issues you are
talking here.
PaScaL
Luis wrote:
> Pascal, thanks for your help.
>
> This allows solving the problem in cases where one has the source code of
> the framework, but what happens when only the binaries are available? In
> such a case, as far as I know there is no other option than to throw that
> framework away.
>
> And even if you have access to the framework source code, then you may need
> to create two versions of the framework: one for Eclipse environments and
> another one for the rest of normal environments. Not a nice solution...
>
> On the other hand, I was thinking on how can plugin B load a class from
> plugin A, from a class loader that plugin B does not know. I think it works
> because the two plugins share the same parent classloader, which is
> responsible of routing class loading to the appropriate plugin's
> classloader. Can anyone confirm that?
>
> Thanks,
>
> Luis.
>
>
> "Pascal Rapicault" <pascal@ibm.canada> wrote in message
> news:d63bba$8uh$1@news.eclipse.org...
>
>>If you are using eclipse, you should look into extension and extension
>>point. In your case the plugin A will provide an extension point, and
>>the plugin B will provide an extension to this extension point where it
>>will indicate the name of the class.
>>
>>When A needs to create the instance of B, then it consults the
>>extensionRegistry (IExtensionRegistry) and use createExecutableExtension
>>on the configuration element.
>>
>>It is really simple and makes the management much nicer.
>>
>>PaScaL
>>
>>Luis wrote:
>>
>>>I hope I am wrong, but I think that the Factory Pattern does not work
>
> when
>
>>>the factory and object to create are in separate plugins / bundles /
>>>classloaders.
>>>
>>>If that is so, then, does this mean that the Factory Pattern cannot be
>
> used
>
>>>out of the implementing plugin?
>>>
>>>I have done a very simple test with two plugins:
>>>
>>>pluginA contains two classes:
>>> - Factory, which provides method "public ClassA create(String
>
> className)
>
>>>throws Exception"
>>> (the factory simply does a
>
> Class.forName(className).newInstance())
>
>>> - ClassA, which provices method "public String hello()" (returning
>>>"Hello from A")
>>>
>>>pluginB contains two classes:
>>> - ClassB, which extends from ClassA and re-implements hello() by
>>>returning "Hello from B"
>>> - RCPApplication, which is the plugin product entry point by
>>>implementing method "public Object run(Object args) throws Exception"
>>>
>>>What I am trying to model is that a given framework is provided as a
>
> plugin
>
>>>and uses the factory pattern in order to create framework objects, which
>
> can
>
>>>be extended and provided by the application code. This is a very typical
>>>usage of this pattern, so it is very frequent for the factory to end up
>>>instantiating classes that do not belong to the framework, but are
>
> extended
>
>>>from the framework by the application code, which is in another plugin.
>>>In a real scenario, the create() method would probably go to an XML file
>
> and
>
>>>match the component ID with its class name.
>>>
>>>So when, from RCPApplication.run() I do:
>>>
>>> Factory f;
>>> ClassA obj;
>>>
>>> f = new Factory();
>>> obj = f.create("test.classloader.plugin.a.ClassA");
>>> System.out.println(obj.hello());
>>>
>>>This successfully prints "Hello from A"
>>>
>>>BUT, when I do:
>>>
>>> obj = f.create("test.classloader.plugin.b.ClassB");
>>> System.out.println(obj.hello());
>>>
>>>I get:
>>> java.lang.ClassNotFoundException: test.classloader.plugin.b.ClassB
>>> at
>>>
>
> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader
>
>>>.java:404)
>>> (etc...)
>>>
>>>If you have read so far, I guess you see what I mean.
>>>So... should I forget about using the factory pattern at all? This looks
>>>very restrictive and drastic!!! And what do I do if I am trying to
>>>"pluginize" an existing framework that has the factory method as its
>
> main
>
>>>way of working?
>>>Is there a way to avoid this problem, or even a workaround?
>>>
>>>Of course there are drastic ways of getting rid of the problem, such as
>>>merging the two plugins or forgetting about plugins at all and simply
>
> use
>
>>>good old JARs, but then I would loose all the advantages of using
>
> plugins
>
>>>such as the possibility of self-provisioning, etc.
>>>
>>>I think this restriction looks so big that there MUST be a solution to
>
> it
>
>>>within Eclipse. ...But it would not be the first time I find this
>
> problem:
>
>>>in WAS, if I place the framework (with its factory) in the system
>
> classpath,
>
>>>so that it can be shared by all applications, then I get the same
>
> problem as
>
>>>it cannot find classes defined in the application classpath. In that
>
> case
>
>>>the only workaround I know of is the brute-force approach of placing the
>>>framework JAR in each and every application classpath.
>>>
>>>And anyway, it's easy to say "each plugin has its own class loader", but
>>>this is not so simple... otherwise, plugin B would have not been able to
>>>instantiate the Factory class in the first time!! How does that get
>
> solved?
>
>>>If pluginA is added to pluginB classpath, then the Factory is loaded by
>>>pluginB classloader and then it would find ClassB!!!
>>>This is very contradictory, now I am really confused! Argh!
>>>
>>>I hope that someone can help me see the light... I have been searching
>
> both
>
>>>eclise help and the web, but only found very dispersed statements here
>
> and
>
>>>there.
>>>
>>>Thanks in advance for your help,
>>>
>>>
>>> Luis.
>>>
>>>
>
>
>
|
|
|
| Re: Bundles, classloaders and the Factory Pattern [message #48316 is a reply to message #48288] |
Mon, 23 May 2005 16:18 |
Luis
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
After looking at the bug, apparently this involves applying a patch to the
RCP platform and then adding some entries in the OSGi manifest file. Could
you please confirm? There is not much explanation in the bug report, and I
am not involved in the development of the platform, so there are some things
I don't understand.
Anyway, what are the advantages of having a separate classloader for each
plugin? Why was that design decision taken?
Until now, I have only found problems and no advantage. The factory
classloading mechanism is used very frequently, and other patterns are also
impacted by this separation.
Is there a way to programatically add a plugin to the list of required
plugins of another plugin? If so, is the API public? That would also solve
the problem. Maybe the buddy classloading mechanism has something to do with
that.
Sorry for being so inquisitive ;-).
Thanks,
Luis.
"Pascal Rapicault" <pascal@ibm.canada> wrote in message
news:d6n8eh$vv7$1@news.eclipse.org...
> If you don't have the code or can't modify it, then you should use the
> buddy classloading mechanism described in bug 87775.
>
> It has been introduced especially to solve the kind of issues you are
> talking here.
>
> PaScaL
>
>
> Luis wrote:
> > Pascal, thanks for your help.
> >
> > This allows solving the problem in cases where one has the source code
of
> > the framework, but what happens when only the binaries are available? In
> > such a case, as far as I know there is no other option than to throw
that
> > framework away.
> >
> > And even if you have access to the framework source code, then you may
need
> > to create two versions of the framework: one for Eclipse environments
and
> > another one for the rest of normal environments. Not a nice solution...
> >
> > On the other hand, I was thinking on how can plugin B load a class from
> > plugin A, from a class loader that plugin B does not know. I think it
works
> > because the two plugins share the same parent classloader, which is
> > responsible of routing class loading to the appropriate plugin's
> > classloader. Can anyone confirm that?
> >
> > Thanks,
> >
> > Luis.
> >
> >
> > "Pascal Rapicault" <pascal@ibm.canada> wrote in message
> > news:d63bba$8uh$1@news.eclipse.org...
> >
> >>If you are using eclipse, you should look into extension and extension
> >>point. In your case the plugin A will provide an extension point, and
> >>the plugin B will provide an extension to this extension point where it
> >>will indicate the name of the class.
> >>
> >>When A needs to create the instance of B, then it consults the
> >>extensionRegistry (IExtensionRegistry) and use createExecutableExtension
> >>on the configuration element.
> >>
> >>It is really simple and makes the management much nicer.
> >>
> >>PaScaL
> >>
> >>Luis wrote:
> >>
> >>>I hope I am wrong, but I think that the Factory Pattern does not work
> >
> > when
> >
> >>>the factory and object to create are in separate plugins / bundles /
> >>>classloaders.
> >>>
> >>>If that is so, then, does this mean that the Factory Pattern cannot be
> >
> > used
> >
> >>>out of the implementing plugin?
> >>>
> >>>I have done a very simple test with two plugins:
> >>>
> >>>pluginA contains two classes:
> >>> - Factory, which provides method "public ClassA create(String
> >
> > className)
> >
> >>>throws Exception"
> >>> (the factory simply does a
> >
> > Class.forName(className).newInstance())
> >
> >>> - ClassA, which provices method "public String hello()" (returning
> >>>"Hello from A")
> >>>
> >>>pluginB contains two classes:
> >>> - ClassB, which extends from ClassA and re-implements hello() by
> >>>returning "Hello from B"
> >>> - RCPApplication, which is the plugin product entry point by
> >>>implementing method "public Object run(Object args) throws Exception"
> >>>
> >>>What I am trying to model is that a given framework is provided as a
> >
> > plugin
> >
> >>>and uses the factory pattern in order to create framework objects,
which
> >
> > can
> >
> >>>be extended and provided by the application code. This is a very
typical
> >>>usage of this pattern, so it is very frequent for the factory to end up
> >>>instantiating classes that do not belong to the framework, but are
> >
> > extended
> >
> >>>from the framework by the application code, which is in another plugin.
> >>>In a real scenario, the create() method would probably go to an XML
file
> >
> > and
> >
> >>>match the component ID with its class name.
> >>>
> >>>So when, from RCPApplication.run() I do:
> >>>
> >>> Factory f;
> >>> ClassA obj;
> >>>
> >>> f = new Factory();
> >>> obj = f.create("test.classloader.plugin.a.ClassA");
> >>> System.out.println(obj.hello());
> >>>
> >>>This successfully prints "Hello from A"
> >>>
> >>>BUT, when I do:
> >>>
> >>> obj = f.create("test.classloader.plugin.b.ClassB");
> >>> System.out.println(obj.hello());
> >>>
> >>>I get:
> >>> java.lang.ClassNotFoundException: test.classloader.plugin.b.ClassB
> >>> at
> >>>
> >
> >
org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader
> >
> >>>.java:404)
> >>> (etc...)
> >>>
> >>>If you have read so far, I guess you see what I mean.
> >>>So... should I forget about using the factory pattern at all? This
looks
> >>>very restrictive and drastic!!! And what do I do if I am trying to
> >>>"pluginize" an existing framework that has the factory method as its
> >
> > main
> >
> >>>way of working?
> >>>Is there a way to avoid this problem, or even a workaround?
> >>>
> >>>Of course there are drastic ways of getting rid of the problem, such as
> >>>merging the two plugins or forgetting about plugins at all and simply
> >
> > use
> >
> >>>good old JARs, but then I would loose all the advantages of using
> >
> > plugins
> >
> >>>such as the possibility of self-provisioning, etc.
> >>>
> >>>I think this restriction looks so big that there MUST be a solution to
> >
> > it
> >
> >>>within Eclipse. ...But it would not be the first time I find this
> >
> > problem:
> >
> >>>in WAS, if I place the framework (with its factory) in the system
> >
> > classpath,
> >
> >>>so that it can be shared by all applications, then I get the same
> >
> > problem as
> >
> >>>it cannot find classes defined in the application classpath. In that
> >
> > case
> >
> >>>the only workaround I know of is the brute-force approach of placing
the
> >>>framework JAR in each and every application classpath.
> >>>
> >>>And anyway, it's easy to say "each plugin has its own class loader",
but
> >>>this is not so simple... otherwise, plugin B would have not been able
to
> >>>instantiate the Factory class in the first time!! How does that get
> >
> > solved?
> >
> >>>If pluginA is added to pluginB classpath, then the Factory is loaded by
> >>>pluginB classloader and then it would find ClassB!!!
> >>>This is very contradictory, now I am really confused! Argh!
> >>>
> >>>I hope that someone can help me see the light... I have been searching
> >
> > both
> >
> >>>eclise help and the web, but only found very dispersed statements here
> >
> > and
> >
> >>>there.
> >>>
> >>>Thanks in advance for your help,
> >>>
> >>>
> >>> Luis.
> >>>
> >>>
> >
> >
> >
|
|
|
Goto Forum:
Current Time: Thu Sep 26 12:55:02 GMT 2024
Powered by FUDForum. Page generated in 0.04080 seconds |
] 
Search
Help
Register
Login
Home
