Re: [docs] Livesites by working area

[Ross Gardler]

hepabolu wrote:

Arje Cahn wrote:

Yes, create a doc typoe, add a few relevant fields (including one of 
tags.




Helma, do you know how to do this? If you add the type, I'll start 
converting the sites..


Arje



I created a CocoonLiveSiteDocument (check spelling!) with a simple 
content part and a Metadata part that should behave like the Book 
Metadata part. However, it doesn't. I suppose Bruno has added some extra 
processing underneath that I should have a look into, but somehow I 
can't get onto the server to have a look.


So for now there is not much else I can do.


I think, to make things future-proof, we need a flexible metadata part, 
much like the bookmetadata part, where metadata key/value pairs can be 
added, rather than a set number of fields which accommodate for the 
current distinctions (category and version).


The approach I use here for our documentation system is to have a 
multi-valued field that any user can use to tag a document. I also have 
a set of collections that are the "official" classifications.


Using this you can have categorisation by tag (which can get quite messy 
of course) and then a categoriasation by collection (which is well 
structured).


Periodically, we review common tags and verify that we have a suitable 
collection for that tag and that all documents are in the right 
collections according to their tags.


If you think otherwise, I'd be happy to create two fields, one with a 
selection list for the versions and one with a selection list for the 
categories.


Do you mean Cocoon version? Should this be a document variant? So you 
would have a single live sites document, with X variants, one for each 
major version.


Ross

Re: [docs] Livesites by working area

[hepabolu]

Arje Cahn wrote:
Yes, create a doc typoe, add a few relevant fields (including 
one of tags.



Helma, do you know how to do this? If you add the type, I'll start converting 
the sites..

Arje



I created a CocoonLiveSiteDocument (check spelling!) with a simple 
content part and a Metadata part that should behave like the Book 
Metadata part. However, it doesn't. I suppose Bruno has added some extra 
processing underneath that I should have a look into, but somehow I 
can't get onto the server to have a look.


So for now there is not much else I can do.


I think, to make things future-proof, we need a flexible metadata part, 
much like the bookmetadata part, where metadata key/value pairs can be 
added, rather than a set number of fields which accommodate for the 
current distinctions (category and version).


If you think otherwise, I'd be happy to create two fields, one with a 
selection list for the versions and one with a selection list for the 
categories.


OTOH: selection lists make the process of assigning values easier and 
less error prone.


WDYT?



Have a look at the Book Definition by creating a new document of that 
type and let me know what you prefer.


Bye, Helma

[jira] Commented: (COCOON-1672) Help popup broken in CForms samples

[Sylvain Wallez (JIRA)]

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

Sylvain Wallez commented on COCOON-1672:


I'm currently working on a fix.

The problem is twofold:
- use of generate-id() which should be avoided in an Ajax environment where 
several requests participate to a single page
- 

[jira] Assigned: (COCOON-1672) Help popup broken in CForms samples

[Sylvain Wallez (JIRA)]

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

Sylvain Wallez reassigned COCOON-1672:
--

Assign To: Sylvain Wallez

> Help popup broken in CForms samples
> ---
>
>  Key: COCOON-1672
>  URL: http://issues.apache.org/jira/browse/COCOON-1672
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms, - Samples
> Versions: 2.1.8-dev (Current SVN)
> Reporter: Andreas Hochsteger
> Assignee: Sylvain Wallez

>
> If you open the multiform (ajax) sample 
> (http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/do-multipage.flow)
>  and click on the help popup for the email addres, it is working.
> But if you click on next, then it is not working any more.
> I get the following JavaScript error:
> Error: helpWinN10010 has no properties
> It seems to me, that the help window is not referenced correctly after the 
> first submit.
> Perhaps it's AJAX-related, because it is working for non-ajax samples:
> http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form1
> http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/captcha/
> Similar problems can be found on the following samples with the help popup 
> and calendar popup, where the images are missing too:
> http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form1.flow
> http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form2.flow
> http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/hotel.flow
> I tested it locally with a fresh svn checkout (r330107) and on 
> cocoon.zones.apache.org with Firefox 1.5beta2 and IE 6 (Win XP Pro, SP2), Sun 
> JDK 1.5.0_04.

-- 
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: [docs] Livesites by working area

[Arje Cahn]

> Yes, create a doc typoe, add a few relevant fields (including 
> one of tags.

Helma, do you know how to do this? If you add the type, I'll start converting 
the sites..

Arje

[jira] Created: (COCOON-1672) Help popup broken in CForms samples

[Andreas Hochsteger (JIRA)]

Help popup broken in CForms samples
---

 Key: COCOON-1672
 URL: http://issues.apache.org/jira/browse/COCOON-1672
 Project: Cocoon
Type: Bug
  Components: Blocks: Forms, - Samples  
Versions: 2.1.8-dev (Current SVN)
Reporter: Andreas Hochsteger


If you open the multiform (ajax) sample 
(http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/do-multipage.flow)
 and click on the help popup for the email addres, it is working.
But if you click on next, then it is not working any more.
I get the following JavaScript error:
Error: helpWinN10010 has no properties

It seems to me, that the help window is not referenced correctly after the 
first submit.

Perhaps it's AJAX-related, because it is working for non-ajax samples:
http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form1
http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/captcha/

Similar problems can be found on the following samples with the help popup and 
calendar popup, where the images are missing too:
http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form1.flow
http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form2.flow
http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/hotel.flow

I tested it locally with a fresh svn checkout (r330107) and on 
cocoon.zones.apache.org with Firefox 1.5beta2 and IE 6 (Win XP Pro, SP2), Sun 
JDK 1.5.0_04.


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

a new cocoon logo?

[Frédéric Moser]

Hi all,

I had an attack of inspiration for a cocoon logo, I don't know if you
need a new one and if you'll like it.
I would be glad if it could bring something to the project which
helped me more than once.

Anyway I join a sketch of it, tell me if you would like me to change anything.

Have a nice day,

Frédéric Moser


cocoon_logo_black.png
Description: PNG image

DO NOT REPLY [Bug 36810] - source that declares namespace fails JXPath/Linkrewriter/Input Modules

[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=36810


Bug 36810 depends on bug 32360, which changed state.

Bug 32360 Summary: [jxpath] Default Namespace not handled correctly
http://issues.apache.org/bugzilla/show_bug.cgi?id=32360

   What|Old Value   |New Value

 Status|REOPENED|RESOLVED
 Resolution||FIXED



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

[jira] Closed: (COCOON-1607) Patch for forms-calender-styling.xsl

[Sylvain Wallez (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1607?page=all ]
 
Sylvain Wallez closed COCOON-1607:
--

Resolution: Fixed

Fixed in revision 307413

> Patch for forms-calender-styling.xsl
> 
>
>  Key: COCOON-1607
>  URL: http://issues.apache.org/jira/browse/COCOON-1607
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: Other
> Reporter: Christoph Hermann
> Assignee: Cocoon Developers Team
> Priority: Trivial
>  Attachments: forms-calender-styleing.xsl-patch
>
> Hello,
> i modified the id attribute of the  in forms-calender-styling.xsl
> (from svn) to make the generated html valid.
> The id tag should contain "-input" (as all other inputs) for the
> label-reference.
> See attached patch.
> Christoph

-- 
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-1629) No default value in forms binding

[Sylvain Wallez (JIRA)]

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

Sylvain Wallez updated COCOON-1629:
---

Bugzilla Id:   (was: 36993)
Description: 
When wishing to have a default value for the binding of a form widget, it is
required to make use of a hack like this:

for (var iter = form.form.getChildren() ; 
iter.hasNext() ;) {
var child = iter.next();
if
(child.getClass().getName().equals("org.apache.cocoon.forms.formmodel.Field") &&
child.getDatatype().getTypeClass().getName().equals("java.lang.Long") &&
child.getValue() == null) {
child.setValue(new java.lang.Long(-1));
}
}   

It would be great to add an attribute on , for example:
 to have a default value that could be
used in the binding.

  was:
When wishing to have a default value for the binding of a form widget, it is
required to make use of a hack like this:

for (var iter = form.form.getChildren() ; 
iter.hasNext() ;) {
var child = iter.next();
if
(child.getClass().getName().equals("org.apache.cocoon.forms.formmodel.Field") &&
child.getDatatype().getTypeClass().getName().equals("java.lang.Long") &&
child.getValue() == null) {
child.setValue(new java.lang.Long(-1));
}
}   

It would be great to add an attribute on , for example:
 to have a default value that could be
used in the binding.


Doesn't the initial value in form definition solve your problem?



> No default value in forms binding
> -
>
>  Key: COCOON-1629
>  URL: http://issues.apache.org/jira/browse/COCOON-1629
>  Project: Cocoon
> Type: Improvement
>   Components: Blocks: Forms
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jean-Baptiste Quenot
> Assignee: Cocoon Developers Team
> Priority: Minor

>
> When wishing to have a default value for the binding of a form widget, it is
> required to make use of a hack like this:
>   for (var iter = form.form.getChildren() ; 
> iter.hasNext() ;) {
>   var child = iter.next();
>   if
> (child.getClass().getName().equals("org.apache.cocoon.forms.formmodel.Field") 
> &&
> child.getDatatype().getTypeClass().getName().equals("java.lang.Long") &&
> child.getValue() == null) {
>   child.setValue(new java.lang.Long(-1));
>   }
>   }   
> It would be great to add an attribute on , for example:
>  to have a default value that could be
> used in the binding.

-- 
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-1615) [CFORMS] Widgets set to INVISIBLE not are removed in AJAX

[Sylvain Wallez (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1615?page=all ]
 
Sylvain Wallez closed COCOON-1615:
--

Resolution: Fixed

Fixed.

> [CFORMS] Widgets set to INVISIBLE not are removed in AJAX
> -
>
>  Key: COCOON-1615
>  URL: http://issues.apache.org/jira/browse/COCOON-1615
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.2-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jason Johnston
> Assignee: Cocoon Developers Team

>
> Since the CForms JXMacros refactoring, a widget which is programatically set 
> to
> WidgetState.INVISIBLE is not removed from the display during AJAX requests,
> because no BrowserUpdate wrapper is created for it.  See
> JXMacrosHelper.pushWidget(), around line 186 (svn rev 291471).

-- 
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-1668) o.a.c.forms.formmodel.GroupTestCase fails

[Sylvain Wallez (JIRA)]

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

Sylvain Wallez updated COCOON-1668:
---

Fix Version: 2.2-dev (Current SVN)
 (was: 2.1.8-dev (Current SVN))

Need to get used to JIRA classifiers...

> o.a.c.forms.formmodel.GroupTestCase fails
> -
>
>  Key: COCOON-1668
>  URL: http://issues.apache.org/jira/browse/COCOON-1668
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.2-dev (Current SVN)
> Reporter: Bertrand Delacretaz
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Fix For: 2.2-dev (Current SVN)

>
> In revision 329128, org.apache.cocoon.forms.formmodel.GroupTestCase fails on 
> my macosx/JDK 1.4.2-38 system, the core problem seems to be "class 
> org.apache.cocoon.core.container.DefaultServiceSelector not found".
> testInheritance:
> Could not get class
> org.apache.avalon.framework.configuration.ConfigurationException: Could not 
> get class at 
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:458)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.setupManagers(ContainerTestCase.java:267)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:190)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:162)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.setUp(ContainerTestCase.java:146)Caused
>  by: java.lang.ClassNotFoundException: 
> org.apache.cocoon.core.container.DefaultServiceSelector at 
> java.net.URLClassLoader$1.run(URLClassLoader.java:199) at 
> java.security.AccessController.doPrivileged(Native Method) at 
> java.net.URLClassLoader.findClass(URLClassLoader.java:187) at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:289) at 
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:235) at 
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:444)
>  ... 14 more

