[jira] [Created] (COCOON-2370) Download page gpg example needs second parameter

[Sebb (Jira)]

Sebb created COCOON-2370:


 Summary: Download page gpg example needs second parameter
 Key: COCOON-2370
 URL: https://issues.apache.org/jira/browse/COCOON-2370
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core
Reporter: Sebb


It is important that the file being checked is also specified [1] on the gpg 
command line [2]

If the second paramater is omitted, gpg can report success without actually 
checking the main artifact. This should not happen on correctly constructed ASF 
downloads, as we only provide detached sigs, but we should not be documenting 
bad practise.

[1] https://www.apache.org/info/verification.html#specify_both
[2] http://cocoon.apache.org/mirror.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (COCOON-2268) To extend the image reader we need to change the visibility to the parameter of the ImageReader

[JIRA]

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

Cédric Damioli updated COCOON-2268:
---

Fix Version/s: (was: 2.1.12-dev (Current SVN))

> To extend the image reader we need to change the visibility to the parameter 
> of the ImageReader
> ---
>
> Key: COCOON-2268
> URL: https://issues.apache.org/jira/browse/COCOON-2268
> Project: Cocoon
>  Issue Type: Improvement
>  Components: * Cocoon Core
>Affects Versions: 2.1.12-dev (Current SVN)
>Reporter: Gaurav Kalia
> Attachments: patch.cocoon.imagereader.txt
>
>
> I am planing to submit a patch to support almost all  image formats with a 
> new  ImageReader based on ImageMagick and I am planning to extend 
> ImageReader. To efficiently do that i need that some methods will change 
> visibility since i am only going to implement the method: 
> protected void processStream(InputStream inputStream)
> I can not see anything against the changes in the patch but if i missed 
> something please tell me so. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: {../parameter}

[Jos Snellings]

Sorry, I want to revoke this message. (my error ;-)

On Tue, Sep 25, 2012 at 1:45 PM, Jos Snellings
wrote:

> Dear,
>
> Just did a test and saw that:
>
> parameters in "relative path" notation get translated as:
>
> 
>  
>  
>   
> 
> {../map:parameter1} ==> they do not translate.
>
> Let me have a closer look...
> Meanwhile:
>  - anyone used this notation/behaviour?
>
> Strange this did not get observed before.
>
> Jos
>



-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

{../parameter}

[Jos Snellings]

Dear,

Just did a test and saw that:

parameters in "relative path" notation get translated as:




  

{../map:parameter1}==> they do not translate.

Let me have a closer look...
Meanwhile:
 - anyone used this notation/behaviour?

Strange this did not get observed before.

Jos

[jira] [Commented] (COCOON3-94) Extend Action to allow to use @src and parameter from within the sitemap

[Hudson (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON3-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236791#comment-13236791
 ] 

Hudson commented on COCOON3-94:
---

Integrated in Cocoon-trunk #160 (See 
[https://builds.apache.org/job/Cocoon-trunk/160/])
COCOON3-94
Bring back old school way of actions back to c3. Although it is not 100% like 
we had in c2.x since the body of an action ATM is ignore. (Revision 1304459)

 Result = FAILURE
thorsten : http://svn.apache.org/viewvc/?view=rev&rev=1304459
Files : 
* 
/cocoon/cocoon3/trunk/cocoon-sample/src/main/java/org/apache/cocoon/sample/action/ErrorThrowingAction.java
* 
/cocoon/cocoon3/trunk/cocoon-sitemap/src/main/java/org/apache/cocoon/sitemap/Invocation.java
* 
/cocoon/cocoon3/trunk/cocoon-sitemap/src/main/java/org/apache/cocoon/sitemap/InvocationImpl.java
* 
/cocoon/cocoon3/trunk/cocoon-sitemap/src/main/java/org/apache/cocoon/sitemap/action/Action.java
* 
/cocoon/cocoon3/trunk/cocoon-sitemap/src/main/java/org/apache/cocoon/sitemap/node/ActNode.java


> Extend Action to allow to use @src and parameter from within the sitemap
> 
>
> Key: COCOON3-94
> URL: https://issues.apache.org/jira/browse/COCOON3-94
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-sitemap
>Affects Versions: 3.0.0-beta-1
>Reporter: Thorsten Scherler
>Priority: Critical
> Fix For: 3.0.0-beta-1
>
>
> In cocoon 2.x you can use the src attribute and further use map:parameter to 
> configure an action. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (COCOON3-94) Extend Action to allow to use @src and parameter from within the sitemap

[Thorsten Scherler (Closed) (JIRA)]

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

Thorsten Scherler closed COCOON3-94.


Resolution: Fixed

Committed revision 1304459.

> Extend Action to allow to use @src and parameter from within the sitemap
> 
>
> Key: COCOON3-94
> URL: https://issues.apache.org/jira/browse/COCOON3-94
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-sitemap
>Affects Versions: 3.0.0-beta-1
>Reporter: Thorsten Scherler
>Priority: Critical
> Fix For: 3.0.0-beta-1
>
>
> In cocoon 2.x you can use the src attribute and further use map:parameter to 
> configure an action. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (COCOON3-94) Extend Action to allow to use @src and parameter from within the sitemap

[Thorsten Scherler (Created) (JIRA)]

Extend Action to allow to use @src and parameter from within the sitemap


 Key: COCOON3-94
 URL: https://issues.apache.org/jira/browse/COCOON3-94
 Project: Cocoon 3
  Issue Type: Improvement
  Components: cocoon-sitemap
Affects Versions: 3.0.0-beta-1
Reporter: Thorsten Scherler
Priority: Critical
 Fix For: 3.0.0-beta-1


In cocoon 2.x you can use the src attribute and further use map:parameter to 
configure an action. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] Created: (COCOON-2268) To extend the image reader we need to change the visibility to the parameter of the ImageReader

[Thorsten Scherler]

On Tue, 2009-09-22 at 08:38 -0700, Gaurav (JIRA) wrote:
> To extend the image reader we need to change the visibility to the parameter 
> of the ImageReader
> ---
> 
>  Key: COCOON-2268
>  URL: https://issues.apache.org/jira/browse/COCOON-2268
>  Project: Cocoon
>   Issue Type: Improvement
>   Components: * Cocoon Core
> Affects Versions: 2.1.12-dev (Current SVN)
> Reporter: Gaurav
>  Fix For: 2.1.12-dev (Current SVN)
>  Attachments: patch.cocoon.imagereader.txt
> 
> I am planing to submit a patch to support almost all  image formats with a 
> new  ImageReader based on ImageMagick and I am planning to extend 
> ImageReader. To efficiently do that i need that some methods will change 
> visibility since i am only going to implement the method: 
> 
> protected void processStream(InputStream inputStream)
> 
> I can not see anything against the changes in the patch but if i missed 
> something please tell me so. 


I reviewed the patch and I do not see any problem with it.

If nobody objects withing 48 hours I will apply the patch.

salu2
-- 
Thorsten Scherler 
Open Source Java 

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

[jira] Updated: (COCOON-2268) To extend the image reader we need to change the visibility to the parameter of the ImageReader

[Gaurav (JIRA)]

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

Gaurav updated COCOON-2268:
---

Attachment: patch.cocoon.imagereader.txt

Patch for ImageReader.

> To extend the image reader we need to change the visibility to the parameter 
> of the ImageReader
> ---
>
> Key: COCOON-2268
> URL: https://issues.apache.org/jira/browse/COCOON-2268
> Project: Cocoon
>  Issue Type: Improvement
>  Components: * Cocoon Core
>Affects Versions: 2.1.12-dev (Current SVN)
>Reporter: Gaurav
> Fix For: 2.1.12-dev (Current SVN)
>
> Attachments: patch.cocoon.imagereader.txt
>
>
> I am planing to submit a patch to support almost all  image formats with a 
> new  ImageReader based on ImageMagick and I am planning to extend 
> ImageReader. To efficiently do that i need that some methods will change 
> visibility since i am only going to implement the method: 
> protected void processStream(InputStream inputStream)
> I can not see anything against the changes in the patch but if i missed 
> something please tell me so. 

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

[jira] Created: (COCOON-2268) To extend the image reader we need to change the visibility to the parameter of the ImageReader

[Gaurav (JIRA)]

To extend the image reader we need to change the visibility to the parameter of 
the ImageReader
---

 Key: COCOON-2268
 URL: https://issues.apache.org/jira/browse/COCOON-2268
 Project: Cocoon
  Issue Type: Improvement
  Components: * Cocoon Core
Affects Versions: 2.1.12-dev (Current SVN)
Reporter: Gaurav
 Fix For: 2.1.12-dev (Current SVN)
 Attachments: patch.cocoon.imagereader.txt

I am planing to submit a patch to support almost all  image formats with a new  
ImageReader based on ImageMagick and I am planning to extend ImageReader. To 
efficiently do that i need that some methods will change visibility since i am 
only going to implement the method: 

protected void processStream(InputStream inputStream)

I can not see anything against the changes in the patch but if i missed 
something please tell me so. 

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

[jira] Commented: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Alfred Nathaniel (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610660#action_12610660
 ] 

Alfred Nathaniel commented on COCOON-2133:
--

Backported to 2.1: http://svn.apache.org/viewvc?rev=674121&view=rev

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Reporter: Robin Wyles
>Assignee: Grzegorz Kossakowski
>Priority: Minor
> Attachments: 4x2.jpg, 
> cocoon-core-SitemapComponentTestCase-read-method.patch, 
> cocoon-imageop-impl-no-effects-test.patch, 
> cocoon-imageop-impl-resize-operation-and-test.patch , ResizeOperation.patch, 
> RevisedResizeOperationPatch.txt
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Closed: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[David Crossley (JIRA)]

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

David Crossley closed COCOON-1928.
--

Resolution: Won't Fix

Please see FOR-1071 where we enabled such configuration using xml entities in 
the main forrest sitemap.

> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: https://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

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

[jira] Updated: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Grzegorz Kossakowski (JIRA)]

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

Grzegorz Kossakowski updated COCOON-2133:
-

Affects version (Component): Parent values: Blocks: ImageOp(10334). Level 1 
values: 1.0.0-M1-SNAPSHOT(10335). 
Fix version (Component): Parent values: Blocks: ImageOp(10336). Level 1 
values: 1.0.0-M1-SNAPSHOT(10337). 
  Affects Version/s: (was: 2.2-dev (Current SVN))
 (was: 2.1.11)

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Reporter: Robin Wyles
>Assignee: Grzegorz Kossakowski
>Priority: Minor
> Attachments: 4x2.jpg, 
> cocoon-core-SitemapComponentTestCase-read-method.patch, 
> cocoon-imageop-impl-no-effects-test.patch, 
> cocoon-imageop-impl-resize-operation-and-test.patch , ResizeOperation.patch, 
> RevisedResizeOperationPatch.txt
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Closed: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Grzegorz Kossakowski (JIRA)]

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

Grzegorz Kossakowski closed COCOON-2133.


Resolution: Fixed

Patch comitted in r610567.

Thanks Robin for providing test-case! The fact that your improvement is covered 
by tests moved your patch to the top of my personal patches-to-review-and-apply 
queue. :)

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Reporter: Robin Wyles
>Assignee: Grzegorz Kossakowski
>Priority: Minor
> Attachments: 4x2.jpg, 
> cocoon-core-SitemapComponentTestCase-read-method.patch, 
> cocoon-imageop-impl-no-effects-test.patch, 
> cocoon-imageop-impl-resize-operation-and-test.patch , ResizeOperation.patch, 
> RevisedResizeOperationPatch.txt
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Assigned: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Grzegorz Kossakowski (JIRA)]

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

Grzegorz Kossakowski reassigned COCOON-2133:


Assignee: Grzegorz Kossakowski

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Affects Versions: 2.1.11, 2.2-dev (Current SVN)
>Reporter: Robin Wyles
>Assignee: Grzegorz Kossakowski
>Priority: Minor
> Attachments: 4x2.jpg, 
> cocoon-core-SitemapComponentTestCase-read-method.patch, 
> cocoon-imageop-impl-no-effects-test.patch, 
> cocoon-imageop-impl-resize-operation-and-test.patch , ResizeOperation.patch, 
> RevisedResizeOperationPatch.txt
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Updated: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Robin Wyles (JIRA)]

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

Robin Wyles updated COCOON-2133:


Attachment: 4x2.jpg
cocoon-imageop-impl-resize-operation-and-test.patch 

