On Thu, 14 Nov 2002 00:09, Jakob Praher wrote: > hi all, > > first of all: > I am a big fan of the avalon project. > I hope I can someday contribute something to the project other than > using and propagating it... ;-)
kool! > The following are ideas and questions I carry with me for a long time. > > One of the problem is that the java versioning mechanism is I think too > weak. > Loading is not effected by versioning since Class.forName or > ClassLoader.loadClass only take a FQCN. > > And, the Package class (in the reflectioning api) is only available, > when a class of that package already got loaded so you could only do > versioning by using a separate "throw away" class loader, in order to > get rid of a class that does not have the right version. right. > In avalon-framework there is that Version class. But I can't find it > elsewhere. I am using the excalibur component container and do some > cocoon programming, but maybe I have overlooked the use of this Class > inside the avalon component architecture. Please correct me here. It is used in Phoenix but it is largely unused by end users. The number of circumstances in which it is actually used is very rare - most people just leave it at default value. > I have also looked at the osgi spec (btw: there is an open source osgi > implementation I found reasently: oscar-osgi.sf.net ). > > The osgi packaging mechanism is a bundle. I didn't get all the details > of the osgi paper, so at this time I can't say anything specific about > versioning other, than it is embedded in the manifest like the weak > versioning spec of j2se 1.3+ (i think). The manifset is used to specify > the version as well as the import and export dependencies. Phoenix does something similar in that it uses the Extension/Optional Package architecture. For documentation on this you can refer to http://jakarta.apache.org/ant/myrmidon/librarys.html#Dependencies > Way all this? > I would like to see a mechanism, by which java distinguishes the classes > of specific versions, or better by which java uses modules ( or > assemblies, plugins, bundles (however you call them) ) in its core. > You see things like these coming out of every larger java community: Extensions are part of Servlet/EJB spec so I would expect to see them adopted more in the future. > Perhaps I am totally wrong here, and too many mandatory specifications > are wrong, as they kill the openness java has proven, but I think it is > a pitty that the jcp (or sun) has not better specified a mandatory way > to do versioning and module loading. They do - it is just not widely used ;) > what are your thoughts about the versioning dilemma? I think the Extension mechanism provides enough infrastructure to build on. It has a few uglies but nothing that can not be worked around. What we (as in Avalon) need is a packaging specification that builds on Extension mechanism and also includes a descriptor that describes services, components and various other resources contained within a jar. There is work going to resolve this but it is going slow - mainly to make sure we don't make any mistakes. -- Cheers, Peter Donald --------------------------------------------------- Murphy's law - "Anything that can go wrong, will." (Actually, this is Finagle's law, which in itself shows that Finagle was right.) --------------------------------------------------- -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
