Hi I don't see the point here. The copying of the file is done when it get deployed and this is a rare occurance. When you now have to open/close the connection to the URL then it can affect the overall performance which I think is the worse that to copy the file. Also the file must inflated anyway and do I miss something ?
Andy ----- Original Message ----- From: "marc fleury" <[EMAIL PROTECTED]> To: "Rickard Öberg" <[EMAIL PROTECTED]> Cc: "Andreas Schaefer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 9:13 AM Subject: RE: [JBoss-dev] Installer / Deployer Problem > |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
