[jira] Assigned: (COCOON-1425) Sessions that use Flowscript are not serializable

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz reassigned COCOON-1425:
--

Assign To: Cocoon Developers Team  (was: Reinhard Poetz)

I'm still convinced that  it is possible but the chance to get serializeable 
Javaflow states is much higher IMHO.

> Sessions that use Flowscript are not serializable
> -
>
>  Key: COCOON-1425
>  URL: http://issues.apache.org/jira/browse/COCOON-1425
>  Project: Cocoon
> Type: Bug
>   Components: - Flowscript
> Versions: 2.2-dev (Current SVN)
>  Environment: Operating System: All
> Platform: PC
> Reporter: Reinhard Poetz
> Assignee: Cocoon Developers Team

>
> The scopes of Flowscripts are  not serializable. The same is valid for the
> continuation objects. This requires a more sophisticated serialization 
> process.
> See http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication for details.

-- 
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-1271) Custom Binding

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-1271:
---

Bugzilla Id:   (was: 31303)
  Component: - Cocoon Forms
 (was: Blocks: (Undefined))
Description: 
In the forms binding frame work you can define a cutom binding class by 
extending org.apache.cocoon.forms.AbstractCustomBinding and implementing 
methods foLoad() and doSave().

This is nice but I think there is a little design issue in class 
org.apache.cocoon.forms.CustomJXPathBinding. Look at following case:

* Take a JavaBean with a other bean as property named test
* Make a custom binder that loads an sets this property from the JavaBean with 
implementation:

doLoad(Widget frmModel, JXPathContext jxpc) {
jxpc.setLenient(true);
Object aValue = jxpc.getValue(".");
jxpc.setLenient(false);
if(aValue != null)
frmModel.setValue(jxpc.getValue(".").toString());
}

doSave(Widget frmModel, JXPathContext jxpc) {
jxpc.setValue(".", LookupUtil.lookupValue(frmModel.getValue()));
}

and in binding xml:



This runs very well if test property isn't null. But is it is null an execption 
is throw before the code in MyCustomBinding is executed (in 
CustomJXPathBinding, line 68 on load, 83 on save) because relative context 
cannot be cerate for a null value!

So I changed the AbstractCustomBinding as like this:

protected abstract void doLoad(Widget frmModel, JXPathContext context, String 
path) throws BindingException;

protected abstract void doSave(Widget frmModel, JXPathContext context, String 
path) throws BindingException;

So I class the doXXX methods with parent context and the selection path, so it 
is possible to handle the null case in custom implementation.

Hope this will help some one in cocoon team (and thanks a lot for your good 
work).

  was:
In the forms binding frame work you can define a cutom binding class by 
extending org.apache.cocoon.forms.AbstractCustomBinding and implementing 
methods foLoad() and doSave().

This is nice but I think there is a little design issue in class 
org.apache.cocoon.forms.CustomJXPathBinding. Look at following case:

* Take a JavaBean with a other bean as property named test
* Make a custom binder that loads an sets this property from the JavaBean with 
implementation:

doLoad(Widget frmModel, JXPathContext jxpc) {
jxpc.setLenient(true);
Object aValue = jxpc.getValue(".");
jxpc.setLenient(false);
if(aValue != null)
frmModel.setValue(jxpc.getValue(".").toString());
}

doSave(Widget frmModel, JXPathContext jxpc) {
jxpc.setValue(".", LookupUtil.lookupValue(frmModel.getValue()));
}

and in binding xml:



This runs very well if test property isn't null. But is it is null an execption 
is throw before the code in MyCustomBinding is executed (in 
CustomJXPathBinding, line 68 on load, 83 on save) because relative context 
cannot be cerate for a null value!

So I changed the AbstractCustomBinding as like this:

protected abstract void doLoad(Widget frmModel, JXPathContext context, String 
path) throws BindingException;

protected abstract void doSave(Widget frmModel, JXPathContext context, String 
path) throws BindingException;

So I class the doXXX methods with parent context and the selection path, so it 
is possible to handle the null case in custom implementation.

Hope this will help some one in cocoon team (and thanks a lot for your good 
work).


> Custom Binding
> --
>
>  Key: COCOON-1271
>  URL: http://issues.apache.org/jira/browse/COCOON-1271
>  Project: Cocoon
> Type: Improvement
>   Components: - Cocoon Forms
> Versions: 2.1.5
>  Environment: Operating System: All
> Platform: All
> Reporter: Lucien Weller
> Assignee: Cocoon Developers Team
> Priority: Minor

>
> In the forms binding frame work you can define a cutom binding class by 
> extending org.apache.cocoon.forms.AbstractCustomBinding and implementing 
> methods foLoad() and doSave().
> This is nice but I think there is a little design issue in class 
> org.apache.cocoon.forms.CustomJXPathBinding. Look at following case:
> * Take a JavaBean with a other bean as property named test
> * Make a custom binder that loads an sets this property from the JavaBean 
> with 
> implementation:
> doLoad(Widget frmModel, JXPathContext jxpc) {
> jxpc.setLenient(true);
> Object aValue = jxpc.getValue(".");
> jxpc.setLenient(false);
> if(aValue != null)
> frmModel.setValue(jxpc.getValue(".").toString());
> }
> doSave(Widget frmModel, JXPathContext jxpc) {
> jxpc.setValue(".", LookupUtil.lookupValue(frmModel.getValue()));
> }
> and in binding xml:
> 
> This runs very well if test property isn't null. But is it is null an 
> execption 
> is throw before the code in MyCustomBinding is executed (in 
> CustomJXPathBinding, line 68 on load, 83 on save) because relative context 
> cannot be cerate for a null value!
> So I chang

[jira] Updated: (COCOON-1655) JavaFlow/CForm/select-list crash

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-1655:
---

Bugzilla Id:   (was: 37187)
  Component: Blocks: Java Flow
 (was: Blocks: (Undefined))
Description: 
I get an error whenever I include an  where
both the form and the XYZ pipeline use JavaFlow. The error is:

No continuation is running 
cause: java.lang.IllegalStateException: No continuation is running
java.lang.IllegalStateException: No continuation is running
at
org.apache.cocoon.components.flow.java.Continuation.suspend(Continuation.java:79)
at
org.apache.cocoon.components.flow.java.AbstractContinuable.sendPageAndWait(AbstractContinuable.java:75)
at 
org.apache.cocoon.forms.flow.java.FormInstance.show(FormInstance.java:181)

The reason is that when cocoon:/XYZ runs, a continuation is created for the same
thread as the form continuation. The continuationsmap in Continuation class gets
overwritten. When cocoon:/XYZ returns, the map is cleared for the thread,
leaving no continuation for the form.

Here's a bit of code from the app to help explain.

The form contains a selection list defined as:

   
   


The sitemap contains:

   


Then I have the following JavaFlow
public void doGenerateUserList() throws Exception {
   Collection userList = databaseManager.getUserList();
   sendPage("user_list", new VarMap().add("list", userList) );
}

  was:
I get an error whenever I include an  where
both the form and the XYZ pipeline use JavaFlow. The error is:

No continuation is running 
cause: java.lang.IllegalStateException: No continuation is running
java.lang.IllegalStateException: No continuation is running
at
org.apache.cocoon.components.flow.java.Continuation.suspend(Continuation.java:79)
at
org.apache.cocoon.components.flow.java.AbstractContinuable.sendPageAndWait(AbstractContinuable.java:75)
at 
org.apache.cocoon.forms.flow.java.FormInstance.show(FormInstance.java:181)

The reason is that when cocoon:/XYZ runs, a continuation is created for the same
thread as the form continuation. The continuationsmap in Continuation class gets
overwritten. When cocoon:/XYZ returns, the map is cleared for the thread,
leaving no continuation for the form.

Here's a bit of code from the app to help explain.

The form contains a selection list defined as:

   
   


The sitemap contains:

   


Then I have the following JavaFlow
public void doGenerateUserList() throws Exception {
   Collection userList = databaseManager.getUserList();
   sendPage("user_list", new VarMap().add("list", userList) );
}


> JavaFlow/CForm/select-list crash
> 
>
>  Key: COCOON-1655
>  URL: http://issues.apache.org/jira/browse/COCOON-1655
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Java Flow
> Versions: 2.1.7
>  Environment: Operating System: other
> Platform: Other
> Reporter: Benoit Deshaies
> Assignee: Cocoon Developers Team

>
> I get an error whenever I include an  
> where
> both the form and the XYZ pipeline use JavaFlow. The error is:
> No continuation is running 
> cause: java.lang.IllegalStateException: No continuation is running
> java.lang.IllegalStateException: No continuation is running
>   at
> org.apache.cocoon.components.flow.java.Continuation.suspend(Continuation.java:79)
>   at
> org.apache.cocoon.components.flow.java.AbstractContinuable.sendPageAndWait(AbstractContinuable.java:75)
>   at 
> org.apache.cocoon.forms.flow.java.FormInstance.show(FormInstance.java:181)
> The reason is that when cocoon:/XYZ runs, a continuation is created for the 
> same
> thread as the form continuation. The continuationsmap in Continuation class 
> gets
> overwritten. When cocoon:/XYZ returns, the map is cleared for the thread,
> leaving no continuation for the form.
> Here's a bit of code from the app to help explain.
> The form contains a selection list defined as:
> 
>
>
> 
> The sitemap contains:
> 
>
> 
> Then I have the following JavaFlow
> public void doGenerateUserList() throws Exception {
>Collection userList = databaseManager.getUserList();
>sendPage("user_list", new VarMap().add("list", userList) );
> }

-- 
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-1147) [PATCH] namespace issues with XMLDBTransformer

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-1147:
---

Bugzilla Id:   (was: 28723)
  Component: Blocks: XML-DB
 (was: Blocks: (Undefined))
Description: 
Just clearing some of my mails.

Some issues were reported according to namespaces with xmldb components:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107908325225663&w=4
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108246750812702&w=4
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108251828604092&w=4
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108305770827148&w=4

  was:
Just clearing some of my mails.

Some issues were reported according to namespaces with xmldb components:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107908325225663&w=4
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108246750812702&w=4
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108251828604092&w=4
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108305770827148&w=4


> [PATCH] namespace issues with XMLDBTransformer
> --
>
>  Key: COCOON-1147
>  URL: http://issues.apache.org/jira/browse/COCOON-1147
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XML-DB
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jörg Heinicke
> Assignee: Cocoon Developers Team
>  Attachments: browser output.txt, qeury result.txt, qeury result.txt, 
> serializer.patch, sitemap.xmap
>
> Just clearing some of my mails.
> Some issues were reported according to namespaces with xmldb components:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107908325225663&w=4
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108246750812702&w=4
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108251828604092&w=4
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108305770827148&w=4

-- 
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-1273) Event-aware cache: registry persistence at shutdown fails (StoreEventRegistryImpl)

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-1273:
---

Bugzilla Id:   (was: 31326)
  Component: Blocks: Event Cache
 (was: Blocks: (Undefined))
Description: 
Related to bug #23585

Event registry persistence (using StoreEventRegistryImpl) to the default JCS 
cache when tomcat shuts down fails. I get the following stack trace in the 
logs:

WARN(2004-09-21) 12:28.53:455   [core.manager] (Unknown-URI) Unknown-
thread/ExcaliburComponentManager: disposing of handler for unreleased 
component. role [org.apache.cocoon.caching.EventRegistry]
DEBUG   (2004-09-21) 12:28.53:455   [core.manager] (Unknown-URI) Unknown-
thread/DefaultComponentFactory: ComponentFactory decommissioning instance of 
org.apache.cocoon.caching.impl.StoreEventRegistryImpl.
DEBUG   (2004-09-21) 12:28.53:458   [core.store] (Unknown-URI) Unknown-
thread/JCSDefaultStore: Store object 
[EMAIL PROTECTED] with key 
EVENTREGWRAPPER
WARN(2004-09-21) 12:28.53:459   [core.manager] (Unknown-URI) Unknown-
thread/ThreadSafeComponentHandler: Error decommissioning component: 
org.apache.cocoon.caching.impl.StoreEventRegistryImpl
java.lang.NullPointerException
at org.apache.cocoon.components.store.impl.JCSDefaultStore.store
(JCSDefaultStore.java:276)
at org.apache.cocoon.caching.impl.StoreEventRegistryImpl.persist
(StoreEventRegistryImpl.java:44)
at 
org.apache.cocoon.caching.impl.AbstractDoubleMapEventRegistry.dispose
(AbstractDoubleMapEventRegistry.java:154)
at org.apache.avalon.framework.container.ContainerUtil.dispose
(ContainerUtil.java:345)
at 
org.apache.avalon.excalibur.component.DefaultComponentFactory.decommission
(DefaultComponentFactory.java:336)
at 
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.dispose
(ThreadSafeComponentHandler.java:165)
at 
org.apache.avalon.excalibur.component.ExcaliburComponentManager.dispose
(ExcaliburComponentManager.java:621)
at org.apache.cocoon.components.CocoonComponentManager.dispose
(CocoonComponentManager.java:468)
at org.apache.avalon.framework.container.ContainerUtil.dispose
(ContainerUtil.java:345)
at org.apache.cocoon.Cocoon.dispose(Cocoon.java:499)
at org.apache.avalon.framework.container.ContainerUtil.dispose
(ContainerUtil.java:345)
at org.apache.cocoon.servlet.CocoonServlet.disposeCocoon
(CocoonServlet.java:1488)
at org.apache.cocoon.servlet.CocoonServlet.destroy
(CocoonServlet.java:498)
at org.apache.catalina.core.StandardWrapper.unload
(StandardWrapper.java:1270)
at org.apache.catalina.core.StandardWrapper.stop
(StandardWrapper.java:1595)
at org.apache.catalina.core.ContainerBase.removeChild
(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.removeChild
(StandardContext.java:3094)
at org.apache.catalina.startup.ContextConfig.stop
(ContextConfig.java:693)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent
(ContextConfig.java:255)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:166)
at org.apache.catalina.core.StandardContext.stop
(StandardContext.java:4443)
at org.apache.catalina.core.ContainerBase.removeChild
(ContainerBase.java:995)
at org.apache.catalina.core.StandardHostDeployer.remove
(StandardHostDeployer.java:606)
at org.apache.catalina.core.StandardHost.remove(StandardHost.java:955)
at org.apache.catalina.startup.HostConfig.undeployApps
(HostConfig.java:1053)
at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1030)
at org.apache.catalina.startup.HostConfig.lifecycleEvent
(HostConfig.java:396)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:166)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1166)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1178)
at org.apache.catalina.core.StandardEngine.stop
(StandardEngine.java:526)
at org.apache.catalina.core.StandardService.stop
(StandardService.java:581)
at org.apache.catalina.core.StandardServer.stop
(StandardServer.java:2379)
at org.apache.catalina.startup.Catalina.stop(Catalina.java:643)
at org.apache.catalina.startup.Catalina.start(Catalina.java:618)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:297)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:398)

I added some debug and confirmed that it is the JCSCacheAccess member 
vari

[jira] Updated: (COCOON-611) Context and Session -input modules not working with Modular Database Actions

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-611:
--

Bugzilla Id:   (was: 28975)
  Component: Blocks: Databases
 (was: Blocks: (Undefined))
Description: 
When pulling data from session-context for saving it in a database, one needs 
to write something like this in the db descriptor file:


  
authentication/authentication/ID
  


All that gets saved in db is NULL, even if the session
context has data. This happens with the SessionInputModule too!

  was:
When pulling data from session-context for saving it in a database, one needs 
to write something like this in the db descriptor file:


  
authentication/authentication/ID
  


All that gets saved in db is NULL, even if the session
context has data. This happens with the SessionInputModule too!


> Context and Session -input modules not working with Modular Database Actions
> 
>
>  Key: COCOON-611
>  URL: http://issues.apache.org/jira/browse/COCOON-611
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Databases
> Versions: 2.1.4
>  Environment: Operating System: All
> Platform: PC
> Reporter: Tuomo Lesonen
> Assignee: Cocoon Developers Team

>
> When pulling data from session-context for saving it in a database, one needs 
> to write something like this in the db descriptor file:
> 
>   
> authentication/authentication/ID
>   
> 
> All that gets saved in db is NULL, even if the session
> context has data. This happens with the SessionInputModule too!

-- 
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-1593) Redirect-to URI for Authentication Handler does not resolve variables on WebSphere

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-1593:
---

Bugzilla Id:   (was: 36543)
  Component: Blocks: Authentication Framework
 (was: Blocks: (Undefined))
Description: 
Variable resolution does not occur on the redirect-to uri of the 
authentication handler when deployed under WebSphere Application Server 6.  I 
have heard similar reports for other versions of WebSphere as well.  I have 
deployed this same sitemap using Tomcat 5 and it works successfully.  I have 
also tried switching from a request variable to a global variable as well as 
the {sitemap-path:} variable, but none of these are resolved.  The resulting 
uri when run on WebSphere is http://localhost/cocoon/{request:requestURIlogin

  

  

  
  
  

  

  

  was:
Variable resolution does not occur on the redirect-to uri of the 
authentication handler when deployed under WebSphere Application Server 6.  I 
have heard similar reports for other versions of WebSphere as well.  I have 
deployed this same sitemap using Tomcat 5 and it works successfully.  I have 
also tried switching from a request variable to a global variable as well as 
the {sitemap-path:} variable, but none of these are resolved.  The resulting 
uri when run on WebSphere is http://localhost/cocoon/{request:requestURIlogin

  

  

  
  
  

  

  


> Redirect-to URI for Authentication Handler does not resolve variables on 
> WebSphere
> --
>
>  Key: COCOON-1593
>  URL: http://issues.apache.org/jira/browse/COCOON-1593
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Authentication Framework
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Dave Thomas
> Assignee: Cocoon Developers Team

>
> Variable resolution does not occur on the redirect-to uri of the 
> authentication handler when deployed under WebSphere Application Server 6.  I 
> have heard similar reports for other versions of WebSphere as well.  I have 
> deployed this same sitemap using Tomcat 5 and it works successfully.  I have 
> also tried switching from a request variable to a global variable as well as 
> the {sitemap-path:} variable, but none of these are resolved.  The resulting 
> uri when run on WebSphere is http://localhost/cocoon/{request:requestURIlogin
>   
> 
>   
> 
>   
>   
>   
> 
>   
> 
>   

-- 
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-1417) Jx:set type ??? (JXTemplate Bug List)

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-1417:
---

Bugzilla Id:   (was: 33236)
  Component: Blocks: Templating
 (was: Blocks: (Undefined))
Description: 
   
   
  
   
returns true or false according to the existence of the ID, so far so good 
OTH   
 returns always true , bug???

  was:
   
   
  
   
returns true or false according to the existence of the ID, so far so good 
OTH   
 returns always true , bug???


