Eclipse Community Forums: Equinox » Invalid Bundle Activator all of a sudden!?

Home » Eclipse Projects » Equinox » Invalid Bundle Activator all of a sudden!?

Invalid Bundle Activator all of a sudden!? [message #44803]

Thu, 22 July 2004 11:06

Eclipse User

Originally posted by: mark.melvin.dspfactory.com

Hi,

I have just built a new drop of my platform and plugins to find that
none of my classes can be instantiated. I swear this worked yesterday
before I went home!

Everything runs fine in a runtime workbench, but when I create a new
branded platform with my plugins - nothign works. All I have done since
then is script the build, and manually bump all the revision numbers up
from 0.0.1 to 0.0.2. UI'm thinking this version change is what
triggered it but I could be wrong....

This is the start of my stack trace:

!SESSION Jul 22, 2004 10:56:49.786
---------------------------------------------

eclipse.buildId=I200406251208
java.version=1.4.2_04
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_CA

!ENTRY org.eclipse.osgi Jul 22, 2004 10:56:49.786
!MESSAGE An error occured while automatically activating bundle
com.mycorp.plugin.ui (5).!STACK 0
org.osgi.framework.BundleException: The activator
com.mycorp.plugin.ui.UIPlugin for bundle com.mycorp.plugin.ui is invalid
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(AbstractBundle.java:158)

All of my plugins are OSGI style and have the following line in the
MANIFEST.MF:

Bundle-Activator: com.mycorp.plugin.ui.UIPlugin

Basically the name of the main plugin class for each plugin I have. The
above line is from my com.mycorp.plugin.ui plugin. This has always
worked. Do I even need this entry, and who put it in there?
Any help would be greatly appreciated.

Mark.

Re: Invalid Bundle Activator all of a sudden!? [message #44833 is a reply to message #44803]

Thu, 22 July 2004 11:28

Eclipse User

Originally posted by: mark.melvin.dspfactory.com

I just manually exported my features and unzipped them into a runtime
platform everything works fine. Something is different between the
automated and manual builds.

Doing a diff of the directories, everything looks fine. The class files
in the .jars are all different - but that is expected. I did however
find that there were some class files NOT in one of the automated
build's .jar file that were present in the manual build. They were:

com.mycorp.ui_0.0.2\ui\com\mycorp\internal\ui\wizards\tools\ ConvertProjectsPage$1.class
com.mycorp.ui_0.0.2\ui\com\mycorp\internal\ui\wizards\tools\ ConvertProjectsPage$2.class
com.mycorp.ui_0.0.2\ui\com\mycorp\internal\ui\wizards\NewPro jectWizard$1.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$1.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$10.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$11.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$2.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$3.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$4.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$5.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$6.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$7.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$8.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$9.class
com.mycorp.ui_0.0.2\ui\com\mycorp\ui\UIPlugin$1.class

What are all these class files with '$' in them?

Mark.

Mark Melvin wrote:

> Hi,
>
> I have just built a new drop of my platform and plugins to find that
> none of my classes can be instantiated. I swear this worked yesterday
> before I went home!
>
> Everything runs fine in a runtime workbench, but when I create a new
> branded platform with my plugins - nothign works. All I have done since
> then is script the build, and manually bump all the revision numbers up
> from 0.0.1 to 0.0.2. UI'm thinking this version change is what
> triggered it but I could be wrong....
>
> This is the start of my stack trace:
>
> !SESSION Jul 22, 2004 10:56:49.786
> ---------------------------------------------
>
> eclipse.buildId=I200406251208
> java.version=1.4.2_04
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_CA
>
> !ENTRY org.eclipse.osgi Jul 22, 2004 10:56:49.786
> !MESSAGE An error occured while automatically activating bundle
> com.mycorp.plugin.ui (5).!STACK 0
> org.osgi.framework.BundleException: The activator
> com.mycorp.plugin.ui.UIPlugin for bundle com.mycorp.plugin.ui is invalid
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(AbstractBundle.java:158)
>
>
>
> All of my plugins are OSGI style and have the following line in the
> MANIFEST.MF:
>
> Bundle-Activator: com.mycorp.plugin.ui.UIPlugin
>
> Basically the name of the main plugin class for each plugin I have. The
> above line is from my com.mycorp.plugin.ui plugin. This has always
> worked. Do I even need this entry, and who put it in there?
> Any help would be greatly appreciated.
>
> Mark.

Re: Invalid Bundle Activator all of a sudden!? [message #44867 is a reply to message #44833]

Thu, 22 July 2004 12:09

Eclipse User

Originally posted by: chaves.nospam.inf.ufsc.br.ok

Those are anonymous inner classes.

Mark Melvin wrote:

> What are all these class files with '$' in them?

Re: Invalid Bundle Activator all of a sudden!? [message #44918 is a reply to message #44867]

Thu, 22 July 2004 13:07

Eclipse User

Originally posted by: mark.melvin.dspfactory.com

Aha. Thanks. Weird that they are missing from the automated build.
<sigh> I was having such a productive week, too....

Mark.

Rafael Chaves wrote:

> Those are anonymous inner classes.
>
> Mark Melvin wrote:
>
>
>>What are all these class files with '$' in them?
>
>
>

Re: Invalid Bundle Activator all of a sudden!? [SOLVED] [message #44939 is a reply to message #44833]

Thu, 22 July 2004 13:36

Eclipse User

Originally posted by: mark.melvin.dspfactory.com

Well, I finally figured this out. There were a couple things combined
that threw me for a loop.

Basically - the Java compile on my automated build was failing, but the
"javacFailOnError" was not set to true - so the build ripped throuhg,
reporting it succeeded, but I only had a partial plugin. Actually, it
was supposed to be set, but my build.properties is based on an OLD
template from 3.0RC1 or M9, and the variable is all lower-case so it
wasn't actually setting the *correct* variable, thus never stopped on
failure.

ANYWAY - I fixed that, then the automated build stopped mid-way because
it couldn't build my plugin. This boiled down to the fact that I was
building 3 different features, each containing various plugins, but I
typed them into the "allElements" target in the wrong order, not
realizing that the dependencies were not automatically figured out at
build time.

So, I have PluginA, PluginB, and PluginC - where PluginC *requires*
PluginB. I had entered them into "allElements" as:

PluginA
PluginC (requires PluginB)
PluginB

Which generated about 400 compile errors in PluginC because most of it's
classes were missing (these classes residing in PluginB). So, simply
rearranging "allElements" to be:

PluginA
PluginB
PluginC (requires PluginB)

...allowed my build to complete successfully and I now have a working
platform. I am a happy camper once again. Whew!

Mark.

Mark Melvin wrote:

> I just manually exported my features and unzipped them into a runtime
> platform everything works fine. Something is different between the
> automated and manual builds.
>
> Doing a diff of the directories, everything looks fine. The class files
> in the .jars are all different - but that is expected. I did however
> find that there were some class files NOT in one of the automated
> build's .jar file that were present in the manual build. They were:
>
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\internal\ui\wizards\tools\ ConvertProjectsPage$1.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\internal\ui\wizards\tools\ ConvertProjectsPage$2.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\internal\ui\wizards\NewPro jectWizard$1.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$1.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$10.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$11.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$2.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$3.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$4.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$5.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$6.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$7.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$8.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$9.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\UIPlugin$1.class
>
>
> What are all these class files with '$' in them?
>
> Mark.
>
> Mark Melvin wrote:
>
>> Hi,
>>
>> I have just built a new drop of my platform and plugins to find that
>> none of my classes can be instantiated. I swear this worked yesterday
>> before I went home!
>>
>> Everything runs fine in a runtime workbench, but when I create a new
>> branded platform with my plugins - nothign works. All I have done
>> since then is script the build, and manually bump all the revision
>> numbers up from 0.0.1 to 0.0.2. UI'm thinking this version change is
>> what triggered it but I could be wrong....
>>
>> This is the start of my stack trace:
>>
>> !SESSION Jul 22, 2004 10:56:49.786
>> ---------------------------------------------
>>
>> eclipse.buildId=I200406251208
>> java.version=1.4.2_04
>> java.vendor=Sun Microsystems Inc.
>> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_CA
>>
>> !ENTRY org.eclipse.osgi Jul 22, 2004 10:56:49.786
>> !MESSAGE An error occured while automatically activating bundle
>> com.mycorp.plugin.ui (5).!STACK 0
>> org.osgi.framework.BundleException: The activator
>> com.mycorp.plugin.ui.UIPlugin for bundle com.mycorp.plugin.ui is
>> invalid at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(AbstractBundle.java:158)
>>
>>
>>
>> All of my plugins are OSGI style and have the following line in the
>> MANIFEST.MF:
>>
>> Bundle-Activator: com.mycorp.plugin.ui.UIPlugin
>>
>> Basically the name of the main plugin class for each plugin I have.
>> The above line is from my com.mycorp.plugin.ui plugin. This has
>> always worked. Do I even need this entry, and who put it in there?
>> Any help would be greatly appreciated.
>>
>> Mark.

Re: Invalid Bundle Activator all of a sudden!? [SOLVED] [message #44966 is a reply to message #44833]

Thu, 22 July 2004 13:38

Eclipse User

Originally posted by: mark.melvin.dspfactory.com

Well, I finally figured this out. There were a couple things combined
that threw me for a loop.

Basically - the Java compile on my automated build was failing, but the
"javacFailOnError" was not set to true - so the build ripped throuhg,
reporting it succeeded, but I only had a partial plugin. Actually, it
was supposed to be set, but my build.properties is based on an OLD
template from 3.0RC1 or M9, and the variable is all lower-case so it
wasn't actually setting the *correct* variable, thus never stopped on
failure.

ANYWAY - I fixed that, then the automated build stopped mid-way because
it couldn't build my plugin. This boiled down to the fact that I was
building 3 different features, each containing various plugins, but I
typed them into the "allElements" target in the wrong order, not
realizing that the dependencies were not automatically figured out at
build time.

So, I have PluginA, PluginB, and PluginC - where PluginC *requires*
PluginB. I had entered them into "allElements" as:

PluginA
PluginC (requires PluginB)
PluginB

Which generated about 400 compile errors in PluginC because most of it's
classes were missing (these classes residing in PluginB). So, simply
rearranging "allElements" to be:

PluginA
PluginB
PluginC (requires PluginB)

...allowed my build to complete successfully and I now have a working
platform. I am a happy camper once again. Whew!

Mark.

Mark Melvin wrote:
> I just manually exported my features and unzipped them into a runtime
> platform everything works fine. Something is different between the
> automated and manual builds.
>
> Doing a diff of the directories, everything looks fine. The class files
> in the .jars are all different - but that is expected. I did however
> find that there were some class files NOT in one of the automated
> build's .jar file that were present in the manual build. They were:
>
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\internal\ui\wizards\tools\ ConvertProjectsPage$1.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\internal\ui\wizards\tools\ ConvertProjectsPage$2.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\internal\ui\wizards\NewPro jectWizard$1.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$1.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$10.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$11.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$2.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$3.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$4.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$5.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$6.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$7.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$8.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\preferences\SourceEdito rPreferencePage$9.class
>
> com.mycorp.ui_0.0.2\ui\com\mycorp\ui\UIPlugin$1.class
>
>
> What are all these class files with '$' in them?
>
> Mark.
>
> Mark Melvin wrote:
>
>> Hi,
>>
>> I have just built a new drop of my platform and plugins to find that
>> none of my classes can be instantiated. I swear this worked yesterday
>> before I went home!
>>
>> Everything runs fine in a runtime workbench, but when I create a new
>> branded platform with my plugins - nothign works. All I have done
>> since then is script the build, and manually bump all the revision
>> numbers up from 0.0.1 to 0.0.2. UI'm thinking this version change is
>> what triggered it but I could be wrong....
>>
>> This is the start of my stack trace:
>>
>> !SESSION Jul 22, 2004 10:56:49.786
>> ---------------------------------------------
>>
>> eclipse.buildId=I200406251208
>> java.version=1.4.2_04
>> java.vendor=Sun Microsystems Inc.
>> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_CA
>>
>> !ENTRY org.eclipse.osgi Jul 22, 2004 10:56:49.786
>> !MESSAGE An error occured while automatically activating bundle
>> com.mycorp.plugin.ui (5).!STACK 0
>> org.osgi.framework.BundleException: The activator
>> com.mycorp.plugin.ui.UIPlugin for bundle com.mycorp.plugin.ui is
>> invalid at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(AbstractBundle.java:158)
>>
>>
>>
>> All of my plugins are OSGI style and have the following line in the
>> MANIFEST.MF:
>>
>> Bundle-Activator: com.mycorp.plugin.ui.UIPlugin
>>
>> Basically the name of the main plugin class for each plugin I have.
>> The above line is from my com.mycorp.plugin.ui plugin. This has
>> always worked. Do I even need this entry, and who put it in there?
>> Any help would be greatly appreciated.
>>
>> Mark.

update.configurator logging errors on restart after installing dynamic plugins [message #45097 is a reply to message #44803]

Wed, 28 July 2004 13:16

Eclipse User

Originally posted by: nalinig.ibm.us

My Eclipse version is 3.0 M9. I have a plugin A that dynamically installs
and starts plugin B from an install URL of the form
reference:file:/c:/eclipse/plugins/B_1.0.0/ using its bundleContext. The
plugin B activates successfully; the problem occurs after Eclipse is shut
down and restarted. There is an error logged by
org.eclipse.update.configurator that says
"Could not install bundle /c:/eclipse/plugins/B_1.0.0/ Bundle "B" version
"1.0.0" has already been installed from:
reference:file:/c:/eclipse/plugins/B_1.0.0/"
and there is no stack trace. The bundle B itself resolves fine, except
for this error message. I don't see this error if a plugin project starts
plugin B in a target workbench.

Why does the update.configurator try to install again from
/c:/eclipse/plugins/B_1.0.0/, who installs the bundle B the first time on
startup? Is there any way of avoiding this message in the error log?

Thanks for any help,
Nalini.

Re: update.configurator logging errors on restart after installing dynamic plugins [message #45129 is a reply to message #45097]

Wed, 28 July 2004 15:01

Eclipse User

Originally posted by: dorian.birsan.net

Try using the Eclipse 3.0 final release, instead of a milestone build.
Some things (like the bundle location and error messages in the
configurator) have changed for the better.

"Nalini Ganapati" <nalinig@ibm.us> wrote in message
news:ce8n24$p7d$1@eclipse.org...
> My Eclipse version is 3.0 M9. I have a plugin A that dynamically installs
> and starts plugin B from an install URL of the form
> reference:file:/c:/eclipse/plugins/B_1.0.0/ using its bundleContext. The
> plugin B activates successfully; the problem occurs after Eclipse is shut
> down and restarted. There is an error logged by
> org.eclipse.update.configurator that says
> "Could not install bundle /c:/eclipse/plugins/B_1.0.0/ Bundle "B" version
> "1.0.0" has already been installed from:
> reference:file:/c:/eclipse/plugins/B_1.0.0/"
> and there is no stack trace. The bundle B itself resolves fine, except
> for this error message. I don't see this error if a plugin project starts
> plugin B in a target workbench.
>
> Why does the update.configurator try to install again from
> /c:/eclipse/plugins/B_1.0.0/, who installs the bundle B the first time on
> startup? Is there any way of avoiding this message in the error log?
>
> Thanks for any help,
> Nalini.
>

Re: update.configurator logging errors on restart after installing dynamic plugins [message #45160 is a reply to message #45129]

Wed, 28 July 2004 16:10

Eclipse User

Originally posted by: nalinig.ibm.us

Actually, I have the final release version of eclipse and can reproduce the
problem there too.
Thanks,
Nalini.

"dorian birsan" <dorian@birsan.net> wrote in message
news:ce8t38$3lc$1@eclipse.org...
> Try using the Eclipse 3.0 final release, instead of a milestone build.
> Some things (like the bundle location and error messages in the
> configurator) have changed for the better.
>
> "Nalini Ganapati" <nalinig@ibm.us> wrote in message
> news:ce8n24$p7d$1@eclipse.org...
> > My Eclipse version is 3.0 M9. I have a plugin A that dynamically
installs
> > and starts plugin B from an install URL of the form
> > reference:file:/c:/eclipse/plugins/B_1.0.0/ using its bundleContext.
The
> > plugin B activates successfully; the problem occurs after Eclipse is
shut
> > down and restarted. There is an error logged by
> > org.eclipse.update.configurator that says
> > "Could not install bundle /c:/eclipse/plugins/B_1.0.0/ Bundle "B"
version
> > "1.0.0" has already been installed from:
> > reference:file:/c:/eclipse/plugins/B_1.0.0/"
> > and there is no stack trace. The bundle B itself resolves fine, except
> > for this error message. I don't see this error if a plugin project
starts
> > plugin B in a target workbench.
> >
> > Why does the update.configurator try to install again from
> > /c:/eclipse/plugins/B_1.0.0/, who installs the bundle B the first time
on
> > startup? Is there any way of avoiding this message in the error log?
> >
> > Thanks for any help,
> > Nalini.
> >
>
>

Re: Invalid Bundle Activator all of a sudden!? [SOLVED] [message #45190 is a reply to message #44939]

Mon, 02 August 2004 10:14

Eclipse User

Originally posted by: g.wagenknecht.planet-wagenknecht.de

Mark Melvin wrote:

> So, I have PluginA, PluginB, and PluginC - where PluginC *requires*
> PluginB. I had entered them into "allElements" as:

Put them into a feature and you don't have to worry about the right compile
order.

Cu, Gunnar

Re: Invalid Bundle Activator all of a sudden!? [SOLVED] [message #45220 is a reply to message #45190]

Tue, 03 August 2004 09:46

Eclipse User

Originally posted by: mark.melvin.dspfactory.com

Gunnar Wagenknecht wrote:
> Mark Melvin wrote:
>
>
>>So, I have PluginA, PluginB, and PluginC - where PluginC *requires*
>>PluginB. I had entered them into "allElements" as:
>
>
> Put them into a feature and you don't have to worry about the right compile
> order.
>

Thanks, Gunnar. Actually, I mis-typed that...they are all features (not
plugins). The proper thing for me to do is not build 3 features in one
build script - rather break it down into a build script pre feature like
the Eclipse build does. I'm working on that...

Mark.

Previous Topic:	SWT/Plugin Book
Next Topic:	Advanced Service Concept

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 13 14:59:04 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter