--- Dominique Devienne <[EMAIL PROTECTED]> 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 type:stringRepresentation. 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? -Matt > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
