commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giorgio Gallo <giorg...@overlord.it>
Subject Re: [JELLY] exotic URL protocols
Date Tue, 12 Apr 2005 22:19:57 GMT
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
> 

Mime
View raw message