Re: [M10N] new pom structure
Reinhard Poetz wrote: Jorg, could you show us a concrete example how this directory structure will look like (where is block.xml, the root-sitemap, BLOCK-INF, the compiled classes, the JARs, ...)? Yes I'll cook something up in the whiteboard. Jorg
Re: [HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8
Pier Fumagalli wrote: Can't see the stacktraces... It works on mine! :-P (And I can't disable AWT, as I'm on OS/X) Well, looking at [1], bcel is using java.awt.Color to do graph coloring. Though I don't understand much about graph coloring in general, I feel that they could've done with some integer constants representing colors rather than using the actual Color class. I've installed X on my server and started in headless mode, the javaflow samples work now. [1] http://svn.apache.org/viewcvs.cgi/jakarta/bcel/trunk/src/java/org/apache/bcel/verifier/structurals/Subroutines.java?rev=292117view=markup
Re: [HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8
Le 25 oct. 05, à 01:29, Torsten Curdt a écrit : ...The javaflow OJB example gives a PersistenceBrokerException Used ConnectionManager instance could not obtain a connection... These database issues were fixed yesterday by Sylvain (thanks!), the demos were all trying to run hsqldb on the same port. Same problem for the databases block. I assume hsqldb is not working on the zones installation. should be fixed as well. The proxy block Examples fails The JSF block Documentation for this demo gives a ResourceNotFoundException: No pipeline matched request: samples/blocks/faces/cardemo/javadocs map:mount - 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 fixed, serializer type was wrong, I'm updating the zone right now Could not create an index on the querybean example Hope these problems are only zones related *sigh*.. I haven't tested except where indicated. -Bertrand
Re: [HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8
Le 25 oct. 05, à 12:14, Pier Fumagalli a écrit : On 25 Oct 2005, at 10:08, Jeroen Reijn wrote: - CAPTCHA validation sample is does not make sense. There is no string shown on the right. http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/ captcha/ Uh... That's a 500: HTTP ERROR: 500 Internal Server Error Fixed by running the zone demos with -Djava.awt.headless=true as suggested, thanks! Can someone add me to the users in the zone, so that I can check what's wrong with it? useradd pier done, including auto_home setup as per http://www.apache.org/dev/solaris-zones.html -Bertrand
Reverting the property search order in CoreUtils
Hi all,
Trying to set the hslqdb server port using the property lookup system in
trunk, I found that the lookup order actually makes it not much useful.
From what I understand, the properties files are read in the following
order:
- WEB-INF/properties/*
- WEB-INF/properties/{run-mode}/*
- custom property providers (where are they defined?)
- work directory and logkit config from web.xml
- an optional user-specific property file, either pointed to by the
org.apache.cocoon.setting property, or the
~/.cocoon/settings.properties file
- system properties.
Cool, even if it would be good to extend lookup in web.xml to any
servlet and/or context parameter (some admins will want to configure
everything using their J2EE deployment tools).
Now the problem comes from the property search order, which follows the
exact same path, meaning the most generic properties (in
WEB-INF/properties) hide any overriding in specific properties (user
settings, system properties).
I reverted the property lookup order, and this now works just fine :-)
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8
On 26 Oct 2005, at 10:31, Bertrand Delacretaz wrote: useradd pier done, including auto_home setup as per http://www.apache.org/dev/solaris-zones.html done vadim as well - as he asked for this many moons ago /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: [HEADS-UP] Testers wanted for the upcoming Cocoon 2.1.8
Can't see the stacktraces... It works on mine! :-P (And I can't disable AWT, as I'm on OS/X) Well, looking at [1], bcel is using java.awt.Color to do graph coloring. Though I don't understand much about graph coloring in general, I feel that they could've done with some integer constants representing colors rather than using the actual Color class. Don't get me started on what could have been done differently ...well, *better* in BCEL :-P I've installed X on my server and started in headless mode, the javaflow samples work now. Thanks for the testing cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: HSQLDB broken on the zone
Sylvain Wallez wrote: 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? Fixed. The 3 Cocoon instances running on the zone were using the same port (9002) for the HSQL server. I made the port configurable using a new entry in build.properties for 2.1, and the property lookup system in trunk. The 2.1.7 demo has no way to change the port, so it uses 9002. Database demos are now running smoothly :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[jira] Created: (COCOON-1661) Portal Sample broken : SQLException
Portal Sample broken : SQLException --- Key: COCOON-1661 URL: http://issues.apache.org/jira/browse/COCOON-1661 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Philippe Gassmann Priority: Blocker An exception occurs when trying to load the portal sample : 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 $Proxy22.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.init(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
[jira] Commented: (COCOON-1661) Portal Sample broken : SQLException
[ http://issues.apache.org/jira/browse/COCOON-1661?page=comments#action_12355954 ] Bertrand Delacretaz commented on COCOON-1661: - It works for me at http://cocoon.zones.apache.org/demos/21branch/samples/blocks/portal/portal which runs the latest SVN code from this morning, are you seeing something different? Portal Sample broken : SQLException --- Key: COCOON-1661 URL: http://issues.apache.org/jira/browse/COCOON-1661 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Philippe Gassmann Priority: Blocker An exception occurs when trying to load the portal sample : 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 $Proxy22.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.init(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
[jira] Commented: (COCOON-1661) Portal Sample broken : SQLException
[ http://issues.apache.org/jira/browse/COCOON-1661?page=comments#action_12355956 ] Philippe Gassmann commented on COCOON-1661: --- Yes, I'm seeing this exception with the today 1:00pm svn after a clean and build : I ran the following commands on my terminal : svn up ./build.sh clean ./build.sh ./cocoon.sh servlet after that I go to http://localhost:/samples/blocks/portal/ And I can't see the portal, just this exception. Portal Sample broken : SQLException --- Key: COCOON-1661 URL: http://issues.apache.org/jira/browse/COCOON-1661 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Philippe Gassmann Priority: Blocker An exception occurs when trying to load the portal sample : 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 $Proxy22.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.init(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
[jira] Closed: (COCOON-1661) Portal Sample broken : SQLException
[ http://issues.apache.org/jira/browse/COCOON-1661?page=all ] Sylvain Wallez closed COCOON-1661: -- Resolution: Fixed The problem was because the 3 Cocoon versions running on the zone where using the same port number for the hsqldb server. This is now fixed, and each instance uses a different port number Portal Sample broken : SQLException --- Key: COCOON-1661 URL: http://issues.apache.org/jira/browse/COCOON-1661 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Philippe Gassmann Priority: Blocker An exception occurs when trying to load the portal sample : 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 $Proxy22.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.init(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
[jira] Created: (COCOON-1662) Portal basket ample does not work well with uploaded items
Portal basket ample does not work well with uploaded items -- Key: COCOON-1662 URL: http://issues.apache.org/jira/browse/COCOON-1662 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN), 2.1.7 Reporter: Philippe Gassmann It seems not to be possible to view or download an uploaded file in the basket sample : when I try to view, it just write in the Content coplet : The item is not XML. This is true, but it should be possible to download this file even it is not 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] Commented: (COCOON-1661) Portal Sample broken : SQLException
[ http://issues.apache.org/jira/browse/COCOON-1661?page=comments#action_12355959 ] Sylvain Wallez commented on COCOON-1661: Sorry, by reading Bertrand's comment, I thought it was about the zone, which is now fixed. No it happens that you had the same exact problem on your PC :-) (Philppe is sitting about 10 meters away from me) Portal Sample broken : SQLException --- Key: COCOON-1661 URL: http://issues.apache.org/jira/browse/COCOON-1661 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Philippe Gassmann Priority: Blocker An exception occurs when trying to load the portal sample : 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 $Proxy22.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.init(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)
[docs] Updating Daisy on the zone (again)
Hi, I'd like to update the Daisy on the zone again (now to version 1.4-M2, last time was to an SVN snapshot) which fixes some problems. I propose to do that today at 16 pm CEST. The server will be down for a few seconds, and editing sessions will be interrupted. I'll give a notice when it's done. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
[jira] Commented: (COCOON-1658) Somewhere output is held...
[ http://issues.apache.org/jira/browse/COCOON-1658?page=comments#action_12355965 ] Vadim Gritsenko commented on COCOON-1658: - (where is reply button in jira?) So, my question is why is the buffer right now set to unlimited? Is there any specific caveat for this? If you are using caching pipeline then complete response will have to be buffered in any case. For non caching pipelines, complete response will have to be buffered if serializer requires content length to be set. For all other cases... I think this outputBuffer is not really needed. Somewhere output is held... --- Key: COCOON-1658 URL: http://issues.apache.org/jira/browse/COCOON-1658 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Reporter: Pier Fumagalli Priority: Critical Cocoon standard, as of right now, built without any blocks. I modify the default sitemap adding one simple entry: map:match pattern=bigtest map:generate src=bigtest.xml/ map:serialize type=xml/ /map:match The file bigtest.xml is a 100Mb XML file that I simply want to generate and serialize (minimal test, no transformers that can do anything weird). I then open my terminal and do a curl http://localhost:/bigtest /dev/null, to have an idea of the thrughput for this file. Apparently, the output is held for roughly 25 seconds, nothing comes out, no bytes are serialized. All of a sudden, the entire 100 megabytes are serialized in one big lump (and it takes 5 seconds to do so). This happens if the pipeline is configured as being caching or noncaching (nothing changes). In the first 25 seconds, the JVM running Cocoon uses 100% of my processor (so, it's doing something), and the TOP shows something _really_ strange. My JVM grows of roughly 200 megabytes in size (note, I start Cocoon, post the big request, close cocoon). This is a trace from my TOP: PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE - 12498 java 0.1% 0:03.01 19 357 240 25.1M 28.7M 25.4M 735M 12498 java87.2% 0:06.22 19 403 242 54.2M+ 28.7M 55.1M+ 735M- 12498 java75.7% 0:10.88 19 403 242 78.3M 28.7M 79.2M 735M 12498 java80.2% 0:14.78 19 403 242 129M 28.7M 130M 735M 12498 java84.3% 0:19.77 19 403 242 168M+ 28.7M 169M+ 735M 12498 java77.4% 0:23.67 19 403 242 231M 28.7M 232M 735M 12498 java40.7% 0:27.92 19 403 242 231M+ 28.7M 232M+ 735M+ 12498 java 0.1% 0:28.18 20 408 245 231M 28.7M 232M 735M Something tells me that we are indeed caching all the content in a big char[] (100 megabytes of US-ASCII text are 200 megabytes when stored in a char[]). Any clue on where this can happen? It's impairing our ability to serve bigger feeds (aka, 2 gigs! :-P) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (COCOON-1658) Somewhere output is held...
On 26 Oct 2005, at 13:58, Vadim Gritsenko (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1658? page=comments#action_12355965 ] Vadim Gritsenko commented on COCOON-1658: - (where is reply button in jira?) You normally can reply to the sender addess of the confirmation message, but that's not yet enabled in the ASF infrastructure... Pier smime.p7s Description: S/MIME cryptographic signature
Re: [docs] Updating Daisy on the zone (again)
On Wed, 2005-10-26 at 14:58 +0200, Bruno Dumon wrote: Hi, I'd like to update the Daisy on the zone again (now to version 1.4-M2, last time was to an SVN snapshot) which fixes some problems. I propose to do that today at 16 pm CEST. The server will be down for a few seconds, and editing sessions will be interrupted. I'll give a notice when it's done. almost forgot about it... done now. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] flow machinery
Sylvain Wallez wrote: Torsten Curdt wrote: Gang, there are a few things regarding the current flow machinery that are bugging me for quite a while now. In order to support flow serialization they need to be addressed. 1. Class vs Interface The WebContinuation is currently a class. IMO it makes much more sense to turn it into an interface an have the individual FlowEngine implementation act as a factory. That way javaflow could create WebContinuations that implement Serializable. +1. +1 2. Naming The name JavaInterpreter just misses the point. I would like to rename the Interpreter interface to something like FlowEngine. Other suggestions are welcome. +1 as well. I even proposed it 2 years ago [1] ;-) +1, I remember :-) and find that the old doc (at new URL: http://wiki.apache.org/cocoon/GeneralizedFlow, ever so unreadable as back then) still holds some ideas worth considering, no? for one: the possibility to have more then one 'flowEngine' as you call it available inside one sitemap would be neat (and there were some more related re-naming suggestions for the sitemap syntax as well IIRC, maybe the future of a 2.2 release offers us the fork to concider some of that as well?) 3. Continuation Management When it comes down to serialization of flow there are 2 aspects. One is flow persistence and the other one is flow replication across machines. In order support flow persistence we would need the make the ContinuationManager save and reload serializable continuations. ...which is not big deal. Unfortunately replication is a slightly different subject. The distributed ContinuationManagers would need to synchronize the continuation trees across the network or at least find a way to direct to the appropriate server that holds the continuation. TBH ...I am not eager to re-invent the wheel here. In fact this whole machinery is already in place for sessions. Why not re-use it? In fact I don't really see a big point of having web continuations without sessions anyway. +1 again. There aren't many real use cases where continuations span several sessions. And being tied to session may be one of the constraints/requirements to use clustered continuations. I was glad enough to hear Torsten make his point on this IRL during drink/reception of this year's gettogether... From a pure web/REST/temp resource POV I still like the idea of having dynamic URI's that can be shared between end users (thus regardless of their session) is kinda cool (think chatrooms/operators assisting in 'your' flow), but I think this kind of use could also be solved by smart redirects and some application level 'resource' management (probably be even safer then just having it de facto available) Assuming the continuations are stored inside the session, storing and restoring the sessions would take care of the persistence. Directing to the server with the right session also assures to get to the right cocoon instance running the right ContinuationManager. And this nice explanation shows IMHO enough pragmatic bonusses... so +1 Yup. This is required also for load balancing. Flow replication itself should then also be solved by session replication without any further effort. The only open question is the continuation expiry mechanism. It might be good enough to just run the expiry on every machine ...I am wondering how that might affect the replication though. Looks like HttpSessionActivationListener can by our friend here, as it allows session attributes to be notified when a session is passivated and activated. Sylvain [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105732879827785w=2 -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [jira] Commented: (COCOON-1658) Somewhere output is held...
Pier Fumagalli wrote: On 26 Oct 2005, at 13:58, Vadim Gritsenko (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1658? page=comments#action_12355965 ] Vadim Gritsenko commented on COCOON-1658: - (where is reply button in jira?) You normally can reply to the sender addess of the confirmation message, but that's not yet enabled in the ASF infrastructure... I rather meant reply as in Bugzilla [reply] which allows to quote message you are replying to. Vadim
Re: [RT] flow machinery
and find that the old doc (at new URL:
http://wiki.apache.org/cocoon/GeneralizedFlow, ever so unreadable as
back then) still holds some ideas worth considering, no?
...forgotten gems :) Definitely!
I have to read up on this.
for one: the possibility to have more then one 'flowEngine' as you
call
it available inside one sitemap would be neat
Ah! Yes! ...that bugged me as well. Forgot it on the write up.
Why would you need to define multiple scripts per flow defined
inside the sitemap? Which one are you referring to when you
call the function?
map:flows
map:flow type=my-flowlanguage=java src=.../
map:flow type=my-second-flow language=java src=.../
map:flow type=my-third-flow language=javascript src=.../
/map:flows
One of the points of the wiki page was appealing on the first glance
and turned into another RT: it might be a good idea to remove the
stigmata from actions and join the concepts a bit more. IMHO having
map:act *and* map:call is not really nice.
map:call action=my-action function=function-name/
map:call action=my-action/ !-- defaulting to the current
default method --
map:call flow=my-flow function=start-of-flow/
map:call function=start-of-flow/ !-- ok if there is only one
flow defined --
map:call continuation={1} /
Something better would be even to handle a flow without sending
a page as an action. So users would not have to think about whether
it is an action or a flow. Of course this blurs the contracts a bit
WDYT?
(and there were some more related re-naming suggestions for the
sitemap
syntax as well IIRC, maybe the future of a 2.2 release offers us the
fork to concider some of that as well?)
Fork?
If we cannot change things like this, the contract of trunk is too
tight IMO.
As long as we provide an easy way to migrate we should be able to shape
*everything* in trunk into a forward direction.
From a pure web/REST/temp resource POV I still like the idea of having
dynamic URI's that can be shared between end users (thus regardless of
their session) is kinda cool (think chatrooms/operators assisting in
'your' flow), but I think this kind of use could also be solved by
smart
redirects and some application level 'resource' management
(probably be
even safer then just having it de facto available)
Hm... but they would not assist in your flow ...they can only start
off where you left off and continue in a new tree of continuations.
Could you offer a more concrete example?
cheers
--
Torsten
PGP.sig
Description: This is a digitally signed message part
Re: [jira] Commented: (COCOON-1658) Somewhere output is held...
Vadim Gritsenko (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1658?page=comments#action_12355965 ] Vadim Gritsenko commented on COCOON-1658: - (where is reply button in jira?) So, my question is why is the buffer right now set to unlimited? Is there any specific caveat for this? If you are using caching pipeline then complete response will have to be buffered in any case. For non caching pipelines, complete response will have to be buffered if serializer requires content length to be set. For all other cases... The only reason for unlimited is error handling. If an error happens when some content has already been streamed to the client, we can't roll back the already streamed part. Without buffering you would get corrupted pages. So if you're sure that you don't have exceptions during streaming, you can turn off buffering. We decided a long time ago, to set the default to unlimited just for making error handling work in all cases. If the caching pipeline is used and in the case the serializer needs to set the content length, then the pipeline takes care about buffering. I think this outputBuffer is not really needed. I think this is another example of running modes. During development you might want to have an unlimited buffer while in production (where never an error occurs :) ) you can disable it. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Reverting the property search order in CoreUtils
Sylvain Wallez wrote: Cool, even if it would be good to extend lookup in web.xml to any servlet and/or context parameter (some admins will want to configure everything using their J2EE deployment tools). This can be done easily. The SettingsHelper class could be simply extended to set all servlet/context parameters in the settings properties as well. Now the problem comes from the property search order, which follows the exact same path, meaning the most generic properties (in WEB-INF/properties) hide any overriding in specific properties (user settings, system properties). I reverted the property lookup order, and this now works just fine :-) D'oh, I thought it was reverted order already...yepp, that's correct now. Thanks Sylvain. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Reverting the property search order in CoreUtils
Carsten Ziegeler wrote: Sylvain Wallez wrote: Now the problem comes from the property search order, which follows the exact same path, meaning the most generic properties (in WEB-INF/properties) hide any overriding in specific properties (user settings, system properties). I reverted the property lookup order, and this now works just fine :-) D'oh, I thought it was reverted order already...yepp, that's correct now. Thanks Sylvain. Carsten I assume you both meant reversed and not reverted. Ralph
Re: Reverting the property search order in CoreUtils
Ralph Goers wrote: I assume you both meant reversed and not reverted. Oh yes, of course !! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Reverting the property search order in CoreUtils
Ralph Goers schrieb: Carsten Ziegeler wrote: Sylvain Wallez wrote: Now the problem comes from the property search order, which follows the exact same path, meaning the most generic properties (in WEB-INF/properties) hide any overriding in specific properties (user settings, system properties). I reverted the property lookup order, and this now works just fine :-) D'oh, I thought it was reverted order already...yepp, that's correct now. Thanks Sylvain. Carsten I assume you both meant reversed and not reverted. LOL - yeah, this happens when you do copy/paste without thinking...(not that not thinking is happening very often to me...) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Reverting the property search order in CoreUtils
Carsten Ziegeler wrote: Sylvain Wallez wrote: Cool, even if it would be good to extend lookup in web.xml to any servlet and/or context parameter (some admins will want to configure everything using their J2EE deployment tools). This can be done easily. The SettingsHelper class could be simply extended to set all servlet/context parameters in the settings properties as well. Oh yes, sure! Something I'm worried a bit about though, is the naming of these parameters in web.xml if we want to keep compatibility with the existing parameter names. The new property stuff uses fully-qualified names, which is very good, whereas the servlet parameters have no prefix. Or maybe when we search for a given property, we should have a double-lookup in web.xml: - lookup the property as is (allows for fully qualified names in web.xml) - if the property name starts with org.apache.cocoon, lookup the property with this prefix stripped. That way, we use fully qualified names everywhere in the code, and property files, but still ensure backwards compatibility with the current web.xml. WDYT? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [jira] Commented: (COCOON-1658) Somewhere output is held...
Carsten Ziegeler wrote: Vadim Gritsenko (JIRA) wrote: So, my question is why is the buffer right now set to unlimited? Is there any specific caveat for this? If you are using caching pipeline then complete response will have to be buffered in any case. For non caching pipelines, complete response will have to be buffered if serializer requires content length to be set. For all other cases... The only reason for unlimited is error handling. Yes, of course, forgot to mention this. I think this outputBuffer is not really needed. I think this is another example of running modes. During development you might want to have an unlimited buffer while in production (where never an error occurs :) ) you can disable it. Why don't we use javax.servlet.ServletResponse.setBufferSize() instead of rolling our own buffering? Vadim
Re: Reverting the property search order in CoreUtils
Sylvain Wallez wrote: Oh yes, sure! Something I'm worried a bit about though, is the naming of these parameters in web.xml if we want to keep compatibility with the existing parameter names. The new property stuff uses fully-qualified names, which is very good, whereas the servlet parameters have no prefix. Or maybe when we search for a given property, we should have a double-lookup in web.xml: - lookup the property as is (allows for fully qualified names in web.xml) - if the property name starts with org.apache.cocoon, lookup the property with this prefix stripped. Or we could add a parameter from web.xml twice: once as is and if the prefix is missing, we add the fully qualified property as well. So we have a single lookup. That way, we use fully qualified names everywhere in the code, and property files, but still ensure backwards compatibility with the current web.xml. Yeap, good idea. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] flow machinery
Torsten Curdt wrote:
3. Continuation Management
When it comes down to serialization of flow there are 2 aspects.
One is flow persistence and the other one is flow replication
across machines.
In order support flow persistence we would need the make the
ContinuationManager save and reload serializable continuations.
...which is not big deal. Unfortunately replication is a slightly
different subject.
The distributed ContinuationManagers would need to synchronize
the continuation trees across the network or at least find a way
to direct to the appropriate server that holds the continuation.
TBH ...I am not eager to re-invent the wheel here. In fact this
whole machinery is already in place for sessions. Why not re-use it?
In fact I don't really see a big point of having web continuations
without sessions anyway.
Assuming the continuations are stored inside the session, storing
and restoring the sessions would take care of the persistence.
Directing to the server with the right session also assures to
get to the right cocoon instance running the right ContinuationManager.
Flow replication itself should then also be solved by session
replication without any further effort. The only open question
is the continuation expiry mechanism. It might be good enough to
just run the expiry on every machine ...I am wondering how that
might affect the replication though.
Comments?
In one of my projects I don't use the HttpSession at all but I can use a
stateful webservice (which is a public interface to a JB***-Cache). Most
probably this means that I have to write my own ContinuationsManager
implementation.
I'm saying this as I want to show that there are alternative scenarios how
clustered applications can be implemenented and that we should consider them
when (re)-designen the interfaces, though I don't think it will be a big deal.
--
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-1658) Somewhere output is held...
[ http://issues.apache.org/jira/browse/COCOON-1658?page=all ] Pier Fumagalli closed COCOON-1658: -- Resolution: Invalid For some odd reason, I never saw the prominent documentation in the Cocoon sitemap: If not specified, the value of the outputBufferSize parameter is -1. This will cause Cocoon to buffer all output until processing has finished before sending it to the client... Somewhere output is held... --- Key: COCOON-1658 URL: http://issues.apache.org/jira/browse/COCOON-1658 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Reporter: Pier Fumagalli Priority: Critical Cocoon standard, as of right now, built without any blocks. I modify the default sitemap adding one simple entry: map:match pattern=bigtest map:generate src=bigtest.xml/ map:serialize type=xml/ /map:match The file bigtest.xml is a 100Mb XML file that I simply want to generate and serialize (minimal test, no transformers that can do anything weird). I then open my terminal and do a curl http://localhost:/bigtest /dev/null, to have an idea of the thrughput for this file. Apparently, the output is held for roughly 25 seconds, nothing comes out, no bytes are serialized. All of a sudden, the entire 100 megabytes are serialized in one big lump (and it takes 5 seconds to do so). This happens if the pipeline is configured as being caching or noncaching (nothing changes). In the first 25 seconds, the JVM running Cocoon uses 100% of my processor (so, it's doing something), and the TOP shows something _really_ strange. My JVM grows of roughly 200 megabytes in size (note, I start Cocoon, post the big request, close cocoon). This is a trace from my TOP: PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE - 12498 java 0.1% 0:03.01 19 357 240 25.1M 28.7M 25.4M 735M 12498 java87.2% 0:06.22 19 403 242 54.2M+ 28.7M 55.1M+ 735M- 12498 java75.7% 0:10.88 19 403 242 78.3M 28.7M 79.2M 735M 12498 java80.2% 0:14.78 19 403 242 129M 28.7M 130M 735M 12498 java84.3% 0:19.77 19 403 242 168M+ 28.7M 169M+ 735M 12498 java77.4% 0:23.67 19 403 242 231M 28.7M 232M 735M 12498 java40.7% 0:27.92 19 403 242 231M+ 28.7M 232M+ 735M+ 12498 java 0.1% 0:28.18 20 408 245 231M 28.7M 232M 735M Something tells me that we are indeed caching all the content in a big char[] (100 megabytes of US-ASCII text are 200 megabytes when stored in a char[]). Any clue on where this can happen? It's impairing our ability to serve bigger feeds (aka, 2 gigs! :-P) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (COCOON-1658) Somewhere output is held...
On 26 Oct 2005, at 17:49, Carsten Ziegeler wrote: Vadim Gritsenko (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1658? page=comments#action_12355965 ] Vadim Gritsenko commented on COCOON-1658: - (where is reply button in jira?) So, my question is why is the buffer right now set to unlimited? Is there any specific caveat for this? If you are using caching pipeline then complete response will have to be buffered in any case. For non caching pipelines, complete response will have to be buffered if serializer requires content length to be set. For all other cases... The only reason for unlimited is error handling. If an error happens when some content has already been streamed to the client, we can't roll back the already streamed part. Without buffering you would get corrupted pages. So if you're sure that you don't have exceptions during streaming, you can turn off buffering. We decided a long time ago, to set the default to unlimited just for making error handling work in all cases. If the caching pipeline is used and in the case the serializer needs to set the content length, then the pipeline takes care about buffering. Ahhh!!! I think this outputBuffer is not really needed. I think this is another example of running modes. During development you might want to have an unlimited buffer while in production (where never an error occurs :) ) you can disable it. Sorry, I'm a moron... For some reason I've never seen that it's extremely well documented in the Cocoon default sitemap. !--+ | If not specified, the value of the outputBufferSize parameter is -1. | This will cause Cocoon to buffer all output until processing has finished | before sending it to the client. This has the advantage that in case | an error occurs during the processing of the SAX- pipeline, Cocoon is still | able to reset the response and send an error page instead. Otherwise the | error page will be appended to the output already send to the client. | If you are generating larger pages, it might be benificial to enable | this parameter, so that output is gradually send to the client as it | is being generated. | For more granularity, you can also supply this parameter to | individual map:pipeline elements (using map:parameter syntax). +-- Pier smime.p7s Description: S/MIME cryptographic signature
Re: [M10N] When to ditch Ant and switch to Maven
Jorg Heymans wrote: Daniel Fagerstrom wrote: * M2 stable enough (2.0 is out so this should be fullfilled) * Reasonably fast (don't need to be as fast as Ant, but not several times slower) * Easy configuration of what blocks to compile (like blocks.properties and maybe even dependency aware) * M2 bundled with Cocoon (it should still be enough to just download and type ./build.sh) I agree with above set, here are mine : (all mainly pom related) * produce jar artifacts from core and every block * produce jar artifacts from core samples and block samples * be able to run all tests Yes, would also like to add: * Still being able to use gump. /Daniel
Re: [M10N] separating samples from blocks
Jorg Heymans wrote: ... I'ld like to also be clear about Daniels' concerns wrt OSGI before we actually go ahead and do this. Don't wait on that, I'm not clear about it my self ;) The idea is that I would assume that when we test a block it is best to do it in an environment that is as close as possible to the environment it will be used in. For an OSGi bundle this means that it will get access to external packages through the OSGi classloader functionality and also that it might need some external services (that we might have mock implementations of). One way of handling this is to run the tests within an OSGi framework, but this give problems. Either the unit tests are in a separate bundle, but then only methods in classes in exported packages can be tested. That is certainly not what we want. Or we have the tests within the bundle, now everything can be tested, but we need export some service that run the tests instead and have some mechanism that remove both this service and the tests for production use. This seem like a clumsy and intrusive solution. I guess that the conclusion is that it not is a good idea to do unit testing in an ordinary OSGi framework. A solution could be to have a special test OSGi framework with limited functionality, like our test containers for Avalon components. Felix and Eclipse will probably have the same problem, so we can move the question to e.g. the Felix list when we need a solution. For now, don't care about OSGi for the tests, we can solve that later. /Daniel
Re: [M10N] separating samples from blocks
Daniel Fagerstrom wrote: Don't wait on that, I'm not clear about it my self ;) The idea is that I would assume that when we test a block it is best to do it in an environment that is as close as possible to the environment it will be used in. For an OSGi bundle this means that it will get access to external packages through the OSGi classloader functionality and also that it might need some external services (that we might have mock implementations of). One way of handling this is to run the tests within an OSGi framework, but this give problems. Either the unit tests are in a separate bundle, but then only methods in classes in exported packages can be tested. That is certainly not what we want. Or we have the tests within the bundle, now everything can be tested, but we need export some service that run the tests instead and have some mechanism that remove both this service and the tests for production use. This seem like a clumsy and intrusive solution. I guess that the conclusion is that it not is a good idea to do unit testing in an ordinary OSGi framework. A solution could be to have a special test OSGi framework with limited functionality, like our test containers for Avalon components. Felix and Eclipse will probably have the same problem, so we can move the question to e.g. the Felix list when we need a solution. For now, don't care about OSGi for the tests, we can solve that later. /Daniel I don't think you have as much to worry about as you think you do. Build a block will probably involve building a jar and then doing some stuff to build the block. When maven runs unit tests it can test against the classes directly - the bundle doesn't even have to exist at that point. Once the bundle is constructed additional functional testing can be performed, but that should just be against the public interfaces. Ralph
Re: [RT] Rules for adding blocks and functionality?
Upayavira wrote: Bertrand Delacretaz wrote: ... Sounds good, and as a first step this could be our own contrib directory. No it wouldn't, because we wouldn't agree what should go there. I think we could agree about some of the existing blocks, but never mind. But we are not forced to continue to have sloopy rules for how to adding functionality, a contrib directory could be useful for new blocks that not have any community support yet or that are outside our main scope. My suggestion is to, as you did with the samples, leave all blocks as they are, and start _hightlighting_ the ones we consider to be best practices. Then, after some extended period if time we may decide to purge the ones that have not received any highlighting, but highlighting core blocks works much better than deprecating old blocks that people may be using. (And by way of recommendation of this approach :-) this is the approach that Buddhists throughout the centuries used to deal with teachings that had grown stale. They didn't say that is a bad teaching, they said, hey, we've got a higher teaching.) So, basically, until we've got blocks functioning, and have had them so for _some_ time, we should do nothing more than highlighting and marking up with meta-data for our blocks. Our blocks system and block repository is going to create a new organism (which, yes, could well want a contrib group elsewhere such as Niclas suggested), but I want to allow for that organism to grow, well, organically :-) Sound good. The important point IMO is that we start to be explicit about our priorities in some way. And highlighting might be easier to do than removing. /Daniel
SQL and CTemplate (was Re: [RT] Rules for adding blocks and functionality?)
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
We are chosen as committers as induviduals and not as representants
for our companies. From a community stand point I would say that it
is time to deprecate the SQLTransformer. As a representative for my
company I would rather say: no way, we have tons of code that depend
on it. It is a complicated question, but I don't think that the
answer is: I need it at my work so the rest of you should support it.
It is really hard to tell what is still useful and what not. Now, the
simple example of the SQLTransformer shows this: most of us seem to
agree that it's some legacy component and that flow etc. should be used
instead.
Now, think of a reporting tool done with Cocoon. This fetches some
hundreds of MB out of the database and just displays them. In this case
everything other than the SQLTransformer + Stylesheet is simply overkill
(ok, XSP+ESQL is fine as well) and too memory/time consuming.
Agree. The really ugly part of SQLTransformer is its ability to
perform insert/updates.
I'm using ESQL in a number of places for publication purposes, and
many people agree that ESQL is what keeps XSP alive. We have to build
an equivalent for CTemplates.
As you might remeber the CTemplate framework was designed with that in
mind. It is rather simple to add a set of external instructions to
CTemplate. But we had a long and not especially nice discussion about
such thing a while ago, and the conclusion was that the community didn't
want such things.
Now, I find it rather strange to keep the SQLTransformer and ESQL
because some people find them being the best way to do simple reporting
at the same time as the community strongly oppose building a modern
replacement of them in CTemplate, because they represent bad practice.
Anyway, for the time beeing I think it is better to focus on making it
as easy as possible to use SQL from flowscripts and present the result
sets in CTemplate. Then if we don't get it easy enough we can start to
think about doing part of ESQL in CTemplate.
Whilst I'm not going to be the person implementing it, having seen the
distinction made between SELECT and UPDATE in ESQL/SQLTransformer, I'd
happily see tags added to CTemplate to allow for SQL querying, without
the ability to update/insert.
Surely the main thing about a template is that it is side-effect free,
and that would be.
Maybe better would be some way to separate the SQL from the template.
Imagine:
esql:select name=my-query idEmployee=#{request.getParameters('id')}/
And queries.sql:
my-query: SELECT * FROM Employee WHERE idEmployee = ${idEmployee}
my-other-query: SELECT * FROM Employers
I guess you'd define your queries.sql file in the map:generators
section of your sitemap.
The worst thing about ESQL/SQLTransformer in my view is the embedded
SQL. Horrible.
Regards, Upayavira
Re: SQL and CTemplate (was Re: [RT] Rules for adding blocks and functionality?)
Upayavira wrote: The worst thing about ESQL/SQLTransformer in my view is the embedded SQL. Horrible. LOL :) It's not much worse than embedded Java in JSP! :) Vadim
Re: [M10N] separating samples from blocks
Daniel Fagerstrom wrote: Don't wait on that, I'm not clear about it my self ;) oh but I didn't :-) I'll soon commit an example of a new flattened repository structure with a few reorganized blocks, everything controlled by maven. For now, don't care about OSGi for the tests, we can solve that later. ok, I think Ralph has a point in that we probably don't need to give it that much thought as we think we should. Furthermore, I read that Felix will be getting some maven related osgi stuff donated to it - with any luck it'll all be in place by the time we need it ;) Jorg
Re: [RT] flow machinery
Torsten Curdt wrote:
...
One of the points of the wiki page was appealing on the first glance
and turned into another RT: it might be a good idea to remove the
stigmata from actions and join the concepts a bit more. IMHO having
map:act *and* map:call is not really nice.
map:call action=my-action function=function-name/
map:call action=my-action/ !-- defaulting to the current
default method --
map:call flow=my-flow function=start-of-flow/
map:call function=start-of-flow/ !-- ok if there is only one
flow defined --
map:call continuation={1} /
Something better would be even to handle a flow without sending
a page as an action. So users would not have to think about whether
it is an action or a flow. Of course this blurs the contracts a bit
WDYT?
+1
IMO it is often a better SoC to have integration code in actions and
use flow scripts only for the actual page flow. It would become
convenient to code in that way if both flow function and action
functions could be defined in the same way and maybe in the same JS (or
Java) file and be used in similar way with similar environments.
And, yes it is time to remove the stigmata from actions, with JS based
actions and the compiling classloader it is efficient to develop with
actions.
The original idea with reusable actions that was put together in a
obscure way with action sets still deserves its stigmata, though ;)
/Daniel
Re: [M10N] When to ditch Ant and switch to Maven
Daniel Fagerstrom wrote: * Still being able to use gump. IIRC, the maven boys have no intention of supporting Gump as of yet. If nothing else we'll have to craft something ourselves, or maintain gump.xml manually. Jorg
Re: Super-easy SQL/Form integration for simple CRUD applications
Sylvain Wallez wrote: Just in time before the code freeze deadline, I committed an additional sample for CForms [1], which shows how, using JDBI [2] and the Collection wrappers for container widgets and repeaters [3] and a few conventions, writing simple CRUD applications with Cocoon is a breeze. A simple flowscript, a form definition and a few templates and you're done. No Java classes, no binding file, no O/R mapping tool! How long till form definitions and templates are generated out of db schema? ;-) Vadim
RE: SQL and CTemplate (was Re: [RT] Rules for adding blocks and functionality?)
From: Upayavira [EMAIL PROTECTED] Date: Wed, 26 Oct 2005 21:44:23 +0100 Whilst I'm not going to be the person implementing it, having seen the distinction made between SELECT and UPDATE in ESQL/SQLTransformer That was one of the things that bugged me about the SQLTransformer too, that and the fact it didn't handle our Sybase-based stored procs (some of which returned a few update counts first from selecting into temporary tables and variables, and only then the result set). Besides which, it's perfectly possible for a stored proc to return more than one result set, and that wasn't catered for either, nor were queries like SET ROWCOUNT 3; SELECT foo FROM bar ORDER BY bub DESC; SET ROWCOUNT 0. So, I modified the transformer to loop over all the returned results. In the process I was able to remove the select/update distinction completely - an update is simply a query that returns an update count in its rowset instead of a bunch of rows (getNextResult can tell the difference without needing to guess it from the query contents). If there's multiple results then you get multiple rowsets, finally followed by any output parameters if isstoredprocedure=true (since the JDBC spec says you should process all results before accessing those anyway). Another improvement was decent handling of sql:in-parameter (allowing the value to be specified in the element body as well as an attribute so you can combine it with sql:substitute-value to use a parameter passed from the sitemap instead of only static values, which is much more useful). If the transformer in CVS hasn't changed too much since I adapted it, I could upload a patch if people think it's worthwhile? The worst thing about ESQL/SQLTransformer in my view is the embedded SQL. Horrible. Nobody said it has to come from a static file, though. You can always generate the query dynamically from an XML file representing your DB schema and a suitable XSL transform to convert it into the SQL query... Andrew.
Re: SQL and CTemplate (was Re: [RT] Rules for adding blocks and functionality?)
Andrew Stevens wrote: If the transformer in CVS hasn't changed too much since I adapted it, It's in SVN now and has been changed several times since we moved away from CVS. Well, it has been 14 months :-) http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java?rev=321209view=log Vadim
