ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: Resource.getURL()
Date Thu, 21 Sep 2006 16:01:17 GMT
--- Dominique Devienne <> wrote:

> > > Concerning custom URLProtocolHandler (s), I am
> not clear how this works ?
> > first you provide something that lets you open
> connections [...]
> FTR, I'm not to fond of this idea of playing with
> custom URL protocols
> and/or handlers, at least as far as I correctly
> understood what it
> means.
> I used to use one before <import> came along, using
> a resource:
> protocol to locate XML entity includes more
> flexibly, and it worked
> fine, except for the fact that it needed JVM args
> required during JVM
> startup. Installing the custom URL handler once the
> VM is already
> started is more involved, and if I remember
> correctly, involves having
> one's own factory for URL handlers, which is bound
> to conflict with
> Ant "containers" who also want to install their own.
> I think when Resources where first introduced to Ant
> we briefly
> discussed why we needed them instead of using
> straight URLs, which is
> a well documented and extensible mechanism to access
> content, but an
> argument against using URLs was that extending URL
> protocols is not
> easy.

Okay, I've never used the custom protocol handlers,
only read about them.  I have no problem taking the
word of others that there may be difficulties; I do
however have a hard time accepting a verdict of
"impossible" where any programming problem is
concerned.  At the same time I realize our time is not
unlimited.  :)

> I'm fine with adding getURL to Resources, if it's an
> optional
> operation (returning null is not supported or
> throwing UOE but only is
> another supportsURL() boolean method is available),

Let me interject on that thought.  Currently
Resource.getInputStream()/.getOutputStream() throw UOE
in the base implementation, without related pre-check
methods as you mention above.  It may be a good idea
to add these.  The base implementation of these
checkers could either return false, leaving it to the
subclasses to override, OR the base implementation
could call the related get...() method; catch any UOE
and return false, or close() the stream if
successfully retrieved.  Preferences, anyone?  Back to
the subject at hand:

> but I can't see
> the need for custom URL protocols. I'm open to
> arguments showing me
> where I'm wrong though, of course. --DD

Okay.  Just to make sure everyone is familiar with the
-reason- for the current proposal, remember that we
made Resource support getting an OutputStream as well
as an InputStream.  The thought here was that we would
be able to write to arbitrary Resources including e.g.
properties.  The problem is how to specify to a task
that you want a single Resource to be the destination
for whatever output it is going to create.  Normally
it would make sense, when you have a singular item, to
use a Java setFoo(Bar); or in Ant/XML, an attribute. 
So the problem is, how do we string-encode a resource
such that we can make a rule in IH to decode that
resource from the string attribute value?  The only
options I see are:

(a) custom URL protocols
(b) the pseudo protocol syntax of

Maybe (b) is the way to go after all; it would use
ComponentHelper and thus would require little to no
extra work on the part of the Resource implementor...

Are there other options I have missed?


> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message