Re: SourceResolver in SSF
Grzegorz Kossakowski wrote: Ralph Goers pisze: I'm not sure what JNet actually is, but the part I was referring to was where Carsten was talking about Excalibur being dead and pulling out the few pieces we use. Maybe it's better that Carsten explains what he meant. :) Yepp I meant we could pull out the code we use from Excalibur into our svn and therefore under our control *without* changing package names, artifact ids etc. We just establish them as *our* sub projects. So, there is no change from a user pov (I mean other users as cocoon), but we get full control over the code. Now we could have the same by just bringing all cocoon developers over to Excalibur. We could also merge the two projects? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: SourceResolver in SSF
I have no problem with merging the PMCs. I am not in favor of merging the source code. Carsten Ziegeler wrote: Grzegorz Kossakowski wrote: Ralph Goers pisze: I'm not sure what JNet actually is, but the part I was referring to was where Carsten was talking about Excalibur being dead and pulling out the few pieces we use. Maybe it's better that Carsten explains what he meant. :) Yepp I meant we could pull out the code we use from Excalibur into our svn and therefore under our control *without* changing package names, artifact ids etc. We just establish them as *our* sub projects. So, there is no change from a user pov (I mean other users as cocoon), but we get full control over the code. Now we could have the same by just bringing all cocoon developers over to Excalibur. We could also merge the two projects? Carsten
Re: SourceResolver in SSF
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare an
official release. :-)
First we have to discuss, which project does the release? Do we want to pull it
into Cocoon? TBH, I'd rather get rid of Excalibur dependencies that creating
another one.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: SourceResolver in SSF
Grzegorz Kossakowski wrote:
Carsten, I've taken a look at your code and it looks very nice. I have
2. All we need to do in SSF is:
a) implement our own SourceFactoriesManager (by extending your
abstrac class)
No :) Just use SourceFactoriesManager.pushFactories when the request
starts and popFactories at the end of the request. This can then also
be used for different factories depending on the block that is
currently executed.
So it's like switching the block context.
3. I'm not sure if I understand this fragment (taken from
SourceURLConnection):
if ( contentType == null ) {
this.contentType = contentType;
}
Shouldn't be here a check for *not* null?
D'oh - yes, thanks for spotting this.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
Re: SourceResolver in SSF
Reinhard Poetz wrote: Grzegorz Kossakowski wrote: 1. If you want other projects to use your stuff you need to prepare an official release. :-) First we have to discuss, which project does the release? Do we want to pull it into Cocoon? TBH, I'd rather get rid of Excalibur dependencies that creating another one. Hmm, yes, I tend to agree. But jnet needs to be a separate project when it proofs to be useful (which i think it is). We already have the configuration stuff and the ssf, so we could jnet here as well as a separate subproject. I've no problem with that. However, as it will be a separate project you still have the dependency. Jnet currently depends on sourceresolve 3.0 which is an avalon free version of sourceresolve...so the whole thing is not that easy :) I think we should try to get the avalon free sourceresolve out of the door at excalibur asap. And perhaps move jnet as its own subproject over to Cocoon? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: SourceResolver in SSF
I think I'm wrong, we could also change the dep from jnet to sourceresolve to use the avalon version as a start. Carsten Carsten Ziegeler wrote: Reinhard Poetz wrote: Grzegorz Kossakowski wrote: 1. If you want other projects to use your stuff you need to prepare an official release. :-) First we have to discuss, which project does the release? Do we want to pull it into Cocoon? TBH, I'd rather get rid of Excalibur dependencies that creating another one. Hmm, yes, I tend to agree. But jnet needs to be a separate project when it proofs to be useful (which i think it is). We already have the configuration stuff and the ssf, so we could jnet here as well as a separate subproject. I've no problem with that. However, as it will be a separate project you still have the dependency. Jnet currently depends on sourceresolve 3.0 which is an avalon free version of sourceresolve...so the whole thing is not that easy :) I think we should try to get the avalon free sourceresolve out of the door at excalibur asap. And perhaps move jnet as its own subproject over to Cocoon? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: SourceResolver in SSF
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare
an official release. :-)
First we have to discuss, which project does the release? Do we want
to pull it into Cocoon? TBH, I'd rather get rid of Excalibur
dependencies that creating another one.
Hmm, yes, I tend to agree. But jnet needs to be a separate project when
it proofs to be useful (which i think it is). We already have the
configuration stuff and the ssf, so we could jnet here as well as a
separate subproject. I've no problem with that. However, as it will be a
separate project you still have the dependency.
Jnet currently depends on sourceresolve 3.0 which is an avalon free
version of sourceresolve...so the whole thing is not that easy :)
I think we should try to get the avalon free sourceresolve out of the
door at excalibur asap. And perhaps move jnet as its own subproject over
to Cocoon?
My problem is not having dependencies in general but with dependencies that
don't have another user than us. It just introduces another layer of bureaucracy
making things more complicated for us without a noticeable benefit.
Since we have to depend on sourceresolve anyway, it doesn't matter if there is
another dependency on jnet that his hosted by Excalibur.
The other option is pulling the sourceresolve code into Cocoon too and promoting
it to the level of a subproject.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: SourceResolver in SSF
Carsten Ziegeler wrote:
The problematic part is the time frame. I would suggest to just copy the
jnet classes to SSF to be able to release SSF in a short time frame.
Shouldn't we rather create another subproject jnet?
We can then sort out the details after Easter.
Just to be clear: Do you propose to wait with the release of 1.0.0 of SSF until
jnet/sourceResolver are properly integrated? (Since we would otherwise ship a
SSF that is only partly useable without cocoon-core I think it makes sense ...)
I should find some time after the Apachecon to cut the release then.
WDYT?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: SourceResolver in SSF
Reinhard Poetz wrote: Carsten Ziegeler wrote: The problematic part is the time frame. I would suggest to just copy the jnet classes to SSF to be able to release SSF in a short time frame. Shouldn't we rather create another subproject jnet? Yes, in the long run. But to get out SSF asap I would just copy the classes. This is internal stuff, so this shouldn't cause problems if the packages, classes or methods change after the SSF release. We can then sort out the details after Easter. Just to be clear: Do you propose to wait with the release of 1.0.0 of SSF until jnet/sourceResolver are properly integrated? (Since we would otherwise ship a SSF that is only partly useable without cocoon-core I think it makes sense ...) I propose to release 1.0.0 with a copy of jnet inside SSF; after the release of 1.0.0 we sort out where and how we want to have the code. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: SourceResolver in SSF
Reinhard Poetz wrote: Carsten Ziegeler wrote: Reinhard Poetz wrote: Grzegorz Kossakowski wrote: 1. If you want other projects to use your stuff you need to prepare an official release. :-) First we have to discuss, which project does the release? Do we want to pull it into Cocoon? TBH, I'd rather get rid of Excalibur dependencies that creating another one. Hmm, yes, I tend to agree. But jnet needs to be a separate project when it proofs to be useful (which i think it is). We already have the configuration stuff and the ssf, so we could jnet here as well as a separate subproject. I've no problem with that. However, as it will be a separate project you still have the dependency. Jnet currently depends on sourceresolve 3.0 which is an avalon free version of sourceresolve...so the whole thing is not that easy :) I think we should try to get the avalon free sourceresolve out of the door at excalibur asap. And perhaps move jnet as its own subproject over to Cocoon? My problem is not having dependencies in general but with dependencies that don't have another user than us. It just introduces another layer of bureaucracy making things more complicated for us without a noticeable benefit. I agree. Since we have to depend on sourceresolve anyway, it doesn't matter if there is another dependency on jnet that his hosted by Excalibur. Yes :( The other option is pulling the sourceresolve code into Cocoon too and promoting it to the level of a subproject. Now, I think that this will be over time the best solution *if* we can keep the excalibur package names - but I think that should be possible. Let's face it, Excalibur is more or less a dead project. The stuff there is useful and used in some projects, but there is no community anymore to support stuff. We are the strongest users of some of the stuff there (sourceresolve, xml, store), so moving these things seems to be a good choice. The problematic part is the time frame. I would suggest to just copy the jnet classes to SSF to be able to release SSF in a short time frame. We can then sort out the details after Easter. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: SourceResolver in SSF
Carsten Ziegeler wrote: Yes, in the long run. But to get out SSF asap I would just copy the classes. This is internal stuff, so this shouldn't cause problems if the packages, classes or methods change after the SSF release. +1 I propose to release 1.0.0 with a copy of jnet inside SSF; after the release of 1.0.0 we sort out where and how we want to have the code. I'm not sure if this is the best option. I hoped to have final release of 1.0.0 before Easter. Integration of JNet, which seems to be an easy task will postpone the release for a few weeks because someone must do this integration, then we will need to test it and only then release. I think everyone will agree that most users of SSF will be users of Cocoon 2.2 as well, at least at the beginning. We don't have a good documentation explaining how to use SSF outside Cocoon land and why it would be useful to do so. Having said that, I don't expect many people upset about dependency on CocoonSourceResolver. I think putting a bold remark that there is a limitation in 1.0.0 release that will get resolved ASAP is enough. Therefore I propose: 1. Make a 1.0.0 of SSF as it's now so Cocoon users can consume it and we will be able to release other artifacts in final version. (Remember: we can't release Cocoon Core 2.2 final if we don't have final release of SSF) 2. Integrate JNet by copying the code, cut first milestone of 1.1.0. This way we will deliver truly Cocoon-independent version of SSF for early adapters and at the same time we will get some time to sort out what to do with JNet code. 3. (Possibly) Create subproject 'JNet', fix bugs in SSF 1.1.0-M1 if any found. 4. Make final relase of JNet 1.0.0 and SSF 1.1.0. Does it make sense? -- Grzegorz
Re: SourceResolver in SSF
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
The problematic part is the time frame. I would suggest to just copy
the jnet classes to SSF to be able to release SSF in a short time frame.
Shouldn't we rather create another subproject jnet?
Yes, in the long run. But to get out SSF asap I would just copy the
classes. This is internal stuff, so this shouldn't cause problems if the
packages, classes or methods change after the SSF release.
We can then sort out the details after Easter.
Just to be clear: Do you propose to wait with the release of 1.0.0 of
SSF until jnet/sourceResolver are properly integrated? (Since we would
otherwise ship a SSF that is only partly useable without cocoon-core I
think it makes sense ...)
I propose to release 1.0.0 with a copy of jnet inside SSF; after the
release of 1.0.0 we sort out where and how we want to have the code.
Ok. Is there anything to be done on the sourceresolve side? e.g. releasing
sourceresolve 3.0?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: SourceResolver in SSF
Carsten Ziegeler wrote: No :) Just use SourceFactoriesManager.pushFactories when the request starts and popFactories at the end of the request. This can then also be used for different factories depending on the block that is currently executed. So it's like switching the block context. Yep, got it now. Anyway, even laconic javadoc comments would be _very_ helpful. :-) -- Grzegorz
Re: SourceResolver in SSF
Grzegorz Kossakowski wrote: Carsten Ziegeler wrote: Yes, in the long run. But to get out SSF asap I would just copy the classes. This is internal stuff, so this shouldn't cause problems if the packages, classes or methods change after the SSF release. +1 I propose to release 1.0.0 with a copy of jnet inside SSF; after the release of 1.0.0 we sort out where and how we want to have the code. I'm not sure if this is the best option. I hoped to have final release of 1.0.0 before Easter. Integration of JNet, which seems to be an easy task will postpone the release for a few weeks because someone must do this integration, then we will need to test it and only then release. I think everyone will agree that most users of SSF will be users of Cocoon 2.2 as well, at least at the beginning. We don't have a good documentation explaining how to use SSF outside Cocoon land and why it would be useful to do so. Having said that, I don't expect many people upset about dependency on CocoonSourceResolver. I think putting a bold remark that there is a limitation in 1.0.0 release that will get resolved ASAP is enough. Therefore I propose: 1. Make a 1.0.0 of SSF as it's now so Cocoon users can consume it and we will be able to release other artifacts in final version. (Remember: we can't release Cocoon Core 2.2 final if we don't have final release of SSF) 2. Integrate JNet by copying the code, cut first milestone of 1.1.0. This way we will deliver truly Cocoon-independent version of SSF for early adapters and at the same time we will get some time to sort out what to do with JNet code. 3. (Possibly) Create subproject 'JNet', fix bugs in SSF 1.1.0-M1 if any found. 4. Make final relase of JNet 1.0.0 and SSF 1.1.0. Does it make sense? Yepp, +1 Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: SourceResolver in SSF
As a user of sourceresolve independent of Cocoon I would be -1 on moving it into Cocoon. If it goes anywhere I'd prefer commons. Carsten Ziegeler wrote: Now, I think that this will be over time the best solution *if* we can keep the excalibur package names - but I think that should be possible. Let's face it, Excalibur is more or less a dead project. The stuff there is useful and used in some projects, but there is no community anymore to support stuff. We are the strongest users of some of the stuff there (sourceresolve, xml, store), so moving these things seems to be a good choice. The problematic part is the time frame. I would suggest to just copy the jnet classes to SSF to be able to release SSF in a short time frame. We can then sort out the details after Easter. WDYT? Carsten
Re: SourceResolver in SSF
Ralph Goers pisze: As a user of sourceresolve independent of Cocoon I would be -1 on moving it into Cocoon. If it goes anywhere I'd prefer commons. Ralph, I'm not sure if you have followed the whole thread. We don't want to tie JNet code with Cocoon but only to establish a subproject of Cocoon and keep it still independent in terms of code dependencies. This way you will still be able to use it outside the Cocoon. -- Grzegorz Kossakowski
Re: SourceResolver in SSF
I'm not sure what JNet actually is, but the part I was referring to was where Carsten was talking about Excalibur being dead and pulling out the few pieces we use. Grzegorz Kossakowski wrote: Ralph Goers pisze: As a user of sourceresolve independent of Cocoon I would be -1 on moving it into Cocoon. If it goes anywhere I'd prefer commons. Ralph, I'm not sure if you have followed the whole thread. We don't want to tie JNet code with Cocoon but only to establish a subproject of Cocoon and keep it still independent in terms of code dependencies. This way you will still be able to use it outside the Cocoon.
Re: SourceResolver in SSF
Ralph Goers pisze: I'm not sure what JNet actually is, but the part I was referring to was where Carsten was talking about Excalibur being dead and pulling out the few pieces we use. Maybe it's better that Carsten explains what he meant. Anyway, my understanding is to bring JNet which is small piece of code described in this e-mail: http://article.gmane.org/gmane.text.xml.cocoon.devel/77146 -- Grzegorz
Re: SourceResolver in SSF
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]
Re: SourceResolver in SSF
Carsten Ziegeler wrote: 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. Yes, IIRC this was born in Equinox when some people started using OSGi in webapps. Felix also has an implementation, which seems to take a large variety of JVMs in to account [1] It might be worth considering a common low-level layer to handle this in various contexts (Felix, Cocoon, etc) Sylvain [1] http://svn.apache.org/repos/asf/felix/trunk/framework/src/main/java/org/apache/felix/framework/URLHandlers.java -- Sylvain Wallez - http://bluxte.net
Re: SourceResolver in SSF
Sylvain Wallez wrote: Carsten Ziegeler wrote: 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. Yes, IIRC this was born in Equinox when some people started using OSGi in webapps. Felix also has an implementation, which seems to take a large variety of JVMs in to account [1] It might be worth considering a common low-level layer to handle this in various contexts (Felix, Cocoon, etc) Yes, that is the reason why I started jnet :) (unfortunately I never had time to finish this) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: SourceResolver in SSF
Carsten Ziegeler wrote:
Yes, that is the reason why I started jnet :) (unfortunately I never had
time to finish this)
What's left? Only polishing or more?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: SourceResolver in SSF
Reinhard Poetz wrote: Carsten Ziegeler wrote: Yes, that is the reason why I started jnet :) (unfortunately I never had time to finish this) What's left? Only polishing or more? Polishing and trying to convince the projects to use it :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: SourceResolver in SSF
Carsten Ziegeler pisze:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Yes, that is the reason why I started jnet :) (unfortunately I never
had time to finish this)
What's left? Only polishing or more?
Polishing and trying to convince the projects to use it :)
Carsten, I've taken a look at your code and it looks very nice. I have few
comments/questions:
1. If you want other projects to use your stuff you need to prepare an official
release. :-)
Could you prepare first milestone release of JNet before Friday? I could try to integrate this
code with SSF during easter egg Christmas.
2. All we need to do in SSF is:
a) implement our own SourceFactoriesManager (by extending your abstrac class)
b) call Installer.setURLStreamHandlerFactory at the startup and set it to
DynamicURLStreamHandlerFactory. Push existing factory on it.
Did I miss something? Or maybe we should install it on every request? Then,
how to uninstall it?
3. I'm not sure if I understand this fragment (taken from SourceURLConnection):
if ( contentType == null ) {
this.contentType = contentType;
}
Shouldn't be here a check for *not* null?
--
Best regards,
Grzegorz Kossakowski
Re: SourceResolver in SSF
Grzegorz Kossakowski wrote: Carsten Ziegeler pisze: Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176 My plan is to register default Excalibur's SourceResolver implementation as a Spring-bean and use it by default. Then, Cocoon Core would replace it with CocoonSourceResolver using Spring configurator features (property overriding, etc.). Not sure if it helps you, but can't we change the SSF to just rely on java.net.URL and use excaliburs jnet underneath? I don't know JNet and new solutions for source resolving so cannot comment. Any pointers to documentation or discussions? So far there is only the source code :( Ok, we planned to do this step in Cocoon for years: just using plain java.net.URL objects to get access the different sources. Now, unfortunately even today, Sun has not provided a usable api to register own url handlers. So this is the main challenge as you can only register a url handler once for the whole jvm. And as some application containers register their own url handler on startup, a webapp can't do this anymore. Not to mention the problem when you have more than one webapp trying to do this. However, there is a trick (or call it hack) to circumvent this problem by using reflection and registering a proxy which then forwards to the appropriate url handler. Jnet has an implementation for this and is able to forward it to excalibur's source resolver or more precisely directly to the source factories. Now to work propertly for each request jnet needs to be notified which source factories are available and when the request is finished, this needs to be cleared. So it basically like the context change we use in cocoon. Then you can do something like URL u = new URL(cocoon:/mypipeline); u.getInputStream(); // or similar Of course, when it comes to XML getting an input stream is not the best choice, therefore there is an additional handling, so you can call u.getContent(SAXResult.class) returning a SAXResult (from the javax.xml package) Using this you have direct streaming of sax events (if the source provides it) without using any additional interfaces. Now, this comes with one problem: the hack to register the url handler proxy might not work on all jvms, it should work on all Sun jvms and getting it running on Harmony shouldn't be a problem. I think its running on ibms jvm as well, but i'm not sure. So, this is the rough idea - the implementation is a first prototype I did last year, so there might be some rough edges. If this code is of interest we could also move it to Cocoon to have better control. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: SourceResolver in SSF
Carsten Ziegeler pisze: Grzegorz Kossakowski wrote: Carsten Ziegeler pisze: Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176 My plan is to register default Excalibur's SourceResolver implementation as a Spring-bean and use it by default. Then, Cocoon Core would replace it with CocoonSourceResolver using Spring configurator features (property overriding, etc.). Not sure if it helps you, but can't we change the SSF to just rely on java.net.URL and use excaliburs jnet underneath? I don't know JNet and new solutions for source resolving so cannot comment. Any pointers to documentation or discussions? So far there is only the source code :( Ok, we planned to do this step in Cocoon for years: just using plain java.net.URL objects to get access the different sources. Now, unfortunately even today, Sun has not provided a usable api to register own url handlers. So this is the main challenge as you can only register a url handler once for the whole jvm. And as some application containers register their own url handler on startup, a webapp can't do this anymore. Not to mention the problem when you have more than one webapp trying to do this. However, there is a trick (or call it hack) to circumvent this problem by using reflection and registering a proxy which then forwards to the appropriate url handler. Jnet has an implementation for this and is able to forward it to excalibur's source resolver or more precisely directly to the source factories. Now to work propertly for each request jnet needs to be notified which source factories are available and when the request is finished, this needs to be cleared. So it basically like the context change we use in cocoon. Then you can do something like URL u = new URL(cocoon:/mypipeline); u.getInputStream(); // or similar Of course, when it comes to XML getting an input stream is not the best choice, therefore there is an additional handling, so you can call u.getContent(SAXResult.class) returning a SAXResult (from the javax.xml package) Using this you have direct streaming of sax events (if the source provides it) without using any additional interfaces. Now, this comes with one problem: the hack to register the url handler proxy might not work on all jvms, it should work on all Sun jvms and getting it running on Harmony shouldn't be a problem. I think its running on ibms jvm as well, but i'm not sure. So, this is the rough idea - the implementation is a first prototype I did last year, so there might be some rough edges. If this code is of interest we could also move it to Cocoon to have better control. 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? :-) 2. What about debugging? What about stracktraces? Won't reflection hack break something? 3. How intrusive it would be to integrate JNet into SSF? 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. 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. -- Grzegorz Kossakowski
