Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMT (Generative Modeling Technologies) » [oaw] ClassLoader issue
[oaw] ClassLoader issue [message #375702] Thu, 21 December 2006 22:00 Go to next message
Eclipse UserFriend
Originally posted by: tobiasbuhr.gmx.de

Hi all,

again it has to do with invoking an xtend m2m-transformation using the
JavaMetaModel.

Problem:

if I invoke my workflow via Platform - Run as oaw-Workflow it goes fine,

but

if I invoke the same workflow from my own plugin code, my self-defined
type won't be resolved (using JavaMetaModel):

'Couldn't resolve type for javahelpers::AJavaClass'

I examined a lot and came to the conclusion, that the problem has to do
with the used classloader. Debugging yields:

Platform - run as oaw: java.lang.classloader is used, knowing around 600
classes, everything, I might need ;-)

my plugin: org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader is
used, but it does not know my javahelpers::AJavaClass :-(

I tried to add

Export-Package: javahelpers,
sampleplugin.ui,
sampleplugin.ui.popup.actions

to the manifest, but it still does not work...

Anyone some idea????

For testing, I uploaded my minimalistic plugin to
<tbuhr.de/oaw_javamm_sample.zip>

Thanks for your time, Tobias
Re: [oaw] ClassLoader issue [message #375707 is a reply to message #375702] Fri, 22 December 2006 13:16 Go to previous message
Eclipse UserFriend
Originally posted by: tobiasbuhr.gmx.de

In the oaw-forum, I got the following answer (sorry for redundant posts,
do not know any better up to now)

Achim wrote:
< http://www.openarchitectureware.org/forum/viewtopic.php?foru m=2&showtopic=2874&lastpost=true>
> In Eclipse/OSGi every plugin (bundle) has its own classloader.
> From your plugin, you reference (i.e. Require_Bundle) the oaw
> workflow plugin, so your plugin knows about the workflow
> plugin's exported classes.

> Since the workflow plugin does not reference your plugin, it
> cannot find your classes. It simply cannot, because

> a) the workflow plugin does not know about your plugin at
> compile time
> b) this would result in a circular dependeny

> You could use Buddy classloaders to avoid this, but this requires
> to oaw workflow plugin to declare Buddy classloading in its
> MANIFEST. Sven should have a say on this.

> Using a launch configuration avoid this problem, since it
> actually launches a separate VM to execute the workflow,
> and in this VM, there is no Eclipse/OSGi environment and
> classloading works as expected: Anything you declare in your
> project's classpath can be found by anyone.

and I answered:

Hi Achim,

your answer describes sad facts Rolling Eyes

I found a solution, similar to your advice with the buddy policies:

I added my javahelpers as a required plugin to oaw.core.expression
(where JavaMetaModel is declared) a now it works.. (I avoided the
circular dependency by moving javahelpers into its own pluging).

Of course this is a kludge, but for now, I will use it that way.

Still I think, there must be a better way. When you think at the
EMF-Metamodels, these are plugins not known by oaw directly, but will
always be recognized correctly. (eg.
EcoreUtil2.getEPackageByClassName("EcorePackage") finds the needed type)
Question

Merry christmas, Tobias
// still will do some research on how EmfMetaModel does its type-finding
(this works obviously better) -- but would be very happy about some
experts helping...
Re: [oaw] ClassLoader issue [message #560633 is a reply to message #375702] Fri, 22 December 2006 13:16 Go to previous message
Eclipse UserFriend
Originally posted by: tobiasbuhr.gmx.de

In the oaw-forum, I got the following answer (sorry for redundant posts,
do not know any better up to now)

Achim wrote:
< http://www.openarchitectureware.org/forum/viewtopic.php?foru m=2&showtopic=2874&lastpost=true>
> In Eclipse/OSGi every plugin (bundle) has its own classloader.
> From your plugin, you reference (i.e. Require_Bundle) the oaw
> workflow plugin, so your plugin knows about the workflow
> plugin's exported classes.

> Since the workflow plugin does not reference your plugin, it
> cannot find your classes. It simply cannot, because

> a) the workflow plugin does not know about your plugin at
> compile time
> b) this would result in a circular dependeny

> You could use Buddy classloaders to avoid this, but this requires
> to oaw workflow plugin to declare Buddy classloading in its
> MANIFEST. Sven should have a say on this.

> Using a launch configuration avoid this problem, since it
> actually launches a separate VM to execute the workflow,
> and in this VM, there is no Eclipse/OSGi environment and
> classloading works as expected: Anything you declare in your
> project's classpath can be found by anyone.

and I answered:

Hi Achim,

your answer describes sad facts Rolling Eyes

I found a solution, similar to your advice with the buddy policies:

I added my javahelpers as a required plugin to oaw.core.expression
(where JavaMetaModel is declared) a now it works.. (I avoided the
circular dependency by moving javahelpers into its own pluging).

Of course this is a kludge, but for now, I will use it that way.

Still I think, there must be a better way. When you think at the
EMF-Metamodels, these are plugins not known by oaw directly, but will
always be recognized correctly. (eg.
EcoreUtil2.getEPackageByClassName("EcorePackage") finds the needed type)
Question

Merry christmas, Tobias
// still will do some research on how EmfMetaModel does its type-finding
(this works obviously better) -- but would be very happy about some
experts helping...
Previous Topic:[oaw] ClassLoader issue
Next Topic:Re: [GEMS] linux/gtk vs. macosx
Goto Forum:
  


Current Time: Thu Dec 18 07:32:09 GMT 2014

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

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