Home » Eclipse Projects » Eclipse Platform » Early plug-in startup not early enough...
| Early plug-in startup not early enough... [message #304263] |
Mon, 05 June 2006 12:15  |
 Pete Ellis
Messages: 85
Registered: July 2009 |
Member |
|
|
Hello all,
I'm seeing an issue (currently using Eclipse SDK 3.1.1) with respect to
early plug-in startup. I use early startup in one of my components to
register the existence of a set of services with another plug-in that
presents a generalized API of those services to clients. The services are
used, in part, to generate content for an editor that I have constructed
based on EditorPart.
Everything works well enough until the case is reached where the platform
is shut down with editor sessions open. When the platform is launched
again, it appears as though Eclipse attempts to restore and render the
editor sessions *prior* to the completion of plug-in early startup logic.
Thus, the edit session fails to get created, all manner of errors get
generated, etc. because, as stated above, the editor content depends
services that get registered during the early startup phase.
I tried explicitly adding to the editor's plug-in a dependency on the
service plug-in, but this had no effect (seems as though a dependent
plug-in's logic is being utilized prior to initialization and loading of
its dependencies???).
Is there any way to get a finer level of control over when the platform
executes aspects of its startup logic? I'm finding that "early start-up"
isn't early enough....
Many thanks,
-Pete
|
|
|
| Re: Early plug-in startup not early enough... [message #304268 is a reply to message #304263] |
Mon, 05 June 2006 12:45  |
Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
Pete Ellis wrote:
> Hello all,
>
> I'm seeing an issue (currently using Eclipse SDK 3.1.1) with respect to
> early plug-in startup. I use early startup in one of my components to
> register the existence of a set of services with another plug-in that
> presents a generalized API of those services to clients. The services are
> used, in part, to generate content for an editor that I have constructed
> based on EditorPart.
>
Why are you doing this? Shouldn't the other plugin check the registry for
the existence of the set of services, as opposed to the way you are doing
it? It seems backwards wrt/ eclipse architecture. Let the service using
plugin expose an extension point, and the service provider implement the
extension point. Then no problems.
Is there some reason you can not do it this way?
> Everything works well enough until the case is reached where the platform
> is shut down with editor sessions open. When the platform is launched
> again, it appears as though Eclipse attempts to restore and render the
> editor sessions *prior* to the completion of plug-in early startup logic.
> Thus, the edit session fails to get created, all manner of errors get
> generated, etc. because, as stated above, the editor content depends
> services that get registered during the early startup phase.
>
plugins are loaded as needed I believe. Though I think you can force a
plugin to load at workbench start but I believe this is frowned upon for
quick start-up purposes.
--
Respectfully,
CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
|
|
|
| Re: Early plug-in startup not early enough... [message #304286 is a reply to message #304263] |
Mon, 05 June 2006 13:41 |
|
That's because the workbench restores itself, opens one window, and at
that point runs the early startup code in a separate Job (outside the
UI thread). There isn't another eclipse-friendly early startup scenario.
In RCP you can add your plugin to the osgi.bundles property, which would
start your plugin with the framework, not the workbench. But your
plugin would not be able to use anything from the workbench, and it
doesn't work so well in Eclipse itself (since you potentially have to
edit the configuration/config.ini file).
Really, you have 2 choices:
1) implement your editor parts so that when they come up, they can go
into a "waiting" state (present a "data not ready" to the user) until
your services start up, at which point any not-ready editors would get
their real data.
2) the eclipse mechanism for this kind of situation is extension points.
Your generalized API plugin would create the extension point, and your
services plugins would implement the extension point. As your editors
asked for the services, your generalized API plugin would ask the
extension registry, which would ask your services plugin.
That is the correct order of operations that ensures eclipse starts up
plugins as they are needed.
Later,
PW
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
| Re: Early plug-in startup not early enough... [message #304320 is a reply to message #304286] |
Mon, 05 June 2006 15:38 |
Pete Ellis
Messages: 85
Registered: July 2009 |
Member |
|
|
Thanks Paul (and CL Gilbert),
It does seem as though I should really pursue your second choice.
The purpose of my "behind the scenes" registration approach (through early
startup logic) was to achieve what I would suppose could be described as a
"private" extension point, one that only our own plug-ins are internally
aware of and could use.
However, I do see now that this approach circumvents aspects of Eclipse's
built-in plug-in activation control.
Thanks for the help
-Pete
Paul Webster wrote:
> That's because the workbench restores itself, opens one window, and at
> that point runs the early startup code in a separate Job (outside the
> UI thread). There isn't another eclipse-friendly early startup scenario.
> In RCP you can add your plugin to the osgi.bundles property, which would
> start your plugin with the framework, not the workbench. But your
> plugin would not be able to use anything from the workbench, and it
> doesn't work so well in Eclipse itself (since you potentially have to
> edit the configuration/config.ini file).
> Really, you have 2 choices:
> 1) implement your editor parts so that when they come up, they can go
> into a "waiting" state (present a "data not ready" to the user) until
> your services start up, at which point any not-ready editors would get
> their real data.
> 2) the eclipse mechanism for this kind of situation is extension points.
> Your generalized API plugin would create the extension point, and your
> services plugins would implement the extension point. As your editors
> asked for the services, your generalized API plugin would ask the
> extension registry, which would ask your services plugin.
> That is the correct order of operations that ensures eclipse starts up
> plugins as they are needed.
> Later,
> PW
|
|
|
| Re: Early plug-in startup not early enough... [message #304330 is a reply to message #304320] |
Mon, 05 June 2006 18:02 |
| Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
Pete Ellis wrote:
> Thanks Paul (and CL Gilbert),
>
> It does seem as though I should really pursue your second choice.
>
> The purpose of my "behind the scenes" registration approach (through early
> startup logic) was to achieve what I would suppose could be described as a
> "private" extension point, one that only our own plug-ins are internally
> aware of and could use.
>
> However, I do see now that this approach circumvents aspects of Eclipse's
> built-in plug-in activation control.
>
> Thanks for the help
> -Pete
>
>
> Paul Webster wrote:
>
>> That's because the workbench restores itself, opens one window, and at
>> that point runs the early startup code in a separate Job (outside the
>> UI thread). There isn't another eclipse-friendly early startup scenario.
>
>> In RCP you can add your plugin to the osgi.bundles property, which would
>> start your plugin with the framework, not the workbench. But your
>> plugin would not be able to use anything from the workbench, and it
>> doesn't work so well in Eclipse itself (since you potentially have to
>> edit the configuration/config.ini file).
>
>> Really, you have 2 choices:
>
>> 1) implement your editor parts so that when they come up, they can go
>> into a "waiting" state (present a "data not ready" to the user) until
>> your services start up, at which point any not-ready editors would get
>> their real data.
>
>> 2) the eclipse mechanism for this kind of situation is extension points.
>> Your generalized API plugin would create the extension point, and your
>> services plugins would implement the extension point. As your editors
>> asked for the services, your generalized API plugin would ask the
>> extension registry, which would ask your services plugin.
>
>> That is the correct order of operations that ensures eclipse starts up
>> plugins as they are needed.
>
>> Later,
>> PW
You can still restrict class usage to only certain plugins. So even if
everyone sees the extension point it does them no good if they can not
implement the interface the extension point requires because they can not
see the interface.
--
Respectfully,
CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
|
|
|
Goto Forum:
Current Time: Thu Aug 29 23:29:32 GMT 2024
Powered by FUDForum. Page generated in 0.03790 seconds |
] 
Search
Help
Register
Login
Home