> Jx:set type ??? (JXTemplate Bug List)
> -
>
>  Key: COCOON-1417
>  URL: http://issues.apache.org/jira/browse/COCOON-1417
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Templating
> Versions: 2.2-dev (Current SVN)
>  Environment: Operating System: Linux
> Platform: All
> Reporter: Tibor Katelbach
> Assignee: Cocoon Developers Team

>
>  value="${session.getAttribute('my_key/authentication')}"/>   
>
>   
>
> returns true or false according to the existence of the ID, so far so good 
> OTH   
>  returns always true , bug???

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

Closed but unresolved issues

[Reinhard Poetz]

We have 79 closed but unresolved issues in Jira. This is a problem as they show 
up in all queries (eg the project page) and gives a wrong picture of open issues.


Is there any faster possibility to change this but to reopen every issue, change 
the resolution state and close it?


--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[jira] Closed: (COCOON-907) Move Woody into CocoonForms block

[Reinhard Poetz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-907?page=all ]
 
Reinhard Poetz closed COCOON-907:
-

Resolution: Fixed

just a test

> Move Woody into CocoonForms block
> -
>
>  Key: COCOON-907
>  URL: http://issues.apache.org/jira/browse/COCOON-907
>  Project: Cocoon
> Type: Improvement
>   Components: - Cocoon Forms
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: andrew
> Assignee: Reinhard Poetz
> Priority: Minor
>  Attachments: woody2cforms.xsl
>
> Rename all packages, namespaces and namespace-prefixes.
> (This is also a test of the "voting" facility in bugzilla)

-- 
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] Reopened: (COCOON-907) Move Woody into CocoonForms block

[Reinhard Poetz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-907?page=all ]
 
Reinhard Poetz reopened COCOON-907:
---


just a test

> Move Woody into CocoonForms block
> -
>
>  Key: COCOON-907
>  URL: http://issues.apache.org/jira/browse/COCOON-907
>  Project: Cocoon
> Type: Improvement
>   Components: - Cocoon Forms
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: andrew
> Assignee: Reinhard Poetz
> Priority: Minor
>  Attachments: woody2cforms.xsl
>
> Rename all packages, namespaces and namespace-prefixes.
> (This is also a test of the "voting" facility in bugzilla)

-- 
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] Reopened: (COCOON-907) Move Woody into CocoonForms block

[Reinhard Poetz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-907?page=all ]
 
Reinhard Poetz reopened COCOON-907:
---


... just a test

> Move Woody into CocoonForms block
> -
>
>  Key: COCOON-907
>  URL: http://issues.apache.org/jira/browse/COCOON-907
>  Project: Cocoon
> Type: Improvement
>   Components: - Cocoon Forms
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: andrew
> Assignee: Reinhard Poetz
> Priority: Minor
>  Attachments: woody2cforms.xsl
>
> Rename all packages, namespaces and namespace-prefixes.
> (This is also a test of the "voting" facility in bugzilla)

-- 
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-907) Move Woody into CocoonForms block

[Reinhard Poetz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-907?page=all ]
 
Reinhard Poetz closed COCOON-907:
-

Resolution: Fixed

just a test

> Move Woody into CocoonForms block
> -
>
>  Key: COCOON-907
>  URL: http://issues.apache.org/jira/browse/COCOON-907
>  Project: Cocoon
> Type: Improvement
>   Components: - Cocoon Forms
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: andrew
> Assignee: Reinhard Poetz
> Priority: Minor
>  Attachments: woody2cforms.xsl
>
> Rename all packages, namespaces and namespace-prefixes.
> (This is also a test of the "voting" facility in bugzilla)

-- 
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-350) ESQL doesn't support namespaces

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-350:
--

Bugzilla Id:   (was: 10827)
  Component: Blocks: XSP
 (was: * Cocoon Core)
Description: 
If the  ESQL tag is used inside of a namespace context, The root and
child nodes do not have a namespace associated with them. ESQL should allow the
inheritance of current xmlns declarations and apply those declarations to the
XML content read from the database. Perhaps a special syntax can be used to
specify the namespace definitions for elements within the database entry as 
well.

This document will reproduce the problem:



http://apache.org/xsp";
  xmlns:esql="http://apache.org/cocoon/SQL/v2";
  xmlns="http://sterling.hanenkamp.com/bugzilla";
  create-session="true">




  somepool
  

  select *
  from sometable



  

  This is in a namespace
  

  

  






A hack I have created to work around the problem is to modify
org/apache/cocoon/components/language/markup/xsp/java/esql.xsl:


992a993,997
>   
>xmlns=\"
>   
>   \"
>   

This allows me to specify a namespace for the root node which suffices for my
purposes. A more comprehensive solution is probably necessary.

A better solution would probably involve treating the database entry as an XML
fragment instead of a complete self-contained document.

  was:
If the  ESQL tag is used inside of a namespace context, The root and
child nodes do not have a namespace associated with them. ESQL should allow the
inheritance of current xmlns declarations and apply those declarations to the
XML content read from the database. Perhaps a special syntax can be used to
specify the namespace definitions for elements within the database entry as 
well.

This document will reproduce the problem:



http://apache.org/xsp";
  xmlns:esql="http://apache.org/cocoon/SQL/v2";
  xmlns="http://sterling.hanenkamp.com/bugzilla";
  create-session="true">




  somepool
  

  select *
  from sometable



  

  This is in a namespace
  

  

  






A hack I have created to work around the problem is to modify
org/apache/cocoon/components/language/markup/xsp/java/esql.xsl:


992a993,997
>   
>xmlns=\"
>   
>   \"
>   

This allows me to specify a namespace for the root node which suffices for my
purposes. A more comprehensive solution is probably necessary.

A better solution would probably involve treating the database entry as an XML
fragment instead of a complete self-contained document.


> ESQL  doesn't support namespaces
> --
>
>  Key: COCOON-350
>  URL: http://issues.apache.org/jira/browse/COCOON-350
>  Project: Cocoon
> Type: Improvement
>   Components: Blocks: XSP
> Versions: 2.0.2
>  Environment: Operating System: Linux
> Platform: PC
> Reporter: sterling
> Assignee: Cocoon Developers Team
> Priority: Minor

>
> If the  ESQL tag is used inside of a namespace context, The root and
> child nodes do not have a namespace associated with them. ESQL should allow 
> the
> inheritance of current xmlns declarations and apply those declarations to the
> XML content read from the database. Perhaps a special syntax can be used to
> specify the namespace definitions for elements within the database entry as 
> well.
> This document will reproduce the problem:
> 
> http://apache.org/xsp";
>   xmlns:esql="http://apache.org/cocoon/SQL/v2";
>   xmlns="http://sterling.hanenkamp.com/bugzilla";
>   create-session="true">
> 
> 
>   somepool
>   
> 
>   select *
>   from sometable
> 
> 
>   
> 
>   This is in a namespace
>   
> 
>   
> 
>   
> 
> 
> 
> A hack I have created to work around the problem is to modify
> org/apache/cocoon/components/language/markup/xsp/java/esql.xsl:
> 992a993,997
> >   
> >xmlns=\"
> >   
> >   \"
> >   
> This allows me to specify a namespace for the root node which suffices for my
> purposes. A more comprehensive solution is probably necessary.
> A better solution would probably involve treating the database entry as an XML
> fragment instead of a complete self-contained document.

-- 
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-1657) VelocityGenerator: error when sending string containing ampersand

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-1657:
---

Component: Blocks: Velocity
   (was: * Cocoon Core)

> VelocityGenerator: error when sending string containing ampersand
> -
>
>  Key: COCOON-1657
>  URL: http://issues.apache.org/jira/browse/COCOON-1657
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Velocity
> Versions: 2.1.7
> Reporter: Andreas Deininger

>
> Take this flowscript:
>  function velotest() {
> cocoon.sendPage("abstract.vm", { "test" : "vm&vm" } );
>   }
> With abstract.vm being an velocity template processed by the Velocity 
> Generator:
> 
> $test
> You receive the following error, due to the occurence of the
> ampersand-sign in the "vm&vm" string::
> An Error Occurred: The reference to entity "vm" must end with the ';' 
> delimiter.
> This seems to be due to the fact that the sent value is not escaped, i.e. & 
> remains & and does not get converted to & in the resulting XML.

-- 
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-1416) JXTemplate Bug List(For Refactoring info)

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-1416:
---

Bugzilla Id:   (was: 33234)
  Component: Blocks: Templating
 (was: Blocks: (Undefined))
Description: 
The any string 
${myvar} will be empty when used. 
 
hack is to pass by jx:macros

  was:
The any string 
${myvar} will be empty when used. 
 
hack is to pass by jx:macros


> JXTemplate Bug List(For Refactoring info)
> -
>
>  Key: COCOON-1416
>  URL: http://issues.apache.org/jira/browse/COCOON-1416
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Templating
> Versions: 2.2-dev (Current SVN)
>  Environment: Operating System: Linux
> Platform: Other
> Reporter: Tibor Katelbach
> Assignee: Cocoon Developers Team

>
> The any string 
> ${myvar} will be empty when used. 
>  
> hack is to pass by jx:macros

-- 
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-1483) New flowscript API Example

[Reinhard Poetz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1483?page=all ]
 
Reinhard Poetz closed COCOON-1483:
--

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

works for me now, I guess Sylvain's refactoring fixed this bug

> New flowscript API Example
> --
>
>  Key: COCOON-1483
>  URL: http://issues.apache.org/jira/browse/COCOON-1483
>  Project: Cocoon
> Type: Bug
>   Components: - Cocoon Forms
> Versions: 2.1.6
>  Environment: Operating System: Linux
> Platform: Other
> Reporter: Hugo Marcelino
> Assignee: Cocoon Developers Team
>  Fix For: 2.2-dev (Current SVN), 2.1.8-dev (Current SVN)

>
> Hi ! 
> My name is Hugo Marcelino and i'm here to report a bug that i've found in
> version Cocoon 2.1.6.
> If you select the sample provided for the new flowscript API example and press
> the commit button you will get the car Selector sample. 
> The problem is that the fields are not changing on event (onChange) and in the
> flowscript i can't know the oldValue and the newValue, but in version 2.1.5.1
> this sample  worked.
> (Basicaly the sample doesn't work.) 
> I've tried to solve but i couldn't get it worked.
> Could you solve this problem ?
> Thank you in advance.
> Hugo.
> 22-03-2005

-- 
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-1526) [PATCH] processToDOM returns a read-only DOM

[Reinhard Poetz (JIRA)]

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

Reinhard Poetz updated COCOON-1526:
---

Bugzilla Id:   (was: 35273)
  Component: * Cocoon Core
 (was: - Components: Avalon)
Description: 
When Saxon is the active XSLT processor, using the zero-argument constructor to 
DOMResult results in a read-only DOM being produced.  This, in turn, means that 
a call to PipelineUtil.processToDOM() always returns a read-only DOM.  The 
attached patch adds overloaded versions of PipelineUtil.processToDOM() and 
SourceUtil.toDOM() to allow the user to pass in an explicit Node object to be 
passed to DOMResult (via DOMBuilder).

  was:
When Saxon is the active XSLT processor, using the zero-argument constructor to 
DOMResult results in a read-only DOM being produced.  This, in turn, means that 
a call to PipelineUtil.processToDOM() always returns a read-only DOM.  The 
attached patch adds overloaded versions of PipelineUtil.processToDOM() and 
SourceUtil.toDOM() to allow the user to pass in an explicit Node object to be 
passed to DOMResult (via DOMBuilder).


> [PATCH] processToDOM returns a read-only DOM
> 
>
>  Key: COCOON-1526
>  URL: http://issues.apache.org/jira/browse/COCOON-1526
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.7
>  Environment: Operating System: All
> Platform: All
> Reporter: Jeffrey Kirby
> Assignee: Cocoon Developers Team
>  Attachments: PipelineUtil.java.diff, SourceUtil.java.diff, utils.patch
>
> When Saxon is the active XSLT processor, using the zero-argument constructor 
> to 
> DOMResult results in a read-only DOM being produced.  This, in turn, means 
> that 
> a call to PipelineUtil.processToDOM() always returns a read-only DOM.  The 
> attached patch adds overloaded versions of PipelineUtil.processToDOM() and 
> SourceUtil.toDOM() to allow the user to pass in an explicit Node object to be 
> passed to DOMResult (via DOMBuilder).

-- 
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-928) [Roadmap] Flowscript - FUTURE releases

[Reinhard Poetz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-928?page=all ]
 
Reinhard Poetz closed COCOON-928:
-

Resolution: Fixed

collection roadmap issues are not needed any more

> [Roadmap] Flowscript - FUTURE releases
> --
>
>  Key: COCOON-928
>  URL: http://issues.apache.org/jira/browse/COCOON-928
>  Project: Cocoon
> Type: Improvement
>   Components: - Flowscript
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Reinhard Poetz
> Assignee: Cocoon Developers Team
> Priority: Minor

>
> This is a grouping entry that enables an easy lookup of all open enhancement
> requests which should be available in a future release of Cocoon.

-- 
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-970) [Roadmap] General - FUTURE releases

[Reinhard Poetz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-970?page=all ]
 
Reinhard Poetz closed COCOON-970:
-

Resolution: Fixed

roadmap tasks are not necessary any more

> [Roadmap] General - FUTURE releases
> ---
>
>  Key: COCOON-970
>  URL: http://issues.apache.org/jira/browse/COCOON-970
>  Project: Cocoon
> Type: Improvement
>   Components: - Components: Avalon
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Reinhard Poetz
> Assignee: Cocoon Developers Team
> Priority: Minor

>
> Collection issue for all general issues which are not urgent (so that we
> remember them in the future)

-- 
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-965) [Roadmap] Cocoon - FUTURE releases

[Reinhard Poetz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-965?page=all ]
 
Reinhard Poetz closed COCOON-965:
-

Resolution: Fixed

roadmap tasks are not necessary any more

> [Roadmap] Cocoon - FUTURE releases
> --
>
>  Key: COCOON-965
>  URL: http://issues.apache.org/jira/browse/COCOON-965
>  Project: Cocoon
> Type: Improvement
>   Components: * Cocoon Core
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Reinhard Poetz
> Assignee: Cocoon Developers Team
> Priority: Minor

>
> Collection issue for all issues which are part of FUTURE releases (so that we
> remember them in the future)

-- 
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-963) [Roadmap] Cocoon

[Reinhard Poetz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-963?page=all ]
 
Reinhard Poetz closed COCOON-963:
-

Resolution: Fixed

roadmap tasks are not necessary any more

> [Roadmap] Cocoon
> 
>
>  Key: COCOON-963
>  URL: http://issues.apache.org/jira/browse/COCOON-963
>  Project: Cocoon
> Type: Improvement
>   Components: * Cocoon Core
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Reinhard Poetz
> Assignee: Cocoon Developers Team
> Priority: Minor

>
> Collection issue for all issues which are part of our official release plan.

-- 
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-1066) [PATCH] LDAPTransformer enhancements

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1066:


Bugzilla Id:   (was: 27279)
  Component: Blocks: Naming
 (was: Blocks: (Undefined))
Description: 
This patch addresses 2 issues through the addition of 2 elements in the
LDAPTransformer (LDAPTransformer.java):

dn-element:
Provide element containing the DN for each entry returned in 'execute-query'. 
This is accomplished via 'dn-element' element that defaults to 'dn'.  This
element is only valid in 'execute-query'.

securityprotocol:
Provide a mechanism for those using JDK prior to 1.4.2 to access LDAP via SSL. 
This is accomplished via an optional 'securityprotocol' element that is empty
(unused) by default.  Please see
http://java.sun.com/products/jndi/tutorial/ldap/security/ssl.html for more
information on the JDK differences WRT LDAP via SSL.

  was:
This patch addresses 2 issues through the addition of 2 elements in the
LDAPTransformer (LDAPTransformer.java):

dn-element:
Provide element containing the DN for each entry returned in 'execute-query'. 
This is accomplished via 'dn-element' element that defaults to 'dn'.  This
element is only valid in 'execute-query'.

securityprotocol:
Provide a mechanism for those using JDK prior to 1.4.2 to access LDAP via SSL. 
This is accomplished via an optional 'securityprotocol' element that is empty
(unused) by default.  Please see
http://java.sun.com/products/jndi/tutorial/ldap/security/ssl.html for more
information on the JDK differences WRT LDAP via SSL.


> [PATCH] LDAPTransformer enhancements
> 
>
>  Key: COCOON-1066
>  URL: http://issues.apache.org/jira/browse/COCOON-1066
>  Project: Cocoon
> Type: Improvement
>   Components: Blocks: Naming
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: All
> Reporter: David L. Day
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Attachments: LDAPTransformer.java.diff
>
> This patch addresses 2 issues through the addition of 2 elements in the
> LDAPTransformer (LDAPTransformer.java):
> dn-element:
> Provide element containing the DN for each entry returned in 'execute-query'. 
> This is accomplished via 'dn-element' element that defaults to 'dn'.  This
> element is only valid in 'execute-query'.
> securityprotocol:
> Provide a mechanism for those using JDK prior to 1.4.2 to access LDAP via 
> SSL. 
> This is accomplished via an optional 'securityprotocol' element that is empty
> (unused) by default.  Please see
> http://java.sun.com/products/jndi/tutorial/ldap/security/ssl.html for more
> information on the JDK differences WRT LDAP via SSL.

-- 
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-806) [PATCH]: HSSF Serializer does not process

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-806:
---

Bugzilla Id:   (was: 23002)
  Component: Blocks: POI
 (was: Blocks: (Undefined))
Description: 
The  element is where we configure all the info related to
print configuration of the stylesheet generated. For example: landscape
orientation, papelsize, margins, etc. Currenlty the HSSF Serializer is ignoring
all the info the user send.

Here is a example of the element:




















r_then_d
landscape


A4


  was:
The  element is where we configure all the info related to
print configuration of the stylesheet generated. For example: landscape
orientation, papelsize, margins, etc. Currenlty the HSSF Serializer is ignoring
all the info the user send.

Here is a example of the element:




















r_then_d
landscape


A4



> [PATCH]: HSSF Serializer does not process 
> 
>
>  Key: COCOON-806
>  URL: http://issues.apache.org/jira/browse/COCOON-806
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: POI
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: All
> Reporter: Antonio Gallardo
> Assignee: Cocoon Developers Team
>  Attachments: EP_Grid.java.diff, EP_Orientation.java.diff, 
> EP_Paper.java.diff, Sheet.java.diff
>
> The  element is where we configure all the info related 
> to
> print configuration of the stylesheet generated. For example: landscape
> orientation, papelsize, margins, etc. Currenlty the HSSF Serializer is 
> ignoring
> all the info the user send.
> Here is a example of the element:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> r_then_d
> landscape
> 
> 
> A4
> 

