Yes, we had this pretty commonly in OWB. You might get funny strings like "wsjar:///..." as URL.toExternalForm() :( Basically all Systems which do not use the native file system but an own virtual files system implementation for storing apps, like JBossAS, WebLogic, WebSphere, etc
For storing URLs in a map you need to do special tricks :( LieGrue, strub ----- Original Message ----- > From: "Honton, Charles" <charles_hon...@intuit.com> > To: Commons Developers List <dev@commons.apache.org>; Mark Struberg > <strub...@yahoo.de> > Cc: > Sent: Thursday, June 7, 2012 1:59 AM > Subject: Re: [classscan] new URL(xxx) and it's problems > > > I did originally use URLs. Due to the ugliness Mark alludes to, I moved > to URIs. The biggest performance consideration was using a URL as a Key > to a map. That completely blew up performance. > > Does anyone have a concrete example of !url.equals(new > URL(url.toExternalForm()) ? > > Thanks, > Chas > > > On 6/6/12 1:13 PM, "Mark Struberg" <strub...@yahoo.de> wrote: > >> Hi! >> >> I've now looked through both impls and both share some very similar API >> classes obviously (MetaClass, MetaField, etc). Details are different, but >> I think we can extract a common API. >> >> One thing I figured while looking at the code is that some parts are full >> with URI handling instead of URL. >> The problem with this is that an URI#toURL() internally does a new >> URL(uri.toString()); >> >> >> Now the problem hereby is that on some systems a >> >> >> URL u = someResource.getURL(); >> URL u2 = new URL(u.toExternalForm()); >> >> doesn't work. Those methods are just not reflexive on some systems. >> >> >> This happens often if VFS are involved (e.g. on JBossAS4,5,6, WebLogic, >> etc) and even in general on some OS (Solaris 10.5/Sparc). >> >> >> The only way I know to cope with it is to _not_ only store the String >> representation but the URL itself. This sucks big times as well, because >> URL is a class which escaped from hell - doing DNS lookup on equals() and >> other weird things *shudder* - but I don't know of any better way :( >> >> Any tip is welcome. >> >> LieGrue, >> strub >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
