Home » Eclipse Projects » Equinox » Plugins as bundles (was Detailed items for dynamic plugins)
| Plugins as bundles (was Detailed items for dynamic plugins) [message #7860] |
Wed, 05 March 2003 21:58  |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
<for clarity/brevity I moved this thread up to the top level and trimmed the
message leaving one bundle spec as an example>
Great. That's perfect. A couple rudimentary OSGi questions.
- Can you describe the Bundle-ClassPath entry?
- Can you describe how the Bundle-Activator works with respect to class
loading and class loaders. (i.e., is it a real class that gets loaded by
the classloader for the bundle or is it loaded by a different loader? What
is its role/duties?...)
Thanks
Jeff
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b457dm$lu$1@rogue.oti.com...
> So here are my manifests...
>
> Bundle-Name: org.eclipse.core.runtime
> Bundle-Name: org.eclipse.core.resources
> Bundle-Name: org.eclipse.swt.win32
> Bundle-Name: org.eclipse.jface
> Bundle-Name: org.eclipse.jface.text
> Bundle-Name: org.eclipse.ui
> Bundle-Name: org.eclipse.ui.workbench
> Bundle-Name: org.eclipse.ui.workbench.texteditor
>
> These are for Eclipse 2.1.... that I had to modify a bit since
> there are packages split between plug-ins... that is, two plug-ins
> are contributing classes to the same package... I know it is
> a temporary thing that should get fixed later... hopefully in 2.2.
>
> Anyway, the bundle manifest might a little exporting too much...
> sometimes, it was rather mechanical for me to get it to work...
> but it gives a good idea... especially of the amount of dependencies
> there is in terms of packages...
>
> Notice also, there are no transitivity in OSGi... so all needed packages
> need to be listed... this seems daunting but this can be fully automated
> by PDE... it is really easy for PDE to see the actual import statements
> in the Java source and deduce the correct and complete set of imports.
>
> For exports... programmers have to be very disciplined... but this is very
> similar to have export filters... they have to think about which packages
> they want to export. A tool can easily point out missing exports for
> unmatched imports...
>
> PS:
> The syntax of the manifests is a bit enhanced wrt OSGi... but nothing
major,
> just allowing comments, and multi-line... no biggy :-)
>
> Best regards,
> Olivier.
> =====================================================
> Bundle-Name: org.eclipse.core.runtime
> Bundle-Version: 2.1.0
> Bundle-Description: IBM OSGi LogService, LogReaderService
> Bundle-Copyright: Licensed Materials - Property of IBM. (C) Copyright IBM
> Corp. 2000-2002 All Rights Reserved. IBM is a registered trademark of IBM
> Corp.
> Bundle-Vendor: IBM Pervasive Computing
> Bundle-DocUrl: http://www.ibm.com/pvc
> Bundle-ContactAddress: pervasive@us.ibm.com
> Build-Information: ${build-information}
> Bundle-ClassPath: .,bin,src
> Export-Package:
> org.eclipse.core.osgi; specification-version=2.1,
> org.eclipse.core.runtime; specification-version=2.1,
> org.eclipse.core.runtime.model; specification-version=2.1,
> org.eclipse.core.internal.plugins; specification-version=2.1
> Import-Package:
> org.eclipse.core.boot; specification-version=2.1,
> org.apache.xerces.parsers; specification-version=1.0
> Export-Service:
> org.eclipse.core.osgi.IRegistryService; specification-version=2.1
> Bundle-Activator:
> org.eclipse.core.osgi.RuntimeActivator
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #7923 is a reply to message #7860] |
Wed, 05 March 2003 23:14  |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
As Peter mentioned, the Bundle-ClassPath is a bundle local CLASSPATH.
It will mention the directories and jar files where to search for class
files.
it is used for any class loading that does not belong to either an imported
or an exported package.
For imported packages, the class loading is delegated to the exporter of the
corresponding package...
For exported packages, they are considered as being imported by default.
This ensures that everyone sees the same version of an exported package,
even the different contending exporters. The system picks which exporter
is exporting a package and all exporters of that package see that version.
Considering exported packages as imported ones forces this to happen.
Now, Bundle-Activator... the bundle activator is a class that is supposed
to be local to your bundle. Once a bundle is resolved (all its imports
are satisfied), it can be started. When started, its activator class is
loaded
and an instance is created (called the activator). The framework calls
the start method on the activator. What does this method is bundle
specific... for instance, in my port of Eclipse, this method looks up
the registry and passes the plugin.xml to it so to register the plug-in.
Also, it passes a reference to the bundle class loader to the registry
since the registry no longer creates the class loaders, but uses the OSGi
ones.
Nothing else happens, no other classes are loaded. Then, when
the registry activates the plug-in, it is the same sequence as it is today,
except that all class loading happens through OSGi class loaders,
that is all.
Typically, an activator is equivalent to the install shield... it is suppose
to finish the installation... In particular, it is suppose to lookup the
necessary
services for the bundle to run... (like above, the plug-in registry)...
and also create services exported by the bundle... although this could be
done later.
When the bundle is stopped, the activator is called again on the "stop"
method... the bundle is supposed to stop... that is, relinquish all
references to services it uses... revoke all services that it registered...
Relisquish other resources such as stop background threads if it has
any... It is also suppose to save any persistent data it cares to keep...
it prepares to be unloaded in other words.
That's about it.
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b45s68$gdp$1@rogue.oti.com...
> <for clarity/brevity I moved this thread up to the top level and trimmed
the
> message leaving one bundle spec as an example>
>
> Great. That's perfect. A couple rudimentary OSGi questions.
>
> - Can you describe the Bundle-ClassPath entry?
>
> - Can you describe how the Bundle-Activator works with respect to class
> loading and class loaders. (i.e., is it a real class that gets loaded by
> the classloader for the bundle or is it loaded by a different loader?
What
> is its role/duties?...)
>
> Thanks
> Jeff
>
>
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b457dm$lu$1@rogue.oti.com...
> > So here are my manifests...
> >
> > Bundle-Name: org.eclipse.core.runtime
> > Bundle-Name: org.eclipse.core.resources
> > Bundle-Name: org.eclipse.swt.win32
> > Bundle-Name: org.eclipse.jface
> > Bundle-Name: org.eclipse.jface.text
> > Bundle-Name: org.eclipse.ui
> > Bundle-Name: org.eclipse.ui.workbench
> > Bundle-Name: org.eclipse.ui.workbench.texteditor
> >
> > These are for Eclipse 2.1.... that I had to modify a bit since
> > there are packages split between plug-ins... that is, two plug-ins
> > are contributing classes to the same package... I know it is
> > a temporary thing that should get fixed later... hopefully in 2.2.
> >
> > Anyway, the bundle manifest might a little exporting too much...
> > sometimes, it was rather mechanical for me to get it to work...
> > but it gives a good idea... especially of the amount of dependencies
> > there is in terms of packages...
> >
> > Notice also, there are no transitivity in OSGi... so all needed packages
> > need to be listed... this seems daunting but this can be fully automated
> > by PDE... it is really easy for PDE to see the actual import statements
> > in the Java source and deduce the correct and complete set of imports.
> >
> > For exports... programmers have to be very disciplined... but this is
very
> > similar to have export filters... they have to think about which
packages
> > they want to export. A tool can easily point out missing exports for
> > unmatched imports...
> >
> > PS:
> > The syntax of the manifests is a bit enhanced wrt OSGi... but nothing
> major,
> > just allowing comments, and multi-line... no biggy :-)
> >
> > Best regards,
> > Olivier.
> > =====================================================
> > Bundle-Name: org.eclipse.core.runtime
> > Bundle-Version: 2.1.0
> > Bundle-Description: IBM OSGi LogService, LogReaderService
> > Bundle-Copyright: Licensed Materials - Property of IBM. (C) Copyright
IBM
> > Corp. 2000-2002 All Rights Reserved. IBM is a registered trademark of
IBM
> > Corp.
> > Bundle-Vendor: IBM Pervasive Computing
> > Bundle-DocUrl: http://www.ibm.com/pvc
> > Bundle-ContactAddress: pervasive@us.ibm.com
> > Build-Information: ${build-information}
> > Bundle-ClassPath: .,bin,src
> > Export-Package:
> > org.eclipse.core.osgi; specification-version=2.1,
> > org.eclipse.core.runtime; specification-version=2.1,
> > org.eclipse.core.runtime.model; specification-version=2.1,
> > org.eclipse.core.internal.plugins; specification-version=2.1
> > Import-Package:
> > org.eclipse.core.boot; specification-version=2.1,
> > org.apache.xerces.parsers; specification-version=1.0
> > Export-Service:
> > org.eclipse.core.osgi.IRegistryService; specification-version=2.1
> > Bundle-Activator:
> > org.eclipse.core.osgi.RuntimeActivator
> >
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #7937 is a reply to message #7923] |
Thu, 06 March 2003 01:57 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b460gv$iu2$1@rogue.oti.com...
> Now, Bundle-Activator... the bundle activator is a class that is supposed
> to be local to your bundle. Once a bundle is resolved (all its imports
> are satisfied), it can be started. When started, its activator class is
> loaded
> and an instance is created (called the activator). The framework calls
> the start method on the activator. What does this method is bundle
Does the framework always have to call the activator or is there a state
where the bundle is present/installed but not started? I seem to remember
something about this in the spec. A corollary to this is, do bundles have
to have an activator?
The reason for asking is that Eclipse targets installs with upto about 5000
plugins. We have current examples of 1000+ in one product stack so even
5000 may be conservative. If the platform has to create 5000 classloaders
and load 5000 activators, that will be a big impact both in speed and space.
Jeff
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #7949 is a reply to message #7937] |
Thu, 06 March 2003 07:55 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Bundles are -not- required to have an activator, they can be limited to
just exporting/importing packages.
Classloaders is another issue. If we want to be able to unload a plugin
a classloader seems to be the minimum. However, I think this can be
limited to (to be) started plugins. You should be able to skip the
classloader before it is started (actually before it is resolved in OSGi
speak).
Isnt the goal of this project to allow people to limit the number of
active plugins to reduce memory consumption? I have a hard time
imagining 5000 active plugins on today's generation of computers :-)
Anyway, the number 5000 should be quantified. I assume this means 5000
plugins on a (very) high end PC with workable performance?
On terminology. I'd like to propose to use the word "static plugin" for
todays Eclipse plugins and "dynamic plugins" for what we are developing.
I agree with Olivier that we should have a dynamic classloader layer at
the bottom that is generic, and well defined. On top of this layer we
(natively) handle dynamic plugins. We could then provide a dynamic
plugin that handles all static plugins. Done properly, this would give
us backward compatibility (which is paramount) and maybe can be
leveraged to minimize the overhead of a particular class of plugins.
+----------+
+------+------+ |
| stat. plugn +---+
+-------+-----+
+----------+ |
+------+------+ | +-------+-------+
| dyn. plugin +---+ | static plugin |
+------+------+ | manager |
| +-------+-------+
| |
+-----------------------------------------+
| dynamic plugin manager |
| class loading & life cycle management |
+-----------------------------------------+
(Hope the picture survives)
Kind regards,
Peter Kriens
Jeff McAffer wrote:
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b460gv$iu2$1@rogue.oti.com...
>
>
>>Now, Bundle-Activator... the bundle activator is a class that is supposed
>>to be local to your bundle. Once a bundle is resolved (all its imports
>>are satisfied), it can be started. When started, its activator class is
>>loaded
>>and an instance is created (called the activator). The framework calls
>>the start method on the activator. What does this method is bundle
>>
>
> Does the framework always have to call the activator or is there a state
> where the bundle is present/installed but not started? I seem to remember
> something about this in the spec. A corollary to this is, do bundles have
> to have an activator?
>
> The reason for asking is that Eclipse targets installs with upto about 5000
> plugins. We have current examples of 1000+ in one product stack so even
> 5000 may be conservative. If the platform has to create 5000 classloaders
> and load 5000 activators, that will be a big impact both in speed and space.
>
> Jeff
>
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #8845 is a reply to message #7923] |
Thu, 06 March 2003 07:59 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
> As Peter mentioned, the Bundle-ClassPath is a bundle local CLASSPATH.
> It will mention the directories and jar files where to search for class
> files.
> it is used for any class loading that does not belong to either an
imported
> or an exported package.
Actually, the Bundle-Classpath is also valid for export/import. It makes
it easy to wrap for example javamail.jar in a bundle without touching it
and providing the import/export clauses in the outer jar.
Kind regards,
Peter Kriens
Olivier Gruber wrote:
> As Peter mentioned, the Bundle-ClassPath is a bundle local CLASSPATH.
> It will mention the directories and jar files where to search for class
> files.
> it is used for any class loading that does not belong to either an imported
> or an exported package.
>
> For imported packages, the class loading is delegated to the exporter of the
> corresponding package...
>
> For exported packages, they are considered as being imported by default.
> This ensures that everyone sees the same version of an exported package,
> even the different contending exporters. The system picks which exporter
> is exporting a package and all exporters of that package see that version.
> Considering exported packages as imported ones forces this to happen.
>
> Now, Bundle-Activator... the bundle activator is a class that is supposed
> to be local to your bundle. Once a bundle is resolved (all its imports
> are satisfied), it can be started. When started, its activator class is
> loaded
> and an instance is created (called the activator). The framework calls
> the start method on the activator. What does this method is bundle
> specific... for instance, in my port of Eclipse, this method looks up
> the registry and passes the plugin.xml to it so to register the plug-in.
> Also, it passes a reference to the bundle class loader to the registry
> since the registry no longer creates the class loaders, but uses the OSGi
> ones.
> Nothing else happens, no other classes are loaded. Then, when
> the registry activates the plug-in, it is the same sequence as it is today,
> except that all class loading happens through OSGi class loaders,
> that is all.
>
> Typically, an activator is equivalent to the install shield... it is suppose
> to finish the installation... In particular, it is suppose to lookup the
> necessary
> services for the bundle to run... (like above, the plug-in registry)...
> and also create services exported by the bundle... although this could be
> done later.
>
> When the bundle is stopped, the activator is called again on the "stop"
> method... the bundle is supposed to stop... that is, relinquish all
> references to services it uses... revoke all services that it registered...
> Relisquish other resources such as stop background threads if it has
> any... It is also suppose to save any persistent data it cares to keep...
> it prepares to be unloaded in other words.
>
> That's about it.
> Best regards,
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> news:b45s68$gdp$1@rogue.oti.com...
>
>><for clarity/brevity I moved this thread up to the top level and trimmed
>>
> the
>
>>message leaving one bundle spec as an example>
>>
>>Great. That's perfect. A couple rudimentary OSGi questions.
>>
>>- Can you describe the Bundle-ClassPath entry?
>>
>>- Can you describe how the Bundle-Activator works with respect to class
>>loading and class loaders. (i.e., is it a real class that gets loaded by
>>the classloader for the bundle or is it loaded by a different loader?
>>
> What
>
>>is its role/duties?...)
>>
>>Thanks
>>Jeff
>>
>>
>>"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
>>news:b457dm$lu$1@rogue.oti.com...
>>
>>>So here are my manifests...
>>>
>>> Bundle-Name: org.eclipse.core.runtime
>>> Bundle-Name: org.eclipse.core.resources
>>> Bundle-Name: org.eclipse.swt.win32
>>> Bundle-Name: org.eclipse.jface
>>> Bundle-Name: org.eclipse.jface.text
>>> Bundle-Name: org.eclipse.ui
>>> Bundle-Name: org.eclipse.ui.workbench
>>> Bundle-Name: org.eclipse.ui.workbench.texteditor
>>>
>>>These are for Eclipse 2.1.... that I had to modify a bit since
>>>there are packages split between plug-ins... that is, two plug-ins
>>>are contributing classes to the same package... I know it is
>>>a temporary thing that should get fixed later... hopefully in 2.2.
>>>
>>>Anyway, the bundle manifest might a little exporting too much...
>>>sometimes, it was rather mechanical for me to get it to work...
>>>but it gives a good idea... especially of the amount of dependencies
>>>there is in terms of packages...
>>>
>>>Notice also, there are no transitivity in OSGi... so all needed packages
>>>need to be listed... this seems daunting but this can be fully automated
>>>by PDE... it is really easy for PDE to see the actual import statements
>>>in the Java source and deduce the correct and complete set of imports.
>>>
>>>For exports... programmers have to be very disciplined... but this is
>>>
> very
>
>>>similar to have export filters... they have to think about which
>>>
> packages
>
>>>they want to export. A tool can easily point out missing exports for
>>>unmatched imports...
>>>
>>>PS:
>>>The syntax of the manifests is a bit enhanced wrt OSGi... but nothing
>>>
>>major,
>>
>>>just allowing comments, and multi-line... no biggy :-)
>>>
>>>Best regards,
>>>Olivier.
>>>=====================================================
>>>Bundle-Name: org.eclipse.core.runtime
>>>Bundle-Version: 2.1.0
>>>Bundle-Description: IBM OSGi LogService, LogReaderService
>>>Bundle-Copyright: Licensed Materials - Property of IBM. (C) Copyright
>>>
> IBM
>
>>>Corp. 2000-2002 All Rights Reserved. IBM is a registered trademark of
>>>
> IBM
>
>>>Corp.
>>>Bundle-Vendor: IBM Pervasive Computing
>>>Bundle-DocUrl: http://www.ibm.com/pvc
>>>Bundle-ContactAddress: pervasive@us.ibm.com
>>>Build-Information: ${build-information}
>>>Bundle-ClassPath: .,bin,src
>>>Export-Package:
>>> org.eclipse.core.osgi; specification-version=2.1,
>>> org.eclipse.core.runtime; specification-version=2.1,
>>> org.eclipse.core.runtime.model; specification-version=2.1,
>>> org.eclipse.core.internal.plugins; specification-version=2.1
>>>Import-Package:
>>> org.eclipse.core.boot; specification-version=2.1,
>>> org.apache.xerces.parsers; specification-version=1.0
>>>Export-Service:
>>> org.eclipse.core.osgi.IRegistryService; specification-version=2.1
>>>Bundle-Activator:
>>> org.eclipse.core.osgi.RuntimeActivator
>>>
>>>
>>
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #8865 is a reply to message #7949] |
Thu, 06 March 2003 14:20 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E66FEF7.9070601@aQute.se...
> Bundles are -not- required to have an activator, they can be limited to
> just exporting/importing packages.
>
> Classloaders is another issue. If we want to be able to unload a plugin
> a classloader seems to be the minimum. However, I think this can be
> limited to (to be) started plugins. You should be able to skip the
> classloader before it is started (actually before it is resolved in OSGi
> speak).
Right. I was not suggesting a change in the classloader-per-bundle/plugin
model. Rather seeking to defer the creation of the classloaders as long as
possible.
> Isnt the goal of this project to allow people to limit the number of
> active plugins to reduce memory consumption? I have a hard time
> imagining 5000 active plugins on today's generation of computers :-)
> Anyway, the number 5000 should be quantified. I assume this means 5000
> plugins on a (very) high end PC with workable performance?
A couple observations:
- The numbers I suggested were for "installed" plugins. In any given
Eclipse session, only a portion of those would actually be active. It is
exactly this point that promotes the idea of "installed" things having
minimal footprint.
- Some plugins (notably doc, help, source) do not provide any code at all.
(11 of the 60 plugins in the SDK provide no code). It would be good to
support these without requiring code (activator) and perhaps even a
classloader.
> On terminology. I'd like to propose to use the word "static plugin" for
> todays Eclipse plugins and "dynamic plugins" for what we are developing.
sounds good
> I agree with Olivier that we should have a dynamic classloader layer at
> the bottom that is generic, and well defined. On top of this layer we
> (natively) handle dynamic plugins. We could then provide a dynamic
> plugin that handles all static plugins. Done properly, this would give
> us backward compatibility (which is paramount) and maybe can be
> leveraged to minimize the overhead of a particular class of plugins.
yes.
> +----------+
> +------+------+ |
> | stat. plugn +---+
> +-------+-----+
>
> +----------+ |
> +------+------+ | +-------+-------+
> | dyn. plugin +---+ | static plugin |
> +------+------+ | manager |
> | +-------+-------+
> | |
> +-----------------------------------------+
> | dynamic plugin manager |
> | class loading & life cycle management |
> +-----------------------------------------+
>
> (Hope the picture survives)
I nominate Peter to do all the ASCII art for the project :-)
> Kind regards,
>
> Peter Kriens
>
>
> Jeff McAffer wrote:
>
> > "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> > news:b460gv$iu2$1@rogue.oti.com...
> >
> >
> >>Now, Bundle-Activator... the bundle activator is a class that is
supposed
> >>to be local to your bundle. Once a bundle is resolved (all its imports
> >>are satisfied), it can be started. When started, its activator class is
> >>loaded
> >>and an instance is created (called the activator). The framework calls
> >>the start method on the activator. What does this method is bundle
> >>
> >
> > Does the framework always have to call the activator or is there a state
> > where the bundle is present/installed but not started? I seem to
remember
> > something about this in the spec. A corollary to this is, do bundles
have
> > to have an activator?
> >
> > The reason for asking is that Eclipse targets installs with upto about
5000
> > plugins. We have current examples of 1000+ in one product stack so even
> > 5000 may be conservative. If the platform has to create 5000
classloaders
> > and load 5000 activators, that will be a big impact both in speed and
space.
> >
> > Jeff
> >
> >
> >
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #8883 is a reply to message #8845] |
Thu, 06 March 2003 15:10 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Agreed.
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E66FFD3.2080609@aQute.se...
> > As Peter mentioned, the Bundle-ClassPath is a bundle local CLASSPATH.
> > It will mention the directories and jar files where to search for class
> > files.
> > it is used for any class loading that does not belong to either an
> imported
> > or an exported package.
>
> Actually, the Bundle-Classpath is also valid for export/import. It makes
> it easy to wrap for example javamail.jar in a bundle without touching it
> and providing the import/export clauses in the outer jar.
>
> Kind regards,
>
> Peter Kriens
>
> Olivier Gruber wrote:
>
> > As Peter mentioned, the Bundle-ClassPath is a bundle local CLASSPATH.
> > It will mention the directories and jar files where to search for class
> > files.
> > it is used for any class loading that does not belong to either an
imported
> > or an exported package.
> >
> > For imported packages, the class loading is delegated to the exporter of
the
> > corresponding package...
> >
> > For exported packages, they are considered as being imported by default.
> > This ensures that everyone sees the same version of an exported package,
> > even the different contending exporters. The system picks which exporter
> > is exporting a package and all exporters of that package see that
version.
> > Considering exported packages as imported ones forces this to happen.
> >
> > Now, Bundle-Activator... the bundle activator is a class that is
supposed
> > to be local to your bundle. Once a bundle is resolved (all its imports
> > are satisfied), it can be started. When started, its activator class is
> > loaded
> > and an instance is created (called the activator). The framework calls
> > the start method on the activator. What does this method is bundle
> > specific... for instance, in my port of Eclipse, this method looks up
> > the registry and passes the plugin.xml to it so to register the plug-in.
> > Also, it passes a reference to the bundle class loader to the registry
> > since the registry no longer creates the class loaders, but uses the
OSGi
> > ones.
> > Nothing else happens, no other classes are loaded. Then, when
> > the registry activates the plug-in, it is the same sequence as it is
today,
> > except that all class loading happens through OSGi class loaders,
> > that is all.
> >
> > Typically, an activator is equivalent to the install shield... it is
suppose
> > to finish the installation... In particular, it is suppose to lookup the
> > necessary
> > services for the bundle to run... (like above, the plug-in registry)...
> > and also create services exported by the bundle... although this could
be
> > done later.
> >
> > When the bundle is stopped, the activator is called again on the "stop"
> > method... the bundle is supposed to stop... that is, relinquish all
> > references to services it uses... revoke all services that it
registered...
> > Relisquish other resources such as stop background threads if it has
> > any... It is also suppose to save any persistent data it cares to
keep...
> > it prepares to be unloaded in other words.
> >
> > That's about it.
> > Best regards,
> > --
> > Olivier Gruber, Ph.D.
> > Persistent & Distributed Object Platforms and Frameworks
> > IBM TJ Watson Research Center
> >
> > "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> > news:b45s68$gdp$1@rogue.oti.com...
> >
> >><for clarity/brevity I moved this thread up to the top level and trimmed
> >>
> > the
> >
> >>message leaving one bundle spec as an example>
> >>
> >>Great. That's perfect. A couple rudimentary OSGi questions.
> >>
> >>- Can you describe the Bundle-ClassPath entry?
> >>
> >>- Can you describe how the Bundle-Activator works with respect to class
> >>loading and class loaders. (i.e., is it a real class that gets loaded
by
> >>the classloader for the bundle or is it loaded by a different loader?
> >>
> > What
> >
> >>is its role/duties?...)
> >>
> >>Thanks
> >>Jeff
> >>
> >>
> >>"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> >>news:b457dm$lu$1@rogue.oti.com...
> >>
> >>>So here are my manifests...
> >>>
> >>> Bundle-Name: org.eclipse.core.runtime
> >>> Bundle-Name: org.eclipse.core.resources
> >>> Bundle-Name: org.eclipse.swt.win32
> >>> Bundle-Name: org.eclipse.jface
> >>> Bundle-Name: org.eclipse.jface.text
> >>> Bundle-Name: org.eclipse.ui
> >>> Bundle-Name: org.eclipse.ui.workbench
> >>> Bundle-Name: org.eclipse.ui.workbench.texteditor
> >>>
> >>>These are for Eclipse 2.1.... that I had to modify a bit since
> >>>there are packages split between plug-ins... that is, two plug-ins
> >>>are contributing classes to the same package... I know it is
> >>>a temporary thing that should get fixed later... hopefully in 2.2.
> >>>
> >>>Anyway, the bundle manifest might a little exporting too much...
> >>>sometimes, it was rather mechanical for me to get it to work...
> >>>but it gives a good idea... especially of the amount of dependencies
> >>>there is in terms of packages...
> >>>
> >>>Notice also, there are no transitivity in OSGi... so all needed
packages
> >>>need to be listed... this seems daunting but this can be fully
automated
> >>>by PDE... it is really easy for PDE to see the actual import statements
> >>>in the Java source and deduce the correct and complete set of imports.
> >>>
> >>>For exports... programmers have to be very disciplined... but this is
> >>>
> > very
> >
> >>>similar to have export filters... they have to think about which
> >>>
> > packages
> >
> >>>they want to export. A tool can easily point out missing exports for
> >>>unmatched imports...
> >>>
> >>>PS:
> >>>The syntax of the manifests is a bit enhanced wrt OSGi... but nothing
> >>>
> >>major,
> >>
> >>>just allowing comments, and multi-line... no biggy :-)
> >>>
> >>>Best regards,
> >>>Olivier.
> >>>=====================================================
> >>>Bundle-Name: org.eclipse.core.runtime
> >>>Bundle-Version: 2.1.0
> >>>Bundle-Description: IBM OSGi LogService, LogReaderService
> >>>Bundle-Copyright: Licensed Materials - Property of IBM. (C) Copyright
> >>>
> > IBM
> >
> >>>Corp. 2000-2002 All Rights Reserved. IBM is a registered trademark of
> >>>
> > IBM
> >
> >>>Corp.
> >>>Bundle-Vendor: IBM Pervasive Computing
> >>>Bundle-DocUrl: http://www.ibm.com/pvc
> >>>Bundle-ContactAddress: pervasive@us.ibm.com
> >>>Build-Information: ${build-information}
> >>>Bundle-ClassPath: .,bin,src
> >>>Export-Package:
> >>> org.eclipse.core.osgi; specification-version=2.1,
> >>> org.eclipse.core.runtime; specification-version=2.1,
> >>> org.eclipse.core.runtime.model; specification-version=2.1,
> >>> org.eclipse.core.internal.plugins; specification-version=2.1
> >>>Import-Package:
> >>> org.eclipse.core.boot; specification-version=2.1,
> >>> org.apache.xerces.parsers; specification-version=1.0
> >>>Export-Service:
> >>> org.eclipse.core.osgi.IRegistryService; specification-version=2.1
> >>>Bundle-Activator:
> >>> org.eclipse.core.osgi.RuntimeActivator
> >>>
> >>>
> >>
> >
> >
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #8905 is a reply to message #7937] |
Thu, 06 March 2003 15:32 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Some comments below,
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b46a6g$nr0$1@rogue.oti.com...
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b460gv$iu2$1@rogue.oti.com...
>
> The reason for asking is that Eclipse targets installs with upto about
5000
> plugins. We have current examples of 1000+ in one product stack so even
> 5000 may be conservative. If the platform has to create 5000 classloaders
> and load 5000 activators, that will be a big impact both in speed and
space.
I am not sure I agree there...
First, creating a class loader is creating an object... I don't believe
there is much
overhead hidden there... even down in the JVM. Hence, I am not sure it would
be a visible overhead given that we are creating a lot of objects in Eclipse
when
parsing the plugin.xml... :-)
Second, the activator is not "activating" the plug-in in the Eclipse
sense...
it is providing the plugin.xml to the plug-in registry... so we are just
loading
an extra class per plug-in. Would that be visible against parsing of the
5000
XML files and creating the entire descriptions in the registry ? I would
have
to be convinced there by numbers.
Actually, an easy modification to OSGi would be to allow the Activator-Class
to be loaded by a different class loader than the bundle class loaer... that
way,
we could load only once a generic class for the default registering of all
plug-ins.
Plus, why should the bootstrap wait until the 5000 plug-ins are parsed and
described in the registry.... Couldn't we background the registering of most
of them? Could we reload only the set of plug-ins that were last active...
assuming that plug-ins get deactivated following some Least-Recently-Used
policy...
This means that menus may not be complete, all perspectives and views
may not be there... but the end user will see a workbench that looked
like what he left and he can restart working right away... Of course, this
means that the plugin-activating actions need to know give a visual
feedback that not all perspectives or views are known yet...
until the background loading is finished.
Third and last, without creating a class loader, you are assuming the
platform always
knows how the plug-in is managed on disk and how to access the plugin.xml
resource... the class loader allows to hide that and rely on the normal
getRessource
method. I think I remember in the code some mention about supporting remote
plug-in sites... Wouldn't it that suggests to have a class loader for
accessing the plugin.xml resource ?
> Jeff
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #8925 is a reply to message #8905] |
Thu, 06 March 2003 18:53 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b47pr7$qcp$1@rogue.oti.com...
> "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
>
> > The reason for asking is that Eclipse targets installs with upto about
> 5000
> > plugins. We have current examples of 1000+ in one product stack so even
> > 5000 may be conservative. If the platform has to create 5000
classloaders
> > and load 5000 activators, that will be a big impact both in speed and
> space.
>
> I am not sure I agree there...
>
> First, creating a class loader is creating an object... I don't believe
> there is much
> overhead hidden there... even down in the JVM. Hence, I am not sure it
would
> be a visible overhead given that we are creating a lot of objects in
Eclipse
> when
> parsing the plugin.xml... :-)
Classloader overhead depends on the VM. I know of some where the overhead
is quite high.
> Second, the activator is not "activating" the plug-in in the Eclipse
> sense...
> it is providing the plugin.xml to the plug-in registry... so we are just
> loading
> an extra class per plug-in. Would that be visible against parsing of the
> 5000
> XML files and creating the entire descriptions in the registry ? I would
> have
> to be convinced there by numbers.
Loading 5000 classes from 5000 *different* jars cannot be very much fun.
Note that this is in addition to the parsing not instead of. Every
millisecond of startup time is precious.
> Actually, an easy modification to OSGi would be to allow the
Activator-Class
> to be loaded by a different class loader than the bundle class loaer...
that
> way,
> we could load only once a generic class for the default registering of all
> plug-ins.
This would help but there would still be alot of jar opening, class reading
etc. Would it make sense to toss the activator for plugins and have the
registry mechanism goes out and find/parse the plugin.xml like it does
today?
> Plus, why should the bootstrap wait until the 5000 plug-ins are parsed and
> described in the registry.... Couldn't we background the registering of
most
> of them? Could we reload only the set of plug-ins that were last active...
> assuming that plug-ins get deactivated following some Least-Recently-Used
> policy...
>
> This means that menus may not be complete, all perspectives and views
> may not be there... but the end user will see a workbench that looked
> like what he left and he can restart working right away... Of course, this
> means that the plugin-activating actions need to know give a visual
> feedback that not all perspectives or views are known yet...
> until the background loading is finished.
This might make sense but suspect it will be complex. Consider for example
that in session 1 I have some jdbc plugin active and it has various DB
connections. Then when I start session 2 the plugin will be activated again
even if I don't want/need a DB connection.
Note that currently the registry is parsed once and cached unless there are
changes to the configuration (install). This saves huge amounts of startup
time.
> Third and last, without creating a class loader, you are assuming the
> platform always
> knows how the plug-in is managed on disk and how to access the plugin.xml
> resource... the class loader allows to hide that and rely on the normal
> getRessource
> method. I think I remember in the code some mention about supporting
remote
> plug-in sites... Wouldn't it that suggests to have a class loader for
> accessing the plugin.xml resource ?
We use URLs not classloaders to get this behaviour.
Jeff
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #8989 is a reply to message #8925] |
Thu, 06 March 2003 21:51 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
In the OSGi model installing is a phase under control of the framework.
There are already many clever tricks done by implementations that use
this phase to pre-process the jar file/manifest, configuration and
security settings. This makes caching straightforward and probably
faster than scanning 5000 directories for changed files. I.e. I once had
an implementation where I actually expanded the JARs in a database of
resource (class) files.
I'd also like to point out that the import/export clauses in the
manifest make classloading a constant time operation independent of the
number of loaders due to that a package can only be exported by one
loader which allows you to hashing. (Not like JMX that does a search
over a potentially all class loaders).
Anyway, if almost anything of 5000 is pushing the envelope in Java.
I would prefer to continue discussing the models and then when we have 2
or 3 alternatives do some benchmarking. It is usually very hard to
estimate the impact of choices so early in the game.
Kind regards,
Peter Kriens
Jeff McAffer wrote:
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b47pr7$qcp$1@rogue.oti.com...
>
>>"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
>>
>>
>>>The reason for asking is that Eclipse targets installs with upto about
>>>
>>5000
>>
>>>plugins. We have current examples of 1000+ in one product stack so even
>>>5000 may be conservative. If the platform has to create 5000
>>>
> classloaders
>
>>>and load 5000 activators, that will be a big impact both in speed and
>>>
>>space.
>>
>>I am not sure I agree there...
>>
>>First, creating a class loader is creating an object... I don't believe
>>there is much
>>overhead hidden there... even down in the JVM. Hence, I am not sure it
>>
> would
>
>>be a visible overhead given that we are creating a lot of objects in
>>
> Eclipse
>
>>when
>>parsing the plugin.xml... :-)
>>
>
> Classloader overhead depends on the VM. I know of some where the overhead
> is quite high.
>
>
>>Second, the activator is not "activating" the plug-in in the Eclipse
>>sense...
>>it is providing the plugin.xml to the plug-in registry... so we are just
>>loading
>>an extra class per plug-in. Would that be visible against parsing of the
>>5000
>>XML files and creating the entire descriptions in the registry ? I would
>>have
>>to be convinced there by numbers.
>>
>
> Loading 5000 classes from 5000 *different* jars cannot be very much fun.
> Note that this is in addition to the parsing not instead of. Every
> millisecond of startup time is precious.
>
>
>>Actually, an easy modification to OSGi would be to allow the
>>
> Activator-Class
>
>>to be loaded by a different class loader than the bundle class loaer...
>>
> that
>
>>way,
>>we could load only once a generic class for the default registering of all
>>plug-ins.
>>
>
> This would help but there would still be alot of jar opening, class reading
> etc. Would it make sense to toss the activator for plugins and have the
> registry mechanism goes out and find/parse the plugin.xml like it does
> today?
>
>
>>Plus, why should the bootstrap wait until the 5000 plug-ins are parsed and
>>described in the registry.... Couldn't we background the registering of
>>
> most
>
>>of them? Could we reload only the set of plug-ins that were last active...
>>assuming that plug-ins get deactivated following some Least-Recently-Used
>>policy...
>>
>>This means that menus may not be complete, all perspectives and views
>>may not be there... but the end user will see a workbench that looked
>>like what he left and he can restart working right away... Of course, this
>>means that the plugin-activating actions need to know give a visual
>>feedback that not all perspectives or views are known yet...
>>until the background loading is finished.
>>
>
> This might make sense but suspect it will be complex. Consider for example
> that in session 1 I have some jdbc plugin active and it has various DB
> connections. Then when I start session 2 the plugin will be activated again
> even if I don't want/need a DB connection.
>
> Note that currently the registry is parsed once and cached unless there are
> changes to the configuration (install). This saves huge amounts of startup
> time.
>
>
>>Third and last, without creating a class loader, you are assuming the
>>platform always
>>knows how the plug-in is managed on disk and how to access the plugin.xml
>>resource... the class loader allows to hide that and rely on the normal
>>getRessource
>>method. I think I remember in the code some mention about supporting
>>
> remote
>
>>plug-in sites... Wouldn't it that suggests to have a class loader for
>>accessing the plugin.xml resource ?
>>
>
> We use URLs not classloaders to get this behaviour.
>
> Jeff
>
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #9093 is a reply to message #8989] |
Fri, 07 March 2003 03:59 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E67C2F9.6040407@aQute.se...
> In the OSGi model installing is a phase under control of the framework.
> There are already many clever tricks done by implementations that use
> this phase to pre-process the jar file/manifest, configuration and
> security settings. This makes caching straightforward and probably
> faster than scanning 5000 directories for changed files. I.e. I once had
> an implementation where I actually expanded the JARs in a database of
> resource (class) files.
Is OSGi 3.0 available yet in any form? I really should refresh myself and
may as well go for the latest.
> I'd also like to point out that the import/export clauses in the
> manifest make classloading a constant time operation independent of the
> number of loaders due to that a package can only be exported by one
> loader which allows you to hashing. (Not like JMX that does a search
> over a potentially all class loaders).
Anyone know what Avalon does?
Eclipse does something akin to this but not as agressive. Plugins can
declare what packages their loader can load (this is different from what
they export). Using that we can compute the loader to use for a particular
package. Actually, we allow the specification of package prefixes to for a
given package there may be several loaders to consult but assuming the
prefix info is reasonable, this set should be small.
> Anyway, if almost anything of 5000 is pushing the envelope in Java.
>
> I would prefer to continue discussing the models and then when we have 2
> or 3 alternatives do some benchmarking. It is usually very hard to
> estimate the impact of choices so early in the game.
Agreed. We do need to keep in mind however the scale of things. 5000 is
alot but there is no reason we should not be able to manage it. Remember,
in general they are not all active at the same time.
Jeff
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #9113 is a reply to message #9093] |
Fri, 07 March 2003 07:04 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Jeff McAffer wrote:
> Is OSGi 3.0 available yet in any form? I really should refresh myself and
> may as well go for the latest.
Release should have been published around this time but we are slightly
delayed for non-technical reasons (the spec is fully ready).
The R2 spec can be downloaded from the web. The core part that would be
useful for Eclipse has not many changes to R3 (excepty maybe the dynamic
import facility).
http://www.osgi.org/resources/docs/spr2book.pdf
Member companies can consult
http://membercvs.osgi.org/specs/pdf/sp-r3.book.pdf
When your company is a member, you can register with www.osgi.org/
http://www.osgi.org/contact/passwordreq.asp
You should get your access password in a couple of days. If you have
registered but are impatient && have a member mail address, mail me for
a password on membercvs.osgi.org. You can contact your OSGi
representative (which is BJ Hargrave for IBM).
> Anyone know what Avalon does?
I have been lurking for 6 months on their mailing list and read their
documentation. From what I have seen they focus more on a larger
granularity of services than what we need here. But I would love to get
a good introduction from Leo Simons <leosimons@apache.org> in this
context. My personal opinion (as you may expect :-) is that OSGi is much
more mature in the areas we are discussing.
Yesterday I read part of the JMX spec because I see it being mentioned
in several places. However, their classloader model uses a delegation
model that is very simplistic. Their M-lets get loaded and they can
export anything. The order of loading depends the search order. From the
spec you can see they had to do a lot of bug fixing. Sighhh, wish they
had just used OSGi :-)
Kind regards,
Peter Kriens
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #9174 is a reply to message #8925] |
Fri, 07 March 2003 14:16 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Jeff,
> Classloader overhead depends on the VM. I know of some where the
overhead
> is quite high.
That is good to know.
> > Actually, an easy modification to OSGi would be to allow the
Activator-Class
> > to be loaded by a different class loader than the bundle class
loaer... that way,
> > we could load only once a generic class for the default registering
of all
> > plug-ins.
>
> This would help but there would still be alot of jar opening, class
reading
> etc.
No, this is not correct. If the ActivatorClass would be allowed to be loaded
by another class loader than the class loader of the bundle being loaded,
then no extra class loading is necessary and therefore no jar opening.
The generic activator would just access the plugins directory, get
the plugin.xml file and pass it to the plugin registry.
So beside creating the class loader to access the plugin.xml resource,
the overhead is the same as today.
>Would it make sense to toss the activator for plugins and have the
> registry mechanism goes out and find/parse the plugin.xml like it does
> today?
It could, if we are ok that plug-in packaging and management allows
the use of URLs for accessing their content... I am not convinced yet.
Also, the class loader in OSGi is not created for activating the bundle,
it is created when resolving the bundle. If think this is yet another
difference
between Eclipse and OSGi.
Correct me if I am wrong, but in Eclipse today, everything is driven through
extensions... this is the trigering fact for activating a plugin... If no
one ask for
one of the plugin extensions... the plugin is not activated. Correct ?
In OSGi, a bundle when installed is first resolved---if possible.
When resolved---i.e. its imports are satisfied---the bundle contributes its
exports. The resolve is automatic once installed... So once installed and
resolved, a bundle like Ant or Xerces would be available... without being
activated (even without an Activator).
So the questions we need to answer are:
- when do a plugin/bundle need to contribute their exports ?
- when do a plugin/bundle need to be activated ?
In OSGi, these are different times... I am not convinced at all that
those two should remain equivalent like in Eclipse today.
> Every millisecond of startup time is precious.
Agreed, but I find you a bit quick in dismissing the potential of
backgrounding
the bootstrap... especially when you say...
> Note that currently the registry is parsed once and cached unless
there are
> changes to the configuration (install). This saves huge amounts of
startup
> time.
So in the absence of any configuration... the OSGi platform would have to
load the bundles for the plugin registry... which would bootstrap from its
cache.
If the resolving of bundles is now backgrounded, the question is not startup
time
but it becomes can the JVM handles 5000 class loaders, which is a fair
question.
In reality, the real question becomes who knows when and what bundles need
be resolved and/or activated... In OSGi, bundles would have to be installed
and uninstalled dynamically to achieve the behavior you want. So basically,
you are asking to have OSGi bootstrap with just the core bundles supporting
the plugin registry itself... Then the plugin registry would install a
bundle when
it wants to activate it... that will create the class loader. Upon shutting
down,
the plugin registry would uninstall all plugins... so that at the next
startup, OSGi
restarts without loading them automatically.
Now the question about how is the platform accessing the plugin.xml is sort
of secondary... upon installing a feature, even before the plugins are
passed
to the OSGi layer, that the plugin.xml is extracted and passed to the plugin
registry...
Peter, does it make sense to you ?
Something is bothering me with this approach, but I can't quite get my
finger
on it...
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #9191 is a reply to message #9174] |
Fri, 07 March 2003 16:26 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b4a9mf$hcb$1@rogue.oti.com...
> > This would help but there would still be alot of jar opening, class
> reading
> > etc.
>
> No, this is not correct. If the ActivatorClass would be allowed to be
loaded
> by another class loader than the class loader of the bundle being loaded,
> then no extra class loading is necessary and therefore no jar opening.
> The generic activator would just access the plugins directory, get
> the plugin.xml file and pass it to the plugin registry.
>
> So beside creating the class loader to access the plugin.xml resource,
> the overhead is the same as today.
Ok. I misunderstood. Your model has one activator class for the entire
system. I thought you meant that each bundle had an activator class but
that there was just one classloader loading these activators. So with this
in mind, it pretty much matches what I was intending with my next comment...
> >Would it make sense to toss the activator for plugins and have the
> > registry mechanism goes out and find/parse the plugin.xml like it
does
> > today?
>
> It could, if we are ok that plug-in packaging and management allows
> the use of URLs for accessing their content... I am not convinced yet.
> Also, the class loader in OSGi is not created for activating the bundle,
> it is created when resolving the bundle. If think this is yet another
> difference
> between Eclipse and OSGi.
>
> Correct me if I am wrong, but in Eclipse today, everything is driven
through
> extensions... this is the trigering fact for activating a plugin... If no
> one ask for
> one of the plugin extensions... the plugin is not activated. Correct ?
This is another key area of difference between Eclipse and OSGi. In eclipse
the only way for a plugin to be "activated" (Eclipse technical term) is for
the classloader associated with the plugin to actually load a class.
Extensions are a common way for this to occur but are not, in and of
themselves, the trigger nor are they the only way. Basically the plugin
classloader, when asked to load a class, first looks to see if it has the
class. If it does (and it is not already loaded), it checks to see if the
associated plugin is activated. If it is, loading continues as normal. If
it is not, the plugin is first activated. When activation is complete, the
requested class is loaded and returned.
Now, there are issues here. We generally like the activation triggered by
classloading but there are problems in the implementation that may be
impossible to resolve. We can get in to more detail in a separate thread.
One challenge for us then is to see how this model can be merged/modified to
work with the underlying support from frameworks like OSGi.
> Agreed, but I find you a bit quick in dismissing the potential of
> backgrounding
> the bootstrap... especially when you say...
>
> > Note that currently the registry is parsed once and cached unless
> there are
> > changes to the configuration (install). This saves huge amounts of
> startup
> > time.
>
> So in the absence of any configuration... the OSGi platform would have to
> load the bundles for the plugin registry... which would bootstrap from its
> cache.
> If the resolving of bundles is now backgrounded, the question is not
startup
> time
> but it becomes can the JVM handles 5000 class loaders, which is a fair
> question.
I am not dismissing it, I just see it as complicated.
- reactivating previously active plugins on restart requires some sort of
automatic plugin deactivation policy so the working set of plugins does not
grow monotonically. I believe this policy to be hard to define and
implement.
- startup time (for me) is the time from double clicking on the icon to when
I can start editing my Java code/web content/... Work needs to be done to
ensure that the plugin needed by the user at startup is not the last one of
5000 to be processed in the background. It is unclear to me how this can be
done in a reasonable way.
- the data structures (classloaders, registry entries,...) associated with
processed plugins should be as minimal as possible for plugins which are not
active. Background processing or not, maintaining the full structure of
5000 plugins in memory will be disappointing. (we are bummed by the
partitial structure of 1000 plugins now!)
Jeff
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #9211 is a reply to message #9191] |
Fri, 07 March 2003 20:14 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
First we are discussing implementation issues. Of course, optimizations
are limited by what a spec theorethically allows.
I disagree with Olivier about the install/uninstall for activation. I
think the activation should be handled with start/stop. The OSGi spec
allows the creation of a class loader very late in the process. I.e. a
bundle may remain unresolved until it is started (it may however not
export until it is resolved).
So my preferred model would probably be that a plugin is installed like
a bundle. During the installation the management agent (Eclipse) detects
the installation and pre-processes the plugin.xml. It stores this
somewhere on disk. (See SynchronousBundleListener for how this is done).
This is a one time action and thus not performance intensive.
When Eclipse needs the plugin it will start it. So what kind of triggers
are we talking about? I guess the static info could be used to create
Action objects that start the dynamic plugin when they are used from the
GUI ?
For exporting packages it is not needed to do anything I think. An
installed bundle can export packages (and import). I think it should be
straightforward to create the required class loader lazily in the
framework. This means that only bundles participating have a classloader.
The nice thing with the OSGi model is that you have a well defined map
of imported/exported packages. If 5000 plugins is a realistic number (I
have my reservations) you could actually keep the package map on disk so
you minimize memory consumption. However, this seems an optimization
where normal implementations would have to pay a price for extreme
requirements.
So: Install for a new plugin, lazily start and lazily export when needed.
Kind regards,
Peter Kriens
Jeff McAffer wrote:
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b4a9mf$hcb$1@rogue.oti.com...
>
>> > This would help but there would still be alot of jar opening, class
>>reading
>> > etc.
>>
>>No, this is not correct. If the ActivatorClass would be allowed to be
>>
> loaded
>
>>by another class loader than the class loader of the bundle being loaded,
>>then no extra class loading is necessary and therefore no jar opening.
>>The generic activator would just access the plugins directory, get
>>the plugin.xml file and pass it to the plugin registry.
>>
>>So beside creating the class loader to access the plugin.xml resource,
>>the overhead is the same as today.
>>
>
> Ok. I misunderstood. Your model has one activator class for the entire
> system. I thought you meant that each bundle had an activator class but
> that there was just one classloader loading these activators. So
with this
> in mind, it pretty much matches what I was intending with my next
comment...
>
>
>> >Would it make sense to toss the activator for plugins and have the
>> > registry mechanism goes out and find/parse the plugin.xml like it
>>
> does
>
>> > today?
>>
>>It could, if we are ok that plug-in packaging and management allows
>>the use of URLs for accessing their content... I am not convinced yet.
>>
>
>
>>Also, the class loader in OSGi is not created for activating the bundle,
>>it is created when resolving the bundle. If think this is yet another
>>difference
>>between Eclipse and OSGi.
>>
>>Correct me if I am wrong, but in Eclipse today, everything is driven
>>
> through
>
>>extensions... this is the trigering fact for activating a plugin... If no
>>one ask for
>>one of the plugin extensions... the plugin is not activated. Correct ?
>>
>
> This is another key area of difference between Eclipse and OSGi. In
eclipse
> the only way for a plugin to be "activated" (Eclipse technical term)
is for
> the classloader associated with the plugin to actually load a class.
> Extensions are a common way for this to occur but are not, in and of
> themselves, the trigger nor are they the only way. Basically the plugin
> classloader, when asked to load a class, first looks to see if it has the
> class. If it does (and it is not already loaded), it checks to see
if the
> associated plugin is activated. If it is, loading continues as
normal. If
> it is not, the plugin is first activated. When activation is
complete, the
> requested class is loaded and returned.
>
> Now, there are issues here. We generally like the activation
triggered by
> classloading but there are problems in the implementation that may be
> impossible to resolve. We can get in to more detail in a separate
thread.
>
> One challenge for us then is to see how this model can be
merged/modified to
> work with the underlying support from frameworks like OSGi.
>
>
>>Agreed, but I find you a bit quick in dismissing the potential of
>>backgrounding
>>the bootstrap... especially when you say...
>>
>> > Note that currently the registry is parsed once and cached unless
>>there are
>> > changes to the configuration (install). This saves huge amounts of
>>startup
>> > time.
>>
>>So in the absence of any configuration... the OSGi platform would have to
>>load the bundles for the plugin registry... which would bootstrap
from its
>>cache.
>>If the resolving of bundles is now backgrounded, the question is not
>>
> startup
>
>>time
>>but it becomes can the JVM handles 5000 class loaders, which is a fair
>>question.
>>
>
> I am not dismissing it, I just see it as complicated.
> - reactivating previously active plugins on restart requires some sort of
> automatic plugin deactivation policy so the working set of plugins
does not
> grow monotonically. I believe this policy to be hard to define and
> implement.
>
> - startup time (for me) is the time from double clicking on the icon
to when
> I can start editing my Java code/web content/... Work needs to be
done to
> ensure that the plugin needed by the user at startup is not the last
one of
> 5000 to be processed in the background. It is unclear to me how this
can be
> done in a reasonable way.
>
> - the data structures (classloaders, registry entries,...) associated
with
> processed plugins should be as minimal as possible for plugins which
are not
> active. Background processing or not, maintaining the full structure of
> 5000 plugins in memory will be disappointing. (we are bummed by the
> partitial structure of 1000 plugins now!)
>
> Jeff
>
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #10242 is a reply to message #9211] |
Fri, 07 March 2003 22:44 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E68FD98.8050408@aQute.se...
> When Eclipse needs the plugin it will start it. So what kind of triggers
> are we talking about? I guess the static info could be used to create
> Action objects that start the dynamic plugin when they are used from the
> GUI ?
One of the issues we will face here is that Eclipse activates plugins the
first time a class is loaded by that plugin's classloader. That could be
the result of some class verification, a user action in the UI, some
explicit Class.forName, ... There are some hooks we can use to cover many
of these (e.g., see createExecutableExtension()) but there will still be
holes.
> For exporting packages it is not needed to do anything I think. An
> installed bundle can export packages (and import). I think it should be
> straightforward to create the required class loader lazily in the
> framework. This means that only bundles participating have a classloader.
Sounds good. Question, can a bundle export classes (i.e., have entries in
the framework;s export table or whatever) and yet still not have a
classloader associated and not have any classes loaded? There are usecases
where bundle A imports a wide range of packages. If A cannot be started
until all of its imports are satisified then all the imported things must be
exported. If exporting requires starting the prereq bundles etc then
effectively the transitive closure of required bundles (i.e., those
exporting imported packages) will be started.
> The nice thing with the OSGi model is that you have a well defined map
> of imported/exported packages. If 5000 plugins is a realistic number (I
> have my reservations) you could actually keep the package map on disk so
> you minimize memory consumption. However, this seems an optimization
> where normal implementations would have to pay a price for extreme
> requirements.
Cool. We do a flavour of this in Eclipse 2.1 where parts of the registry
are stored on disk and paged in as needed. It saves us a fair bit of space
and so far has not cost alot of time.
Jeff
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #10307 is a reply to message #10242] |
Sat, 08 March 2003 11:06 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Jeff McAffer wrote:
> One of the issues we will face here is that Eclipse activates plugins the
> first time a class is loaded by that plugin's classloader. That could be
> the result of some class verification, a user action in the UI, some
> explicit Class.forName, ... There are some hooks we can use to cover many
> of these (e.g., see createExecutableExtension()) but there will still be
> holes.
I think this can be fully handled with the current spec if we separate
the activation between classloading (libraries) and active dynamic
plugins with behavior. If we want to activate a plugin once one of its
classes is needed we need, for OSGi, a new type of hook. However,
activating a dynamic entity before a cloass is loaded seems kind of
tricky to me due to the unpredictable behavior of classloading. I.e.
circular dependencies which will create initialization order issues.
> Sounds good. Question, can a bundle export classes (i.e., have entries in
> the framework;s export table or whatever) and yet still not have a
> classloader associated and not have any classes loaded?
When a bundle is installed, it is available as entity (Bundle object).
At that time, it does not need to have a classloader yet. The bundle
object can be kept very small I think when the bundle is not started yet.
> There are usecases
> where bundle A imports a wide range of packages. If A cannot be started
> until all of its imports are satisified then all the imported things must be
> exported. If exporting requires starting the prereq bundles etc then
> effectively the transitive closure of required bundles (i.e., those
> exporting imported packages) will be started.
Yes. But I think any other solution is pushing problems to a later time
when real work can be lost. It again makes the cases where we want to
distinguishe between active dynamic plugins and library dynamic plugins.
Where activations is actively triggered and not by classloading (I think).
> Cool. We do a flavour of this in Eclipse 2.1 where parts of the registry
> are stored on disk and paged in as needed. It saves us a fair bit of space
> and so far has not cost alot of time.
Did you try with 5000 plugins :-) (Still think the number is a bit over
the top).
Kind regards,
Peter Kriens
>
> Jeff
>
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #10573 is a reply to message #9093] |
Sat, 08 March 2003 21:14 |
| Eclipse User |
|
|
|
Originally posted by: joerg.schaible.web.de
Hi Jeff,
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> schrieb im Newsbeitrag
news:b495mc$qej$1@rogue.oti.com...
>
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E67C2F9.6040407@aQute.se...
[...]
> > I'd also like to point out that the import/export clauses in the
> > manifest make classloading a constant time operation independent of the
> > number of loaders due to that a package can only be exported by one
> > loader which allows you to hashing. (Not like JMX that does a search
> > over a potentially all class loaders).
>
> Anyone know what Avalon does?
See Stephen McConnell's description in his posting of the basic avalon
implementations. From my (not very long) usage of the simpler Fortress
implementation I know, that you can define yourself how many background
threads are used to run through the initialization part of the life-cycle
model.
Merlin (i.e. the more basic assembly package) is here much more
sophisticated
and dealing also with different classloaders and versioning.
Regards,
J
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #10739 is a reply to message #9093] |
Sun, 09 March 2003 08:15 |
| Eclipse User |
|
|
|
Originally posted by: mcconnell.apache.org
Jeff McAffer wrote:
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E67C2F9.6040407@aQute.se...
>
>>In the OSGi model installing is a phase under control of the framework.
>>There are already many clever tricks done by implementations that use
>>this phase to pre-process the jar file/manifest, configuration and
>>security settings. This makes caching straightforward and probably
>>faster than scanning 5000 directories for changed files. I.e. I once had
>>an implementation where I actually expanded the JARs in a database of
>>resource (class) files.
>
>
> Is OSGi 3.0 available yet in any form? I really should refresh myself and
> may as well go for the latest.
>
>
>>I'd also like to point out that the import/export clauses in the
>>manifest make classloading a constant time operation independent of the
>>number of loaders due to that a package can only be exported by one
>>loader which allows you to hashing. (Not like JMX that does a search
>>over a potentially all class loaders).
>
>
> Anyone know what Avalon does?
The Assembly package scans (a) manifest and (b) indexes of jar files.
Manifests scanning establishes extension dependencies. If a jar file
contains extension dependencies then these extensions are loaded and
scanned. Index scanning is the process of looking for components within
a jar file.
Components are recognized by <classname>.xinfo files contained in the
jar file. Jar files may also include <classname>.xprofile and
<classname>.xconfig files. Profiles are component deployment templates.
The xconfig is a default configuration. The xinfo is the actually
meta-data about the component. During the scanning process this
information is collected and assigned to different repositories,
enabling the establishment of candidate components.
When you request a particular service provider, the assembly engine
builds an Appliance which is basically the association of deployment
context, configuration, etc. together with associations to all of the
deployment and runtime providers. A service request to a provider
results in the deployment of the component (and behind the scenes the
deployment of all deployment provider components and runtime dependent
components).
At the Merlin level there is a thing called a Block. A block is the
encapsulation of all of the stuff happening above. A block structure
looks something like:
* block
* engine definition
* classloader directives
* extension directives
* implementation
* import of external blocks
* inclusion of embedded blocks
* interface
* service export directives
In addition to the above, a block is a component, and as such it can
declare its own deployment and runtime dependencies.
Somethin to keep in mind is that the impact of the above is that you
know in advance is a component is deployable or not, and secondly, if it
is deployable, the component is deployed when needed (which is not
necessarily at the time of compoent establishment). Thirdly, the block
abstract enables encapsualtion of service provider sourcing - so for
example service providers can be distributed. All of the above is aimed
at enabling a scalable distributed service platform.
>
> Eclipse does something akin to this but not as agressive. Plugins can
> declare what packages their loader can load (this is different from what
> they export). Using that we can compute the loader to use for a particular
> package. Actually, we allow the specification of package prefixes to for a
> given package there may be several loaders to consult but assuming the
> prefix info is reasonable, this set should be small.
>
>
>>Anyway, if almost anything of 5000 is pushing the envelope in Java.
>>
>>I would prefer to continue discussing the models and then when we have 2
>>or 3 alternatives do some benchmarking. It is usually very hard to
>>estimate the impact of choices so early in the game.
>
> Agreed. We do need to keep in mind however the scale of things. 5000 is
> alot but there is no reason we should not be able to manage it. Remember,
> in general they are not all active at the same time.
The default implementation in the assembly framework works well in the
range of hundreds. For something in the order of thousands and
alternative implementation of the service, type, profile and applliance
respositories would be required (but this is relatively strait-forward
as repositories are already plugable.
Cheers, Steve.
> Jeff
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #10826 is a reply to message #10307] |
Sun, 09 March 2003 14:56 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Peter,
I am a little confused here...
> When a bundle is installed, it is available as entity (Bundle object).
> At that time, it does not need to have a classloader yet. The bundle
> object can be kept very small I think when the bundle is not started
yet.
Just to be clear, a bundle may be installed, resolved, or active...
In the installed state, the bundle neither imports nor export packages.
In the resolved state, the bundle has all its imports satisfied (exported
by other bundles in at least the resolved state).
In the active state, the bundle is resolved and the "start" method on
the activator has been called.
So, are you suggesting that when installing a bundle, the bundle is
created but there is no attempt to actually resolve it... that is, no
class loader is created. In other word, be lazzy about it. However,
the framework would build the map of who is exporting what...
Then, bundle activation would be the trigger for transitive resolves,
therefore creating the class loaders for all the needed exporters.
Sounds good to me, but I need to think more about that one...
However, I still have a problem with accesing the plugin.xml,
parsing it and caching the results on disk as you propose.
I guess one of the question here is how Eclipse and OSGi relate.
(1) Eclipse is a set of bundles above OSGi...
(2) Eclipse is an OSGi implementation...
The two are fundamentally different in what Eclipse is allowed to do or
not... :-)
In (1), Eclipse cannot access directly the internals of a bundle
once installed. The Eclipse plugin registry would need to go through
the OSGi framework. This would be done through Bundle.getResouce().
But, as per the JavaDoc, this is supposed to go through the class loader...
In (2), Eclipse can do what it wants... so it can give priviledge
access to the plugin.xml... So there, everything is possible, I guess,
haven't thought it through...
So, which one are we talking about ?
An Eclipse that is an OSGi environment... or an Eclipse that
runs above an OSGi environment ?
As I understand what you said, we are talking about Eclipse being an OSGi
implementation, with a fully lazzy resolve behavior and priviledge access
to bundle resources (such as plugin.xml).
Is that correct?
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E69CEC3.2040203@aQute.se...
> Jeff McAffer wrote:
>
> > One of the issues we will face here is that Eclipse activates plugins
the
> > first time a class is loaded by that plugin's classloader. That could
be
> > the result of some class verification, a user action in the UI, some
> > explicit Class.forName, ... There are some hooks we can use to cover
many
> > of these (e.g., see createExecutableExtension()) but there will still be
> > holes.
>
> I think this can be fully handled with the current spec if we separate
> the activation between classloading (libraries) and active dynamic
> plugins with behavior. If we want to activate a plugin once one of its
> classes is needed we need, for OSGi, a new type of hook. However,
> activating a dynamic entity before a cloass is loaded seems kind of
> tricky to me due to the unpredictable behavior of classloading. I.e.
> circular dependencies which will create initialization order issues.
>
>
> > Sounds good. Question, can a bundle export classes (i.e., have entries
in
> > the framework;s export table or whatever) and yet still not have a
> > classloader associated and not have any classes loaded?
>
> When a bundle is installed, it is available as entity (Bundle object).
> At that time, it does not need to have a classloader yet. The bundle
> object can be kept very small I think when the bundle is not started yet.
>
> > There are usecases
> > where bundle A imports a wide range of packages. If A cannot be started
> > until all of its imports are satisified then all the imported things
must be
> > exported. If exporting requires starting the prereq bundles etc then
> > effectively the transitive closure of required bundles (i.e., those
> > exporting imported packages) will be started.
>
> Yes. But I think any other solution is pushing problems to a later time
> when real work can be lost. It again makes the cases where we want to
> distinguishe between active dynamic plugins and library dynamic plugins.
> Where activations is actively triggered and not by classloading (I think).
>
>
> > Cool. We do a flavour of this in Eclipse 2.1 where parts of the
registry
> > are stored on disk and paged in as needed. It saves us a fair bit of
space
> > and so far has not cost alot of time.
>
> Did you try with 5000 plugins :-) (Still think the number is a bit over
> the top).
>
> Kind regards,
>
> Peter Kriens
>
>
>
> >
> > Jeff
> >
> >
> >
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #11936 is a reply to message #10826] |
Sun, 09 March 2003 20:20 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Olivier Gruber wrote:
> Peter,
> I am a little confused here...
I think you resolved that confusion while writing the mail?
> (1) Eclipse is a set of bundles above OSGi...
> (2) Eclipse is an OSGi implementation...
Why not both? I would like a model where Equinox would have a separate
component that is an OSGi implemention heavily optimized for Eclipse use
cases. E.g. 5000 plugins, relatively few active bundles etc. On top of
that Eclipse runs as a bundle. The cool thing is that it would allow one
to run Eclipse on a framework of SUN, IBM, Siemens, Samsung, Gatespace,
Acunia, Prosyst, Atinave, Espial, etc. Having a solid spec in the
middle makes the job easier I think.
Kind regards,
Peter Kriens
>
> The two are fundamentally different in what Eclipse is allowed to do or
> not... :-)
>
> In (1), Eclipse cannot access directly the internals of a bundle
> once installed. The Eclipse plugin registry would need to go through
> the OSGi framework. This would be done through Bundle.getResouce().
> But, as per the JavaDoc, this is supposed to go through the class loader...
>
> In (2), Eclipse can do what it wants... so it can give priviledge
> access to the plugin.xml... So there, everything is possible, I guess,
> haven't thought it through...
>
> So, which one are we talking about ?
> An Eclipse that is an OSGi environment... or an Eclipse that
> runs above an OSGi environment ?
>
> As I understand what you said, we are talking about Eclipse being an OSGi
> implementation, with a fully lazzy resolve behavior and priviledge access
> to bundle resources (such as plugin.xml).
>
> Is that correct?
>
> Best regards,
>
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E69CEC3.2040203@aQute.se...
>
>>Jeff McAffer wrote:
>>
>>
>>>One of the issues we will face here is that Eclipse activates plugins
>>>
> the
>
>>>first time a class is loaded by that plugin's classloader. That could
>>>
> be
>
>>>the result of some class verification, a user action in the UI, some
>>>explicit Class.forName, ... There are some hooks we can use to cover
>>>
> many
>
>>>of these (e.g., see createExecutableExtension()) but there will still be
>>>holes.
>>>
>>I think this can be fully handled with the current spec if we separate
>>the activation between classloading (libraries) and active dynamic
>>plugins with behavior. If we want to activate a plugin once one of its
>>classes is needed we need, for OSGi, a new type of hook. However,
>>activating a dynamic entity before a cloass is loaded seems kind of
>>tricky to me due to the unpredictable behavior of classloading. I.e.
>>circular dependencies which will create initialization order issues.
>>
>>
>>
>>>Sounds good. Question, can a bundle export classes (i.e., have entries
>>>
> in
>
>>>the framework;s export table or whatever) and yet still not have a
>>>classloader associated and not have any classes loaded?
>>>
>>When a bundle is installed, it is available as entity (Bundle object).
>>At that time, it does not need to have a classloader yet. The bundle
>>object can be kept very small I think when the bundle is not started yet.
>>
>>
>>>There are usecases
>>>where bundle A imports a wide range of packages. If A cannot be started
>>>until all of its imports are satisified then all the imported things
>>>
> must be
>
>>>exported. If exporting requires starting the prereq bundles etc then
>>>effectively the transitive closure of required bundles (i.e., those
>>>exporting imported packages) will be started.
>>>
>>Yes. But I think any other solution is pushing problems to a later time
>>when real work can be lost. It again makes the cases where we want to
>>distinguishe between active dynamic plugins and library dynamic plugins.
>>Where activations is actively triggered and not by classloading (I think).
>>
>>
>>
>>>Cool. We do a flavour of this in Eclipse 2.1 where parts of the
>>>
> registry
>
>>>are stored on disk and paged in as needed. It saves us a fair bit of
>>>
> space
>
>>>and so far has not cost alot of time.
>>>
>>Did you try with 5000 plugins :-) (Still think the number is a bit over
>>the top).
>>
>>Kind regards,
>>
>>Peter Kriens
>>
>>
>>
>>
>>>Jeff
>>>
>>>
>>>
>>>
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #11949 is a reply to message #11936] |
Sun, 09 March 2003 20:39 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E6BA215.7030609@aQute.se...
> Olivier Gruber wrote:
>
> > Peter,
> > I am a little confused here...
>
> I think you resolved that confusion while writing the mail?
>
> > (1) Eclipse is a set of bundles above OSGi...
> > (2) Eclipse is an OSGi implementation...
Just to be painfully pedantic and ensure we are all talking about same
thing...
> Why not both? I would like a model where Equinox would have a separate
> component that is an OSGi implemention heavily optimized for Eclipse use
"component" = technical OSGi term? (I suspect not)
"OSGi implementation" => of the OSGi framework spec?
This is #2 right?
> cases. E.g. 5000 plugins, relatively few active bundles etc. On top of
> that Eclipse runs as a bundle. The cool thing is that it would allow one
"Eclipse runs as a bundle": do you mean "a bunch of bundles" essentially
one per plugin (i.e., #1)?
> to run Eclipse on a framework of SUN, IBM, Siemens, Samsung, Gatespace,
> Acunia, Prosyst, Atinave, Espial, etc. Having a solid spec in the
> middle makes the job easier I think.
My summary of this is:
Do #1 as the main approach but also do #2 to optimize the cases where other
OSGi implementations do not expect the sort of usecase Eclipse presents.
That is, #1 cannot assume #2 as requiring our own OSGi implementation is not
alot better than what we have today.
Concur?
Jeff
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #11962 is a reply to message #11949] |
Sun, 09 March 2003 21:13 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Jeff McAffer wrote:
> Do #1 as the main approach but also do #2 to optimize the cases where other
> OSGi implementations do not expect the sort of usecase Eclipse presents.
Fully concur.
> That is, #1 cannot assume #2 as requiring our own OSGi implementation is not
> alot better than what we have today.
Coupling an Eclipse/OSGi framework to Eclipse on OSGi would leave out
some of the advantages imho. The nice thing with starting from a stable
specification is that from day 1 you have stable implementations for
testing. It simplifies the development significantly.
The Eclipse OSGi implementation would of course have use outside Eclipse
as well. It might be an important foundation component for many other
projects.
Kind regards,
Peter Kriens
>
> Concur?
>
> Jeff
>
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #12089 is a reply to message #11962] |
Mon, 10 March 2003 15:54 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E6BAE79.4080007@aQute.se...
> Jeff McAffer wrote:
> Coupling an Eclipse/OSGi framework to Eclipse on OSGi would leave out
> some of the advantages imho. The nice thing with starting from a stable
> specification is that from day 1 you have stable implementations for
> testing. It simplifies the development significantly.
>
> The Eclipse OSGi implementation would of course have use outside Eclipse
> as well. It might be an important foundation component for many other
> projects.
It is an interesting directly. Going this way we would really have to deal
with any fundamental incompatibilities up front. The basic models must line
up etc. so that any Eclipse OSGi implementation would purely be for
optimizations. Note that we should also have confidence that "reasonable"
Eclipse installs would work well on various OSGi implemenations. Issues of
early classloading, startup, classloader creation are not just a problem in
the 5000 plugin case!
Jeff
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #13067 is a reply to message #11936] |
Thu, 13 March 2003 12:51 |
| Eclipse User |
|
|
|
Originally posted by: delete_heavy_nospam.ungoverned.org
pkriens wrote:
> Olivier Gruber wrote:
>> (1) Eclipse is a set of bundles above OSGi...
>> (2) Eclipse is an OSGi implementation...
>
>
> Why not both? I would like a model where Equinox would have a separate
> component that is an OSGi implemention heavily optimized for Eclipse use
> cases. E.g. 5000 plugins, relatively few active bundles etc. On top of
> that Eclipse runs as a bundle. The cool thing is that it would allow one
> to run Eclipse on a framework of SUN, IBM, Siemens, Samsung, Gatespace,
> Acunia, Prosyst, Atinave, Espial, etc. Having a solid spec in the
> middle makes the job easier I think.
>
I agree with Peter here, I think the best approach is if we could create
standard bundles out of Eclipse (and associated plugins), so that it
would run on any OSGi framework (albeit, slower).
After reading all of this discussion about performance, I concur that it
all seems do-able. Oscar already does lazy bundle resolve...although
currently it does create the class loader at the get-go, but this is
definitely not necessary.
Oscar is not an exercise in performance tuning, but everything discussed
here sounds reasonable. I have users with lots of bundles that were
seeing start-up slowness; this was resolved in a simplistic fashion by
caching JarFile objects when accessing bundle JARs, instead of
recreating each time.
I don't really think this is the best approach for best performance,
though. I think pre-processing a bundle the first time it is installed
is better. Perhaps even extracting all bundle JARs and embedded JARs, so
they can be accessed directly in the file system. This would waste disk
space, but perhaps it better than wasting memory and CPU.
I think the more difficult issues are not performance (since all dynamic
and static plug-in mechanisms suffer from these issues), rather I think
bridging the mismatch in core assumptions in versioning, etc.
-> richard
|
|
| |
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #14172 is a reply to message #14071] |
Wed, 19 March 2003 00:10 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
I thought Eclipse persisted plugins or something for faster startup? I
notice the first time I start it up after adding some projects it takes
longer than subsequent starts. I believe however this is due to the JVM
loading the first time and afterwards the OS keeps some of the JVM dll's
cached or something. I see this in my own apps to, where the first time I
launch the app it seems to take 20+ seconds, then afterwards its like 2
seconds or so.
So what you are describing is a way to log the frequency of which a plugin
is used and give it a priority to be reloaded first the next time Eclipse
starts. I thought Eclipse lasy loads all plugins anyway, so that no plugins
are loaded initially until a menu item or button is clicked? I am sure some
basic plugins start up, to restore project state, but I thought almost all
plugins don't load or get created until requested.
"Richard Wilson" <richard_wilson@us.ibm.com> wrote in message
news:b55qr1$mkr$1@rogue.oti.com...
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b47pr7$qcp$1@rogue.oti.com...
> ...
> >
> > Plus, why should the bootstrap wait until the 5000 plug-ins are parsed
and
> > described in the registry.... Couldn't we background the registering of
> most
> > of them? Could we reload only the set of plug-ins that were last
active...
> > assuming that plug-ins get deactivated following some
Least-Recently-Used
> > policy...
> >
> > This means that menus may not be complete, all perspectives and views
> > may not be there... but the end user will see a workbench that looked
> > like what he left and he can restart working right away... Of course,
this
> > means that the plugin-activating actions need to know give a visual
> > feedback that not all perspectives or views are known yet...
> > until the background loading is finished.
> >
> When eclipse is used in cases where it is booted or restarted often, a
> quicker startup time would be very attractive. I like the idea of trying
to
> speed the eclipse platform startup time by loading last-used plugins in
the
> foreground and loading the rest in the background. This of course
requires
> dynamicity in the plugin registry and could be an especially appealing win
> when registering large plugin sets.
>
> Rick
>
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #14206 is a reply to message #14172] |
Wed, 19 March 2003 03:08 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Eclipse currently parses all discovered plugin.xml (and fragment.xml) files
on first startup or when it detects that there is likely a change. A plugin
registry is built from this information and the platform is started. At
some point in the running of this session, this registry is dumped to a
binary file as a cache. On subsequent starts (assuming no changes have been
detected) the registry is reloaded from this cache. The amount of time
saved varies with the number and complexity of the plugins in the registry
but for example, an order of magnitude (e.g., 6s -> 600ms) is pretty
standard.
Eclipse lazily *activates* plugins. This implies class loading not plugin
registry entry loading. All plugins are eagerly discovered and the registry
populated.
Side note, the cache is structured such that we can make loading even more
lazy. Large chunks of a particular plugin's registry structure is left on
disk on restart and loaded on demand.
Hope that clears things up.
Jeff
"Kevin" <kduffey@marketron.com> wrote in message
news:b58ci6$jo2$1@rogue.oti.com...
> I thought Eclipse persisted plugins or something for faster startup? I
> notice the first time I start it up after adding some projects it takes
> longer than subsequent starts. I believe however this is due to the JVM
> loading the first time and afterwards the OS keeps some of the JVM dll's
> cached or something. I see this in my own apps to, where the first time I
> launch the app it seems to take 20+ seconds, then afterwards its like 2
> seconds or so.
>
> So what you are describing is a way to log the frequency of which a plugin
> is used and give it a priority to be reloaded first the next time Eclipse
> starts. I thought Eclipse lasy loads all plugins anyway, so that no
plugins
> are loaded initially until a menu item or button is clicked? I am sure
some
> basic plugins start up, to restore project state, but I thought almost all
> plugins don't load or get created until requested.
>
> "Richard Wilson" <richard_wilson@us.ibm.com> wrote in message
> news:b55qr1$mkr$1@rogue.oti.com...
> > "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> > news:b47pr7$qcp$1@rogue.oti.com...
> > ...
> > >
> > > Plus, why should the bootstrap wait until the 5000 plug-ins are parsed
> and
> > > described in the registry.... Couldn't we background the registering
of
> > most
> > > of them? Could we reload only the set of plug-ins that were last
> active...
> > > assuming that plug-ins get deactivated following some
> Least-Recently-Used
> > > policy...
> > >
> > > This means that menus may not be complete, all perspectives and views
> > > may not be there... but the end user will see a workbench that looked
> > > like what he left and he can restart working right away... Of course,
> this
> > > means that the plugin-activating actions need to know give a visual
> > > feedback that not all perspectives or views are known yet...
> > > until the background loading is finished.
> > >
> > When eclipse is used in cases where it is booted or restarted often, a
> > quicker startup time would be very attractive. I like the idea of trying
> to
> > speed the eclipse platform startup time by loading last-used plugins in
> the
> > foreground and loading the rest in the background. This of course
> requires
> > dynamicity in the plugin registry and could be an especially appealing
win
> > when registering large plugin sets.
> >
> > Rick
> >
> >
> >
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #14322 is a reply to message #13067] |
Sat, 22 March 2003 14:14 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Could not agree more... especially on the following points:
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Richard S. Hall" <delete_heavy_nospam@ungoverned.org> wrote in message
news:b4puvm$g7f$1@rogue.oti.com...
> After reading all of this discussion about performance, I concur that
it
> all seems do-able. Oscar already does lazy bundle resolve...although
> currently it does create the class loader at the get-go, but this is
> definitely not necessary.
I am actually working on this... see below...
> I don't really think this is the best approach for best performance,
> though. I think pre-processing a bundle the first time it is installed
> is better. Perhaps even extracting all bundle JARs and embedded JARs,
so
> they can be accessed directly in the file system. This would waste
disk
> space, but perhaps it better than wasting memory and CPU.
I would totally agree here and I am quite puzzled at why do we keep
jar files... Is it only for saving disk space ? Does any one from Eclispe
has the answer why Eclipse does not manipulate its plugins always
with directories of class files rather than jars... actually, this would
simplify
things because now plugins would have only one format (the -dev format,
not the packaged one)... so there must be a reason...
> I think the more difficult issues are not performance (since all
dynamic
> and static plug-in mechanisms suffer from these issues), rather I
think
> bridging the mismatch in core assumptions in versioning, etc.
Again, bull's eye... All this talking about performance has been diverting
us from the real issues... I understand though, it is quite natural...
But, the fact remains... some assumptions are different and this results
in different models. They are very close to each others though, so there
is great hope in merging them... however, both parties would have to
give up a bit to gain a lot...
I am working as I write on this merge... figuring out a middle ground
that would be acceptable for both parties... Hoping to have good news
soon...
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #14334 is a reply to message #14206] |
Sat, 22 March 2003 14:24 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Thanks Jeff, it does clarify what Eclipse does today,
but does not clarify what you think about backgrounded
plug-in loading... This is just an idea, and not top priority,
but I would keep it in mind.
The original idea was that likely, when I restart Eclipse, I will
reuse the same plugins as when I shut them down... this is actually
why Eclipse re-creates my workbench as it was...
Hence, all the other plugins don't even need to be known by the
registry... I am likely to be able to work with Eclipse. For instance,
if I was editing Java, I would need the Java perspective... but if I am
using an Eclipse with dozen of tools... and thousands of plugins...
most of them I don't need right away...
Maybe I am missing something, but once the registry is dynamic...
there does not seem to be a need to load all extension-related
descriptions at bootstrap... it seems the only one needed are
the active perspectives... For the other plugins which provide
other perspectives, they don't even need to be loaded in the
registry until the user does window->open perspective or open
view...
Hope it clarifies a bit the idea I was pursuing... to be complete,
I have my own questions about that idea... it may not save
us much... and also, I am worried about the dynamic reaction
of the workbench as new plugin manifest are parsed in the
background and the workbench is notified of new extensions...
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b58mvs$p3u$1@rogue.oti.com...
> Eclipse currently parses all discovered plugin.xml (and fragment.xml)
files
> on first startup or when it detects that there is likely a change. A
plugin
> registry is built from this information and the platform is started. At
> some point in the running of this session, this registry is dumped to a
> binary file as a cache. On subsequent starts (assuming no changes have
been
> detected) the registry is reloaded from this cache. The amount of time
> saved varies with the number and complexity of the plugins in the registry
> but for example, an order of magnitude (e.g., 6s -> 600ms) is pretty
> standard.
>
> Eclipse lazily *activates* plugins. This implies class loading not plugin
> registry entry loading. All plugins are eagerly discovered and the
registry
> populated.
>
> Side note, the cache is structured such that we can make loading even more
> lazy. Large chunks of a particular plugin's registry structure is left on
> disk on restart and loaded on demand.
>
> Hope that clears things up.
>
> Jeff
>
>
> "Kevin" <kduffey@marketron.com> wrote in message
> news:b58ci6$jo2$1@rogue.oti.com...
> > I thought Eclipse persisted plugins or something for faster startup? I
> > notice the first time I start it up after adding some projects it takes
> > longer than subsequent starts. I believe however this is due to the JVM
> > loading the first time and afterwards the OS keeps some of the JVM dll's
> > cached or something. I see this in my own apps to, where the first time
I
> > launch the app it seems to take 20+ seconds, then afterwards its like 2
> > seconds or so.
> >
> > So what you are describing is a way to log the frequency of which a
plugin
> > is used and give it a priority to be reloaded first the next time
Eclipse
> > starts. I thought Eclipse lasy loads all plugins anyway, so that no
> plugins
> > are loaded initially until a menu item or button is clicked? I am sure
> some
> > basic plugins start up, to restore project state, but I thought almost
all
> > plugins don't load or get created until requested.
> >
> > "Richard Wilson" <richard_wilson@us.ibm.com> wrote in message
> > news:b55qr1$mkr$1@rogue.oti.com...
> > > "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> > > news:b47pr7$qcp$1@rogue.oti.com...
> > > ...
> > > >
> > > > Plus, why should the bootstrap wait until the 5000 plug-ins are
parsed
> > and
> > > > described in the registry.... Couldn't we background the registering
> of
> > > most
> > > > of them? Could we reload only the set of plug-ins that were last
> > active...
> > > > assuming that plug-ins get deactivated following some
> > Least-Recently-Used
> > > > policy...
> > > >
> > > > This means that menus may not be complete, all perspectives and
views
> > > > may not be there... but the end user will see a workbench that
looked
> > > > like what he left and he can restart working right away... Of
course,
> > this
> > > > means that the plugin-activating actions need to know give a visual
> > > > feedback that not all perspectives or views are known yet...
> > > > until the background loading is finished.
> > > >
> > > When eclipse is used in cases where it is booted or restarted often, a
> > > quicker startup time would be very attractive. I like the idea of
trying
> > to
> > > speed the eclipse platform startup time by loading last-used plugins
in
> > the
> > > foreground and loading the rest in the background. This of course
> > requires
> > > dynamicity in the plugin registry and could be an especially appealing
> win
> > > when registering large plugin sets.
> > >
> > > Rick
> > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #15164 is a reply to message #14334] |
Sat, 22 March 2003 19:39 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
My guess is that the registry is built up in order to provide the "proxy"
needed to allow the UI to create plugins as needed. I am not sure about
plugins that don't add UI elements, but I am guessing that those that build
upon UI elements via their plugin.xml information is kept in memory to
quickly create the plugin classes needed?
But, I would think, if I am understanding what you are saying, is that
instead of loading up this entire registry, simply scan all plugin.xml
files, build the UI and keep a simple URL to the plugin dir, so that WHEN
the ui element is clicked on, the engine simply has a lookup to the location
of the plugin, then reparses it at the time of activation, including
resolving any dependencies at runtime?
I know in my own engine I also store a registry of plugin information. I
keep track of extension points, extensions, name/version, guid, and create
each plugins classloader and resolve all dependencies as soon as the engine
starts. The classes are all created lazily except those that need to
immediately be started. I have been working on adding "services", where by a
plugin can request a service (implemented by another plugin) at runtime and
if found the classloader stuff is handled at that moment. If not, the plugin
requesting the service needs to be coded to handle this circumstance. This
model mimics more of what OSGi does I think? However, the downside to this
approach in my opinion is the extra coding needed by plugin developers to
handle if a service they request is not available. Do they then get
unloaded? Do they continue to stay in memory? do the start a thread and try
for the service every so often? This type of model puts more emphasis on the
plugin developer being aware that services may or may not be available and
thus their dependencies on them almost have to be dynamic, where by code is
written to handle when a service is not available.
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b5hrik$tl2$1@rogue.oti.com...
> Thanks Jeff, it does clarify what Eclipse does today,
> but does not clarify what you think about backgrounded
> plug-in loading... This is just an idea, and not top priority,
> but I would keep it in mind.
>
> The original idea was that likely, when I restart Eclipse, I will
> reuse the same plugins as when I shut them down... this is actually
> why Eclipse re-creates my workbench as it was...
>
> Hence, all the other plugins don't even need to be known by the
> registry... I am likely to be able to work with Eclipse. For instance,
> if I was editing Java, I would need the Java perspective... but if I am
> using an Eclipse with dozen of tools... and thousands of plugins...
> most of them I don't need right away...
>
> Maybe I am missing something, but once the registry is dynamic...
> there does not seem to be a need to load all extension-related
> descriptions at bootstrap... it seems the only one needed are
> the active perspectives... For the other plugins which provide
> other perspectives, they don't even need to be loaded in the
> registry until the user does window->open perspective or open
> view...
>
> Hope it clarifies a bit the idea I was pursuing... to be complete,
> I have my own questions about that idea... it may not save
> us much... and also, I am worried about the dynamic reaction
> of the workbench as new plugin manifest are parsed in the
> background and the workbench is notified of new extensions...
>
> Best regards,
>
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> news:b58mvs$p3u$1@rogue.oti.com...
> > Eclipse currently parses all discovered plugin.xml (and fragment.xml)
> files
> > on first startup or when it detects that there is likely a change. A
> plugin
> > registry is built from this information and the platform is started. At
> > some point in the running of this session, this registry is dumped to a
> > binary file as a cache. On subsequent starts (assuming no changes have
> been
> > detected) the registry is reloaded from this cache. The amount of time
> > saved varies with the number and complexity of the plugins in the
registry
> > but for example, an order of magnitude (e.g., 6s -> 600ms) is pretty
> > standard.
> >
> > Eclipse lazily *activates* plugins. This implies class loading not
plugin
> > registry entry loading. All plugins are eagerly discovered and the
> registry
> > populated.
> >
> > Side note, the cache is structured such that we can make loading even
more
> > lazy. Large chunks of a particular plugin's registry structure is left
on
> > disk on restart and loaded on demand.
> >
> > Hope that clears things up.
> >
> > Jeff
> >
> >
> > "Kevin" <kduffey@marketron.com> wrote in message
> > news:b58ci6$jo2$1@rogue.oti.com...
> > > I thought Eclipse persisted plugins or something for faster startup? I
> > > notice the first time I start it up after adding some projects it
takes
> > > longer than subsequent starts. I believe however this is due to the
JVM
> > > loading the first time and afterwards the OS keeps some of the JVM
dll's
> > > cached or something. I see this in my own apps to, where the first
time
> I
> > > launch the app it seems to take 20+ seconds, then afterwards its like
2
> > > seconds or so.
> > >
> > > So what you are describing is a way to log the frequency of which a
> plugin
> > > is used and give it a priority to be reloaded first the next time
> Eclipse
> > > starts. I thought Eclipse lasy loads all plugins anyway, so that no
> > plugins
> > > are loaded initially until a menu item or button is clicked? I am sure
> > some
> > > basic plugins start up, to restore project state, but I thought almost
> all
> > > plugins don't load or get created until requested.
> > >
> > > "Richard Wilson" <richard_wilson@us.ibm.com> wrote in message
> > > news:b55qr1$mkr$1@rogue.oti.com...
> > > > "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> > > > news:b47pr7$qcp$1@rogue.oti.com...
> > > > ...
> > > > >
> > > > > Plus, why should the bootstrap wait until the 5000 plug-ins are
> parsed
> > > and
> > > > > described in the registry.... Couldn't we background the
registering
> > of
> > > > most
> > > > > of them? Could we reload only the set of plug-ins that were last
> > > active...
> > > > > assuming that plug-ins get deactivated following some
> > > Least-Recently-Used
> > > > > policy...
> > > > >
> > > > > This means that menus may not be complete, all perspectives and
> views
> > > > > may not be there... but the end user will see a workbench that
> looked
> > > > > like what he left and he can restart working right away... Of
> course,
> > > this
> > > > > means that the plugin-activating actions need to know give a
visual
> > > > > feedback that not all perspectives or views are known yet...
> > > > > until the background loading is finished.
> > > > >
> > > > When eclipse is used in cases where it is booted or restarted often,
a
> > > > quicker startup time would be very attractive. I like the idea of
> trying
> > > to
> > > > speed the eclipse platform startup time by loading last-used plugins
> in
> > > the
> > > > foreground and loading the rest in the background. This of course
> > > requires
> > > > dynamicity in the plugin registry and could be an especially
appealing
> > win
> > > > when registering large plugin sets.
> > > >
> > > > Rick
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #15265 is a reply to message #14334] |
Mon, 24 March 2003 03:40 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b5hrik$tl2$1@rogue.oti.com...
> Thanks Jeff, it does clarify what Eclipse does today,
> but does not clarify what you think about backgrounded
> plug-in loading... This is just an idea, and not top priority,
> but I would keep it in mind.
We need to be clear here what "plugin loading" means. In this context I am
talking about the creation of the plugin's entry in the registry. No
classloading, no plugin code running (that would be plugin activation). The
reason this is not done lazily in Eclipse today is because on second start
it takes almost no time anyway. The parsed registry is cached in its parsed
and resolved state after the first run. Doing this incrementally in the
background would result in many additions to the registry. Each addition
would cause the registry to be reresolved and more lifecycle events
broadcast etc etc.
> The original idea was that likely, when I restart Eclipse, I will
> reuse the same plugins as when I shut them down... this is actually
> why Eclipse re-creates my workbench as it was...
A couple of points here:
- how do you tell which plugins are "in use"? Just because it was active in
the previous session does not mean it is needed in the next. It actually
would be a very interesting outcome of Equinox to figure out how to tell
when a plugin is "in use". It would allow for the automatic deactivation of
plugins which are not in use.
- when the UI comes up it recreates the user's view of the world. This
necessarily causes various plugins to be activated. The plugin runtime does
not know about these plugins explicitly. They are implicitly activated when
the UI plugin restores its state.
- Eclipse plugin behaviour is in no way driven by the UI. there need not
even be a UI. This must be true in any model we come up with.
> Hence, all the other plugins don't even need to be known by the
> registry... I am likely to be able to work with Eclipse. For instance,
> if I was editing Java, I would need the Java perspective... but if I am
> using an Eclipse with dozen of tools... and thousands of plugins...
> most of them I don't need right away...
The cost of knowing about plugins is very low. It could be lower but on the
grand scale of things it is pretty low now. Even the cost of activating the
plugins is not all that high (though it is still uncomfortable). The
problem is that most plugins do WAY too much on activation.
> Maybe I am missing something, but once the registry is dynamic...
> there does not seem to be a need to load all extension-related
> descriptions at bootstrap... it seems the only one needed are
> the active perspectives... For the other plugins which provide
> other perspectives, they don't even need to be loaded in the
> registry until the user does window->open perspective or open
> view...
Menu entries are contributed via extensions. To tell which actions are in
which menus/perspectives, you have to look at all contributed menu
extensions and effectively sort them. Plugins could show up incrementally.
When they do, newly contributed menu entries could be added. We will likely
have to work this out for the dynamic plugin case. My concern here is the
cost of doing this for the normal startup case.
Jeff
|
|
|
| Re: Plugins as bundles (was Detailed items for dynamic plugins) [message #15364 is a reply to message #14322] |
Mon, 24 March 2003 19:42 |
 Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
Olivier Gruber wrote:
>
> "Richard S. Hall" <delete_heavy_nospam@ungoverned.org> wrote in message
> news:b4puvm$g7f$1@rogue.oti.com...
>
>
> > I don't really think this is the best approach for best performance,
> > though. I think pre-processing a bundle the first time it is installed
> > is better. Perhaps even extracting all bundle JARs and embedded JARs,
> so
> > they can be accessed directly in the file system. This would waste
> disk
> > space, but perhaps it better than wasting memory and CPU.
>
> I would totally agree here and I am quite puzzled at why do we keep
> jar files... Is it only for saving disk space ? Does any one from Eclispe
> has the answer why Eclipse does not manipulate its plugins always
> with directories of class files rather than jars... actually, this would
> simplify
> things because now plugins would have only one format (the -dev format,
> not the packaged one)... so there must be a reason...
>
I can't speak for the eclipse team, but I can say that from a
generalized point of view there are reasons to use jars during run-time
rather than extracting into discrete files. These reasons have various
importance / relevance in different circumstances, of course and all or
none may apply here.
1) Loading from jar files means opening fewer files during run-time.
This can be an issue with operating systems that have tight limits on
the number of open files or whose performance bogs down because of that.
2) Extracting, decompressing and using a file from a compressed jar file
should be faster (in general) than reading a larger amount of data from
disk in the form of an uncompressed, individual file.
3) A Jar file can be signed and the packages contained can be locked.
I'm not sure what the ramifications for locking packages are if a
package is extracted for run-time. I suppose if it is the class-loader
itself that does the unpacking, then it can enforce the package-private
strictures, but would this work across run-time boundaries if you didn't
re-archive? I suppose one could use a manifest of signatures for all
files in the distribution to detect modifications so there probably are
ways to work around this.
4) Inability to load native libraries deployed within a jar using
getResource() unless one extracts them to a separate file. This is, of
course a security precaution in a way because it demands that the code
have write access before allowing it to extract the lib to a file. If
the native lib is already extracted, then it can potentially be loaded
by using ClassLoader.getResource() and then System.load(url.getFile()).
This is a way of loading natives that are not deployed in the
system's load library path. So using jar's at runtime protects you from
this if you dissallow the code from extracting from the jar. This does
not protect you, of course, from having the code loaded from elsewhere
in the classpath so you have to control what the classpath is used for
the code in question.
There are probably other issues that are relevant here. These are just
some that jumped to mind.
Cheers,
Mel
|
|
|
Goto Forum:
Current Time: Fri Sep 20 16:40:22 GMT 2024
Powered by FUDForum. Page generated in 0.17096 seconds |
] 
Search
Help
Register
Login
Home