-- 
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-1123) Patch for WebDAV block concerning locking and state.

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1123:


Bugzilla Id:   (was: 28311)
  Component: Blocks: WebDAV
 (was: Blocks: (Undefined))
Description: 
This patch integrates a new feature of apaches webdavclient from  Slide2RC2.
See http://marc.theaimsgroup.com/?l=slide-dev&m=108057214410350&w=2 .

Now it is possible to loack files/collections and still operate on them
independant of the session.

  was:
This patch integrates a new feature of apaches webdavclient from  Slide2RC2.
See http://marc.theaimsgroup.com/?l=slide-dev&m=108057214410350&w=2 .

Now it is possible to loack files/collections and still operate on them
independant of the session.


> Patch for WebDAV block concerning locking and state.
> 
>
>  Key: COCOON-1123
>  URL: http://issues.apache.org/jira/browse/COCOON-1123
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: WebDAV
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: All
> Reporter: Rolf Kulemann
> Assignee: Cocoon Developers Team
>  Attachments: WebDAVUtil_locking.patch
>
> This patch integrates a new feature of apaches webdavclient from  Slide2RC2.
> See http://marc.theaimsgroup.com/?l=slide-dev&m=108057214410350&w=2 .
> Now it is possible to loack files/collections and still operate on them
> independant of the session.

-- 
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-1116) Fix for WebDAVRepository*

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1116:


Bugzilla Id:   (was: 28189)
  Component: Blocks: WebDAV
 (was: Blocks: (Undefined))
Description: 
Fixes an obvious copy n paste error in createResource(String, String).

Would it be ok to commit those changes direct to cvs?

  was:
Fixes an obvious copy n paste error in createResource(String, String).

Would it be ok to commit those changes direct to cvs?


> Fix for WebDAVRepository*
> -
>
>  Key: COCOON-1116
>  URL: http://issues.apache.org/jira/browse/COCOON-1116
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: WebDAV
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: All
> Reporter: Rolf Kulemann
> Assignee: Cocoon Developers Team
>  Attachments: WebDAVRepositoryVersioningHelper_patch.txt, 
> WebDAVRepository_patch.txt, WebDAVRepository_patch.txt, WebDAVUtil_patch.txt
>
> Fixes an obvious copy n paste error in createResource(String, String).
> Would it be ok to commit those changes direct to cvs?

-- 
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-1182) [PATCH] Writing an XMLDBSource through the SourceWritingTransformer does not use user and password.

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1182:


Bugzilla Id:   (was: 29524)
  Component: Blocks: XML-DB
 (was: Blocks: (Undefined))
Description: 
Hi,

I was trying to write an document to an eXist database using the 
WritingSourceTransformer when I figure out that the user and password 
defined in cocoon.xconf at:





were not used.

the XML used to store the document is like :


xmldb:exist://localhost:8080/exist/xmlrpc/db/test.xml

pim pam pom



The XMLDBSourceFactory get user and password from cocoon.xconf and use them to
create an XMLDBSource but two methods of this class doesn't handle credentials
when accessing database : writeOutputStream() and delete().
the call to :
DatabaseManager.getCollection(base);
is used instead of :
DatabaseManager.getCollection(base, user, password) ;

  was:
Hi,

I was trying to write an document to an eXist database using the 
WritingSourceTransformer when I figure out that the user and password 
defined in cocoon.xconf at:





were not used.

the XML used to store the document is like :


xmldb:exist://localhost:8080/exist/xmlrpc/db/test.xml

pim pam pom



The XMLDBSourceFactory get user and password from cocoon.xconf and use them to
create an XMLDBSource but two methods of this class doesn't handle credentials
when accessing database : writeOutputStream() and delete().
the call to :
DatabaseManager.getCollection(base);
is used instead of :
DatabaseManager.getCollection(base, user, password) ;


> [PATCH] Writing an XMLDBSource through the SourceWritingTransformer does not 
> use user and password.
> ---
>
>  Key: COCOON-1182
>  URL: http://issues.apache.org/jira/browse/COCOON-1182
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XML-DB
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Gildas Guillemot
> Assignee: Cocoon Developers Team
>  Attachments: XMLDBSource.diff
>
> Hi,
> I was trying to write an document to an eXist database using the 
> WritingSourceTransformer when I figure out that the user and password 
> defined in cocoon.xconf at:
>  class="org.apache.cocoon.components.source.impl.XMLDBSourceFactory" 
> name="xmldb">
>  password="password"/>
> 
> were not used.
> the XML used to store the document is like :
> 
> xmldb:exist://localhost:8080/exist/xmlrpc/db/test.xml
> 
> pim pam pom
> 
> 
> The XMLDBSourceFactory get user and password from cocoon.xconf and use them to
> create an XMLDBSource but two methods of this class doesn't handle credentials
> when accessing database : writeOutputStream() and delete().
> the call to :
> DatabaseManager.getCollection(base);
> is used instead of :
> DatabaseManager.getCollection(base, user, password) ;

-- 
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-1165) XMLDBSource: default character encoding

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1165:


Bugzilla Id:   (was: 29061)
  Component: Blocks: XML-DB
 (was: Blocks: (Undefined))
Description: 
The org.apache.cocoon.components.source.impl.XMLDBSource.XMLDBOutputStream.close
() method uses the java.io.ByteArrayOutputStream.toString() method to translate
 bytes into characters. IMO, it should use the
java.io.ByteArrayOutputStream.toString(String encoding) method to prevent
corruption of non-us data. At the same time, there should be an XMLDBSource
class property that would set the encoding. If it is not set the
java.io.ByteArrayOutputStream.toString() method should still be used.

Please,see
http://archives.real-time.com/pipermail/cocoon-users/2004-May/051561.html for
more info.

Good luck!

  was:
The org.apache.cocoon.components.source.impl.XMLDBSource.XMLDBOutputStream.close
() method uses the java.io.ByteArrayOutputStream.toString() method to translate
 bytes into characters. IMO, it should use the
java.io.ByteArrayOutputStream.toString(String encoding) method to prevent
corruption of non-us data. At the same time, there should be an XMLDBSource
class property that would set the encoding. If it is not set the
java.io.ByteArrayOutputStream.toString() method should still be used.

Please,see
http://archives.real-time.com/pipermail/cocoon-users/2004-May/051561.html for
more info.

Good luck!


> XMLDBSource: default character encoding
> ---
>
>  Key: COCOON-1165
>  URL: http://issues.apache.org/jira/browse/COCOON-1165
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XML-DB
> Versions: 2.1.4
>  Environment: Operating System: All
> Platform: PC
> Reporter: Timur Izhbulatov
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Attachments: XMLDBSource.java.diff, XMLDBSource.java.patch, test.txt
>
> The 
> org.apache.cocoon.components.source.impl.XMLDBSource.XMLDBOutputStream.close
> () method uses the java.io.ByteArrayOutputStream.toString() method to 
> translate
>  bytes into characters. IMO, it should use the
> java.io.ByteArrayOutputStream.toString(String encoding) method to prevent
> corruption of non-us data. At the same time, there should be an XMLDBSource
> class property that would set the encoding. If it is not set the
> java.io.ByteArrayOutputStream.toString() method should still be used.
> Please,see
> http://archives.real-time.com/pipermail/cocoon-users/2004-May/051561.html for
> more info.
> Good luck!

-- 
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-1243) [PATCH] null pointer exception in XMLDB transformer

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1243:


Bugzilla Id:   (was: 30849)
  Component: Blocks: XML-DB
 (was: Blocks: (Undefined))
Description: 
The code assumes that DatabaseManager.getCollection raises an XMLDBException for
errors, but in fact in at least some cases (non-existent collection), it returns
null.

The patch reworks the error checking to explicitly raise an exception for this 
case.

  was:
The code assumes that DatabaseManager.getCollection raises an XMLDBException for
errors, but in fact in at least some cases (non-existent collection), it returns
null.

The patch reworks the error checking to explicitly raise an exception for this 
case.


> [PATCH] null pointer exception in XMLDB transformer
> ---
>
>  Key: COCOON-1243
>  URL: http://issues.apache.org/jira/browse/COCOON-1243
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XML-DB
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: All
> Reporter: Tim Goodwin
> Assignee: Cocoon Developers Team
>  Attachments: patch
>
> The code assumes that DatabaseManager.getCollection raises an XMLDBException 
> for
> errors, but in fact in at least some cases (non-existent collection), it 
> returns
> null.
> The patch reworks the error checking to explicitly raise an exception for 
> this case.

-- 
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-1248) [Patch] XMLDBSource cannot handle BinaryResources

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1248:


Bugzilla Id:   (was: 30924)
  Component: Blocks: XML-DB
 (was: Blocks: (Undefined))
Description: 
The method getInputStream() does not correctly handle BinaryResources stored in
the XMLDB store; therefore, you cannot do


Patch will be attached.

  was:
The method getInputStream() does not correctly handle BinaryResources stored in
the XMLDB store; therefore, you cannot do


Patch will be attached.


> [Patch] XMLDBSource cannot handle BinaryResources
> -
>
>  Key: COCOON-1248
>  URL: http://issues.apache.org/jira/browse/COCOON-1248
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XML-DB
> Versions: 2.1.5
>  Environment: Operating System: All
> Platform: All
> Reporter: lpb+apache
> Assignee: Cocoon Developers Team
>  Attachments: binary-resource.patch
>
> The method getInputStream() does not correctly handle BinaryResources stored 
> in
> the XMLDB store; therefore, you cannot do
> 
> Patch will be attached.

-- 
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-1249) [Patch] XMLDBSource should accept scheme://user:[EMAIL PROTECTED]:port/path URIs

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1249:


Bugzilla Id:   (was: 30928)
  Component: Blocks: XML-DB
 (was: Blocks: (Undefined))
Description: 
It should be possible to have the following in the sitemap:



so each user can have their own authentication to the XMLDB as necessary. This
corresponds to the missing "application managed security" paradigm; currently
XMLDBSource only implements "container managed security". 

The attached patch accomplishes this goal. UserInfo in the URI overrides
"container managed" credential information if it exists. This seems consistent
with J2EE.

  was:
It should be possible to have the following in the sitemap:



so each user can have their own authentication to the XMLDB as necessary. This
corresponds to the missing "application managed security" paradigm; currently
XMLDBSource only implements "container managed security". 

The attached patch accomplishes this goal. UserInfo in the URI overrides
"container managed" credential information if it exists. This seems consistent
with J2EE.


> [Patch] XMLDBSource should accept scheme://user:[EMAIL PROTECTED]:port/path 
> URIs
> 
>
>  Key: COCOON-1249
>  URL: http://issues.apache.org/jira/browse/COCOON-1249
>  Project: Cocoon
> Type: Improvement
>   Components: Blocks: XML-DB
> Versions: 2.1.5
>  Environment: Operating System: other
> Platform: Other
> Reporter: lpb+apache
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Attachments: local-login.patch
>
> It should be possible to have the following in the sitemap:
>  src="xmldb:db://{session-attr:user}:{session-attr:[EMAIL 
> PROTECTED]:port/db/etc.xml" />
> so each user can have their own authentication to the XMLDB as necessary. This
> corresponds to the missing "application managed security" paradigm; currently
> XMLDBSource only implements "container managed security". 
> The attached patch accomplishes this goal. UserInfo in the URI overrides
> "container managed" credential information if it exists. This seems consistent
> with J2EE.

-- 
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-1256) [PATCH] login and pseudo protocol xmldb

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1256:


Bugzilla Id:   (was: 31011)
  Component: Blocks: XML-DB
 (was: Blocks: (Undefined))
Description: 
this patch allow to set user and password in the sitemap for the pseudo protocol
xmldb.

ex:

  

  


  was:
this patch allow to set user and password in the sitemap for the pseudo protocol
xmldb.

ex:

  

  



> [PATCH] login and pseudo protocol xmldb
> ---
>
>  Key: COCOON-1256
>  URL: http://issues.apache.org/jira/browse/COCOON-1256
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XML-DB
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: All
> Reporter: vincent jaulin
> Assignee: Cocoon Developers Team
>  Attachments: XMLDBSourceFactory.java.diff
>
> this patch allow to set user and password in the sitemap for the pseudo 
> protocol
> xmldb.
> ex:
> 
>src="xmldb:xdepo://{session-attr:login}:{session-attr:pwd}@/db/repository/"/>
> 
>   
> 

-- 
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-1259) [PATCH] XMLDBTransformer can use username/password to access XMLDB

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1259:


Bugzilla Id:   (was: 31064)
  Component: Blocks: XML-DB
 (was: Blocks: (Undefined))
Description: 
This patch allows a user to configure the XMLDBTransformer to use a username and
password to access the underlying collection(s) for update. The new tags are
sitemap parameters named "username" and "password".

  was:
This patch allows a user to configure the XMLDBTransformer to use a username and
password to access the underlying collection(s) for update. The new tags are
sitemap parameters named "username" and "password".


> [PATCH] XMLDBTransformer can use username/password to access XMLDB
> --
>
>  Key: COCOON-1259
>  URL: http://issues.apache.org/jira/browse/COCOON-1259
>  Project: Cocoon
> Type: Improvement
>   Components: Blocks: XML-DB
> Versions: 2.1.5
>  Environment: Operating System: other
> Platform: Other
> Reporter: lpb+apache
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Attachments: 20050916-XMLDBTransformer, username.txt
>
> This patch allows a user to configure the XMLDBTransformer to use a username 
> and
> password to access the underlying collection(s) for update. The new tags are
> sitemap parameters named "username" and "password".

-- 
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-1316) I18NTransformer Cannot format ISO8601 dateTime format

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1316:


Bugzilla Id:   (was: 31889)
  Component: * Cocoon Core
 (was: Blocks: (Undefined))
Description: 
The i18nTransformer cannot format datesTime elements using the ISO8601 format 
of CCYY-MM_DDThh:mm:ss as the source (Note the 'T' is the letter T and not a 
field). An example date time is: 2002-04-02T12:30:00.00+10:00

A src-pattern could be used but the transformer barfs on the 'T' 
with "java.lang.IllegalArgumentException: Illegal pattern character 'T'".

ISO8601 is the date/time format specified for dateTime elements in the XML 
Schema definition and is the dateTime format returned by many XML databases.  
For more information see: http://www.w3.org/TR/xmlschema-2/#dateTime

  was:
The i18nTransformer cannot format datesTime elements using the ISO8601 format 
of CCYY-MM_DDThh:mm:ss as the source (Note the 'T' is the letter T and not a 
field). An example date time is: 2002-04-02T12:30:00.00+10:00

A src-pattern could be used but the transformer barfs on the 'T' 
with "java.lang.IllegalArgumentException: Illegal pattern character 'T'".

ISO8601 is the date/time format specified for dateTime elements in the XML 
Schema definition and is the dateTime format returned by many XML databases.  
For more information see: http://www.w3.org/TR/xmlschema-2/#dateTime


> I18NTransformer Cannot format ISO8601 dateTime format
> -
>
>  Key: COCOON-1316
>  URL: http://issues.apache.org/jira/browse/COCOON-1316
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.5
>  Environment: Operating System: All
> Platform: All
> Reporter: Dean Cording
> Assignee: Cocoon Developers Team

>
> The i18nTransformer cannot format datesTime elements using the ISO8601 format 
> of CCYY-MM_DDThh:mm:ss as the source (Note the 'T' is the letter T and not a 
> field). An example date time is: 2002-04-02T12:30:00.00+10:00
> A src-pattern could be used but the transformer barfs on the 'T' 
> with "java.lang.IllegalArgumentException: Illegal pattern character 'T'".
> ISO8601 is the date/time format specified for dateTime elements in the XML 
> Schema definition and is the dateTime format returned by many XML databases.  
> For more information see: http://www.w3.org/TR/xmlschema-2/#dateTime

-- 
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-1148) FragmentExtractor always returns same fragment

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1148:


Bugzilla Id:   (was: 28724)
  Component: * Cocoon Core
 (was: Blocks: (Undefined))
Description: 
>From the code it is not a caching issue. Did not investigate/test further.

http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107461016305358&w=4
http://marc.theaimsgroup.com/?t=10818801311&r=1&w=4
http://marc.theaimsgroup.com/?t=10820962381&r=1&w=4

  was:
>From the code it is not a caching issue. Did not investigate/test further.

http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107461016305358&w=4
http://marc.theaimsgroup.com/?t=10818801311&r=1&w=4
http://marc.theaimsgroup.com/?t=10820962381&r=1&w=4


> FragmentExtractor always returns same fragment
> --
>
>  Key: COCOON-1148
>  URL: http://issues.apache.org/jira/browse/COCOON-1148
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jörg Heinicke
> Assignee: Jörg Heinicke

>
> From the code it is not a caching issue. Did not investigate/test further.
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107461016305358&w=4
> http://marc.theaimsgroup.com/?t=10818801311&r=1&w=4
> http://marc.theaimsgroup.com/?t=10820962381&r=1&w=4

-- 
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-1339) Error-uri double instatiations in the new portal.

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1339:


Bugzilla Id:   (was: 32199)
  Component: Blocks: Portal
 (was: Blocks: (Undefined))
Description: 
Hi! 

I've found a bug in the new portal. 
If a coplet has an error, the error should be handled by the pipeline defined 
in the attribute  tag 'error-uri', that was set in the copletdata/portal.xml 
file.

Actually this happens, but the problem is that this happens twice. if the 
coplet has an error, the content ('error-uri' pipeline), is instantiated two 
times.

Thanks in advance.
Hugo.

  was:
Hi! 

I've found a bug in the new portal. 
If a coplet has an error, the error should be handled by the pipeline defined 
in the attribute  tag 'error-uri', that was set in the copletdata/portal.xml 
file.

Actually this happens, but the problem is that this happens twice. if the 
coplet has an error, the content ('error-uri' pipeline), is instantiated two 
times.

Thanks in advance.
Hugo.


> Error-uri double instatiations in the new portal.
> -
>
>  Key: COCOON-1339
>  URL: http://issues.apache.org/jira/browse/COCOON-1339
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Portal
> Versions: 2.1.5
>  Environment: Operating System: Linux
> Platform: PC
> Reporter: Hugo Marcelino
> Assignee: Cocoon Developers Team
> Priority: Critical

>
> Hi! 
> I've found a bug in the new portal. 
> If a coplet has an error, the error should be handled by the pipeline defined 
> in the attribute  tag 'error-uri', that was set in the copletdata/portal.xml 
> file.
> Actually this happens, but the problem is that this happens twice. if the 
> coplet has an error, the content ('error-uri' pipeline), is instantiated two 
> times.
> Thanks in advance.
> Hugo.

-- 
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-1351) Batik FragmentExtractorTransformer fragment id clash

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1351:


