You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Giorgio Gallo <gi...@overlord.it> on 2005/04/11 20:30:02 UTC
[JELLY] exotic URL protocols
I am trying to write a patch to solve issue JELLY-208
(http://issues.apache.org/jira/browse/JELLY-208)
Let me know if you committers prefer to handle this one directly,
because of the fact that URLs contain "/" beeing assumed just about
everywhere in jelly... :)
Also:
Thomas Burns (the issue reporter) mentions a "custom url protocol".
It is not needed for the specific issue to manifest (think of
"file:script.jelly") to have a custom protocol, but it could be the case
that a protocol does not use the "usual" URL pattern
(protocol://user:password@host:port/path...) and that therefore we (ie:
jelly) cannot resolve relative URLs simply by parsing the string
representation of the base URL and assuming it has more meaning that
protocol:opaquePart...
Besides modifying jelly to ALWAYS use
new URL(URL, String)
to resolve relative URLs, another fact should/could be addressed: it
could be impossible in some protocols to infer the "parent" URL of a
script from the script's own URL (ie: it's what
JellyContext#getJellyContextURL does)
I see a few options to address this:
1. The "protocol:<opaquePart>" thing above comes from some confused
corner of my head and I have to read RFCs again :)
2. Declare those "exotic" protocols unsupported :)
3. Refactor jelly to use a script's very url (eg:
file:///dir/dir/script.jelly) to resolve relative URLs and remove
auto-detection of "context URLs" altoghether (ie: context-relative URLs
will be resolved against the script URL unless a different context URL
is explicitly specifyed)
4. use null as context url when there are no "/"s and assume the usual
URL pattern if a "/" is present
I would opt for the third possibility (really - can't see any drawback
in it, not at 4:00AM at least).
Please let me know if such a patch would be welcome or, again, if it's
like you committers prefer to handle this on your own.
(please pardon me if my english is not very clear)
rgds,
Giorgio
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [JELLY] exotic URL protocols
Posted by Giorgio Gallo <gi...@overlord.it>.
ups! just realised my .classpath got into the patch - sorry :)
BTW: shouldn't it be removed from svn?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [JELLY] exotic URL protocols
Posted by Giorgio Gallo <gi...@overlord.it>.
Couldn't do it without letting a context's currentUrl be the full url of
the script - sorry :)
I didn't remove the rootUrl stuff: it's still inferred from currentUrl
(although context-relative url resolution uses new URL(URL, String) now)
I used jdk 1.3.1
---
TODO:
- org.apache.commons.jelly.task.JellyTask needs fixing
- org.apache.commons.jelly.test.BaseJellyTest needs fixing
(BTW: it's in src/java instead of into src/test)
- org.apache.commons.jelly.core.BaseMemoryLeakTest could need fixing
---
I took a look at xml-commons-resolver: didn't know xml had a commons
project...
It looks like an implementation of OASIS xml catalog - AFAIK it is a
standard for mapping URNs to URLs (eg: for locating the DTD
corresponding to a particular public doctype).
I guess it could be helpful for the tag-library stuff: jelly could
set-up a catalog based on all the catalog files it finds inside the
various META-INF in the classpath and use it for locating taglib
descriptors (if they are to be introduced into jelly - or classes
otherwise).
I imagine we could even let taglibs be defined via doctype declarations
instead of xmlns attributes... it could sound a little bit useless but i
think it would be really cool :)
About "exotic" URL schemes, what I was trying to say is that
URL-to-resource resolution is entirely dependand on the URL scheme (ie:
protocol): in the patch I added two tests wich use a custom URL scheme
named "dummyprotocol" that resolves
dummyprotocol:a.jelly
to the file
src/test/org/apache/commons/jelly/core/a.jelly
In the same way I could define a scheme to resolve
home:///giorgio/a.jelly
to the file
/home/giorgio/a.jelly
All theese custom protocols pose no problems to jelly as long as they
have a path-like structure, with path elements separated by '/' and in
"descending" order.
Now imagine i want to define a scheme that maps URLs to email messages:
your message (ie: the one I am replying to) is assigned and id (I guess
from your smtp - but I don't know really who assigns theese ids) of
22d3fadc8e263f199b950a476aeab8e4@activemath.org.
I could want to resolve
emailmessage:22d3fadc8e263f199b950a476aeab8e4@activemath.org
to that message and write an URLStreamHandler that does so.
Well, there are really no relative urls inside an email message (besides
stuff inside the message itself) so never mind about if this could pose
any threat to jelly... :)
Let's go back to the "home:" stuff.
Instead of the former "usual-way-structured" scheme, I could (for
whatever reason) want to have URLs like
home:a.jelly@giorgio
resolved to files inside my home directory - and i could write an
URLStreamHandler to do so.
What about referring to a file that is beneath my home dir, buryed into
tons of subfolders?
It could be
home:java-stuff/asf/jelly/src/org/[...]/core/a.jelly@giorgio
and this would definitely break jelly...
Hope to have my point explained a little bit more clearly than yesterday
- I was _really_ sleepy when I wrote that message :)
PS:
Sorry for the crappy examples - I just couldn't think of any widely-used
protocol which doesn't use a path-like structure and is commonly used
with relative urls...
Paul Libbrecht wrote:
> Giorgio,
>
> I am not sure I have grasped the whole picture...
>
> Would you be able to make a first patch that only tackles the usage of
> new URL(url) and then pinpoint the further issues ?
>
> I am wondering if the usage of xml-commons-resolver would not help here
> ? It's a quite small package, it's well licensed (!), and it's very
> close to our needs.
>
> paul
>
>
> Le 11 avr. 05, à 20:30, Giorgio Gallo a écrit :
>
>>
>> I am trying to write a patch to solve issue JELLY-208
>> (http://issues.apache.org/jira/browse/JELLY-208)
>>
>> Let me know if you committers prefer to handle this one directly,
>> because of the fact that URLs contain "/" beeing assumed just about
>> everywhere in jelly... :)
>>
>> Also:
>>
>> Thomas Burns (the issue reporter) mentions a "custom url protocol".
>>
>> It is not needed for the specific issue to manifest (think of
>> "file:script.jelly") to have a custom protocol, but it could be the case
>> that a protocol does not use the "usual" URL pattern
>> (protocol://user:password@host:port/path...) and that therefore we (ie:
>> jelly) cannot resolve relative URLs simply by parsing the string
>> representation of the base URL and assuming it has more meaning that
>> protocol:opaquePart...
>>
>> Besides modifying jelly to ALWAYS use
>> new URL(URL, String)
>> to resolve relative URLs, another fact should/could be addressed: it
>> could be impossible in some protocols to infer the "parent" URL of a
>> script from the script's own URL (ie: it's what
>> JellyContext#getJellyContextURL does)
>>
>>
>> I see a few options to address this:
>>
>> 1. The "protocol:<opaquePart>" thing above comes from some confused
>> corner of my head and I have to read RFCs again :)
>>
>> 2. Declare those "exotic" protocols unsupported :)
>>
>> 3. Refactor jelly to use a script's very url (eg:
>> file:///dir/dir/script.jelly) to resolve relative URLs and remove
>> auto-detection of "context URLs" altoghether (ie: context-relative URLs
>> will be resolved against the script URL unless a different context URL
>> is explicitly specifyed)
>>
>> 4. use null as context url when there are no "/"s and assume the usual
>> URL pattern if a "/" is present
>>
>>
>> I would opt for the third possibility (really - can't see any drawback
>> in it, not at 4:00AM at least).
>>
>> Please let me know if such a patch would be welcome or, again, if it's
>> like you committers prefer to handle this on your own.
>>
>> (please pardon me if my english is not very clear)
>>
>> rgds,
>> Giorgio
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [JELLY] exotic URL protocols
Posted by Paul Libbrecht <pa...@activemath.org>.
Giorgio,
I am not sure I have grasped the whole picture...
Would you be able to make a first patch that only tackles the usage of
new URL(url) and then pinpoint the further issues ?
I am wondering if the usage of xml-commons-resolver would not help here
? It's a quite small package, it's well licensed (!), and it's very
close to our needs.
paul
Le 11 avr. 05, à 20:30, Giorgio Gallo a écrit :
>
> I am trying to write a patch to solve issue JELLY-208
> (http://issues.apache.org/jira/browse/JELLY-208)
>
> Let me know if you committers prefer to handle this one directly,
> because of the fact that URLs contain "/" beeing assumed just about
> everywhere in jelly... :)
>
> Also:
>
> Thomas Burns (the issue reporter) mentions a "custom url protocol".
>
> It is not needed for the specific issue to manifest (think of
> "file:script.jelly") to have a custom protocol, but it could be the
> case
> that a protocol does not use the "usual" URL pattern
> (protocol://user:password@host:port/path...) and that therefore we (ie:
> jelly) cannot resolve relative URLs simply by parsing the string
> representation of the base URL and assuming it has more meaning that
> protocol:opaquePart...
>
> Besides modifying jelly to ALWAYS use
> new URL(URL, String)
> to resolve relative URLs, another fact should/could be addressed: it
> could be impossible in some protocols to infer the "parent" URL of a
> script from the script's own URL (ie: it's what
> JellyContext#getJellyContextURL does)
>
>
> I see a few options to address this:
>
> 1. The "protocol:<opaquePart>" thing above comes from some confused
> corner of my head and I have to read RFCs again :)
>
> 2. Declare those "exotic" protocols unsupported :)
>
> 3. Refactor jelly to use a script's very url (eg:
> file:///dir/dir/script.jelly) to resolve relative URLs and remove
> auto-detection of "context URLs" altoghether (ie: context-relative URLs
> will be resolved against the script URL unless a different context URL
> is explicitly specifyed)
>
> 4. use null as context url when there are no "/"s and assume the usual
> URL pattern if a "/" is present
>
>
> I would opt for the third possibility (really - can't see any drawback
> in it, not at 4:00AM at least).
>
> Please let me know if such a patch would be welcome or, again, if it's
> like you committers prefer to handle this on your own.
>
> (please pardon me if my english is not very clear)
>
> rgds,
> Giorgio
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org