You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2006/09/21 06:34:08 UTC
Re: Resource.getURL()
On Wed, 20 Sep 2006, Matt Benson <gu...@yahoo.com> wrote:
> --- Antoine Levy-Lambert <an...@gmx.de> wrote:
>
>> Hello Matt,
>>
>> thanks for fixing my fixes !
>>
>> did you already add getURL() to all Resource(s) ?
>> this would be cool to be able to always set the
>> SystemId in case of XML documents of all sorts.
>
> I have been thinking it might make sense to add
> getURL() to Resource. Did a discussion on that
> already take place?
I don't remember any.
Given that Resource as a class and not an interface we are able to add
new methods even after 1.7.0 without running the risk of breaking the
code of people who implement their own resources. Given that there
wouldn't be any code in Ant 1.7.0 that used getURL() we should defer
adding the method as well, IMHO.
> And, for example, what would we do for resources of
> nonstandard "protocols"? Would a StringResource with
> value "foo" return "string:foo" as its URL? Should we
> install custom protocol handlers for built-in
> resources and encourage the same be done for
> third-party resource implementations?
+1 for custom protocol handlers.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello Dominique,
in this case I would add getURL() to Resource, returning null,
and getURL() to FileResource returning file://.... and getURL() to ZipResource returning jar:file://... .
Concerning the custom handlers, I will not do anything. This will be left to the developers of custom resource implementations.
Regards,
Antoine
-------- Original-Nachricht --------
Datum: Thu, 21 Sep 2006 09:06:23 -0500
Von: "Dominique Devienne" <dd...@gmail.com>
An: "Ant Developers List" <de...@ant.apache.org>
Betreff: Re: Resource.getURL()
> > > 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.
>
> 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), 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> Sent: Tuesday, 26 September 2006 6:28 AM
> To: Ant Developers List
> Subject: RE: Resource.getURL()
[snip]
> > Matt:
> >
> > Can you expand on what you mean by "a string representation of a
> > Resource"?
> > Are your implying something equivalent to the way a URL can be
> > externalized to a string (which could be done if all resources are
> > associated with dedicated url handlers). Some concrete
> > usage examples would be handy.
> >
> > /Steve.
>
> Exactly. Take for example the echo task. It defines a
> method like public void setFile(File).
> Ant knows how to resolve file="somefile" to a File object.
> Resources' OutputStream is hardly used at present; the
> concept behind its (OutputStream's) addition to the API is:
>
> <echo to="property:foo">bar</echo>
>
> I used "to" here; maybe the right name is "toresource"
> or simply "resource" as is "file". The implementation of
> setFile(File f) would be:
>
> setTo(new FileResource(f));
>
> This is the exact use case driving this, from my perspective
> anyway. It should be solvable, as you mention, using either
> application-level pseudo-protocols or custom protocol
> handlers. But without this functionality I will consider any
> solution incomplete.
OK - now things are making more sense. In effect the 'property:foo' is a
resource identifier in that the resource protocol is 'property' and the
resource name is 'foo'.
For the other resource types:
tar:[name] TarResource in memory tar archive
zip:[name] ZipArchive in memory zip archive
bzip:[name] BZipResource in memory compressed archive
gzip:[name] GZipArchive in memory compressed archive
file:[name] FileResource named reference to file or
directory
property:[name] PropertyResource in memory property binding
string:[name] StringResource in memory string value
uri:[name] URLResource named reference to a streamable
source
defined by a URL
I have not included CompressedResource or JavaResource resource in the above
list because my impression is that these two are both abstract resource
definitions. For example, something like 'class:[name]' could map to a
resource class derived from JavaResource. E.g:
class:[name] ClassResource named reference to classname and
path
handler:[name] HandlerResource named reference to a protocol
handler
Also important to note is that:
* all of the above return URLs that are in fact URIs identifiy
the resource instance
Does that sound correct?
/Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Matt Benson <gu...@yahoo.com>.
--- Stephen McConnell <mc...@dpml.net> wrote:
>
>
> > -----Original Message-----
> > From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> > Sent: Tuesday, 26 September 2006 4:17 AM
> > To: Ant Developers List
> > Subject: Re: Resource.getURL()
> >
> > --- Dominique Devienne <dd...@gmail.com>
> wrote:
> >
> > > > 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).
> > >
> > > I have no issue whatsoever with this Steve :-)
> --DD
> >
> > The problem with this approach--specifying the
> handler
> > classname to the URLResource constructor--is that
> it fails to
> > address the primary requirement that Ant have a
> predictable
> > way to resolve a string representation of a
> Resource to a
> > properly configured Resource implementation. :(
>
> Matt:
>
> Can you expand on what you mean by "a string
> representation of a Resource"?
> Are your implying something equivalent to the way a
> URL can be externalized
> to a string (which could be done if all resources
> are associated with
> dedicated url handlers). Some concrete usage
> examples would be handy.
>
> /Steve.
Exactly. Take for example the echo task. It defines
a method like
public void setFile(File).
Ant knows how to resolve file="somefile" to a File
object. Resources' OutputStream is hardly used at
present; the concept behind its (OutputStream's)
addition to the API is:
<echo to="property:foo">bar</echo>
I used "to" here; maybe the right name is "toresource"
or simply "resource" as is "file". The implementation
of setFile(File f) would be:
setTo(new FileResource(f));
This is the exact use case driving this, from my
perspective anyway. It should be solvable, as you
mention, using either application-level
pseudo-protocols or custom protocol handlers. But
without this functionality I will consider any
solution incomplete.
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> Sent: Tuesday, 26 September 2006 4:17 AM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> --- Dominique Devienne <dd...@gmail.com> wrote:
>
> > > 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).
> >
> > I have no issue whatsoever with this Steve :-) --DD
>
> The problem with this approach--specifying the handler
> classname to the URLResource constructor--is that it fails to
> address the primary requirement that Ant have a predictable
> way to resolve a string representation of a Resource to a
> properly configured Resource implementation. :(
Matt:
Can you expand on what you mean by "a string representation of a Resource"?
Are your implying something equivalent to the way a URL can be externalized
to a string (which could be done if all resources are associated with
dedicated url handlers). Some concrete usage examples would be handy.
/Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Matt Benson <gu...@yahoo.com>.
--- Dominique Devienne <dd...@gmail.com> wrote:
> > 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).
>
> I have no issue whatsoever with this Steve :-) --DD
The problem with this approach--specifying the handler
classname to the URLResource constructor--is that it
fails to address the primary requirement that Ant have
a predictable way to resolve a string representation
of a Resource to a properly configured Resource
implementation. :(
-Matt
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Dominique Devienne <dd...@gmail.com>.
> 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).
I have no issue whatsoever with this Steve :-) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Matt Benson <gu...@yahoo.com>.
--- Stephen McConnell <mc...@dpml.net> wrote:
>
>
> > -----Original Message-----
> > From: Dominique Devienne
> [mailto:ddevienne@gmail.com]
> > Sent: Monday, 25 September 2006 10:32 PM
> > To: Ant Developers List
> > Subject: Re: Resource.getURL()
> >
> > > > The question is why would you need to get back
> a URL from
> > > > a Resource?
> > >
> > > You need to get a URL from a resource if you
> want to use
> > > the resource as InputSource in XML processing.
> > > The URL is used to set the SystemId, in practice
> to be able
> > > to resolve includes, entities, ... which are to
> be found
> > > with a relative path.
> >
> > But when you get a StringResource, or
> PropertyResource, which
> > are ficticious Resource impls wrapping a string or
> the value
> > of an Ant property, even if you wrap these into a
> custom URL,
> > how would you resolve URLs relative to these???
> >
> > This is the reason why I'm saying that a getURL
> only makes
> > sense for true URLResources only.
> >
> > Pushing it down to Resource smells wrong to me.
>
> I think the smell you are talking about may be the
> general aroma related to
> a class providing more than a single concern. The
> Resource class as declared
> in 1.6.5 addresses several:
>
> a) association with a name
> b) comparable
> c) equivalence
> d) existence
> e) association with a modification timestamp
> f) association with a size
> g) a flag declaring if the resource is a directory
>
> The version of Resource declared in 1.7 adds the
> following additional
> behaviour:
>
> d) streamable behaviour
> a) a flag indicating if the resource is derived
> from the filesystem
> (which makes me uncomfortable)
FWIW, this probably would not be necessary except to
ensure backward compatibility of the filesystem-based
resource collections existing pre-Ant 1.7: fileset,
dirset, path, filelist. Especially because it is an
unfortunate fact that some tools, e.g. Sun's javac
implementation (at least pre JDK 1.6), operate on
files and not streams.
> b) adds ResourceCollection as an implemented
> interface
> c) adds the ArchiveResource, CompressedResource,
> FileResource,
> JavaResource, PropertyResource, StringResource,
> and
> URLResource as derived types
>
> As things stand all of these classes expose the
> operation getOutputStream().
> The getOutputStream() method is documented as
> throwing
> UnsupportedOperationException if the supply of a
> resource stream is not
> supported. IMO there is a good argument to include
> getURL() at the same
> level as getInputStream() and getOutputStream(). My
> immediate conclusion is
> that we could declare a interface named Streamable
> that includes all three
> methods and from this define the abstract class
> StreamableResource. In
> addition - any streamable resource implementation
> should be required to
> fully support getURL() and getOutputStream().
There are some situations in which it makes sense for
a Resource to provide an InputStream but not an
OutputStream. The examples that come to mind are for
already set properties, and already "valued" strings.
However, these both throw
oata.types.resources.ImmutableResourceException in
these cases, so I could live with the above proposal.
But it probably needs to happen sooner rather than
later, OR it could take the form of an intervening
abstract class rather than an interface. Not sure if
either approach promises any great benefit over the
other here.
-Matt
>
> Thoughts?
>
> Cheers, Steve.
>
> --------------------------
> Stephen McConnell
> mailto:mcconnell@dpml.net
> http://www.dpml.net
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Dominique Devienne [mailto:ddevienne@gmail.com]
> Sent: Monday, 25 September 2006 10:32 PM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> > > The question is why would you need to get back a URL from
> > > a Resource?
> >
> > You need to get a URL from a resource if you want to use
> > the resource as InputSource in XML processing.
> > The URL is used to set the SystemId, in practice to be able
> > to resolve includes, entities, ... which are to be found
> > with a relative path.
>
> But when you get a StringResource, or PropertyResource, which
> are ficticious Resource impls wrapping a string or the value
> of an Ant property, even if you wrap these into a custom URL,
> how would you resolve URLs relative to these???
>
> This is the reason why I'm saying that a getURL only makes
> sense for true URLResources only.
>
> Pushing it down to Resource smells wrong to me.
I think the smell you are talking about may be the general aroma related to
a class providing more than a single concern. The Resource class as declared
in 1.6.5 addresses several:
a) association with a name
b) comparable
c) equivalence
d) existence
e) association with a modification timestamp
f) association with a size
g) a flag declaring if the resource is a directory
The version of Resource declared in 1.7 adds the following additional
behaviour:
d) streamable behaviour
a) a flag indicating if the resource is derived from the filesystem
(which makes me uncomfortable)
b) adds ResourceCollection as an implemented interface
c) adds the ArchiveResource, CompressedResource, FileResource,
JavaResource, PropertyResource, StringResource, and
URLResource as derived types
As things stand all of these classes expose the operation getOutputStream().
The getOutputStream() method is documented as throwing
UnsupportedOperationException if the supply of a resource stream is not
supported. IMO there is a good argument to include getURL() at the same
level as getInputStream() and getOutputStream(). My immediate conclusion is
that we could declare a interface named Streamable that includes all three
methods and from this define the abstract class StreamableResource. In
addition - any streamable resource implementation should be required to
fully support getURL() and getOutputStream().
Thoughts?
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 25 Sep 2006, Matt Benson <gu...@yahoo.com> wrote:
> --- Antoine Levy-Lambert <an...@gmx.de> wrote:
>> URLResource (s) AFAIK do not have a special "root".
>
> I think they are considered as having a root concept;
You are both correct.
There are hierarchical and opaque URLs. opaque URLs, for example
mailto:bodewig@apache.org don't have a root, hierarchical URLs have.
Hierarchical URLs follow the schema part with two slashes (i.e. after
the first colon) while opaque URLs don't.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Matt Benson <gu...@yahoo.com>.
--- Antoine Levy-Lambert <an...@gmx.de> wrote:
> Hello Dominique,
>
> Dominique Devienne wrote:
> >>
> >> getURL() makes sense for FileResource and
> ZipResource too.
> >
> > Yes, but these can be expressed as URLResource
> just the same. Maybe
> > they should in fact derive from URLResource...
> I do not agree with you on this. ZipResource and
> FileResource have the
> special semantics of resources which are centered on
> a root directory or
> root resource.
> This root is the directory of a fileset, or the
> whole zip file in case
> of ZipResource.
>
> URLResource (s) AFAIK do not have a special "root".
I think they are considered as having a root concept;
they surely have the concept of a relative path. See
the API for java.net.URL(URL, String).
-Matt
>
> The root or base part of the ZipResource or
> FileResource change what
> happens when a copy is done, or a zip file gets
> built, ...
>
> Regards,
>
> Antoine
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello Dominique,
Dominique Devienne wrote:
>>
>> getURL() makes sense for FileResource and ZipResource too.
>
> Yes, but these can be expressed as URLResource just the same. Maybe
> they should in fact derive from URLResource...
I do not agree with you on this. ZipResource and FileResource have the
special semantics of resources which are centered on a root directory or
root resource.
This root is the directory of a fileset, or the whole zip file in case
of ZipResource.
URLResource (s) AFAIK do not have a special "root".
The root or base part of the ZipResource or FileResource change what
happens when a copy is done, or a zip file gets built, ...
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Dominique Devienne <dd...@gmail.com>.
> > This is the reason why I'm saying that a getURL only makes sense for
> > true URLResources only.
> getURL() makes sense for FileResource and ZipResource too.
Yes, but these can be expressed as URLResource just the same. Maybe
they should in fact derive from URLResource... This way, we could
differentiate betweem "pure" Resource which are content-only, with no
way to "address" or "locate" them (like StringResource and
PropertyResource) , and those which are in fact URL-based
(FileResource, ZipResource, etc...). Types who only care about content
would use Resource, while those who also care of resolving other
resources relative to another would accept URLResource, and not
"plain" Resource.
XML processing, which you mention as an use case for the getURL
method, is in fact more abstracted than that, and depends only on
SAX's InputSource and EntityResolver. InputSource itself only depends
on InputStream/Reader, although you can supply a URL as well. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hi,
Dominique Devienne wrote:
>> > The question is why would you need to get back a URL from a Resource?
>> You need to get a URL from a resource if you want to use the resource as
>> InputSource in XML processing.
>> The URL is used to set the SystemId, in practice to be able to resolve
>> includes, entities, ... which are to be found with a relative path.
>
> But when you get a StringResource, or PropertyResource, which are
> ficticious Resource impls wrapping a string or the value of an Ant
> property, even if you wrap these into a custom URL, how would you
> resolve URLs relative to these???
I would let getURL() return null for StringResource, PropertyResource,
... all this
>
> This is the reason why I'm saying that a getURL only makes sense for
> true URLResources only.
getURL() makes sense for FileResource and ZipResource too.
> Pushing it down to Resource smells wrong to
> me. Even if I'm wrong, it's easier to push it down to Resource
> afterward, based on community experience, rather that putting it there
> in the first place IMHO. --DD
>
I can wait.
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Dominique Devienne <dd...@gmail.com>.
> > The question is why would you need to get back a URL from a Resource?
> You need to get a URL from a resource if you want to use the resource as
> InputSource in XML processing.
> The URL is used to set the SystemId, in practice to be able to resolve
> includes, entities, ... which are to be found with a relative path.
But when you get a StringResource, or PropertyResource, which are
ficticious Resource impls wrapping a string or the value of an Ant
property, even if you wrap these into a custom URL, how would you
resolve URLs relative to these???
This is the reason why I'm saying that a getURL only makes sense for
true URLResources only. Pushing it down to Resource smells wrong to
me. Even if I'm wrong, it's easier to push it down to Resource
afterward, based on community experience, rather that putting it there
in the first place IMHO. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Dominique Devienne wrote:
>
> The question is why would you need to get back a URL from a Resource?
You need to get a URL from a resource if you want to use the resource as
InputSource in XML processing.
The URL is used to set the SystemId, in practice to be able to resolve
includes, entities, ... which are to be found with a relative path.
This is the only reason why I want to add getURL() to Resource. The
Resource type is a normal, non abstract class.
Stefan Bodewig suggested to wait until after 1.7.0 is out to do that.
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL() - example
Posted by Stephen McConnell <mc...@dpml.net>.
Looking at options that have been put forward following Matt's request for
comment it seems to me that the actual requirements are still too loose.
However - I do think we can break down some different topics:
1. namespaced resources
the support within Ant for named resources associated
with a namespace identifying a particular type of
feature (e.g. property:foo, zip:bar, etc.)
2. using a foreign URL as local file source
the ability within Ant to support supplied URL instances
(and please note that I'm talking about a URL instance
as opposed to a uri String and as such I'm precluding
any discovery issues) when constructing collections of
references such as Path instances
3. enabling url protocol handler registration in a build file
the ability within Ant to recognize String urn values
and construct properly populated URL instances without
dependence on the underlying JVM discovery mechanisms
based on data declared in a build file
4. URL publication where Ant is the data source
the ability of Ant to publish URL instances (and note
that I'm again referring to properly populated URL
instances) that can be resolved by client applications
without reference or dependence on the Ant API but with
a valid client assumption that resolution of streams or
content against that URL will return a valid value
derived from an Ant project references by the URL
connection
Each of the four requirements identified so far represent distinct problems.
If addressed separately there are some identifiable actions that could be
taken (or not taken), and some identifiable relationships between these
requirements and operation features and usability within Ant 1.7.
1. Namespaced Resources
-----------------------
The 1.7 codebase includes the Resource class and a number of derived
classes. A question was raised concerning the addition of the method
getURL() on the Resource class and this in turn brought about discussion of
custom protocol handlers and a bunch of other stuff. Within the thread a
number of points have been raised concerning the existing classes and their
relationship to URLs, local files, and urns. For the moment I'm going to
suggest that we exclude URL publication on the grounds that a URL instance
makes sense when publishing data about a project to a client that will use
the URL without reference (or knowledge of) Ant - and I think such a feature
is not justified at this time (even though it does open up a host of
interesting possibilities for advanced applications that embed Ant).
I do think that some clarification is needed with respect to URLResource as
there are at least three possible roles of a URL:
a) where the supplied URL is the value
b) where the supplied URL is the source of the value
c) where the supplied URL is the source of a custom resource
I think item (a) can be excluded on the grounds that this is really a
property concern (i.e. the URL value is the value of a property). Item (b)
is IMO the genuine concern - however, the concern detailed under item (c)
needs to be addressed. Specifically, item (c) could be resolved through the
addition of a ResourceFactory into the Ant API and within which the result
of applying something like the following operation on a URL argument would
establish a resource type:
Resource resource = (Resource) url.getContent( new
Class[]{Resource.class} );
I would also note that given ResourceFactory, the need for URLResource as a
distinct resource type becomes questionable as it seems to me that
everything needed (in terms of methods) is already available under the
Resource class. Also, I'll come back to the subject of Resource.getURL()
later in this email when addressing the forth item - 'URL publication'.
I also should note that given a resource factory, the utility of such a
factory is limited to API only usage unless a framework is provided in Ant
for the registration of URL protocol handlers (unless a enclosing
application context is established). Put more simply - if a build file
contains a foreign uri and if we want that uri to be usable, then we need a
framework to declare a hander to use when constructing URL instances
internally within Ant - and this is the subject addressed under point (3)
'enabling url protocol handler registration in a build file'.
2. Using Foreign URLs
---------------------
Item (2) deals with subject of Ant's support within the API for foreign URLs
and in effect dealing with the issue that the current codebase does not
provide good support for protocols other than "file" in the establishment of
local file references. This subject can be subdivided into two distinct
concerns.
a) extraction of a File instance from a URL
b) identification of Resource instances that support
exposure of local File instance
Item (a) can be resolved by employing the following convention:
File file = (File) url.getContent( new Class[]{File.class} );
If the resulting file instance is null then the supplied URL is invalid,
otherwise everything folds nicely into the existing API assumptions. There
is the presumption here that the Path instance (and possibly other classes)
need to expose appropriate createXxxx( URL url ) methods through which file
paths resolved using the above technique may be added to path collections.
Item (b) has already been discussed and resolves around the premise that
FileResource should not be the definition of the base for resources that can
be resolved to a File value. Based on the reply from Stefan on this subject
it seems that this is reasonably easy to resolve using something like a
LocalFileProvider interface.
There is also the underlying but separate issue of the ability within Ant to
recognize and bind a protocol handler when creating a new URL instance as
this is the feature that lets us declare urn strings in a build file with
knowledge that Ant can bind and resolve them properly - which is addressed
under the next 'enabling url protocol handler registration in a build file'.
3. Enabling URL protocol handler registration in a build file
-------------------------------------------------------------
The discussion concerning resources and foreign URLs has been focussed
primarily of the usage of the Ant API by a client application (e.g. a
container establishing, configuring and executing an Ant project). In this
scenario URLs passed as arguments in methods exposed on the Ant API can be
established with a protocol handler and as such no handler discovery is
required. However - this precluded the possibility of using custom
protocols as string arguments in attributes within build files.
Within this thread we have already covered the discovery mechanisms used by
the JVM (including stream handler factories and the usage of system
classloader manipulation in conjunction with the java.protocol.handler.pkgs
system property). The result of that discussion was the establishment of a
rational strategy for the explicit declaration of handlers at the Ant
application level and the potential for Ant to locate and bind handlers when
constructing new URL instances. The solution involved the addition of a
ClassResource (extending JavaResource) and HandlerResource (extending
ClassResource) where a name is associated to a loaded class and the name is
used to locate a custom protocol handler based on the uri scheme name. This
should be trivial to implement and requires no knowledge of custom handlers
or connections.
The build.xml view of this would be something like:
<handler id="artifact" class="net.dpml.transit.artifact.Handler">
<classpath>
<pathelement location="my-handler-jar.jar"/>
</classpath>
</handler>
<path id="my-path">
<pathelement uri="artifact:jar:acme/widget"/>
</path>
Given the ability to declare handlers we can then move forward with much
more clarity because Ant will be open via a standard extension mechanism -
and with recognition of uris in areas such as resource creation, things will
be looking really good.
4. URL publication where Ant is the data source
-----------------------------------------------
In everything described above - there is no requirement for any
implementation within Ant of custom URL protocol handlers. In effect, by
breaking out the separate issues of incoming URLs, incoming uris (urls as
strings), and the url to file issue, we are left with the separate concern
of URL creation and publication by the Ant runtime. I should note that I am
not addressing strignified urls such as 'property:foo' on the grounds that
these values will appear in a context where it is known to be a resource
reference. I am only addressing the potential publication of something like
'property:foo' as a URL instance - e.g.
URL url = new URL( context, 'property:foo', handler );
The ultimate objective of reviewing the above line is two-fold. Firstly - I
want to examine what each of the arguments represent, and secondly - I want
to establish the potential value that a URL provides. Starting of with the
arguments - we have:
a) the context - which inevitable resolves down to an Ant
project instance
- an identifiable instance
- or, the current ant instance
b) the resource identifier urn (e.g. 'property:foo')
- a feature type (property)
- a feature name (foo)
c) the protocol handler
- a factory for the 'property' protocol connection
- an implementation of a URLConnection for property
that knows how to resolve a value for the named
resource relative to the current or identified
project context
Given the above we need to keep in mind that identifiable Ant project
instances are IMO out-of-scope without substantial development of the Ant
runtime, so I think its reasonable to presume that the context is any
current Ant project instance. However - if a current project instance is a
prerequisite, then there is no need for a URL because Ant is already in
scope and as such simple string urn values handled by the Ant runtime are
sufficient (a.k.a. the application managed scenario). Anyone who has been
following this thread closely will probably recognize that this conclusion
is inconsistent with earlier comments from myself. In effect, I think the
process of breaking out concerns 1, 2, and 3 have enabled the removal of
several related subjects (combined with the fact that some quick prototypes
from yesterday conformed to me that this thread was mixing too many
concerns).
Conclusion
----------
1. some cleanup is needed with respect to URLResource
and potential factory semantics
2. better support should be added for foreign file capable
urls in Path and other collection classes
3. url handler registration should be included with emphasis
this this is a big feature plus and a small code impact
4. that Resource.getURL() is not required given the above
5. that items (1) and (2) require item (3) when we move from
the API to the build file
Hoping that this is useful ...
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL() - example
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 28 Sep 2006, Matt Benson <gu...@yahoo.com> wrote:
> My current impression is that, partially contingent on
> Stephen's willingness to field questions, ;) the
> protocol-based solution is preferable, or at least
> worth _proving_ unsuitable. In any event, I'd like
> for us to reach a decision on this fairly soon before
> this thread runs out of steam and we have to do it all
> over again (voice of experience). What are the other
> committers' feelings at this point?
I tend to prefer an application protocol by now, nut it is by no means
a very strong opinion.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL() - example
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> My current impression is that, partially contingent on
> Stephen's willingness to field questions, ;) the
> protocol-based solution is preferable, or at least
> worth _proving_ unsuitable.
Matt:
My schedule is free over the next week and I'll be free to field questions,
contribute code examples, prepare testcases, etc.
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL() - example
Posted by Matt Benson <gu...@yahoo.com>.
--- Scott Stirling <sc...@gmail.com> wrote:
> On 9/28/06, Stephen McConnell <mc...@dpml.net>
> wrote:
> [...]
> > This difference in scope an example that
> demonstrates an area where existing
> > protocols and software are insufficient.
>
> OK, if you say so. In my experience the statement
> "existing protocols
> and software are insufficient," is a red flag, but I
> will step aside.
> I feel like I am ignorant of what's really going on
> in your builds.
> I've worked some pretty hairy cross-repository
> builds in commercial
> systems. I've never needed to resort to custom
> protocol handlers, so I
> obviously don't know something about your situation
> that you do. Fair
> enough.
[SNIP]
>
> I have to look into Depot. Like I said, I think I'll
> step aside and
> let the discussion open up for others to give input.
As the opener of this can of worms I welcome all
input. My situation: it is my opinion that Ant needs
a solution here. I am working on the assumption no
committer would -1 me on this point. That
accomplished, it seems that the custom protocol
handler idea and the application-level pseudo-protocol
idea are the two possibilities at hand. I still know
fairly little about the former; the latter is fairly
straightforward. As far as I know I am the originator
of both suggestions in the context of resolving an Ant
resource from a string representation. Given my lack
of expertise on the protocol-based approach and the
apparent "depth" of that solution, I solicited the
opinions of others. The apparent results so far:
protocol-based approach:
-tricky to get installed smoothly and correctly
-no Ant developer knowledge, but possibly Stephen M.
is willing to guide us where we stumble?
-standard (for better or worse); therefore possibly
applicable to more situations AND preexisting
protocols may be easier to adapt to Ant.
-seen by some as "too much"? (is that a fair
paraphrase of your feelings, Scott?)
application-level approach:
-3rd-party impls still require some sort of
Ant-specific registration
-resolution is fairly straightforward
-solution only applies to whatever situations we
explicitly provide for.
My current impression is that, partially contingent on
Stephen's willingness to field questions, ;) the
protocol-based solution is preferable, or at least
worth _proving_ unsuitable. In any event, I'd like
for us to reach a decision on this fairly soon before
this thread runs out of steam and we have to do it all
over again (voice of experience). What are the other
committers' feelings at this point?
TIA,
Matt
>
> Best regards,
> Scott Stirling
> Framingham, MA
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL() - example
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Scott Stirling [mailto:scottstirling@gmail.com]
> But when you encapsulate artifact location resolution into
> Java protocol handlers (which is what I think you're doing),
> you've made the build into something that, while, OK, not a
> black box, requires an understanding of Java programming,
> which a lot of folks don't have or don't think they should
> need to have (even when they do!) to undestand how the build works.
Scott:
The usage of the http protocol handler does not imply a requirement on build
users for an understanding of the java programming language. It does imply
an understanding that a URL is a well defined string that describes the
location of a resource, and that a protocol (e.g. 'http') defines additional
semantics and runtime behaviour. However, the support within Ant for any
URL protocol would imply an understanding of the protocol in use by the
build user (which would be a user's choice). Irrespective of the choice
between a bundled protocol or a dynamically loaded protocol, an
understanding of the Java language is not implied or required.
But I agree with you that new protocol (a.k.a. new ideas) bring new
overheads in understanding.
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL() - example
Posted by Scott Stirling <sc...@gmail.com>.
On 9/28/06, Stephen McConnell <mc...@dpml.net> wrote:
[...]
> This difference in scope an example that demonstrates an area where existing
> protocols and software are insufficient.
OK, if you say so. In my experience the statement "existing protocols
and software are insufficient," is a red flag, but I will step aside.
I feel like I am ignorant of what's really going on in your builds.
I've worked some pretty hairy cross-repository builds in commercial
systems. I've never needed to resort to custom protocol handlers, so I
obviously don't know something about your situation that you do. Fair
enough.
> When we look at an individual codebase (and I'm referring here to a single
> codebase delivering a small number of discrete deliverables)
> the usage of location information (relative files locations and selection
> patterns) is totally appropriate. However, when codebase A references
> content in codebase B via location we are introducing a dependency not
> only on a foreign codebase location, but more importantly we are adding
> information about a foreign build strategy (via paths into a foreign
> structure).
I'm with you. I lost interest in Maven a long time ago because it was
obviously tailored for simple projects a la Jakarta commons projects.
I hear it's much better now, but anyway, I know the pain you're
talking about.
> If you consider a scenario where you are working with 10s or 100s of
> projects - the usage of explicit location (and the implicit leaking of foreign
> build strategies into the consuming project has (in my experience) been
> a major source of failure and contributes dramatically to build system
> maintenance overhead.
The common solution here is to establish some conventions and
contracts between projects, i.e., build A will output its artifacts to
location X, etc., build B will use location Y for its dependency
repository.
I don't see how custom protocol handlers, or much of anything, can
solve the maintenance overhead issue since you sound as if you have no
control over these distributed projects.
> > inside of a protocol handler black's box.
>
> I would agree that protocol handling is an area of the JVM API a less well
> known (but I would disagree with the black-box metaphor). In the context of
> this thread a protocol handler is simply a standard factory for standard
> connections. The clarity of the behaviour of the respective protocol
> handler is directly related to its implementation and documentation.
Well, I meant that to a new, e.g., release engineer coming onto a
project, he or she will be trying to understand the build(s). When he
or she can see how everything in the build is related via properties
files, shell scripts, and Ant build scripts (*declaratively*
programmed), then the principle of "least surprise" is met and the
person can probably figure this stuff out without me or you being
there, necessarily. And they can change stuff without dropping into
Java.
But when you encapsulate artifact location resolution into Java
protocol handlers (which is what I think you're doing), you've made
the build into something that, while, OK, not a black box, requires an
understanding of Java programming, which a lot of folks don't have or
don't think they should need to have (even when they do!) to undestand
how the build works.
> From my point of view the support for the association of a resource with a
> configured URL opens up some significant opportunities for down-scaling
> management applications (and here I am thinking specifically about products
> such as the Depot build-system). The downscaling would be possible simply
> as a result of the use of common data elements - specifically URL instances
> that could flow in bother directions (from Depot to ant during project
> configuration, and from Ant to Depot during project execution).
>
> URL protocol handlers are simple standard structures and support within Ant
> for these structures would have a significant positive impact on the forward
> development of Depot.
I have to look into Depot. Like I said, I think I'll step aside and
let the discussion open up for others to give input.
Best regards,
Scott Stirling
Framingham, MA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL() - example
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Steve Loughran [mailto:stevel@apache.org]
> If we retrofit stuff into Java, with Java URL handling, then
> some URL like a reference to a file on the classpath, it
> would have to be turned into a string that included a
> classloader reference:
>
> classpathresource://classloader/03455he/resource/org/example/something
>
> To turn it into a URL that represented the infinite random
> stream of a seeded random number generator, loaded as an
> antlib, I would be scared to think where to begin.
Can an infinite random stream of a seeded random number generators can be
expressed more simply as "the state of something in Ant"?. While there are
several answers that I could provide relative to state and URL encoding - I
would be guessing as to what you are actually saying/asking because the
above description is not easy to interpret in terms of a concrete question
or assumption. Could you restate the problem, the scope your assuming, and
the issues your concerned about?
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL() - example
Posted by Steve Loughran <st...@apache.org>.
Stephen McConnell wrote:
>
>
>> -----Original Message-----
>> From: Scott Stirling [mailto:scottstirling@gmail.com]
>
> [snip]
>
>>>> All of these protocols include support for the establishment of a
>>>> locally cached file that is a copy of the remote resource (partly
>>>> driven by the need to handle the relationship between models of
>>>> projects and Ant's build-time requirements). Typically a
>>>> link such as link:jar:acme/widget#1.2 (a symbolic link defining
>>>> a jar file under the group namespace acme, name widget, with a
>>>> published version of 1.2) could reference an artifact such as
>>>> 'artifact:jar:net/osm/demo#1.2.9', which in turn maps to a range
>>>> of possible sources where each source defines its own scheme for
>>>> artifact to path transformation (i.e. the automation of the
>>>> transformation of the artifact specification to something like
>>>> file://d:/dpml/data/cache/net/osm/jars/demo-1.2.9.jar is
>>>> an example of one of potentially multiple source paths).
>> What you have in the [above] paragraph is very REST-ful in its
>> way of encoding location, version and name in URLs. I would
>> ask us to consider (Occam's Razor in hand) at what point one
>> actully needs to create a custom protocol (and code to
>> support it) versus using REST-ful URL conventions to achieve
>> much of the same thing with existing protocols and software.
>
> The generalization here makes me feel a touch REST-less as the scope of
> concerns are significantly different. The paper deals with the www as the
> initial blackboard whereas the examples provided here focus primarily with
> normalization within the confines of a single physical hardware device
> within a context of a specific language API. In effect the Java language
> via the protocol handler framework provides an important extension point.
> DPML's collection of protocols are (in the context of this discussion)
> nothing more than an example of the application of that API in dealing with
> basic development and runtime issues in larger scale project scenarios.
> This difference in scope an example that demonstrates an area where existing
> protocols and software are insufficient.
If you look at 1060research.com's NetKernel (disclaimer; friends of
mine, its an ex-HPLabs project), you can see what loosely coupled REST
designs can do in-process. Netkernel is an XML processing
language/runtime that uses URIs extensively to refer to other things in
the app, be they database selects, remote web pages, invocations of
other functions, and then uses caching to decide which to re-evaluate
versus serve up.
to do this they've had to build everything from the ground up, and have
a nice (but complex) arch to do it.
If we retrofit stuff into Java, with Java URL handling, then some URL
like a reference to a file on the classpath, it would have to be turned
into a string that included a classloader reference:
classpathresource://classloader/03455he/resource/org/example/something
To turn it into a URL that represented the infinite random stream of a
seeded random number generator, loaded as an antlib, I would be scared
to think where to begin.
Yet I do know how to have an Ant resource to do this
<ex:random length="412" seed="28" />
I can also imagine Ivy references fitting in here
<ivy:artifact project="org.apache.log4j" artifact="log4j"
version="1.2.13" />
Or even the output of an pipe hooked up to the output of a running java
program
<pipe:output refid="running.junit" />
I dont see that URLs fit in well to all these things.
My plans @ work post-ant1.7 would be to resource-enable our ant tasks so
that we could feed the output of stuff into wherever resources are used,
e.g
<sf:resolved "HOST 192.168.2.1:console:main:iconized" />
to get back whatever resolve to the path console:main:iconized on a
remote host.
Seems to me that there is a lot of fun to be had with Resource without
worrying too much about REST-enabling ant's core.
Who else is doing stuff with resources?
>
>>>> The key thing is that these protocols enable the removal
>>>> of location concerns by shifting the focus to identity.
>> Another take on the [above] statement is that location is a
>> concern to make explicit to the reader of a build script,
>> rather than obscuring a thing's actual location
>
> When we look at an individual codebase (and I'm referring here to a single
> codebase delivering a small number of discrete deliverables) the usage of
> location information (relative files locations and selection patterns) is
> totally appropriate. However, when codebase A references content in codebase
> B via location we are introducing a dependency not only on a foreign
> codebase location, but more importantly we are adding information about a
> foreign build strategy (via paths into a foreign structure). If you
> consider a scenario where you are working with 10s or 100s of projects - the
> usage of explicit location (and the implicit leaking of foreign build
> strategies into the consuming project has (in my experience) been a major
> source of failure and contributes dramatically to build system maintenance
> overhead. At the end of the day the movement towards identity versus
> locality is an example of the application of 'inversion of control'
> principals in that an individual build (or runtime) solution should not need
> to know where something comes from (which is a management concern) but
> instead should deal with identifying the things it needs.
>
>> inside of a protocol handler black's box.
>
> I would agree that protocol handling is an area of the JVM API a less well
> known (but I would disagree with the black-box metaphor). In the context of
> this thread a protocol handler is simply a standard factory for standard
> connections. The clarity of the behaviour of the respective protocol
> handler is directly related to its implementation and documentation.
>
>> Just some thoughts on this interesting topic. I don't buy the
>> need for all these protocols and handlers or the associated
>> flexibility in Ant (yet).
>
> From my point of view the support for the association of a resource with a
> configured URL opens up some significant opportunities for down-scaling
> management applications (and here I am thinking specifically about products
> such as the Depot build-system). The downscaling would be possible simply
> as a result of the use of common data elements - specifically URL instances
> that could flow in bother directions (from Depot to ant during project
> configuration, and from Ant to Depot during project execution).
>
> URL protocol handlers are simple standard structures and support within Ant
> for these structures would have a significant positive impact on the forward
> development of Depot.
>
> Cheers, Steve.
>
> --------------------------
> Stephen McConnell
> mailto:mcconnell@dpml.net
> http://www.dpml.net
>
>
>> Scott Stirling
>> Framingham, MA
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For
>> additional commands, e-mail: dev-help@ant.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL() - example
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Scott Stirling [mailto:scottstirling@gmail.com]
[snip]
> > > All of these protocols include support for the establishment of a
> > > locally cached file that is a copy of the remote resource (partly
> > > driven by the need to handle the relationship between models of
> > > projects and Ant's build-time requirements). Typically a
> > > link such as link:jar:acme/widget#1.2 (a symbolic link defining
> > > a jar file under the group namespace acme, name widget, with a
> > > published version of 1.2) could reference an artifact such as
> > > 'artifact:jar:net/osm/demo#1.2.9', which in turn maps to a range
> > > of possible sources where each source defines its own scheme for
> > > artifact to path transformation (i.e. the automation of the
> > > transformation of the artifact specification to something like
> > > file://d:/dpml/data/cache/net/osm/jars/demo-1.2.9.jar is
> > > an example of one of potentially multiple source paths).
>
> What you have in the [above] paragraph is very REST-ful in its
> way of encoding location, version and name in URLs. I would
> ask us to consider (Occam's Razor in hand) at what point one
> actully needs to create a custom protocol (and code to
> support it) versus using REST-ful URL conventions to achieve
> much of the same thing with existing protocols and software.
The generalization here makes me feel a touch REST-less as the scope of
concerns are significantly different. The paper deals with the www as the
initial blackboard whereas the examples provided here focus primarily with
normalization within the confines of a single physical hardware device
within a context of a specific language API. In effect the Java language
via the protocol handler framework provides an important extension point.
DPML's collection of protocols are (in the context of this discussion)
nothing more than an example of the application of that API in dealing with
basic development and runtime issues in larger scale project scenarios.
This difference in scope an example that demonstrates an area where existing
protocols and software are insufficient.
> > > The key thing is that these protocols enable the removal
> > > of location concerns by shifting the focus to identity.
>
> Another take on the [above] statement is that location is a
> concern to make explicit to the reader of a build script,
> rather than obscuring a thing's actual location
When we look at an individual codebase (and I'm referring here to a single
codebase delivering a small number of discrete deliverables) the usage of
location information (relative files locations and selection patterns) is
totally appropriate. However, when codebase A references content in codebase
B via location we are introducing a dependency not only on a foreign
codebase location, but more importantly we are adding information about a
foreign build strategy (via paths into a foreign structure). If you
consider a scenario where you are working with 10s or 100s of projects - the
usage of explicit location (and the implicit leaking of foreign build
strategies into the consuming project has (in my experience) been a major
source of failure and contributes dramatically to build system maintenance
overhead. At the end of the day the movement towards identity versus
locality is an example of the application of 'inversion of control'
principals in that an individual build (or runtime) solution should not need
to know where something comes from (which is a management concern) but
instead should deal with identifying the things it needs.
> inside of a protocol handler black's box.
I would agree that protocol handling is an area of the JVM API a less well
known (but I would disagree with the black-box metaphor). In the context of
this thread a protocol handler is simply a standard factory for standard
connections. The clarity of the behaviour of the respective protocol
handler is directly related to its implementation and documentation.
> Just some thoughts on this interesting topic. I don't buy the
> need for all these protocols and handlers or the associated
> flexibility in Ant (yet).
>From my point of view the support for the association of a resource with a
configured URL opens up some significant opportunities for down-scaling
management applications (and here I am thinking specifically about products
such as the Depot build-system). The downscaling would be possible simply
as a result of the use of common data elements - specifically URL instances
that could flow in bother directions (from Depot to ant during project
configuration, and from Ant to Depot during project execution).
URL protocol handlers are simple standard structures and support within Ant
for these structures would have a significant positive impact on the forward
development of Depot.
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
>
> Scott Stirling
> Framingham, MA
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For
> additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL() - example
Posted by Scott Stirling <sc...@gmail.com>.
On 9/27/06, Stephen McConnell <mc...@dpml.net> wrote:
> > I make extensive use of custom protocols to represent links
> > to resources not contained within a particular project
> > code-base. These protocols include the following:
> >
> > 'artifact' used to resolve resources from a collection
> > of remote hosts (where the definition is 'remote'
> > is a configurable characteristic) based on group,
> > name, type and version data
> >
> > 'local' used to reference local preference information
> > using the same 'group', 'name', 'type' and
> > 'version' pattern
> >
> > 'link' a symbolic reference that enables one group,
> > name, type, version reference to point to another
> > resource
The concept of REST
(http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm)
is coming to mind as I read this.
What you have in the next paragraph is very REST-ful in its way of
encoding location, version and name in URLs. I would ask us to
consider (Occam's Razor in hand) at what point one actully needs to
create a custom protocol (and code to support it) versus using
REST-ful URL conventions to achieve much of the same thing with
existing protocols and software.
> > All of these protocols include support for the establishment
> > of a locally cached file that is a copy of the remote
> > resource (partly driven by the need to handle the
> > relationship between models of projects and Ant's build-time
> > requirements). Typically a link such as
> > link:jar:acme/widget#1.2 (a symbolic link defining a jar file
> > under the group namespace acme, name widget, with a published
> > version of 1.2) could reference an artifact such as
> > 'artifact:jar:net/osm/demo#1.2.9', which in turn maps to a
> > range of possible sources where each source defines its own
> > scheme for artifact to path transformation (i.e. the
> > automation of the transformation of the artifact
> > specification to something like
> > file://d:/dpml/data/cache/net/osm/jars/demo-1.2.9.jar is an
> > example of one of potentially multiple source paths).
Another take on the following statement is that location is a concern
to make explicit to the reader of a build script, rather than
obscuring a thing's actual location inside of a protocol handler
black's box.
> > The key thing is that these protocols enable the removal of
> > location concerns by shifting the focus to identity.
Just some thoughts on this interesting topic. I don't buy the need for
all these protocols and handlers or the associated flexibility in Ant
(yet).
Scott Stirling
Framingham, MA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL() - example
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@dpml.net]
> Sent: Wednesday, 27 September 2006 4:58 PM
> To: 'Ant Developers List'
> Subject: RE: Resource.getURL()
>
>
>
> > -----Original Message-----
> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> > Sent: Wednesday, 27 September 2006 2:00 PM
> > To: dev@ant.apache.org
> > Subject: Re: Resource.getURL()
> >
> > On Tue, 26 Sep 2006, Stephen McConnell <mc...@dpml.net> wrote:
> >
> > > As such, some resource are implicitly file based (e.g.
> > > FileResource) while other resources may (or may not) be
> > > resolvable to a local file.
> >
> > What kind of resources would that be?
>
> I make extensive use of custom protocols to represent links
> to resources not contained within a particular project
> code-base. These protocols include the following:
>
> 'artifact' used to resolve resources from a collection
> of remote hosts (where the definition is 'remote'
> is a configurable characteristic) based on group,
> name, type and version data
>
> 'local' used to reference local preference information
> using the same 'group', 'name', 'type' and
> 'version' pattern
>
> 'link' a symbolic reference that enables one group,
> name, type, version reference to point to another
> resource
>
> All of these protocols include support for the establishment
> of a locally cached file that is a copy of the remote
> resource (partly driven by the need to handle the
> relationship between models of projects and Ant's build-time
> requirements). Typically a link such as
> link:jar:acme/widget#1.2 (a symbolic link defining a jar file
> under the group namespace acme, name widget, with a published
> version of 1.2) could reference an artifact such as
> 'artifact:jar:net/osm/demo#1.2.9', which in turn maps to a
> range of possible sources where each source defines its own
> scheme for artifact to path transformation (i.e. the
> automation of the transformation of the artifact
> specification to something like
> file://d:/dpml/data/cache/net/osm/jars/demo-1.2.9.jar is an
> example of one of potentially multiple source paths).
>
> The key thing is that these protocols enable the removal of
> location concerns by shifting the focus to identity.
> Supporting this principal is the internal support for the
> maintenance of a local file cache which is used for things
> like Ant where file paths are required.
Here is an example of the hypothetical creation of path elements using
'artifact' as a foreign url resource handler. The example presumes that the
usage of the 'uri' attribute triggers the creation of a new resource.
<path id="foo">
<resource name="widget" uri="artifact:jar:acme/widget"/>
<resource name="gizmo" uri="artifact:jar:acme/gizmo"/>
</path>
In the following example I'm referencing existing named resources:
<path id="foo">
<resource refid="widget"/>
<resource refid="gizmo"/>
</path>
In the creation (first) example I think the uri scheme is the key to
selection of a custom resource implementation class which is where something
like the implementation of an interface such as LocalFileProvider would be
detected.
Cheers, Steve.
p.s. the examples above use '<resource>' as a made up element.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Wednesday, 27 September 2006 2:00 PM
> To: dev@ant.apache.org
> Subject: Re: Resource.getURL()
>
> On Tue, 26 Sep 2006, Stephen McConnell <mc...@dpml.net> wrote:
>
> > As such, some resource are implicitly file based (e.g.
> > FileResource) while other resources may (or may not) be
> > resolvable to a local file.
>
> What kind of resources would that be?
I make extensive use of custom protocols to represent links to resources not
contained within a particular project code-base. These protocols include
the following:
'artifact' used to resolve resources from a collection
of remote hosts (where the definition is 'remote'
is a configurable characteristic) based on group,
name, type and version data
'local' used to reference local preference information
using the same 'group', 'name', 'type' and
'version' pattern
'link' a symbolic reference that enables one group,
name, type, version reference to point to another
resource
All of these protocols include support for the establishment of a locally
cached file that is a copy of the remote resource (partly driven by the need
to handle the relationship between models of projects and Ant's build-time
requirements). Typically a link such as link:jar:acme/widget#1.2 (a
symbolic link defining a jar file under the group namespace acme, name
widget, with a published version of 1.2) could reference an artifact such as
'artifact:jar:net/osm/demo#1.2.9', which in turn maps to a range of possible
sources where each source defines its own scheme for artifact to path
transformation (i.e. the automation of the transformation of the artifact
specification to something like
file://d:/dpml/data/cache/net/osm/jars/demo-1.2.9.jar is an example of one
of potentially multiple source paths).
The key thing is that these protocols enable the removal of location
concerns by shifting the focus to identity. Supporting this principal is
the internal support for the maintenance of a local file cache which is used
for things like Ant where file paths are required.
> > The important distinction here is that Path should allow
> > any type of resource that is resolvable to a local file
> > (but which is not necessarily a file resource).
>
> I agree under the assumption that such resources exist.
>
> > However - there is nothing in the definition of Resource
> > that allows an implementation to return a local file.
> > Instead the current model assumes that only FileResource
> > is a valid source of a local file.
>
> Or the recommended extension point for custom resources that
> are resolvable to local files.
However - in practice the class is not an appropriate extension point as it
commences with the assumption that the resource is a file. In effect
URLResource is a better starting point in that the principal of initial
representation of identity and source of stream information is the url.
> > This could be resolved by separating the concern of local file
> > resolvability via a interface dedicated to this concern .. E.g.
> >
> > public interface LocalFileProvider
> > {
> > File getFile();
> > }
>
> Would work and it would even be pretty easy to retrofit the
> implementation of isFilesystemOnly to look after that
> interface instead of the FileResource class. Same for task
> that only work on FileResources right now.
That's my impression as well.
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 26 Sep 2006, Stephen McConnell <mc...@dpml.net> wrote:
> As such, some resource are implicitly file based (e.g. FileResource)
> while other resources may (or may not) be resolvable to a local
> file.
What kind of resources would that be?
> The important distinction here is that Path should allow any type of
> resource that is resolvable to a local file (but which is not
> necessarily a file resource).
I agree under the assumption that such resources exist.
> However - there is nothing in the definition of Resource that allows
> an implementation to return a local file. Instead the current model
> assumes that only FileResource is a valid source of a local file.
Or the recommended extension point for custom resources that are
resolvable to local files.
> This could be resolved by separating the concern of local file
> resolvability via a interface dedicated to this concern .. E.g.
>
> public interface LocalFileProvider
> {
> File getFile();
> }
Would work and it would even be pretty easy to retrofit the
implementation of isFilesystemOnly to look after that interface
instead of the FileResource class. Same for task that only work on
FileResources right now.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Tuesday, 26 September 2006 12:56 PM
> To: dev@ant.apache.org
> Subject: Re: Resource.getURL()
>
> On Tue, 26 Sep 2006, Stephen McConnell <mc...@dpml.net> wrote:
> >> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
>
> >> Path's inheritance hierarchy was altered such that its immediate
> >> superclass is the new Union resource collection. So the only
> >> difference between the two is, for all practical purposes, the
> >> filesystem-only restriction.
> >
> > Meaning that tasks such as javac (and others) that take classpath
> > definitions as Path arguments could be changed to take a
> Union as an
> > argument?
>
> If you look through Ant 1.7.0 you will see that most tasks
> that supported <filesets> or <paths> or ... now support
> arbitrary resource collections. Tasks that supported nested
> <path> elements in Ant 1.6.5 now automatically support nested
> resources as child elements of that <path>.
>
> In the case of <javac> the compiler itself doesn't deal with
> anything but file resources, so the tasks must ensure only
> Fileresources are added - and <path> guarantees just that.
To translate this into my thinking:
* any child resource of a Path needs to be resolvable to
a local file when dealing with tools such as
javac, java, etc.
As such, some resource are implicitly file based (e.g. FileResource) while
other resources may (or may not) be resolvable to a local file. The
important distinction here is that Path should allow any type of resource
that is resolvable to a local file (but which is not necessarily a file
resource). However - there is nothing in the definition of Resource that
allows an implementation to return a local file. Instead the current model
assumes that only FileResource is a valid source of a local file. Perhaps
this is where I'm running into grief - I have resources that are expressed
as URLs that are resolvable to local files (if necessary) but the current
distinction made between FileResource and anything else prevents their
potential inclusion in path constructs.
This could be resolved by separating the concern of local file resolvability
via a interface dedicated to this concern .. E.g.
public interface LocalFileProvider
{
File getFile();
}
Such an interface could be implemented by FileResource and optionally
implemented by any other resource class - and the Path implementation could
do a if( foo instanceof LocalFileProvider ) ... before accessing the local
file value. In addition changes would be required to Path to allow the
inclusion of file-providing resource children, e.g.
<path id="foo">
<pathelement resource="abc:def"/> <!-- must implement LocalFileProvider
-->
</path>
Does this sound reasonable?
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 26 Sep 2006, Stephen McConnell <mc...@dpml.net> wrote:
>> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
>> Path's inheritance hierarchy was altered such that its immediate
>> superclass is the new Union resource collection. So the only
>> difference between the two is, for all practical purposes, the
>> filesystem-only restriction.
>
> Meaning that tasks such as javac (and others) that take classpath
> definitions as Path arguments could be changed to take a Union as an
> argument?
If you look through Ant 1.7.0 you will see that most tasks that
supported <filesets> or <paths> or ... now support arbitrary resource
collections. Tasks that supported nested <path> elements in Ant 1.6.5
now automatically support nested resources as child elements of that
<path>.
In the case of <javac> the compiler itself doesn't deal with anything
but file resources, so the tasks must ensure only Fileresources are
added - and <path> guarantees just that.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> Sent: Tuesday, 26 September 2006 4:28 AM
> To: Ant Developers List
> Subject: RE: Resource.getURL()
>
> --- Stephen McConnell <mc...@dpml.net> wrote:
> [SNIP]
> >
> > 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).
> >
>
> We could come back to this; in my opinion relaxing this
> restriction in the future would not hurt anything. However,
> in the ResourceCollection refactoring, Path's inheritance
> hierarchy was altered such that its immediate superclass is
> the new Union resource collection. So the only difference
> between the two is, for all practical purposes, the
> filesystem-only restriction. Path further supports its
> historical API e.g. <pathelement>, list(). But to get back
> to the point, in general a <union> can be used where a
> filesystem-agnostic <path> is desired.
Meaning that tasks such as javac (and others) that take classpath
definitions as Path arguments could be changed to take a Union as an
argument?
/Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Matt Benson <gu...@yahoo.com>.
--- Stephen McConnell <mc...@dpml.net> wrote:
[SNIP]
>
> 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).
>
We could come back to this; in my opinion relaxing
this restriction in the future would not hurt
anything. However, in the ResourceCollection
refactoring, Path's inheritance hierarchy was altered
such that its immediate superclass is the new Union
resource collection. So the only difference between
the two is, for all practical purposes, the
filesystem-only restriction. Path further supports
its historical API e.g. <pathelement>, list(). But to
get back to the point, in general a <union> can be
used where a filesystem-agnostic <path> is desired.
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
Scott Stirling wrote:
> Where would these protocols appear from a user perspective?
> In build scripts? If that's the case, then I'd definitely say
> consider letting Ant handle them and convert them to standard
> URLs through a registry mechanism perhaps like the custom
> task registry.
Dominique Devienne wrote:
> I guess my position on these handlers depends on the ease to
> install them to a running JVM, and the actual use cases
> having them would solves. --DD
I've put together an example that demonstrates the hypothetical usage of a
custom URL protocol handler. The example uses classic Ant to create a path
datatype containing the resources that contain the custom stream handler
class. The next step is to declare the stream handler to Ant using the
hypothetical <handler> datatype. The <handler> datatype associates the
protocol name with the classpath and the protocol handler classname. The
next step demonstrates the creation of a new <path> object using the custom
protocol. In this case I'm declaring a hypothetical pathelement using a
'uri' attribute on the assumption that the protocol of the uri argument is
easily recognizable, and that the stream handler can be resolved by looking
up the named handler. I'm subsequently referencing the path as an argument
to javac.
<target name="demo">
<!--
Create a path containing a jar file which holds the
custom URL stream handler.
-->
<path id="handler.path">
<pathelement location="${user.home}/my-handler.jar"/>
</path>
<!--
Create a hypothetical custom url stream handler declaration that
declares a datatype under the id corresponding to the stream handler
protocol, declares the handler classname, and reference the path
object within which the handler class can be loaded.
-->
<handler id="artifact" classpathref="handler.path"
class="net.dpml.transit.artifact.Handler"/>
<!--
Declare a path using a hypothetical path element object that takes
a uri as an argument - the implementation of which could evaluate the
the uri scheme and use this to locate the stream handler to be used
as a URL constructor argument. As such, a PathElement.getURL() would
return an appropriate argument during classloader creation.
-->
<path id="example.path">
<pathelement uri="artifact:jar:dpml/util/dpml-cli#1.0.0"/>
</path>
<!--
Use the path in some scenario.
-->
<javac classpathref="example.path"
srcdir="target/build/main" destdir="target/classes/main"/>
</target>
To summarise - the hypothetical content in this example includes:
a) the <handler> datatype used to hold a custom URL stream
handler class that would be referenced by things like
Path.PathElement.
b) The uri attribute on PathElement to allow the declaration
of a path element established using a custom URL (which
conflicts with the current file-based restrictions within
the Path implementation but is feasible given the existance
of Resource.getURL() and underlying support for handler
declaration).
Hope this helps!
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Dominique Devienne [mailto:ddevienne@gmail.com]
> 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:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Dominique Devienne <dd...@gmail.com>.
> > 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?
> 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.
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).
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Dominique Devienne [mailto:ddevienne@gmail.com]
> Sent: Sunday, 24 September 2006 1:27 AM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> > Actual mutation of the system classloader can be handled
> > with relative safety in JRE 1.4 and later via a system
> > property 'java.system.class.loader'
>
> This is news to me Steven. This implies that the system
> classloader would need to query this property to see if it
> changed any time it attempts to locate a new Class, no?
Nope.
> This surprises me. You're positive you can change the system's
> classloader classpath dynamically just by assigning to this property?
Lets take a step back for a moment.
The system property 'java.system.class.loader' is used to declare the name
of custom system classloader class. Given control over the system
classloader it is feasible to declare supplementary operations dealing with
content mutation. For example you could declare methods allowing the
addition and retraction of a classloader to be included in a stack of
classloaders to consulted before consulting the original classpath - and
operations allowing the addition/retraction of classloaders to be consulted
after evaluating the initial and overriding stacks. But as I pointed out -
this is a JRE 1.4 feature.
> You're description of URL custom handlers is pretty good, but
> you gloss over the registration of the custom handlers. Don't
> you still need to install your own handler factory?
Each custom protocol needs a URLStreamHandler which acts as a factory for
URLConnection instances. There are three approaches to handler
registration:
a) declaration of a URLStreamHandlerFactory - which is
problematic because only one instance may be declared for
a given JVM (and there are no chaining semantics) and
this is where complications can occur with applications
that are assigning their own factory
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
Option (b) is the strategy I described in an earlier post - in effect your
dealing with a property that contains a sequence of package names separated
by the '|' character where each package name is used to locate a protocol
handler using the convention '[package-name].[protocol-name].Handler'. A
task within Ant could update the value of this property which in turn would
enable JVM runtime location of custom handlers (assuming the handlers are
resolvable be the system classloader).
> Doesn't
> that require a JVM arg at startup, i.e. you cannot install it
> once the JVM is up?
You can modify the 'java.protocol.handler.pkgs' at runtime.
> I'm still concerned about the use of an
> embedded Ant regarding the custom handler factory.
> Maybe things have changed since I looked at them, but I felt
> that custom URL handlers' registration or discovery was not
> convenient or flexible enough the way the JDK implemented it.
I think the URLStreamHandlerFactory model fits this description. In effect
it does not provide an API to support runtime customization or multiple
factory declaration/chaining. 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.
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Dominique Devienne <dd...@gmail.com>.
> Actual mutation of the system classloader can be handled with relative
> safety in JRE 1.4 and later via a system property 'java.system.class.loader'
This is news to me Steven. This implies that the system classloader
would need to query this property to see if it changed any time it
attempts to locate a new Class, no? This surprises me. You're positive
you can change the system's classloader classpath dynamically just by
assigning to this property?
You're description of URL custom handlers is pretty good, but you
gloss over the registration of the custom handlers. Don't you still
need to install your own handler factory? Doesn't that require a JVM
arg at startup, i.e. you cannot install it once the JVM is up? I'm
still concerned about the use of an embedded Ant regarding the custom
handler factory. Maybe things have changed since I looked at them, but
I felt that custom URL handlers' registration or discovery was not
convenient or flexible enough the way the JDK implemented it. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Scott Stirling <sc...@gmail.com>.
Yes, exactly. Sorry, I missed that. Just re-joined the list after a
long absence. I've implemented "pseudo" or application-level protocol
handlers before to achieve the same goals as here (as I understand
them so far).
Scott S.
> Scott, are you talking about something like option (b)
> that I described at the end of:
>
> http://marc.theaimsgroup.com/?l=ant-dev&m=115885448826992&w=2
>
> ?
>
> -Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Scott Stirling [mailto:scottstirling@gmail.com]
> Sent: Friday, 22 September 2006 11:58 PM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> DD asks:
> > > Does that play well with application containers that
> often embed Ant?
>
> Stephen McConnell replies, in part:
> > Something to keep in mind is that the creation of a URL is handled
> > inside the system classloader. As such when the JVM attempts to
> > locate handler classes, it is limited to classes that exist
> > within the system classloader or system extensions.
> > Application normally deal with this constraint be ensuring
> > that the jar file containing protocol handlers is included in
> > system classloader or is installed as a JVM extension -
> > however, an alternative is to deploy a JVM with
> > a mutable system classloader.
>
> What do you guys mean by "mutable system classloader?" This
> is intriguing but also smells suspicious to me, having worked
> with classloaders quite a bit over the years.
A URL is constructed using the java.net.URL class [1] using something like
new URL( path ). This creates an instance of URL with the supplied
arguments as the instance state. When a client invokes something like
url.openConnection() to establish the connection object (which is trigger by
things like url.getContent() and url.openStream()), the url implementation
has to locate a URLConnection [2] that knows about the url protocol. If the
protocol is one of the standard protocols that ships with a JVM then
everything works as expected. If the protocol is a custom protocol then the
JVM has to find a URLStreamHandler [3] class that will do the work of
creating the dedicated URLConnection instance. If the
URLStreamHandlerFactory exists and the protocol is supported then again -
everything works as expected, otherwise a URLStreamHandler instance will be
instantiated based on the handler path and protocol name strategy I
mentioned earlier - in which case the class must exist in the system
classloader.
Normally the existence of a handler in the system classloader is not a
problem for an application because the system classloader is generally
configurable based on the application launch parameters, however, in the
case of Ant we need to deal with the possibility for the declaration of a
custom handler at the level of a build file. In this scenario the classes
containing the protocol handler need to be added to the system classloader -
hence the requirement for dynamic mutation of system classloader state.
Actual mutation of the system classloader can be handled with relative
safety in JRE 1.4 and later via a system property 'java.system.class.loader'
but Ant is backward compatible relative to JRE 1.2 which precludes the
possibility for using this approach. As a consequence the strategy used in
the examples I've seen on the dev list are focussed on reflective invocation
of the addURL method (and thereby bypassing the package protection on that
method which has a certain smell about it but the smell is understandable
given the 1.2 constraint).
> > > > Enabling the declaration of custom protocol
> > > > handlers as a part of system classloader
> > > > expansion would significantly simply things for
> > > > applications such as Depot (which makes extensive
> > > > use of custom handlers).
>
> Custom protocol handlers can, I know because I've done it, be
> handled in another way by building up support for them at the
> application layer. For example (from a an XML file for
> location metadata:
>
> <map src="cp:maps/first-floor.png"
> xSize="300" ySize="500" name="First Floor"/>
>
> That src="cp:maps/first-floor.png" is handled in code that
> interprets any src attribute value beginning with "cp:" as a
> pointer to a resource that should be loaded from the
> classpath (the cp). This was added to support loading maps in
> a JUnit test context. When the "cp:"
> prefix is not present, the resource is interpreted as a file
> system resource.
>
> This is a simple example. My point is just that custom
> protocol handlers could probably be handled as an application
> layer enhancement, as alternative to leveraging the JVM
> system settings, which is invasive and inconvenient to
> deploy, especially in embedded contexts.
The above example is practical in the scenario where the code resolving the
uri knows about the 'cp:' protocol. The downside of this approach is that
the 'cp' protocol is meaningless outside of that dedicated application. For
example, if I asked you to replace 'cp:maps/first-floor.png' with
'artifact:png:maps/first-floor' the solution would not work (unless you also
provided a protocol to handler mapping and supporting framework), however,
if the solution were reworked to use the URL handling mechanism then it
would work providing that the 'artifact' [5] protocol handler was resolvable
by the JVM.
> > > > the combination of system classloader mutation plus support for
> > > > custom URL handlers would contribute to a significant potential
> > > > simplification of Depot's extensions to the Ant project
> > > > model and task some task implementations.
>
> What is Depot?, if you don't mind me asking, late to the discussion.
Depot [4] is a Java application that handles the automatic building of
multiple projects based on a centralized index of project definitions and
dependencies. When building an individual project is deploys a plugin to
handle the actual build actions (compile, jar, text, etc). Depot's default
builder is a plugin that constructs an embedded Ant project and delegates
execution to the Ant project instance. Depot used a number of custom
protocol handlers which enable things like the loading of a antlib using a
uri value, the importing of templates, etc.
> > Custom handlers allow the introduction of alternative
> > resource identification and retrieval mechanisms. For
> > example - data could be referenced using a query
> > structure expressed as a url and the handler
> > could use the url to interrogate a remote database.
> > Another example is multiple remote data sources (as is
> > the case of the 'artifact' protocol). In these example
> > the custom URL enables the removal of logic concerning
> > resource type and associated retrieval mechanics from
> > application code. This results in greater portability and
> > easier long-term maintenance.
>
> I think you're right. I remember a classic JavaWorld example
> using the protocol handler API to create one for working with
> the Windows registry. That said, in the embedded contexts
> where Ant often runs (IDEs, installers, app servers, other
> tools), it is arguably much more powerful for Ant to be able
> to control such things in its application layer rather than
> depending on system-level JVM configuration.
It is feasible to do this at the application level if Ant maintains a
registry of protocol schemes and associated handlers, and applying new URL(
context, spec, handler ) for all URL instance creation. This would imply a
overhead on all Ant tools and extensions to use a common URL factory
provided in the Ant core. The alternative is to use the existing JVM
configuration mechanisms. Irrespective of the choice - the subject of
system classloader mutation is still a issue when building tasks that need
to customize system behaviour.
> Where would these protocols appear from a user perspective?
This is an interesting question. The subject of this thread places focus on
the revision to the Resource class but raises the overall subject of support
within Ant for custom protocol handlers. My use of custom handlers is mainly
focussed around the loading of plugins (e.g. antlib plus classloader
information), templates, and any resource that is not within a particular
project codebase. Due to the lack of support in Ant for custom protocol
handlers - there are lots of places in Depot where custom uris are resolved
into local file resources before being applied to Ant tasks (e.g. path
creation, imports, etc.).
> In build scripts? If that's the case, then I'd definitely say
> consider letting Ant handle them and convert them to standard
> URLs through a registry mechanism perhaps like the custom
> task registry.
Ultimately I think there is much to be done in Ant related to moving away
from 'file-centric' towards 'stream-centric' logic and within this context
the subject of protocol handler declaration at the level of Ant should in
principal be nothing more than syntactic sugar over the existing JVM
mechanisms.
Cheers, Steve.
[1] http://java.sun.com/j2se/1.4.2/docs/api/java/net/URL.html
[2] http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLConnection.html
[3] http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLStreamHandler.html
[4] http://www.dpml.net/depot/concepts/index.html
[5] http://www.dpml.net/transit/technical/artifact.html
> > > I guess my position on these handlers depends on the ease
> > > to install them to a running JVM, and the actual use
> > > cases having them would
> > > solves. --DD
>
> Scott Stirling
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Matt Benson <gu...@yahoo.com>.
--- Scott Stirling <sc...@gmail.com> wrote:
> DD asks:
> > > Does that play well with application containers
> that often embed Ant?
>
> Stephen McConnell replies, in part:
> > Something to keep in mind is that the creation of
> a URL is handled inside
> > the system classloader. As such when the JVM
> attempts to locate handler
> > classes, it is limited to classes that exist
> within the system classloader
> > or system extensions. Application normally deal
> with this constraint be
> > ensuring that the jar file containing protocol
> handlers is included in
> > system classloader or is installed as a JVM
> extension - however, an
> > alternative is to deploy a JVM with a mutable
> system classloader.
>
> What do you guys mean by "mutable system
> classloader?" This is
> intriguing but also smells suspicious to me, having
> worked with
> classloaders quite a bit over the years.
>
> > > > Enabling the declaration of
> > > > custom protocol handlers as a part of system
> classloader expansion
> > > > would significantly simply things for
> applications such as Depot
> > > > (which makes extensive use of custom
> handlers).
>
> Custom protocol handlers can, I know because I've
> done it, be handled
> in another way by building up support for them at
> the application
> layer. For example (from a an XML file for location
> metadata:
>
> <map src="cp:maps/first-floor.png"
> xSize="300" ySize="500" name="First
> Floor"/>
>
> That src="cp:maps/first-floor.png" is handled in
> code that interprets
> any src attribute value beginning with "cp:" as a
> pointer to a
> resource that should be loaded from the classpath
> (the cp). This was
> added to support loading maps in a JUnit test
> context. When the "cp:"
> prefix is not present, the resource is interpreted
> as a file system
> resource.
>
> This is a simple example. My point is just that
> custom protocol
> handlers could probably be handled as an application
> layer
> enhancement, as alternative to leveraging the JVM
> system settings,
> which is invasive and inconvenient to deploy,
> especially in embedded
> contexts.
>
> > > > the combination of system classloader mutation
> plus support for
> > > > custom URL handlers would contribute to a
> significant potential
> > > > simplification of
> > > > Depot's extensions to the Ant project model
> and task some
> > > task implementations.
>
> What is Depot?, if you don't mind me asking, late to
> the discussion.
>
> > Custom handlers allow the introduction of
> alternative resource
> > identification and retrieval mechanisms. For
> example - data could be
> > referenced using a query structure expressed as a
> url and the handler could
> > use the url to interrogate a remote database.
> Another example is multiple
> > remote data sources (as is the case of the
> 'artifact' protocol). In these
> > example the custom URL enables the removal of
> logic concerning resource
> > type and associated retrieval mechanics from
> application code. This results in
> > greater portability and easier long-term
> maintenance.
>
> I think you're right. I remember a classic JavaWorld
> example using the
> protocol handler API to create one for working with
> the Windows
> registry. That said, in the embedded contexts where
> Ant often runs
> (IDEs, installers, app servers, other tools), it is
> arguably much more
> powerful for Ant to be able to control such things
> in its application
> layer rather than depending on system-level JVM
> configuration.
>
> Where would these protocols appear from a user
> perspective? In build
> scripts? If that's the case, then I'd definitely say
> consider letting
> Ant handle them and convert them to standard URLs
> through a registry
> mechanism perhaps like the custom task registry.
Scott, are you talking about something like option (b)
that I described at the end of:
http://marc.theaimsgroup.com/?l=ant-dev&m=115885448826992&w=2
?
-Matt
>
> > > I guess my position on these handlers depends on
> the ease to
> > > install them to a running JVM, and the actual
> use cases
> > > having them would solves. --DD
>
> Scott Stirling
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Scott Stirling <sc...@gmail.com>.
DD asks:
> > Does that play well with application containers that often embed Ant?
Stephen McConnell replies, in part:
> Something to keep in mind is that the creation of a URL is handled inside
> the system classloader. As such when the JVM attempts to locate handler
> classes, it is limited to classes that exist within the system classloader
> or system extensions. Application normally deal with this constraint be
> ensuring that the jar file containing protocol handlers is included in
> system classloader or is installed as a JVM extension - however, an
> alternative is to deploy a JVM with a mutable system classloader.
What do you guys mean by "mutable system classloader?" This is
intriguing but also smells suspicious to me, having worked with
classloaders quite a bit over the years.
> > > Enabling the declaration of
> > > custom protocol handlers as a part of system classloader expansion
> > > would significantly simply things for applications such as Depot
> > > (which makes extensive use of custom handlers).
Custom protocol handlers can, I know because I've done it, be handled
in another way by building up support for them at the application
layer. For example (from a an XML file for location metadata:
<map src="cp:maps/first-floor.png"
xSize="300" ySize="500" name="First Floor"/>
That src="cp:maps/first-floor.png" is handled in code that interprets
any src attribute value beginning with "cp:" as a pointer to a
resource that should be loaded from the classpath (the cp). This was
added to support loading maps in a JUnit test context. When the "cp:"
prefix is not present, the resource is interpreted as a file system
resource.
This is a simple example. My point is just that custom protocol
handlers could probably be handled as an application layer
enhancement, as alternative to leveraging the JVM system settings,
which is invasive and inconvenient to deploy, especially in embedded
contexts.
> > > the combination of system classloader mutation plus support for
> > > custom URL handlers would contribute to a significant potential
> > > simplification of
> > > Depot's extensions to the Ant project model and task some
> > task implementations.
What is Depot?, if you don't mind me asking, late to the discussion.
> Custom handlers allow the introduction of alternative resource
> identification and retrieval mechanisms. For example - data could be
> referenced using a query structure expressed as a url and the handler could
> use the url to interrogate a remote database. Another example is multiple
> remote data sources (as is the case of the 'artifact' protocol). In these
> example the custom URL enables the removal of logic concerning resource
> type and associated retrieval mechanics from application code. This results in
> greater portability and easier long-term maintenance.
I think you're right. I remember a classic JavaWorld example using the
protocol handler API to create one for working with the Windows
registry. That said, in the embedded contexts where Ant often runs
(IDEs, installers, app servers, other tools), it is arguably much more
powerful for Ant to be able to control such things in its application
layer rather than depending on system-level JVM configuration.
Where would these protocols appear from a user perspective? In build
scripts? If that's the case, then I'd definitely say consider letting
Ant handle them and convert them to standard URLs through a registry
mechanism perhaps like the custom task registry.
> > I guess my position on these handlers depends on the ease to
> > install them to a running JVM, and the actual use cases
> > having them would solves. --DD
Scott Stirling
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Dominique Devienne [mailto:ddevienne@gmail.com]
> Sent: Friday, 22 September 2006 11:44 AM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> > Just for reference I have quite a bit of experience working with
> > custom protocol handlers.
>
> OK, that's better than my casual experience with them. How do
> you install them? What does it require in terms of JVM
> startup arguments?
There are two primary mechanisms:
* declaring a URLStreamHandlerFactory
* declaring the 'java.protocol.handler.pkgs' system property
> Does that play well with application containers that often embed Ant?
The first option (the URLStreamHandlerFactory) can cause problems in that
only one factory may be declared and conflicts can arise with applications
that assume they have control over this resource. The second option is more
flexible in that the system property value can be set within an application
and any existing declarations can be maintained because arguments are
separated by the '|' character (i.e. Ant can read in the value of the
property and supplement that value with any additional protocol package
names that are declared).
An example of the declaration of the 'java.protocol.handler.pkgs' system
property is:
-Djava.protocol.handler.pkgs=net.dpml.transit
In this example the property value identifies a package path which will be
used to resolve a protocol handler. In the case of the Transit resource
management system there are a number of protocols including 'artifact',
'link', and 'local'. When a URL is constructed the protocol is identified
(e.g. file:, http:, or in the case of Transit - artifact:). The JVM uses
the combination of package path and protocol name to locate a protocol
handler using the convention:
[package-path].[protocol-name].Handler
In the case of the DPML Transit artifact protocol [1] and handler [2] this
translates to the class:
net.dpm.transit.artifact.Handler
Something to keep in mind is that the creation of a URL is handled inside
the system classloader. As such when the JVM attempts to locate handler
classes, it is limited to classes that exist within the system classloader
or system extensions. Application normally deal with this constraint be
ensuring that the jar file containing protocol handlers is included in
system classloader or is installed as a JVM extension - however, an
alternative is to deploy a JVM with a mutable system classloader.
> > In the context of Ant this subject will inevitably link back to the
> > subject of system classloader mutation. Enabling the
> > declaration of
> > custom protocol handlers as a part of system classloader expansion
> > would significantly simply things for applications such as Depot
> > (which makes extensive use of custom handlers). In fact the
> > combination of system classloader mutation plus support for
> custom URL
> > handlers would contribute to a significant potential
> simplification of
> > Depot's extensions to the Ant project model and task some
> task implementations.
>
> You're loosing me a bit here ;-) As far as I understand them,
> Ant's new Resource type is kind of a duplicate to URLs to get
> access to some content (stream), but without the "location"
> part. There's already a URLResource I believe, so whatever
> URL the JVM already supports can be hooked up to a resource.
> Why would Ant need to "mess" with custom URL handlers?
Custom handlers allow the introduction of alternative resource
identification and retrieval mechanisms. For example - data could be
referenced using a query structure expressed as a url and the handler could
use the url to interrogate a remote database. Another example is multiple
remote data sources (as is the case of the 'artifact' protocol). In these
example the custom URL enables the removal of logic concerning resource type
and associated retrieval mechanics from application code. This results in
greater portability and easier long-term maintenance.
> I guess my position on these handlers depends on the ease to
> install them to a running JVM, and the actual use cases
> having them would solves. --DD
I'll need to get myself more up-to-date with the resource class and its
usage in Ant to answer this properly (which I'll do in the next few days).
Cheers, Steve.
[1] artifact protocol
http://www.dpml.net/transit/technical/artifact.html
[2] artifact protocol handler javadoc and source
http://www.dpml.net/api/dpml/1.0.2/net/dpml/transit/artifact/Handler.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Dominique Devienne <dd...@gmail.com>.
> Just for reference I have quite a bit of experience working with custom
> protocol handlers.
OK, that's better than my casual experience with them. How do you
install them? What does it require in terms of JVM startup arguments?
Does that play well with application containers that often embed Ant?
> In the context of Ant this subject will inevitably link
> back to the subject of system classloader mutation. Enabling the
> declaration of custom protocol handlers as a part of system classloader
> expansion would significantly simply things for applications such as Depot
> (which makes extensive use of custom handlers). In fact the combination of
> system classloader mutation plus support for custom URL handlers would
> contribute to a significant potential simplification of Depot's extensions
> to the Ant project model and task some task implementations.
You're loosing me a bit here ;-) As far as I understand them, Ant's
new Resource type is kind of a duplicate to URLs to get access to some
content (stream), but without the "location" part. There's already a
URLResource I believe, so whatever URL the JVM already supports can be
hooked up to a resource. Why would Ant need to "mess" with custom URL
handlers?
I guess my position on these handlers depends on the ease to install
them to a running JVM, and the actual use cases having them would
solves. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Resource.getURL()
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Friday, 22 September 2006 4:58 AM
> To: dev@ant.apache.org
> Subject: Re: Resource.getURL()
>
> On Thu, 21 Sep 2006, Matt Benson <gu...@yahoo.com> wrote:
>
> > 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;
>
> Same here.
Just for reference I have quite a bit of experience working with custom
protocol handlers. In the context of Ant this subject will inevitably link
back to the subject of system classloader mutation. Enabling the
declaration of custom protocol handlers as a part of system classloader
expansion would significantly simply things for applications such as Depot
(which makes extensive use of custom handlers). In fact the combination of
system classloader mutation plus support for custom URL handlers would
contribute to a significant potential simplification of Depot's extensions
to the Ant project model and task some task implementations.
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:mcconnell@dpml.net
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 21 Sep 2006, Matt Benson <gu...@yahoo.com> wrote:
> 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;
Same here.
> 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.
If we add them for getURL(), yes, we should be consistent.
> 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.
I'd keep that simple, i.e. return false;
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Matt Benson <gu...@yahoo.com>.
--- Dominique Devienne <dd...@gmail.com> 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:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Dominique Devienne <dd...@gmail.com>.
> > 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.
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), 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Steve Loughran <st...@apache.org>.
Antoine Levy-Lambert wrote:
> Hi,
>
> I would like to add getURL() to Resource before Ant 1.7 ships.
>
> I would add it to the Resource base class, and to ZipResource, FileResource.
>
> I am not clear whether it is better to signal that a particular Resource does not provide URL by throwing UnsupportedOperationException (as Matt suggested) or by returning null.
>
> Concerning custom URLProtocolHandler (s), I am not clear how this works ?
first you provide something that lets you open connections
http://smartfrog.cvs.sourceforge.net/smartfrog/core/extras/cdl/src/org/smartfrog/sfcore/languages/cdl/importing/classpath/ClasspathUrlStreamHandler.java?view=markup
and connections should be openable, or, as in this case, tell you off
for trying to do so
http://smartfrog.cvs.sourceforge.net/smartfrog/core/extras/cdl/src/org/smartfrog/sfcore/languages/cdl/importing/classpath/ClasspathUrlConnection.java?view=markup
The real problem is that to use URLs with URL.openConnection() you need
to register the protocol in the top classloader, or the URL class
cannot open them. The alternative is to have a method in some class,
openConnection(URL), which looks through its list of registered handlers
and picks the right one:
http://smartfrog.cvs.sourceforge.net/smartfrog/core/extras/cdl/src/org/smartfrog/sfcore/languages/cdl/importing/classpath/UrlFactory.java?view=markup
To summarise: ***If you are going to play with URLs, you are going to
discover problems with classloaders***
dont say I didnt warn you...
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hi,
I would like to add getURL() to Resource before Ant 1.7 ships.
I would add it to the Resource base class, and to ZipResource, FileResource.
I am not clear whether it is better to signal that a particular Resource does not provide URL by throwing UnsupportedOperationException (as Matt suggested) or by returning null.
Concerning custom URLProtocolHandler (s), I am not clear how this works ?
Regards,
Antoine
-------- Original-Nachricht --------
Datum: Thu, 21 Sep 2006 10:08:48 +0100
Von: Steve Loughran <st...@apache.org>
An: Ant Developers List <de...@ant.apache.org>
Betreff: Re: Resource.getURL()
> Stefan Bodewig wrote:
> > On Wed, 20 Sep 2006, Matt Benson <gu...@yahoo.com> wrote:
> >> --- Antoine Levy-Lambert <an...@gmx.de> wrote:
> >>
> >>> Hello Matt,
> >>>
> >>> thanks for fixing my fixes !
> >>>
> >>> did you already add getURL() to all Resource(s) ?
> >>> this would be cool to be able to always set the
> >>> SystemId in case of XML documents of all sorts.
> >> I have been thinking it might make sense to add
> >> getURL() to Resource. Did a discussion on that
> >> already take place?
> >
> > I don't remember any.
> >
> > Given that Resource as a class and not an interface we are able to add
> > new methods even after 1.7.0 without running the risk of breaking the
> > code of people who implement their own resources. Given that there
> > wouldn't be any code in Ant 1.7.0 that used getURL() we should defer
> > adding the method as well, IMHO.
>
> maybe, but if a subclass adds its own getURL() method bad things happen.
> Also, if subclasses ought to override it, then we dont give ant1.7-based
> resources a warking.
>
> >
> >> And, for example, what would we do for resources of
> >> nonstandard "protocols"? Would a StringResource with
> >> value "foo" return "string:foo" as its URL? Should we
> >> install custom protocol handlers for built-in
> >> resources and encourage the same be done for
> >> third-party resource implementations?
> >
> > +1 for custom protocol handlers.
>
> Its very hard to add custom protocol handlers in java once you have a
> classloader tree. and you increase the effort needed to implement a
> resource.
>
> How about having a hasURL interface that resources can implement? That
> way things like my <random> component dont need to bother.?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Resource.getURL()
Posted by Steve Loughran <st...@apache.org>.
Stefan Bodewig wrote:
> On Wed, 20 Sep 2006, Matt Benson <gu...@yahoo.com> wrote:
>> --- Antoine Levy-Lambert <an...@gmx.de> wrote:
>>
>>> Hello Matt,
>>>
>>> thanks for fixing my fixes !
>>>
>>> did you already add getURL() to all Resource(s) ?
>>> this would be cool to be able to always set the
>>> SystemId in case of XML documents of all sorts.
>> I have been thinking it might make sense to add
>> getURL() to Resource. Did a discussion on that
>> already take place?
>
> I don't remember any.
>
> Given that Resource as a class and not an interface we are able to add
> new methods even after 1.7.0 without running the risk of breaking the
> code of people who implement their own resources. Given that there
> wouldn't be any code in Ant 1.7.0 that used getURL() we should defer
> adding the method as well, IMHO.
maybe, but if a subclass adds its own getURL() method bad things happen.
Also, if subclasses ought to override it, then we dont give ant1.7-based
resources a warking.
>
>> And, for example, what would we do for resources of
>> nonstandard "protocols"? Would a StringResource with
>> value "foo" return "string:foo" as its URL? Should we
>> install custom protocol handlers for built-in
>> resources and encourage the same be done for
>> third-party resource implementations?
>
> +1 for custom protocol handlers.
Its very hard to add custom protocol handlers in java once you have a
classloader tree. and you increase the effort needed to implement a
resource.
How about having a hasURL interface that resources can implement? That
way things like my <random> component dont need to bother.?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org