Home » Archived » GMT (Generative Modeling Technologies) » [oaw] ClassLoader issue
| [oaw] ClassLoader issue [message #375702] |
Thu, 21 December 2006 22:00  |
Eclipse User |
|
|
|
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  |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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...
|
|
|
Goto Forum:
Current Time: Fri Apr 19 21:25:17 GMT 2024
Powered by FUDForum. Page generated in 0.02767 seconds |
] 
Search
Help
Register
Login
Home
