[jira] Updated: (COCOON-2206) Pass the sitemap and the input parameters separately to the controller.
[ https://issues.apache.org/jira/browse/COCOON-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Dolg updated COCOON-2206: Attachment: controller.txt A patch with the changes described above. Relative to corona-controller. Pass the sitemap and the input parameters separately to the controller. --- Key: COCOON-2206 URL: https://issues.apache.org/jira/browse/COCOON-2206 Project: Cocoon Issue Type: Bug Components: Corona (experimental) Reporter: Steven Dolg Attachments: controller.txt Currently sitemap and input parameters are passed to the controller in a single map. This can lead to parameters overriding each other. Pass them separately to prevent this and make explicit which parameters are part of the configuration (iow sitemap) and which are part of the input (iow request). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2206) Pass the sitemap and the input parameters separately to the controller.
Pass the sitemap and the input parameters separately to the controller. --- Key: COCOON-2206 URL: https://issues.apache.org/jira/browse/COCOON-2206 Project: Cocoon Issue Type: Bug Components: Corona (experimental) Reporter: Steven Dolg Attachments: controller.txt Currently sitemap and input parameters are passed to the controller in a single map. This can lead to parameters overriding each other. Pass them separately to prevent this and make explicit which parameters are part of the configuration (iow sitemap) and which are part of the input (iow request). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [OT] Mac OS X and Java development
On Thu, May 8, 2008 at 1:10 AM, Joerg Heinicke [EMAIL PROTECTED] wrote:
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?
Came preinstalled on my mac. Did you install the dev tools?
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.
VX Revo here. 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.
I dumped eclipse a while back for being too broken/buggy for my
tastes. But, when I was using it, I just abbreviated the names in
package explorer. No problems after that.
Frankly the Mighty Mouse drives me crazy. Tried it once, almost threw
it against the wall.
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.
Command-left,right,up,down move to the beginning end of the line
or document. Same global consistency.
Option left-right move between words. Option up/down goes up/down a
page. Again, consistent.
These are the same in almost every program I've used so far. Every
*other* platform drives me crazy now.
The only time I ever hit the Fn keys are for page up/down in some
programs that don't do Option-* (e.g. bash, which traps those keys,
but can't use them properly), and if I want to use the function keys.
Most mac apps bind menu options to the command key and a letter,
making the function keys useful only for UI functions (e.g. exposé,
spaces) or apps ported from other platforms.
Sorry it's not identical to windows, which was copied by linux, but it
*is* better.
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.
Huh, I didn't realize people still run such older versions of MacOS.
Leopard has tools like svn, ant, mvn, ruby, python, etc installed by
default with the devtools. Only reason I got macports last time was
to install wireshark.
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 ;)
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. Looks like they're strained for devs between Mac
OS X and the iPhone.
Again, did you install the dev tools off the Leopard DVD?
--
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech
[continuum] BUILD SUCCESSFUL: Cocoon - Apache Cocoon [build root] - Build Def:
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=87967projectId=51 Build statistics: State: Ok Previous Build: No previous build. Started at: Thu 8 May 2008 06:35:39 -0700 Finished at: Thu 8 May 2008 06:51:18 -0700 Total time: 15m 38s Build Trigger: Schedule Build Number: 267 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.4.2_15 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks,it Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4, Large Memory Description: Test Summary: Tests: 360 Failures: 0 Total time: 99.19399
[jira] Assigned: (COCOON-2206) Pass the sitemap and the input parameters separately to the controller.
[ https://issues.apache.org/jira/browse/COCOON-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhard Poetz reassigned COCOON-2206: -- Assignee: Reinhard Poetz Pass the sitemap and the input parameters separately to the controller. --- Key: COCOON-2206 URL: https://issues.apache.org/jira/browse/COCOON-2206 Project: Cocoon Issue Type: Bug Components: Corona (experimental) Reporter: Steven Dolg Assignee: Reinhard Poetz Attachments: controller.txt Currently sitemap and input parameters are passed to the controller in a single map. This can lead to parameters overriding each other. Pass them separately to prevent this and make explicit which parameters are part of the configuration (iow sitemap) and which are part of the input (iow request). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2206) Pass the sitemap and the input parameters separately to the controller.
[ https://issues.apache.org/jira/browse/COCOON-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhard Poetz closed COCOON-2206. -- Resolution: Fixed patch applied - thanks Steven! Pass the sitemap and the input parameters separately to the controller. --- Key: COCOON-2206 URL: https://issues.apache.org/jira/browse/COCOON-2206 Project: Cocoon Issue Type: Bug Components: Corona (experimental) Reporter: Steven Dolg Assignee: Reinhard Poetz Attachments: controller.txt Currently sitemap and input parameters are passed to the controller in a single map. This can lead to parameters overriding each other. Pass them separately to prevent this and make explicit which parameters are part of the configuration (iow sitemap) and which are part of the input (iow request). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
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. Joerg Heinicke wrote: 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: Avoiding OutOfMemory Errors by limiting data in pipeline
Hi Joerg, I am +1. One question, what are supposed to be the default values for both parameters? Best Regards, Antonio Gallardo. Joerg Heinicke escribió: 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 Wed, 2008-05-07 at 22:52 -0400, Joerg Heinicke wrote: 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 What happens if an exception leaves the parser in a messy state when it is reused? Is there any rule which would guarantee that this should never happen for the average SAXParser implementation? Cheers, Alfred.
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabled]
On Mon, 2008-05-05 at 00:08 -0700, Ralph Goers wrote: I sure am glad we decided to go with Java 1.4 for 2.2. See the nice bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least now I'm certain we won't be supporting 1.4 until 2010. No hope to get rid of 1.4 anytime soon. Java 1.3 is EOL since Dec 2006, and we are still supporting it for 2.1. http://java.sun.com/j2se/1.3/download.html Cheers, Alfred.
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