Grzegorz, thanks for your test case patches!

Attached is patch for "allow-enlarge" parameter along with a suitable test case.

Writing the tests I uncovered some strange behavior with allow-enlarge 
parameter when used with preserve-ratio. It seems that before my patches the 
ResizeOperation would fail to enlarge an image at all when preserve-ratio was 
set to true and only one dimension was supplied. This final patch fixes this 
issue, using allow-enlarge parameter to control first whether image should be 
resized and then preserve-ratio to determine final size.

I also include my test image separately as well - for me at least images often 
seem to corrupt when supplied as part of a patch.

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Affects Versions: 2.1.11, 2.2-dev (Current SVN)
>Reporter: Robin Wyles
>Priority: Minor
> Attachments: 4x2.jpg, 
> cocoon-core-SitemapComponentTestCase-read-method.patch, 
> cocoon-imageop-impl-no-effects-test.patch, 
> cocoon-imageop-impl-resize-operation-and-test.patch , ResizeOperation.patch, 
> RevisedResizeOperationPatch.txt
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Updated: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Grzegorz Kossakowski (JIRA)]

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

Grzegorz Kossakowski updated COCOON-2133:
-

Attachment: cocoon-imageop-impl-no-effects-test.patch

Here comes a patch adding very simple test for ImageOp reader.

I have not given both patches too much testing but I hope you will find it 
helpful.

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Affects Versions: 2.1.11, 2.2-dev (Current SVN)
>Reporter: Robin Wyles
>Priority: Minor
> Attachments: cocoon-core-SitemapComponentTestCase-read-method.patch, 
> cocoon-imageop-impl-no-effects-test.patch, ResizeOperation.patch, 
> RevisedResizeOperationPatch.txt
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Updated: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Grzegorz Kossakowski (JIRA)]

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

Grzegorz Kossakowski updated COCOON-2133:
-

Attachment: cocoon-core-SitemapComponentTestCase-read-method.patch

Having some spare time while waiting for a bus I opened my laptop and created 
this patch. It adds missing read() method to be used for testing Readers.

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Affects Versions: 2.1.11, 2.2-dev (Current SVN)
>Reporter: Robin Wyles
>Priority: Minor
> Attachments: cocoon-core-SitemapComponentTestCase-read-method.patch, 
> ResizeOperation.patch, RevisedResizeOperationPatch.txt
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Commented: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Robin Wyles (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555291#action_12555291
 ] 

Robin Wyles commented on COCOON-2133:
-

I'd be happy to provide a test-case but I can't see how to set one up to test a 
Reader. Looking at SitemapComponentTestCase I don't see a corresponding "read" 
method and I can't find any test-cases for other readers in any other blocks. 
If you can let me know how I might implement this test-case then I'll write it.

In the meantime I attach a revised patch that fixes a bug with the previous 
patch where scaling with allowEnlarge property would be ignored when only one 
dimension needs to be reduced in size.

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Affects Versions: 2.1.11, 2.2-dev (Current SVN)
>Reporter: Robin Wyles
>Priority: Minor
> Attachments: ResizeOperation.patch, RevisedResizeOperationPatch.txt
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Updated: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Robin Wyles (JIRA)]

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

Robin Wyles updated COCOON-2133:


Attachment: RevisedResizeOperationPatch.txt

Revised patch that fixes a bug with the previous patch where scaling with 
allowEnlarge property would be ignored when only one dimension needs to be 
reduced in size.

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Affects Versions: 2.1.11, 2.2-dev (Current SVN)
>Reporter: Robin Wyles
>Priority: Minor
> Attachments: ResizeOperation.patch, RevisedResizeOperationPatch.txt
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Updated: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Grzegorz Kossakowski (JIRA)]

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

Grzegorz Kossakowski updated COCOON-2133:
-

Fix Version/s: (was: 2.1.11)
   (was: 2.2-dev (Current SVN))

Thanks Robin for providing a patch.

Before it can be applied I would like to see it covered by test-case. Could 
also attach a test for allow-enlarge parameter?

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Affects Versions: 2.1.11, 2.2-dev (Current SVN)
>Reporter: Robin Wyles
>Priority: Minor
> Attachments: ResizeOperation.patch
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Closed: (COCOON-2067) CocoonServlet error message names wrong parameter: configurations

[solprovider (JIRA)]

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

solprovider closed COCOON-2067.
---

 Resolution: Fixed
  Fix Version/s: 2.1.11-dev (Current SVN)
Affects version (Component): Parent values: Cocoon Core(10151). 
Fix version (Component): Parent values: Cocoon Core(10227). 

Added 's'.  
Committed 20071224 revision 606745 for 2.1.11.

> CocoonServlet error message names wrong parameter: configurations
> -
>
> Key: COCOON-2067
> URL: https://issues.apache.org/jira/browse/COCOON-2067
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.1.10
>Reporter: solprovider
>Priority: Trivial
> Fix For: 2.1.11-dev (Current SVN)
>
>
> The error message in the last line of the code below misnames the parameter 
> as 'configuration' instead of 'configurations'.
> The easy fix is to add an 's'.
> A better fix would move the string to a constant for use in all the code below
> [Obviously excerpted code.  Pretend ellipses are after each line.]
> public class CocoonServlet extends HttpServlet { 
>   public void init(ServletConfig conf) throws ServletException {
>   this.appContext.put(Constants.CONTEXT_CONFIG_URL, 
> getConfigFile(conf.getInitParameter("configurations")));
>   }
> private URL getConfigFile(final String configFileName) throws 
> ServletException {
> getLogger().warn("Servlet initialization argument 
> 'configurations' not specified, attempting to use '/WEB-INF/cocoon.xconf'");
>  getLogger().debug("Using configuration file: " + usedFileName);
>  String msg = "Init parameter 'configurations' is invalid : " + 
> usedFileName;
>String msg = "Init parameter 'configurations' is invalid : " + 
> usedFileName;
>  String msg = "Init parameter 'configuration' doesn't name an 
> existing resource : " + usedFileName;
>}
> }

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

[jira] Updated: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Robin Wyles (JIRA)]

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

Robin Wyles updated COCOON-2133:


Attachment: ResizeOperation.patch

Patch to add "allow-enlarge" parameter to imageop resize operation.

> Addition of "allow-enlarge" parameter to ImageOp resize operation
> -
>
> Key: COCOON-2133
> URL: https://issues.apache.org/jira/browse/COCOON-2133
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: ImageOp
>Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
>Reporter: Robin Wyles
>Priority: Minor
> Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
>
> Attachments: ResizeOperation.patch
>
>
> The addition of an "allow-enlarge" parameter to the resize operation allows 
> the user to control whether an image should be enlarged by the operation. 
> This new  parameter is declared in the sitemap like so:
> 
>   
>   
>   
>   
> 

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

[jira] Created: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation

[Robin Wyles (JIRA)]

Addition of "allow-enlarge" parameter to ImageOp resize operation
-

 Key: COCOON-2133
 URL: https://issues.apache.org/jira/browse/COCOON-2133
 Project: Cocoon
  Issue Type: Improvement
  Components: Blocks: ImageOp
Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Reporter: Robin Wyles
Priority: Minor
 Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)


The addition of an "allow-enlarge" parameter to the resize operation allows the 
user to control whether an image should be enlarged by the operation. 

This new  parameter is declared in the sitemap like so:








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

Content-Type charset parameter and application/ types

[Tobia Conforto]

Hello

According to tests I've done and to a piece of documentation, it would
seem that a "charset=" parameter is added to the Content-Type header
only when the mime type starts with text/.

In fact http://cocoon.apache.org/2.1/userdocs/xml-serializer.html says:

    The charset parameter should not be specified explicitly;
instead, when the top-level media type is text, a charset
    parameter should be added according to the character encoding
actually used by the output method.

But this should also happen for application/xml, application/xhtml+xml,
and possibly other types.  RFC 3236 says:

application/xhtml+xml

    The charset parameter has identical semantics to the charset
    parameter of the "application/xml" media type

and RFC 3023 says:

application/xml

Although listed as an optional parameter, the use of the charset
parameter is STRONGLY RECOMMENDED, since [whatever]

Is this the serializer's fault?
The servlet container's fault?


Tobia

[jira] Created: (COCOON-2067) CocoonServlet error message names wrong parameter: configurations

[solprovider (JIRA)]

CocoonServlet error message names wrong parameter: configurations
-

 Key: COCOON-2067
 URL: https://issues.apache.org/jira/browse/COCOON-2067
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core
Affects Versions: 2.1.10
Reporter: solprovider
Priority: Trivial


The error message in the last line of the code below misnames the parameter as 
'configuration' instead of 'configurations'.
The easy fix is to add an 's'.
A better fix would move the string to a constant for use in all the code below

[Obviously excerpted code.  Pretend ellipses are after each line.]
public class CocoonServlet extends HttpServlet { 
  public void init(ServletConfig conf) throws ServletException {
  this.appContext.put(Constants.CONTEXT_CONFIG_URL, 
getConfigFile(conf.getInitParameter("configurations")));
  }
private URL getConfigFile(final String configFileName) throws 
ServletException {
getLogger().warn("Servlet initialization argument 'configurations' 
not specified, attempting to use '/WEB-INF/cocoon.xconf'");
 getLogger().debug("Using configuration file: " + usedFileName);
 String msg = "Init parameter 'configurations' is invalid : " + 
usedFileName;
   String msg = "Init parameter 'configurations' is invalid : " + 
usedFileName;
 String msg = "Init parameter 'configuration' doesn't name an existing 
resource : " + usedFileName;
   }
}

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

RE: Using variables in sitemap component parameter

[Andrew Stevens]

From: "Bas Suverkropp PC" <[EMAIL PROTECTED]>
To: 


More a query for the user list, I'd have thought...


Subject: Using variables in sitemap component parameter
Date: Thu, 3 May 2007 13:56:34 +0200

I am trying to make my sitemap environment-independent, with local 
parameters read from

a properties file (assembly.properties)

Unfortunately, using properties does not seem to work in the components 
declaration.


I want to replace

src="nl.kluwer.cocoon.transformation.HtmlMailTransformer" >

smtp.provider.com
25
[EMAIL PROTECTED]


with something like

src="nl.kluwer.cocoon.transformation.HtmlMailTransformer" >

{assembly:smtphost}
{assembly:smtpport}
{assembly:from}


Any suggestions?


You didn't say which version of Cocoon you're using.  With the latest 2.2 
stuff, I believe the intended method is that you include all different 
versions of the configurations in your .war file and specify a "running 
mode" in a system property to tell Cocoon which set to use.  With 2.1.x, 
what I've done in the past is to use an external XML entity file rather than 
a properties file, include it in the relevant place with e.g.



]>


src="nl.kluwer.cocoon.transformation.HtmlMailTransformer" >

&emailsettings;


