from:"Thorsten Scherler"


On 20/05/2010, at 11:30, Sjur Moshagen wrote:

 Hi all,
 
 There seems to be certain problems with Dispatcher and the non-ascii 
 characters in the Latin 1 range. The following two screenshots illustrate the 
 problem:
 
 Skins-based site:
 Latin1-chars-skins.png
 
 Dispatcher-based site:
 Latin1-chars-dispatcher.png
 
 As you can see, it is not generally UTF-8 characters, it seems to effect only 
 those characters that are in the Latin1 set.
 
 This is with the latest Forrest trunk, I haven't yet checked which revision 
 introduced this bug.
 

that should be fixed with FOR-1194. Make sure your contract and the structurer 
is utf-8. How are you producing the boxes?

 MacOS X 10.6.3
 

I had the same problem on a mac, our company blog is utf-8 and has some 
characters like ¿ñ so in FOR-1194 I forced the use of UTF-8.

salu2

 java version 1.6.0_20
 Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
 Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
 
 
 Best,
 Sjur
 

Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: svn commit: r945269 - in /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src: cocoon-2.2-block/src/main/resources/COB-INF/ cocoon-2.2-block/src/main/resources/META


On 18/05/2010, at 02:51, Thorsten Scherler wrote:

 
 On 18/05/2010, at 02:46, Thorsten Scherler wrote:
 
 
 On 18/05/2010, at 01:59, Thorsten Scherler wrote:
 
 
 On 17/05/2010, at 23:24, Tim Williams wrote:
 
 Hi Thorsten, is this working for you locally?  I noticed the
 Forrestbot failure just now and I'm also failing locally (with a NPE)
 on a dispatcher sample site.  Was thinking it might be related but
 don't see anything obvious in here...
 
 Hmm, really weird. I did a quick debug and it seems the problem is in 
 xsl:include href=cocoon://prepare.contract.html.helper-render-image /
 If you comment this line then it will work again.
 
 I ATM not sure what happens and am flying out in a couple of hours, I will 
 try to have a look again tomorrow but if you want you can revert the commit 
 or comment the contract in the structurer.
 
 The problem seems to be 
 xsl:include href=cocoon://prepare.contract.html.element/xsl:include
 
 However I am not sure, need to go to bed now.
 
 I did a quick try and reverting is fixing it. 

The forrestbot did not report any more failure since r946337, so I guess that 
fixed it. Sorry again and thanks Tim for the quick headsup.

salu2

Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: Latin1 character problems in dispatcher


On 20/05/2010, at 12:45, Sjur Moshagen wrote:

 Den 20. mai. 2010 kl. 12.48 skrev Thorsten Scherler:
 
 On 20/05/2010, at 11:30, Sjur Moshagen wrote:
 
 Hi all,
 
 There seems to be certain problems with Dispatcher and the non-ascii 
 characters in the Latin 1 range. The following two screenshots illustrate 
 the problem:
 
 Skins-based site:
 Latin1-chars-skins.png
 
 Dispatcher-based site:
 Latin1-chars-dispatcher.png
 
 As you can see, it is not generally UTF-8 characters, it seems to effect 
 only those characters that are in the Latin1 set.
 
 This is with the latest Forrest trunk, I haven't yet checked which revision 
 introduced this bug.
 
 
 that should be fixed with FOR-1194. Make sure your contract and the 
 structurer is utf-8.
 
 They should be utf-8 all of them, they have the xml declaration:
 
 ?xml version=1.0 encoding=UTF-8?
 
 How are you producing the boxes?
 
 I'm using the following Forrest-doc v2 code:
 
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V2.0//EN
 http://forrest.apache.org/dtd/document-v20.dtd;
 document xml:lang=en
  header
titleDivvun - Sámi proofing tools project/title
  /header
 
  body
 
   note label=UTF-8 character test
 There seems to be problems with certain characters, but only in
 Dispatcher:br/
 a á c č d đ n ŋ s š t ŧ z ž ae æ oe ø ao å a¨ ä o¨ ö g ǥ h ħ u ʉ i ɨ
   /note
  /body
 /document
 
 stored in an utf-8 encoded file.
 
 MacOS X 10.6.3
 
 
 I had the same problem on a mac, our company blog is utf-8 and has some 
 characters like ¿ñ so in FOR-1194 I forced the use of UTF-8.
 
 ok. despite this, I still get the bug, after having checked the contract and 
 structurer files.


Are you using the latest head revision, because I had a similar usecase and 
after the fix it works fine.

Make sure you did a clean before building again.

salu2
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: Latin1 character problems in dispatcher


On 20/05/2010, at 14:18, Sjur Moshagen wrote:
 ...
 Hmm, that is weird. Please try the following:
 - add a new contract that uses ñ, í and similar characters
 - see what comes out
 
 I added a blank contract that just printed the same line of characters I used 
 earlier for testing, and this is what came out:
 
 This is a text containing problematic characters:
 a á c č d đ n ŋ s š t ŧ z ž ae æ oe ø ao å a¨ ä o¨ ö g ǥ h ħ u ʉ i ɨ
 
 That is, the text from the contract comes through just fine, but text coming 
 from a standard Forrest v2 document gets garbled.
 
 I have attached a picture of the page as it renders. The box comes from the 
 document, the text at the bottom is from the contract.

Ok I see. 

Please post the dataUri you use for the contract. It seems that the utf-8 is 
lost in this step. If you have the dataUrl of the contract see what is coming 
out there, whether it is already scrambled or not.

salu2

 
 further can you open a terminal and tell me what the output of locale are?
 
 $ locale
 LANG=no_NO.UTF-8
 LC_COLLATE=no_NO.UTF-8
 LC_CTYPE=no_NO.UTF-8
 LC_MESSAGES=no_NO.UTF-8
 LC_MONETARY=no_NO.UTF-8
 LC_NUMERIC=no_NO.UTF-8
 LC_TIME=no_NO.UTF-8
 LC_ALL=no_NO.UTF-8
 
 Sjur
 

Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: Dispatcher Specific characters #160; problem

On 07/04/2010, at 13:56, Cyriaque Dupoirieux wrote:

le 07/04/2010 13:50 Thorsten Scherler a écrit :
On 31/03/2010, at 11:48, Cyriaque Dupoirieux wrote:

Hi,

I have problems with the dispatcher which generate strange
charachters - generally Â instead of #160; which should be a blank if I
remember...
These characters drive me to a second error during pdf generation :
[Fatal Error] :6:25: Invalid byte 2 of 3-byte UTF-8 sequence.

I tried to remove #160; from
forrest\build\plugins\org.apache.forrest.plugin.internal.dispatcher\themer\themes\common\html\branding-fontsize.contract.xml
to make a test and then it's OK, the special characters are not generated.

I wonder if I am the only one and if my machine needs a specific
configuration or if we should remove these characters from the dispatcher.

It should work fine, however I must admit that I have not tested the pdf
part very well.

I will try this week and report back.

It seems that there are some problems with encoding format (cf. previous
thread forrest-sample-2 FAILED and build test failed: Could not resolve
locat)
This occurs for some dispatcher intermediate files and on Windoze.
I am going to check in a Mandriva Linux when I have time...

I can confirm this in Linux the encoding is UTF-8 and fine but as soon I try on
MAC I see the characters screwed up. :(

It seems a problem with the jvm.

Try to start the jvm with -Dfile.encoding=UTF-8

salu2

Salutations,
Cyriaque

salu2

Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

[jira] Created: (FOR-1194) Dispatcher does not force UTF-8 usage

2010-05-17 Thread Thorsten Scherler (JIRA)

Dispatcher does not force UTF-8 usage
-

 Key: FOR-1194
 URL: https://issues.apache.org/jira/browse/FOR-1194
 Project: Forrest
  Issue Type: Bug
  Components: Whiteboard: Dispatcher (stax)
Reporter: Thorsten Scherler
Priority: Critical


There is a problem in the dispatcher which seems only occur in Windows and Mac. 
In linux it is working fine.

If you create a contract and add e.g. #191;#241;#220;#237;  which is 
something like ü ñ ¿ it will become ¬ø√±√ú√≠ 

I am investigating since 2 days now and I identify the following code where the 
encoding get lost in Mac os. Actually everything that goes into the 
transformation is utf-8. after the transformer.transform(saxSource, 
streamResult); it is lost. 

XSLContractHelper.java

  public void transform(InputStream dataStream, Result streamResult)
  throws ContractException {
//Source dataSource = new StreamSource(dataStream);
try {
  InputSource inputSource = new InputSource(new 
InputStreamReader(dataStream, UTF-8));
  inputSource.setEncoding(UTF-8);
  SAXSource saxSource = new SAXSource(xmlReader,inputSource);
  transformer.transform(saxSource, streamResult);
} catch (Exception e) {
  String message = The xsl transformation has thrown an exception. for 
+ the contract \+name+\.\nPlease see some FAQ:
  + \n
  + e
  + \n\nproblem-solution:\n
  + - org.apache.xpath.XPathException: Can not convert #STRING to a 
NodeList!\n
  + - Try to activate \allowXml\ and/or \shrink\. If this is not 
working try the contract 
  + xsl standalone and make sure it is not a xsl specific problem.;
  throw new ContractException(message);
}
  }

This method is invoked from XSLContract.java, The out.toString is scrampled:
public BufferedInputStream execute(InputStream dataStream,
  MapString, Object properties) throws ContractException {
...
 ByteArrayOutputStream out = new ByteArrayOutputStream();
// create a StreamResult and use it for the transformation
try {
OutputStreamWriter writer = new OutputStreamWriter(out,UTF-8);
Result streamResult = new StreamResult(writer);
helper.transform(dataStream,streamResult);
} catch (Exception e) {
  String message = Could not invoke the transformation for 
  + the contract \+name+\. +\n+ e;
  throw new ContractException(message);
}
log.debug(out.toString());
...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (FOR-1194) Dispatcher does not force UTF-8 usage

2010-05-17 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOR-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler closed FOR-1194.
--

Resolution: Fixed

In the end the problem was in the last step that:

Index: 
../java/org/apache/forrest/dispatcher/transformation/DispatcherWrapperTransformer.java
===
--- 
../java/org/apache/forrest/dispatcher/transformation/DispatcherWrapperTransformer.java
  (revision 940483)
+++ 
../java/org/apache/forrest/dispatcher/transformation/DispatcherWrapperTransformer.java
  (working copy)
@@ -374,7 +374,7 @@
   }
   // get the result of the structurer as stream
   InputStream result = structurer.execute(new BufferedInputStream(
-  new ByteArrayInputStream(document.getBytes())), requestedFormat);
+  new ByteArrayInputStream(document.getBytes(UTF-8))), 
requestedFormat);
   // requesting a parser
   parser = (SAXParser) manager.lookup(SAXParser.ROLE);
   // adding the result to the consumer

Committed revision 945269.

 Dispatcher does not force UTF-8 usage
 -

 Key: FOR-1194
 URL: https://issues.apache.org/jira/browse/FOR-1194
 Project: Forrest
  Issue Type: Bug
  Components: Whiteboard: Dispatcher (stax)
Reporter: Thorsten Scherler
Priority: Critical

 There is a problem in the dispatcher which seems only occur in Windows and 
 Mac. In linux it is working fine.
 If you create a contract and add e.g. #191;#241;#220;#237;  which is 
 something like ü ñ ¿ it will become ¬ø√±√ú√≠ 
 I am investigating since 2 days now and I identify the following code where 
 the encoding get lost in Mac os. Actually everything that goes into the 
 transformation is utf-8. after the transformer.transform(saxSource, 
 streamResult); it is lost. 
 XSLContractHelper.java
   public void transform(InputStream dataStream, Result streamResult)
   throws ContractException {
 //Source dataSource = new StreamSource(dataStream);
 try {
   InputSource inputSource = new InputSource(new 
 InputStreamReader(dataStream, UTF-8));
   inputSource.setEncoding(UTF-8);
   SAXSource saxSource = new SAXSource(xmlReader,inputSource);
   transformer.transform(saxSource, streamResult);
 } catch (Exception e) {
   String message = The xsl transformation has thrown an exception. for 
 + the contract \+name+\.\nPlease see some FAQ:
   + \n
   + e
   + \n\nproblem-solution:\n
   + - org.apache.xpath.XPathException: Can not convert #STRING to a 
 NodeList!\n
   + - Try to activate \allowXml\ and/or \shrink\. If this is 
 not working try the contract 
   + xsl standalone and make sure it is not a xsl specific problem.;
   throw new ContractException(message);
 }
   }
 This method is invoked from XSLContract.java, The out.toString is scrampled:
 public BufferedInputStream execute(InputStream dataStream,
   MapString, Object properties) throws ContractException {
 ...
  ByteArrayOutputStream out = new ByteArrayOutputStream();
 // create a StreamResult and use it for the transformation
 try {
 OutputStreamWriter writer = new OutputStreamWriter(out,UTF-8);
 Result streamResult = new StreamResult(writer);
 helper.transform(dataStream,streamResult);
 } catch (Exception e) {
   String message = Could not invoke the transformation for 
   + the contract \+name+\. +\n+ e;
   throw new ContractException(message);
 }
 log.debug(out.toString());
 ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r945269 - in /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src: cocoon-2.2-block/src/main/resources/COB-INF/ cocoon-2.2-block/src/main/resources/META

())), requestedFormat);
 +  new ByteArrayInputStream(document.getBytes(UTF-8))), 
 requestedFormat);
   // requesting a parser
   parser = (SAXParser) manager.lookup(SAXParser.ROLE);
   // adding the result to the consumer
 
 
 

Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: svn commit: r945269 - in /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src: cocoon-2.2-block/src/main/resources/COB-INF/ cocoon-2.2-block/src/main/resources/META


On 18/05/2010, at 01:59, Thorsten Scherler wrote:

 
 On 17/05/2010, at 23:24, Tim Williams wrote:
 
 Hi Thorsten, is this working for you locally?  I noticed the
 Forrestbot failure just now and I'm also failing locally (with a NPE)
 on a dispatcher sample site.  Was thinking it might be related but
 don't see anything obvious in here...
 
 Hmm, really weird. I did a quick debug and it seems the problem is in 
 xsl:include href=cocoon://prepare.contract.html.helper-render-image /
 If you comment this line then it will work again.
 
 I ATM not sure what happens and am flying out in a couple of hours, I will 
 try to have a look again tomorrow but if you want you can revert the commit 
 or comment the contract in the structurer.

The problem seems to be 
xsl:include href=cocoon://prepare.contract.html.element/xsl:include

However I am not sure, need to go to bed now.

salu2

 
 salu2
 
 
 --tim
 
 On Mon, May 17, 2010 at 1:42 PM,  thors...@apache.org wrote:
 Author: thorsten
 Date: Mon May 17 17:42:05 2010
 New Revision: 945269
 
 URL: http://svn.apache.org/viewvc?rev=945269view=rev
 Log:
 FOR-1194 Fixing utf-8 compability by forcing to use UTF-8 in every step
 
 Modified:
   
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/sitemap.xmap
   
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/META-INF/cocoon/avalon/dispatcher-sitemapcomponents.xconf
   
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/impl/XSLContract.java
   
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/impl/helper/XSLContractHelper.java
   
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherTransformer.java
   
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherWrapperTransformer.java
 
 Modified: 
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/sitemap.xmap
 URL: 
 http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/sitemap.xmap?rev=945269r1=945268r2=945269view=diff
 ==
 --- 
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/sitemap.xmap
  (original)
 +++ 
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/sitemap.xmap
  Mon May 17 17:42:05 2010
 @@ -22,7 +22,7 @@ xmlns:map=http://apache.org/cocoon/site
map:pipeline id=lm
  map:match pattern=locationmap.xml
map:generate src=locationmap.xml /
 -map:serialize type=xml /
 +map:serialize/
  /map:match
/map:pipeline
map:pipeline id=dispatcher
 @@ -61,7 +61,7 @@ xmlns:map=http://apache.org/cocoon/site
/map:transform
map:transform src=lm://hooks-to-fo.xsl /
map:transform src=lm://strip-dispatcher-remains-fo.xsl /
 -map:serialize type=xml /
 +map:serialize/
  /map:match
  map:match pattern=**.prepare.dispatcher.css
map:generate src=lm://resolve.structurer.{1} type=jx
 @@ -93,11 +93,11 @@ xmlns:map=http://apache.org/cocoon/site
  map:act type=locale
map:match pattern=resolve.structurer.**
  map:generate src=lm://resolve.structurer.{1} /
 -  map:serialize type=xml /
 +  map:serialize/
/map:match
map:match pattern=resolve.contract.*.**
  map:generate src={lm:resolve.contract.{1}.{2}} /
 -  map:serialize type=xml /
 +  map:serialize/
/map:match
map:match pattern=prepare.contract.*.**
  map:generate src={lm:resolve.contract.{1}.{2}} /
 @@ -105,7 +105,7 @@ xmlns:map=http://apache.org/cocoon/site
  map:transform type=i18n
map:parameter name=locale value={../locale} /
  /map:transform
 -  map:serialize type=xml /
 +  map:serialize/
/map:match
  /map:act
/map:pipeline
 @@ -116,7 +116,7 @@ xmlns:map=http://apache.org/cocoon/site
  map:match pattern=prepare.panels.**
map:generate src={lm:resolve.panels.{1}} /
map:transform src={lm:root-strip.xsl} /
 -map:serialize type=xml /
 +map:serialize/
  /map:match
/map:pipeline
map:pipeline
 @@ -126,7 +126,7 @@ xmlns:map=http://apache.org/cocoon/site
  map:parameter name=path value={1}.html /
  map:parameter name=theme value={global:dispatcher.theme

Re: svn commit: r945269 - in /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src: cocoon-2.2-block/src/main/resources/COB-INF/ cocoon-2.2-block/src/main/resources/META


On 18/05/2010, at 02:46, Thorsten Scherler wrote:

 
 On 18/05/2010, at 01:59, Thorsten Scherler wrote:
 
 
 On 17/05/2010, at 23:24, Tim Williams wrote:
 
 Hi Thorsten, is this working for you locally?  I noticed the
 Forrestbot failure just now and I'm also failing locally (with a NPE)
 on a dispatcher sample site.  Was thinking it might be related but
 don't see anything obvious in here...
 
 Hmm, really weird. I did a quick debug and it seems the problem is in 
 xsl:include href=cocoon://prepare.contract.html.helper-render-image /
 If you comment this line then it will work again.
 
 I ATM not sure what happens and am flying out in a couple of hours, I will 
 try to have a look again tomorrow but if you want you can revert the commit 
 or comment the contract in the structurer.
 
 The problem seems to be 
 xsl:include href=cocoon://prepare.contract.html.element/xsl:include
 
 However I am not sure, need to go to bed now.

I did a quick try and reverting is fixing it. 

Sorry!

salu2

 
 salu2
 
 
 salu2
 
 
 --tim
 
 On Mon, May 17, 2010 at 1:42 PM,  thors...@apache.org wrote:
 Author: thorsten
 Date: Mon May 17 17:42:05 2010
 New Revision: 945269
 
 URL: http://svn.apache.org/viewvc?rev=945269view=rev
 Log:
 FOR-1194 Fixing utf-8 compability by forcing to use UTF-8 in every step
 
 Modified:
  
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/sitemap.xmap
  
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/META-INF/cocoon/avalon/dispatcher-sitemapcomponents.xconf
  
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/impl/XSLContract.java
  
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/impl/helper/XSLContractHelper.java
  
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherTransformer.java
  
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherWrapperTransformer.java
 
 Modified: 
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/sitemap.xmap
 URL: 
 http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/sitemap.xmap?rev=945269r1=945268r2=945269view=diff
 ==
 --- 
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/sitemap.xmap
  (original)
 +++ 
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/sitemap.xmap
  Mon May 17 17:42:05 2010
 @@ -22,7 +22,7 @@ xmlns:map=http://apache.org/cocoon/site
   map:pipeline id=lm
 map:match pattern=locationmap.xml
   map:generate src=locationmap.xml /
 -map:serialize type=xml /
 +map:serialize/
 /map:match
   /map:pipeline
   map:pipeline id=dispatcher
 @@ -61,7 +61,7 @@ xmlns:map=http://apache.org/cocoon/site
   /map:transform
   map:transform src=lm://hooks-to-fo.xsl /
   map:transform src=lm://strip-dispatcher-remains-fo.xsl /
 -map:serialize type=xml /
 +map:serialize/
 /map:match
 map:match pattern=**.prepare.dispatcher.css
   map:generate src=lm://resolve.structurer.{1} type=jx
 @@ -93,11 +93,11 @@ xmlns:map=http://apache.org/cocoon/site
 map:act type=locale
   map:match pattern=resolve.structurer.**
 map:generate src=lm://resolve.structurer.{1} /
 -  map:serialize type=xml /
 +  map:serialize/
   /map:match
   map:match pattern=resolve.contract.*.**
 map:generate src={lm:resolve.contract.{1}.{2}} /
 -  map:serialize type=xml /
 +  map:serialize/
   /map:match
   map:match pattern=prepare.contract.*.**
 map:generate src={lm:resolve.contract.{1}.{2}} /
 @@ -105,7 +105,7 @@ xmlns:map=http://apache.org/cocoon/site
 map:transform type=i18n
   map:parameter name=locale value={../locale} /
 /map:transform
 -  map:serialize type=xml /
 +  map:serialize/
   /map:match
 /map:act
   /map:pipeline
 @@ -116,7 +116,7 @@ xmlns:map=http://apache.org/cocoon/site
 map:match pattern=prepare.panels.**
   map:generate src={lm:resolve.panels.{1}} /
   map:transform src={lm:root-strip.xsl} /
 -map:serialize type=xml /
 +map:serialize/
 /map:match
   /map:pipeline
   map:pipeline
 @@ -126,7 +126,7 @@ xmlns:map=http://apache.org/cocoon/site
 map:parameter name=path value={1}.html

Re: Subversion client configuration (Was: svn commit: r941344 ...common/html/helper-copyover.contract.xml

2010-05-12 Thread Thorsten Scherler


On 12/05/2010, at 00:48, David Crossley wrote:

 Thorsten, it seems that your Subversion client has configuration problems.
 Missing eol-style and should not be executable.
 
 See:
 http://apache.org/dev/#svn
 http://apache.org/dev/version-control.html#https-svn-config

Thanks for spotting this and sorry for any inconvenience.

salu2

 
 -David
 
 Author: thorsten
 Date: Wed May  5 15:28:14 2010
 New Revision: 941344
 
 URL: http://svn.apache.org/viewvc?rev=941344view=rev
 Log:
 adding helper to copy the input
 
 Added:

 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/resource/themer/themes/common/html/helper-copyover.contract.xml
(with props)
 
 Added: 
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/resource/themer/themes/common/html/helper-copyover.contract.xml
 URL: 
 http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/resource/themer/themes/common/html/helper-copyover.contract.xml?rev=941344view=auto
 ==
 --- 
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/resource/themer/themes/common/html/helper-copyover.contract.xml
  (added)
 
 [snip ]
 
 Propchange: 
 forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/cocoon-2.2-block/src/main/resources/COB-INF/resource/themer/themes/common/html/helper-copyover.contract.xml
 --
svn:executable = *
 
 

Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: Merging back the dispatcher

2010-04-27 Thread Thorsten Scherler


On 27/04/2010, at 08:04, David Crossley wrote:

 Tim Williams wrote:
 
 Well, if the dispatcher is all that changed in such a release, we
 could do a 0.91 afterwards.  I think there's another consideration
 that I didn't mention too.  I feel irresponsible releasing software
 that we can't support and I'm concerned that this would be the case
 with the dispatcher.  I have a difficult enough time now digging up
 Cocoon knowledge when questions come across but with
 dispatcher-related ones I have no clue.  Maybe it's an unfounded
 concern, I dunno...
 
 I have the same concerns.
 
 Perhaps we should get 0.9 released ASAP,
 then make a concerted effort to build a Dispatcher
 community. Make another release soon after.


I understand what you are all saying, but the dispatcher is basically one 
transformer and the usage of locationmap for resolving the structurer and 
contracts. There is not much more to it. 

salu2

Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: Dispatcher Specific characters #160; problem

2010-04-07 Thread Thorsten Scherler


On 31/03/2010, at 11:48, Cyriaque Dupoirieux wrote:

 Hi,
 
I have problems with the dispatcher which generate strange
 charachters - generally Â instead of #160; which should be a blank if I
 remember...
These characters drive me to a second error during pdf generation :
 [Fatal Error] :6:25: Invalid byte 2 of 3-byte UTF-8 sequence.
 
I tried to remove #160; from
 forrest\build\plugins\org.apache.forrest.plugin.internal.dispatcher\themer\themes\common\html\branding-fontsize.contract.xml
 to make a test and then it's OK, the special characters are not generated.
 
I wonder if I am the only one and if my machine needs a specific
 configuration or if we should remove these characters from the dispatcher.

It should work fine, however I must admit that I have not tested the pdf part 
very well.

I will try this week and report back.

salu2

Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: [VOTE] - Upgrade Java Version to 1.5

2010-03-05 Thread Thorsten Scherler


On 04/03/2010, at 01:02, Gav... wrote:

 Hi All,
 
 This vote is to move 'trunk' to using java version 1.5.


+1

Thanks Gavin to bring the ball rolling.

salu2


Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

RE: Can't get Dispatcher working at all windows/linux from trunk

2010-02-22 Thread Thorsten Scherler

On Mon, 2010-02-22 at 20:22 +1000, Gav... wrote:

  -Original Message-
  From: David Crossley [mailto:cross...@apache.org]
  Sent: Monday, 22 February 2010 8:11 PM
  To: dev@forrest.apache.org
  Subject: Re: Can't get Dispatcher working at all windows/linux from
  trunk

  Gav... wrote:

   I see Davids thread 'strange dispatcher behaviour after merge' is
  exactly the same problems
   as I am getting now. David, I see no follow up solution, what did you
  do to get it going again?

   I also note Brian says he is not having any issues either, Brian,
  what did you need to change
   to get dispatcher in current trunk working for you?

  I did *not* get it working. I needed to go back to before
  the Dispatcher merge. I did 'svn up' to r882421 2009-11-20.

 Ah right, ok, same as what I did then, 'somebody' must have it working 
 and it needs to be sorted soon otherwise it doesn't belong in trunk.

Hmm, I will try now as well. Can you post the exception that you got
again, please?

  As said before, one of the issues is the agreed Java base version.
  See the build.compiler.vm parameter in our build.xml
  and instructions in the Release documentation and recent discussion
  in these dev archives.

 Yep, I read briefly but need to go back in case I missed something.

 One thing is for sure, the forward momentum of this project depends on this
 being resolved, and soon. We should vote on a minimum version of java soon, 
 then work on fixing it for that version - as tried and tested as much as I 
 have, dispatcher for me doesn't work in any of them.

I personally prefer to use 1.6 as minimum since 1.4 and 1.5 are not
officially supported anymore. However to make the dispatcher work with
1.4 is not that hard since it is mostly generic compilation exception. 

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

[Fwd: RE: Can't get Dispatcher working at all windows/linux from trunk]

2010-02-22 Thread Thorsten Scherler


-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)



---BeginMessage---
On Mon, 2010-02-22 at 22:00 +1000, Gavin wrote:
 On Mon, 2010-02-22 at 11:48 +0100, Thorsten Scherler wrote:
  On Mon, 2010-02-22 at 20:22 +1000, Gav... wrote:
   
-Original Message-
From: David Crossley [mailto:cross...@apache.org]
Sent: Monday, 22 February 2010 8:11 PM
To: dev@forrest.apache.org
Subject: Re: Can't get Dispatcher working at all windows/linux from
trunk

Gav... wrote:

 I see Davids thread 'strange dispatcher behaviour after merge' is
exactly the same problems
 as I am getting now. David, I see no follow up solution, what did you
do to get it going again?

 I also note Brian says he is not having any issues either, Brian,
what did you need to change
 to get dispatcher in current trunk working for you?

I did *not* get it working. I needed to go back to before
the Dispatcher merge. I did 'svn up' to r882421 2009-11-20.
   
   Ah right, ok, same as what I did then, 'somebody' must have it working 
   and it needs to be sorted soon otherwise it doesn't belong in trunk.
  
  Hmm, I will try now as well. Can you post the exception that you got
  again, please?
 
 Its pasted into the bottom of the original message in this thread
 earlier today. However there may be no need, see below
 
  
  
  
   

As said before, one of the issues is the agreed Java base version.
See the build.compiler.vm parameter in our build.xml
and instructions in the Release documentation and recent discussion
in these dev archives.
   
   Yep, I read briefly but need to go back in case I missed something.
 
 And there lies the clue!
 
 Despite having set default java to either 1.5 or 1.6, despite setting
 JAVA_HOME to point to 1.5 or 1.6, it still compiled using 1.4 due to the
 fact that the build.compiler.vm was still set at 1.4 !!
 
 I have now brought my local copy back up to trunk:HEAD, changed the
 setting to 1.5, changed the JAVA_HOME to 1.5 and Dispatcher now works
 fine on Windows and Linux !!
 
 (Have others tried that and had success/failure)
 
 Looking at the Forrest Zone at
 
 http://forrest.zones.apache.org/ft/build/forrest-sample-2/
 
 it is clearly not using Dispatcher.
 
 I also tested in 1.6 and get the following compile errors:
 
 compile:
 Created dir: /home/gmcdonald/asf/forrest/build/classes
 Compiling 33 source files to /home/gmcdonald/asf/forrest/build/classes
 /home/gmcdonald/asf/forrest/main/java/org/apache/forrest/util/IdGeneratorTransformer.java:177:
  unmappable character for encoding UTF8
 //- a href=#Quelques+r%E8gles...Quelques
 r�gles.../a
   ^
 /home/gmcdonald/asf/forrest/main/java/org/apache/forrest/util/IdGeneratorTransformer.java:180:
  unmappable character for encoding UTF8
 //- a href=#Quelques+r%C3%A8gles...Quelques
 r�gles.../a
  ^
 2 errors
 
 So, getting closer to having 1.6 work too.

Hmm, that is under Windows right?

I have seen it before in other projects.

 
   
   One thing is for sure, the forward momentum of this project depends on 
   this
   being resolved, and soon. We should vote on a minimum version of java 
   soon, 
   then work on fixing it for that version - as tried and tested as much as 
   I 
   have, dispatcher for me doesn't work in any of them.
  
  I personally prefer to use 1.6 as minimum since 1.4 and 1.5 are not
  officially supported anymore. However to make the dispatcher work with
  1.4 is not that hard since it is mostly generic compilation exception. 
 
 If others can test, and it is as simple as upping the build.compiler.vm
 setting, then I say we should do it right now, but others may have other
 views.

Well, nothing is fater to raise build.compiler.vm settings other then
having a vote. ...but I reckon it should not hard to get it 1.4 conform
my problem is ATM I am having too much commercial work to actually do
some coding on the dispatcher.

 
 As we are still in the 0.X range of release versions, then if we can fix
 the above UTF8 problem I'd be happy to go straight to 1.6

If you under windows I could ask a co worker that had the similar
problem.

aslu2

 
 
 Thanks for looking into it.
 
 Gav...
 
  
  salu2
 
 
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)



---End Message---

Re: [OT] Send xml email from html form data

2009-12-30 Thread Thorsten Scherler


On 27/12/2009, at 14:54, Gav... wrote:

 Hi All,
  
 Off topic sorry, but thought someone here might know the best approach.
  
 I’m trying to create an xml output file from form data of an  html web page.

hmm you mean take the different request parameter and convert them into xml?

Could be easily done with a java loop, but normally you get each request 
parameter one by one and do something with it.

salu2

  
 Is there a program out there to do this or what would be a sensible approach
 In handing this? Perhaps an xslt stylesheet to convert a txt output document 
 but
 I was hoping there was a more direct route.
  
 Thanks
  
 Gav...

Java version of plugins/main (was Re: strange Dispatcher behaviour after merge)

2009-12-06 Thread Thorsten Scherler


On 05/12/2009, at 01:25, David Crossley wrote:

 Dispatcher seems to have some strange behaviours after the recent merge.
 I don't have much time, so here is a quick dump of notes.
 Perhaps someone else can raise Jira issues for them.
 
 Using Java-1.5
 
 1) Rebuild forrest. All seems okay.
 2) cd 
 $FORREST_HOME/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher
 3) rm -rf build
 3) $FORREST_HOME/tools/ant/bin/ant local-deploy
 4) Get compilation errors and BUILD FAILED (see [A])
 
 It sounds like someone needs to get the PMC to agree on
 increasing the base Java version.

You are right that a version change needs a PMC vote. When I did the rewrite of 
the dispatcher I was using 1.5 and 1.6 since I do not use 1.4 since a long 
time. 

Regarding the support of 1.4, the EOSL transition period began Dec, 11 2006 and 
completed October 30th, 2008, meaning 1.4 is only supported for Solaris user.
Regarding the support for 1.5 it reached its End of Service Life (EOSL) on 
November the 3rd 2009.

Like said dispatcher is ATM 1.5 due to use of generics and a couple of other 
things (annotations). It should not be hard to fix this, if we decide to keep 
our support for 1.4.

However in the light of above (1.4 and 1.5 reached their EOSL) I think we 
should raise the minimum version of forrest to at least 1.5 if not 1.6.

salu2

Re: Merging back the dispatcher

2009-12-03 Thread Thorsten Scherler

On Wed, 2009-12-02 at 13:35 +0100, Thorsten Scherler wrote:
 Hi all,
 
 I will try to merge back the dispatcher branch into trunk and re-do all
 the following commits:
 733422
 734387
 734405
 734546
 734605
 773472
 795708
 816460
 816466
 
 Please if you use trunk and the dispatcher make sure that it might be
 broken temporary.

733422 - done
734387 - already ok
734405 - done
734546 - done
734605 - already ok
773472 - already ok
795708 - done
816460 - done
816466 - done

All commits have been redone. I will add now the note that the branch is
closed.

salu2

 salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: svn commit: r886758 - /forrest/branches/dispatcher_rewrite/STATUS.txt

2009-12-03 Thread Thorsten Scherler

On Thu, 2009-12-03 at 07:24 -0500, Tim Williams wrote:
 On Thu, Dec 3, 2009 at 7:21 AM,  thors...@apache.org wrote:
  Author: thorsten
  Date: Thu Dec  3 12:21:48 2009
  New Revision: 886758
 
  URL: http://svn.apache.org/viewvc?rev=886758view=rev
  Log:
  This branch is closed.
 
 Nice!  Thanks Thorsten...

You are welcome, thank you for driving the release. :)

salu2

 
 --tim
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: Release-related issues [was: Re: Blocking Issues

2009-12-03 Thread Thorsten Scherler

One thing we did not had before in any release is that we have some
maven artifacts in our svn rep.

whiteboard/cocoon-2.2-blocks

Are we going to deploy those to the maven rep?

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Merging back the dispatcher

2009-12-02 Thread Thorsten Scherler

Hi all,

I will try to merge back the dispatcher branch into trunk and re-do all
the following commits:
733422
734387
734405
734546
734605
773472
795708
816460
816466

Please if you use trunk and the dispatcher make sure that it might be
broken temporary.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

RE: State of dispatcher?

2009-11-23 Thread Thorsten Scherler

On Mon, 2009-11-23 at 19:15 +1000, Gavin wrote:
...
  I will try a dry-run merge now and see what is coming out.
 
 Ah, this would be good, thanks Thorsten.
 
 To be honest I lost track of where I was supposed to be working when doing
 dispatcher stuff, so continued with 
 
 /trunk/whiteboard/plugins/*dispatcher
 /trunk/whiteboard/plugins/*themes
 
 It would be good to have all this stuff merged, then we can look at the
 state of the merger and decide if it can go into the release.

The following release have been done in the trunk against the dispatcher
after the creation of the branch:

733422
734387
734405
734546
734605
773472
795708
816460
816466

The above committs have to be re-done by hand after the merge, or?

I did:
cd forrest/trunk/whiteboard
svn merge -r 700363:HEAD
https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite

I will try to merge the above revision with the trunk. 

salu2

 
 Thanks
 
 Gav...
 
 
  
  salu2
  
   --tim
  --
  Thorsten Scherler thorsten.at.apache.org
  Open Source Java consulting, training and solutions
  
  Sociedad Andaluza para el Desarrollo de la Sociedad
  de la Información, S.A.U. (SADESI)
  
  
  
  
  No virus found in this incoming message.
  Checked by AVG - www.avg.com
  Version: 8.5.425 / Virus Database: 270.14.71/2510 - Release Date: 11/17/09
  19:26:00
 
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

RE: State of dispatcher?

2009-11-23 Thread Thorsten Scherler

On Mon, 2009-11-23 at 15:18 +0100, Thorsten Scherler wrote:
 On Mon, 2009-11-23 at 19:15 +1000, Gavin wrote:
 ...
   I will try a dry-run merge now and see what is coming out.
  
  Ah, this would be good, thanks Thorsten.
  
  To be honest I lost track of where I was supposed to be working when doing
  dispatcher stuff, so continued with 
  
  /trunk/whiteboard/plugins/*dispatcher
  /trunk/whiteboard/plugins/*themes
  
  It would be good to have all this stuff merged, then we can look at the
  state of the merger and decide if it can go into the release.
 
 The following release have been done in the trunk against the dispatcher
 after the creation of the branch:

I mean revisions!

 733422
 734387
 734405
 734546
 734605
 773472
 795708
 816460
 816466
 
 The above committs have to be re-done by hand after the merge, or?
 
 I did:
 cd forrest/trunk/whiteboard
 svn merge -r 700363:HEAD
 https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite
 
 I will try to merge the above revision with the trunk. 

...with the merged trunk.

salu2

 
 salu2
 
  
  Thanks
  
  Gav...
  
  
   
   salu2
   
--tim
   --
   Thorsten Scherler thorsten.at.apache.org
   Open Source Java consulting, training and solutions
   
   Sociedad Andaluza para el Desarrollo de la Sociedad
   de la Información, S.A.U. (SADESI)
   
   
   
   
   No virus found in this incoming message.
   Checked by AVG - www.avg.com
   Version: 8.5.425 / Virus Database: 270.14.71/2510 - Release Date: 11/17/09
   19:26:00
  
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: xdocs title element and the title bar of browser windows

2009-11-16 Thread Thorsten Scherler

On Mon, 2009-11-16 at 09:23 +0100, Vicent Mas wrote:
 On 2009-11-14 Sina K. Heshmati s...@khakbaz.com said:
 
...
  forrest:contract name=content-title
 dataURI=cocoon://#{$getRequest}.title.xml/
  
  Please note that, the content of *.title.xml is in this form: titleA
   Title/title
  ...
  
 
 OK. Now I understand the problem better... but I still cannot fix it. I've 
 done 
 the following:
 
 1) I wasn't very happy with the dirty trick of using an id attribute for 
 passing the second title. So I've extended the document-v2.dtd with a new 
 btitle element. I use this element to pass the body title:
 
 document
   headtitleHead title/title/head
   bodybtitleBody title/btitle
 ...

I am not sure whether you really want to do that since you need to
maintain the resulting dtd.

 
 2) I've overriden the content-title.ft contract. I've commented out the lines:
   !--forrest:part
 xsl:comment+ |start content-title +/xsl:comment
 h1 class=content-title
   xsl:value-of select=$content-title/*/
 /h1

Sian explained that $content-title is from xsl:param
name=content-title select=//

Meaning you can pass the content from the structurer and if not it will
use the doc root. 

Another way would be to pass it via a property:

forrest:contract name=content-title
  forrest:property name=content-title
titlemy title/title
  /forrest:property
/forrest:contract

You can as well create a complete different pipeline which will return
you the different values dynamically. 

forrest:contract name=content-title
dataURI=cocoon://#{$getRequest}.myTitle.xml/

Where you then implement a pipeline match pattern=*.myTitle.xml/
which should return titlemyTitle/title.


 xsl:comment+ |end content-title +/xsl:comment
   /forrest:part--
 
 3) By imitating content-title.ft I've created a new contract, body-title.ft. 
 It should create the body title. I've attached it to this mail.
 
 4) Imitating the dispatcher dataModel.xmap (in particular the title.xml 
 pipeline) I've modified my local sitemap and added the following lines:
 
 map:pipeline
   map:match pattern=**.btitle.xml
 map:generate src=cocoon://{1}.xml /
 map:transform src={lm:dataModel-xml-document-to-btitle.xsl} /
 map:serialize /


Make sure that the above serializer returns xml. Seeing your error below
I think that the default is xhtml. Try map:serialize type=xml/

That should work.

salu2

   /map:match
 /map:pipeline
 
 5) in my local stylesheets directory I've created the file xslt/xml/document-
 to-btitle.xsl. It extracts the content of the btitle element.
 
 Now I run forrest and get the following error:
 
 Message: null
 Description: No details available.
 Sender: org.apache.cocoon.servlet.CocoonServlet
 Source: Cocoon Servlet
 cause
 
 dispatcherError: 500 - Internal server error
 The contract body-title has thrown thrown an exception by resolving raw 
 data 
 from cocoon://index.btitle.xml.
 
 dispatcherErrorStack:
  java.io.IOException: Server returned HTTP response code: 503 for URL: 
 http://www.w3.org/TR/html4/loose.dtd
 
 Request URI
 index.html
 request-uri
 /index.html;jsessionid=3tf3ujcnmsumk
 
 Could you give me a hand (again) please? I'm reading sitemap documentation, 
 but it is not easy for a newbie. And Google didn't help me.
 
 Thanks
 
 Vicent
 
 PS: sorry for the lengthy mail.
 ::
 
   Share what you know, learn what you don't
 
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: [Important] Status and future direction

2009-10-09 Thread Thorsten Scherler



On 08/10/2009, at 21:07, Ross Gardler wrote:

I agree with Tim here, especially the bit where he can't agree with  
me more ;-)


I don't know a great deal about Cocoon 3, but I have no personal  
interest in using it here - sledgehammer to crack a nut. Since I'm  
not active here my opinion doesn't count for much in that respect  
though.


I am still developing mostly with cocoon in different versions. Just a  
couple of days back I had a chance to use cocoon 3 within droids and I  
have to say it is not sledgehammer anymore. You can use it without any  
sitemap if you want. ...


more inline



If someone wanted to look at and validate my evening hacks on  
Forrest 2 I might be drawn back in, I do have a need for such a  
lightweight and embeddable solution. However, I don't have the time  
or resources to drive forward alone on thIs.


David, thank you for raising this issue.

Sorry about top posting...
Sent from my mobile device.

On 8 Oct 2009, at 13:35, Tim Williams william...@gmail.com wrote:


Thanks David, this is a tough, but necessary, conversation.

I snipped A and B because I don't consider them fruitful options at  
all.


IMO A should be the way to wrap up current development. Like pointed  
out by David we need to have a release that  contains the work of the  
last years since the release.


I talked about trying to do the release but this task got moved down  
my priority list again due to workload. Actually in my work we ATM  
only use the cocoon 2.2 blocks from forrest and they are working fine.  
To move to cocoon 2.2 at whole is IMO as well not worth the while  
since we will find quite a bunch of problems which are not easily  
solvable.






C) Try to upgrade to Cocoon-3 version.
I don't know whether Cocoon-3 is ready or
possible for Forrest. Would someone else comment.


Cocoon-3 seems ready from what I can tell, though it is already
suffering from the same things that drove me away from enjoying
regular Cocoon.  It's overly complex.


Hmm, I am not sure whether I can sign that. Cocoon 3 is quite straight  
forward and flexible to integrate in what ever underlying framework  
you like to use.



There was a time when the
return on the steep Cocoon learning curve was worth it but that time,
for me, has passed.  I now have minimum amount of spare time to hack
at Forrest and when I've tried lately, it's no longer a pleasure
primarily because I spend much of that time re-learning Cocoon
complexity instead of being productive.  I must admit that when I was
at the height of my Cocoon knowledge I was unempathetic to Ross'
pleas, but now, I probably couldn't agree with his sentiments more.
Anyway, I think this is a long way of saying that i honestly don't  
see

there being a future in a Cocoon-based Forrest.


I have to admit that I am not sure about whole discussion about the  
future of forrest. We have a working product with a small committer  
community behind it. Our user base however is I guess larger then we  
imagine however we do not know them since forrest seems to just work.  
So no problems = no mails = no traffic.


Regarding the traffic on our commit lists is similar, we do not add  
any new functionality to forrest for a while now and more or less  
maintain the code we have with the feedback from the list and  
individual test cases.





D) Develop some other core.

See past discussion in our dev mail archives.


I think it's ultimately going to be this or the Attic.  Implementing
something that's intuitive, prefers convention, and doesn't attempt  
to

solve all problems could very well bring the fun back.  I think we'd
have a much easier time attracting new devs too since we wouldn't  
have

the problem of yeah, forrest is easy to understand *after* you
understand this other ridiculously complex beast over there.



The fear that I have that we will replace one complex beast with  
another. However I agree that the shinny new thing phenomenon can  
attract new devs, the only question is whether our focus will attract  
them. What can forrest do for me that xyz cannot do? Does our  
framework of input, internal and output plugins can be slimed down to  
a jar that I can add to my standard project where I need SOME of the  
functionality but not all? In which programming language do we want to  
develop to start with? 





E) Cease Forrest and move to the Apache Attic.

http://attic.apache.org/


I think there is a niche out there for Forrest.  I've got a need now,
for example, for a simple documentation site but, unfortunately,
forrest is too much of a burden to use for it - documentation is a
side-show that people don't want to have to spend hours/days coming
up to speed.  So I sincerely hope this option isn't where we end up.


I do not see forrest in the attic neither. There are still quite a  
bunch of code in our rep that attracts people with certain usecase. We  
know that people are using our software, we still have people  
answering mails and

Re: [jira] Commented: (FOR-1176) enable plugins to utilise stylesheets from exslt.org

2009-08-19 Thread Thorsten Scherler

On Wed, 2009-08-19 at 14:32 +0300, Sjur Moshagen wrote:
 Den 19. aug. 2009 kl. 10.50 skrev Sjur Moshagen:
 
  Den 19. aug. 2009 kl. 09.23 skrev Brian M Dube:
 
  Any idea on how to make the protocol 'known' to the xsl processor in
  Cocoon?
 
  I've been down this path once before. There is a Jira issue
  (somewhere; sorry, I'm just on the way to sleep) about rewriting the
  imports. I never had success with it. I'll look for that issue and  
  any
  notes I may have.
 
  It is in:
 
  https://issues.apache.org/jira/browse/FOR-1000
 
  But according to:
 
  http://www.mail-archive.com/u...@forrest.apache.org/msg02743.html  
  (Thorsten Scherler)
 
  it should work. I'll continue the investigation.
 
 It seems to be used in dispatcher, in at least the following file:
 
 whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/ 
 resources/stylesheets/helper/variable.helper.xsl:
 
 xsl:stylesheet version=1.0
xmlns:forrest=http://apache.org/forrest/properties/1.0;
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:import href=lm://transform.xml.dotdots/
xsl:import href=lm://transform.xml.pathutils/
 ...
 
 The dotdots LM string matches in one of the main locationmaps, and  
 should resolve just fine. That is, when using dispatcher, using an lm:  
 protocol in an xsl import seems to work just fine.
 
 The question is then: why doesn't it work in all other cases?


It should work fine everywhere. Make sure the resources are exposed via
the locationmap.

salu2

 
 Best regards,
 Sjur
 
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source consulting, training and solutions

Re: [jira] Commented: (FOR-1176) enable plugins to utilise stylesheets from exslt.org

2009-08-19 Thread Thorsten Scherler

On Wed, 2009-08-19 at 10:50 +0300, Sjur Moshagen wrote:
 Den 19. aug. 2009 kl. 09.23 skrev Brian M Dube:
 
  Any idea on how to make the protocol 'known' to the xsl processor in
  Cocoon?
 
  I've been down this path once before. There is a Jira issue
  (somewhere; sorry, I'm just on the way to sleep) about rewriting the
  imports. I never had success with it. I'll look for that issue and any
  notes I may have.
 
 It is in:
 
 https://issues.apache.org/jira/browse/FOR-1000
 
 But according to:
 
 http://www.mail-archive.com/u...@forrest.apache.org/msg02743.html  
 (Thorsten Scherler)
 
 it should work. I'll continue the investigation.

The puppy is in the xconf file:
Source Factories section:
component-instance
class=org.apache.forrest.locationmap.source.impl.LocationmapSourceFactory 
name=lm/

so that SHOULD be enough.

I am ATM working at a client so cannot really look into it but I may
find a spare minute to have a look.

salu2

 
 Best regards,
 Sjur
 
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source consulting, training and solutions

Re: [jira] Commented: (FOR-1176) enable plugins to utilise stylesheets from exslt.org

2009-08-18 Thread Thorsten Scherler

On Tue, 2009-08-18 at 03:42 -0700, Sjur N. Moshagen (JIRA) wrote:
 [ 
 https://issues.apache.org/jira/browse/FOR-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744451#action_12744451
  ] 
 
 Sjur N. Moshagen commented on FOR-1176:
 ---
 
 One question: will the locationmap function in xslt import statements? As in:
 
 xsl:stylesheet version=1.0
 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
 xmlns:date=http://exslt.org/dates-and-times;
 extension-element-prefixes=date
 
   xsl:import href={lm:exslt-extensions}/date.add.template.xsl /

the way you call it is not correct. the above should read xsl:import
href=lm:/exslt-extensions/date.add.template.xsl /

Since input modules are not available in xsl.

salu2

 
 ...
 /xsl:stylesheet
 
  enable plugins to utilise stylesheets from exslt.org
  
 
  Key: FOR-1176
  URL: https://issues.apache.org/jira/browse/FOR-1176
  Project: Forrest
   Issue Type: New Feature
   Components: Core operations, Plugin: input.baetle, Plugins 
  (general issues)
 Affects Versions: 0.9-dev
 Reporter: David Crossley
 Priority: Blocker
  Fix For: 0.9-dev
 
 
  Various plugins (e.g. input.baetle) want to use selected stylesheets from 
  exslt.org
 
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source consulting, training and solutions

Re: missing license headers

2009-07-20 Thread Thorsten Scherler

On Mon, 2009-07-20 at 17:03 +1000, David Crossley wrote:
 While doing the scan to ensure that our licensing is in order,
 i found some anomalies.
 
 Would the responsible committers please ensure that these
 files are their own work. If so then please add the
 ASF license header. If not then please indicate appropriately.
...
 Also Thorsten, i added various missing licenses to some
 Dispatcher stuff:
 http://svn.apache.org/viewvc?view=revrevision=795708

Thank you David I can confirm that each of these has been contributed
with the intent to licence to the ASF.

One question: do the properties as well need a license, seeing your
commit I say yes, but I thought that they did not (not sure why though).

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

[jira] Reopened: (FOR-1164) The 'lm' preffix is harcoded, make it configurable

2009-06-17 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOR-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler reopened FOR-1164:



The patch is not deep enough since there are still some places in the code 
where we have a fixed lm value for the variable.

The problem is in org.apache.forrest.locationmap.lm.LocationMap
public static final String ANCHOR_NAME = lm;

We are using in a couple of classes LocationMap.ANCHOR_NAME which is causing 
problems for the new prefixed source Factories because in the end it will 
always look up lm and not e.g. lmx

 The 'lm' preffix is harcoded, make it configurable
 --

 Key: FOR-1164
 URL: https://issues.apache.org/jira/browse/FOR-1164
 Project: Forrest
  Issue Type: Improvement
  Components: Locationmap
Reporter: Javier Puerto
Priority: Minor

 We are using the Locationmap with the Dispatcher block of Cocoon 2.2 and 
 found that we can't define the preffix for the SourceFactory because it' 
 harcoded in the LocationmapSourceFactory class.
 public static final String LM_PREFIX = lm;
 In our case, we use the locationmap in two diferents blocks with diferent 
 locationmap.xml configurations but because of spring the configurations 
 overlaping between block. As the configurations is diferent for each block, 
 we need anothe preffix to make it works.
 I made this changes to make LocationmapSourceFactory configurable:
 Entends from Configurable.
 Add a private attribute: private String prefix;
 Sustitute any reference to LM_PREFIX for the new prefix variable.
 Implements the follow function to make the config to work.
 public void configure(Configuration configuration)
  throws ConfigurationException {
   prefix = configuration.getAttribute(prefix, LM_PREFIX);
 }
 Now we can configure like this:
   source-factories
 component-instance 
 class=org.apache.forrest.locationmap.source.impl.LocationmapSourceFactory
 name=lmx prefix=lmx/
   /source-factories
 And call the other instance of Locationmap with uris like this lmx://*

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (FOR-1164) The 'lm' preffix is harcoded, make it configurable

2009-05-12 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOR-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler closed FOR-1164.
--

Resolution: Fixed

Committed revision 773885.

muchas gracias Javier

 The 'lm' preffix is harcoded, make it configurable
 --

 Key: FOR-1164
 URL: https://issues.apache.org/jira/browse/FOR-1164
 Project: Forrest
  Issue Type: Improvement
  Components: Locationmap
Reporter: Javier Puerto
Priority: Minor

 We are using the Locationmap with the Dispatcher block of Cocoon 2.2 and 
 found that we can't define the preffix for the SourceFactory because it' 
 harcoded in the LocationmapSourceFactory class.
 public static final String LM_PREFIX = lm;
 In our case, we use the locationmap in two diferents blocks with diferent 
 locationmap.xml configurations but because of spring the configurations 
 overlaping between block. As the configurations is diferent for each block, 
 we need anothe preffix to make it works.
 I made this changes to make LocationmapSourceFactory configurable:
 Entends from Configurable.
 Add a private attribute: private String prefix;
 Sustitute any reference to LM_PREFIX for the new prefix variable.
 Implements the follow function to make the config to work.
 public void configure(Configuration configuration)
  throws ConfigurationException {
   prefix = configuration.getAttribute(prefix, LM_PREFIX);
 }
 Now we can configure like this:
   source-factories
 component-instance 
 class=org.apache.forrest.locationmap.source.impl.LocationmapSourceFactory
 name=lmx prefix=lmx/
   /source-factories
 And call the other instance of Locationmap with uris like this lmx://*

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ForrestBot build for forrest-docs FAILED

2009-05-07 Thread Thorsten Scherler

On Thu, 2009-05-07 at 04:13 +, forrest...@forrest.zones.apache.org
wrote:
...
  [java] X [0]
 forrest-issues.html
 BROKEN: /export/home/config/forrestbot-trunk/conf/work/forrest-docs/.
 (Is a directory)
 

The other build fail was similar, but complaining about the url
directly. Maybe there are temp problems with jira.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: Editing the docu with Firedocs

2009-04-20 Thread Thorsten Scherler

On Fri, 2009-04-17 at 16:13 +0200, Andreas Hartmann wrote:
 Andreas Hartmann schrieb:
  Andreas Hartmann schrieb:
  Hi Lenya devs,
 
  I have started to extend the docu publication and the 
  forrestDocument20 resource type with the goal of making the 
  documentation editable with Firedocs. IMO this will further lower the 
  barrier to improve our documentation. And if it proves useful, maybe 
  we can invite other ASF projects to take a look at the system, present 
  it at ApacheCon etc.?
 
  Unfortunately editing is limited to simple text changes at the moment. 
  The editor seems to recognize the document structure (the XPath at the 
  bottom of the page is displayed correctly), but it doesn't allow to 
  apply any structural changes.
  
  Apparently this is due to the lack of a namespace. When I add a 
  namespace to the document and schema, structural editing is possible.
  
  I'd suggest that we add the namespace to the schema and to all 
  documentation documents. IMO this can be done incrementally, we just 
  have to add an intermediate transformation to the presentation pipeline 
  which adds the namespace where it is missing.
 
 There doesn't seem to be any inclination in the Forrest project to 
 introduce a namespace (Thorsten, please correct me if I'm wrong). So I'd 
 suggest that we just choose (a Lenya-specific) one, e.g.
 
http://apache.org/lenya/forrest

Hmm, we do not use them ATM for the doc, however we are using them in
some parts of of code. 

The dispatcher e.g. uses 
forrest:views xmlns:forrest=http://apache.org/forrest/templates/1.0;
  xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;

Maybe http://apache.org/forrest/document/v20 makes sense for our use
case (reflects best the DOCTYPE declaration).

 
 Should we discuss this with the Forrest project? Introducing an 
 official Forrest namespace would make sense as soon as we promote our 
 documentation solution to other projects. But we can still convert our 
 documents should the occasion arise.

I cc forrest-dev. 

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: problem with site.xml and tabs.xml: empty menus

2009-04-05 Thread Thorsten Scherler

On Thu, 2009-04-02 at 13:17 +0200, Vicent Mas wrote: 
 Hi,

Hi Vicent,

normally Ross points out the importance to NOT TOP POST!

Why?

http://www.caliburn.nl/topposting.html
http://en.wikipedia.org/wiki/Posting_style

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



 I've attached minimal versions of site.xml and tabs.xml. Tabs with id 'home',
 'screenshots' and 'development' have no navigation section (no menu appears
 when they are selected). The rounded bottom line is not added to them. The
 other two tabs show a menu when they are selected. The rounded bottom line is
 added to these menus.
 
 Please, tell me if you need some more info.
 

Hmm, see what I asked for: 

 Vicent
 
 2009/4/2 Thorsten Scherler thorsten.scherler@juntadeandalucia.es:
  On Wed, 2009-04-01 at 16:41 +0200, Vicent Mas wrote:
  Hi,
 ...
  To give you a quick feedback, please can you send/point me to the
  responsible code in skins that work.
 
  You should be able to do exactly the same in the dispatcher then in
  skins. It seems some devs fixed the skins but did not apply the fix to
  the dispatcher.

Meaning please see the code of skins that's treats this part of the
navigation. Further please point me to the dispatcher contract that you
patched. I am sorry that ATM I cannot be a bigger help and debug it
myself, but too much other commitments are eating my time.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source consulting, training and solutions

Re: problem with site.xml and tabs.xml: empty menus

2009-04-02 Thread Thorsten Scherler

On Wed, 2009-04-01 at 16:41 +0200, Vicent Mas wrote:
 Hi,
 
 finally I've fixed my problem. In my customisation layer I've done the
 following changes:
 
 - in pelt-html.leftbar.panel.xml I've commented out the call to the
 nav-section-round-bottom contract
 - in nav-section.ft, I've added a template with the same functionality than 
 the
 nav-section-round-bottom contract. I've added too a conditional call to this
 template: it is called from xsl:template match='/' when the condition
 xsl:if test=$nav-section/navigation/menu != '' is fulfilled
 
 In a few words, if a tab doesn't contain a navigation menu then the bottom is
 not rounded. Probably this can be achieved in a much easier way (it works
 fine if I use the skinconfig approach instead of the dispatcher) but, as a 
 good
 newbie, I cannot find it. Please tell me if you know a better solution.

To give you a quick feedback, please can you send/point me to the
responsible code in skins that work.

You should be able to do exactly the same in the dispatcher then in
skins. It seems some devs fixed the skins but did not apply the fix to
the dispatcher.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

opendocument contacts

2009-03-23 Thread Thorsten Scherler

Hi all,

a while ago I meet Alexandro Colorado in a conference and we talk about
that forrest can become the webinterface for the opendocument format. 

I past his mail here and would like to hear your thoughts abut it.

On Sat, 2008-11-08 at 18:08 -0600, Alexandro Colorado wrote:
 of ODF over the web. I would like you to invite you to
 the different ODF things that are happening around the web specially
 something that opendocumentfellowship did.
 http://opendocumentfellowship.com/resources/for_webmasters
 
 The youtube video on o...@www and project site:
 http://www.youtube.com/watch?v=rI0AEJkotzM
 http://odf-at-www.openoffice.org/
 
 also recomend this explanations for developers:
 http://blogs.sun.com/GullFOSS/entry/odf_www_how_it_works

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source consulting, training and solutions

Re: murmurs of a release

2009-03-20 Thread Thorsten Scherler

On Thu, 2009-03-19 at 00:03 +, Ross Gardler wrote:
 2009/3/18 David Crossley cross...@apache.org:
  Gavin wrote:
  Thorsten Scherler
  
   I hope that people will give me support (as they always did) when
   I shortly will merge back the dispatcher rewrite and volunteer to
   get a long overdue forrest 0.9 release out.
 
 Go Thorsten
 
 If you want to get together at ApacheCon and force me to do some
 testing I'd be happy to do so (if you can get hold of me for long
 enough). At present Tuesday AM is the only time I have pretty free in
 Hackathon time.

jeje, would be very nice to get a release out while in Amsterdam, will
see you there and we make the planing over a heinecken. ;)

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: Changes to tidy-config.txt

2009-03-16 Thread Thorsten Scherler

On Wed, 2009-03-11 at 15:19 +1100, David Crossley wrote:
 Thorsten Scherler wrote:
  Hi all,
  
  I played around with 
  $FORREST_HOME/etc/tidy-xml.pl 
  in a custom project where I need to clean up the white spaces. 
 
 At Forrest we do not use that old experiment.
 Probably should remove it, as is seems to confuse.
 
 See my answer to Gavin a few weeks ago.
 There is an xmlformat task in main/build.xml
 which uses etc/xmlformat.conf
 
 I did heaps of work with this just before our last
 release, and found it to be much much better than
 using tidy.

Thanks for explaining. I found that tidy broke my xsl:text elements
(which are supposed to be printed as is) and that leaded to a couple of
bugs where I saw #10; in the paths.

Will need to look into the task.

Gracias y salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Changes to tidy-config.txt

2009-03-09 Thread Thorsten Scherler

Hi all,

I played around with 
$FORREST_HOME/etc/tidy-xml.pl 
in a custom project where I need to clean up the white spaces. 

For now we have not set the encoding in our configuration, this however
can lead to problems in combination with 
add-xml-decl: yes

If you have a xml file that did not had a xml declaration, tidy will add
one and use the default encoding which is us-ascii.

I needed to add char-encoding: utf8 to the config to get rid of
invalid character error that all my utf-8 characters had thrown.

Another thing is the indent of all attributes. IMO that it just too much
since if you have an element with 5 attributes you will have it now in 6
lines.

I propose the following change:
Index: etc/tidy-config.txt
===
--- etc/tidy-config.txt (revision 748122)
+++ etc/tidy-config.txt (working copy)
@@ -1,8 +1,9 @@
 add-xml-decl: yes
+char-encoding: utf8
 input-xml: yes
 output-xml:yes
 indent: auto
-indent-attributes: yes
+indent-attributes: no
 indent-spaces: 2
 write-back: yes
 preserve-entities: yes

wdyt?

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: svn commit: r750422 - in /forrest/branches/dispatcher_rewrite/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher: impl/helper/ transformation/

2009-03-05 Thread Thorsten Scherler

 = dispatcherError:\n
  ++ SAXParser could not be setup! Abort;
  +  getLogger().error(error);
  +  throw new ProcessingException(error);
  +}
}
 
/*
  @@ -328,7 +339,6 @@
   */
  // setup our super class
  super.setup(resolver, objectModel, src, par);
  -storedPrefixMap = new HashMap();
 
  // get the id of this request
  this.requestId = parameters
  @@ -480,11 +490,6 @@
  }
}
 
  -  public void ignorableWhitespace(char c[], int start, int len)
  -  throws SAXException {
  - // do nothing here!
  -  }
  -
 
public void characters(char c[], int start, int len)
throws SAXException {
  @@ -498,7 +503,7 @@
}
 
public void startDocument() throws SAXException {
  - // Add the namespace filter to our own output.
  +// Add the namespace filter to our own output.
  RedundantNamespacesFilter nsPipe = new RedundantNamespacesFilter();
  if (this.xmlConsumer != null) {
  nsPipe.setConsumer(this.xmlConsumer);
  @@ -506,24 +511,28 @@
  nsPipe.setContentHandler(this.contentHandler);
  }
  setConsumer(nsPipe);
  -super.startDocument();
}
 
public void endDocument()
throws SAXException {
  structurerProcessingEnd();
  -super.endDocument();
}
 
/*
  -   * copy 'n paste
  +   * do nothing on the following methods, since we do not use them
 */
  +  public void ignorableWhitespace(char c[], int start, int len)
  +  throws SAXException {
  +  }
 
public void startCDATA() throws SAXException {
}
 
public void endCDATA() throws SAXException {
}
  +
  +  public void comment(char[] ary, int start, int length) throws 
  SAXException {
  +  }
 
