Re: Release 2.1.9 (again)

2006-03-11 Thread Antonio Gallardo

Ralph Goers wrote:




Carsten Ziegeler wrote:


Thanks :) The older you get the more you enjoy talking to yourself...

Anyways, given my current time constraints I can do the release not any
sooner than the 31st of March - so, seeing this as a positive fact, we
have a little more time to test everything :). I would call for a code
freeze on the 24th of March then.

WDYT?
Carsten
  


+1  In the meantime, lets keep looking at patches in the queue.


+1. It sounds like a great plan. ;-)

Best Regards,

Antonio Gallardo.



Re: [jira] Created: (COCOON-1789) [PATCH] Char datatype

2006-03-11 Thread Andrew Savory

Hi Simone,

Simone Gianni (JIRA) wrote:

[PATCH] Char datatype
-


Patch applied. I noticed that your editor is not set to use the 
preferred coding style for tabs - can you update it to use 4 spaces, 
instead of tabs?


I also noticed @author in the javadoc comments - I believe use of 
@author is now deprecated, so I've stripped them.



Thanks,

Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/


[jira] Closed: (COCOON-1789) [PATCH] Char datatype

2006-03-11 Thread Andrew Savory (JIRA)
 [ http://issues.apache.org/jira/browse/COCOON-1789?page=all ]
 
Andrew Savory closed COCOON-1789:
-

Resolution: Fixed

Patch applied. Thanks!

> [PATCH] Char datatype
> -
>
>  Key: COCOON-1789
>  URL: http://issues.apache.org/jira/browse/COCOON-1789
>  Project: Cocoon
> Type: New Feature
>   Components: Blocks: Forms
> Versions: 2.1.9-dev (current SVN)
> Reporter: Simone Gianni
> Priority: Minor
>  Attachments: chardataype-conf.diff, chardataype-samples.diff, 
> chardataype.diff
>
> Cocoon forms lacks a Char datatype. This is often needed in bean bindings for 
> database oriented applications, where the char often appears in a field.
> The first patch provides a char datatype with it's builder, it's char 
> convertor, the second patch the changes to the configuration to add the 
> datatype, the third a modification of the samples form2 definition, bean and 
> binding to give an example of the char datatype adding a middleInitial char 
> field.
> Patches applied to 2.1.X branch, but tested on 2.1.6, 2.1.7 and trunk.
> Thanks to Maurizio Pillitu for first implementation.

-- 
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: Release 2.1.9 (again)

2006-03-11 Thread Ralph Goers



Carsten Ziegeler wrote:

Thanks :) The older you get the more you enjoy talking to yourself...

Anyways, given my current time constraints I can do the release not any
sooner than the 31st of March - so, seeing this as a positive fact, we
have a little more time to test everything :). I would call for a code
freeze on the 24th of March then.

WDYT?
Carsten
  

+1  In the meantime, lets keep looking at patches in the queue.


Re: Release 2.1.9 (again)

2006-03-11 Thread Carsten Ziegeler
Joerg Heinicke wrote:
> On 10.03.2006 15:55, Sylvain Wallez wrote:
> 
>> Yep! Sorry, I have a crazy cahotic schedule lately. Development of the
>> Dojo stuff is finished and I'm currently chasing a bug in IE.
>>
>> Commit should hopefully happen in a few hours.
> 
> So, let's talk about a release date - which is mostly a monolog of 
> Carsten ;)
> 
Thanks :) The older you get the more you enjoy talking to yourself...

Anyways, given my current time constraints I can do the release not any
sooner than the 31st of March - so, seeing this as a positive fact, we
have a little more time to test everything :). I would call for a code
freeze on the 24th of March then.

WDYT?
Carsten

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


Re: [jira] Closed: (COCOON-1728) Apples can't access components declared in mounted sitemap

2006-03-11 Thread Jorg Heymans

