Greg Steuck wrote:
I can give you an example of how I use versioning. Back a few years ago the OMG adopted a specification for a people, places and things. This service basically provides support for the the defintion of a user, desktop, workspace, task, message and resource. This specification was subsequently refined under a number of revision task force recommendation in which interface defintions were matured as a result of practical implementation results. Today, the specification version is 2.1. This means that I'm dealing with a version interface in which the semantics may be different between versions."Jakob" == Jakob Praher <[EMAIL PROTECTED]> writes:
Jakob> One of the problem is that the java versioning mechanism is I Jakob> think too weak. Loading is not effected by versioning since Jakob> Class.forName or ClassLoader.loadClass only take a FQCN. Versioning in general. I may be terribly off mark here and my green underbelly may be showing, but I don't understand the need for versioning. What problem is versioning supposed to solve? I see only one answer: * name space extension, in other words, not only do you specify that you need X you also specify that you want X-V. Then we add some arbitrary rules saying that V is compatible with a range of values that client specifies in during lookup (i.e. lookup for 3.0 can be satisfied by 3.anything)
Given the container component seperation, a version at the level of a service defintion lets a container handle the association of a component that it capable of providing (a) meeting the interface and (b) the semantics implied by the version.
This is not always possible. For example, the interface org.omg.Session.User is an interface that is defined by a standardization body in a published specification. There are several versions of this interface.
Versioning in Avalon.
The only place in Avalon where versioning I see applies is component
versioning. But we have better ways of determining component
compatibility: component roles. So, instead of creating versioned
interfaces we simply create *different* interfaces (java
interfaces).
The Role interface becomes fixed once and for eternity along with allThis also assumes that you can alsways control the interface defintion which is not always the case.
contracts surrounding it. Event that normally triggers incompatible
version bump up is an incompatible interfaced change, but in this case
you simply produce a *different* Role interface. The old client wouldn't
be able to use the new implementation anyway (it's incompatible).
There is a seperation implementation version and service version under the excalibur/meta package. Using this information a container can actually handle multiple providers of version serrvices in an effective manner.
http://jakarta.apache.org/avalon/excalibur/meta
Component implemetation version information can be declared at the type level using the Type class:
http://jakarta.apache.org/avalon/excalibur/meta/api/index.html
Service information is declared under the Service class:
http://jakarta.apache.org/avalon/excalibur/meta/api/index.html
Dependencies that a component has on services are declared under depedency descriptors.
http://jakarta.apache.org/avalon/excalibur/meta/api/index.html
Using the above, a container can provide complete mnangement of component implemetation versioning, different versions of services provided by a component (including multiple version support), and the handling of service assignment based on depedencies declared by a target component type.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@;osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
