> on 10/4/2000 3:52 PM, "Ed Korthof" <edk at collab dot net> wrote:> > > where it's from. If I've got to look through the classpath, then I have> > to reconstruct that and look through a bunch of .jar files -- painful &> > somewhat more error prone. It also requires me to use a shell account to> > poke around the live system.> > I don't get *why* this is error prone and difficult though...> > #1. You know what class is the problem (you said "given class" above).> > #2. You know it must exist in one of two .jar's for which you know which one> it is. > > #3. You look at which .jar comes first in the classpath.> > Problem solved in 3 easy steps.

#1 : This requires a shell login on the live machine. This is somethingto be avoided (in the long term, right now it's still needed)

#2 : I've no reason to believe that instanciations and applications willalways have only one jar file.

#3 : Hitting a servlet w/ authentication to get this information is fasterand simpler, and still less error-prone.

> > OTOH -- if I can use the JVM to figure out where a given class is from,> > then my debugging of this hypothetical problem is much easier.> > Ok, so you are going to spend time writing code to give you the solution.> Sorry, but that sounds a lot more painful than simply looking at the> classpath.

Umm ... the code is simple, and it's not a complext task; and afterwardsmy life will be just slightly easier. I'm willing to make investments inadvance to make my life easier later.

> Now, that also only tells you which class is being used...not even> necessarily *why* and either way, you are going to have to come back and fix> the classpath issue so you are back at square one.

In the scenario which I presented, the problem wasn't that the wrongversion was getting loaded, but that the version getting loaded had a bug.What is important is to figure out where that version lives, fix the codebase containing it, and upgrade.

> > I'm with Manoj in believing that this scenario is one we should avoid in> > the first place, by not overriding classes. However, that is *not* the> > current plan: the current *design* for how to do instanciations includes> > overriding some but *not* all files in joist/helm/etc. Because of that, I> > think this offers a compelling advantage.> > > > Unless you want to try to convince people to avoid overriding classes,> > ever. I'd be with you, but I've no time left to fight that fight. <sad> > smile>> > Right...that is also a really bad aspect of this whole thing...Why aren't> these classes defined in property files instead so that they can be easily> swapped out?

I agree with you on this wholeheartedly -- configuration is the rightplace for this kind of customization, not code. OTOH -- there are somecomplexities involved, as we'd also need to add interfaces for theclasses & so on. But I've argued for this (I just gave up 'cause it's notmy area, and I've enough to worry about already).

> If you are going to spend all the time added $Id: $ to the files and writing> code to figure out which class is loaded, you might as well spend the time> going through the code base and use> Class.forName(props.​getString("class.i.r​eally.want.to.instan​tiate")).newInst> ance() as a real solution instead. In fact, you can probably do regex> replacements in the code to get the above effect.

We're really not talking about that much additional time to do what lucasis talking about; at this point, we've probably spent more time arguingthan it'd have taken.

OTOH -- using interfaces & Class.forName() [or the Java 1.1 equivalent,which is ugly as sin] would take some time. I don't have time to do thatright now ...