Joerg Heinicke wrote:
> On 11.03.2006 14:04, Jorg Heymans wrote:
> 
>> AFAICT the apples block has not been copied to trunk yet.
> 
> What about
> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/apples/trunk/java/org/apache/cocoon/components/flow/apples/
> ?
> 

synchronized now.


Jorg



Re: [jira] Closed: (COCOON-1728) Apples can't access components declared in mounted sitemap

2006-03-11 Thread Joerg Heinicke

On 11.03.2006 14:04, Jorg Heymans wrote:


AFAICT the apples block has not been copied to trunk yet.


What about 
http://svn.apache.org/viewcvs.cgi/cocoon/blocks/apples/trunk/java/org/apache/cocoon/components/flow/apples/ 
?


Jörg


Re: [jira] Closed: (COCOON-1728) Apples can't access components declared in mounted sitemap

2006-03-11 Thread Jorg Heymans

Joerg Heinicke wrote:

> 
> What about trunk?
>

AFAICT the apples block has not been copied to trunk yet.


Jorg



Re: [jira] Closed: (COCOON-1728) Apples can't access components declared in mounted sitemap

2006-03-11 Thread Joerg Heinicke

On 11.03.2006 13:26, Jorg Heymans (JIRA) wrote:

 [ http://issues.apache.org/jira/browse/COCOON-1728?page=all ]
 
Jorg Heymans closed COCOON-1728:



Fix Version: 2.1.9-dev (current SVN)
 Resolution: Fixed


What about trunk?


Apples can't access components declared in mounted sitemap
--

 Key: COCOON-1728
 URL: http://issues.apache.org/jira/browse/COCOON-1728
 Project: Cocoon
Type: Bug
  Components: Blocks: Apples
Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN)


From the bug report it seems also apply to trunk.

Jörg


[jira] Closed: (COCOON-1728) Apples can't access components declared in mounted sitemap

2006-03-11 Thread Jorg Heymans (JIRA)
 [ http://issues.apache.org/jira/browse/COCOON-1728?page=all ]
 
Jorg Heymans closed COCOON-1728:


Fix Version: 2.1.9-dev (current SVN)
 Resolution: Fixed

> Apples can't access components declared in mounted sitemap
> --
>
>  Key: COCOON-1728
>  URL: http://issues.apache.org/jira/browse/COCOON-1728
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Apples
> Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
> Reporter: Paul Focke
> Priority: Minor
>  Fix For: 2.1.9-dev (current SVN)
>  Attachments: cocoon-appleProcessor.diff
>
> Apples use the serviceManager from the root sitemap to lookup components, 
> therefore components from mounted sitemaps cannot be found.  This patch gives 
> the apple the serviceManager from the current sitemap.

-- 
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] Geschlossen: (COCOON-1799) [PATCH] Threads waste when reading a not found resource.

2006-03-11 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1799?page=all ]
 
Jörg Heinicke closed COCOON-1799:
-

Resolution: Fixed

added comment to TO-SYNC-FROM-BRANCH.TXT

> [PATCH] Threads waste when reading a not found resource.
> 
>
>  Key: COCOON-1799
>  URL: http://issues.apache.org/jira/browse/COCOON-1799
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.9-dev (current SVN)
> Reporter: Simone Gianni
> Assignee: Antonio Gallardo
> Priority: Blocker
>  Fix For: 2.1.9-dev (current SVN)
>  Attachments: pipeline.diff
>
> When setting up a pipeline with a reader on a not found file, the first time 
> a 404 is reported, but following requests will hang up and the thread will 
> never get released, causing a potential complete lock exausting threads.
> In the AbstractCachingProcessingPipeline class, in ProcessReader method, the 
> following happens :
> - 774: a pcKey is created for caching content
> - 853: the method eventually waits if another thread is generating
> - 869: the method acquires a lock, to avoid other threads to generate twice
> - 886: if there is no need cache validity pcKey is setted to null
> - 918: if an exception occurrs while generating, the following code is in a 
> finally :
>   if (pcKey != null) {
>   releaseLock(pcKey);
>   }
> This obviously brings to the following situation :
> - A non existing resource is being generated
> - A lock is acquired
> - The FileSource returns null if the file does not exist.
> - So pcKey is setted to null.
> - An exception is thrown, since the file is not found.
> - The finally block does not release the lock
> - Next requests on the same file will hang waiting on the lock, but the other 
> thread will never release it.
> This can easily consume all threads, it's quite easy to have this kind of 
> errors on a missing gif, or css, or favicon.ico or something else. 
> I modified this class so that it :
> - Does not set pckey to null when readerValidity == null
> - Checks for pckey != null && readerValidity != null on line 907 so that 
> content is not cached if readerValidity == null
> - Since pckey is != null the lock is released.
> I tested it and seems to work correctly, but this is core stuff, please 
> double check it!!

