Hi.
I had the problem that I have to receive rows from a table
where the number of columns is variable (because the query is
variabe). For this reason it is useful to have the element names
the same for each column.
I introduced the tag-name attribute in esql:get-columns.
E.g. esql:get-columns
Hi Michael,
you can also use in your database xsp
row
esql:get-columns/
/row
this get all columns like
rowID1234/ID... /row
and in your xsl
xsl:template match=row
xsl:if test=position()=2
tr bgcolor=#ee
xsl:for-each select=*tdxsl:value-of select=local-name(.)//td
One quick question: Is this still a bug?
Carsten
-Ursprungliche Nachricht-
Von: giacomo [mailto:[EMAIL PROTECTED]]
Gesendet: Sonntag, 2. September 2001 12:20
An: Davanum Srinivas
Cc: [EMAIL PROTECTED]
Betreff: RE: [C2] cocoon:/ url's don't work from root to subsitemap
On Thu,
Hi Vadim,
did you find a better solution or should I take a look at it?
Carsten
-Ursprüngliche Nachricht-
Von: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 20. August 2001 23:59
An: Cocoon Developers
Betreff: Problem with handle-errors and sub-sitemap
Carsten,
Hi,
I am really impressed by the changes which took effect over the
last weeks. Great work!
But I am now wondering if we do the right thing. The C2.1 version
is now incompatible to 2.0. So I fear, that people will never use
the (final) 2.0 version and jump-start using 2.1 as they otherwise
Hi,
About the discussion about context-relative path:
Is it allowed to acces from one servlet-context a jsp-file
residing in some other servlet-context?
Is this against some security restriction, or servlet-api specs?
Perhaps some thoughts...
Yes, it's against restrictions, but I think
Team,
I think it's time to set a date for a Release Candidate for C2.0. How about 15th of
September?
We'll need to do an inventory of the differences between C2.0 and C2.1 and decide
which ones to
back-port to C2.0. If we can do this by end of this week, we can concentrate on
testing C2.0
Great idea!
+1 for the 15th of september
Do you have a list of differences?
Carsten
-Ursprungliche Nachricht-
Von: Davanum Srinivas [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 4. September 2001 13:47
An: [EMAIL PROTECTED]
Betreff: Re: [C2]: Changes between C2.0 and C2.1
Enke Michael wrote:
Hi.
I had the problem that I have to receive rows from a table
where the number of columns is variable (because the query is
variabe). For this reason it is useful to have the element names
the same for each column.
I introduced the tag-name attribute in
Thanks.
I never saw the position() function
in XML in a nutshell.
Are there specific resources available
to the XSL transformer which cocoon uses?
Michael
Klaus Bertram wrote:
Hi Michael,
you can also use in your database xsp
row
esql:get-columns/
/row
this get all columns
Bernhard,
Can you please do me a favor? Please follow these instructions to re-post the patch.
(It's real
hard to apply the changes by hand).
1. Get (checkout) the latest C2.1 from CVS.
2. Apply your changes.
3. Run cvs diff -u from the xml-cocoon2 directory.
4. Zip up the output out step #3
I'm not allowed to vote, but 09-15 sounds fine.
I would however like to call a vote for including root component managers
into C2.1. It is a very much needed feature for clustering and hosting of
multiple C2 webapps.
Patch for C2.1 is attached.
/LS
pcm21.zip
An again I missed something ;) Thanx for the hints...
I tried the HttpSessionBindingListener interface since this seems to be exactly
what I was looking for. This interface seems to be in API 2.2 and 2.3
so everything did look fine.
But after my User class implemented the
Bernhard Huber wrote:
Hi,
I'm currently enhancing org.apache.cocoon.generation.StatusGenerator
exposing all system properties, adding classloaders infos, and
all threads, and thread groups.
any ideas to add any other info?
Cache sizes
Torsten,
Did you use the Tomcat4.0 Servlet.JAR in xml-cocoon2\lib when you did the build?
Thanks,
dims
--- Torsten Curdt [EMAIL PROTECTED] wrote:
An again I missed something ;) Thanx for the hints...
I tried the HttpSessionBindingListener interface since this seems to be exactly
what I
Torsten,
Did you use the Tomcat4.0 Servlet.JAR in xml-cocoon2\lib when you did the build?
Yes. For cocoon as well as for our classes!
If there were a compatibility problem
shouldn't there be a different exception, anyway?
I just don't get it...
Any other ideas?
Thanks,
--
Torsten
---
Quoting Carsten Ziegeler [EMAIL PROTECTED]:
One quick question: Is this still a bug?
Yes, I haven't found the reason so far :/
Also, I don't know if it is a Catalina issue. If you point your browser to
http://localhost:8080/cocoon/ you get redirected to
http://localhost:8080/welcome. This
Hi Carsten,
Welcome back. Nope, I am deep in paid work right now,
and expect to be there for a month or so...
PS: About AW: [C2] cocoon:/ url's don't work from root to subsitemap,
I think the isue is still there - check http://localhost:8080/cocoon/sub/
Vadim
-Original Message-
No, it's not a Catalina issue. I can reproduce this with 3.2.
I traced it down to the invoke() method of the Manager. The
context url is now reset in the finally clause, so the
environment looses the information that it belongs
to a subsitemap.
I am currently testing a solution for this. Perhaps
Quoting Carsten Ziegeler [EMAIL PROTECTED]:
Hi,
I am really impressed by the changes which took effect over the
last weeks. Great work!
But I am now wondering if we do the right thing. The C2.1 version
is now incompatible to 2.0. So I fear, that people will never use
the (final) 2.0
Giacomo Pati wrote:
Quoting Carsten Ziegeler [EMAIL PROTECTED]:
Hi,
I am really impressed by the changes which took effect over the
last weeks. Great work!
But I am now wondering if we do the right thing. The C2.1 version
is now incompatible to 2.0. So I fear, that people
Does the entity resolver start correctly for everybody?
At the default verbosity level, you should see resolver
messages going to standard output.
It would be good to finalise it so that we can add it
to the C2.0 release. The only thing that i can see holding
it up, is a success report from a
Quoting Carsten Ziegeler [EMAIL PROTECTED]:
Great idea!
+1 for the 15th of september
Do you have a list of differences?
Carsten
I'm +1 as well but have some worries about the failing samples (IIRC).
Giacomo
-Ursprungliche Nachricht-
Von: Davanum Srinivas [mailto:[EMAIL
I do not see this problem. C2.0 + TC4.0b6.
Vadim
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 10:06 AM
To: [EMAIL PROTECTED]
Subject: AW: [C2] cocoon:/ url's don't work from root to subsitemap
No, it's not a Catalina
cziegeler01/09/04 07:44:13
Modified:src/org/apache/cocoon/components/source SitemapSource.java
src/org/apache/cocoon/environment AbstractEnvironment.java
src/org/apache/cocoon/environment/wrapper
EnvironmentWrapper.java
Ok, I found it...
For some strange reasons the error message from javac could not
be parsed correctly and the tokenizer threw an exception that
was not caught.
Now it is rethrown as a CompilerException. Now I can at least
see the error ;)
Patch attached.
Thanks!
--
Torsten
Index: Javac.java
Quoting David Crossley [EMAIL PROTECTED]:
Does the entity resolver start correctly for everybody?
At the default verbosity level, you should see resolver
messages going to standard output.
No! It is one of the samples I mentioned not working correctly as well as the
sitemap editor throwing
+1 from me! Port away!
-Original Message-
From: Giacomo Pati [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 04 September 2001 4:05 pm
To: [EMAIL PROTECTED]
Subject: Re: AW: [C2]: Changes between C2.0 and C2.1
Quoting Carsten Ziegeler [EMAIL PROTECTED]:
Giacomo Pati wrote:
Quoting Vadim Gritsenko [EMAIL PROTECTED]:
I do not see this problem. C2.0 + TC4.0b6.
I haven't had it with prior version but I can imagine that b8 has introduced
that. Also I don't have it with with TC-3.2.3-dev
Giacomo
Vadim
-Original Message-
From: Carsten Ziegeler
dims01/09/04 08:14:33
Modified:src/org/apache/cocoon/components/language/programming/java
Tag: cocoon_20_branch Javac.java
Log:
Patch from Torsten Curdt [EMAIL PROTECTED] for error message from javac
Revision ChangesPath
No
Giacomo wrote:
Quoting David Crossley [EMAIL PROTECTED]:
Does the entity resolver start correctly for everybody?
At the default verbosity level, you should see resolver
messages going to standard output.
No! It is one of the samples I mentioned not working correctly
as well as the
Vadim,
I changed your solution a little bit, could you please verify
if this is working (or is there an example I could test) ?
Carsten
-Ursprüngliche Nachricht-
Von: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 4. September 2001 16:00
An: [EMAIL PROTECTED]
Nope, it does not...
http://localhost:8080/cocoon/sub/xsl-cocoon
java.lang.NullPointerException
at
org.apache.cocoon.components.source.SitemapSource.toSAX(SitemapSource.java:296)
at
org.apache.cocoon.components.source.SitemapSource.getInputStream(SitemapSource.java:183)
Hi Konstantin, does the following file exist under tomcat home?
webapps\cocoon\WEB-INF\classes\CatalogManager.properties
Yes, I have such file there.
It should have been copied there by the build process and the
path to the default catalog automatically adjusted. If not, then
see the Build
For some reason Javac can't parse error message from java compiler. Add some debug
printouts before
line 137 and find out why parsing is failing.
at
org.apache.cocoon.components.language.programming.java.Javac.parseModernError(Javac.java:137)
Ok, now I got the real error
At 12:05 AM +1000 5/9/01, David Crossley wrote:
Does the entity resolver start correctly for everybody?
At the default verbosity level, you should see resolver
messages going to standard output.
It would be good to finalise it so that we can add it
to the C2.0 release. The only thing that i can
This is actually a different problem. If you look at the sub sitemap,
there is the following entry:
map:match pattern=xsl-cocoon
map:generate src=docs/hello-page.xml/
map:transform src=cocoon:/xsl-source/
map:serialize/
/map:match
Writing a test pipeline in the sub sitemap
Carsten,
Yes, it is working. Test case:
Page http://localhost:8080/cocoon/sub/generror should match
http://localhost:8080/cocoon/generror
(they both are generated by main sitemap handler).
And http://localhost:8080/cocoon/sub/does-not-exist should present customized (by
subsitemap)
page.
Did you try to set the correct catalog path in the
CatalogManager.properties file (in WEB-INF/classes),
it should read something like ${install.war}/
After changing this manually, it works. Without changing
I get exactly the same error as you did.
Carsten
-Ursprungliche Nachricht-
Hmm, it's not working here:
- Page http://localhost:8080/cocoon/sub/generror is the servlet error page!
- Page http://localhost:8080/cocoon/generror is the correct one.
- Page http://localhost:8080/cocoon/sub/does-not-exist is served by the
subsitemap.
Carsten
-Ursprüngliche
Oops! I need to checkin small change to main sitemap, sorry!
Here it is:
Index: sitemap.xmap
===
RCS file: /home/cvs/xml-cocoon2/webapp/sitemap.xmap,v
retrieving revision 1.44
diff -u -r1.44 sitemap.xmap
--- sitemap.xmap
That's weird :-\
Why HTTP works and cocoon: does not?
map:transform src=http://localhost:8080/cocoon/sub/xsl-source/
Vadim
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 11:43 AM
To: [EMAIL PROTECTED]
Subject: AW: cvs commit:
Hi Jeremy, i would guess that you have the same problem
as did Konstantin. That is the expected error message when the
entity resolver has no mapping for the requested entity.
The entity resolver probably did not configure itself because it could
not find the properties file at Cocoon startup.
+100 for LogKitManager. This is a major LogKit enhancement that is
really useful in production environments. Thanks for it, Giacomo.
+1 also for porting the Source interface changes, since they impact the
core classes. IMO, it's better to have the same core in 2.0 and 2.1
while 2.0 isn't
Hi Carsten, you should not need to set the catalogs property
manually. It should be automatically set by the build process
to be full pathname to webapps/cocoon/resources/entities/catalog
Did you use build -Dinstall.war=$TOMCAT_HOME/webapps
regards, David
Date: Tue, 4 Sep 2001 17:48:49 +0200
At 5:48 PM +0200 4/9/01, Carsten Ziegeler wrote:
Did you try to set the correct catalog path in the
CatalogManager.properties file (in WEB-INF/classes),
it should read something like ${install.war}/
After changing this manually, it works. Without changing
I get exactly the same error as you
Carsten,
This problem happens because toSAX is called twice, from:
java.lang.Exception: In toSAX
at
org.apache.cocoon.components.source.SitemapSource.toSAX(SitemapSource.java:288)
at
org.apache.cocoon.components.source.SitemapSource.getInputStream(SitemapSource.java:183)
+1 from here.
Vadim
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 12:08 PM
To: [EMAIL PROTECTED]
Subject: Re: [C2]: Changes between C2.0 and C2.1
+100 for LogKitManager. This is a major LogKit enhancement that is
really
Jeremy,
Do not combine these tasks!
And, do not do install if you ever used build.sh without
-Dinstall.war=$TOMCAT_HOME/webapps
parameter!
Try this:
./build.sh clean
./build.sh -Dinclude.webapp.libs=yes -Dinstall.war=$TOMCAT_HOME/webapps install
PS Need to write clearly in doc that before
Jeremy,
Please try this sequence.
cd $TARDIS/Checkouts/xml-cocoon2
./build.sh clean
./build.sh -Dinclude.webapp.libs=yes -Dinstall.war=$TOMCAT_HOME/webapps install
cd $TOMCAT_HOME/bin
./startup.sh
Thanks,
dims
--- Jeremy Quinn [EMAIL PROTECTED] wrote:
At 5:48 PM +0200 4/9/01, Carsten
dims01/09/04 09:36:24
Modified:webapp sitemap.xmap
Log:
patch from Vadim Gritsenko [EMAIL PROTECTED] for Problem with handle-errors
and sub-sitemap
Revision ChangesPath
1.47 +5 -0 xml-cocoon2/webapp/sitemap.xmap
Index: sitemap.xmap
Thanks Vadim, i was just writing the same email to Jeremy.
However, are you sure that build clean is needed.
I just do the one-line build command that you have shown
and all is well.
David
Vadim wrote:
Jeremy,
Do not combine these tasks!
And, do not do install if you ever used build.sh
At 12:27 PM -0400 4/9/01, Vadim Gritsenko wrote:
Jeremy,
Do not combine these tasks!
And, do not do install if you ever used build.sh without
-Dinstall.war=$TOMCAT_HOME/webapps
parameter!
Try this:
./build.sh clean
./build.sh -Dinclude.webapp.libs=yes -Dinstall.war=$TOMCAT_HOME/webapps
install
Hello, I was wondering if it was possible to specify the context directory
independently of the sitemap file when mounting a sub-sitemap. After some
digging around, it doesn't seem possible, but perhaps I missed something
obvious?
Would it be useful to add this flexibility? I can see two
If your ever used build without specifying install dir - then yes, it's required,
because on second run Ant will skip this step:
copy todir=${build.war} filtering=on
in
target name=copy-webapp depends=prepare
target, but it needs to be executed with initialized variable install.war.
Vadim
I'm getting the following compile error in the latest CVS of 2.1:
[javac] /Users/stuart/Documents/OpenSource/xml-cocoon2+/build/cocoon/
src/org/apache/cocoon/environment/AbstractEnvironment.java:157: Wrong
number of arguments in method.
[javac]
Team,
Here are the significant differences. Please go ahead and add your +1/-1/0 to each
item. If i
have missed anything, please add it to the bottom of the list with your vote.
1) XML:DB Generators - There are two generators in C2.1 for dealing with data from
XML:DB data
sources
2) FOP
On Tue, 4 Sep 2001, Vadim Gritsenko wrote:
Ok, I'll port te LogKit management over to 2.0 this week.
Giacomo
+1 from here.
Vadim
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 12:08 PM
To: [EMAIL PROTECTED]
Subject:
Hi Dims, it seems that there is too much variability
in the build process. It appears that we may not be
able to rely on them using the build option
-Dinstall.war=$TOMCAT_HOME/webapps
I am sure that there would be a way to load the
default catalog via our Cocoon classes at
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
cziegeler01/09/04 23:10:49
Modified:src/org/apache/cocoon/environment AbstractEnvironment.java
Log:
Oops, forget to check this in (I still need more vacation...)
Revision ChangesPath
1.21 +9 -2
62 matches
Mail list logo
