Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » Plugin loading fails in 3.3/3.4
Plugin loading fails in 3.3/3.4 [message #334418] Sat, 07 February 2009 15:45 Go to next message
Eclipse UserFriend
Originally posted by: riwright.adobe.com

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3316837550_4864002
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

This is a post I put up in the newbie section, but got no response. I
subsequently saw several posts about invalid activators on this list (though
none were entirely relevant to my case). The odd thing about this is that
it is absolutely due to some change in classloaders from 3.2 to 3.3. I'm
still working on it, but if anyone can make any suggestions, I would be
appreciative.

TIA, Ric

--------------------------------------------------
I've gotten a little farther. I turned on the debugging in the launch tab
and I found:

!ENTRY org.eclipse.osgi 2 0 2009-02-06 16:28:48.779
!MESSAGE The activator
com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is
invalid
!STACK 0
org.osgi.framework.BundleException: The activator
com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is invalid

at
org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(
AbstractBundle.java:146)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.s tart(BundleConte
xtImpl.java:980)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWor ker(BundleHost.j
ava:346)

Not clear what change between 3.2 and 3.3 would have produced this error.
Some spelunking suggests it might have something to do with the third party
jars
(e.g. Jogl) that I use but no further clues. But a JOGL view works fine
only plugins fail. Any suggestions or tips welcome.

TIA, Ric

On 2/6/09 2:43 PM, in article C5B1FCFF.161BC%riwright@adobe.com, "Ric
Wright" <riwright@adobe.com> wrote:

> I have a plugin that I wrote a while ago. It's a normal Eclipse plugin.
> It's main class is com.geofx.opengl.OpenGLView. The plugin loads and runs
> without problems in Eclipse 3.2 but fails in 3.3 and 3.4 with the message
>
> "Could not create the view: Plug-in com.geofx.opengl.view was unable to load
> class com.geofx.opengl.view.OpenGLView."
>
> At a guess, classloading changed in some way from 3.2 to 3.3 and 3.4. To be
> honest, classloaders are a black art to me (and wouldn't mind keeping it
> that way). I don't really know how to start figuring this out.
>
> I posted a question here once before about this but didn't get any pointers.
> I am happy (or at least resigned) to dig into this, but frankly not sure
> where to start. Any pointers would be appreciated.
>
> Thanks,
> Ric
>
>



--B_3316837550_4864002
Content-type: text/plain; name="stack_trace.txt";
x-mac-creator="21526368";
x-mac-type="54455854"
Content-disposition: attachment;
filename="stack_trace.txt"
Content-transfer-encoding: base64


amF2YS5sYW5nLkNsYXNzTm90Rm91bmRFeGNlcHRpb246IGNvbS5nZW9meC5v cGVuZ2wudmll
dy5PcGVuR0xWaWV3CglhdCBvcmcuZWNsaXBzZS5vc2dpLmZyYW1ld29yay5p bnRlcm5hbC5j
b3JlLkJ1bmRsZUxvYWRlci5maW5kQ2xhc3NJbnRlcm5hbChCdW5kbGVMb2Fk ZXIuamF2YTo0
ODEpCglhdCBvcmcuZWNsaXBzZS5vc2dpLmZyYW1ld29yay5pbnRlcm5hbC5j b3JlLkJ1bmRs
ZUxvYWRlci5maW5kQ2xhc3MoQnVuZGxlTG9hZGVyLmphdmE6Mzk3KQoJYXQg b3JnLmVjbGlw
c2Uub3NnaS5mcmFtZXdvcmsuaW50ZXJuYWwuY29yZS5CdW5kbGVMb2FkZXIu ZmluZENsYXNz
KEJ1bmRsZUxvYWRlci5qYXZhOjM4NSkKCWF0IG9yZy5lY2xpcHNlLm9zZ2ku aW50ZXJuYWwu
YmFzZWFkYXB0b3IuRGVmYXVsdENsYXNzTG9hZGVyLmxvYWRDbGFzcyhEZWZh dWx0Q2xhc3NM
b2FkZXIuamF2YTo4NykKCWF0IGphdmEubGFuZy5DbGFzc0xvYWRlci5sb2Fk Q2xhc3MoQ2xh
c3NMb2FkZXIuamF2YToyNTEpCglhdCBvcmcuZWNsaXBzZS5vc2dpLmZyYW1l d29yay5pbnRl
cm5hbC5jb3JlLkJ1bmRsZUxvYWRlci5sb2FkQ2xhc3MoQnVuZGxlTG9hZGVy LmphdmE6MzEz
KQoJYXQgb3JnLmVjbGlwc2Uub3NnaS5mcmFtZXdvcmsuaW50ZXJuYWwuY29y ZS5CdW5kbGVI
b3N0LmxvYWRDbGFzcyhCdW5kbGVIb3N0LmphdmE6MjI3KQoJYXQgb3JnLmVj bGlwc2Uub3Nn
aS5mcmFtZXdvcmsuaW50ZXJuYWwuY29yZS5BYnN0cmFjdEJ1bmRsZS5sb2Fk Q2xhc3MoQWJz
dHJhY3RCdW5kbGUuamF2YToxMjc0KQoJYXQgb3JnLmVjbGlwc2UuY29yZS5p bnRlcm5hbC5y
ZWdpc3RyeS5vc2dpLlJlZ2lzdHJ5U3RyYXRlZ3lPU0dJLmNyZWF0ZUV4ZWN1 dGFibGVFeHRl
bnNpb24oUmVnaXN0cnlTdHJhdGVneU9TR0kuamF2YToxNjApCglhdCBvcmcu ZWNsaXBzZS5j
b3JlLmludGVybmFsLnJlZ2lzdHJ5LkV4dGVuc2lvblJlZ2lzdHJ5LmNyZWF0 ZUV4ZWN1dGFi
bGVFeHRlbnNpb24oRXh0ZW5zaW9uUmVnaXN0cnkuamF2YTo4NjcpCglhdCBv cmcuZWNsaXBz
ZS5jb3JlLmludGVybmFsLnJlZ2lzdHJ5LkNvbmZpZ3VyYXRpb25FbGVtZW50 LmNyZWF0ZUV4
ZWN1dGFibGVFeHRlbnNpb24oQ29uZmlndXJhdGlvbkVsZW1lbnQuamF2YToy NDMpCglhdCBv
cmcuZWNsaXBzZS5jb3JlLmludGVybmFsLnJlZ2lzdHJ5LkNvbmZpZ3VyYXRp b25FbGVtZW50
SGFuZGxlLmNyZWF0ZUV4ZWN1dGFibGVFeHRlbnNpb24oQ29uZmlndXJhdGlv bkVsZW1lbnRI
YW5kbGUuamF2YTo1MSkKCWF0IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLldv cmtiZW5jaFBs
dWdpbiQxLnJ1bihXb3JrYmVuY2hQbHVnaW4uamF2YToyNjcpCglhdCBvcmcu ZWNsaXBzZS5z
d3QuY3VzdG9tLkJ1c3lJbmRpY2F0b3Iuc2hvd1doaWxlKEJ1c3lJbmRpY2F0 b3IuamF2YTo3
MCkKCWF0IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLldvcmtiZW5jaFBsdWdp bi5jcmVhdGVF
eHRlbnNpb24oV29ya2JlbmNoUGx1Z2luLmphdmE6MjYzKQoJYXQgb3JnLmVj bGlwc2UudWku
aW50ZXJuYWwucmVnaXN0cnkuVmlld0Rlc2NyaXB0b3IuY3JlYXRlVmlldyhW aWV3RGVzY3Jp
cHRvci5qYXZhOjYzKQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuVmll d1JlZmVyZW5j
ZS5jcmVhdGVQYXJ0SGVscGVyKFZpZXdSZWZlcmVuY2UuamF2YTozMjgpCglh dCBvcmcuZWNs
aXBzZS51aS5pbnRlcm5hbC5WaWV3UmVmZXJlbmNlLmNyZWF0ZVBhcnQoVmll d1JlZmVyZW5j
ZS5qYXZhOjIzMCkKCWF0IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLldvcmti ZW5jaFBhcnRS
ZWZlcmVuY2UuZ2V0UGFydChXb3JrYmVuY2hQYXJ0UmVmZXJlbmNlLmphdmE6 NTk0KQoJYXQg
b3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuUGVyc3BlY3RpdmUuc2hvd1ZpZXco UGVyc3BlY3Rp
dmUuamF2YToyMTI3KQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuV29y a2JlbmNoUGFn
ZS5idXN5U2hvd1ZpZXcoV29ya2JlbmNoUGFnZS5qYXZhOjEwNjIpCglhdCBv cmcuZWNsaXBz
ZS51aS5pbnRlcm5hbC5Xb3JrYmVuY2hQYWdlJDE5LnJ1bihXb3JrYmVuY2hQ YWdlLmphdmE6
Mzc3MykKCWF0IG9yZy5lY2xpcHNlLnN3dC5jdXN0b20uQnVzeUluZGljYXRv ci5zaG93V2hp
bGUoQnVzeUluZGljYXRvci5qYXZhOjcwKQoJYXQgb3JnLmVjbGlwc2UudWku aW50ZXJuYWwu
V29ya2JlbmNoUGFnZS5zaG93VmlldyhXb3JrYmVuY2hQYWdlLmphdmE6Mzc3 MCkKCWF0IG9y
Zy5lY2xpcHNlLnVpLmludGVybmFsLldvcmtiZW5jaFBhZ2Uuc2hvd1ZpZXco V29ya2JlbmNo
UGFnZS5qYXZhOjM3NDYpCglhdCBvcmcuZWNsaXBzZS51aS5oYW5kbGVycy5T aG93Vmlld0hh
bmRsZXIub3BlblZpZXcoU2hvd1ZpZXdIYW5kbGVyLmphdmE6MTY1KQoJYXQg b3JnLmVjbGlw
c2UudWkuaGFuZGxlcnMuU2hvd1ZpZXdIYW5kbGVyLm9wZW5PdGhlcihTaG93 Vmlld0hhbmRs
ZXIuamF2YToxMDkpCglhdCBvcmcuZWNsaXBzZS51aS5oYW5kbGVycy5TaG93 Vmlld0hhbmRs
ZXIuZXhlY3V0ZShTaG93Vmlld0hhbmRsZXIuamF2YTo3NykKCWF0IG9yZy5l Y2xpcHNlLnVp
LmludGVybmFsLmhhbmRsZXJzLkhhbmRsZXJQcm94eS5leGVjdXRlKEhhbmRs ZXJQcm94eS5q
YXZhOjI4MSkKCWF0IG9yZy5lY2xpcHNlLmNvcmUuY29tbWFuZHMuQ29tbWFu ZC5leGVjdXRl
V2l0aENoZWNrcyhDb21tYW5kLmphdmE6NDc2KQoJYXQgb3JnLmVjbGlwc2Uu Y29yZS5jb21t
YW5kcy5QYXJhbWV0ZXJpemVkQ29tbWFuZC5leGVjdXRlV2l0aENoZWNrcyhQ YXJhbWV0ZXJp
emVkQ29tbWFuZC5qYXZhOjUwOCkKCWF0IG9yZy5lY2xpcHNlLnVpLmludGVy bmFsLmhhbmRs
ZXJzLkhhbmRsZXJTZXJ2aWNlLmV4ZWN1dGVDb21tYW5kKEhhbmRsZXJTZXJ2 aWNlLmphdmE6
MTY5KQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuaGFuZGxlcnMuU2xh dmVIYW5kbGVy
U2VydmljZS5leGVjdXRlQ29tbWFuZChTbGF2ZUhhbmRsZXJTZXJ2aWNlLmph dmE6MjQ3KQoJ
YXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuU2hvd1ZpZXdNZW51JDMucnVu KFNob3dWaWV3
TWVudS5qYXZhOjEzNCkKCWF0IG9yZy5lY2xpcHNlLmpmYWNlLmFjdGlvbi5B Y3Rpb24ucnVu
V2l0aEV2ZW50KEFjdGlvbi5qYXZhOjQ5OCkKCWF0IG9yZy5lY2xpcHNlLmpm YWNlLmFjdGlv
bi5BY3Rpb25Db250cmlidXRpb25JdGVtLmhhbmRsZVdpZGdldFNlbGVjdGlv bihBY3Rpb25D
b250cmlidXRpb25JdGVtLmphdmE6NTgzKQoJYXQgb3JnLmVjbGlwc2UuamZh Y2UuYWN0aW9u
LkFjdGlvbkNvbnRyaWJ1dGlvbkl0ZW0uYWNjZXNzJDIoQWN0aW9uQ29udHJp YnV0aW9uSXRl
bS5qYXZhOjUwMCkKCWF0IG9yZy5lY2xpcHNlLmpmYWNlLmFjdGlvbi5BY3Rp b25Db250cmli
dXRpb25JdGVtJDUuaGFuZGxlRXZlbnQoQWN0aW9uQ29udHJpYnV0aW9uSXRl bS5qYXZhOjQx
MSkKCWF0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLkV2ZW50VGFibGUuc2Vu ZEV2ZW50KEV2
ZW50VGFibGUuamF2YTo4NCkKCWF0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRz LldpZGdldC5z
ZW5kRXZlbnQoV2lkZ2V0LmphdmE6MTU2MSkKCWF0IG9yZy5lY2xpcHNlLnN3 dC53aWRnZXRz
LldpZGdldC5zZW5kRXZlbnQoV2lkZ2V0LmphdmE6MTU4NSkKCWF0IG9yZy5l Y2xpcHNlLnN3
dC53aWRnZXRzLldpZGdldC5zZW5kRXZlbnQoV2lkZ2V0LmphdmE6MTU3MCkK CWF0IG9yZy5l
Y2xpcHNlLnN3dC53aWRnZXRzLldpZGdldC5ub3RpZnlMaXN0ZW5lcnMoV2lk Z2V0LmphdmE6
MTM2MCkKCWF0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLkRpc3BsYXkucnVu RGVmZXJyZWRF
dmVudHMoRGlzcGxheS5qYXZhOjM0ODIpCglhdCBvcmcuZWNsaXBzZS5zd3Qu d2lkZ2V0cy5E
aXNwbGF5LnJlYWRBbmREaXNwYXRjaChEaXNwbGF5LmphdmE6MzA2OCkKCWF0 IG9yZy5lY2xp
cHNlLnVpLmludGVybmFsLldvcmtiZW5jaC5ydW5FdmVudExvb3AoV29ya2Jl bmNoLmphdmE6
MjM4MikKCWF0IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLldvcmtiZW5jaC5y dW5VSShXb3Jr
YmVuY2guamF2YToyMzQ2KQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwu V29ya2JlbmNo
LmFjY2VzcyQ0KFdvcmtiZW5jaC5qYXZhOjIxOTgpCglhdCBvcmcuZWNsaXBz ZS51aS5pbnRl
cm5hbC5Xb3JrYmVuY2gkNS5ydW4oV29ya2JlbmNoLmphdmE6NDkzKQoJYXQg b3JnLmVjbGlw
c2UuY29yZS5kYXRhYmluZGluZy5vYnNlcnZhYmxlLlJlYWxtLnJ1bldpdGhE ZWZhdWx0KFJl
YWxtLmphdmE6Mjg4KQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuV29y a2JlbmNoLmNy
ZWF0ZUFuZFJ1bldvcmtiZW5jaChXb3JrYmVuY2guamF2YTo0ODgpCglhdCBv cmcuZWNsaXBz
ZS51aS5QbGF0Zm9ybVVJLmNyZWF0ZUFuZFJ1bldvcmtiZW5jaChQbGF0Zm9y bVVJLmphdmE6
MTQ5KQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuaWRlLmFwcGxpY2F0 aW9uLklERUFw
cGxpY2F0aW9uLnN0YXJ0KElERUFwcGxpY2F0aW9uLmphdmE6MTEzKQoJYXQg b3JnLmVjbGlw
c2UuZXF1aW5veC5pbnRlcm5hbC5hcHAuRWNsaXBzZUFwcEhhbmRsZS5ydW4o RWNsaXBzZUFw
cEhhbmRsZS5qYXZhOjE5MykKCWF0IG9yZy5lY2xpcHNlLmNvcmUucnVudGlt ZS5pbnRlcm5h
bC5hZGFwdG9yLkVjbGlwc2VBcHBMYXVuY2hlci5ydW5BcHBsaWNhdGlvbihF Y2xpcHNlQXBw
TGF1bmNoZXIuamF2YToxMTApCglhdCBvcmcuZWNsaXBzZS5jb3JlLnJ1bnRp bWUuaW50ZXJu
YWwuYWRhcHRvci5FY2xpcHNlQXBwTGF1bmNoZXIuc3RhcnQoRWNsaXBzZUFw cExhdW5jaGVy
LmphdmE6NzkpCglhdCBvcmcuZWNsaXBzZS5jb3JlLnJ1bnRpbWUuYWRhcHRv ci5FY2xpcHNl
U3RhcnRlci5ydW4oRWNsaXBzZVN0YXJ0ZXIuamF2YTozODYpCglhdCBvcmcu ZWNsaXBzZS5j
b3JlLnJ1bnRpbWUuYWRhcHRvci5FY2xpcHNlU3RhcnRlci5ydW4oRWNsaXBz ZVN0YXJ0ZXIu
amF2YToxNzkpCglhdCBzdW4ucmVmbGVjdC5OYXRpdmVNZXRob2RBY2Nlc3Nv ckltcGwuaW52
b2tlMChOYXRpdmUgTWV0aG9kKQoJYXQgc3VuLnJlZmxlY3QuTmF0aXZlTWV0 aG9kQWNjZXNz
b3JJbXBsLmludm9rZShOYXRpdmVNZXRob2RBY2Nlc3NvckltcGwuamF2YToz OSkKCWF0IHN1
bi5yZWZsZWN0LkRlbGVnYXRpbmdNZXRob2RBY2Nlc3NvckltcGwuaW52b2tl KERlbGVnYXRp
bmdNZXRob2RBY2Nlc3NvckltcGwuamF2YToyNSkKCWF0IGphdmEubGFuZy5y ZWZsZWN0Lk1l
dGhvZC5pbnZva2UoTWV0aG9kLmphdmE6NTg1KQoJYXQgb3JnLmVjbGlwc2Uu ZXF1aW5veC5s
YXVuY2hlci5NYWluLmludm9rZUZyYW1ld29yayhNYWluLmphdmE6NTQ5KQoJ YXQgb3JnLmVj
bGlwc2UuZXF1aW5veC5sYXVuY2hlci5NYWluLmJhc2ljUnVuKE1haW4uamF2 YTo1MDQpCglh
dCBvcmcuZWNsaXBzZS5lcXVpbm94LmxhdW5jaGVyLk1haW4ucnVuKE1haW4u amF2YToxMjM2
KQoJYXQgb3JnLmVjbGlwc2UuZXF1aW5veC5sYXVuY2hlci5NYWluLm1haW4o TWFpbi5qYXZh
OjEyMTIpCg==
--B_3316837550_4864002
Content-type: application/octet-stream; name="plugin.xml"
Content-disposition: attachment;
filename="plugin.xml"
Content-transfer-encoding: base64


PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjw/ZWNs aXBzZSB2ZXJz
aW9uPSIzLjMiPz4NCjxwbHVnaW4+DQoNCiAgIDxleHRlbnNpb24NCiAgICAg ICAgIHBvaW50
PSJvcmcuZWNsaXBzZS51aS52aWV3cyI+DQogICAgICA8Y2F0ZWdvcnkNCiAg ICAgICAgICAg
IG5hbWU9Ik9wZW5HTCBDYXRlZ29yeSINCiAgICAgICAgICAgIGlkPSJjb20u Z2VvZngub3Bl
bmdsLnZpZXciPg0KICAgICAgPC9jYXRlZ29yeT4NCiAgICAgIDx2aWV3DQog ICAgICAgICAg
ICBuYW1lPSJPcGVuR0wgVmlldyINCiAgICAgICAgICAgIGljb249Imljb25z L3NhbXBsZS5n
aWYiDQogICAgICAgICAgICBjYXRlZ29yeT0iY29tLmdlb2Z4Lm9wZW5nbC52 aWV3Ig0KICAg
ICAgICAgICAgY2xhc3M9ImNvbS5nZW9meC5vcGVuZ2wudmlldy5PcGVuR0xW aWV3Ig0KICAg
ICAgICAgICAgaWQ9ImNvbS5nZW9meC5vcGVuZ2wudmlldy5PcGVuR0xWaWV3 Ij4NCiAgICAg
IDwvdmlldz4NCiAgIDwvZXh0ZW5zaW9uPg0KICAgPGV4dGVuc2lvbg0KICAg ICAgICAgcG9p
bnQ9Im9yZy5lY2xpcHNlLnVpLnBlcnNwZWN0aXZlRXh0ZW5zaW9ucyI+DQog ICAgICA8cGVy
c3BlY3RpdmVFeHRlbnNpb24NCiAgICAgICAgICAgIHRhcmdldElEPSJvcmcu ZWNsaXBzZS51
aS5yZXNvdXJjZVBlcnNwZWN0aXZlIj4NCiAgICAgICAgIDx2aWV3DQogICAg ICAgICAgICAg
ICByYXRpbz0iMC41Ig0KICAgICAgICAgICAgICAgcmVsYXRpdmU9Im9yZy5l Y2xpcHNlLnVp
LnZpZXdzLlRhc2tMaXN0Ig0KICAgICAgICAgICAgICAgcmVsYXRpb25zaGlw PSJyaWdodCIN
CiAgICAgICAgICAgICAgIGlkPSJjb20uZ2VvZngub3BlbmdsLnZpZXcuT3Bl bkdMVmlldyI+
DQogICAgICAgICA8L3ZpZXc+DQogICAgICA8L3BlcnNwZWN0aXZlRXh0ZW5z aW9uPg0KICAg
PC9leHRlbnNpb24+DQogICA8ZXh0ZW5zaW9uDQogICAgICAgICBwb2ludD0i b3JnLmVjbGlw
c2UudWkuYWN0aW9uU2V0cyI+DQogICAgICA8YWN0aW9uU2V0DQogICAgICAg ICAgICBpZD0i
Y29tLmdlb2Z4Lm9wZW5nbC52aWV3LmFjdGlvblNldCINCiAgICAgICAgICAg IGxhYmVsPSJT
ZWxlY3QgU2NlbmUiDQogICAgICAgICAgICB2aXNpYmxlPSJ0cnVlIj4NCiAg ICAgICAgIDxt
ZW51DQogICAgICAgICAgICAgICBpZD0ic2NlbmVTZWxlY3QiDQogICAgICAg ICAgICAgICBs
YWJlbD0iJmFtcDtPcGVuR0wiPg0KICAgICAgICAgICAgPHNlcGFyYXRvciBu YW1lPSJzZWxl
Y3RHcm91cCIvPg0KICAgICAgICAgPC9tZW51Pg0KICAgICAgICAgPGFjdGlv bg0KICAgICAg
ICAgICAgICAgY2xhc3M9ImNvbS5nZW9meC5vcGVuZ2wuc2NlbmUuU2NlbmVT ZWxlY3QiDQog
ICAgICAgICAgICAgICBpY29uPSJpY29ucy9vZ2xfc21fc3F1YXJlLmdpZiIN CiAgICAgICAg
ICAgICAgIGlkPSJjb20uZ2VvZngub3BlbmdsLnZpZXcuYWN0aW9ucy5TZWxl Y3RTY2VuZSIN
CiAgICAgICAgICAgICAgIGxhYmVsPSImYW1wO1NlbGVjdCBTY2VuZSINCiAg ICAgICAgICAg
ICAgIG1lbnViYXJQYXRoPSJzY2VuZVNlbGVjdC9zZWxlY3RHcm91cCINCiAg ICAgICAgICAg
ICAgIHRvb2xiYXJQYXRoPSJzZWxlY3RHcm91cCINCiAgICAgICAgICAgICAg IHRvb2x0aXA9
IlNlbGVjdCBTY2VuZSIvPg0KICAgICAgPC9hY3Rpb25TZXQ+DQogICA8L2V4 dGVuc2lvbj4N
CjwvcGx1Z2luPg0K
--B_3316837550_4864002
Content-type: application/octet-stream; name="build.properties"
Content-disposition: attachment;
filename="build.properties"
Content-transfer-encoding: base64


b3V0cHV0Li4gPSBiaW4vDQpiaW4uaW5jbHVkZXMgPSBwbHVnaW4ueG1sLFwN CiAgICAgICAg
ICAgICAgIE1FVEEtSU5GLyxcDQogICAgICAgICAgICAgICBpY29ucy8sXA0K ICAgICAgICAg
ICAgICAgZ2x1ZWdlbi1ydC5qYXIsXA0KICAgICAgICAgICAgICAgam9nbC5q YXIsXA0KICAg
ICAgICAgICAgICAgY29tLmdlb2Z4Lm9wZW5nbC51dGlsXzEuMC4wLmphcixc DQogICAgICAg
ICAgICAgICBiaW4vDQpzcmMuaW5jbHVkZXMgPSBzcmMvDQo=
--B_3316837550_4864002
Content-type: application/octet-stream; name="MANIFEST.MF"
Content-disposition: attachment;
filename="MANIFEST.MF"
Content-transfer-encoding: base64


TWFuaWZlc3QtVmVyc2lvbjogMS4wCkJ1bmRsZS1NYW5pZmVzdFZlcnNpb246 IDIKQnVuZGxl
LU5hbWU6IE9wZW5HTCBWaWV3IFBsdWctaW4KQnVuZGxlLVN5bWJvbGljTmFt ZTogY29tLmdl
b2Z4Lm9wZW5nbC52aWV3O3NpbmdsZXRvbjo9dHJ1ZQpCdW5kbGUtVmVyc2lv bjogMS4wLjAK
QnVuZGxlLUFjdGl2YXRvcjogY29tLmdlb2Z4Lm9wZW5nbC52aWV3LkFjdGl2 YXRvcgpCdW5k
bGUtTG9jYWxpemF0aW9uOiBwbHVnaW4KUmVxdWlyZS1CdW5kbGU6IG9yZy5l Y2xpcHNlLnVp
LAogb3JnLmVjbGlwc2UuY29yZS5ydW50aW1lLAogamF2YTNkIApFY2xpcHNl LUxhenlTdGFy
dDogdHJ1ZQpCdW5kbGUtQ2xhc3NQYXRoOiBnbHVlZ2VuLXJ0LmphciwKIGpv Z2wuamFyLAog
Y29tLmdlb2Z4Lm9wZW5nbC51dGlsXzEuMC4wLmphcgpFeHBvcnQtUGFja2Fn ZTogY29tLmdl
b2Z4Lm9wZW5nbC52aWV3OwogIHVzZXM6PSJvcmcuZWNsaXBzZS51aS5wYXJ0 LAogICBjb20u
Z2VvZngub3BlbmdsLnNjZW5lLAogICBvcmcub3NnaS5mcmFtZXdvcmssCiAg IG9yZy5lY2xp
cHNlLnVpLnBsdWdpbiwKICAgb3JnLmVjbGlwc2UuamZhY2UucmVzb3VyY2Us CiAgIG9yZy5l
Y2xpcHNlLmNvcmUucnVudGltZSwKICAgb3JnLmVjbGlwc2Uuc3d0LndpZGdl dHMiCg==
--B_3316837550_4864002--
Re: Plugin loading fails in 3.3/3.4 [message #334422 is a reply to message #334418] Sat, 07 February 2009 18:54 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: subs._nospam_consertum.com

I think it more likely that your activator isn't a valid activator for
3.3. Have you tried opening the source in a 3.3 PDE and see what it
complains about?

Have you looked at the 3.3 Migration Guide?
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/porting/eclipse_3_3_porting_guide.html

Ric Wright wrote:
> This is a post I put up in the newbie section, but got no response. I
> subsequently saw several posts about invalid activators on this list (though
> none were entirely relevant to my case). The odd thing about this is that
> it is absolutely due to some change in classloaders from 3.2 to 3.3. I'm
> still working on it, but if anyone can make any suggestions, I would be
> appreciative.
>
> TIA, Ric
>
> --------------------------------------------------
> I've gotten a little farther. I turned on the debugging in the launch tab
> and I found:
>
> !ENTRY org.eclipse.osgi 2 0 2009-02-06 16:28:48.779
> !MESSAGE The activator
> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is
> invalid
> !STACK 0
> org.osgi.framework.BundleException: The activator
> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is invalid
>
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(
> AbstractBundle.java:146)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.s tart(BundleConte
> xtImpl.java:980)
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.startWor ker(BundleHost.j
> ava:346)
>
> Not clear what change between 3.2 and 3.3 would have produced this error.
> Some spelunking suggests it might have something to do with the third party
> jars
> (e.g. Jogl) that I use but no further clues. But a JOGL view works fine
> only plugins fail. Any suggestions or tips welcome.
>
> TIA, Ric
>
> On 2/6/09 2:43 PM, in article C5B1FCFF.161BC%riwright@adobe.com, "Ric
> Wright" <riwright@adobe.com> wrote:
>
>> I have a plugin that I wrote a while ago. It's a normal Eclipse plugin.
>> It's main class is com.geofx.opengl.OpenGLView. The plugin loads and runs
>> without problems in Eclipse 3.2 but fails in 3.3 and 3.4 with the message
>>
>> "Could not create the view: Plug-in com.geofx.opengl.view was unable to load
>> class com.geofx.opengl.view.OpenGLView."
>>
>> At a guess, classloading changed in some way from 3.2 to 3.3 and 3.4. To be
>> honest, classloaders are a black art to me (and wouldn't mind keeping it
>> that way). I don't really know how to start figuring this out.
>>
>> I posted a question here once before about this but didn't get any pointers.
>> I am happy (or at least resigned) to dig into this, but frankly not sure
>> where to start. Any pointers would be appreciated.
>>
>> Thanks,
>> Ric
>>
>>
>
>


--
Derek
Re: Plugin loading fails in 3.3/3.4 [message #334425 is a reply to message #334422] Sat, 07 February 2009 20:32 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: riwright.adobe.com

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3316854740_5862917
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

Thanks for responding, Derek.

AFAIK, the activator is valid (attached). When brought up in Eclipse, there
is only a warning about a raw iterator (that I will fix once I get past
this).

I did read through the migration and the only thing that seemed relevant was
the boot delegation order. I tried the org.osgi.framework.bootdelegation=*
in the config.ini, but it made no difference, so that doesn't seem to be it.

The execution never gets to the Activator BTW, neither ctor nor start()
methods are ever called. My suspicion is that one of the dependencies (e.g.
The JOGL or Java3D jars can't be resolved so the message is a little bogus.
But I don't know how to find out WHICH class it thinks it can't find. It
says com.geofx.opengl.view.OpenGLView but I think that is misleading since
that file IS in the exported package, etc. But I could be missing
something.

I included the plugin.xml, manifest.xml etc. in the previous post on this
thread.

Thanks, Ric


On 2/7/09 10:54 AM, in article gmkld3$9h$1@build.eclipse.org, "Derek"
<subs@_nospam_consertum.com> wrote:

> I think it more likely that your activator isn't a valid activator for
> 3.3. Have you tried opening the source in a 3.3 PDE and see what it
> complains about?
>
> Have you looked at the 3.3 Migration Guide?
> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/p
> orting/eclipse_3_3_porting_guide.html
>
> Ric Wright wrote:
>> This is a post I put up in the newbie section, but got no response. I
>> subsequently saw several posts about invalid activators on this list (though
>> none were entirely relevant to my case). The odd thing about this is that
>> it is absolutely due to some change in classloaders from 3.2 to 3.3. I'm
>> still working on it, but if anyone can make any suggestions, I would be
>> appreciative.
>>
>> TIA, Ric
>>
>> --------------------------------------------------
>> I've gotten a little farther. I turned on the debugging in the launch tab
>> and I found:
>>
>> !ENTRY org.eclipse.osgi 2 0 2009-02-06 16:28:48.779
>> !MESSAGE The activator
>> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is
>> invalid
>> !STACK 0
>> org.osgi.framework.BundleException: The activator
>> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is invalid
>>
>> at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(
>> AbstractBundle.java:146)
>> at
>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.s tart(BundleConte
>> xtImpl.java:980)
>> at
>> org.eclipse.osgi.framework.internal.core.BundleHost.startWor ker(BundleHost.j
>> ava:346)
>>
>> Not clear what change between 3.2 and 3.3 would have produced this error.
>> Some spelunking suggests it might have something to do with the third party
>> jars
>> (e.g. Jogl) that I use but no further clues. But a JOGL view works fine
>> only plugins fail. Any suggestions or tips welcome.
>>
>> TIA, Ric
>>
>> On 2/6/09 2:43 PM, in article C5B1FCFF.161BC%riwright@adobe.com, "Ric
>> Wright" <riwright@adobe.com> wrote:
>>
>>> I have a plugin that I wrote a while ago. It's a normal Eclipse plugin.
>>> It's main class is com.geofx.opengl.OpenGLView. The plugin loads and runs
>>> without problems in Eclipse 3.2 but fails in 3.3 and 3.4 with the message
>>>
>>> "Could not create the view: Plug-in com.geofx.opengl.view was unable to load
>>> class com.geofx.opengl.view.OpenGLView."
>>>
>>> At a guess, classloading changed in some way from 3.2 to 3.3 and 3.4. To be
>>> honest, classloaders are a black art to me (and wouldn't mind keeping it
>>> that way). I don't really know how to start figuring this out.
>>>
>>> I posted a question here once before about this but didn't get any pointers.
>>> I am happy (or at least resigned) to dig into this, but frankly not sure
>>> where to start. Any pointers would be appreciated.
>>>
>>> Thanks,
>>> Ric
>>>
>>>
>>
>>
>


--B_3316854740_5862917
Content-type: application/octet-stream; name="Activator.java"
Content-disposition: attachment;
filename="Activator.java"
Content-transfer-encoding: base64


LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioNCiAqIENvcHlyaWdodCAoYykg MjAwOCBSaWMg
V3JpZ2h0IA0KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4gVGhpcyBwcm9ncmFt IGFuZCB0aGUg
YWNjb21wYW55aW5nIG1hdGVyaWFscyANCiAqIGFyZSBtYWRlIGF2YWlsYWJs ZSB1bmRlciB0
aGUgdGVybXMgb2YgdGhlIEVjbGlwc2UgUHVibGljIExpY2Vuc2UgdjEuMA0K ICogd2hpY2gg
YWNjb21wYW5pZXMgdGhpcyBkaXN0cmlidXRpb24sIGFuZCBpcyBhdmFpbGFi bGUgYXQNCiAq
IGh0dHA6Ly93d3cuZWNsaXBzZS5vcmcvb3JnL2RvY3VtZW50cy9lcGwtdjEw Lmh0bWwNCiAq
IA0KICogQ29udHJpYnV0b3JzOg0KICogICAgIFJpYyBXcmlnaHQgLSBpbml0 aWFsIGltcGxl
bWVudGF0aW9uDQogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8NCg0KcGFj a2FnZSBjb20u
Z2VvZngub3BlbmdsLnZpZXc7DQoNCmltcG9ydCBqYXZhLmxhbmcucmVmbGVj dC5JbnZvY2F0
aW9uVGFyZ2V0RXhjZXB0aW9uOw0KaW1wb3J0IGphdmEubmV0LlVSTDsNCmlt cG9ydCBqYXZh
LnV0aWwuQXJyYXlMaXN0Ow0KaW1wb3J0IGphdmEudXRpbC5FbnVtZXJhdGlv bjsNCg0KaW1w
b3J0IG9yZy5lY2xpcHNlLmNvcmUucnVudGltZS5QbGF0Zm9ybTsNCmltcG9y dCBvcmcuZWNs
aXBzZS5qZmFjZS5yZXNvdXJjZS5JbWFnZURlc2NyaXB0b3I7DQppbXBvcnQg b3JnLmVjbGlw
c2Uuc3d0LndpZGdldHMuQ29tcG9zaXRlOw0KaW1wb3J0IG9yZy5lY2xpcHNl LnVpLnBsdWdp
bi5BYnN0cmFjdFVJUGx1Z2luOw0KaW1wb3J0IG9yZy5vc2dpLmZyYW1ld29y ay5CdW5kbGVD
b250ZXh0Ow0KDQppbXBvcnQgY29tLmdlb2Z4Lm9wZW5nbC5zY2VuZS5HTFNj ZW5lOw0KDQov
KioNCiAqIFRoZSBhY3RpdmF0b3IgY2xhc3MgY29udHJvbHMgdGhlIHBsdWct aW4gbGlmZSBj
eWNsZQ0KICovDQpwdWJsaWMgY2xhc3MgQWN0aXZhdG9yIGV4dGVuZHMgQWJz dHJhY3RVSVBs
dWdpbg0Kew0KDQoJLy8gVGhlIHBsdWctaW4gSUQNCglwdWJsaWMgc3RhdGlj IGZpbmFsIFN0
cmluZyBQTFVHSU5fSUQgPSAiY29tLmdlb2Z4Lm9wZW5nbC52aWV3IjsNCg0K CS8vIFRoZSBz
aGFyZWQgaW5zdGFuY2UNCglwcml2YXRlIHN0YXRpYyBBY3RpdmF0b3IgCXBs dWdpbjsNCglw
cml2YXRlIHN0YXRpYyBTdHJpbmcJCXNjZW5lTmFtZTsNCglwcml2YXRlIHN0 YXRpYyBPcGVu
R0xWaWV3CWdsVmlldzsNCgkNCglwcml2YXRlIHN0YXRpYyBBcnJheUxpc3Q8 Q2xhc3NJbmZv
PgljbGFzc0luZm8gPSBuZXcgQXJyYXlMaXN0PENsYXNzSW5mbz4oKTsNCgkN CgkvKioNCgkg
KiBUaGUgY29uc3RydWN0b3INCgkgKi8NCglwdWJsaWMgQWN0aXZhdG9yKCkN Cgl7DQoJCXBs
dWdpbiA9IHRoaXM7DQoJfQ0KDQoJcHVibGljIHN0YXRpYyBBcnJheUxpc3Qg Z2V0Q2xhc3NJ
bmZvKCkNCgl7DQoJCXJldHVybiBjbGFzc0luZm87DQoJfQ0KCQ0KCS8qDQoJ ICogKG5vbi1K
YXZhZG9jKQ0KCSAqIA0KCSAqIEBzZWUgb3JnLmVjbGlwc2UudWkucGx1Z2lu LkFic3RyYWN0
VUlQbHVnaW4jc3RhcnQob3JnLm9zZ2kuZnJhbWV3b3JrLkJ1bmRsZUNvbnRl eHQpDQoJICov
DQoJcHVibGljIHZvaWQgc3RhcnQoQnVuZGxlQ29udGV4dCBjb250ZXh0KSB0 aHJvd3MgRXhj
ZXB0aW9uDQoJew0KCQlTeXN0ZW0ub3V0LnByaW50bG4oIkFjdGl2YXRvcjpz dGFydCgpIik7
DQoJCQ0KCQlzdXBlci5zdGFydChjb250ZXh0KTsNCgkJDQoJCWVudW1DbGFz c2VzKCk7DQoJ
CQ0KCQkvLyBmZXRjaCB0aGUgc2NlbmUgdXNlZCB0aGUgbGFzdCB0aW1lLCBp ZiBhbnkNCgkJ
c2NlbmVOYW1lID0gZ2V0RGVmYXVsdCgpLmdldFByZWZlcmVuY2VTdG9yZSgp LmdldFN0cmlu
ZyhQbHVnaW5Db25zdGFudHMuU0NFTkVOQU1FKTsNCgkJaWYgKHNjZW5lTmFt ZSA9PSAiIikN
CgkJew0KCQkJc2NlbmVOYW1lID0gUGx1Z2luQ29uc3RhbnRzLkRFRkFVTFRf U0NFTkVOQU1F
Ow0KCQl9DQoJfQ0KDQoJLyoNCgkgKiAobm9uLUphdmFkb2MpDQoJICogQHNl ZSBvcmcuZWNs
aXBzZS51aS5wbHVnaW4uQWJzdHJhY3RVSVBsdWdpbiNzdG9wKG9yZy5vc2dp LmZyYW1ld29y
ay5CdW5kbGVDb250ZXh0KQ0KCSAqLw0KCXB1YmxpYyB2b2lkIHN0b3AoQnVu ZGxlQ29udGV4
dCBjb250ZXh0KSB0aHJvd3MgRXhjZXB0aW9uDQoJew0KCQkvLyBzYXZlIHRo ZSBzY2VuZSB3
ZSB1c2VkIHRoaXMgdGltZQ0KCQlnZXREZWZhdWx0KCkuZ2V0UHJlZmVyZW5j ZVN0b3JlKCku
c2V0VmFsdWUoUGx1Z2luQ29uc3RhbnRzLlNDRU5FTkFNRSwgc2NlbmVOYW1l KTsNCgkJDQoJ
CXBsdWdpbiA9IG51bGw7DQoJCXN1cGVyLnN0b3AoY29udGV4dCk7DQoJfQ0K DQoJLyoqDQoJ
ICogUmV0dXJucyB0aGUgc2hhcmVkIGluc3RhbmNlDQoJICoNCgkgKiBAcmV0 dXJuIHRoZSBz
aGFyZWQgaW5zdGFuY2UNCgkgKi8NCglwdWJsaWMgc3RhdGljIEFjdGl2YXRv ciBnZXREZWZh
dWx0KCkNCgl7DQoJCXJldHVybiBwbHVnaW47DQoJfQ0KDQoJLyoqDQoJICog UmV0dXJucyBh
biBpbWFnZSBkZXNjcmlwdG9yIGZvciB0aGUgaW1hZ2UgZmlsZSBhdCB0aGUg Z2l2ZW4NCgkg
KiBwbHVnLWluIHJlbGF0aXZlIHBhdGgNCgkgKg0KCSAqIEBwYXJhbSBwYXRo IHRoZSBwYXRo
DQoJICogQHJldHVybiB0aGUgaW1hZ2UgZGVzY3JpcHRvcg0KCSAqLw0KCXB1 YmxpYyBzdGF0
aWMgSW1hZ2VEZXNjcmlwdG9yIGdldEltYWdlRGVzY3JpcHRvcihTdHJpbmcg cGF0aCkNCgl7
DQoJCXJldHVybiBpbWFnZURlc2NyaXB0b3JGcm9tUGx1Z2luKFBMVUdJTl9J RCwgcGF0aCk7
DQoJfQ0KDQoJLy8gZ2V0dGVycyBhbmQgc2V0dGVycyBmb3IgdGhlIHNjZW5l TmFtZSBhbmQg
dGhlIGdsVmlldyBvYmplY3RzDQoJcHVibGljIHN0YXRpYyBTdHJpbmcgZ2V0 U2NlbmVOYW1l
KCkNCgl7DQoJCXJldHVybiBzY2VuZU5hbWU7DQoJfQ0KDQoJcHVibGljIHN0 YXRpYyB2b2lk
IHNldFNjZW5lTmFtZSggU3RyaW5nIG5hbWUgKQ0KCXsNCgkJc2NlbmVOYW1l ID0gbmFtZTsN
Cgl9DQoNCglwdWJsaWMgc3RhdGljIHZvaWQgc2V0R0xWaWV3KCBPcGVuR0xW aWV3IGdsVmll
dyApDQoJew0KCQlBY3RpdmF0b3IuZ2xWaWV3ID0gZ2xWaWV3Ow0KCX0NCg0K CXB1YmxpYyBz
dGF0aWMgT3BlbkdMVmlldyBnZXRHTFZpZXcoKQ0KCXsNCgkJcmV0dXJuIGds VmlldzsNCgl9
DQoJDQoJLyoqDQoJICogVXNpbmcgdGhlIGJ1bmRsZSwgZW51bWVyYXRlIGFs bCB0aGUgY2xh
c3NlcyBpbiB0aGlzIHBsdWdpbiBhbmQgc2VlIHdoaWNoIA0KCSAqIG9uZXMg YXJlIGluIHRo
ZSBleGFtcGxlcyBwYWNrYWdlLiBUaG9zZSBhcmUgdGhlIG9uZXMgd2Ugd2ls bCBhbGxvdyB0
aGUgdXNlciB0byBjaG9vc2UuDQoJICogDQoJICogQHJldHVybiBsaXN0IG9m IGNsYXNzZXMg
dG8gY2hvb3NlIGZyb20NCgkgKi8NCglwdWJsaWMgdm9pZCBlbnVtQ2xhc3Nl cygpDQoJew0K
CQl0cnkNCgkJew0KCQkJRW51bWVyYXRpb24gZW50cmllcyA9IFBsYXRmb3Jt LmdldEJ1bmRs
ZShQbHVnaW5Db25zdGFudHMuUExVR0lOX0lEKS5maW5kRW50cmllcygiLyIs ICIqIiArICIu
Y2xhc3MiLCB0cnVlKTsNCgkJCXdoaWxlIChlbnRyaWVzLmhhc01vcmVFbGVt ZW50cygpKQ0K
CQkJew0KCQkJCVVSTCBlbnRyeSA9IChVUkwpIGVudHJpZXMubmV4dEVsZW1l bnQoKTsNCgkJ
CQkvLyBDaGFuZ2UgdGhlIFVSTHMgdG8gaGF2ZSBKYXZhIGNsYXNzIG5hbWVz DQoJCQkJU3Ry
aW5nIHBhdGggPSBlbnRyeS5nZXRQYXRoKCkucmVwbGFjZSgnLycsICcuJyk7 DQoJCQkJLy8g
c2VlIGlmIHRoZSBjbGFzcyBpcyBpbiB0aGUgcGFja2FnZSB3ZSBhcmUgaW50 ZXJlc3RlZCBp
biBhbmQgaXNuJ3QgYSBzdWJjbGFzcw0KCQkJCWludCBzdGFydCA9IHBhdGgu aW5kZXhPZihQ
bHVnaW5Db25zdGFudHMuRVhBTVBMRVNfUEFDS0FHRSk7DQoJCQkJaW50IHN1 YkNsYXNzID0g
cGF0aC5pbmRleE9mKCIkIik7DQoJCQkJaWYgKHN0YXJ0ID49IDAgJiYgc3Vi Q2xhc3MgPT0g
LTEgKQ0KCQkJCXsNCgkJCQkJLy8gc3RyaXAgb2ZmIHRoZSBjbGFzcyBzdWZm aXggYW5kIHdl
IGFyZSBkb25lDQoJCQkJCVN0cmluZyBuYW1lID0gcGF0aC5zdWJzdHJpbmco c3RhcnQsIHBh
dGgubGVuZ3RoKCkgLSAiLmNsYXNzIi5sZW5ndGgoKSk7DQoJCQkJDQoJCQkJ CUdMU2NlbmUJ
c2NlbmUgPSBjb25zdHJ1Y3RTY2VuZSggbmFtZSwgbnVsbCwgbnVsbCApOwkJ CQkJDQoJCQkJ
CWNsYXNzSW5mby5hZGQoIGdldENsYXNzSW5mbyhuYW1lLCBzY2VuZSkgKTsN CgkJCQl9DQoJ
CQl9DQoJCX0NCgkJY2F0Y2ggKEV4Y2VwdGlvbiBlKQ0KCQl7DQoJCQllLnBy aW50U3RhY2tU
cmFjZSgpOw0KCQl9DQoJfQ0KCQ0KCS8qKg0KCSAqIA0KCSAqIEBwYXJhbSBu YW1lDQoJICog
QHBhcmFtIHNjZW5lDQoJICogQHJldHVybg0KCSAqLw0KCXByaXZhdGUgQ2xh c3NJbmZvIGdl
dENsYXNzSW5mbyggU3RyaW5nIG5hbWUsIEdMU2NlbmUgc2NlbmUgKQ0KCXsN CgkJQ2xhc3NJ
bmZvIAlpbmZvID0gbmV3IENsYXNzSW5mbyggbmFtZSwgc2NlbmUuZ2V0RGVz Y3JpcHRpb24o
KSwgc2NlbmUuZ2V0TGFiZWwoKSApOw0KCQlTeXN0ZW0ub3V0LnByaW50bG4o ImluZm8gPSAi
ICsgaW5mbyk7DQoJDQoJCXJldHVybiBpbmZvOw0KCX0NCgkNCgkvKioNCgkg KiANCgkgKiBA
cGFyYW0gbmFtZQ0KCSAqIEBwYXJhbSBjb21wb3NpdGUNCgkgKiBAcGFyYW0g ZnJhbWUNCgkg
KiBAcmV0dXJuDQoJICovDQoJcHVibGljIHN0YXRpYyBHTFNjZW5lIGNvbnN0 cnVjdFNjZW5l
KCBTdHJpbmcgCQkJbmFtZSwNCgkJCQkJCQkJICAgICAgICAgIENvbXBvc2l0 ZSAJCWNvbXBv
c2l0ZSwNCgkJCQkJCQkJICAgICAgICAgIGphdmEuYXd0LkZyYW1lIAlmcmFt ZSApDQoJew0K
CQlHTFNjZW5lCW5ld1NjZW5lID0gbnVsbDsNCgkJT2JqZWN0W10gYXJncyA9 IHt9Ow0KCQlD
bGFzc1tdIHR5cGVzID0ge307DQoJCUNsYXNzPD8+IGNsYXNzZTsNCgkJDQoJ CXRyeQ0KCQl7
DQoJCQljbGFzc2UgPSBDbGFzcy5mb3JOYW1lKG5hbWUpOw0KCQkJDQoJCQlp ZiAoY29tcG9z
aXRlICE9IG51bGwgJiYgZnJhbWUgIT0gbnVsbCkNCgkJCXsNCgkJCQlhcmdz ID0gbmV3IE9i
amVjdFsyXTsNCgkJCQlhcmdzWzBdID0gY29tcG9zaXRlOw0KCQkJCWFyZ3Nb MV0gPSBmcmFt
ZTsNCgkJCQl0eXBlcyA9IG5ldyBDbGFzc1syXTsNCgkJCQl0eXBlc1swXSA9 IENvbXBvc2l0
ZS5jbGFzczsNCgkJCQl0eXBlc1sxXSA9IGphdmEuYXd0LkZyYW1lLmNsYXNz Ow0KCQkJCW5l
d1NjZW5lID0gKEdMU2NlbmUpIGNsYXNzZS5nZXRDb25zdHJ1Y3Rvcih0eXBl cykubmV3SW5z
dGFuY2UoYXJncyk7DQoJCQl9DQoJCQllbHNlDQoJCQkJbmV3U2NlbmUgPSAo R0xTY2VuZSkg
Y2xhc3NlLmdldENvbnN0cnVjdG9yKHR5cGVzKS5uZXdJbnN0YW5jZSgpOw0K CQl9DQoJCWNh
dGNoIChDbGFzc05vdEZvdW5kRXhjZXB0aW9uIGUpDQoJCXsNCgkJCWUucHJp bnRTdGFja1Ry
YWNlKCk7DQoJCX0NCgkJY2F0Y2ggKElsbGVnYWxBcmd1bWVudEV4Y2VwdGlv biBlKQ0KCQl7
DQoJCQllLnByaW50U3RhY2tUcmFjZSgpOw0KCQl9DQoJCWNhdGNoIChTZWN1 cml0eUV4Y2Vw
dGlvbiBlKQ0KCQl7DQoJCQllLnByaW50U3RhY2tUcmFjZSgpOw0KCQl9DQoJ CWNhdGNoIChJ
bnN0YW50aWF0aW9uRXhjZXB0aW9uIGUpDQoJCXsNCgkJCWUucHJpbnRTdGFj a1RyYWNlKCk7
DQoJCX0NCgkJY2F0Y2ggKElsbGVnYWxBY2Nlc3NFeGNlcHRpb24gZSkNCgkJ ew0KCQkJZS5w
cmludFN0YWNrVHJhY2UoKTsNCgkJfQ0KCQljYXRjaCAoSW52b2NhdGlvblRh cmdldEV4Y2Vw
dGlvbiBlKQ0KCQl7DQoJCQllLnByaW50U3RhY2tUcmFjZSgpOw0KCQl9DQoJ CWNhdGNoIChO
b1N1Y2hNZXRob2RFeGNlcHRpb24gZSkNCgkJew0KCQkJZS5wcmludFN0YWNr VHJhY2UoKTsN
CgkJfQ0KCQkJDQoJCXJldHVybiBuZXdTY2VuZTsNCgl9DQoJDQoJLyoqDQoJ ICogSnVzdCBh
IHNpbXBsZSBob2xkZXIgZm9yIG91ciBDbGFzc0luZm8NCgkgKg0KCSAqLw0K CXB1YmxpYyBj
bGFzcyBDbGFzc0luZm8gDQoJew0KCQlwdWJsaWMgU3RyaW5nCW5hbWU7DQoJ CXB1YmxpYyBT
dHJpbmcJZGVzY3JpcHRpb247DQoJCXB1YmxpYyBTdHJpbmcgCWxhYmVsOw0K CQkNCgkJcHVi
bGljIENsYXNzSW5mbyAoIFN0cmluZyBuLCBTdHJpbmcgZCwgU3RyaW5nIGwg KQ0KCQl7DQoJ
CQluYW1lID0gbjsNCgkJCWRlc2NyaXB0aW9uID0gZDsNCgkJCWxhYmVsID0g bDsNCgkJfQ0K
CX0NCn0=
--B_3316854740_5862917--
Re: Plugin loading fails in 3.3/3.4 [message #334432 is a reply to message #334425] Mon, 09 February 2009 00:30 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: riwright.adobe.com

OK. After a little digging I found a few more things. First, I had a raw
Iterator, which Eclipse warned me about, but which worked fine in 3.2. But
apparently not in 3.4. It also caused another weird behaviour in that there
were no local variables shown.

So I fixed the Iterator and suddenly I had local variables and got more info
back in the stack trace. Turns out that Eclipse is apparently complaining
that it cannot instantiate one of my classes. I call Class.forName() with
the name of one of my classes. Since I am using JOGL, that class extends
GLEventListener, which at base is a native class accessed via JNI. All the
proper JARs and JNILibs are in /Library/Java/Extensions and the
java.library.path points to it. This all seems correct to me. The build
path for the project shows the JOGL libs under the JRE System libs in the
build path dialog. Again, this all seems correct.

I'm still digging, but if this suggests anything to anybody, I'd appreciate
it.

TIA, Ric


On 2/7/09 12:32 PM, in article C5B32FD4.18A37%riwright@adobe.com, "Ric
Wright" <riwright@adobe.com> wrote:

> Thanks for responding, Derek.
>
> AFAIK, the activator is valid (attached). When brought up in Eclipse, there
> is only a warning about a raw iterator (that I will fix once I get past
> this).
>
> I did read through the migration and the only thing that seemed relevant was
> the boot delegation order. I tried the org.osgi.framework.bootdelegation=*
> in the config.ini, but it made no difference, so that doesn't seem to be it.
>
> The execution never gets to the Activator BTW, neither ctor nor start()
> methods are ever called. My suspicion is that one of the dependencies (e.g.
> The JOGL or Java3D jars can't be resolved so the message is a little bogus.
> But I don't know how to find out WHICH class it thinks it can't find. It
> says com.geofx.opengl.view.OpenGLView but I think that is misleading since
> that file IS in the exported package, etc. But I could be missing
> something.
>
> I included the plugin.xml, manifest.xml etc. in the previous post on this
> thread.
>
> Thanks, Ric
>
>
> On 2/7/09 10:54 AM, in article gmkld3$9h$1@build.eclipse.org, "Derek"
> <subs@_nospam_consertum.com> wrote:
>
>> I think it more likely that your activator isn't a valid activator for
>> 3.3. Have you tried opening the source in a 3.3 PDE and see what it
>> complains about?
>>
>> Have you looked at the 3.3 Migration Guide?
>>
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/>>
p
>> orting/eclipse_3_3_porting_guide.html
>>
>> Ric Wright wrote:
>>> This is a post I put up in the newbie section, but got no response. I
>>> subsequently saw several posts about invalid activators on this list (though
>>> none were entirely relevant to my case). The odd thing about this is that
>>> it is absolutely due to some change in classloaders from 3.2 to 3.3. I'm
>>> still working on it, but if anyone can make any suggestions, I would be
>>> appreciative.
>>>
>>> TIA, Ric
>>>
>>> --------------------------------------------------
>>> I've gotten a little farther. I turned on the debugging in the launch tab
>>> and I found:
>>>
>>> !ENTRY org.eclipse.osgi 2 0 2009-02-06 16:28:48.779
>>> !MESSAGE The activator
>>> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is
>>> invalid
>>> !STACK 0
>>> org.osgi.framework.BundleException: The activator
>>> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is invalid
>>>
>>> at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(
>>> AbstractBundle.java:146)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.s tart(BundleConte
>>> xtImpl.java:980)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWor ker(BundleHost.j
>>> ava:346)
>>>
>>> Not clear what change between 3.2 and 3.3 would have produced this error.
>>> Some spelunking suggests it might have something to do with the third party
>>> jars
>>> (e.g. Jogl) that I use but no further clues. But a JOGL view works fine
>>> only plugins fail. Any suggestions or tips welcome.
>>>
>>> TIA, Ric
>>>
>>> On 2/6/09 2:43 PM, in article C5B1FCFF.161BC%riwright@adobe.com, "Ric
>>> Wright" <riwright@adobe.com> wrote:
>>>
>>>> I have a plugin that I wrote a while ago. It's a normal Eclipse plugin.
>>>> It's main class is com.geofx.opengl.OpenGLView. The plugin loads and runs
>>>> without problems in Eclipse 3.2 but fails in 3.3 and 3.4 with the message
>>>>
>>>> "Could not create the view: Plug-in com.geofx.opengl.view was unable to
>>>> load
>>>> class com.geofx.opengl.view.OpenGLView."
>>>>
>>>> At a guess, classloading changed in some way from 3.2 to 3.3 and 3.4. To
>>>> be
>>>> honest, classloaders are a black art to me (and wouldn't mind keeping it
>>>> that way). I don't really know how to start figuring this out.
>>>>
>>>> I posted a question here once before about this but didn't get any
>>>> pointers.
>>>> I am happy (or at least resigned) to dig into this, but frankly not sure
>>>> where to start. Any pointers would be appreciated.
>>>>
>>>> Thanks,
>>>> Ric
>>>>
>>>>
>>>
>>>
>>
>
Loading Native Libraries (was Re: Plugin loading fails in 3.3/3.4) [message #334449 is a reply to message #334432] Mon, 09 February 2009 23:07 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: riwright.adobe.com

I poked at this a little more during lunch and I am still puzzled.
Previously, on Windows, I would point at the JOGL jar, and then set the
native library location field. However, since Eclipse found the jars on its
own and placed them in JRE System Library section of the build path dialog,
I thought I would just set the native location there. But no soap. Eclipse
lets me set it, but immediately it clears it again - read-only perhaps? I
suppose I could move the JOGL jars somewhere else and explicitly add them
and set their native library attributes, etc. But since Eclipse and the Mac
have done 90% of the task seamlessly, that seems like a shame.

Does anyone know the right way to do this?

TIA, Ric


On 2/8/09 4:30 PM, in article C5B4B919.1B1AC%riwright@adobe.com, "Ric
Wright" <riwright@adobe.com> wrote:

> OK. After a little digging I found a few more things. First, I had a raw
> Iterator, which Eclipse warned me about, but which worked fine in 3.2. But
> apparently not in 3.4. It also caused another weird behaviour in that there
> were no local variables shown.
>
> So I fixed the Iterator and suddenly I had local variables and got more info
> back in the stack trace. Turns out that Eclipse is apparently complaining
> that it cannot instantiate one of my classes. I call Class.forName() with
> the name of one of my classes. Since I am using JOGL, that class extends
> GLEventListener, which at base is a native class accessed via JNI. All the
> proper JARs and JNILibs are in /Library/Java/Extensions and the
> java.library.path points to it. This all seems correct to me. The build
> path for the project shows the JOGL libs under the JRE System libs in the
> build path dialog. Again, this all seems correct.
>
> I'm still digging, but if this suggests anything to anybody, I'd appreciate
> it.
>
> TIA, Ric
>
>
> On 2/7/09 12:32 PM, in article C5B32FD4.18A37%riwright@adobe.com, "Ric
> Wright" <riwright@adobe.com> wrote:
>
>> Thanks for responding, Derek.
>>
>> AFAIK, the activator is valid (attached). When brought up in Eclipse, there
>> is only a warning about a raw iterator (that I will fix once I get past
>> this).
>>
>> I did read through the migration and the only thing that seemed relevant was
>> the boot delegation order. I tried the org.osgi.framework.bootdelegation=*
>> in the config.ini, but it made no difference, so that doesn't seem to be it.
>>
>> The execution never gets to the Activator BTW, neither ctor nor start()
>> methods are ever called. My suspicion is that one of the dependencies (e.g.
>> The JOGL or Java3D jars can't be resolved so the message is a little bogus.
>> But I don't know how to find out WHICH class it thinks it can't find. It
>> says com.geofx.opengl.view.OpenGLView but I think that is misleading since
>> that file IS in the exported package, etc. But I could be missing
>> something.
>>
>> I included the plugin.xml, manifest.xml etc. in the previous post on this
>> thread.
>>
>> Thanks, Ric
>>
>>
>> On 2/7/09 10:54 AM, in article gmkld3$9h$1@build.eclipse.org, "Derek"
>> <subs@_nospam_consertum.com> wrote:
>>
>>> I think it more likely that your activator isn't a valid activator for
>>> 3.3. Have you tried opening the source in a 3.3 PDE and see what it
>>> complains about?
>>>
>>> Have you looked at the 3.3 Migration Guide?
>>>
>
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/>>
>
> p
>>> orting/eclipse_3_3_porting_guide.html
>>>
>>> Ric Wright wrote:
>>>> This is a post I put up in the newbie section, but got no response. I
>>>> subsequently saw several posts about invalid activators on this list
>>>> (though
>>>> none were entirely relevant to my case). The odd thing about this is that
>>>> it is absolutely due to some change in classloaders from 3.2 to 3.3. I'm
>>>> still working on it, but if anyone can make any suggestions, I would be
>>>> appreciative.
>>>>
>>>> TIA, Ric
>>>>
>>>> --------------------------------------------------
>>>> I've gotten a little farther. I turned on the debugging in the launch tab
>>>> and I found:
>>>>
>>>> !ENTRY org.eclipse.osgi 2 0 2009-02-06 16:28:48.779
>>>> !MESSAGE The activator
>>>> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is
>>>> invalid
>>>> !STACK 0
>>>> org.osgi.framework.BundleException: The activator
>>>> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is invalid
>>>>
>>>> at
>>>>
org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator >>>>
(
>>>> AbstractBundle.java:146)
>>>> at
>>>>
org.eclipse.osgi.framework.internal.core.BundleContextImpl.s tart(BundleCont >>>>
e
>>>> xtImpl.java:980)
>>>> at
>>>>
org.eclipse.osgi.framework.internal.core.BundleHost.startWor ker(BundleHost. >>>>
j
>>>> ava:346)
>>>>
>>>> Not clear what change between 3.2 and 3.3 would have produced this error.
>>>> Some spelunking suggests it might have something to do with the third party
>>>> jars
>>>> (e.g. Jogl) that I use but no further clues. But a JOGL view works fine
>>>> only plugins fail. Any suggestions or tips welcome.
>>>>
>>>> TIA, Ric
>>>>
>>>> On 2/6/09 2:43 PM, in article C5B1FCFF.161BC%riwright@adobe.com, "Ric
>>>> Wright" <riwright@adobe.com> wrote:
>>>>
>>>>> I have a plugin that I wrote a while ago. It's a normal Eclipse plugin.
>>>>> It's main class is com.geofx.opengl.OpenGLView. The plugin loads and runs
>>>>> without problems in Eclipse 3.2 but fails in 3.3 and 3.4 with the message
>>>>>
>>>>> "Could not create the view: Plug-in com.geofx.opengl.view was unable to
>>>>> load
>>>>> class com.geofx.opengl.view.OpenGLView."
>>>>>
>>>>> At a guess, classloading changed in some way from 3.2 to 3.3 and 3.4. To
>>>>> be
>>>>> honest, classloaders are a black art to me (and wouldn't mind keeping it
>>>>> that way). I don't really know how to start figuring this out.
>>>>>
>>>>> I posted a question here once before about this but didn't get any
>>>>> pointers.
>>>>> I am happy (or at least resigned) to dig into this, but frankly not sure
>>>>> where to start. Any pointers would be appreciated.
>>>>>
>>>>> Thanks,
>>>>> Ric
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: Loading Native Libraries (was Re: Plugin loading fails in 3.3/3.4) [message #334496 is a reply to message #334449] Thu, 12 February 2009 17:07 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: riwright.adobe.com

I guess nobody knows the answer (or is willing to say ;-). I have now
reproduced the same problem on Windows, so it is not a Mac issue. And I set
up the jars like I always do, with the jar in an external folder and the
native library beside it and the build path points to both. But I still get
an error that it cannot find a public class in the native library. But it
compiles fine - it is just at runtime it fails. This strongly suggests to
me that Eclipse is not loading the native library. The exact same code and
procedures work fine in Eclipse 3.2.

I found this:
http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse. platform.doc.isv
/porting/3.3/incompatibilities.html
And section 3 talks about boot delegation changes in class loading, but
frankly that is out of my ken.

Can some classloading maven suggest what I might do next? Could this be
some manifest/buddy-loading issue? I'll look at that next, but any
suggestions would be appreciated.

Thanks, Ric


On 2/9/09 3:07 PM, in article C5B5F73E.1B2F8%riwright@adobe.com, "Ric
Wright" <riwright@adobe.com> wrote:

> I poked at this a little more during lunch and I am still puzzled.
> Previously, on Windows, I would point at the JOGL jar, and then set the
> native library location field. However, since Eclipse found the jars on its
> own and placed them in JRE System Library section of the build path dialog,
> I thought I would just set the native location there. But no soap. Eclipse
> lets me set it, but immediately it clears it again - read-only perhaps? I
> suppose I could move the JOGL jars somewhere else and explicitly add them
> and set their native library attributes, etc. But since Eclipse and the Mac
> have done 90% of the task seamlessly, that seems like a shame.
>
> Does anyone know the right way to do this?
>
> TIA, Ric
>
>
> On 2/8/09 4:30 PM, in article C5B4B919.1B1AC%riwright@adobe.com, "Ric
> Wright" <riwright@adobe.com> wrote:
>
>> OK. After a little digging I found a few more things. First, I had a raw
>> Iterator, which Eclipse warned me about, but which worked fine in 3.2. But
>> apparently not in 3.4. It also caused another weird behaviour in that there
>> were no local variables shown.
>>
>> So I fixed the Iterator and suddenly I had local variables and got more info
>> back in the stack trace. Turns out that Eclipse is apparently complaining
>> that it cannot instantiate one of my classes. I call Class.forName() with
>> the name of one of my classes. Since I am using JOGL, that class extends
>> GLEventListener, which at base is a native class accessed via JNI. All the
>> proper JARs and JNILibs are in /Library/Java/Extensions and the
>> java.library.path points to it. This all seems correct to me. The build
>> path for the project shows the JOGL libs under the JRE System libs in the
>> build path dialog. Again, this all seems correct.
>>
>> I'm still digging, but if this suggests anything to anybody, I'd appreciate
>> it.
>>
>> TIA, Ric
>>
>>
>> On 2/7/09 12:32 PM, in article C5B32FD4.18A37%riwright@adobe.com, "Ric
>> Wright" <riwright@adobe.com> wrote:
>>
>>> Thanks for responding, Derek.
>>>
>>> AFAIK, the activator is valid (attached). When brought up in Eclipse, there
>>> is only a warning about a raw iterator (that I will fix once I get past
>>> this).
>>>
>>> I did read through the migration and the only thing that seemed relevant was
>>> the boot delegation order. I tried the org.osgi.framework.bootdelegation=*
>>> in the config.ini, but it made no difference, so that doesn't seem to be it.
>>>
>>> The execution never gets to the Activator BTW, neither ctor nor start()
>>> methods are ever called. My suspicion is that one of the dependencies (e.g.
>>> The JOGL or Java3D jars can't be resolved so the message is a little bogus.
>>> But I don't know how to find out WHICH class it thinks it can't find. It
>>> says com.geofx.opengl.view.OpenGLView but I think that is misleading since
>>> that file IS in the exported package, etc. But I could be missing
>>> something.
>>>
>>> I included the plugin.xml, manifest.xml etc. in the previous post on this
>>> thread.
>>>
>>> Thanks, Ric
>>>
>>>
>>> On 2/7/09 10:54 AM, in article gmkld3$9h$1@build.eclipse.org, "Derek"
>>> <subs@_nospam_consertum.com> wrote:
>>>
>>>> I think it more likely that your activator isn't a valid activator for
>>>> 3.3. Have you tried opening the source in a 3.3 PDE and see what it
>>>> complains about?
>>>>
>>>> Have you looked at the 3.3 Migration Guide?
>>>>
>>
>
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/>>
>
>>
>> p
>>>> orting/eclipse_3_3_porting_guide.html
>>>>
>>>> Ric Wright wrote:
>>>>> This is a post I put up in the newbie section, but got no response. I
>>>>> subsequently saw several posts about invalid activators on this list
>>>>> (though
>>>>> none were entirely relevant to my case). The odd thing about this is that
>>>>> it is absolutely due to some change in classloaders from 3.2 to 3.3. I'm
>>>>> still working on it, but if anyone can make any suggestions, I would be
>>>>> appreciative.
>>>>>
>>>>> TIA, Ric
>>>>>
>>>>> --------------------------------------------------
>>>>> I've gotten a little farther. I turned on the debugging in the launch tab
>>>>> and I found:
>>>>>
>>>>> !ENTRY org.eclipse.osgi 2 0 2009-02-06 16:28:48.779
>>>>> !MESSAGE The activator
>>>>> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is
>>>>> invalid
>>>>> !STACK 0
>>>>> org.osgi.framework.BundleException: The activator
>>>>> com.geofx.opengl.view.Activator for bundle com.geofx.opengl.view is
>>>>> invalid
>>>>>
>>>>> at
>>>>>
>
org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator >>>>
>
> (
>>>>> AbstractBundle.java:146)
>>>>> at
>>>>>
>
org.eclipse.osgi.framework.internal.core.BundleContextImpl.s tart(BundleCont >>>>
>
> e
>>>>> xtImpl.java:980)
>>>>> at
>>>>>
>
org.eclipse.osgi.framework.internal.core.BundleHost.startWor ker(BundleHost. >>>>
>
> j
>>>>> ava:346)
>>>>>
>>>>> Not clear what change between 3.2 and 3.3 would have produced this error.
>>>>> Some spelunking suggests it might have something to do with the third
>>>>> party
>>>>> jars
>>>>> (e.g. Jogl) that I use but no further clues. But a JOGL view works fine
>>>>> only plugins fail. Any suggestions or tips welcome.
>>>>>
>>>>> TIA, Ric
>>>>>
>>>>> On 2/6/09 2:43 PM, in article C5B1FCFF.161BC%riwright@adobe.com, "Ric
>>>>> Wright" <riwright@adobe.com> wrote:
>>>>>
>>>>>> I have a plugin that I wrote a while ago. It's a normal Eclipse plugin.
>>>>>> It's main class is com.geofx.opengl.OpenGLView. The plugin loads and
>>>>>> runs
>>>>>> without problems in Eclipse 3.2 but fails in 3.3 and 3.4 with the
>>>>>> message
>>>>>>
>>>>>> "Could not create the view: Plug-in com.geofx.opengl.view was unable to
>>>>>> load
>>>>>> class com.geofx.opengl.view.OpenGLView."
>>>>>>
>>>>>> At a guess, classloading changed in some way from 3.2 to 3.3 and 3.4. To
>>>>>> be
>>>>>> honest, classloaders are a black art to me (and wouldn't mind keeping it
>>>>>> that way). I don't really know how to start figuring this out.
>>>>>>
>>>>>> I posted a question here once before about this but didn't get any
>>>>>> pointers.
>>>>>> I am happy (or at least resigned) to dig into this, but frankly not sure
>>>>>> where to start. Any pointers would be appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>> Ric
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Loading Native Libraries (was Re: Plugin loading fails in 3.3/3.4) [message #334499 is a reply to message #334496] Thu, 12 February 2009 20:02 Go to previous messageGo to next message
Walter Harley is currently offline Walter HarleyFriend
Messages: 847
Registered: July 2009
Senior Member
"Ric Wright" <riwright@adobe.com> wrote in message
news:C5B99748.1B892%riwright@adobe.com...
> Can some classloading maven suggest what I might do next? Could this be
> some manifest/buddy-loading issue? I'll look at that next, but any
> suggestions would be appreciated.

I suspect it's got more to do with execution environment definitions,
because it sounds like you're talking about libraries that are optional JRE
components and that aren't getting picked up at runtime.

I don't know the answer, but at least maybe that gives you another search
term to work with.
Re: Loading Native Libraries (was Re: Plugin loading fails in 3.3/3.4) [message #334503 is a reply to message #334499] Thu, 12 February 2009 21:57 Go to previous messageGo to next message
KarlFriend
Messages: 10
Registered: July 2009
Location: USA
Junior Member
I haven't been following this thread. This is the first post I have
seen. If you are talking about loading native code within a plug-in, you
could use the Bundle-NativeCode entry in manifest and provide a plug-in
relative path to the libraries.

Karl

Walter Harley wrote:
> "Ric Wright" <riwright@adobe.com> wrote in message
> news:C5B99748.1B892%riwright@adobe.com...
>> Can some classloading maven suggest what I might do next? Could this be
>> some manifest/buddy-loading issue? I'll look at that next, but any
>> suggestions would be appreciated.
>
> I suspect it's got more to do with execution environment definitions,
> because it sounds like you're talking about libraries that are optional JRE
> components and that aren't getting picked up at runtime.
>
> I don't know the answer, but at least maybe that gives you another search
> term to work with.
>
>
Re: Loading Native Libraries (was Re: Plugin loading fails in 3.3/3.4) [message #334519 is a reply to message #334499] Fri, 13 February 2009 19:39 Go to previous message
Eclipse UserFriend
Originally posted by: riwright.adobe.com

Walter and I conversed offline and converged on giving up on my other
approach and I simply created a new JOGL plugin by importing the jars.
Worked great on Windows. On the Mac I haven't been able to test due to
another problem. I'll post about that in a minute. When I get this working
on both platforms I'll try to write it up somewhere so others may profit
from my errors.

My thanks to Harley for his advice!


On 2/12/09 12:02 PM, in article gn1v87$lh9$1@build.eclipse.org, "Walter
Harley" <eclipse@cafewalter.com> wrote:

> "Ric Wright" <riwright@adobe.com> wrote in message
> news:C5B99748.1B892%riwright@adobe.com...
>> Can some classloading maven suggest what I might do next? Could this be
>> some manifest/buddy-loading issue? I'll look at that next, but any
>> suggestions would be appreciated.
>
> I suspect it's got more to do with execution environment definitions,
> because it sounds like you're talking about libraries that are optional JRE
> components and that aren't getting picked up at runtime.
>
> I don't know the answer, but at least maybe that gives you another search
> term to work with.
>
>
Previous Topic:[FieldAssist] Pasting into a control with field assist not working?
Next Topic:enabledWhen for handlers and editors
Goto Forum:
  


Current Time: Fri Sep 27 07:14:46 GMT 2024

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

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

Back to the top