-- 
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-1728) Apples can't access components declared in mounted sitemap

2006-03-11 Thread Jorg Heymans (JIRA)
[ 
http://issues.apache.org/jira/browse/COCOON-1728?page=comments#action_12369985 
] 

Jorg Heymans commented on COCOON-1728:
--

Applied, thanks.

Please check and close this issue.

> Apples can't access components declared in mounted sitemap
> --
>
>  Key: COCOON-1728
>  URL: http://issues.apache.org/jira/browse/COCOON-1728
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Apples
> Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
> Reporter: Paul Focke
> Priority: Minor
>  Attachments: cocoon-appleProcessor.diff
>
> Apples use the serviceManager from the root sitemap to lookup components, 
> therefore components from mounted sitemaps cannot be found.  This patch gives 
> the apple the serviceManager from the current sitemap.

-- 
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] Geschlossen: (COCOON-1779) [PATCH] JUnit tests for LocaleAction

2006-03-11 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1779?page=all ]
 
Jörg Heinicke closed COCOON-1779:
-

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

It's better to set it to FIXED/CLOSED and let the reporter reopen it if 
necessary.

> [PATCH] JUnit tests for LocaleAction
> 
>
>  Key: COCOON-1779
>  URL: http://issues.apache.org/jira/browse/COCOON-1779
>  Project: Cocoon
> Type: Test
>   Components: * Cocoon Core
> Versions: 2.1.9-dev (current SVN)
> Reporter: Andrew Stevens
> Assignee: Jorg Heymans
> Priority: Minor
>  Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
>  Attachments: LocaleActionTestCase.java, LocaleActionTestCase.xtest, 
> mockrequest.diff
>
> While looking into the patch on COCOON-1592, I figured some test cases for 
> the existing action would be useful, to be sure that the patch didn't break 
> any existing functionality.
> Attached are the testcase and .xtest files, to go in 
> src/test/org/apache/cocoon/acting.  Also, in order to test the case where the 
> locale is read from the browser's Accept-Language or server default, I had to 
> add a setLocale method to the MockRequest; the attached diff is for this.

-- 
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] Geschlossen: (COCOON-1335) [PATCH] RoleFilterTransformer dependent on buggy FilterTransformer

2006-03-11 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1335?page=all ]
 
Jörg Heinicke closed COCOON-1335:
-

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

It's better to set it to FIXED/CLOSED and let the reporter reopen it if 
necessary.

> [PATCH] RoleFilterTransformer dependent on buggy FilterTransformer
> --
>
>  Key: COCOON-1335
>  URL: http://issues.apache.org/jira/browse/COCOON-1335
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.5
>  Environment: Operating System: All
> Platform: Other
> Reporter: Michal Durdina
> Assignee: Jorg Heymans
>  Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
>  Attachments: release_2_1_5_1.patch_11.txt, release_2_1_6.patch_9.diff, 
> release_2_1_7.patch.diff
>
> Inheritance from class FilterTransformer removed, required (useless) 
> parameters 
> for FilterTransformer are not needed anymore.

