commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Florey" <daniel.flo...@web.de>
Subject AW: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Date Tue, 21 Dec 2004 20:51:56 GMT
Thanks for the links. Do you know if there is a maven task to automatically
generate this manifest entries based on the project.xml? 
If not this might be a first step in order to allow easy adoption for the
upcoming assembly-component ;-)

> -----Urspr√ľngliche Nachricht-----
> Von: commons-dev-return-64891-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-64891-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Craig McClanahan
> Gesendet: Dienstag, 21. Dezember 2004 21:28
> An: Jakarta Commons Developers List
> Betreff: Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
> 
> Don't forget to do a little light reading first :-)
> 
> Mechanism to declare dependencies in a MANIFEST.MF File:
> 
>   http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html
> 
> ClassLoader implementation for representing an "Assembly":
> 
>   http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLClassLoader.html
> 
> Craig
> 
> 
> 
> On Tue, 21 Dec 2004 14:34:56 -0500, Matt Sgarlata
> <sgarlatm@users.sourceforge.net> wrote:
> > Count me in!  I'm planning on taking some time off for the holidays, so
> > that should give me time to play around with this :)
> >
> > Matt
> >
> > Daniel Florey wrote:
> > > <snip/>
> > >
> > >>>an application using 1.x.b will work with component 1.x.a
> > >>>Does this sound reasonable? Missed something?
> > >>
> > >>Have you seen the guidelines in use by the Apache APR project?  It
> looks
> > >>to me like you're basically advocating the same system they have in
> > >>place.  It might save us hassle to just adopt their version numbering
> > >>system whole-sale (as the Spring Acegi Security subs(ystem does)
> > >>
> > >>http://apr.apache.org/versioning.html
> > >
> > >
> > > Very funny - looks pretty identical to me ;-) So, yes, let's adopt
> this.
> > > I've not played around with classloading a lot, so I'm very curious if
> this
> > > will work. I'll try to start working on this if I'll find the time for
> it.
> > > If you are interested I could setup an account for you at my personal
> root
> > > server (I've installed Subversion). Or should I create a subproject in
> the
> > > commons-sandbox?
> > > As it's in stage of brainstorming I'd prefer to do it in my personal
> space
> > > first.
> > > Are you interested?
> > >
> > > Cheers,
> > > Daniel
> > >
> > >
> > >>>I'd prefer to keep the "jar" naming as introducing "assembly" would
> > >>
> > >>cause
> > >>
> > >>>some confusion.
> > >>>If anyone would be interested I could put a simple proposal to the
> > >>
> > >>sandbox.
> > >>
> > >>Good point, JAR may be a better name.  I see two benefits to using
> > >>"assembly" or "assembler" as the name:
> > >>- Clearly indicates that you aren't dealing with plain-old-JAR files
> > >>anymore
> > >>- Parallels name used in .NET so that the analogy is directly obvious
> > >>
> > >>
> > >>>This approach will not address the trouble that may be caused by
> > >>>applications not using this package. So finally I think that it is
> > >>
> > >>required
> > >>
> > >>>that this feature (or something comparable) will make it into Java
> 1.6.
> > >>>Up to then I still think it's a very simple but easy way to add the
> > >>
> > >>version
> > >>
> > >>>number to the package names to avoid at least the very big problems
> > >>>concerning incompatible jars in the same classloader.
> > >>
> > >>I understand your reasoning behind putting this code in Java 1.6, but
> I
> > >>think we can do this without a new release of the Java language (see
> > >>below).  If our ideas are successful, this new Commons component could
> > >>always migrate later to a JSR proposal, as Doug Lea's concurrent
> package
> > >>did.
> > >>
> > >>With regards to problems caused by components that aren't using this
> new
> > >>package, I'm thinking that as long as the component does not make any
> > >>Class.forName calls, we should be OK.  If there are Class.forName
> calls,
> > >>the component may still be able to work, but we would strongly
> encourage
> > >>a migration to using Assembly.getType or whatever.  This entails the
> > >>component introducing a dependency on Assembler, which means the
> > >>Assembler API will need to maintain backwards compatability as much as
> > >>possible (e.g. - imagine the nightmare that would ensue if
> > >>java.util.Vector were to change its semantics!)
> > >>
> > >>
> > >>>Regards,
> > >>>Daniel
> > >>
> > >>Matt
> > >>
> > >>
> > >>>>-----Urspr√ľngliche Nachricht-----
> > >>>>Von: commons-dev-return-64857-
> daniel.florey=web.de@jakarta.apache.org
> > >>>>[mailto:commons-dev-return-64857-
> > >>
> > >>daniel.florey=web.de@jakarta.apache.org]
> > >>
> > >>>>Im Auftrag von Matt Sgarlata
> > >>>>Gesendet: Dienstag, 21. Dezember 2004 13:04
> > >>>>An: commons-dev@jakarta.apache.org
> > >>>>Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares
> > >>>>
> > >>>>Chris Lambrou wrote:
> > >>>>
> > >>>>
> > >>>>>Matt Sgarlata wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>Does this mean .NET doesn't have reflection?  That's such
a killer
> > >>>>>>feature of Java; I can't believe they wouldn't have ported
it to
> .NET.
> > >>>>>>Any .NET developers out there that can tell us how .NET
deals with
> > >>>>>>reflection when you have multiple versions of the same class?
> > >>>>>
> > >>>>>
> > >>>>>Since the class name alone is insufficient to fully identify
a
> specific
> > >>>>>version of a class, to my knowledge there is no equivalent to
> > >>>>>Class.forName(String classname) in .NET. Instead, .NET has the
> Assembly
> > >>>>>class. An Assembly is roughly akin to a java jar file, and is
> typically
> > >>>>>a single DLL that contains one or more classes. Assembly has
a
> > >>>>>non-static getType(String typeName) method, that performs the
same
> job
> > >>>>>as the static Class.forName(String classname) method in java,
but
> for a
> > >>>>>specific Assembly instance. There is never any ambiguity over
which
> > >>>>>version of the named Type that is returned, since an Assembly
can
> only
> > >>>>>contain one version of any given class. Support for multiple
> versions
> > >>
> > >>of
> > >>
> > >>>>>a class at runtime is achieved by storing those multiple class
> versions
> > >>>>>in separate Assemblies.
> > >>>>
> > >>>>Thanks for the info, Chris!  This definitely sounds like a good
> > >>>>approach.  Now my question is, can we simulate this in a new commons
> > >>>>component? :)
> > >>>>
> > >>>>Here are the steps I would imagine to be involved:
> > >>>>1) Define our own JAR sub-type to mirror the .NET assembly notion.
> > >>>>Include some type of a plain-text file that describes the versions
> of
> > >>>>the software required to perform certain tasks.  It would be nice
to
> do
> > >>>>this in an existing structure like MANIFEST.MF, but I don't know...
> are
> > >>>>you allowed to add arbitrary information to that file?  In any case,
> we
> > >>>>wouldn't use the existing dependency descriptors because that would
> > >>>>prevent multiple versions of the same class from being loaded.
> > >>>>2) Call org.apache.commons.assembler.Assembler.getType(String
> > >>>>assembledPackage, String className).  The Assembler would then go
to
> the
> > >>>>assemblyPackage path on the classpath and search the plain-text
file
> > >>>
> > >>>>from step #1 which would list the versions of classes that are
> required
> > >>>
> > >>>>by the given assembledPackage.  For example, if assembledPackage
was
> the
> > >>>>Digester, which required collections 3, the assembledPackage would
> be
> > >>>>org.apache.commons.digester.  A dynamic proxy or generated bytecode
> > >>>>would be loaded that fulfilled the given contract and that would
be
> > >>>>returned to the client.  Any existing code that is just calling
> > >>>>Class.forName would have classes looked up in the normal way, so
we
> > >>>>would need to make sure that this dynamic proxy doesn't get loaded
> into
> > >>>>the JVM in the same way as Class.forName (this is where the dynamic
> > >>>>proxy and/or bytecode generation comes in)
> > >>>>
> > >>>>What do you guys think?  Does this sound feasible?  I'd rather spin
> this
> > >>>>as a commons component than a J2SE 1.6 enhancement request, because
> the
> > >>>>later will take years to come to fruition.
> > >>>>
> > >>>>
> > >>>>
> > >>>>>Chris
> > >>>>
> > >>>>Matt
> > >>>>
> > >>>>
> > >>>>--------------------------------------------------------------------
> -
> > >>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > >>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >>
> > >>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message