Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Sender: greg@home.nest.cx
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Subject: Re: services, bundles and versioning
References: <1037192966.988.59.camel@jaques2>
From: Greg Steuck <greg-avalon-dev@nest.cx>
Date: 13 Nov 2002 16:13:46 -0800
In-Reply-To: <1037192966.988.59.camel@jaques2>
Message-ID: <86heelxb2d.fsf@home.nest.cx>
Lines: 62
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>>>>> "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.

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)

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? 

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

    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?

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>