-- 
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-1779) [PATCH] JUnit tests for LocaleAction

2006-03-11 Thread Jorg Heymans (JIRA)
[ 
http://issues.apache.org/jira/browse/COCOON-1779?page=comments#action_12369981 
] 

Jorg Heymans commented on COCOON-1779:
--

nevermind, my patching skills are getting rusty... 

Synchronized to trunk, please check and close this issue.

> [PATCH] JUnit tests for LocaleAction
> 
>
>  Key: COCOON-1779
>  URL: http://issues.apache.org/jira/browse/COCOON-1779
>  Project: Cocoon
> Type: Test
>   Components: * Cocoon Core
> Versions: 2.1.9-dev (current SVN)
> Reporter: Andrew Stevens
> Assignee: Jorg Heymans
> Priority: Minor
>  Attachments: LocaleActionTestCase.java, LocaleActionTestCase.xtest, 
> mockrequest.diff
>
> While looking into the patch on COCOON-1592, I figured some test cases for 
> the existing action would be useful, to be sure that the patch didn't break 
> any existing functionality.
> Attached are the testcase and .xtest files, to go in 
> src/test/org/apache/cocoon/acting.  Also, in order to test the case where the 
> locale is read from the browser's Accept-Language or server default, I had to 
> add a setLocale method to the MockRequest; the attached diff is for this.

-- 
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: Sharing the template block between 2.1 and 2.2 DONE!

2006-03-11 Thread Bruno Dumon
On Fri, 2006-03-10 at 16:53 +0100, Reinhard Poetz wrote:
> Jason Johnston wrote:
> 
> > A question: it appears that both the 2.1.x core and the template block
> > contain the classes o.a.c.generation.JXTemplateGenerator and
> > o.a.c.transformation.JXTemplateTransformer.  In 2.1.x they're the old JX
> > we know and love, and in the template block they point to the new JX.
> > 
> > So when using those old classes in 2.1.x with the template block
> > included, which version of JX gets used?
> 
> In 2.1.x the old generator should *not* extend the new generator and in the 
> template block we should simply remove the class. In order to do this and 
> follow 
> our versioning policy, we have to deprecate the old implementations.
> 

I followed this suggestion, as this is also what has been voted on [1].

The "move" is done now. The java sources of the template block are
shared via svn:externals.

In 2.1, the new jx template generator is by default declared in the
sitemap with the name "newjx".

[1] http://marc.theaimsgroup.com/?t=11371475241&r=1&w=2

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]



Re: svn commit: r384717 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline.java status.xml

2006-03-11 Thread Antonio Gallardo

Jean-Baptiste Quenot wrote:


* [EMAIL PROTECTED]:
 


Author: antonio
Date: Thu Mar  9 22:41:58 2006
New Revision: 384717

URL: http://svn.apache.org/viewcvs?rev=384717&view=rev
Log:


  Threads waste when reading a not found resource.

   



Actually the locking feature does not appear in status.xml.  So
IMHO this bugfix should not be mentioned in status.xml.  What
needs to be mentioned is the new locking feature.
 

IMHO, the reason why it should not appear in the status.xml is because 
the bug was never released. I will delete it now.



This feature must also be ported to trunk.
 


+1 I will prefer if Max can do that.

Best Regards,

Antonio Gallardo


[jira] Commented: (COCOON-1779) [PATCH] JUnit tests for LocaleAction

2006-03-11 Thread Jorg Heymans (JIRA)
[ 
http://issues.apache.org/jira/browse/COCOON-1779?page=comments#action_12369978 
] 

Jorg Heymans commented on COCOON-1779:
--

Actually, could have a look in porting the patch to trunk ? mockrequest.diff 
does not seem to apply there.

