| How to debug classloading failures? [message #248815] |
Thu, 03 June 2004 13:33  |
Eclipse User |
|
|
|
Originally posted by: mark.melvin.dspfactory.com
Since switching to 3.0RC1 my preference page no longer works. It tells
me my plugin failed to load the class. The same code works fine in
3.0M9. Unfortunately there is only a dialog, no traceback, no error
log, etc.
My question is - what is the usual way to go about debugging this sort
of failure? My class never attempts to get instantiated - it simply
cannot be found - so breakpoints in the constructor obviously are of no
help. Is there a 'standard' method of tracking down these sorts of bugs?
Thanks,
Mark.
|
|
|
| Re: How to debug classloading failures? [message #249039 is a reply to message #248815] |
Thu, 03 June 2004 19:21  |
| Eclipse User |
|
|
|
Originally posted by: mark.melvin.dspfactory.com
Mark Melvin wrote:
> Since switching to 3.0RC1 my preference page no longer works. It tells
> me my plugin failed to load the class. The same code works fine in
> 3.0M9. Unfortunately there is only a dialog, no traceback, no error
> log, etc.
>
> My question is - what is the usual way to go about debugging this sort
> of failure? My class never attempts to get instantiated - it simply
> cannot be found - so breakpoints in the constructor obviously are of no
> help. Is there a 'standard' method of tracking down these sorts of bugs?
>
Well, after much mucking about - I have found that somehow my
MANIFEST.MF file got screwed about with and my "Bundle-Activator:" was
set to some arcane value as follows:
Bundle-Activator: org.eclipse.core.internal.compatibility.PluginActivator
I noticed my other plugin was set to my main plugin class, so I changed
it to my main plugin class and voila - it works now. What the hell?!
How did this get changed? I've noticed other things are slightly
different as well.
While I'm on this topic - *many* people (including myself) have posed
the question "Should we be using OSGI-style plugins?" with no response
but deafening silence. Eclipse still does not default to using them -
so what is the deal. Is this stuff broken? Should we not be using it?
There was another one today - see the post entitled "Is it now time to
convert plugins to OSGI?"
Tha problem is it that it is almost impossible to debug these errors! I
only found this last bug by looking at the active plugins in the OSGI
console and noticing my dependent plugin was not even active. No wonder
it couldn't find the class! So I tried to manually start it and got a
huge dump of errors boiling down to the Bundle-Activator failed to load
my plugin. This error must have already been fired once when my plugin
attempted to load its dependents - but I was not notified, nor was it
dumped to the console. It is like working with a black box here...
So what *is* the deal? Should I be pulling all this out and reverting
to plugin.xml-style plugins, or should I keep slamming my head against
the desk? Is version 3.0 going to include full support for OSGI stuff,
or is it going to be trial and error?
Sorry if I seem frustrated, but I am going nuts here trying to figure
some of this stuff out. I have been filing bugs like mad in Bugzilla in
the meantime. I see others commenting that we are using pre-release
versions and to expect bugs, but I assume "Release Candidates" are
called that because they are considered "releaseable".
Anyone else have any comments, or am I just cranky today? I need
another c-c-c-coffee...
Thanks,
Mark.
|
|
|
|
| OSGI or no? That is the question. [WAS - Re: How to debug classloading failures?] [message #249479 is a reply to message #249099] |
Fri, 04 June 2004 14:14 |
| Eclipse User |
|
|
|
Originally posted by: mark.melvin.dspfactory.com
Tom Johnson wrote:
> Mark Melvin wrote:
>
> (snip)
>
>> While I'm on this topic - *many* people (including myself) have posed
>> the question "Should we be using OSGI-style plugins?" with no response
>> but deafening silence. Eclipse still does not default to using them -
>> so what is the deal. Is this stuff broken? Should we not be using
>> it? There was another one today - see the post entitled "Is it now
>> time to convert plugins to OSGI?"
>
>
> (snip)
>
> I concur with your frustration. It *seems* to me as if there are at
> least three phases of the "OSGI transition":
>
> 1. ignore it altogether, even if it means lagging the 3.0 milestones
>
> 2. try to keep up with milestones (3.0RC1 included) except for
> MANIFEST.MF changes
>
> 3. "full" OSGI bundle compliance (whatever that means)
>
> From something Rich Kulp posted earlier, he seems to be advising people
> not to rush to use the MANIFEST.MF files at all; however there is a
> tendency for the PDE plugin.xml editor to generate them for you.
>
> So, I think I'm asking the same question as you when I ask: "what can
> we do to get all of the 'good' features in 3.0RC1 but avoid the
> 'bleeding edge' when it comes to OSGI"?
>
Nice to know I am not alone....I guess we'll find out after 3.0. Too
bad - I need to release a milestone by June 15 and I am kind of working
blindly on this. It's too late for me to change so I'm sticking with
OSGI and the manifests, and the latest 'Release Candidates'. Hopefully
my current situation (it seems to work now...) will hold for a couple
more weeks, and we'll find out 3.0 ecourages their use. <crosses fingers>
Mark.
|
|
|
|
| Re: OSGI or no? That is the question. [WAS - Re: How to debug classloading failures?] [message #249830 is a reply to message #249712] |
Sat, 05 June 2004 00:35 |
| Eclipse User |
|
|
|
Originally posted by: ed.burnette.REMOVE.THIS.sas.com
I recently converted a couple of my plug-ins and it's not a big deal. Two
resources for you:
- Source for org.eclipse.core.runtime, which has been converted and makes a
good example.
- Jeff McAffer's Eclipse 3.0 Runtime Adoption Guide at:
http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform -core-home/runtime/adoption.html
One advantage of converting is that you can get rid of the compatability
layers, saving a little memory and performance. See the Adoption Guide for
more details.
--
Ed Burnette, co-author, Eclipse in Action
www.eclipsepowered.org
"Tom Johnson" <tdjohns1@rockwellcollins.com> wrote in message
news:c9qfll$54j$1@eclipse.org...
>
> The root cause of the NPE? Using AbstractUIPlugin.getPreferenceStore()
> inside the constructor. Probably not a smart thing to do, which is why
> I have now asked for a "good" example of plugin preference management
> using the new API. I got into the present situation by mimicing a
> no-so-good example in the first place, and didn't bother to understand
> it while it seemed to work.
>
> Tom Johnson
|
|
|
| Re: OSGI or no? That is the question. [WAS - Re: How to debug classloading failures?] [message #250720 is a reply to message #249479] |
Wed, 09 June 2004 00:12 |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
In 3.0, osgi will be here and is first class from a runtime point of
view since it is the runtime.
Eclipse does not use all the power of the new runtime because it came
late (M6) and there were not enough time for all the components to fully
adapt to it.
The plugin.xml is kept in the new world for several reasons:
- to specify extension / extension point
- for people that don't want to worry about the new way to
express dependencies
- Shelter users from changes that could occur in the forecoming osgi
4.0 spec (like the name of the entries in the manifest.mf) where some
changes we used should be ratified.
- because tooling to express new dependencies if not first class yet
(however tooling fully supports bundles and understand manifest.mf)
Even if you don't have a plugin.xml, the compatibility layer and the
manifest generator that converts on the fly your plugin.xml allows you
to fully take advantage of the osgi facilities since you can have an
activator, access the bundleContext to declare services, etc. In this
case I would say that "like the suit does not make the man, the manifest
does not make the plugin" :-). This is for example how the runtime or
the update.configurator take advantage (or used to) of the new runtime
without having to write a manifest.mf.
So basically there is several level to the 3.0 runtime adoption:
1) fix the deprecation and go through the runtime API to access everything
2) fix the deprecation and directly use osgi API where possible (however
be careful because some API have not been ratified yet and are therefore
subject to change)
HTH,
PaScaL
Mark Melvin wrote:
> Tom Johnson wrote:
>
>> Mark Melvin wrote:
>>
>> (snip)
>>
>>> While I'm on this topic - *many* people (including myself) have posed
>>> the question "Should we be using OSGI-style plugins?" with no
>>> response but deafening silence. Eclipse still does not default to
>>> using them - so what is the deal. Is this stuff broken? Should we
>>> not be using it? There was another one today - see the post entitled
>>> "Is it now time to convert plugins to OSGI?"
>>
>>
>>
>> (snip)
>>
>> I concur with your frustration. It *seems* to me as if there are at
>> least three phases of the "OSGI transition":
>>
>> 1. ignore it altogether, even if it means lagging the 3.0 milestones
>>
>> 2. try to keep up with milestones (3.0RC1 included) except for
>> MANIFEST.MF changes
>>
>> 3. "full" OSGI bundle compliance (whatever that means)
>>
>> From something Rich Kulp posted earlier, he seems to be advising people
>> not to rush to use the MANIFEST.MF files at all; however there is a
>> tendency for the PDE plugin.xml editor to generate them for you.
>>
>> So, I think I'm asking the same question as you when I ask: "what can
>> we do to get all of the 'good' features in 3.0RC1 but avoid the
>> 'bleeding edge' when it comes to OSGI"?
>>
>
> Nice to know I am not alone....I guess we'll find out after 3.0. Too
> bad - I need to release a milestone by June 15 and I am kind of working
> blindly on this. It's too late for me to change so I'm sticking with
> OSGI and the manifests, and the latest 'Release Candidates'. Hopefully
> my current situation (it seems to work now...) will hold for a couple
> more weeks, and we'll find out 3.0 ecourages their use. <crosses fingers>
>
> Mark.
|
|
|
| Re: OSGI or no? That is the question. [WAS - Re: How to debug classloading failures?] [message #250936 is a reply to message #250720] |
Wed, 09 June 2004 14:09 |
| Eclipse User |
|
|
|
Originally posted by: mark.melvin.dspfactory.com
Thanks for the response, Pascal. I'll digest this one, and see if I
have any questions afterwards. ;o)
Mark.
Pascal Rapicault wrote:
> In 3.0, osgi will be here and is first class from a runtime point of
> view since it is the runtime.
> Eclipse does not use all the power of the new runtime because it came
> late (M6) and there were not enough time for all the components to fully
> adapt to it.
>
> The plugin.xml is kept in the new world for several reasons:
> - to specify extension / extension point
> - for people that don't want to worry about the new way to
> express dependencies
> - Shelter users from changes that could occur in the forecoming osgi
> 4.0 spec (like the name of the entries in the manifest.mf) where some
> changes we used should be ratified.
> - because tooling to express new dependencies if not first class yet
> (however tooling fully supports bundles and understand manifest.mf)
>
> Even if you don't have a plugin.xml, the compatibility layer and the
> manifest generator that converts on the fly your plugin.xml allows you
> to fully take advantage of the osgi facilities since you can have an
> activator, access the bundleContext to declare services, etc. In this
> case I would say that "like the suit does not make the man, the manifest
> does not make the plugin" :-). This is for example how the runtime or
> the update.configurator take advantage (or used to) of the new runtime
> without having to write a manifest.mf.
>
> So basically there is several level to the 3.0 runtime adoption:
> 1) fix the deprecation and go through the runtime API to access everything
> 2) fix the deprecation and directly use osgi API where possible (however
> be careful because some API have not been ratified yet and are therefore
> subject to change)
>
> HTH,
>
> PaScaL
>
> Mark Melvin wrote:
>
>> Tom Johnson wrote:
>>
>>> Mark Melvin wrote:
>>>
>>> (snip)
>>>
>>>> While I'm on this topic - *many* people (including myself) have
>>>> posed the question "Should we be using OSGI-style plugins?" with no
>>>> response but deafening silence. Eclipse still does not default to
>>>> using them - so what is the deal. Is this stuff broken? Should we
>>>> not be using it? There was another one today - see the post
>>>> entitled "Is it now time to convert plugins to OSGI?"
>>>
>>>
>>>
>>>
>>> (snip)
>>>
>>> I concur with your frustration. It *seems* to me as if there are at
>>> least three phases of the "OSGI transition":
>>>
>>> 1. ignore it altogether, even if it means lagging the 3.0 milestones
>>>
>>> 2. try to keep up with milestones (3.0RC1 included) except for
>>> MANIFEST.MF changes
>>>
>>> 3. "full" OSGI bundle compliance (whatever that means)
>>>
>>> From something Rich Kulp posted earlier, he seems to be advising people
>>> not to rush to use the MANIFEST.MF files at all; however there is a
>>> tendency for the PDE plugin.xml editor to generate them for you.
>>>
>>> So, I think I'm asking the same question as you when I ask: "what can
>>> we do to get all of the 'good' features in 3.0RC1 but avoid the
>>> 'bleeding edge' when it comes to OSGI"?
>>>
>>
>> Nice to know I am not alone....I guess we'll find out after 3.0. Too
>> bad - I need to release a milestone by June 15 and I am kind of
>> working blindly on this. It's too late for me to change so I'm
>> sticking with OSGI and the manifests, and the latest 'Release
>> Candidates'. Hopefully my current situation (it seems to work now...)
>> will hold for a couple more weeks, and we'll find out 3.0 ecourages
>> their use. <crosses fingers>
>>
>> Mark.
|
|
|
Powered by
FUDForum. Page generated in 0.05063 seconds
] 
Search
Help
Register
Login
Home