Bugzilla Id:   (was: 32289)
  Component: * Cocoon Core
 (was: Blocks: (Undefined))
Description: 
The fragment id generated by the FragmentExtractorTransformer is not unique for 
each fragment extracted.

The fragment id is generated by the following code:
this.requestURI = ObjectModelHelper.getRequest(objectModel).getSitemapURI();
String id = Long.toHexString((hashCode()^HashUtil.hash(requestURI)) + 
fragmentID);

where fragmentId is an integer that starts at 0 and is incremented by one for 
each fragment extracted in the current response.

I have an application where a jpeg image is embedded in xml as base64 data.  I 
use FragmentExtractorTransformer to extract the base64 data and replace it with 
a url based on the fragment id.   Another pipeline handles the image request 
from the browser by connecting a fragmentExtractorGenerator with a base64 
serializer.  The problem is that the same image (usually the first one 
requested) is returned for all requests.

The problem occurs because the request for the page containing the image 
displays a different image depending on the request parameters passed.  As 
fragmentExtractorTransformer only uses the SitemapURI as the basis of the hash 
key, it produces the same hash key for every image.  This causes different 
images to be stored under the same id.  Its anyone's guess which image is 
returned by the following request for the image.

The solution is that the fragment id hash should include the request parameters 
as well as the uri to generate unique ids.

  was:
The fragment id generated by the FragmentExtractorTransformer is not unique for 
each fragment extracted.

The fragment id is generated by the following code:
this.requestURI = ObjectModelHelper.getRequest(objectModel).getSitemapURI();
String id = Long.toHexString((hashCode()^HashUtil.hash(requestURI)) + 
fragmentID);

where fragmentId is an integer that starts at 0 and is incremented by one for 
each fragment extracted in the current response.

I have an application where a jpeg image is embedded in xml as base64 data.  I 
use FragmentExtractorTransformer to extract the base64 data and replace it with 
a url based on the fragment id.   Another pipeline handles the image request 
from the browser by connecting a fragmentExtractorGenerator with a base64 
serializer.  The problem is that the same image (usually the first one 
requested) is returned for all requests.

The problem occurs because the request for the page containing the image 
displays a different image depending on the request parameters passed.  As 
fragmentExtractorTransformer only uses the SitemapURI as the basis of the hash 
key, it produces the same hash key for every image.  This causes different 
images to be stored under the same id.  Its anyone's guess which image is 
returned by the following request for the image.

The solution is that the fragment id hash should include the request parameters 
as well as the uri to generate unique ids.


> Batik FragmentExtractorTransformer fragment id clash
> 
>
>  Key: COCOON-1351
>  URL: http://issues.apache.org/jira/browse/COCOON-1351
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.5
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Dean Cording
> Assignee: Cocoon Developers Team

>
> The fragment id generated by the FragmentExtractorTransformer is not unique 
> for 
> each fragment extracted.
> The fragment id is generated by the following code:
> this.requestURI = ObjectModelHelper.getRequest(objectModel).getSitemapURI();
> String id = Long.toHexString((hashCode()^HashUtil.hash(requestURI)) + 
> fragmentID);
> where fragmentId is an integer that starts at 0 and is incremented by one for 
> each fragment extracted in the current response.
> I have an application where a jpeg image is embedded in xml as base64 data.  
> I 
> use FragmentExtractorTransformer to extract the base64 data and replace it 
> with 
> a url based on the fragment id.   Another pipeline handles the image request 
> from the browser by connecting a fragmentExtractorGenerator with a base64 
> serializer.  The problem is that the same image (usually the first one 
> requested) is returned for all requests.
> The problem occurs because the request for the page containing the image 
> displays a different image depending on the request parameters passed.  As 
> fragmentExtractorTransformer only uses the SitemapURI as the basis of the 
> hash 
> key, it produces the same hash key for every image.  This causes different 
> images to be stored under the same id.  Its anyone's guess which image is 
> returned by the following request for the image.
> The solution is that the fragment id hash should include the request 

[jira] Updated: (COCOON-1536) STX concurrency problem

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1536:


Bugzilla Id:   (was: 35444)
  Component: Blocks: STX
 (was: Blocks: (Undefined))
Description: 
Cocoon ships with an old version of Joost (20040330), and this seems to have a 
concurrency problem. After upgrading Joost to 20050521, the problem 
disappeared.

  was:
Cocoon ships with an old version of Joost (20040330), and this seems to have a 
concurrency problem. After upgrading Joost to 20050521, the problem 
disappeared.


> STX concurrency problem
> ---
>
>  Key: COCOON-1536
>  URL: http://issues.apache.org/jira/browse/COCOON-1536
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: STX
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Askild Aaberg Olsen
> Assignee: Cocoon Developers Team

>
> Cocoon ships with an old version of Joost (20040330), and this seems to have 
> a 
> concurrency problem. After upgrading Joost to 20050521, the problem 
> disappeared.

-- 
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-1549) [PATCH] Batik Rhino support incompatible with Cocoon's

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1549:


Bugzilla Id:   (was: 35578)
  Component: Blocks: Batik
 (was: Blocks: (Undefined))
Description: 
A bug has been filed at Batik, but nobody has replied yet:
http://issues.apache.org/bugzilla/show_bug.cgi?id=35233

The need is to use Batik's Rhino support for adding JavaScript to SVG.  The
problem is that Batik's RhinoInterpreter sets a custom security domain
incompatible with Rhino context from Cocoon's FlowScript which doesn't set one.

The idea is to remove Batik's Rhino security controller to ensure proper
interoperability between Cocoon and Batik.

  was:
A bug has been filed at Batik, but nobody has replied yet:
http://issues.apache.org/bugzilla/show_bug.cgi?id=35233

The need is to use Batik's Rhino support for adding JavaScript to SVG.  The
problem is that Batik's RhinoInterpreter sets a custom security domain
incompatible with Rhino context from Cocoon's FlowScript which doesn't set one.

The idea is to remove Batik's Rhino security controller to ensure proper
interoperability between Cocoon and Batik.


> [PATCH] Batik Rhino support incompatible with Cocoon's
> --
>
>  Key: COCOON-1549
>  URL: http://issues.apache.org/jira/browse/COCOON-1549
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Batik
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jean-Baptiste Quenot
> Assignee: Cocoon Developers Team
>  Attachments: patch-rhinointerpreter
>
> A bug has been filed at Batik, but nobody has replied yet:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35233
> The need is to use Batik's Rhino support for adding JavaScript to SVG.  The
> problem is that Batik's RhinoInterpreter sets a custom security domain
> incompatible with Rhino context from Cocoon's FlowScript which doesn't set 
> one.
> The idea is to remove Batik's Rhino security controller to ensure proper
> interoperability between Cocoon and Batik.

-- 
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-1547) [PATCH] XMLDBSource cannot find SerializerSelector

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1547:


Bugzilla Id:   (was: 35575)
  Component: Blocks: XML-DB
 (was: Blocks: (Undefined))
Description: 
In some rare circumstances, XMLDBSource.getInputStream() cannot manage to find
the component SerializerSelector.  The comment for getInputStream() suggests
that it has been copy/pasted from SitemapSource, which has seen evolved, so the
code may have to be rewritten.

  was:
In some rare circumstances, XMLDBSource.getInputStream() cannot manage to find
the component SerializerSelector.  The comment for getInputStream() suggests
that it has been copy/pasted from SitemapSource, which has seen evolved, so the
code may have to be rewritten.


> [PATCH] XMLDBSource cannot find SerializerSelector
> --
>
>  Key: COCOON-1547
>  URL: http://issues.apache.org/jira/browse/COCOON-1547
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XML-DB
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jean-Baptiste Quenot
> Assignee: Cocoon Developers Team
>  Attachments: patch-xmldb
>
> In some rare circumstances, XMLDBSource.getInputStream() cannot manage to find
> the component SerializerSelector.  The comment for getInputStream() suggests
> that it has been copy/pasted from SitemapSource, which has seen evolved, so 
> the
> code may have to be rewritten.

-- 
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-1574) Memory Leak with XMLFileModule

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1574:


Bugzilla Id:   (was: 36162)
  Component: * Cocoon Core
 (was: Blocks: (Undefined))
Description: 
I'm currently looking into a memory leak issue at Apache Forrest.  Forrest's
site currently needs to be built with -Xmx128m because of this.  I believe the
issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule.

A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which
get referenced by XMLFileModule.DocumentHelper.  Their URIs are linkmap-xxx.

LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper,
which seems to reference a XMLFileModule.
  ...
  newLink = (String) modHelper.getAttribute(this.objectModel,
 ^
  ...

The XMLFileModule keeps the visited documents in a map, which is where they
build up.

Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from
  this.documents.put(src, new DocumentHelper(reload, cache, src, this));
to
  return new DocumentHelper(reload, cache, src, this);

Thus, a new DocumentHelper is created every time, instead of caching them.  The
result: No more memory problems, Apache Forrest's site builds again with -Xmx32.

Ron

  was:
I'm currently looking into a memory leak issue at Apache Forrest.  Forrest's
site currently needs to be built with -Xmx128m because of this.  I believe the
issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule.

A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which
get referenced by XMLFileModule.DocumentHelper.  Their URIs are linkmap-xxx.

LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper,
which seems to reference a XMLFileModule.
  ...
  newLink = (String) modHelper.getAttribute(this.objectModel,
 ^
  ...

The XMLFileModule keeps the visited documents in a map, which is where they
build up.

Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from
  this.documents.put(src, new DocumentHelper(reload, cache, src, this));
to
  return new DocumentHelper(reload, cache, src, this);

Thus, a new DocumentHelper is created every time, instead of caching them.  The
result: No more memory problems, Apache Forrest's site builds again with -Xmx32.

Ron


> Memory Leak with XMLFileModule
> --
>
>  Key: COCOON-1574
>  URL: http://issues.apache.org/jira/browse/COCOON-1574
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.2-dev (Current SVN)
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Ron Blaschke
> Assignee: Cocoon Developers Team

>
> I'm currently looking into a memory leak issue at Apache Forrest.  Forrest's
> site currently needs to be built with -Xmx128m because of this.  I believe the
> issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule.
> A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), 
> which
> get referenced by XMLFileModule.DocumentHelper.  Their URIs are linkmap-xxx.
> LinkRewriterTransformer#createTransformedLink(String) uses a 
> InputModuleHelper,
> which seems to reference a XMLFileModule.
>   ...
>   newLink = (String) modHelper.getAttribute(this.objectModel,
>  ^
>   ...
> The XMLFileModule keeps the visited documents in a map, which is where they
> build up.
> Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) 
> from
>   this.documents.put(src, new DocumentHelper(reload, cache, src, this));
> to
>   return new DocumentHelper(reload, cache, src, this);
> Thus, a new DocumentHelper is created every time, instead of caching them.  
> The
> result: No more memory problems, Apache Forrest's site builds again with 
> -Xmx32.
> Ron

-- 
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-1578) WebServiceProxyGenerator sample block error

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1578:


Bugzilla Id:   (was: 36299)
  Component: Blocks: Proxy
 (was: Blocks: (Undefined))
Description: 
http://localhost:/samples/blocks/proxy/wsproxy/ doesn't work in 2.1.7 
build.

I get this error message:
"Impossible de résoudre le préfixe de l'espace de noms : xalan"
(wich means in english: "unable to resolve xalan namespace"

I've seen that this block has bugs (14916, 21339, 21340, 21399) open in the 
main SVN trunk... but they don't seem to deal with this problem.

I tried to remove: 
  exclude-result-prefixes="xalan"
from newWizard2html.xsl
(just to see...)
I get an other error message:
C:\...\cocoon-2.1.7\build\webapp\stylesheets\system\xmlform2html.xslt (Le 
fichier spécifié est introuvable)
(in english: unable to find .../xmlform2html.xslt)

Is it solve in the main trunk ?



--
Full stacktrace of "unable to resolve xalan namespace":

org.apache.cocoon.ProcessingException: Unable to get transformer handler for 
file:/C:/developpement/apache/cocoon-
2.1.7/build/webapp/samples/blocks/proxy/stylesheets/newWizard2html.xsl: 
org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in creating 
Transform Handler
at org.apache.cocoon.transformation.TraxTransformer.setup
(TraxTransformer.java:318)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline
(AbstractProcessingPipeline.java:398)
at 
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.se
tupPipeline(AbstractCachingProcessingPipeline.java:620)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipelin
e(AbstractProcessingPipeline.java:503)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process
(AbstractProcessingPipeline.java:455)
at 
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke
(SerializeNode.java:120)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:46)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
(PreparableMatchNode.java:130)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:68)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
(PipelineNode.java:138)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:68)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke
(PipelinesNode.java:92)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:234)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:176)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process
(TreeProcessor.java:243)
at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke
(MountNode.java:117)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:46)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
(PreparableMatchNode.java:130)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:68)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
(PipelineNode.java:138)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:68)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke
(PipelinesNode.java:92)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:234)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:176)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process
(TreeProcessor.java:243)
at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke
(MountNode.java:117)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:46)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
(PreparableMatchNode.java:130)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:68)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
(PipelineNode.java:138)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(Abstr

[jira] Updated: (COCOON-1584) [PATCH] Improve WebDAVSource error messages

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1584:


Bugzilla Id:   (was: 36371)
  Component: Blocks: WebDAV
 (was: Blocks: (Undefined))
Description: 
When WebDAVSource fails to connect to a WebDAV server, the error message should
advertise the server address, else it is impossible to diagnose the problem.

  was:
When WebDAVSource fails to connect to a WebDAV server, the error message should
advertise the server address, else it is impossible to diagnose the problem.


> [PATCH] Improve WebDAVSource error messages
> ---
>
>  Key: COCOON-1584
>  URL: http://issues.apache.org/jira/browse/COCOON-1584
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: WebDAV
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jean-Baptiste Quenot
> Assignee: Jörg Heinicke
> Priority: Minor
>  Attachments: WebDAVSource.patch
>
> When WebDAVSource fails to connect to a WebDAV server, the error message 
> should
> advertise the server address, else it is impossible to diagnose the problem.

-- 
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-1600) [PATCH] Add method makeCollection() in XMLDBSource

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1600:


Bugzilla Id:   (was: 36686)
  Component: Blocks: XML-DB
 (was: Blocks: (Undefined))
Description: 
There is currently no way to create a collection in an XML database using the
Source API.

  was:
There is currently no way to create a collection in an XML database using the
Source API.


> [PATCH] Add method makeCollection() in XMLDBSource
> --
>
>  Key: COCOON-1600
>  URL: http://issues.apache.org/jira/browse/COCOON-1600
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XML-DB
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jean-Baptiste Quenot
> Assignee: Cocoon Developers Team
>  Attachments: 20050916-XMLDBSource
>
> There is currently no way to create a collection in an XML database using the
> Source API.

-- 
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-1608) Missing Dependency in Webdav block

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1608:


Bugzilla Id:   (was: 36736)
  Component: Blocks: WebDAV
 (was: Blocks: (Undefined))
Description: 
Trace Back: 
 
 [exec] java.lang.NoClassDefFoundError: org/jdom/input/DOMBuilder 
 [exec] at 
org.apache.webdav.lib.BaseProperty.getPropertyAsString(BaseProperty.java:129) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.processProperty(WebdavResource.java:4911) 
 [exec] [exec] java.lang.NoClassDefFoundError: 
org/jdom/input/DOMBuilder 
 [exec] at 
org.apache.webdav.lib.BaseProperty.getPropertyAsString(BaseProperty.java:129) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.processProperty(WebdavResource.java:4911) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setWebdavProperties(WebdavResource.java:1066)
 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:968) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.java:912)
 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1894) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.(WebdavResource.java:223) 
 [exec] at 
org.apache.cocoon.components.source.impl.WebDAVSource.initResource(WebDAVSource.java:212)
 
 [exec] at 
org.apache.cocoon.components.source.impl.WebDAVSource.exists(WebDAVSource.java:410)
 
 at 
org.apache.webdav.lib.WebdavResource.setWebdavProperties(WebdavResource.java:1066)
 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:968) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.java:912)
 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1894) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.(WebdavResource.java:223) 
 [exec] at 
org.apache.cocoon.components.source.impl.WebDAVSource.initResource(WebDAVSource.java:212)
 
 [exec] at 
org.apache.cocoon.components.source.impl.WebDAVSource.exists(WebDAVSource.java:410)
 
 
Patch to gump.xml 
 
=== 
--- gump.xml(revision 290444) 
+++ gump.xml(working copy) 
@@ -1157,6 +1157,7 @@ 
 
  
  
+ 
 
  
 

  was:
Trace Back: 
 
 [exec] java.lang.NoClassDefFoundError: org/jdom/input/DOMBuilder 
 [exec] at 
org.apache.webdav.lib.BaseProperty.getPropertyAsString(BaseProperty.java:129) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.processProperty(WebdavResource.java:4911) 
 [exec] [exec] java.lang.NoClassDefFoundError: 
org/jdom/input/DOMBuilder 
 [exec] at 
org.apache.webdav.lib.BaseProperty.getPropertyAsString(BaseProperty.java:129) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.processProperty(WebdavResource.java:4911) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setWebdavProperties(WebdavResource.java:1066)
 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:968) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.java:912)
 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1894) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.(WebdavResource.java:223) 
 [exec] at 
org.apache.cocoon.components.source.impl.WebDAVSource.initResource(WebDAVSource.java:212)
 
 [exec] at 
org.apache.cocoon.components.source.impl.WebDAVSource.exists(WebDAVSource.java:410)
 
 at 
org.apache.webdav.lib.WebdavResource.setWebdavProperties(WebdavResource.java:1066)
 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:968) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.java:912)
 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1894) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301) 
 [exec] at 
org.apache.webdav.lib.WebdavResource.(WebdavResource.java:223) 
 [exec] at 
org.apache.cocoon.components.source.impl.WebDAVSource.initResource(WebDAVSource.java:212)
 
 [exec] at 
org.apache.cocoon.components.source.impl.WebDAVSource.exists(WebDAVSource.java:410)
 
 
Patch to gump.xml 
 
=== 
--- gump.xml(revision 290444) 
+++ gump.xml(working copy) 
@@ -1157,6 +1157,7 @@ 
 
  
  

[jira] Updated: (COCOON-1639) [patch] NekoHTMLTransformer

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1639:


Bugzilla Id:   (was: 37023)
  Component: Blocks: HTML
 (was: Blocks: (Undefined))
Description: 
The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator and...
hey, where's the NekoHTMLTransformer?

So, just to complete the set, here's one I prepared earlier :-)
I've also included an (empty) neko.properties configuration file, and updated
the neko generator's setup bits to allow for setting parser features as well as
properties.

  was:
The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator and...
hey, where's the NekoHTMLTransformer?

So, just to complete the set, here's one I prepared earlier :-)
I've also included an (empty) neko.properties configuration file, and updated
the neko generator's setup bits to allow for setting parser features as well as
properties.


> [patch] NekoHTMLTransformer
> ---
>
>  Key: COCOON-1639
>  URL: http://issues.apache.org/jira/browse/COCOON-1639
>  Project: Cocoon
> Type: Improvement
>   Components: Blocks: HTML
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: All
> Reporter: Andrew Stevens
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Attachments: NekoHTMLTransformer.java, htmlblock.diff, neko.properties
>
> The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator 
> and...
> hey, where's the NekoHTMLTransformer?
> So, just to complete the set, here's one I prepared earlier :-)
> I've also included an (empty) neko.properties configuration file, and updated
> the neko generator's setup bits to allow for setting parser features as well 
> as
> properties.

-- 
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-1450) i18n messages don't work for required fields

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1450:


Bugzilla Id:   (was: 33637)
  Component: * Cocoon Core
 (was: Blocks: (Undefined))
Description: 
I've tried using i18n tags in the XSL for required fields to no avail. The 
other validation messages work when i18n tags used in form definitions but 
localized messages for required fields no joy under any conditions. 

Ideally I'd be submitting a patch with this but haven't nail exactly where the 
problem is. The problem is also in the samples.. You can get localised 
messages working when you define them with i18n tags in the form def, but a 
simple test using Packages.ValidationError("mykey.inmessages",true) fails. 

I've got as far as System.outs in I18nMessage.toSax() but haven't worked out a 
means of debuging a contentHandler as yet.

  was:
I've tried using i18n tags in the XSL for required fields to no avail. The 
other validation messages work when i18n tags used in form definitions but 
localized messages for required fields no joy under any conditions. 

Ideally I'd be submitting a patch with this but haven't nail exactly where the 
problem is. The problem is also in the samples.. You can get localised 
messages working when you define them with i18n tags in the form def, but a 
simple test using Packages.ValidationError("mykey.inmessages",true) fails. 

I've got as far as System.outs in I18nMessage.toSax() but haven't worked out a 
means of debuging a contentHandler as yet.


> i18n messages don't work for required fields
> 
>
>  Key: COCOON-1450
>  URL: http://issues.apache.org/jira/browse/COCOON-1450
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: Windows XP
> Platform: All
> Reporter: Mark
> Assignee: Cocoon Developers Team

>
> I've tried using i18n tags in the XSL for required fields to no avail. The 
> other validation messages work when i18n tags used in form definitions but 
> localized messages for required fields no joy under any conditions. 
> Ideally I'd be submitting a patch with this but haven't nail exactly where 
> the 
> problem is. The problem is also in the samples.. You can get localised 
> messages working when you define them with i18n tags in the form def, but a 
> simple test using Packages.ValidationError("mykey.inmessages",true) 
> fails. 
> I've got as far as System.outs in I18nMessage.toSax() but haven't worked out 
> a 
> means of debuging a contentHandler as yet.

-- 
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] Reopened: (COCOON-1626) [Link] Polska Strefa

[JIRA]

 [ http://issues.apache.org/jira/browse/COCOON-1626?page=all ]
 
Grzegorz Tańczyk reopened COCOON-1626:
--


Why Daisy Live sites not Cocoon 2.1.6?

> [Link] Polska Strefa
> 
>
>  Key: COCOON-1626
>  URL: http://issues.apache.org/jira/browse/COCOON-1626
>  Project: Cocoon
> Type: Improvement
>   Components: - Documentation
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: All
> Reporter: Grzegorz Tańczyk
> Assignee: Cocoon Developers Team
> Priority: Minor

>
> URL of the website: http://www.classifieds.pl
> Title of the website: Polska Strefa
> Cocoon version used: 2.1.6
> Short summary: Polish website with classified ads 
> How can we verify this site is actually built with Cocoon? Beacause I posted 
> few times since last year on users@cocoon.apache.org ?
> - How much time did it take to build the site from design to publication?
> 2 months, but it is still under developement. New important improvements are 
> still pedning.
> - How much traffic does the site handle?
> About 40.000 sessions each day
> - What made you choose Cocoon to build the site?
> 1. Java
> 2. XML
> - What other information do you want to disclose (e.g. how does it work, how 
> did
> you build it, what parts of Cocoon did you use)?
> I didn't use Flow, CForms, Portal Framework, SQLTransformer or Database 
> Actions etc. It is based on my own Actions, Generators, Readers. Cron 
> Scheduler is an important part there. I decided to use PostgreSQL as database 
> engine.
> - Can you provide a contact email address if people want further information?
> [EMAIL PROTECTED]

-- 
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-1196) [XSP] logicsheet-util.xsl failes with duplicate namespace declarations

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1196:


Bugzilla Id:   (was: 29864)
  Component: Blocks: XSP
 (was: Blocks: (Undefined))
Description: 
If an input module namespace is declared twice, e.g.

  xmlns:xsp-input="http://apache.org/cocoon/xsp/input/1.0";
  xmlns:input="http://apache.org/cocoon/xsp/input/1.0";

and  is used for a required parameter:

  
foo
list
  

a ProcessingException is thrown, because the template
"get-namespace-prefix" in logicsheet-util.xsl is matching
the first namespace declaration and does not find any
parameter tags for this namespace prefix.

I think it is not a good practise to rely on namespace
prefixes. Wouldn't it be possible to use just the
namespace URIs to resolve the parameter?

  was:
If an input module namespace is declared twice, e.g.

  xmlns:xsp-input="http://apache.org/cocoon/xsp/input/1.0";
  xmlns:input="http://apache.org/cocoon/xsp/input/1.0";

and  is used for a required parameter:

  
foo
list
  

a ProcessingException is thrown, because the template
"get-namespace-prefix" in logicsheet-util.xsl is matching
the first namespace declaration and does not find any
parameter tags for this namespace prefix.

I think it is not a good practise to rely on namespace
prefixes. Wouldn't it be possible to use just the
namespace URIs to resolve the parameter?


> [XSP] logicsheet-util.xsl failes with duplicate namespace declarations
> --
>
>  Key: COCOON-1196
>  URL: http://issues.apache.org/jira/browse/COCOON-1196
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XSP
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Andreas Hartmann
> Assignee: Cocoon Developers Team
> Priority: Minor

>
> If an input module namespace is declared twice, e.g.
>   xmlns:xsp-input="http://apache.org/cocoon/xsp/input/1.0";
>   xmlns:input="http://apache.org/cocoon/xsp/input/1.0";
> and  is used for a required parameter:
>   
> foo
> list
>   
> a ProcessingException is thrown, because the template
> "get-namespace-prefix" in logicsheet-util.xsl is matching
> the first namespace declaration and does not find any
> parameter tags for this namespace prefix.
> I think it is not a good practise to rely on namespace
> prefixes. Wouldn't it be possible to use just the
> namespace URIs to resolve the parameter?

-- 
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-1251) XSP compile failure when using Java 1.5 features

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1251:


Bugzilla Id:   (was: 30971)
  Component: Blocks: XSP
 (was: Blocks: (Undefined))
Description: 
I am trying to use the new JDK1.5 foreach loop in XSP, basically:

List entries = new ArrayList();
for (Map entry: entries) {
...
}

which causes the following error with the default EclipseJavaCompiler:

