Home » Eclipse Projects » Equinox » Plugins - singletons or not?
| |
| Re: Plugins - singletons or not? [message #15625 is a reply to message #15593] |
Thu, 27 March 2003 15:40   |
 Pascal Rapicault
Messages: 333
Registered: July 2009
Location: Ottawa |
Senior Member |
|
|
Jonathan,
What you propose is not possible since it's the runtime plugin that creates
the instance of the plugin.
Regards,
PaScaL
"Jonathan Gossage" <jgossage@magma.ca> wrote in message
news:b5usbg$iim$1@rogue.oti.com...
>
> "Mel Martinez" <melm@us.ibm.com> wrote in message
> news:b5tii7$ofl$1@rogue.oti.com...
> > Plugins are curious beasts.
> >
> > The recommended pattern for plugin creation is something like:
> >
> > public class MyPlugin extends Plugin {
> > private static MyPlugin theplugin;
> >
> > public MyPlugin(IPluginDescriptor descr){
> > super(descr);
> > ...
> > theplugin = this;
> > }
> >
> > public static MyPlugin getInstance(){
> > return theplugin;
> > }
> > }
> >
> > Ugh.. doesn't that just seem so vulnerable? I look through various
> > examples, including the eclipse codebase and the above is what I see
> > folks doing, of course (some code uses a static 'getDefault()' instead
> > of 'getInstance()'). It all seems to depend on the fragile hope that no
> > one does the (perfectly legal by API standards) following thing:
> >
> > MyPlugin myref = new MyPlugin(whatever);
> >
> > because that would destroy the validity of the reference returned by
> > getInstance() (or getDefault()).
> >
> > I'd like it if the javadocs for Plugin and AbstractUIPlugin at least
> > changed to recommend the constructor did a null check like so:
> >
> > public class MyPlugin extends Plugin {
> > private static MyPlugin theplugin;
> >
> > public MyPlugin(IPluginDescriptor descr){
> > super(descr);
> > ...
> > if(theplugin==null) then {
> > theplugin = this;
> > }
> > }
> >
> > public static MyPlugin getInstance(){
> > return theplugin;
> > }
> > }
> >
> > Also, this should systematically be retrofit into the existing eclipse
> > codebase.
> >
> > While this still wouldn't prevent others from instantiating your plugin,
> > it would enforce that getInstance() would continue to always return the
> > instance that the Platform originally created.
> >
> > This is, imho, a significant vulnerability in the current plugin model
> > that can lead to unpredictable behavior and instability and even
> > potential security holes.
> >
> > I'd love it if someone had thoughts on some ways to add stronger
> > enforcement of the singleton pattern in the API itself.
> >
> > I suppose one solution is to use the Java Security Manager API to
> > disallow invocation of the constructor of each plugin other than by the
> > platform. I'm not sure exactly of all the ramifications of that might
> > be, though. Thoughts?
> >
> > Cheers,
> >
> > Mel
> >
>
> Have you considered making the constructor private and invoking it from
the
> getInstance() method. That way you retain total control over the
> construction process since getInstance() can ensure that only one instance
> is created.
>
> Regards
>
> Jonathan Gossage
>
>
|
|
|
| Re: Plugins - singletons or not? [message #15745 is a reply to message #15625] |
Thu, 27 March 2003 19:40 |
Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
My understanding is that the runtime plugin that first requests another
plugin (via class variable assignment, typecast, etc), forces the JVM to
call upon the requesting plugin's classloader to find the class bytecode.
The classloader, through delegation eventually finds the classloader of the
plugin being requested, which would then create the class, store it in its
cache, and return the Class. So in actuality, the plugin is not really
creating the plugin it requests, it is assuming its already in its
classpath, and the classloader(s) are doing the work in finding and
instantiating the class. I don't think a plugin directly creates another
plugin does it? I do know of the extensionExecutable method (sorry, forget
the exact name), but the engine is still asking the plugins classloader to
create it then return it as far as I can tell. If I am wrong, please
enlighten me as to how this actually works.
Thanks.
"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
news:b5v5sc$qu1$1@rogue.oti.com...
> Jonathan,
>
> What you propose is not possible since it's the runtime plugin that
creates
> the instance of the plugin.
>
> Regards,
>
> PaScaL
>
> "Jonathan Gossage" <jgossage@magma.ca> wrote in message
> news:b5usbg$iim$1@rogue.oti.com...
> >
> > "Mel Martinez" <melm@us.ibm.com> wrote in message
> > news:b5tii7$ofl$1@rogue.oti.com...
> > > Plugins are curious beasts.
> > >
> > > The recommended pattern for plugin creation is something like:
> > >
> > > public class MyPlugin extends Plugin {
> > > private static MyPlugin theplugin;
> > >
> > > public MyPlugin(IPluginDescriptor descr){
> > > super(descr);
> > > ...
> > > theplugin = this;
> > > }
> > >
> > > public static MyPlugin getInstance(){
> > > return theplugin;
> > > }
> > > }
> > >
> > > Ugh.. doesn't that just seem so vulnerable? I look through various
> > > examples, including the eclipse codebase and the above is what I see
> > > folks doing, of course (some code uses a static 'getDefault()' instead
> > > of 'getInstance()'). It all seems to depend on the fragile hope that
no
> > > one does the (perfectly legal by API standards) following thing:
> > >
> > > MyPlugin myref = new MyPlugin(whatever);
> > >
> > > because that would destroy the validity of the reference returned by
> > > getInstance() (or getDefault()).
> > >
> > > I'd like it if the javadocs for Plugin and AbstractUIPlugin at least
> > > changed to recommend the constructor did a null check like so:
> > >
> > > public class MyPlugin extends Plugin {
> > > private static MyPlugin theplugin;
> > >
> > > public MyPlugin(IPluginDescriptor descr){
> > > super(descr);
> > > ...
> > > if(theplugin==null) then {
> > > theplugin = this;
> > > }
> > > }
> > >
> > > public static MyPlugin getInstance(){
> > > return theplugin;
> > > }
> > > }
> > >
> > > Also, this should systematically be retrofit into the existing eclipse
> > > codebase.
> > >
> > > While this still wouldn't prevent others from instantiating your
plugin,
> > > it would enforce that getInstance() would continue to always return
the
> > > instance that the Platform originally created.
> > >
> > > This is, imho, a significant vulnerability in the current plugin model
> > > that can lead to unpredictable behavior and instability and even
> > > potential security holes.
> > >
> > > I'd love it if someone had thoughts on some ways to add stronger
> > > enforcement of the singleton pattern in the API itself.
> > >
> > > I suppose one solution is to use the Java Security Manager API to
> > > disallow invocation of the constructor of each plugin other than by
the
> > > platform. I'm not sure exactly of all the ramifications of that might
> > > be, though. Thoughts?
> > >
> > > Cheers,
> > >
> > > Mel
> > >
> >
> > Have you considered making the constructor private and invoking it from
> the
> > getInstance() method. That way you retain total control over the
> > construction process since getInstance() can ensure that only one
instance
> > is created.
> >
> > Regards
> >
> > Jonathan Gossage
> >
> >
>
>
|
|
|
| Re: Plugins - singletons or not? [message #16422 is a reply to message #15745] |
Thu, 27 March 2003 19:58 |
Pascal Rapicault
Messages: 333
Registered: July 2009
Location: Ottawa |
Senior Member |
|
|
Kevin,
You should look at this webpage
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynamic
Plugins/currentPluginModel.html
It says "When something happens causing the code within a plug-in to be
loaded, that particular plug-in is activated"
You can also take a look at:
PluginClassLoader:internalFindClassParentSelf(..., ..., ..., ... )
which calls activatePlugin(...)
Hope this help,
PaScaL
"Kevin" <kduffey@marketron.com> wrote in message
news:b5vjut$8rt$1@rogue.oti.com...
> My understanding is that the runtime plugin that first requests another
> plugin (via class variable assignment, typecast, etc), forces the JVM to
> call upon the requesting plugin's classloader to find the class bytecode.
> The classloader, through delegation eventually finds the classloader of
the
> plugin being requested, which would then create the class, store it in its
> cache, and return the Class. So in actuality, the plugin is not really
> creating the plugin it requests, it is assuming its already in its
> classpath, and the classloader(s) are doing the work in finding and
> instantiating the class. I don't think a plugin directly creates another
> plugin does it? I do know of the extensionExecutable method (sorry, forget
> the exact name), but the engine is still asking the plugins classloader to
> create it then return it as far as I can tell. If I am wrong, please
> enlighten me as to how this actually works.
>
> Thanks.
>
> "Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
> news:b5v5sc$qu1$1@rogue.oti.com...
> > Jonathan,
> >
> > What you propose is not possible since it's the runtime plugin that
> creates
> > the instance of the plugin.
> >
> > Regards,
> >
> > PaScaL
> >
> > "Jonathan Gossage" <jgossage@magma.ca> wrote in message
> > news:b5usbg$iim$1@rogue.oti.com...
> > >
> > > "Mel Martinez" <melm@us.ibm.com> wrote in message
> > > news:b5tii7$ofl$1@rogue.oti.com...
> > > > Plugins are curious beasts.
> > > >
> > > > The recommended pattern for plugin creation is something like:
> > > >
> > > > public class MyPlugin extends Plugin {
> > > > private static MyPlugin theplugin;
> > > >
> > > > public MyPlugin(IPluginDescriptor descr){
> > > > super(descr);
> > > > ...
> > > > theplugin = this;
> > > > }
> > > >
> > > > public static MyPlugin getInstance(){
> > > > return theplugin;
> > > > }
> > > > }
> > > >
> > > > Ugh.. doesn't that just seem so vulnerable? I look through various
> > > > examples, including the eclipse codebase and the above is what I see
> > > > folks doing, of course (some code uses a static 'getDefault()'
instead
>
> > > > of 'getInstance()'). It all seems to depend on the fragile hope
that
> no
> > > > one does the (perfectly legal by API standards) following thing:
> > > >
> > > > MyPlugin myref = new MyPlugin(whatever);
> > > >
> > > > because that would destroy the validity of the reference returned by
> > > > getInstance() (or getDefault()).
> > > >
> > > > I'd like it if the javadocs for Plugin and AbstractUIPlugin at least
> > > > changed to recommend the constructor did a null check like so:
> > > >
> > > > public class MyPlugin extends Plugin {
> > > > private static MyPlugin theplugin;
> > > >
> > > > public MyPlugin(IPluginDescriptor descr){
> > > > super(descr);
> > > > ...
> > > > if(theplugin==null) then {
> > > > theplugin = this;
> > > > }
> > > > }
> > > >
> > > > public static MyPlugin getInstance(){
> > > > return theplugin;
> > > > }
> > > > }
> > > >
> > > > Also, this should systematically be retrofit into the existing
eclipse
> > > > codebase.
> > > >
> > > > While this still wouldn't prevent others from instantiating your
> plugin,
> > > > it would enforce that getInstance() would continue to always return
> the
> > > > instance that the Platform originally created.
> > > >
> > > > This is, imho, a significant vulnerability in the current plugin
model
> > > > that can lead to unpredictable behavior and instability and even
> > > > potential security holes.
> > > >
> > > > I'd love it if someone had thoughts on some ways to add stronger
> > > > enforcement of the singleton pattern in the API itself.
> > > >
> > > > I suppose one solution is to use the Java Security Manager API to
> > > > disallow invocation of the constructor of each plugin other than by
> the
> > > > platform. I'm not sure exactly of all the ramifications of that
might
> > > > be, though. Thoughts?
> > > >
> > > > Cheers,
> > > >
> > > > Mel
> > > >
> > >
> > > Have you considered making the constructor private and invoking it
from
> > the
> > > getInstance() method. That way you retain total control over the
> > > construction process since getInstance() can ensure that only one
> instance
> > > is created.
> > >
> > > Regards
> > >
> > > Jonathan Gossage
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Plugins - singletons or not? [message #16478 is a reply to message #15593] |
Thu, 27 March 2003 21:52 |
Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
Jonathan Gossage wrote:
>
>
> Have you considered making the constructor private and invoking it from the
> getInstance() method. That way you retain total control over the
> construction process since getInstance() can ensure that only one instance
> is created.
>
> Regards
>
> Jonathan Gossage
>
>
Unfortunately, that is not possible with the way the IPlugin API is
designed. For one thing, the abstract implementations, Plugin and
AbstractUIPlugin, have declared public constructor. Descendants are not
allowed to make an inherited member less public. The constructor is
public for the purpose of allowing the platform to invoke it. Also, the
platform uses the constructor to pass initialization arguments (the
PluginDescriptor) to the plugin instance that it creates.
The basic problem is that we have two different parties responsible for
the lifecycle of the plugin. The platform is responsible for creation,
while providing access to the plugin is left up to the plugin itself
with no clearly defined protocol. The abstract Plugin class' javadoc
suggests a static 'getInstance()' accessor, while implementations of
AbstractUIPlugin seem to use 'getDefault()'.
It would be preferable if one class was responsible for both creation
and access. For example, a simple factory like so would do the trick:
public class PluginFactory {
private static Map pluginMap = new Hashtable();
public static IPlugin getInstance(
Class pluginClass,
IPluginDescriptor descr){
IPlugin plugin = (IPlugin)pluginMap.get(pluginClass);
if(plugin==null){
try{
Class[] ptype = {IPluginDescriptor.class};
Constructor const = pluginClass.getConstructor(ptype);
Object[] params = {descr};
plugin = (IPlugin)const.newInstance(params);
}catch(Exception e){
//handle exception
}
pluginMap.put(pluginClass,plugin);
}
return plugin;
}
}
The platform code concerned with initial creation of the plugin
(PluginDescriptor.internalDoPluginActivation() last I looked) would do
like so:
IPlugin theplugin = PluginFactory.getInstance(pluginClass,descr);
Given that, all other parties interested in getting a reference
org.example.MyPlugin would simply use:
MyPlugin myplugin;
myplugin = (MyPlugin)PluginFactory.getInstance(MyPlugin.class,null);
And of course, for convenience, one would expect that each plugin would
be recommended to define a static accessor like so:
public class MyPlugin extends Plugin{
...
public static MyPlugin getInstance(){
return (MyPlugin)PluginFactory.getInstance(this.getClass(),null);
}
...
}
This seems like something that could be shoe-horned into the existing
codebase without breaking anything. It would then give us a starting
point to migrating folks to a more stable model for accessing plugins
without breaking the existing one. We would have a cohesive class
responsible for creation and access to all plugins and one could finally
start to rely on singleton-like behavior.
Some points to consider: In the 'dynamic' world, one would need to
flush the plugin class from the hashtable when it was unloaded.
Alternatively, one could use a WeakHashMap so it would go away when
there are no other references, but I'm not sure how well that would
work. I would prefer an explicit removal. Thus the PluginFactory here
needs to be a listener for plugin unload events.
Thoughts?
Mel
|
|
|
| Re: Plugins - singletons or not? [message #16589 is a reply to message #15560] |
Fri, 28 March 2003 16:14 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
I agree that the singleton pattern is implemented weakly but disagree that
it is not specified strongly. The following is from
Plugin.Plugin(IPluginDescriptor).
* Instances of plug-in runtime classes are automatically created
* by the platform in the course of plug-in activation.
* <b>Clients must never explicitly instantiate a plug-in runtime class.</b>
As for the getInstance(), getDefault(), these are convenience methods that
various plugins have chosen to implement. The Eclipse runtime cannot prevent
or control this. In most cases I doubt that they are API (often the plugin
classes themselves are not API). The Eclipse API way of getting a
particular plugin instance is
Platform.getPlugin("<plugin id">);
We could have implemented an explicit singleton mechanism in the Plugin
hierarchy but in the end, we need to keep the plugin instances in the
registry anyway, and have API for accessing these instances so why
duplicate?
Anyway, I missed the problem that is being addressed here.
Jeff
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b5tii7$ofl$1@rogue.oti.com...
> Plugins are curious beasts.
>
> The recommended pattern for plugin creation is something like:
>
> public class MyPlugin extends Plugin {
> private static MyPlugin theplugin;
>
> public MyPlugin(IPluginDescriptor descr){
> super(descr);
> ...
> theplugin = this;
> }
>
> public static MyPlugin getInstance(){
> return theplugin;
> }
> }
>
> Ugh.. doesn't that just seem so vulnerable? I look through various
> examples, including the eclipse codebase and the above is what I see
> folks doing, of course (some code uses a static 'getDefault()' instead
> of 'getInstance()'). It all seems to depend on the fragile hope that no
> one does the (perfectly legal by API standards) following thing:
>
> MyPlugin myref = new MyPlugin(whatever);
>
> because that would destroy the validity of the reference returned by
> getInstance() (or getDefault()).
>
> I'd like it if the javadocs for Plugin and AbstractUIPlugin at least
> changed to recommend the constructor did a null check like so:
>
> public class MyPlugin extends Plugin {
> private static MyPlugin theplugin;
>
> public MyPlugin(IPluginDescriptor descr){
> super(descr);
> ...
> if(theplugin==null) then {
> theplugin = this;
> }
> }
>
> public static MyPlugin getInstance(){
> return theplugin;
> }
> }
>
> Also, this should systematically be retrofit into the existing eclipse
> codebase.
>
> While this still wouldn't prevent others from instantiating your plugin,
> it would enforce that getInstance() would continue to always return the
> instance that the Platform originally created.
>
> This is, imho, a significant vulnerability in the current plugin model
> that can lead to unpredictable behavior and instability and even
> potential security holes.
>
> I'd love it if someone had thoughts on some ways to add stronger
> enforcement of the singleton pattern in the API itself.
>
> I suppose one solution is to use the Java Security Manager API to
> disallow invocation of the constructor of each plugin other than by the
> platform. I'm not sure exactly of all the ramifications of that might
> be, though. Thoughts?
>
> Cheers,
>
> Mel
>
|
|
|
| Re: Plugins - singletons or not? [message #16638 is a reply to message #16589] |
Fri, 28 March 2003 18:06 |
Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
Jeff McAffer wrote:
> I agree that the singleton pattern is implemented weakly but disagree that
> it is not specified strongly. The following is from
> Plugin.Plugin(IPluginDescriptor).
>
> * Instances of plug-in runtime classes are automatically created
> * by the platform in the course of plug-in activation.
> * <b>Clients must never explicitly instantiate a plug-in runtime class.</b>
>
This assumes that all developers will read and heed this specification.
> As for the getInstance(), getDefault(), these are convenience methods that
> various plugins have chosen to implement. The Eclipse runtime cannot prevent
> or control this. In most cases I doubt that they are API (often the plugin
> classes themselves are not API). The Eclipse API way of getting a
> particular plugin instance is
> Platform.getPlugin("<plugin id">);
>
See, I personally missed that one. It just goes to show how developers
like me miss stuff in the docs, no matter how plainly written! :-) Even
so, that is distinctly not mentioned as the recommended form of access
as documented in the documentation in AbstractUIPlugin on how to create
and access plugins.
From AbstractUIPlugin:
* For easy access to your plug-in object, use the singleton pattern.
* Declare a
* static variable in your plug-in class for the singleton. Store the
* first
* (and only) instance of the plug-in class in the singleton when it is
* created.
* Then access the singleton when needed through a static
* <code>getDefault</code>
* method.
I suspect developers descending from AbstractUIPlugin often don't
realize they need to also look closely at the Plugin docs.
And even though the Platform.getPlugin("<plugin id>") access is
mentioned in the Plugin docs, the example in that same doc still
recommends using a static field set without null check by the
constructor to access the plugin. That would be fine, so long as you
ensure that the field is only set once.
Also, to nit-pick, the Platform.getPlugin() method is not strong API for
access to a singleton instance of a particular plugin class. Rather it
is a weak reference to an instance of whatever class is associated with
that string id in the registry by way of the descriptor. This may be a
descendant of Plugin, it may be an instance of Plugin itself as place
holder.
> We could have implemented an explicit singleton mechanism in the Plugin
> hierarchy but in the end, we need to keep the plugin instances in the
> registry anyway, and have API for accessing these instances so why
> duplicate?
>
> Anyway, I missed the problem that is being addressed here.
>
The problem is that the Platform has one reference to an instance of
MyPlugin (which can be retrieved using Platform.getPlugin()) while other
code use a different reference maintained as a static field in the the
MyPlugin class. Again, that would be fine if the field was set only
once (such as declared final or with a null-check. But if some code
(accidentally through incompetence or intentially through malice) does
instantiate another MyPlugin instance then the Platform.getPlugin()
would point to one instance and the MyPlugin.getInstance()/getDefault()
methods would point to another instance.
In sum - it is possible for some code to be using a different instance
of the plugin other than the Platform's instance, without being aware
that such a switch has occurred. This seems like a potential security hole.
The still weak but simple way of addressing this is to improve the docs
to better reflect best practices to prevent this problem (such as simply
using a null check in the constructor before setting the static instance
field). Or they should simply recommend using the plugin id to get it
from the Platform.
To me, it seems that the problem stems from spreading responsibility for
the lifecycle and access of a plugin around. The plugin docs are
recommending each plugin pretend it is a Singleton and provide static
accessor. The PluginDescriptor is for some reason delegated the
responsibility of activation and actual instantiation of the Plugin -
that may make more sense to me later. And then we are given the
Platform.getPlugin() method as recommended external access to the plugin.
I would like to see things refactored so that plugin creation and access
to instances is managed by one party. I think this could be done
without breaking any existing code.
The comment about how the Plugin implementations are not always API (and
not even required) for a plugin is true. However if they ARE exposed as
API, then other code has access to the class. They should have a
reliable way of accessing the installed instance of that class.
I hope this doesn't come off as overly critical. I'm simply trying to
understand the eclipse platform and some of the design choices and make
recommendations when I can.
Cheers,
Mel
|
|
|
| Re: Plugins - singletons or not? [message #17539 is a reply to message #16638] |
Mon, 31 March 2003 08:48 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
I am a bit confused. If we have dynamic plugins, we have the problem
that they can go away. The patterns described to handle plugin creation
are therefore not applicable anymore, isnt it?
If plugins come and go, we need a service registry approach where the
plugins are registered and unregistered. Access to static fields and
getInstance()/getDefault() methods seem to be not sufficient?
Kind regards,
Peter Kriens
Mel Martinez wrote:
> Jeff McAffer wrote:
>
>> I agree that the singleton pattern is implemented weakly but disagree
>> that
>> it is not specified strongly. The following is from
>> Plugin.Plugin(IPluginDescriptor).
>>
>> * Instances of plug-in runtime classes are automatically created
>> * by the platform in the course of plug-in activation.
>> * <b>Clients must never explicitly instantiate a plug-in runtime
>> class.</b>
>>
>
> This assumes that all developers will read and heed this specification.
>
>> As for the getInstance(), getDefault(), these are convenience methods
>> that
>> various plugins have chosen to implement. The Eclipse runtime cannot
>> prevent
>> or control this. In most cases I doubt that they are API (often the
>> plugin
>> classes themselves are not API). The Eclipse API way of getting a
>> particular plugin instance is
>> Platform.getPlugin("<plugin id">);
>>
>
> See, I personally missed that one. It just goes to show how developers
> like me miss stuff in the docs, no matter how plainly written! :-) Even
> so, that is distinctly not mentioned as the recommended form of access
> as documented in the documentation in AbstractUIPlugin on how to create
> and access plugins.
>
> From AbstractUIPlugin:
> * For easy access to your plug-in object, use the singleton pattern.
> * Declare a
> * static variable in your plug-in class for the singleton. Store the
> * first
> * (and only) instance of the plug-in class in the singleton when it is
> * created.
> * Then access the singleton when needed through a static
> * <code>getDefault</code>
> * method.
>
> I suspect developers descending from AbstractUIPlugin often don't
> realize they need to also look closely at the Plugin docs.
>
> And even though the Platform.getPlugin("<plugin id>") access is
> mentioned in the Plugin docs, the example in that same doc still
> recommends using a static field set without null check by the
> constructor to access the plugin. That would be fine, so long as you
> ensure that the field is only set once.
>
> Also, to nit-pick, the Platform.getPlugin() method is not strong API for
> access to a singleton instance of a particular plugin class. Rather it
> is a weak reference to an instance of whatever class is associated with
> that string id in the registry by way of the descriptor. This may be a
> descendant of Plugin, it may be an instance of Plugin itself as place
> holder.
>
>> We could have implemented an explicit singleton mechanism in the Plugin
>> hierarchy but in the end, we need to keep the plugin instances in the
>> registry anyway, and have API for accessing these instances so why
>> duplicate?
>>
>> Anyway, I missed the problem that is being addressed here.
>>
>
> The problem is that the Platform has one reference to an instance of
> MyPlugin (which can be retrieved using Platform.getPlugin()) while other
> code use a different reference maintained as a static field in the the
> MyPlugin class. Again, that would be fine if the field was set only
> once (such as declared final or with a null-check. But if some code
> (accidentally through incompetence or intentially through malice) does
> instantiate another MyPlugin instance then the Platform.getPlugin()
> would point to one instance and the MyPlugin.getInstance()/getDefault()
> methods would point to another instance.
>
> In sum - it is possible for some code to be using a different instance
> of the plugin other than the Platform's instance, without being aware
> that such a switch has occurred. This seems like a potential security
> hole.
>
> The still weak but simple way of addressing this is to improve the docs
> to better reflect best practices to prevent this problem (such as simply
> using a null check in the constructor before setting the static instance
> field). Or they should simply recommend using the plugin id to get it
> from the Platform.
>
> To me, it seems that the problem stems from spreading responsibility for
> the lifecycle and access of a plugin around. The plugin docs are
> recommending each plugin pretend it is a Singleton and provide static
> accessor. The PluginDescriptor is for some reason delegated the
> responsibility of activation and actual instantiation of the Plugin -
> that may make more sense to me later. And then we are given the
> Platform.getPlugin() method as recommended external access to the plugin.
>
> I would like to see things refactored so that plugin creation and access
> to instances is managed by one party. I think this could be done
> without breaking any existing code.
>
> The comment about how the Plugin implementations are not always API (and
> not even required) for a plugin is true. However if they ARE exposed as
> API, then other code has access to the class. They should have a
> reliable way of accessing the installed instance of that class.
>
> I hope this doesn't come off as overly critical. I'm simply trying to
> understand the eclipse platform and some of the design choices and make
> recommendations when I can.
>
> Cheers,
>
> Mel
>
>
>
>
>
|
|
|
| Re: Plugins - singletons or not? [message #17605 is a reply to message #17539] |
Mon, 31 March 2003 14:58 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E8800D9.4050203@aQute.se...
> I am a bit confused. If we have dynamic plugins, we have the problem
> that they can go away. The patterns described to handle plugin creation
> are therefore not applicable anymore, isnt it?
>
> If plugins come and go, we need a service registry approach where the
> plugins are registered and unregistered. Access to static fields and
> getInstance()/getDefault() methods seem to be not sufficient?
Right. In actual fact, the plugin registry already provides this function.
If plugin A is deactivated and reactivated you can safely reference the new
one via the registry. Same for uninstall, install, update, ...
For my money getDefault/getInstance should be
return Platform.getPlugin("my id");
Jeff
|
|
|
| Re: Plugins - singletons or not? [message #17629 is a reply to message #17605] |
Mon, 31 March 2003 15:51 |
Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
Jeff McAffer wrote:
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E8800D9.4050203@aQute.se...
>
>>I am a bit confused. If we have dynamic plugins, we have the problem
>>that they can go away. The patterns described to handle plugin creation
>>are therefore not applicable anymore, isnt it?
>>
>>If plugins come and go, we need a service registry approach where the
>>plugins are registered and unregistered. Access to static fields and
>>getInstance()/getDefault() methods seem to be not sufficient?
>
>
> Right. In actual fact, the plugin registry already provides this function.
> If plugin A is deactivated and reactivated you can safely reference the new
> one via the registry. Same for uninstall, install, update, ...
>
> For my money getDefault/getInstance should be
> return Platform.getPlugin("my id");
>
I couldn't agree more with that last statement except that it doesn't go
far enough to address Peter's concern. To remove need for access to the
class one shouldn't even be using a static getInstance() method.
Instead, they should always be going directly to the
Platform.getPlugin("my id") modus, and probably Plugin implementation's
should not even be providing a getDefault()/getInstance() accessor.
Since this is not a strongly enforced convention, we may have problems
going forward with unnecessary coupling arising from this. I guess this
dependency is flagged broadly under the <requires> element.
Mel
|
|
|
| Re: Plugins - singletons or not? [message #17680 is a reply to message #17629] |
Mon, 31 March 2003 19:12 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b69nv7$ie2$1@rogue.oti.com...
> Jeff McAffer wrote:
> > "pkriens" <Peter.Kriens@aQute.se> wrote in message
> > news:3E8800D9.4050203@aQute.se...
> >
> >>I am a bit confused. If we have dynamic plugins, we have the problem
> >>that they can go away. The patterns described to handle plugin creation
> >>are therefore not applicable anymore, isnt it?
> >>
> >>If plugins come and go, we need a service registry approach where the
> >>plugins are registered and unregistered. Access to static fields and
> >>getInstance()/getDefault() methods seem to be not sufficient?
> >
> >
> > Right. In actual fact, the plugin registry already provides this
function.
> > If plugin A is deactivated and reactivated you can safely reference the
new
> > one via the registry. Same for uninstall, install, update, ...
> >
> > For my money getDefault/getInstance should be
> > return Platform.getPlugin("my id");
> >
>
> I couldn't agree more with that last statement except that it doesn't go
> far enough to address Peter's concern. To remove need for access to the
> class one shouldn't even be using a static getInstance() method.
> Instead, they should always be going directly to the
> Platform.getPlugin("my id") modus, and probably Plugin implementation's
> should not even be providing a getDefault()/getInstance() accessor.
Yes. I am a little unclear about the need to remove references to classes.
While this may be a good thing in general, clearly plugins are going to
reference classes from other plugins. Clearing up this one case does not
solve the problem. So what am I missing here? Are you proposing that all
cross plugin class references use some sort of service registry mechanism?
As a point of interest, how does that work for subclassing, implementing,
casting etc style relationships?
> Since this is not a strongly enforced convention, we may have problems
> going forward with unnecessary coupling arising from this. I guess this
> dependency is flagged broadly under the <requires> element.
The <requires> elements tell you that if A requires B and B is shutdown,
replaced, ... A needs to do something. The straightforward approach is to
shutdown and restart all the dependents (or the whole platform) in these
situations.
In OSGi (at least some older versions) the old bundle (B) would stay around
until the framework was restarted or all dependent bundles were shutdown and
restarted. Is this still the state of the art in OSGi?
Jeff
|
|
|
| Re: Plugins - singletons or not? [message #18453 is a reply to message #17680] |
Mon, 31 March 2003 20:47 |
Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
Jeff McAffer wrote:
> Yes. I am a little unclear about the need to remove references to classes.
> While this may be a good thing in general, clearly plugins are going to
> reference classes from other plugins. Clearing up this one case does not
> solve the problem. So what am I missing here? Are you proposing that all
> cross plugin class references use some sort of service registry mechanism?
> As a point of interest, how does that work for subclassing, implementing,
> casting etc style relationships?
>
Plugin subclasses are a special case compared to other classes in the
plugin packages because they provide 1)based on the lifecycle, the
Plugin subclass provides a logical starting point of initialization for
the rest of the plugin and 2) a platform-defined API for accessing a
variety of plugin-specific services (for example access to
Plugin.getPluginPreferences() provides a very plugin-specific service)
without need for visibility of the particular plugin's classes.
In other words, (1) provides reason for subclassing the Plugin class and
2) shows that cross-plugin utilization can happen without specific class
visibility.
Once you go beyond that to utilizing discrete classes and interfaces
from within the plugin, then you become coupled. The acts of
subclassing (extending & implementing) and casting all are compile-time
relationships because they require visibility of the classes you are
subclassing or casting to. The distinction can thus be generalized to
say that if you depend on it at compile time, you will definitely be
bound by classloader visibility during run-time. If you can compile
without the class, you _may_ be decoupled during run-time, depending on
whether you maintain stateful reference to the other plugin's objects.
Thus, a best practice for a component provider is (as Olivier has
mentioned repeatedly) to put the public interfaces and abstractions in
one 'B' plugin (which would tend to not get unloaded) and put
implementations in separate 'C' plugin(s) that can be unloaded.
And a best practice for a component consumer 'A' is to 1) only compile
against the 'B' plugin's classes and 2) never retain stateful reference
to objects pulled from other plugins.
The difficulty is that in order to hide the classes in 'C' from 'A',
they can't be public or exported. So you can't have them directly
created by 'B' since to support that they would need to be public.
Thus a third best practice is that the implementing plugin 'C' should
only export (a) public factory(s) as it's only public api, keeping all
implementation classes internal. 'B' then uses the factory in 'C' to
create implementations of 'B's interfaces for use by other plugins such
as 'A'. Now, 'A' _is_allowed_ to use 'C's public factory to create the
objects, but since the classes are not exported, it would have no way to
use them unless it uses 'B's interfaces so it might as well rely on 'B's
factories to build the objects.
>
>>Since this is not a strongly enforced convention, we may have problems
>>going forward with unnecessary coupling arising from this. I guess this
>>dependency is flagged broadly under the <requires> element.
>
>
> The <requires> elements tell you that if A requires B and B is shutdown,
> replaced, ... A needs to do something. The straightforward approach is to
> shutdown and restart all the dependents (or the whole platform) in these
> situations.
>
Yeah, I think that the straightforward solution is that if A requires B,
and B exports any classes, the assumption must be that A requires class
visibility and must be shutdown as well. That supports the current
model. As an enhancement to the relationship, though, we could extend
the plugin.xml so that when A specifies that it <requires> B, it
optionally can specify that it listens for events which would allow it
to clean up. In that case we would try to unload B without shutting A
down as well.
> In OSGi (at least some older versions) the old bundle (B) would stay around
> until the framework was restarted or all dependent bundles were shutdown and
> restarted. Is this still the state of the art in OSGi?
>
This is a perfectly legitimate way to handle the problem (multiple
instances of the component), so long as this is clear from the start and
both the API model and developer conventions have this potential
scenario in mind. Otherwise, there obviously is the potential for all
kinds of problems such as resource contention.
Mel
|
|
|
| Re: Plugins - singletons or not? [message #18480 is a reply to message #18453] |
Mon, 31 March 2003 21:31 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b6a99d$28t$1@rogue.oti.com...
> Jeff McAffer wrote:
>
> > Yes. I am a little unclear about the need to remove references to
classes.
> > While this may be a good thing in general, clearly plugins are going to
> > reference classes from other plugins. Clearing up this one case does
not
> > solve the problem. So what am I missing here? Are you proposing that
all
> > cross plugin class references use some sort of service registry
mechanism?
> > As a point of interest, how does that work for subclassing,
implementing,
> > casting etc style relationships?
> >
>
> Plugin subclasses are a special case compared to other classes in the
> plugin packages because they provide 1)based on the lifecycle, the
> Plugin subclass provides a logical starting point of initialization for
> the rest of the plugin and 2) a platform-defined API for accessing a
> variety of plugin-specific services (for example access to
> Plugin.getPluginPreferences() provides a very plugin-specific service)
> without need for visibility of the particular plugin's classes.
>
> In other words, (1) provides reason for subclassing the Plugin class and
> 2) shows that cross-plugin utilization can happen without specific class
> visibility.
Agreed. Relating this back to the original topic, we should advise against
using MyPlugin.getDefault() and recommend Platform.getPlugin("myPlugin").
Generalizing this, one of the tips and tricks for writing dynamic plugins
should include "avoid references to classes from other plugins where
alternatives exist or can be designed in".
Do you have a common usecase for one plugin to reference another's generic
plugin services (e.g., preference store) and have no references to any
classes from the plugin.
> Thus, a best practice for a component provider is (as Olivier has
> mentioned repeatedly) to put the public interfaces and abstractions in
> one 'B' plugin (which would tend to not get unloaded) and put
> implementations in separate 'C' plugin(s) that can be unloaded.
>
> And a best practice for a component consumer 'A' is to 1) only compile
> against the 'B' plugin's classes and 2) never retain stateful reference
> to objects pulled from other plugins.
right. This is the service model. It gives you finer granularity for
talking about changes. We can think of each plugin as one big service that
can change in various ways. See the registry delta discussion. It is still
possible to have finer granularity as complementary function.
> > The <requires> elements tell you that if A requires B and B is shutdown,
> > replaced, ... A needs to do something. The straightforward approach is
to
> > shutdown and restart all the dependents (or the whole platform) in these
> > situations.
>
> Yeah, I think that the straightforward solution is that if A requires B,
> and B exports any classes, the assumption must be that A requires class
> visibility and must be shutdown as well. That supports the current
> model. As an enhancement to the relationship, though, we could extend
> the plugin.xml so that when A specifies that it <requires> B, it
> optionally can specify that it listens for events which would allow it
> to clean up. In that case we would try to unload B without shutting A
> down as well.
The registry deltas allow for this information to be transmitted but
currently there is no way to say that A should not be shut down. Imagine
that as a result of being told of B's shutdown, A could respond with "shut
me down too" or "B? what B?". Default would be the former. Smarter
plugins could do the latter.
Jeff
|
|
|
| Re: Plugins - singletons or not? [message #18522 is a reply to message #18480] |
Tue, 01 April 2003 06:45 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
Jeff,
I would go as far as stating that in order to allow your plugin and any
dependents to be properly unloaded/reloaded, a developer MUST follow the
guidelines or own up to the problems that may occur when his/her plugin is
running along side plugins that do abide by the guidelines. I don't see any
reason why plugin developers can't follow the guidelines, what's the point
of developing a plugin for a framework and its engine if the plugin is a
renegade.
Assuming that the result of this project is an engine that can be used for
other UI based applications (outside of Eclipse), i'd say that each person
using the engine in their application should specify a best practices
guidelines for plugin developers.
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b6abss$4c3$1@rogue.oti.com...
>
> "Mel Martinez" <melm@us.ibm.com> wrote in message
> news:b6a99d$28t$1@rogue.oti.com...
> > Jeff McAffer wrote:
> >
> > > Yes. I am a little unclear about the need to remove references to
> classes.
> > > While this may be a good thing in general, clearly plugins are going
to
> > > reference classes from other plugins. Clearing up this one case does
> not
> > > solve the problem. So what am I missing here? Are you proposing that
> all
> > > cross plugin class references use some sort of service registry
> mechanism?
> > > As a point of interest, how does that work for subclassing,
> implementing,
> > > casting etc style relationships?
> > >
> >
> > Plugin subclasses are a special case compared to other classes in the
> > plugin packages because they provide 1)based on the lifecycle, the
> > Plugin subclass provides a logical starting point of initialization for
> > the rest of the plugin and 2) a platform-defined API for accessing a
> > variety of plugin-specific services (for example access to
> > Plugin.getPluginPreferences() provides a very plugin-specific service)
> > without need for visibility of the particular plugin's classes.
> >
> > In other words, (1) provides reason for subclassing the Plugin class and
> > 2) shows that cross-plugin utilization can happen without specific class
> > visibility.
>
> Agreed. Relating this back to the original topic, we should advise
against
> using MyPlugin.getDefault() and recommend Platform.getPlugin("myPlugin").
> Generalizing this, one of the tips and tricks for writing dynamic plugins
> should include "avoid references to classes from other plugins where
> alternatives exist or can be designed in".
>
> Do you have a common usecase for one plugin to reference another's generic
> plugin services (e.g., preference store) and have no references to any
> classes from the plugin.
>
> > Thus, a best practice for a component provider is (as Olivier has
> > mentioned repeatedly) to put the public interfaces and abstractions in
> > one 'B' plugin (which would tend to not get unloaded) and put
> > implementations in separate 'C' plugin(s) that can be unloaded.
> >
> > And a best practice for a component consumer 'A' is to 1) only compile
> > against the 'B' plugin's classes and 2) never retain stateful reference
> > to objects pulled from other plugins.
>
> right. This is the service model. It gives you finer granularity for
> talking about changes. We can think of each plugin as one big service
that
> can change in various ways. See the registry delta discussion. It is
still
> possible to have finer granularity as complementary function.
>
> > > The <requires> elements tell you that if A requires B and B is
shutdown,
> > > replaced, ... A needs to do something. The straightforward approach
is
> to
> > > shutdown and restart all the dependents (or the whole platform) in
these
> > > situations.
> >
> > Yeah, I think that the straightforward solution is that if A requires B,
> > and B exports any classes, the assumption must be that A requires class
> > visibility and must be shutdown as well. That supports the current
> > model. As an enhancement to the relationship, though, we could extend
> > the plugin.xml so that when A specifies that it <requires> B, it
> > optionally can specify that it listens for events which would allow it
> > to clean up. In that case we would try to unload B without shutting A
> > down as well.
>
> The registry deltas allow for this information to be transmitted but
> currently there is no way to say that A should not be shut down. Imagine
> that as a result of being told of B's shutdown, A could respond with "shut
> me down too" or "B? what B?". Default would be the former. Smarter
> plugins could do the latter.
>
> Jeff
>
>
|
|
|
| Re: Plugins - singletons or not? [message #18539 is a reply to message #17680] |
Tue, 01 April 2003 07:01 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Jeff McAffer wrote:
> In OSGi (at least some older versions) the old bundle (B) would stay around
> until the framework was restarted or all dependent bundles were shutdown and
> restarted. Is this still the state of the art in OSGi?
In release 1 some frameworks refreshed "eagerly", restarting any
dependent bundles, other frameworks left the packages lying around and
resolved the problem lazy. In release 2 we mandate the lazy approach but
provide a special service, the PackageAdmin service that allows the
Management Agent to initiate a refresh (and expose the current status of
package sharing). The refresh can do a global refresh or for a set of
bundles.
The idea behind this is that a management agent can install several
bundles before it refreshes saving time and some error scenarios.
BTW, what stayed around were exported packages not the bundle.
Kind regards,
Peter Kriens
>
> Jeff
>
>
>
|
|
|
| Re: Plugins - singletons or not? [message #18600 is a reply to message #18539] |
Tue, 01 April 2003 18:46 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Just to recap then.
"eager" = restart all dependents when a prereq changes
"lazy" = wait until an explicit framework restart/refresh to hook the new
packages into the global namespace.
Is this close? Assuming it is,
What happens during the refresh? Is this effectively a framework restart
where everything is shutdown and restarted? If not, how do the dependents
of some updated bundle know to drop their references to old classes and get
new ones?
Jeff
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E893936.8000104@aQute.se...
> Jeff McAffer wrote:
>
> > In OSGi (at least some older versions) the old bundle (B) would stay
around
> > until the framework was restarted or all dependent bundles were shutdown
and
> > restarted. Is this still the state of the art in OSGi?
>
> In release 1 some frameworks refreshed "eagerly", restarting any
> dependent bundles, other frameworks left the packages lying around and
> resolved the problem lazy. In release 2 we mandate the lazy approach but
> provide a special service, the PackageAdmin service that allows the
> Management Agent to initiate a refresh (and expose the current status of
> package sharing). The refresh can do a global refresh or for a set of
> bundles.
>
> The idea behind this is that a management agent can install several
> bundles before it refreshes saving time and some error scenarios.
>
> BTW, what stayed around were exported packages not the bundle.
>
> Kind regards,
>
> Peter Kriens
>
>
> >
> > Jeff
> >
> >
> >
>
|
|
|
| Re: Plugins - singletons or not? [message #19325 is a reply to message #18600] |
Tue, 01 April 2003 19:03 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Yes. your recap is correct.
A refresh is not a framework restart (though it might be implemented as
such for simple minded implementers). The parameter to the refresh is a
set of bundles. The implementation is supposed to calculate the closure
of all dependent bundles and restart those. So -at least- the affected
bundles should be stopped and started again (which effectively creates a
new ClassLoader for each). Good implementations minize the set of
affected bundles though this is not a trivial calculation.
Kind regards,
Peter Kriens
Jeff McAffer wrote:
> Just to recap then.
> "eager" = restart all dependents when a prereq changes
> "lazy" = wait until an explicit framework restart/refresh to hook the new
> packages into the global namespace.
> Is this close? Assuming it is,
>
> What happens during the refresh? Is this effectively a framework restart
> where everything is shutdown and restarted? If not, how do the dependents
> of some updated bundle know to drop their references to old classes and get
> new ones?
>
> Jeff
>
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E893936.8000104@aQute.se...
>
>>Jeff McAffer wrote:
>>
>>
>>>In OSGi (at least some older versions) the old bundle (B) would stay
>>>
> around
>
>>>until the framework was restarted or all dependent bundles were shutdown
>>>
> and
>
>>>restarted. Is this still the state of the art in OSGi?
>>>
>>In release 1 some frameworks refreshed "eagerly", restarting any
>>dependent bundles, other frameworks left the packages lying around and
>>resolved the problem lazy. In release 2 we mandate the lazy approach but
>>provide a special service, the PackageAdmin service that allows the
>>Management Agent to initiate a refresh (and expose the current status of
>>package sharing). The refresh can do a global refresh or for a set of
>>bundles.
>>
>>The idea behind this is that a management agent can install several
>>bundles before it refreshes saving time and some error scenarios.
>>
>>BTW, what stayed around were exported packages not the bundle.
>>
>>Kind regards,
>>
>>Peter Kriens
>>
>>
>>
>>>Jeff
>>>
>>>
>>>
>>>
>
>
|
|
|
| Re: Plugins - singletons or not? [message #19371 is a reply to message #19325] |
Tue, 01 April 2003 22:31 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Great. Thanks for the clarification. Makes sense.
Jeff
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E89E264.5040302@aQute.se...
> Yes. your recap is correct.
>
> A refresh is not a framework restart (though it might be implemented as
> such for simple minded implementers). The parameter to the refresh is a
> set of bundles. The implementation is supposed to calculate the closure
> of all dependent bundles and restart those. So -at least- the affected
> bundles should be stopped and started again (which effectively creates a
> new ClassLoader for each). Good implementations minize the set of
> affected bundles though this is not a trivial calculation.
>
> Kind regards,
>
> Peter Kriens
>
>
> Jeff McAffer wrote:
>
> > Just to recap then.
> > "eager" = restart all dependents when a prereq changes
> > "lazy" = wait until an explicit framework restart/refresh to hook the
new
> > packages into the global namespace.
> > Is this close? Assuming it is,
> >
> > What happens during the refresh? Is this effectively a framework
restart
> > where everything is shutdown and restarted? If not, how do the
dependents
> > of some updated bundle know to drop their references to old classes and
get
> > new ones?
> >
> > Jeff
> >
> > "pkriens" <Peter.Kriens@aQute.se> wrote in message
> > news:3E893936.8000104@aQute.se...
> >
> >>Jeff McAffer wrote:
> >>
> >>
> >>>In OSGi (at least some older versions) the old bundle (B) would stay
> >>>
> > around
> >
> >>>until the framework was restarted or all dependent bundles were
shutdown
> >>>
> > and
> >
> >>>restarted. Is this still the state of the art in OSGi?
> >>>
> >>In release 1 some frameworks refreshed "eagerly", restarting any
> >>dependent bundles, other frameworks left the packages lying around and
> >>resolved the problem lazy. In release 2 we mandate the lazy approach but
> >>provide a special service, the PackageAdmin service that allows the
> >>Management Agent to initiate a refresh (and expose the current status of
> >>package sharing). The refresh can do a global refresh or for a set of
> >>bundles.
> >>
> >>The idea behind this is that a management agent can install several
> >>bundles before it refreshes saving time and some error scenarios.
> >>
> >>BTW, what stayed around were exported packages not the bundle.
> >>
> >>Kind regards,
> >>
> >>Peter Kriens
> >>
> >>
> >>
> >>>Jeff
> >>>
> >>>
> >>>
> >>>
> >
> >
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 00:08:21 GMT 2024
Powered by FUDForum. Page generated in 0.04683 seconds |
] 
Search
Help
Register
Login
Home
