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 2007/09/18 10:10:09 UTC
Code freeze?
Hi,
I forgot that Reinhard asked us for code freeze from 18 to 21 of September and checked few things in.
Reinhard, could you confirm that you are going to make a release so we will know that committs are
rather not allowed these days?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Javadocs
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> But now I run into another problem: When I use the find/xargs command,
>> the working directory is the directory where I entered this command
>> and not the directory where the create-apidocs.sh script is located.
>> Is there a way to set the working directory the way I have expected it?
>
> Yep. Put this script say in your home dir, name it 'x.sh' and make it
> executable:
>
> #!/bin/sh
> cd `dirname $1`
> # Both "sh $1" and ". $1" should work
> . $1
>
> From your home dir (where x.sh is):
>
> find /x1/www/cocoon.apache.org/2.2 -name "create-apidocs.sh" | grep
> apidocs/ | xargs -n 1 ./x.sh
>
thanks, works like a charm!
> Alternatively you can put cd `dirname $1` in each of create-apidocs.sh
> but I figured you'd want to avoid this :)
:-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Javadocs
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> But now I run into another problem: When I use the find/xargs command,
> the working directory is the directory where I entered this command and
> not the directory where the create-apidocs.sh script is located. Is
> there a way to set the working directory the way I have expected it?
Yep. Put this script say in your home dir, name it 'x.sh' and make it executable:
#!/bin/sh
cd `dirname $1`
# Both "sh $1" and ". $1" should work
. $1
From your home dir (where x.sh is):
find /x1/www/cocoon.apache.org/2.2 -name "create-apidocs.sh" | grep apidocs/
| xargs -n 1 ./x.sh
Alternatively you can put cd `dirname $1` in each of create-apidocs.sh but I
figured you'd want to avoid this :)
Vadim
Re: Javadocs
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> thanks. The command seems to work but I have a problem to execute the
>> script because David is the owner and neither chown nor chmod are
>> permitted using my account:
>>
>> /x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs
>> > ls -lsa
>> total 14
>> 2 drwxrwxr-x 3 crossley cocoon 512 Sep 26 17:08 .
>> 2 drwxrwxr-x 6 crossley cocoon 512 Sep 26 17:08 ..
>> 2 drwxrwxr-x 6 crossley cocoon 512 Sep 27 14:33 .svn
>> 2 -rw-rw-r-- 1 crossley cocoon 581 Sep 26 17:08 create-apidocs.sh
>
> You don't need chmod/chown; permissions are looking fine as it is. But
> when I try to run it, I get an error:
>
> vgritsenko@minotaur
> /x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs $
> bash create-apidocs.sh
> ----------------------------------------------------------------
> Creating JavaDocs for cocoon-pipeline-api:1.0.0-RC2
> create-apidocs.sh: line 9: syntax error near unexpected token `else'
> create-apidocs.sh: line 9: `else'
>
>
> When I fixed both if/then/else:
>
> if [ ! -f $f ]
> then
> wget --header "User-Agent: Mozilla/5.0 Firefox/2.0.0.7"
> http://repo1.maven.org/maven2/$jd
> dl=1
> fi
This seems to be subtle difference between shell script interpreters:
find . -name "create-apidocs.sh" | grep apidocs | xargs sh
works fine without having to change the if/then/else syntax.
But now I run into another problem: When I use the find/xargs command, the
working directory is the directory where I entered this command and not the
directory where the create-apidocs.sh script is located. Is there a way to set
the working directory the way I have expected it?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Javadocs
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> thanks. The command seems to work but I have a problem to execute the
> script because David is the owner and neither chown nor chmod are
> permitted using my account:
>
> /x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs
> > ls -lsa
> total 14
> 2 drwxrwxr-x 3 crossley cocoon 512 Sep 26 17:08 .
> 2 drwxrwxr-x 6 crossley cocoon 512 Sep 26 17:08 ..
> 2 drwxrwxr-x 6 crossley cocoon 512 Sep 27 14:33 .svn
> 2 -rw-rw-r-- 1 crossley cocoon 581 Sep 26 17:08 create-apidocs.sh
You don't need chmod/chown; permissions are looking fine as it is. But when I
try to run it, I get an error:
vgritsenko@minotaur
/x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs $ bash
create-apidocs.sh
----------------------------------------------------------------
Creating JavaDocs for cocoon-pipeline-api:1.0.0-RC2
create-apidocs.sh: line 9: syntax error near unexpected token `else'
create-apidocs.sh: line 9: `else'
When I fixed both if/then/else:
if [ ! -f $f ]
then
wget --header "User-Agent: Mozilla/5.0 Firefox/2.0.0.7"
http://repo1.maven.org/maven2/$jd
dl=1
fi
It was working fine:
vgritsenko@minotaur
/x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs $ bash
create-apidocs.sh
----------------------------------------------------------------
Creating JavaDocs for cocoon-pipeline-api:1.0.0-RC2
--15:33:08--
http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-pipeline-api/1.0.0-RC2/cocoon-pipeline-api-1.0.0-RC2-javadoc.jar
=> `cocoon-pipeline-api-1.0.0-RC2-javadoc.jar'
Resolving repo1.maven.org... 63.246.20.112
Connecting to repo1.maven.org|63.246.20.112|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
15:33:08 ERROR 404: Not Found.
--15:33:08--
http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-pipeline-api/1.0.0-RC2/cocoon-pipeline-api-1.0.0-RC2-javadoc.jar
=> `cocoon-pipeline-api-1.0.0-RC2-javadoc.jar'
Resolving people.apache.org... 140.211.11.9
Connecting to people.apache.org|140.211.11.9|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 362,072 (354K) [application/java-archive]
100%[=======================================================================================================================================>]
362,072 --.--K/s
15:33:08 (41.75 MB/s) - `cocoon-pipeline-api-1.0.0-RC2-javadoc.jar' saved
[362072/362072]
vgritsenko@minotaur
/x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs $ ls
META-INF/ help-doc.html
overview-tree.html
allclasses-frame.html index-all.html
package-list
allclasses-noframe.html index.html
packages
cocoon-pipeline-api-1.0.0-RC2-javadoc.jar options
packages.html
constant-values.html org/
resources/
create-apidocs.sh overview-frame.html
serialized-form.html
deprecated-list.html overview-summary.html
stylesheet.css
Vadim
Re: Javadocs
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> Vadim Gritsenko wrote:
>>> Reinhard Poetz wrote:
>>>> Could somebody help me with an additional script which recursivly
>>>> scans for the download scripts, sets the "x" attribute on the file
>>>> and executes it then?
>>>
>>> Sure; what's the script name / name pattern?
>>
>> It will be located in apidocs/create-apidocs.sh
>
> This will do it:
>
> find . -name "create-apidocs.sh" | grep apidocs | xargs bash
thanks. The command seems to work but I have a problem to execute the script
because David is the owner and neither chown nor chmod are permitted using my
account:
/x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs
> ls -lsa
total 14
2 drwxrwxr-x 3 crossley cocoon 512 Sep 26 17:08 .
2 drwxrwxr-x 6 crossley cocoon 512 Sep 26 17:08 ..
2 drwxrwxr-x 6 crossley cocoon 512 Sep 27 14:33 .svn
2 -rw-rw-r-- 1 crossley cocoon 581 Sep 26 17:08 create-apidocs.sh
6 -rw-rw-r-- 1 crossley cocoon 5385 Sep 26 17:08 index.html
(When I copy the script into my home directory, it works fine.)
Can anybody help?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Javadocs
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vadim Gritsenko wrote:
> Giacomo Pati wrote:
>> Vadim Gritsenko wrote:
>>> Reinhard Poetz wrote:
>>>> It will be located in apidocs/create-apidocs.sh
>>> This will do it:
>>>
>>> find . -name "create-apidocs.sh" | grep apidocs | xargs bash
>>
>> Well, the grep wouldn't do anything helpfull, right ;-)
>
> Just to enforce a contract :)
Oh, that's a good answer ;-)
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG962NLNdJvZjjVZARAr5wAJ4qIj3cCXDE3EE4GzRj/p2aqOoIGwCfW8LS
LejiXOsVp1r7S4EVfr+z2oY=
=iSys
-----END PGP SIGNATURE-----
Re: Javadocs
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Giacomo Pati wrote:
> Vadim Gritsenko wrote:
>> Reinhard Poetz wrote:
>>> It will be located in apidocs/create-apidocs.sh
>> This will do it:
>>
>> find . -name "create-apidocs.sh" | grep apidocs | xargs bash
>
> Well, the grep wouldn't do anything helpfull, right ;-)
Just to enforce a contract :)
Vadim
Re: Javadocs
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> Vadim Gritsenko wrote:
>>> Reinhard Poetz wrote:
>>>> Could somebody help me with an additional script which recursivly
>>>> scans for the download scripts, sets the "x" attribute on the file
>>>> and executes it then?
>>>
>>> Sure; what's the script name / name pattern?
>>
>> It will be located in apidocs/create-apidocs.sh
>
> This will do it:
>
> find . -name "create-apidocs.sh" | grep apidocs | xargs bash
Well, the grep wouldn't do anything helpfull, right ;-)
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG927aLNdJvZjjVZARAg00AKDCHpD11kXEFyaka1qdjcDR/5O9XgCfUprn
6+nVq0q8xB0vvj68OeQey0U=
=APMB
-----END PGP SIGNATURE-----
Re: Javadocs
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>> Reinhard Poetz wrote:
>>> Could somebody help me with an additional script which recursivly
>>> scans for the download scripts, sets the "x" attribute on the file
>>> and executes it then?
>>
>> Sure; what's the script name / name pattern?
>
> It will be located in apidocs/create-apidocs.sh
This will do it:
find . -name "create-apidocs.sh" | grep apidocs | xargs bash
Vadim
Re: Javadocs
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> Could somebody help me with an additional script which recursivly
>> scans for the download scripts, sets the "x" attribute on the file and
>> executes it then?
>
> Sure; what's the script name / name pattern?
It will be located in apidocs/create-apidocs.sh
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Javadocs
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Could somebody help me with an additional script which recursivly scans
> for the download scripts, sets the "x" attribute on the file and
> executes it then?
Sure; what's the script name / name pattern?
Vadim
Re: Javadocs
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> I also use this release to publish our docs. I wonder now whether I
>> should add the Javadocs to our docs or not. For the
>> spring-configurator and and configuration-api I've added them because
>> they are subprojects but I'm not sure if it is the best idea to add
>> the javadocs of our core modules and the blocks to SVN either. The
>> problem is that they take up a lot of space and make a checkout of our
>> site really slow.
>
> Add javadocs to the website - yes, into svn - no.
>
>
>> OTOH if we don't generate them using Maven and then add them to our
>> SVN I don't know how we can do it in a comfortable way.
>
> Traditionally, one would unzip javadocs from a copy of a release on a
> website into 'apidocs' directory, and that'd be all. In such a setup,
> even if javadocs are not in svn, they can be easily restored by getting
> release off archive.apache.org and unzipping it.
>
> http://svn.apache.org/repos/asf/cocoon/site/site/2.1/apidocs/README.txt
The problem is that there are 40+ release artifacts now and doing it this way is
very inconvenient.Maybe I should to write a Maven report which creates only the
menu entry and an apidocs directory. I could put a script into this directory
which downloads the zipped javadocs archive from the central Maven repository
and unzip it then.
Could somebody help me with an additional script which recursivly scans for the
download scripts, sets the "x" attribute on the file and executes it then?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Javadocs
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> I also use this release to publish our docs. I wonder now whether I
> should add the Javadocs to our docs or not. For the spring-configurator
> and and configuration-api I've added them because they are subprojects
> but I'm not sure if it is the best idea to add the javadocs of our core
> modules and the blocks to SVN either. The problem is that they take up a
> lot of space and make a checkout of our site really slow.
Add javadocs to the website - yes, into svn - no.
> OTOH if we don't generate them using Maven and then add them to our SVN
> I don't know how we can do it in a comfortable way.
Traditionally, one would unzip javadocs from a copy of a release on a website
into 'apidocs' directory, and that'd be all. In such a setup, even if javadocs
are not in svn, they can be easily restored by getting release off
archive.apache.org and unzipping it.
http://svn.apache.org/repos/asf/cocoon/site/site/2.1/apidocs/README.txt
Vadim
Javadocs
Posted by Reinhard Poetz <re...@apache.org>.
I also use this release to publish our docs. I wonder now whether I should add
the Javadocs to our docs or not. For the spring-configurator and and
configuration-api I've added them because they are subprojects but I'm not sure
if it is the best idea to add the javadocs of our core modules and the blocks to
SVN either. The problem is that they take up a lot of space and make a checkout
of our site really slow.
OTOH if we don't generate them using Maven and then add them to our SVN I don't
know how we can do it in a confortable way.
Any ideas or opinions?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze - over
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Grzegorz Kossakowski wrote:
>>> Reinhard Poetz pisze:
>>>
>>> Thanks Reinhard for taking care!
>>>
>>> It's nice that we will be able to start creating buzz about Cocoon 2.2
>>> shortly! :-)
>> ;-)
>>
>> btw, I've forgotten to mention that I'm waiting for the solution(s) that
>> fix(es) Giacomo's bug and the cocoon:/ problem. Then I will recreate the
>> affected core modules and then call for the vote.
>
> Oups, I forgot about it too.
>
> I'll give this a thorough look this weekend so there is a humble ask: if you,
> Giacomo, Reinhard and others could monitor our mailing list during this
> weekend more often than usually I would be grateful. It's very likely I will
> be having additional questions.
I'm sorry, but I will be offline over the weekend. Maybe I have a chance to
check the mails on Sunday afternoon but can't promise.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze - over
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz pisze:
>>
>> Thanks Reinhard for taking care!
>>
>> It's nice that we will be able to start creating buzz about Cocoon 2.2
>> shortly! :-)
>
> ;-)
>
> btw, I've forgotten to mention that I'm waiting for the solution(s)
> that fix(es) Giacomo's bug and the cocoon:/ problem. Then I will
> recreate the affected core modules and then call for the vote.
Oups, I forgot about it too.
I'll give this a thorough look this weekend so there is a humble ask: if you, Giacomo, Reinhard and
others could monitor our mailing list during this weekend more often than usually I would be
grateful. It's very likely I will be having additional questions.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Code freeze - over
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> All release artifacts and their docs have been created. This means that
>> the code freeze is over and our SVN is happily awaiting your commits again!
>>
>> Currently trunk doesn't build because the parent pom references are not
>> set correctly. I will take care for this tommorrow morning if nobody
>> else is doing it in the meantime:
>>
>> You would just have to use tools/pom-updater/pu.sh and set
>>
>> org.apache.cocoon:cocoon
>> org.apache.cocoon:cocoon-blocks-modules
>> org.apache.cocoon:cocoon-core-modules
>> org.apache.cocoon:cocoon-tools-modules
>>
>> to 6-SNAPSHOT.
>
> Thanks Reinhard for taking care!
>
> It's nice that we will be able to start creating buzz about Cocoon 2.2 shortly! :-)
;-)
btw, I've forgotten to mention that I'm waiting for the solution(s) that
fix(es) Giacomo's bug and the cocoon:/ problem. Then I will recreate the
affected core modules and then call for the vote.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze - over
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
>
> All release artifacts and their docs have been created. This means that
> the code freeze is over and our SVN is happily awaiting your commits again!
>
> Currently trunk doesn't build because the parent pom references are not
> set correctly. I will take care for this tommorrow morning if nobody
> else is doing it in the meantime:
>
> You would just have to use tools/pom-updater/pu.sh and set
>
> org.apache.cocoon:cocoon
> org.apache.cocoon:cocoon-blocks-modules
> org.apache.cocoon:cocoon-core-modules
> org.apache.cocoon:cocoon-tools-modules
>
> to 6-SNAPSHOT.
Thanks Reinhard for taking care!
It's nice that we will be able to start creating buzz about Cocoon 2.2 shortly! :-)
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Code freeze - over
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Reinhard Poetz wrote:
>>
>> All release artifacts and their docs have been created. This means
>> that the code freeze is over and our SVN is happily awaiting your
>> commits again!
>>
>> Currently trunk doesn't build because the parent pom references are
>> not set correctly. I will take care for this tommorrow morning if
>> nobody else is doing it in the meantime:
>>
>> You would just have to use tools/pom-updater/pu.sh and set
>>
>> org.apache.cocoon:cocoon
>> org.apache.cocoon:cocoon-blocks-modules
>> org.apache.cocoon:cocoon-core-modules
>> org.apache.cocoon:cocoon-tools-modules
>>
>> to 6-SNAPSHOT.
>>
>
> I have some unexpected free time this evening and I'm going to run the
> pom-updater now.
the build runs through again for me. If you find any problems pls let us know
via this list - filing a Jira issue shouldn't be necessary.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze - over
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
>
> All release artifacts and their docs have been created. This means that
> the code freeze is over and our SVN is happily awaiting your commits again!
>
> Currently trunk doesn't build because the parent pom references are not
> set correctly. I will take care for this tommorrow morning if nobody
> else is doing it in the meantime:
>
> You would just have to use tools/pom-updater/pu.sh and set
>
> org.apache.cocoon:cocoon
> org.apache.cocoon:cocoon-blocks-modules
> org.apache.cocoon:cocoon-core-modules
> org.apache.cocoon:cocoon-tools-modules
>
> to 6-SNAPSHOT.
>
I have some unexpected free time this evening and I'm going to run the
pom-updater now.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Code freeze - over
Posted by Reinhard Poetz <re...@apache.org>.
All release artifacts and their docs have been created. This means that the code
freeze is over and our SVN is happily awaiting your commits again!
Currently trunk doesn't build because the parent pom references are not set
correctly. I will take care for this tommorrow morning if nobody else is doing
it in the meantime:
You would just have to use tools/pom-updater/pu.sh and set
org.apache.cocoon:cocoon
org.apache.cocoon:cocoon-blocks-modules
org.apache.cocoon:cocoon-core-modules
org.apache.cocoon:cocoon-tools-modules
to 6-SNAPSHOT.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze - NOW
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Reinhard Poetz wrote:
>> Reinhard Poetz wrote:
>>> As you probably have noticed, I've started with the release of the
>>> POM modules. So far this shouldn't have affected you except a short
>>> period when trunk didn't build.
>>>
>>> I'm going to continue with the jar modules in core and blocks which
>>> means that I ask you not to commit to any of the affected directories
>>> in SVN (see the list of the proposed artifacts).
>>>
>>> I will let you know as soon as I'm finished.
>>
>> Though I've only created the release artifacts for the Configurator
>> subproject, I have to suspend the code freeze until I have a working
>> solution for the problem with the Javadocs (see the seperate mail
>> thread about this issue).
I solved this problem by creating a special Maven report that generates a script
which downloads the javadoc archives from a Maven repository and removed the
normal JavaDocs report.
I will continue with creating release artifacts on Monday. So if you want to
commit something, go for it but please be careful not to break any of the
artifacts to be released ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze - NOW
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Reinhard Poetz wrote:
>> As you probably have noticed, I've started with the release of the POM
>> modules. So far this shouldn't have affected you except a short period
>> when trunk didn't build.
>>
>> I'm going to continue with the jar modules in core and blocks which
>> means that I ask you not to commit to any of the affected directories
>> in SVN (see the list of the proposed artifacts).
>>
>> I will let you know as soon as I'm finished.
>
> Though I've only created the release artifacts for the Configurator
> subproject, I have to suspend the code freeze until I have a working
> solution for the problem with the Javadocs (see the seperate mail thread
> about this issue).
If you wonder why the release and the doc generation are reletated at all: it's
because that's the simplest way to create docs that contain correct version
numbers. Otherwise all the Maven docs (e.g. the list of dependencies) refer to
SNAPSHOT releases which is confusing IMO.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze - NOW
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> As you probably have noticed, I've started with the release of the POM
> modules. So far this shouldn't have affected you except a short period
> when trunk didn't build.
>
> I'm going to continue with the jar modules in core and blocks which
> means that I ask you not to commit to any of the affected directories in
> SVN (see the list of the proposed artifacts).
>
> I will let you know as soon as I'm finished.
Though I've only created the release artifacts for the Configurator subproject,
I have to suspend the code freeze until I have a working solution for the
problem with the Javadocs (see the seperate mail thread about this issue).
Nevertheless I want to ask you not to do any commits which have a deeper impact
on our codebase. Thanks!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Code freeze - NOW
Posted by Reinhard Poetz <re...@apache.org>.
As you probably have noticed, I've started with the release of the POM modules.
So far this shouldn't have affected you except a short period when trunk didn't
build.
I'm going to continue with the jar modules in core and blocks which means that I
ask you not to commit to any of the affected directories in SVN (see the list of
the proposed artifacts).
I will let you know as soon as I'm finished.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
>
> Can anybody confirm this or is it a problem with my environment
> (although I deleted my local repo, then entered svn up, mvn clean install)?
I just rebuilt Cocoon and expierienced no of errors you mentioned. I'm going to delete my Maven repo
and see if this changes...
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Code freeze?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 18.09.2007 14:43 Uhr, Grzegorz Kossakowski wrote:
>> No failures in the biggest report! And next biggest, and so on...
>
> Text instead of XML reports should be working. Nevertheless, you have found more reliable way.
I think the problem is that many tests work with expected exceptions and
log them. That's why the size is not working.
Joerg
Re: Code freeze?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Vadim Gritsenko pisze:
> Grzegorz Kossakowski wrote:
>> Vadim Gritsenko pisze:
>>> Fails here on mac os:
>>>
>>> Results :
>>> Tests run: 98, Failures: 1, Errors: 0, Skipped: 0
>>>
>>> Is there an easy way to find out which test fails?
>>
>> That's good question, I wondered about it too.
>> Meanwhile I suggest to just go to cocoon-core/target/surefire and sort
>> files by their size. The file
>> containing report about failing test is the biggest one.
>
> Well this method does not work :)
> TEST-org.apache.cocoon.matching.CookieMatcherTestCase.xml:
> <testsuite errors="0" skipped="0" tests="2" time="0.033" failures="0"
> name="org.apache.cocoon.matching.CookieMatcherTestCase">
>
> No failures in the biggest report! And next biggest, and so on...
Text instead of XML reports should be working. Nevertheless, you have found more reliable way.
> Anyway
> here is *really* ugly way to find it:
>
> $ find . -name "TEST-*.xml" | xargs grep failures=.1.
> ./core/cocoon-core/target/surefire-reports/TEST-org.apache.cocoon.components.source.impl.CachingSourceTestCase.xml:<testsuite
> errors="0" skipped="0" tests="6" time="11.521" failures="1"
> name="org.apache.cocoon.components.source.impl.CachingSourceTestCase">
>
>
> And here is error:
>
> <failure type="junit.framework.AssertionFailedError"
> message="expected
> same:&lt;org.apache.cocoon.components.source.impl.CachingSource$SourceMeta@c07f58&gt;
> was
> not:&lt;org.apache.cocoon.components.source.impl.CachingSource$SourceMeta@e89f1b&gt;">junit.framework.AssertionFailedError:
> expected
> same:&org.apache.cocoon.components.source.impl.CachingSource$SourceMeta@c07f58&
> was
> not:&org.apache.cocoon.components.source.impl.CachingSource$SourceMeta@e89f1b&
>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotSame(Assert.java:276)
> at junit.framework.Assert.assertSame(Assert.java:239)
> at junit.framework.Assert.assertSame(Assert.java:246)
> at
> org.apache.cocoon.components.source.impl.CachingSourceTestCase.testCachingURI(CachingSourceTestCase.java:86)
>
> </failure>
Is your internet connection reliable? CachingSourceTestCase has been failing for number of people
just because it depends on content obtained from slashdot site. I never liked this approach and
expressed my concerns about it some time ago (cannot give pointer, though). I think we should change
this test to avoid fake failings.
> PS Ant had this nifty task generating junit html reports...
I guess that Maven has something similar but we didn't configure it...
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Code freeze?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Grzegorz Kossakowski wrote:
> Vadim Gritsenko pisze:
>> Fails here on mac os:
>>
>> Results :
>> Tests run: 98, Failures: 1, Errors: 0, Skipped: 0
>>
>> Is there an easy way to find out which test fails?
>
> That's good question, I wondered about it too.
> Meanwhile I suggest to just go to cocoon-core/target/surefire and sort files by their size. The file
> containing report about failing test is the biggest one.
Well this method does not work :)
TEST-org.apache.cocoon.matching.CookieMatcherTestCase.xml:
<testsuite errors="0" skipped="0" tests="2" time="0.033" failures="0"
name="org.apache.cocoon.matching.CookieMatcherTestCase">
No failures in the biggest report! And next biggest, and so on... Anyway here is
*really* ugly way to find it:
$ find . -name "TEST-*.xml" | xargs grep failures=.1.
./core/cocoon-core/target/surefire-reports/TEST-org.apache.cocoon.components.source.impl.CachingSourceTestCase.xml:<testsuite
errors="0" skipped="0" tests="6" time="11.521" failures="1"
name="org.apache.cocoon.components.source.impl.CachingSourceTestCase">
And here is error:
<failure type="junit.framework.AssertionFailedError" message="expected
same:&lt;org.apache.cocoon.components.source.impl.CachingSource$SourceMeta@c07f58&gt;
was
not:&lt;org.apache.cocoon.components.source.impl.CachingSource$SourceMeta@e89f1b&gt;">junit.framework.AssertionFailedError:
expected
same:&org.apache.cocoon.components.source.impl.CachingSource$SourceMeta@c07f58&
was
not:&org.apache.cocoon.components.source.impl.CachingSource$SourceMeta@e89f1b&
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotSame(Assert.java:276)
at junit.framework.Assert.assertSame(Assert.java:239)
at junit.framework.Assert.assertSame(Assert.java:246)
at
org.apache.cocoon.components.source.impl.CachingSourceTestCase.testCachingURI(CachingSourceTestCase.java:86)
</failure>
PS Ant had this nifty task generating junit html reports...
Vadim
Re: Code freeze?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Vadim Gritsenko pisze:
>
> Fails here on mac os:
>
> Results :
> Tests run: 98, Failures: 1, Errors: 0, Skipped: 0
>
> Is there an easy way to find out which test fails?
That's good question, I wondered about it too.
Meanwhile I suggest to just go to cocoon-core/target/surefire and sort files by their size. The file
containing report about failing test is the biggest one.
If someone knows less "clever" method let us know ;-)
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Code freeze?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Grzegorz Kossakowski wrote:
> Felix Knecht pisze:
>>>>>> Can anybody confirm this or is it a problem with my environment
>>>>>> (although I deleted my local repo, then entered svn up, mvn clean
>>>>>> install)?
>> Works for me under linux, using sun-jdk-1.6 and sun-jdk-1.5
>
> Same here so it's again OS-specific issue. I wonder why nobody found this problem earlier. AFAIR we
> have not changed our dependencies that could cause this problem for at least few weeks.
Fails here on mac os:
Results :
Tests run: 98, Failures: 1, Errors: 0, Skipped: 0
Is there an easy way to find out which test fails?
Vadim
Re: Code freeze?
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Felix Knecht pisze:
>>>>>> Can anybody confirm this or is it a problem with my environment
>>>>>> (although I deleted my local repo, then entered svn up, mvn clean
>>>>>> install)?
>> Works for me under linux, using sun-jdk-1.6 and sun-jdk-1.5
>
> Same here so it's again OS-specific issue. I wonder why nobody found this problem earlier. AFAIR we
> have not changed our dependencies that could cause this problem for at least few weeks.
>
> Is it really something new for you or you report it just now?
It's new for me but I have to admit that I haven't used trunk for a while (~4 to
5 weeks I guess).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht pisze:
>>>>> Can anybody confirm this or is it a problem with my environment
>>>>> (although I deleted my local repo, then entered svn up, mvn clean
>>>>> install)?
> Works for me under linux, using sun-jdk-1.6 and sun-jdk-1.5
Same here so it's again OS-specific issue. I wonder why nobody found this problem earlier. AFAIR we
have not changed our dependencies that could cause this problem for at least few weeks.
Is it really something new for you or you report it just now?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Code freeze?
Posted by Felix Knecht <fe...@apache.org>.
>>>> Can anybody confirm this or is it a problem with my environment
>>>> (although I deleted my local repo, then entered svn up, mvn clean
>>>> install)?
Works for me under linux, using sun-jdk-1.6 and sun-jdk-1.5
Felix
Re: Code freeze?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz pisze:
>>> Can anybody confirm this or is it a problem with my environment
>>> (although I deleted my local repo, then entered svn up, mvn clean
>>> install)?
>>
>> Reinhard, I tried to build Cocoon with empty Maven local repo and
>> results are the same: everything
>> works just fine. Are you sure there is no old junk somewhere?
>
> I don't think so. I removed all Cocoon artifacts from my local repo
> and did a fresh 'svn co' of trunk. (WinXP, Java 1.5.0_11)
>
> For me the ZipSourceTestCase is failing (again):
>
> -------------------------------------------------------------------------------
>
> Test set: org.apache.cocoon.components.source.impl.ZipSourceTestCase
> -------------------------------------------------------------------------------
>
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.03
> sec <<< FAILURE!
> testURIHandling(org.apache.cocoon.components.source.impl.ZipSourceTestCase)
> Time elapsed: 0.01 sec <<< FAILURE!
> junit.framework.ComparisonFailure: Uri is wrong.
> expected:<zip:file://[/]test.zip!/test.xml> but
> was:<zip:file://[]test.zip!/test.xml>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at
> org.apache.cocoon.components.source.impl.ZipSourceTestCase.testURIHandling(ZipSourceTestCase.java:45)
>
>
I have the same problem.
/Danie
Finishing the 2.2-RC2 release (was Re: pipelineComponent scope troubles)
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Leszek Gawron pisze:
>>> Caused by: org.apache.cocoon.CascadingIOException: If you see this
>>> exception you probably called
>>> Source.getInputStream even though the source reported proper validity.
>>> The only way to solve this
>>> is to implement a resource heavy version of postable source.:
>>> javax.servlet.ServletException: If
>>> you see this exception you probably called Source.getInputStream even
>>> though the source reported
>>> proper validity. The only way to solve this is to implement a resource
>>> heavy version of postable
>>> source.
>> this probably means we will not be able to implement fully pipelined
>> servlet services.. I have reverted the change we did at GT.
>
> Very unfortunate news but I don't think situation is hopeless.
>
> Anyway, my opinion is that we should just start with buffer and after servlet-service stabilizes. We
> could continue improving servlet protocol performance. Otherwise, if we are going to complicate it
> now it's going to be hard to figure out what's the possible problem with servlet protocol.
>
> Giacomo, does everything work for you after Leszek reverted his changes?
Grek, in the case that Giacomo's answer is yes, could you please branch the
affacted modules from /tags/cocoon-2.2/???/[version] to
/branches/cocoon-2.2/???/[version] and apply your patch(es) their too? Then I
could recreate the release artifacts and we can start to test them.
--
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: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> Giacomo Pati wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Grzegorz Kossakowski wrote:
>>> Giacomo, Felix: Could you confirm that everything works for you if
>>> you stick to 1.0.0 version of
>>> template so we can release Cocoon 2.2 RC2?
>>
>> Actually we don't have the problem as the situation when mentioned NPE
>> happens is not used by our
>> app and thus we run fine with HEAD.
>
> I am a little bit confused. Is there still a problem? If so does if
> affect 1.0.0 branch or trunk version of cocoon-template?
Well, currently we run from trunk and it seem to work so far.
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHIfC8LNdJvZjjVZARAskaAKCqX7U0MSAdrce3N0oJCJUKK4qHOgCg0dl3
WZghfYenztocotVza5+1Cus=
=xg8H
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Grzegorz Kossakowski wrote:
>> Giacomo, Felix: Could you confirm that everything works for you if you stick to 1.0.0 version of
>> template so we can release Cocoon 2.2 RC2?
>
> Actually we don't have the problem as the situation when mentioned NPE happens is not used by our
> app and thus we run fine with HEAD.
I am a little bit confused. Is there still a problem? If so does if
affect 1.0.0 branch or trunk version of cocoon-template?
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
>
> Giacomo, Felix: Could you confirm that everything works for you if you stick to 1.0.0 version of
> template so we can release Cocoon 2.2 RC2?
Actually we don't have the problem as the situation when mentioned NPE happens is not used by our
app and thus we run fine with HEAD.
Ciao and thanks
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHDIuZLNdJvZjjVZARAgSFAKDdkDavg9CsAA2cV29Gm1W7tqBznQCgmi5f
e/0UX0QiGZKKlQLkcg3sed8=
=Bk1x
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht pisze:
>
> It seems that the JXGenerator stopped working.
>
> Changing the generation part in the sitemap [1] from
>
> <snip>
>
> <map:match pattern="*-display-pipeline.jx">
> <map:generate type="jx" src="forms/{1}_template.xml" label="content1">
> <map:parameter name="locale" value="{flow-attribute:locale}" />
> </map:generate>
>
> </snip>
>
> to
>
> <map:match pattern="*-display-pipeline.jx">
> <map:generate src="forms/{1}_template.xml" label="content1">
> <map:parameter name="locale" value="{flow-attribute:locale}" />
> </map:generate>
> <map:transform type="jx" />
>
> made sample working again.
>
> It looks like the properties from the bean definition
> (saxParser,scriptManager, ObjectModel) are not set when the
> JXTemplateGenerator.setup(...) is called and therefor
>
> this.startDocument = scriptManager.resolveTemplate(src);
>
> throws Exception below because scriptManager = null.
>
>
>
> Caused by: java.lang.NullPointerException
> at
> org.apache.cocoon.template.JXTemplateGenerator.setup(JXTemplateGenerator.java:117)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
> at $Proxy9.setup(Unknown Source)
> at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:341)
Yep, I dug into this problem too and shared my thoughts in a new thread:
http://article.gmane.org/gmane.text.xml.cocoon.devel/75588
As for now I think you can safely stick to 1.0.0 version of template block and update your application.
Giacomo, Felix: Could you confirm that everything works for you if you stick to 1.0.0 version of
template so we can release Cocoon 2.2 RC2?
(actually, this situation proves that branching is quite good idea and Springification is not always
such a straightforward process as we thought)
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Felix Knecht <fe...@otego.com>.
>
> Even Felix can now run our app without the known hassles and exceptions. But we don't know whether
> to migrate as now some of the CForm samples throw exceptions they didn't after my springification.
>
> Any ideas what caused the samples to stop working?
>
It seems that the JXGenerator stopped working.
Changing the generation part in the sitemap [1] from
<snip>
<map:match pattern="*-display-pipeline.jx">
<map:generate type="jx" src="forms/{1}_template.xml" label="content1">
<map:parameter name="locale" value="{flow-attribute:locale}" />
</map:generate>
</snip>
to
<map:match pattern="*-display-pipeline.jx">
<map:generate src="forms/{1}_template.xml" label="content1">
<map:parameter name="locale" value="{flow-attribute:locale}" />
</map:generate>
<map:transform type="jx" />
made sample working again.
It looks like the properties from the bean definition
(saxParser,scriptManager, ObjectModel) are not set when the
JXTemplateGenerator.setup(...) is called and therefor
this.startDocument = scriptManager.resolveTemplate(src);
throws Exception below because scriptManager = null.
Caused by: java.lang.NullPointerException
at
org.apache.cocoon.template.JXTemplateGenerator.setup(JXTemplateGenerator.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy9.setup(Unknown Source)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:341)
Felix
[1]
blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/sitemap.xmap
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Giacomo Pati wrote:
>
>
> Grzegorz Kossakowski wrote:
>> Leszek Gawron pisze:
>>>> Caused by: org.apache.cocoon.CascadingIOException: If you see this
>>>> exception you probably called
>>>> Source.getInputStream even though the source reported proper validity.
>>>> The only way to solve this
>>>> is to implement a resource heavy version of postable source.:
>>>> javax.servlet.ServletException: If
>>>> you see this exception you probably called Source.getInputStream even
>>>> though the source reported
>>>> proper validity. The only way to solve this is to implement a resource
>>>> heavy version of postable
>>>> source.
>>> this probably means we will not be able to implement fully pipelined
>>> servlet services.. I have reverted the change we did at GT.
>> Very unfortunate news but I don't think situation is hopeless.
>
>> Anyway, my opinion is that we should just start with buffer and after servlet-service stabilizes. We
>> could continue improving servlet protocol performance. Otherwise, if we are going to complicate it
>> now it's going to be hard to figure out what's the possible problem with servlet protocol.
>
>> Giacomo, does everything work for you after Leszek reverted his changes?
>
> I'm still testing after Leszek reverted his changes and suprisingly our app seems to work now
> (whatever change or revert made it happen) ?!?!?!
>
> I'll give more info as soon as I've finished testing our app with latest Cocoon
Even Felix can now run our app without the known hassles and exceptions. But we don't know whether
to migrate as now some of the CForm samples throw exceptions they didn't after my springification.
Any ideas what caused the samples to stop working?
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHCyp2LNdJvZjjVZARAiidAJ4ojXh750dL6ohL2rjeymCt/qqptwCg1r7m
M+MEQ92qHv4dFsDiZcxY9dk=
=3AJl
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Leszek Gawron pisze:
>>> Caused by: org.apache.cocoon.CascadingIOException: If you see this
>>> exception you probably called
>>> Source.getInputStream even though the source reported proper validity.
>>> The only way to solve this
>>> is to implement a resource heavy version of postable source.:
>>> javax.servlet.ServletException: If
>>> you see this exception you probably called Source.getInputStream even
>>> though the source reported
>>> proper validity. The only way to solve this is to implement a resource
>>> heavy version of postable
>>> source.
>> this probably means we will not be able to implement fully pipelined
>> servlet services.. I have reverted the change we did at GT.
>
> Very unfortunate news but I don't think situation is hopeless.
>
> Anyway, my opinion is that we should just start with buffer and after servlet-service stabilizes. We
> could continue improving servlet protocol performance. Otherwise, if we are going to complicate it
> now it's going to be hard to figure out what's the possible problem with servlet protocol.
>
> Giacomo, does everything work for you after Leszek reverted his changes?
I'm still testing after Leszek reverted his changes and suprisingly our app seems to work now
(whatever change or revert made it happen) ?!?!?!
I'll give more info as soon as I've finished testing our app with latest Cocoon
Ciao and thanks
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHCyI4LNdJvZjjVZARAhxkAKC6E6CtiQvOmimVqYFqb0C9i6wiLwCghYOZ
Pb/QhMdqO/Pl00K12Fzjpio=
=L/xL
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Leszek Gawron pisze:
>>
>> Caused by: org.apache.cocoon.CascadingIOException: If you see this
>> exception you probably called
>> Source.getInputStream even though the source reported proper validity.
>> The only way to solve this
>> is to implement a resource heavy version of postable source.:
>> javax.servlet.ServletException: If
>> you see this exception you probably called Source.getInputStream even
>> though the source reported
>> proper validity. The only way to solve this is to implement a resource
>> heavy version of postable
>> source.
>
> this probably means we will not be able to implement fully pipelined
> servlet services.. I have reverted the change we did at GT.
Very unfortunate news but I don't think situation is hopeless.
Anyway, my opinion is that we should just start with buffer and after servlet-service stabilizes. We
could continue improving servlet protocol performance. Otherwise, if we are going to complicate it
now it's going to be hard to figure out what's the possible problem with servlet protocol.
Giacomo, does everything work for you after Leszek reverted his changes?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Giacomo Pati wrote:
>>
>> Grzegorz Kossakowski wrote:
>>
>>> Giacomo, sorry that it took me so long to take a look at this but
>>> CocoonGT was quite involving event. It certainly was worth the effort I
>>> put to get there! :)
>> NP. Hope you enjoyed GT.
>>
>>> Getting back to the topic. I think I found cause of all problems people
>>> were having and it turns out that I forgot that cocoon: protocol has
>>> insanely complicated flow so all decent assumptions about our
>>> environment do not work when it is used.
>>> I believe that the changed I committed in r582629 fixes all troubles. At
>>> least your sample is working now returning such result:
>>> <?xml version="1.0" encoding="ISO-8859-1"?><status
>>> xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"><document
>>> xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
>>> <body>
>>> <count>3</count>
>>> <size>2</size>
>>> </body>
>>> </document></status>
>>> Is it what you expected? Could give it little more testing? Actually
>>> this issue blocks whole RC2 so haste is advisable here.
>> Thanks alot! I'll take a look at it this today.
>
> Actually I get mostly:
>
> org.apache.cocoon.CascadingIOException: If you see this exception you probably called
> Source.getInputStream even though the source reported proper validity. The only way to solve this
> is to implement a resource heavy version of postable source.: javax.servlet.ServletException: If
> you see this exception you probably called Source.getInputStream even though the source reported
> proper validity. The only way to solve this is to implement a resource heavy version of postable
> source.
>
> on things which were valid before.
>
> Any hints?
>
> Relevant stack trace:
>
> Caused by: org.apache.cocoon.CascadingIOException: If you see this exception you probably called
> Source.getInputStream even though the source reported proper validity. The only way to solve this
> is to implement a resource heavy version of postable source.: javax.servlet.ServletException: If
> you see this exception you probably called Source.getInputStream even though the source reported
> proper validity. The only way to solve this is to implement a resource heavy version of postable
> source.
this probably means we will not be able to implement fully pipelined
servlet services.. I have reverted the change we did at GT.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Giacomo Pati wrote:
>
>
> Grzegorz Kossakowski wrote:
>
>> Giacomo, sorry that it took me so long to take a look at this but
>> CocoonGT was quite involving event. It certainly was worth the effort I
>> put to get there! :)
>
> NP. Hope you enjoyed GT.
>
>> Getting back to the topic. I think I found cause of all problems people
>> were having and it turns out that I forgot that cocoon: protocol has
>> insanely complicated flow so all decent assumptions about our
>> environment do not work when it is used.
>> I believe that the changed I committed in r582629 fixes all troubles. At
>> least your sample is working now returning such result:
>> <?xml version="1.0" encoding="ISO-8859-1"?><status
>> xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"><document
>> xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
>> <body>
>> <count>3</count>
>> <size>2</size>
>> </body>
>> </document></status>
>
>> Is it what you expected? Could give it little more testing? Actually
>> this issue blocks whole RC2 so haste is advisable here.
>
> Thanks alot! I'll take a look at it this today.
Actually I get mostly:
org.apache.cocoon.CascadingIOException: If you see this exception you probably called
Source.getInputStream even though the source reported proper validity. The only way to solve this
is to implement a resource heavy version of postable source.: javax.servlet.ServletException: If
you see this exception you probably called Source.getInputStream even though the source reported
proper validity. The only way to solve this is to implement a resource heavy version of postable
source.
on things which were valid before.
Any hints?
Relevant stack trace:
Caused by: org.apache.cocoon.CascadingIOException: If you see this exception you probably called
Source.getInputStream even though the source reported proper validity. The only way to solve this
is to implement a resource heavy version of postable source.: javax.servlet.ServletException: If
you see this exception you probably called Source.getInputStream even though the source reported
proper validity. The only way to solve this is to implement a resource heavy version of postable
source.
at
org.apache.cocoon.servletservice.components.ServletSource.getInputStream(ServletSource.java:89)
at org.apache.cocoon.components.source.util.SourceUtil.getInputSource(SourceUtil.java:428)
at org.apache.cocoon.components.source.util.SourceUtil.parse(SourceUtil.java:297)
at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:144)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:331)
... 143 more
The FileGenerator in question has:
<map:generate src="servlet:myBlock2:/user-status" />
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHCgZ6LNdJvZjjVZARAghoAJ4wNVH+JFiP3yUnVlaMuDy19ce0ygCdEe91
h/4Xx1HjIZnyJf4leuOcYyg=
=55Lm
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo, sorry that it took me so long to take a look at this but
> CocoonGT was quite involving event. It certainly was worth the effort I
> put to get there! :)
NP. Hope you enjoyed GT.
> Getting back to the topic. I think I found cause of all problems people
> were having and it turns out that I forgot that cocoon: protocol has
> insanely complicated flow so all decent assumptions about our
> environment do not work when it is used.
> I believe that the changed I committed in r582629 fixes all troubles. At
> least your sample is working now returning such result:
> <?xml version="1.0" encoding="ISO-8859-1"?><status
> xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"><document
> xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
> <body>
> <count>3</count>
> <size>2</size>
> </body>
> </document></status>
>
> Is it what you expected? Could give it little more testing? Actually
> this issue blocks whole RC2 so haste is advisable here.
Thanks alot! I'll take a look at it this today.
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHCbpOLNdJvZjjVZARArdrAKCwRGV0/p5rfxHwzmFCtAHuwwlCCACgt5Hx
HmPMa3rZCI15m+SiYtoAoC0=
=qC4y
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Giacomo Pati pisze:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Grzegorz Kossakowski wrote:
>> Any chance to reproduce this behaviour with my little sample? I tried to modify it so empty List is
>> passed but everything works fine. Is your list a standard Java implementation like ArrayList?
>> Isolating the problem that anyone can test on its own machine is crucial here, really. Or you can
>> just consider debugging Jexl yourself, it's has source code written decently.
>
> I've setup a stripped down to bare minimum sample (based on your little sample) that has the
> behaviour as our application. I can confirm, that this sample works with trunk upto revision
> 567300. You'll find it at http://people.apache.org/~giacomo/c2.2-test.tar.gz
Giacomo, sorry that it took me so long to take a look at this but
CocoonGT was quite involving event. It certainly was worth the effort I
put to get there! :)
Getting back to the topic. I think I found cause of all problems people
were having and it turns out that I forgot that cocoon: protocol has
insanely complicated flow so all decent assumptions about our
environment do not work when it is used.
I believe that the changed I committed in r582629 fixes all troubles. At
least your sample is working now returning such result:
<?xml version="1.0" encoding="ISO-8859-1"?><status
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"><document
xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
<body>
<count>3</count>
<size>2</size>
</body>
</document></status>
Is it what you expected? Could give it little more testing? Actually
this issue blocks whole RC2 so haste is advisable here.
Thanks for your patience.
--
Grzegorz Kossakowski
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz pisze:
>
> Caused by: java.lang.NullPointerException
> at org.apache.cocoon.callstack.CallScope.get(CallScope.java:37)
>
> It can easily be reproduced by adding this pipeline to a Cocoon 2.2 app
> created by the Cocoon 2.2 archetype:
>
> <map:match pattern="fails">
> <map:generate src="cocoon:/spring-bean"/>
> <map:serialize type="xml"/>
> </map:match>
It wasn't serious but I fixed it (by disabling
PipelineComponentProxyDecorator) in r582628.
Thanks for reporting.
--
Grzegorz Kossakowski
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> Grzegorz Kossakowski wrote:
>> Any chance to reproduce this behaviour with my little sample? I tried to modify it so empty List is
>> passed but everything works fine. Is your list a standard Java implementation like ArrayList?
>> Isolating the problem that anyone can test on its own machine is crucial here, really. Or you can
>> just consider debugging Jexl yourself, it's has source code written decently.
>
> I've setup a stripped down to bare minimum sample (based on your little sample) that has the
> behaviour as our application. I can confirm, that this sample works with trunk upto revision
> 567300. You'll find it at http://people.apache.org/~giacomo/c2.2-test.tar.gz
I don't know if it is related but if I use the cocoon protocol to call a
pipeline that uses a jx-template, the template doesn't receive the passed
objects anymore. I think that's the relevant part of the stacktrace:
Caused by: java.lang.NullPointerException
at org.apache.cocoon.callstack.CallScope.get(CallScope.java:37)
It can easily be reproduced by adding this pipeline to a Cocoon 2.2 app created
by the Cocoon 2.2 archetype:
<map:match pattern="fails">
<map:generate src="cocoon:/spring-bean"/>
<map:serialize type="xml"/>
</map:match>
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Any chance to reproduce this behaviour with my little sample? I tried to modify it so empty List is
> passed but everything works fine. Is your list a standard Java implementation like ArrayList?
> Isolating the problem that anyone can test on its own machine is crucial here, really. Or you can
> just consider debugging Jexl yourself, it's has source code written decently.
I've setup a stripped down to bare minimum sample (based on your little sample) that has the
behaviour as our application. I can confirm, that this sample works with trunk upto revision
567300. You'll find it at http://people.apache.org/~giacomo/c2.2-test.tar.gz
HTH and MTIA
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG96fVLNdJvZjjVZARApDvAKDaG/DTbXqfv7k9YOn5H3pJu7LyZwCfRJxD
bIEHV4c7Esf4jA9U/ssWak8=
=qjEq
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
> I've tried current trunk as well and it seems that the stack trace I've
> reported earlier is gone now and I'm again at the NPE from jexl. After
> some debugging as you told me, I can confirm that the failing request of
> my app is using the one and only OM instance created during that
> request. I can also see the status object being put into it and fetched
> later again with a "myTasks" attribute which _is_ a List having a size
> of 0
Good to hear that. We have at least can remove large portion of code from the list of suspected.
> but jexl still barfs the NPE "cannot evaluate
> 'status.myTasks.size()'?!?!?! Which makes me believe it could be a Jexl
> problem. Did we changed Jexl version???
>
> I'm stuck again.
I'm sure that we have not upgraded Jexl for at least three months.
Any chance to reproduce this behaviour with my little sample? I tried to modify it so empty List is
passed but everything works fine. Is your list a standard Java implementation like ArrayList?
Isolating the problem that anyone can test on its own machine is crucial here, really. Or you can
just consider debugging Jexl yourself, it's has source code written decently.
Thank you for quick response.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@otego.com>.
On Thu, 20 Sep 2007, Grzegorz Kossakowski wrote:
> Date: Thu, 20 Sep 2007 18:54:24 +0200
> From: Grzegorz Kossakowski <gk...@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: pipelineComponent scope troubles (was Code freeze?)
>
> Grzegorz Kossakowski pisze:
>>
>> When looking at this issue and the stacktrace you have given above I'm feeling like having Déjà vu.
>> I have experienced problem with UnmodifiableMap at the time I made the commit you mentioned and I
>> thought that I had fixed it immediately. It turns out that I must have forgot to do it and lost my
>> fix while upgrading my hardware...
>>
>> I'm going to find a proper fix now. Thanks for reporting.
>
> Ehkm. After digging the code I came to conclusion that this issue has been fixed, after all...
>
> The fix was pretty naive and made in r567433 (my next commit after r567329), see:
> http://article.gmane.org/gmane.text.xml.cocoon.cvs/25006
I've tried current trunk as well and it seems that the stack trace I've
reported earlier is gone now and I'm again at the NPE from jexl. After
some debugging as you told me, I can confirm that the failing request of
my app is using the one and only OM instance created during that request.
I can also see the status object being put into it and fetched later again
with a "myTasks" attribute which _is_ a List having a size of 0 but jexl
still barfs the NPE "cannot evaluate 'status.myTasks.size()'?!?!?!
Which makes me believe it could be a Jexl problem. Did we changed Jexl
version???
I'm stuck again.
--
Otego AG Tel: +41 (0)1 240 00 55
Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04
Apache Software Foundation Member Mailto:giacomo@apache.org
Hohlstrasse 216 Mailto:Giacomo.Pati@otego.com
CH-8004 Zürich http://www.otego.com
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Grzegorz Kossakowski pisze:
>
> When looking at this issue and the stacktrace you have given above I'm feeling like having Déjà vu.
> I have experienced problem with UnmodifiableMap at the time I made the commit you mentioned and I
> thought that I had fixed it immediately. It turns out that I must have forgot to do it and lost my
> fix while upgrading my hardware...
>
> I'm going to find a proper fix now. Thanks for reporting.
Ehkm. After digging the code I came to conclusion that this issue has been fixed, after all...
The fix was pretty naive and made in r567433 (my next commit after r567329), see:
http://article.gmane.org/gmane.text.xml.cocoon.cvs/25006
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>
>
> Giacomo Pati wrote:
>
> <snip-all>
>
> I've isolated the culprit commit that caused our application to stop working. Our application works
> fine up to and excluding commit r567329 which was
> http://article.gmane.org/gmane.text.xml.cocoon.cvs/24998/match=r567329:
>
> cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/components/treeprocessor/InvokeContext.java
> Sat Aug 18 14:12:45 2007
>> @@ -231,6 +231,8 @@
>> final String sitemapObjectModelPathPrefix = "sitemap";
>> final String sitemapObjectModelNamedPathPrefix = sitemapObjectModelPathPrefix + "/$named$";
>
>> + newObjectModel.markLocalContext();
>> +
>> this.mapStack.add(map);
>
>> if (getLogger().isDebugEnabled()) {
>> @@ -292,6 +294,7 @@
>> Object name = this.mapToName.get(map);
>> this.mapToName.remove(map);
>> this.nameToMap.remove(name);
>> + this.newObjectModel.cleanupLocalContext();
>> }
>
>
> Looking at the commit above and the stack trace we have got
>
> Caused by: java.lang.UnsupportedOperationException
> at org.apache.commons.collections.map.UnmodifiableMap.remove(UnmodifiableMap.java:115)
> at
> org.apache.commons.collections.map.AbstractMapDecorator.remove(AbstractMapDecorator.java:114)
> at org.apache.cocoon.objectmodel.ObjectModelImpl.removeAt(ObjectModelImpl.java:167)
> at org.apache.cocoon.objectmodel.ObjectModelImpl.cleanupLocalContext(ObjectModelImpl.java:177)
>
> it seams that the cleanupLocalContext() method will modify a UnmodifiableMap which of cource will
> produce this exception.
>
> Now, before I'll dig into it, I'll ask here whether this is something obvious to someone?
>
> Ciao and thanks
Giacomo, I'm lost with your issues. What about NPE you had, what about my sample? Does this work for
you, now?
When looking at this issue and the stacktrace you have given above I'm feeling like having Déjà vu.
I have experienced problem with UnmodifiableMap at the time I made the commit you mentioned and I
thought that I had fixed it immediately. It turns out that I must have forgot to do it and lost my
fix while upgrading my hardware...
I'm going to find a proper fix now. Thanks for reporting.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Giacomo Pati wrote:
<snip-all>
I've isolated the culprit commit that caused our application to stop working. Our application works
fine up to and excluding commit r567329 which was
http://article.gmane.org/gmane.text.xml.cocoon.cvs/24998/match=r567329:
cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/components/treeprocessor/InvokeContext.java
Sat Aug 18 14:12:45 2007
> @@ -231,6 +231,8 @@
> final String sitemapObjectModelPathPrefix = "sitemap";
> final String sitemapObjectModelNamedPathPrefix = sitemapObjectModelPathPrefix + "/$named$";
>
> + newObjectModel.markLocalContext();
> +
> this.mapStack.add(map);
>
> if (getLogger().isDebugEnabled()) {
> @@ -292,6 +294,7 @@
> Object name = this.mapToName.get(map);
> this.mapToName.remove(map);
> this.nameToMap.remove(name);
> + this.newObjectModel.cleanupLocalContext();
> }
Looking at the commit above and the stack trace we have got
Caused by: java.lang.UnsupportedOperationException
at org.apache.commons.collections.map.UnmodifiableMap.remove(UnmodifiableMap.java:115)
at
org.apache.commons.collections.map.AbstractMapDecorator.remove(AbstractMapDecorator.java:114)
at org.apache.cocoon.objectmodel.ObjectModelImpl.removeAt(ObjectModelImpl.java:167)
at org.apache.cocoon.objectmodel.ObjectModelImpl.cleanupLocalContext(ObjectModelImpl.java:177)
it seams that the cleanupLocalContext() method will modify a UnmodifiableMap which of cource will
produce this exception.
Now, before I'll dig into it, I'll ask here whether this is something obvious to someone?
Ciao and thanks
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG8m+zLNdJvZjjVZARApWjAKC5u3j4fyqaLjhArbtZVmMBMffOjQCgpgFN
L3apJJhlEh8bxVfZy72v14w=
=FMhy
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, thanks. So we have at least 2 machines where current trunk isn't running correctly. And as
Linux is probably the most used target platform I categorize it as a serious problem.
Is there anybody having success on Linux?
Felix Knecht wrote:
> Giacomo Pati schrieb:
>> Felix
>>
>> As you have a similar environment as I have, could you give the sample
>> from Grzegorz a try with the
>> latest trunk (including changes from Grzegorz of today)?
>>
> Yes of course
>
>> First build (mvn clean install) myBlock2, than myBlock1, and
>> afterwards myCocoonWebapp. Let it run
>> and point to http://localhost:8888/myBlock2/screens/obtain-data to see
>> whether you get an Exception
>> or data.
>>
> I still get an Exception, see log [1].
>
> I cleaned local maven repo and rebuild latest svn co of cocoon trunk
> r577240 with sun-jdk-1.6.0_02
>
> [1] http://people.apache.org/~felixk/GrekSample_001.log
>
> PS:
> Of course now the zip... testcase fails under linux because of commit
> 577108 again ;-)
>
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG8RC3LNdJvZjjVZARAnuHAKCwzd4KUcXHBEwUtgJEK7F04elHawCeLlWt
wC1SKi9cMPH/iYo+eMVi7xU=
=Dpu5
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.09.2007 7:54 Uhr, Felix Knecht wrote:
> PS:
> Of course now the zip... testcase fails under linux because of commit
> 577108 again ;-)
You can easily fix this by adding the slash back to the test case locally.
Joerg
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Felix Knecht <fe...@apache.org>.
Giacomo Pati schrieb:
>
> Felix
>
> As you have a similar environment as I have, could you give the sample
> from Grzegorz a try with the
> latest trunk (including changes from Grzegorz of today)?
>
Yes of course
> First build (mvn clean install) myBlock2, than myBlock1, and
> afterwards myCocoonWebapp. Let it run
> and point to http://localhost:8888/myBlock2/screens/obtain-data to see
> whether you get an Exception
> or data.
>
I still get an Exception, see log [1].
I cleaned local maven repo and rebuild latest svn co of cocoon trunk
r577240 with sun-jdk-1.6.0_02
[1] http://people.apache.org/~felixk/GrekSample_001.log
PS:
Of course now the zip... testcase fails under linux because of commit
577108 again ;-)
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Felix Knecht wrote:
>> Is this failing test case a blocker for the release? In my opinion not
>> because everything else seems to work.
>>
>> WDOT?
>>
> I don't think it's a blocker:
> 1. We wouldn't be the only ones releasing (just in case it's a real bug
> and not a testcase problem) and having a release note with already known
> bugs.
> 2. It's a RC (2). Why are (just in case) already known bugs not allowed?
> 3. It would be really nice to see the RC2 released for the CocoonGT
> (Please go ahead with the release.)!
> 4. If ever I'd rather consider the 'pipelineComponent Scope troubles' as
> a problem than the zipper stuff.
Felix
As you have a similar environment as I have, could you give the sample from Grzegorz a try with the
latest trunk (including changes from Grzegorz of today)?
First build (mvn clean install) myBlock2, than myBlock1, and afterwards myCocoonWebapp. Let it run
and point to http://localhost:8888/myBlock2/screens/obtain-data to see whether you get an Exception
or data.
TIA
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG8QfPLNdJvZjjVZARAn+VAKCiQ8gViZlM8+oF7RiLHBZL3Do01gCeKKJE
N6To1VPPVtLYZWgowty4hdc=
=dSUj
-----END PGP SIGNATURE-----
Re: Code freeze?
Posted by Reinhard Poetz <re...@apache.org>.
Felix Knecht wrote:
> 4. If ever I'd rather consider the 'pipelineComponent Scope troubles' as
> a problem than the zipper stuff.
agreed, but after some thinking about it I came to the conclusion that I can
create the release artifacts anyway. I will only have to wait with starting the
voting process until we know if there is some serious bug or not. If there is
one, I will recreate the relevant artifacts again but most of the work will
already be done by then and I can do it in between.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht pisze:
> I don't think it's a blocker:
> 1. We wouldn't be the only ones releasing (just in case it's a real bug
> and not a testcase problem) and having a release note with already known
> bugs.
> 2. It's a RC (2). Why are (just in case) already known bugs not allowed?
> 3. It would be really nice to see the RC2 released for the CocoonGT
> (Please go ahead with the release.)!
+1
> 4. If ever I'd rather consider the 'pipelineComponent Scope troubles' as
> a problem than the zipper stuff.
I switched pipelineComponent scope off in r577222 as promised earlier. Giacomo's problem seems to be
rather exotic (when taking account his last e-mail) and I'm not sure if other people do have the
same problem.
I would be grateful if others could try my little sample with newest trunk. Expected result: tiny
XML file and no exceptions thrown.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Code freeze?
Posted by Felix Knecht <fe...@apache.org>.
> Is this failing test case a blocker for the release? In my opinion not
> because everything else seems to work.
>
> WDOT?
>
I don't think it's a blocker:
1. We wouldn't be the only ones releasing (just in case it's a real bug
and not a testcase problem) and having a release note with already known
bugs.
2. It's a RC (2). Why are (just in case) already known bugs not allowed?
3. It would be really nice to see the RC2 released for the CocoonGT
(Please go ahead with the release.)!
4. If ever I'd rather consider the 'pipelineComponent Scope troubles' as
a problem than the zipper stuff.
Felix
Re: Code freeze?
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Hmm, I'm still not sure what is wrong: the sourceresolver impl or this
> test? After the disaster of the 2.2.2 release breaking this stuff, I
> tested the 2.2.3 release on both windows and macos x and it did work for
> me. I also tested Cocoon 2.1.x and trunk with it and it worked - both
> failed with the 2.2.2 version.
>
> So, perhaps its just the test case which is wrong?
Is this failing test case a blocker for the release? In my opinion not because
everything else seems to work.
WDOT?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.09.2007 8:35 Uhr, Carsten Ziegeler wrote:
> But, I think that we need the three slashes in some cases, as the uri is
> otherwise not parsable as a uri again. Although its not a correct uri it
> works whereas the correct uri does not.
But before we had any os-specific refinement it worked for us, so
actually with only one or two slashes. It was only the introduced
ZipSourceTestCase that revealed the different behavior with the slashes.
So we should be ok with 2 slashes but I don't mind if we always go to 3
slashes. The code in the FileSource is just for wiping out the os
differences.
Joerg
Re: Code freeze?
Posted by Carsten Ziegeler <cz...@apache.org>.
Joerg Heinicke schrieb:
> On 19.09.2007 3:12 Uhr, Carsten Ziegeler wrote:
>
>>> This code was updated on 20.07.2007 with the upgrade to sourceresolve
>>> 2.2.3 (rev 557982 and 557994 [1, 2] and 557984 on 2.1 [3]). Since then
>>> it must be failing. From what I get it's now failing for Windows with 2
>>> slashes while the test expects 3. Linux/Mac OS X seems to work since
>>> they have 3 slashes now. Before it was the other way around, Windows
>>> worked with 2, Linux/Mac OS X failed with 1.
>>>
>>> From the implementation [4] this is pretty clear:
>>>
>>> uri = file.toURL().toExternalForm();
>>> // toExternalForm() is buggy, see e.g.
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4924415
>>> // therefore we check if file: is followed by just one slash
>>> // TODO when we move to JDK 1.4+, we should use
>>> file.toURI().toASCIIString() instead.
>>> if ( uri.length() > 6 && uri.startsWith("file:/") && uri.charAt(6) !=
>>> '/' )
>>> {
>>> uri = "file:///" + uri.substring(6);
>>> }
>>>
>>> It just adds 3 slashes instead of 2 as it is supposed to do. So we
>>> probably need a sourceresolve 2.2.4. Is this likely to happen fast or do
>>> we need to revert the test case to not fail for the moment? Anyway, I'm
>>> going to change the test case back to 2 slashes. sourceresolve's own
>>> test case also only checks for 2 slashes [5].
>>>
>> Hmm, I'm still not sure what is wrong: the sourceresolver impl or this
>> test? After the disaster of the 2.2.2 release breaking this stuff, I
>> tested the 2.2.3 release on both windows and macos x and it did work for
>> me. I also tested Cocoon 2.1.x and trunk with it and it worked - both
>> failed with the 2.2.2 version.
>>
>> So, perhaps its just the test case which is wrong?
>
> Without the above condition the uri came out with 2 slashes on Windows
> and 1 slash on other os. With the condition you actually replace file:/
> with file:/// so you eventually have 3 slashes in case there was only
> one before.
>
> If you had a successful run on Windows (did it run through the condition
> or had it 3 slashes from the beginning??) there must be a different
> behavior between Windows versions as well. But can you place
> double-check that? On Windows you should really get exactly 2 slashes.
> That's why I thought the code needs to be fixed and not the test case.
> The uri should always have 2 slashes.
>
I'll double check on windows - I tested weeks ago :)
But, I think that we need the three slashes in some cases, as the uri is
otherwise not parsable as a uri again. Although its not a correct uri it
works whereas the correct uri does not.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Code freeze?
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joerg Heinicke wrote:
> On 19.09.2007 11:32 Uhr, Daniel Fagerstrom wrote:
>
>> While we have a historical tradition of using 2 slashes, but it is
>> wrong according to the URL standard
>> (http://gbiv.com/protocols/uri/rfc/rfc3986.html). 1 or 3 slashes is
>> correct. No idea about how we should handle this fact though ;)
>
> Ok, for Windows it might make sense considering the drives as
> authority part: file://C:/temp/file.tmp. Maybe we should talk about
> the actual task of this method. Is it about wiping out differences of
> the os what I thought so far? Or do we go with the os differences.
> Then maybe the test must be more relaxed.
I don't think so. The way I read it C would be a host name a the ":"
would be invalid because it is required to be followed by a port.
http://www.mozilla.org/quality/networking/testing/filetests.html has a
bunch of examples.
http://blogs.msdn.com/ie/archive/2006/12/06/file-uris-in-windows.aspx
documents what was done in IE 7.
Of course, I always solve this by using cygwin on Windows...
Ralph
Re: Code freeze?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.09.2007 11:32 Uhr, Daniel Fagerstrom wrote:
> While we have a historical tradition of using 2 slashes, but it is wrong
> according to the URL standard
> (http://gbiv.com/protocols/uri/rfc/rfc3986.html). 1 or 3 slashes is
> correct. No idea about how we should handle this fact though ;)
Ok, for Windows it might make sense considering the drives as authority
part: file://C:/temp/file.tmp. Maybe we should talk about the actual
task of this method. Is it about wiping out differences of the os what I
thought so far? Or do we go with the os differences. Then maybe the test
must be more relaxed.
Joerg
Re: Code freeze?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke skrev:
> On 19.09.2007 3:12 Uhr, Carsten Ziegeler wrote:
>
>>> This code was updated on 20.07.2007 with the upgrade to sourceresolve
>>> 2.2.3 (rev 557982 and 557994 [1, 2] and 557984 on 2.1 [3]). Since then
>>> it must be failing. From what I get it's now failing for Windows with 2
>>> slashes while the test expects 3. Linux/Mac OS X seems to work since
>>> they have 3 slashes now. Before it was the other way around, Windows
>>> worked with 2, Linux/Mac OS X failed with 1.
>>>
>>> From the implementation [4] this is pretty clear:
>>>
>>> uri = file.toURL().toExternalForm();
>>> // toExternalForm() is buggy, see e.g.
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4924415
>>> // therefore we check if file: is followed by just one slash
>>> // TODO when we move to JDK 1.4+, we should use
>>> file.toURI().toASCIIString() instead.
>>> if ( uri.length() > 6 && uri.startsWith("file:/") && uri.charAt(6)
>>> != '/' )
>>> {
>>> uri = "file:///" + uri.substring(6);
>>> }
>>>
>>> It just adds 3 slashes instead of 2 as it is supposed to do. So we
>>> probably need a sourceresolve 2.2.4. Is this likely to happen fast
>>> or do
>>> we need to revert the test case to not fail for the moment? Anyway, I'm
>>> going to change the test case back to 2 slashes. sourceresolve's own
>>> test case also only checks for 2 slashes [5].
>>>
>> Hmm, I'm still not sure what is wrong: the sourceresolver impl or this
>> test? After the disaster of the 2.2.2 release breaking this stuff, I
>> tested the 2.2.3 release on both windows and macos x and it did work for
>> me. I also tested Cocoon 2.1.x and trunk with it and it worked - both
>> failed with the 2.2.2 version.
>>
>> So, perhaps its just the test case which is wrong?
>
> Without the above condition the uri came out with 2 slashes on Windows
> and 1 slash on other os. With the condition you actually replace
> file:/ with file:/// so you eventually have 3 slashes in case there
> was only one before.
>
> If you had a successful run on Windows (did it run through the
> condition or had it 3 slashes from the beginning??) there must be a
> different behavior between Windows versions as well. But can you place
> double-check that? On Windows you should really get exactly 2 slashes.
> That's why I thought the code needs to be fixed and not the test case.
> The uri should always have 2 slashes.
While we have a historical tradition of using 2 slashes, but it is wrong
according to the URL standard
(http://gbiv.com/protocols/uri/rfc/rfc3986.html). 1 or 3 slashes is
correct. No idea about how we should handle this fact though ;)
/Daniel
Re: Code freeze?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.09.2007 8:25 Uhr, Joerg Heinicke wrote:
> But can you place double-check that?
... please ...
Joerg
Re: Code freeze?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.09.2007 3:12 Uhr, Carsten Ziegeler wrote:
>> This code was updated on 20.07.2007 with the upgrade to sourceresolve
>> 2.2.3 (rev 557982 and 557994 [1, 2] and 557984 on 2.1 [3]). Since then
>> it must be failing. From what I get it's now failing for Windows with 2
>> slashes while the test expects 3. Linux/Mac OS X seems to work since
>> they have 3 slashes now. Before it was the other way around, Windows
>> worked with 2, Linux/Mac OS X failed with 1.
>>
>> From the implementation [4] this is pretty clear:
>>
>> uri = file.toURL().toExternalForm();
>> // toExternalForm() is buggy, see e.g.
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4924415
>> // therefore we check if file: is followed by just one slash
>> // TODO when we move to JDK 1.4+, we should use
>> file.toURI().toASCIIString() instead.
>> if ( uri.length() > 6 && uri.startsWith("file:/") && uri.charAt(6) != '/' )
>> {
>> uri = "file:///" + uri.substring(6);
>> }
>>
>> It just adds 3 slashes instead of 2 as it is supposed to do. So we
>> probably need a sourceresolve 2.2.4. Is this likely to happen fast or do
>> we need to revert the test case to not fail for the moment? Anyway, I'm
>> going to change the test case back to 2 slashes. sourceresolve's own
>> test case also only checks for 2 slashes [5].
>>
> Hmm, I'm still not sure what is wrong: the sourceresolver impl or this
> test? After the disaster of the 2.2.2 release breaking this stuff, I
> tested the 2.2.3 release on both windows and macos x and it did work for
> me. I also tested Cocoon 2.1.x and trunk with it and it worked - both
> failed with the 2.2.2 version.
>
> So, perhaps its just the test case which is wrong?
Without the above condition the uri came out with 2 slashes on Windows
and 1 slash on other os. With the condition you actually replace file:/
with file:/// so you eventually have 3 slashes in case there was only
one before.
If you had a successful run on Windows (did it run through the condition
or had it 3 slashes from the beginning??) there must be a different
behavior between Windows versions as well. But can you place
double-check that? On Windows you should really get exactly 2 slashes.
That's why I thought the code needs to be fixed and not the test case.
The uri should always have 2 slashes.
Joerg
Re: Code freeze?
Posted by Carsten Ziegeler <cz...@apache.org>.
Joerg Heinicke wrote:
> This code was updated on 20.07.2007 with the upgrade to sourceresolve
> 2.2.3 (rev 557982 and 557994 [1, 2] and 557984 on 2.1 [3]). Since then
> it must be failing. From what I get it's now failing for Windows with 2
> slashes while the test expects 3. Linux/Mac OS X seems to work since
> they have 3 slashes now. Before it was the other way around, Windows
> worked with 2, Linux/Mac OS X failed with 1.
>
> From the implementation [4] this is pretty clear:
>
> uri = file.toURL().toExternalForm();
> // toExternalForm() is buggy, see e.g.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4924415
> // therefore we check if file: is followed by just one slash
> // TODO when we move to JDK 1.4+, we should use
> file.toURI().toASCIIString() instead.
> if ( uri.length() > 6 && uri.startsWith("file:/") && uri.charAt(6) != '/' )
> {
> uri = "file:///" + uri.substring(6);
> }
>
> It just adds 3 slashes instead of 2 as it is supposed to do. So we
> probably need a sourceresolve 2.2.4. Is this likely to happen fast or do
> we need to revert the test case to not fail for the moment? Anyway, I'm
> going to change the test case back to 2 slashes. sourceresolve's own
> test case also only checks for 2 slashes [5].
>
Hmm, I'm still not sure what is wrong: the sourceresolver impl or this
test? After the disaster of the 2.2.2 release breaking this stuff, I
tested the 2.2.3 release on both windows and macos x and it did work for
me. I also tested Cocoon 2.1.x and trunk with it and it worked - both
failed with the 2.2.2 version.
So, perhaps its just the test case which is wrong?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Code freeze?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 18.09.2007 19:34 Uhr, Joerg Heinicke wrote:
> // toExternalForm() is buggy, see e.g.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4924415
> // therefore we check if file: is followed by just one slash
> // TODO when we move to JDK 1.4+, we should use
> file.toURI().toASCIIString() instead.
Btw., I can't confirm the proposed fixes in Sun's bug tracker. It's not
only File.toURL() that is broken. File.toURI() does neither work for me
on Mac OS X but ends up with just 1 slash.
Joerg
Re: Code freeze?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 18.09.2007 7:45 Uhr, Reinhard Poetz wrote:
> Test set: org.apache.cocoon.components.source.impl.ZipSourceTestCase
> -------------------------------------------------------------------------------
>
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec
> <<< FAILURE!
> testURIHandling(org.apache.cocoon.components.source.impl.ZipSourceTestCase)
> Time elapsed: 0.01 sec <<< FAILURE!
> junit.framework.ComparisonFailure: Uri is wrong.
> expected:<zip:file://[/]test.zip!/test.xml> but
> was:<zip:file://[]test.zip!/test.xml>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at
> org.apache.cocoon.components.source.impl.ZipSourceTestCase.testURIHandling(ZipSourceTestCase.java:45)
This code was updated on 20.07.2007 with the upgrade to sourceresolve
2.2.3 (rev 557982 and 557994 [1, 2] and 557984 on 2.1 [3]). Since then
it must be failing. From what I get it's now failing for Windows with 2
slashes while the test expects 3. Linux/Mac OS X seems to work since
they have 3 slashes now. Before it was the other way around, Windows
worked with 2, Linux/Mac OS X failed with 1.
From the implementation [4] this is pretty clear:
uri = file.toURL().toExternalForm();
// toExternalForm() is buggy, see e.g.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4924415
// therefore we check if file: is followed by just one slash
// TODO when we move to JDK 1.4+, we should use
file.toURI().toASCIIString() instead.
if ( uri.length() > 6 && uri.startsWith("file:/") && uri.charAt(6) != '/' )
{
uri = "file:///" + uri.substring(6);
}
It just adds 3 slashes instead of 2 as it is supposed to do. So we
probably need a sourceresolve 2.2.4. Is this likely to happen fast or do
we need to revert the test case to not fail for the moment? Anyway, I'm
going to change the test case back to 2 slashes. sourceresolve's own
test case also only checks for 2 slashes [5].
Joerg
[1] http://svn.apache.org/viewvc?view=rev&revision=557982
[2] http://svn.apache.org/viewvc?view=rev&revision=557994
[3] http://svn.apache.org/viewvc?view=rev&revision=557984
[4]
http://svn.apache.org/viewvc/excalibur/tags/excalibur-sourceresolve-2.2.3/src/java/org/apache/excalibur/source/impl/FileSource.java?revision=540857&view=markup
[5]
http://svn.apache.org/viewvc/excalibur/tags/excalibur-sourceresolve-2.2.3/src/test/org/apache/excalibur/source/test/FileSourceTestCase.java?revision=553534&view=markup
Re: Code freeze?
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Can anybody confirm this or is it a problem with my environment
>> (although I deleted my local repo, then entered svn up, mvn clean install)?
>
> Reinhard, I tried to build Cocoon with empty Maven local repo and results are the same: everything
> works just fine. Are you sure there is no old junk somewhere?
I don't think so. I removed all Cocoon artifacts from my local repo and did a
fresh 'svn co' of trunk. (WinXP, Java 1.5.0_11)
For me the ZipSourceTestCase is failing (again):
-------------------------------------------------------------------------------
Test set: org.apache.cocoon.components.source.impl.ZipSourceTestCase
-------------------------------------------------------------------------------
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec <<<
FAILURE!
testURIHandling(org.apache.cocoon.components.source.impl.ZipSourceTestCase)
Time elapsed: 0.01 sec <<< FAILURE!
junit.framework.ComparisonFailure: Uri is wrong.
expected:<zip:file://[/]test.zip!/test.xml> but
was:<zip:file://[]test.zip!/test.xml>
at junit.framework.Assert.assertEquals(Assert.java:81)
at
org.apache.cocoon.components.source.impl.ZipSourceTestCase.testURIHandling(ZipSourceTestCase.java:45)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Code freeze?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> Can anybody confirm this or is it a problem with my environment
> (although I deleted my local repo, then entered svn up, mvn clean install)?
Reinhard, I tried to build Cocoon with empty Maven local repo and results are the same: everything
works just fine. Are you sure there is no old junk somewhere?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Code freeze?
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Hi,
>
> I forgot that Reinhard asked us for code freeze from 18 to 21 of September
> and checked few things in.
>
> Reinhard, could you confirm that you are going to make a release so we will
> know that committs are rather not allowed these days?
Yes, I can do it but currently the tests don't run through and the samples don't
work. http://localhost:8888/samples/ returns xml and e.g.
http://localhost:8888/samples/forms/ causes an exception:
java.net.MalformedURLException: Unknown block name template in block context uri
blockcontext:/template/sitemap.xmap
at
org.apache.cocoon.components.source.impl.BlockContextSourceFactory.getSource(BlockContextSourceFactory.java:78)
at
org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:152)
at
org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:182)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.createChildProcessor(TreeProcessor.java:167)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.getProcessor(MountNode.java:141)
and the console shows
blockcontext:/template/sitemap.xmap
java.lang.IllegalStateException: Committed
at org.mortbay.jetty.Response.resetBuffer(Response.java:855)
at org.mortbay.jetty.Response.reset(Response.java:834)
at
org.apache.cocoon.servlet.RequestUtil.manageException(RequestUtil.java:120)
at
org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.ja
va:125)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja
va:1045)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Can anybody confirm this or is it a problem with my environment (although I
deleted my local repo, then entered svn up, mvn clean install)?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------