// start error (lines 1003-1003) "Syntax error on token ":", ";"
expected"
for (Map entry: entries)
{

// end error

or even with the Javac compiler:

/home/tomcat/work/Default/beta.hostmaster.org/_/cocoon-
files/org/apache/cocoon/www/Dictionary_xsp.java:1003: ';' expected.
for (Map entry: entries)
{

Cocoon is running under Tomcat 5.0.28 on j2sdk-1.5.0-beta2-b51.

  was:
I am trying to use the new JDK1.5 foreach loop in XSP, basically:

List entries = new ArrayList();
for (Map entry: entries) {
...
}

which causes the following error with the default EclipseJavaCompiler:

// start error (lines 1003-1003) "Syntax error on token ":", ";"
expected"
for (Map entry: entries)
{

// end error

or even with the Javac compiler:

/home/tomcat/work/Default/beta.hostmaster.org/_/cocoon-
files/org/apache/cocoon/www/Dictionary_xsp.java:1003: ';' expected.
for (Map entry: entries)
{

Cocoon is running under Tomcat 5.0.28 on j2sdk-1.5.0-beta2-b51.


> XSP compile failure when using Java 1.5 features
> 
>
>  Key: COCOON-1251
>  URL: http://issues.apache.org/jira/browse/COCOON-1251
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XSP
> Versions: 2.1.5
>  Environment: Operating System: Linux
> Platform: PC
> Reporter: Thomas Zehetbauer
> Assignee: Antonio Gallardo

>
> I am trying to use the new JDK1.5 foreach loop in XSP, basically:
> List entries = new ArrayList();
> for (Map entry: entries) {
> ...
> }
> which causes the following error with the default EclipseJavaCompiler:
> // start error (lines 1003-1003) "Syntax error on token ":", ";"
> expected"
> for (Map entry: entries)
> {
> // end error
> or even with the Javac compiler:
> /home/tomcat/work/Default/beta.hostmaster.org/_/cocoon-
> files/org/apache/cocoon/www/Dictionary_xsp.java:1003: ';' expected.
> for (Map entry: entries)
> {
> Cocoon is running under Tomcat 5.0.28 on j2sdk-1.5.0-beta2-b51.

-- 
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-1280) XSP logicsheet jpath.xsl: incorrect call to JXPathContext.compile

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1280:


Bugzilla Id:   (was: 31493)
  Component: Blocks: XSP
 (was: Blocks: (Undefined))
Description: 
The xsp logix sheet jpath.xsl incorrectly calls the JXPathContext.compile 
method from an instance. This leads to a compilation error for the generated 
java source. compile should be called as a static method i.e 
JXPathContext.compile i.s.o. jxpathContext.compile.

  was:
The xsp logix sheet jpath.xsl incorrectly calls the JXPathContext.compile 
method from an instance. This leads to a compilation error for the generated 
java source. compile should be called as a static method i.e 
JXPathContext.compile i.s.o. jxpathContext.compile.


> XSP logicsheet jpath.xsl: incorrect call to JXPathContext.compile
> -
>
>  Key: COCOON-1280
>  URL: http://issues.apache.org/jira/browse/COCOON-1280
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XSP
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: All
> Reporter: Rob Berens
> Assignee: Cocoon Developers Team
>  Attachments: patch.txt
>
> The xsp logix sheet jpath.xsl incorrectly calls the JXPathContext.compile 
> method from an instance. This leads to a compilation error for the generated 
> java source. compile should be called as a static method i.e 
> JXPathContext.compile i.s.o. jxpathContext.compile.

-- 
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-1286) [PATCH] XSP - JXPath logicsheet using relative contexts

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1286:


Bugzilla Id:   (was: 31564)
  Component: Blocks: XSP
 (was: Blocks: (Undefined))
Description: 
Are you using the jpath logicsheet and have been annoyed that you can't access 
parents or siblings elements in a for-each loop?
like

   - 

won't work because the logicsheet changed the context and /title is not 
available.

There is a simple way to fix that, simply iterating over pointers instead of 
values. This way one can build contexts that are relative to the current one.
So . and non-absolute paths will still point to the iterated element, but 
absolute paths point to the root and siblings etc should work, too.

I wrote that patch a while ago so it is tested and works fine.

---

This patch also adds a new tag to switch the lenient setting of jxpath.
By default it is set to false. If set to true, xpaths that don't point to an 
object or a set of them will return null (Instead of that annoying exception). 
Saves all the checking if you can accept nulls and are sure there are no typos.

If the tag contains child elements it will scope the setting for the enclosed 
elements, otherwise it is a global setting. You can't nest  
tags.

gunnar

ps: the diff file does not have the correct path for the filenames as I had to 
use the webinterface to get the current 2.1 branch jpath.xsl.

  was:
Are you using the jpath logicsheet and have been annoyed that you can't access 
parents or siblings elements in a for-each loop?
like

   - 

won't work because the logicsheet changed the context and /title is not 
available.

There is a simple way to fix that, simply iterating over pointers instead of 
values. This way one can build contexts that are relative to the current one.
So . and non-absolute paths will still point to the iterated element, but 
absolute paths point to the root and siblings etc should work, too.

I wrote that patch a while ago so it is tested and works fine.

---

This patch also adds a new tag to switch the lenient setting of jxpath.
By default it is set to false. If set to true, xpaths that don't point to an 
object or a set of them will return null (Instead of that annoying exception). 
Saves all the checking if you can accept nulls and are sure there are no typos.

If the tag contains child elements it will scope the setting for the enclosed 
elements, otherwise it is a global setting. You can't nest  
tags.

gunnar

ps: the diff file does not have the correct path for the filenames as I had to 
use the webinterface to get the current 2.1 branch jpath.xsl.


> [PATCH] XSP - JXPath logicsheet  using relative contexts
> -
>
>  Key: COCOON-1286
>  URL: http://issues.apache.org/jira/browse/COCOON-1286
>  Project: Cocoon
> Type: Improvement
>   Components: Blocks: XSP
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Gunnar Brand
> Assignee: Antonio Gallardo
> Priority: Minor
>  Attachments: jpath.xsl.diff, jpath.xsl.diff
>
> Are you using the jpath logicsheet and have been annoyed that you can't 
> access 
> parents or siblings elements in a for-each loop?
> like
> 
>- 
> 
> won't work because the logicsheet changed the context and /title is not 
> available.
> There is a simple way to fix that, simply iterating over pointers instead of 
> values. This way one can build contexts that are relative to the current one.
> So . and non-absolute paths will still point to the iterated element, but 
> absolute paths point to the root and siblings etc should work, too.
> I wrote that patch a while ago so it is tested and works fine.
> ---
> This patch also adds a new tag to switch the lenient setting of jxpath.
> By default it is set to false. If set to true, xpaths that don't point to an 
> object or a set of them will return null (Instead of that annoying 
> exception). 
> Saves all the checking if you can accept nulls and are sure there are no 
> typos.
> 
> If the tag contains child elements it will scope the setting for the enclosed 
> elements, otherwise it is a global setting. You can't nest 
>  
> tags.
> gunnar
> ps: the diff file does not have the correct path for the filenames as I had 
> to 
> use the webinterface to get the current 2.1 branch jpath.xsl.

-- 
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-1391) [PATCH] Popular website with XSP homepage won't come up

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1391:


Bugzilla Id:   (was: 32935)
  Component: Blocks: XSP
 (was: Blocks: (Undefined))
Description: 
Whilst the cache of compiled XSPs is empty, each thread entering 
a.o.c.components.language.generator.ProgramGeneratorImpl.load queues for the 
lock on self and before compiling the XSP.

If during startup requests for an XSP arrive faster than the time it takes to 
compile the XSP, the server will be on its knees recompiling the same XSP over 
and over again.  Therefore a popular website with an XSP homepage will have a 
hard time to come up.

PATCH
=
After acquiring the lock, check again the cache:

--- ProgramGeneratorImpl.java   7 Jul 2003 14:32:15 -   1.1.1.3
+++ ProgramGeneratorImpl.java   4 Jan 2005 11:27:14 -
@@ -290,21 +290,31 @@
 }
 
 if (programInstance == null) {
-// no instance found
-if (getLogger().isDebugEnabled()) {
-getLogger().debug("Creating new serverpage for [" + id 
+ "]");
-}
 synchronized (this) {
-generateSourcecode(source,
-   normalizedName,
-   markupLanguage,
-   programmingLanguage);
-
-programInstance = loadProgram(newManager,
-  normalizedName,
-  markupLanguage,
-  programmingLanguage);
-}
+   // Attempt again to load program object from cache.
+   // This avoids that simultaneous requests recompile
+   // the same XSP over and over again.
+   try {
+   programInstance = (CompiledComponent) this.cache.select
(normalizedName);
+   if (getLogger().isDebugEnabled()) {
+   getLogger().debug("The serverpage [" + id + "] was 
now in the cache");
+   }
+   } catch (ComponentException e) {
+   // no instance found
+   if (getLogger().isDebugEnabled()) {
+   getLogger().debug("Creating new serverpage for [" + 
id + "]");
+   }
+   generateSourcecode(source,
+  normalizedName,
+  markupLanguage,
+  programmingLanguage);
+
+   programInstance = loadProgram(newManager,
+ normalizedName,
+ markupLanguage,
+ programmingLanguage);
+   }
+   }
 } else {
 // found an instance
 if (this.autoReload) {

  was:
Whilst the cache of compiled XSPs is empty, each thread entering 
a.o.c.components.language.generator.ProgramGeneratorImpl.load queues for the 
lock on self and before compiling the XSP.

If during startup requests for an XSP arrive faster than the time it takes to 
compile the XSP, the server will be on its knees recompiling the same XSP over 
and over again.  Therefore a popular website with an XSP homepage will have a 
hard time to come up.

PATCH
=
After acquiring the lock, check again the cache:

--- ProgramGeneratorImpl.java   7 Jul 2003 14:32:15 -   1.1.1.3
+++ ProgramGeneratorImpl.java   4 Jan 2005 11:27:14 -
@@ -290,21 +290,31 @@
 }
 
 if (programInstance == null) {
-// no instance found
-if (getLogger().isDebugEnabled()) {
-getLogger().debug("Creating new serverpage for [" + id 
+ "]");
-}
 synchronized (this) {
-generateSourcecode(source,
-   normalizedName,
-   markupLanguage,
-   programmingLanguage);
-
-programInstance = loadProgram(newManager,
-  normalizedName,
-  markupLanguage,
-  programmingLanguage);
-}
+   // Attempt again to load program object from cache.
+   // This avoids that simultaneous requests recompile
+   // the same XSP over and over again.
+   try {
+   programInstance = (CompiledComponent) this.cache.select
(normalizedName);
+

[jira] Updated: (COCOON-1557) [PATCH] Change access to AbstractContinuable.getContext to protected

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1557:


Bugzilla Id:   (was: 35672)
  Component: Blocks: Java Flow
 (was: Blocks: (Undefined))
Description: 
The attached patch changes the access of AbstractContinuable.getContext from
private to protected so subclasses can access the context.

  was:
The attached patch changes the access of AbstractContinuable.getContext from
private to protected so subclasses can access the context.


> [PATCH] Change access to AbstractContinuable.getContext to protected
> 
>
>  Key: COCOON-1557
>  URL: http://issues.apache.org/jira/browse/COCOON-1557
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Java Flow
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jochen Kuhnle
> Assignee: Cocoon Developers Team
>  Attachments: patch-continuablecontext.txt
>
> The attached patch changes the access of AbstractContinuable.getContext from
> private to protected so subclasses can access the context.

-- 
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-1458) jython jar not added to war in XSP block on build

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1458:


Bugzilla Id:   (was: 33763)
  Component: Blocks: XSP
 (was: Blocks: (Undefined))
Description: 
Environment
===
fedora core 3 linux 2.6.10-1.766_FC3
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)

Tomcat 5.5.7

jsp
org.apache.jasper.servlet.JspServlet

fork
false
javac


xpoweredBy
false

3


Cocoon
URL: http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 155211
Node Kind: directory
Schedule: normal
Last Changed Author: sylvain
Last Changed Rev: 155210
Last Changed Date: 2005-02-24 09:02:09 -0800 (Thu, 24 Feb 2005)
Properties Last Updated: 2005-01-24 11:30:14 -0800 (Mon, 24 Jan 2005)

Build
=
Cocoon builds fine under jdk1.5.0_01 with modifications to
tools/targets/init-build.xml to target the 1.5 jdk.

152c152
target="1.4"
178c178
target="1.4"

modification to lib/jars.xml
1177,1186d1176
<   
< Jython
< 
<   Python interpretor in Java
< 
< XSP
< optional/jython-2.1.jar
< http://www.jython.org
<   
<

Issue
=
Accessing http://localhost:8080/cocoon/samples/blocks/xsp/python/hello generates
the folloing error:

Resource not found
org/python/core/PyObject
org.apache.cocoon.ResourceNotFoundException: org/python/core/PyObject
cause: org.apache.cocoon.ResourceNotFoundException: org/python/core/PyObject

Copying jython-2.1.jar into $TOMCAT_HOME/webapps/cocoon/WEB-INF/lib fixes the
problem.

jar -tf cocoon.war does not show the jar file in cocoon.war

  was:
Environment
===
fedora core 3 linux 2.6.10-1.766_FC3
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)

Tomcat 5.5.7

jsp
org.apache.jasper.servlet.JspServlet

fork
false
javac


xpoweredBy
false

3


Cocoon
URL: http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 155211
Node Kind: directory
Schedule: normal
Last Changed Author: sylvain
Last Changed Rev: 155210
Last Changed Date: 2005-02-24 09:02:09 -0800 (Thu, 24 Feb 2005)
Properties Last Updated: 2005-01-24 11:30:14 -0800 (Mon, 24 Jan 2005)

Build
=
Cocoon builds fine under jdk1.5.0_01 with modifications to
tools/targets/init-build.xml to target the 1.5 jdk.

152c152
target="1.4"
178c178
target="1.4"

modification to lib/jars.xml
1177,1186d1176
<   
< Jython
< 
<   Python interpretor in Java
< 
< XSP
< optional/jython-2.1.jar
< http://www.jython.org
<   
<

Issue
=
Accessing http://localhost:8080/cocoon/samples/blocks/xsp/python/hello generates
the folloing error:

Resource not found
org/python/core/PyObject
org.apache.cocoon.ResourceNotFoundException: org/python/core/PyObject
cause: org.apache.cocoon.ResourceNotFoundException: org/python/core/PyObject

Copying jython-2.1.jar into $TOMCAT_HOME/webapps/cocoon/WEB-INF/lib fixes the
problem.

jar -tf cocoon.war does not show the jar file in cocoon.war


> jython jar not added to war in XSP block on build
> -
>
>  Key: COCOON-1458
>  URL: http://issues.apache.org/jira/browse/COCOON-1458
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: XSP
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: Linux
> Platform: PC
> Reporter: Mark Eggers
> Assignee: Cocoon Developers Team

>
> Environment
> ===
> fedora core 3 linux 2.6.10-1.766_FC3
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
> Tomcat 5.5.7
> 
> jsp
> org.apache.jasper.servlet.JspServlet
> 
> fork
> false
> javac
> 
> 
> xpoweredBy
> false
> 
> 3
> 
> Cocoon
> URL: http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 155211
> Node Kind: directory
> Schedule: normal
> Last Changed Author: sylvain
> Last Changed Rev: 155210
> Last Changed Date: 2005-02-24 09:02:09 -0800 (Thu, 24 Feb 2005)
> Properties Last Updated: 2005-01-24 11:30:14 -0800 (Mon, 24 Jan 2005)
> Build
> =
> Cocoon builds fine under jdk1.5.0_01 with modifications to
> tools/targets/init-build.xml to target the 1.5 jdk.
> 152c152
>  ---
> >target="1.4"
> 178c178
>  ---
> >target="1.4"
> 

[jira] Updated: (COCOON-1523) [PATCH] XSP expressions (attribute value/text interpolation)

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1523:


Bugzilla Id:   (was: 35228)
  Component: Blocks: XSP
 (was: Blocks: (Undefined))
Description: 
In [1] in we discussed an XSP expression syntax for attribute value and text
expressions. This patch makes expressions available.

In XSP, you now can write:
expression
or
Hello #user.getFullName, which will be expanded to Hello
user.getFullName

Writing {##text} will prevent expansion and will be replaced by the text
"{#text}". Inside expressions, write "##" to get "#" and "#}" to get "}".

This works in XSPs as well as logicsheets. The '#' was chosen out of the
discussed characters because it is IMO least likely to occur in an expression in
the used languages.

This feature is turned on by default and can be turned off by setting
"attribute-value-interpolation" or "text-interpolation" to "false" in 
cocon.xconf:



...



It can be turned on or off on a per-XSP-/logicsheet-basis by setting attributes
"attribute-value-interpolation" or "text-interpolation" of the top level element
to true or false. Note that these attributes must belong to the
"http://apache.org/xsp"; namespace.

How it works:

New class XSPExpressionParser is a parser for the expressions. New class
XSPExpressionFilter is a filter that gets SAX events with embedded expressions
and generates SAX events for expanded expressions. This is used in LogicSheet to
filter read logicsheers and in XSPMarkupLanguage to filter the XSP.

Changes to existing code.

LogicSheets need to know the namespace and uri of the markup language in order
to replace expressions. Therefor AbstractMarkupLanguage needs to know this when
reading logicsheets. This meant that I had to move this configuration
information from parametrize to configure. It is unclear to me anyway, why
AbstractMarkupLanguage used both methods at the same time (which are described
as "incompatible" in the Avalon documentation).

The old PreProcessFilter wraps text() nodes in  elements inside some
tags (See [2]). It is unclear to me why this was done, and all XSPs I've tested
worked without this. I got no reponse on the list, so I left this feature out of
the new PreProcessFilter.

If any of the above changes need further discussion, clarification or change,
please tell me and I'll update the patch.

This patch also should be applied to 2.2. If it does not work, again please tell
me and I'll make a 2.2 patch available.

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111693513631888&w=2

[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111778627925208&w=2

  was:
In [1] in we discussed an XSP expression syntax for attribute value and text
expressions. This patch makes expressions available.

In XSP, you now can write:
expression
or
Hello #user.getFullName, which will be expanded to Hello
user.getFullName

Writing {##text} will prevent expansion and will be replaced by the text
"{#text}". Inside expressions, write "##" to get "#" and "#}" to get "}".

This works in XSPs as well as logicsheets. The '#' was chosen out of the
discussed characters because it is IMO least likely to occur in an expression in
the used languages.

This feature is turned on by default and can be turned off by setting
"attribute-value-interpolation" or "text-interpolation" to "false" in 
cocon.xconf:



...



It can be turned on or off on a per-XSP-/logicsheet-basis by setting attributes
"attribute-value-interpolation" or "text-interpolation" of the top level element
to true or false. Note that these attributes must belong to the
"http://apache.org/xsp"; namespace.

How it works:

New class XSPExpressionParser is a parser for the expressions. New class
XSPExpressionFilter is a filter that gets SAX events with embedded expressions
and generates SAX events for expanded expressions. This is used in LogicSheet to
filter read logicsheers and in XSPMarkupLanguage to filter the XSP.

Changes to existing code.

LogicSheets need to know the namespace and uri of the markup language in order
to replace expressions. Therefor AbstractMarkupLanguage needs to know this when
reading logicsheets. This meant that I had to move this configuration
information from parametrize to configure. It is unclear to me anyway, why
AbstractMarkupLanguage used both methods at the same time (which are described
as "incompatible" in the Avalon documentation).

The old PreProcessFilter wraps text() nodes in  elements inside some
tags (See [2]). It is unclear to me why this was done, and all XSPs I've tested
worked without this. I got no reponse on the list, so I left this feature out of
the new PreProcessFilter.

If any of the above changes need further discussion, clarification or change,
please tell me and I'll update the patch.

This patch also should be applied to 2.2. If it does not work, again please tell
me and I'll make a 2.2 patch available.

[1] ht

[jira] Updated: (COCOON-1474) i18n transformer does not work when tags are added via XSL

[Ralph Goers (JIRA)]

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

Ralph Goers updated COCOON-1474:


Bugzilla Id:   (was: 34025)
  Component: * Cocoon Core
 (was: Blocks: (Undefined))
Description: 
I have reproduced this in both Cocoon 2.1.5 and 2.2.0-dev. If  tags
are included in the initial file of a pipeline, the i18n transformer works
great. But if they are added via an XSL transformation, the i18n transfomer no
longer works. In this case, when the  tags are added via an XSL
transform, the logs are recording unbalanced SAX events, and the end output is
not well formed XML. I can reproduce this behavior with  and
 tags. Passing i18n attributes works fine.

An example of the unbalanced SAX events are that when the i18nTransformer is
processing the  elements, the SAX events look like this in the log:

[startElement] uri=,local=i18n:text,raw=i18n:text
[characters] MPT
[endElement] uri=http://apache.org/cocoon/i18n/2.1,local=text,raw=i18n:text

I'm not a SAX expert, but all the other SAX events in my log have the same thing
for startElement and endElement. Further, when it outputs, it looks like this:
MPT
This is not well-formed XML. The i18nTransformer has removed the second
 tag, but not the first, and of course it hasn't translated anything
either.

Here is a test case, so you can reproduce this:

The pipelines:




































Files:

simple.xml:

http://apache.org/cocoon/i18n/2.1";>

  
titletext
  



  MPT

  


simple2.xml

http://apache.org/cocoon/i18n/2.1";>

  
titletext
  



  MPT

  


bugtest.xsl:

http://www.w3.org/1999/XSL/Transform";
xmlns:i18n="http://apache.org/cocoon/i18n/2.1";
xmlns:dir="http://apache.org/cocoon/directory/2.0"; 
exclude-result-prefixes="dir">
























bugtest2.xsl:
http://www.w3.org/1999/XSL/Transform";
xmlns:i18n="http://apache.org/cocoon/i18n/2.1";
xmlns:dir="http://apache.org/cocoon/directory/2.0"; 
exclude-result-prefixes="dir">

























Am I missing something? I can reproduce this in many places, but I've tried to
boil it down to the simplest case I can. Thanks in advance for any advice!

  was:
I have reproduced this in both Cocoon 2.1.5 and 2.2.0-dev. If  tags
are included in the initial file of a pipeline, the i18n transformer works
great. But if they are added via an XSL transformation, the i18n transfomer no
longer works. In this case, when the  tags are added via an XSL
transform, the logs are recording unbalanced SAX events, and the end output is
not well formed XML. I can reproduce this behavior with  and
 tags. Passing i18n attributes works fine.

An example of the unbalanced SAX events are that when the i18nTransformer is
processing the  elements, the SAX events look like this in the log:

[startElement] uri=,local=i18n:text,raw=i18n:text
[characters] MPT
[endElement] uri=http://apache.org/cocoon/i18n/2.1,local=text,raw=i18n:text

I'm not a SAX expert, but all the other SAX events in my log have the same thing
for startElement and endElement. Further, when it outputs, it looks like this:
MPT
This is not well-formed XML. The i18nTransformer has removed the second
 tag, but not the first, and of course it hasn't translated anything
either.

Here is a test case, so you can reproduce this:

The pipelines:




































Files:

simple.xml:

http://apache.org/cocoon/i18n/2.1";>

  
titletext
  



  MPT

  


simple2.xml

http://apache.org/cocoon/i18n/2.1";>

  
titletext
  



  MPT

  


bugtest.xsl:

http://www.w3.org/1999/XSL/Transform";
xmlns:i18n="http://apache.org/cocoon/i18n/2.1";
xmlns:dir="http://apache.org/cocoon/directory/2.0"; 
exclude-result-prefixes="dir">
























bugtest2.xsl:
http://www.w3.org/1999/XSL/Transform";
xmlns:i18n="http://apache.org/cocoon/i18n/2.1";
xmlns:dir="http://apache.org/cocoon/directory/2.0"; 
exclude-result-prefixes="dir">

























Am I missing something? I can reproduce this in many places, but I've tried to
boil it down to the simplest case I can. Thanks in advance for any advice!


> i18n transformer does not work when  tags are added via XSL
> --
>
>  Key: COCOON-1474
>  URL: http://issues.apache.org/jira/browse/COCOON-1474
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.2-dev (Current SVN)
>  Environment: Operating System: Mac OS X 10.3
> Platform: Macintosh
> Reporter: Bess Sadler
> Assignee: Cocoon Developers Team

>
> I have reproduced this in both Cocoon 2.1.5 and 2.2.0-dev. If  tags
> are included in the initial file of a pipeline, the i18n transformer works
> great. But if they are added via an XSL transformation, the i18n transfomer no
> longer works. In

Re: [HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8

[Torsten Curdt]

Please report any issue or showstopper to dev@cocoon.apache.org



The javaflow forms binding example is broken due to a cforms change.
I assume it's an easy fix.

The javaflow OJB example gives a PersistenceBrokerException "Used
ConnectionManager instance could not obtain a connection"

Same problem for the databases block. I assume hsqldb is not working
on the zones installation.

The proxy block "Examples" fails

The JSF block "Documentation for this demo" gives a  
ResourceNotFoundException:

"No pipeline matched request: samples/blocks/faces/cardemo/javadocs"
 - context://samples/blocks/faces/sitemap.xmap - 107:68
I assume the version on zones is built without javadocs?

None of the examples from the Ajax block were working for me.

Seems like the XSLTAL examples always returns XML instead of HTML

Could not create an index on the querybean example

Hope these problems are only zones related *sigh*
Enough testing for tonight.

cheers
--
Torsten


PGP.sig
Description: This is a digitally signed message part

Re: JIRA encoding problem

[Jeff Turner]

On Mon, Oct 24, 2005 at 10:48:29PM +0100, Pier Fumagalli wrote:
> On 24 Oct 2005, at 22:41, Joerg Heinicke wrote:
> > On 24.10.2005 23:34, Pier Fumagalli wrote:
> >
> >
> >>> The JIRA import seems to have a UTF-8 vs. LATIN-1 encoding problem.
> >>>
> >> If you click on the link backs to the original issues, you'll see  
> >> (at  least, that's what I see in my browser) that the data was  
> >> corrupted  by Bugzilla, not by Jira:
> >
> > For me too. If I switch the page to UTF-8 by hand I see the names  
> > correctly. But independent on this: Could not the user change its  
> > name himself? This would make it superfluous to care about this  
> > issue more than necessarily.
> 
> Of course you do... Because they submitted the form subscribing  
> originally in UTF-8, Bugzilla stored it "as is" but that said, it's  
> delivering pages in ISO8859-1...

Bugzilla and Jira use the same MySQL 3.23 database, and MySQL <4.1
doesn't have unicode support. See:

http://issues.apache.org/jira/browse/INFRA-559


--Jeff


> And yes... Users can change their full name (and email) by themselves...
> 
> 
>  Pier
> 

blocks-portal block failure

[Christian]

hi there.
here is the error message that showed up when I tried to open the 
"Portal Block" sample on the live demo page.


good luck,
christian


An error has occured

java.sql.SQLException: Connection is broken: Transfer corrupted

Cocoon stacktrace[hide]
Sitemap: error when calling sub-sitemap
context://samples/blocks/sitemap.xmap - 66:68   
context://samples/sitemap.xmap - 201:65 
context://sitemap.xmap - 890:66 

Java stacktrace[hide]

java.sql.SQLException: Connection is broken: Transfer corrupted
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.jdbcConnection.getAutoCommit(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)
	at 
org.apache.avalon.excalibur.datasource.AbstractJdbcConnection.invoke(AbstractJdbcConnection.java:397)

at $Proxy23.getAutoCommit(Unknown Source)
	at 
org.apache.avalon.excalibur.datasource.JdbcConnectionFactory.newInstance(JdbcConnectionFactory.java:223)
	at 
org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.newPoolable(InstrumentedResourceLimitingPool.java:655)
	at 
org.apache.avalon.excalibur.pool.ValidatedResourceLimitingPool.newPoolable(ValidatedResourceLimitingPool.java:145)
	at 
org.apache.avalon.excalibur.datasource.ResourceLimitingJdbcConnectionPool.newPoolable(ResourceLimitingJdbcConnectionPool.java:91)
	at 
org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.get(InstrumentedResourceLimitingPool.java:371)
	at 
org.apache.avalon.excalibur.pool.ValidatedResourceLimitingPool.get(ValidatedResourceLimitingPool.java:97)
	at 
org.apache.avalon.excalibur.datasource.ResourceLimitingJdbcDataSource.getConnection(ResourceLimitingJdbcDataSource.java:188)
	at 
org.apache.cocoon.ojb.components.ConnectionFactoryImpl.lookupConnection(ConnectionFactoryImpl.java:129)
	at 
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(Unknown 
Source)
	at 
org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStatement(Unknown 
Source)
	at 
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown 
Source)
	at org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown 
Source)

at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown Source)
	at 
org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unknown 
Source)
	at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(Unknown 
Source)
	at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(Unknown 
Source)
	at 
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown 
Source)
	at 
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown 
Source)
	at 
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown 
Source)
	at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknown 
Source)
	at 
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown 
Source)
	at 
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown 
Source)
	at 
org.apache.cocoon.portal.security.DBSecurityHandler.login(DBSecurityHandler.java:50)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)
	at 
org.apache.avalon.excalibur.component.ComponentProxyGenerator$ComponentInvocationHandler.invoke(ComponentProxyGenerator.java:143)

at $Proxy18.login(Unknown Source)
	at 
org.osoco.cowarp.impl.StandardApplicationManager.login(StandardApplicationManager.java:193)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)
	at 
org.apache.avalon.excalibur.component.ComponentProxyGenerator$ComponentInvocationHandler.invoke(ComponentProxyGenerator.java:143)

at $Proxy17.login(Unknown Source)
at org.osoco.cowarp.acting.LoginAction.act(LoginAction.java:61)
	at 
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:119)
	at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
	at 
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:138)
	at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java

RE: [2.1.8 release] all htmlunit tests pass on macosx, how about other platforms?

[Nathaniel Alfred]

>Le 20 oct. 05, à 10:54, Bertrand Delacretaz a écrit :

