| Plugin Class in M9 [message #243942] |
Sun, 23 May 2004 08:15  |
Eclipse User |
|
|
|
Hello,
Since I update from M8 to M9 my own Plugin doesn't really work fine and
many methods were marked as deprecated. So I decided to solve these
deprecates and switch to OSGi Plugin.
I created a MANIFEST.MF file with the Plug-in Manifest Editor. Then I
removed the XyzPlugin(IPluginDescriptor descriptor) constructor from my
Plugin class so that only the default constructor is left over.
Now the problem is that by calling the getDefault() method the singleton
instance field within the plugin class isn’t initialized, due to the
fact that the default constructor wasn’t called.
My question is when should the singleton instance be initialized? By
calling the getDefault() method or will it triggered by a callback
method of the osgi framework?
Thx
Ingo
|
|
|
|
| Re: Plugin Class in M9 [message #243951 is a reply to message #243947] |
Sun, 23 May 2004 08:47  |
| Eclipse User |
|
|
|
Hi Mariano,
I guess I know how it should work.
If your plugin class have the now deprecated constructor with the
IPluginDescriptor parameter then this constructor will be called before
accessing your plugin. But your constructor is still deprecated.
My problem with the manifest.mf file was that the Bundle-Activator
doesn't point to my plugin class. After correcting this it works fine.
But I am still not sure, how the lifecyle of the plugin should look like.
So any further hints would be wonderfull.
Thx
Ingo
Mariano Kamp wrote:
> Hallo Ingo,
>
> I also "healed" my former usage of the now deprecated methods, but
> this didn't involve building a manifest file.
>
> Regarding the getDefault() call. I do just assign this to a static
> variable in the constructor of my plugin and return this reference when
> getDefault() is called. Eclipse takes care of just instantiating the
> plug-in once.
>
> Having said that, it didn't work on the first try and my plug-in has
> been instantiated over and over again, but after using a fresh
> runtime-workspace the problem didn't occur again.
>
> Cheers,
> Mariano
>
> Ingo Düppe wrote:
>
>> Hello,
>>
>> Since I update from M8 to M9 my own Plugin doesn't really work fine
>> and many methods were marked as deprecated. So I decided to solve
>> these deprecates and switch to OSGi Plugin.
>>
>> I created a MANIFEST.MF file with the Plug-in Manifest Editor. Then I
>> removed the XyzPlugin(IPluginDescriptor descriptor) constructor from
>> my Plugin class so that only the default constructor is left over.
>>
>> Now the problem is that by calling the getDefault() method the
>> singleton instance field within the plugin class isn’t initialized,
>> due to the fact that the default constructor wasn’t called.
>>
>> My question is when should the singleton instance be initialized? By
>> calling the getDefault() method or will it triggered by a callback
>> method of the osgi framework?
>>
>> Thx
>> Ingo
>>
>>
|
|
|
| Re: Plugin Class in M9 [message #243966 is a reply to message #243951] |
Sun, 23 May 2004 12:41 |
| Eclipse User |
|
|
|
You try set start and stop method like :
public void start(BundleContext context) throws Exception {
super.start(context);
}
public void stop(BundleContext context) throws Exception {
super.stop(context);
}
regards
Haris Peco
Ingo Düppe wrote:
> Hi Mariano,
>
> I guess I know how it should work.
>
> If your plugin class have the now deprecated constructor with the
> IPluginDescriptor parameter then this constructor will be called before
> accessing your plugin. But your constructor is still deprecated.
>
> My problem with the manifest.mf file was that the Bundle-Activator
> doesn't point to my plugin class. After correcting this it works fine.
>
> But I am still not sure, how the lifecyle of the plugin should look like.
>
> So any further hints would be wonderfull.
>
> Thx
>
> Ingo
>
>
>
> Mariano Kamp wrote:
>> Hallo Ingo,
>>
>> I also "healed" my former usage of the now deprecated methods, but
>> this didn't involve building a manifest file.
>>
>> Regarding the getDefault() call. I do just assign this to a static
>> variable in the constructor of my plugin and return this reference when
>> getDefault() is called. Eclipse takes care of just instantiating the
>> plug-in once.
>>
>> Having said that, it didn't work on the first try and my plug-in has
>> been instantiated over and over again, but after using a fresh
>> runtime-workspace the problem didn't occur again.
>>
>> Cheers,
>> Mariano
>>
>> Ingo Düppe wrote:
>>
>>> Hello,
>>>
>>> Since I update from M8 to M9 my own Plugin doesn't really work fine
>>> and many methods were marked as deprecated. So I decided to solve
>>> these deprecates and switch to OSGi Plugin.
>>>
>>> I created a MANIFEST.MF file with the Plug-in Manifest Editor. Then I
>>> removed the XyzPlugin(IPluginDescriptor descriptor) constructor from
>>> my Plugin class so that only the default constructor is left over.
>>>
>>> Now the problem is that by calling the getDefault() method the
>>> singleton instance field within the plugin class isn’t initialized,
>>> due to the fact that the default constructor wasn’t called.
>>>
>>> My question is when should the singleton instance be initialized? By
>>> calling the getDefault() method or will it triggered by a callback
>>> method of the osgi framework?
>>>
>>> Thx
>>> Ingo
>>>
>>>
|
|
|
|
|
| Re: Plugin Class in M9 [message #244007 is a reply to message #243951] |
Sun, 23 May 2004 13:06 |
| Eclipse User |
|
|
|
Hallo Ingo,
> If your plugin class have the now deprecated constructor with the
> IPluginDescriptor parameter then this constructor will be called before
> accessing your plugin. But your constructor is still deprecated.
Nope, I removed the constructor completely and have a default (no-arg)
constructor now.
I didn't read the adoption guide yet (my bad), but I guess, as the
BundleContext is now passed into the stop() method there is no further
need for the plugin Descriptor. I relied on the javadocs and the result
seems to work for me (tm).
My new constructor just looks like this:
public PepeMaxPlugin() {
super();
plugin = this;
}
I also had to change the startup()/shutdown() method and use
start()/stop() instead, but for the caller this is just mechanics, no
change in semantics.
FWIW you can see the working code here:
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/pepemax/pepe max/org.jabberstudio.pepemax.core/src/org/jabberstudio/pepem ax/internal/core/PepeMaxPlugin.java?view=markup
or
http://tinyurl.com/37fy9
Btw. I am also accessing the symbolicName like this:
getBundle().getSymbolicName()
> But I am still not sure, how the lifecyle of the plugin should look like.
What lifecycle do you mean?
There is one instance, the constructor is called, start() is called and
eventually stop(). Above mentioned code is also a Singleton. Regarding
your issue, see my getModelInternally() or getDefault() method.
I am not sure, if I understood you correctly. If my post doesn't answer
your question, please rephrase your question.
Btw. I didn't create any manifest file. If PDE didn't create one without
telling me, it works without having one.
Cheers,
Mariano
>
> Thx
>
> Ingo
>
>
>
> Mariano Kamp wrote:
>
>> Hallo Ingo,
>>
>> I also "healed" my former usage of the now deprecated methods, but
>> this didn't involve building a manifest file.
>>
>> Regarding the getDefault() call. I do just assign this to a static
>> variable in the constructor of my plugin and return this reference
>> when getDefault() is called. Eclipse takes care of just instantiating
>> the plug-in once.
>>
>> Having said that, it didn't work on the first try and my plug-in has
>> been instantiated over and over again, but after using a fresh
>> runtime-workspace the problem didn't occur again.
>>
>> Cheers,
>> Mariano
>>
>> Ingo Düppe wrote:
>>
>>> Hello,
>>>
>>> Since I update from M8 to M9 my own Plugin doesn't really work fine
>>> and many methods were marked as deprecated. So I decided to solve
>>> these deprecates and switch to OSGi Plugin.
>>>
>>> I created a MANIFEST.MF file with the Plug-in Manifest Editor. Then I
>>> removed the XyzPlugin(IPluginDescriptor descriptor) constructor from
>>> my Plugin class so that only the default constructor is left over.
>>>
>>> Now the problem is that by calling the getDefault() method the
>>> singleton instance field within the plugin class isn’t initialized,
>>> due to the fact that the default constructor wasn’t called.
>>>
>>> My question is when should the singleton instance be initialized? By
>>> calling the getDefault() method or will it triggered by a callback
>>> method of the osgi framework?
>>>
>>> Thx
>>> Ingo
>>>
>>>
|
|
|
|
|
|
| Re: Plugin Class in M9 [message #244066 is a reply to message #244012] |
Sun, 23 May 2004 16:57 |
| Eclipse User |
|
|
|
Fine that was the missing thing. Thx alot. Now the constructor is called.
Regards
Ingo
Michael Keppler wrote:
> Ingo Düppe schrieb:
>
>> Now the problem is that by calling the getDefault() method the
>> singleton instance field within the plugin class isn’t initialized,
>> due to the fact that the default constructor wasn’t called.
>
>
> Did you remove the org.eclipse.runtime.compatibility plugin from the
> list of dependencies and added org.eclipse.runtime instead?
>
> I had the same problem (not called constructor) because I forgot to
> change thiose dependencies after removing the IPluginDescriptor from the
> constructor.
>
> Ciao, Michael.
|
|
|
Powered by
FUDForum. Page generated in 0.24774 seconds
Home