Re: Micro-Cocoon ... Corona
Luca Morandini wrote:
Sylvain Wallez wrote:
So we can take a different approach, and consider that we can use
plain programming languages rather than grow our own
pseudo-languages. A well-defined Java API and its Javascript
binding would make people way more productive than an XML-based
language like the sitemap.
Do you mind terribly showing me an example of the use of this API ?
Something like:
CocooonStream stream= new CocoonStream(file, documents/mydoc.xml);
stream.transform(xslt, xsl/doc2html.xsl);
return stream.serialize(html);
Yes, something like that. But add in the mix the often discussed
content-aware selection (see [1] for the Flickr API):
CocoonStream stream = new CocoonStream(url,
http://api.flickr.com/services/rest/?method=flickr.test.echoname=foo;);
if (stream.inspect(xpath, /[EMAIL PROTECTED]'ok'])) {
doSomeUsefulApplicationStuff();
stream.transform(xslt, xsl/flickr-success.xsl);
} else {
stream.transform(xslt, xsl/flickr-error.xsl);
}
return stream.serialize(html);
I understand the usefulness of having a programmatic API and this
approach plays well with the Java monoculture, but, there aren't
libraries already doing that ?
I don't think we're talking about monoculture here, but about avoiding
the clumsyness of a reinventing a real programming language in XML. Such
an API can be mapped to the language of your choice: Javascript, Python,
Ruby, Scala or whatever language is available on the JVM, including but
not limited to the sitemap.
About existing APIs, javax.xml.transform addresses part of it (it
doesn't have stream inspection though) but it often perceived as
difficult to grasp from the simple fact that you have to wire the
pipeline backwards, starting with the serializer.
Sylvain
[1] http://www.flickr.com/services/api/request.rest.html
--
Sylvain Wallez - http://bluxte.net
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: Reinhard Poetz wrote: This time I will create the Maven 2 release artifacts and normal zip/tar release artifacts for non-Maven users. I created release artifacts for the Servlet-Service framework using the old RC1 release form October last year and published them to http://people.apache.org/~reinhard/cocoon-staging/ssf/. Could others please have a look and check if those release artifacts meet all legal requirements? I see that the META-INF/NOTICE.txt etc. files in each of cocoon-components and impl directory, would correspond with those from the sources. However where does top-level NOTICE.txt file come from? Should it be generated as a combination of the other two? The files in the sub-directories could potentially be different. I expected a top-level cocoon-servlet-service directory to be created. Should it? -David
Re: Test release artifacts - Legal requirements check
I saw that some committers have been using lowercase filenames e.g. notice.txt, so the release-builder needs to handle that. -David
Re: Normal release artifacts
Vadim Gritsenko wrote: Reinhard Poetz wrote: Reinhard Poetz wrote: I have started to write some Ant scripts to produce non-Maven release artifacts. This will of course help everybody who doesn't want to use Maven or Ivy for dependency management but will also bundle all the information that belongs together (src, binaries, docs, javadocs, licensing information). Most of the work has been finished but now I got stuck with the question if we should ship third-party libs or not. E.g. for the Spring configurator this would be everything listed at http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/1.0/dependencies.html . The advantages are that the user gets everything that she needs but the disadvantages are that we would have to add all license files of all 3rd-party libs (AFAIK there is no automatic mechanism for that) and the download size would increase. And I think that in 2008 you shouldn't manage your library dependency graph manually anymore in your projects (Maven, Ivy, the Maven Ant tasks are of great help and at least the last one is very easy to use.) Finally, if we decide to ship 3rd party libs, one technical question: Am I right that there is no automatic mechanism for Ant or Maven that pulls together all license information of all 3rd-party libs? That would be good. At Forrest, we have similar issues not yet solved. And, if we decide to not ship 3rd party libs, am I right that we don't have to add license files of them? (Otherwise all artifacts on the central Maven repository would be legally broken ...) Any comments? Perhaps legal-discuss@ list can help. Anyone? If I don't hear anything I will *not* include any third-party stuff (the only exception will be the getting-started stuff). Users will have to download all libraries themselves. IMHO what's good a downloadable release if 'cocoon.sh run' does not work? One of the points of such release is to make it one stop shop, to get everything up and running in one quick download. May be it's just me. Shrug. What does the getting-started stuff include? Perhaps we include the bare minimum and list exactly the other supporting products that they need to go further. Any supporting products that we do bundle, need their source too. -David
[jira] Closed: (COCOON-2150) Error on resetting response
[ https://issues.apache.org/jira/browse/COCOON-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2150. Resolution: Fixed Fix version (Component): Parent values: Servlet Service Framework(10247). Level 1 values: 1.0.0-RC2-dev(10316). (was: Parent values: Servlet Service Framework(10247). ) Fixed (hopefully) definitively in r637416, r637417, r637418 and r637419. Error on resetting response --- Key: COCOON-2150 URL: https://issues.apache.org/jira/browse/COCOON-2150 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Jörg Heinicke Assignee: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) This is the exception shown on the console: java.lang.IllegalStateException: Committed at org.mortbay.jetty.Response.resetBuffer(Response.java:855) at org.mortbay.jetty.Response.reset(Response.java:834) at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:182) at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:576) at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:545) at org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy2.service(Unknown Source) at org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459) It seems to be thrown whenever the response object is reseted after the actual response has been sent by the sitemap error handler. In this case reset is no longer possible since the response has already been committed as stated in the error message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
COCOON-2150 testing
Hello guys, I believe that COCOON-2150 is finally fixed but that was quite radical change involving lots of conditional coding craft so I cannot be entirely sure if I hadn't missed any obscure case. Therefore I would like you to give latest trunk Cocoon version extensive testing and observing if there are no errors reported by servlet container or Cocoon. I plan to decorate this code with some comments to increase readability. -- Best regards, Grzegorz
Re: Micro-Cocoon ... Corona
Sylvain Wallez wrote: Luca Morandini wrote: Do you mind terribly showing me an example of the use of this API ? Something like: CocooonStream stream= new CocoonStream(file, documents/mydoc.xml); stream.transform(xslt, xsl/doc2html.xsl); return stream.serialize(html); Yes, something like that. But add in the mix the often discussed content-aware selection I remember that one, it was one of my first gripes with Cocoon, circa 2001... gee, that's 7 years ago ! I understand the usefulness of having a programmatic API and this approach plays well with the Java monoculture, but, there aren't libraries already doing that ? I don't think we're talking about monoculture here, but about avoiding the clumsyness of a reinventing a real programming language in XML. Point taken, though having a single place to look at in order to understand the URI routing has its merits. Moreover, since the introduction of Flowscript, the tricky things can be done in it, leaving the sitemap declarative syntax to what it does best. About existing APIs, javax.xml.transform addresses part of it (it doesn't have stream inspection though) but it often perceived as difficult to grasp from the simple fact that you have to wire the pipeline backwards, starting with the serializer. Ok, but... (bear with my my ignorance a bit more) is *that* difficult to develop such an API ? I mean, the classes dealing with the sitemap are already doing that, isn't just a matter of spreading an API over them ? Regards, Luca Morandini www.lucamorandini.it
Re: Micro-Cocoon ... Corona
Luca Morandini wrote: Sylvain Wallez wrote: snip/ About existing APIs, javax.xml.transform addresses part of it (it doesn't have stream inspection though) but it often perceived as difficult to grasp from the simple fact that you have to wire the pipeline backwards, starting with the serializer. Ok, but... (bear with my my ignorance a bit more) is *that* difficult to develop such an API ? I mean, the classes dealing with the sitemap are already doing that, isn't just a matter of spreading an API over them ? Oh, I don't think it's a giant task, and what we wrote in this thread is pretty close to the current pipeline interface [1]. But it was designed as support code for the sitemap because this was the target goal, and thus it contains some sitemap-isms. We probably need to polish it by thinking the other way around, i.e. start aim at a clean Java API on top of which we can add and XML language... if we want. Sylvain [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-api/src/main/java/org/apache/cocoon/components/pipeline/ProcessingPipeline.java -- Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Reinhard Poetz wrote: Of course we are! We only have to work out the details of how we do it. The main question is, if we have to go through ASF IP clearance or not. Since it's rather a proposal than a finished project (~700 lines of code), I think it's enough if Steven sends in an CLA and attaches the code to a Jira issue. In the meantime (until Steven's CLA is recorded) we could prepare a snapshot package of Corona that we make privatly available to the Cocoon PMC. Is this a viable procedure? I consider that it is. It is your creative work, so it is just contributed under your Individual CLAs. You and Steven declare that you have the rights to contribute it. For your benefit, you might need the Corporate CLA if your ability to contribute is not clear with respect to your employment agreement. Probably okay in your case. -David
