You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2008/03/15 15:36:59 UTC
COCOON-2150 testing
Hello guys,
I believe that COCOON-2150 is finally fixed but that was quite radical change involving lots of
conditional coding craft so I cannot be entirely sure if I hadn't missed any obscure case.
Therefore I would like you to give latest trunk Cocoon version extensive testing and observing if
there are no errors reported by servlet container or Cocoon.
I plan to decorate this code with some comments to increase readability.
--
Best regards,
Grzegorz
Re: SourceResolver in SSF
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: SourceResolver in SSF
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: SourceResolver in SSF
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: Code freeze
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz pisze:
>
> I released everything except the cocoon-servlet-service-components which
> depend on cocoon-core. But this shouldn't be relevant for the JNet
> integration.
>
Hmmm, it will be relevant because I'll need to move blockcontext source from components to impl. I
think that creation of branches for 1.0.0 line is the safest option for now.
If they turn out to be superfluous we can always remove them and move to 1.1.0 line definitively.
I'll create them right away.
Thanks for your hard work Reinhard!
--
Grzegorz
Re: Code freeze
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Ok. Then I will create the release artifacts for
>>
>> cocoon-parent
>> cocoon-servlet-service-impl
>> cocoon-servlet-service-components
>> cocoon-configuration
>> cocoon-spring-configurator
>>
>> this afternoon.
>>
>> Please don't do any commits in the relevant parts of our repository.
>> Thanks!
>
> Is the code freeze over? I would like to start working on integration of JNet into SSF.
I released everything except the cocoon-servlet-service-components which depend
on cocoon-core. But this shouldn't be relevant for the JNet integration.
>> - o -
>>
>> The rest will follow as soon as COCOON-2179 is fixed, if time permits
>> this week otherwise in the first week of April.
>
> Done, see r639686.
>
> Can we have final release of Cocoon core this week? Reinhard, will you manage to prepare them? :-)
no, I won't have time over the Easter break. I will _probably_ continue on Tuesday.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: Code freeze
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz pisze:
>
> Ok. Then I will create the release artifacts for
>
> cocoon-parent
> cocoon-servlet-service-impl
> cocoon-servlet-service-components
> cocoon-configuration
> cocoon-spring-configurator
>
> this afternoon.
>
> Please don't do any commits in the relevant parts of our repository.
> Thanks!
Is the code freeze over? I would like to start working on integration of JNet into SSF.
> - o -
>
> The rest will follow as soon as COCOON-2179 is fixed, if time permits
> this week otherwise in the first week of April.
Done, see r639686.
Can we have final release of Cocoon core this week? Reinhard, will you manage to prepare them? :-)
--
Grzegorz Kossakowski
Code freeze is over
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> Grzegorz Kossakowski wrote:
>>> 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)
>
> Ok. Then I will create the release artifacts for
>
> cocoon-parent
> cocoon-servlet-service-impl
> cocoon-servlet-service-components
> cocoon-configuration
> cocoon-spring-configurator
>
> this afternoon.
>
> Please don't do any commits in the relevant parts of our repository.
> Thanks!
>
> - o -
>
> The rest will follow as soon as COCOON-2179 is fixed, if time permits
> this week otherwise in the first week of April.
Thanks to Grek who fixed COCOON-2179 more quickly than expected, I was able to
create all the other M2 release artifacts. This means that the code freeze is over.
Before I can call for a vote I have to create all the Non-Maven release
artifacts which will happen the next days.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Code freeze
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Grzegorz Kossakowski wrote:
>> 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)
Ok. Then I will create the release artifacts for
cocoon-parent
cocoon-servlet-service-impl
cocoon-servlet-service-components
cocoon-configuration
cocoon-spring-configurator
this afternoon.
Please don't do any commits in the relevant parts of our repository. Thanks!
- o -
The rest will follow as soon as COCOON-2179 is fixed, if time permits this week
otherwise in the first week of April.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: SourceResolver in SSF
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: SourceResolver in SSF
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: SourceResolver in SSF
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: SourceResolver in SSF
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: SourceResolver in SSF
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: SourceResolver in SSF
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: SourceResolver in SSF
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: SourceResolver in SSF
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: SourceResolver in SSF
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: SourceResolver in SSF
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: SourceResolver in SSF
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: SourceResolver in SSF
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: SourceResolver in SSF
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Re: SourceResolver in SSF
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
SourceResolver in SSF (was: Re: COCOON-2150 testing)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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?
--
Grzegorz Kossakowski
Re: COCOON-2150 testing
Posted by Carsten Ziegeler <cz...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>>
>> yes, this dependency on the Cocoon source resolver has to removed ASAP
>> because otherwise our claim that SSF is independant from Cocoon core
>> is bogus.
>>
>
> 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?
Carsten
>
> Additionally, I think we should move BlockContext source implementation
> from components to impl module of SSF.
>
> Those two should resolve this issue.
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: COCOON-2150 testing
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz pisze:
>
> yes, this dependency on the Cocoon source resolver has to removed ASAP
> because otherwise our claim that SSF is independant from Cocoon core is
> bogus.
>
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.).
Additionally, I think we should move BlockContext source implementation from components to impl
module of SSF.
Those two should resolve this issue.
--
Grzegorz Kossakowski
Re: COCOON-2150 testing
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Grzegorz Kossakowski wrote:
>>> Hello guys,
>>>
>>> I believe that COCOON-2150 is finally fixed but that was quite
>>> radical change involving lots of conditional coding craft so I cannot
>>> be entirely sure if I hadn't missed any obscure case.
>>>
>>> Therefore I would like you to give latest trunk Cocoon version
>>> extensive testing and observing if there are no errors reported by
>>> servlet container or Cocoon.
>>
>> Looks good to me! The integration tests run through, I've tested it
>> with two internal projects and also tested with Corona.
>
> You mentioned that Corona does not rely on CocoonSourceResolver but on
> JNet. How Corona could work with SSF if it has dependency on
> CocoonSourceResolver?
We haven't implemented source resolving yet but only use the SSF to manage the
Corona servlet. Before your patch we saw a lot of exceptions in the console when
we set status codes.
>> Thanks a lot, Grzegorz!
>
> No problem, I'm glad to hear it's working fine. :-)
>
>> - o -
>>
>> On my personal feature list for SSF, only SAX buffering and the
>> support for redirects are missing but this shouldn't block a 1.0 release.
>
> +1. Those issues could be implemented in 1.1.0 release.
>
> I'm still not entirely comfortable with SSF's dependency on
> CocoonSourceResolver. I have investigated further into that and I have
> already prepared a test-case presenting the problem. I'll file up an
> issue today.
>
> Anyway, I don't want to block this release. We can always cut 1.1.0 as
> soon as the dependency is removed.
yes, this dependency on the Cocoon source resolver has to removed ASAP because
otherwise our claim that SSF is independant from Cocoon core is bogus.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: COCOON-2150 testing
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz pisze:
> Grzegorz Kossakowski wrote:
>> Hello guys,
>>
>> I believe that COCOON-2150 is finally fixed but that was quite radical
>> change involving lots of conditional coding craft so I cannot be
>> entirely sure if I hadn't missed any obscure case.
>>
>> Therefore I would like you to give latest trunk Cocoon version
>> extensive testing and observing if there are no errors reported by
>> servlet container or Cocoon.
>
> Looks good to me! The integration tests run through, I've tested it with
> two internal projects and also tested with Corona.
You mentioned that Corona does not rely on CocoonSourceResolver but on JNet. How Corona could work
with SSF if it has dependency on CocoonSourceResolver?
> Thanks a lot, Grzegorz!
No problem, I'm glad to hear it's working fine. :-)
> - o -
>
> On my personal feature list for SSF, only SAX buffering and the support
> for redirects are missing but this shouldn't block a 1.0 release.
+1. Those issues could be implemented in 1.1.0 release.
I'm still not entirely comfortable with SSF's dependency on CocoonSourceResolver. I have
investigated further into that and I have already prepared a test-case presenting the problem. I'll
file up an issue today.
Anyway, I don't want to block this release. We can always cut 1.1.0 as soon as the dependency is
removed.
> I believe that SSF is ready to be released. If nobody objects, I will
> create the release artifacts tommorrow, together with cocoon-parent and
> cocoon-configuration.
+1 and thanks again.
--
Grzegorz Kossakowski
Re: COCOON-2150 testing
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Hello guys,
>
> I believe that COCOON-2150 is finally fixed but that was quite radical
> change involving lots of conditional coding craft so I cannot be
> entirely sure if I hadn't missed any obscure case.
>
> Therefore I would like you to give latest trunk Cocoon version extensive
> testing and observing if there are no errors reported by servlet
> container or Cocoon.
Looks good to me! The integration tests run through, I've tested it with two
internal projects and also tested with Corona.
Thanks a lot, Grzegorz!
- o -
On my personal feature list for SSF, only SAX buffering and the support for
redirects are missing but this shouldn't block a 1.0 release.
I believe that SSF is ready to be released. If nobody objects, I will create the
release artifacts tommorrow, together with cocoon-parent and cocoon-configuration.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________