and let the parser do the work.  The .ent file contains the markup and 
settings to include inside the map:transformer; .ent (XMLSpy's default for 
external entities) rather than .xml as this probably won't be a well-formed 
XML document, but you could name it anything you like.
The only down side I found was that editing the settings file required a 
restart of the application before the changes would take effect (but that 
may vary depending on which app server you're using).



Andrew.
--
http://pseudoq.sourceforge.net/  Open source java Sudoku application.

_
Reserve your place in history - Email Britain! 
http://www.emailbritain.co.uk/

RE: Using variables in sitemap component parameter

[Geert Josten]

Dear Bas,

Rewrite your component to accept properties at transform time and pass
them in the map:transform step with map:parameter calls.

Groeten,
Geert 

> 
   
 
Drs. G.P.H. Josten
Consultant
 
 

Daidalos BV
Source of Innovation
Hoekeindsehof 1-4
2665  JZ  Bleiswijk
Tel.: +31 (0) 10 850 1200
Fax: +31 (0) 10 850 1199
www.daidalos.nl
KvK 27164984


De informatie - verzonden in of met dit emailbericht - is afkomstig van 
Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit 
bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit 
bericht kunnen geen rechten worden ontleend.
 

> From: Bas Suverkropp PC [mailto:[EMAIL PROTECTED] 
> Sent: donderdag 3 mei 2007 13:57
> To: dev@cocoon.apache.org
> Subject: Using variables in sitemap component parameter
> 
> I am trying to make my sitemap environment-independent, with 
> local parameters read from a properties file (assembly.properties)
> 
> Unfortunately, using properties does not seem to work in the 
> components declaration.
> 
> I want to replace
> 
>  src="nl.kluwer.cocoon.transformation.HtmlMailTransformer" >
>   smtp.provider.com
>   25
>   [EMAIL PROTECTED]
> 
> 
> with something like
> 
>  src="nl.kluwer.cocoon.transformation.HtmlMailTransformer" >
>   {assembly:smtphost}
>   {assembly:smtpport}
>   {assembly:from}
> 
> 
> Any suggestions?
> 
> This email and any attachments may contain confidential or 
> privileged information and is intended for the addressee 
> only. If you are not the intended recipient, please 
> immediately notify us by email or telephone and delete the 
> original email and attachments without using, disseminating 
> or reproducing its contents to anyone other than the intended 
> recipient. Kluwer shall not be liable for the incorrect or 
> incomplete transmission of this email or any attachments, nor 
> for unauthorized use by its employees. 
> Deze e-mail (en eventuele bijlagen) kan vertrouwelijke 
> informatie bevatten en is alleen bestemd voor de 
> geadresseerde. Als u niet de bedoelde geadresseerde bent, 
> informeer ons a.u.b. hierover per e-mail of telefoon en 
> verwijder de originele e-mail zonder de inhoud en bijlagen te 
> gebruiken, te verspreiden of te vermenigvuldigen aan anderen 
> dan de bedoelde geadresseerde. Kluwer is niet aansprakelijk 
> voor onjuiste of incomplete verzending van deze e-mail en 
> bijlagen, noch voor ongeautoriseerd gebruik door haar medewerkers. 
> Kluwer bv is statutair gevestigd te Deventer en ingeschreven 
> in het handelsregister van de Kamer van Koophandel onder het 
> nummer 380 132 26.
>

Using variables in sitemap component parameter

[Bas Suverkropp PC]

I am trying to make my sitemap environment-independent, with local parameters 
read from 
a properties file (assembly.properties)

Unfortunately, using properties does not seem to work in the components 
declaration.

I want to replace


smtp.provider.com
25
[EMAIL PROTECTED]


with something like


{assembly:smtphost}
{assembly:smtpport}
{assembly:from}


Any suggestions?

This email and any attachments may contain confidential or privileged 
information and is intended for the addressee only. If you are not the intended 
recipient, please immediately notify us by email or telephone and delete the 
original email and attachments without using, disseminating or reproducing its 
contents to anyone other than the intended recipient. Kluwer shall not be 
liable for the incorrect or incomplete transmission of this email or any 
attachments, nor for unauthorized use by its employees. 
Deze e-mail (en eventuele bijlagen) kan vertrouwelijke informatie bevatten en 
is alleen bestemd voor de geadresseerde. Als u niet de bedoelde geadresseerde 
bent, informeer ons a.u.b. hierover per e-mail of telefoon en verwijder de 
originele e-mail zonder de inhoud en bijlagen te gebruiken, te verspreiden of 
te vermenigvuldigen aan anderen dan de bedoelde geadresseerde. Kluwer is niet 
aansprakelijk voor onjuiste of incomplete verzending van deze e-mail en 
bijlagen, noch voor ongeautoriseerd gebruik door haar medewerkers. 
Kluwer bv is statutair gevestigd te Deventer en ingeschreven in het 
handelsregister van de Kamer van Koophandel onder het nummer 380 132 26.

[jira] Closed: (COCOON-1998) CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed COCOON-1998.


Resolution: Fixed

Thanks for the patch!!!
It's applied now.

> CocoonPortlet needs to allow overriding servlet-path parameter with 
> preferences.
> 
>
> Key: COCOON-1998
> URL: https://issues.apache.org/jira/browse/COCOON-1998
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Portal
>Affects Versions: 2.1.11-dev (Current SVN)
>Reporter: Woonsan Ko
> Assigned To: Carsten Ziegeler
> Fix For: 2.1.11-dev (Current SVN)
>
> Attachments: servlet-path-pref-diff.txt, servlet-path-pref-diff2.txt, 
> servlet-path-pref-diff3.txt
>
>
> The CocoonPortlet in BRANCH_2_1_X does not allow overriding the 
> *servlet-path* init parameter by preferences.
> If the CocoonPortlet reads preferences to override the 'servlet-path', portal 
> users can use manycoplet fragments without tedious portlet tag additions.
> FYI, some portals such as Jetspeed 2 allows inline preference settings, not 
> allowed for end-users.
> Without this feature, portal users have to add portlet tags in the 
> portlet.xml whenever they need to use another coplet in the portal site.
> To test properly for the patch, you should add init-parameter in the 
> cocoon/WEB-INF/portlet.xml like the
> following:
>   
> CocoonPortlet
> ...
> 
>   allow-preferences
>   true
> 
> ...
>   
> ManagedCocoonPortlet will read preferences just when the above parameter is 
> set to true. (I borrowed this from GenericServletPortlet in Apache portal 
> bridges.)
> I've tested this modification under Jetspeed-2 
> (/WEB-INF/pages/default-page.psml).
> The portlet fragment can be added with preferences like the following:
> 
> 
> 
> 
> samples/blocks/portal/portlets/helloworld
> 
> 

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

[jira] Updated: (COCOON-1998) CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Woonsan Ko (JIRA)]

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

Woonsan Ko updated COCOON-1998:
---

Attachment: servlet-path-pref-diff3.txt

I'm sorry and thank you, Carsten. 
I modified it not to hide instance variable. Also I reviewed and tested again. 
It works fine when I tested on my production server.

To excuse myself, the local variable, 'servletPath' was added in Aug. 12, 2004, 
so I did not modify the local variable hiding the instance variable.
Anyway, I think you are right. The local variable hiding the instance member is 
so confusing. Thanks.

> CocoonPortlet needs to allow overriding servlet-path parameter with 
> preferences.
> 
>
> Key: COCOON-1998
> URL: https://issues.apache.org/jira/browse/COCOON-1998
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Portal
>Affects Versions: 2.1.11-dev (Current SVN)
>Reporter: Woonsan Ko
> Assigned To: Carsten Ziegeler
> Fix For: 2.1.11-dev (Current SVN)
>
> Attachments: servlet-path-pref-diff.txt, servlet-path-pref-diff2.txt, 
> servlet-path-pref-diff3.txt
>
>
> The CocoonPortlet in BRANCH_2_1_X does not allow overriding the 
> *servlet-path* init parameter by preferences.
> If the CocoonPortlet reads preferences to override the 'servlet-path', portal 
> users can use manycoplet fragments without tedious portlet tag additions.
> FYI, some portals such as Jetspeed 2 allows inline preference settings, not 
> allowed for end-users.
> Without this feature, portal users have to add portlet tags in the 
> portlet.xml whenever they need to use another coplet in the portal site.
> To test properly for the patch, you should add init-parameter in the 
> cocoon/WEB-INF/portlet.xml like the
> following:
>   
> CocoonPortlet
> ...
> 
>   allow-preferences
>   true
> 
> ...
>   
> ManagedCocoonPortlet will read preferences just when the above parameter is 
> set to true. (I borrowed this from GenericServletPortlet in Apache portal 
> bridges.)
> I've tested this modification under Jetspeed-2 
> (/WEB-INF/pages/default-page.psml).
> The portlet fragment can be added with preferences like the following:
> 
> 
> 
> 
> samples/blocks/portal/portlets/helloworld
> 
> 

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

[jira] Commented: (COCOON-1998) CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469787
 ] 

Carsten Ziegeler commented on COCOON-1998:
--

Sorry, but I think the patch is still not 100% correct. In this snippet:
>>>
+if (servletPath.startsWith("/")) {
+servletPath = servletPath.substring(1);
+}
+if (servletPath.endsWith("/")) {
+servletPath = servletPath.substring(0, servletPath.length() - 1);
+}
+
 String pathInfo = getPathInfo(request);
 
 String uri = servletPath;
<<<
servletPath is still changed, I think it should be that you first assing 
servletPath to "uri" and then only work with "uri" from there, like
if (uri.startsWith("/")) {
  uri = uri.substring(1);
}
and so on.

I think servletPath should never be changed inside these methods.


> CocoonPortlet needs to allow overriding servlet-path parameter with 
> preferences.
> 
>
> Key: COCOON-1998
> URL: https://issues.apache.org/jira/browse/COCOON-1998
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Portal
>Affects Versions: 2.1.11-dev (Current SVN)
>Reporter: Woonsan Ko
> Assigned To: Carsten Ziegeler
> Fix For: 2.1.11-dev (Current SVN)
>
> Attachments: servlet-path-pref-diff.txt, servlet-path-pref-diff2.txt
>
>
> The CocoonPortlet in BRANCH_2_1_X does not allow overriding the 
> *servlet-path* init parameter by preferences.
> If the CocoonPortlet reads preferences to override the 'servlet-path', portal 
> users can use manycoplet fragments without tedious portlet tag additions.
> FYI, some portals such as Jetspeed 2 allows inline preference settings, not 
> allowed for end-users.
> Without this feature, portal users have to add portlet tags in the 
> portlet.xml whenever they need to use another coplet in the portal site.
> To test properly for the patch, you should add init-parameter in the 
> cocoon/WEB-INF/portlet.xml like the
> following:
>   
>     CocoonPortlet
> ...
> 
>   allow-preferences
>   true
> 
> ...
>   
> ManagedCocoonPortlet will read preferences just when the above parameter is 
> set to true. (I borrowed this from GenericServletPortlet in Apache portal 
> bridges.)
> I've tested this modification under Jetspeed-2 
> (/WEB-INF/pages/default-page.psml).
> The portlet fragment can be added with preferences like the following:
> 
> 
> 
> 
> samples/blocks/portal/portlets/helloworld
> 
> 

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

[jira] Updated: (COCOON-1998) CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Woonsan Ko (JIRA)]

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

Woonsan Ko updated COCOON-1998:
---

Attachment: servlet-path-pref-diff2.txt

Guided by Carsten, I modified my patch to use local 'servlet-path' variable, 
and change the name of the init-parameter to 'servlet-path-overriding'.
Also, I modified the portlet.xml to set this parameter to 'true' by default.

FYI, I tested like the following steps using Apache Jetspeed 2:

0. Deploy cocoon.war into Apache Jetspeed2. Usually just put cocoon.war in 
/jetseed/WEB-INF/deploy/.

1. Copy 'cocoon/samples/blocks/portal/portlets/hello.html' to 
'cocoon/samples/blocks/portal/portlets/hello2.html', and edit 'hello2.html' to 
display different content.

2. Add a map in the 'cocoon/samples/blocks/portal/portlets/sitemap.xmap' like 
the following:
  

  

3. Add the following fragments into 'jetspeed/WEB-INF/pages/default-page.psml 
like the following:



  
  




  
  
  
samples/blocks/portal/portlets/hello2
      



Thanks.

> CocoonPortlet needs to allow overriding servlet-path parameter with 
> preferences.
> 
>
> Key: COCOON-1998
> URL: https://issues.apache.org/jira/browse/COCOON-1998
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Portal
>Affects Versions: 2.1.11-dev (Current SVN)
>Reporter: Woonsan Ko
> Assigned To: Carsten Ziegeler
> Fix For: 2.1.11-dev (Current SVN)
>
> Attachments: servlet-path-pref-diff.txt, servlet-path-pref-diff2.txt
>
>
> The CocoonPortlet in BRANCH_2_1_X does not allow overriding the 
> *servlet-path* init parameter by preferences.
> If the CocoonPortlet reads preferences to override the 'servlet-path', portal 
> users can use manycoplet fragments without tedious portlet tag additions.
> FYI, some portals such as Jetspeed 2 allows inline preference settings, not 
> allowed for end-users.
> Without this feature, portal users have to add portlet tags in the 
> portlet.xml whenever they need to use another coplet in the portal site.
> To test properly for the patch, you should add init-parameter in the 
> cocoon/WEB-INF/portlet.xml like the
> following:
>   
> CocoonPortlet
> ...
> 
>   allow-preferences
>   true
> 
> ...
>   
> ManagedCocoonPortlet will read preferences just when the above parameter is 
> set to true. (I borrowed this from GenericServletPortlet in Apache portal 
> bridges.)
> I've tested this modification under Jetspeed-2 
> (/WEB-INF/pages/default-page.psml).
> The portlet fragment can be added with preferences like the following:
> 
> 
> 
> 
> samples/blocks/portal/portlets/helloworld
> 
> 

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