>> I have fixed a few things so that all htmlunit-tests pass here (JDK 
>> 1.4.2, macosx 10.3.8).
>>
>> It would be cool if people could run these tests on other platforms 
>> and report results here...

>FWIW, I've received a success report off-list, that the tests also pass 
>on winXP / java 1.4.2_09

JDK 1.4.2_09 on SPARC Solaris also passes all htlmunit tests.

Cheers, Alfred.
 
 
This message is for the named person's use only. It may contain confidential, 
proprietary or legally privileged information. No confidentiality or privilege 
is waived or lost by any mistransmission. If you receive this message in error, 
please notify the sender urgently and then immediately delete the message and 
any copies of it from your system. Please also immediately destroy any 
hardcopies of the message. You must not, directly or indirectly, use, disclose, 
distribute, print, or copy any part of this message if you are not the intended 
recipient. The sender's company reserves the right to monitor all e-mail 
communications through their networks. Any views expressed in this message are 
those of the individual sender, except where the message states otherwise and 
the sender is authorised to state them to be the views of the sender's company.

Re: JIRA encoding problem

[Pier Fumagalli]

On 24 Oct 2005, at 22:41, Joerg Heinicke wrote:

On 24.10.2005 23:34, Pier Fumagalli wrote:



The JIRA import seems to have a UTF-8 vs. LATIN-1 encoding problem.

If you click on the link backs to the original issues, you'll see  
(at  least, that's what I see in my browser) that the data was  
corrupted  by Bugzilla, not by Jira:


For me too. If I switch the page to UTF-8 by hand I see the names  
correctly. But independent on this: Could not the user change its  
name himself? This would make it superfluous to care about this  
issue more than necessarily.


Of course you do... Because they submitted the form subscribing  
originally in UTF-8, Bugzilla stored it "as is" but that said, it's  
delivering pages in ISO8859-1...


And yes... Users can change their full name (and email) by themselves...


Pier



smime.p7s
Description: S/MIME cryptographic signature

Re: JIRA encoding problem

[Joerg Heinicke]

On 24.10.2005 23:34, Pier Fumagalli wrote:


The JIRA import seems to have a UTF-8 vs. LATIN-1 encoding problem.


If you click on the link backs to the original issues, you'll see (at  
least, that's what I see in my browser) that the data was corrupted  by 
Bugzilla, not by Jira:


For me too. If I switch the page to UTF-8 by hand I see the names 
correctly. But independent on this: Could not the user change its name 
himself? This would make it superfluous to care about this issue more 
than necessarily.


Jörg

Re: JIRA encoding problem

[Pier Fumagalli]

On 24 Oct 2005, at 22:14, Nathaniel Alfred wrote:


The JIRA import seems to have a UTF-8 vs. LATIN-1 encoding problem.
The reporter field is messed up in
http://issues.apache.org/jira/browse/COCOON-1603
http://issues.apache.org/jira/browse/COCOON-1627

On the hand Jörg is spelled correctly in
http://issues.apache.org/jira/browse/COCOON-1624


If you click on the link backs to the original issues, you'll see (at  
least, that's what I see in my browser) that the data was corrupted  
by Bugzilla, not by Jira:


In the order you specified them:

http://issues.apache.org/bugzilla/show_bug.cgi?id=36718 (is COCOON-1603)
http://issues.apache.org/bugzilla/show_bug.cgi?id=36984 (is COCOON-1627)
http://issues.apache.org/bugzilla/show_bug.cgi?id=36963 (is COCOON-1624)

As you can see, the data was corrupted on entry, so, unfortunately,  
there's not much JIRA can do (it tries to fix other engines bugs, but  
it doesn't always succeed! :-) :-)


Pier





smime.p7s
Description: S/MIME cryptographic signature

Re: treeprocessor doesn't resolve variables in all attributes of sitemap nodes

[Sylvain Wallez]

Marc Portier wrote:

Hi there,

just found out that
 

kept giving me a statuscode 200 no matter what the value of statusCode was.

as it turns out the SerializeNodeBuilder will in it's buildNode do:
  

this.node = new SerializeNode(
type,
VariableResolverFactory.getResolver(config.getAttribute("src", 
null), this.manager),

VariableResolverFactory.getResolver(config.getAttribute("mime-type", null), 
this.manager),
config.getAttributeAsInteger("status-code", -1)
);



which I read as: @src and @mime-type can but @status-code can-not be
resolved from variables

from an end-user POV this difference in handling is quite arbitrary
(meaning: if there are good considerations for this we should document
them well)


other examples of non-resolvable attributes:

  

./ActionSetNodeBuilder.java:"name"

./ActNodeBuilder.java:  "set"
./ActNodeBuilder.java:  "name"
./ActNodeBuilder.java:  "src"

./CallNodeBuilder.java: "resource"
./CallNodeBuilder.java: "function"
./CallNodeBuilder.java: "continuation"

./HandleErrorsNodeBuilder.java: "type"
./HandleErrorsNodeBuilder.java: "when"

./FlowNodeBuilder.java: "language"

./MatchNodeBuilder.java:"pattern"
./MatchNodeBuilder.java:"name"

./MountNodeBuilder.java:"check-reload"
./MountNodeBuilder.java:"pass-through"

./PipelineNodeBuilder.java: "internal-only"

./RedirectToNodeBuilder.java:   "resource"
./RedirectToNodeBuilder.java:   "target"
./RedirectToNodeBuilder.java:   "session"
./RedirectToNodeBuilder.java:   "global"
./RedirectToNodeBuilder.java:   "permanent"

./ReadNodeBuilder.java: "mime-type"
./ReadNodeBuilder.java: "status-code"

./SerializeNodeBuilder.java:"mime-type"
./SerializeNodeBuilder.java:"status-code"

./ScriptNodeBuilder.java:"src"

./SitemapLanguage.java: "logger"
./SitemapLanguage.java: "role"
./SitemapLanguage.java: "class"

./ViewNodeBuilder.java: "from-label"
./ViewNodeBuilder.java: "from-position"




# based on the naieve lookup through
$ cd  src/java/org/apache/cocoon/components/treeprocessor/sitemap/;
$ find -type f |xargs grep 'config\.get' | grep -v '\.svn' | grep -v
VariableResolverFactory > ~/UnresolvedSitemapAttributes.txt


anyone any opinion on these?
  


All attributes that define the sitemap processing flow should be static. 
This was decided to prevent the building of dynamic pipelines, and is 
used by the TreeProcessor to do some build-time optimizations.


These static attributes are mainly the "name" on instructions (that 
choose the component type) and view labels.


The status-code is obviously a good candidate for resolution, and we can 
review all attributes to see what others should be resolved as well.


Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: svn commit: r312968 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/components/source/impl/validity/ src/java/org/apache/cocoon/i18n/ src/java/org/apache/cocoon/transformation/ s

[Sylvain Wallez]

Vadim Gritsenko wrote:

Well I can see that in dev environment you would prefer to get error 
right away, but historically i18n was allowing content editors to push 
broken XML files and site admins to scream on editors, while all other 
users can continue to use older version of a site.


Ah, I see the reason now, even if I disagree with the process :-)

It's better to ensure that files are well-formed before deploying them!



SNFE is used here as a substitute for source.exist(), probably 
because two implementations don't have a proper implementation for 
it. Better fix the implementations or log the exception only if 
source.exists() returns true rather than fill the logs with 
meaningless exceptions.


Won't argue with that. OTOH, there might be broken sources out there 
where even if source.exists() it can still throw SNFE.


You also have to take into an account a situation where source WAS 
existing at the moment of .exists(), but was removed before you 
tried to .getInputStream() it. So, SNFE handling still has to be 
present.


Ok, so what about :

