Re: [VOTE] Javier Puerto as cocoon committer
+1 and welcome! Joerg On 28.05.12 10:26, Thorsten Scherler wrote: He is an ASF committer in Apache Droids and I think he would make a great addition to our team. He contributes now on a regular base and lately as well started to dig into many issues that are critical for the c3 release.
Re: [VOTE] Require Java 1.6 for Cocoon3
+1 Joerg On 19.09.2011 23:03, Nathaniel, Alfred wrote: Hi all, A few weeks ago we had a discussion [1] whether to increase for Cocoon3 the minimum Java version from 1.5 to 1.6. There were a number of advantages identified to be gained by using Java6, which I don't want to repeat here, The only downside is the exclusion of potential C3 users locked in to Java5. A survey on the user list [2] asking users to step forward if that really applied to anybody did not yield any response. Therefore I' call the vote on Code Modification [3]: +1 = Yes, Cocoon3 shall require Java 1.6 -1 = No, Cocoon3 must remain usable with Java 1.5 (with justification for the veto) This change is targeted only at Cocoon3. Cocoon2.1 and Cocoon2.2 are not affected. Please cast your votes before Mon 3 Oct 06:00 UTC. Here is mine: +1 Cheers, Alfred. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg59791.html [2] http://www.mail-archive.com/users@cocoon.apache.org/msg46231.html [3] http://www.apache.org/foundation/voting.html The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
Re: How-to disable caching for Cocoon2.2 completely
You can switch off caching per pipeline. There is a non-caching pipeline. Please don't ask me for details though - too long ago :-) Joerg On 17.02.2011 14:42, Robby Pelssers wrote: I would like to check out the performance without any caching and check if I can live with it... if so it will at least solve my corrupted cache issue.
Re: SAXGenerator - URLGenerator
On 14.12.2009 09:33, Reinhard Pötz wrote: On Sun, Dec 13, 2009 at 3:59 PM, Joerg Heinickejoerg.heini...@gmx.de wrote: A long time ago I argued for renaming the FileGenerator to XMLGenerator since the generators are usually named after the input they accept (Midi, HTML, Directory, JSP, JXTemplate, etc.). I'm not sure SAXGenerator reflects that exactly but it's good enough I guess. I agree that we should have one consistent naming scheme and since we usually use the input type, we shouldn't change it for this case. I see two solutions in order to get a consistent naming of our components: a) We rename SAXGenerator AND StAXGenerator to XMLGenerator or b) We add the SAX prefix to all pipeline components. I'm in favor of a) because SAX or StAX is already part of the package name and looking at the implemented interfaces makes it clear what underlying event mechanism is used. I agree with your reasoning. Regards, Joerg
Re: [vote] Simone Tripodi as new Cocoon committer
On 13.12.2009 14:58, Reinhard Pötz wrote: I propose Simone Tripodi as a new Cocoon committer and PMC member. +1 Joerg
Re: SAXGenerator - URLGenerator
On 13.12.2009 14:44, Reinhard Pötz wrote: Long time ago (I think when the StAX module was added) we discussed to have a SAXGenerator which is mainly useful when the pipeline API is used. It has constructors for File, InputStream, String and Node. See http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/SAXGenerator.java I also renamed FileGenerator to URLGenerator because this better reflects what it really does. But thinking more about this it would also make sense to merge the URLGenerator into the SAXGenerator. WDYT? A long time ago I argued for renaming the FileGenerator to XMLGenerator since the generators are usually named after the input they accept (Midi, HTML, Directory, JSP, JXTemplate, etc.). I'm not sure SAXGenerator reflects that exactly but it's good enough I guess. Joerg
Re: [jira] Commented: (COCOON3-46) URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null
Oh, you're right :-) I only read your mail on the mailing list, not the complete issue text. Joerg On 05.12.2009 11:04, Jos Snellings wrote: That is what I did. On Sat, 2009-12-05 at 09:50 +, Jörg Heinicke (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON3-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12786368#action_12786368 ] Jörg Heinicke commented on COCOON3-46: -- Isn't it more convenient if closeQuietly(..) just handles null? URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null --- Key: COCOON3-46 URL: https://issues.apache.org/jira/browse/COCOON3-46 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Jos Snellings Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-3 finally clause in URLResponse method execute() contains call to URLConnectionUtils.closeQuietly. If servletConnection = this.url.openConnection(); fails, servletConnection is null. In that case closeQuietly causes a stacktrace to be output. Solution is if (servletConnection != null) URLConnectionUtils.closeQuietly(servletConnection);, guard the call with a test, or even better, take into account in closeQuietly that the input parameter may be null.
Re: cocoon profiling
On 14.05.2009 13:51, Christoph Leiter wrote: Sebastian Rosensteiner wrote: Sebastian here, one of the students working on cocoon-profiling. We are about to build a suitable data structure for the profiling data, and we are now facing the problem that a lot of data we store is redundant. This is because some of our aspects are very generic and intercept calls of the same object (e.g. a PipelineComponent) several times, storing the same information in several ProfilingData objects. I see no way to make the aspects more specific, since we have no information which servlets, sitemaps and pipeline components might be used and which methods are called. Measuring the runtime of servlets, sitemaps and pipeline components is now done at a method basis, which means that we have accurate data on the runtime of the intercepted methods, but no data on the runtime (lifetime) of a specific servlet or pipeline component. this may sound a bit confusing to everyone not that much involved in this subproject. I agree :) The bigger picture is needed - or a concrete example. Joerg
Re: [C3] Sitemap implemented in Scala
On 05.03.2009 00:33, Grzegorz Kossakowski wrote: Now I'll give a few words of comments why I find my implementation easier to follow. First of all, sitemap processing is divided into a few distinct stages: 1. Sitemap parsing 2. Sitemap reduction 3. Sitemap invocation 3.1 Actions execution 3.2 Pipeline building 3.3 Pipeline execution 3.4 Catching possible exception 4. If exception catched, reduction of handle errors node 5. Handling exception with reduction result What's more, for most of the time code is based on immutable structures which is the biggest advantage. What I found hard with current implementation hard is InvocationImpl passed around that quite a lot of state. If you combine it with InvocationResult switches (cases) that every node has to return in its invoke() method the result isn't really appealing. This sort of resembles mistakes from C2.x where big, mutable objects were passed around leading to unmaintainable code. I'm interested in hearing your opinions on that subject. I know that's rather hard to judge rather big piece of code in unfamiliar language but I'm sure you can easily get some overall feeling about my implementation and ideas behind it. I don't have the time to actually look into your implementation. I'm just wondering if all the insight views couldn't be used to improve the Java implementation rather than starting something in a different language. Joerg
[Travel Assistance] Applications for ApacheCon EU 2009 - Now Open
Original Message Subject: [Travel Assistance] Applications for ApacheCon EU 2009 - Now Open Date: Fri, 23 Jan 2009 13:28:19 + From: Tony Stevenson pct...@apache.org Reply-To: commun...@apache.org To: travel-assista...@apache.org The Travel Assistance Committee is now accepting applications for those wanting to attend ApacheCon EU 2009 between the 23rd and 27th March 2009 in Amsterdam. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon EU 2009 who need some financial support in order to get there. There are very few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF or open source in general. Financial assistance is available for travel, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in the United States or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon EU of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the online application form. Time is very tight for this event, so applications are open now and will end on the 4th February 2009 - to give enough time for travel arrangements to be made. Good luck to all those that apply. Regards, The Travel Assistance Committee
Re: ForrestBot build for cocoon-docs FAILED
On 18.10.2008 14:25, [EMAIL PROTECTED] wrote: [java] X [0] 2.1/prepare-mojo.html BROKEN: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy (Is a directory) [java] ^ 2.1/userdocs/flow/file:/home/daisy/tmpdocimport/documentation/apidocs/org/apache/cocoon/environment/Request.html [java] ^ 2.1/userdocs/flow/file:/home/daisy/tmpdocimport/documentation/apidocs/org/apache/cocoon/environment/Session.html [java] ^ 2.1/userdocs/flow/file:/home/daisy/tmpdocimport/documentation/apidocs/org/apache/cocoon/environment/Context.html [java] ^ 2.1/userdocs/flow/file:/home/daisy/tmpdocimport/documentation/apidocs/org/apache/cocoon/components/flow/WebContinuation.html [java] Total time: 13 minutes 5 seconds, Site size: 18,514,599 Site pages: 353 [java] Java Result: 1 [echo] Copying broken links file to site root. [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs [echo] Oops, something broke On what exactly can ForrestBot fail? The only thing I get from the report is that there are a broken link and some links with file: somewhere in the middle of the name. Joerg
Re: New Spring Maintenance policy
On 24.09.2008 00:00, Sylvain Wallez wrote: Yeah. I read this as 3 months after release n+1 is out, release n becomes closed source. I'm wondering how long it will take for forks to appear that will provide open source bug fixes to old releases. I don't think that's n+1 but n: After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. They wouldn't talk about initial stability issues anymore if it were n+1. Joerg
Re: New Spring Maintenance policy
On 24.09.2008 17:10, Antonio Gallardo wrote: There is a worst case scenario now: What if they don't collect enough money from subscriptions and do the next step: remove the 3 months window or worse go full closed source? Spring is released with Apache 2 license so we are free to grab and host a fork if it will be necessary. I think changing the rules is not fair at all. That should rings our bells. Most important, our own user base will suffer. Any of our user now have to have in the pocket 16k yearly in order to deploy a cocoon 2.2 based application. That does not sounds good at all. Of course it's a Bad Thing, but they are free to do so and we have to live with it. As it looks now it's gonna be alright. There are many ways to describe the spirit of the apache community, but there is one that I like more than all the others: 'we care about people more than we care about code'. We have to do something. No idea how the one relates to the other :) But I oppose immediate actions. I wrote I really wonder if they are gonna keep up the policy in the state it is right now. And even if there is no reason for immediate actions since it still works. We just have to go from one major release to the next one (which is actually minor) without a lots of intermediate patch releases. Joerg
Re: Help with Continuations
On 23.09.2008 13:39, Jeremy Quinn wrote: I don't see any way of working around this. What a shame, I guess this rules out putting this functionality into a system-level sitemap. That's actually by intention and used to be different. It was Leszek who changed it [1]. One very good reason [2] is the wrong context in a different interpreter and so sitemap. Links wouldn't be resolved correctly anymore. Joerg [1] http://svn.apache.org/viewvc?view=revrevision=106089 [2] http://marc.info/?l=xml-cocoon-devm=110268944032541w=4
Re: New Spring Maintenance policy
On 23.09.2008 22:43, Peter Hunsberger wrote: As the number of versions of Spring used in production grows, it is impossible for us to provide free maintenance for multiple releases and perform backports of issues. Doing so would unfairly subsidize conservative customers who want to remain on a previous version, at the cost of the open source community. The reasoning is totally awkward. Nobody questions discontinuing support for old major releases. But how does the above justify not providing patch releases after 3 month of a major release? [1] They are doing those releases anyway. The last sentence above is purely a joke. At the end the new maintenance policy is a means to push people into the enterprise support program. They are absolutely free to do so, but they should admit it not talk crap. Joerg [1] http://www.springsource.com/products/enterprise/maintenancepolicy
Re: Help with Continuations
On 22.09.2008 17:12, Jeremy Quinn wrote: However, it seems I am unable to retrieve a continuation made in one sitemap, from another sitemap. Can anyone confirm this? As far as I remember the continuations are managed per sitemap. You might have a look at ContinuationsManagerImpl.lookupWebContinuation(..), around line 240, where it checks the continuation against the stored interpreter ID. That's where you should run through if you access a continuation from another sitemap than the one it was created in if I'm not mistaken. Joerg
Re: Patch for NPE in ApplicationUtil (cocoon-auth-api)
Benjamin Boksa mailinglists at boksa.de writes: Hi, today I ran into a NPE when using ApplicationUtil.isUserInRole(…), attached is a patch that allows the User instance passed to isUserInRole(…) to be null. Hope it is OK to submit a patch like that - if there is a better way to do it just let me know. Hi Benjamin, please file an issue in our bug-tracking system Jira [1]. This is especially for legal reasons since you have to grant license to ASF to actually allow us to use your patch in Cocoon. You will find this option I'm talking about when you attach the patch to the issue. Thanks, Joerg [1] https://issues.apache.org/jira/browse/COCOON
ApacheCon US
Hey guys, I'm considering to go to New Orleans. I justed wanted to ask who is planning to go as well and if anybody wants to share a room. Cheers, Joerg
Re: Bug in ContinuationManagerImpl
On 03.09.2008 23:37, Joerg Heinicke wrote: just discovered an exception inside our freshly migrated cocoon 2.2 migration, thrown by the ContinuationManagerImpl: Exception in thread Timer-0 java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(Unknown Source) at java.util.HashMap$ValueIterator.next(Unknown Source) at org.apache.cocoon.components.flow.ContinuationsManagerImpl.invalidateContinuations( ContinuationsManagerImpl.java:390) at org.apache.cocoon.components.flow.ContinuationsManagerImpl$WebContinuationsHolder.valueUnbound( ContinuationsManagerImpl.java:548) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue( AbstractSessionManager.java:1125) Is this a new bug, or am I doing something wrong? It's a new bug I introduced with [1]. Reviewing the changes I did I found that I optimized some code. :-) It's around line 390 [2]. I'll have a look on how to fix it. Sorry for the inconveniences. Hey Gabriel, I committed a fix. Can you please retry and report back? Thanks, Joerg
Re: Bug in ContinuationManagerImpl
On 03.09.2008 21:25, Gabriel Gruber wrote: just discovered an exception inside our freshly migrated cocoon 2.2 migration, thrown by the ContinuationManagerImpl: Exception in thread Timer-0 java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(Unknown Source) at java.util.HashMap$ValueIterator.next(Unknown Source) at org.apache.cocoon.components.flow.ContinuationsManagerImpl.invalidateContinuations( ContinuationsManagerImpl.java:390) at org.apache.cocoon.components.flow.ContinuationsManagerImpl$WebContinuationsHolder.valueUnbound( ContinuationsManagerImpl.java:548) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue( AbstractSessionManager.java:1125) Is this a new bug, or am I doing something wrong? It's a new bug I introduced with [1]. Reviewing the changes I did I found that I optimized some code. :-) It's around line 390 [2]. I'll have a look on how to fix it. Sorry for the inconveniences. Joerg [1] http://svn.apache.org/viewvc?view=revrevision=643752 [2] http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java?r1=643716r2=643752diff_format=h
Re: Bug in ContinuationManagerImpl
On 03.09.2008 23:37, Joerg Heinicke wrote: Exception in thread Timer-0 java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(Unknown Source) at java.util.HashMap$ValueIterator.next(Unknown Source) at org.apache.cocoon.components.flow.ContinuationsManagerImpl.invalidateContinuations( ContinuationsManagerImpl.java:390) at org.apache.cocoon.components.flow.ContinuationsManagerImpl$WebContinuationsHolder.valueUnbound( ContinuationsManagerImpl.java:548) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue( AbstractSessionManager.java:1125) It's a new bug I introduced with [1]. Reviewing the changes I did I found that I optimized some code. :-) It's around line 390 [2]. I'll have a look on how to fix it. Sorry for the inconveniences. Two different proposals: 1. Reintroducing the original workaround using continuationsHolder.holder.values().toArray() in invalidateContinuations(..). 2. Adding iter.remove() directly after iter.next() in line 390. The later problematic call to remove the continuation from the map would just not do anything. WDYT? Joerg [1] http://svn.apache.org/viewvc?view=revrevision=643752 [2] http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java?r1=643716r2=643752diff_format=h
Re: svn commit: r689749 - /cocoon/whiteboard/corona/trunk/corona-sitemap/src/main/java/org/apache/cocoon/corona/sitemap/InvocationImpl.java
On 29.08.2008 07:45, Reinhard Pötz wrote: URL: http://svn.apache.org/viewvc?rev=689749view=rev Log: improve error reporting: print the full stacktrace when the loglevel is set to INFO or below. Otherwise only print the first 5 lines. Shouldn't these kind of things be left to the logging implementation and configuration? If I knew how to do this ... Log4j isn't really well documented. I don't know either. I just felt wrong. Somebody else might know how to do it or implement his own formatter. I saw you already removed it. Thanks :) Joerg
Re: svn commit: r689749 - /cocoon/whiteboard/corona/trunk/corona-sitemap/src/main/java/org/apache/cocoon/corona/sitemap/InvocationImpl.java
On 28.08.2008 09:47, [EMAIL PROTECTED] wrote: Author: reinhard Date: Thu Aug 28 00:47:42 2008 New Revision: 689749 URL: http://svn.apache.org/viewvc?rev=689749view=rev Log: improve error reporting: print the full stacktrace when the loglevel is set to INFO or below. Otherwise only print the first 5 lines. Shouldn't these kind of things be left to the logging implementation and configuration? Joerg
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
Reinhard Pötz reinhard at apache.org writes: XML NAMESPACES --- Since I don't see how version numbers could help, I propose Don't these version numbers just help in the same way as versioned jars help? It's possible to signal additional functionality or incompatibilities. Just look at the Spring framework. We did look at the Spring framework and they don't use versioned namespaces, e.g. http://www.springframework.org/schema/beans, but only versioned XSDs. Oh, I'm sorry I had XSDs in mind when you wrote about namespaces. So please ignore my last mail. IMO versioned XSDs are all you need to signal additional functionality or incompatibilities. I agree. So +1 one for your proposal. Joerg
Re: Custom Xpath Selector
Hi Richard,
It's actually not possible by design. Matchers, selectors and actions
are evaluated in the pipeline setup phase to find the pipeline
components. Only when the setup is finished the pipeline is executed and
the SAX events sent through the pipeline. That's why you don't have
access to pipeline content in a selector. Transformer (with access to
SAX events) and flowscript (splitting the pipeline into 2) are the 2
already mentioned alternatives.
Joerg
On 23.07.2008 09:04, Richard McKenzie wrote:
Cheers Peter
Thanks for the advice, we are trying to avoid using flow script if
possible. I just thought I'd post the question in case anybody had
created a selector which did something similar, after decompiling all
the cocoon selectors I suspected that it was not possible to do
elegantly.
Many Thanks
-Original Message-
From: Peter Hunsberger [mailto:[EMAIL PROTECTED]
Sent: 22 July 2008 16:28
To: dev@cocoon.apache.org
Subject: Re: Custom Xpath Selector
On Tue, Jul 22, 2008 at 10:04 AM, Richard McKenzie
[EMAIL PROTECTED] wrote:
snip/
Perhaps I am barking up the wrong tree and a selector is not the best
solution, it would be nice to be able to do different things bassed on
the contents of the xml passed through a pipeline
If you have complicated use cases I suspect you're going to want to use
a Java transformer to inspect the XML in the pipeline and have it make
the decisions on what should be done. This can be done from flow script
by firing off the pipeline at that point and then inspecting some
returned result. I'm not sure about 2.1 but in 2.0 this looks like
var sourceURI = run/_checkXML/;
var destinationURI = xmodule:request-attr:checkXMLresult;
var resolver = null;
var destination = null;
var output = null;
try {
resolver = cocoon.getComponent(
Packages.org.apache.cocoon.environment.SourceResolver.ROLE );
destination = resolver.resolveURI( destinationURI );
output = destination.getOutputStream();
cocoon.processPipelineTo( sourceURI, {}, output );
output.close();
if ( cocoon.request.getAttribute( checkXMLresult ) == ...) {
//see what happened in the XML checking pipeline
// Do whatever should be done based on the results...
return true;
}
}
finally {
if (destination != null) {
resolver.release( destination );
}
cocoon.releaseComponent( resolver );
}
--
Peter Hunsberger
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
On 21.08.2008 23:53, Reinhard Pötz wrote: After having already discussed the details, let's make a formal decision about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3. +1 to everything except ... XML NAMESPACES --- Corona currently uses three different namespaces in XML documents: http://apache.org/cocoon/corona/sitemap http://apache.org/cocoon/corona/servlet http://apache.org/cocoon/corona/controller These namespaces are without a version number. Since I don't see how version numbers could help, I propose http://apache.org/cocoon/sitemap http://apache.org/cocoon/servlet http://apache.org/cocoon/controller I know I'm rather late ... Don't these version numbers just help in the same way as versioned jars help? It's possible to signal additional functionality or incompatibilities. Just look at the Spring framework. CI --- Apache Infrastructure offers a managed Hudson instance. I propose to setup a Cocoon 3 project there. I'd like to see continuous integration, be it Continuum, Hudson or Gump. Joerg
Re: [vote] Cocoon 3.0
Reinhard Pötz reinhard at apache.org writes: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. +1 Joerg
Re: [vote] Java 1.5 as minimal requirement for trunk
Grzegorz Kossakowski grek at tuffmail.com writes: switching to Java 1.5 as minimal required version +1 Joerg
Re: [vote] David Legg as new Cocoon committer
Grzegorz Kossakowski grek at tuffmail.com writes: I would like to propose David Legg as a new Cocoon committer and PMC Member. +1 Joerg
Re: Find a new name for Corona
Torsten Curdt tcurdt at apache.org writes: I think Corona is a great name. Everyone uses it. People already know it by now. Let's officially call it Apache Cocoon (Project) Corona. Everyone will call it Corona anyway. Will that really be a problem? (Sorry if I missed that thread/post) And once things are there we can think of a migration strategy and migrate it to Cocoon 3.0. But that is still a long way. I tend to agree with Torsten. Renaming it now and potentially again in a year sounds like a lot of confusion. Of course tagging it with the final name as early as possible would be good but it seems we can't agree on calling it Cocoon 3.0 right now. So I prefer to leave it as it is (or just change it to the official name Apache Cocoon Corona). Joerg
Re: RFC: Using icu4j for number formatting
Jeremy Quinn jeremy at apache.org writes: Currently, o.a.c.forms.datatype.convertor.FormattingDecimalConvertor (the baseclass for all Number Formatting convertors), uses java.text.DecimalFormat internally, without exposing the class to the outside (except for one protected Method). If I were to re-implement FormattingDecimalConvertor using icu4j, should I leave the old one alone and create a new icu4jFormattingDecimalConvertor, or work with the original class? Please see [1]. If this solves the problem, this would be the only decimal convertor that would work properly with Dojo, so it would seem pointless to leave the old one around, leading to confusion . But Dojo is not the only option. And considering the differences between icu4j and java.text people might want to have the option to switch. I don't know if Sylvain ever did what he wanted to do (last mail in mentioned thread). Joerg [1] http://marc.info/?t=11096654551r=1w=4
Re: FW: Accessing Cocoon context from class (2.1)
You need to retrieve a component from the ServiceManager, just instantiating doesn't work. Joerg On 21.07.2008 22:59, Gary Larsen wrote: I'm sorry for my impatient developer posting. Still not grasping Avalon and Excalibur stuff in 2.1, but it would seem like it's possible to create a class which could access the Cocoon context (org.apache.cocoon.environment.Context). I've tried Serviceable, Contextualizable and Component interfaces and registering the component in cocoon.xconf - but no luck yet. Could someone suggest some pointers or samples to help me out? Thanks, gary _ From: Gary Larsen [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2008 2:31 PM To: [EMAIL PROTECTED] Subject: Accessing Cocoon context from class (2.1) I'm running Cocoon 2.1.9. Could someone tell me how to access the Cocoon context from a class? I've built generators which have the ObjectModel passed to it, but in this case the class is isolated (it also implements HttpSessionBindingListener). Does this class need to implement an interface and/or be registered as a Cocoon component somehow? Thanks for any assistance. gary
Re: [proposal] Corona: A Cocoon subproject
On 20.07.2008 14:17, Reinhard Pötz wrote: First we should define the mission of this subproject. Corona has two main goals: 1. Become the best platform for RESTful services and RESTful web applications based on the concept of pipelines. 2. Provide a generic pipeline Java API with SAX and STaX based default implementations. We will need a one-sentence description anyway. Then the appropriate name should fall out. I lean towards Fibre or Silk. However because it might not be the pipeline API that Cocoon uses, then perhaps some other type of fibre. For example, Kapok - a fine fibrous cotton-like substance found surrounding the seeds of a tropical tree. (Australian Oxford English Dictionary). The term Java Kapok is used, but from my quick search not in the software industry. http://en.wikipedia.org/wiki/Ceiba_pentandra So my proposals are: Apache Cocoon Kapok Apache Cocoon Fibre I tend towards Apache (Cocoon) Silk because it is short and easily pronounceable (in contrast to Fibre) and doesn't sound like Klingon (Kapok). I don't know if we should add Cocoon to the name and have no strong opinion. Is it THAT different that you don't consider calling it Cocoon 3.0 at all? Joerg
Re: [Corona] PIpeline API
Torsten Curdt tcurdt at apache.org writes: The question if those configuration are needed in a generic form in the API. (I doubt it) As I would expect them to be implementation specific a configuration callback that sets up the pipeline might be a way around this? I guess we are on the same position on this one, setup and clean up are usually implementation specific and should therefore not be part of the API. Even for the finish() method it might be necessary to pass a context or parameters. Already passing it in setup() might be an option, but then you force the component to have special handling for thread-safety. Carsten Ziegeler cziegeler at apache.org writes: I added now a finish method which is called by the pipeline implementation. This keeps me free from any configuration hassels with the various containers. Some want to use spring, some others something different. But that's exactly what these container are there for. And perhaps someone doesn't want to use a container at all, just instantiate the objects, run the pipeline and that's it. By just instantiating the objects you know exactly with which implementation you work - and which setup and finish method you are supposed to call. Therefore I really think that these lifecycle methods belong to the api. That's what I don't agree with :-) I see no other reliable way of closing resources. A listener/callback approach would be cleaner for the API, but more complex. Question is if it needs to be part of the API at all. Joerg
Re: [Corona] PIpeline API
Carsten Ziegeler cziegeler at apache.org writes: c) Pre and post processing As the pipeline interfaces are not tied to sax or any other model (which is ok), there is no explicit notion of indicating that the processing starts or is finished - the latter is especially interesting for cleanup. So I think we should add these two lifecycle methods to the pipeline component interface. I don't see any problem either. Being curious, what are your use cases? I've some pipeline components that open/close resources, like a JCR session for instance. If the contract includes that the pre and post processing methods are always called, the post processing method acts like kind of a disposal method where I can close my session. I've other - in this sense rather obscure - use cases where the pipeline components need to pass information back to the caller before the processing starts. So the caller calls the pre processing method where the pipeline component adds something to the map, the caller can pick it up and then start the processing based in this information. Isn't that a rather specific use case? It feels kinda wrong when lifecycle methods will now pollute the pipeline interfaces rather than letting pipeline components implement lifecycle interfaces. Doesn't Spring show how to do these kind of things with templates or aspects? And is there actually something like start and end in a pipeline? How do you determine that? It's rather easy with SAX since there is startDocument() and endDocument() but in general? It's not an objection, just some thoughts ... Joerg
Re: pipeline vs match
On 14.06.2008 09:06, Kamal wrote: Something I have noticed about the Cocoon documentation is that the terms pipeline seems to be used to describe a map:match. For example: Sets the generator for the pipeline.[1] We know what is meant, but this could be very confusing for a newbie. Should we be using the term match here, perhaps with a link the description of map:match? I know historically, it is a pipeline. Cheers. PS. I have been adding the clearer descriptions to the various sitemap component found in the Cocoon 2.1 documentation. Are there any objections? Yes, because it's wrong. It is a pipeline, not a match. A match is just similar to an if and has nothing to do with a pipeline as you can see in the following example: map:pipeline map:match map:generate/ map:transform/ map:match !-- executes 2nd transform only in certain cases -- map:transform/ /map:match map:serialize/ /map:match /map:pipeline or map:pipeline internal-only=true map:match map:generate/ map:transform/ /map:match map:match map:generate/ /map:match !-- ALL internal pipeline use XML serializer -- map:serialize type=xml/ /map:pipeline The confusion result from 2 facts: In most cases one complete pipeline is wrapped within one map:match statement. There is no obvious wrapping for the actual pipeline, map:pipeline seems to wrap multiple pipelines rather than one. But that's not quite true if you read it differently: A pipeline starts with the first generator that the treeprocessor comes along the path and ends with the first serializer. A map:match (just like an if) excludes a map:generate from certain paths to be found. Other examples: map:pipeline map:generate/ map:transform/ map:serialize/ map:match !-- will never be reached -- /map:match /map:pipeline The first combination of map:generate to map:serialize make the pipeline, map:match will never be reached. map:pipeline !-- different generator for different paths -- map:match pattern=path1 map:generate/ /map:match map:match pattern=path2 map:generate/ /map:match !-- same transformation -- map:transform/ map:match pattern=path1 map:serialize/ /map:match !-- path1 won't reach this, only path2 -- map:serialize/ /map:pipeline So technically map:pipeline IS the wrapper for a complete pipeline, because always only one pipeline will be constructed within it. It's just not that obvious. Disclaimer: The above examples should all work in Cocoon, but that does not mean I recommend to use them. The standard case of wrapping a pipeline within a map:match probably makes a sitemap more readable and useful than these examples to outline the concepts. Joerg
Re: svn commit: r666946 - in /cocoon/branches/BRANCH_2_1_X/tools/targets: compile-build.xml init-build.xml
That's why I just wrapped the stuff in comments rather than taking it out completely :) Joerg On 12.06.2008 02:51, Ralph Goers wrote: Until we need to take advantage of some Java 1.5 feature ;-) [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=666946view=rev Log: With minimum Java raised to 1.4.2 it is no longer necessary to have JDK-specific source directories.
Re: [2.1.x] Build failed after jdk1.* directories were removed
On 11.06.2008 09:17, Andreas Hartmann wrote:
Removed:
cocoon/branches/BRANCH_2_1_X/src/jdk1.3/
cocoon/branches/BRANCH_2_1_X/src/jdk1.4/
now the build fails for me due to the missing directories
(compile-build.xml):
!-- compiles the core --
target name=compile-core depends=compile-mocks, clover.on
cocoon.compile srcdir=${java}
destdir=${build.dest}/
echoCompiling jdk ${used.vm} core classes/echo
cocoon.compile srcdir=${jdk.java}
destdir=${build.dest}/
/target
Does it work for you?
Hmm, on the one hand it does not really surprise me that it fails on
missing directories, on the other hand that's exactly why I tried a
build clean on my machine (Mac OS X though) before committing it. I
will just take this compile statement out, but can not really test it
obviously. Please report back if there are still problems.
Sorry for the inconveniences.
Joerg
Re: svn commit: r665954 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/environment/ src/java/org/apache/cocoon/environment/wrapper/ src/java/org/apache/cocoon/util/ src/test/org/apa
On 09.06.2008 22:40, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Mon Jun 9 19:40:16 2008
New Revision: 665954
URL: http://svn.apache.org/viewvc?rev=665954view=rev
Log:
as a follow-up of COCOON-2168 (http://marc.info/?t=12089986853r=1w=4):
Cocoon's pipeline buffer increases from an initial buffer size of 8192 bytes to
the configurable flush buffer size rather than allocating the complete buffer
beforehand.
I'm still working on making initial buffer size configurable in sitemap.
+public OutputStream getOutputStream(int bufferSize) throws IOException {
// This method could be called several times during request processing
// with differing values of bufferSize and should handle this situation
// correctly.
+// FIXME (JH): Question is what correctly means. The current behavior
+// seems to be inconsistent: On a second call with bufferSize == 0 we
+// discard whatever the first called set up. With a bufferSize != 0 the
+// first call's setup is preserved. Why not always creating new
+// BufferedOutputStream in the else block replacing a potentially
+// existing one?
Any idea/comment on this? If the current behavior is correct or expected
it should probably commented appropriately.
Joerg
XSP block (was: Type 'serverpages' does not exist for 'map:generate')
Moving this discussion from users list (for reference [1]) to dev list. On 06.06.2008 19:02, Alfred Nathaniel wrote: Warning: I'm stating my own opinion here, nothing official or something like that. There are at least three problems with XSP: 1. No active committer is interested in XSP anymore, and even more, hardly anyone wants to invest her time in technology that seems to be deprecated in every dev's head but still block is not officially marked as deprecated. I may be not as active as you but I am a committer who is still very interested in XSP. In may daytime job we have 1000+ XSPs in production and no intention to drop that technology in the forseeable future. XSP has its shortcomings and pitfalls but after 7 years experience we know how to handle that. 2. The only reason why people keep trying to use XSP is that it has decent documentation on our site and this documentation has no information about XSP status. We should really explain people that Templates + Flowscript is much better approach. I think the reason why XSP appeals to newcomer is that the concept is familiar from JSP, and it is a combination of the three core technologies which Cocoon handles extremely well: XSP = XML + XSLT + Java. Personally, I still do not consider Flowscript an alternative for enterprise websites for three reasons: a.) Serverside JavaScript is an additional level in the technology stack you and your team have to master. b.) I would not bet my head on Rhino being threadsafe, and it is such a big beast to debug it yourself. c.) Continuations are a great idea, but how do you know when it is safe to free the memory? 3. XSP is really old technique and is not maintained by anyone (again officially, at dev/commits list). I'm not the one willing to take costs of XSP maintenance in C2.2 therefore I'll probably vote -1 for any actions leading to release of XSP block for C2.2. This is my first such a strong voice in this case but I firmly believe it's a high time have a concrete opinion. XSP is a really mature technology which hardly needs any maintenance any more. The reason why the XSP block (as many other blocks) is not released yet is actually more of a C2.2 issue than an XSP problem. Still, I'm open for discussion of course. I'd prefer to have this sort of discussion on the dev-list. I completely agree with Alfred. I don't see any reason for not releasing XSP block. Yes, somebody has to do the actual work. But why blocking it when somebody puts in the effort? You can estimate the maintenance costs by looking at the changes in the last years in the 2.1 branch. Joerg [1] http://marc.info/?t=12124988641r=1w=4
Re: BufferedOutputStream
On 07.06.2008 03:13, Andy Stevens wrote: Out of interest, have you raised an enhancement request and/or a patch with the OpenJDK project[1]? It seems to me this increasing buffer behaviour would be useful more generally... Done. Joerg
Re: multithreaded Content Aggregator migration from 2.1 to 2.2
On 06.06.2008 12:51, Grzegorz Kossakowski wrote: E.g. if two threads share the same (inherited) instance of ObjectModel all nasty side-effects of multi-threading should be expected like parallel modification and loosing of data consistency kept in OM. How Cocoon used to solve these kind of problems in the past? I don't see that much of a problem here - and it always used to be that way. If it is a distinctive object model or just the request object does not really make a difference to me. Also in other frameworks where you only work with request or session objects you have to be aware of multi-threading. Is the multi-threading processing a feature one has to switch on intentionally? Joerg
Re: multithreaded Content Aggregator migration from 2.1 to 2.2
InheritableThreadLocal [1] might be one solution. But being not able to
clean up a thread is always a problem in web environment. IIRC Spring
used to use InheritableThreadLocal in RequestContextListener, but they
changed it to standard ThreadLocal for that reason.
I don't know if CocoonRunnable mentioned by Grek is another point for
potential changes.
Joerg
[1]
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/InheritableThreadLocal.html
On 05.06.2008 09:21, Imran Pariyani wrote:
Hello,
we have come across this issue .. i posted it on user mailing list and
some one from there suggested me to post it here since it seems to be
bug in cocoon 2.2 .. its a very crucial issue for us.. we cant upgrade
to 2.2 unless we some how solve or find a work around for this issue ..
we have multithreaded Content Aggregator which is based on the
CIncludeTransformer and it also implements CacheableProcessingComponent
for caching .. it used to work fine for cocoon 2.1.x but with cocoon 2.2
it gives strange error .. it is actually a generator and it gives error
in the generate method ..
the code where it gives error
// generate...
for (Part part : this.parts) {
if (this.manager.hasService(IncludeCacheManager.ROLE)) {
part.uri = this.cacheManager.load(part.uri,
this.cachingSession);
} else {
this.getLogger().error(
The ContentAggregator: aggregator cannot find
the IncludeCacheManager);
}
}
// aggregate...
StreamPipe streamPipe = new StreamPipe(this.contentHandler);
for (Part part : this.parts) {
streamPipe.firstElement(part.element, this.rootElement,
part.stripRootElement);
try {
System.out.println(ParallelContentAgg.part.uri: +
part.uri);
this.cacheManager.stream(part.uri,
this.cachingSession, streamPipe);
} finally {
streamPipe.lastElement(part.element);
}
}
it gives the following error
Caused by: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name
'scopedTarget.org.apache.cocoon.el.objectmodel.ObjectModel': Scope
'request' is not active for the current thread; consider defining a
scoped proxy for this bean if you intend to refer to it from a
singleton; nested exception is java.lang.IllegalStateException: No
thread-bound request found: Are you referring to request attributes
outside of an actual web request? If you are actually operating within a
web request and still receive this message,your code is probably running
outside of DispatcherServlet/DispatcherPortlet: In this case, use
RequestContextListener or RequestContextFilter to expose the current
request.
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:293)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
at
org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:184)
at $Proxy2.cleanupLocalContext(Unknown Source)
at
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:382)
at
org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.java:111)
at
org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.java:170)
at
org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:63)
at
org.apache.cocoon.transformation.helpers.DefaultIncludeCacheManager$LoaderThread.run(DefaultIncludeCacheManager.java:415)
at
org.apache.cocoon.environment.CocoonRunnable.doRun(CocoonRunnable.java:64)
at
org.apache.cocoon.environment.internal.EnvironmentHelper$AbstractCocoonRunnable.run(EnvironmentHelper.java:453)
at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
... 1 more
Grzegorz Kossakowski wrote:
Imran Pariyani pisze:
Hi
Hi Imran,
last night i wasted 5 hrs overs this without any success .. i guess
it has something to do with passing the RequestContextListener to the
spring context .. i have initialized the listener in my web.xml and
also added the config in applicationcontext.xml .. i checked
everything on my end .. everything seems to be fine .. is something
wrong with the cachemanager present in cocoon ?
any help will be greatly appreciated !! ..
Unfortunately, it looks like you stumbled across rather complicated
(and obscure) bug. It's related to the fact how Spring's request scope
works (objects are tied to the thread). If you run multithreaded
aggregation then child threads don't have an access to beans defined
with 'request' scope because they are visible only in parent thread.
More
Re: BufferedOutputStream
Reinhard Pötz reinhard at apache.org writes: Is my understanding right that the content length header can only be set as long as you haven't written into the underlying output stream? Yes, it is. That's why the buffering has to be big enough, i.e. nothing must have been flushed yet. What happens when the buffer size is exceeded? Does it mean that the output is streamed and the content length parameter can't be set? If the buffer size is exceeded the output stream is flushed and eventually written to the response. A header like the content-length can no longer be set. That's why Cocoon's BufferedOutputStream was setup to buffer all and everything by default which lead to COCOON-2168 [1] with Cocoon's default setting. With the change to a buffer of 1 MB rather than endless buffering we switched back to java.io.BufferedOutputStream, but this allocates the memory for the buffer immediately. So even with 10 KB pages you always end up with 1 MB byte[]. I intend to fix this in our BufferedOutputStream with an increasing buffer and the two configuration parameters initial buffer size and flush buffer size. Just to make it clear: We talk about default configuration of Cocoon here. You still can enforce complete buffering by setting flush buffer size to -1 again. But it's up to the user to enforce this and potentially run into OOME. It's also up to the users to find a reasonable flush buffer size as it always used to be when they haven't used the endless buffering. Only thing that is going to change is in case of not endless buffering: The full buffer is not allocated immediately but step by step. Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168
Re: BufferedOutputStream
On 02.06.2008 05:56, Sylvain Wallez wrote: Only issue I want to solve before the release is the BufferedOutputStream issue. I planned to do it this weekend. Done. Please review the file attached. It's still completely untested. At the moment I need some sleep ;) I will write junit tests for it this week and eventually commit it. Stupid question: why do we need a special BufferedOutputStream? For being able to reset the response buffer for error handling. This is also possible with java.io.BufferedOutputStream, if the buffer size is big enough (current default value is 1MB), but then the buffer byte[] is always that big rather than increasing. That's what's happening right now, if you don't specify -1 as buffer size. -1 means complete buffering which on the other hand might lead to OutOfMemoryError [1]. In addition our BOS counts the bytes so that we can use the value to set the content length header. Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168
Re: BufferedOutputStream
Reinhard Pötz reinhard at apache.org writes: Is my understanding right that the content length header can only be set as long as you haven't written into the underlying output stream? Yes, it is. That's why the buffering has to be big enough, i.e. nothing must have been flushed yet. Joerg
BufferedOutputStream (was: Releasing 2.1.12 - a new release manager?)
On 29.05.2008 00:06, Joerg Heinicke wrote:
Only issue I want to solve before the release is the
BufferedOutputStream issue. I planned to do it this weekend.
Done. Please review the file attached. It's still completely untested.
At the moment I need some sleep ;) I will write junit tests for it this
week and eventually commit it.
Joerg
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the License); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.cocoon.util;
import java.io.FilterOutputStream;
import java.io.IOException;
import java.io.OutputStream;
/**
* This class is similar to the [EMAIL PROTECTED]
java.io.BufferedOutputStream}. In
* addition it provides an increasing buffer, the possibility to reset the
* buffer and it counts the number of bytes written to the output stream.
*
* @author a href=mailto:[EMAIL PROTECTED]Carsten Ziegeler/a
* @version CVS $Id: BufferedOutputStream.java 433543 2006-08-22 06:22:54Z
crossley $
* @since 2.1
*/
public class BufferedOutputStream extends FilterOutputStream {
private byte buffer[];
private int count;
private int totalCount;
private final int flushBufferSize;
/**
* Creates a new buffered output stream to write data to the
* specified underlying output stream with a default 8192-byte
* buffer size.
*
* @param out the underlying output stream.
*/
public BufferedOutputStream(final OutputStream out) {
this(out, 8192, 32768);
}
/**
* Creates a new buffered output stream to write data to the specified
* underlying output stream with the specified buffer sizes.
*
* @param outthe underlying output stream.
* @param initialBufferSize the initial buffer size. Must be greater than
0.
* Will be limited to the flush buffer size.
* @param flushBufferSize the buffer size when the stream is flushed. Must
* be greater than 0 or -1 meaning the stream never
* flushes itself.
*/
public BufferedOutputStream(final OutputStream out,
final int initialBufferSize,
final int flushBufferSize) {
super(out);
if (initialBufferSize = 0) {
throw new IllegalArgumentException(Initial buffer size = 0);
}
if (flushBufferSize = 0 flushBufferSize != -1) {
throw new IllegalArgumentException(Flush buffer size = 0 !=
-1);
}
this.buffer =
new byte[initialBufferSize flushBufferSize ? flushBufferSize :
initialBufferSize];
this.flushBufferSize = flushBufferSize;
}
/**
* Writes the specified byte to this buffered output stream.
*
* @param b the byte to be written.
* @exception IOException if an I/O error occurs.
*/
public void write(int b) throws IOException {
if (this.count == this.buffer.length) {
// No need to check return value, can NEVER be 0.
this.increaseBuffer(1);
}
this.buffer[this.count++] = (byte)b;
this.totalCount++;
if (this.count == this.flushBufferSize) {
flush();
}
}
/**
* Writes codelen/code bytes from the specified byte array
* starting at offset codeoff/code to this buffered output stream.
*
* p Ordinarily this method stores bytes from the given array into this
* stream's buffer, flushing the buffer to the underlying output stream as
* needed. If the requested length is at least as large as this stream's
* buffer, however, then this method will flush the buffer and write the
* bytes directly to the underlying output stream. Thus redundant
* codeBufferedOutputStream/codes will not copy data unnecessarily.
*
* @param b the data.
* @param off the start offset in the data.
* @param len the number of bytes to write.
* @exception IOException if an I/O error occurs.
*/
public void write(final byte[] b, final int off, final int len) throws
IOException {
if (len this.buffer.length - this.count) {
int actualIncrease = this.increaseBuffer(len
Re: Releasing 2.1.12 - a new release manager?
On 28.05.2008 02:05, Carsten Ziegeler wrote: I think it's really time now to get 2.1.12 out of the door. As I'm not involved in Cocoon anymore I would like to step down as the release manager; imho it makes more sense if someone still working on/with Cocoon does this job :) It's really easy, everything is outlined in our docs and I can help during the process if required. So any volunteers? If it is only 2.1 (at least for the time being) I can do this job (though I'm neither working with Cocoon anymore lately). Just have to check this documentation (any links?) what it needs to do such a release (signed PGP key or things like that). Only issue I want to solve before the release is the BufferedOutputStream issue. I planned to do it this weekend. Joerg
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
On 09.05.2008 09:41, Peter Hunsberger wrote: I think this is rather hard to do. The place where we instantiate the BufferedOutputStreams (both java.io and o.a.c.util) is AbstractEnvironment.getOutputStream(int bufferSize). So in order to pass a second buffer size argument to the BufferedOutputStream constructor we need to have it available there. One option would be to add it to getOutputStream() - which is an interface change and not really nice. I haven't looked at the code here, but couldn't you just introduce a second getOutputStream( int bufferSize ) method where the current interface method continues with the current default logic if it is used? getOutputStream() actually already takes an int parameter, the flush buffer size. Whether to add another getOutputStream() method or modify the existing one there is not really a difference IMO. Environment is a kind of internal interface (or SPI how it used to be called lately, isn't it?). This means there should be only very few implementations besides the one we provide if at all (Forrest, Lenya, CLI environment?). And in Cocoon we would change all usages of the single-parameterized method to the one with 2 parameters. So whoever provides such an Environment implementation has to adapt his implementation in a meaningful way anyway (empty implementation returning null, throwing NotSupportedException, whatever would not work). So it's the same effort for them whether to add a new method or changing existing one on the interface. IMO the decision should be made purely from a design perspective. Should a configuration parameter passed around as method parameter though it is static through the whole lifecycle of the Environment instance? In a perfect world I'd say no :) Which leaves the question how to inject the parameter. One place is on instantiation (e.g. CocoonServlet.getEnvironment(..) in 2.1, RequestProcessor.getEnvironment(..) in 2.2) which leaves us with the web.xml init parameter (or analogical alternatives for other environments) as described. Another option I found is to setup the environment (i.e. injecting the parameter) while setting up the pipeline. AbstractProcessingPipeline is the place where we have access to the current flush buffer size parameter and call getOutputStream(..) on the environment. It has a method setupPipeline(Environment). Why not injecting the parameter(s) here? Due to its lifecycle changing the property of the environment should not cause any problem since it's a one-time usage object, no threading problems or something like that. I'm just curious what the original reason was to pass the parameter along rather than injecting it? Maybe there is a flaw in my thoughts :) Whoever knows the code, are my statements correct and what do you think about the approach injecting the parameters rather than passing them along? Second, if it is a valid approach which way to go? 1) Don't provide a separate configuration option for initial buffer size. 2) Pass both parameters to getOutputStream(..). 3) Leave the current flush buffer size as parameter to getOutputStream(..) but inject the other one a) from web.xml. b) from pipeline configuration. 4) Inject both buffer sizes, eventually reactivating/reintroducing getOutputStream() without any parameter and deprecating the other one. Many questions, yet another one: What do you think? :) Joerg
Re: [OT] Mac OS X and Java development
On 08.05.2008 05:39, Lally Singh wrote:
What missing Java sources? They are in
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/src.jar
Hmm, not for me. Directory exists, but no src.jar inside. So where to get
it from?
Came preinstalled on my mac. Did you install the dev tools?
No dev tools. Are they only available for Leopard? I'm still on Tiger -
and would rather switch to Linux than spending money for Leopard ;)
There's no way in hell I'm traversing a tree with a
keyboard. I have a mouse, a good one, and it does everything I want
faster than any keyboard.
That's probably personal taste. I can do lots of stuff faster with just
the keyboard.
Keyboard navigation in Mac OS X is completely inconsistent, especially
with Java programs.
Uh? What is consistency besides the usual cut/copy/paste?
What about Ctrl/Alt/Shift + Left/Right/Up/Down/Page Up/Page Down/Home/End?
I use these key combinations very heavily in Windows - and try to use
similar cominations in Mac OS X, but pretty much every program has its own
combinations. Notebook keyboard with fn seems to complicate it even more.
Especially annoying in Eclipse fn+Left (which should be Home) jumps to first
position in file.
Actually the consistency is what I love the most:
Emacs keybindings (Ctrl-{A,E,P,N,K,Y, etc}) work *everywhere*, even
the single-line textfields like the search box in web browsers.
But not in Eclipse ;) Anyways, I don't want to get started with letters
for cursor navigation.
Command-left,right,up,down move to the beginning end of the line
or document. Same global consistency.
Not in jEdit. Also fn+left jumps to beginning of document - with cursor
in Eclipse, without moving cursor (just scrolling) in SeaMonkey.
Option left-right move between words. Option up/down goes up/down a
page. Again, consistent.
Not at all in jEdit. Option+up/down moves lines in Eclipse.
Sorry it's not identical to windows, which was copied by linux, but it
*is* better.
Can't agree.
Huh, I didn't realize people still run such older versions of MacOS.
Tiger? Leopard is only out since 1/2 year, so what ... And I'm not
willing to pay for it.
Java 6 is the first time apple's drug their feet for any real amt of
time like this. Java 5 was a few weeks after the general release, but
nothing like this.
Why a completely separated version after all? I can see the point of a
native lookfeel, but beyond that ...
Joerg
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
On 08.05.2008 11:53, Bruce Atherton wrote: My only comment is that I think it would be good to allow the initial buffer size to be configurable. If you know the bulk of your responses are greater than 32K, then performing the ramp-up from 8K every time would be a waste of resources. For another web site, if most responses were smaller than 6K then an 8K buffer would be perfect. Allowing someone to tweak that based on their situation seems useful to me. Not critical though, if it is hard to do. Allowing the buffer to scale is the important thing. I think this is rather hard to do. The place where we instantiate the BufferedOutputStreams (both java.io and o.a.c.util) is AbstractEnvironment.getOutputStream(int bufferSize). So in order to pass a second buffer size argument to the BufferedOutputStream constructor we need to have it available there. One option would be to add it to getOutputStream() - which is an interface change and not really nice. The second option would be to pass it to the Environment instance. Since environments can be wrapped it needs again an interface change (but just adding a method, which is much better). And you have to look where environments are instantiated, e.g. HttpServletEnvironment in CocoonServlet. From what I see from a quick look only potential way to provide a configuration would be as servlet init parameter. That makes it two different places to configure these two different buffer sizes - not very intuitive. Joerg
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
On 08.05.2008 12:16, Antonio Gallardo wrote: One question, what are supposed to be the default values for both parameters? For the initial buffer size I thought of 8K, maybe 16K. It should be a reasonable size that's not overly large (i.e. unnecessarily reserved memory) for most of the resources. For the flush buffer size we already talked about 1MB as default value [1]. This size should be nearly never hit. Joerg [1] http://marc.info/?t=12047341133r=1w=4
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
On 27.04.2008 23:43, Joerg Heinicke wrote: 2. Does the full amount of the buffer automatically get allocated for each request, or does it grow gradually based on the xml stream size? I have a lot of steps in the pipeline, so I am worried about the impact of creating too many buffers even if they are relatively small. A 1 Meg buffer might be too much if it is created for every element of every pipeline for every request. That's a very good question - with a negative answer: A buffer of that particular size is created initially. That's why I want to bring this issue up on dev again: With my changes for COCOON-2168 [1] it's now not only a problem for applications with over-sized downloads but potentially for everyone relying on Cocoon's default configuration. One idea would be to change our BufferedOutputStream implementation to take 2 parameters: one for the initial buffer size and one for the flush size. The flush treshold would be the configurable outputBufferSize, the initial buffer size does not need to be configurable I think. What do other think? No interest or no objections? :) Joerg
Re: svn commit: r629374 - /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
On 30.03.2008 02:50, Joerg Heinicke wrote: Author: antonio Date: Tue Feb 19 22:42:45 2008 New Revision: 629374 URL: http://svn.apache.org/viewvc?rev=629374view=rev Log: Faster implementation. Saw this one only now ... I'm a bit concerned about the approach. First, do you really think this implementation is significantly faster? Your implementation only caches the parser instance, you replace the instantiation with ThreadLocal handling. Parsing itself should still be the slowest part. How many Strings do you convert to SAX per thread? Second, who cleans up the thread before it goes back to the thread pool? At the end is it really worth the ugly implementation? IMO it's a much better approach to make it a real Cocoon component (Serializeable) instead and look up the SAXParser. Any opinions on this one? Joerg [1] http://marc.info/?l=xml-cocoon-cvsm=120348979305179w=4
Re: [OT] Mac OS X and Java development
On 04.04.2008 11:33, Sylvain Wallez wrote: With Mac OS X I also have no access to the source code of the JDK. Which makes me wonder again how to do serious Java development with Mac OS X. I know a few of you guys are using Mac OS X. How do you do it? Er... without any problem, and I nothing would make me swith back to Windoze :-) Whenever I start this I get annoyed very fast. The missing Java sources are only the tip of the iceberg. What missing Java sources? They are in /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/src.jar Hmm, not for me. Directory exists, but no src.jar inside. So where to get it from? Every tree representation in Eclipse just sucks. What sucks? The missing vertical lines? It means a bit more indentation, but less visual clutter. And my Mighty Mouse's scroll ball does magic to navigate in all directions :-) I have a Logitech MX Revolution, so sidewards scrolling isn't a problem. But try keyboard navigation. You are on the 100th child and hit left key. I now expect to jump to the parent and on the next hit on left to close the parent. Keyboard navigation in Mac OS X is completely inconsistent, especially with Java programs. Uh? What is consistency besides the usual cut/copy/paste? What about Ctrl/Alt/Shift + Left/Right/Up/Down/Page Up/Page Down/Home/End? I use these key combinations very heavily in Windows - and try to use similar cominations in Mac OS X, but pretty much every program has its own combinations. Notebook keyboard with fn seems to complicate it even more. Especially annoying in Eclipse fn+Left (which should be Home) jumps to first position in file. There seems to be no serious SVN command line client (or at least the CollabNet download page is just self-linking at the moment: http://downloads.open.collab.net/binaries.html). Install macports and just run sudo port install subversion Found http://www.wikihow.com/Install-Subversion-on-Mac-OS-X and from there http://www.codingmonkeys.de/mbo/. So at least one problem solved. And so on ... Windows has also bunch of annoying issues but there is at least consistency and usually there is a solution for everything. Do you guys all switch to Linux when it comes to Java development? :) Nh. I'm very happy with my Mac :-) If I could just say the same ;) Joerg
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
On 24.04.2008 16:08, Bruce Atherton wrote: Thanks for the response. About setting the buffer size, this looks like it could be what I am looking for. A few questions: 1. Do I have to set the buffer size on each transformer and the serializer as well as the generator? What about setting it on the pipeline? It is on the pipeline and only there. You can set it on the map:pipe element in the map:components section, so that it is applied to each pipeline of that type. Or on any individual map:pipeline element in the map:pipelines section. 2. Does the full amount of the buffer automatically get allocated for each request, or does it grow gradually based on the xml stream size? I have a lot of steps in the pipeline, so I am worried about the impact of creating too many buffers even if they are relatively small. A 1 Meg buffer might be too much if it is created for every element of every pipeline for every request. That's a very good question - with a negative answer: A buffer of that particular size is created initially. That's why I want to bring this issue up on dev again: With my changes for COCOON-2168 [1] it's now not only a problem for applications with over-sized downloads but potentially for everyone relying on Cocoon's default configuration. One idea would be to change our BufferedOutputStream implementation to take 2 parameters: one for the initial buffer size and one for the flush size. The flush treshold would be the configurable outputBufferSize, the initial buffer size does not need to be configurable I think. What do other think? On an unrelated note, is there some way to configure caching so that nothing is cached that is larger than a certain size? I'm worried that this might be a caching issue rather than a buffer issue. Not that I'm aware of. Why do you think it's caching? Caching is at least configurable in terms of number of cache entries and I also think in terms of max cache size. But beyond a certain cache size the cache entries are written to disk anyway so it's unlikely resulting in a memory issue. How do you read the object graph from the heap dump? To tell you the truth, I'm not sure. This is the hierarchy generated by the Heap Analyzer tool from IBM, and is from a heap dump on an AIX box running the IBM JRE. My guess as to the Object referencing the ComponentsSelector is that the ArrayList is not generified, so the analyzer doesn't know the actual type of the Object being referenced. What the object actually is would depend on what CachingProcessorPipeline put into the ArrayList. That is just a guess, though. And I have no explanation for the link between FOM_Cocoon$CallContext and ConcreteCallProcessor. Perhaps things were different in the 2.1.9 release? No serious changes since 2.1.9 which is rev 392241 [2]. Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168 [2] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java?view=log
Re: [continuum] BUILD FAILURE: Apache Cocoon [build root]
On 20.04.2008 02:56, Continuum VMBuild Server wrote:
[INFO] Building Cocoon: JNet
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/home/continuum/data/working-directory/51/subprojects/cocoon-jnet/target
[INFO] Deleting directory
/home/continuum/data/working-directory/51/subprojects/cocoon-jnet/target/classes
[INFO] Deleting directory
/home/continuum/data/working-directory/51/subprojects/cocoon-jnet/target/test-classes
[INFO] Deleting directory
/home/continuum/data/working-directory/51/subprojects/cocoon-jnet/target/site
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 10 source files to
/home/continuum/data/working-directory/51/subprojects/cocoon-jnet/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/continuum/data/working-directory/51/subprojects/cocoon-jnet/src/main/java/org/apache/excalibur/sourceresolve/jnet/source/SourceURLStreamHandler.java:[20,16]
cannot resolve symbol
symbol : class Proxy location: package net
/home/continuum/data/working-directory/51/subprojects/cocoon-jnet/src/main/java/org/apache/excalibur/sourceresolve/jnet/source/SourceURLStreamHandler.java:[42,52]
cannot resolve symbol
symbol : class Proxy location: class
org.apache.excalibur.sourceresolve.jnet.source.SourceURLStreamHandler
Reinhard, can you please also take care of this error? We have that one
since a few days.
Thanks,
Joerg
Re: svn commit: r649333 - in /cocoon/branches/BRANCH_2_1_X/src/blocks/javaflow/test/org/apache/cocoon/components/flow/java/test: FlowTest.java InheritanceFlowTest.java
On 17.04.2008 19:57, [EMAIL PROTECTED] wrote: Author: anathaniel Date: Thu Apr 17 16:57:56 2008 New Revision: 649333 URL: http://svn.apache.org/viewvc?rev=649333view=rev Log: Fix compile errors Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/javaflow/test/org/apache/cocoon/components/flow/java/test/FlowTest.java cocoon/branches/BRANCH_2_1_X/src/blocks/javaflow/test/org/apache/cocoon/components/flow/java/test/InheritanceFlowTest.java Sorry for the oversight and thanks for the fix. Joerg
Re: svn commit: r648942 - in /cocoon/trunk/core/cocoon-core/src: changes/changes.xml main/java/org/apache/cocoon/servlet/multipart/MultipartParser.java
On 18.04.2008 11:36, Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Author: joerg Date: Wed Apr 16 20:32:57 2008 New Revision: 648942 URL: http://svn.apache.org/viewvc?rev=648942view=rev Log: fix inconsistencies between inline parts and file parts when multiple fields of the same name exist (http://marc.info/?l=xml-cocoon-devm=120835513330316w=4) Modified: cocoon/trunk/core/cocoon-core/src/changes/changes.xml cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/servlet/multipart/MultipartParser.java Modified: cocoon/trunk/core/cocoon-core/src/changes/changes.xml URL: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-core/src/changes/changes.xml?rev=648942r1=648941r2=648942view=diff == --- cocoon/trunk/core/cocoon-core/src/changes/changes.xml (original) +++ cocoon/trunk/core/cocoon-core/src/changes/changes.xml Wed Apr 16 20:32:57 2008 @@ -29,6 +29,11 @@ body release version=2.2.0 date=TBA description=released + action dev=joerg type=add +Allow multiple file uploads of the same field name. If there are multiple file uploads Request.get(String) will +return a Vector. If there is only one file upload it will return the Part as it did before. This is now the same +behavior as for inline parts. + /action Joerg, as you can see 2.2.0 of core has been already released so you need to create new release tag and move your log there. :-) Oh, of course :) Fixed now. Joerg
Re: svn commit: r648313 - in /cocoon: subprojects/ trunk/subprojects/
On 15.04.2008 12:23, [EMAIL PROTECTED] wrote: Author: reinhard Date: Tue Apr 15 09:23:00 2008 New Revision: 648313 URL: http://svn.apache.org/viewvc?rev=648313view=rev Log: mv subprojects into trunk Added: cocoon/trunk/subprojects/ - copied from r648312, cocoon/subprojects/ Removed: cocoon/subprojects/ Is there a reason for that? When I want to check out Cocoon trunk I don't want to have all the subprojects of it, do I? Joerg
Re: svn commit: r648145 - /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/sitemap/SitemapServlet.java
On 15.04.2008 03:40, [EMAIL PROTECTED] wrote: Author: reinhard Date: Tue Apr 15 00:40:21 2008 New Revision: 648145 URL: http://svn.apache.org/viewvc?rev=648145view=rev Log: lazy initialization (... have to figure out why an advice around the init() method on servlets doesn't work as expected) I don't know exactly how it is set up, but I guess init() is configured as a init-method as in Initialization callbacks [1]. This would explain why there is no advice: First the object is instantiated, then initialized and afterwards wrapped by whatever. See Juergen's explanation [2]. With AspectJ the behavior might be different because there is no longer a target object and a proxy. Joerg [1] http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-factory-lifecycle-initializingbean [2] http://jira.springframework.org/browse/SPR-2740
Re: Location of subprojects in SVN
On 16.04.2008 08:35, Reinhard Poetz wrote: URL: http://svn.apache.org/viewvc?rev=648313view=rev Log: mv subprojects into trunk Is there a reason for that? When I want to check out Cocoon trunk I don't want to have all the subprojects of it, do I? My first idea was to move our subprojects (SSF, Spring configurator, JNet, Block Deployment) to cocoon/subprojects but this would have mae it more difficult to run a complete build of trunk because you would have to make sure that you build the subprojects first. Of course this could be solved by having releases of all subprojects and use them instead of the SNAPSHOTs, but we haven't reached that point yet for JNet and Block Deployer. Considering this I propose that we leave the subprojects _for now_ in cocoon/trunk/subprojects and move them out as soon as all 4 subprojects have been released. WDYT? As a temporary solution that's fine. Joerg
Re: Multipart Parser bug with multiple FileParts named the same name
On 16.04.2008 10:11, Jerry DuVal wrote: Is this a bug? Feature :) More an inconsistency than an actual bug. I for myself would not rely on the correct order of both All.primaryKey and All.foo. When a MultipartHttpServletRequest parses the values using MultipartParser it puts the Inline Parts into a Vector, but when parsing FileParts it just puts them into the parts hashtable. The problem with this is when a Request has multiple FileParts named the same, the parsed parts for the FilePart will always be the value of the last parsed FilePart. Using the example HTML below, if you attached different files to All.foo for each row, the MultipartParser would only have 1 value for All.foo ( the value from the second row ) instead of a vector. Let me know what you think, I can create a patch. http://marc.info/?l=xml-cocoon-cvsm=120840321224196w=4 http://marc.info/?l=xml-cocoon-cvsm=120840325524262w=4 Please test the new code in SVN. Thanks for your report. Joerg
Re: [vote] Release Cocoon 2.2-final
On 03.04.2008 15:06, Grzegorz Kossakowski wrote: COCOON BLOCKS - cocoon-template-impl-1.1.0.jar* - cocoon-forms-impl-1.1.0.jar* [*] The 1.0.0 releases are still missing but provided for a version that hasn't been mirgrated to Spring. These artifacts will hopefully follow soon. Any reason for such a weird practice marked with [*]? It's really questionable to release 1.1.0 before 1.0.0... If think you of linearly releases, yes, it is weird. But we have branches, so I don't see a real problem with it. Would be nice if we could release them sometime in the next weeks though. Joerg
Re: [vote] Release Cocoon 2.2-final
On 02.04.2008 11:36, Reinhard Poetz wrote: I've prepared the artifacts for the release of Cocoon 2.2 final. Find instructions about how you can test in a seperate mail. Report your findings to that thread and use this one for voting only. Thanks! +1 Unfortunately without testing. I planned to do it but haven't made it ... and in few hours I'm leaving for 1 week of American culture shock: Orlando, Florida :) Joerg
[OT] Mac OS X and Java development (was: Re: [jira] Updated: (COCOON-2063))
On 03.04.2008 23:33, Jörg Heinicke (JIRA) wrote: With Mac OS X I also have no access to the source code of the JDK. Which makes me wonder again how to do serious Java development with Mac OS X. I know a few of you guys are using Mac OS X. How do you do it? Whenever I start this I get annoyed very fast. The missing Java sources are only the tip of the iceberg. Every tree representation in Eclipse just sucks. Keyboard navigation in Mac OS X is completely inconsistent, especially with Java programs. There seems to be no serious SVN command line client (or at least the CollabNet download page is just self-linking at the moment: http://downloads.open.collab.net/binaries.html). And so on ... Windows has also bunch of annoying issues but there is at least consistency and usually there is a solution for everything. Do you guys all switch to Linux when it comes to Java development? :) Joerg
Re: svn commit: r643295 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/components/flow/ContinuationsManager.java src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.jav
On 01.04.2008 02:21, [EMAIL PROTECTED] wrote: Author: joerg Date: Mon Mar 31 23:21:53 2008 New Revision: 643295 URL: http://svn.apache.org/viewvc?rev=643295view=rev Log: Fix synchronization issues in ContinuationsManager implementation. Refactored version for 2.2 will follow this week ... Joerg
Re: svn commit: r643293 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuationDataBean.java
On 01.04.2008 08:02, Vadim Gritsenko wrote:
fix threading issue (DateFormat is not thread-safe)
public String getLastAccessTime() {
-return formatter.format(new Date(wc.getLastAccessTime()));
+synchronized (this.formatter) {
+return formatter.format(new Date(wc.getLastAccessTime()));
+}
}
The better fix is to use FastDateFormat which features thread safe
formatting.
All these nice little gems hidden in Apache Commons libs :)
Applied.
Thanks,
Joerg
Re: svn commit: r629374 - /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
On 20.02.2008 01:42, [EMAIL PROTECTED] wrote:
Author: antonio
Date: Tue Feb 19 22:42:45 2008
New Revision: 629374
URL: http://svn.apache.org/viewvc?rev=629374view=rev
Log:
Faster implementation.
Saw this one only now ... I'm a bit concerned about the approach.
First, do you really think this implementation is significantly faster?
Your implementation only caches the parser instance, you replace the
instantiation with ThreadLocal handling. Parsing itself should still be
the slowest part. How many Strings do you convert to SAX per thread?
Second, who cleans up the thread before it goes back to the thread pool?
At the end is it really worth the ugly implementation?
IMO it's a much better approach to make it a real Cocoon component
(Serializeable) instead and look up the SAXParser.
Joerg
Modified:
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
Modified:
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
URL:
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java?rev=629374r1=629373r2=629374view=diff
==
---
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
(original)
+++
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
Tue Feb 19 22:42:45 2008
@@ -5,9 +5,9 @@
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the License); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -29,25 +29,40 @@
/**
* XMLizable a String
- *
+ *
* @since 2.1.7
*/
public class StringXMLizable implements XMLizable {
+private static class Context {
+SAXParser parser;
+Context() throws SAXException {
+SAXParserFactory parserFactory = SAXParserFactory.newInstance();
+parserFactory.setNamespaceAware(true);
+parser = null;
+try {
+parser = parserFactory.newSAXParser();
+} catch (ParserConfigurationException e) {
+throw new SAXException(Error creating SAX parser., e);
+}
+}
+}
+
+private static final ThreadLocal context = new ThreadLocal();
private String data;
-public StringXMLizable(String data) {
+public StringXMLizable(final String data) {
this.data = data;
}
-public void toSAX(ContentHandler contentHandler) throws SAXException {
-SAXParserFactory parserFactory = SAXParserFactory.newInstance();
-parserFactory.setNamespaceAware(true);
-SAXParser parser = null;
-try {
-parser = parserFactory.newSAXParser();
-} catch (ParserConfigurationException e) {
-throw new SAXException(Error creating SAX parser., e);
+private Context getContext() throws SAXException {
+if (context.get() == null) {
+context.set(new Context());
}
+return (Context) context.get();
+}
+
+public void toSAX(ContentHandler contentHandler) throws SAXException {
+final SAXParser parser = getContext().parser;
parser.getXMLReader().setContentHandler(contentHandler);
InputSource is = new InputSource(new StringReader(data));
try {
Re: Javaflow - major memory issue
On 28.03.2008 04:55, Torsten Curdt wrote: The output I showed pointed to org.apache.cocoon.components.flow.java.Continuation which only seems to exist in Cocoon 2.1. Nothing unsets the context there. Hah - well spotted! Having a look into the code continuations are only handled by JavaInterpreter. There are two methods callFunction(..) and handleContinuation(..) calling Continuation.registerThread() and deregisterThread() in a finally block. From a brief look I have no idea if I can just unset the ContinuationContext there as well. You might know more about it. We should add a try/finally block in Continuation.suspend() that clears the context after a suspend. That should fix it. Unfortunately, it is not possible to unset the ContinuationContext completely. It's needed in JavaInterpreter.handleContinuation(..) when a child continuation is created: Continuation parentContinuation = (Continuation) parentwk.getContinuation(); ContinuationContext parentContext = (ContinuationContext) parentContinuation.getContext(); ContinuationContext context = new ContinuationContext(); context.setObject(parentContext.getObject()); context.setMethod(parentContext.getMethod()); Without completely rewriting it the only thing I did was to remove the data in the ContinuationContext that is not necessary. I do this by an extra call to ContinuationContext.onSuspend() in AbstractContinuable since Continuation is not aware of the implementation of its context (it's just an Object). Please review my changes [1] because I'm not really sure about them. They work for the normal case, but what happens in an error case? I can't see what's really going on except that the method is left on Continuation.suspend() ... It was very interesting to debug it when AbstractContinuable.sendPageAndWait(..) was actually hit twice. I guess this handling is different in 2.2. There a clean ContinuationContext is created on both callFunction(..) and handleContinuation(..). Joerg [1] http://svn.apache.org/viewvc?rev=642694view=rev
Re: Javaflow - major memory issue
On 30.03.2008 07:35, Torsten Curdt wrote: There is no need to really obtain that value from the parent. If handleContinuation would have also the function parameter it could use the same initialization as in callFuntion. Yes, if the function name would have been available ... This was beyond what I wanted to do. But since you confirmed it now I risked this change. Actually a way of fixing this would be to add two Strings to the Continuation class. One holding the classname, the other holding the method name. And then do context.setObject(userScopes.get(parentContinuation.getScopeName())); context.setMethod(methods.get(parentContinuation.getFunctionName())); The scopes are by Class. Therefore I only stored the function name and retrieved the method. in handleContinuation. Then the cleaning of the context should be fine. Yes, it's better now. Without completely rewriting it the only thing I did was to remove the data in the ContinuationContext that is not necessary. I do this by an extra call to ContinuationContext.onSuspend() in AbstractContinuable since Continuation is not aware of the implementation of its context (it's just an Object). Please review my changes [1] because I'm not really sure about them. Not a fan of the Collections.synchronizedMap(new HashMap()) change - but Just curious, any reason for this? Is it not as optimized? other than that they look OK on the first glance :) They work for the normal case, but what happens in an error case? I can't see what's really going on except that the method is left on Continuation.suspend() ... It was very interesting to debug it when AbstractContinuable.sendPageAndWait(..) was actually hit twice. :) ...what error case do you mean? Not sure, originally you proposed to put it into a try finally block. I guess this handling is different in 2.2. There a clean ContinuationContext is created on both callFunction(..) and handleContinuation(..). Indeed ...that would be another fix ...porting it from 2.2 :) That's really beyond what I want to do ;-) Let's leave the good stuff for 2.2. Thanks for looking into that. It was really interesting to see how a Java method is cut into two pieces. Suddenly the debugger stops stepping, but just leaves the methods. And on the next call it just jumps to the appropriate places in the code. Once you get used to it it's easy to debug. I have never tried it before but now I like it better than flowscript. Joerg
Re: [jira] Updated: (COCOON-2109) Incorrent cleanup of expired continuations
On 30.03.2008 20:08, Jörg Heinicke (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-2109: -- Affects version (Component): Parent values: Cocoon Core(10151). Component/s: (was: - Flowscript) * Cocoon Core Fix version (Component): Parent values: Cocoon Core(10227). I would like to add the proper Cocoon 2.2/Cocoon Core 1.0 versions, but the component versions are not yet available. Could somebody please add them or do we have to go via Infrastructure for that? Thanks, Joerg
Re: svn commit: r642855 - /cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java
On 30.03.2008 22:19, [EMAIL PROTECTED] wrote: Author: joerg Date: Sun Mar 30 19:19:41 2008 New Revision: 642855 URL: http://svn.apache.org/viewvc?rev=642855view=rev Log: fix synchronization Can you please review this [1]? It's too easy to mess this up ... I hope I did not introduce any deadlock. One thing I came across and did not like is the maintenance of the Set forest which is according to Javadoc only done for debugging reason, on the other hand exposed even via the interface. I would rather clean up the interface and remove the following 2 methods: /** * Prints debug information about all web continuations into the log file. * @see WebContinuation#display() */ public void displayAllContinuations(); /** * Get a list of all continuations as codeWebContinuationDataBean/code objects. */ public List getWebContinuationsDataBeanList(); At the moment it's only needed for StatusGenerator. We can therefore add another method getContinuations() which only returns a clone of the continuations. Also we should not maintain forest, but just reuse the Set expirations. We should be able to reconstruct everything else on demand. The current interface makes the implementation overly complex. In 2.1 it is even worse due to maintenance of Instrumentable variables. WDYT? If we don't want to remove the 2 methods for compatibility reasons we can deprecate them and change the implementation to just print a deprecation warning. Joerg [1] http://marc.info/?l=xml-cocoon-cvsm=120693001028779w=4
Re: Layered software designs
On 27.03.2008 02:25, Steven Dolg wrote: What I want to see is a concise pipeline API that comes with only little overhead in terms of its learning curve and its dependencies on third-party software. Usually this means that we stick with standard APIs as much as possible - and I think this rule applies for our situation too. See, one thing that I just don't get (and already asked) is how the pipeline API has anything to do with uri resolving. For me the latter (using java.net or source resolve) is an implementation detail. Our current pipeline interface [1] has no relationship to uri resolving. It only has a reference to SourceValidity because of caching [2]. If all this discussion is about removing this method (and the related getKeyForEventPipeline()) to get rid of this dependency I'm ok with it. The caching concern could be implemented in a separate Cacheable interface which should then also be decoupled from uri resolving (which seems to point to Peter's approach [3]). Just as a general observation: I'm starting to believe that I do not understand (anymore) what this is all about. We're jumping from high-level concepts (caching, layering) straight down to the lowest level (it's just method a in class B) and then right back. I have had the same problem from the beginning [1] and expressed it in my question above again. What is this discussion about - if uri resolving has nothing to do with the pipeline API? And what do we win when replacing source resolve with java.net except that we have one less dependency - when nobody really gets in contact with uri resolving anyway? I have only received half an answer to only the second question (standard API). Only then I started to look at the relationship between uri resolving and pipeline API and found only this one reference to the source resolve package. Joerg [1] http://marc.info/?l=xml-cocoon-devm=120649777119480w=4
Re: Javaflow - major memory issue
On 27.03.2008 04:39, Torsten Curdt wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? What do you mean by environment ...it's not like the whole jvm is stored but only the flow. External resources should be injected (vs stored) as much as possible. Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Joerg
Re: Javaflow - major memory issue
Torsten Curdt tcurdt at apache.org writes: Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? Ah, getting closer :) It's the Continuation that holds the ContinuationContext [1]: org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor $TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext context of org.apache.cocoon.components.flow.java.Continuation continuation of org.apache.cocoon.components.flow.WebContinuation Joerg [1] http://marc.info/?l=xml-cocoon-usersm=120582409910104w=4
Re: Javaflow - major memory issue
On 27.03.2008 10:33, Torsten Curdt wrote: Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? Ah, getting closer :) It's the Continuation that holds the ContinuationContext [1]: Hm... it should set clear the reference in 'finally'. See the execute method http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/StackRecorder.java?revision=560660view=markup The output I showed pointed to org.apache.cocoon.components.flow.java.Continuation which only seems to exist in Cocoon 2.1. Nothing unsets the context there. Having a look into the code continuations are only handled by JavaInterpreter. There are two methods callFunction(..) and handleContinuation(..) calling Continuation.registerThread() and deregisterThread() in a finally block. From a brief look I have no idea if I can just unset the ContinuationContext there as well. You might know more about it. Joerg
Re: JNet integration
On 26.03.2008 03:34, Reinhard Poetz wrote: I never had the need to implement a Source and for the mentioned simple cases I wonder where you have to cope with them at all? Cocoon used to be a framework for non-Java developers ... even if we introduce a pipeline API as in the examples in this thread why do I need to care about Urls or Sources at all? Why should it be different then map:generate with its src attribtue? And when I read CacheableFileGenerator something tells me this approach is wrong. What's the advantage of giving our components the responsibility to deal with strings that represent sources? Isn't that what components are there for? Encapsulating commonly used functionality? Why should I extract that to the pipeline *instance* level? So writing pipelines is becoming a mess! Joerg
Re: JNet integration
On 26.03.2008 08:04, Carsten Ziegeler wrote: What's the advantage of giving our components the responsibility to deal with strings that represent sources? Isn't that what components are there for? Encapsulating commonly used functionality? Why should I extract that to the pipeline *instance* level? So writing pipelines is becoming a mess! Hmm, I don't think so. Imagine a pipeline java api just taking a uri for the sources used in the pipeline. That's simple and easy. Now, you can use the source resolver on top of that, resolve your sources and you get a uri from your source that you can put into the pipeline api. That's neither a mess nor does it require more java coding. I'm not sure if we are talking about the same. If I take Reinhard's sample [1] URL baseUrl = new URL(file:///C:/temp/); Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml)); pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, xyz.xslt)); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(new InvocationImpl(System.out)); and want to add caching to it and therefore have to switch from URL to Source and from FileGenerator to CachingFileGenerator - sorry, but that's a mess since this means pretty much rewriting the application for adding caching. Why is this page so slow? Oh, sorry we forgot this pipeline to switch to caching ... Why can't high-level pipeline components use low-level components like SourceResolver? Then it is up to the component to use either URLs or Sources. That would be like implementing CacheableProcessingComponent or not. That's why I wonder where a pipeline writer gets into uri resolving at all? Why does he have to care about URLs or Sources? That's the component developer's concern. I really wonder if I miss something. All this seems to be too obvious to me ... Joerg [1] http://marc.info/?l=xml-cocoon-devm=120646488429681w=4
Re: JNet integration
On 26.03.2008 09:08, Carsten Ziegeler wrote: and want to add caching to it and therefore have to switch from URL to Source and from FileGenerator to CachingFileGenerator - sorry, but that's a mess since this means pretty much rewriting the application for adding caching. Why is this page so slow? Oh, sorry we forgot this pipeline to switch to caching ... Ah, no no, I'm not saying this :) There should only be one file generator. CachingFileGenerator was something Reinhard came up with - I only explained why I considered this as starting point for a mess which you disagreed with. But I will turn around the questions :) What caching do you need? The ultra complex caching we currently have which can cache partial pipelines? Or just the result of a pipeline? To be honest, I don't care about caching or how complex it is. It has to work and it does it nicely in Cocoon. If your name isn't Ard ( ;-) ) you usually don't need to know more details. And that's what it is as Vadim pointed out: implementation details. Joerg
Re: Layered software designs
On 26.03.2008 09:14, Reinhard Poetz wrote: What I want to see is a concise pipeline API that comes with only little overhead in terms of its learning curve and its dependencies on third-party software. Usually this means that we stick with standard APIs as much as possible - and I think this rule applies for our situation too. See, one thing that I just don't get (and already asked) is how the pipeline API has anything to do with uri resolving. For me the latter (using java.net or source resolve) is an implementation detail. Our current pipeline interface [1] has no relationship to uri resolving. It only has a reference to SourceValidity because of caching [2]. If all this discussion is about removing this method (and the related getKeyForEventPipeline()) to get rid of this dependency I'm ok with it. The caching concern could be implemented in a separate Cacheable interface which should then also be decoupled from uri resolving (which seems to point to Peter's approach [3]). Joerg [1] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/pipeline/ProcessingPipeline.html [2] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/pipeline/ProcessingPipeline.html#getValidityForEventPipeline() [3] http://marc.info/?l=xml-cocoon-devm=120654005017297w=4
Re: Null pointer when using Cocoon
On 23.03.2008 06:47, FreddyFlint wrote: Am new to cocoon and think have managed to install it correctly and everything but get the following error when I start tomcat Hey Freddy, it seems you have a problem with your classpath. If you look at the following lines root cause java.lang.NoSuchFieldError: JAVA_VERSION_INT org.apache.cocoon.components.language.programming.java.JavaLanguage.parameterize(JavaLanguage.java:119) you will see that Cocoon tries to access a static field on commons-lang's SystemUtils: this.compilerComplianceLevel = SystemUtils.JAVA_VERSION_INT; Nothing fancy about it, plain Java. Since this code compiles, you must have an older commons-lang.jar (Cocoon uses 2.3) on your classpath during runtime. Joerg
Re: Javaflow - major memory issue
On 18.03.2008 03:07, footh wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? Joerg
Re: JNet integration
On 25.03.2008 10:53, Reinhard Poetz wrote: Once again, my goal is that if you use e.g. Corona in its simplest form, I don't want to make everybody and his dog depend on JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL object is enough for simple use cases of a pipeline API. Yes, I understand that when it comes to caching pipelines, you need more, but not everybody needs caching pipelines. For that purpose there could be a CacheableFileGenerator, etc. If you are right and it is difficult or even impossible to remove the dependencies on source/sourceresolve/xmlutils/jnet, then be it. I withdraw my example Url(servlet:...) from above. When we can switch to sourceresolve 3.0, the dependency graph will get smaller anyway. The main benefit from using URLs (instead of the SourceResolver) comes from simple use cases, e.g. you need a pipeline in your Java application that reads in some XML file, performs some transformations and finally creates a PDF document. FWIW, using URLs should be all that you need. Hmm, I don't see the advantages of dropping the Source abstractions. Why giving up all the good things just to remove one dependency? What are the downsides of the Source abstraction? I never had the need to implement a Source and for the mentioned simple cases I wonder where you have to cope with them at all? Cocoon used to be a framework for non-Java developers ... even if we introduce a pipeline API as in the examples in this thread why do I need to care about Urls or Sources at all? Why should it be different then map:generate with its src attribtue? And when I read CacheableFileGenerator something tells me this approach is wrong. Joerg
Re: [2.2] Forms dependency on Ajax block
On 18.03.2008 03:46, Luca Morandini wrote: I beg to differ: disable your javascript, go to http://www.tutelamare.it/ and click on AmbienteMeteo; you'll see no Javascript there (at least for the widget types we used). With JavaScript *enabled* I'm stuck at the front page saying Tutela del mare - Loading... and Ottimizzato per Mozilla Firefox 2.0 e Microsoft Internet Explorer 7. Additionally it shows a dolphin and a spinning circle. ;-) Joerg
Re: [2.2] Forms dependency on Ajax block
On 18.03.2008 08:15, Luca Morandini wrote: I beg to differ: disable your javascript, go to http://www.tutelamare.it/ and click on AmbienteMeteo; you'll see no Javascript there (at least for the widget types we used). With JavaScript *enabled* I'm stuck at the front page saying Tutela del mare - Loading... and Ottimizzato per Mozilla Firefox 2.0 e Microsoft Internet Explorer 7. Additionally it shows a dolphin and a spinning circle. ;-) Duh ! Well, it works on my computer ;) Seriously: does it lament any Javascript error ? I'm using latest Mozilla SeaMonkey. It does not show any error in the Error Console. I have certain JavaScript functions disabled though: - Move or resize existing windows - Raise or lower windows - Hide the status bar - Change status bar text - Disable or replace context menus I don't know what exactly happens in case some page wants to try the one or the other (complete stop of JavaScript processing or just ignoring that particular function?). Usually these functions should really not be used - and I don't think that's the source of the problem. Joerg PS: We might better do this off-list if you have more questions.
Re: [2.2] Forms dependency on Ajax block
On 13.03.2008 16:20, Luca Morandini wrote: This means that Forms must depend on Ajax (Dojo to be more precise) despite the fact you use Ajax or not. This is not quite true I think. Forms used to have two different stylesheets: forms-field-styling.xsl and forms-advanced-field-styling.xsl. The first was a pure implementation, the second one used JS-enabled widgets. Which is a departure from 2.1.9, which, IIRC, worked even with Javascript disabled on the browser. I don't think Forms used to work without Javascript. There have always been onload handlers as far as I remember, but for the general idea, yes, it seems this has changed. If we are migrating to Dojo 1.0 that is definitely one of the requirements I'd like to see being addressed. Forms should work without Dojo. Dojo might be a requirement for Ajax-enabled though. GoogleMap should definitely be moved to advanced field stylesheet. I presume that a way to disentangle forms and ajax blocks would be to make two different forms-field-styling.xsl (one with Javascript and/or Ajax, the other without Javascript), loaded conditionally on ajax=true by forms-samples-styling.xsl. As I wrote that was originally the idea between forms-field-styling.xsl and forms-advanced-field-styling.xsl. We should get back to this separation. Why I'm making such a plea ? Well, the use of non-Javascript forms is a requirement for making websites accessible, which is a mandatory for governmental websites in Italy. I don't quite agree with it, Javascript does not necessarily prevent accessibility. I'm not too familiar with all the accessibility requirements but for example the tabs we have in Forms should be fine, aren't they? Joerg
Re: [jira] Commented: (COCOON-2150) Error on resetting response
On 12.03.2008 13:17, Grzegorz Kossakowski wrote: @Rice: No, this is not a good fix because response must be always discarded no matter if it's been already comitted or not. Why do you think so? Why do you want to discard a response which I carefully crafted in my application? And what would you deliver to the browser instead of my response which I expect to see? I'll discard it only if you return 404 response code *and* the servlet that has generated the response has a super servlet declared. Then I'll deliver response from super servlet (or from super servlet of super servlet, ect.). I guess the confusion resulted from your unconditional statement in the answer to Rice. This just did not make sense to me - and apparently Vadim. Joerg
Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
On 11.03.2008 08:54, Carsten Ziegeler wrote: We could argue about another default value than -1 though. Something like 1024^2. Hmm, not sure if we should change the default value. The idea of this default was to be sure that error handling works out of the box. If you have special cases like mentioned in the bug, it makes imho more sense to fine tune these special cases (for instance by not buffering). The output buffer value is one of the settings which is optimized for development and it should be tweaked for production usage. Hmm, ok, we could change this in the main sitemap as a default configuration while leaving it in the java code untouched. However, I still think that this is not needed, if people want to stream huge responses, they should think about what they are doing and configure everything accordingly. I totally agree that we lack documentation here. I really don't agree with this reasoning but I don't want to stress it too much to not get on your nerves, so it's my last try :-) 1. This IS already documented in the main sitemap and I think though hardly anybody is aware of it: Nobody had reacted on Felix' issue entry for 3 weeks. I can also see why: our main sitemap is the first thing I would get rid of when creating my own Cocoon application ;-) 2. Actually I don't care about the huge resources that much. I rather have big resources in mind - and concurrent users. What's worse as a default behavior for an incautious user: a screwed error page or a server brought down with an OOME? I also wanted to put the default as big as 1 MB so that it hardly affects anybody. I really don't see an additional value of endless buffering over such a big buffer. But I can prevent a fatal user error. And for everything that's beyond the default buffer size, here I completely agree with you, the user should think about potential issues in terms of buffering or caching. 3. Another, I admit minor point after so long time might be the change in behavior compared to former Cocoon versions. According to Robert [1] in Cocoon 2.0.4 it used to work out of the box. Joerg [1] http://marc.info/?l=xml-cocoon-devm=120473398413381w=4
Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
On 11.03.2008 04:48, Carsten Ziegeler wrote: We could argue about another default value than -1 though. Something like 1024^2. What do others think? Shall we change the default value from buffer everything (which lead to the OutOfMemoryError [1]) to something more secure in the sense of avoiding a potential source of error? Besides mentioning it on the changes page we have to set it to a value that's unlikely to be hit with a normal web application to change user application's behavior only in extreme cases. That's why I suggested 1MB. Hmm, not sure if we should change the default value. The idea of this default was to be sure that error handling works out of the box. If you have special cases like mentioned in the bug, it makes imho more sense to fine tune these special cases (for instance by not buffering). But I fear hardly anybody is aware or even uses the feature. The output buffer value is one of the settings which is optimized for development and it should be tweaked for production usage. It's not really development, is it? I mean even if you can not reset output buffer completely, you will still get the error markup appended and I would not care for development about how this looks :) Being aware of the potential change in behavior I also chose a quite huge buffer of 1 MB so that hardly anybody should be affected. We can also discuss about making it even bigger like 10 MB. But I consider a buffer that's flushed too early once in a while better than an OOME in the default setup. And people can still change it to -1 and endless buffering if they really need. But at least they are aware of the effects then. Joerg
Re: Problem with flowscript after svn up this morning
Has something changed with Rhino? http://cocoon.zones.apache.org/demos/trunk/samples/forms/form1.flow java.lang.RuntimeException: NOT SUPPORTED at org.mozilla.javascript.Context.compileImpl(Context.java:2353) at org.mozilla.javascript.Context.compileReader(Context.java:1310) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.compileScript(FOM_JavaScriptInterpreter.java:503) at org.apache.cocoon.components.flow.CompilingInterpreter$ScriptSourceEntry.compile(CompilingInterpreter.java:114) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:429) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:575) Joerg On 10.03.2008 08:20, rossputin wrote: I ran an svn up this morning on my Cocoon 2.2, first time in a while, and it seems to have broken flowscript across the board in the cocoon forms samples. I double checked by looking on 'http://cocoon.zones.apache.org/demos/trunk/samples/forms/' and it is the same situation there. The 'Various Actions' sample is fine, but anything involving flowscript is broken. I am not sure if this has already been raised on the list, I did a quick search but could not find anything.
Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
On 05.03.2008 23:06, Joerg Heinicke wrote: From what I see from the code (AbstractProcessingPipeline) it is possible to configure and setup/parameterize a pipeline with outputBufferSize. This means on both map:pipe and map:pipeline it should be possible to set an actual buffer size. Only if none is set (and it defaults to -1) the non-flushing BufferedOutputStream is used. I found a thread on the users list claiming outputBufferSize does not work [1] at the moment (or since some time). Carsten wrote he sees a potential problem but does not outline them. Felix, have you tried outputBufferSize? Carsten, can you tell us what might be wrong? Joerg [1] http://marc.info/?t=120111212300011r=1w=4
Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
On 08.03.2008 15:34, Felix Knecht wrote: ATM we are always talking about Buffered... I'm believe this has to do with caching the pipelines, right? So I wonder really why my the issue also occurs in noncaching pipelines? No, it has to do with the capability of resetting the OutputStream to send an error response in case of an error. If your buffer is too small, a first part of the actual content might already have been flushed when the error occurs and the error content is appended. Looks weird at the client's browser ;) Joerg
Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
On 08.03.2008 15:28, Felix Knecht wrote: Felix, have you tried outputBufferSize? Not yet. I didn't even knew how to configure it :-( Both map:pipe and map:pipeline should work as mentioned here: http://marc.info/?l=xml-cocoon-devm=120477640924395w=4 Joerg
Re: [Fwd: [jira] Closed: (MNG-2339) ${project.*} are interpreted in the wrong place]
On 07.03.2008 17:41, Grzegorz Kossakowski wrote: Yep... But can we start to think about pushing minimal version require for working with Cocoon? I know that 2.0.9 is not released yet but it looks like Maven folks are planning the release already. I'm very motivated to remove all these crap MNG-2339 introduced to our POMs. Can you describe what the current situation is? I thought we have problems only when using Java 1.4. You are talking about fixes to our POMs because of this issue. In which cases exactly do they apply and why not in the other ones? Are they only for Java 5 or has Java 5 never been a problem? Depending on the answer to the last question we could just recommend (i.e. not enforce) either use Maven 2.0.9 or Java 5. If removing all the crap breaks Cocoon with Java 5 as well I definitely prefer to raise the minimal required Maven version. If not I'm fine either way. Joerg
Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
On 05.03.2008 23:06, Joerg Heinicke wrote: We could argue about another default value than -1 though. Something like 1024^2. What do others think? Shall we change the default value from buffer everything (which lead to the OutOfMemoryError [1]) to something more secure in the sense of avoiding a potential source of error? Besides mentioning it on the changes page we have to set it to a value that's unlikely to be hit with a normal web application to change user application's behavior only in extreme cases. That's why I suggested 1MB. Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168
Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
On 05.03.2008 11:19, Felix Knecht wrote:
We are encountering this same problem in Cocoon 2.1.11. What is the
status of this issue? Is there a fix for it? It doesn't seem to
exist in Cocoon 2.0.4.
Obviously net yet, otherwise you could see it in the issue tracker.
Maybe BufferedOutputStream was introduced after cocoon 2.0.4 so that
version doesn't suffers this issue.
I've looked into this issue and I'm against Felix' fix. It stands
completely against the idea of buffering the whole pipeline content
which is done for error handlers. It should be possible for them to
reset the OutputStream. Or asked in other words? Why using the
non-flushing BufferedOutputStream at all?
Now how to handle the issue with huge resources? Should be quite easy.
From what I see from the code (AbstractProcessingPipeline) it is
possible to configure and setup/parameterize a pipeline with
outputBufferSize. This means on both map:pipe and map:pipeline it
should be possible to set an actual buffer size. Only if none is set
(and it defaults to -1) the non-flushing BufferedOutputStream is used.
Root sitemap has this example (in map:components/map:pipes section):
map:pipe name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProcessingPipeline
pool-max=${noncaching-pipeline.pool-max}
!-- parameter name=outputBufferSize value=8192/ --
/map:pipe
The following should also work (in map:pipelines section):
map:pipeline
map:parameter name=outputBufferSize value=8192/
...
/map:pipeline
We could argue about another default value than -1 though. Something
like 1024^2.
WDYT?
Joerg
ResourceReader headers
When looking at the history of ResourceReader I also noticed something else: In rev 155087 [1] Vadim did the following change: Move response header initialization into the setup phase. Remove Last-Modified header initialization: this is done in the environment by request from AbstractProcessingPipeline. In the next revision 410112 [2] (but 15 months later) Antonio readded setting the Last-Modified header: Fix COCOON-1840 XMLFileModule: file-specific configuration ignored. The commit message seems to be wrong and the change was not included in the user-provided patch [3]. It rather seems to be COCOON-1266 [4] but the provided and applied patch is older than Vadim's change. I guess we should review this code. The revisions for trunk are 155099 [5] and 410113 [6]. Joerg [1] http://svn.apache.org/viewvc?view=revrevision=155087 [2] http://svn.apache.org/viewvc?view=revrevision=410112 [3] https://issues.apache.org/jira/browse/COCOON-1840 [4] https://issues.apache.org/jira/browse/COCOON-1266 [5] http://svn.apache.org/viewvc?view=revrevision=155099 [6] http://svn.apache.org/viewvc?view=revrevision=410113
[Fwd: [jira] Closed: (MNG-2339) ${project.*} are interpreted in the wrong place]
Eventually ...
Joerg
Original Message
Subject: [jira] Closed: (MNG-2339) ${project.*} are interpreted in the
wrong place
Date: Wed, 27 Feb 2008 18:56:28 -0600 (CST)
[http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
Brett Porter closed MNG-2339.
-
Resolution: Fixed
${project.*} are interpreted in the wrong place
---
Key: MNG-2339
URL: http://jira.codehaus.org/browse/MNG-2339
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Reporter: Emmanuel Venisse
Assignee: Brett Porter
Priority: Critical
Fix For: 2.0.9
If a plugin use ${project.version}, this parameter is interpreted with the
version of the current project and not the plugin version. I think we have the
same pb with dependencies and other ${project.*}
For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT,
${project.version} used in the plugin will be interpreted as 1.0-SNAPSHOT
instead of 2.0
Re: Rename cocoon:rcl to cocoon:wrap-block
On 20.02.2008 12:47, Reinhard Poetz wrote: mvn cocoon:load jetty:run after reading all the mails again, here are my two favorits: mvn cocoon:load jetty:run mvn cocoon:prepare jetty:run Considering your explanation [1] I slightly prefer cocoon:prepare. Joerg [1] http://marc.info/?l=xml-cocoon-devm=120351863516460w=4