Re: CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Woonsan Ko]

Hi Carsten,

Thanks for your comment.
I agree with you. It's somewhat strange.
I seems right to use local variable instead of instance variable.

I'll test again and post to JIRA until tomorrow.

Thank you very much.

Regards,

Woonsan.

--- Carsten Ziegeler <[EMAIL PROTECTED]> wrote:

> Hi Woonsan,
> 
> thanks for the patch! I'm wondering a little bit about the following
> code (I removed some lines to just quote the important parts):
> 
> a)String servletPath = this.servletPath;
> 
>   ...
> if (this.servletPath.startsWith("/")) {
> this.servletPath = this.servletPath.substring(1);
> }
> if (this.servletPath.endsWith("/")) {
> this.servletPath = servletPath.substring(0,
> servletPath.length() - 1);
> }
> 
> String pathInfo = getPathInfo(request);
> 
> z)String uri = servletPath;
> 
> In line a) you create a new local variable and initialize it with the
> value if the instance variable servletPath. Finally in z) you assign
> the value of the local variable to "uri".
> 
> Inbetween you check the value of the instance variable servletPath and
> change it eventually. I think, it would be correct to check the *local*
> variable servletPath and change this instead.
> 
> What do you think?
> 
> Carsten
> 
> Woonsan Ko wrote:
> > Hi Carsten,
> > 
> > Sorry it took so long to get back to you.
> > My INBOX became overloaded and now I finally caught up.
> > 
> > I just posted my patch to JIRA.
> > Thanks.
> > 
> > Regards,
> > 
> > Woonsan
> > 
> > --- Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> > 
> >> Woon-San Ko wrote:
> >>> Hi, all.
> >>>
> >>> The CocoonPortlet in BRANCH_2_1_X does not allow overriding the 
> >>> *servlet-path* init
> parameter
> >> by
> >>> preferences.
> >>> So, portal users have to add portlet tags in the portlet.xml whenever 
> >>> they need to use
> another
> >>> coplet in the portal site.
> >>>
> >>> If the CocoonPortlet reads preferences to override the *servlet-path*, 
> >>> portal users can use
> >> many
> >>> coplet fragments without tedious portlet tag additions.
> >>>
> >> Hi,
> >>
> >> I think this is a good addition to the ManagedCocoonPortlet. Can you
> >> please come up with a proper patch that you file into Jira? Every patch
> >> should go through our tracking system. If you also could change the code
> >> a little bit to avoid the code duplication (by factoring this out into a
> >>  method) would be great!
> >>
> >> Thanks
> >> Carsten
> >>
> >> -- 
> >> Carsten Ziegeler - Open Source Group, S&N AG
> >> http://www.s-und-n.de
> >> http://www.osoco.org/weblogs/rael/
> >>
> > 
> > 
> > 
> >  
> > 
> > Get your own web address.  
> > Have a HUGE year through Yahoo! Small Business.
> > http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
> > 
> 
> 
> -- 
> Carsten Ziegeler
> http://www.osoco.org/weblogs/rael/
> 



 

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

[jira] Assigned: (COCOON-1998) CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned COCOON-1998:


Assignee: Carsten Ziegeler

> CocoonPortlet needs to allow overriding servlet-path parameter with 
> preferences.
> 
>
> Key: COCOON-1998
> URL: https://issues.apache.org/jira/browse/COCOON-1998
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Portal
>Affects Versions: 2.1.11-dev (Current SVN)
>Reporter: Woonsan Ko
> Assigned To: Carsten Ziegeler
> Fix For: 2.1.11-dev (Current SVN)
>
> Attachments: servlet-path-pref-diff.txt
>
>
> The CocoonPortlet in BRANCH_2_1_X does not allow overriding the 
> *servlet-path* init parameter by preferences.
> If the CocoonPortlet reads preferences to override the 'servlet-path', portal 
> users can use manycoplet fragments without tedious portlet tag additions.
> FYI, some portals such as Jetspeed 2 allows inline preference settings, not 
> allowed for end-users.
> Without this feature, portal users have to add portlet tags in the 
> portlet.xml whenever they need to use another coplet in the portal site.
> To test properly for the patch, you should add init-parameter in the 
> cocoon/WEB-INF/portlet.xml like the
> following:
>   
> CocoonPortlet
> ...
> 
>   allow-preferences
>   true
> 
> ...
>   
> ManagedCocoonPortlet will read preferences just when the above parameter is 
> set to true. (I borrowed this from GenericServletPortlet in Apache portal 
> bridges.)
> I've tested this modification under Jetspeed-2 
> (/WEB-INF/pages/default-page.psml).
> The portlet fragment can be added with preferences like the following:
> 
> 
> 
> 
> samples/blocks/portal/portlets/helloworld
> 
> 

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

Re: CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Carsten Ziegeler]

Hi Woonsan,

thanks for the patch! I'm wondering a little bit about the following
code (I removed some lines to just quote the important parts):

a)String servletPath = this.servletPath;

  ...
if (this.servletPath.startsWith("/")) {
this.servletPath = this.servletPath.substring(1);
}
if (this.servletPath.endsWith("/")) {
this.servletPath = servletPath.substring(0,
servletPath.length() - 1);
}

String pathInfo = getPathInfo(request);

z)String uri = servletPath;

In line a) you create a new local variable and initialize it with the
value if the instance variable servletPath. Finally in z) you assign
the value of the local variable to "uri".

Inbetween you check the value of the instance variable servletPath and
change it eventually. I think, it would be correct to check the *local*
variable servletPath and change this instead.

What do you think?

Carsten

Woonsan Ko wrote:
> Hi Carsten,
> 
> Sorry it took so long to get back to you.
> My INBOX became overloaded and now I finally caught up.
> 
> I just posted my patch to JIRA.
> Thanks.
> 
> Regards,
> 
> Woonsan
> 
> --- Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> 
>> Woon-San Ko wrote:
>>> Hi, all.
>>>
>>> The CocoonPortlet in BRANCH_2_1_X does not allow overriding the 
>>> *servlet-path* init parameter
>> by
>>> preferences.
>>> So, portal users have to add portlet tags in the portlet.xml whenever they 
>>> need to use another
>>> coplet in the portal site.
>>>
>>> If the CocoonPortlet reads preferences to override the *servlet-path*, 
>>> portal users can use
>> many
>>> coplet fragments without tedious portlet tag additions.
>>>
>> Hi,
>>
>> I think this is a good addition to the ManagedCocoonPortlet. Can you
>> please come up with a proper patch that you file into Jira? Every patch
>> should go through our tracking system. If you also could change the code
>> a little bit to avoid the code duplication (by factoring this out into a
>>  method) would be great!
>>
>> Thanks
>> Carsten
>>
>> -- 
>> Carsten Ziegeler - Open Source Group, S&N AG
>> http://www.s-und-n.de
>> http://www.osoco.org/weblogs/rael/
>>
> 
> 
> 
>  
> 
> Get your own web address.  
> Have a HUGE year through Yahoo! Small Business.
> http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
> 


-- 
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/

Re: CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Woonsan Ko]

Hi Carsten,

Sorry it took so long to get back to you.
My INBOX became overloaded and now I finally caught up.

I just posted my patch to JIRA.
Thanks.

Regards,

Woonsan

--- Carsten Ziegeler <[EMAIL PROTECTED]> wrote:

> Woon-San Ko wrote:
> > Hi, all.
> > 
> > The CocoonPortlet in BRANCH_2_1_X does not allow overriding the 
> > *servlet-path* init parameter
> by
> > preferences.
> > So, portal users have to add portlet tags in the portlet.xml whenever they 
> > need to use another
> > coplet in the portal site.
> > 
> > If the CocoonPortlet reads preferences to override the *servlet-path*, 
> > portal users can use
> many
> > coplet fragments without tedious portlet tag additions.
> > 
> Hi,
> 
> I think this is a good addition to the ManagedCocoonPortlet. Can you
> please come up with a proper patch that you file into Jira? Every patch
> should go through our tracking system. If you also could change the code
> a little bit to avoid the code duplication (by factoring this out into a
>  method) would be great!
> 
> Thanks
> Carsten
> 
> -- 
> Carsten Ziegeler - Open Source Group, S&N AG
> http://www.s-und-n.de
> http://www.osoco.org/weblogs/rael/
> 



 

Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

[jira] Updated: (COCOON-1998) CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Woonsan Ko (JIRA)]

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

Woonsan Ko updated COCOON-1998:
---

Attachment: servlet-path-pref-diff.txt

> CocoonPortlet needs to allow overriding servlet-path parameter with 
> preferences.
> 
>
> Key: COCOON-1998
> URL: https://issues.apache.org/jira/browse/COCOON-1998
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Portal
>Affects Versions: 2.1.11-dev (Current SVN)
>Reporter: Woonsan Ko
> Fix For: 2.1.11-dev (Current SVN)
>
> Attachments: servlet-path-pref-diff.txt
>
>
> The CocoonPortlet in BRANCH_2_1_X does not allow overriding the 
> *servlet-path* init parameter by preferences.
> If the CocoonPortlet reads preferences to override the 'servlet-path', portal 
> users can use manycoplet fragments without tedious portlet tag additions.
> FYI, some portals such as Jetspeed 2 allows inline preference settings, not 
> allowed for end-users.
> Without this feature, portal users have to add portlet tags in the 
> portlet.xml whenever they need to use another coplet in the portal site.
> To test properly for the patch, you should add init-parameter in the 
> cocoon/WEB-INF/portlet.xml like the
> following:
>   
> CocoonPortlet
> ...
> 
>   allow-preferences
>   true
> 
> ...
>   
> ManagedCocoonPortlet will read preferences just when the above parameter is 
> set to true. (I borrowed this from GenericServletPortlet in Apache portal 
> bridges.)
> I've tested this modification under Jetspeed-2 
> (/WEB-INF/pages/default-page.psml).
> The portlet fragment can be added with preferences like the following:
> 
> 
> 
> 
> samples/blocks/portal/portlets/helloworld
> 
> 

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

[jira] Created: (COCOON-1998) CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Woonsan Ko (JIRA)]

CocoonPortlet needs to allow overriding servlet-path parameter with preferences.


 Key: COCOON-1998
 URL: https://issues.apache.org/jira/browse/COCOON-1998
 Project: Cocoon
  Issue Type: Improvement
  Components: Blocks: Portal
Affects Versions: 2.1.11-dev (Current SVN)
Reporter: Woonsan Ko
 Fix For: 2.1.11-dev (Current SVN)
 Attachments: servlet-path-pref-diff.txt

The CocoonPortlet in BRANCH_2_1_X does not allow overriding the *servlet-path* 
init parameter by preferences.
If the CocoonPortlet reads preferences to override the 'servlet-path', portal 
users can use manycoplet fragments without tedious portlet tag additions.
FYI, some portals such as Jetspeed 2 allows inline preference settings, not 
allowed for end-users.

Without this feature, portal users have to add portlet tags in the portlet.xml 
whenever they need to use another coplet in the portal site.

To test properly for the patch, you should add init-parameter in the 
cocoon/WEB-INF/portlet.xml like the
following:

  
CocoonPortlet
...

  allow-preferences
  true

...
  

ManagedCocoonPortlet will read preferences just when the above parameter is set 
to true. (I borrowed this from GenericServletPortlet in Apache portal bridges.)

I've tested this modification under Jetspeed-2 
(/WEB-INF/pages/default-page.psml).
The portlet fragment can be added with preferences like the following:





samples/blocks/portal/portlets/helloworld



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

[jira] Updated: (COCOON-1693) When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html

[JIRA]

 [ http://issues.apache.org/jira/browse/COCOON-1693?page=all ]

Jörg Heinicke updated COCOON-1693:
--


> When using src parameter on sendMail action, body is included as attachment, 
> and when using body parameter, mimeType is always text/html
> 
>
> Key: COCOON-1693
> URL: http://issues.apache.org/jira/browse/COCOON-1693
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Mail
>Affects Versions: 2.1.8
>Reporter: Marc Salvetti
>Priority: Minor
> Attachments: MailMessageSender.java, MailSender.java, Sendmail.java
>
>
> If using the src parameter, the body is included as an attachment (the header 
> Content-disposition=attachment) is set.
> Moreover, when trying to stick some html in the body parameter, the mimeType 
> is always text/html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[JIRA]

[ 
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441939 
] 

Jörg Heinicke commented on COCOON-1928:
---

> Cyriaque, have you tried declaring the serializer in your project's 
> sitemap.xmap file? I am not sure which one takes precedence.

> Sitemap precedence would probably be better, if possible. 

I don't know how a Forrest plugin works, but in standard Cocoon sitemaps work 
as sub-containers and redeclared components are only usable in this sitemap and 
its childs (if not redeclared again).

So if the plugin's sitemap is actually a super-sitemap (or part of it) of the 
project's sitemap and if it also contains the pipeline where this component is 
used, it will use the original component, not the redeclared one.

> Probably should create a FOR Jira issue and leave this one for your original 
> suggestion.

I don't think that this proposal will make it into Cocoon. You can ask on the 
developers list, but I guess this one will get a WONTFIX (to speak in bugzilla 
resolvings).

> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441895 
] 

