|-----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
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
