Don't you get to this same result by creating your own URLClassLoader for each "assembly", with its own set of JARs and/or directories making up its "class path"?
Craig On Tue, 21 Dec 2004 07:03:50 -0500, Matt Sgarlata <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
