Hello Oleg,
But I think that the getURLs() method of the new class (that will subclass
URLClassLoader), will only return the http://... URL from where code can be
downloaded. The method will not prompt every classloader in the chain for
their URLs.
The goal of this new class is (almost) only to override the behaviour of the
getURLs method to return only a single URL.
HTH. Cheers,
Sacha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Oleg
> Nitz
> Envoye : jeudi, 7 juin 2001 19:32
> A : Scott M Stark
> Objet : Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network
> traffic
>
>
> Hi Scott,
>
> Thanks for your answer.
> I am afraid you speak about another problem.
> At least I don't believe that the problem that I'm speaking about
> can be solved in a subclass of URLClassLoader.
> If MarshalledObject gets an object in the constructor,
> which is loaded by any subclass of URLClassLoader,
> MarshalledObject calls getURLs() on it and stores the result inside
> itself, so that the array of all URLs from client's classpath is sent
> to the server together with each minor parameter, and all URLs from
> the server's classpath are sent to client together with each return
> value (if its class is not in the system classpath).
> Just to make it clear: currently we are not going to use dynamic class
> loading at all, we have all needed classes on the client,
> we are anxious about the unnecessary network traffic.
> And this traffic is absolutely stupid, to be honest :-)
>
> Oleg
>
> Scott M Stark wrote:
> > This really should be fixed by having a new URLClassLoader subclass that
> > returns the java.rmi.server.codebase so that code can be
> properly downloaded
> > to the clients while still loading classes from the local urls.
> This fixes
> > the current
> > dynamic class loading problem. I have a solution based on what Vlad and
> > Sacha
> > had mentioned in their investigation of the problem that I'm
> going to commit
> > next
> > week.
>
> > ----- Original Message -----
> > From: "Oleg Nitz" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, June 07, 2001 9:27 AM
> > Subject: [JBoss-dev] MarshalledObject + URLClassLoader = huge network
> > traffic
>
>
> >> Hi,
> >>
> >> We've noticed the enormous traffic between client and server.
> >> Investigation showed that the problem is in MarshalledObject:
> >> "...classes are annotated with a codebase URL from where the class can
> >> be loaded (if available)", which means that when the enclosed
> >> object was loaded via URLClassLoader, then the list of all URLs of the
> >> classloader is enclosed in the MarshalledObject instance.
> >> This list includes full names of all jar-files residing in the local
> >> filesystem, in any case they can't be used on the remote computer.
> >> In our project we use URLClassLoader in the client application,
> >> JBoss and underlying JMX library use it as well, the result is awful.
> >> My proposition to JBoss developers: to introduce own class which would
> >> do the same things as the standard MarshalledObject class, but will
> >> not enclose the URLs list,
> >> or will contain only non-"file:" URLs ("http:", "ftp:"),
> >> which can be used on the remote machine, at least theoretically.
> >> I will implement this idea when/if it meets with approval.
> >> Comments are appreciated.
> >>
> >> Oleg
> >>
> >>
> >>
> >> _______________________________________________
> >> Jboss-development mailing list
> >> [EMAIL PROTECTED]
> >> http://lists.sourceforge.net/lists/listinfo/jboss-development
> >>
>
>
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
