Home » Eclipse Projects » Rich Client Platform (RCP) » classloader or packaging problem?
| |
| Re: classloader or packaging problem? [message #436611 is a reply to message #436601] |
Wed, 14 September 2005 07:07   |
 Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
Boris Bokowski wrote:
> I think you need to either patch the SWT jar, or provide a fragment with the
> additional class.
Thank you very much for your answer, Boris! Would you be so nice and
explain somewhat more detailed the reasons for this behaviour?
And what do you mean by patching the SWT jar? (Actually I used the swt
package as an language "trick" to get access to the
Spinner.getSelectionText() method. To my opinion this is a legal one.
Is the reason to use a fragment (project) related to another
class-loader policy of fragments?
Thank you very much and
Greetings from Bremen,
Daniel
>
> Boris
>
> "Daniel Krügler" <dsp@bdal.de> wrote in message
> news:dg61hl$kfd$1@news.eclipse.org...
>
>>Hello,
>>
>>since currently the modify event of Spinner does not allow
>>access to the current content of the spinner, (see
>>
>>https://bugs.eclipse.org/bugs/show_bug.cgi?id=100363
>>
>>) I tried to workaround this by performing the following
>>steps:
>>
>>In my ui-helper plugin I created a Workaround class in
>>the org.eclipse.swt.widgets package (to get access to the default
>>visible Spinner.getSelectionText() method), as described below:
>>
>>/////////////////////////////////////
>>package org.eclipse.swt.widgets;
>>
>>public class Workaround {
>>
>> public final static int getSelectionText(Spinner spinner) {
>> final int result = spinner.getSelectionText();
>> return result;
>> }
>>
>>}
>>/////////////////////////////////////
>>
>>but calling this static function in my client code leads to an
>>java.lang.IllegalAccessError, as seen below in the abridged log file.
>>Do I stumble about a language corner-case or is this a packaging problem?
>>
>>Thank you in advance,
>>
>>Daniel Krügler
>>
>>
>>
>>!SESSION 2005-09-13 10:01:27.280
>>-----------------------------------------------
>>eclipse.buildId=unknown
>>java.version=1.5.0_04
>>java.vendor=Sun Microsystems Inc.
>>BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
>>Framework arguments: -product MyProduct.client.ui.ide -pdelaunch
>>Command-line arguments: -product MyProduct.client.ui.ide -data
>>MyPath\MyProduct -dev
>>
>
> file:AnyPath/workspace/.metadata/.plugins/org.eclipse.pde.co re/MyProduct/dev.properties
>
>>-pdelaunch -os win32 -ws win32 -arch x86 -data @noDefault
>>
>>!ENTRY org.eclipse.ui 4 0 2005-09-13 10:01:40.936
>>!MESSAGE tried to access method
>>org.eclipse.swt.widgets.Spinner.getSelectionText()I from class
>>org.eclipse.swt.widgets.Workaround
>>!STACK 0
>>java.lang.IllegalAccessError: tried to access method
>>org.eclipse.swt.widgets.Spinner.getSelectionText()I from class
>>org.eclipse.swt.widgets.Workaround
>>at org.eclipse.swt.widgets.Workaround.getSelectionText(Workarou nd.java:31)
>>at
>>
>
> WhatEver.common.ui.binding.SpinnerAdapter$1.modifyText(Spinn erAdapter.java:5
> 6)
>
>>at
>> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:188)
>>at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
>>at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:843)
>>at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:867)
>>at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:848)
>>at org.eclipse.swt.widgets.Spinner.wmCommandChild(Spinner.java: 1171)
>>at org.eclipse.swt.widgets.Control.WM_COMMAND(Control.java:3164 )
>>at org.eclipse.swt.widgets.Control.windowProc(Control.java:3041 )
>>at org.eclipse.swt.widgets.Spinner.windowProc(Spinner.java:1042 )
>>at org.eclipse.swt.widgets.Display.windowProc(Display.java:3706 )
>>at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method)
>>at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:158 0)
>>at org.eclipse.swt.widgets.Spinner.callWindowProc(Spinner.java: 88)
>>at org.eclipse.swt.widgets.Spinner.windowProc(Spinner.java:1040 )
>>at org.eclipse.swt.widgets.Display.windowProc(Display.java:3706 )
>>at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
>>at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:16 56)
>>at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2711)
>>at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1699)
>>at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1663)
>>at
>>
>
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:367)
>
>>at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:143)
>>at WhatEver.MyApp.client.ui.AppMain.run(AppMain.java:60)
>>at
>>
>
> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.
> java:226)
>
>>at
>>
>
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:376)
>
>>at
>>
>
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:163)
>
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>at java.lang.reflect.Method.invoke(Unknown Source)
>>at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334 )
>>at org.eclipse.core.launcher.Main.basicRun(Main.java:278)
>>at org.eclipse.core.launcher.Main.run(Main.java:973)
>>at org.eclipse.core.launcher.Main.main(Main.java:948)
>
>
>
|
|
|
| Re: classloader or packaging problem? [message #436662 is a reply to message #436611] |
Wed, 14 September 2005 12:53 |
Alex Blewitt
Messages: 946
Registered: July 2009 |
Senior Member |
|
|
The problem is that the SWT jar will be loaded in a seperate classloader to your patch, and thus will be seen as a different package (although the names are the same) resulting in the IllegalAccesError.
A fragment is like a plugin, but the contents of the fragment are merged with the plugin before being loaded by the classloader, so anything that's visible/accessible in the plugin is visible from the fragment, and vice versa. Additionally, where files that are the same in both the fragment and plugin, the ones in the fragment will take precedence, so it's a great way of shipping 'delta' patches for plugins.
In this example, you want to fix the SWT, so create a fragment to the SWT plugin and enclose your spinner class. It should then be able to access the package-level methods, and give you the result you're looking for.
http://help.eclipse.org/help31/topic/org.eclipse.pde.doc.use r/guide/pde_fragment_example.htm
|
|
|
| Re: classloader or packaging problem? [message #436667 is a reply to message #436662] |
Wed, 14 September 2005 13:52 |
Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
Alex Blewitt wrote:
> The problem is that the SWT jar will be loaded in a seperate
> classloader to your patch, and thus will be seen as a different
> package (although the names are the same) resulting in the
> IllegalAccesError.
>
OK, now I see that my assumption was right concerning the class loader,
although I was not aware of the details, buts please wait...
> A fragment is like a plugin, but the contents of the fragment are
> merged with the plugin before being loaded by the classloader, so
> anything that's visible/accessible in the plugin is visible from the
> fragment, and vice versa. Additionally, where files that are the same
> in both the fragment and plugin, the ones in the fragment will take
> precedence, so it's a great way of shipping 'delta' patches for
> plugins.
>
> In this example, you want to fix the SWT, so create a fragment to the
> SWT plugin and enclose your spinner class. It should then be able to
> access the package-level methods, and give you the result you're
> looking for.
>
> http://help.eclipse.org/help31/topic/org.eclipse.pde.doc.use r/guide/pde_fragment_example.htm
Hmmh, actually I really don't want to enclose my **own** Spinner class,
I really **only** want to get access to the getSelectionText method,
which has package (default) accessibility. Can I realize this task with
the same procedure? I tried the following:
I created a fragment project Whatever.swtpatch (I hope the name of the
fragment is not importand - is it??) to the host plugin
org.eclipse.swt
with the proposed host version range 3.1.0. Than I created a package
org.eclipse.swt.widgets
(to which Spinner belongs) in the corresponding src directory of
the fragment project and created the following class:
//////////////////////////////////
package org.eclipse.swt.widgets;
public class Workaround {
public final static int getSelectionText(Spinner spinner) {
final int result = spinner.getSelectionText();
return result;
}
}
//////////////////////////////////
but the fragment cannot **resolve** the identifier "Spinner". Even after
I added org.eclipse.swt.widgets to the list of imported packages on the
dependencies page, I could not resolve the name Spinner.
I would appreciate any help!
Thank you very much,
Daniel
|
|
| |
| Re: classloader or packaging problem? [message #436714 is a reply to message #436685] |
Thu, 15 September 2005 08:36 |
Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
Alex Blewitt wrote:
>>Hmmh, actually I really don't want to enclose my
>>**own** Spinner class,
>>I really **only** want to get access to the
>>getSelectionText method,
>>which has package (default) accessibility. Can I
>>realize this task with
>>the same procedure? I tried the following:
>>
>>I created a fragment project Whatever.swtpatch (I
>>hope the name of the
>>fragment is not importand - is it??) to the host
>>plugin
>>
>>org.eclipse.swt
>>
>>with the proposed host version range 3.1.0. Than I
>>created a package
>>
>>org.eclipse.swt.widgets
>
>
> You're definitely going in the right direction with this. It doesn't
> matter what the fragment name is, as long as the host plugin is set
> to the right version.
OK.
> Is the resolution a compile-time problem, or a run-time problem?
It is (it was ;-)) a compile-time problem. I needed half a day to found
out, that the current Eclipse version (3.1.0 release version) obviously
is sensible to nasty caching (?) problems.
The problem is, that by simply adding org.eclipse.swt to the list of
requirered bundles is not enough, because Eclipse dos not recognize that
Spinner also depends on the org.eclipse.swt.win32.win32.x86 plugin. This
problem only occurred, if I use the new osgi bundles mechanism.
You will not believe me how I could convince Eclipse to properly
recognize that there exist a plugin dependency to
org.eclipse.swt.win32.win32.x86:
1) I added a dependency to org.eclipse.swt. This is actually not
possible using the dependency editor (!), because org.eclipse.swt is not
shown there in the list, but choosing another plugin and modifying its
name to org.eclipse.swt in the raw manifest editor works.
2) I replaced the fragment host "org.eclipse.swt" by
"org.eclipse.swt.win32.win32.x86". In this case Eclipse plugin editor
signals me, that this id is invalid because
org.eclipse.swt.win32.win32.x86 itself is a fragment.
3) I replaced now the errornous org.eclipse.swt.win32.win32.x86 fragment
host by the "parent" host id org.eclipse.swt again - and the
plugin dependency to org.eclipse.swt.win32.win32.x86 is visible in the
package explorer!
Yes, it is some kind of magic and I really don't understand the actual
problem, but I could reproduce this phenomenon several times! (The
plugin becomes invalid at the point I remove the dependency on
org.eclipse.swt again).
This **must** be a severe bug of the manifest editor!
(The reason for attempting the org.eclipse.swt.win32.win32.x86 route was
that I had used the non-osgi bundle at another time. In this case I
simply set org.eclipse.swt.win32.win32.x86 as fragement host and all was
fine)
Thank you very much for your help!
Greetings from Bremen,
Daniel Krügler
|
|
|
| Re: classloader or packaging problem? [message #436870 is a reply to message #436593] |
Mon, 19 September 2005 14:00 |
Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Neither, its a threading problem. You can't access GUI methods outside
of a GUI thread. You need to create a small Runnable that will read out
the values from the GUI object that you need. Then run the runnable
inside the GUI thread. Alternately you can have an event on your GUI
that writes its data when the GUI is changed, to a variable outside of
the GUI object. But then you must ensure its read in a thread safe manner.
CL
Daniel Krügler wrote:
> Hello,
>
> since currently the modify event of Spinner does not allow
> access to the current content of the spinner, (see
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=100363
>
> ) I tried to workaround this by performing the following
> steps:
>
> In my ui-helper plugin I created a Workaround class in
> the org.eclipse.swt.widgets package (to get access to the default
> visible Spinner.getSelectionText() method), as described below:
>
> /////////////////////////////////////
> package org.eclipse.swt.widgets;
>
> public class Workaround {
>
> public final static int getSelectionText(Spinner spinner) {
> final int result = spinner.getSelectionText();
> return result;
> }
>
> }
> /////////////////////////////////////
>
> but calling this static function in my client code leads to an
> java.lang.IllegalAccessError, as seen below in the abridged log file.
> Do I stumble about a language corner-case or is this a packaging problem?
>
> Thank you in advance,
>
> Daniel Krügler
>
>
>
> !SESSION 2005-09-13 10:01:27.280
> -----------------------------------------------
> eclipse.buildId=unknown
> java.version=1.5.0_04
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
> Framework arguments: -product MyProduct.client.ui.ide -pdelaunch
> Command-line arguments: -product MyProduct.client.ui.ide -data
> MyPath\MyProduct -dev
> file:AnyPath/workspace/.metadata/.plugins/org.eclipse.pde.co re/MyProduct/dev.properties
> -pdelaunch -os win32 -ws win32 -arch x86 -data @noDefault
>
> !ENTRY org.eclipse.ui 4 0 2005-09-13 10:01:40.936
> !MESSAGE tried to access method
> org.eclipse.swt.widgets.Spinner.getSelectionText()I from class
> org.eclipse.swt.widgets.Workaround
> !STACK 0
> java.lang.IllegalAccessError: tried to access method
> org.eclipse.swt.widgets.Spinner.getSelectionText()I from class
> org.eclipse.swt.widgets.Workaround
> at
> org.eclipse.swt.widgets.Workaround.getSelectionText(Workarou nd.java:31)
> at
> WhatEver.common.ui.binding.SpinnerAdapter$1.modifyText(Spinn erAdapter.java:56)
>
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:188)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:843)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:867)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:848)
> at org.eclipse.swt.widgets.Spinner.wmCommandChild(Spinner.java: 1171)
> at org.eclipse.swt.widgets.Control.WM_COMMAND(Control.java:3164 )
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:3041 )
> at org.eclipse.swt.widgets.Spinner.windowProc(Spinner.java:1042 )
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:3706 )
> at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method)
> at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:158 0)
> at org.eclipse.swt.widgets.Spinner.callWindowProc(Spinner.java: 88)
> at org.eclipse.swt.widgets.Spinner.windowProc(Spinner.java:1040 )
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:3706 )
> at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
> at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:16 56)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2711)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1699)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1663)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:367)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:143)
> at WhatEver.MyApp.client.ui.AppMain.run(AppMain.java:60)
> at
> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:226)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:376)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:163)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334 )
> at org.eclipse.core.launcher.Main.basicRun(Main.java:278)
> at org.eclipse.core.launcher.Main.run(Main.java:973)
> at org.eclipse.core.launcher.Main.main(Main.java:948)
|
|
| |
| Re: classloader or packaging problem? [message #437054 is a reply to message #436918] |
Wed, 21 September 2005 14:08 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Daniel Krügler wrote:
> CL [dnoyeb] Gilbert wrote:
>
>> Neither, its a threading problem. You can't access GUI methods
>> outside of a GUI thread. You need to create a small Runnable that
>> will read out the values from the GUI object that you need. Then run
>> the runnable inside the GUI thread. Alternately you can have an event
>> on your GUI that writes its data when the GUI is changed, to a
>> variable outside of the GUI object. But then you must ensure its read
>> in a thread safe manner.
>
>
> How do you come to this conclusion? The problem has nothing to do with
> threads, but is class-loader related. After defining the fragment for
> org.eclipse.swt according to the proposals of Alex Blewitt and Boris
> Bokowski the problem was solved.
>
> Greetings,
>
> Daniel
if it worked then they are correct. I came to the conclusiotn based on
your access of the GUI element spinner and the refusal of the workbench
to allow it. This has always been an issue of which thread you are
accessing it from. But I guess with the new osgi stuff in 3.1 perhaps
you are being prevented from accessing it where you wouldnt be in
pre-released versions.
|
|
|
| Re: classloader or packaging problem? [message #437055 is a reply to message #436714] |
Wed, 21 September 2005 14:14 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Daniel Krügler wrote:
> Alex Blewitt wrote:
>
>>> Hmmh, actually I really don't want to enclose my
>>> **own** Spinner class,
>>> I really **only** want to get access to the
>>> getSelectionText method,
>>> which has package (default) accessibility. Can I
>>> realize this task with the same procedure? I tried the following:
>>>
>>> I created a fragment project Whatever.swtpatch (I
>>> hope the name of the fragment is not importand - is it??) to the host
>>> plugin
>>>
>>> org.eclipse.swt
>>>
>>> with the proposed host version range 3.1.0. Than I
>>> created a package
>>>
>>> org.eclipse.swt.widgets
>>
>>
>>
>> You're definitely going in the right direction with this. It doesn't
>> matter what the fragment name is, as long as the host plugin is set
>> to the right version.
>
>
> OK.
>
>> Is the resolution a compile-time problem, or a run-time problem?
>
>
> It is (it was ;-)) a compile-time problem. I needed half a day to found
> out, that the current Eclipse version (3.1.0 release version) obviously
> is sensible to nasty caching (?) problems.
>
> The problem is, that by simply adding org.eclipse.swt to the list of
> requirered bundles is not enough, because Eclipse dos not recognize that
> Spinner also depends on the org.eclipse.swt.win32.win32.x86 plugin. This
> problem only occurred, if I use the new osgi bundles mechanism.
>
> You will not believe me how I could convince Eclipse to properly
> recognize that there exist a plugin dependency to
> org.eclipse.swt.win32.win32.x86:
>
> 1) I added a dependency to org.eclipse.swt. This is actually not
> possible using the dependency editor (!), because org.eclipse.swt is not
> shown there in the list, but choosing another plugin and modifying its
> name to org.eclipse.swt in the raw manifest editor works.
>
> 2) I replaced the fragment host "org.eclipse.swt" by
> "org.eclipse.swt.win32.win32.x86". In this case Eclipse plugin editor
> signals me, that this id is invalid because
> org.eclipse.swt.win32.win32.x86 itself is a fragment.
>
> 3) I replaced now the errornous org.eclipse.swt.win32.win32.x86 fragment
> host by the "parent" host id org.eclipse.swt again - and the
> plugin dependency to org.eclipse.swt.win32.win32.x86 is visible in the
> package explorer!
>
> Yes, it is some kind of magic and I really don't understand the actual
> problem, but I could reproduce this phenomenon several times! (The
> plugin becomes invalid at the point I remove the dependency on
> org.eclipse.swt again).
>
> This **must** be a severe bug of the manifest editor!
>
> (The reason for attempting the org.eclipse.swt.win32.win32.x86 route was
> that I had used the non-osgi bundle at another time. In this case I
> simply set org.eclipse.swt.win32.win32.x86 as fragement host and all was
> fine)
>
> Thank you very much for your help!
>
> Greetings from Bremen,
>
> Daniel Krügler
>
>
>
why don't you ask in the swt forum. You seem to be doing the equivalent
of creating your own version of an swt class and need that level of
plugin access.
CL
|
|
| | |
Goto Forum:
Current Time: Mon Dec 09 06:14:42 GMT 2024
Powered by FUDForum. Page generated in 0.06409 seconds |
] 
Search
Help
Register
Login
Home