> [PATCH] JUnit tests for LocaleAction
> 
>
>  Key: COCOON-1779
>  URL: http://issues.apache.org/jira/browse/COCOON-1779
>  Project: Cocoon
> Type: Test
>   Components: * Cocoon Core
> Versions: 2.1.9-dev (current SVN)
> Reporter: Andrew Stevens
> Assignee: Jorg Heymans
> Priority: Minor
>  Attachments: LocaleActionTestCase.java, LocaleActionTestCase.xtest, 
> mockrequest.diff
>
> While looking into the patch on COCOON-1592, I figured some test cases for 
> the existing action would be useful, to be sure that the patch didn't break 
> any existing functionality.
> Attached are the testcase and .xtest files, to go in 
> src/test/org/apache/cocoon/acting.  Also, in order to test the case where the 
> locale is read from the browser's Accept-Language or server default, I had to 
> add a setLocale method to the MockRequest; the attached diff is for this.

-- 
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-1779) [PATCH] JUnit tests for LocaleAction

2006-03-11 Thread Jorg Heymans (JIRA)
[ 
http://issues.apache.org/jira/browse/COCOON-1779?page=comments#action_12369977 
] 

Jorg Heymans commented on COCOON-1779:
--

Applied, thanks .

Please have a look if all went in ok and close this issue.

> [PATCH] JUnit tests for LocaleAction
> 
>
>  Key: COCOON-1779
>  URL: http://issues.apache.org/jira/browse/COCOON-1779
>  Project: Cocoon
> Type: Test
>   Components: * Cocoon Core
> Versions: 2.1.9-dev (current SVN)
> Reporter: Andrew Stevens
> Assignee: Jorg Heymans
> Priority: Minor
>  Attachments: LocaleActionTestCase.java, LocaleActionTestCase.xtest, 
> mockrequest.diff
>
> While looking into the patch on COCOON-1592, I figured some test cases for 
> the existing action would be useful, to be sure that the patch didn't break 
> any existing functionality.
> Attached are the testcase and .xtest files, to go in 
> src/test/org/apache/cocoon/acting.  Also, in order to test the case where the 
> locale is read from the browser's Accept-Language or server default, I had to 
> add a setLocale method to the MockRequest; the attached diff is for this.

-- 
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-1779) [PATCH] JUnit tests for LocaleAction

2006-03-11 Thread Jorg Heymans (JIRA)
 [ http://issues.apache.org/jira/browse/COCOON-1779?page=all ]

Jorg Heymans reassigned COCOON-1779:


Assign To: Jorg Heymans

> [PATCH] JUnit tests for LocaleAction
> 
>
>  Key: COCOON-1779
>  URL: http://issues.apache.org/jira/browse/COCOON-1779
>  Project: Cocoon
> Type: Test
>   Components: * Cocoon Core
> Versions: 2.1.9-dev (current SVN)
> Reporter: Andrew Stevens
> Assignee: Jorg Heymans
> Priority: Minor
>  Attachments: LocaleActionTestCase.java, LocaleActionTestCase.xtest, 
> mockrequest.diff
>
> While looking into the patch on COCOON-1592, I figured some test cases for 
> the existing action would be useful, to be sure that the patch didn't break 
> any existing functionality.
> Attached are the testcase and .xtest files, to go in 
> src/test/org/apache/cocoon/acting.  Also, in order to test the case where the 
> locale is read from the browser's Accept-Language or server default, I had to 
> add a setLocale method to the MockRequest; the attached diff is for this.

-- 
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-1335) [PATCH] RoleFilterTransformer dependent on buggy FilterTransformer

2006-03-11 Thread Jorg Heymans (JIRA)
[ 
http://issues.apache.org/jira/browse/COCOON-1335?page=comments#action_12369976 
] 

Jorg Heymans commented on COCOON-1335:
--

Applied thanks.

Please have a look if all went in ok.


