On 2001.11.27 13:34:31 -0500 marc fleury wrote: > > > |-----Original Message----- > |From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] > |Sent: Tuesday, November 27, 2001 12:57 PM > |To: marc fleury; Rickard Öberg > |Cc: [EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] Installer / Deployer Problem > | > | > |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 > > It really slows down large deployment. Copying 2 meg is just bad. Again > packaging madness. > > |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 ? > > it's a point, I don't care either way. But when do you need to "inflate" > and why? refresh my memory
You may not need to inflate a jar, but rar, ear, and now sar have jars inside them. Unless someone can come up with a way to get classes out of them using a jar:jar:jar:http://.....!/!/!/ url we need to unpack them. If network speed is the problem here, how can it possibly be faster after deployment to use a remote url rather than a local copy? Otherwise are you sure it is file copying that is taking the time? So far I agree with Andy. david jencks > > marcf > | > |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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
