RE: [JBoss-dev] Removal of UnifiedClassLoader.getURLs override was invalid
|This change to UnifiedClassLoader: |removed invalid getURLs() method. Not sure why we want to return null | for a URLClassLoader. Comments suggested it was to avoid some |RMI bloat, | but code that expects a URLClassLoader will expect that this baby will | return something valid. It certainly won't expect a null. If this | behavior of masking the url list is trully desired, then return new |URL[0], | but I suggest that is also invalid, since a URLClassLoader with no URLS |is | a wasted object... what does one load from it... IMHO (ok not so humble) | it is best not to obfuscate here. | |breaks dynamic class loading and does cause bloat of serialized RMI |objects as well as MarshalledObjects. Do not rip out code you do |not like unless you really understand why it was there. maybe we should isolate the ucl as critical code marcf | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Removal of UnifiedClassLoader.getURLs override was invalid
Great, also let me add that we have the capacity to add a unified codebase so we would have one URL, this would make the dynamic loading easier marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jung |, Dr. Christoph |Sent: Sunday, February 17, 2002 11:42 PM |To: 'Jboss-Development' |Subject: AW: [JBoss-dev] Removal of UnifiedClassLoader.getURLs override |was invalid | | |Hi! | |see my previous discussion with Marc and Oleg. | |IMHO, a clean solution to the RMI bloat problem would be to build different |MarshalledInput/OutputStreams for non-dynamic classloading |environments that |do not annotate classes (and do not call URLClassLoader.getUrls()) and to |have dynamic classloading streams that are taylored to our unified |deployment scenario (find out exactly which URL[1] belongs to a class |instead of prophylicatically sending all the classpath). | |If I understood it right, Oleg has already some code in that respect and |wanted to |change that. | |CGJ | |-Ursprüngliche Nachricht- |Von: Scott M Stark [mailto:[EMAIL PROTECTED]] |Gesendet: Sonntag, 17. Februar 2002 22:12 |An: [EMAIL PROTECTED] |Betreff: [JBoss-dev] Removal of UnifiedClassLoader.getURLs override was |invalid | | | |This change to UnifiedClassLoader: |removed invalid getURLs() method. Not sure why we want to return null | for a URLClassLoader. Comments suggested it was to avoid some |RMI bloat, | but code that expects a URLClassLoader will expect that this baby will | return something valid. It certainly won't expect a null. If this | behavior of masking the url list is trully desired, then return new |URL[0], | but I suggest that is also invalid, since a URLClassLoader with no URLS |is | a wasted object... what does one load from it... IMHO (ok not so humble) | it is best not to obfuscate here. | |breaks dynamic class loading and does cause bloat of serialized RMI objects |as well as MarshalledObjects. Do not rip out code you do not like |unless you |really understand why it was there. | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | | | |___ |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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Removal of UnifiedClassLoader.getURLs override was invalid
I have been looking at this as well. What code do you have Oleg? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jung , Dr. Christoph [EMAIL PROTECTED] To: 'Jboss-Development' [EMAIL PROTECTED] Sent: Sunday, February 17, 2002 11:42 PM Subject: AW: [JBoss-dev] Removal of UnifiedClassLoader.getURLs override was invalid Hi! see my previous discussion with Marc and Oleg. IMHO, a clean solution to the RMI bloat problem would be to build different MarshalledInput/OutputStreams for non-dynamic classloading environments that do not annotate classes (and do not call URLClassLoader.getUrls()) and to have dynamic classloading streams that are taylored to our unified deployment scenario (find out exactly which URL[1] belongs to a class instead of prophylicatically sending all the classpath). If I understood it right, Oleg has already some code in that respect and wanted to change that. CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Sonntag, 17. Februar 2002 22:12 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Removal of UnifiedClassLoader.getURLs override was invalid This change to UnifiedClassLoader: removed invalid getURLs() method. Not sure why we want to return null for a URLClassLoader. Comments suggested it was to avoid some RMI bloat, but code that expects a URLClassLoader will expect that this baby will return something valid. It certainly won't expect a null. If this behavior of masking the url list is trully desired, then return new URL[0], but I suggest that is also invalid, since a URLClassLoader with no URLS is a wasted object... what does one load from it... IMHO (ok not so humble) it is best not to obfuscate here. breaks dynamic class loading and does cause bloat of serialized RMI objects as well as MarshalledObjects. Do not rip out code you do not like unless you really understand why it was there. Scott Stark Chief Technology Officer JBoss Group, LLC ___ 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Removal of UnifiedClassLoader.getURLs override was invalid
This change to UnifiedClassLoader: removed invalid getURLs() method. Not sure why we want to return null for a URLClassLoader. Comments suggested it was to avoid some RMI bloat, but code that expects a URLClassLoader will expect that this baby will return something valid. It certainly won't expect a null. If this behavior of masking the url list is trully desired, then return new URL[0], but I suggest that is also invalid, since a URLClassLoader with no URLS is a wasted object... what does one load from it... IMHO (ok not so humble) it is best not to obfuscate here. breaks dynamic class loading and does cause bloat of serialized RMI objects as well as MarshalledObjects. Do not rip out code you do not like unless you really understand why it was there. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Removal of UnifiedClassLoader.getURLs override was invalid
Hi! see my previous discussion with Marc and Oleg. IMHO, a clean solution to the RMI bloat problem would be to build different MarshalledInput/OutputStreams for non-dynamic classloading environments that do not annotate classes (and do not call URLClassLoader.getUrls()) and to have dynamic classloading streams that are taylored to our unified deployment scenario (find out exactly which URL[1] belongs to a class instead of prophylicatically sending all the classpath). If I understood it right, Oleg has already some code in that respect and wanted to change that. CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Sonntag, 17. Februar 2002 22:12 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Removal of UnifiedClassLoader.getURLs override was invalid This change to UnifiedClassLoader: removed invalid getURLs() method. Not sure why we want to return null for a URLClassLoader. Comments suggested it was to avoid some RMI bloat, but code that expects a URLClassLoader will expect that this baby will return something valid. It certainly won't expect a null. If this behavior of masking the url list is trully desired, then return new URL[0], but I suggest that is also invalid, since a URLClassLoader with no URLS is a wasted object... what does one load from it... IMHO (ok not so humble) it is best not to obfuscate here. breaks dynamic class loading and does cause bloat of serialized RMI objects as well as MarshalledObjects. Do not rip out code you do not like unless you really understand why it was there. Scott Stark Chief Technology Officer JBoss Group, LLC ___ 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
