Grzegorz Kossakowski wrote:
Thanks Carsten for a summary!
To be honest, I'm not sure what kind of action we should take here. What
you described sounds great and it's very tempting to have sources
properly working with just standard URL class.
Anyway, I'm little bit worried that whole things bases on *ugly* hack.
I'm wondering how reliable the solution is. I have a few additional
questions:
1. Has this technique (not necessarily JNet's implementation) been used
in some project? Or it's your brilliant invention? :-)
Hehe, no, afaik other projects are using this as well and I borrowed the
idea from there and made my own implementation. Among the projects is
Equinox, the platform for Eclipse. I think there are some other projects
out there using this as well.
2. What about debugging? What about stracktraces? Won't reflection hack
break something?
Ah ok, the reflection is just used to register an own url handler. As
you can't call setHandler (the actual method name is different but I
don't remember it) you search via reflection for the "handler" property
and change this through reflection.
3. How intrusive it would be to integrate JNet into SSF?
I think this has minimal impact; in theory you don't need jnet at all,
just use plain urls in SSF and you're done.
Cocoon can then use jnet to make the Spring source factories available
as plain url objects.
I'm interested in experimenting with your work but since this issue is
rather urgent I would like to be able to count on your help if it's me
who is going to resolve this problem.
Sure, count me in :)
What do others think?
PS. Here we are talking about SSF only at the moment. Inside
SitemapServlet the CocoonSourceResolver will be preserved, at least for
now.
Yepp, things change hopefully with Corona :)
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