> [PATCH] RoleFilterTransformer dependent on buggy FilterTransformer
> --
>
>  Key: COCOON-1335
>  URL: http://issues.apache.org/jira/browse/COCOON-1335
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.5
>  Environment: Operating System: All
> Platform: Other
> Reporter: Michal Durdina
> Assignee: Jorg Heymans
>  Attachments: release_2_1_5_1.patch_11.txt, release_2_1_6.patch_9.diff, 
> release_2_1_7.patch.diff
>
> Inheritance from class FilterTransformer removed, required (useless) 
> parameters 
> for FilterTransformer are not needed anymore.

-- 
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: svn commit: r384153 - /cocoon/blocks/naming/trunk/java/org/apache/cocoon/transformation/LDAPTransformer.java

2006-03-11 Thread Joerg Heinicke

URL: http://svn.apache.org/viewcvs?rev=384153&view=rev
Log: Sync with 2.1


Could you (all) please avoid such useless commit messages. Later on 
nobody knows what actually has changed in this revision. Either copy the 
commit from the other branch or refer to the revision of that commit. 
And only in case of exceptional circumstances (e.g. after one year of 
two completely different versions in both branches) fall back to such a 
commit message.


Thanks.

Jörg


Re: [WEBSITE] 2.1/installing/index.html

2006-03-11 Thread Joerg Heinicke

On 09.03.2006 18:51, Seth Foss wrote:
Your website needs to contain installation procedures for the most 
up-to-date versions of both Cocoon and Tomcat. (Cocoon 2.1.x and Tomcat 
5.5.x)


An installation procedure for this version of Cocoon is difficult to 
find anywhere online, especially for use with Tomcat 5 or later.


There's nothing special about deploying Cocoon in web server, that's why 
this document never has been updated. But it arose from a time where the 
web servers behave very differently and where you needed different 
instructions for different environments.


Jörg



Re: Release 2.1.9 (again)

2006-03-11 Thread Joerg Heinicke

On 10.03.2006 15:55, Sylvain Wallez wrote:


Yep! Sorry, I have a crazy cahotic schedule lately. Development of the
Dojo stuff is finished and I'm currently chasing a bug in IE.

Commit should hopefully happen in a few hours.


So, let's talk about a release date - which is mostly a monolog of 
Carsten ;)


Jörg


Re: [jira] Reopened: (COCOON-1799) [PATCH] Threads waste when reading a not found resource.

2006-03-11 Thread Joerg Heinicke

On 11.03.2006 00:20, Antonio Gallardo wrote:
I'm reopening this issue just for trunk: 
AbstractCachingProcessingPipeline locking feature *must* be ported to 
trunk, and this bugfix as well.


IMHO given the current code base, the bug has already been fixed 
everywhere. The bug was introduced with the newly "locking feature". 
Note the bug was only for 2.1.x-dev and since the code has not been 
merged in 2.2 yet, actually it does not apply for 2.2. When the trunk 
will be synchronized, this bug will be automatically fixed there too, 
hence the bug has never been nor will appear in 2.2.



wdyt?


+1 I agree. There is another "to be synced" document somewhere.

Jörg


[jira] Assigned: (COCOON-1335) [PATCH] RoleFilterTransformer dependent on buggy FilterTransformer

2006-03-11 Thread Jorg Heymans (JIRA)
 [ http://issues.apache.org/jira/browse/COCOON-1335?page=all ]

Jorg Heymans reassigned COCOON-1335:


Assign To: Jorg Heymans  (was: Cocoon Developers Team)

> [PATCH] RoleFilterTransformer dependent on buggy FilterTransformer
> --
>
>  Key: COCOON-1335
>  URL: http://issues.apache.org/jira/browse/COCOON-1335
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.5
>  Environment: Operating System: All
> Platform: Other
> Reporter: Michal Durdina
> Assignee: Jorg Heymans
>  Attachments: release_2_1_5_1.patch_11.txt, release_2_1_6.patch_9.diff, 
> release_2_1_7.patch.diff
>
> Inheritance from class FilterTransformer removed, required (useless) 
> parameters 
> for FilterTransformer are not needed anymore.

-- 
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