> -----Original Message----- > From: Dominique Devienne [mailto:[EMAIL PROTECTED] > Sent: Monday, 25 September 2006 10:28 AM > To: Ant Developers List > Subject: Re: Resource.getURL() > > > > This surprises me. You're positive you can change the system's > > > classloader classpath dynamically just by assigning to > this property? > > > The system property 'java.system.class.loader' is used to > declare the > > name of custom system classloader class. [...] But as I > pointed out, > > this is a JRE 1.4 feature. > > Thanks for the precision. I missed the .loader part of the > property name, my mistake. OK, you are replacing the default > system class loader with your own. But I'd assume > 'java.system.class.loader' is thus a sys pty you need to > specify at startup then, no?
Correct. > > > b) declaration of the package paths under the > > 'java.protocol.handler.pkgs' system property - which is > > more flexible in that the property value is mutable and > > can be updated/extended at runtime > > Ah, again I didn't know about that. Thinking back, I probably > needed to specify it on the command line because the custom > protocol I was declaring was used in XML entity includes, so > used during the parsing of the build file, and thus before > I'd have the chance to change sys properties with Ant. > > > This is principal reason why I suggested the approach > > related to the 'java.protocol.handler.pkgs' property as > > this does not interfere with nor depend on any > > URLStreamHandlerFactory declaration. > > I like that, but if I read you correctly, you still need the > special sys class loader to locate these handlers if they are > not already on the sys class path, which implies replacing > the sys class loader, something problematic for embedded use of Ant. Modification of the content of the system classloader is possible using if the system classloader is derived from URLClassLoader via reflective invocation of the 'addURL' operation. As such usage of a special system classloader is not prerequisite (it is simply a better way of controlling dynamic modification of classes accessible by the system classloader). However - playing around with the system classloader may not be necessary (see notes towards the end of this message). > All that said, to come back to Resource, as I previsouly > wrote, you can already use any URL as a resource in the build > file. Resource is akin to URL in the sense that it allows you > to get access to streams. > The question is why would you need to get back a URL from a Resource? > I'm not sure yet. Maybe we should have a Resource.getURL but > rather a URLResource.getURL. I still don't see the point of > forcing all Resources to be URL-based. > > "Normal" protocol URLs (file:, http:, etc...) are often > "absolute", in that they are context-free. The URL name is > all you need to get back at the same streams. Resources on > the other hand, like a resource on the classpath, is not > "absolute", and will give you different results depending on > which classpath is used. The resource "name" is not enough in > itself to locate the streams. Sure you can wrap a single Ant > property value (just a String) into a URL using some custom > handler, but again the URL name (or path if you want) is > meaningless. This is this fondamental distinction between > URLs and Resources which make me reluctant to add a getURL > method to the base Resource type (interface, abstract class, > I don't remember). Some thoughts after digging though Resource and associated classes ... Of particular interest to me is the ability to declare resources that can be used as arguments to a Path definition - however, as things currently stand the Path datatype explicitly excludes resource collections that are not file based (which seems to me to defeat the purpose of Resource - but I'm hoping this is resolvable). Aside from that - I've been looking at the URLResource class and have an idea about how url-based resources that use custom protocol handler could be declared without impacting the system classloader definition. I think it would be feasible to declare a URLResource using the following arguments: 1. the resource name 2. the resource uri 3. the URL handler classname 4. a reference to an identifiable classloader containing the handler class With the above information a handler class would be resolvable from the classloader, a handler instance created using handlerClass.newInstance(), and the url created using new URL( null, uri, handler ). To break this a bit further - we could image a class named ClassResource (possibly derived from JavaResource) that allowed association of a name with a classname and classpath and exposing an operation to retrieve the target class. A URLResource could then be created using: new URLResource( name, uri, handlerClassResourceName ); The upside of this approach is the elimination of the entire subject of system classloader mutation, and a framework for binding custom handlers (which resolves some of the earlier issues raised in this thread). WDYT? Cheers, Steve. -------------------------- Stephen McConnell mailto:[EMAIL PROTECTED] http://www.dpml.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