David Crossley commented on COCOON-1928:


Sitemap precedence would probably be better, if possible.

Another technique that i wonder about: Let the project or plugin declare a 
separate map:serializer with different "name" attribute. Then make the name be 
configurable for deciding which serializer to use later in the map:pipelines. I 
gather that the Cocoon properties system will enable such configuration 
(FOR-917).

The entities technique should work (being an xml framework). The biggest 
trouble that i have found is getting the entity resolver to work in all three 
situations: local jetty, command-line CLI, and webapp war. Forrest entity 
resolver is able to be used at core, plugin, and project levels. Here is one 
technique that might help you: 
http://forrest.apache.org/docs/dev/faq.html#xml-entities

Probably should create a FOR Jira issue and leave this one for your original 
suggestion.

> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[Cyriaque Dupoirieux (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441642 
] 

Cyriaque Dupoirieux commented on COCOON-1928:
-

David, I am going to try the solution of Jörg with entities. I think it can be 
the solution and it's really pretty nice.
When my test is good, I will close the problem.

> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441620 
] 

David Crossley commented on COCOON-1928:


Cyriaque, have you tried declaring the serializer in your project's 
sitemap.xmap file? I am not sure which one takes precedence.

> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[JIRA]

 [ http://issues.apache.org/jira/browse/COCOON-1928?page=all ]

Jörg Heinicke updated COCOON-1928:
--


> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[JIRA]

[ 
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441464 
] 

Jörg Heinicke commented on COCOON-1928:
---

> Doctype is configurable right now, see Cocoon samples

Of course it is. But I wondered why he wants to make even the configuration 
configurable with the parameter substitution. That's why I called it FS.

> Because the core of forrest - an internal plugin exactly... - defines the 
> serializer with ...

I don't know how Forrest works internally, but does Forrest provide other 
extension mechanisms? Have you asked on the Forrest list for possibilities?

> Another mistake is to confuse properties substitution in cocoon 2.2 (using 
> ${} syntax) with sitemap variable substitution (using {} syntax).

That probably results from Forrest already being based on Cocoon 2.2?

> What do you mean by include XML entities?



]


&dtPublic;
&dtSystem;
UTF-8
yes
no


with doctype-public.xml:

 -//W3C//DTD XHTML 1.0 Strict//EN 

and doctype-system.xml:

 http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd 


And so both files could be used as configuration.

Jörg

> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[Vadim Gritsenko (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441449 
] 

Vadim Gritsenko commented on COCOON-1928:
-

To Joerg:
Doctype is configurable right now, see Cocoon samples:

  -//W3C//DTD HTML 4.01 Transitional//EN
  http://www.w3.org/TR/html4/loose.dtd


What Cyriaque is suggesting is syntax change, which I am against since it does 
not give anything, and introduces inconsistent syntax.


To Cyriaque:
You are mistaken, syntax change will not help you. Variable substitution in 
component configuration has to happen manually. Sitemap variable susbstitution 
in parameter values is happening only within  section, not within 
 section.

Another mistake is to confuse properties substitution in cocoon 2.2 (using ${} 
syntax) with sitemap variable substitution (using {} syntax).

Vadim


> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[Cyriaque Dupoirieux (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441446 
] 

Cyriaque Dupoirieux commented on COCOON-1928:
-

Because the core of forrest - an internal plugin exactly... - defines the 
serializer with :

-//W3C//DTD XHTML 1.0 Strict//EN 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd 


It may be complex for webmasters using Forrest to be XHTM Strict compliant - I 
don't know if you have tried...

And it is not possible at the moment to configure it through a forrest 
configuration file.

That's all.

I am not sure it is featuritis - I didn't know the word, but I like it - since 
I need it and have no other solution than to have a local change a file of the 
core of Forrest to do what I want... - The next step can be to have a local 
change a class of the core of Cocoon ?

What do you mean by include XML entities ? It may be the solution ?

> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[JIRA]

[ 
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441410 
] 

Jörg Heinicke commented on COCOON-1928:
---

Sorry, but this really looks like FS (Flexibility Syndrome aka featuritis). Why 
do you need this dynamic? Where do those values come from? Aren't there other 
include mechanisms possible like XML entities?

Jörg

> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[Cyriaque Dupoirieux (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441369 
] 

Cyriaque Dupoirieux commented on COCOON-1928:
-

Here is my problem,
I want to use two variables to be able to define the doctype-public and the 
doctype-system.
At the moment if I try this :

${doctype-public}
${doctype-system}
UTF-8
yes
no
 

I get this :



And I have seen example where variable are used in a tag attribute value : 


So I think my problem should be solve if I could write the example exposed in 
my first comment...


> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1928?page=all ]

Antonio Gallardo updated COCOON-1928:
-


Would you provide an use case? I am asking because I wonder why this is needed.

> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[Cyriaque Dupoirieux (JIRA)]

Add the ability to pass the doctype in parameter for Serializer
---

 Key: COCOON-1928
 URL: http://issues.apache.org/jira/browse/COCOON-1928
 Project: Cocoon
  Issue Type: New Feature
  Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Cyriaque Dupoirieux
Priority: Minor


I need - with forrest - to get the doctype-system and doctype-public in a 
parameter like following :


http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
UTF-8
yes
no


here is a patch which apply to the AbstractTextSerializer.
in case the doctype is also found in the childs, child have priority.

Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer

[Cyriaque Dupoirieux (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1928?page=all ]

Cyriaque Dupoirieux updated COCOON-1928:


Attachment: AbstractTextSerializer.diff

> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
>  Issue Type: New Feature
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a 
> parameter like following :
>  name="xhtml" pool-grow="2" pool-max="64" pool-min="2" 
> src="org.apache.cocoon.serialization.XMLSerializer">
> 
>  value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
>   no
> 
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Carsten Ziegeler]

Woon-San Ko wrote:
> Hi, all.
> 
> The CocoonPortlet in BRANCH_2_1_X does not allow overriding the 
> *servlet-path* init parameter by
> preferences.
> So, portal users have to add portlet tags in the portlet.xml whenever they 
> need to use another
> coplet in the portal site.
> 
> If the CocoonPortlet reads preferences to override the *servlet-path*, portal 
> users can use many
> coplet fragments without tedious portlet tag additions.
> 
Hi,

I think this is a good addition to the ManagedCocoonPortlet. Can you
please come up with a proper patch that you file into Jira? Every patch
should go through our tracking system. If you also could change the code
a little bit to avoid the code duplication (by factoring this out into a
 method) would be great!

Thanks
Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

CocoonPortlet needs to allow overriding servlet-path parameter with preferences.

[Woon-San Ko]

Hi, all.

The CocoonPortlet in BRANCH_2_1_X does not allow overriding the *servlet-path* 
init parameter by
preferences.
So, portal users have to add portlet tags in the portlet.xml whenever they need 
to use another
coplet in the portal site.

If the CocoonPortlet reads preferences to override the *servlet-path*, portal 
users can use many
coplet fragments without tedious portlet tag additions.

In the Portals Bridges project, *GenericServletPortlet* provides this kind of 
functionality.
GenericServletPortlet reads the init parameters initially to set *ViewPage*, 
*EditPage*, and
*HelpPage*, but if it finds preferences with same name, then it replaces the 
page URLs with the
preference values. (GenericServletPortlet reads request attributes before 
reading preferences,
actually.)

I made this kind of implementation and pasted the patch at the bottom for
*src/blocks/portal/java/org/apache/cocoon/portlet/ManagedCocoonPortlet.java*.

To test properly, you should add init-parameter in the 
cocoon/WEB-INF/portlet.xml like the
following:

  <portlet>
<portlet-name>CocoonPortlet</portlet-name>
...
<init-param>
  <name>allow-preferences</name>
  <value>true</value>
</init-param>
...
  </portlet>

ManagedCocoonPortlet will read preferences just when the above parameter is set 
to true. (I
borrowed this from GenericServletPortlet.)

I've tested this modification under Jetspeed-2 
(/WEB-INF/pages/default-page.psml).
The portlet fragment can be added with preferences like the following:

<fragment id="dp-19" type="portlet" name="cocoon::CocoonPortlet">
<property name="row" value="6"/>
<property name="column" value="0"/>
<preference name="servlet-path" readOnly="true">

<value>samples/blocks/portal/portlets/helloworldCocoonPortlet instance.
  *
  * Uses the following parameters:
@@ -353,6 +359,8 @@

 }
 
 this.storeSessionPath = 
getInitParameterAsBoolean("store-session-path", false);
+
+this.allowPreferences = getInitParameterAsBoolean("allow-preferences", 
false);
 }
 
 public void processAction(ActionRequest req, ActionResponse res)
@@ -400,6 +408,28 @@

 if (servletPath == null) {
 servletPath = "portlets/" + getPortletConfig().getPortletName();
 }
+
+// allow servlet-path override by the request
+String reqServletPath = (String) request.getAttribute("servlet-path");
+if (reqServletPath != null) {
+this.servletPath = reqServletPath;
+} 
+// allow servlet-path override by the preferences
+else if (this.allowPreferences == true) {
+PortletPreferences prefs = request.getPreferences();
+
+if (prefs != null && reqServletPath == null) {
+this.servletPath = prefs.getValue("servlet-path", 
this.servletPath);
+}  
+}
+
+if (this.servletPath.startsWith("/")) {
+this.servletPath = this.servletPath.substring(1);
+}
+if (this.servletPath.endsWith("/")) {
+this.servletPath = servletPath.substring(0, servletPath.length() - 
1);
+}
+
 String pathInfo = getPathInfo(request);
 
 String uri = servletPath;
@@ -547,6 +577,28 @@

 if (servletPath == null) {
 servletPath = "portlets/" + getPortletConfig().getPortletName();
 }
+
+// allow servlet-path override by the request
+String reqServletPath = (String) request.getAttribute("servlet-path");
+if (reqServletPath != null) {
+this.servletPath = reqServletPath;
+} 
+// allow servlet-path override by the preferences
+else if (this.allowPreferences == true) {
+PortletPreferences prefs = request.getPreferences();
+
+if (prefs != null && reqServletPath == null) {
+this.servletPath = prefs.getValue("servlet-path", 
this.servletPath);
+}  
+}
+
+if (this.servletPath.startsWith("/")) {
+this.servletPath = this.servletPath.substring(1);
+}
+if (this.servletPath.endsWith("/")) {
+this.servletPath = servletPath.substring(0, servletPath.length() - 
1);
+}
+
 String pathInfo = getPathInfo(request);
 
 String uri = servletPath;


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[jira] Assigned: (COCOON-1693) When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html

[Jean-Baptiste Quenot (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1693?page=all ]

Jean-Baptiste Quenot reassigned COCOON-1693:


Assign To: (was: Jean-Baptiste Quenot)

Sorry I won't be able to work on this anymore

> When using src parameter on sendMail action, body is included as attachment, 
> and when using body parameter, mimeType is always text/html
> 
>
>  Key: COCOON-1693
>  URL: http://issues.apache.org/jira/browse/COCOON-1693
>  Project: Cocoon
> Type: Bug

>   Components: Blocks: Mail
> Versions: 2.1.8
> Reporter: Marc Salvetti
> Priority: Minor
>  Attachments: MailMessageSender.java, MailSender.java, Sendmail.java
>
> If using the src parameter, the body is included as an attachment (the header 
> Content-disposition=attachment) is set.
> Moreover, when trying to stick some html in the body parameter, the mimeType 
> is always text/html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1693) When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html

