marc fleury wrote: > |It's not fixed. Marc, do you remember when we were at J1 and talked to > |your french friend that said something about it being a security hole if > |it was fixed. Or something like that. > > Are you sure it is not fixed? as in you verified or as in you took what this > guy said at face value (name is jc collet btw), I wouldn't trust everything > he said :) you know we were friends and all but...
Haven't checked, but can't imagine that it's been fixed... still, would be nice with a solution that works on 1.3 too. > |I've been thinking about this problem though. Wouldn't it be possible to > |make a custom URL handler that returns a connection wrapper that we can > |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we > |can still close the file under the covers. I think that would make it > |work, and wouldn't be *that* intrusive in the code. > > sure, that is an idea and it would simplify the code a lot. The problem I > see is that I suspect they keep the connection opened for classloading > reasons, i.e. the VM asks for loading classes at random times. Reopening the > connection seems slow (the security hole would be the capability to change > the jar we look up???). That's irrelevant. It's ok that they hold on to the connection. It's not ok that there's no way to flush that cache. What our custom URL handler would buy us is that we can close the underlying connections explicitly as needed. If there's another call on the connection we would reopen it, but during the time it is closed we can replace the underlying JAR. > I guess the way this works is you would put a time out on the URL or > something, you need to make guesses as to when the vm will be done loading > from this puppy which is never in the case of JMX and SL CL architectures. Nope, just an explicit way of closing the connections and thus disregarding how the URLClassLoader connection cache does things. > A problem will be slow classloading in the JMX/SL base (it will affect 2.4 > and 3.0) as you will ask CL to look for classes in connections that are > closed....... hmmmm we are going to need smart CLs... at least with > indexing, yes... indexing of cl contents to allow for fast clusterwide > lookups.... hmmmm me likes... do you see these? is there a way to create a > default jar tvf (t being the important one here) and allowing for indexing > PER Cl, that would dramaticaly improve the speed of our superservers as well > as solve the above problem. blah blah blah... nonsense. Not a problem, see above. The only thing that's important is that we can *close* them when *we* want to. Other than that its fine that the URLCL hangs onto open connections. /Rickard -- Rickard Öberg _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