catch (SNFE snfe) {
   if (!source.exists()) {
   getLogger.info("bundle " + source.getURI() + " doesn't exist");
   } else {
   getLogger.info("bundle " + source.getURI() + " is said to 
exist but could not be loaded", sfne);

   }
}

That way, we avoid logging an exception that just says that the 
source doesn't exist, but still log it whenever there is an 
inconsistency between exists() and getInputStream(), whatever its cause.


Deal?


No objections to this one.


Ok, I'll do it.

Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: Jira - How to...?

[Ralph Goers]

Reinhard Poetz wrote:


Ralph Goers wrote:


Pier Fumagalli wrote:

There are already two components: The Portal Block and the 
deprecated  Portal-FW block...



Pier


The table below is what I see (Sorry for the html).  I don't see the 
portal block.



You can't see the component "Portal Block" as no issue has been 
assigned to it yet. Open the issue you want to move, and use the 
"edit" link at the menu on the left.



Thanks. Pier gave me cocoon-developer status and then I was able to make 
some progress.

[HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8

[Sylvain Wallez]

Dear Cocoon users and developers,

We plan to release Cocoon version 2.1.8 at the end of this week, and we 
need the whole Cocoon community to help us ensuring it is rock-solid as 
we expect it to be.


Please download the latest Cocoon:
- checkout the SVN repository (preferred method):
 svn co http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/

- alternately, you can grab the latest snapshot of the repository:
 http://svn.apache.org/snapshots/cocoon-BRANCH_2_1_X/

Then build it, test it, shake it! Go through the various samples, and if 
possible test some of your existing applications with the new version.


If you don't have enough time to do the above, you can also go through 
the samples of the live demo at 
http://cocoon.zones.apache.org/demos/21branch/


Please report any issue or showstopper to dev@cocoon.apache.org

Thanks for your help!

Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

JIRA encoding problem

[Nathaniel Alfred]

The JIRA import seems to have a UTF-8 vs. LATIN-1 encoding problem.
The reporter field is messed up in
http://issues.apache.org/jira/browse/COCOON-1603
http://issues.apache.org/jira/browse/COCOON-1627

On the hand Jörg is spelled correctly in
http://issues.apache.org/jira/browse/COCOON-1624

Cheers, Alfred.
 
 
This message is for the named person's use only. It may contain confidential, 
proprietary or legally privileged information. No confidentiality or privilege 
is waived or lost by any mistransmission. If you receive this message in error, 
please notify the sender urgently and then immediately delete the message and 
any copies of it from your system. Please also immediately destroy any 
hardcopies of the message. You must not, directly or indirectly, use, disclose, 
distribute, print, or copy any part of this message if you are not the intended 
recipient. The sender's company reserves the right to monitor all e-mail 
communications through their networks. Any views expressed in this message are 
those of the individual sender, except where the message states otherwise and 
the sender is authorised to state them to be the views of the sender's company.

Re: Jira - How to...?

[Reinhard Poetz]

Ralph Goers wrote:

Pier Fumagalli wrote:

There are already two components: The Portal Block and the deprecated  
Portal-FW block...



Pier


The table below is what I see (Sorry for the html).  I don't see the 
portal block.


You can't see the component "Portal Block" as no issue has been assigned to it 
yet. Open the issue you want to move, and use the "edit" link at the menu on the 
left.



--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: treeprocessor doesn't resolve variables in all attributes of sitemap nodes

[Vadim Gritsenko]

Carsten Ziegeler wrote:

Vadim Gritsenko wrote:


Yes, I think we should go through all these attributes and see/vote
which ones can be made dynamic.



IIRC, this vote was already done at Cocoon 2.0 times. Substitution for component 
types etc was prohibited on the basis that it makes it easier to implement 
"dynamic pipelines".




Yeah, I know - and that's absolutely ok for component types. But what
about mime-type,
or the some others Marc listed?


I think following attributes can be subject to substitution:

  status-code, mime-type on serialize and read
  src on act
  session, global, permanent on redirect-to

and probably

  pattern on match

as well.


Vadim

Re: svn commit: r312968 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/components/source/impl/validity/ src/java/org/apache/cocoon/i18n/ src/java/org/apache/cocoon/transformation/ s

[Vadim Gritsenko]

Sylvain Wallez wrote:

Vadim Gritsenko wrote:


Sylvain Wallez wrote:


Vadim Gritsenko wrote:


- Bad formed XML files and other serious exceptions are 
semi-silently ignored. By semi-silently, I mean they're just logged 
and don't bubble up higher in the call stack, thus giving the false 
impression that the system works.


Such exceptions must not bubble up upstream: if exception is let 
through, your whole site goes down simply due to single bug in i18n 
catalogue. With existing exception handling, i18n (and your whole 
site) continues functioning with older version of the catalogue, but 
reports an error into the log file (that's what you've got 
monitoring for). That's the i18n behaviour as it was originally 
designed. See "Keep existing loaded values" comment.


Ok. So you mean that i18n allows broken message files to exist?


Exactly.


Wow. I really dislike that.


Well I can see that in dev environment you would prefer to get error right away, 
but historically i18n was allowing content editors to push broken XML files and 
site admins to scream on editors, while all other users can continue to use 
older version of a site.


I would prefer to keep this functionality, but for development environment you 
can make it configurable, by adding a parameter, something like


  false




I guess it takes some getting used to it.


C'mon! What does it mean "getting used to it"? If it's broken, let's fix 
it!! It's too late for 2.1.8, but I'd like this subject to be discussed, 
as it really seems a bad thing to me.


It's not broken; and it can be improved - see above.


More general note - ignored exceptions is the single most frustrating 
experience you can have with Cocoon in particular and Java in general. 
Hence I'm proponent of having the ability to see exception if so desired.


Me too, but in this particular case, most exceptions will just say that 
the source doesn't exists.


Agreed. Hence there is INFO level :-P


SNFE is used here as a substitute for source.exist(), probably 
because two implementations don't have a proper implementation for 
it. Better fix the implementations or log the exception only if 
source.exists() returns true rather than fill the logs with 
meaningless exceptions.


Won't argue with that. OTOH, there might be broken sources out there 
where even if source.exists() it can still throw SNFE.


You also have to take into an account a situation where source WAS 
existing at the moment of .exists(), but was removed before you tried 
to .getInputStream() it. So, SNFE handling still has to be present.


Ok, so what about :

catch (SNFE snfe) {
   if (!source.exists()) {
   getLogger.info("bundle " + source.getURI() + " doesn't exist");
   } else {
   getLogger.info("bundle " + source.getURI() + " is said to exist 
but could not be loaded", sfne);

   }
}

That way, we avoid logging an exception that just says that the source 
doesn't exist, but still log it whenever there is an inconsistency 
between exists() and getInputStream(), whatever its cause.


Deal?


No objections to this one.

Vadim

Test cocoon 2.1.8-rc1

[Felix Knecht]

Dear all

The following samples of the Mail Block sample do not work:

http://cocoon.zones.apache.org/demos/21branch/samples/blocks/mail/mail/index.html
http://cocoon.zones.apache.org/demos/21branch/docs/userdocs/actions/sendmail-action.html
http://cocoon.zones.apache.org/demos/21branch/docs/userdocs/xsp/sendmail.html


Maybe I was to early with testing (tonight ;-)
Regards
Felix

Re: [IMP] Code freeze starts tonight

[Carsten Ziegeler]

Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> 
>>Ralph Goers wrote:
>>  
>>
>>>Out of curiosity, when exactly does "tonight" begin?
>>>
>>>
>>
>>Sorry, overlooked this one... :)
>>
>>"tonight" meant the end of the day, MET - will be more specific next time.
>>  
> 
> 
> We should also make an annouce that this is the testing week and invite 
> people to checkout the SVN and test. Otherwise, people will just hold 
> their breath and wait for the release to happen.
> 
> I can do it if you want.
> 
Yes, please do it and thanks, Sylvain.

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

Re: [IMP] Code freeze starts tonight

[Bertrand Delacretaz]

Le 24 oct. 05, à 21:24, Sylvain Wallez a écrit :

..We should also make an annouce that this is the testing week and 
invite people to checkout the SVN and test. Otherwise, people will 
just hold their breath and wait for the release to happen.


I can do it if you want...


If you do, please also mention that people can also test at 
http://cocoon.zones.apache.org/demos/21branch/


-Bertrand

Re: [IMP] Code freeze starts tonight

[Sylvain Wallez]

Carsten Ziegeler wrote:

Ralph Goers wrote:
  

Out of curiosity, when exactly does "tonight" begin?



Sorry, overlooked this one... :)

"tonight" meant the end of the day, MET - will be more specific next time.
  


We should also make an annouce that this is the testing week and invite 
people to checkout the SVN and test. Otherwise, people will just hold 
their breath and wait for the release to happen.


I can do it if you want.

Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: Identifier used in FragmentExtractorTransformer

[Joerg Heinicke]

On 24.10.2005 08:50, Bart Molenkamp wrote:


So what is your solution? I can't find it in the mail archive...


They are added as comments to the bug which can now be found at Jira:
http://issues.apache.org/jira/browse/COCOON-1148

Jörg


Van: Joerg Heinicke
Verzonden: vrijdag 21 oktober 2005 23:14


How is this problem related to caching? It is not that hard for me to
provide a patch which just generates a new identifier, but I'm wondering
if it breaks caching...


It is related to caching as the cache key is only based on the request
uri and the fragment id. So with always the same uri and id you will
always get the same content from the cache.

Unfortunately nobody ever responded to my proposals about fixing it.

Jörg

Re: JIRA: let me know your Jira user names...

[Joerg Heinicke]

On 24.10.2005 18:34, Pier Fumagalli wrote:


Please,
let me know your preferred Jira accounts, some of them have been  
duplicated in the import as you've used different email accounts in  
Bugzilla and Jira when registering.


I want to go through and de-dupe the accounts and make sure that  y'all 
have the correct rights to work on our Cocoon Jira project...


Could it be that there are two accounts for me? One created by hand long 
time ago and another one now imported? But both should run on the same 
email address.


Jörg

Re: calling special ant task for javaflow block

[Torsten Curdt]

the javaflow needs to instrument classes at build
time. There is an ant task that needs to be called.
TBH I am not quite sure where and how to hook that
into the current build system best.



Which ant task is this? I'm asking because we would want to do this in
the maven build as well.


This is from the javaflow maven.xml

  


  
  


  
classname="org.apache.commons.javaflow.ant.AntRewriteTask"

 classpathref="rewrite.classpath"
 />


  
**/*Flow*.java
  


  

There is still a bug in the pattern matching code.
But I suspect that's a minor thing.

cheers
--
Torsten


PGP.sig
Description: This is a digitally signed message part

Re: [M10N] new pom structure

[Carsten Ziegeler]

Jorg Heymans wrote:
> I've just commited a new pom structure for the forms block. It looks
> like this
> 
> src/blocks/
>pom.xml  --> contains all block modules
>/forms
>pom.xml  --> modules for this block + all lib dependencies
>/trunk
>pom.xml  --> implementation, depends on ../pom.xml
>/samples
>  pom.xml  --> sample related stuff, depends on impl
>/test
> 
> 
> Once we've finalized the pom and block directory structure i'll convert
> the rest of the blocks, no point in doing every step for all 60 blocks.
> 
Hmm, shouldn't "/forms/pom.xml" also be versioned? It might be that a
branch has different modules than trunk, I think.
I'm all for a unified directory layout where possible. I can imagine
some blocks will not fit into this. For example the portal block will
consist of several modules (core, portlet support, wsrp support, castor
support, db support and so on), and perhaps several samples. But I think
with m2 and the hierarchy of poms this doesn't really matter.


> Further, the root pom now only has following modules :
> 
> core
> core/test-core
> webapp
> src/blocks
> src/mocks
> 
> There is another multi-module pom in src/blocks that contains all the
> block modules then.
> 
Great

Carsten

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

[M10N] new pom structure

[Jorg Heymans]

I've just commited a new pom structure for the forms block. It looks
like this

src/blocks/
   pom.xml  --> contains all block modules
   /forms
   pom.xml  --> modules for this block + all lib dependencies
   /trunk
   pom.xml  --> implementation, depends on ../pom.xml
   /samples
 pom.xml  --> sample related stuff, depends on impl
   /test


Once we've finalized the pom and block directory structure i'll convert
the rest of the blocks, no point in doing every step for all 60 blocks.

Further, the root pom now only has following modules :

core
core/test-core
webapp
src/blocks
src/mocks

There is another multi-module pom in src/blocks that contains all the
block modules then.


Regards
Jorg

Re: [IMP] Code freeze starts tonight

[Carsten Ziegeler]

Ralph Goers wrote:
> Out of curiosity, when exactly does "tonight" begin?
> 
Sorry, overlooked this one... :)

"tonight" meant the end of the day, MET - will be more specific next time.

Carsten

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

Re: calling special ant task for javaflow block

[Jorg Heymans]

Torsten Curdt wrote:
> 
> the javaflow needs to instrument classes at build
> time. There is an ant task that needs to be called.
> TBH I am not quite sure where and how to hook that
> into the current build system best.

Which ant task is this? I'm asking because we would want to do this in
the maven build as well.

Thanks
Jorg

HSQLDB broken on the zone

[Sylvain Wallez]

Hi all,

Up to now, I couldn't see the SQL samples running on the zone. It says :

java.sql.SQLException: Connection is broken: Transfer corrupted
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.jdbcConnection.getAutoCommit(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.apache.avalon.excalibur.datasource.AbstractJdbcConnection.invoke(AbstractJdbcConnection.java:397)


Any hint?

Thanks,
Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: svn commit: r312968 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/components/source/impl/validity/ src/java/org/apache/cocoon/i18n/ src/java/org/apache/cocoon/transformation/ s

[Sylvain Wallez]

Vadim Gritsenko wrote:

Sylvain Wallez wrote:

Vadim Gritsenko wrote:


- Bad formed XML files and other serious exceptions are 
semi-silently ignored. By semi-silently, I mean they're just logged 
and don't bubble up higher in the call stack, thus giving the false 
impression that the system works.



Such exceptions must not bubble up upstream: if exception is let 
through, your whole site goes down simply due to single bug in i18n 
catalogue. With existing exception handling, i18n (and your whole 
site) continues functioning with older version of the catalogue, but 
reports an error into the log file (that's what you've got 
monitoring for). That's the i18n behaviour as it was originally 
designed. See "Keep existing loaded values" comment.



Ok. So you mean that i18n allows broken message files to exist?


Exactly.


Wow. I really dislike that.

This is contradictory with *all* other hot-reload behaviours in 
Cocoon: if an XSLT, a template or sitemap are modified and are 
malformed, an error is raised and bubbles up (yes, potentially 
breaking the whole system). We don't use the cached version of the 
file if reload fails.


That's why I find the way i18n handles this very strange. Or does it 
mean message dictionaries are not considered on an equal stand with 
other application files, and are allowed to be buggy and changed live 
on the production server without testing beforehand? This really 
doesn't sound good to me...


I guess it takes some getting used to it.


C'mon! What does it mean "getting used to it"? If it's broken, let's fix 
it!! It's too late for 2.1.8, but I'd like this subject to be discussed, 
as it really seems a bad thing to me.




More general note - ignored exceptions is the single most frustrating 
experience you can have with Cocoon in particular and Java in general. 
Hence I'm proponent of having the ability to see exception if so desired.


Me too, but in this particular case, most exceptions will just say that 
the source doesn't exists.


SNFE is used here as a substitute for source.exist(), probably 
because two implementations don't have a proper implementation for 
it. Better fix the implementations or log the exception only if 
source.exists() returns true rather than fill the logs with 
meaningless exceptions.


Won't argue with that. OTOH, there might be broken sources out there 
where even if source.exists() it can still throw SNFE.


You also have to take into an account a situation where source WAS 
existing at the moment of .exists(), but was removed before you tried 
to .getInputStream() it. So, SNFE handling still has to be present.


Ok, so what about :

catch (SNFE snfe) {
   if (!source.exists()) {
   getLogger.info("bundle " + source.getURI() + " doesn't exist");
   } else {
   getLogger.info("bundle " + source.getURI() + " is said to exist 
but could not be loaded", sfne);

   }
}

That way, we avoid logging an exception that just says that the source 
doesn't exist, but still log it whenever there is an inconsistency 
between exists() and getInputStream(), whatever its cause.


Deal?

Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: treeprocessor doesn't resolve variables in all attributes of sitemap nodes

[Carsten Ziegeler]

Vadim Gritsenko wrote:
>>Yes, I think we should go through all these attributes and see/vote
>>which ones can be made dynamic.
> 
> 
> IIRC, this vote was already done at Cocoon 2.0 times. Substitution for 
> component 
> types etc was prohibited on the basis that it makes it easier to implement 
> "dynamic pipelines".
> 
Yeah, I know - and that's absolutely ok for component types. But what
about mime-type,
or the some others Marc listed?

Carsten


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

calling special ant task for javaflow block

[Torsten Curdt]

Guys,

the javaflow needs to instrument classes at build
time. There is an ant task that needs to be called.
TBH I am not quite sure where and how to hook that
into the current build system best.

Any pointers are welcome...

cheers
--
Torsten


PGP.sig
Description: This is a digitally signed message part

Re: [JIRA] Migration complete...

[Sander Temme]

On Oct 24, 2005, at 10:16 AM, Pier Fumagalli wrote:


On 24 Oct 2005, at 12:46, Bertrand Delacretaz wrote:


Le 24 oct. 05, à 13:38, Patrick Ahles a écrit :


...Just to let you know, you are aware of the fact that a lot of  
links in

http://cocoon.apache.org/2.1/index.html and below still point to
Bugzilla?..




Yes, but we can run script to add a link like

http://issues.apache.org/jira/bugzillasearch.jsp?id=8017

as a comment in each bugzilla issue, to point to the new issue in  
jira. We need this as there are many links to bugzilla issues out  
there.


I hope to do this later this week unless someone beats me to it  
(Pier: this will need deactivating the "closed for bug entry" flag  
in bugzilla temporarily, either you can tell me how to do it or  
I'll ask for it).


The 'Closed for Bug Entry' flag only affects the possibility to add  
new bugs, not to change existing ones.


Currently, "Cocoon 1" is open for entry in Bugzilla, "Cocoon 2" is  
closed.


I want to have that as well, but I thought that if we run it for  
something like 1655 bugs (there are that many in Bugzilla ATM),  
will mean that at least 3310 emails to the mailing list, all people  
on CC, all reporters, EVERYONE...


That's huge spam...


Yes, that would be unfortunate.

I asked on IRC today if someone knew how to add a comment and then  
close bugs in bugzilla WITHOUT generating any email, and probably  
SCTemme can help, but this morning he was not there...


We can poke directly into the MySQL database, but I want to do that  
MySELF.


S.

CCing infrastructure to keep them in the loop, does anyone know  
howto??


Pier





--
[EMAIL PROTECTED]  http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF



smime.p7s
Description: S/MIME cryptographic signature

Re: [JIRA] Migration complete...

[Pier Fumagalli]

On 24 Oct 2005, at 18:29, Sander Temme wrote:

On Oct 24, 2005, at 10:16 AM, Pier Fumagalli wrote:

On 24 Oct 2005, at 12:46, Bertrand Delacretaz wrote:

Le 24 oct. 05, à 13:38, Patrick Ahles a écrit :

...Just to let you know, you are aware of the fact that a lot of  
links in

http://cocoon.apache.org/2.1/index.html and below still point to
Bugzilla?..


Yes, but we can run script to add a link like

http://issues.apache.org/jira/bugzillasearch.jsp?id=8017

as a comment in each bugzilla issue, to point to the new issue in  
jira. We need this as there are many links to bugzilla issues out  
there.


I hope to do this later this week unless someone beats me to it  
(Pier: this will need deactivating the "closed for bug entry"  
flag in bugzilla temporarily, either you can tell me how to do it  
or I'll ask for it).


The 'Closed for Bug Entry' flag only affects the possibility to add  
new bugs, not to change existing ones.


Currently, "Cocoon 1" is open for entry in Bugzilla, "Cocoon 2" is  
closed.


Yes, we only migrated Cocoon 2, not Cocoon 1

I want to have that as well, but I thought that if we run it for  
something like 1655 bugs (there are that many in Bugzilla ATM),  
will mean that at least 3310 emails to the mailing list, all  
people on CC, all reporters, EVERYONE...


That's huge spam...


Yes, that would be unfortunate.


Extremely much so...

I asked on IRC today if someone knew how to add a comment and then  
close bugs in bugzilla WITHOUT generating any email, and probably  
SCTemme can help, but this morning he was not there...


We can poke directly into the MySQL database, but I want to do that  
MySELF.


I have the MySQL "readbugs" readonly access, so I can poke around the  
DB and see what's to do. But unfortunately I don't have an account on  
AJAX, and therefore cannot connect to the DB...


Can someone help?

Pier




smime.p7s
Description: S/MIME cryptographic signature

Re: [JIRA] Migration complete...

[Pier Fumagalli]

On 24 Oct 2005, at 12:46, Bertrand Delacretaz wrote:

Le 24 oct. 05, à 13:38, Patrick Ahles a écrit :

...Just to let you know, you are aware of the fact that a lot of  
links in

http://cocoon.apache.org/2.1/index.html and below still point to
Bugzilla?..



Yes, but we can run script to add a link like

http://issues.apache.org/jira/bugzillasearch.jsp?id=8017

as a comment in each bugzilla issue, to point to the new issue in  
jira. We need this as there are many links to bugzilla issues out  
there.


I hope to do this later this week unless someone beats me to it  
(Pier: this will need deactivating the "closed for bug entry" flag  
in bugzilla temporarily, either you can tell me how to do it or  
I'll ask for it).


I want to have that as well, but I thought that if we run it for  
something like 1655 bugs (there are that many in Bugzilla ATM), will  
mean that at least 3310 emails to the mailing list, all people on CC,  
all reporters, EVERYONE...


That's huge spam...

I asked on IRC today if someone knew how to add a comment and then  
close bugs in bugzilla WITHOUT generating any email, and probably  
SCTemme can help, but this morning he was not there...


CCing infrastructure to keep them in the loop, does anyone know howto??

Pier



smime.p7s
Description: S/MIME cryptographic signature

Re: [JIRA] Migration complete...

[Bertrand Delacretaz]

Le 24 oct. 05, à 13:38, Patrick Ahles a écrit :

...Just to let you know, you are aware of the fact that a lot of links 
in

http://cocoon.apache.org/2.1/index.html and below still point to
Bugzilla?..


Yes, but we can run script to add a link like

http://issues.apache.org/jira/bugzillasearch.jsp?id=8017

as a comment in each bugzilla issue, to point to the new issue in jira. 
We need this as there are many links to bugzilla issues out there.


I hope to do this later this week unless someone beats me to it (Pier: 
this will need deactivating the "closed for bug entry" flag in bugzilla 
temporarily, either you can tell me how to do it or I'll ask for it).


-Bertrand

Re: [2.1.8 release] all htmlunit tests pass on macosx, how about other platforms?

[Bertrand Delacretaz]

Le 20 oct. 05, à 10:54, Bertrand Delacretaz a écrit :

I have fixed a few things so that all htmlunit-tests pass here (JDK 
1.4.2, macosx 10.3.8).


It would be cool if people could run these tests on other platforms 
and report results here...


FWIW, I've received a success report off-list, that the tests also pass 
on winXP / java 1.4.2_09


-Bertrand

Re: JIRA: let me know your Jira user names...

[Pier Fumagalli]

On 24 Oct 2005, at 17:53, Bertrand Delacretaz wrote:

Le 24 oct. 05, à 18:34, Pier Fumagalli a écrit :


...let me know your preferred Jira accounts..


Either [EMAIL PROTECTED] or [EMAIL PROTECTED],  
whatever's most convenient for you.


K... And this time I'll try to avoid the spamming! :-D

Pier



smime.p7s
Description: S/MIME cryptographic signature

[jira] Assigned: (COCOON-1359) Portal: attributes not set for local JSR-168 portlets

[Pier Fumagalli (JIRA)]

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

Pier Fumagalli reassigned COCOON-1359:
--

Assign To: Ralph Goers  (was: Ralph Goers)

> Portal: attributes not set for local JSR-168 portlets
> -
>
>  Key: COCOON-1359
>  URL: http://issues.apache.org/jira/browse/COCOON-1359
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: (Undefined)
> Versions: 2.1.6
>  Environment: Operating System: All
> Platform: All
> Reporter: Ralph Goers
> Assignee: Ralph Goers

>
> Cocoon does not set values for attributes "javax.portlet.request" and
> "javax.portlet.response" for JSR-168 portlets running in the Cocoon webapp. 
> This
> is required by the JSR-168 specification.

-- 
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, trunk and branch now run on cocoon.zone

[Bertrand Delacretaz]

Le 24 oct. 05, à 13:14, hepabolu a écrit :

...Great idea and thanks for the work, but there are currently two  
issues:


- "core documentation" on  
http://cocoon.zones.apache.org/demos/21branch/samples/ results in an  
error:


java.io.FileNotFoundException:  
/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/docs/ 
sitemap.xmap (No such file or directory)


Thanks for the report - I have removed (in SVN, will be on the zone at  
the next scheduled update) the "core documentation" link on  
http://cocoon.zones.apache.org/demos/21branch/samples/ as the docs are  
not part of the build anymore.



- http://cocoon.zones.apache.org/demos/trunk/

results in:

HTTP ERROR: 404 %2Fdemos%2Ftrunk%2F+Not+Found


That's because the trunk build failed on the last update:

Compiling 685 source files to  
/home/cdemos/demos/trunk/trunk/build/cocoon/classes
/home/cdemos/demos/trunk/trunk/src/java/org/apache/cocoon/components/ 
blocks/BlockWiring.java:193: ';' expected

" and " + this.location + " error: " + e.getMessage());

That's the beauty of continuous integration: these demos will be broken  
when the builds are broken - so the build must be fixed for this to  
start working again.


FYI, people who have access to the zone, the logs of these demos are  
found in /home/cdemos/demos/NNN/logs where NNN is the demo name, like  
"trunk" in this case.


-Bertrand

[jira] Updated: (COCOON-1239) [Patch] don't compile sample sources if samples have been disabled

[Pier Fumagalli (JIRA)]

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

Pier Fumagalli updated COCOON-1239:
---

Reporter: Ralph Goers  (was: Ralph Goers)

> [Patch] don't compile sample sources  if samples have been disabled
> ---
>
>  Key: COCOON-1239
>  URL: http://issues.apache.org/jira/browse/COCOON-1239
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.5
>  Environment: Operating System: All
> Platform: All
> Reporter: Ralph Goers
> Assignee: Cocoon Developers Team
>  Attachments: 30738.patch
>
> Patch to blocks-build.xsl that causes sample source to not be compiled when 
> webapp samples have been disabled.

-- 
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-1020) Allow the Authentication Framework to invoke a pipeline during logout

[Pier Fumagalli (JIRA)]

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

Pier Fumagalli updated COCOON-1020:
---

Reporter: Ralph Goers  (was: Ralph Goers)

> Allow the Authentication Framework to invoke a pipeline during logout
> -
>
>  Key: COCOON-1020
>  URL: http://issues.apache.org/jira/browse/COCOON-1020
>  Project: Cocoon
> Type: Bug
>   Components: * Cocoon Core
> Versions: 2.1.3
>  Environment: Operating System: All
> Platform: All
> Reporter: Ralph Goers
> Assignee: Cocoon Developers Team
>  Attachments: authfw-patch.diff
>
>  

-- 
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-1145) [PATCH] Allow XConfToolTask to modify multiple attributes

[Pier Fumagalli (JIRA)]

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

Pier Fumagalli updated COCOON-1145:
---

Reporter: Ralph Goers  (was: Ralph Goers)

> [PATCH] Allow XConfToolTask to modify multiple attributes
> -
>
>  Key: COCOON-1145
>  URL: http://issues.apache.org/jira/browse/COCOON-1145
>  Project: Cocoon
> Type: Improvement
>   Components: * Cocoon Core
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: All
> Reporter: Ralph Goers
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Attachments: patch-28704.diff
>
> The attached patch allows XConfToolTask to modify multiple attributes in a
> single file. This is very useful in updating the pool parameters. 
> The immplemmentation requires that attributes names start with 
> "add-attribute-".
> What follows the '-' is the attribute name. The value specified for this will
> become the value of the attribute.  For example, the following will modify the
> pool-max, pool-min, and pool-grow attributes on the file generator.  In
> addition, it suppresses the comments that would normally be inserted. This is
> useful when several patches are applied, some of which add new content while
> some only modify attributes.
>add-attribute-pool-max="100" add-attribute-pool-min="25"
>   add-attribute-pool-grow="5" add-comments="false"
>   />

-- 
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-1264) [PATCH] Portal - generate navigation for non-selected tabs

[Pier Fumagalli (JIRA)]

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

Pier Fumagalli updated COCOON-1264:
---

Reporter: Ralph Goers  (was: Ralph Goers)

> [PATCH] Portal - generate navigation for non-selected tabs
> --
>
>  Key: COCOON-1264
>  URL: http://issues.apache.org/jira/browse/COCOON-1264
>  Project: Cocoon
> Type: Improvement
>   Components: Blocks: (Undefined)
> Versions: 2.1.8-dev (Current SVN)
>  Environment: Operating System: All
> Platform: All
> Reporter: Ralph Goers
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Attachments: 31229.patch, 31229c.patch, 31229e.patch
>
> The supplied patch generates named-items when the tab-content aspect is
> configured to do so. Adding  value="child-tab-layout"/> will cause tabs which are not selected to have 
> their
> sub-navigation items appear as named-item elements within a child-tab-layout
> element.  
> This patch allows drop-down lists to be generated for the non-selected tabs.

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