[Jean-Baptiste Quenot (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1693?page=all ]

Jean-Baptiste Quenot updated COCOON-1693:
-


Please don't forget to submit patches for this issue

> When using src parameter on sendMail action, body is included as attachment, 
> and when using body parameter, mimeType is always text/html
> 
>
>  Key: COCOON-1693
>  URL: http://issues.apache.org/jira/browse/COCOON-1693
>  Project: Cocoon
> Type: Bug

>   Components: Blocks: Mail
> Versions: 2.1.8
> Reporter: Marc Salvetti
> Assignee: Jean-Baptiste Quenot
> Priority: Minor
>  Attachments: MailMessageSender.java, MailSender.java, Sendmail.java
>
> If using the src parameter, the body is included as an attachment (the header 
> Content-disposition=attachment) is set.
> Moreover, when trying to stick some html in the body parameter, the mimeType 
> is always text/html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (COCOON-1845) [PATCH] Add omit-xml-declaration parameter to XHTMLSerializer

[Andrew Savory (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1845?page=all ]
 
Andrew Savory closed COCOON-1845:
-

Resolution: Fixed

Patches applied to branch and trunk. Thanks, Maurizio!

> [PATCH] Add omit-xml-declaration parameter to XHTMLSerializer
> -
>
>  Key: COCOON-1845
>  URL: http://issues.apache.org/jira/browse/COCOON-1845
>  Project: Cocoon
> Type: Improvement

>   Components: Blocks: Serializers
> Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
> Reporter: Maurizio Pillitu
> Priority: Minor
>  Attachments: XHTMLSerializer.java.diff, serializers.serializer.xmap.diff
>
> As all the AbstractTextSerializer based serializers, also the XHTMLSerializer 
> should handle the omit-xml-declaration to do not put the XML declaration as 
> first line of the serialized document.
> This prevent many rendering problems in Internet Explorer.
> Default behaviour is to send the xml declaration as before.
> Tested on 2.1.10-dev, but patch should work on 2.2.0 as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (COCOON-1845) [PATCH] Add omit-xml-declaration parameter to XHTMLSerializer

[Maurizio Pillitu (JIRA)]

[PATCH] Add omit-xml-declaration parameter to XHTMLSerializer
-

 Key: COCOON-1845
 URL: http://issues.apache.org/jira/browse/COCOON-1845
 Project: Cocoon
Type: Improvement

  Components: Blocks: Serializers  
Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
Reporter: Maurizio Pillitu
Priority: Minor
 Attachments: XHTMLSerializer.java.diff, serializers.serializer.xmap.diff

As all the AbstractTextSerializer based serializers, also the XHTMLSerializer 
should handle the omit-xml-declaration to do not put the XML declaration as 
first line of the serialized document.

This prevent many rendering problems in Internet Explorer.

Default behaviour is to send the xml declaration as before.

Tested on 2.1.10-dev, but patch should work on 2.2.0 as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (COCOON-1511) [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface

[Carsten Ziegeler (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1511?page=all ]
 
Carsten Ziegeler closed COCOON-1511:


Fix Version: 2.2-dev (Current SVN)
 2.1.10-dev (current SVN)
 Resolution: Fixed

> [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface
> -
>
>  Key: COCOON-1511
>  URL: http://issues.apache.org/jira/browse/COCOON-1511
>  Project: Cocoon
> Type: Bug

>   Components: * Cocoon Core
> Versions: 2.1.8
>  Environment: Operating System: All
> Platform: All
> Reporter: James Bates
> Assignee: Carsten Ziegeler
>  Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
>  Attachments: cli-user-agent-header.patch, user-agent.patch
>
> The Cocoon command line interface provides a switch for simulating 
> the Cocoon User-Agent header that would be sent by a browser. The 
> idea being that it could be used by e.g. the browser selector to 
> "detect" that a request is coming from the CLI.
>  
> When investigating however, I noticed that the Cocoon bean (the 
> class that implements the CLI) does not place the User-Agent into a 
> HEDAER, but into a request PARAMETER instead (occurs on line 407 of 
> CocoonWrapper.java, in method processURI() in BRANCH_2_1_X; line 421 
> of the same file in 2.2 trunk).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (COCOON-1511) [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface

[Carsten Ziegeler (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1511?page=all ]

Carsten Ziegeler reassigned COCOON-1511:


Assign To: Carsten Ziegeler  (was: Cocoon Developers Team)

> [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface
> -
>
>  Key: COCOON-1511
>  URL: http://issues.apache.org/jira/browse/COCOON-1511
>  Project: Cocoon
> Type: Bug

>   Components: * Cocoon Core
> Versions: 2.1.8
>  Environment: Operating System: All
> Platform: All
> Reporter: James Bates
> Assignee: Carsten Ziegeler
>  Attachments: cli-user-agent-header.patch, user-agent.patch
>
> The Cocoon command line interface provides a switch for simulating 
> the Cocoon User-Agent header that would be sent by a browser. The 
> idea being that it could be used by e.g. the browser selector to 
> "detect" that a request is coming from the CLI.
>  
> When investigating however, I noticed that the Cocoon bean (the 
> class that implements the CLI) does not place the User-Agent into a 
> HEDAER, but into a request PARAMETER instead (occurs on line 407 of 
> CocoonWrapper.java, in method processURI() in BRANCH_2_1_X; line 421 
> of the same file in 2.2 trunk).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function

[Grzegorz Kossakowski (aka g[R]eK) (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1798?page=comments#action_12369844 
] 

Grzegorz Kossakowski (aka g[R]eK) commented on COCOON-1798:
---

Thank you very much!

> Flowscript doc lacks information about isGlobal parameter of 
> cocoon.redirectTo function
> ---
>
>  Key: COCOON-1798
>  URL: http://issues.apache.org/jira/browse/COCOON-1798
>  Project: Cocoon
> Type: Improvement
>   Components: - Documentation
> Versions: 2.1.8
> Reporter: Grzegorz Kossakowski (aka g[R]eK)
> Assignee: Helma van der Linden

>
> Nothing needed to add to the summury ;-)
> I think it should be fixed soon.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (COCOON-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function

[Helma van der Linden (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1798?page=all ]
 
Helma van der Linden closed COCOON-1798:


Resolution: Fixed

Information is added to the Daisy documentation and will be reflected in the 
next documentation update.

> Flowscript doc lacks information about isGlobal parameter of 
> cocoon.redirectTo function
> ---
>
>  Key: COCOON-1798
>  URL: http://issues.apache.org/jira/browse/COCOON-1798
>  Project: Cocoon
> Type: Improvement
>   Components: - Documentation
> Versions: 2.1.8
> Reporter: Grzegorz Kossakowski (aka g[R]eK)
> Assignee: Helma van der Linden

>
> Nothing needed to add to the summury ;-)
> I think it should be fixed soon.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (COCOON-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function

[Helma van der Linden (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1798?page=all ]

Helma van der Linden reassigned COCOON-1798:


Assign To: Helma van der Linden

> Flowscript doc lacks information about isGlobal parameter of 
> cocoon.redirectTo function
> ---
>
>  Key: COCOON-1798
>  URL: http://issues.apache.org/jira/browse/COCOON-1798
>  Project: Cocoon
> Type: Improvement
>   Components: - Documentation
> Versions: 2.1.8
> Reporter: Grzegorz Kossakowski (aka g[R]eK)
> Assignee: Helma van der Linden

>
> Nothing needed to add to the summury ;-)
> I think it should be fixed soon.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function

[Grzegorz Kossakowski (aka g[R]eK) (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1798?page=comments#action_12369821 
] 

Grzegorz Kossakowski (aka g[R]eK) commented on COCOON-1798:
---

Make a use of projects documentation, it's not that bad at all ;)
http://cocoon.apache.org/2.1/userdocs/concepts/redirection.html (the next to 
last paragraph)

> Flowscript doc lacks information about isGlobal parameter of 
> cocoon.redirectTo function
> ---
>
>  Key: COCOON-1798
>  URL: http://issues.apache.org/jira/browse/COCOON-1798
>  Project: Cocoon
> Type: Improvement
>   Components: - Documentation
> Versions: 2.1.8
> Reporter: Grzegorz Kossakowski (aka g[R]eK)

>
> Nothing needed to add to the summury ;-)
> I think it should be fixed soon.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (COCOON-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function

[Upayavira]

Helma van der Linden (JIRA) wrote:
> [ 
> http://issues.apache.org/jira/browse/COCOON-1798?page=comments#action_12369743
>  ] 
> 
> Helma van der Linden commented on COCOON-1798:
> --
> 
> I'm not sure what you want to happen. If it's merely an extension to the 
> documentation I'd be happy to add it if you can provide a sensible 
> description of the isGlobal parameter (i.e. something more sensible than 
> "global redirect").

IIRC a global redirect is one that returns all the way to the browser,
even from within internal requests.

Regards, Upayavira

[jira] Commented: (COCOON-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function

[Helma van der Linden (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1798?page=comments#action_12369743 
] 

Helma van der Linden commented on COCOON-1798:
--

I'm not sure what you want to happen. If it's merely an extension to the 
documentation I'd be happy to add it if you can provide a sensible description 
of the isGlobal parameter (i.e. something more sensible than "global redirect").

> Flowscript doc lacks information about isGlobal parameter of 
> cocoon.redirectTo function
> ---
>
>  Key: COCOON-1798
>  URL: http://issues.apache.org/jira/browse/COCOON-1798
>  Project: Cocoon
> Type: Improvement
>   Components: - Documentation
> Versions: 2.1.8
> Reporter: Grzegorz Kossakowski (aka g[R]eK)

>
> Nothing needed to add to the summury ;-)
> I think it should be fixed soon.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (COCOON-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function

[Grzegorz Kossakowski (aka g[R]eK) (JIRA)]

Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo 
function
---

 Key: COCOON-1798
 URL: http://issues.apache.org/jira/browse/COCOON-1798
 Project: Cocoon
Type: Improvement
  Components: - Documentation  
Versions: 2.1.8
Reporter: Grzegorz Kossakowski (aka g[R]eK)


Nothing needed to add to the summury ;-)
I think it should be fixed soon.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (COCOON-1785) I18nMessage - null parameter values causes NPE

[Eric Meyer (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1785?page=all ]
 
Eric Meyer closed COCOON-1785:
--

Resolution: Fixed

Thanks, Antonio.
--Eric

> I18nMessage - null parameter values causes NPE
> --
>
>  Key: COCOON-1785
>  URL: http://issues.apache.org/jira/browse/COCOON-1785
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.1.8, 2.1.9-dev (current SVN)
> Reporter: Eric Meyer
> Assignee: Antonio Gallardo
>  Attachments: I18nMessageNPE.txt
>
> Putting a null in a parameter value causes an NPE when creating the SAX events
> java.lang.NullPointerException
>   at org.apache.cocoon.forms.util.I18nMessage.toSAX(I18nMessage.java:128)
>   at 
> org.apache.cocoon.forms.validation.ValidationError.generateSaxFragment(ValidationError.java:85)
>   at 
> org.apache.cocoon.forms.formmodel.Field.generateItemSaxFragment(Field.java:453)
>   at 
> org.apache.cocoon.forms.formmodel.AbstractWidget.generateSaxFragment(AbstractWidget.java:498)
>   at 
> org.apache.cocoon.forms.generation.JXMacrosHelper.generateWidget(JXMacrosHelper.java:292)
> Note: this NPE then causes the Ajax transformer to go wonky for all users in 
> all sessions. I'm still digging into that one.
> I am attaching a patch (license granted to ASF)  that allows null parameter 
> values (using String.valueOf(parameters[i]) so that nulls are turned into 
> "null".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1785) I18nMessage - null parameter values causes NPE

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1785?page=all ]

Antonio Gallardo updated COCOON-1785:
-


Would you cross check and close the bug?

> I18nMessage - null parameter values causes NPE
> --
>
>  Key: COCOON-1785
>  URL: http://issues.apache.org/jira/browse/COCOON-1785
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.1.8, 2.1.9-dev (current SVN)
> Reporter: Eric Meyer
> Assignee: Antonio Gallardo
>  Attachments: I18nMessageNPE.txt
>
> Putting a null in a parameter value causes an NPE when creating the SAX events
> java.lang.NullPointerException
>   at org.apache.cocoon.forms.util.I18nMessage.toSAX(I18nMessage.java:128)
>   at 
> org.apache.cocoon.forms.validation.ValidationError.generateSaxFragment(ValidationError.java:85)
>   at 
> org.apache.cocoon.forms.formmodel.Field.generateItemSaxFragment(Field.java:453)
>   at 
> org.apache.cocoon.forms.formmodel.AbstractWidget.generateSaxFragment(AbstractWidget.java:498)
>   at 
> org.apache.cocoon.forms.generation.JXMacrosHelper.generateWidget(JXMacrosHelper.java:292)
> Note: this NPE then causes the Ajax transformer to go wonky for all users in 
> all sessions. I'm still digging into that one.
> I am attaching a patch (license granted to ASF)  that allows null parameter 
> values (using String.valueOf(parameters[i]) so that nulls are turned into 
> "null".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1785) I18nMessage - null parameter values causes NPE

[Antonio Gallardo (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1785?page=comments#action_12368329 
] 

Antonio Gallardo commented on COCOON-1785:
--

 Thanks Eric for your contribution!
The i18nMessage doesn't include a logger. Patch applied as is.

> I18nMessage - null parameter values causes NPE
> --
>
>  Key: COCOON-1785
>  URL: http://issues.apache.org/jira/browse/COCOON-1785
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.1.8, 2.1.9-dev (current SVN)
> Reporter: Eric Meyer
> Assignee: Antonio Gallardo
>  Attachments: I18nMessageNPE.txt
>
> Putting a null in a parameter value causes an NPE when creating the SAX events
> java.lang.NullPointerException
>   at org.apache.cocoon.forms.util.I18nMessage.toSAX(I18nMessage.java:128)
>   at 
> org.apache.cocoon.forms.validation.ValidationError.generateSaxFragment(ValidationError.java:85)
>   at 
> org.apache.cocoon.forms.formmodel.Field.generateItemSaxFragment(Field.java:453)
>   at 
> org.apache.cocoon.forms.formmodel.AbstractWidget.generateSaxFragment(AbstractWidget.java:498)
>   at 
> org.apache.cocoon.forms.generation.JXMacrosHelper.generateWidget(JXMacrosHelper.java:292)
> Note: this NPE then causes the Ajax transformer to go wonky for all users in 
> all sessions. I'm still digging into that one.
> I am attaching a patch (license granted to ASF)  that allows null parameter 
> values (using String.valueOf(parameters[i]) so that nulls are turned into 
> "null".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1511) [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface

[David Crossley (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1511?page=all ]

David Crossley updated COCOON-1511:
---

Bugzilla Id:   (was: 34906)
 Other Info: [Patch available]
Description: 
The Cocoon command line interface provides a switch for simulating 
the Cocoon User-Agent header that would be sent by a browser. The 
idea being that it could be used by e.g. the browser selector to 
"detect" that a request is coming from the CLI.
 
When investigating however, I noticed that the Cocoon bean (the 
class that implements the CLI) does not place the User-Agent into a 
HEDAER, but into a request PARAMETER instead (occurs on line 407 of 
CocoonWrapper.java, in method processURI() in BRANCH_2_1_X; line 421 
of the same file in 2.2 trunk).

  was:
The Cocoon command line interface provides a switch for simulating 
the Cocoon User-Agent header that would be sent by a browser. The 
idea being that it could be used by e.g. the browser selector to 
“detect” that a request is coming from the CLI.
 
When investigating however, I noticed that the Cocoon bean (the 
class that implements the CLI) does not place the User-Agent into a 
HEDAER, but into a request PARAMETER instead (occurs on line 407 of 
CocoonWrapper.java, in method processURI() in BRANCH_2_1_X; line 421 
of the same file in 2.2 trunk).


> [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface
> -
>
>  Key: COCOON-1511
>  URL: http://issues.apache.org/jira/browse/COCOON-1511
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.8
>  Environment: Operating System: All
> Platform: All
> Reporter: James Bates
> Assignee: Cocoon Developers Team
>  Attachments: cli-user-agent-header.patch, user-agent.patch
>
> The Cocoon command line interface provides a switch for simulating 
> the Cocoon User-Agent header that would be sent by a browser. The 
> idea being that it could be used by e.g. the browser selector to 
> "detect" that a request is coming from the CLI.
>  
> When investigating however, I noticed that the Cocoon bean (the 
> class that implements the CLI) does not place the User-Agent into a 
> HEDAER, but into a request PARAMETER instead (occurs on line 407 of 
> CocoonWrapper.java, in method processURI() in BRANCH_2_1_X; line 421 
> of the same file in 2.2 trunk).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1785) I18nMessage - null parameter values causes NPE

[Antonio Gallardo (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1785?page=comments#action_12368215 
] 

Antonio Gallardo commented on COCOON-1785:
--

String.valueOf() replace null --> "null" [1]

Is this the expected behavior? Is not better to log the error or to throw the 
exception?

[1] 
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#valueOf(java.lang.Object)

> I18nMessage - null parameter values causes NPE
> --
>
>  Key: COCOON-1785
>  URL: http://issues.apache.org/jira/browse/COCOON-1785
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.1.8, 2.1.9-dev (current SVN)
> Reporter: Eric Meyer
> Assignee: Antonio Gallardo
>  Attachments: I18nMessageNPE.txt
>
> Putting a null in a parameter value causes an NPE when creating the SAX events
> java.lang.NullPointerException
>   at org.apache.cocoon.forms.util.I18nMessage.toSAX(I18nMessage.java:128)
>   at 
> org.apache.cocoon.forms.validation.ValidationError.generateSaxFragment(ValidationError.java:85)
>   at 
> org.apache.cocoon.forms.formmodel.Field.generateItemSaxFragment(Field.java:453)
>   at 
> org.apache.cocoon.forms.formmodel.AbstractWidget.generateSaxFragment(AbstractWidget.java:498)
>   at 
> org.apache.cocoon.forms.generation.JXMacrosHelper.generateWidget(JXMacrosHelper.java:292)
> Note: this NPE then causes the Ajax transformer to go wonky for all users in 
> all sessions. I'm still digging into that one.
> I am attaching a patch (license granted to ASF)  that allows null parameter 
> values (using String.valueOf(parameters[i]) so that nulls are turned into 
> "null".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (COCOON-1785) I18nMessage - null parameter values causes NPE

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1785?page=all ]

Antonio Gallardo reassigned COCOON-1785:


Assign To: Antonio Gallardo

> I18nMessage - null parameter values causes NPE
> --
>
>  Key: COCOON-1785
>  URL: http://issues.apache.org/jira/browse/COCOON-1785
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.1.8, 2.1.9-dev (current SVN)
> Reporter: Eric Meyer
> Assignee: Antonio Gallardo
>  Attachments: I18nMessageNPE.txt
>
> Putting a null in a parameter value causes an NPE when creating the SAX events
> java.lang.NullPointerException
>   at org.apache.cocoon.forms.util.I18nMessage.toSAX(I18nMessage.java:128)
>   at 
> org.apache.cocoon.forms.validation.ValidationError.generateSaxFragment(ValidationError.java:85)
>   at 
> org.apache.cocoon.forms.formmodel.Field.generateItemSaxFragment(Field.java:453)
>   at 
> org.apache.cocoon.forms.formmodel.AbstractWidget.generateSaxFragment(AbstractWidget.java:498)
>   at 
> org.apache.cocoon.forms.generation.JXMacrosHelper.generateWidget(JXMacrosHelper.java:292)
> Note: this NPE then causes the Ajax transformer to go wonky for all users in 
> all sessions. I'm still digging into that one.
> I am attaching a patch (license granted to ASF)  that allows null parameter 
> values (using String.valueOf(parameters[i]) so that nulls are turned into 
> "null".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (COCOON-1785) I18nMessage - null parameter values causes NPE

[Eric Meyer (JIRA)]

I18nMessage - null parameter values causes NPE
--

 Key: COCOON-1785
 URL: http://issues.apache.org/jira/browse/COCOON-1785
 Project: Cocoon
Type: Bug
  Components: Blocks: Forms  
Versions: 2.1.8, 2.1.9-dev (current SVN)
Reporter: Eric Meyer
 Attachments: I18nMessageNPE.txt

Putting a null in a parameter value causes an NPE when creating the SAX events

java.lang.NullPointerException
at org.apache.cocoon.forms.util.I18nMessage.toSAX(I18nMessage.java:128)
at 
org.apache.cocoon.forms.validation.ValidationError.generateSaxFragment(ValidationError.java:85)
at 
org.apache.cocoon.forms.formmodel.Field.generateItemSaxFragment(Field.java:453)
at 
org.apache.cocoon.forms.formmodel.AbstractWidget.generateSaxFragment(AbstractWidget.java:498)
at 
org.apache.cocoon.forms.generation.JXMacrosHelper.generateWidget(JXMacrosHelper.java:292)

Note: this NPE then causes the Ajax transformer to go wonky for all users in 
all sessions. I'm still digging into that one.

I am attaching a patch (license granted to ASF)  that allows null parameter 
values (using String.valueOf(parameters[i]) so that nulls are turned into 
"null".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (COCOON-1693) When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html

[Jean-Baptiste Quenot (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1693?page=all ]

Jean-Baptiste Quenot reassigned COCOON-1693:


Assign To: Jean-Baptiste Quenot

> When using src parameter on sendMail action, body is included as attachment, 
> and when using body parameter, mimeType is always text/html
> 
>
>  Key: COCOON-1693
>  URL: http://issues.apache.org/jira/browse/COCOON-1693
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Mail
> Versions: 2.1.8
> Reporter: Marc Salvetti
> Assignee: Jean-Baptiste Quenot
> Priority: Minor
>  Attachments: MailMessageSender.java, MailSender.java, Sendmail.java
>
> If using the src parameter, the body is included as an attachment (the header 
> Content-disposition=attachment) is set.
> Moreover, when trying to stick some html in the body parameter, the mimeType 
> is always text/html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1693) When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html

[Jean-Baptiste Quenot (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1693?page=comments#action_12362940 
] 

Jean-Baptiste Quenot commented on COCOON-1693:
--

Thanks for your contribution.  However, you must submit your work as a patch 
obtained via "svn diff".  Also, this issue has also been raised in other bug 
reports, could you please try them so that we find the best solution:

SendMailTransformer and HTML body
http://issues.apache.org/jira/browse/COCOON-1622

handling of alternatives in MailTransformer
http://issues.apache.org/jira/browse/COCOON-1603

Followup or close this issue if one of the above solution fits your need.

> When using src parameter on sendMail action, body is included as attachment, 
> and when using body parameter, mimeType is always text/html
> 
>
>  Key: COCOON-1693
>  URL: http://issues.apache.org/jira/browse/COCOON-1693
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Mail
> Versions: 2.1.8
> Reporter: Marc Salvetti
> Priority: Minor
>  Attachments: MailMessageSender.java, MailSender.java, Sendmail.java
>
> If using the src parameter, the body is included as an attachment (the header 
> Content-disposition=attachment) is set.
> Moreover, when trying to stick some html in the body parameter, the mimeType 
> is always text/html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1693) When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html

[Marc Salvetti (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1693?page=comments#action_12358248 
] 

Marc Salvetti commented on COCOON-1693:
---

I changed 3 files :
MailMessageSender.java
MailSender.java
SendMail.java

Basically, i added a "bodyMimeType" parameter to the action, and checked if 
this attribute is set, use the setContent(body, mimeType) method rather than 
the setText(body, charset) method.

> When using src parameter on sendMail action, body is included as attachment, 
> and when using body parameter, mimeType is always text/html
> 
>
>  Key: COCOON-1693
>  URL: http://issues.apache.org/jira/browse/COCOON-1693
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Mail
> Versions: 2.1.8
> Reporter: Marc Salvetti
> Priority: Minor
>  Attachments: MailMessageSender.java, MailSender.java, Sendmail.java
>
> If using the src parameter, the body is included as an attachment (the header 
> Content-disposition=attachment) is set.
> Moreover, when trying to stick some html in the body parameter, the mimeType 
> is always text/html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1693) When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html

[Marc Salvetti (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1693?page=all ]

Marc Salvetti updated COCOON-1693:
--

Attachment: Sendmail.java
MailSender.java
MailMessageSender.java

> When using src parameter on sendMail action, body is included as attachment, 
> and when using body parameter, mimeType is always text/html
> 
>
>  Key: COCOON-1693
>  URL: http://issues.apache.org/jira/browse/COCOON-1693
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Mail
> Versions: 2.1.8
> Reporter: Marc Salvetti
> Priority: Minor
>  Attachments: MailMessageSender.java, MailSender.java, Sendmail.java
>
> If using the src parameter, the body is included as an attachment (the header 
> Content-disposition=attachment) is set.
> Moreover, when trying to stick some html in the body parameter, the mimeType 
> is always text/html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (COCOON-1693) When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html

[Marc Salvetti (JIRA)]

When using src parameter on sendMail action, body is included as attachment, 
and when using body parameter, mimeType is always text/html


 Key: COCOON-1693
 URL: http://issues.apache.org/jira/browse/COCOON-1693
 Project: Cocoon
Type: Bug
  Components: Blocks: Mail  
Versions: 2.1.8
Reporter: Marc Salvetti
Priority: Minor


If using the src parameter, the body is included as an attachment (the header 
Content-disposition=attachment) is set.
Moreover, when trying to stick some html in the body parameter, the mimeType is 
always text/html.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1320) [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list

[Ralph Goers (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1320?page=all ]

Ralph Goers updated COCOON-1320:


Bugzilla Id:   (was: 32011)
  Component: Blocks: Databases
 (was: Blocks: (Undefined))
Description: 
The buildList method in AbstractDatabaseAction does not put commas between
parameter names, leading to incorrect SQL queries.

A fix is the following (diff of AbstractDatabaseAction.java):

730a731,733
>   if (i < length - 1) {
>   buffer.append(", ");
>   }

  was:
The buildList method in AbstractDatabaseAction does not put commas between
parameter names, leading to incorrect SQL queries.

A fix is the following (diff of AbstractDatabaseAction.java):

730a731,733
>   if (i < length - 1) {
>   buffer.append(", ");
>   }


> [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list
> --
>
>  Key: COCOON-1320
>  URL: http://issues.apache.org/jira/browse/COCOON-1320
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Databases
> Versions: 2.1.5
>  Environment: Operating System: Linux
> Platform: PC
> Reporter: wchao
> Assignee: Cocoon Developers Team
>  Attachments: abc.tgz
>
> The buildList method in AbstractDatabaseAction does not put commas between
> parameter names, leading to incorrect SQL queries.
> A fix is the following (diff of AbstractDatabaseAction.java):
> 730a731,733
> >   if (i < length - 1) {
> >   buffer.append(", ");
> >   }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1262) [PATCH] JXPathMetaModule incorrectly checks for null parameter (can't happen) instead of empty string.

[Pier Fumagalli (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1262?page=all ]

Pier Fumagalli updated COCOON-1262:
---

Reporter: Ralph Goers  (was: Ralph Goers)

> [PATCH] JXPathMetaModule incorrectly checks for null parameter (can't happen) 
> instead of empty string.
> --
>
>  Key: COCOON-1262
>  URL: http://issues.apache.org/jira/browse/COCOON-1262
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.5
>  Environment: Operating System: All
> Platform: All
> Reporter: Ralph Goers
> Assignee: Cocoon Developers Team
> Priority: Critical
>  Attachments: 31134.patch
>
> In trying to upgrade from 2.1.4 to 2.1.5.1 we discovered that the
> SimpleFormTransformer is now broken. Both our site and the Cocoon sample are
> failing.  The symptom is that none of the initial (default) values are
> displayed.  In addition, sitemap.log contains:
> WARN(2004-09-08) 14:43.31:102   [sitemap.transformer.simpleform-instance]
> (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem
> occurred acquiring a value from 'jxpath' for '/car/car/persons': Module does 
> not
> support <>attribute.
> WARN(2004-09-08) 14:43.31:114   [sitemap.transformer.simpleform-instance]
> (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem
> occurred acquiring a value from 'jxpath' for '/car/car/type': Module does not
> support <>attribute.
> WARN(2004-09-08) 14:43.31:116   [sitemap.transformer.simpleform-instance]
> (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem
> occurred acquiring a value from 'jxpath' for '/car/car/deposit': Module does 
> not
> support <>attribute.
> WARN(2004-09-08) 14:43.31:118   [sitemap.transformer.simpleform-instance]
> (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem
> occurred acquiring a value from 'jxpath' for '/car/car/email': Module does not
> support <>attribute.
> WARN(2004-09-08) 14:43.31:119   [sitemap.transformer.simpleform-instance]
> (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem
> occurred acquiring a value from 'jxpath' for '/car/car/address': Module does 
> not
> support <>attribute.
> WARN(2004-09-08) 14:43.31:130   [sitemap.transformer.simpleform-instance]
> (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem
> occurred acquiring a value from 'jxpath' for '/car/car/driver': Module does 
> not
> support <>attribute.
> WARN(2004-09-08) 14:43.31:136   [sitemap.transformer.simpleform-instance]
> (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem
> occurred acquiring a value from 'jxpath' for '/car/car/go': Module does not
> support <>attribute.
> I have verified that this problem still exists in BRANCH-2.1.X.
> To reproduce this simply run:
> http://localhost:/samples/simpleform/four/index
> The form should have default values but none are there. The same page with 
> 2.1.4
> displays the defaults.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

RE: [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface

[James Bates]

DONE
 

-Original Message-
From: James Bates [mailto:[EMAIL PROTECTED] 
Sent: 23 May 2005 11:53
To: [EMAIL PROTECTED]
Subject: Re: [Patch] User-Agent is PARAMETER, not HEADER in Command-line 
interface

OK; I was unaware of the meaning of the flags in bugzilla.

I have a second patch for the "trunk" branch, but have not inserted it into 
Bugzilla yet. Will do so this afternoon...
As for committing, I cannot as I am no Cocoon regular developer. Could someone 
else do so?

James


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sun 22/05/2005 22:41
To: James Bates
Subject: DO NOT REPLY [Bug 34906]  -[Patch] User-Agent is PARAMETER, not 
HEADER in Command-line interface
 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH 
THE WEB INTERFACE AVAILABLE AT 
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34906>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG 
DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34906


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
Summary|User-Agent is PARAMETER, not|[Patch] User-Agent is
   |HEADER in Command-line  |PARAMETER, not HEADER in
   |interface   |Command-line interface




--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 22:41 --- 
AFAICS this patch has not been committed yet, so it is better to not set the 
bug to fixed. Otherwise the patch won't be applied.

Joerg

--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: --- You are the assignee for 
the bug, or are watching the assignee.
You reported the bug, or are watching the reporter.

DO NOT REPLY [Bug 34906] - [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34906





--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 14:41 ---
Created an attachment (id=15131)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15131&action=view)
patch against "trunk" (2.2.X) branch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface

[James Bates]

OK; I was unaware of the meaning of the flags in bugzilla.

I have a second patch for the "trunk" branch, but have not inserted it into 
Bugzilla yet. Will do so this afternoon...
As for committing, I cannot as I am no Cocoon regular developer. Could someone 
else do so?

James


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sun 22/05/2005 22:41
To: James Bates
Subject: DO NOT REPLY [Bug 34906]  -[Patch] User-Agent is PARAMETER, not 
HEADER in Command-line interface
 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34906>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34906


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
Summary|User-Agent is PARAMETER, not|[Patch] User-Agent is
   |HEADER in Command-line  |PARAMETER, not HEADER in
   |interface   |Command-line interface




--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 22:41 ---
AFAICS this patch has not been committed yet, so it is better to not set the bug
to fixed. Otherwise the patch won't be applied.

Joerg

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
You reported the bug, or are watching the reporter.

DO NOT REPLY [Bug 34906] - [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34906


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]|dev@cocoon.apache.org
 Status|REOPENED|NEW




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 34906] - User-Agent is PARAMETER, not HEADER in Command-line interface

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34906>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34906


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|dev@cocoon.apache.org   |[EMAIL PROTECTED]
 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2005-05-13 13:59 ---
Created an attachment (id=15019)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15019&action=view)
Patch to resolve issue (against 2.1.X code branch)

The code ALTERS the behaviour sothat any 
existing implemenetations that depend on the user agent being in a 
PARAMETER and not a HEADER when running the CLI will break... It would 
be recommended I imagine to mention this in the "Changes" file?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 34906] New: - User-Agent is PARAMETER, not HEADER in Command-line interface

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34906>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34906

   Summary: User-Agent is PARAMETER, not HEADER in Command-line
interface
   Product: Cocoon 2
   Version: Current SVN 2.1
  Platform: All
   URL: http://cocoon.apache.org/2.1
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


The Cocoon command line interface provides a switch for simulating 
the Cocoon User-Agent header that would be sent by a browser. The 
idea being that it could be used by e.g. the browser selector to 
“detect” that a request is coming from the CLI.
 
When investigating however, I noticed that the Cocoon bean (the 
class that implements the CLI) does not place the User-Agent into a 
HEDAER, but into a request PARAMETER instead (occurs on line 407 of 
CocoonWrapper.java, in method processURI() in BRANCH_2_1_X; line 421 
of the same file in 2.2 trunk).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Images not cached by IE if using ImageReader without expires parameter

[Vadim Gritsenko]

Adam Ratcliffe wrote:
I've just resolved an issue I had with images loaded by a javascript 
preloader not being cached by Internet Explorer, the images
are produced in a Cocoon pipeline that uses the ImageReader.
 
The problem is with the 'Vary' response header that is set by the reader 
if the 'expires' parameter is not provided. IE will not cache
responses containing this header unless its field value is the 
'User-Agent' field, for more detail see:
http://lists.over.net/pipermail/mod_gzip/2002-December/006826.html
 
Looking at the ResourceReader source and the associated bug report, 
setting the 'Vary' header was intended to prevent IE from
caching the resource when the 'expires' parameter was provided with a 
value of 0.  The way the code is implemented the header
will also be set when the expires parameter is not provided.
 
Should the default behaviour of the ResourceReader be to provide 
non-cachable content?
Don't think so. Please provide a patch via bugzilla.
PS And switch to plain text email, html on mail lists is evil.
Vadim

Images not cached by IE if using ImageReader without expires parameter

[Adam Ratcliffe]

I've just resolved 
an issue I had with images loaded by a _javascript_ preloader not being cached by 
Internet Explorer, the images
are produced in a 
Cocoon pipeline that uses the ImageReader.
 
The problem is with 
the 'Vary' response header that is set by the reader if the 'expires' parameter 
is not provided. IE will not cache
responses containing 
this header unless its field value is the 'User-Agent' field, for more detail 
see:
http://lists.over.net/pipermail/mod_gzip/2002-December/006826.html
 
Looking at the 
ResourceReader source and the associated bug report, setting the 'Vary' header 
was intended to prevent IE from
caching the resource 
when the 'expires' parameter was provided with a value of 0.  The way the 
code is implemented the header
will also be set 
when the expires parameter is not provided.
 
Should the default 
behaviour of the ResourceReader be to provide non-cachable 
content?
 
Cheers
Adam

DO NOT REPLY [Bug 32961] - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32961


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32961] - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32961


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-01-12 12:20 ---
Applied, please cross-check and close the bug.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32961] - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32961


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32961] - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32961





--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 09:55 ---
Created an attachment (id=13909)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13909&action=view)
fb:insert-bean-documentation Patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32961] - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32961





--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 09:54 ---
Created an attachment (id=13908)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13908&action=view)
InsertBeanJXPathBindingBuilder Patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32961] - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32961





--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 09:53 ---
Created an attachment (id=13907)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13907&action=view)
InsertBeanJXPathBinding Patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32961] New: - [PATCH] Allow to use fb:insert-bean with add methods without a parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32961>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32961

   Summary: [PATCH] Allow to use fb:insert-bean with add methods
without a parameter
   Product: Cocoon 2
   Version: Current SVN 2.1
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: CocoonForms
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


This patch allows to use fb:insert-bean without the classname attribute to 
support models which have add methods without parameters (myObj.addNewElement
() instead of myObj.addNewElement(myNewElement)). If the classname attribute 
is specified a new instance of it is created and passed to the add method and 
if classname is not specified it just calls the add method, so classname is 
optional now.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 31134] - [PATCH] JXPathMetaModule incorrectly checks for null parameter (can't happen) instead of empty string.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31134


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32011] - [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32011





--- Additional Comments From [EMAIL PROTECTED]  2004-11-17 17:24 ---
OK. Applied in 2.1.6-dev and 2.2. Thanks for the contribution. :-D

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32011] - [PATCH] buildList in AbstractDatabaseAction generates incorrect parameter list

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32011





--- Additional Comments From [EMAIL PROTECTED]  2004-11-17 16:59 ---
That sounds good to me.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.