Home » Eclipse Projects » Equinox » Component Model
| Component Model [message #516] |
Thu, 20 February 2003 18:06  |
Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
This posting is to start the discussion thread on the component model.
I want to start with a quick overview of the current component model
in Eclipse. I am sure I will forget things or do injustice to others.
So feel free to correct me or add precisions.
Eclipse today supports the concept of plug-ins as its component model.
Briefly, a plug-in is a Java library at the core, that is, it is a set of
Java packages and a set of resources. A plug-in may also be
contributing to the extension mechanism provided by the Eclipse plug-in
registry. It may define extension points and/or provide extensions.
Plug-ins are loaded in isolation (in their own class loader) but the
platform
allows and encourages cooperation between plug-ins. Such a cooperation
happens at two levels. One is the sharing of Java packages, the other
entails extension points. In order to inter-operate, a plug-in has to
require
other plug-ins (in its plugin.xml). Note that a "require" statement is
expressed
at a plug-in level. Therefore, that a plugin A requires a plugin B means
the following things.
- A can see all Java classes and all resources from B, respecting normal
Java
class visibility rules.
- A and B may provide classes for the same packages
- B may expose extension points that A provides extensions to.
- All extension points from B are available to A to provide extensions to.
Note that a "require" statement is specific to a plug-in.The dependency is
not
on needed Java packages or resources, irrespectively of which plug-in
provides
them; the dependency is on a specific plug-in. The same holds true for
extension
points, the dependency is on a specific provider of an extension point.
I believe the extension point mechanism goes even a step further, relating
the plug-in Id with the extension point Id. In other words, a given
extension
points is provided by one plug-in, and that plug-in only. Therefore, a
plugin B
cannot provide extension points defined in another plug-in A.
Eclipse made also an interesting decision in allowing local classes to
override
shared classes. In other words, a plug-in may override classes from other
required plug-ins by having a class with the same name on its local class
path.
I heard that this introduces a security hole, but I am no security expert.
Anybody has knowledge on this, please step forward.
Plug-ins are versioned, and therefore dependencies are expressed on versions
of plug-ins. Eclipse versions do not have to maintain backward compatibility
across
major releases. Hence, Eclipse has adopted a versioning that is in
contradiction with the
Java versioning specification
[ http://java.sun.com/j2se/1.4/docs/guide/versioning/index.htm l]
Version identifier for a plug-in. In its string representation, it consists
of up to 4 tokens
separated by a decimal point. The first 3 tokens are positive integer
numbers, the last token
is an uninterpreted string (no whitespace characters allowed). For example,
the following
are valid version identifiers (as strings):
0.0.0
1.0.127564
3.7.2.build-127J
1.9 which is interpreted as 1.9.0
3 which is interpreted as 3.0.0
The version identifier can be decomposed into a major, minor, service level
component and
qualifier components. A difference in the major component is interpreted as
an incompatible
version change. A difference in the minor (and not the major) component is
interpreted as a
compatible version change. The service level component is interpreted as a
cumulative and
compatible service update of the minor version component. The qualifier is
not interpreted,
other than in version comparisons. The qualifiers are compared using
lexicographical string
comparison.
In order to try to satisfy potentially conflicting dependencies on different
plug-in versions,
the Eclipse platform loads plug-ins in different ways depending on if they
expose either
extensions or extension points. In Eclipse parlance, a plug-in that neither
defines extensions
nor extension points is called a library. The platform may load multiple
versions of a library
in order to satisfy conflicting dependencies. For instance, if two plug-ins
need to different
major versions of the XERCES parser, the two versions will be loaded in the
JVM if
they are available.
The limitations to this approach are imposed by the Java class loader
limitations. For
well behaved libraries, not manipulating shared resources, it will work just
fine in most
cases. For other libraries, the position may be more difficult to defend.
For instance,
SWT or JFace are also libraries, but it makes much less sense to have
plug-ins bound
to different SWT or JFace versions, their integration in the workbench maybe
a little
difficult.
So that's it, folks, for the short overview/analysis of Eclipse platform,
from a component
model perspective. Please, feel free to correct potential mistakes and
provide precisions;
I am quite sure I made some. Stay tuned for other postings about how I see
Equinox
evolving from Eclipse.
Best regards,
Olivier.
|
|
|
| Re: Component Model [message #531 is a reply to message #516] |
Thu, 20 February 2003 20:32  |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
I will be the first one to answer my own posting... :-)
With another rather long posting about how I see Equinox evolve from
Eclipse.
I believe the two essential problems are a lack of encapsulation and a lack
of
independence between published API and implementations. I certainly
understand
that it helped achieve parallel developments across teams, allowing to make
quicker progress in the early stages of Eclipse. But as a more mature
platform,
these are two serious flaws. Additionally, I would argue that Eclipse is
missing a
service framework, not to replace the extension-point mechanism, but to
advantageously complement it. Concretely, I would like to see the following:
- Separate concerns between Java library and plug-ins
- Introduce encapsulation at the library level
- Move dependencies on API, not implementations
- Introduce a service framework
Let me detail these...
First separation of concerns and encapsulation. I would propose
that we see plug-ins as extensions of libraries, which are basically
Java software components.
A Java software component is a set of Java packages and resources.
A component is encapsulated. It is sand-boxed in its own class
loader. It exports only specific Java packages, which become visible
in a global name space, shared by all components. Its other packages
are private and are not visible to other components. A component may
also import Java packages. The imported packages are specified by
names and not by a potential provider:
import:
org.eclipse.core.xxx; version = 1.2
org.eclipse.core.yyy; version = 2.1
export:
org.eclipse.runtime.zzz; version = 1.3
The runtime can then match imports and exports at loading time,
following the Java philosophy to dynamic loading. The same package
version may be exported by different components, only one
will be visible in the shared name space. Only one component
can contribute classes to an exported package.
The big question is regarding multiple versions of the same component.
Do we allow multiple loading of different versions or not. I personally
don't like it... it is too error-prone... too easy to write components
that just won't work if loaded multiple times. Moreover, I am not sure
it is the right way to go. I would argue that the most recent version
should be loaded and if some other components need back-level
versions, these components need be updated, hoping their new
versions will have more up-to-date dependencies.
Please jump in on this and argue my point....
A plug-in becomes an extended Java component, contributing
extensions and extension points to the plug-in registry. The
plugin.xml is therefore solely concerned about extensions
and extension points, the component manifest superseeds
the previous "require" and "runtime" tags from the plugin.xml.
The plugin.xml expresses dependencies on extension points
and not plug-ins.
This means that the name space for extension ids and
extension-point ids should be disjoint than the name space
for plug-in ids. All ids would follow the same naming
convention as Java packages. By default, the ids of
extensions and extension points may extend their plugin id,
but it is not mandatory, thereby bringing the independence
we are looking for.
Aside extensions and extension points, I propose that we
support a service framework. The service framework
comes to complement the plug-in environment, not to replace
it.
A typical service framework provides a registry where to register
services. A service is typically defined in terms of interfaces. A service
is typically provided by an object, whose class implements those
interfaces. Also, the registry usually offers a name space to name
services, potentially services have attributes so that a query language
can be supported. Additionally, a service framework usually provides
a full-fledge framework for life-cycle events of services.
That's it folks...
I will provide a quick description of OSGi (www.osgi.org) in
another posting. OSGi is the closest open standard, I am aware
of, to what I just described, but not quite the same because some
fundamental assumptions are different. But this will be the subject
of another posting...
Best regards,
Olivier.
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b333mf$67g$1@rogue.oti.com...
> This posting is to start the discussion thread on the component model.
> I want to start with a quick overview of the current component model
> in Eclipse. I am sure I will forget things or do injustice to others.
> So feel free to correct me or add precisions.
>
> Eclipse today supports the concept of plug-ins as its component model.
> Briefly, a plug-in is a Java library at the core, that is, it is a set of
> Java packages and a set of resources. A plug-in may also be
> contributing to the extension mechanism provided by the Eclipse plug-in
> registry. It may define extension points and/or provide extensions.
>
> Plug-ins are loaded in isolation (in their own class loader) but the
> platform
> allows and encourages cooperation between plug-ins. Such a cooperation
> happens at two levels. One is the sharing of Java packages, the other
> entails extension points. In order to inter-operate, a plug-in has to
> require
> other plug-ins (in its plugin.xml). Note that a "require" statement is
> expressed
> at a plug-in level. Therefore, that a plugin A requires a plugin B means
> the following things.
>
> - A can see all Java classes and all resources from B, respecting normal
> Java
> class visibility rules.
> - A and B may provide classes for the same packages
> - B may expose extension points that A provides extensions to.
> - All extension points from B are available to A to provide extensions
to.
>
> Note that a "require" statement is specific to a plug-in.The dependency is
> not
> on needed Java packages or resources, irrespectively of which plug-in
> provides
> them; the dependency is on a specific plug-in. The same holds true for
> extension
> points, the dependency is on a specific provider of an extension point.
>
> I believe the extension point mechanism goes even a step further, relating
> the plug-in Id with the extension point Id. In other words, a given
> extension
> points is provided by one plug-in, and that plug-in only. Therefore, a
> plugin B
> cannot provide extension points defined in another plug-in A.
>
> Eclipse made also an interesting decision in allowing local classes to
> override
> shared classes. In other words, a plug-in may override classes from other
> required plug-ins by having a class with the same name on its local class
> path.
> I heard that this introduces a security hole, but I am no security expert.
> Anybody has knowledge on this, please step forward.
>
> Plug-ins are versioned, and therefore dependencies are expressed on
versions
> of plug-ins. Eclipse versions do not have to maintain backward
compatibility
> across
> major releases. Hence, Eclipse has adopted a versioning that is in
> contradiction with the
> Java versioning specification
> [ http://java.sun.com/j2se/1.4/docs/guide/versioning/index.htm l]
>
> Version identifier for a plug-in. In its string representation, it
consists
> of up to 4 tokens
> separated by a decimal point. The first 3 tokens are positive integer
> numbers, the last token
> is an uninterpreted string (no whitespace characters allowed). For
example,
> the following
> are valid version identifiers (as strings):
>
> 0.0.0
> 1.0.127564
> 3.7.2.build-127J
> 1.9 which is interpreted as 1.9.0
> 3 which is interpreted as 3.0.0
>
> The version identifier can be decomposed into a major, minor, service
level
> component and
> qualifier components. A difference in the major component is interpreted
as
> an incompatible
> version change. A difference in the minor (and not the major) component is
> interpreted as a
> compatible version change. The service level component is interpreted as a
> cumulative and
> compatible service update of the minor version component. The qualifier is
> not interpreted,
> other than in version comparisons. The qualifiers are compared using
> lexicographical string
> comparison.
>
> In order to try to satisfy potentially conflicting dependencies on
different
> plug-in versions,
> the Eclipse platform loads plug-ins in different ways depending on if they
> expose either
> extensions or extension points. In Eclipse parlance, a plug-in that
neither
> defines extensions
> nor extension points is called a library. The platform may load multiple
> versions of a library
> in order to satisfy conflicting dependencies. For instance, if two
plug-ins
> need to different
> major versions of the XERCES parser, the two versions will be loaded in
the
> JVM if
> they are available.
>
> The limitations to this approach are imposed by the Java class loader
> limitations. For
> well behaved libraries, not manipulating shared resources, it will work
just
> fine in most
> cases. For other libraries, the position may be more difficult to defend.
> For instance,
> SWT or JFace are also libraries, but it makes much less sense to have
> plug-ins bound
> to different SWT or JFace versions, their integration in the workbench
maybe
> a little
> difficult.
>
> So that's it, folks, for the short overview/analysis of Eclipse platform,
> from a component
> model perspective. Please, feel free to correct potential mistakes and
> provide precisions;
> I am quite sure I made some. Stay tuned for other postings about how I see
> Equinox
> evolving from Eclipse.
>
> Best regards,
> Olivier.
>
>
>
>
>
>
>
>
>
>
>
|
|
| |
| Re: Component Model [message #555 is a reply to message #516] |
Thu, 20 February 2003 21:05 |
 Pascal Rapicault
Messages: 333
Registered: July 2009
Location: Ottawa |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0018_01C2D8F9.F3F12A40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,=20
Just to correct one thing:
The plugins A do NOT see all the classes of plugin B.
It exists a notion of export associated to a library which filters
the packages that the library want to make visible.
A typical use of that is to prevent people from using non API classes.
Here is a example in GEF.
<library name=3D"runtime/gef.jar">
<export name=3D"org.eclipse.gef.*" />=20
... .....
</library>
PaScaL
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message =
news:b333mf$67g$1@rogue.oti.com...
> This posting is to start the discussion thread on the component model.
> I want to start with a quick overview of the current component model
> in Eclipse. I am sure I will forget things or do injustice to others.
> So feel free to correct me or add precisions.
>=20
> Eclipse today supports the concept of plug-ins as its component model.
> Briefly, a plug-in is a Java library at the core, that is, it is a set =
of
> Java packages and a set of resources. A plug-in may also be
> contributing to the extension mechanism provided by the Eclipse =
plug-in
> registry. It may define extension points and/or provide extensions.
>=20
> Plug-ins are loaded in isolation (in their own class loader) but the
> platform
> allows and encourages cooperation between plug-ins. Such a cooperation
> happens at two levels. One is the sharing of Java packages, the other
> entails extension points. In order to inter-operate, a plug-in has to
> require
> other plug-ins (in its plugin.xml). Note that a "require" statement is
> expressed
> at a plug-in level. Therefore, that a plugin A requires a plugin B =
means
> the following things.
>=20
> - A can see all Java classes and all resources from B, respecting =
normal
> Java
> class visibility rules.
> - A and B may provide classes for the same packages
> - B may expose extension points that A provides extensions to.
> - All extension points from B are available to A to provide =
extensions to.
>=20
> Note that a "require" statement is specific to a plug-in.The =
dependency is
> not
> on needed Java packages or resources, irrespectively of which plug-in
> provides
> them; the dependency is on a specific plug-in. The same holds true for
> extension
> points, the dependency is on a specific provider of an extension =
point.
>=20
> I believe the extension point mechanism goes even a step further, =
relating
> the plug-in Id with the extension point Id. In other words, a given
> extension
> points is provided by one plug-in, and that plug-in only. Therefore, a
> plugin B
> cannot provide extension points defined in another plug-in A.
>=20
> Eclipse made also an interesting decision in allowing local classes to
> override
> shared classes. In other words, a plug-in may override classes from =
other
> required plug-ins by having a class with the same name on its local =
class
> path.
> I heard that this introduces a security hole, but I am no security =
expert.
> Anybody has knowledge on this, please step forward.
>=20
> Plug-ins are versioned, and therefore dependencies are expressed on =
versions
> of plug-ins. Eclipse versions do not have to maintain backward =
compatibility
> across
> major releases. Hence, Eclipse has adopted a versioning that is in
> contradiction with the
> Java versioning specification
> [ http://java.sun.com/j2se/1.4/docs/guide/versioning/index.htm l]
>=20
> Version identifier for a plug-in. In its string representation, it =
consists
> of up to 4 tokens
> separated by a decimal point. The first 3 tokens are positive integer
> numbers, the last token
> is an uninterpreted string (no whitespace characters allowed). For =
example,
> the following
> are valid version identifiers (as strings):
>=20
> 0.0.0
> 1.0.127564
> 3.7.2.build-127J
> 1.9 which is interpreted as 1.9.0
> 3 which is interpreted as 3.0.0
>=20
> The version identifier can be decomposed into a major, minor, service =
level
> component and
> qualifier components. A difference in the major component is =
interpreted as
> an incompatible
> version change. A difference in the minor (and not the major) =
component is
> interpreted as a
> compatible version change. The service level component is interpreted =
as a
> cumulative and
> compatible service update of the minor version component. The =
qualifier is
> not interpreted,
> other than in version comparisons. The qualifiers are compared using
> lexicographical string
> comparison.
>=20
> In order to try to satisfy potentially conflicting dependencies on =
different
> plug-in versions,
> the Eclipse platform loads plug-ins in different ways depending on if =
they
> expose either
> extensions or extension points. In Eclipse parlance, a plug-in that =
neither
> defines extensions
> nor extension points is called a library. The platform may load =
multiple
> versions of a library
> in order to satisfy conflicting dependencies. For instance, if two =
plug-ins
> need to different
> major versions of the XERCES parser, the two versions will be loaded =
in the
> JVM if
> they are available.
>=20
> The limitations to this approach are imposed by the Java class loader
> limitations. For
> well behaved libraries, not manipulating shared resources, it will =
work just
> fine in most
> cases. For other libraries, the position may be more difficult to =
defend.
> For instance,
> SWT or JFace are also libraries, but it makes much less sense to have
> plug-ins bound
> to different SWT or JFace versions, their integration in the workbench =
maybe
> a little
> difficult.
>=20
> So that's it, folks, for the short overview/analysis of Eclipse =
platform,
> from a component
> model perspective. Please, feel free to correct potential mistakes and
> provide precisions;
> I am quite sure I made some. Stay tuned for other postings about how I =
see
> Equinox
> evolving from Eclipse.
>=20
> Best regards,
> Olivier.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>
------=_NextPart_000_0018_01C2D8F9.F3F12A40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>
<DIV><FONT face=3DArial size=3D2>Hello, </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Just to correct one thing:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The plugins A do NOT see all the =
classes of plugin=20
B.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It exists a notion of export =
associated to a=20
library which filters</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the packages that the library want to =
make=20
visible.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>A typical use of that is to prevent =
people from=20
using non API classes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Here is a example in GEF.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV class=3De>
<DIV class=3Dc style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT =
face=3DArial><FONT=20
size=3D2> <SPAN class=3Dm><</SPAN><SPAN=20
class=3Dt>library</SPAN><SPAN class=3Dt> name</SPAN><SPAN=20
class=3Dm>=3D"</SPAN>runtime/gef.jar<SPAN class=3Dm>"</SPAN><SPAN=20
class=3Dm>></SPAN></FONT></FONT></DIV>
<DIV>
<DIV class=3De>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3Db> =
</SPAN> <SPAN=20
class=3Dm><</SPAN><SPAN class=3Dt>export</SPAN> <SPAN =
class=3Dt>name</SPAN><SPAN=20
class=3Dm>=3D"</SPAN>org.eclipse.gef.*<SPAN class=3Dm>"</SPAN><SPAN =
class=3Dm>=20
/></SPAN> </FONT></FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT face=3DArial=20
size=3D2> .. &nbs p; ..... </FONT></=
DIV></DIV>
<DIV class=3De>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3Db> </SPAN><SPAN=20
class=3Dm></</SPAN><SPAN class=3Dt>library</SPAN><SPAN=20
class=3Dm>></SPAN></FONT></FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN class=3Dm><FONT =
face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN class=3Dm><FONT =
face=3DArial=20
size=3D2> =20
PaScaL</FONT></SPAN></DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN class=3Dm><FONT =
face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN=20
class=3Dm></SPAN> </DIV></DIV></DIV></DIV></DIV ></DIV>
<DIV><FONT face=3DArial size=3D2>"Olivier Gruber" <</FONT><A=20
href=3D"mailto:ogruber@us.ibm.com"><FONT face=3DArial=20
size=3D2>ogruber@us.ibm.com</FONT></A><FONT face=3DArial size=3D2>> =
wrote in=20
message </FONT><A href=3D"news:b333mf$67g$1@rogue.oti.com"><FONT =
face=3DArial=20
size=3D2>news:b333mf$67g$1@rogue.oti.com</FONT></A><FONT face=3DArial=20
size=3D2>...</FONT></DIV><FONT face=3DArial size=3D2>> This posting =
is to start the=20
discussion thread on the component model.<BR>> I want to start with a =
quick=20
overview of the current component model<BR>> in Eclipse. I am sure I =
will=20
forget things or do injustice to others.<BR>> So feel free to correct =
me or=20
add precisions.<BR>> <BR>> Eclipse today supports the concept of =
plug-ins=20
as its component model.<BR>> Briefly, a plug-in is a Java library at =
the=20
core, that is, it is a set of<BR>> Java packages and a set of =
resources. A=20
plug-in may also be<BR>> contributing to the extension mechanism =
provided by=20
the Eclipse plug-in<BR>> registry. It may define extension points =
and/or=20
provide extensions.<BR>> <BR>> Plug-ins are loaded in isolation =
(in their=20
own class loader) but the<BR>> platform<BR>> allows and encourages =
cooperation between plug-ins. Such a cooperation<BR>> happens at two =
levels.=20
One is the sharing of Java packages, the other<BR>> entails extension =
points.=20
In order to inter-operate, a plug-in has to<BR>> require<BR>> =
other=20
plug-ins (in its plugin.xml). Note that a "require" statement is<BR>> =
expressed<BR>> at a plug-in level. Therefore, that a plugin A =
requires a=20
plugin B means<BR>> the following things.<BR>> <BR>> - A =
can see=20
all Java classes and all resources from B, respecting normal<BR>>=20
Java<BR>> class visibility rules.<BR>> - A and =
B may=20
provide classes for the same packages<BR>> - B may expose =
extension=20
points that A provides extensions to.<BR>> - All extension =
points from=20
B are available to A to provide extensions to.<BR>> <BR>> Note =
that a=20
"require" statement is specific to a plug-in.The dependency is<BR>>=20
not<BR>> on needed Java packages or resources, irrespectively of =
which=20
plug-in<BR>> provides<BR>> them; the dependency is on a specific =
plug-in.=20
The same holds true for<BR>> extension<BR>> points, the dependency =
is on a=20
specific provider of an extension point.<BR>> <BR>> I believe the=20
extension point mechanism goes even a step further, relating<BR>> the =
plug-in=20
Id with the extension point Id. In other words, a given<BR>>=20
extension<BR>> points is provided by one plug-in, and that plug-in =
only.=20
Therefore, a<BR>> plugin B<BR>> cannot provide extension points =
defined in=20
another plug-in A.<BR>> <BR>> Eclipse made also an interesting =
decision in=20
allowing local classes to<BR>> override<BR>> shared classes. In =
other=20
words, a plug-in may override classes from other<BR>> required =
plug-ins by=20
having a class with the same name on its local class<BR>> =
path.<BR>> I=20
heard that this introduces a security hole, but I am no security =
expert.<BR>>=20
Anybody has knowledge on this, please step forward.<BR>> <BR>> =
Plug-ins=20
are versioned, and therefore dependencies are expressed on =
versions<BR>> of=20
plug-ins. Eclipse versions do not have to maintain backward=20
compatibility<BR>> across<BR>> major releases. Hence, Eclipse has =
adopted=20
a versioning that is in<BR>> contradiction with the<BR>> Java =
versioning=20
specification<BR>>=20
[ http://java.sun.com/j2se/1.4/docs/guide/versioning/index.htm l]<BR>> =
<BR>>=20
Version identifier for a plug-in. In its string representation, it=20
consists<BR>> of up to 4 tokens<BR>> separated by a decimal point. =
The=20
first 3 tokens are positive integer<BR>> numbers, the last =
token<BR>> is=20
an uninterpreted string (no whitespace characters allowed). For =
example,<BR>>=20
the following<BR>> are valid version identifiers (as =
strings):<BR>>=20
<BR>> 0.0.0<BR>>=20
1.0.127564<BR>>=20
3.7.2.build-127J<BR>>=20
1.9 which is interpreted as=20
1.9.0<BR>> 3 which is =
interpreted=20
as 3.0.0<BR>> <BR>> The version identifier can be decomposed into =
a major,=20
minor, service level<BR>> component and<BR>> qualifier components. =
A=20
difference in the major component is interpreted as<BR>> an=20
incompatible<BR>> version change. A difference in the minor (and not =
the=20
major) component is<BR>> interpreted as a<BR>> compatible version =
change.=20
The service level component is interpreted as a<BR>> cumulative =
and<BR>>=20
compatible service update of the minor version component. The qualifier=20
is<BR>> not interpreted,<BR>> other than in version comparisons. =
The=20
qualifiers are compared using<BR>> lexicographical string<BR>>=20
comparison.<BR>> <BR>> In order to try to satisfy potentially =
conflicting=20
dependencies on different<BR>> plug-in versions,<BR>> the Eclipse =
platform=20
loads plug-ins in different ways depending on if they<BR>> expose=20
either<BR>> extensions or extension points. In Eclipse parlance, a =
plug-in=20
that neither<BR>> defines extensions<BR>> nor extension points is =
called a=20
library. The platform may load multiple<BR>> versions of a =
library<BR>> in=20
order to satisfy conflicting dependencies. For instance, if two =
plug-ins<BR>>=20
need to different<BR>> major versions of the XERCES parser, the two =
versions=20
will be loaded in the<BR>> JVM if<BR>> they are available.<BR>> =
<BR>> The limitations to this approach are imposed by the Java class=20
loader<BR>> limitations. For<BR>> well behaved libraries, not =
manipulating=20
shared resources, it will work just<BR>> fine in most<BR>> cases. =
For=20
other libraries, the position may be more difficult to defend.<BR>> =
For=20
instance,<BR>> SWT or JFace are also libraries, but it makes much =
less sense=20
to have<BR>> plug-ins bound<BR>> to different SWT or JFace =
versions, their=20
integration in the workbench maybe<BR>> a little<BR>> =
difficult.<BR>>=20
<BR>> So that's it, folks, for the short overview/analysis of Eclipse =
platform,<BR>> from a component<BR>> model perspective. Please, =
feel free=20
to correct potential mistakes and<BR>> provide precisions;<BR>> I =
am quite=20
sure I made some. Stay tuned for other postings about how I see<BR>>=20
Equinox<BR>> evolving from Eclipse.<BR>> <BR>> Best =
regards,<BR>>=20
Olivier.<BR>> <BR>> <BR>> <BR>> <BR>> <BR>> <BR>> =
<BR>>=20
<BR>> <BR>> <BR>> </FONT></BODY></HTML>
------=_NextPart_000_0018_01C2D8F9.F3F12A40--
|
|
| | |
| Re: Component Model [message #597 is a reply to message #516] |
Thu, 20 February 2003 22:59 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Another angle on the component model... the architecture angle.
Today, Eclipse is fairly monolithic. Everything is a plug-in and therefore
everything is loaded by the plug-in registry, even though they don't
provide extensions or extension points. As discussed in earlier
postings, they are quite many plug-ins which are just libraries.
This would suggest by itself a two-layer approach. The first one would
be a Java platform that would manage libraries, that is, Java software
components. The second one, build upon the first layer, would extend
that platform with a plug-in container.
More precisely, I believe the right approach would be to have a
self-hosting Java platform for network-deployed Java software
components (libraries in Eclipse parlance). I will call this platform
the Java foundation. Then, above the Java foundation, we would
provide a plug-in container as well as a web application container.
Indeed, Eclipse embeds an instance of Tomcat...
This Java foundation, which still knows nothing about plug-ins, would be
self-hosting, as is Eclipse today. It is a platform that can bootstrap and
load components. Components are network-deployed from web sites
where they have been published from the tooling. This means the update
manager moves down to work at the foundation level. The tooling is either
a modified JDT or PDE with first-class understanding of Java components.
The foundation takes care of the deployment and loading of components,
as well as matching imports with exports of Java packages. Services
complement components, making this platform a very attractive one.
It allows to develop, publish, and deploy Java software components,
without requiring the full Eclipse. This is very interesting to wrap
and deploy technologies from Eclipse or Apache such as Xerces, Ant,
SWT, or JFace. It is also very interesting to develop new components
from scratch and deploy them through the web.
This foundation is very very close to what an OSGi platform is
(www.osgi.org).
If the differences between Eclipse and OSGi assumptions could be resolved,
Eclipse could basically leverage an open standard as its foundation,
focusing on the plug-in model. In particular, it is interesting to know that
OSGi
is advocating to host a web application server... one more common point.
But we haven't talked about OSGi yet, so let's not assume it will be OSGi.
So above the Java foundation for network-deployed software components,
two containers will be provided: one for plug-ins and the other for web
applications. The first thing to notice is that these containers are
themsleves
developed using Java components. They are network deployed, incrementally.
Because the update manager is at the level of the Java platform, the
plug-in container and the web container can be easily updated as any
other component in the system.
This is a more robust approach with respect to local administration.
Today, one mis-behaving plug-in can lock the entire Eclipse platform.
Since there is not other layer, once the plug-in platform is locked, the
entire system is locked. In this case, an admin API can be provided
that relies only on a few core components. The admin API would allow
to stop, restart, or even unload plug-ins or components. That API could
provide a SWT-based interface or even a web-based interface for
remote access. There are very small footprint web servers that are good
enough to support a recovery-mode administration interface.
This approach is also more robust to updating and installing new components
or new plug-ins. Today, because everything is a plug-in, and because the
update manager is dependent on the rest of Eclipse (both the plug-in
registry
and the workbench), it would be fairly easy to get Eclipse in a state were
it cannot
be restarted when considering a lot of dynamic updates. If that happens, the
configuration cannot be repaired since the update manager can only run
if Eclipse run. In the approach I just described, the Java foundation is
minimal and the update manager may have a recovery mode where its
interface relies only on SWT only or a wed-based interface. This can be
faked
on the current Eclipse, but I believe it is just cleaner to have a two-layer
approach, the foundation with containers above (plug-ins and web).
Each container will work hand in hand with the underlying foundation
and its update manager. Both plug-ins and web applications will be
downloaded
from the network by the update manager as components. Indeed, both
plug-ins or web applications are Java components, that is, jar files with
class files and resources. Both have extra metadata describing the plug-in
specifics or the web application specifics. The foundation deploys the
components and loads them. Once loaded, these components can easily
look for their respective container (through the service framework) and
register
themselves.
It is important to point out that this does not imply that all the
components have
to be loaded in the JVM. This is a rather common misconception. It is easy
to have system-level activator classes, which are responsible to register
the plug-in or the web application, without provoking any further loading
of classes from the component. In reality, the only thing that is necessary
is
a class loader that will provide access to the plugin.xml or the web.xml
resources. I have implemented this, and it does no more class loading
than the current static loading of plugin.xml files done by the Eclipse
bootstrap.
To summarize, we have a good opportunity to break the monolithic approach
of the Eclipse design and architecture. There is great value in separating
the libraries from the plug-ins. We have the opportunity to provide a
self-hosting
Java foundation for network-deployed Java software components. That
foundation could be used for developing, publishing, and deploying Java
components, without requiring the full Eclipse. Eclipse design and
architecture
becomes more modular and easier. It offers a more robust approach to
updating the system. It balances things out between plug-ins and web
applications, making it easy to deployment web applications to the
embedded web application server in Eclipse.
Least but certainly not last, it opens the way to adopt an open standard
rather than reinventing the wheel. If the differences between OSGi and
Eclipse could be resolved, Eclipse could leverage an existing and growing
open standard for network-deployed components. Even in the unlikely
situation where the differences cannot be resolved, it is still a more
modular,
robust, and attractive architecture than the current Eclipse one.
That's it folks, best regards.
Olivier.
|
|
|
| Re: Component Model [message #614 is a reply to message #555] |
Thu, 20 February 2003 23:10 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
This is a multi-part message in MIME format.
------=_NextPart_000_0078_01C2D90B.5F8CB600
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Oops, thanks !
Does that also works in fragments ?
Olivier.
"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message =
news:b33eb4$f0m$1@rogue.oti.com...
Hello,=20
Just to correct one thing:
The plugins A do NOT see all the classes of plugin B.
It exists a notion of export associated to a library which filters
the packages that the library want to make visible.
A typical use of that is to prevent people from using non API classes.
Here is a example in GEF.
<library name=3D"runtime/gef.jar">
<export name=3D"org.eclipse.gef.*" />=20
.. .....
</library>
PaScaL
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message =
news:b333mf$67g$1@rogue.oti.com...
> This posting is to start the discussion thread on the component =
model.
> I want to start with a quick overview of the current component model
> in Eclipse. I am sure I will forget things or do injustice to =
others.
> So feel free to correct me or add precisions.
>=20
> Eclipse today supports the concept of plug-ins as its component =
model.
> Briefly, a plug-in is a Java library at the core, that is, it is a =
set of
> Java packages and a set of resources. A plug-in may also be
> contributing to the extension mechanism provided by the Eclipse =
plug-in
> registry. It may define extension points and/or provide extensions.
>=20
> Plug-ins are loaded in isolation (in their own class loader) but the
> platform
> allows and encourages cooperation between plug-ins. Such a =
cooperation
> happens at two levels. One is the sharing of Java packages, the =
other
> entails extension points. In order to inter-operate, a plug-in has =
to
> require
> other plug-ins (in its plugin.xml). Note that a "require" statement =
is
> expressed
> at a plug-in level. Therefore, that a plugin A requires a plugin B =
means
> the following things.
>=20
> - A can see all Java classes and all resources from B, respecting =
normal
> Java
> class visibility rules.
> - A and B may provide classes for the same packages
> - B may expose extension points that A provides extensions to.
> - All extension points from B are available to A to provide =
extensions to.
>=20
> Note that a "require" statement is specific to a plug-in.The =
dependency is
> not
> on needed Java packages or resources, irrespectively of which =
plug-in
> provides
> them; the dependency is on a specific plug-in. The same holds true =
for
> extension
> points, the dependency is on a specific provider of an extension =
point.
>=20
> I believe the extension point mechanism goes even a step further, =
relating
> the plug-in Id with the extension point Id. In other words, a given
> extension
> points is provided by one plug-in, and that plug-in only. Therefore, =
a
> plugin B
> cannot provide extension points defined in another plug-in A.
>=20
> Eclipse made also an interesting decision in allowing local classes =
to
> override
> shared classes. In other words, a plug-in may override classes from =
other
> required plug-ins by having a class with the same name on its local =
class
> path.
> I heard that this introduces a security hole, but I am no security =
expert.
> Anybody has knowledge on this, please step forward.
>=20
> Plug-ins are versioned, and therefore dependencies are expressed on =
versions
> of plug-ins. Eclipse versions do not have to maintain backward =
compatibility
> across
> major releases. Hence, Eclipse has adopted a versioning that is in
> contradiction with the
> Java versioning specification
> [ http://java.sun.com/j2se/1.4/docs/guide/versioning/index.htm l]
>=20
> Version identifier for a plug-in. In its string representation, it =
consists
> of up to 4 tokens
> separated by a decimal point. The first 3 tokens are positive =
integer
> numbers, the last token
> is an uninterpreted string (no whitespace characters allowed). For =
example,
> the following
> are valid version identifiers (as strings):
>=20
> 0.0.0
> 1.0.127564
> 3.7.2.build-127J
> 1.9 which is interpreted as 1.9.0
> 3 which is interpreted as 3.0.0
>=20
> The version identifier can be decomposed into a major, minor, =
service level
> component and
> qualifier components. A difference in the major component is =
interpreted as
> an incompatible
> version change. A difference in the minor (and not the major) =
component is
> interpreted as a
> compatible version change. The service level component is =
interpreted as a
> cumulative and
> compatible service update of the minor version component. The =
qualifier is
> not interpreted,
> other than in version comparisons. The qualifiers are compared using
> lexicographical string
> comparison.
>=20
> In order to try to satisfy potentially conflicting dependencies on =
different
> plug-in versions,
> the Eclipse platform loads plug-ins in different ways depending on =
if they
> expose either
> extensions or extension points. In Eclipse parlance, a plug-in that =
neither
> defines extensions
> nor extension points is called a library. The platform may load =
multiple
> versions of a library
> in order to satisfy conflicting dependencies. For instance, if two =
plug-ins
> need to different
> major versions of the XERCES parser, the two versions will be loaded =
in the
> JVM if
> they are available.
>=20
> The limitations to this approach are imposed by the Java class =
loader
> limitations. For
> well behaved libraries, not manipulating shared resources, it will =
work just
> fine in most
> cases. For other libraries, the position may be more difficult to =
defend.
> For instance,
> SWT or JFace are also libraries, but it makes much less sense to =
have
> plug-ins bound
> to different SWT or JFace versions, their integration in the =
workbench maybe
> a little
> difficult.
>=20
> So that's it, folks, for the short overview/analysis of Eclipse =
platform,
> from a component
> model perspective. Please, feel free to correct potential mistakes =
and
> provide precisions;
> I am quite sure I made some. Stay tuned for other postings about how =
I see
> Equinox
> evolving from Eclipse.
>=20
> Best regards,
> Olivier.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
------=_NextPart_000_0078_01C2D90B.5F8CB600
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Oops, thanks !</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Does that also works in fragments =
?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Olivier.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Pascal Rapicault" <<A=20
=
href=3D"mailto:pascal_rapicault@ca.ibm.com">pascal_rapicault@ca.ibm.com</=
A>>=20
wrote in message <A=20
=
href=3D"news:b33eb4$f0m$1@rogue.oti.com">news:b33eb4$f0m$1@rogue.oti.com<=
/A>...</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>Hello, </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Just to correct one =
thing:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The plugins A do NOT see all the =
classes of=20
plugin B.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It exists a notion of export =
associated to a=20
library which filters</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the packages that the library want to =
make=20
visible.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>A typical use of that is to prevent =
people from=20
using non API classes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Here is a example in =
GEF.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV class=3De>
<DIV class=3Dc style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT=20
face=3DArial><FONT size=3D2> <SPAN=20
class=3Dm><</SPAN><SPAN class=3Dt>library</SPAN><SPAN class=3Dt> =
name</SPAN><SPAN=20
class=3Dm>=3D"</SPAN>runtime/gef.jar<SPAN class=3Dm>"</SPAN><SPAN=20
class=3Dm>></SPAN></FONT></FONT></DIV>
<DIV>
<DIV class=3De>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3Db> =
</SPAN> <SPAN=20
class=3Dm><</SPAN><SPAN class=3Dt>export</SPAN> <SPAN =
class=3Dt>name</SPAN><SPAN=20
class=3Dm>=3D"</SPAN>org.eclipse.gef.*<SPAN class=3Dm>"</SPAN><SPAN =
class=3Dm>=20
/></SPAN> </FONT></FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT face=3DArial=20
=
size=3D2> .. &nbs p; ..... </FONT></=
DIV></DIV>
<DIV class=3De>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3Db> </SPAN><SPAN=20
class=3Dm></</SPAN><SPAN class=3Dt>library</SPAN><SPAN=20
class=3Dm>></SPAN></FONT></FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN =
class=3Dm><FONT=20
face=3DArial size=3D2></FONT></SPAN> </DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN =
class=3Dm><FONT=20
face=3DArial size=3D2> =
=20
PaScaL</FONT></SPAN></DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN =
class=3Dm><FONT=20
face=3DArial size=3D2></FONT></SPAN> </DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN=20
class=3Dm></SPAN> </DIV></DIV></DIV></DIV></DIV ></DIV>
<DIV><FONT face=3DArial size=3D2>"Olivier Gruber" <</FONT><A=20
href=3D"mailto:ogruber@us.ibm.com"><FONT face=3DArial=20
size=3D2>ogruber@us.ibm.com</FONT></A><FONT face=3DArial size=3D2>> =
wrote in=20
message </FONT><A href=3D"news:b333mf$67g$1@rogue.oti.com"><FONT =
face=3DArial=20
size=3D2>news:b333mf$67g$1@rogue.oti.com</FONT></A><FONT face=3DArial=20
size=3D2>...</FONT></DIV><FONT face=3DArial size=3D2>> This posting =
is to start=20
the discussion thread on the component model.<BR>> I want to start =
with a=20
quick overview of the current component model<BR>> in Eclipse. I am =
sure I=20
will forget things or do injustice to others.<BR>> So feel free to =
correct=20
me or add precisions.<BR>> <BR>> Eclipse today supports the =
concept of=20
plug-ins as its component model.<BR>> Briefly, a plug-in is a Java =
library=20
at the core, that is, it is a set of<BR>> Java packages and a set =
of=20
resources. A plug-in may also be<BR>> contributing to the extension =
mechanism provided by the Eclipse plug-in<BR>> registry. It may =
define=20
extension points and/or provide extensions.<BR>> <BR>> Plug-ins =
are=20
loaded in isolation (in their own class loader) but the<BR>>=20
platform<BR>> allows and encourages cooperation between plug-ins. =
Such a=20
cooperation<BR>> happens at two levels. One is the sharing of Java=20
packages, the other<BR>> entails extension points. In order to=20
inter-operate, a plug-in has to<BR>> require<BR>> other plug-ins =
(in its=20
plugin.xml). Note that a "require" statement is<BR>> =
expressed<BR>> at a=20
plug-in level. Therefore, that a plugin A requires a plugin B =
means<BR>>=20
the following things.<BR>> <BR>> - A can see all Java =
classes and=20
all resources from B, respecting normal<BR>> Java<BR>> =
=20
class visibility rules.<BR>> - A and B may provide classes =
for the=20
same packages<BR>> - B may expose extension points that A =
provides=20
extensions to.<BR>> - All extension points from B are =
available to A=20
to provide extensions to.<BR>> <BR>> Note that a "require" =
statement is=20
specific to a plug-in.The dependency is<BR>> not<BR>> on needed =
Java=20
packages or resources, irrespectively of which plug-in<BR>>=20
provides<BR>> them; the dependency is on a specific plug-in. The =
same holds=20
true for<BR>> extension<BR>> points, the dependency is on a =
specific=20
provider of an extension point.<BR>> <BR>> I believe the =
extension point=20
mechanism goes even a step further, relating<BR>> the plug-in Id =
with the=20
extension point Id. In other words, a given<BR>> extension<BR>> =
points=20
is provided by one plug-in, and that plug-in only. Therefore, =
a<BR>> plugin=20
B<BR>> cannot provide extension points defined in another plug-in=20
A.<BR>> <BR>> Eclipse made also an interesting decision in =
allowing=20
local classes to<BR>> override<BR>> shared classes. In other =
words, a=20
plug-in may override classes from other<BR>> required plug-ins by =
having a=20
class with the same name on its local class<BR>> path.<BR>> I =
heard that=20
this introduces a security hole, but I am no security expert.<BR>> =
Anybody=20
has knowledge on this, please step forward.<BR>> <BR>> Plug-ins =
are=20
versioned, and therefore dependencies are expressed on =
versions<BR>> of=20
plug-ins. Eclipse versions do not have to maintain backward=20
compatibility<BR>> across<BR>> major releases. Hence, Eclipse =
has=20
adopted a versioning that is in<BR>> contradiction with the<BR>> =
Java=20
versioning specification<BR>>=20
=
[ http://java.sun.com/j2se/1.4/docs/guide/versioning/index.htm l]<BR>>=20
<BR>> Version identifier for a plug-in. In its string =
representation, it=20
consists<BR>> of up to 4 tokens<BR>> separated by a decimal =
point. The=20
first 3 tokens are positive integer<BR>> numbers, the last =
token<BR>> is=20
an uninterpreted string (no whitespace characters allowed). For=20
example,<BR>> the following<BR>> are valid version identifiers =
(as=20
strings):<BR>> <BR>> =20
0.0.0<BR>> =
1.0.127564<BR>>=20
3.7.2.build-127J<BR>>=20
1.9 which is interpreted as =
1.9.0<BR>> 3 which is=20
interpreted as 3.0.0<BR>> <BR>> The version identifier can be =
decomposed=20
into a major, minor, service level<BR>> component and<BR>> =
qualifier=20
components. A difference in the major component is interpreted =
as<BR>> an=20
incompatible<BR>> version change. A difference in the minor (and =
not the=20
major) component is<BR>> interpreted as a<BR>> compatible =
version=20
change. The service level component is interpreted as a<BR>> =
cumulative=20
and<BR>> compatible service update of the minor version component. =
The=20
qualifier is<BR>> not interpreted,<BR>> other than in version=20
comparisons. The qualifiers are compared using<BR>> lexicographical =
string<BR>> comparison.<BR>> <BR>> In order to try to satisfy =
potentially conflicting dependencies on different<BR>> plug-in=20
versions,<BR>> the Eclipse platform loads plug-ins in different =
ways=20
depending on if they<BR>> expose either<BR>> extensions or =
extension=20
points. In Eclipse parlance, a plug-in that neither<BR>> defines=20
extensions<BR>> nor extension points is called a library. The =
platform may=20
load multiple<BR>> versions of a library<BR>> in order to =
satisfy=20
conflicting dependencies. For instance, if two plug-ins<BR>> need =
to=20
different<BR>> major versions of the XERCES parser, the two =
versions will=20
be loaded in the<BR>> JVM if<BR>> they are available.<BR>> =
<BR>>=20
The limitations to this approach are imposed by the Java class =
loader<BR>>=20
limitations. For<BR>> well behaved libraries, not manipulating =
shared=20
resources, it will work just<BR>> fine in most<BR>> cases. For =
other=20
libraries, the position may be more difficult to defend.<BR>> For=20
instance,<BR>> SWT or JFace are also libraries, but it makes much =
less=20
sense to have<BR>> plug-ins bound<BR>> to different SWT or JFace =
versions, their integration in the workbench maybe<BR>> a =
little<BR>>=20
difficult.<BR>> <BR>> So that's it, folks, for the short=20
overview/analysis of Eclipse platform,<BR>> from a =
component<BR>> model=20
perspective. Please, feel free to correct potential mistakes =
and<BR>>=20
provide precisions;<BR>> I am quite sure I made some. Stay tuned =
for other=20
postings about how I see<BR>> Equinox<BR>> evolving from=20
Eclipse.<BR>> <BR>> Best regards,<BR>> Olivier.<BR>> =
<BR>>=20
<BR>> <BR>> <BR>> <BR>> <BR>> <BR>> <BR>> =
<BR>>=20
<BR>> </FONT></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0078_01C2D90B.5F8CB600--
|
|
|
| Re: Component Model [message #626 is a reply to message #584] |
Thu, 20 February 2003 23:12 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Hi Peter,
Pascal and yourself both have a point.
Pascal is right that features are not core to the runtime platform,
there are no runtime concept of features, only plug-ins and fragments...
which may actually be wrong...
But you have a good point is that features by driving what is installed,
also play a role in what is enabled. This duality is extremely visible
when considering self-hosting... where some features need to be installed
so that their plug-ins be available to be imported in their workspace to
build
some other plug-ins going in some other features... :-)
This is more the sort of topic of discussion I had in mind for the
self-hosting
thread of discussion. I had the idea it would be easier to focus here, like
Pascal is
suggesting, on the core runtime concepts of plug-ins and fragments...
Argh... fragments... I forgot them in my Eclipse overview... :-)
I will start the other thread of discussion on self-hosting as soon as I
can...
so that we can have that discussion there. We have to be very carefull of
how
we merge features, plug-ins, and fragments in a dynamic self-hosting
environment.
Stay tune for that other thread of discussion ! :-)
Best regards,
Olivier.
"Peter Manahan" <manahan@ca.ibm.com> wrote in message
news:3E5549BA.2080800@ca.ibm.com...
> I'm pretty sure features are used at runtime they are actually dual
> purpose (which is bad in itself). Initially they were only packaging
> manifests but that no longer is true. They now can drive which plugins
> are configured to run. It is possible to have one install of eclipse
> with all features and run different configurations based on features. If
> a feature is disabled its plugins are no longer available at runtime.
>
> Peter
> Pascal Rapicault wrote:
> > Hello,
> >
> > I think that features do not fall under the scope of the problem
> > listed previously since they are not present a runtime. Features
> > are used as a packaging / updating mechanism. However they
> > will indirectly benefits from the modification of the runtime.
> >
> > For example, if we are able to load / unload plugins, then we'll
> > be able to do "hot" update. Since installing a new feature will
> > then consists in unloading all the plugins and then reloading those.
> >
> > PaScaL
> >
> >
> > "Peter Manahan" <manahan@ca.ibm.com> wrote in message
> > news:3E554311.7010708@ca.ibm.com...
> >
> >>Hello,
> >>I'm curious how you see features fit into this model if at all? From the
> >>perspective of an application the smallest component is a feature.
> >>Plugins are useful from a development perspective to split work up but
> >>aren't usually useful unless collected together. From a
> >>release/application point of view features are what make up an
> >>application the Platform SDK for example is made up of big features
> >>Platform, JDT and SDK (PDE + source). Plugins are components of the more
> >>important whole :)
> >>
> >>It is far more manageable to to require the JDT 2.0.2 for your code than
> >>specific versions of the JDT plugins. I realize that the granularity is
> >>larger but for dependencies it would be simpler. In practice the JDT is
> >>never shipped or distributed piecemeal, you always get the whole thing.
> >>
> >>As soon as you increase the scale of the runtime then the usefulness of
> >>features becomes more apparent. WSAD for example ships something over
> >>400 plugins not including the base Eclipse platform. It ships only 50
> >>function containing features (there is about double that if you consider
> >>the translations and os specific ones). A much more manageable number
> >>than four hundred.
> >>
> >>Peter
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
|
|
| | | |
| Re: Component Model [message #1445 is a reply to message #650] |
Fri, 21 February 2003 04:29 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
That features have associated plugins is an aberration. The only real
reason they are there is to be a base for providing translations! Since
there currently is no such thing as a "feature fragment", there is no way to
add translations of the feature description etc directly to the feature.
Instead, it is added to the feature plugin. As such, the feature plugin and
its fragments provide the feature related content of the About dialog etc.
Summary: Peter is right in that features affect what is run but for
purists, this really should be looked at as a sort of dynamic
install/configuration mechanism where the features are used to control what
plugins and fragments are considered for execution but features are not
actually needed for execution.
Jeff
"Peter Manahan" <manahan@ca.ibm.com> wrote in message
news:3E558DBC.7010109@ca.ibm.com...
>
> After mentioning my confusion (re: is a feature a runtime component) to
> a colleague he reminded me that features have an associated plugin in
> order to provide a runtime component for the feature as features
> themselves aren't runtime. This seems to indicate a need for features at
> least in some sense should be considered more runtime or perhaps provide
> another method to get the runtime the same information.
>
> Peter
>
>
|
|
|
| Re: Component Model [message #1453 is a reply to message #638] |
Fri, 21 February 2003 04:38 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
There are good points on both sides here. Features are there to allow for
logical groupings so people don't have to understand the details. This is
powerful and useful. Interestingly, features can overlap. So, to carry
Peter's analogy through, in the embedded Java world people talk about
"profiles". A profile defines a set of packages, classes and methods which
are suitable as a base for applications in certain conditions (e.g., MIDP,
Foundation, Gateway, ...). Generally/roughly speaking they are subsets of
the full Java SDK.
So in Eclipse, while many/most will use the standard course grained features
like Platform or JDT, others will find those to be too big/bulky for their
requirements. The cool thing about features is that they are just logical
views -- People can define features to include whatever they want. My view
of the "platform" can consist of 10 small features while yours has just one
large feature. Assuming plugin version compatibility, both feature sets can
be installed at the same time.
Jeff
"Peter Manahan" <manahan@ca.ibm.com> wrote in message
news:3E5581CC.6090302@ca.ibm.com...
> Olivier Gruber wrote:
> > Hi Peter,
> >
> > Pascal and yourself both have a point.
> > Pascal is right that features are not core to the runtime platform,
> > there are no runtime concept of features, only plug-ins and fragments...
> > which may actually be wrong...
>
> One last blurb.
>
> I realize that features are not "currently" :-) core to the current
> runtime. They do however supply runtime components and affect the
> behavior of the runtime (which is where I got it stuck in my head that
> it was a runtime component).
>
> I've had this particular discussion before and the analogy that proved
> to be useful was:
> features = jar files
> plugins = classes
> eclipse the platform = Java the platform.
>
> There comes a point where the dependency on the jar is more important
> than its content. The rt.jar of the JVM. The dependency isn't on
> java.lang.String its on JDK 1.1.8 in most peoples eyes. As eclipse
> matures features will become more and more important as the core
> building blocks being passed around.
>
> As one of those who needs to use eclipse to build a complete product it
> is extremely apparent that plugins are far too granular to work with.
> Several things about building and maintaining a product would be made
> much easier if features were more core.
>
> OK, Said my piece :-) Features still may not be felt by many to be a
> runtime component but it is a component that affects the behavior of the
> runtime. And as eclipse matures they will become more and more important.
>
> Peter
>
>
>
>
|
|
|
| Re: Component Model [message #1464 is a reply to message #516] |
Fri, 21 February 2003 04:57 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Some comments/clarifications:
- plugins need not contribute code at all. For example, the doc plugins
have only html content and extensions.
- while it is technically possible for two plugins to define classes in the
same package, that goes against the Eclipse conventions (yes I know Eclipse
does it in a few limited places)
- Plugin prerequisite relationships are not required for the
extension/extension-point model. That is, A can extend B but not require B.
- Plugins can "override" classes from prerequisites but since the
classloader used is different, the masquerade will quickly be discovered.
Class identity includes the classloader. So class C loaded by L1 is
different from class C loaded by L2. Assume P1 requires P2 and both supply
a class C. All of P2's function will work ONLY with L2.C. It has no idea
what L1.C is. So unless P1 completely covers P2's function/implementation
related to C, you will eventually get class cast exceptions. So,
technically possible but challenging.
Jeff
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b333mf$67g$1@rogue.oti.com...
> This posting is to start the discussion thread on the component model.
> I want to start with a quick overview of the current component model
> in Eclipse. I am sure I will forget things or do injustice to others.
> So feel free to correct me or add precisions.
>
> Eclipse today supports the concept of plug-ins as its component model.
> Briefly, a plug-in is a Java library at the core, that is, it is a set of
> Java packages and a set of resources. A plug-in may also be
> contributing to the extension mechanism provided by the Eclipse plug-in
> registry. It may define extension points and/or provide extensions.
>
> Plug-ins are loaded in isolation (in their own class loader) but the
> platform
> allows and encourages cooperation between plug-ins. Such a cooperation
> happens at two levels. One is the sharing of Java packages, the other
> entails extension points. In order to inter-operate, a plug-in has to
> require
> other plug-ins (in its plugin.xml). Note that a "require" statement is
> expressed
> at a plug-in level. Therefore, that a plugin A requires a plugin B means
> the following things.
>
> - A can see all Java classes and all resources from B, respecting normal
> Java
> class visibility rules.
> - A and B may provide classes for the same packages
> - B may expose extension points that A provides extensions to.
> - All extension points from B are available to A to provide extensions
to.
>
> Note that a "require" statement is specific to a plug-in.The dependency is
> not
> on needed Java packages or resources, irrespectively of which plug-in
> provides
> them; the dependency is on a specific plug-in. The same holds true for
> extension
> points, the dependency is on a specific provider of an extension point.
>
> I believe the extension point mechanism goes even a step further, relating
> the plug-in Id with the extension point Id. In other words, a given
> extension
> points is provided by one plug-in, and that plug-in only. Therefore, a
> plugin B
> cannot provide extension points defined in another plug-in A.
>
> Eclipse made also an interesting decision in allowing local classes to
> override
> shared classes. In other words, a plug-in may override classes from other
> required plug-ins by having a class with the same name on its local class
> path.
> I heard that this introduces a security hole, but I am no security expert.
> Anybody has knowledge on this, please step forward.
>
> Plug-ins are versioned, and therefore dependencies are expressed on
versions
> of plug-ins. Eclipse versions do not have to maintain backward
compatibility
> across
> major releases. Hence, Eclipse has adopted a versioning that is in
> contradiction with the
> Java versioning specification
> [ http://java.sun.com/j2se/1.4/docs/guide/versioning/index.htm l]
>
> Version identifier for a plug-in. In its string representation, it
consists
> of up to 4 tokens
> separated by a decimal point. The first 3 tokens are positive integer
> numbers, the last token
> is an uninterpreted string (no whitespace characters allowed). For
example,
> the following
> are valid version identifiers (as strings):
>
> 0.0.0
> 1.0.127564
> 3.7.2.build-127J
> 1.9 which is interpreted as 1.9.0
> 3 which is interpreted as 3.0.0
>
> The version identifier can be decomposed into a major, minor, service
level
> component and
> qualifier components. A difference in the major component is interpreted
as
> an incompatible
> version change. A difference in the minor (and not the major) component is
> interpreted as a
> compatible version change. The service level component is interpreted as a
> cumulative and
> compatible service update of the minor version component. The qualifier is
> not interpreted,
> other than in version comparisons. The qualifiers are compared using
> lexicographical string
> comparison.
>
> In order to try to satisfy potentially conflicting dependencies on
different
> plug-in versions,
> the Eclipse platform loads plug-ins in different ways depending on if they
> expose either
> extensions or extension points. In Eclipse parlance, a plug-in that
neither
> defines extensions
> nor extension points is called a library. The platform may load multiple
> versions of a library
> in order to satisfy conflicting dependencies. For instance, if two
plug-ins
> need to different
> major versions of the XERCES parser, the two versions will be loaded in
the
> JVM if
> they are available.
>
> The limitations to this approach are imposed by the Java class loader
> limitations. For
> well behaved libraries, not manipulating shared resources, it will work
just
> fine in most
> cases. For other libraries, the position may be more difficult to defend.
> For instance,
> SWT or JFace are also libraries, but it makes much less sense to have
> plug-ins bound
> to different SWT or JFace versions, their integration in the workbench
maybe
> a little
> difficult.
>
> So that's it, folks, for the short overview/analysis of Eclipse platform,
> from a component
> model perspective. Please, feel free to correct potential mistakes and
> provide precisions;
> I am quite sure I made some. Stay tuned for other postings about how I see
> Equinox
> evolving from Eclipse.
>
> Best regards,
> Olivier.
>
>
>
>
>
>
>
>
>
>
>
|
|
|
| Re: Component Model [message #1487 is a reply to message #614] |
Fri, 21 February 2003 14:04 |
Pascal Rapicault
Messages: 333
Registered: July 2009
Location: Ottawa |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_001A_01C2D988.316EF490
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
yes.
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message =
news:b33lhh$k1p$1@rogue.oti.com...
Oops, thanks !
Does that also works in fragments ?
Olivier.
"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message =
news:b33eb4$f0m$1@rogue.oti.com...
Hello,=20
Just to correct one thing:
The plugins A do NOT see all the classes of plugin B.
It exists a notion of export associated to a library which filters
the packages that the library want to make visible.
A typical use of that is to prevent people from using non API =
classes.
Here is a example in GEF.
<library name=3D"runtime/gef.jar">
<export name=3D"org.eclipse.gef.*" />=20
.. .....
</library>
PaScaL
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message =
news:b333mf$67g$1@rogue.oti.com...
> This posting is to start the discussion thread on the component =
model.
> I want to start with a quick overview of the current component =
model
> in Eclipse. I am sure I will forget things or do injustice to =
others.
> So feel free to correct me or add precisions.
>=20
> Eclipse today supports the concept of plug-ins as its component =
model.
> Briefly, a plug-in is a Java library at the core, that is, it is a =
set of
> Java packages and a set of resources. A plug-in may also be
> contributing to the extension mechanism provided by the Eclipse =
plug-in
> registry. It may define extension points and/or provide =
extensions.
>=20
> Plug-ins are loaded in isolation (in their own class loader) but =
the
> platform
> allows and encourages cooperation between plug-ins. Such a =
cooperation
> happens at two levels. One is the sharing of Java packages, the =
other
> entails extension points. In order to inter-operate, a plug-in has =
to
> require
> other plug-ins (in its plugin.xml). Note that a "require" =
statement is
> expressed
> at a plug-in level. Therefore, that a plugin A requires a plugin B =
means
> the following things.
>=20
> - A can see all Java classes and all resources from B, respecting =
normal
> Java
> class visibility rules.
> - A and B may provide classes for the same packages
> - B may expose extension points that A provides extensions to.
> - All extension points from B are available to A to provide =
extensions to.
>=20
> Note that a "require" statement is specific to a plug-in.The =
dependency is
> not
> on needed Java packages or resources, irrespectively of which =
plug-in
> provides
> them; the dependency is on a specific plug-in. The same holds true =
for
> extension
> points, the dependency is on a specific provider of an extension =
point.
>=20
> I believe the extension point mechanism goes even a step further, =
relating
> the plug-in Id with the extension point Id. In other words, a =
given
> extension
> points is provided by one plug-in, and that plug-in only. =
Therefore, a
> plugin B
> cannot provide extension points defined in another plug-in A.
>=20
> Eclipse made also an interesting decision in allowing local =
classes to
> override
> shared classes. In other words, a plug-in may override classes =
from other
> required plug-ins by having a class with the same name on its =
local class
> path.
> I heard that this introduces a security hole, but I am no security =
expert.
> Anybody has knowledge on this, please step forward.
>=20
> Plug-ins are versioned, and therefore dependencies are expressed =
on versions
> of plug-ins. Eclipse versions do not have to maintain backward =
compatibility
> across
> major releases. Hence, Eclipse has adopted a versioning that is in
> contradiction with the
> Java versioning specification
> [ http://java.sun.com/j2se/1.4/docs/guide/versioning/index.htm l]
>=20
> Version identifier for a plug-in. In its string representation, it =
consists
> of up to 4 tokens
> separated by a decimal point. The first 3 tokens are positive =
integer
> numbers, the last token
> is an uninterpreted string (no whitespace characters allowed). For =
example,
> the following
> are valid version identifiers (as strings):
>=20
> 0.0.0
> 1.0.127564
> 3.7.2.build-127J
> 1.9 which is interpreted as 1.9.0
> 3 which is interpreted as 3.0.0
>=20
> The version identifier can be decomposed into a major, minor, =
service level
> component and
> qualifier components. A difference in the major component is =
interpreted as
> an incompatible
> version change. A difference in the minor (and not the major) =
component is
> interpreted as a
> compatible version change. The service level component is =
interpreted as a
> cumulative and
> compatible service update of the minor version component. The =
qualifier is
> not interpreted,
> other than in version comparisons. The qualifiers are compared =
using
> lexicographical string
> comparison.
>=20
> In order to try to satisfy potentially conflicting dependencies on =
different
> plug-in versions,
> the Eclipse platform loads plug-ins in different ways depending on =
if they
> expose either
> extensions or extension points. In Eclipse parlance, a plug-in =
that neither
> defines extensions
> nor extension points is called a library. The platform may load =
multiple
> versions of a library
> in order to satisfy conflicting dependencies. For instance, if two =
plug-ins
> need to different
> major versions of the XERCES parser, the two versions will be =
loaded in the
> JVM if
> they are available.
>=20
> The limitations to this approach are imposed by the Java class =
loader
> limitations. For
> well behaved libraries, not manipulating shared resources, it will =
work just
> fine in most
> cases. For other libraries, the position may be more difficult to =
defend.
> For instance,
> SWT or JFace are also libraries, but it makes much less sense to =
have
> plug-ins bound
> to different SWT or JFace versions, their integration in the =
workbench maybe
> a little
> difficult.
>=20
> So that's it, folks, for the short overview/analysis of Eclipse =
platform,
> from a component
> model perspective. Please, feel free to correct potential mistakes =
and
> provide precisions;
> I am quite sure I made some. Stay tuned for other postings about =
how I see
> Equinox
> evolving from Eclipse.
>=20
> Best regards,
> Olivier.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>
------=_NextPart_000_001A_01C2D988.316EF490
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>yes.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Olivier Gruber" <<A=20
href=3D"mailto:ogruber@us.ibm.com">ogruber@us.ibm.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:b33lhh$k1p$1@rogue.oti.com">news:b33lhh$k1p$1@rogue.oti.com<=
/A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Oops, thanks !</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Does that also works in fragments =
?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Olivier.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Pascal Rapicault" <<A=20
=
href=3D"mailto:pascal_rapicault@ca.ibm.com">pascal_rapicault@ca.ibm.com</=
A>>=20
wrote in message <A=20
=
href=3D"news:b33eb4$f0m$1@rogue.oti.com">news:b33eb4$f0m$1@rogue.oti.com<=
/A>...</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>Hello, </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Just to correct one =
thing:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The plugins A do NOT see all the =
classes of=20
plugin B.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It exists a notion of export =
associated to=20
a library which filters</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the packages that the library want =
to make=20
visible.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>A typical use of that is to prevent =
people from=20
using non API classes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Here is a example in =
GEF.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV class=3De>
<DIV class=3Dc style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT=20
face=3DArial><FONT size=3D2> <SPAN=20
class=3Dm><</SPAN><SPAN class=3Dt>library</SPAN><SPAN class=3Dt>=20
name</SPAN><SPAN class=3Dm>=3D"</SPAN>runtime/gef.jar<SPAN =
class=3Dm>"</SPAN><SPAN=20
class=3Dm>></SPAN></FONT></FONT></DIV>
<DIV>
<DIV class=3De>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3Db> =
</SPAN>=20
<SPAN class=3Dm><</SPAN><SPAN class=3Dt>export</SPAN> <SPAN=20
class=3Dt>name</SPAN><SPAN =
class=3Dm>=3D"</SPAN>org.eclipse.gef.*<SPAN=20
class=3Dm>"</SPAN><SPAN class=3Dm> /></SPAN> </FONT></FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT =
face=3DArial=20
=
size=3D2> .. &nbs p; ..... </FONT></=
DIV></DIV>
<DIV class=3De>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3Db> </SPAN><SPAN=20
class=3Dm></</SPAN><SPAN class=3Dt>library</SPAN><SPAN=20
class=3Dm>></SPAN></FONT></FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN =
class=3Dm><FONT=20
face=3DArial size=3D2></FONT></SPAN> </DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN =
class=3Dm><FONT=20
face=3DArial size=3D2> =
=20
PaScaL</FONT></SPAN></DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN =
class=3Dm><FONT=20
face=3DArial size=3D2></FONT></SPAN> </DIV>
<DIV style=3D"MARGIN-LEFT: 1em; TEXT-INDENT: -2em"><SPAN=20
class=3Dm></SPAN> </DIV></DIV></DIV></DIV></DIV ></DIV>
<DIV><FONT face=3DArial size=3D2>"Olivier Gruber" <</FONT><A=20
href=3D"mailto:ogruber@us.ibm.com"><FONT face=3DArial=20
size=3D2>ogruber@us.ibm.com</FONT></A><FONT face=3DArial =
size=3D2>> wrote in=20
message </FONT><A href=3D"news:b333mf$67g$1@rogue.oti.com"><FONT =
face=3DArial=20
size=3D2>news:b333mf$67g$1@rogue.oti.com</FONT></A><FONT =
face=3DArial=20
size=3D2>...</FONT></DIV><FONT face=3DArial size=3D2>> This =
posting is to start=20
the discussion thread on the component model.<BR>> I want to =
start with a=20
quick overview of the current component model<BR>> in Eclipse. I =
am sure=20
I will forget things or do injustice to others.<BR>> So feel free =
to=20
correct me or add precisions.<BR>> <BR>> Eclipse today =
supports the=20
concept of plug-ins as its component model.<BR>> Briefly, a =
plug-in is a=20
Java library at the core, that is, it is a set of<BR>> Java =
packages and=20
a set of resources. A plug-in may also be<BR>> contributing to =
the=20
extension mechanism provided by the Eclipse plug-in<BR>> =
registry. It may=20
define extension points and/or provide extensions.<BR>> <BR>> =
Plug-ins=20
are loaded in isolation (in their own class loader) but the<BR>>=20
platform<BR>> allows and encourages cooperation between plug-ins. =
Such a=20
cooperation<BR>> happens at two levels. One is the sharing of =
Java=20
packages, the other<BR>> entails extension points. In order to=20
inter-operate, a plug-in has to<BR>> require<BR>> other =
plug-ins (in=20
its plugin.xml). Note that a "require" statement is<BR>>=20
expressed<BR>> at a plug-in level. Therefore, that a plugin A =
requires a=20
plugin B means<BR>> the following things.<BR>> <BR>> =
- A can=20
see all Java classes and all resources from B, respecting =
normal<BR>>=20
Java<BR>> class visibility rules.<BR>> - A =
and B=20
may provide classes for the same packages<BR>> - B may =
expose=20
extension points that A provides extensions to.<BR>> - All=20
extension points from B are available to A to provide extensions =
to.<BR>>=20
<BR>> Note that a "require" statement is specific to a =
plug-in.The=20
dependency is<BR>> not<BR>> on needed Java packages or =
resources,=20
irrespectively of which plug-in<BR>> provides<BR>> them; the=20
dependency is on a specific plug-in. The same holds true for<BR>> =
extension<BR>> points, the dependency is on a specific provider =
of an=20
extension point.<BR>> <BR>> I believe the extension point =
mechanism=20
goes even a step further, relating<BR>> the plug-in Id with the =
extension=20
point Id. In other words, a given<BR>> extension<BR>> points =
is=20
provided by one plug-in, and that plug-in only. Therefore, a<BR>> =
plugin=20
B<BR>> cannot provide extension points defined in another plug-in =
A.<BR>> <BR>> Eclipse made also an interesting decision in =
allowing=20
local classes to<BR>> override<BR>> shared classes. In other =
words, a=20
plug-in may override classes from other<BR>> required plug-ins by =
having=20
a class with the same name on its local class<BR>> path.<BR>> =
I heard=20
that this introduces a security hole, but I am no security =
expert.<BR>>=20
Anybody has knowledge on this, please step forward.<BR>> <BR>> =
Plug-ins are versioned, and therefore dependencies are expressed on=20
versions<BR>> of plug-ins. Eclipse versions do not have to =
maintain=20
backward compatibility<BR>> across<BR>> major releases. Hence, =
Eclipse=20
has adopted a versioning that is in<BR>> contradiction with =
the<BR>>=20
Java versioning specification<BR>>=20
=
[ http://java.sun.com/j2se/1.4/docs/guide/versioning/index.htm l]<BR>>=20
<BR>> Version identifier for a plug-in. In its string =
representation, it=20
consists<BR>> of up to 4 tokens<BR>> separated by a decimal =
point. The=20
first 3 tokens are positive integer<BR>> numbers, the last =
token<BR>>=20
is an uninterpreted string (no whitespace characters allowed). For=20
example,<BR>> the following<BR>> are valid version identifiers =
(as=20
strings):<BR>> <BR>> =
=20
0.0.0<BR>> =
1.0.127564<BR>>=20
3.7.2.build-127J<BR>>=20
1.9 which is interpreted =
as=20
1.9.0<BR>> 3 which is=20
interpreted as 3.0.0<BR>> <BR>> The version identifier can be=20
decomposed into a major, minor, service level<BR>> component =
and<BR>>=20
qualifier components. A difference in the major component is =
interpreted=20
as<BR>> an incompatible<BR>> version change. A difference in =
the minor=20
(and not the major) component is<BR>> interpreted as a<BR>> =
compatible=20
version change. The service level component is interpreted as =
a<BR>>=20
cumulative and<BR>> compatible service update of the minor =
version=20
component. The qualifier is<BR>> not interpreted,<BR>> other =
than in=20
version comparisons. The qualifiers are compared using<BR>>=20
lexicographical string<BR>> comparison.<BR>> <BR>> In order =
to try=20
to satisfy potentially conflicting dependencies on different<BR>> =
plug-in=20
versions,<BR>> the Eclipse platform loads plug-ins in different =
ways=20
depending on if they<BR>> expose either<BR>> extensions or =
extension=20
points. In Eclipse parlance, a plug-in that neither<BR>> defines=20
extensions<BR>> nor extension points is called a library. The =
platform=20
may load multiple<BR>> versions of a library<BR>> in order to =
satisfy=20
conflicting dependencies. For instance, if two plug-ins<BR>> need =
to=20
different<BR>> major versions of the XERCES parser, the two =
versions will=20
be loaded in the<BR>> JVM if<BR>> they are available.<BR>> =
<BR>>=20
The limitations to this approach are imposed by the Java class=20
loader<BR>> limitations. For<BR>> well behaved libraries, not=20
manipulating shared resources, it will work just<BR>> fine in=20
most<BR>> cases. For other libraries, the position may be more =
difficult=20
to defend.<BR>> For instance,<BR>> SWT or JFace are also =
libraries,=20
but it makes much less sense to have<BR>> plug-ins bound<BR>> =
to=20
different SWT or JFace versions, their integration in the workbench=20
maybe<BR>> a little<BR>> difficult.<BR>> <BR>> So that's =
it,=20
folks, for the short overview/analysis of Eclipse platform,<BR>> =
from a=20
component<BR>> model perspective. Please, feel free to correct =
potential=20
mistakes and<BR>> provide precisions;<BR>> I am quite sure I =
made=20
some. Stay tuned for other postings about how I see<BR>> =
Equinox<BR>>=20
evolving from Eclipse.<BR>> <BR>> Best regards,<BR>>=20
Olivier.<BR>> <BR>> <BR>> <BR>> <BR>> <BR>> =
<BR>>=20
<BR>> <BR>> <BR>> <BR>>=20
</FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_001A_01C2D988.316EF490--
|
|
|
| Re: Component Model [message #1502 is a reply to message #1464] |
Fri, 21 February 2003 15:48 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b349uc$tgq$1@rogue.oti.com...
> Some comments/clarifications:
> - plugins need not contribute code at all. For example, the doc plugins
> have only html content and extensions.
Agreed.
> - while it is technically possible for two plugins to define classes in
the
> same package, that goes against the Eclipse conventions (yes I know
Eclipse
> does it in a few limited places)
I know it is not the Eclipse convention... :-)
but nothing prevents it... nor it is explicitly said it should not happen.
it is not criticizing Eclipse but rather showing that we may want to enforce
this in the Equinox runtime...
> - Plugin prerequisite relationships are not required for the
> extension/extension-point model. That is, A can extend B but not require
B.
How is this working ?
I thought that most extensions were done by implementing an interface
or extending a class... provided by the plug-in providing the extension
point.
So A would need to require B to be able to see B's interface or class for
the extension point... I am missing something ?
> - Plugins can "override" classes from prerequisites but since the
> classloader used is different, the masquerade will quickly be discovered.
> Class identity includes the classloader. So class C loaded by L1 is
> different from class C loaded by L2. Assume P1 requires P2 and both
supply
> a class C. All of P2's function will work ONLY with L2.C. It has no idea
> what L1.C is. So unless P1 completely covers P2's function/implementation
> related to C, you will eventually get class cast exceptions. So,
> technically possible but challenging.
Agreed.
> Jeff
>
>
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b333mf$67g$1@rogue.oti.com...
> > This posting is to start the discussion thread on the component model.
> > I want to start with a quick overview of the current component model
> > in Eclipse. I am sure I will forget things or do injustice to others.
> > So feel free to correct me or add precisions.
> >
> > Eclipse today supports the concept of plug-ins as its component model.
> > Briefly, a plug-in is a Java library at the core, that is, it is a set
of
> > Java packages and a set of resources. A plug-in may also be
> > contributing to the extension mechanism provided by the Eclipse plug-in
> > registry. It may define extension points and/or provide extensions.
> >
> > Plug-ins are loaded in isolation (in their own class loader) but the
> > platform
> > allows and encourages cooperation between plug-ins. Such a cooperation
> > happens at two levels. One is the sharing of Java packages, the other
> > entails extension points. In order to inter-operate, a plug-in has to
> > require
> > other plug-ins (in its plugin.xml). Note that a "require" statement is
> > expressed
> > at a plug-in level. Therefore, that a plugin A requires a plugin B means
> > the following things.
> >
> > - A can see all Java classes and all resources from B, respecting
normal
> > Java
> > class visibility rules.
> > - A and B may provide classes for the same packages
> > - B may expose extension points that A provides extensions to.
> > - All extension points from B are available to A to provide extensions
> to.
> >
> > Note that a "require" statement is specific to a plug-in.The dependency
is
> > not
> > on needed Java packages or resources, irrespectively of which plug-in
> > provides
> > them; the dependency is on a specific plug-in. The same holds true for
> > extension
> > points, the dependency is on a specific provider of an extension point.
> >
> > I believe the extension point mechanism goes even a step further,
relating
> > the plug-in Id with the extension point Id. In other words, a given
> > extension
> > points is provided by one plug-in, and that plug-in only. Therefore, a
> > plugin B
> > cannot provide extension points defined in another plug-in A.
> >
> > Eclipse made also an interesting decision in allowing local classes to
> > override
> > shared classes. In other words, a plug-in may override classes from
other
> > required plug-ins by having a class with the same name on its local
class
> > path.
> > I heard that this introduces a security hole, but I am no security
expert.
> > Anybody has knowledge on this, please step forward.
> >
> > Plug-ins are versioned, and therefore dependencies are expressed on
> versions
> > of plug-ins. Eclipse versions do not have to maintain backward
> compatibility
> > across
> > major releases. Hence, Eclipse has adopted a versioning that is in
> > contradiction with the
> > Java versioning specification
> > [ http://java.sun.com/j2se/1.4/docs/guide/versioning/index.htm l]
> >
> > Version identifier for a plug-in. In its string representation, it
> consists
> > of up to 4 tokens
> > separated by a decimal point. The first 3 tokens are positive integer
> > numbers, the last token
> > is an uninterpreted string (no whitespace characters allowed). For
> example,
> > the following
> > are valid version identifiers (as strings):
> >
> > 0.0.0
> > 1.0.127564
> > 3.7.2.build-127J
> > 1.9 which is interpreted as 1.9.0
> > 3 which is interpreted as 3.0.0
> >
> > The version identifier can be decomposed into a major, minor, service
> level
> > component and
> > qualifier components. A difference in the major component is interpreted
> as
> > an incompatible
> > version change. A difference in the minor (and not the major) component
is
> > interpreted as a
> > compatible version change. The service level component is interpreted as
a
> > cumulative and
> > compatible service update of the minor version component. The qualifier
is
> > not interpreted,
> > other than in version comparisons. The qualifiers are compared using
> > lexicographical string
> > comparison.
> >
> > In order to try to satisfy potentially conflicting dependencies on
> different
> > plug-in versions,
> > the Eclipse platform loads plug-ins in different ways depending on if
they
> > expose either
> > extensions or extension points. In Eclipse parlance, a plug-in that
> neither
> > defines extensions
> > nor extension points is called a library. The platform may load multiple
> > versions of a library
> > in order to satisfy conflicting dependencies. For instance, if two
> plug-ins
> > need to different
> > major versions of the XERCES parser, the two versions will be loaded in
> the
> > JVM if
> > they are available.
> >
> > The limitations to this approach are imposed by the Java class loader
> > limitations. For
> > well behaved libraries, not manipulating shared resources, it will work
> just
> > fine in most
> > cases. For other libraries, the position may be more difficult to
defend.
> > For instance,
> > SWT or JFace are also libraries, but it makes much less sense to have
> > plug-ins bound
> > to different SWT or JFace versions, their integration in the workbench
> maybe
> > a little
> > difficult.
> >
> > So that's it, folks, for the short overview/analysis of Eclipse
platform,
> > from a component
> > model perspective. Please, feel free to correct potential mistakes and
> > provide precisions;
> > I am quite sure I made some. Stay tuned for other postings about how I
see
> > Equinox
> > evolving from Eclipse.
> >
> > Best regards,
> > Olivier.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
|
|
| |
| Re: Component Model [message #1529 is a reply to message #1502] |
Fri, 21 February 2003 18:35 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Another common example is the Documentation extension point.
Doc is all HTML and XML, so no interface required.
|
|
|
| Re: Component Model [message #2730 is a reply to message #1516] |
Mon, 24 February 2003 23:56 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Yep, crystal clear :-)
So some extension points do not imply Java-level type dependencies,
but some do. This tends to augment my feeling that Java-type dependencies
belong to another level, disjoint than extension-related dependencies.
As you point out, there are two name spaces...
The more I think about it, the more I like having two separate layers,
one for Java-level components and dependencies, and the other one
for extension-related functionality.
Best regards,
Olivier.
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
news:b35hv6$s1j$1@rogue.oti.com...
> > > - Plugin prerequisite relationships are not required for the
> > > extension/extension-point model. That is, A can extend B but not
> require
> > B.
> >
> > How is this working ?
> > I thought that most extensions were done by implementing an interface
> > or extending a class... provided by the plug-in providing the extension
> > point.
> > So A would need to require B to be able to see B's interface or class
for
> > the extension point... I am missing something ?
> >
>
> An extension does NOT always require associated Java code.
> The fact that some extensions require java code, is a specificity of the
> extension
> point that is being extended.
> For example, view categories do not require java code to be added and to
be
> displayed.
> As a consequence a plugin providing categories does need to have the ui
> plugin in its requirements.
>
> It is important to note that there is two "name spaces":
> the first one is the java language and the second one contains
> plugin-ids / extension-points..
>
> Was I clear?
>
> PaScaL
>
>
|
|
| |
| Re: Component Model [message #4488 is a reply to message #662] |
Wed, 26 February 2003 22:12 |
David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
Christophe Elek wrote:
> Another word :-)
> We realized that Update Manager should not be the installer. Most
> programmer (if not all) will use native installer (RPM, and so on).
> Some other will work with JNLP. Other will use DMTF or Tivoli assicated
> deployer... Should we support every model ?
I respect the concern about using RPM, DEBs, etc., when possible, but
none of these services are ubiquitous, even within the Linux community,
much less outside it.
I read the threads that appeared about the time 2.0 shipped from Debian
and Red Hat/Mandrake users who preferred to receive their updates
through APT and RPM respectively. Personally, I feel that this is
misguided since it assumes a Debian or Red Hat-centric view of the world.
Suppose, for the sake of argument, that we tried to write a "SWT for
update managers". We could probably successfully encapsulate the
semantics of how a package (or Feature) plus its dependenciesare
installed, upgraded, uninstalled, and/or purged. However, the result
would still be far less than ideal. Developers could not create a
single Java "Feature" that would just install on all platforms.
Developers would be forced to use each platform's package tool to
package and distribute their software, an awesomely unnecessary headache.
I have no problem if the individual Linux distributions want to create
parallel packages of common Features that may be installed and updated
via the platform package manager. In fact, this is exactly how Perl is
currently managed on both Debian and Red Hat.
Perl has its own update manager as well--CPAN. Debian users are free to
use CPAN to update their Perl installations or (at their own option)
just wait for the desired Perl modules to become available through
separate Debian packages. We do not limit the Debian or Red Hat users
at all by having our own internal package manager any more than Perl
limits these platforms by having its own internal package manager.
It strikes me that the problem here is exactly the same as the one
solved by the Ant and Maven for build tools: We had Makefiles, but the
trouble with them was that their semantics have diverged over the years
across the platforms. It has become impossible to write a single
Makefile that will work correctly on any platform and no matter if it is
run by Microsoft's make utiltiy, Sun's make utility, or Gnu make (to
pick three common options). So autoconf/automake was built to hide the
differences between platforms, but this is really an ugly solution at
best and I believe only works if you choose Gnu make. It's really just
a band-aid solution on top of an otherwise unmanageable problem.
Consequently, people said, "Enough already" and wrote Ant so that we
could have a single Java build tool that runs exactly the same way on
all platforms.
Here is the upshot:
Do we want to create the autoconf/automake of package update tools or
the Ant/Maven of package update tools?
The current update manager corresponds with the Ant/Maven approach.
Sure, we break compatibility with the existing platform-specific ways of
updating packages. But we gain a whole lot more--a single
cross-platform way to manage Eclipse features.
In other words, I think that the update manager is the right approach.
(I'm saying this even though I personally run Debian.) If it could be
made to work with the new component model that we're working on here, it
would be awesome.
Best,
Dave
--
Dave Orme
Advanced Systems Concepts
http://www.swtworkbench.com
|
|
| |
| Re: Component Model [message #4837 is a reply to message #4488] |
Fri, 28 February 2003 18:05 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
I agree with you there David.
But it seems we are thinking about two levels, or at least, I am :-)
The native installer should be used to install the Eclipse platform
itself...
check the dependencies on the JRE, and do the other installation things
such as put taskbars, menus, registry updates...
But once the platform is there, I agree, it should have its own update
manager that understands not only features, but the specificities of the
Java
language. No other native installer that I am aware of is a language-level
installer... they deal with concepts at the OS level... when deploying
plug-ins, we are first and foremost concerned with Java type versioning
and Java binary compatibility as defined in the language specification.
Then we are concerned about plug-ins and fragments, grouped in features.
Those are unique concepts. We may learn from native installer, but they
are usually looking at intallable components from an OS perspective... not
a language platform one.
In short, let's see how to use native installers to package the core
Eclipse platform... and then let the update manager finish the install
bringing down needed/wanted features.
Best regards,
Olivier.
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"David J. Orme" <daveo@asc-iseries.com> wrote in message
news:b3jcd1$b96$1@rogue.oti.com...
> Christophe Elek wrote:
> > Another word :-)
> > We realized that Update Manager should not be the installer. Most
> > programmer (if not all) will use native installer (RPM, and so on).
> > Some other will work with JNLP. Other will use DMTF or Tivoli assicated
> > deployer... Should we support every model ?
>
> I respect the concern about using RPM, DEBs, etc., when possible, but
> none of these services are ubiquitous, even within the Linux community,
> much less outside it.
>
> I read the threads that appeared about the time 2.0 shipped from Debian
> and Red Hat/Mandrake users who preferred to receive their updates
> through APT and RPM respectively. Personally, I feel that this is
> misguided since it assumes a Debian or Red Hat-centric view of the world.
>
> Suppose, for the sake of argument, that we tried to write a "SWT for
> update managers". We could probably successfully encapsulate the
> semantics of how a package (or Feature) plus its dependenciesare
> installed, upgraded, uninstalled, and/or purged. However, the result
> would still be far less than ideal. Developers could not create a
> single Java "Feature" that would just install on all platforms.
> Developers would be forced to use each platform's package tool to
> package and distribute their software, an awesomely unnecessary headache.
>
> I have no problem if the individual Linux distributions want to create
> parallel packages of common Features that may be installed and updated
> via the platform package manager. In fact, this is exactly how Perl is
> currently managed on both Debian and Red Hat.
>
> Perl has its own update manager as well--CPAN. Debian users are free to
> use CPAN to update their Perl installations or (at their own option)
> just wait for the desired Perl modules to become available through
> separate Debian packages. We do not limit the Debian or Red Hat users
> at all by having our own internal package manager any more than Perl
> limits these platforms by having its own internal package manager.
>
> It strikes me that the problem here is exactly the same as the one
> solved by the Ant and Maven for build tools: We had Makefiles, but the
> trouble with them was that their semantics have diverged over the years
> across the platforms. It has become impossible to write a single
> Makefile that will work correctly on any platform and no matter if it is
> run by Microsoft's make utiltiy, Sun's make utility, or Gnu make (to
> pick three common options). So autoconf/automake was built to hide the
> differences between platforms, but this is really an ugly solution at
> best and I believe only works if you choose Gnu make. It's really just
> a band-aid solution on top of an otherwise unmanageable problem.
> Consequently, people said, "Enough already" and wrote Ant so that we
> could have a single Java build tool that runs exactly the same way on
> all platforms.
>
> Here is the upshot:
>
> Do we want to create the autoconf/automake of package update tools or
> the Ant/Maven of package update tools?
>
> The current update manager corresponds with the Ant/Maven approach.
> Sure, we break compatibility with the existing platform-specific ways of
> updating packages. But we gain a whole lot more--a single
> cross-platform way to manage Eclipse features.
>
> In other words, I think that the update manager is the right approach.
> (I'm saying this even though I personally run Debian.) If it could be
> made to work with the new component model that we're working on here, it
> would be awesome.
>
>
> Best,
>
> Dave
> --
> Dave Orme
> Advanced Systems Concepts
> http://www.swtworkbench.com
>
|
|
| | | |
| Re: Component Model - Security? [message #9030 is a reply to message #516] |
Fri, 07 March 2003 10:16 |
Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
I read everything in the Component Model thread and I didn't see this
addressed so here it is:
In a world of dynamic plugins/components, perhaps downloaded from the
web, it is natural that a user might recieve and be about to install an
application from a source that is perhaps not all that trustworthy.
From what I can tell, the current plugin model assumes that if a user
has the code installed on his local machine that it is A-OK (i.e.
codebase==local so security==AllPermissions).
I'm thinking that this is not really a very good thing. I'm sure that
others more experienced here will chime in with clarifications and
corrections but I'll humbly offer my thoughts.
I think that a component model needs to have a certification and
permission mechanism. When a user installs a component, the component
manager should prompt the user with questions like:
The component <Name of Component> requires permission to <modify files
anywhere on your system, which could totally destroy all your critical
data or otherwise put it at risk>. It is signed by <Signer of Code>
which has/has not been verified by <Certificate Authority>.
[Trust this time] [Trust always from Signer] [Deny the sucker]
There are a couple of ways to do this. In either way we start by
denying ALL critical permissions for any new plugin by default.
The first model says: wait until the component tries to do something, in
which case we trap the SecurityException, then prompt the user like
above and modify our policy according to the user's grants so that in
the future the code won't trip the exception.
The second model says that the component's manifest explicitely states
what permissions it will require and so the user is prompted at install
time (unless their is already an encompassing permission for that
component such as all code from that signer) so that the security policy
is set right away. In that case, any deviation from the policy will
still trigger a security exception, of course.
The attractive thing about the first model is that it is implicit for
the developer. All the onus is on the platform to properly catch the
exception and identify the offender. I don't like it because it can be
difficult to do that (trap/identify/query/grant) cleanly and accurately
in a complex multi-threaded, mult-classloader environment.
I like the second model because it is explicit. Explicit things always
seem to be better in the long run. The negative is that _requiring_
explicit permission requests is incompatible with current plugin.xml.
Of course, the best model is to do both: _allow_ permission requests to
be specified in the component manifest so that they can be setup at
install time yet still implicitely trap/identify/query/grant dynamically
as needed.
Thoughts?
|
|
|
| Re: Component Model - Security? [message #9051 is a reply to message #9030] |
Fri, 07 March 2003 02:52 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
Something we did in our application, and will do in others, is add a "user
role". That is, every click, every menu item, button, etc is checked against
a user role to see if the person is allowed to do it or not. Not that this
is what you are talking about here, but I thought I would add my thoughts to
see if this is something that should be implemented. Most GUI apps,
especially in the enteprise or ASP region want to be built around user
roles. Our application is used by many people in one company, each with
varying "rights" to do things. Some can simply look. Some can add. Some can
delete and pull reports. All based on users rights. We do connect to a J2EE
server and get those rigths, but the same can be built into a generic
framework that allows the plugin config file to specify a permission level
to use a given plugins feature(s).
As for what you said, I'd agree too. Seems there should be a more secure
manner built in to letting a given plugin be installed and/or started. I'd
imagine it is pretty easy to pass off a renegade plugin as being something
good and get full control over one's computer. First, for me, with an
open-source application like Eclipse, I'd feel safe only with the source and
build capabilities. Imagine downloading and using a plugin that sends
internet reports of all source code passing through the IDE, so that someone
could be stealing source code from all over. Not that this would happen, but
I believe it is a possibility. And here we are only talking about the IDE!
In the real world, where an app may be used to connect to the world bank,
each user must not be able to install plugins, or only allow to upgrade
based on roles or permissions or something. And, all plugins should be able
to be through a certified process, where by if a plugin developers wants to
sell it, the certification process is that someone looks through the source,
builds the plugin, guarantees that it is solid with no renegade code, then
it is signed and sealed somehow, so that when you download it, you only can
get signed/sealed plugins, and quite possibly a special key is used to
unlock it before it can install or start.
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b48hj8$fq1$1@rogue.oti.com...
> I read everything in the Component Model thread and I didn't see this
> addressed so here it is:
>
> In a world of dynamic plugins/components, perhaps downloaded from the
> web, it is natural that a user might recieve and be about to install an
> application from a source that is perhaps not all that trustworthy.
>
> From what I can tell, the current plugin model assumes that if a user
> has the code installed on his local machine that it is A-OK (i.e.
> codebase==local so security==AllPermissions).
>
> I'm thinking that this is not really a very good thing. I'm sure that
> others more experienced here will chime in with clarifications and
> corrections but I'll humbly offer my thoughts.
>
> I think that a component model needs to have a certification and
> permission mechanism. When a user installs a component, the component
> manager should prompt the user with questions like:
>
> The component <Name of Component> requires permission to <modify files
> anywhere on your system, which could totally destroy all your critical
> data or otherwise put it at risk>. It is signed by <Signer of Code>
> which has/has not been verified by <Certificate Authority>.
>
> [Trust this time] [Trust always from Signer] [Deny the sucker]
>
> There are a couple of ways to do this. In either way we start by
> denying ALL critical permissions for any new plugin by default.
>
> The first model says: wait until the component tries to do something, in
> which case we trap the SecurityException, then prompt the user like
> above and modify our policy according to the user's grants so that in
> the future the code won't trip the exception.
>
> The second model says that the component's manifest explicitely states
> what permissions it will require and so the user is prompted at install
> time (unless their is already an encompassing permission for that
> component such as all code from that signer) so that the security policy
> is set right away. In that case, any deviation from the policy will
> still trigger a security exception, of course.
>
> The attractive thing about the first model is that it is implicit for
> the developer. All the onus is on the platform to properly catch the
> exception and identify the offender. I don't like it because it can be
> difficult to do that (trap/identify/query/grant) cleanly and accurately
> in a complex multi-threaded, mult-classloader environment.
>
> I like the second model because it is explicit. Explicit things always
> seem to be better in the long run. The negative is that _requiring_
> explicit permission requests is incompatible with current plugin.xml.
>
> Of course, the best model is to do both: _allow_ permission requests to
> be specified in the component manifest so that they can be setup at
> install time yet still implicitely trap/identify/query/grant dynamically
> as needed.
>
> Thoughts?
>
>
>
|
|
|
| Re: Component Model - Security? [message #9072 is a reply to message #9030] |
Fri, 07 March 2003 03:18 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Excellent. The current Eclipse infrastructure has relatively few security
mechanisms. JARs can be signed but that's about it. This is definitely
something that should be considered. My knowledge in this area is very
sketchy. Especially in considering permissions across plugins (i.e.,
classloaders). For example, the resources plugin would need to be able to
create/delete files. Since it can do so just about anywhere on the disk and
it exposes API, what is to stop my plugin calling that API to delete C:\*.*?
My first reaction to the options you suggest is "explicit is good" (i.e., #2
rules). #1 is convenient but as you say, catching and correctly
interpreting the execeptions would be very hard. Headless plugins would
have a hard time doing anything useful.
Any thoughts on how other systems handle this?
Jeff
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b48hj8$fq1$1@rogue.oti.com...
> I read everything in the Component Model thread and I didn't see this
> addressed so here it is:
>
> In a world of dynamic plugins/components, perhaps downloaded from the
> web, it is natural that a user might recieve and be about to install an
> application from a source that is perhaps not all that trustworthy.
>
> From what I can tell, the current plugin model assumes that if a user
> has the code installed on his local machine that it is A-OK (i.e.
> codebase==local so security==AllPermissions).
>
> I'm thinking that this is not really a very good thing. I'm sure that
> others more experienced here will chime in with clarifications and
> corrections but I'll humbly offer my thoughts.
>
> I think that a component model needs to have a certification and
> permission mechanism. When a user installs a component, the component
> manager should prompt the user with questions like:
>
> The component <Name of Component> requires permission to <modify files
> anywhere on your system, which could totally destroy all your critical
> data or otherwise put it at risk>. It is signed by <Signer of Code>
> which has/has not been verified by <Certificate Authority>.
>
> [Trust this time] [Trust always from Signer] [Deny the sucker]
>
> There are a couple of ways to do this. In either way we start by
> denying ALL critical permissions for any new plugin by default.
>
> The first model says: wait until the component tries to do something, in
> which case we trap the SecurityException, then prompt the user like
> above and modify our policy according to the user's grants so that in
> the future the code won't trip the exception.
>
> The second model says that the component's manifest explicitely states
> what permissions it will require and so the user is prompted at install
> time (unless their is already an encompassing permission for that
> component such as all code from that signer) so that the security policy
> is set right away. In that case, any deviation from the policy will
> still trigger a security exception, of course.
>
> The attractive thing about the first model is that it is implicit for
> the developer. All the onus is on the platform to properly catch the
> exception and identify the offender. I don't like it because it can be
> difficult to do that (trap/identify/query/grant) cleanly and accurately
> in a complex multi-threaded, mult-classloader environment.
>
> I like the second model because it is explicit. Explicit things always
> seem to be better in the long run. The negative is that _requiring_
> explicit permission requests is incompatible with current plugin.xml.
>
> Of course, the best model is to do both: _allow_ permission requests to
> be specified in the component manifest so that they can be setup at
> install time yet still implicitely trap/identify/query/grant dynamically
> as needed.
>
> Thoughts?
>
>
>
|
|
|
| Re: Component Model - Security? [message #9136 is a reply to message #9051] |
Fri, 07 March 2003 07:51 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Security from an OSGi perspective:
The OSGi has a full blown (on Java 2 based) security model. The
framework implements a security model using permissions. Each bundle has
its own protection domain (which is restriction on the Java model that
allows multiple signers). The permissions of a bundle are managed
through a service, allowing the specific security policy to be handled
in an Eclipse defined way.
One problem with Java 2 security is that if you are not careful you tend
to make -too- many Permission classes. The OSGi therefore has
ServicePermission which allows a bundle to register, or get a service
from the service registry. One of the requirements of the spec is that
if you do not have ServicePermission[GET,MyService], you cannot detect
its presence. I.e. even events regarding MyService are filtered.
We found that many security models can be implemented by carefully
crafting the service permissions and thus preventing the creation domain
specific permissions. (We are coming from an embedded world, classes are
expensive!!).
Further there is PackagePermission and AdminPermission.
PackagePermission[IMPORT|EXPORT,my.package] allows a bundle to export
packages or import packages. AdminPermission is a catch-all. Many
services are more lenient when one has AdminPermission.
Further services may define specific permissions when necesary. I.e.
there is UserPermission for the User Admin service, WirePermission for
Wire Admin, etc. And there are of course the standard Java permissions.
Security will be related to the codebase but also the user that runs the
app (See Mel Martinez post). The OSGi provides a User Admin service that
manages a User/Group/Role database which might be useful. The JAAS
architecture is compatible with this though we normally have a more
light-weight model.
One note about security. The Java security model is NOT light-weight. It
requires stack crawling and Permission class creation for EVERY check.
Many optimizations are not possible because the model is OO based (hides
the implementation) and not declarative. The other problem is that code
that runs under security will require changes. In Java, all code on the
stack requires permission XPermission if X is done (or AllPermission).
If you have code that wants to do X regardless of the stack, you must
create a subclass of PrivilegedAction for each ocurrence. This can
become expensive quickly. The OSGi specifications require the Framework
to at least do the callbacks in the bundles in a privileged action with
only their own permissions, simplifying life considerably. But realize
what you are asking for.
The same for the user based authorization. This is VERY intrusive in ALL
code and is usually not much more than a "helper" to remove/disable GUI
components that are not usable. The real authorization must be done on a
secured server, not on a tamperable client.
Kind regards,
Peter Kriens
Kevin wrote:
> Something we did in our application, and will do in others, is add a "user
> role". That is, every click, every menu item, button, etc is checked against
> a user role to see if the person is allowed to do it or not. Not that this
> is what you are talking about here, but I thought I would add my thoughts to
> see if this is something that should be implemented. Most GUI apps,
> especially in the enteprise or ASP region want to be built around user
> roles. Our application is used by many people in one company, each with
> varying "rights" to do things. Some can simply look. Some can add. Some can
> delete and pull reports. All based on users rights. We do connect to a J2EE
> server and get those rigths, but the same can be built into a generic
> framework that allows the plugin config file to specify a permission level
> to use a given plugins feature(s).
>
> As for what you said, I'd agree too. Seems there should be a more secure
> manner built in to letting a given plugin be installed and/or started. I'd
> imagine it is pretty easy to pass off a renegade plugin as being something
> good and get full control over one's computer. First, for me, with an
> open-source application like Eclipse, I'd feel safe only with the source and
> build capabilities. Imagine downloading and using a plugin that sends
> internet reports of all source code passing through the IDE, so that someone
> could be stealing source code from all over. Not that this would happen, but
> I believe it is a possibility. And here we are only talking about the IDE!
> In the real world, where an app may be used to connect to the world bank,
> each user must not be able to install plugins, or only allow to upgrade
> based on roles or permissions or something. And, all plugins should be able
> to be through a certified process, where by if a plugin developers wants to
> sell it, the certification process is that someone looks through the source,
> builds the plugin, guarantees that it is solid with no renegade code, then
> it is signed and sealed somehow, so that when you download it, you only can
> get signed/sealed plugins, and quite possibly a special key is used to
> unlock it before it can install or start.
>
>
> "Mel Martinez" <melm@us.ibm.com> wrote in message
> news:b48hj8$fq1$1@rogue.oti.com...
>
>>I read everything in the Component Model thread and I didn't see this
>>addressed so here it is:
>>
>>In a world of dynamic plugins/components, perhaps downloaded from the
>>web, it is natural that a user might recieve and be about to install an
>>application from a source that is perhaps not all that trustworthy.
>>
>> From what I can tell, the current plugin model assumes that if a user
>>has the code installed on his local machine that it is A-OK (i.e.
>>codebase==local so security==AllPermissions).
>>
>>I'm thinking that this is not really a very good thing. I'm sure that
>>others more experienced here will chime in with clarifications and
>>corrections but I'll humbly offer my thoughts.
>>
>>I think that a component model needs to have a certification and
>>permission mechanism. When a user installs a component, the component
>>manager should prompt the user with questions like:
>>
>>The component <Name of Component> requires permission to <modify files
>>anywhere on your system, which could totally destroy all your critical
>>data or otherwise put it at risk>. It is signed by <Signer of Code>
>>which has/has not been verified by <Certificate Authority>.
>>
>>[Trust this time] [Trust always from Signer] [Deny the sucker]
>>
>>There are a couple of ways to do this. In either way we start by
>>denying ALL critical permissions for any new plugin by default.
>>
>>The first model says: wait until the component tries to do something, in
>>which case we trap the SecurityException, then prompt the user like
>>above and modify our policy according to the user's grants so that in
>>the future the code won't trip the exception.
>>
>>The second model says that the component's manifest explicitely states
>>what permissions it will require and so the user is prompted at install
>>time (unless their is already an encompassing permission for that
>>component such as all code from that signer) so that the security policy
>>is set right away. In that case, any deviation from the policy will
>>still trigger a security exception, of course.
>>
>>The attractive thing about the first model is that it is implicit for
>>the developer. All the onus is on the platform to properly catch the
>>exception and identify the offender. I don't like it because it can be
>>difficult to do that (trap/identify/query/grant) cleanly and accurately
>>in a complex multi-threaded, mult-classloader environment.
>>
>>I like the second model because it is explicit. Explicit things always
>>seem to be better in the long run. The negative is that _requiring_
>>explicit permission requests is incompatible with current plugin.xml.
>>
>>Of course, the best model is to do both: _allow_ permission requests to
>>be specified in the component manifest so that they can be setup at
>>install time yet still implicitely trap/identify/query/grant dynamically
>>as needed.
>>
>>Thoughts?
>>
>>
>>
>>
>
>
|
|
|
| Re: Component Model - Security? [message #9154 is a reply to message #9030] |
Fri, 07 March 2003 08:06 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
If we need security, I would like to consider a more "profile" based
security model. Imho, very few people understand the consequences of
clicking "Always trust from this source". Certificates are not very easy
to read for mere mortals. Also, people tend to distrust the security
dialog when they ever have surfed to "obscure" sites ...
A user, however, knows what he wants to do with a plugin. Having a few
categories (<10) would allow a user to select the one he expects the
plugin to need. If the plugin tries to do things outside its category,
it could be asked if it could be assigned to other categories as well.
Ie if I download a mail reader plugin I know it will do network stuff.
If I download an XML plugin I do not expect it to call network code.
Again, realize what you ask for. This stuff can make everything
significantly more complicated. Does an IDE need this complexity?
Kind regards,
Peter Kriens
Mel Martinez wrote:
> I read everything in the Component Model thread and I didn't see this
> addressed so here it is:
>
> In a world of dynamic plugins/components, perhaps downloaded from the
> web, it is natural that a user might recieve and be about to install an
> application from a source that is perhaps not all that trustworthy.
>
> From what I can tell, the current plugin model assumes that if a user
> has the code installed on his local machine that it is A-OK (i.e.
> codebase==local so security==AllPermissions).
>
> I'm thinking that this is not really a very good thing. I'm sure that
> others more experienced here will chime in with clarifications and
> corrections but I'll humbly offer my thoughts.
>
> I think that a component model needs to have a certification and
> permission mechanism. When a user installs a component, the component
> manager should prompt the user with questions like:
>
> The component <Name of Component> requires permission to <modify files
> anywhere on your system, which could totally destroy all your critical
> data or otherwise put it at risk>. It is signed by <Signer of Code>
> which has/has not been verified by <Certificate Authority>.
>
> [Trust this time] [Trust always from Signer] [Deny the sucker]
>
> There are a couple of ways to do this. In either way we start by
> denying ALL critical permissions for any new plugin by default.
>
> The first model says: wait until the component tries to do something, in
> which case we trap the SecurityException, then prompt the user like
> above and modify our policy according to the user's grants so that in
> the future the code won't trip the exception.
>
> The second model says that the component's manifest explicitely states
> what permissions it will require and so the user is prompted at install
> time (unless their is already an encompassing permission for that
> component such as all code from that signer) so that the security policy
> is set right away. In that case, any deviation from the policy will
> still trigger a security exception, of course.
>
> The attractive thing about the first model is that it is implicit for
> the developer. All the onus is on the platform to properly catch the
> exception and identify the offender. I don't like it because it can be
> difficult to do that (trap/identify/query/grant) cleanly and accurately
> in a complex multi-threaded, mult-classloader environment.
>
> I like the second model because it is explicit. Explicit things always
> seem to be better in the long run. The negative is that _requiring_
> explicit permission requests is incompatible with current plugin.xml.
>
> Of course, the best model is to do both: _allow_ permission requests to
> be specified in the component manifest so that they can be setup at
> install time yet still implicitely trap/identify/query/grant dynamically
> as needed.
>
> Thoughts?
>
>
>
|
|
|
| Re: Component Model - Security? [message #9229 is a reply to message #9154] |
Sat, 08 March 2003 08:14 |
Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
Peter wrote:
> If we need security, I would like to consider a more "profile" based
> security model. Imho, very few people understand the consequences of
> clicking "Always trust from this source". Certificates are not very easy
> to read for mere mortals. Also, people tend to distrust the security
> dialog when they ever have surfed to "obscure" sites ...
>
I was just about to suggest this very thing (security 'profiles') in
response to your last post. This is analogous to granting user's access
based on 'role' or 'group' in a multi-user system.
In fact, I wonder if there is any work going on (i.e. JSR) on adding
'permission profiles' to the standard Java Security model. It seems
like a no brainer that one should have a way of aggregating multiple
permissions into a reusable, referenceable set to be granted to code
from specified codebases.
> A user, however, knows what he wants to do with a plugin. Having a few
> categories (<10) would allow a user to select the one he expects the
> plugin to need. If the plugin tries to do things outside its category,
> it could be asked if it could be assigned to other categories as well.
>
> Ie if I download a mail reader plugin I know it will do network stuff.
> If I download an XML plugin I do not expect it to call network code.
>
> Again, realize what you ask for. This stuff can make everything
> significantly more complicated. Does an IDE need this complexity?
>
I don't know about the complexity, but an IDE does need to consider
security just like any extensible application, if it is going to be
involved with work that must be secure. Programmers work with sensitive
data (source code!) that might be at risk. The moment we (equinox)
start talking about the ability to dynamically load/unload components -
especially from the web, then we are talking about all the same risks
one has with applets.
On the overhead of security permission checking, that, I believe is one
area that should be improved in 1.4+ JRE's. Even without those
improvements, I don't see it as a performance killer in a user-app. I
could be wrong, but that's my gut feeling.
On user-based security (authentication & access control - i.e. JAAS) I
don't currently see a reason to incorporate that into the platform as
eclipse is not a multi-user application. Different users of an eclipse
install on a given machine might have different profiles and access to
particular plugins - but that can be administered in other ways, outside
of the scope of eclipse itself. I guess one could see a component using
JAAS to authenticate the current user if multiple users might use the
same account on a given machine (ex - kiosk mode) and then act
accordingly, but the fact is that only one user would still be using the
process instance. This is not the same as a mult-user server app where
each thread in the app typically belongs to different users. For most
use cases of eclipse-derived applications I would bet that it is
sufficient to assume that the user has authenticated with the host OS in
order to be even running the app and thus
System.getProperty("user.name") is more than enough. Otherwise, JAAS
support seems like it could be added as a plugin and used only on an
application-specific basis.
I stand ready to be corrected on that, of course.
My concern remains with codebase security.
Cheers,
Mel
|
|
|
| Re: Component Model - Security? [message #10274 is a reply to message #9229] |
Sat, 08 March 2003 00:25 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
I am pretty sure this is what I said in my post. ;) Basically a user role
that can work either at the plugin level, the class level or the component
level. I think at the UI component level may be best. A user doesn't care
that a plugin provides 35 UI components or not. A user does care that given
his/her permission level, he/she can access a given UI component they are
trained to use. In an IDE, obviously all components would be available, I
see not much use of a user role in this scenario. I certainly don't want our
IT guy turning off some features in my IDE that I may use to develop with.
But in using Eclipse and OSGi as a complete start from scratch UI framework,
there may be low level users and admin users with the same client. I am all
for hiding any components a given level of user can't use. Why disable them
and clutter the UI? Just hide them completely, so that the user never sees
them nor has to worry about them.
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b4aurl$3jr$1@rogue.oti.com...
> Peter wrote:
> > If we need security, I would like to consider a more "profile" based
> > security model. Imho, very few people understand the consequences of
> > clicking "Always trust from this source". Certificates are not very easy
> > to read for mere mortals. Also, people tend to distrust the security
> > dialog when they ever have surfed to "obscure" sites ...
> >
>
> I was just about to suggest this very thing (security 'profiles') in
> response to your last post. This is analogous to granting user's access
> based on 'role' or 'group' in a multi-user system.
>
> In fact, I wonder if there is any work going on (i.e. JSR) on adding
> 'permission profiles' to the standard Java Security model. It seems
> like a no brainer that one should have a way of aggregating multiple
> permissions into a reusable, referenceable set to be granted to code
> from specified codebases.
>
> > A user, however, knows what he wants to do with a plugin. Having a few
> > categories (<10) would allow a user to select the one he expects the
> > plugin to need. If the plugin tries to do things outside its category,
> > it could be asked if it could be assigned to other categories as well.
> >
> > Ie if I download a mail reader plugin I know it will do network stuff.
> > If I download an XML plugin I do not expect it to call network code.
> >
> > Again, realize what you ask for. This stuff can make everything
> > significantly more complicated. Does an IDE need this complexity?
> >
>
> I don't know about the complexity, but an IDE does need to consider
> security just like any extensible application, if it is going to be
> involved with work that must be secure. Programmers work with sensitive
> data (source code!) that might be at risk. The moment we (equinox)
> start talking about the ability to dynamically load/unload components -
> especially from the web, then we are talking about all the same risks
> one has with applets.
>
> On the overhead of security permission checking, that, I believe is one
> area that should be improved in 1.4+ JRE's. Even without those
> improvements, I don't see it as a performance killer in a user-app. I
> could be wrong, but that's my gut feeling.
>
> On user-based security (authentication & access control - i.e. JAAS) I
> don't currently see a reason to incorporate that into the platform as
> eclipse is not a multi-user application. Different users of an eclipse
> install on a given machine might have different profiles and access to
> particular plugins - but that can be administered in other ways, outside
> of the scope of eclipse itself. I guess one could see a component using
> JAAS to authenticate the current user if multiple users might use the
> same account on a given machine (ex - kiosk mode) and then act
> accordingly, but the fact is that only one user would still be using the
> process instance. This is not the same as a mult-user server app where
> each thread in the app typically belongs to different users. For most
> use cases of eclipse-derived applications I would bet that it is
> sufficient to assume that the user has authenticated with the host OS in
> order to be even running the app and thus
> System.getProperty("user.name") is more than enough. Otherwise, JAAS
> support seems like it could be added as a plugin and used only on an
> application-specific basis.
>
> I stand ready to be corrected on that, of course.
>
> My concern remains with codebase security.
>
> Cheers,
>
> Mel
>
|
|
|
| Re: Component Model - Security? [message #10340 is a reply to message #9229] |
Sat, 08 March 2003 11:10 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
I still do not see that much a use case for security in an IDE. As you
indicate, an IDE is single user application which usually runs on a host
where the owner has full control. We can restrict a plugin from doing
bad things (oode base security) but we cannot restrict the user from
doing bad things because he controls the hardware.
About overhead. There is a significant overhead in Java 2 security that
is hard to optimize away. However, my main concern is with the code that
becomes significantly more complex if it has to live in a secure
environment, at least imho.
Kind regards,
Peter Kriens
Mel Martinez wrote:
> Peter wrote:
>
>> If we need security, I would like to consider a more "profile" based
>> security model. Imho, very few people understand the consequences of
>> clicking "Always trust from this source". Certificates are not very
>> easy to read for mere mortals. Also, people tend to distrust the
>> security dialog when they ever have surfed to "obscure" sites ...
>>
>
> I was just about to suggest this very thing (security 'profiles') in
> response to your last post. This is analogous to granting user's access
> based on 'role' or 'group' in a multi-user system.
>
> In fact, I wonder if there is any work going on (i.e. JSR) on adding
> 'permission profiles' to the standard Java Security model. It seems
> like a no brainer that one should have a way of aggregating multiple
> permissions into a reusable, referenceable set to be granted to code
> from specified codebases.
>
>> A user, however, knows what he wants to do with a plugin. Having a few
>> categories (<10) would allow a user to select the one he expects the
>> plugin to need. If the plugin tries to do things outside its category,
>> it could be asked if it could be assigned to other categories as well.
>>
>> Ie if I download a mail reader plugin I know it will do network stuff.
>> If I download an XML plugin I do not expect it to call network code.
>>
>> Again, realize what you ask for. This stuff can make everything
>> significantly more complicated. Does an IDE need this complexity?
>>
>
> I don't know about the complexity, but an IDE does need to consider
> security just like any extensible application, if it is going to be
> involved with work that must be secure. Programmers work with sensitive
> data (source code!) that might be at risk. The moment we (equinox)
> start talking about the ability to dynamically load/unload components -
> especially from the web, then we are talking about all the same risks
> one has with applets.
>
> On the overhead of security permission checking, that, I believe is one
> area that should be improved in 1.4+ JRE's. Even without those
> improvements, I don't see it as a performance killer in a user-app. I
> could be wrong, but that's my gut feeling.
>
> On user-based security (authentication & access control - i.e. JAAS) I
> don't currently see a reason to incorporate that into the platform as
> eclipse is not a multi-user application. Different users of an eclipse
> install on a given machine might have different profiles and access to
> particular plugins - but that can be administered in other ways, outside
> of the scope of eclipse itself. I guess one could see a component using
> JAAS to authenticate the current user if multiple users might use the
> same account on a given machine (ex - kiosk mode) and then act
> accordingly, but the fact is that only one user would still be using the
> process instance. This is not the same as a mult-user server app where
> each thread in the app typically belongs to different users. For most
> use cases of eclipse-derived applications I would bet that it is
> sufficient to assume that the user has authenticated with the host OS in
> order to be even running the app and thus
> System.getProperty("user.name") is more than enough. Otherwise, JAAS
> support seems like it could be added as a plugin and used only on an
> application-specific basis.
>
> I stand ready to be corrected on that, of course.
>
> My concern remains with codebase security.
>
> Cheers,
>
> Mel
>
|
|
| | |
| Re: Component Model - Security? [message #12102 is a reply to message #10606] |
Mon, 10 March 2003 16:05 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
I would agree with Pascal... Eclipse is on the verge of being used
for far more things than just an IDE... but even within the IDE land,
security is a concern...
You see, so far, an IDE meant a product from a single company...
but this is no longer the case. Features may come from different providers,
working on different data sets... but within the same workspace...
Furthermore, the concept of an IDE itself is changing, adding more
communication and cooperation tools... such as chats or emails...
seems to me that I want to be able to download features but control
what they can do on my behalf in my workspace or on my machine.
Also, wouldn't it be also better for feature providers to be able
to enable/disable features based on a role rather than code structure.
I am thinking about subscriptions or test versions... it is very hard
to structure a code base for all possible marketing-related roles...
but it would be interesting to have one code base, protected from
tampering, that understands role and therefore what is available to
a subscription can be tailored in details.
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Pascal Rapicault" <pascal_rapicault@yahoo.fr> wrote in message
news:b4du8h$h15$1@rogue.oti.com...
> Also right now Eclipse is mainly used as an IDE, there are already
> many people trying to use it for other purposes than developing.
> They want to build chess game, mailers, etc...
>
> Moreover in the next version there is an attempt to:
> "Enable Eclipse to be used as a general purpose application framework"
> http://www.eclipse.org/eclipse/development/eclipse_project_p lan_2_2.html
>
> PaScaL
>
>
> "pkriens" <Peter.Kriens@aQute.se> a
|
|
| |
Goto Forum:
Current Time: Fri Aug 16 18:29:34 GMT 2024
Powered by FUDForum. Page generated in 0.06512 seconds |
] 
Search
Help
Register
Login
Home
