[continuum] BUILD ERROR: Cocoon Configuration Implementation
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/61/buildId/1458 Build statistics: State: Error Previous State: Error Started at: Tue, 2 Jan 2007 12:34:01 + Finished at: Tue, 2 Jan 2007 12:34:04 + Total time: 3s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Environment [modules]
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/63/buildId/1459 Build statistics: State: Error Previous State: Error Started at: Tue, 2 Jan 2007 12:34:27 + Finished at: Tue, 2 Jan 2007 12:34:32 + Total time: 4s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Environment API
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/64/buildId/1460 Build statistics: State: Error Previous State: Error Started at: Tue, 2 Jan 2007 12:34:32 + Finished at: Tue, 2 Jan 2007 12:34:34 + Total time: 1s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Environment Implementation
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/65/buildId/1461 Build statistics: State: Error Previous State: Error Started at: Tue, 2 Jan 2007 12:34:34 + Finished at: Tue, 2 Jan 2007 12:34:39 + Total time: 4s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
Re: Planing Cocoon Core 2.2 M3
Reinhard Poetz wrote: Daniel and Carsten have been investing a lot of time and work into splitting up core into smaller pieces and they have also started to transform Avalon components into POJOs. The question now is where to draw the line. When is everything being considered stable enough (interfaces, classes being in the right modules) to be released as release candidate and what should better go into point releases or 3.0? Can we render a list of finite tasks? As discussed some weeks ago, I would like to release Cocoon Core 2.2 M3 by the end of the month and have a first release candidate in February. Comments? I want to release the spring-configurator in the middle of January, so I'm currently testing and working on the docs. Apart from that, the ongoing work of splitting up and transforming avalon components into Pojos will take a long time, but should/will at no point of time prevent us from releasing something. It would be great to have a final 2.2 version out before ApacheCon EU, so the earlier we can have a m3 the better. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Planing Cocoon Core 2.2 M3
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Daniel and Carsten have been investing a lot of time and work into splitting up
core into smaller pieces and they have also started to transform Avalon
components into POJOs. The question now is where to draw the line. When is
everything being considered stable enough (interfaces, classes being in the
right modules) to be released as release candidate and what should better go
into point releases or 3.0? Can we render a list of finite tasks?
As discussed some weeks ago, I would like to release Cocoon Core 2.2 M3 by the
end of the month and have a first release candidate in February.
Comments?
I want to release the spring-configurator in the middle of January
What will it be labeled? I guess 1.0-RC1?
At http://cocoon.zones.apache.org/daisy/cdocs-site-main/g4/g1/1199.html you
should find everything explained for the actual release work.
, so
I'm currently testing and working on the docs.
Do you need help with the Daisy setup (see the how-to section of
http://cocoon.zones.apache.org/daisy/cdocs/1201.html)? If yes, just let me know!
Apart from that, the ongoing work of splitting up and transforming
avalon components into Pojos will take a long time, but should/will at
no point of time prevent us from releasing something.
ok. Then I plan for a release of M3 in about 4 weeks. It would be great if there
are no major refactorings around the release date.
It would be great to have a final 2.2 version out before ApacheCon EU,
so the earlier we can have a m3 the better.
seems to be feasible but after the long history of 2.2 ... ;-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Planing Cocoon Core 2.2 M3
Reinhard Poetz wrote: I want to release the spring-configurator in the middle of January What will it be labeled? I guess 1.0-RC1? Hmm, I would like to call it 1.0 right away. If there are problems, we can release a 1.0.1 asap. It's a small module anyway. At http://cocoon.zones.apache.org/daisy/cdocs-site-main/g4/g1/1199.html you should find everything explained for the actual release work. Thanks for the pointer! There is one question: In my opinion we have too many parent poms. The configurator is a child of the core-configuration which is a child of core which is a child of Cocoon which is a child of the apache root pom. Is there any way to simplify this? Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Reducing the number of POM artifacts in trunk
Carsten Ziegeler wrote:
There is one question: In my opinion we have too many parent poms. The
configurator is a child of the core-configuration which is a child of
core which is a child of Cocoon which is a child of the apache root pom.
Is there any way to simplify this?
Yes I know, that's a real PITA. One option is making
org.apache.cocoon:cocoon-core-modules being the parent of all core modules and
org.apache.cocoon:blocks being the parent of all blocks. (I don't want to reduce
these two POM modules either as they are needed for the site generation.)
But, I don't know if this can cause any problems if the logical hierarchy is
different to the directory structure. Does anybody know? Jorg?
But maybe we should just try it out ;-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Planing Cocoon Core 2.2 M3
Reinhard Poetz skrev: Daniel and Carsten have been investing a lot of time and work into splitting up core into smaller pieces and they have also started to transform Avalon components into POJOs. The question now is where to draw the line. When is everything being considered stable enough (interfaces, classes being in the right modules) to be released as release candidate and what should better go into point releases or 3.0? Can we render a list of finite tasks? To get the splitting of the core right will take some time, but that should not hinder any releases as long as we make clear that people should depend on the cocoon-core module and that the more fine grained split that the cocoon-core in turn depend on currently is experimental and that it is subject to change. For the POJOfication of the components I think we should keep but deprecate the possibility to manage sitemap components the Avalon way. For the rest of the components I don't think that it is worthwhile to keep the Avalon functionality. But as it will take time to convert them all we have to live with the situation that some are converted an some are not. But for most users that should not mater much as they will used th predefined components anyway. As discussed some weeks ago, I would like to release Cocoon Core 2.2 M3 by the end of the month and have a first release candidate in February. +1 /Daniel
Re: Problems with writing sitemap components as spring beans
Carsten Ziegeler wrote: Reinhard Poetz wrote: we could provide an abstract parent bean definition (http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-child-bean-definitions). Yes, but this would also mean that all implementations inherit from an abstract class we provide. This is not a big deal, I guess we can live with that. IIRC this is not *required* (thought is convenient in many cases). In an abstract bean definition you can declare only a property, only the class, only a factory method or any mix of the preceding and something more. Obviously if you say that there is a property named thatStuff, it will search for setThatStuff, but that could be in a common interface and does not require that every subclass extends the same abstract base class. Simone
Re: Core split status
Daniel Fagerstrom wrote: The pipeline layer consists of: cocoon-pipeline-api - Interfaces: ProcessingPipeline, sitemap component and basic XML interfaces, the environment abstraction, caching interfaces and needed exceptions. cocoon-pipeline-impl - The various implementations of ProcessingPipeline together with classes that they depend on and various abstract classes for the sitemap components. cocoon-pipeline-components - generators, transformers, serializers, readers, some sources and xpointer and xslt components. Here probably some of the abstract classes should be moved to the api module, but I didn't want to make the api to heavy in the first step. Also the impl module probably contains components and utility class that would be better to factor out to own modules. Maybe the component module should be split into a base and an optional module? Right now the dependency graph is: api - impl - components while it rather should be api - impl api - components Hi Daniel, very good work! But I'm missing something : if *-impl contains abstract classes for components, and *-components contains that components, how can they not depend on the abstract classes they extend? Simone
Re: Problems with writing sitemap components as spring beans
Carsten Ziegeler wrote: So far, I've only seen people using labels for debugging pipelines which is really not what it was intended for (I think we should provide a better alternative for debugging pipelines anyway). If it would be me, we could forget about views completly (they are not inherited to sub sitemaps, can easily be a security problem etc.) +1 for dropping views, they are only used for debugging or for other small tricks for which writing another matcher is better, they introduce some security risks, and also have some strange behaviors with cocoon:// calls and subsitemaps. Anyway, for debugging, is the great profiling processing pipeline dead? because for debugging that was by far better than views, and was in general a very good piece of software and among the most useful and less used features in cocoon!! Simone
Re: DTD validation: Unsupported grammar language
On 12/20/2006 6:09 PM, Joerg Heinicke wrote: Hello Lars, just from having a look at the code: 1. It's http://www.w3.org/TR/REC-xml (see Validator interface and its declared constants). That documentation is where I got the string from. Glad for the confirmation that it's right. 2. This exception is thrown in AbstractValidator.getValidationHandler() in line 327 in the current code. It is thrown when no SchemaParser can be found. 3. Grammars and their parsers seem to be configured via Configurable.configure(). So maybe the javadoc for this method [1] is helpful. Otherwise you might need to have a look into the code of this method or do some debugging. Thanks... It's a little disappointing when Cocoon bills itself as a web development framework that makes it possible to use a Lego(tm)-like approach in building web solutions, hooking together components into pipelines *without any required programming*, with strong foundations in *XML-based* server-side web application frameworks,[1] that users have to go dig through the framework source code in order to find out whether DTD validation is even possible out of the box. I looked at the javadoc you mentioned. It seems to suggest that I do what I've already done, namely to specify the grammar using map:parameter name=grammar value=http://www.w3.org/TR/REC-xml; /. I confess I don't really understand the stuff about schema factories and parsers. Two other Cocoon users have requested the same thing on the Cocoon user list, with no response. I'm sure it would be appreciated if someone could figure this out... even if the answer is no, it's not currently supported. Right now, we're using the third-party fcc.ima.cocoon.ValidatorTransformer with Cocoon 2.1.7. However, it always reports validation errors as being in line 1 column 1, which is not very helpful in finding the error. Apparently this is because the generator provides a Locator interface that supplies meaningless location info. I was hoping the built-in validation block in Cocoon 2.1.8+ would do better. Thanks, Lars [1] http://cocoon.apache.org/ Regards Jörg [1] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/validation/jaxp/JaxpSchemaParser.html#configure(org.apache.avalon.framework.configuration.Configuration) On 19.12.2006 18:32, Lars Huttar wrote: Hello, I seconded this question on the Cocoon user list but have not received a response, so would like to ask the developers. In Cocoon 2.1.9, we are trying to use ValidationReportTransformer to validate our XML against a DTD. I'm looking at the documentation at http://cocoon.zones.apache.org/daisy/documentation/864/validation.html and http://cocoon.zones.apache.org/daisy/documentation/components/1058/g2/691.html. The validation sample block has examples for validating against RNG and XML Schema, but not against a DTD. Like José quoted below, I'm trying to figure out how to make it work. Here's my attempt, a copy-and-modify of a match pattern in samples\blocks\validation\sitemap.xmap: map:match pattern=report-dtd-valid map:generate src=source-ok.xml/ map:transform type=validation-report src=schema-ok.dtd map:parameter name=grammar value=http://www.w3.org/TR/REC-xml; / /map:transform map:transform src=context:/stylesheets/system/xml2html.xslt/ map:serialize/ /map:match I added the grammar parameter, as instructed by the documentation referenced above, to the validation-report transformer. For grammar identifier, the documentation seemed to indicate I should use http://www.w3.org/TR/REC-xml;. (I also tried dtd just for kicks.) But the result is that I get the error org.apache.cocoon.components.validation.ValidatorException: Unsupported grammar languagehttp://www.w3.org/TR/REC-xml Does this mean there is no support for validating against DTDs? Or am I doing something wrong? Thanks, Lars
Re: having problems while trying to build trunk
[EMAIL PROTECTED] skrev: While trying to build trunk like this: mvn -Dmaven.test.skip=true -Dmaven.war.shieldingclassloader=false \ -Dallblocks -Dalldists clean install at the end I get: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.AbstractWarMojo.unpack(AbstractWarMojo.java:704) at org.apache.maven.plugin.war.AbstractWarMojo.unpackWarToTempDirectory(AbstractWarMojo.java:680) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:600) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:379) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:182) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:64) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Any hints? See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116414054703369w=2. But I would recommend you to not bother about the dist samples as no one currently maintain them and as they only create a binary distribution, they are not intended to be the base for development or anything like that. Instead I recommend that you try the cocoon-webapp as a first step: mvn -Dmaven.test.skip=true install cd core/cocoon-webapp mvn -Dorg.apache.cocoon.mode=develop -e jetty:run and point your browser to http://localhost:/ I added some samples to the cocoon-webapp yesterday, so now it actually does something. When you have experimented with the cocoon-webapp and want to start an own project you just follow the instructions in http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1159.html. /Daniel
Re: Core split status
Simone Gianni skrev: Daniel Fagerstrom wrote: The pipeline layer consists of: cocoon-pipeline-api - Interfaces: ProcessingPipeline, sitemap component and basic XML interfaces, the environment abstraction, caching interfaces and needed exceptions. cocoon-pipeline-impl - The various implementations of ProcessingPipeline together with classes that they depend on and various abstract classes for the sitemap components. cocoon-pipeline-components - generators, transformers, serializers, readers, some sources and xpointer and xslt components. Here probably some of the abstract classes should be moved to the api module, but I didn't want to make the api to heavy in the first step. Also the impl module probably contains components and utility class that would be better to factor out to own modules. Maybe the component module should be split into a base and an optional module? Right now the dependency graph is: api - impl - components while it rather should be api - impl api - components Hi Daniel, very good work! Thanks :) But I'm missing something : if *-impl contains abstract classes for components, and *-components contains that components, how can they not depend on the abstract classes they extend? You are absolutely right. Abstract base classes intended for reuse should be part of the API. But as we, IMHO, severely overuse abstract base classes in and as the abstract base classes would increase the number of dependencies for the API and as we are trying to decrease the Avalon dependencies, I felt rather reluctant to put all the abstract classes in the API. And because of that the components depends on the impl instead of just the API. I hope we will be able to get to the point where the abstract base classes have more reasonable dependencies and can be moved to that API or maybe some pipeline util module. /Daniel
Trouble w/ trunk / samples
Hi, I'm trying to test samples against my source build. This is from a mvn clean install on a freshly-updated trunk as of last night. First, I tried mvn jetty:run from cocoon-dist-samples. Jetty falls over with these messages: === 4212 [main] INFO / - Loading Spring root WebApplicationContext 7314 [main] WARN org.mortbay.log - failed [EMAIL PROTECTED]/,file:/Volumes/codeshack-data1/ml/software/ Cocoon/cocoon/dev/trunk/dists/cocoon-dist-samples/target/cocoon- samples/} 7470 [main] WARN org.mortbay.log - failed [EMAIL PROTECTED] 7471 [main] WARN org.mortbay.log - failed [EMAIL PROTECTED] 7507 [main] INFO org.mortbay.log - Started SelectChannelConnector @ 0.0.0.0: 7508 [main] WARN org.mortbay.log - failed [EMAIL PROTECTED] [INFO] Jetty server exiting. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failure Embedded error: Cannot invoke listener [EMAIL PROTECTED] Class [org.apache.cocoon.spring.configurator.impl.ConfiguratorNamespaceHandler ] does not implement the NamespaceHandler interface === Then, remembering http://svn.apache.org/viewvc?view=revrev=491696, I tried jetty:run from cocoon-webapp. Cocoon starts OK, but then when I hit the block samples link on the welcome page, I get the error shown below. Any clues? Am I doing something wrong? thx, —ml— === HTTP ERROR: 500 javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; RequestURI=/blocks/ Caused by: java.lang.NoSuchMethodError: javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; at org.apache.xalan.transformer.TransformerIdentityImpl.createResultContent Handler(TransformerIdentityImpl.java:199) at org.apache.xalan.transformer.TransformerIdentityImpl.setDocumentLocator( TransformerIdentityImpl.java:880) at org.apache.cocoon.xml.AbstractXMLPipe.setDocumentLocator(AbstractXMLPipe .java:39) at org.apache.xerces.parsers.AbstractSAXParser.startDocument(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java: 196) at org.apache.cocoon.core.xml.avalon.DefaultSAXParser.parse(DefaultSAXParse r.java:47) at org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java: 128) at org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.jav a:180) at org.apache.cocoon.components.source.util.SourceUtil.toDOM(SourceUtil.jav a:285) at org.apache.cocoon.generation.XPathTraversableGenerator.performXPathQuery (XPathTraversableGenerator.java:220) at org.apache.cocoon.generation.XPathTraversableGenerator.addContent(XPathT raversableGenerator.java:196) at org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGen erator.java:482) at org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGen erator.java:464) at org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGen erator.java:464) at org.apache.cocoon.generation.TraversableGenerator.addAncestorPath(Traver sableGenerator.java:383) at org.apache.cocoon.generation.TraversableGenerator.generate(TraversableGe nerator.java:321) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invo ke(PoolableProxyHandler.java:61) at $Proxy2.generate(Unknown Source) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe line.processXMLPipeline(AbstractCachingProcessingPipeline.java:358) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process
cocoon-webapp, cocoon-dist-samples (Re: svn commit: r491696 - /cocoon/trunk/core/cocoon-webapp/pom.xml)
I don't get it, why is keeping cocoon-dist-samples working so much harder than making samples work in cocoon-webapp? cheers, —ml— On Jan 1, 2007, at 11:06 PM, Carsten Ziegeler wrote: [EMAIL PROTECTED] wrote: Author: danielf Date: Mon Jan 1 15:26:31 2007 New Revision: 491696 URL: http://svn.apache.org/viewvc?view=revrev=491696 Log: I want working samples! Until someone find the motivation to maintain the dist samples we should keep cocoon-webapp in such a state that people can use it for testing Cocoon. Big +1 Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Trouble w/ trunk / samples
You get the wrong version of DOM, see http://osdir.com/ml/dev@cocoon.apache.org/msg48088.html, for some hints. /Daniel Mark Lundquist skrev: Hi, I'm trying to test samples against my source build. This is from a mvn clean install on a freshly-updated trunk as of last night. First, I tried mvn jetty:run from cocoon-dist-samples. Jetty falls over with these messages: === 4212 [main] INFO / - Loading Spring root WebApplicationContext 7314 [main] WARN org.mortbay.log - failed [EMAIL PROTECTED]/,file:/Volumes/codeshack-data1/ml/software/Cocoon/cocoon/dev/trunk/dists/cocoon-dist-samples/target/cocoon-samples/} 7470 [main] WARN org.mortbay.log - failed [EMAIL PROTECTED] 7471 [main] WARN org.mortbay.log - failed [EMAIL PROTECTED] 7507 [main] INFO org.mortbay.log - Started SelectChannelConnector @ 0.0.0.0: 7508 [main] WARN org.mortbay.log - failed [EMAIL PROTECTED] [INFO] Jetty server exiting. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failure Embedded error: Cannot invoke listener [EMAIL PROTECTED] Class [org.apache.cocoon.spring.configurator.impl.ConfiguratorNamespaceHandler] does not implement the NamespaceHandler interface === Then, remembering http://svn.apache.org/viewvc?view=revrev=491696, I tried jetty:run from cocoon-webapp. Cocoon starts OK, but then when I hit the block samples link on the welcome page, I get the error shown below. Any clues? Am I doing something wrong? thx, —ml— === HTTP ERROR: 500 javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; RequestURI=/blocks/ Caused by: java.lang.NoSuchMethodError: javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; at org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:199) at org.apache.xalan.transformer.TransformerIdentityImpl.setDocumentLocator(TransformerIdentityImpl.java:880) at org.apache.cocoon.xml.AbstractXMLPipe.setDocumentLocator(AbstractXMLPipe.java:39) at org.apache.xerces.parsers.AbstractSAXParser.startDocument(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:196) at org.apache.cocoon.core.xml.avalon.DefaultSAXParser.parse(DefaultSAXParser.java:47) at org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:128) at org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.java:180) at org.apache.cocoon.components.source.util.SourceUtil.toDOM(SourceUtil.java:285) at org.apache.cocoon.generation.XPathTraversableGenerator.performXPathQuery(XPathTraversableGenerator.java:220) at org.apache.cocoon.generation.XPathTraversableGenerator.addContent(XPathTraversableGenerator.java:196) at org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGenerator.java:482) at org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGenerator.java:464) at org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGenerator.java:464) at org.apache.cocoon.generation.TraversableGenerator.addAncestorPath(TraversableGenerator.java:383) at org.apache.cocoon.generation.TraversableGenerator.generate(TraversableGenerator.java:321) 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.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:61) at $Proxy2.generate(Unknown Source) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:358)
Re: cocoon-webapp, cocoon-dist-samples (Re: svn commit: r491696 - /cocoon/trunk/core/cocoon-webapp/pom.xml)
I don't say that it is much harder to keep cocoon-dist-samples working than making cocoon-webapp working. I just say that I lack the motivation. The reason for that is that cocoon-webapp is a good example for seeing what a development environment for Cocoon 2.2 looks like with Maven poms and everything. While cocoon-dist-samples just is a prepackaged application. You can't use it for starting new projects or learning anything, its just show case the samples, nothing else. And the samples are the same as in 2.1 so if you want to see them you can just point your browser to http://cocoon.zones.apache.org/demos/release/. Later, when we have released 2.2, a binary sample distribution might be worthwhile currently it is, IMO, not. But if someone is motivated, please go ahead and fix it. But IIRC, it has never worked correctly. What IMO would be cool, would be to blockify the samples. If we do that the sample app would only be a POM that would download all the needed blocks and create a webapp from them with the deployer. That would illustrate what Cocoon 2.2 is about. A fat binary sample app doesn't. /Daniel Mark Lundquist skrev: I don't get it, why is keeping cocoon-dist-samples working so much harder than making samples work in cocoon-webapp? cheers, —ml— On Jan 1, 2007, at 11:06 PM, Carsten Ziegeler wrote: [EMAIL PROTECTED] wrote: Author: danielf Date: Mon Jan 1 15:26:31 2007 New Revision: 491696 URL: http://svn.apache.org/viewvc?view=revrev=491696 Log: I want working samples! Until someone find the motivation to maintain the dist samples we should keep cocoon-webapp in such a state that people can use it for testing Cocoon. Big +1 Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: cocoon-webapp, cocoon-dist-samples (Re: svn commit: r491696 - /cocoon/trunk/core/cocoon-webapp/pom.xml)
On Jan 2, 2007, at 10:55 AM, Daniel Fagerstrom wrote: What IMO would be cool, would be to blockify the samples. If we do that the sample app would only be a POM that would download all the needed blocks and create a webapp from them with the deployer. That would illustrate what Cocoon 2.2 is about. A fat binary sample app doesn't. I get it. The above is what I thought cocoon-dist-samples was! :-) I see what you mean about the cocoon-dist-samples (a) not being useful, and (b) not teaching anything about how a C2.2 app is supposed to go together. (a), because... who needs a big fat Cocoon samples war? Nobody that I know. So cocoon-dist-samples is just a war packager, and the jetty:run goal that I was using from there to run the nonpacked webapp is just a sideshow, right? I have the motivation to do thing we are talking about. Unfortunately, I'm lacking the know-how! :-) Maybe I will try anyway, and then when I'm done I'll have the knowledge... :-) thx, —ml—
Re: What is the deal with blocks
On Dec 28, 2006, at 3:08 PM, Daniel Fagerstrom wrote: As you can see there was a quite gradual divergence from the original concept to what we have today. IMO it would be preferable to just use the word block in one of the two uses of the the word. +100. Please, please, yes. I really think that block should be reserved for the new Block things! As we have used the term block for the container aspect for so long we probably have keep that (although plugin probably would be easier to understand for outsiders). To me, the term plugin has a distinct connotation: that of something conforming to some plugin API published by the hosting framework, like in Eclipse or Maven. In Cocoon, with the 2.1-style blocks there is (as Reinhard said) no contract in view at all, and in the new Blocks when we speak of the block contract we mean the block-specific contract that expresses the service(s) provided by the block, right? IIUC, the interface that makes a Block function like a plugin is not an API at all, rather it's the structure+content conventions (e.g. COB-INF, etc.) that you spoke of... is that correct? In that case, I don't see plugin as a natural term to apply to either the old-skool blocks or the c2.2 Blocks. I think plugin has the potential to engender more confusion than it alleviates... :-/ IMHO, going forward the things like CForms, Ajax, Batik etc. should no longer be called blocks at all... rather they should be called optional modules, because that's all they are. They are Maven modules, and they are optional because you have the choice whether or not to name them in your POM (in 2.1, blocks were optional because you had the choice whether or not to build them, but... that was then, this is now! :-). Even though these were called blocks before, I don't think that should stand in the way of this nomenclature shift. If all of a sudden we start talking about the CForms module instead of the CForms block, that's not going to cause anybody's brain to melt. It's pretty obvious what is going on and people will pick up the change readily. Right now we have core/ and blocks/; I would propose renaming the blocks directory to optional, changing the nomenclature in the docs, and the text of the Block Samples section of the samples page rewritten (that's horribly out of date and was in need of a rewrite even in 2.1!) Don't you love nomenclature changes? [1] Cheers, —ml— [1] — http://en.wikipedia.org/wiki/Knights_who_say_Ni
Re: What is the deal with blocks
On Jan 2, 2007, at 11:32 AM, Mark Lundquist wrote: IMHO, going forward the things like CForms, Ajax, Batik etc. should no longer be called blocks at all... rather they should be called optional modules, because that's all they are. OTOH, I should think that it would be perfectly OK if some optional modules happened to include real Block(s). My proposed nomenclature change isn't meant to imply some mutually exclusive thing, nor should the structure of our sources or artifacts. For instance, maybe Portal, Lucene, and/or Captcha are things that would work well as Blocks. I don't really know enough yet to say for sure. Other things like CForms don't really provide services, they are more like infrastructure things. cheers, —ml—
Re: [jira] Commented: (COCOON-1975) cocoon-core-M2 could not be runned because of missing dependencies on avalon-framework-api-4.3 and excalibur-instrument-api-2.1
Reinhard Poetz napisał(a): I can reproduce this, today. I could swear that it worked when I cut the release two weeks ago also with an empty local repository. Any idea what's going on here? After reading debug log of Maven I can describe what happens partly: In some parent poms (like cocoon's root pom) there is declaration of apache.snapshot repository where avalon stuff is stored in. For some reason when it comes that Maven should get pom of avalon-framework-impl-4.3 it forgets about apache.snapshot and checks only central. She fails to download POM so it uses default pom. Processing other part of dependency graph Maven suddenly recalls about apache.snapshot repo but it's too late. Default pom is being used so she does not try to download real pom, and also does not try to resolve dependencies. So what the avalon-framework-api-4.3.jar comes from? It seems (I'm not sure!) that default pom means also search the jar default location on all repositories, and surprisingly Maven manages to find right jar on apache.snapshot ;-) I think it's no point to release new version of core because *dependencies seem to be correct*. It's only question how to make Maven to not forget about repository, I think the easiest way is to add information about repository to the archetypes (tested and it works). Few sentences of _speculation_: I'm not Maven expert so it's my guessing (and only guessing) but I think Maven goes crazy when pom has declared parent explicitly and at other place is referenced by other pom as dependency. Then the situation looks like pom has two parents and one of them is being rejected. I had no time to verify this hypothesis but if I'm wrong you can shout at me and save some of my time :) I'll try to clarify situation by debugging Maven but I feel it won't be piece of cake for me (any hints appreciated!). You can expect some results on Friday. -- Best regards Grzegorz Kossakowski
Object pooling considered harmful
One complication in our work in making the Cocoon components work in a standard Spring container without special Avalon support is that a large amount of our components are Poolable (or more specifically Recyclable). And Spring doesn't have any concept of object pooling. Even worse Spring doesn't even have a concept of returning components to the container. For singletons the container can call a destroy method when the component goes out of scope. But for non singletons (prototypes) your are on your own and have to take care of destroying the component yourself. Of course it is possible to implement pooling for Spring anyway, but Spring doesn't help us. --- o0o --- So I started to search the web to find out if anyone else had done some work on extending Spring with object pooling support. And found nothing. But what I did found were some articles that explained, rather convincingly, that object pooling will decrease rather than increase performance in most cases [1]. What is this object pooling about? Once, long time ago, Java was really slow in creating and destroying objects (it was actually slow in doing about anything). So one optimization trick was to keep a pool of objects and clean them and reuse them instead of destroying them and creating new ones. In Cocoon this is done for nearly all sitemap components. Now with modern JVMs (1.2 and later), things has changed dramatically. Creation and destruction of objects is amazingly fast. A new Object() is about 10 machine instructions in HotSpot 1.4.2 and later, while the best performing malloc in C requires 60-100 machine instructions [1]. And for short lived object, like most sitemap components that only has request scope, destruction has most often zero cost. For pooled object OTH, their object graphs must be traversed by the GC. They also bulk up memory and might create synchronization bottle necks for the object pools. Handling pooling is also rather intrusive in the code as one have to keep track on the recycling everywhere. The conclusion in [1] is that object pooling today only is worthwhile for small object that are very expensive to create. Taking a look on what kind of objects that are recycled in Cocoon core all components that I found are really simple to create. Most objects just have a number of fields that are nulled in the recycle method. For these objects already the recycle method might be more expensive than destruction + creation. The most heavy components also contains a few array lists or hash maps that are cleared in the recycle method. That is about it. --- o0o --- My proposal is that we don't bother trying to implement object pooling for POJOfied Cocoon components, we should use prototype scope instead in Spring. Actually I would go even further and suggest that we just turn off recycling in the Avalon-Spring adapter and treat Poolables as prototypes. I also suggest that we deprecate all recycle methods in our abstract base classes for sitemap components. This will AFAICS, booth improve Cocoons performance and simplify the implementation. WDYT? [1] http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends, http://www-128.ibm.com/developerworks/java/library/j-jtp01274.html
Re: What is the deal with blocks
Mark Lundquist skrev: On Dec 28, 2006, at 3:08 PM, Daniel Fagerstrom wrote: As you can see there was a quite gradual divergence from the original concept to what we have today. IMO it would be preferable to just use the word block in one of the two uses of the the word. +100. Please, please, yes. I really think that block should be reserved for the new Block things! -100 ;) Seriously, we have used the term block for the container aspect for like 5 years, and it is used in that sense everywhere in the documentation, code and in the mailing list. People would be seriously confused if we tried to change that now. Finding some term that doesn't contain the word block for polymorphic servlet services, would be much less of a problem as it is different from the original block concept and not that many people have used the blocks-fw yet. So if someone have suggestions for a better terminology for the polymorphic servlet services I at least would be prepared to go for it. As we have used the term block for the container aspect for so long we probably have keep that (although plugin probably would be easier to understand for outsiders). To me, the term plugin has a distinct connotation: that of something conforming to some plugin API published by the hosting framework, like in Eclipse or Maven. In Cocoon, with the 2.1-style blocks there is (as Reinhard said) no contract in view at all, and in the new Blocks when we speak of the block contract we mean the block-specific contract that expresses the service(s) provided by the block, right? IIUC, the interface that makes a Block function like a plugin is not an API at all, rather it's the structure+content conventions (e.g. COB-INF, etc.) that you spoke of... is that correct? In that case, I don't see plugin as a natural term to apply to either the old-skool blocks or the c2.2 Blocks. I think plugin has the potential to engender more confusion than it alleviates... :-/ Already 2.1 blocks provides services, classes and resources. Eclipse plugins also provide services, classes and resources. It is not that different. IMHO, going forward the things like CForms, Ajax, Batik etc. should no longer be called blocks at all... rather they should be called optional modules, because that's all they are. They are Maven modules, and they are optional because you have the choice whether or not to name them in your POM (in 2.1, blocks were optional because you had the choice whether or not to /build/ them, but... that was then, this is now! :-). Even though these were called blocks before, I don't think that should stand in the way of this nomenclature shift. If all of a sudden we start talking about the CForms module instead of the CForms block, that's not going to cause anybody's brain to melt. It's pretty obvious what is going on and people will pick up the change readily. Right now we have core/ and blocks/; I would propose renaming the blocks directory to optional, changing the nomenclature in the docs, and the text of the Block Samples section of the samples page rewritten (that's horribly out of date and was in need of a rewrite even in 2.1!) Maven modules OTH just provide classes and resources, no services. Don't you love nomenclature changes? [1] Actually, no ;) /Daniel
Re: Object pooling considered harmful
On 02.01.2007 23:05, Daniel Fagerstrom wrote: One complication in our work in making the Cocoon components work in a standard Spring container without special Avalon support is that a large amount of our components are Poolable (or more specifically Recyclable). And Spring doesn't have any concept of object pooling. Even worse Spring doesn't even have a concept of returning components to the container. For singletons the container can call a destroy method when the component goes out of scope. But for non singletons (prototypes) your are on your own and have to take care of destroying the component yourself. Of course it is possible to implement pooling for Spring anyway, but Spring doesn't help us. Not that I want to propagate pooling, but Spring at least provides some support: http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/aop/target/CommonsPoolTargetSource.html http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/beans/factory/config/Scope.html I don't know anything about the CommonsPoolTargetSource, but the Scope obviously provides a destruction callback mechanism. You only need to know the end of the scope, what's easy for request or session. Don't know what other scopes might apply. I'd mostly refrain from pooling as well. But where we need it, we have still options. Jörg
Re: What is the deal with blocks
Daniel Fagerstrom wrote:
Don't you love nomenclature changes? [1]
Actually, no ;)
neither do I
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: What is the deal with blocks
On Jan 2, 2007, at 2:36 PM, Daniel Fagerstrom wrote: Finding some term that doesn't contain the word block for polymorphic servlet services, would be much less of a problem as it is different from the original block concept and not that many people have used the blocks-fw yet.Fair enough :-) So if someone have suggestions for a better terminology for the polymorphic servlet services I at least would be prepared to go for it. How about just services? E.g., • services-fw • ServiceServlet(or CocoonServiceServlet?) • ServiceContext(or CocoonServiceContext?) • service: protocol Seems like a reasonable shorthand for polymorphic servlet services. I'll admit that ServiceServlet is a little unwieldy, but I could live with it. [snipped... plugins?] Already 2.1 blocks provides services, classes and resources. Eclipse plugins also provide services, classes and resources. It is not that different. Right, not all that different. To me, plugin still implies plugin API, but I wouldn't start a fight over it. Anyway since we agree that the polymorphic servlet services is the thing that's to be renamed, plugin might not be a good choice for that, since as you say 2.1 blocks already provide the things that to you (and presumably to others) comprise a plugin. Maven modules OTH just provide classes and resources, no services. Yes — maven modules provide classes and resources for the system being built. Maven plugins (mojos), OTOH, do provide a primitive kind of service to maven itself. BTW, thx for the great summary of the history/progression of the blocks framework development — that was really helpful. cheers, —ml—
Re: What is the deal with blocks
On Jan 2, 2007, at 3:07 PM, Reinhard Poetz wrote: Don't you love nomenclature changes? [1] Actually, no ;) neither do I hey, I was kidding about the love it part :-) —ml—
[continuum] BUILD ERROR: Cocoon Common
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/58/buildId/1469 Build statistics: State: Error Previous State: Error Started at: Wed, 3 Jan 2007 00:19:38 + Finished at: Wed, 3 Jan 2007 00:19:39 + Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Configuration Implementation
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/61/buildId/1470 Build statistics: State: Error Previous State: Error Started at: Wed, 3 Jan 2007 00:19:42 + Finished at: Wed, 3 Jan 2007 00:19:43 + Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Environment [modules]
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/63/buildId/1471 Build statistics: State: Error Previous State: Error Started at: Wed, 3 Jan 2007 00:19:48 + Finished at: Wed, 3 Jan 2007 00:19:49 + Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Environment API
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/64/buildId/1472 Build statistics: State: Error Previous State: Error Started at: Wed, 3 Jan 2007 00:19:49 + Finished at: Wed, 3 Jan 2007 00:19:50 + Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Environment Implementation
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/65/buildId/1473 Build statistics: State: Error Previous State: Error Started at: Wed, 3 Jan 2007 00:19:50 + Finished at: Wed, 3 Jan 2007 00:19:51 + Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
Changes to CForms in 2.1.11-dev
Hi All
A lot of work is being done on CForms for the 2.1.11 release.
It may be a bit disruptive temporarily to users' projects, but IMHO
it will be worth it.
What if all you do is write a few simple forms and use the standard
form-processing pipelines and xslt?
There will be very little to do to move to cocoon 2.1.11 as most of
the changes are handled by those built-in resources.
A list of the changes :
1. Update the Dojo Libraries to 0.4.1, the latest release (with a few
fixes).
Dojo 0.4.1 seems faster, more stable and more compatible across
browsers.
It brings many benefits, the main one IMHO was the ability to do item
(2).
2. Switch to using namespaces for Dojo Widgets.
The switch to Dojo 0.4.1 allows us to use namespaces for Widgets.
Although in the short-term it may feel that replacing stuff like
dojoType=CFormsSuggest with dojoType=forms:CFormsSuggest is a
PIA, it brings great advantages.
The client-side code now consists of 3 namespaces :
dojo : all of dojo, the default (no need for a prefix)
forms : widgets from the cocoon.forms module
ajax : widgets from the cocoon.ajax module
These namespace modules are registered with dojo and a manifest is
provided so their widgets can be auto-loaded.
What this means is that instead of for example, our XSLT adding
dojo.require(some.package) because something might possibly be wanted
from it, we can leave the dojo.require declarations out, libraries in
the modules load because their module path is registered, widgets
load automatically because they have a resolver in their manifest.
The hack of dojo.require in cocoon.js is no longer required, or used
(or compatible).
It now becomes far easier for you to develop dojo widgets in your own
namespace and have them auto-loaded as well.
If you have custom dojo-savvy js libraries to load you'd do something
like this :
dojo.registerModulePath(myorg.modulename, ../myorg/modulename/
js);
dojo.require(myorg.modulename.mybrilliantlibrary);
. . .
// do something with my library after everything has safely
loaded :
dojo.addOnLoad(function()
{ myorg.modulename.mybrilliantlibrary.doSomethingAstonishing(); });
Dojo would load : _cocoon/resources/myorg/modulename/js/
mybrilliantlibrary.js
This could be served from either :
build/webapp/resources/myorg/modulename/js/mybrilliantlibrary.js
or from a jar file in build/webapp/WEB-INF/libs/ with a package path
like :
org/apache/cocoon/myorg/resources/modulename/js/
mybrilliantlibrary.js
Your library must at least say :
dojo.provide(myorg.modulename.mybrilliantlibrary);
Say your project required you to extend some of CForm's or Dojo's
widgets, the cleanest and simplest thing to do will be to do that in
your own namespace.
Say you were writing Widgets in the same registered module as above,
you would provide a manifest file which dojo would try to load from
here :
_cocoon/resources/myorg/modulename/manifest.js (NB. it is in
modulename/ not modulename/js/).
Your manifest would typically register a namespace like this :
dojo.registerNamespace(mystuff, myorg.modulename,
resolverFunction);
Then it would provide a resolverFunction that maps between lowercase
widget names and a full packagename.
See the manifests in the forms and ajax blocks for an example.
You would use your widgets like this :
div dojoType=mystuff:FunkyMonkey/
and dojo would attempt to load : _cocoon/resources/myorg/modulename/
js/FunkyMonkey.js
As we move more of our CForms widget implementations to dojo, this
will lead to a dramatic reduction of unnecessary code being loaded by
the browser (a big problem in previous versions imho).
3. Cleanup of the client-side code.
Apart from a general push to convert all of cocoon's javascript
(clientside and serverside) into namespaced javascript as a general
best practise, I felt that the existing implementation of the
clientside code was more complex/opaque than it needed to be.
forms_lib.js and cocoon.forms.common have been refactored.
forms_* functions in forms_lib.js have been deprecated and are
replaced by nearly equivalent functions in cocoon.forms.* the old
functions can still be called (temporarily) they do their best to
pass the calls on to the new implementation.
One issue dealt with by this update, is removing barriers to having
multiple cforms per page. This required changing some of the
parameters passed to functions like adding onSubmit handlers, we now
need a reference to the form as well as the handler. Another side
effect of this is that forms now need id attributes. If you do not
have one in your template, one is added for you in the standard
CForms rendering pipelines.
If you are not writing your own CForms Widgets, you are unlikely to
be effected.
4. Dojo widgets for ajax and non-ajax forms.
CFormForm.js which used to be the Dojo Widget used for ajax-enabled
CForms
Changes to CForms in trunk
Hi All As you may have seen from my previous message, I have ripped the bejebus out of CForms over the holidays and just committed the changes. I have the changes all tested and running in BRANCH_2.1.X, but have not/cannot test in trunk (umm, are samples working yet?). My understanding is that the forms block is shared between 2.1.X and 2.2, so no problem there (I hope). But 2.1.X uses the dojo in lib/optional/dojo-[date].jar and trunk uses blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/ apache/cocoon/dojo/resources/dojo-[version]-[profile].zip, which must have been expanded and built into the jar by building the package. Does this sound right? Or is there more to do to support this change in trunk ? thanks regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Changes to CForms in 2.1.11-dev
Jeremy,
Does this break binary compatibility? Some of the changes sound like
users who upgrade from 2.1.10 to 2.1.11 may have to modify their
application? If so, I see that as a problem.
Ralph
Jeremy Quinn wrote:
Hi All
A lot of work is being done on CForms for the 2.1.11 release.
It may be a bit disruptive temporarily to users' projects, but IMHO it
will be worth it.
What if all you do is write a few simple forms and use the standard
form-processing pipelines and xslt?
There will be very little to do to move to cocoon 2.1.11 as most of
the changes are handled by those built-in resources.
A list of the changes :
1. Update the Dojo Libraries to 0.4.1, the latest release (with a few
fixes).
Dojo 0.4.1 seems faster, more stable and more compatible across browsers.
It brings many benefits, the main one IMHO was the ability to do item
(2).
2. Switch to using namespaces for Dojo Widgets.
The switch to Dojo 0.4.1 allows us to use namespaces for Widgets.
Although in the short-term it may feel that replacing stuff like
dojoType=CFormsSuggest with dojoType=forms:CFormsSuggest is a PIA,
it brings great advantages.
The client-side code now consists of 3 namespaces :
dojo : all of dojo, the default (no need for a prefix)
forms : widgets from the cocoon.forms module
ajax : widgets from the cocoon.ajax module
These namespace modules are registered with dojo and a manifest is
provided so their widgets can be auto-loaded.
What this means is that instead of for example, our XSLT adding
dojo.require(some.package) because something might possibly be wanted
from it, we can leave the dojo.require declarations out, libraries in
the modules load because their module path is registered, widgets load
automatically because they have a resolver in their manifest. The hack
of dojo.require in cocoon.js is no longer required, or used (or
compatible).
It now becomes far easier for you to develop dojo widgets in your own
namespace and have them auto-loaded as well.
If you have custom dojo-savvy js libraries to load you'd do something
like this :
dojo.registerModulePath(myorg.modulename,
../myorg/modulename/js);
dojo.require(myorg.modulename.mybrilliantlibrary);
. . .
// do something with my library after everything has safely loaded :
dojo.addOnLoad(function(){
myorg.modulename.mybrilliantlibrary.doSomethingAstonishing(); });
Dojo would load :
_cocoon/resources/myorg/modulename/js/mybrilliantlibrary.js
This could be served from either :
build/webapp/resources/myorg/modulename/js/mybrilliantlibrary.js
or from a jar file in build/webapp/WEB-INF/libs/ with a package path
like :
org/apache/cocoon/myorg/resources/modulename/js/mybrilliantlibrary.js
Your library must at least say :
dojo.provide(myorg.modulename.mybrilliantlibrary);
Say your project required you to extend some of CForm's or Dojo's
widgets, the cleanest and simplest thing to do will be to do that in
your own namespace.
Say you were writing Widgets in the same registered module as above,
you would provide a manifest file which dojo would try to load from
here :
_cocoon/resources/myorg/modulename/manifest.js (NB. it is in
modulename/ not modulename/js/).
Your manifest would typically register a namespace like this :
dojo.registerNamespace(mystuff, myorg.modulename,
resolverFunction);
Then it would provide a resolverFunction that maps between lowercase
widget names and a full packagename.
See the manifests in the forms and ajax blocks for an example.
You would use your widgets like this :
div dojoType=mystuff:FunkyMonkey/
and dojo would attempt to load :
_cocoon/resources/myorg/modulename/js/FunkyMonkey.js
As we move more of our CForms widget implementations to dojo, this
will lead to a dramatic reduction of unnecessary code being loaded by
the browser (a big problem in previous versions imho).
3. Cleanup of the client-side code.
Apart from a general push to convert all of cocoon's javascript
(clientside and serverside) into namespaced javascript as a general
best practise, I felt that the existing implementation of the
clientside code was more complex/opaque than it needed to be.
forms_lib.js and cocoon.forms.common have been refactored.
forms_* functions in forms_lib.js have been deprecated and are
replaced by nearly equivalent functions in cocoon.forms.* the old
functions can still be called (temporarily) they do their best to pass
the calls on to the new implementation.
One issue dealt with by this update, is removing barriers to having
multiple cforms per page. This required changing some of the
parameters passed to functions like adding onSubmit handlers, we now
need a reference to the form as well as the handler. Another side
effect of this is that forms now need id attributes. If you do not
have one in your template, one is added for you in the standard CForms
rendering pipelines.
If you are not writing your own CForms
Re: Changes to CForms in trunk
Jeremy Quinn wrote:
Hi All
As you may have seen from my previous message, I have ripped the bejebus
out of CForms over the holidays and just committed the changes.
I have the changes all tested and running in BRANCH_2.1.X, but have
not/cannot test in trunk (umm, are samples working yet?).
My understanding is that the forms block is shared between 2.1.X and
2.2, so no problem there (I hope).
But 2.1.X uses the dojo in lib/optional/dojo-[date].jar and trunk uses
blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/dojo/resources/dojo-[version]-[profile].zip,
which must have been expanded and built into the jar by building the
package.
Does this sound right?
Or is there more to do to support this change in trunk ?
IIRC that's all. After providing an initial documentation for 2.2, working on
the release of some blocks will be the next item on my todo list. CForms and
Ajax will definitly be part of this list of blocks. Expect some feedback from me
then!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