/**
 * Will execute the contract and process the result.
  @@ -665,8 +674,10 @@
}else{
  root.serialize(out);
}
  -  StringXMLizable xml = new StringXMLizable(out.toString());
  -  xml.toSAX(new IncludeXMLConsumer(super.xmlConsumer));
  +
  +  InputSource is = new InputSource(new StringReader(out.toString()));
  +   // adding the result to the consumer
  +  parser.parse(is, super.xmlConsumer);
  } catch (Exception e) {
throw new SAXException(e);
  }
 
 
 
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: [important] developers need to assist each other

2009-03-05 Thread Thorsten Scherler

On Wed, 2009-02-18 at 18:48 +1100, David Crossley wrote:
...
 However, recently i notice that people are not being
 answered on the dev list. For example both Tim and Thorsten
 have issues that need assistance.

I did not found time to answer this mail till now.
Thank you David for your good intention. 

Actually only some quite specific mails from me have not found 
any answers but I understand this. 

I hope that people will give me support (as they always did) when 
I shortly will merge back the dispatcher rewrite and volunteer to 
get a long overdue forrest 0.9 release out.

I would love to help to port forrest to cocoon 2.2 again since it solves
some common integration problems quite nicely. However due to time constrains
I cannot take the lead on this but I have ported some forrest components 
to cocoon 2.2 blocks a while ago and it is not hard to port the rest. 
It only takes up lots of time for a single person to move the whole code 
to blocks. 

 Remember that anyone who is subscribed to this
 dev mail list should assist. Not just ASF committers.

That is so true.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source consulting, training and solutions

Re: [HeadsUp] next steps for dispatcher integration - please test

2009-02-16 Thread Thorsten Scherler

On Sun, 2009-02-15 at 15:57 +1100, David Crossley wrote:
 Thorsten Scherler wrote:
...
   Since I have done the whole work in a branch I need to merge it ASAP. I
   suspect that the merge will not be fully conflict free since there has
   been some commits to the trunk of contracts that are not in the branch.
  
  Since I did not merged the branches right away the recent work of Gavin
  and David on the html/css validation compatibility is not incorporated
  when I simply merge the branches. Bummer.
 
 I am no branching expert, but can you merge the changes from
 trunk into your branch. When all is well you then merge
 branch to trunk.

 http://svn.apache.org/viewcvs?view=revrev=701113

The problem is that they have moved they place with the first commit. To
workaround that results in nearly the the same work as doing it again
from the start. Maybe somebody has an idea to overcome this problem?
without to repeat it all.
 
 At the moment i don't have time to test, or to comment
 on your plan. So i hope that other developers do.

Thank you for your comment.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: [HeadsUp] next steps for dispatcher integration - please test

2009-02-12 Thread Thorsten Scherler

On Thu, 2008-10-09 at 14:26 +0200, Thorsten Scherler wrote:
 Hi all,
 
 after an extended rewrite of the dispatcher I am happy to say that my
 first tests are all passing now.
 
 The upgrade steps for custom dispatcher projects are straightforward:
 1) Renaming extension of the contracts from *.ft to *.contracts.xml
 demonstrated with http://svn.apache.org/viewcvs?view=revrev=701113
 
 2) Renaming elements from view to structurer
 demonstrated with http://svn.apache.org/viewcvs?view=revrev=701117
 
 3) Renaming structurer file and adding new extension
 demonstrated with http://svn.apache.org/viewcvs?view=revrev=701325
 
 4) The path of the defaultVariables has changed a bit. Removing one
 level
 demonstrated with http://svn.apache.org/viewcvs?view=revrev=703149
 
 5) [optional] Renaming extensions for contracts and structurer in
 properties files.
 demonstrated with http://svn.apache.org/viewcvs?view=revrev=701119
 
 Step 5 is optional since in the normal use case one is using the default
 configuration. However our fresh site sadly added the
 dispatcher.theme-ext property. Just do:
 -  property name=dispatcher.theme-ext value=.fv/
 
 
 On my todo list still are two open points:
 1) Merge the cocoon-2.2 block dispatcher into the current plugin. This
 needs extending the normal build of plugins since cocoon 2.2 needs
 additional files in the resulting jar. 

That has be done as well.

 2) Small document of the new features and how we can use them.

This still needs more work.

 
 Since I have done the whole work in a branch I need to merge it ASAP. I
 suspect that the merge will not be fully conflict free since there has
 been some commits to the trunk of contracts that are not in the branch.

Since I did not merged the branches right away the recent work of Gavin
and David on the html/css validation compatibility is not incorporated
when I simply merge the branches. Bummer.

IMO the best is to repeat the above steps on a clean new branch for the
rewrite or even directly do it in trunk since the plugin should leave
the whiteboard as well.

WDYT?

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: Dispatcher rewrite - should be faster but it is not

2009-02-10 Thread Thorsten Scherler

On Sun, 2009-02-08 at 15:42 -0500, Tim Williams wrote:
 On Tue, Jan 27, 2009 at 8:57 AM, Thorsten Scherler
 thorsten.scherler@juntadeandalucia.es wrote:
  Hi all,
 
  I am running out of ideas why the dispatcher rewrite is not faster then
  the old one we have.
 
  The old dispatcher is around 10% faster and consumes less memory (!!!)
  then the new one. The new one is using AXIOM to create the final
  document which supposed to be faster then DOM, but it is not.
 
  I switch the contract processing from DOM to AXIOM to finally have SAX.
 
  Some sidenotes of my profiling sessions:
  - we use as testing ground a dedicated linux box which is basically a
  replica of http://juntadeandalucia.es/index.html
  - the side is made with cocoon 2.2 and old dispatcher cocoon 2.2 block
  (which is the same as we use here in forrest projects).
  - The app is running on a tomcat6 and java6.
  - We using jmeter to have an incremental test run on concurrent threads
  (starting with 5 to 90 concurrent threads).
 
  Jmeter says for 90 threads that we have a throughput of 70 threads/sec
  with the old one but only 60 threads/sec with the new one.
 
  The max memory for the 90 threads are 65 MB for the old one and the new
  one is using 5 MB more.
 
  The total amount of class instances have been around 12.000 in the old
  and in the new around 15.000.
 
  Somebody has any idea I would really appreciate some suggestions, I do
  not understand why the new one is not significantly faster and resource
  friendlier.
 
 I have no clue really, just some thoughts.  

Thank you Tim, I really appreciate them!

 On a side note, if there's
 an easy way for me to setup the same test here, maybe I could help
 more. Assuming I use the rewrite_branch, what site should I set up?

Actually I have set up a some wars to make it easier to test
see for some details https://issues.apache.org/jira/browse/FOR-1157

Basically
https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite/FOR-1157/

has two different wars.

 Have you benchmarked the parsers independent of the dispatcher
 framework?  Maybe its simply a case of the assumptions being wrong?
 AXIOM is specifically fast for small docs, right?  

Not sure I had the perception that it should be faster for bigger docs.
However I am getting your point. 

 Maybe yours are
 larger than the threshold in which AXIOM can be expected to outperform
 others?  I haven't looked at AXIOM but maybe the higher memory is due
 to AXIOM being optimized for certain doc types/size?  Maybe the
 dispatcher isn't wrong, is there a chance your expectations are?

I understand your point and you are completely right in saying that some
parser are optimized to certain doc types/size. However the only thing
that I cannot explain myself is what I comment in the issue:
Like you see even if the new transformer is not used at all we are
loosing around 10 requests per second.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

[jira] Created: (FOR-1158) FOPNGSerializer in war not found

FOPNGSerializer in war not found
--

 Key: FOR-1158
 URL: https://issues.apache.org/jira/browse/FOR-1158
 Project: Forrest
  Issue Type: Bug
  Components: Launch servlet WAR, Plugin: output.pdf
Reporter: Thorsten Scherler


When building a war from a fresh-site the pdf plugin fails with:
ERROR   (2009-01-30) 10:51.27:086   [sitemap] (/my-project/samples-b/faq.html) 
http-8080-1/ExcaliburComponentManager: Caught an exception trying to initialize 
the component handler.
org.apache.avalon.framework.configuration.ConfigurationException: Could not 
load class org.apache.cocoon.blocks.fop.FOPNGSerializer for component named 
'fo2pdf' at 
file:///home/thorsten/src/apache/tomcat6/webapps/my-project/build/plugins/org.apache.forrest.plugin.output.pdf/output.xmap:38:116
at 
org.apache.cocoon.components.ExtendedComponentSelector.configure(ExtendedComponentSelector.java:236)
at 
org.apache.cocoon.components.treeprocessor.sitemap.ComponentsSelector.configure(ComponentsSelector.java:158)
at 
org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201)
...
Caused by: java.lang.ClassNotFoundException: 
org.apache.cocoon.blocks.fop.FOPNGSerializer
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1358)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
at 
org.apache.cocoon.components.ExtendedComponentSelector.configure(ExtendedComponentSelector.java:228)
... 296 more


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (FOR-1074) the war target needs to include supporting jars that are provided in each plugin lib directory


 [ 
https://issues.apache.org/jira/browse/FOR-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler closed FOR-1074.
--

Resolution: Fixed

Commit de la revisión 739234.

FOR-1074 Using the war ant task to include the plugin libs

 the war target needs to include supporting jars that are provided in each 
 plugin lib directory
 --

 Key: FOR-1074
 URL: https://issues.apache.org/jira/browse/FOR-1074
 Project: Forrest
  Issue Type: Bug
  Components: Launch servlet WAR, Plugins (general issues)
Affects Versions: 0.9-dev
Reporter: Thorsten Scherler
Priority: Blocker
 Fix For: 0.9-dev


 Do
 cd testing
 forrest seed
 forrest war
 cp build/my-project.war $CATALINA_HOME/webapps/tomcat.war
 lynx http://localhost:8080/tomcat/
 = Internal Server Error
 == webapps/tomcat/WEB-INF/logs/core.log ==
 ERROR   (2008-03-03) 09:49.45:186   [access] (/tomcat/) 
 http-8080-2/CocoonServlet: Internal Cocoon Problem
 org.apache.cocoon.ProcessingException: Sitemap: error when calling sub-sitemap
 at [Exception] - 
 file:/home/thorsten/src/apache/apache-tomcat-6.0.14/webapps/tomcat/build/plugins/org.apache.forrest.plugin.output.pdf/output.xmap:21:120
 at [ConfigurationException] - 
 file:/home/thorsten/src/apache/apache-tomcat-6.0.14/webapps/tomcat/build/plugins/org.apache.forrest.plugin.output.pdf/output.xmap:21:120
 at map:mount - 
 file:/home/thorsten/src/apache/apache-tomcat-6.0.14/webapps/tomcat/project/build/tmp/output.xmap:33:147
 at map:mount - 
 file:/home/thorsten/src/apache/apache-tomcat-6.0.14/webapps/tomcat/sitemap.xmap:533:106
 at 
 org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:112)
 at 
 org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117)
 at 
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
 at 
 org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:81)
 at 
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
 at 
 org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:155)
 at 
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
 at 
 org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:95)
 at 
 org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:292)
 at 
 org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:223)
 at 
 org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:289)
 at 
 org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:114)
 at 
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
 at 
 org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:81)
 at 
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
 at 
 org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:155)
 at 
 org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
 at 
 org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:95)
 at 
 org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:292)
 at 
 org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:223)
 at 
 org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:289)
 at org.apache.cocoon.Cocoon.process(Cocoon.java:557)
 at 
 org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:364)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 at 
 org.apache.catalina.core.StandardHostValve.invoke

[jira] Updated: (FOR-1157) The dispatcher rewrite is loosing throughput in jmeter tests


 [ 
https://issues.apache.org/jira/browse/FOR-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler updated FOR-1157:
---

Attachment: (was: stress.jmx)

 The dispatcher rewrite is loosing throughput in jmeter tests
 

 Key: FOR-1157
 URL: https://issues.apache.org/jira/browse/FOR-1157
 Project: Forrest
  Issue Type: Test
  Components: Plugin: internal.dispatcher
Reporter: Thorsten Scherler

 http://markmail.org/thread/gkp4ys65q2l7hpyy
 The old dispatcher is around 10% faster and consumes less memory (!!!) then 
 the new one. The new one is using AXIOM to create the final document which 
 supposed to be faster then DOM, but it is not.
 I switch the contract processing from DOM to AXIOM to finally have SAX.
 Some sidenotes of my profiling sessions: - we use as testing ground a 
 dedicated linux box which is basically a replica of 
 http://juntadeandalucia.es/index.html - the side is made with cocoon 2.2 and 
 old dispatcher cocoon 2.2 block (which is the same as we use here in 
 forrest projects). - The app is running on a tomcat6 and java6. - We using 
 jmeter to have an incremental test run on concurrent threads (starting with 5 
 to 90 concurrent threads). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FOR-1157) The dispatcher rewrite is loosing throughput in jmeter tests


[ 
https://issues.apache.org/jira/browse/FOR-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668821#action_12668821
 ] 

Thorsten Scherler commented on FOR-1157:


Use the stress file in the branch 
https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite/FOR-1157/stress.jmx

 The dispatcher rewrite is loosing throughput in jmeter tests
 

 Key: FOR-1157
 URL: https://issues.apache.org/jira/browse/FOR-1157
 Project: Forrest
  Issue Type: Test
  Components: Plugin: internal.dispatcher
Reporter: Thorsten Scherler

 http://markmail.org/thread/gkp4ys65q2l7hpyy
 The old dispatcher is around 10% faster and consumes less memory (!!!) then 
 the new one. The new one is using AXIOM to create the final document which 
 supposed to be faster then DOM, but it is not.
 I switch the contract processing from DOM to AXIOM to finally have SAX.
 Some sidenotes of my profiling sessions: - we use as testing ground a 
 dedicated linux box which is basically a replica of 
 http://juntadeandalucia.es/index.html - the side is made with cocoon 2.2 and 
 old dispatcher cocoon 2.2 block (which is the same as we use here in 
 forrest projects). - The app is running on a tomcat6 and java6. - We using 
 jmeter to have an incremental test run on concurrent threads (starting with 5 
 to 90 concurrent threads). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FOR-1157) The dispatcher rewrite is loosing throughput in jmeter tests

[
https://issues.apache.org/jira/browse/FOR-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668839#action_12668839
]

Thorsten Scherler commented on FOR-1157:

new dispatcher on Apache Tomcat/6.0.14

java version 1.6.0
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Server VM (build 1.6.0-b105, mix

TOTAL requests: 21556
request/sec: 35.8

The dispatcher rewrite is loosing throughput in jmeter tests

Key: FOR-1157
URL: https://issues.apache.org/jira/browse/FOR-1157
Project: Forrest
Issue Type: Test
Components: Plugin: internal.dispatcher
Reporter: Thorsten Scherler

http://markmail.org/thread/gkp4ys65q2l7hpyy
The old dispatcher is around 10% faster and consumes less memory (!!!) then
the new one. The new one is using AXIOM to create the final document which
supposed to be faster then DOM, but it is not.
I switch the contract processing from DOM to AXIOM to finally have SAX.
Some sidenotes of my profiling sessions: - we use as testing ground a
dedicated linux box which is basically a replica of
http://juntadeandalucia.es/index.html - the side is made with cocoon 2.2 and
old dispatcher cocoon 2.2 block (which is the same as we use here in
forrest projects). - The app is running on a tomcat6 and java6. - We using
jmeter to have an incremental test run on concurrent threads (starting with 5
to 90 concurrent threads).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FOR-1157) The dispatcher rewrite is loosing throughput in jmeter tests


[ 
https://issues.apache.org/jira/browse/FOR-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668842#action_12668842
 ] 

Thorsten Scherler commented on FOR-1157:


map:match pattern=**.html
 map:generate src=lm://resolve.structurer.{1} type=jx
  map:parameter name=lenient-xpath value=true/
  map:parameter name=getRequest value={1}/
  map:parameter name=contextPath value={request:contextPath}/
  map:parameter name=getRequestExtension value=html/
 /map:generate
!--
  1) map:serialize type=xml/
--
 map:transform type=dispatcher
  map:parameter name=cacheKey value={0}/
  map:parameter name=validityFile value=lm://resolve.structurer.{1}/
  map:parameter name=request value={1}/
  map:parameter name=type value=html/
 /map:transform
!--
  2) map:serialize type=xhtml/
--
 map:transform src=lm://hooks-to-html.xsl/
!--
  3) map:serialize type=xhtml/
--
 map:transform src=lm://namespace-stripped/
!--
  4) map:serialize type=xhtml/
--
 map:transform src=lm://strip-dispatcher-remains-html.xsl/
 map:serialize type=xhtml/
/map:match

throughput with 90 threads (10 min) [old TRUNK]:
1) 55,5 [64,5]


 The dispatcher rewrite is loosing throughput in jmeter tests
 

 Key: FOR-1157
 URL: https://issues.apache.org/jira/browse/FOR-1157
 Project: Forrest
  Issue Type: Test
  Components: Plugin: internal.dispatcher
Reporter: Thorsten Scherler

 http://markmail.org/thread/gkp4ys65q2l7hpyy
 The old dispatcher is around 10% faster and consumes less memory (!!!) then 
 the new one. The new one is using AXIOM to create the final document which 
 supposed to be faster then DOM, but it is not.
 I switch the contract processing from DOM to AXIOM to finally have SAX.
 Some sidenotes of my profiling sessions: - we use as testing ground a 
 dedicated linux box which is basically a replica of 
 http://juntadeandalucia.es/index.html - the side is made with cocoon 2.2 and 
 old dispatcher cocoon 2.2 block (which is the same as we use here in 
 forrest projects). - The app is running on a tomcat6 and java6. - We using 
 jmeter to have an incremental test run on concurrent threads (starting with 5 
 to 90 concurrent threads). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FOR-1157) The dispatcher rewrite is loosing throughput in jmeter tests


[ 
https://issues.apache.org/jira/browse/FOR-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668845#action_12668845
 ] 

Thorsten Scherler commented on FOR-1157:


LIke you see even if the new transformer is not used at all we are loosing 
around 10 requests per second. 



 The dispatcher rewrite is loosing throughput in jmeter tests
 

 Key: FOR-1157
 URL: https://issues.apache.org/jira/browse/FOR-1157
 Project: Forrest
  Issue Type: Test
  Components: Plugin: internal.dispatcher
Reporter: Thorsten Scherler

 http://markmail.org/thread/gkp4ys65q2l7hpyy
 The old dispatcher is around 10% faster and consumes less memory (!!!) then 
 the new one. The new one is using AXIOM to create the final document which 
 supposed to be faster then DOM, but it is not.
 I switch the contract processing from DOM to AXIOM to finally have SAX.
 Some sidenotes of my profiling sessions: - we use as testing ground a 
 dedicated linux box which is basically a replica of 
 http://juntadeandalucia.es/index.html - the side is made with cocoon 2.2 and 
 old dispatcher cocoon 2.2 block (which is the same as we use here in 
 forrest projects). - The app is running on a tomcat6 and java6. - We using 
 jmeter to have an incremental test run on concurrent threads (starting with 5 
 to 90 concurrent threads). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reasons for perfomance decline - ideas wanted

2009-01-30 Thread Thorsten Scherler

Hi all,

I am trying to find out why one of my projects suffer perfomance
declines.

I opened an issue around the problem
https://issues.apache.org/jira/browse/FOR-1157 and added some testing
file to
https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite/FOR-1157

Both wars are basically the same but have some minor difference, mainly
the dispatcher library and its dependencies. However I debugged both
versions and tested with different tests. The most important match I am
debugging is the following:

map:match pattern=**.html 
 map:generate src=lm://resolve.structurer.{1} type=jx 
  map:parameter name=lenient-xpath value=true/ 
  map:parameter name=getRequest value={1}/ 
  map:parameter name=contextPath value={request:contextPath}/ 
  map:parameter name=getRequestExtension value=html/ 
 /map:generate 
!-- 
  1) map:serialize type=xml/ 
-- 
 map:transform type=dispatcher 
  map:parameter name=cacheKey value={0}/ 
  map:parameter name=validityFile
value=lm://resolve.structurer.{1}/ 
  map:parameter name=request value={1}/ 
  map:parameter name=type value=html/ 
 /map:transform 
!-- 
  2) map:serialize type=xhtml/ 
-- 
 map:transform src=lm://hooks-to-html.xsl/ 
!-- 
  3) map:serialize type=xhtml/ 
-- 
 map:transform src=lm://namespace-stripped/ 
!-- 
  4) map:serialize type=xhtml/ 
-- 
 map:transform src=lm://strip-dispatcher-remains-html.xsl/ 
 map:serialize type=xhtml/ 
/map:match

In one test I cut the pipeline after the generator (1) and the result is
surprising. Since there is NO difference between the old and new version
in the generator I was awaiting that the performance should be the same.

But 55,5 (new) vs. 64,5 (old) are not even close to be the same. I do
not see any reason for performance penalty since I am not actually
testing my development but a general component that did not changed at
all.

Has anybody an idea what the reason for the performance decline can be?

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

[jira] Updated: (FOR-1157) The dispatcher rewrite is loosing throughput in jmeter tests

2009-01-29 Thread Thorsten Scherler (JIRA)


 [ 
https://issues.apache.org/jira/browse/FOR-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler updated FOR-1157:
---

Attachment: stress.jmx

jmeter stress test 200 threads attacking a fresh seed.

 The dispatcher rewrite is loosing throughput in jmeter tests
 

 Key: FOR-1157
 URL: https://issues.apache.org/jira/browse/FOR-1157
 Project: Forrest
  Issue Type: Test
  Components: Plugin: internal.dispatcher
Reporter: Thorsten Scherler
 Attachments: stress.jmx


 http://markmail.org/thread/gkp4ys65q2l7hpyy
 The old dispatcher is around 10% faster and consumes less memory (!!!) then 
 the new one. The new one is using AXIOM to create the final document which 
 supposed to be faster then DOM, but it is not.
 I switch the contract processing from DOM to AXIOM to finally have SAX.
 Some sidenotes of my profiling sessions: - we use as testing ground a 
 dedicated linux box which is basically a replica of 
 http://juntadeandalucia.es/index.html - the side is made with cocoon 2.2 and 
 old dispatcher cocoon 2.2 block (which is the same as we use here in 
 forrest projects). - The app is running on a tomcat6 and java6. - We using 
 jmeter to have an incremental test run on concurrent threads (starting with 5 
 to 90 concurrent threads). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FOR-1157) The dispatcher rewrite is loosing throughput in jmeter tests

2009-01-29 Thread Thorsten Scherler (JIRA)

[
https://issues.apache.org/jira/browse/FOR-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668469#action_12668469
]

Thorsten Scherler commented on FOR-1157:

With the dispatcher rewrite branch I find that I cannot use the 200 threads
since it will throw:
4:46:01.669 EVENT LOW ON THREADS ((100-100+4)5) on socketliste...@0.0.0.0:
14:46:01.670 EVENT LOW ON THREADS ((100-100+4)5) on
socketliste...@0.0.0.0:
14:46:01.808 WARN!! OUT OF THREADS: socketliste...@0.0.0.0:

However with this error I got 28.6 throughput for 200 thread (10 min running)

The dispatcher rewrite is loosing throughput in jmeter tests

Key: FOR-1157
URL: https://issues.apache.org/jira/browse/FOR-1157
Project: Forrest
Issue Type: Test
Components: Plugin: internal.dispatcher
Reporter: Thorsten Scherler
Attachments: stress.jmx

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FOR-1157) The dispatcher rewrite is loosing throughput in jmeter tests

2009-01-29 Thread Thorsten Scherler (JIRA)


[ 
https://issues.apache.org/jira/browse/FOR-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668476#action_12668476
 ] 

Thorsten Scherler commented on FOR-1157:


I got 29.6 throughput for 90 thread (10 min running)



 The dispatcher rewrite is loosing throughput in jmeter tests
 

 Key: FOR-1157
 URL: https://issues.apache.org/jira/browse/FOR-1157
 Project: Forrest
  Issue Type: Test
  Components: Plugin: internal.dispatcher
Reporter: Thorsten Scherler
 Attachments: stress.jmx


 http://markmail.org/thread/gkp4ys65q2l7hpyy
 The old dispatcher is around 10% faster and consumes less memory (!!!) then 
 the new one. The new one is using AXIOM to create the final document which 
 supposed to be faster then DOM, but it is not.
 I switch the contract processing from DOM to AXIOM to finally have SAX.
 Some sidenotes of my profiling sessions: - we use as testing ground a 
 dedicated linux box which is basically a replica of 
 http://juntadeandalucia.es/index.html - the side is made with cocoon 2.2 and 
 old dispatcher cocoon 2.2 block (which is the same as we use here in 
 forrest projects). - The app is running on a tomcat6 and java6. - We using 
 jmeter to have an incremental test run on concurrent threads (starting with 5 
 to 90 concurrent threads). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Dispatcher rewrite - should be faster but it is not

2009-01-27 Thread Thorsten Scherler

Hi all,

I am running out of ideas why the dispatcher rewrite is not faster then
the old one we have.

The old dispatcher is around 10% faster and consumes less memory (!!!)
then the new one. The new one is using AXIOM to create the final
document which supposed to be faster then DOM, but it is not.

I switch the contract processing from DOM to AXIOM to finally have SAX.

Some sidenotes of my profiling sessions:
- we use as testing ground a dedicated linux box which is basically a
replica of http://juntadeandalucia.es/index.html 
- the side is made with cocoon 2.2 and old dispatcher cocoon 2.2 block
(which is the same as we use here in forrest projects). 
- The app is running on a tomcat6 and java6.
- We using jmeter to have an incremental test run on concurrent threads
(starting with 5 to 90 concurrent threads). 

Jmeter says for 90 threads that we have a throughput of 70 threads/sec
with the old one but only 60 threads/sec with the new one. 

The max memory for the 90 threads are 65 MB for the old one and the new
one is using 5 MB more.

The total amount of class instances have been around 12.000 in the old
and in the new around 15.000.

Somebody has any idea I would really appreciate some suggestions, I do
not understand why the new one is not significantly faster and resource
friendlier. 

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: SolrForrest plugin

El mié, 14-01-2009 a las 12:11 +0100, Andrzej Bialecki escribió:
Hi devs,

I found this Forrest plugin at the Forrest site. If you guys have a
moment to spare I'd really appreciate your advice.

I'm a complete newbie to Forrest, the only things I know how to do is to
fill in the blanks in the default site xdocs and generate static html.
It's not much, I'm afraid.

Should be enough. ;)

Since the plugin is still in the whiteboard you need to use the TRUNK of
forrest. Best to get started with the plugin:

cd
$FORREST_HOME/whiteboard/plugins/org.apache.forrest.plugin.output.solr
forrest run

http://localhost:/index.html - here you find some samples and basic
instructions.

Now, I need to index the content of a Forrest site in Solr, using a
custom schema - e.g. the id in my case should be equivalent to the
full URL of the page of the deployed site.

You have seen http://wiki.apache.org/solr/SolrForrest and
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.solr/

First, I'm stuck conceptually - sitting in the top-level dir of the
forrest site, what is it that I have to do to produce a file with the
Solr add documents?

Actually that is doing the plugin to you.
http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.solr/output.xmap?view=markup
...
!-- Output xdocs as solr docs --
map:match pattern=**.solr
map:generate src=cocoon://{1}.xml/
map:transform src={lm:solr.transform.xdocs.solrDoc}
map:parameter name=document-url value={1}.xml/
map:parameter name=project value={properties:project.name}/
/map:transform
map:serialize/
/map:match

You are talking about to extend the
./resources/stylesheets/xdocs-to-solrDoc.xsl with your custom attributes.
First have a look at the plugins xsl to get an idea about how we are doing
things.

Now copy the file to your project into your stylesheet dir (default is
src/documentation/resources/stylesheets/ = {project.stylesheets-dir}).

Let forrest know that you want to provide a custom location by adding the
following in your project locationmap.xml after the locator element:
match pattern=solr.transform.xdocs.solrDoc
location src={project.stylesheets-dir}/xdocs-to-solrDoc.xsl/
/match

From here you need to implement your logic.

I already added the Solr output plugin to
skinconf.xml. I discovered that I can get this via webapp, but I'd
rather not actually run the webapp.

hmm, skinconf.xml has nothing to do with the plugin. Where did you get
the expression that you need to edit this file? You need to add the
plugin to project.required.plugins.

Second, how can I modify the schema of the produced documents, so that
e.g. the id is the full URL - a configurable root URL plus the page
name, and so that I can add other metadata to the docs?

You will need to create your own xsl to override the default one as
described above.

Thanks in advance for any help that you can provide!

Please keep on asking if this are still not very clear.

salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad
de la Información, S.A.U. (SADESI)

Re: SolrForrest plugin

El jue, 15-01-2009 a las 14:07 +0100, Andrzej Bialecki escribió:
 Thorsten Scherler wrote:
...
  
  Now, I need to index the content of a Forrest site in Solr, using a 
  custom schema - e.g. the id in my case should be equivalent to the 
  full URL of the page of the deployed site.
  
  You have seen http://wiki.apache.org/solr/SolrForrest and
  http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.solr/
 
 Yes, but that documentation is not helpful for a newbie like me. It 
 lists some configuration snippets without telling where to put them.
 
 Basically, I need a step-by-step instruction how to generate _static_ 
 Solr documents output, exactly like the one here 
 http://192.168.0.251:/index-creation.solr.add - but this one is 
 generated dynamically, i.e. requires a running instance of forrest, and 
 I need to generate it statically.

Hmm, I @work and I guess our firewall is not letting me check the link.
However it seems that you already has done the part of patching the xsl.

Actually did you run forrest and not forrest run. If the page is
link from your pages then it will created static. No extra work no
further configuration.

Makes me curious why you need a static index-creation.solr.add and why
not using http://192.168.0.251:/index-creation.solr.add.do directly
and let forrest inject the document.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: SolrForrest plugin

El jue, 15-01-2009 a las 08:37 -0500, Tim Williams escribió:
 On Thu, Jan 15, 2009 at 8:29 AM, Thorsten Scherler
...
  Basically, I need a step-by-step instruction how to generate _static_
  Solr documents output, exactly like the one here
  http://192.168.0.251:/index-creation.solr.add - but this one is
  generated dynamically, i.e. requires a running instance of forrest, and
  I need to generate it statically.
 
  Hmm, I @work and I guess our firewall is not letting me check the link.
  However it seems that you already has done the part of patching the xsl.
 
 
 It's not you, he referred to a private IP ;)

lol right.

... I urgently need sleep.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: SolrForrest plugin

On Thu, 2009-01-15 at 17:19 +0100, Andrzej Bialecki wrote:
 Thorsten Scherler wrote:
 
  Actually did you run forrest and not forrest run. If the page is
  link from your pages then it will created static. No extra work no
  further configuration.
  I did run forrest, and all other static pages have been created. Where 
  should I expect the solr docs? alongside the html/pdf docs?
  
  http://forrest.apache.org/docs_0_90/your-project.html
  
  http://forrest.apache.org/docs_0_90/linking.html
  
  All files that are linked from either
  - site.xml
  - tab.xml
  - anyOtherXmlHavingALinkToTheDoc.html
  are genrated along the e.g. html file in the path they are defined by
  the link.
 
 Yes, this is clear, but I don't understand how this is relevant to my 
 question. Does it mean that I should add a href=index.solr.add in 
 one of my documents?

If you want to generate the solr add pages when generating the site then
yes every page should have a link to itself but as .solr extension. This
way forrest automatically will generate this pages, when generating the
rest of the site.

 
 
  
  If you run forrest in the solr plugin it will actually connect to your
  solr server and inject the documents.
 
 I don't understand what you're saying - what does it mean to run 
 forrest in the solr plugin?


cd whiteboard/plugins/org.apache.forrest.plugin.output.solr/
forrest

This will generate the static site.


 
   
  You will find index.solr.add in build/site/.
 
 Apparently I'm still missing some vital step - after building the site I 
 can see index.html and index.pdf, but no index.solr.add .

since you did not added links, right?

Are you using the dispatcher or skins?

 
  
  Makes me curious why you need a static index-creation.solr.add and why
  not using http://192.168.0.251:/index-creation.solr.add.do directly
  and let forrest inject the document.
  Because I want to control myself when and how the documents are 
  submitted to Solr.
  
  ok, you can do the first one as well with forrest and the second with
  limitation. 
 
 Sorry, this really doesn't answer my question - you assume that I can 
 keep forrest running and use it to submit Solr documents, which I don't 
 want to do for various reasons. In such case, is it possible to generate 
 the Solr docs statically, or not?

No, you did not understand. I do not assume a running instance of
forrest. When you create your documentation statically the solr server
will be updated as well. 

The dynamic mode allows you to update specific pages. The static the
whole bunch.

salu2



 
 
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: SolrForrest plugin

On Thu, 2009-01-15 at 20:44 +0100, Thorsten Scherler wrote:
 On Thu, 2009-01-15 at 17:19 +0100, Andrzej Bialecki wrote:
...
  
  
   
   If you run forrest in the solr plugin it will actually connect to your
   solr server and inject the documents.
  
  I don't understand what you're saying - what does it mean to run 
  forrest in the solr plugin?
 
 
 cd whiteboard/plugins/org.apache.forrest.plugin.output.solr/
 forrest
 
 This will generate the static site.
...
   You will find index.solr.add in build/site/.
  
  Apparently I'm still missing some vital step - after building the site I 
  can see index.html and index.pdf, but no index.solr.add .

If you do the above and have a solr server running under the default path, 
the build will fail since the solr server has not the right schema and we are 
attempting to inject the new documents,

BUT

there should be such a file in build/site/ afterward.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: svn commit: r725650 - /forrest/branches/dispatcher_rewrite/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherTransformer.java

2008-12-11 Thread Thorsten Scherler

On Thu, 2008-12-11 at 11:57 +0100, Cyriaque Dupoirieux wrote:
 Thosten,
 
 Are you working on the main branch or are you developing in another
 one ?

In http://svn.apache.org/viewvc/forrest/branches/dispatcher_rewrite

 Because, as you know, I use the dispatcher and I would like to use
 the version you are working on...

jeje, you are coming the right moment. I finished more or less the
rewrite and need some tester. ;)

just do:

cd whiteboard
svn switch
http://svn.apache.org/viewvc/forrest/branches/dispatcher_rewrite

Then seed a project, activate the dispatcher plugin (only
org.apache.forrest.plugin.internal.dispatcher is left!) and you should
be ready to go. 

Today I did some stress testing and the rewrite is as nearly as fast as
the old one (yes it is weired that is not faster since we do not use DOM
anymore, but seems AXIOM is even slower). However I still need to
profile the memory usage since this should be much lower with the new
version.

In any form you will find the code much clearer and well documented (I
used lots of comments). There is another not yet activated feature: java
contracts. The new version is ready for java contracts (we just need to
implement an example).

Further the plugin is ready to be deployed as cocoon-2.2 block.

Hope you will like it. 

salu2
 
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

RE: [jira] Commented: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows

2008-12-04 Thread Thorsten Scherler

On Fri, 2008-12-05 at 02:47 +1000, Gavin wrote:
...
   In the pluginTemplate we can add commented out example code to
   locationmap.xml like :-
  
 locator
   !-- Uncomment the below matches once you have a stylesheet you wish to
  use.
   Note that these are needed for the plugin to work on windows. See FOR-
  1108
   --
 !--
 match pattern=plugin.transform.*.*
select
  location src=resources/stylesheets/{1}-to-{2}.xsl /
location
   src={forrest:forrest.plugins}/@plugin-name@/resources/stylesheets/{1}-
  to-{2
   }.xsl/
/select
  /match
  --
/locator
  
   Currently the locator / is empty. Then once a stylesheet has been
  created
   the dev can uncomment out the example.
  
  My comment referred to the ant target which creates the new
  plugin. It already edits some files from the pluginTemplate
  on the way to add the plugin name, so it should be trivial
  to add this extra locationmap match.
 
 Ok, that's fine I can do that, it will still need to be in comments though
 as there wont be a stylesheet for it to refer to until the plugin dev
 creates one.
 

Why not: 
match pattern=output.Text.home
  location
src={forrest:forrest.plugins}/org.apache.forrest.plugin.output.Text//
/match

or 

match pattern=org.apache.forrest.plugin.output.Text.home
  location
src={forrest:forrest.plugins}/org.apache.forrest.plugin.output.Text//
/match

This way we have a nice lm match to refer to.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: deploying pdf plugin (Was: r722698 ...output.pdf)

2008-12-03 Thread Thorsten Scherler

El mié, 03-12-2008 a las 08:55 +0100, Thorsten Scherler escribió:
 El mié, 03-12-2008 a las 12:24 +1100, David Crossley escribió:
  That just deployed the docs. However it refers to changes
  to the plugin that have not yet been deployed.
  
  There was past discussion about this but not yet done.
  It refers to the instructions about plugin management.
  
  The plugins version number would need to incremented.
  Also the new features require 0.9 forrest version.
  So need to deploy the old 0.8 based plugin one more time,
  then deploy the 0.9 version.
 
 Hmm, rats I thought the 'deploy-docs' will pick up my local version and
 publish correspondingly. I will revert the commit.

Did that now 
Commit de la revisión 722880.

The version of the plugin already had been changed (as I could see from
the merging div) leaves us to deploy to 0.9 and not 08, right?
-  0.3-dev
+  0.2-dev

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: dev-changes: documentation?

On Tue, 2008-12-02 at 14:55 +0100, EMMEL Thomas wrote:
 Hi,
 
 where can I see documented changes to the code-base (0.9dev)?

http://forrest.apache.org/docs_0_90/changes.html#version_0.9-dev

However each plugin should provide its own changes file. 


 For example, it seems that there was a change in the colors used for
 creating pdf-files:
 
 (skinconf.xml)
 old: pdfbody,
 new: body (which was previously available without meaning?)

That sounds like 
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/changes.html

However seems that is not updated (yet I am trying to do so ATM)

However there have been a lot discussion about this on the dev list and
on the user list Ferdinand made some examples on it.

 
 However, I can't find the change anywhere documented...
 Any hint?

There is always svn log. ... but see the archives first since there is
some good starting points there. 

HTH

salu2

 
 Regards
 
 Thomas
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

RE: [jira] Commented: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows

On Tue, 2008-12-02 at 21:52 +1000, Gavin wrote:
...
 
 Thanks, it also happens to be a (not necessarily the) fix for getting trunk
 working again for Windows Devs. We need to look a bit higher up in the chain
 as to what makes this work and if we can find a solution without having to
 have this fallback permanently in all plugins, current and future.

Actually it maybe our bug after all. Looking at my commit you pointed
out it feels right to have a non relative match as fallback. I mean the
relative match in the lm is for the rare case that one is requesting the
plugin directly or one needs a custom implementation of the match.
However relative path for plugins means: one cannot reuse the lm match
from a project or plugin without implementing the match. 

...and that does not feel right and more like a bug. 

 
 I don't know why, I just have the niggling feeling that because it works
 without this fix for Linux/MAC then applying the above fix for Windows feels
 to me like a hack.

The above discussed is not a hack but a clear enhancement. Well e.g.
{forrest:forrest.plugins}/org.apache.forrest.plugin.output.Text/ should
be replaced by something shorter. Awesome would be {this} but not sure
whether that is easily to implement.

salu2
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: deploying pdf plugin (Was: r722698 ...output.pdf)

El mié, 03-12-2008 a las 12:24 +1100, David Crossley escribió:
 That just deployed the docs. However it refers to changes
 to the plugin that have not yet been deployed.
 
 There was past discussion about this but not yet done.
 It refers to the instructions about plugin management.
 
 The plugins version number would need to incremented.
 Also the new features require 0.9 forrest version.
 So need to deploy the old 0.8 based plugin one more time,
 then deploy the 0.9 version.

Hmm, rats I thought the 'deploy-docs' will pick up my local version and
publish correspondingly. I will revert the commit.

salu2

 
 -David
 
  Author: thorsten
  Date: Tue Dec  2 16:18:17 2008
  New Revision: 722698
  
  URL: http://svn.apache.org/viewvc?rev=722698view=rev
  Log:
  Deployment of docs for org.apache.forrest.plugin.output.pdf plugin 
  (deployed by 'deploy-docs' target of plugin build script)
  
  Added:
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/images/update.jpg
 (with props)
  Modified:
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/changes.html
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/changes.rss
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/index.html
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/linkmap.html
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/skin/CommonMessages_de.xml
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/skin/CommonMessages_es.xml
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/skin/CommonMessages_fr.xml
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/skin/basic.css
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/skin/screen.css
  
  forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.pdf/todo.html
-- 
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

Re: [jira] Commented: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows