MIDI .... wow!!!
I just updated Cocoon, and took a wizz around the samples In the MIDI section, I clicked on A Short MIDI File, and it played in my browser =:-() I NEARLY DROPPED MY CHIPS ! Well done!!! It reminds me of something I never got to contribute to Cocoon 1, I had made a set of XSLT templates that converted Stefano's Slides to a SMIL movie, it just about worked, but tended to crash the bejesus out of QuickTime :( regards Jeremy
cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/offline ant.xml bean.xml book.xml cli.xml index.xml
upayavira2003/08/07 03:39:42
Modified:src/documentation/xdocs/userdocs book.xml
Added: src/documentation/xdocs/userdocs/offline ant.xml bean.xml
book.xml cli.xml index.xml
Log:
Documentation for the CLI and Bean
Revision ChangesPath
1.5 +3 -0 cocoon-2.1/src/documentation/xdocs/userdocs/book.xml
Index: book.xml
===
RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/book.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- book.xml 1 Aug 2003 09:41:23 - 1.4
+++ book.xml 7 Aug 2003 10:39:42 - 1.5
@@ -31,6 +31,9 @@
menu-item label=XSP href=xsp/index.html/
/menu
+ menu label=Offline Generation
+menu-item label=Offline Generation href=offline/index.html/
+ /menu
/book
1.1 cocoon-2.1/src/documentation/xdocs/userdocs/offline/ant.xml
Index: ant.xml
===
?xml version=1.0 encoding=UTF-8?
!DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.0//EN
../../dtd/document-v10.dtd
document
header
titleOffline Page Generation with Apache Ant/title
version0.9/version
typeTechnical document/type
authorsperson name=Upayavira email=[EMAIL PROTECTED]/
/authors
abstractThis document explains how to use Cocoon to generate offline pages
and sites with Apache Ant./abstract
/header
body
s1 title=Overview
pApache Ant can be used to start Cocoon in its Offline mode. Whilst
a specific
Cocoon Ant task is planned, at present it can be invoked by starting the
command line interface using a standard Java task.
/p
/s1
s1 title=Sample Ant Task
pA sample Ant task would be as follows:/p
source
![CDATA[
java classname=org.apache.cocoon.Main fork=true
dir=${build.context}
failonerror=true maxmemory=128m
arg value=-xcli.xconf/
arg value=index.html/
classpath
path refid=classpath/
fileset dir=${build.dir}
include name=*.jar/
/fileset
pathelement location=${tools.jar}/
pathelement location=${build.context}/WEB-INF/classes/
/classpath
/java
]]/source
pThis makes use of the Cocoon Command Line Interface's xconf configuration
file. See
link href=cli.htmlcommand line/link page for details about how to
use this file./p
/s1
/body
/document
1.1 cocoon-2.1/src/documentation/xdocs/userdocs/offline/bean.xml
Index: bean.xml
===
?xml version=1.0 encoding=UTF-8?
!DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.0//EN
../../dtd/document-v10.dtd
document
header
titleThe Cocoon Bean/title
version0.9/version
typeTechnical document/type
authorsperson name=Upayavira email=[EMAIL PROTECTED]/
/authors
abstractThis document details the basics of using the Cocoon
bean./abstract
/header
body
s1 title=Overview
pThe Cocoon Bean provides a Java programmatic interface for offline
page and site generation
with Apache Cocoon.
/p
/s1
s1 title=Details
pThe Cocoon Bean forms the core of, and is used by the Cocoon Command Line
Interface
(CLI)./p
pTo find more about using the bean, look at the code for the CLI, which can
be found
in the Cocoon codebase in codesrc/java/code, in the class
codeorg.apache.cocoon.Main/code./p
noteWhilst the Cocoon Bean works, it is still under development, and
therefore its API
must be considered unstable. Return to this page in future versions to
see what has
changed./note
/s1
/body
/document
1.1 cocoon-2.1/src/documentation/xdocs/userdocs/offline/book.xml
Index: book.xml
===
?xml version=1.0?
!DOCTYPE book PUBLIC -//APACHE//DTD Cocoon Documentation Book V1.0//EN
../../dtd/book-cocoon-v10.dtd
book software=Apache Cocoon
title=Apache Cocoon User Documentation - Concepts
copyright=@year@ The Apache Software Foundation
menu label=Navigation
menu-item label=Main href=../../index.html/
menu-item label=User Documentation href=../index.html/
/menu
menu label=Offline
menu-item label=Overview href=index.html/
menu-item label=Command Line href=cli.html/
menu-item label=Ant href=ant.html/
menu-item label=Cocoon Bean
RE: [RT] Starting 2.2
Sylvain Wallez wrote: I don't clearly understand what you want to achieve... It's plain simple :) Now, the usual way would be to create a new repository (cocoon-2.2) and copy everything from 2.1 in there. Then we have two branches which require syncing which can be a real pita. My approach is to sync as less as possible by only copying those parts that we will change in the near future. And this should be the core sources, but not the documentation or any block. As I expect that we will end in a different structure when we have real blocks (e.g. perhaps a blocks repository etc.) this would be imho an easier migration strategy. Does this make sense? Carsten
Re: [RT] Views for readers
On 14 Aug 2003 at 15:34, Bertrand Delacretaz wrote:
I find this more understandable (but dunno about implementation):
!-- if reader is executed, the rest is not --
map:read src=docs/{1}.doc unless-view=wordToXml/
map:generate src=docs/{1}.doc type=wordToXml/
map:transform...
Simplifying further:
map:read src=docs/{1}.doc view-generator=wordToXml/
Surely that'd do it?
Regards, Upayavira
Re: [RT] Starting 2.2
On 13/8/03 16:37, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying we start a new major version (2.2). (if the answer is yes, we can talk about the layout). YES! :-) As I have few [RT]s on my own! :-) :-) :-) Pier
Re: Washington D.C. Area (and Baltimore) Cocoon Pre-Release party
Berin Loritsch wrote: Ryan Hoegg wrote: Well, I wouldn't exactly call it a /party/ but, This Saturday, August 9, at 10:00am EDT. anyone and everyone is invited to join us at the Starbucks in Silver Spring (which unfortunately does *not* have wi-fi) here: Alas, something close by and I can't come My company is having a picnic and I already RSVP'd. Shoot, I was hoping to have you there. Hopefully this won't be the last - a great future session would be all of us picking your brain about Avalon. Geoff
Using cocoon: source in xsl:imports
I'm seeing an error when I use xsl:imports containing cocoon: sources. During processing of the import sources, ResourceReader.processStream() calls: response.setHeader(Content-Length, Long.toString(contentLength)); But the response referenced is the _original_ (external) http request, not some internal one. The result is that if cocoon:source has a length that is less than that of the request, the response is truncated. Has anyone seen this? Bugzilla didn't have anything appropriate. The handling of sources in XSLTProcessorImpl is fairly new code, right? Should it be doing something more than just: xslSource = resolver.resolveURI(href); like consing up a request/response? Or is the problem really just that setHeader shouldn't be called (unconditionally)? Thanks, Phil P.s.: This is on cocoon-2.1m3-dev running with tomcat under linux, solaris, and freebsd.
RE: How to use input modules in flow
From: news [mailto:[EMAIL PROTECTED] Hi Cocoon developers, I just updated from 2.1-M1 to 2.1 and noticed that the inputModuleGetAttribute() function is no longer supported. Yep legacy support for cocoon.input(..) and cocoon.act(..) has not been implemented yet The purpose of the input module call was to obtain an object from a custom Avalon component. The FOM does not provide access to input modules, does it? So, what is the recommended way to get an object from an Avalon component? var myComp = cocoon.getComponent(myComp.ROLE); var myObj = myComp.mymethod(); Cheers, Reinhard
Re: cocoon + MS SQL Server problem
Has anybody asked them for releasing a new version? Joerg Frank Taffelt wrote: Hi, i had the same problems with jtds jdbc driver and ms sql server (and it was driving me crazy). The problem described shortly: The sql server closes connections and the jdbc driver throws an exception. This exception is not recognized by the jdbc pooling component. The connection gets lost, but the jdbc pool doesn't know it. This occurs till your max connection number is exceed and then your application hangs when requesting a datasource from the pool. A solution is to upgrade your excalibure datasource to a recent version. Look under http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/datasource/src/java/org/a pache/avalon/excalibur/datasource/AbstractJdbcConnection.java revision 1.30 fixes this bug. hth, Frank
Re: [RT] Views for readers
Bertrand Delacretaz wrote:
Le Jeudi, 14 aoû 2003, à 15:24 Europe/Zurich, Sylvain Wallez a écrit :
...But what if we write it the other way around :
map:read src=docs/{1}.doc
map:generate src=docs/{1}.doc type=wordToXml label=content/
/map:read
I find this more understandable (but dunno about implementation):
!-- if reader is executed, the rest is not --
map:read src=docs/{1}.doc unless-view=wordToXml/
map:generate src=docs/{1}.doc type=wordToXml/
map:transform...
Interesting. This is looks like a more compact notation for the
view-selector I was thinking of at first. We're leaving the RT world...
But shouldn't we keep labels that are already used into pipelines ? E.g :
map:read src=docs/{1}.doc label=raw, xdoc/
map:generate src=docs/{1}.doc type=word2xml label=raw/
map:transform src=xword2xdoc.xsl label=xdoc/
The label on the reader would skip the reader if the requested view
corresponds to one of these labels. Now should this be named label or
unless-label ?
Ah, and this is very easily implementable ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Views for readers
Jeff Turner wrote:
On Wed, Aug 13, 2003 at 12:02:04PM +0200, Sylvain Wallez wrote:
Frederic's question about search engine integration led me to
questioning myself at how Cocoon's Lucene integration could be able to
transparently index Word PDF documents along with XML-produced documents.
There exists some text-extraction libraries for Word PDF (e.g.
http://www.textmining.org/). Now how can we integrate this as
transparently as possible in Cocoon's search functionnality ?
The Lucene indexer crawls a website and asks for a particular view
(content) which is used to fill the index. But Word and PDF documents
being binary files, they're handled by a map:read statement, which
does not handle views. On the other hand, this use case shows that
having views on binary content may make sense : the normal requests
just sends back the binary content, while a view can use a text/XML
extraction on these binary files.
So the question is : how could views be plugged to readers ? I must say
that I don't have an answer, as views contain transformers and a
serializer, but no generator. So how could we express in the sitemap
that a particular view on a reader should replace that reader by a
particular generator ? Or should this go through some special readers
that could also act as generators ?
Or maybe these are silly thoughts and we should use a map:select
directing to a map:read or map:generate depending on the view. But
this introduces explicit view management in the pipelines, which doesn't
seem nice to me.
Solution: strongly typed pipelines! :)
Imagine if, at each node in the sitemap, we knew what type of content we
were dealing with (usually some flavour of XML). Then we could write a
single view that behaves differently depending on the _type_ of data:
map:view name=indexablecontent from-position=first
map:select type=xml-type
map:when test=docbook
map:transform src=docbook2whatever.xsl/
/map:when
map:when test=tei
map:transform src=tei2whatever.xsl/
/map:when
map:when test=msword
map:transform src=word2whatever.xsl/
/map:when
/map:select
/map:view
Ah, ok, the strongly type pipelines are a different wording for
content-aware selectors !
So http://mycocoonsite.com/foo.doc?cocoon_view=indexablecontent would
return XML representing the content of the .doc file.
I described the same thing in a mail with subject 'Type-aware Views (Re:
Link view goodness)'. Same need, different context, same proposed
solution.
Not exactly : the use case here is that we have a binary file which is
normally sent as is to the browser using a reader. It is _not_ parsed as
an XML stream. So we can't attach a view to these kinds of URLs since
views provide a different _ending_ to a pipeline, meaning there must
exist at least a generator and optionnaly one or more transformers at
the point where processing is directed to the view.
So even content-aware selectors don't solve this problem...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: I18nTransformer : differences between 2.1 and 2.0
Sylvain Wallez wrote: BTW, on my way to support legacy, I also supported non-namespaced attributes on i18n: elements. This means one can write i18n:text key=blah instead of i18n:text i18n:key=blah which always seemed cumbersome to me. Common sense tells me that i18n:text key=blah should be the mainstream syntax, and not a legacy syntax... Vadim I'll commit this, so that it can go into 2.1.1... Sylvain
Flow + Hibernate sample offer
Dear All, I have just been given permission by my client inIVA.org to open source the application I have been writing for them for editing their SQL dataset (their Archive on http://www.iniva.org/archive). My hope is that this could constitute a sample of working with FlowScript + JX + Hibernate. It would not be otherwise useful to anyone, because it all depends on inIVA's copious data (which would obviously not be supplied). I would either supply the App as a .gzip download, or maybe from the private CVS I use. I imagine I would put a page on the wiki to alert people of the existence of the sample, with a link to the download. So, some questions what do you think, is this a good idea? should/can I add the Apache license to it? does it matter that I used my own form-framework, not Woody, JXForm etc.? would anyone care to peer-review it (to check I have used good practises) before release? should I publish it with a test dataset, so the jUnit tests work (if so, how)? are there any other issues I have not thought of? Thanks for your feedback regards Jeremy
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/transformation I18nTransformer.java
sylvain 2003/08/13 10:12:25
Modified:.status.xml
src/java/org/apache/cocoon/transformation
I18nTransformer.java
Log:
Ensure legacy behaviour of the I18nTransformer
Revision ChangesPath
1.119 +6 -1 cocoon-2.1/status.xml
Index: status.xml
===
RCS file: /home/cvs/cocoon-2.1/status.xml,v
retrieving revision 1.118
retrieving revision 1.119
diff -u -r1.118 -r1.119
--- status.xml13 Aug 2003 08:54:44 - 1.118
+++ status.xml13 Aug 2003 17:12:25 - 1.119
@@ -202,6 +202,11 @@
changes
release version=@version@ date=@date@
+ action dev=SW type=fix
+ Update the I18nTransformer so that it also accepts the 2.0 namespace. This
ensures backwards compatibility
+ for 2.0 applications. Additionally, attributes on i18n: elements can now be
in the default namespace (meaning
+ we can now write lt;i8n:text key=foogt; instead of lt;i18n:text
i18n:key=foogt;)
+ /action
action dev=BRD type=fix
Fix in the SVG serializer: if setDocumentLocator wasn't called on the
serializer (which can happen if you have e.g. an XSLT transformer in the
1.12 +41 -13
cocoon-2.1/src/java/org/apache/cocoon/transformation/I18nTransformer.java
Index: I18nTransformer.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/transformation/I18nTransformer.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- I18nTransformer.java 6 Aug 2003 14:50:11 - 1.11
+++ I18nTransformer.java 13 Aug 2003 17:12:25 - 1.12
@@ -252,6 +252,12 @@
public static final String I18N_OLD_NAMESPACE_URI =
http://apache.org/cocoon/i18n/2.0;;
+/**
+ * Did we already encountered a old namespace ? This is static to ensure that
+ * the associated message will be logged only once.
+ */
+private static boolean deprecationFound = false;
+
//
// i18n elements
//
@@ -1127,15 +1133,19 @@
strBuffer = null;
}
+// Process start element event
if (I18N_OLD_NAMESPACE_URI.equals(uri)) {
-this.getLogger().error(The namespace
- + I18N_OLD_NAMESPACE_URI
- + for i18n is not supported any more, use:
- + I18N_NAMESPACE_URI);
-}
+if (!deprecationFound) {
+deprecationFound = true;
+this.getLogger().warn(The namespace '
+ + I18N_OLD_NAMESPACE_URI
+ + ' for i18n is not supported any more, use:
'
+ + I18N_NAMESPACE_URI + ');
+}
+debug(Starting deprecated i18n element: + name);
+startI18NElement(name, attr);
-// Process start element event
-if (I18N_NAMESPACE_URI.equals(uri)) {
+} else if (I18N_NAMESPACE_URI.equals(uri)) {
debug(Starting i18n element: + name);
startI18NElement(name, attr);
} else { // We have a non i18n element event
@@ -1164,7 +1174,7 @@
strBuffer = null;
}
-if (I18N_NAMESPACE_URI.equals(uri)) {
+if (I18N_NAMESPACE_URI.equals(uri) || I18N_OLD_NAMESPACE_URI.equals(uri)) {
endI18NElement(name);
} else if (current_state == STATE_INSIDE_PARAM) {
param_recorder.endElement(uri, name, raw);
@@ -1221,8 +1231,22 @@
prev_state = current_state;
current_state = STATE_INSIDE_TEXT;
-current_key = attr.getValue(I18N_NAMESPACE_URI, I18N_KEY_ATTRIBUTE);
-currentCatalogueId = attr.getValue(I18N_NAMESPACE_URI,
I18N_CATALOGUE_ATTRIBUTE);
+
+current_key = attr.getValue(, I18N_KEY_ATTRIBUTE);
+if (current_key == null) {
+// Try the namespaced attribute
+current_key = attr.getValue(I18N_NAMESPACE_URI, I18N_KEY_ATTRIBUTE);
+if (current_key == null) {
+// Try the old namespace
+current_key = attr.getValue(I18N_OLD_NAMESPACE_URI,
I18N_KEY_ATTRIBUTE);
+}
+}
+
+currentCatalogueId = attr.getValue(, I18N_CATALOGUE_ATTRIBUTE);
+if (currentCatalogueId == null) {
+// Try the namespaced attribute
+currentCatalogueId = attr.getValue(I18N_NAMESPACE_URI,
I18N_CATALOGUE_ATTRIBUTE);
+}
if (prev_state != STATE_INSIDE_PARAM)
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: ... Hmm, yes, but we could start the 2.2 repo with the current core source, so we have a starting point. I expect that blocks will require longer discussions and I personally don't want to wait with 2.2 for this. I'm wondering. What are you personally planning which requires 2.2 repo and can not be done in the current repo? /me feels that you are trying to solve some problem without stating what the problem is Vadim
Re: Request URI in FOM [was: Re: How to use input modules in flow]
What makes it more special than getRequestMethod(), the hostname, or reading cookie data? Those can be gathered in the sitemap and passed as parameters too can't they? Not arguing, just trying to figure out the distinction. - Miles Elam The FOM request does not contain a getRequestURI() method. In the wiki I've read that URI handling is not supported because this is not necessary. How should the request URI be obtained? Your application should work without a certain uri ... If your need it you can work around it using an input module and pass its value to the flow using map:parameter.
Re: [RT] Views for readers
Le Jeudi, 14 aoû 2003, à 15:24 Europe/Zurich, Sylvain Wallez a écrit :
...But what if we write it the other way around :
map:read src=docs/{1}.doc
map:generate src=docs/{1}.doc type=wordToXml label=content/
/map:read
I find this more understandable (but dunno about implementation):
!-- if reader is executed, the rest is not --
map:read src=docs/{1}.doc unless-view=wordToXml/
map:generate src=docs/{1}.doc type=wordToXml/
map:transform...
-Bertrand
Re: Official i18n namespace (was Re: I18nTransformer : differencesbetween 2.1 and 2.0)
On Wed, 2003-08-13 at 22:55, Sylvain Wallez wrote: Sylvain Wallez wrote: Bruno Dumon wrote: On Wed, 2003-08-13 at 18:15, Sylvain Wallez wrote: Hi mates, I'm currently porting an i18nized application from 2.0 to 2.1 and hit an incompatible change due to the namespace change between the two versions. Browsing the docs, I can't see any change in the i18n markup. The changes seem only to be in the component's configuration which now accept several catalogues. Did I miss some other important changes (I mean incompatible ones) ? We had this discussion some time ago, and nobody seemed to remember why it changed, but it changed. There have been features added but I don't know if (and don't think that) compatibility of existing features was broken. If not, why doesn't this transformer accept a legacy mode with the old namespace and configuration ? This would allow for immediate back compatibility. Seems ok to me. If we tried this before the 2.1 release I would even have been in favor of dropping the 2.1 namespace alltogether, but now it's a bit too late for that. Yep, too late. Too bad :-( BTW, the old sitemap configuration (before multi-catalogue support) is still supported. I just finished legacy support in the I18nTransformer, and the old application seems to run just fine. This makes me think... What about reverting the official i18n namespace to .../i18n/2.0 as it was before ? This would allow warning-less compatibility of 2.0 applications and avoid breaking lots of docs, books, articles, etc. Of course, we should provide legacy support for the ../i18n/2.1 namespace as it has been released (damn, wish I did this a few days before). What do you think ? How about making them synonyms, i.e. giving them an equals status? The new namespace is already in Cocoon 2.1 for a very long time, and I think many people started to depend on it. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Official i18n namespace (was Re: I18nTransformer : differences between2.1 and 2.0)
Sylvain Wallez wrote:
Bruno Dumon wrote:
On Wed, 2003-08-13 at 18:15, Sylvain Wallez wrote:
Hi mates,
I'm currently porting an i18nized application from 2.0 to 2.1 and
hit an incompatible change due to the namespace change between the
two versions.
Browsing the docs, I can't see any change in the i18n markup. The
changes seem only to be in the component's configuration which now
accept several catalogues.
Did I miss some other important changes (I mean incompatible ones) ?
We had this discussion some time ago, and nobody seemed to remember
why it changed, but it changed.
There have been features added but I don't know if (and don't think
that) compatibility of existing features was broken.
If not, why doesn't this transformer accept a legacy mode with the
old namespace and configuration ? This would allow for immediate
back compatibility.
Seems ok to me. If we tried this before the 2.1 release I would even
have been in favor of dropping the 2.1 namespace alltogether, but now
it's a bit too late for that.
Yep, too late. Too bad :-(
BTW, the old sitemap configuration (before multi-catalogue support)
is still supported.
I just finished legacy support in the I18nTransformer, and the old
application seems to run just fine.
This makes me think...
What about reverting the official i18n namespace to .../i18n/2.0 as
it was before ? This would allow warning-less compatibility of 2.0
applications and avoid breaking lots of docs, books, articles, etc.
Of course, we should provide legacy support for the ../i18n/2.1
namespace as it has been released (damn, wish I did this a few days before).
What do you think ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Views for readers
Miles Elam wrote:
Ummm... Quick question: What are the use cases for this that are not
handled by existing methods? I mean, couldn't this be handled with an
(as-yet unwritten) action?
Matcher *does* exist:
map:match pattern=*.doc
map:match type=wildcard-request-parameter pattern=content
map:parameter name=parameter-name value=cocoon-view/
map:generate type=word2xml src={../1}.doc/
!-- complete the pipeline --
/map:match
map:read src={1}.doc/
/map:match
snip/
Vadim
Re: SQLTransformer mod to optionally preserve case of column names
Can you add this to bugzilla, so it won't get lost? Joerg Steve Schwarz wrote: Hi again, Sorry for the thrash, I had a paste error in the diff I posted - here is the correct one Regards Steve diff -u SQLTransformer.java.old SQLTransformer.java ...
Re: [RT] Views for readers
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le Jeudi, 14 aoû 2003, à 15:53 Europe/Zurich, Sylvain Wallez a écrit :
...But shouldn't we keep labels that are already used into pipelines
? E.g :
map:read src=docs/{1}.doc label=raw, xdoc/
map:generate src=docs/{1}.doc type=word2xml label=raw/
map:transform src=xword2xdoc.xsl label=xdoc/
If it's this way I'd prefer unless-label in map:read to make it clear.
Or maybe
map:read src=docs/{1}.doc unless-label=*/
would do, meaning use this unless any views are requested
(and * would be the only allowed value).
Ah, and this is very easily implementable ;-)
Quickquick, do it before the FS police hears us ;-)
Seriously, I find this useful for indexing and other purposes
(gettting meta-information about binary files, images, etc for example).
Me too. But since is a change in the sitemap syntax, we should have a
vote on this.
Any other proposal or opinion on this subject before we start a vote ?
Can't you just enable generators in map:view in case when view starts
with reader?
Vadim
Re: converting FlowApp to new FOM
Jeremy Quinn wrote:
snip/
I just converted all my classes to use the
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.FOM_Request.
jsFunction_getParameter (String name) method, and they appear to be
working.
Would it be 'safer' to pass the FOM_Cocoon object itself, and unwrap
the org.apache.cocoon.environment.Request from it as Ugo appears to
have done?
Yep. Furthermore, you don't have to unwrap the request, since
FOM_Cocoon provides a getRequest() method that gives access to the
_real_ o.a.c.environment.Request object.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Accessing public static final constants from JXTemplate
On Friday, August 8, 2003, at 08:36 PM, Hunsberger, Peter wrote: Jeremy Quinn [EMAIL PROTECTED] writes: OK, thats a bit clearer ;) But I still don't understand how I would go about using these constants from inside JXTemplate XPath expressions. I don't use JXTemplate, but I assume you've got a normal Cocoon generated input file and a Cocoon transform? IF so, you aggregate the XML file with the original source (as a simple File source) and then you can use Xpath to access it's contents as well as the contents you where previously using Xpath on... No, I am using the JXTemplate Generator. Thanks anyway regards Jeremy
Re: [OT] should I laugh or cry?
I test stuff on a AMD 1ghz 256MB Ram (Laptop Tho) With WIN XP Build takes 43 minutes from fresh cvs :( I thought it was normal .. Heh heh JD Daniels Geoff Howard wrote: BUILD SUCCESSFUL Total time: 44 minutes 8 seconds man, what are you building on, a p166? :) brag my athlon xp 2400 takes 5 minutes for a full build from a fresh cvs checkout /brag tony - This message was sent using Solar Winds Online Webmail. http://www.solarwinds.com/
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/environment/commandlineLinkSamplingEnvironment.java
[EMAIL PROTECTED] wrote:
upayavira2003/08/10 12:58:09
Modified:src/java/org/apache/cocoon/environment/commandline
LinkSamplingEnvironment.java
Log:
Make the CLI only report unique link count in a page (previously it reported every link, including repeated links, when using link view)
Should mean that link view and linkGathering both report the same number of links in a page
Why not using a Set then? See patch as attachment.
Joerg
Index: LinkSamplingEnvironment.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/environment/commandline/LinkSamplingEnvironment.java,v
retrieving revision 1.3
diff -u -r1.3 LinkSamplingEnvironment.java
--- LinkSamplingEnvironment.java10 Aug 2003 19:58:09 - 1.3
+++ LinkSamplingEnvironment.java11 Aug 2003 23:12:29 -
@@ -50,16 +50,21 @@
*/
package org.apache.cocoon.environment.commandline;
-import org.apache.avalon.framework.logger.Logger;
-
-import org.apache.cocoon.Constants;
-import org.apache.cocoon.environment.ObjectModelHelper;
-
-import java.io.*;
+import java.io.BufferedReader;
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.IOException;
+import java.io.InputStreamReader;
import java.net.MalformedURLException;
-import java.util.ArrayList;
import java.util.Collection;
+import java.util.HashSet;
import java.util.Map;
+import java.util.Set;
+
+import org.apache.avalon.framework.logger.Logger;
+import org.apache.cocoon.Constants;
+import org.apache.cocoon.environment.ObjectModelHelper;
/**
* This environment is sample the links of the resource.
@@ -101,7 +106,7 @@
* Indicates if other links are present.
*/
public Collection getLinks() throws IOException {
-ArrayList list = new ArrayList();
+Set set = new HashSet();
if (!skip) {
BufferedReader buffer = null;
try {
@@ -109,14 +114,9 @@
new InputStreamReader(
new ByteArrayInputStream(
((ByteArrayOutputStream)
super.outputStream).toByteArray(;
-
-while (true) {
-String line = buffer.readLine();
-if (line == null)
-break;
-if (!list.contains(line)) {
-list.add(line);
-}
+String line;
+while ((line = buffer.readLine()) != null) {
+set.add(line);
}
} finally {
// explictly close the input
@@ -129,6 +129,6 @@
}
}
}
-return list;
+return set;
}
}
Re: java.lang.NoSuchMethodError again?
[EMAIL PROTECTED] wrote: I build from latest CVS, copy contents of .../build/webapp into my [TOMCAT]/webapps/cocoon directory, delete [TOMCAT]/work/localhost/cocoon and (re)start tomcat. Tomcat welcome page appears but when I try to get localhost:8080/cocoon/ I receive a blank page Additional info: everything works when I build from cocoon-2.1rc1 binary. Something about CVS? Michael, I just did a full CVS-pulldown/build/deploy the other day, and I got the blank page, then I remembered about the 'endorsed libs' problem. http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem This could be your problem Tony
cvs commit: cocoon-2.1 blocks.properties
reinhard2003/08/07 01:56:39 Modified:.blocks.properties Log: - add deprecated section Revision ChangesPath 1.25 +9 -1 cocoon-2.1/blocks.properties Index: blocks.properties === RCS file: /home/cvs/cocoon-2.1/blocks.properties,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- blocks.properties 7 Aug 2003 07:27:01 - 1.24 +++ blocks.properties 7 Aug 2003 08:56:39 - 1.25 @@ -43,7 +43,6 @@ #exclude.block.velocity=true #exclude.block.web3=true #exclude.block.xmldb=true -#exclude.block.xmlform=true # Unstable blocks -- @@ -73,3 +72,12 @@ #exclude.block.taglib=true #exclude.block.webdav=true #exclude.block.woody=true + + + +# Deprecated blocks + +# Although these blocks are stable they have been deprecated in favour of other +# blocks. + +#exclude.block.xmlform=true \ No newline at end of file
cvs commit: cocoon-2.1/src/blocks/midi/java/org/apache - New directory
bdelacretaz2003/08/07 00:23:55 cocoon-2.1/src/blocks/midi/java/org/apache - New directory
cvs commit: cocoon-2.1 status.xml
bruno 2003/08/06 08:54:13
Modified:src/blocks/apples/java/org/apache/cocoon/components/flow/apples
ApplesProcessor.java
src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_Cocoon.java
src/java/org/apache/cocoon/components/flow
AbstractInterpreter.java
src/documentation/xdocs/userdocs/flow api.xml
src/blocks/apples/samples sitemap.xmap
.status.xml
Log:
Cleaned up the situation with regards to the uri argument to
the sendPage, sendPageAndWait, and processPipelineTo functions.
URI's starting with a slash are resolved against the root sitemap,
URI's not starting with a slash are resolved against the current sitemap.
Revision ChangesPath
1.3 +0 -6
cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/ApplesProcessor.java
Index: ApplesProcessor.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/ApplesProcessor.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ApplesProcessor.java 4 Aug 2003 09:15:50 - 1.2
+++ ApplesProcessor.java 6 Aug 2003 15:54:13 - 1.3
@@ -58,7 +58,6 @@
import org.apache.cocoon.environment.Environment;
import org.apache.cocoon.environment.ObjectModelHelper;
import org.apache.cocoon.environment.Request;
-import org.apache.excalibur.source.SourceUtil;
/**
* ApplesProcessor is the core Cocoon component that provides the 'Apples'
@@ -148,12 +147,7 @@
env.redirect(false, res.getURI());
} else {
String uri = res.getURI();
-if (SourceUtil.indexOfSchemeColon(uri) == -1) {
-uri = cocoon:/ + uri;
-}
-
getLogger().debug(Apple forwards to + uri + with bizdata= +
res.getData());
-
this.forwardTo(uri, res.getData(), wk, env);
}
1.9 +3 -6
cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java
Index: FOM_Cocoon.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- FOM_Cocoon.java 4 Aug 2003 21:07:47 - 1.8
+++ FOM_Cocoon.java 6 Aug 2003 15:54:13 - 1.9
@@ -158,10 +158,7 @@
String redUri = uri;
-if(! uri.startsWith( cocoon:// ) ) {
-redUri = cocoon:// + this.environment.getURIPrefix() + uri;
-}
-FOM_WebContinuation fom_wk =
+FOM_WebContinuation fom_wk =
new FOM_WebContinuation(wk);
fom_wk.setParentScope(getParentScope());
fom_wk.setPrototype(getClassPrototype(getParentScope(),
@@ -916,7 +913,7 @@
throws Exception {
interpreter.forwardTo(getTopLevelScope(this),
this,
- cocoon:// + environment.getURIPrefix() + uri,
+ uri,
bean,
fom_wk,
environment);
1.7 +17 -2
cocoon-2.1/src/java/org/apache/cocoon/components/flow/AbstractInterpreter.java
Index: AbstractInterpreter.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/AbstractInterpreter.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- AbstractInterpreter.java 31 Jul 2003 17:30:13 - 1.6
+++ AbstractInterpreter.java 6 Aug 2003 15:54:13 - 1.7
@@ -63,6 +63,7 @@
import org.apache.cocoon.environment.Context;
import org.apache.cocoon.environment.Environment;
import org.apache.cocoon.environment.wrapper.EnvironmentWrapper;
+import org.apache.excalibur.source.SourceUtil;
import java.io.OutputStream;
import java.util.ArrayList;
@@ -177,9 +178,18 @@
throw new NullPointerException(No outputstream specified for process);
}
+// if the uri starts with a slash, then assume that the uri contains an
absolute
+// path, starting from the root sitemap. Otherwise, the uri is relative to
the current
+// sitemap.
+if (uri.length() 0 uri.charAt(0) == '/') {
+uri = uri.substring(1);
+} else {
+uri = env.getURIPrefix() + uri;
+}
+
// Create a wrapper environment for the subrequest to be processed.
EnvironmentWrapper
Re: [RT] Views for readers
On Thu, Aug 14, 2003 at 01:41:55PM +0200, Sylvain Wallez wrote:
Jeff Turner wrote:
...
map:view name=indexablecontent from-position=first
map:select type=xml-type
map:when test=docbook
map:transform src=docbook2whatever.xsl/
/map:when
map:when test=tei
map:transform src=tei2whatever.xsl/
/map:when
map:when test=msword
map:transform src=word2whatever.xsl/
/map:when
/map:select
/map:view
Ah, ok, the strongly type pipelines are a different wording for
content-aware selectors !
Ah yes. Strange how the same concept can live two separate lives in
one's head ;) Like the same class in two classloaders.
So http://mycocoonsite.com/foo.doc?cocoon_view=indexablecontent would
return XML representing the content of the .doc file.
I described the same thing in a mail with subject 'Type-aware Views (Re:
Link view goodness)'. Same need, different context, same proposed
solution.
Not exactly : the use case here is that we have a binary file which is
normally sent as is to the browser using a reader. It is _not_ parsed as
an XML stream. So we can't attach a view to these kinds of URLs since
views provide a different _ending_ to a pipeline, meaning there must
exist at least a generator and optionnaly one or more transformers at
the point where processing is directed to the view.
So even content-aware selectors don't solve this problem...
Isn't the problem there that a map:read is a whole little pipeline unto
itself? If it were broken into two atomic operations:
map:generate type=binary src=foo.doc/
map:serialize type=binary/
then we could have a map:view from-position=first/ using a
content-aware pipeline, and everything would work.
I have the feeling that handling non-XML content in Cocoon is Just Wrong,
and that map:read is just a hack. The fact that it doesn't integrate
with Views is a symptom of this. In a theoretically pure world, we'd
either make Cocoon an XML-only framework and kill map:read, or make
Cocoon a generic data pipelining framework capable of handling and
transforming binary content.
Well it's a RT after all.. ;)
--Jeff
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
[OT] java[script]doc
Hi All, Does anyone know if there is an equivalent to the javadoc tool for JavaScript files? I'd love to pump out nice html docs for my commented flowscripts ;) Thanks for any suggestions regards Jeremy
Re: [RT] Views for readers
Miles Elam wrote:
Sylvain Wallez wrote:
Go back to first post of this thread, where (last paragraph) I
proposed something similar. The whole discussion is about how we
could have a syntax which doesn't introduce such verbosity in the
sitemap.
Verbosity is not necessarily a bad thing. If it were, would any of us
be using XML? ;-)
Good point.
snip/
Let's consider the MIDI example. Suppose we have a large collection
of karaoke files (MIDI supports embedded text that can be played on
screen while playing the music), and we want to index the text of
these songs for easy retrieval (along with some other meta-data).
Here's a sitemap example, using the current syntax
snip/
And the proposed shorter one :
map:match pattern=*.mid
map:read src={1}.mid unless-label=content/
map:generate type=midi src={1}.mid/
map:transform src=xmidi2xdoc.xsl label=content-label/
!-- should never come here --
map:serialize type=xml/
/map:match
Two lines. What does it give except obfuscation? Given the point above
(Verbosity is not necessarily a bad thing (c) Miles Elam) more
readable and already supported syntax is:
map:resource name=midi/
map:match type=view pattern=content
map:generate type=midi src={1}.mid/
map:transform src=xmidi2xdoc.xsl label=content/
map:serialize type=xml/
/map:match
map:read mime-type=whatever/midi src={1}.mid/
/map:match
map:match pattern=*.mid/
map:call resource=midi/
/map:match
Moreover! Resource midi is reusable:
map:match pattern=another/*.mid/
map:call resource=midi/
/map:match
, while example above is not.
This breaks current convention that either a reader or a
generator/transformer/serializer can act in a pipeline.
And, given this resource example, it does not break any sitemap
semantics which we have today.
In the first example, if content isn't specified, the action returns
null and the reader is invoked; As far as the pipeline logic is
concerned, there is only the reader. Serializers are already known as
universal exit points. To use the second, the convention must be
broken and readers must become universal exit points.
In other words,
map:match pattern=*.mid
map:read src={1}.mid/ !-- without the unless-label --
map:generate type=midi src={1}.mid/
map:transform src=xmidi2xdoc.xsl label=content-label/
!-- should never come here --
map:serialize type=xml/
/map:match
must become valid for consistency. A reader becomes an exit point and
the rest of a pipeline is, by default, ignored. Is this an intended
consequence?
I fell strongly -1 on this one.
Vadim
Re: [OT] Carsten's period of silence
Sylvain Wallez wrote: Carsten got his right hand injured. See http://radio.weblogs.com/0107211/2003/08/03.html Carsten, we all wish you a quick recovery. Carsten, you should really stop doing manual work. I'm about as clumsy as you are and I've decided that in order to avoid hurting myself and others, I would limit myself to intellectual activities in the summer, like reading books on the beach under an umbrella ;-). Get well soon. Ugo -- Ugo Cei - Consorzio di Bioingegneria e Informatica Medica P.le Volontari del Sangue, 2 - 27100 Pavia - Italy Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]
cvs commit: cocoon-site/src/documentation/content/xdocs/community mail-archives.xml mail-lists.xml
joerg 2003/08/06 08:56:33 Modified:src/documentation/content/xdocs index.xml site.xml src/documentation/content/xdocs/community mail-archives.xml mail-lists.xml Log: back to document v 1.0 use relative links instead of absolute (http://c.a.o/) for offline browsing where possible (Forrest does not claim about links to dirs - is it a bug there? Should we link relative in general with some broken links messages but complete offline browsing?) some old xml.apache.org links fixed Revision ChangesPath 1.8 +21 -19cocoon-site/src/documentation/content/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/index.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- index.xml 25 Jun 2003 14:54:36 - 1.7 +++ index.xml 6 Aug 2003 15:56:33 - 1.8 @@ -1,30 +1,32 @@ ?xml version=1.0 encoding=UTF-8? -!DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.1//EN -document-v11.dtd +!DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.0//EN document-v10.dtd document header titleThe Apache Cocoon Project/title +authors + person name=Cocoon Developers email=[EMAIL PROTECTED]/ +/authors /header body -pThe Apache Cocoon project is a framework for building web publications -and applications, that raises the usage of serverside Java, XML and -related technologies to a new level. Apache Cocoon, its main project, has -been designed for performance and scalability around pipelined SAX -processing. Cocoon offers a flexible environment based on a separation of -concerns between content, logic, and style. Cocoon#39;s centralized -configuration system and sophisticated caching help you to create, deploy, -and maintain rock-solid XML server applications./p +s1 title=The Apache Cocoon Project + pThe Apache Cocoon project is a framework for building web publications + and applications, that raises the usage of serverside Java, XML and + related technologies to a new level. Apache Cocoon, its main project, has + been designed for performance and scalability around pipelined SAX + processing. Cocoon offers a flexible environment based on a separation of + concerns between content, logic, and style. Cocoon#39;s centralized + configuration system and sophisticated caching help you to create, deploy, + and maintain rock-solid XML server applications./p -pThe Apache Cocoon project currently consists of:/p + pThe Apache Cocoon project currently consists of:/p -ul - lilink href=http://cocoon.apache.org/2.1/;Apache Cocoon/link - itself./li - - lilink href=http://cocoon.apache.org/lenya/;Lenya/link, an - link href=incubation.htmlincubating/link - website content management framework based on Cocoon./li -/ul + ul +lilink href=2.1/Apache Cocoon/link itself./li +lilink href=lenya/Lenya/link, an +link href=incubation.htmlincubating/link +website content management framework based on Cocoon./li + /ul +/s1 /body /document 1.12 +4 -4 cocoon-site/src/documentation/content/xdocs/site.xml Index: site.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/site.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- site.xml 6 Aug 2003 15:20:24 - 1.11 +++ site.xml 6 Aug 2003 15:56:33 - 1.12 @@ -20,11 +20,11 @@ projects label=Projects cocoon label=Cocoon - link label=Cocoon 1.x href=http://cocoon.apache.org/1.x// - link label=Cocoon 2.0 href=http://cocoon.apache.org/2.0// - link label=Cocoon 2.1 href=http://cocoon.apache.org/2.1// + link label=Cocoon 1.x href=1.x// + link label=Cocoon 2.0 href=2.0// + link label=Cocoon 2.1 href=2.1// /cocoon -link label=Lenya href=http://cocoon.apache.org/lenya// +link label=Lenya href=lenya// /projects community label=Community href=community/ 1.4 +12 -10 cocoon-site/src/documentation/content/xdocs/community/mail-archives.xml Index: mail-archives.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/community/mail-archives.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- mail-archives.xml 9 Jul 2003 17:50:11 - 1.3 +++ mail-archives.xml 6 Aug 2003 15:56:33 - 1.4 @@ -1,26 +1,28 @@ ?xml version=1.0 encoding=UTF-8? -!DOCTYPE
cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/offline - New directory
upayavira2003/08/07 03:38:57 cocoon-2.1/src/documentation/xdocs/userdocs/offline - New directory
Re: cvs commit: cocoon-2.1 README.txt CREDITS.txt announcement.xml
On 5/08/2003 11:49 [EMAIL PROTECTED] wrote: new marketing strategy and dealing with all the due credits and copyright restrictions Thanks for the copyright stuff! Some remarks: + Apache Cocoon is a web development framework built around the concept + of separation of concerns (that is: allowing people to do their job + without having to step on each other toes) and component-oriented web + RAD. The term RAD has a very (out)dated sound in my ears. Surely RAD is OK, but people will hear RAD and understand '4GL'. My rephrasing: Apache Cocoon is a web development framework built around the concepts of separation of concerns (making sure people can interact and collaborate on a project, without stepping on each other toes) and component-based web development. + Cocoon implements these concepts around the notion of 'component + pipelines' modelled after the 'process chain' concept where each + worker specializes on a particular operation. This makes it possible + to use a Lego(tm)-like approach in building web solutions where + these components can be hooked together into pipelines without + requiring further programming. That first sentence is very 'jserv-like'. ;-) I would reduce verbiage into: Cocoon implements these concepts around the notion of 'component pipelines', each component on the pipeline specializing on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions, hooking together components into pipelines without any required programming. + We like to think at Cocoon as web glue for your web application + development needs. But most important, a glue that can keep + concerns separate and allow parallel evolution of the two sides, + improving development pace and reducing the chance of conflicts. What two sides?... Also, maybe we should sound a little bit stronger: Cocoon is web glue for your web application development needs. It is a glue that keeps concerns separate and + Cocoon has been designed to interoperate side-by-side with your J2EE coexist and interoperate? (introducing more verbiage ;-) + existing solutions or give them new functionality without requiring + any change in the existing infrastructure. snip/ +This product includes software developed by the IronSmith Project +(http://www.ironsmith.org/). Eh? +Portions are Copyright (c) 2001 Tivano Software GmbH +(http://www.tivano.de). All Rights Reserved. Eh? +Portions are Copyright (c) 2001 Scott Robert Ladd. All rights reserved. Eh? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/concepts caching.xml
cziegeler2003/08/07 08:18:52 Modified:src/documentation/xdocs/userdocs/concepts caching.xml Log: Start updating caching doc Revision ChangesPath 1.3 +44 -43cocoon-2.1/src/documentation/xdocs/userdocs/concepts/caching.xml Index: caching.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/concepts/caching.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- caching.xml 7 Aug 2003 15:09:57 - 1.2 +++ caching.xml 7 Aug 2003 15:18:52 - 1.3 @@ -22,7 +22,7 @@ how they can be configured and how to implement your own cacheable components. /p /s1 - s1 title=How to configure caching + s1 title=How to Configure Caching pThe caching can be turned on and off on a per pipeline setting in the sitemap. This means, for each emmap:pipeline/em section in a sitemap, it's possible to turn on/off caching and configure the caching algorithm./p @@ -62,17 +62,49 @@ override this whereever it makes sense./p /s1 !-- FIXME: THe following is OLD -- - s1 title=Caching of event pipelines - pThe algorithm used for caching depends on the event pipeline configured. - For more information about configuration see the chapter below./p -pThe following subchapters describe the available caching algorithms./p - s2 title=The CachingEventPipeline - pThe CachingEventPipeline uses a very easy but effective approach - to cache the event pipelines of a request: The pipeline process - is cached up to the most possible point./p - pEach sitemap component (generator or transformer) which might be - cacheable must implement the Cacheable interface. When the - event pipeline is processed each sitemap component starting with + s1 title=The Default Caching Algorithm + pThe default algorithm uses a very easy but effective approach + to cache a request: The pipeline process is cached up to the most + possible point./p +pTherefore each component in the pipeline is queried by Cocoon if it +supports caching. Several components, like the file generator or the xslt +transformer support caching. However, dynamic components like the sql transformer +or the cinclude transformer do not. Let's have a look at some examples:/p + s2 title=Simple Examples + pIf you have the following pipeline:/p + pGenerator[type=file|src=a.xml] - Transformer[type=xslt|src=a.xsl] - Serializer/p + pThe file generator is cacheable and generates a key which uses the src + (or the filename) to build the key. The cache uses the last modification date of the xml file + to test if the cached content is valid./p + pThe xslt transformer is cacheable and generates a key which uses + the filename to build the unique key. The cache validity object + uses the last modification date of the xslt file./p + pThe default serializer (html) supports the caching as well./p + pAll three keys are used to build a unique key for this pipeline. + The first time it is invoked its response is cached. The second time + this pipeline is called, the cached content is get from the cache. + If it is still valid, the cached content is directly send to the client./p +/s2 +s2 title=Complex Example +pOnly part of the following pipeline is cached:/p + pGenerator[type=file|src=a.xml] - Transformer[type=xslt|src=a.xsl] - Transformer[type=sql] - Transformer[type=xslt|src=b.xsl] - Serializer/p + pThe file generator is cacheable and generates a key which uses the src + (or the filename) to build the key. The cache uses the last modification date of the xml file + to test if the cached content is valid./p + pThe xslt transformer is cacheable and generates a key which uses + the filename to build the unique key. The cache validity object + uses the last modification date of the xslt file./p + pThe sql transformer is not cacheable, so the caching algorithm stops +at this point although the last transformer is cacheable again./p + pSo the cached response is absolutely the same as in the first example + and therefore the unique key build from the two keys (from the + generator and the
cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/flow jxtemplate.xml
mpo 2003/08/11 02:12:40 Modified:src/documentation/xdocs/userdocs/flow jxtemplate.xml Log: Validating xdocs learns that source needs no p wrapper. Revision ChangesPath 1.19 +1 -4 cocoon-2.1/src/documentation/xdocs/userdocs/flow/jxtemplate.xml Index: jxtemplate.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/flow/jxtemplate.xml,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- jxtemplate.xml8 Aug 2003 18:49:06 - 1.18 +++ jxtemplate.xml11 Aug 2003 09:12:40 - 1.19 @@ -237,7 +237,7 @@ p The codeformatNumber/code tag is used to display numeric data, including currencies and percentages, in a locale-specific manner. It determines from the locale, for example, whether to use a period or a comma for delimiting the integer and decimal portions of a number. Here is its syntax: /p -psource +source lt;formatNumber value=Expression [type=Type] [pattern=Expression] [currencyCode=Expression] [currencySymbol=Expression] @@ -246,7 +246,6 @@ [groupingUsed=Expression] [var=Name] [locale=Expression]gt; /source -/p p Only the codevalue/code attribute is required. It is used to specify the numeric value that is to be formatted. /p @@ -269,13 +268,11 @@ /s2 s2 title=formatDate pThe codeformatDate/code tag provides facilities to format Date values:/p -p source lt;formatDate value=Expression [dateStyle=Style] [timeStyle=Style] [pattern=Expression] [type=Type] [var=Name] [locale=Expression]gt; /source -/p p Only the value attribute is required. Its value should be an instance of the codejava.util.Date/code class, specifying the date and/or time data to be formatted and displayed./p
FYI: PatternTransformer, deserves some publicity I think...
I just had a look at the PatternTransformer and its samples, and although there has been almost no mention of it on the lists it looks very interesting for free-form parsing or enhancement of text (like adding links based on text patterns). For example, it can easily map text such as Here is a link in the middle of plain text, http://www.perdu.com To Here is a link in the middle of plain text, a href=http://www.perdu.com;http://www.perdu.com/a Thanks Stephan for this! I know you have something more sophisticated in mind, but this looks very useful already. -Bertrand
DO NOT REPLY [Bug 20033] - [PATCH] LDAPTransformer patch: add/replace/append
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20033. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20033 [PATCH] LDAPTransformer patch: add/replace/append [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-07 00:34 --- please have a look at collection patch at bug 22173
cvs commit: cocoon-2.1/src/java/org/apache/cocoon cocoon.properties
cziegeler2003/08/12 04:37:45 Modified:.forrest.properties status.xml src/java/org/apache/cocoon cocoon.properties Log: New version Revision ChangesPath 1.21 +1 -1 cocoon-2.1/forrest.properties Index: forrest.properties === RCS file: /home/cvs/cocoon-2.1/forrest.properties,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- forrest.properties12 Aug 2003 11:34:49 - 1.20 +++ forrest.properties12 Aug 2003 11:37:44 - 1.21 @@ -6,7 +6,7 @@ #forrest.echo=true # Project name (used to name .war file) -project.name=cocoon-2.1 +project.name=cocoon-2.1.1-dev # Specifies name of Forrest skin to use #project.skin=forrest-site 1.115 +4 -1 cocoon-2.1/status.xml Index: status.xml === RCS file: /home/cvs/cocoon-2.1/status.xml,v retrieving revision 1.114 retrieving revision 1.115 diff -u -r1.114 -r1.115 --- status.xml11 Aug 2003 21:54:09 - 1.114 +++ status.xml12 Aug 2003 11:37:44 - 1.115 @@ -202,6 +202,9 @@ changes release version=@version@ date=@date@ + action dev=CZ type=addDUMMY/action + /release + release version=2.1 date=August 12 2003 action dev=JH type=update fixes-bug=22288 due-to=Mark Leicester due-to-email=[EMAIL PROTECTED] midi block refactoring applied. /action 1.14 +1 -1 cocoon-2.1/src/java/org/apache/cocoon/cocoon.properties Index: cocoon.properties === RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/cocoon.properties,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- cocoon.properties 12 Aug 2003 11:34:49 - 1.13 +++ cocoon.properties 12 Aug 2003 11:37:45 - 1.14 @@ -4,7 +4,7 @@ # very high chance of breaking the build system. Do it only if you know what # you're doing. -version=2.1 +version=2.1.1-dev released.version=2.1 year=1999-2003 name=cocoon
cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/util SimpleServiceSelector.java
bruno 2003/08/12 09:33:08
Modified:src/blocks/woody/java/org/apache/cocoon/woody/util
SimpleServiceSelector.java
Log:
Fix error in exception message
Revision ChangesPath
1.3 +1 -1
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/util/SimpleServiceSelector.java
Index: SimpleServiceSelector.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/util/SimpleServiceSelector.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SimpleServiceSelector.java16 Jul 2003 14:00:20 - 1.2
+++ SimpleServiceSelector.java12 Aug 2003 16:33:08 - 1.3
@@ -107,7 +107,7 @@
LifecycleHelper lifecycleHelper = new LifecycleHelper(getLogger(),
null, serviceManager, null, null, componentConfs[i]);
lifecycleHelper.setupComponent(component);
} catch (Exception e) {
-throw new ConfigurationException(Error creating + hintShortHand
+ declared at + componentConfs[i], e);
+throw new ConfigurationException(Error creating + hintShortHand
+ declared at + componentConfs[i].getLocation(), e);
}
components.put(name, component);
DO NOT REPLY [Bug 19839] - instrumentation support is broken in CVS HEAD
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19839. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19839 instrumentation support is broken in CVS HEAD --- Additional Comments From [EMAIL PROTECTED] 2003-08-07 13:25 --- What exactly does not work? I could at least start the client. Must/Should the client libraries correspond to the libraries used in Cocoon\lib\optional? Where to get the AltRMI binaries from? The source in the CVS has nothing about a version.
RE: Switching cache to Persistent Store
On 11 Aug 2003 at 12:06, Carsten Ziegeler wrote: Upayavira wrote: I've been exploring how to get the CLI to use Cocoon's caching mechanism and environment.isLastModified() to prevent the CLI from generating otherwise cached pages. The problem I currently have is that the cache Cocoon uses is transient, and is thus lost every time the CLI restarts. So: a) How can I switch Cocoon to always use a Persistent cache? Putting cacheparameter name=store value=org.apache.excalibur.store.Store//cache into cocoon.xconf makes CacheImpl pick a persistent store, but for some reason values aren't in the store after Cocoon has been restarted. What do you mean by after Cocoon has been restarted? I'm not sure but it could be possible that the store is cleaned on startup. All I know is that, when the store is transient, the first page that is loaded isn't in the cache. And, when I switch to the persistent store using the cocoon.xconf cache element, the persistent store is picked by CacheImpl, but still the first page isn't in the cache, even after multiple runs. By after Cocoon has restarted I'm referring to the fact that, each time you invoke the CLI, Cocoon starts up from scratch, does its work, and then shuts down. So anything in a transient cache presumably won't survive between invocations of the CLI. b) How can I get Cocoon to use a persisitent store for CLI and a transient one for servlet? By using different configurations, ok dumb answer I know, but the easiest (?) solution is to change the above mentioned store parameter to the required values. Not dumb. But I tried it, but the page still wasn't in the cache after Cocoon had restarted (through debugging in Eclipse), and I could see that CacheImpl was loading a DefaultStore rather than a MRUMemoryStore. And default store is based upon Jisp, which is persistent, no? I'll have more of a look this evening to see if I can spot why it isn't working. Can you give me any pointers to where I should look? Thanks for your help here. I'm pretty green when it comes to caching in Cocoon, but I'm improving rapidly! Regards, Upayavira
cvs commit: cocoon-2.1/src/documentation/stylesheets changes2document.xsl statuschanges2document.xsl
joerg 2003/08/06 20:32:14 Modified:src/documentation/stylesheets changes2document.xsl statuschanges2document.xsl Log: handling multiple, comma separated bugs in changes (@fixesbug) Revision ChangesPath 1.2 +15 -4 cocoon-2.1/src/documentation/stylesheets/changes2document.xsl Index: changes2document.xsl === RCS file: /home/cvs/cocoon-2.1/src/documentation/stylesheets/changes2document.xsl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- changes2document.xsl 9 Mar 2003 00:07:31 - 1.1 +++ changes2document.xsl 7 Aug 2003 03:32:14 - 1.2 @@ -8,7 +8,9 @@ xsl:param name=name/ - xsl:variable name=bugzillahttp://nagoya.apache.org/bugzilla/show_bug.cgi?id=/xsl:variable + xsl:variable name=bugzilla select='http://nagoya.apache.org/bugzilla/'/ + xsl:variable name=singleBug select=concat($bugzilla, 'show_bug.cgi?id=')/ + xsl:variable name=buglist select=concat($bugzilla, 'buglist.cgi?bug_id=')/ xsl:template match=changes document @@ -52,9 +54,18 @@ xsl:if test=@fixes-bug xsl:text Fixes /xsl:text -link href=[EMAIL PROTECTED] - xsl:textbug /xsl:textxsl:value-of select=@fixes-bug/ -/link +xsl:choose + xsl:when test=contains(@fixes-bug, ',') + link href=[EMAIL PROTECTED] + xsl:textbugs /xsl:textxsl:value-of select=@fixes-bug/ + /link + /xsl:when + xsl:otherwise + link href=[EMAIL PROTECTED] + xsl:textbug /xsl:textxsl:value-of select=@fixes-bug/ + /link + /xsl:otherwise +/xsl:choose xsl:text./xsl:text /xsl:if /li 1.2 +15 -4 cocoon-2.1/src/documentation/stylesheets/statuschanges2document.xsl Index: statuschanges2document.xsl === RCS file: /home/cvs/cocoon-2.1/src/documentation/stylesheets/statuschanges2document.xsl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- statuschanges2document.xsl6 Apr 2003 04:13:23 - 1.1 +++ statuschanges2document.xsl7 Aug 2003 03:32:14 - 1.2 @@ -8,7 +8,9 @@ xsl:param name=name/ - xsl:variable name=bugzillahttp://nagoya.apache.org/bugzilla/show_bug.cgi?id=/xsl:variable + xsl:variable name=bugzilla select='http://nagoya.apache.org/bugzilla/'/ + xsl:variable name=singleBug select=concat($bugzilla, 'show_bug.cgi?id=')/ + xsl:variable name=buglist select=concat($bugzilla, 'buglist.cgi?bug_id=')/ xsl:template match=/ xsl:apply-templates select=//changes/ @@ -56,9 +58,18 @@ xsl:if test=@fixes-bug xsl:text Fixes /xsl:text -link href=[EMAIL PROTECTED] - xsl:textbug /xsl:textxsl:value-of select=@fixes-bug/ -/link +xsl:choose + xsl:when test=contains(@fixes-bug, ',') + link href=[EMAIL PROTECTED] + xsl:textbugs /xsl:textxsl:value-of select=@fixes-bug/ + /link + /xsl:when + xsl:otherwise + link href=[EMAIL PROTECTED] + xsl:textbug /xsl:textxsl:value-of select=@fixes-bug/ + /link + /xsl:otherwise +/xsl:choose xsl:text./xsl:text /xsl:if /li
RE: accessing a HashMap from JXTemplate
It took me some time to find out how you can iterate over a map in jxpath:
c:forEach select=#{values(/units)}
#{./id} br/
/c:forEach
/units is a map of unit objects.
You can call a java function on a java object by giving the instance as the
first parameter. So I am calling the java values() function on my /units map
which creates a collection of its values.
#{./id} prints the id field of each of my unit objects.
The jexl syntax works without conversion:
c:forEach var=item items=${mapU}
${item.getId()} br/
/c:forEach
Hugo
-Original Message-
From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
Sent: Friday, August 08, 2003 9:47 PM
To: [EMAIL PROTECTED]
Subject: accessing a HashMap from JXTemplate
but it does not output anything, so I tried this :
t:forEach items=#{form/errors}
tr valign=top
td#{name()}/td
td#{.}/td
/tr
/t:forEach
but got unexpected results :
DO NOT REPLY [Bug 20445] - i18n transformer does not recognize 2.0 namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20445. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20445 i18n transformer does not recognize 2.0 namespace [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
Re: cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/conceptsaggregation.xml book.xml
[EMAIL PROTECTED] wrote: upayavira2003/08/09 06:12:04 Modified:src/documentation/xdocs/userdocs/concepts book.xml Added: src/documentation/xdocs/userdocs/concepts aggregation.xml Log: Couldn't find any documentation on map:aggregate, so here's some basic docs, just in time for final release. Please improve on these http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Aggregating Joerg
Re: [OT] should I laugh or cry?
Geoff Howard wrote: BUILD SUCCESSFUL Total time: 44 minutes 8 seconds LOL Impressive! What did you do this on? Was it a full distribution, or build the binary type of thing? -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
DO NOT REPLY [Bug 20033] - [PATCH] LDAPTransformer patch: add/replace/append
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20033. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20033 [PATCH] LDAPTransformer patch: add/replace/append [EMAIL PROTECTED] changed: What|Removed |Added Summary|[PATCH]LDAPTransformer patch|[PATCH] LDAPTransformer ||patch: add/replace/append
cvs commit: cocoon-2.1/src/blocks/mail/java/org/apache/cocoon/mail/transformation SendMailTransformer.java
reinhard2003/08/08 07:15:41
Modified:src/blocks/mail/java/org/apache/cocoon/mail/transformation
SendMailTransformer.java
Log:
- quick solution to enable build under jdk1.3.1 (must be reimplemented)
Revision ChangesPath
1.2 +3 -2
cocoon-2.1/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java
Index: SendMailTransformer.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SendMailTransformer.java 8 Aug 2003 11:35:03 - 1.1
+++ SendMailTransformer.java 8 Aug 2003 14:15:41 - 1.2
@@ -671,11 +671,12 @@
super.sendEndElementEvent(email:message);
super.sendStartElementEvent(email:stacktrace);
+/* doesn't compile under 1.3.1 (RP)
for (int i = 0; i ex.getStackTrace().length; i++) {
String s = ((StackTraceElement) ex.getStackTrace()[i]).toString();
super.sendTextEvent(s + \n);
}
-
+*/
super.sendEndElementEvent(email:stacktrace);
super.sendEndElementEvent(email:exception);
} catch (SAXException e) {
Re: [OT] should I laugh or cry?
Bertrand Delacretaz wrote: BUILD SUCCESSFUL Total time: 44 minutes 8 seconds compiling by hand, maybe? ;-) -Bertrand :D
Re: Extending the Bean (non-HTML)
Upayavira wrote: [here's a non-HTML version - mailer misbehaved again :-( ] OT: Have you tried mozilla mail client? * split the bean into a CocoonWrapper that handles configuring a Cocoon object and handling a single request, and a CocoonBean which handles crawling What is the API of these new beans? Please do not forget that CocoonBean is out of the door with 2.1 release and people (might be) already building applications with CocoonBean, meaning, you can't change CocoonBean API in backward incompatible way without proper deprecating and support of released functionality. * Made the CocoonBean use a Crawler class (derived from the one in the scratchpad Ant task) Do you mean org.apache.cocoon.components.crawler.Crawler? I don't see how it can be used in CocoonBean. Can you elaborate? * Moved all of the URI logic (mangling URIs etc) into the Target class Sounds good. * made it report the time taken to generate a single page Ok. Next I want to: * moving the member variables of the wrapper and bean into a Context object, so that the Bean can be used in a ThreadSafe environment. AFAIU, CocoonBean.processURI is already thread safe. All addTarget() methods are obviously not. addTarget() methods can easily be made threadsafe (in some sense -- call to addTarget in one thread does not break bean but affects process() running in another thread) by synchronyzing access to the targets collection. It can be thread safe in another sense too (calls to processTargets in different threads are independent of each other): you just need to add processTargets(targets) method. * rework the way the bean is configured (possibly using Configuration objects) Why would you need those Configuration objects? * improve reporting so that it reports pages generated, time taken per page, the links found in a page, stack trace from errors, pages that contain broken links, and more. Ok. * Make this reporting use SAX (to a file), so that in future it can be the basis of a publishing service I think that's overkill. Especially writing to the file part. Extend BeanListener interface if you like, implement FileBeanListener if you need, but I don't think SAX is really what you need here. * Get caching working properly, and make it use ifModifiedSince() to determine whether to save the file or not. Must-have feature. Top priority. I hope you've seen my emails on persistent store subject. * Build a simple Ant task to replace Main.java for ant driven processes Good. * Make Cocoon work with an external Cocoon object, again for the sake of a PublishingService I don't get this. What Cocoon with which external Cocoon? * replace the contents of the cli.xconf file with correct settings for generating documentation from the built webapp, keeping the documentation system working Don't know what you mean. * implement exclude/include, a la Ant in the cli.xconf Ok. * make it configurable as to which pages are scanned for links (why generate /docs/logo.gif?cocoon-view=links)? Set of extensions which are not quieried for the links (configuration parameter don't-follow-links=gif, jpg, png)? * work out how to implement Vadim's idea for a single pipeline with an XMLTeePipe to generate both a link view and page view in one hit Yep. Should increase performance and conformance! * improve the cli.xconf format to be more flexible, e.g: generate multiple pages to a single destination, and to have links followed on some pages but not others, etc Ok. Phew. More than I thought! And there's more I haven't mentioned... I'm scared! :) Vadim
Re: [QUICK-VOTE] Release Date for 2.1 final
Carsten Ziegeler wrote: I just wanted to check what the general feeling for the final release date of 2.1 is. I think we can either release next week (12th) or the week after (19th). I prefer the 12th and don't think that we need one more week. We can make a 2.1.1 were easy anyway. So, to make this thread easier, please only speak up if you think that the 19th is better and give a short reason. My personal point is having the TraversableGenerator in the main trunk. The discussion didn't really solve the issues, so I'm about to propose a vote and see what happens. Other than that, I'm fine with releasing on the 12th. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl DateType.java
bruno 2003/08/12 05:56:54
Modified:src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl
DateType.java
Log:
small javadoc improvement
Revision ChangesPath
1.2 +1 -1
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl/DateType.java
Index: DateType.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl/DateType.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DateType.java 15 Jul 2003 14:06:16 - 1.1
+++ DateType.java 12 Aug 2003 12:56:54 - 1.2
@@ -53,7 +53,7 @@
import java.util.Date;
/**
- * A [EMAIL PROTECTED] org.apache.cocoon.woody.datatype.Datatype} implementation for
+ * A [EMAIL PROTECTED] org.apache.cocoon.woody.datatype.Datatype Datatype}
implementation for
* java.util.Date's (so includes a time-component).
*/
public class DateType extends AbstractDatatype {
DO NOT REPLY [Bug 22132] New: - Cannot use redirect-to after submit jxform
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22132.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22132
Cannot use redirect-to after submit jxform
Summary: Cannot use redirect-to after submit jxform
Product: Cocoon 2
Version: 2.1m2
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
If you include a redirect-to directove in yuor sitemap in a map:match that
catches the submission of a JXForm, the redirect-to fails and you're left with
a blank page. This was discovered while trying to make a login JXForm and
using the Cocoon authorization but was confirmed later with a standalone form.
Source code for the problem. Note, as is, this code works. However, if you
replace any of the generate/serialize inthe selector with a redirect-to, it
will fail.
Here's the sitemap that exhibits the problem:
-
!-- Pattern for initial/continuation form requests --
map:match pattern=doform-*-*
map:call function=jxForm
map:parameter name=function value={2}/
map:parameter name=id value=form-{1}-{2}/
map:parameter name=validator-schema-ns
value=http://www.ascc.net/xml/schematron/
map:parameter name=validator-schema value=schematron/rules-{1}-
{2}.xml/
map:parameter name=scope value=request/
/map:call
/map:match
!-- Pattern for form rendering - called from jscript sendView() --
map:match pattern=form-*
map:generate type=jxforms src=content/forms/form-{1}.xml label=xml/
map:transform type=xalan src=transforms/jxforms-default.xsl
label=debug /
map:transform type=xalan src=transforms/jxforms2html.xsl
label=debug2 /
map:serialize type=html /
/map:match
!-- Pattern for handling XSLT generated output --
!-- Using a map:redirect-to in ANY map:when will FAIL --
map:match pattern=output-*
map:select type=parameter
map:parameter name=parameter-selector-test value={1}/
!-- case: query results for login activity --
map:when test=admin-login
map:generate src=authorization/elrsaudit.xml/
map:transform src=transforms/admin-queryresults.xsl label=debug
map:parameter name=use-request-parameters value=true/
/map:transform
map:serialize/
/map:when
!-- case: query results for receipt activity --
map:when test=admin-receipt
map:generate src=content/xml/misc-impl.xml/
map:serialize/
/map:when
!-- case: query results for any other activity --
map:otherwise
map:generate src=content/xml/misc-impl.xml/
map:serialize/
/map:otherwise
/map:select
/map:match
Here's the javascript used:
---
cocoon.load(resource://org/apache/cocoon/components/jxforms/flow/jxForm.js);
function queryaudit(form) {
var searchCriteria = {
startDate: ,
endDate: ,
actType: ,
userName: ,
groupName: ,
docNum: ,
pin:
}
form.setModel(searchCriteria);
form.sendView(form-admin-queryfilter);
form.finish(output-admin- + searchCriteria.actType)
}
Here's the form definition:
---
?xml version=1.0?
html xmlns:xf=http://apache.org/cocoon/jxforms/1.0;
headtitleTest/title/head
body
p
!-- Specifics for this page --
This page will allow users with sufficient privledges to enter criteria for a
search of the audit records.
/p
xf:form id=form-admin-queryaudit view=form-admin-queryfilter
action=doform-auth-queryaudit method=GET
xf:labelQuery Parameters/xf:label
error
xf:violations/
/error
xf:input ref=startDate
xf:labelStart Date (req'd)/xf:label
xf:hintEnter an inclusive start date (MM/DD/)/xf:hint
xf:violations class=error/
/xf:input
xf:input ref=endDate
xf:labelEnd Date (req'd)/xf:label
xf:hintEnter an inclusive end data (MM/DD/)/xf:hint
xf:violations class=error/
/xf:input
xf:select1 ref=actType
xf:labelActivity Type/xf:label
xf:item
xf:labelLogin/xf:label
xf:valuelogin/xf:value
/xf:item
xf:item
xf:labelDocument Receipt/xf:label
xf:valuereceipt/xf:value
/xf:item
/xf:select1
xf:input ref=userName
xf:labelUser Name/xf:label
xf:violations class=error/
/xf:input
xf:input ref=groupName
xf:labelGroup Name/xf:label
xf:violations class=error/
/xf:input
xf:input ref=docNum
xf:labelDocument Number/xf:label
xf:hintFormat is: XX##/xf:hint
xf:violations class=error/
/xf:input
xf:input ref=pin
xf:labelPIN/xf:label
Re: cocoon + MS SQL Server problem
Hi, i had the same problems with jtds jdbc driver and ms sql server (and it was driving me crazy). The problem described shortly: The sql server closes connections and the jdbc driver throws an exception. This exception is not recognized by the jdbc pooling component. The connection gets lost, but the jdbc pool doesn't know it. This occurs till your max connection number is exceed and then your application hangs when requesting a datasource from the pool. A solution is to upgrade your excalibure datasource to a recent version. Look under http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/datasource/src/java/org/a pache/avalon/excalibur/datasource/AbstractJdbcConnection.java revision 1.30 fixes this bug. hth, Frank
Re: FYI: SlopGenerator added (as the unstable slop block)
Le Mercredi, 6 aoû 2003, à 16:06 Europe/Zurich, Vadim Gritsenko a écrit : ...Let me add one more question: can we have both in the same block? There's no common code between SlopGenerator and Chaperon, and the very different ways of using them might create some confusion if they share the same block. I didn't want to pollute Chaperon with experimental stuff, and having a separate slop block makes it easier to see if there's interest in it IMHO. -Bertrand
Re: [RT] Updating our marketing strategy
Hunsberger, Peter wrote: Geoff Howard [EMAIL PROTECTED] asks: snip on Cocoon positioning/ Related to positioning ourselves as glue/duct tape: Speaking of J2EE, I think we are really missing the boat by not offering really dead-simple integration with EJB (even though so many here are waiting for its carcass). The fact is that EJB for now is the reigning king and needs a good front end. I know Cocoon works well with EJB but it isn't dead simple for a newbie to see how. Unfortunately, I am not currently using them and didn't even have a container installed at home until recently. Anyone want to work on some examples/code with me? Peter, Just saw a post from you and remembered I lost this one. I've been starting to gather a little support for contributing some of our stuff to the project. I know I can't do much of anything soon, but perhaps could do a lot more come this fall. In particular, I've got some relational DB Hedge generator code that might work well as an example: if you're familiar with Joe Celko's (SQL for Smarties) set/subset algorithms for managing hierarchical data in a relational database it exploits that structure directly to produce XML hedges with roughly O(N) memory and processing time (in proportion to the max hedge depth). (An XML Hedge is a collection of XML tree's sharing a common root.) The interfaces and abstract classes could be generally useful within Cocoon for Hedge production (and just need refactoring into the Cocoon package hierarchy which I could in an hour or so if I get permission from my Boss). Working up a concrete implementation against some database would take a little more work. If you're ok with just Session beans (no update, read only) I could maybe get an example together within a week or two if I get the ok. Would this be the kind of thing you're interested in? If so, I'll push for permission to contribute it... This sounds great - more advanced than I was envisioning, but that's a Good Thing (TM). Let us know if you have any luck. If that doesn't work, perhaps a simpler example of just getting a reference to a Session or Entity bean within Cocoon and producing some xml out of it in a brain-dead way, or calling Session beans from flow would be a good start. XSP would seem to be a very inviting and intuitive way in for those used to JSP fronting EJB (which it seems an awful lot of people are). Geoff
cvs commit: cocoon-2.1/src/blocks/midi/samples/xmidi - New directory
bdelacretaz2003/08/07 00:23:56 cocoon-2.1/src/blocks/midi/samples/xmidi - New directory
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/pipeline AbstractProcessingPipeline.java
cziegeler2003/08/06 03:07:30
Modified:src/java/org/apache/cocoon/components/pipeline
AbstractProcessingPipeline.java
Log:
The parameters was never set.
Revision ChangesPath
1.7 +2 -1
cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
Index: AbstractProcessingPipeline.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- AbstractProcessingPipeline.java 31 Jul 2003 03:54:22 - 1.6
+++ AbstractProcessingPipeline.java 6 Aug 2003 10:07:30 - 1.7
@@ -184,6 +184,7 @@
* Setup this component
*/
public void setup(Parameters params) {
+this.parameters = params;
final String expiresValue = params.getParameter(expires, null);
if (expiresValue != null) {
this.expires = this.parseExpires(expiresValue);
cvs commit: cocoon-2.1/src/blocks/slop/samples email-example.txt sitemap.xmap special-chars.txt tc-example.txt welcome.xml
bdelacretaz2003/08/06 05:59:13
Modified:.gump.xml
Added: src/blocks/slop/conf slop-generator.xmap slop.xsamples
src/blocks/slop/java/org/apache/cocoon/slop/generation
SlopGenerator.java
src/blocks/slop/java/org/apache/cocoon/slop/interfaces
SlopConstants.java SlopParser.java
src/blocks/slop/java/org/apache/cocoon/slop/parsing
SimpleSlopParser.java
src/blocks/slop/lib .cvsignore
src/blocks/slop/samples email-example.txt sitemap.xmap
special-chars.txt tc-example.txt welcome.xml
Log:
slop block added (SlopGenerator + samples)
Revision ChangesPath
1.73 +20 -1 cocoon-2.1/gump.xml
Index: gump.xml
===
RCS file: /home/cvs/cocoon-2.1/gump.xml,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -r1.72 -r1.73
--- gump.xml 4 Aug 2003 08:39:41 - 1.72
+++ gump.xml 6 Aug 2003 12:59:13 - 1.73
@@ -960,6 +960,25 @@
nag from=Gump to=[EMAIL PROTECTED]/
/project
+ project name=cocoon-block-slop status=unstable
+packageorg.apache.cocoon/package
+
+ant target=gump-block
+ property name=block-name value=slop/
+ property name=version value=@@DATE@@/
+/ant
+
+depend project=cocoon inherit=all/
+
+work nested=tools/anttasks/
+home nested=build/cocoon-@@DATE@@/
+
+jar name=blocks/slop-block.jar/
+
+nag from=Gump to=[EMAIL PROTECTED]/
+ /project
+
+
!--
COCOON SUPPLIED PROJECTS
1.1 cocoon-2.1/src/blocks/slop/conf/slop-generator.xmap
Index: slop-generator.xmap
===
?xml version=1.0?
xmap xpath=/sitemap/components/generators unless=[EMAIL PROTECTED]'slop']
map:generator
name=slop
logger=sitemap.generator.slop
src=org.apache.cocoon.slop.generation.SlopGenerator
/
/xmap
1.1 cocoon-2.1/src/blocks/slop/conf/slop.xsamples
Index: slop.xsamples
===
?xml version=1.0?
xsamples xpath=/samples unless=[EMAIL PROTECTED]'Slop']
group name=Slop
sample name=Slop Text Parser href=slop/
Examples showing how to use SLOP
(the Simple Line Oriented Parser)
to parse text files
/sample
/group
/xsamples
1.1
cocoon-2.1/src/blocks/slop/java/org/apache/cocoon/slop/generation/SlopGenerator.java
Index: SlopGenerator.java
===
/*
The Apache Software License, Version 1.1
Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modifica-
tion, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if any, must
include the following acknowledgment: This product includes software
developed by the Apache Software Foundation (http://www.apache.org/).
Alternately, this acknowledgment may appear in the software itself, if
and wherever such third-party acknowledgments normally appear.
4. The names Apache Cocoon and Apache Software Foundation must not be
used to endorse or promote products derived from this software without
prior written permission. For written permission, please contact
[EMAIL PROTECTED]
5. Products derived from this software may not be called Apache, nor may
Apache appear in their name, without prior written permission of the
Apache Software Foundation.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
cvs commit: cocoon-2.1/src/blocks/midi/test/org/apache/cocoon - New directory
bdelacretaz2003/08/07 00:23:56 cocoon-2.1/src/blocks/midi/test/org/apache/cocoon - New directory
Re: [OT] should I laugh or cry?
Geoff Howard wrote: BUILD SUCCESSFUL Total time: 44 minutes 8 seconds man, what are you building on, a p166? :) brag my athlon xp 2400 takes 5 minutes for a full build from a fresh cvs checkout /brag tony
DO NOT REPLY [Bug 14348] - [PATCH] Caching problem with XSP, XSL and cocoon pseudo protocol
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348 [PATCH] Caching problem with XSP, XSL and cocoon pseudo protocol [EMAIL PROTECTED] changed: What|Removed |Added Summary|Caching problem with XSP, |[PATCH] Caching problem with |XSL and cocoon pseudo |XSP, XSL and cocoon pseudo |protocol|protocol --- Additional Comments From [EMAIL PROTECTED] 2003-08-06 15:02 --- here it is. hopefully the right format (it's my first time ;-)
cvs commit: cocoon-site/src/documentation/content/xdocs/link livesites-1.x.xml livesites-2.0.xml livesites-2.1.xml book.xml livesites.xml
joerg 2003/08/06 08:20:24 Modified:src/documentation/content/xdocs site.xml src/documentation/content/xdocs/link book.xml Added: src/documentation/content/xdocs/link livesites-1.x.xml livesites-2.0.xml livesites-2.1.xml Removed: src/documentation/content/xdocs/link livesites.xml Log: livesites splitted into 1.x, 2.0, 2.1 Revision ChangesPath 1.11 +7 -3 cocoon-site/src/documentation/content/xdocs/site.xml Index: site.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/site.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- site.xml 29 Jul 2003 09:03:17 - 1.10 +++ site.xml 6 Aug 2003 15:20:24 - 1.11 @@ -6,7 +6,7 @@ whoweare label=Who we are href=whoweare.html/ !--| -| Guidelines shouldn't be put live before they are porperly voted upon. +| Guidelines shouldn't be put live before they are properly voted upon. | guidelines label=Guidelines href=guidelines.html/ |-- @@ -35,8 +35,12 @@ /community menu label=Links href=link/ -link label=Cocoon Links href=index.html/ -link label=Live Sites href=livesites.html/ +link label=Cocoon Links href=index.html/ +livesites label=Live Sites + link label=Cocoon 1.x href=livesites-1.x.html/ + link label=Cocoon 2.0 href=livesites-2.0.html/ + link label=Cocoon 2.1 href=livesites-2.1.html/ +/livesites link label=Cocoon Hosting href=hosting.html/ /menu 1.2 +6 -1 cocoon-site/src/documentation/content/xdocs/link/book.xml Index: book.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/link/book.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- book.xml 3 Jul 2003 14:25:01 - 1.1 +++ book.xml 6 Aug 2003 15:20:24 - 1.2 @@ -20,10 +20,15 @@ menu-item label=Training href=training.html/ /menu + menu label=Live Sites +menu-item label=Cocoon 1.x href=livesites-1.x.html/ +menu-item label=Cocoon 2.0 href=livesites-2.0.html/ +menu-item label=Cocoon 2.1 href=livesites-2.1.html/ + /menu + menu label=External Sites menu-item label=Info Sites href=sites.html/ menu-item label=Projects href=projects.html/ -menu-item label=Live Sites href=livesites.html/ menu-item label=Cocoon Hosting href=hosting.html/ /menu 1.1 cocoon-site/src/documentation/content/xdocs/link/livesites-1.x.xml Index: livesites-1.x.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.0//EN document-v10.dtd document header titleLive Sites Powered by Apache Cocoon 1.x/title authors person name=Cocoon Developers email=[EMAIL PROTECTED]/ /authors /header body !--lilink href=/link/li-- s1 title=Live Sites powered by Apache Cocoon 1.x p Here are some web sites that are proudly powered by Cocoon 1.x (only ordered by Cocoon version): /p s2 title=Cocoon 1.8.2 ul lilink href=http://www.linuxtv.org/;Linux TV/link/li lilink href=http://www.cogentlogic.com/;Cogent Logic Corporation/link/li lilink href=http://www.planetsalvage.com/;Planet Salvage/link/li lilink href=http://damocles.uc3m.es/TC/;Sentencias del Tribunal Constitucional/link - Univ. Carlos III, Madrid, Spain/li lilink href=http://www.powerfm.org/;Power FM - Web Station/link/li lilink href=http://www.estig.ipbeja.pt/;ESTIG/link/li lilink href=http://www.derecho.com/;http://www.derecho.com/link/li lilink href=http://www.gtsuae.com/;http://www.gtsuae.com/link/li!-- broken javascript document.write()-- /ul /s2 s2 title=Cocoon 1.8 ul lilink href=http://www.intelinet.com.br/;Intelinet/link/li lilink href=http://www.dfki.de/ruleml/;The Rule Markup Initiative/link/li lilink href=http://www.linxs.pt/;Linxs/link/li lilink href=http://www.infoplanning.com/;Information Planning and Management Services/link/li lilink href=http://www.globalcrossing.com/;Global Crossing/link - Telecommunication Solutions/li /ul /s2 s2 title=Cocoon 1.7.4 ul lilink href=http://www.nakapeida.com/;Naka Peida/link/li lilink href=http://www.worlddent.com/;World Dentistry/link/li /ul /s2 s2 title=unknown version ul lilink href=http://www.derecho.com/;Derecho.com/link/li lilink href=http://www.law.unc.edu/;Law at University of North Carolina/link/li lilink
DO NOT REPLY [Bug 14348] - [PATCH] Caching problem with XSP, XSL and cocoon pseudo protocol
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348 [PATCH] Caching problem with XSP, XSL and cocoon pseudo protocol [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED
Switching cache to Persistent Store
I've been exploring how to get the CLI to use Cocoon's caching mechanism and environment.isLastModified() to prevent the CLI from generating otherwise cached pages. The problem I currently have is that the cache Cocoon uses is transient, and is thus lost every time the CLI restarts. So: a) How can I switch Cocoon to always use a Persistent cache? Putting cacheparameter name=store value=org.apache.excalibur.store.Store//cache into cocoon.xconf makes CacheImpl pick a persistent store, but for some reason values aren't in the store after Cocoon has been restarted. b) How can I get Cocoon to use a persisitent store for CLI and a transient one for servlet? To show the sort of impovements possible, here's two pages, each generated twice, the second time cached. For those interested in improving the performance of the CLI, check out the benefits :-) * docs/index.html [4.447 seconds] * docs/index.html [0.3 seconds] * samples/hello-world/hello.html [0.381 seconds] * samples/hello-world/hello.html [0.04 seconds] Total time: 0 minutes 14 seconds Regards, Upayavira
Extending the Bean (non-HTML)
[here's a non-HTML version - mailer misbehaved again :-( ] In another message I mentioned I've done a lot of reworking of the bean/CLI. I thought I'd mention what I've done so far, and what I have planned. Doesn't really qualify for [RT] status, as it doesn't seem all that random to me! As to the reworking, I've: * split the bean into a CocoonWrapper that handles configuring a Cocoon object and handling a single request, and a CocoonBean which handles crawling * Made the CocoonBean use a Crawler class (derived from the one in the scratchpad Ant task) * Moved all of the URI logic (mangling URIs etc) into the Target class * made it report the time taken to generate a single page Next I want to: * moving the member variables of the wrapper and bean into a Context object, so that the Bean can be used in a ThreadSafe environment. * rework the way the bean is configured (possibly using Configuration objects) * improve reporting so that it reports pages generated, time taken per page, the links found in a page, stack trace from errors, pages that contain broken links, and more. * Make this reporting use SAX (to a file), so that in future it can be the basis of a publishing service * Get caching working properly, and make it use ifModifiedSince() to determine whether to save the file or not. * Build a simple Ant task to replace Main.java for ant driven processes * Make Cocoon work with an external Cocoon object, again for the sake of a PublishingService * replace the contents of the cli.xconf file with correct settings for generating documentation from the built webapp, keeping the documentation system working * implement exclude/include, a la Ant in the cli.xconf * make it configurable as to which pages are scanned for links (why generate /docs/logo.gif?cocoon-view=links)? * work out how to implement Vadim's idea for a single pipeline with an XMLTeePipe to generate both a link view and page view in one hit * improve the cli.xconf format to be more flexible, e.g: generate multiple pages to a single destination, and to have links followed on some pages but not others, etc Phew. More than I thought! And there's more I haven't mentioned... Regards, Upayavira
Re: cocoon.process uri argument (was RE: sendPage, sendPageAndWaituri argument)
Bruno Dumon wrote: On Mon, 2003-08-04 at 17:41, Unico Hommes wrote: On a related note: the cocoon.process(uri,object,outStream) FOM function is always resolved as cocoon:// . Do you think this should behave as sendPage(AndWait)? To provide the necessary context for others: this would mean that an uri starting with a slash is resolved starting from the root sitemap, while an uri not starting with a slash is resolved against the current sitemap. I think that would make a lot of sense, +1 from me. This would break existing uses of that method though, but I think we better change it now than later. Anyone else? +1 from me. Geoff
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemap ActNodeBuilder.java ActTypeNode.java ActionSetNode.java ActionSetNodeBuilder.java
sylvain 2003/08/07 01:42:20
Modified:src/blocks/databases/samples/tutorial sitemap.xmap
src/java/org/apache/cocoon/components/treeprocessor
DefaultTreeBuilder.java TreeBuilder.java
src/java/org/apache/cocoon/components/treeprocessor/sitemap
ActNodeBuilder.java ActTypeNode.java
ActionSetNode.java ActionSetNodeBuilder.java
Added: src/blocks/databases/samples/tutorial apache.xsl
Log:
Fix bug #9835 (hopefully) related to nested actions in action-sets
Revision ChangesPath
1.3 +10 -3 cocoon-2.1/src/blocks/databases/samples/tutorial/sitemap.xmap
Index: sitemap.xmap
===
RCS file: /home/cvs/cocoon-2.1/src/blocks/databases/samples/tutorial/sitemap.xmap,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- sitemap.xmap 25 Mar 2003 17:10:36 - 1.2
+++ sitemap.xmap 7 Aug 2003 08:42:20 - 1.3
@@ -82,7 +82,8 @@
map:serialize/
/map:act
map:generate type=serverpages src=docs/{1}-dept.xsp/
- map:transform
src=context://samples/common/style/xsl/html/simple-page2html.xsl/
+ map:transform src=apache.xsl/
+ !--map:transform
src=context://samples/common/style/xsl/html/simple-page2html.xsl/--
map:serialize/
/map:match
@@ -94,14 +95,20 @@
map:serialize/
/map:act
map:generate type=serverpages src=docs/{1}-empl.xsp/
- map:transform
src=context://samples/common/style/xsl/html/simple-page2html.xsl/
+ map:transform src=apache.xsl/
+ !--map:transform
src=context://samples/common/style/xsl/html/simple-page2html.xsl/--
map:serialize/
/map:match
map:match pattern=**.html
map:generate src=docs/{1}.xml/
-map:transform
src=context://samples/common/style/xsl/html/simple-page2html.xsl/
+ map:transform src=apache.xsl/
+!--map:transform
src=context://samples/common/style/xsl/html/simple-page2html.xsl/--
map:serialize/
+ /map:match
+
+ map:match pattern=images/**
+map:read src=context://docs/{0}/
/map:match
/map:pipeline
1.1 cocoon-2.1/src/blocks/databases/samples/tutorial/apache.xsl
Index: apache.xsl
===
?xml version=1.0?
!-- Author: Berin Loritsch [EMAIL PROTECTED] --
!-- Version: 1.0 --
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=document
html
head
titlexsl:value-of select=document/header/title//title
xsl:if test=@redirect
meta http-equiv=Refresh content=[EMAIL PROTECTED];[EMAIL PROTECTED]/
/xsl:if
/head
body text=#00 link=#039acc vlink=#0086b2 alink=#cc
topmargin=4 leftmargin=4 marginwidth=4 marginheight=4
bgcolor=#ff
!-- THE TOP BAR (HEADER) --
table width=100% cellspacing=0 cellpadding=0 border=0
tr
td width=135 height=60 rowspan=3 valign=top align=left
img width=135 height=60 src=images/logo.gif hspace=0
vspace=0 border=0/
/td
td width=100% height=5 valign=top align=left colspan=2
background=images/line.gif
img width=1 height=5 src=images/line.gif hspace=0 vspace=0
border=0 align=left/
/td
td width=29 height=60 rowspan=3 valign=top align=left
img width=29 height=60 src=images/right.gif hspace=0
vspace=0 border=0/
/td
/tr
tr
td width=100% height=35 valign=top align=left colspan=2
bgcolor=#0086b2font size=5 face=arial,helvetica,sanserif color=#ffdiv
style=text-align: right;xsl:value-of select=header/title//div/font/td
/tr
tr
td width=100% height=20 valign=top align=left bgcolor=#0086b2
background=images/bottom.gif
img width=3 height=20 src=images/bottom.gif hspace=0
vspace=0 border=0 align=left/
/td
td align=right bgcolor=#0086b2 height=20 valign=top width=288
background=images/bottom.gif
table border=0 cellpadding=0 cellspacing=0 width=288
tr
td width=96 height=20 valign=top align=left
a href=http://xml.apache.org/; target=new
img alt=http://xml.apache.org/; width=96 height=20
src=images/button-xml-lo.gif
name=xml hspace=0 vspace=0 border=0/
/a
/td
td width=96 height=20 valign=top align=left
a href=http://www.apache.org/; target=new
img alt=http://www.apache.org/; width=96 height=20
src=images/button-asf-lo.gif
cvs commit: cocoon-2.1/src/blocks/slop/java/org/apache/cocoon/slop/parsing - New directory
bdelacretaz2003/08/06 05:57:58 cocoon-2.1/src/blocks/slop/java/org/apache/cocoon/slop/parsing - New directory
Re: Using cocoon: source in xsl:imports
Phil Shafer wrote: I'm seeing an error when I use xsl:imports containing cocoon: sources. During processing of the import sources, ResourceReader.processStream() calls: response.setHeader(Content-Length, Long.toString(contentLength)); But the response referenced is the _original_ (external) http request, not some internal one. The result is that if cocoon:source has a length that is less than that of the request, the response is truncated. Has anyone seen this? Bugzilla didn't have anything appropriate. The handling of sources in XSLTProcessorImpl is fairly new code, right? Should it be doing something more than just: xslSource = resolver.resolveURI(href); like consing up a request/response? It's not concern of the resolver's user to fiddle with request / response. If change to be made, it should be done in cocoon source implementation. Or is the problem really just that setHeader shouldn't be called (unconditionally)? I think reader has a right to make this call unconditionally. PS Are you using reader to deliver xsl:import parts? Have you tried generate/serialize pair, which does work? Vadim
Re: Getting an X from a FOM_X
Reinhard Pötz wrote: But now I have a need to add the getRealPath method to the context, only because Linotype uses it extensively and I wanted to port it to the FOM. Is there a particular reason why it shouldn't be there? I think because Stefano considered it as hack - see his comment: /* * Yeah, I know that hardwiring those is hacky as hell. But I'll try to * fix this with link translation later on. */ var home = cocoon.context.getRealPath(/) + samples/linotype/; I think that actually Stefano was blaming hardwiring configuration info right in the code instead than getting them from somewhere, not the getRealPath stuff. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
cvs commit: cocoon-2.1/src/blocks/midi/java/org - New directory
bdelacretaz2003/08/07 00:23:55 cocoon-2.1/src/blocks/midi/java/org - New directory
cvs commit: cocoon-2.1/src/documentation/xdocs/installing index.xml
vgritsenko2003/08/07 19:51:59 Modified:src/documentation/xdocs/installing index.xml Log: Correct link to snapshots Revision ChangesPath 1.9 +1 -1 cocoon-2.1/src/documentation/xdocs/installing/index.xml Index: index.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/installing/index.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- index.xml 3 Jul 2003 14:48:10 - 1.8 +++ index.xml 8 Aug 2003 02:51:59 - 1.9 @@ -68,7 +68,7 @@ s2 title=Download a development snapshot p You also can download one of the development snapshots from the -link href=http://xml.apache.org/cocoon/mirror.cgi#nightly;CVS snapshots/link +link href=http://cocoon.apache.org/mirror.cgi#nightly;CVS snapshots/link directory. /p /s2
Re: [QUICK-VOTE] Release Date for 2.1 final
On Thu, 2003-08-07 at 09:44, Carsten Ziegeler wrote: I just wanted to check what the general feeling for the final release date of 2.1 is. I think we can either release next week (12th) or the week after (19th). I prefer the 12th and don't think that we need one more week. We can make a 2.1.1 were easy anyway. So, to make this thread easier, please only speak up if you think that the 19th is better and give a short reason. I'm fine with either, but one thing that IMO still needs to be done prior to release is remove the old FOM. It is however still used in a few places (xmlform, linotype). People who will use that code as an example for doing their own stuff will end up using the unsupported API. Or maybe we could simply add a big warning on top of the .js files, if nobody wants to update that code right now. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Switching cache to Persistent Store
... Vadim's already answered you on that but another point is that I'm pretty sure there's nothing wrong with the Store(s) or Cache because I don't see this happening in the webapp. You could prove this to yourself by configuring the max-objects param for transient-store in cocoon.xconf to a very small number (like 5) and then watching items go into the persistent storage by using the webapp some. You can then use the sample to clear the MRU store and you'll see that you can still get cached responses out of the persistent-store. I haven't tried all that yet, but I have just got my webapp working via Tomcat rather than Jetty and: * load a sample page * load status page - contains stuff in MRUMemoryStore * restart Tomcat and wait * reload status page - MRU and Default stores are both empty I'm happy that things might make it into the persistent store during the life of a particular invocation of the servlet container. What I'm complaining about is that the persistent store doesn't seem to survive a restart of the servlet container/Cocoon. Regards, Upayavira
Re: [RT] Views for readers
Bertrand Delacretaz wrote:
Le Jeudi, 14 aoû 2003, à 15:53 Europe/Zurich, Sylvain Wallez a écrit :
...But shouldn't we keep labels that are already used into pipelines
? E.g :
map:read src=docs/{1}.doc label=raw, xdoc/
map:generate src=docs/{1}.doc type=word2xml label=raw/
map:transform src=xword2xdoc.xsl label=xdoc/
If it's this way I'd prefer unless-label in map:read to make it clear.
Or maybe
map:read src=docs/{1}.doc unless-label=*/
would do, meaning use this unless any views are requested
(and * would be the only allowed value).
Ah, and this is very easily implementable ;-)
Quickquick, do it before the FS police hears us ;-)
Seriously, I find this useful for indexing and other purposes
(gettting meta-information about binary files, images, etc for example).
Me too. But since is a change in the sitemap syntax, we should have a
vote on this.
Any other proposal or opinion on this subject before we start a vote ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
cvs commit: cocoon-2.1/src/blocks/midi/test/org/apache/cocoon/serialization - New directory
joerg 2003/08/11 14:53:47 cocoon-2.1/src/blocks/midi/test/org/apache/cocoon/serialization - New directory
cvs commit: cocoon-2.1/tools/instrumentation/lib excalibur-instrument-client-2003-03-31.jar excalibur-instrument-client-0.3.jar
joerg 2003/08/07 09:53:34 Added: tools/instrumentation/lib excalibur-instrument-client-2003-03-31.jar Removed: tools/instrumentation/lib excalibur-instrument-client-0.3.jar Log: The naming at excalibur is not unambiguous (no x.x-dev versions), so it's better to name the jar by date. Revision ChangesPath 1.1 cocoon-2.1/tools/instrumentation/lib/excalibur-instrument-client-2003-03-31.jar Binary file
Re: cocoon + MS SQL Server problem
Maybe this is caused by the following recently-fixed bug? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22050 On Sat, 2003-08-09 at 09:21, Leszek Gawron wrote: I am successfully using cocoon as a middle tier to Microsoft SQL Server engine via Microsoft JDBC driver (SP1). I do not really know if this is a cocoon or a JDBC driver issue but I'm unable to determine it without your help. The goal of the project is to provide the end user with alternate client to various accounting systems. The client application resides on Pocket PC based devices (C++) and communicates with middle tier via HTTP (sending and receiving xml instructions and data). Now the problem: One of our customers reported that after some days of my cocoon based middie tier running that his accounting system starts working veeery slow. The only connection point between my system and the accounting system is the database as the original accounting clients connect directly to SQL Server database. - |The fix he found: restart Tomcat on which cocoon resides. The effect is| |immediate and everything goes back to normal (for 2-3 days). | | | |The version installed at custmers site is cocoon-2.1 (cvs version about a | |month old). For my database communication I use __ESQL only__. | - Best regards Leszek Gawron -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: cvs commit: cocoon-2.1 README.txt CREDITS.txt announcement.xml
On Tuesday, Aug 5, 2003, at 16:40 Europe/Rome, Steven Noels wrote: On 5/08/2003 11:49 [EMAIL PROTECTED] wrote: new marketing strategy and dealing with all the due credits and copyright restrictions Thanks for the copyright stuff! Some remarks: + Apache Cocoon is a web development framework built around the concept + of separation of concerns (that is: allowing people to do their job + without having to step on each other toes) and component-oriented web + RAD. The term RAD has a very (out)dated sound in my ears. Surely RAD is OK, but people will hear RAD and understand '4GL'. My rephrasing: Apache Cocoon is a web development framework built around the concepts of separation of concerns (making sure people can interact and collaborate on a project, without stepping on each other toes) and component-based web development. +1 + Cocoon implements these concepts around the notion of 'component + pipelines' modelled after the 'process chain' concept where each + worker specializes on a particular operation. This makes it possible + to use a Lego(tm)-like approach in building web solutions where + these components can be hooked together into pipelines without + requiring further programming. That first sentence is very 'jserv-like'. ;-) I would reduce verbiage into: Cocoon implements these concepts around the notion of 'component pipelines', each component on the pipeline specializing on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions, hooking together components into pipelines without any required programming. +1 + We like to think at Cocoon as web glue for your web application + development needs. But most important, a glue that can keep + concerns separate and allow parallel evolution of the two sides, + improving development pace and reducing the chance of conflicts. What two sides?... Also, maybe we should sound a little bit stronger: Cocoon is web glue for your web application development needs. It is a glue that keeps concerns separate and +1 + Cocoon has been designed to interoperate side-by-side with your J2EE coexist and interoperate? (introducing more verbiage ;-) +1 + existing solutions or give them new functionality without requiring + any change in the existing infrastructure. snip/ +This product includes software developed by the IronSmith Project +(http://www.ironsmith.org/). Eh? the qdox block +Portions are Copyright (c) 2001 Tivano Software GmbH +(http://www.tivano.de). All Rights Reserved. Eh? the spark block +Portions are Copyright (c) 2001 Scott Robert Ladd. All rights reserved. Eh? the jisp library -- Stefano.
DO NOT REPLY [Bug 13070] - [PATCH] Add a new tag xsp-session:getxml to XSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13070. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13070 [PATCH] Add a new tag xsp-session:getxml to XSP --- Additional Comments From [EMAIL PROTECTED] 2003-08-07 13:49 --- What's the status now? Is it a session-fw logicsheet? From the README in the patch I guess no.
Re: [RT] Updating our marketing strategy
Le Mardi, 5 aoû 2003, à 10:29 Europe/Zurich, Steven Noels a écrit : ...I needed something for a conference I'll be speaking, and I came up with: Apache Cocoon is a compelling XML-centric framework compelling sounds like marketingspeak to me, I'd take it out for building serious web applications. Like Konstantin, I find serious not precise enough. heavy-duty? industrial grade? simple or complex? Different from traditional development frameworks, Cocoon provides XML pipelining and aggregation for content composition cleanly separated from a flow definition maybe page flow? and execution context, offering an ideal platform for both content- and logic-driven web applications. How does that sound? Sounds good! -Bertrand
cvs commit: cocoon-2.1/src/blocks/slop/java/org/apache/cocoon/slop/generation SlopGenerator.java
cziegeler2003/08/07 04:08:06 Modified:src/java/org/apache/cocoon/components/treeprocessor/sitemap ActionSetNodeBuilder.java src/blocks/slop/java/org/apache/cocoon/slop/generation SlopGenerator.java Log: Organizing imports Revision ChangesPath 1.3 +1 -2 cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemap/ActionSetNodeBuilder.java Index: ActionSetNodeBuilder.java === RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemap/ActionSetNodeBuilder.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ActionSetNodeBuilder.java 7 Aug 2003 08:42:20 - 1.2 +++ ActionSetNodeBuilder.java 7 Aug 2003 11:08:06 - 1.3 @@ -57,7 +57,6 @@ import org.apache.avalon.framework.configuration.ConfigurationException; import org.apache.avalon.framework.thread.ThreadSafe; import org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder; -import org.apache.cocoon.components.treeprocessor.AbstractProcessingNodeBuilder; import org.apache.cocoon.components.treeprocessor.ProcessingNode; /** 1.2 +10 -11 cocoon-2.1/src/blocks/slop/java/org/apache/cocoon/slop/generation/SlopGenerator.java Index: SlopGenerator.java === RCS file: /home/cvs/cocoon-2.1/src/blocks/slop/java/org/apache/cocoon/slop/generation/SlopGenerator.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- SlopGenerator.java6 Aug 2003 12:59:13 - 1.1 +++ SlopGenerator.java7 Aug 2003 11:08:06 - 1.2 @@ -51,25 +51,24 @@ package org.apache.cocoon.slop.generation; +import java.io.IOException; +import java.io.InputStreamReader; +import java.io.LineNumberReader; +import java.io.Serializable; +import java.util.Map; + import org.apache.avalon.framework.parameters.Parameters; import org.apache.cocoon.ProcessingException; -import org.apache.cocoon.slop.parsing.SimpleSlopParser; -import org.apache.cocoon.slop.interfaces.SlopParser; -import org.apache.cocoon.generation.ComposerGenerator; import org.apache.cocoon.caching.CacheableProcessingComponent; import org.apache.cocoon.environment.SourceResolver; +import org.apache.cocoon.generation.ComposerGenerator; +import org.apache.cocoon.slop.interfaces.SlopParser; +import org.apache.cocoon.slop.parsing.SimpleSlopParser; import org.apache.excalibur.source.Source; import org.apache.excalibur.source.SourceException; import org.apache.excalibur.source.SourceValidity; import org.xml.sax.SAXException; -import org.xml.sax.helpers.AttributesImpl; import org.xml.sax.helpers.LocatorImpl; - -import java.io.IOException; -import java.io.InputStreamReader; -import java.io.LineNumberReader; -import java.io.Serializable; -import java.util.Map; /** * SlopGenerator: Simple Line-Oriented Parsing of text files.
cvs commit: cocoon-2.1/src/blocks/midi/java/org/apache/cocoon/components/midi/xmidi - New directory
joerg 2003/08/11 14:53:47 cocoon-2.1/src/blocks/midi/java/org/apache/cocoon/components/midi/xmidi - New directory
RE: Switching cache to Persistent Store
On 11 Aug 2003 at 12:16, Upayavira wrote: On 11 Aug 2003 at 12:06, Carsten Ziegeler wrote: Upayavira wrote: I've been exploring how to get the CLI to use Cocoon's caching mechanism and environment.isLastModified() to prevent the CLI from generating otherwise cached pages. The problem I currently have is that the cache Cocoon uses is transient, and is thus lost every time the CLI restarts. So: a) How can I switch Cocoon to always use a Persistent cache? Putting cacheparameter name=store value=org.apache.excalibur.store.Store//cache into cocoon.xconf makes CacheImpl pick a persistent store, but for some reason values aren't in the store after Cocoon has been restarted. What do you mean by after Cocoon has been restarted? I'm not sure but it could be possible that the store is cleaned on startup. All I know is that, when the store is transient, the first page that is loaded isn't in the cache. And, when I switch to the persistent store using the cocoon.xconf cache element, the persistent store is picked by CacheImpl, but still the first page isn't in the cache, even after multiple runs. By after Cocoon has restarted I'm referring to the fact that, each time you invoke the CLI, Cocoon starts up from scratch, does its work, and then shuts down. So anything in a transient cache presumably won't survive between invocations of the CLI. b) How can I get Cocoon to use a persisitent store for CLI and a transient one for servlet? By using different configurations, ok dumb answer I know, but the easiest (?) solution is to change the above mentioned store parameter to the required values. Not dumb. But I tried it, but the page still wasn't in the cache after Cocoon had restarted (through debugging in Eclipse), and I could see that CacheImpl was loading a DefaultStore rather than a MRUMemoryStore. And default store is based upon Jisp, which is persistent, no? I'll have more of a look this evening to see if I can spot why it isn't working. Can you give me any pointers to where I should look? Thanks for your help here. I'm pretty green when it comes to caching in Cocoon, but I'm improving rapidly! I've just done a further check which makes this problem easier to see: 1) add the cacheparameter name=store value=org.apache.excalibur.store.Store/ /cache thing to cocoon.xconf. 2) Start Cocoon in Jetty 3) Load a page to get something into the cache, e.g: http://localhost:/samples/hello-world/ 4) Go to http://localhost:/samples/status.html and you'll see your pages in the default store. Correct. 5) Shut down Jetty and restart 6) Go back to http://localhost:/samples/status.html and you're pages have disappeared from the default store. Surely this is wrong! Regards, Upayavira
Re: Garbage or The Quest for the Perfect Template Language
That's a problem with JXTemplateGenerator: it returns a raw
java.lang.Class object from java.util.Locale which doesn't have a
property ITALIAN. I'll try to fix that so it returns a wrapped Class
object that shows static fields as properties as in JavaScript.
In general, I think you're right, though, JXTemplate generator requires
additional tags to support Number, Date, and Message formatting. JSTL
has such tags. If I have time I'll try to add them.
Regards,
Chris
Ugo Cei wrote:
Christopher Oliver wrote:
By the way JXTemplateGenerator adds the capability to call Java
constructors to Jexl, so you can also do this:
jx:out
value='${java.text.SimpleDateFormat(dd/MM/).format(someDate)}'/
OK, this works:
${java.text.SimpleDateFormat(dd/MM/).format(date)}
But this does not:
${java.text.SimpleDateFormat(dd/MM/,java.util.Locale.ITALIAN).format(date)}
and gives the following error:
The choice of Java constructor java.text.SimpleDateFormat matching
JavaScript argument types (string,null) is ambiguous; candidate
constructors are: (java.lang.String,java.text.DateFormatSymbols),
(java.lang.String,java.util.Locale)
Problem with static members?
Ugo
cvs commit: cocoon-2.1/src/webapp/samples/i18n sitemap.xmap
sylvain 2003/08/12 08:48:02
Modified:.status.xml
src/java/org/apache/cocoon/components
ExtendedComponentSelector.java
src/java/org/apache/cocoon/components/treeprocessor/sitemap
ComponentsSelector.java SerializeNode.java
SitemapNodeBuilder.java
src/java/org/apache/cocoon/sitemap
DefaultSitemapComponentSelector.java
src/webapp/samples/i18n sitemap.xmap
Log:
Fix bug #22239 (views on resources don't work)
Revision ChangesPath
1.116 +6 -2 cocoon-2.1/status.xml
Index: status.xml
===
RCS file: /home/cvs/cocoon-2.1/status.xml,v
retrieving revision 1.115
retrieving revision 1.116
diff -u -r1.115 -r1.116
--- status.xml12 Aug 2003 11:37:44 - 1.115
+++ status.xml12 Aug 2003 15:48:02 - 1.116
@@ -202,7 +202,11 @@
changes
release version=@version@ date=@date@
- action dev=CZ type=addDUMMY/action
+ action dev=SW type=fix fixes-bug=22239
+ Views are now always loaded before resources, ensuring proper call of views
from resources.
+ Redeclaring a component (e.g. file generator) with no label attribute was
wrongly inheriting
+ view labels from the same component in the parent sitemap.
+ /action
/release
release version=2.1 date=August 12 2003
action dev=JH type=update fixes-bug=22288 due-to=Mark Leicester
due-to-email=[EMAIL PROTECTED]
1.4 +21 -1
cocoon-2.1/src/java/org/apache/cocoon/components/ExtendedComponentSelector.java
Index: ExtendedComponentSelector.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/ExtendedComponentSelector.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ExtendedComponentSelector.java4 Aug 2003 03:19:22 - 1.3
+++ ExtendedComponentSelector.java12 Aug 2003 15:48:02 - 1.4
@@ -95,6 +95,9 @@
/** The default hint */
protected String defaultHint;
+/** This selector's location (used for debugging purposes) */
+private String location;
+
public ExtendedComponentSelector()
{
super();
@@ -210,6 +213,9 @@
*/
public void configure(Configuration config) throws ConfigurationException {
+// Store location
+this.location = config.getLocation();
+
this.roleName = getRoleName(config);
// Pass a copy of the top-level object to superclass so that
@@ -321,12 +327,26 @@
}
}
+/**
+ * Does this selector or its parent have the given hint ?
+ */
public boolean hasComponent(Object hint) {
boolean exists = super.hasComponent( hint );
if ( !exists this.parentSelector != null ) {
exists = this.parentSelector.hasComponent( hint );
}
return exists;
+}
+
+/**
+ * Does this selector declare a given hint? Check is performed on the
components declared for this
+ * selector only, and strongnot/strong those potentially inherited from the
parent selector.
+ *
+ * @param hint the hint to check for
+ * @return codetrue/code if this selector has the specified hint
+ */
+protected boolean hasDeclaredComponent(Object hint) {
+return super.hasComponent(hint);
}
/* (non-Javadoc)
1.5 +27 -22
cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemap/ComponentsSelector.java
Index: ComponentsSelector.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemap/ComponentsSelector.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ComponentsSelector.java 29 Jul 2003 07:41:26 - 1.4
+++ ComponentsSelector.java 12 Aug 2003 15:48:02 - 1.5
@@ -134,7 +134,7 @@
/** The parent selector, if it's of the current class */
private SitemapComponentSelector parentSitemapSelector;
-
+
/* (non-Javadoc)
* @see
org.apache.cocoon.components.ParentAware#setParentInformation(org.apache.avalon.framework.component.ComponentManager,
java.lang.String)
*/
@@ -165,8 +165,8 @@
public void configure(Configuration config) throws ConfigurationException {
-
-// How are we ?
+
+// Who are we ?
String role = getRoleName(config);
this.roleId = UNKNOWN; // unknown
for (int i = 0; i SELECTOR_ROLES.length; i++) {
@@ -295,17 +295,16 @@
public String
Re: Switching cache to Persistent Store
Upayavira wrote: ... Anyway, I've done some more research, including downloading the source for Avalon (for the first time!) and stepped through the code for the Store. I don't know if this is a problem, but in AbstractJispFilesystemStore, the get and store methods don't seem to match up: get(): value = m_Database.read(this.wrapKeyObject(key), m_Index); and store(): KeyObject[] keyArray = new KeyObject[1]; keyArray[0] = this.wrapKeyObject(key); m_Database.write(keyArray, (Serializable) value); So one uses a wrapped key object, and the other uses an array of wrapped key objects with one element. Does this mean it's not using the same key, and thus can never get at stuff in the persistent store? Is this correct? That's Ok. http://www.coyotegulch.com/docs/jisp/com/coyotegulch/jisp/IndexedObjectDatabase.html [I've still to work out how to compile Avalon, so I can't try it myself yet!] To compile avalon you need maven... Or you can simply put avalon framework jar in the place where it should be and simply run ant in avalon-excalibur/store directory. Vadim
cvs commit: cocoon-2.1/src/blocks/eventcache/conf eventcache.xconf
cziegeler2003/08/11 02:50:40 Modified:src/blocks/eventcache/samples sitemap.xmap src/blocks/eventcache/conf eventcache.xconf Log: The EventAware cache is not the default automatically; only the samples of the eventcache use it Revision ChangesPath 1.2 +7 -1 cocoon-2.1/src/blocks/eventcache/samples/sitemap.xmap Index: sitemap.xmap === RCS file: /home/cvs/cocoon-2.1/src/blocks/eventcache/samples/sitemap.xmap,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- sitemap.xmap 14 Jul 2003 02:50:45 - 1.1 +++ sitemap.xmap 11 Aug 2003 09:50:40 - 1.2 @@ -17,6 +17,11 @@ map:actions map:action name=cacheevent src=org.apache.cocoon.acting.CacheEventAction/ /map:actions +map:pipes default=caching + map:pipe name=event-aware src=org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline +parameter name=cache-role value=org.apache.cocoon.caching.Cache/EventAware/ + /map:pipe +/map:pipes /map:components map:flow language=javascript @@ -30,7 +35,8 @@ /map:views map:pipelines -map:pipeline +map:pipeline type=event-aware + map:match pattern=flow map:call function=cacheEvent/ /map:match 1.2 +1 -2 cocoon-2.1/src/blocks/eventcache/conf/eventcache.xconf Index: eventcache.xconf === RCS file: /home/cvs/cocoon-2.1/src/blocks/eventcache/conf/eventcache.xconf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- eventcache.xconf 14 Jul 2003 02:50:45 - 1.1 +++ eventcache.xconf 11 Aug 2003 09:50:40 - 1.2 @@ -1,6 +1,5 @@ ?xml version=1.0? xconf xpath=/cocoon unless=[EMAIL PROTECTED]'org.apache.cocoon.caching.impl.EventAwareCacheImpl'] - !-- Override default Cache impl and use the event aware version -- - component role=org.apache.cocoon.caching.Cache + component role=org.apache.cocoon.caching.Cache/EventAware class=org.apache.cocoon.caching.impl.EventAwareCacheImpl/ /xconf
Re: FYI: SlopGenerator added (as the unstable slop block)
On Wed, 2003-08-06 at 15:07, Bertrand Delacretaz wrote: SlopGenerator (Simple Line Oriented Parser) I see a class named SimpleSlopParser, which after expansion becomes SimpleSimpleLineOperatorParserParser :-) parses text files using very simple rules, where lines starting with a name and a colon are converted to XML elements. It is usable for parsing RFC822 messages, with some limitations mentioned on the samples page, which shouldn't be hard to remove if someone has an itch to scratch. I think the logical (and annoying) question now is: couldn't chaperon be used? (disclaimer: I don't know anything about either chaperon or slop) -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing 2.1]
* Steven Noels ([EMAIL PROTECTED]) wrote : On 2/08/2003 22:21 Justin Erenkrantz wrote: The trial instance has been up on minotaur (http://minotaur.apache.org:38080/) for little more than a week - so I was wondering whether anyone already had been load-testing it. So far, it seems stable, even after dualit.netcraft.com has been hitting it with a lot of exploit URLs. yup, netcraft do a weekly network examination for apache.org. I'm able to do some load testing myself, but don't want to interfere with ongoing operations, and I'm sure people over here know better where to watch for. Also, I would like your advise as to how to mount the new Wiki location in the cocoon.apache.org namespace: using mod_proxy or mod_jk, and also what we should do with (Tomcat) access log files: disable them and let httpd take care of logging, or add some log rotation scripts. I'd suggest using mod_proxy; when you're happy that you've got the functionality working right, i'd suggest you to talk to root and/or Greg Ames [EMAIL PROTECTED] to get the proxy config done, then test that, then actually let people know about it. I wouldn't bother with tomcat logs, they're fairly awful and HTTPD's will give you nicer usage stats for the whole site should you need them. Cheers -Thom
MIDI block (was: Another music proposal)
On 4/08/2003 21:03, Bertrand Delacretaz [EMAIL PROTECTED] wrote: To me most or all recognizable signature tunes usually become boring once you hear them repeatedly. Quite right. Actually infuriating might be even more accurate. Are you planning on attending the GetTogether 2003? Regrettably no, I shall be back in my home country of New Zealand by October 7th; about as far from Belgium as anyone can be - but I guess a jam via webcam isn't completely out of the question :) Anyhow, here is my first block. This is the MIDI generator, a test case, two sample MIDI files, and a sample pipeline. What is the normal course of action now? Do I ask a committer nicely to commit it for me? If so, here is my block for you, urrr on a block as it were. Attached is the block in a zip, and this is the gump entry (I think this is correct?): project name=cocoon-block-midi status=unstable packageorg.apache.cocoon/package ant target=gump-block property name=block-name value=midi/ property name=version value=@@DATE@@/ /ant depend project=cocoon inherit=all/ work nested=tools/anttasks/ home nested=build/cocoon-@@DATE@@/ jar name=blocks/midi-block.jar/ nag from=Gump to=[EMAIL PROTECTED]/ /project Thanks everyone for all your help - especially the pointers and advice on test cases! Stephan, did I mention that your Cocoon testing code is fantastic and very easy to use. Can you tell that I'm impressed?! Mark midi.zip Description: Binary data
DO NOT REPLY [Bug 19841] - untranslated-text doesn't work for i18n:text
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19841. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19841 untranslated-text doesn't work for i18n:text [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED
cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding JXPathBindingManager.java
bruno 2003/08/12 08:38:55
Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding
JXPathBindingManager.java
Log:
Make ServiceManager available through Assistent
Revision ChangesPath
1.6 +4 -0
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/JXPathBindingManager.java
Index: JXPathBindingManager.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/JXPathBindingManager.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JXPathBindingManager.java 12 Aug 2003 12:56:32 - 1.5
+++ JXPathBindingManager.java 12 Aug 2003 15:38:55 - 1.6
@@ -219,5 +219,9 @@
return datatypeManager;
}
+public ServiceManager getServiceManager() {
+return serviceManager;
+}
+
}
}
Re: An approach to unit testing in Cocoon / MIDIGenerator
On Mon, 4 Aug 2003, Mark Leicester wrote:
On 4/08/2003 15:15, Stephan Michels [EMAIL PROTECTED] wrote:
Have you take a look into
src/test/org/apache/cocoon/AbstractCompositeTestCase.java
Heh, no I haven't seen this at all! Cool! Wow, this is the real thing! Is
this quite new? I looked earlier this year and didn't see anything. I'll try
it out immediately! Are there any docs for these unit testing classes yet? I
looked quickly on the wiki and didn't find anything. If there aren't, I'm
definitely keen to help!
Sorry, no docu. But I think it is pretty easy.
public void testGenerator() {
String src = resource://input.xml;
String result = resource://result.xml;
assertEqual(load(result),
generate(mygenerator, src, EMPTY_PARAMS));
}
You can also test pipelines.
assertEqual(load(result),
transform(mytransformer, src2, EMPTY_PARAMS,
generate(mygenerator, src, EMPTY_PARAMS)));
If you're using request paramters etc. you can easily change them by
public void testRequestAction() {
getRequest().setRequestURI(test.xml?abc=defghi=jkl);
getRequest().setQueryString(abc=defghi=jkl);
getRequest().setContextPath(servlet);
getRequest().addParameter(abc, def);
Parameters parameters = new Parameters();
parameters.setParameter(parameters, true);
Map result = act(request, null, parameters);
assertNull(Test for parameter, (String)result.get(ghi));
}
The setup of the xtest file is a bit difficult, but using the
ExcaliburTestCase ensures that all lifecycle methods will be handled
correct.
Stephan.
Re: Cocoon uses unstable EventCache by default
Carsten Ziegeler wrote: Vadim Gritsenko wrote: Geoff Howard wrote: It seems to me that this block is somewhat different from many others. Disabling Linotype or not because it is unstable won't affect the basic running of your Cocoon setup. However, the EventCache is directly overriding something central to a Cocoon system, i.e. its cache, with code marked unstable. This doesn't seem ideal to me. True that this is different than others - I'm fine to mark it excluded by default if there's still a level of concern. Please turn it off till 2.1 release is out. Then, you can switch it back on :) I turned it off for the release, but the samples of the eventcache should still use it. You can configure each pipeline with the cache to use and I did this for the samples. Great solution - thanks. Geoff