-- 
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-1668) o.a.c.forms.formmodel.GroupTestCase fails

[Sylvain Wallez (JIRA)]

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

Sylvain Wallez updated COCOON-1668:
---

Version: 2.2-dev (Current SVN)
 (was: 2.1.8-dev (Current SVN))

Changing to version 2.2 as it's where it breaks now

> o.a.c.forms.formmodel.GroupTestCase fails
> -
>
>  Key: COCOON-1668
>  URL: http://issues.apache.org/jira/browse/COCOON-1668
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.2-dev (Current SVN)
> Reporter: Bertrand Delacretaz
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Fix For: 2.1.8-dev (Current SVN)

>
> In revision 329128, org.apache.cocoon.forms.formmodel.GroupTestCase fails on 
> my macosx/JDK 1.4.2-38 system, the core problem seems to be "class 
> org.apache.cocoon.core.container.DefaultServiceSelector not found".
> testInheritance:
> Could not get class
> org.apache.avalon.framework.configuration.ConfigurationException: Could not 
> get class at 
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:458)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.setupManagers(ContainerTestCase.java:267)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:190)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:162)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.setUp(ContainerTestCase.java:146)Caused
>  by: java.lang.ClassNotFoundException: 
> org.apache.cocoon.core.container.DefaultServiceSelector at 
> java.net.URLClassLoader$1.run(URLClassLoader.java:199) at 
> java.security.AccessController.doPrivileged(Native Method) at 
> java.net.URLClassLoader.findClass(URLClassLoader.java:187) at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:289) at 
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:235) at 
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:444)
>  ... 14 more

-- 
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-1669) o.a.c.jcr.source.JCRSourceTestCase fails

[Sylvain Wallez (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1669?page=all ]
 
Sylvain Wallez closed COCOON-1669:
--

Resolution: Fixed

Updated repository.xml (format has changed in newer jackrabbit) and guarded 
against a NPE as there's no request in the object model when running in a 
testcase

> o.a.c.jcr.source.JCRSourceTestCase fails
> 
>
>  Key: COCOON-1669
>  URL: http://issues.apache.org/jira/browse/COCOON-1669
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: JCR
> Versions: 2.1.8-dev (Current SVN)
> Reporter: Bertrand Delacretaz
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Fix For: 2.1.8-dev (Current SVN)

>
> All tests fail with "Cannot access configuration information at null:36:21" 
> on my macosx/JDK 1.4.2-38 system.
> Details: Cannot access configuration information at null:36:21
> org.apache.avalon.framework.configuration.ConfigurationException: Cannot 
> access configuration information at null:36:21 at 
> org.apache.cocoon.jcr.JackrabbitRepository.configure(JackrabbitRepository.java:98)
>  at 
> org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201)
>  at 
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:289)
>  at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.

-- 
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-1668) o.a.c.forms.formmodel.GroupTestCase fails

[Sylvain Wallez (JIRA)]

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

