|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... |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???). 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. 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. but in any case until we know what it takes to open and close a connection that would be the simplest. Go ahead and also try to get some number on "how much time to open one connection to file/10 connections/ lookup a class randomly in the 10 that are there"... if you get that in time for the rewrite it would really make the work simple. marcf | |/Rickard | |-- |Rickard Öberg | _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
