avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <jpra...@yahoo.de>
Subject Re: services, bundles and versioning
Date Thu, 14 Nov 2002 13:49:17 GMT
hi,

thanks for your reply,
Am Don, 2002-11-14 um 01.13 schrieb Greg Steuck:
> >>>>> "Jakob" == Jakob Praher <jp@hapra.at> 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.

it's always good to question such abstract terms.
but given that I see versioning like this:

what I think is not the problem are versions that are not substituable,
ie which break compatibility to another api.
I would sugest here too, to use another package name, to denote such a
change.

but just think about minor changes to a component (which by definition
obeys to an interface contract) which would improve performance or
something like that.

this is where versioning comes in handy.
you have component A that uses B.
Now there is a new version of B, that is compatible to the one A used at
start. 
(I like it how the org.apache.avalon.framework.Version class implements
this semantics )

now it would be great for A to say:
ok I want the newest and Best version for the B compoennt that is
compatible with the original B component I use.

this would also ease the way module loadinng works.

I think it is a burden that should be on the implementor, to say which
version of which component is compatible to another, but if you don't
specifiy it, the deployer must decide which version of which modules or
bundles to keep around. This makes deployment a messy thing.

plus I think versioning should not be done on a per class basis (just as
you release components (like xalan, xerces) in jar bundles of classes),
the version should state the version of the bundle as a whole.


> 
> 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)

ok.
if you mean on a bundle basis - it's ok. on a class basis it can be
cumbersome to implement.

note: by bundle I mean module or plugin, or assembly ...


but a more cop way would be interesting too:

a simple interface:

interface Version {
        /* or getRole( ) */
	String  getSpecificationID( ) ;
	boolean isCompatibleWith( BundleId, Version x ) ; 

}

and an implementation in the module, which by default has
metainformation, e.g. a manifest or something like that.


 Bundle-Specification:	aa-abbb--cc--cas        #a unique bundle id

 #which takes care of answering version question, 
 #implements the Version interface 
 Version:		org.my.impl.VersionImpl 

the question here is if a mechanism like this can be implemented
efficiently in the current jar loading policy.
you probably have to override the classloader to only load that
VersionImpl out of the jar file and forget the rest for the checking of
the versioning.

if it maches than you can load the jar.
I would also suggest that every bundle has a unique id, a bundle
specification id which is the same for minor version but differs for
major version.

or in avalon terms: a bundle role id....

the bundle id is used to sort out the bundles which are totally
differnent and not compatible to the bundle needed. (this should speed
up things a bit ).

just my $0.02

> 
> 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 all
> 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).
> 
> What's wrong with this model? 

okay I get your point.

but then you also have a configuration of, say the excalibur container,
or the new fortress (which I really like) and have:

<component role="x.y.z" class="a.b.c" />

now the problem is again that you have only the FQCN to denote the
identity of the implementation, and the Excalibur Container loads it by 

Class.forName( "a.b.c" );

so there is no way the VM can tell you whether to prefer bundle A or
bundle B, which both provide the class "a.b.c"


> 
>     Jakob> And, the Package class (in the reflectioning api) is only
>     Jakob> available, when a class of that package already got loaded so
>     Jakob> you could only do versioning by using a separate "throw away"
>     Jakob> class loader, in order to get rid of a class that does not
>     Jakob> have the right version.
> 
> And class level is not the right place to put versioning at all in my
> view. Moreover, having explicit versions specification in the code is a
> plain violation of IoC (or so my understanding of IoC tells me).
> 
yes that's true. I totally agree with you.

>     Jakob> this (.NET) I think ressembles more the shared object (or
>     Jakob> dll) view, where you first load the shared object and then
>     Jakob> look into the shared object to find the function pointer (or
>     Jakob> in our case the type).
> 
> Anybody else feeling that those are hacks from pre-historic era of
> weakly typed dynamic libraries don't apply anymore?
> 
>     Jakob> and the problem is you have to wrap everything to be used in
>     Jakob> netbeans, to be used in osgi and to be used in eclipse in a
>     Jakob> different way.
> 
> Most likely because they have totally different component models, no?
> 
granted, but there is something that applies to all:

* bundling of classes and interfaces
* versioning and compatibilty checking

for instance:

org.netbeans.modules.ModuleInfo
	has 
		getCodeNameBase( ) /* the module name */
		getImplementationVersion( )  /*the version of the impl*/
		getSpecificationVersion( ) /* the version of the spec */
	
org.eclipse.core.runtime.IPluginDescriptor 
	has
		getPluginVersionIdentifier( )	/* the versioning of the plugin */
		getUniqueIdentifier( ) /* the unique id of the plugin */
		

org.eclipse.core.runtime.PluginVersionIdentifier
	has
		getMajorComponent, getMinorComponent, ...
		isEquivalentTo( PluginVersionIdentifier rhs )
		isCompatibleWith( PluginVersionIdentifer rhs )


and this could be abstracted in a core. ( I like the eclipse framework)

plus it is only useful when everybody agrees on it. 
that is my criticism on the current java way - it can be done and is
implemented but differently in different environments.

> Thanks
> Greg
> 
> --
> To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message