Sylvain Wallez commented on COCOON-1668:


Fixed in the 2.1 branch. However, we have a problem as there's no 
implementation of ServiceSelector that is common to both branches.

Maybe we should reintroduce ExtendedComponentSelector in 2.2 (and make it 
extend o.a.c.core.container.StandaloneServiceSelector) so that we can have 
multi-branch configurations?

> o.a.c.forms.formmodel.GroupTestCase fails
> -
>
>  Key: COCOON-1668
>  URL: http://issues.apache.org/jira/browse/COCOON-1668
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.1.8-dev (Current SVN)
> Reporter: Bertrand Delacretaz
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Fix For: 2.1.8-dev (Current SVN)

>
> In revision 329128, org.apache.cocoon.forms.formmodel.GroupTestCase fails on 
> my macosx/JDK 1.4.2-38 system, the core problem seems to be "class 
> org.apache.cocoon.core.container.DefaultServiceSelector not found".
> testInheritance:
> Could not get class
> org.apache.avalon.framework.configuration.ConfigurationException: Could not 
> get class at 
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:458)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.setupManagers(ContainerTestCase.java:267)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:190)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:162)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.setUp(ContainerTestCase.java:146)Caused
>  by: java.lang.ClassNotFoundException: 
> org.apache.cocoon.core.container.DefaultServiceSelector at 
> java.net.URLClassLoader$1.run(URLClassLoader.java:199) at 
> java.security.AccessController.doPrivileged(Native Method) at 
> java.net.URLClassLoader.findClass(URLClassLoader.java:187) at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:289) at 
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:235) at 
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:444)
>  ... 14 more

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

DO NOT REPLY [Bug 36810] - source that declares namespace fails JXPath/Linkrewriter/Input Modules

[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=36810


Bug 36810 depends on bug 32360, which changed state.

Bug 32360 Summary: [jxpath] Default Namespace not handled correctly
http://issues.apache.org/bugzilla/show_bug.cgi?id=32360

   What|Old Value   |New Value

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



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