Cocoon-2.1.X Tests Failure 12/08/04
Automated Cocoon Unit tests failed! Full log file if this unit test run is available here: http://nagoya.apache.org/~vadim/cocoon-test-log-20041208.log Last messages from the log file: == [foreach] reader-mime-type.xml:39: Starting http://localhost:1///samples/test/reader-mime-type/test20.html [foreach] reader-mime-type.xml:41: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:39: Finished http://localhost:1///samples/test/reader-mime-type/test20.html (103ms) [foreach] reader-mime-type.xml:44: Starting http://localhost:1///samples/test/reader-mime-type/test20.html [foreach] reader-mime-type.xml:46: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:44: Finished http://localhost:1///samples/test/reader-mime-type/test20.html (35ms) [foreach] reader-mime-type.xml:50: Starting http://localhost:1///samples/test/reader-mime-type/test30.html [foreach] reader-mime-type.xml:52: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:50: Finished http://localhost:1///samples/test/reader-mime-type/test30.html (502ms) [foreach] reader-mime-type.xml:55: Starting http://localhost:1///samples/test/reader-mime-type/test30.html [foreach] reader-mime-type.xml:57: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:55: Finished http://localhost:1///samples/test/reader-mime-type/test30.html (87ms) [foreach] reader-mime-type.xml:61: Starting http://localhost:1///samples/test/reader-mime-type/test40.html [foreach] reader-mime-type.xml:63: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:61: Finished http://localhost:1///samples/test/reader-mime-type/test40.html (21ms) [foreach] reader-mime-type.xml:66: Starting http://localhost:1///samples/test/reader-mime-type/test40.html [foreach] reader-mime-type.xml:68: Running test [Header: Content-type = text/html ... done (1ms) [foreach] reader-mime-type.xml:66: Finished http://localhost:1///samples/test/reader-mime-type/test40.html (31ms) [foreach] reader-mime-type.xml:72: Starting http://localhost:1///samples/test/reader-mime-type/test50.html [foreach] reader-mime-type.xml:74: Running test [Header: Content-type = text/html[1;31m Failure: file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:74: message doesn't match because header 'content-type' is not present[m [foreach] ... done (9ms) [foreach] reader-mime-type.xml:72: Finished http://localhost:1///samples/test/reader-mime-type/test50.html (51ms) BUILD FAILED file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72: Task at file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72: failed Total time: 28 seconds Last messages from the server console: == [EMAIL PROTECTED]: Startup sequence initiated from main() method [EMAIL PROTECTED]: Loaded properties from [/disk/raid0/home/vadim/svn/cocoon-2.1.X/server.properties] [EMAIL PROTECTED]: Initiating startup sequence... [EMAIL PROTECTED]: Server socket opened successfully in 3 ms. [EMAIL PROTECTED]: Database [index=0, id=0, db=file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db/cocoondb, alias=] opened sucessfully in 1776 ms. [EMAIL PROTECTED]: Startup sequence completed in 1832 ms. [EMAIL PROTECTED]: 2004-12-08 01:29:45.409 HSQLDB server 1.7.3 is online [EMAIL PROTECTED]: To close normally, connect and execute SHUTDOWN SQL [EMAIL PROTECTED]: From command line, use [Ctrl]+[C] to abort abruptly - The database 'db' root directory has been set to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db. Keep in mind that if a war upgrade will take place the database will be lost. - Database points to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db - [main] '/db/system/SysSymbols' Set object system_SysConfig - [main] '/db/system/SysConfig' Set document database.xml - [main] '/db/system/SysSymbols' Set object meta_Metas - [main] '/db/system/SysSymbols' Set object meta_Metas_system_SysConfig - Database 'db' successfully opened - Xindice server successfully started parameter = @PARAMETER@ replaceme = replaceme-abc parameter = @PARAMETER@ replaceme = replaceme-123 - VM shutting down with the disk store for cocoon-ehcache-1 still active. The disk store is persistent. Calling dispose... - Database 'db' successfully closed - Scheduler Cocoon_$_Wed_Dec_08_01:29:33_PST_2004 paused. - Scheduler Cocoon_$_Wed_Dec_08_01:29:33_PST_2004 shutting down. - Scheduler Cocoon_$_Wed_Dec_08_01:29:33_PST_2004 paused
Proposed ImageReader patch
Dear All
I was thinking of changing the org.apache.cocoon.reading.ImageReader
(from the 2.1.5.1 release) to accept any input image type supported by
the j2se. Of course, due to the lack of available encoders the output is
still jpeg. I'm attaching the source to this email, if you're happy with
it let me know so I can commit it to bugzilla.
comments/advice welcome
G.
/*
* Copyright 1999-2004 The Apache Software Foundation.
*
* Licensed 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.reading;
import java.awt.color.ColorSpace;
import java.awt.geom.AffineTransform;
import java.awt.image.AffineTransformOp;
import java.awt.image.BufferedImage;
import java.awt.Image;
import java.awt.image.ColorConvertOp;
import java.awt.image.RescaleOp;
import java.awt.image.WritableRaster;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.Serializable;
import java.util.Map;
import javax.swing.*;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.environment.SourceResolver;
import org.apache.commons.lang.BooleanUtils;
import org.xml.sax.SAXException;
import com.sun.image.codec.jpeg.ImageFormatException;
import com.sun.image.codec.jpeg.JPEGCodec;
import com.sun.image.codec.jpeg.JPEGDecodeParam;
import com.sun.image.codec.jpeg.JPEGImageDecoder;
import com.sun.image.codec.jpeg.JPEGImageEncoder;
/**
* The codeImageReader/code component is used to serve binary image data
* in a sitemap pipeline. It makes use of HTTP Headers to determine if
* the requested resource should be written to the codeOutputStream/code
* or if it can signal that it hasn't changed.
*
* Parameters:
* dl
* dtlt;widthgt;/dt
* ddThis parameter is optional. When specified it determines the width
* of the image that should be served.
* /dd
* dtlt;heightgt;/dt
* ddThis parameter is optional. When specified it determines the height
* of the image that should be served.
* /dd
* dtlt;scale(Red|Green|Blue)gt;/dt
* ddThis parameter is optional. When specified it will cause the
* specified color component in the image to be multiplied by the
* specified floating point value.
* /dd
* dtlt;offset(Red|Green|Blue)gt;/dt
* ddThis parameter is optional. When specified it will cause the
* specified color component in the image to be incremented by the
* specified floating point value.
* /dd
* dtlt;grayscalegt;/dt
* ddThis parameter is optional. When specified and set to true it
* will cause each image pixel to be normalized. Default is false.
* /dd
* dtlt;allow-enlarginggt;/dt
* ddThis parameter is optional. By default, if the image is smaller
* than the specified width and height, the image will be enlarged.
* In some circumstances this behaviour is undesirable, and can be
* switched off by setting this parameter to no so that images will
* be reduced in size, but not enlarged. The default is yes.
* /dd
* /dl
*
* @author a href=mailto:[EMAIL PROTECTED]Stefano Mazzocchi/a
* @author a href=mailto:[EMAIL PROTECTED]Stephan Michels/a
* @author a href=mailto:[EMAIL PROTECTED]Torsten Curdt/a
* @version CVS $Id: ImageReader.java,v 1.10 2004/03/28 20:51:24 antonio Exp $
*/
final public class ImageReader extends ResourceReader {
private int width;
private int height;
private float[] scaleColor = new float[3];
private float[] offsetColor = new float[3];
private RescaleOp colorFilter = null;
private boolean enlarge;
private final static String ENLARGE_DEFAULT = true;
private ColorConvertOp grayscaleFilter = null;
private final static String GRAYSCALE_DEFAULT = false;
public void setup(SourceResolver resolver, Map objectModel, String src,
Parameters par)
throws ProcessingException, SAXException, IOException {
super.setup(resolver, objectModel, src, par);
width = par.getParameterAsInteger(width, 0);
height = par.getParameterAsInteger(height, 0);
scaleColor[0] = par.getParameterAsFloat(scaleRed, -1.0f);
scaleColor[1] = par.getParameterAsFloat(scaleGreen, -1.0f);
scaleColor[2] = par.getParameterAsFloat(scaleBlue, -1.0f);
offsetColor[0] =
Re: Proposed ImageReader patch
george georgovassilis wrote: Dear All I was thinking of changing the org.apache.cocoon.reading.ImageReader (from the 2.1.5.1 release) to accept any input image type supported by the j2se. Of course, due to the lack of available encoders the output is still jpeg. I'm attaching the source to this email, if you're happy with it let me know so I can commit it to bugzilla. please create a diff -u patch and file it to bugzilla thanks -- Torsten
Re: XML Serializers [was: XMLSerializer replaces tabs with #9; ]
It is set up to serialize a Doctype if it's present in the incoming stream, but it doesn't read from the sitemap configuration to read specific values for cases where the stream doesn't have DOCTYPE info. Which leads to a few questions: 1) Is XSLT output the preferred way now to get a DOCTYPE on pipeline results? Not as far as i know. IIUC Cocoon does everthing via the serializers. These are new serializers that Pier made recently for his app and donated back to Cocoon. I don't know whether they are finished or just enough to get his job done. there are still some minor issues with them. but it would be great if we could fix them and switch to use them by default (IMHO) 2) Would it make sense to have the new XML Serializer read configuration parameters for doctype-public and doctype-system? (I note that it already reads configuration for 'encoding', something else that can be set via XSLT output) I say yes. Implement them so that people can just switch the name of their component and directly use the same sitemap config. sure thing. cheers -- Torsten
Re: happy nikolaus
Does this mean we could theoretically have e.g. WEB-INF/src with all webapp source files and have them automagically compiled on the fly (including Cocoon itself)? potentially - yes. not sure about the implications on the container though. probably the CCL needs to go even further up the chain for that. ...but feel free to give it a try :-) that would be hardcore! cheers -- Torsten
Re: happy nikolaus
What on earth can we give you as a return gift? Community gratitude. that's way enough :-) cheers -- Torsten
Re: happy nikolaus
...we have auto-compiling javaflow!! snip/ You are now officially *MY* hero. No, wait, you need to allow me to have dynamically autorecompiled sitemap components and at *that* point you are my hero :-) AFAIU, this could easily be done by adding a per-sitemap autocompiling classloader. We could even have per-sitemap lib and src directories. Read BLOCK-INF/lib and BLOCK-INF/src ;-) you volunteering? sounds like that to me? ;o) ...but I am not sure if it's that easy. the container needs to be notified. The roles might have changed and so on. cheers -- Torsten
Re: Proposed ImageReader patch
On Wed, 8 Dec 2004, Torsten Curdt wrote: hi george i have already this patch file (diff), so i can add the patch in bugzilla for you, if you dont mind. --stavros george georgovassilis wrote: Dear All I was thinking of changing the org.apache.cocoon.reading.ImageReader (from the 2.1.5.1 release) to accept any input image type supported by the j2se. Of course, due to the lack of available encoders the output is still jpeg. I'm attaching the source to this email, if you're happy with it let me know so I can commit it to bugzilla. please create a diff -u patch and file it to bugzilla thanks -- Torsten
Re: happy nikolaus
Torsten Curdt wrote: AFAIU, this could easily be done by adding a per-sitemap autocompiling classloader. We could even have per-sitemap lib and src directories. Read BLOCK-INF/lib and BLOCK-INF/src ;-) you volunteering? sounds like that to me? ;o) ...but I am not sure if it's that easy. the container needs to be notified. The roles might have changed and so on. First step is having a running BlockManager in Cocoon core. Things might be clearer then ... -- Reinhard
Re: Issue with cocoon views -- Using views to debug not really possible?
Thomas Alexnat wrote:
Dear Sylvain,
thank you for your help. I have tested your idea, with a simple
content aggregation and both variants do not show the correct xml tree:
map:aggregate element=categoryindexpage
map:part src=cocoon:/getXMLContentA/
map:part src=cocoon:/getXMLContentB/
/map:aggregate
or
map:aggregate element=categoryindexpage
map:part src=cocoon:raw:/getXMLContentA/
map:part src=cocoon:raw:/getXMLContentB/
/map:aggregate
are resulting in a corrupt XML tree after calling them with the
default pretty-print view. As expected, the pretty-view gets
pretty-printed...
Ok, so cocoon:raw behaves exaclty as the regular cocoon: regarding
views.
QUESTION
What could be the best practice, if I want to look at the XML of a
certain pipeline, before its transformation is being called? All I
need is a good debugger view for any matcher. I am just wondering why
nobody else had this same issue before...
The answer with the current view handling is to only use view with
final pipelines, i.e. ones that don't rely on cocoon: URLs.
Now the question is what behaviour is to be considered correct
regarding views and internal pipeline calls. Should we consider that
view should be taken into account only for external requests?
What do people think?
Sylvain
PS: Thomas, no need to cc me privately, I'm a careful reader of this
list, especially follow-ups to my posts.
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Proposed ImageReader patch
i have already this patch file (diff), so i can add the patch in bugzilla for you, if you dont mind. the file you posted wasn't a diff. cheers -- Torsten
Re: Proposed ImageReader patch
Dear All let's not make a fuzz of it :-) I'm new to this whole procedure of committing, patching etc. In the committers tips it advises 'patience', so please be patient even if it takes me a few days (given that I'm quite busy today and our network link is really nerve-testing) to create the patch and commit it. I promise that I'll do it, just give me time to do it the right way. Best Regards G. Torsten Curdt wrote: i have already this patch file (diff), so i can add the patch in bugzilla for you, if you dont mind. the file you posted wasn't a diff. cheers -- Torsten
[GUMP@brutus]: Project cocoon-block-template (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-template has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-template : Java XML Framework Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [template-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/gump_work/build_cocoon_cocoon-block-template.html Work Name: build_cocoon_cocoon-block-template (Type: Build) Work ended in a state of : Failed Elapsed: 6 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=08122004 -Dblock-name=template gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[GUMP@brutus]: Project cocoon-block-cron (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-cron has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-cron : Java XML Framework Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-cron/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [cron-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/cocoon/cocoon-block-cron/gump_work/build_cocoon_cocoon-block-cron.html Work Name: build_cocoon_cocoon-block-cron (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=08122004 -Dblock-name=cron gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
Re: Proposed ImageReader patch
let's not make a fuzz of it :-) no fuzz ...but in order to review the patch we expect a diff -u as stated on the website ...that's all I was saying. not sure what this has to do with impatience as you were implying. Just file to bugzilla whenever you want and we will review it whenever we want ;-) cheers -- Torsten
Re: [RT] Attribute Driven Templates
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
When I started working on a attribute template language (ATL)
proposal, it was obvious to me that it should be attribute name
driven. So why did I end up proposing a content driven one? While the
attribute driven is atractive for very simple examples it IMO very
soon becomes rather complicated as soon as you try to describe
something slightly more complicated. E.g. if we need more than one
parameter to the directive, how do we describe that? TAL uses the
syntax:
textarea rows=80 cols=20
tal:attributes=rows request/rows;cols request/cols
The problem here is not exactly of having multiple parameters for one
directive, but more multiple directives with the same name, which
clashes with the fact that XML require distinct attribute names.
I chosed the example as I got the impression that TAL never uses more
than one argument. So the above was the closest to having more than one
argument. The main place where more than one argument i needed is for
macro definiton and call, and TAL only have Phyton defined macros.
Seeing the example again I realize that I was wrong it actually takes
two argument: in tal:attribute=rows request/rows, rows is one
argument and request/rows is another.
Somewhat OT, I also think that the argument, and content directives
could be removed. They are used in TAL as they don't have any embeded
expressions (${expr}), so it is the only way of injecting data, an
advantage with their approach is that you see example content instead of
content with embeded ${expr} in your WYSIWYG. The disadvantage is
that it is much harder to write the template.
What we need that I forgot is a mechanism for selectively inserting
attributes like:
option tl:do=attribute-if(.=$current, name='selected')
selected=selected ...
...
that let a named attribute be part of the output if a test is true.
In our annotated-HTML-to-XSL compiler, we avoid this problem by using
the following notation for attributes:
textarea rows=80 cols=20 tal:attribute-rows=request/rows
tal:attribute-cols=request/cols
The tal:attribute-* instruction allows any attribute name to be
specified, while still imposing uniqueness of the names of dynamically
evaluated attributes.
You instead create the problem that you can't use a scheme for checking
your attributes. Sorry, I just don't like the idea about leting part of
an attribute name become a parameter for the directive.
snip/
tr t:forEach=cart/item
or
tr t:forEach=item in cart/item
for iterators.
Here is the questions are if we want to work on a implicitly defined
context as in XSLT or if we want to define a loop variable and also
if we should use synatctic constructs that are close to natural
language like item in cart/item. I prefer the implictely defined
context and would also prefer avoiding complicated syntactic
conctructs if possible.
JXTemplate provides both approaches, depending if JXPath or Jexl is
used [1]. But this is semantically similar to a java.util.Iterator()
while the varStatus variant provides the feature of an indexed loop
(i.e. for (int i = 0; i list.size(); i++)).
This varStatus variant is much more complicated but is sometimes
invaluable to know where you are in the iteration process.
When do you need that?
Note than rather to use an approach or the other depending on the EL
language used or the attribute, we could use different constructs.
Modify the context object:
tr t:foreach=cart/item
Define an iterator:
tr t:loop=item in cart/item
Define an indexed loop:
tr t:indexed-loop=status in cart/item
I don't get the difference between loop and indexed-loop.
(hearing Stefano coming behind me, ready to shout FS!!! in my ears...)
His new FS detector doesn't seem fully callibrated yet, so I do some
community service instead ;)
FS!!!
AFAIK the only reason to defiene a loop variable is that you don't want
to affect the context. But you can just save the context in a variable
instead:
tr t:do=let(ctx=.);forEach(cart/item)
No need to have two constructions.
Concering indexed loops, when do you need them? The idea with a template
is to present model data, so in most cases you just iterate over the
model data. I've used indexed loops in just a handfull of cases, and
that have been in cases where I probably put a little bit to much
programing logic in my view.
snip/
Needing to solve the same problem as you solved with JXTG but
imposing an extra
constraint (the template must be able to show in Dreamweaver all the
time) cannot
reasonably simplify the problem can it?
Well, you presented some extreme cases. It's unlikely that a single
tag will hold more that, say, two control structures (e.g. loop and
if), which keeps the attributes quite readable.
The problem is not the number of directives, it is rather that you need
to understand in what order the two directives is going to be applied.
So to sum up, I believe that attribute name based syntax will
Re: [Templates] Summary and Voting aspects
Glen Ezkovich wrote: On Dec 7, 2004, at 4:18 AM, Daniel Fagerstrom wrote: Refactoring JXTG I think everything starts here. Once this gets refactored the opportunities for further development should become apparent. There is nothing terribly wrong with JXTG, except that it is a monolithic class with monolithic methods. Yes, my current view is that I feel unconfortable with starting from scratch (http://www.joelonsoftware.com/printerFriendly/articles/fog000348.html). Fun or not, we should just build a large test set arround JXTG and refactor it, towards the kind of architecture that we have discussed in previous discussions. We can do that work on a copy of JXTG in the template block. There is not that much activity on the current codebase, so I think it easier to keep them syncronized than working on everything whithin core. I have started some work in that direction and will put them in SVN as soon as I get my splitted version of JXTG to compile again :/ For 1), the back compabillity preserving refactoring of JXTG. I cannot see any need for voting about this. Either it gains community support in terms of that people joins in design, implementation and testing, or it don't. And in that case we just remove it. Then if the new refactored implementation should replace the current one and get oficial status, thats certainly something to vote about. Also if we develop some new interfaces e.g. for ELs or formaters that we feel that should be made part of core, it will also be something that should be handled by proposals and votes. I can assure you that I have no urge to implement everything myself at all (as some of you might have noticed I enjoy design descussions and proposals more than implementing stuff ;) ), You mean some people actually LIKE to implement stuff? ;-) I do, but not as much as discussing the design ;) I will continue to strive for community involvment. And I will write a proposal about how to continue the refactoring as soon as I find time. Next Generation JXTG This is about how we should continue our development of the template language beyond JXTG 1.0. It is purely at the RT stage, no concrete design proposals yet. Later there might be proposals in form of documents or proof of concept implementations. But that is a later question. And an interesting discussion. I think once people look at the refactored JXTG and have an itch to scratch you will see a few attempts at expression language development. Yes, the current monolith makes that far to hard. Attribute Driven Templating === This is ongoing discussions. My hope is that we can design the template engine in such a way that the synatx handling part is plugable so that attribute and tag driven templates (JXTG) can coexist, (although not in the same document ;) ). I'm guessing that after refactoring JXTG you will see that this is easily doable. I'm only guessing because I have only taken a brief look at JXTG's code, but one of the goals of refactoring is to organize the code properly. Yes, it will be easily doable after refactoring. But that is a technical quiestion IMO. Anyway, we need to discuss the consequences of dirrerent syntaxes a little bit more before implementing anything. You mean defining the language. No one wants to implement. ;-) Actually there are some people around here that prefer programming to discussing. And a few impresive persons who manage to be active in both areas :) Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow Cool, one of my favourite books.
Re: Proposed ImageReader patch
On Wednesday 08 December 2004 17:40, george georgovassilis wrote: Dear All I was thinking of changing the org.apache.cocoon.reading.ImageReader (from the 2.1.5.1 release) to accept any input image type supported by the j2se. Of course, due to the lack of available encoders the output is still jpeg. I'm attaching the source to this email, if you're happy with it let me know so I can commit it to bugzilla. A couple of months ago, I have actually posted a much more advanced block, called ImageOpReader that can replace both the old ImageReader as well as the proposed patch, be extended with more Image operations, and is pretty quick for scaling operations. See http://issues.apache.org/bugzilla/show_bug.cgi?id=31718 for details. Unfortunately, noone has picked this up before :o( Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
[EMAIL PROTECTED] wrote: Author: lgawron Date: Wed Dec 8 03:47:12 2004 New Revision: 111262 URL: http://svn.apache.org/viewcvs?view=revrev=111262 Log: implement 2 modes of work for continuations manager: - standard, as it was up till now - secure in which continuations are bound to session. Only the session that created a continuation can invoke it. All continuations bound to session are invalidated when the session ifself gets invalidated. This mode is for those users who build web applications protected with authentification. Modified: cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuation.java cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf Previously we have discussed about three continuations manager work modes: - standard (current functionality) - continuations invalidated along with session, still the continuation is reachable from other sessions (or no session at all) - fully isolated. only the session that created the continuation can access it. Thing is after a while I still do not see a use case for a second case where continuations would be invalidated with user session but still accessibe for everyone (of course before invalidation). So I have changed the continuations manager to support only 1st and 3rd case. about 2nd: YAGNI (thanks Stefano for new cool phrase :)) -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
DO NOT REPLY [Bug 32586] New: - Allow ImageReader to process other image formats than JPEG
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32586. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32586 Summary: Allow ImageReader to process other image formats than JPEG Product: Cocoon 2 Version: 2.1.5 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Changed org.apache.cocoon.reading.ImageReader (from the 2.1.5.1 release) to accept any input image type supported by the j2se. Of course, due to the lack of available encoders the output is still jpeg. Instead of the JPEGDecoder used previously this now uses classes from java.awt and java.swing. In order for this to work on environments without graphics support, use -Djava.awt.headless=true -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32586] - Allow ImageReader to process other image formats than JPEG
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32586. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32586 --- Additional Comments From [EMAIL PROTECTED] 2004-12-08 14:18 --- Created an attachment (id=13681) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13681action=view) Diff for ImageReader -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32541] - [Patch] HTTPIncludeTransformer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32541 --- Additional Comments From [EMAIL PROTECTED] 2004-12-08 14:32 --- In fact, my transformer isnt a real include transformer, since it doesnt act as a content aggregator. More I think on it, and more I believe HTTPRequestTransformer should be a more appropriate name. I wrote this transformer because I didn't want to use the SourceWriting Transformer hack for doing SOAP call (it is not its function anyway). Since SOAP call is POST request containing XML, I thought of writing a transformer able to do (at least) GET and POST requests. The transformer is useful in many use cases like doing Google search, retrieving stock quotes, post form etc. Beside that, you can specify header-request to pass additional information about the request, and about the client itself, to the server (like cookies). In addition, the transformer supports challenge-response authentication mechanisms (Basic and Digest) which can be used by a server to challenge a client request and by a client to provide authentication information. It also support NTLM authentication. Finally, it uses JTidy for formatting HTML content in XHTML format. You cant do all these stuffs with the CInclude Transformer, unless I misunderstood. I saw a real need on the user mailing list for such a transformer and I thought sharing it with the Cocoon community would be profitable. WDYT? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
Re: [Templates] Summary and Voting aspects
On Dec 8, 2004, at 5:37 AM, Daniel Fagerstrom wrote: You mean defining the language. No one wants to implement. ;-) Actually there are some people around here that prefer programming to discussing. And a few impresive persons who manage to be active in both areas :) A that explains why there is a Cocoon and not just a set of requirements. :-) Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: reaching viewData in a CForms event handler
I have worked around the problem by adding my bizData to the Form as an
Attribute.
We need to decide which to do
fix it if it is broken
update the docs with the proper technique if it does actually work
remove it from the docs if we don't want this functionality
regards Jeremy
On 7 Dec 2004, at 14:28, Jeremy Quinn wrote:
Sorry to bug you guys about this again, but I still have no solution.
According to the docs, I am supposed to have access to BizData sent
with the sendForm function, from within CForms EventHandlers, but
still cannot work out how to do it.
I am using the CForms model in :
resource://org/apache/cocoon/forms/flow/javascript/Form.js
Form.js seems to add the bizData to the ContextObject, but I do not
see how to retrieve it.
Should I be able to do this?
Or is it a bug in the code or the docs?
Thanks for any help
regards Jeremy
On 1 Dec 2004, at 19:29, Jeremy Quinn wrote:
Hi All
A little problem I cannot solve .. and I cannot find any samples
tat do this ..
Part of a form I am working on has a couple of menus.
The menu called 'group' is a list of folders grabbed dynamically from
the filesystem by the flowscript that calls the form.
The menu called 'cid' is set to a list of the files in the folder
chosen in group.
fd:field id=group required=true
. . .
fd:selection-list type=flow-jxpath list-path=groups
value-path=value label-path=label /
fd:on-value-changed
javascript
var value = event.source.value;
var cid = event.source.lookupWidget(../cid);
if (value != null) {
cid.setSelectionList(getComponentFiles(viewData.components,
value), value, label);
} else {
event.source.setValue(null);
cid.setSelectionList(new
Packages.org.apache.cocoon.forms.datatype.EmptySelectionList(...));
}
cid.setValue(null);
/javascript
/fd:on-value-changed
/fd:field
The function getComponentFiles needs the 'components' parameter,
which is the location of the base components folder. It needs to be
passed from a SiteMap parameter, so I have added it to the bizData:
form.showForm(screen, {groups:getComponentGroups(components),
components:components});
I am getting errors similar to this when the form attempts to load:
ReferenceError: viewData is not defined
I have used the viewData value in projects before, in earlier
versions of CForms.
I have tried several variations, but cannot work out the correct way
of getting the bizdata.
viewData.components
viewData[components]
components
etc.
If I make 'components' a global JS variable instead of passing it as
bizData, I can access it fine, but I would prefer not to work that
way ;)
What am I doing wrong?
Thanks for any suggestions.
regards Jeremy
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !
smime.p7s
Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 29360] - [PATCH] precompile xsp's without starting URI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29360. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29360 [EMAIL PROTECTED] changed: What|Removed |Added Summary|precompile xsp's without|[PATCH] precompile xsp's |starting URI|without starting URI --- Additional Comments From [EMAIL PROTECTED] 2004-12-08 14:52 --- This patch allows the precompiling of xsp, but outside of the CocoonBean/CLI. Precompiling without uri scans the context-directory for xsp-files and compiles this with the components from XSP (ProgramGenerator). This was not a crawling through pages like the CocoonBean does. By moving XSP to a block all dependences were removed from org.apache.cocoon.Cocoon org.apache.cocoon.bean.CocoonWrapper/CocoonBean. The patch is a copy and paste of all this removed code in a single class XSPPrecompileWrapper. It depends on the XSP-Block and in this case it is placed in the XSP-Block. A simple extend of the CocoonWrapper is impossible (the needed org.apache.cocoon.Cocoon is private there). So all code from the Wrapper is copy and paste there. The patch is tested with cocoon-2.1.5.1 and cocoon-2.1.6 and works in both. Usage: -- * all classes and jars must be in classpath (servlet.jar too) (Unix: for i in `ls build/webapp/WEB-INF/lib/*.jar`; do export CLASSPATH=$CLASSPATH:$i; done) * java org.apache.cocoon.bean.XSPPrecompileWrapper -c build/webapp -w my_work_dir this will generate all *.java and *.class files to the work-dir. Best Regards, Simon -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
DO NOT REPLY [Bug 29360] - [PATCH] precompile xsp's without starting URI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29360. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29360 --- Additional Comments From [EMAIL PROTECTED] 2004-12-08 14:54 --- Created an attachment (id=13682) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13682action=view) the patch works with patch -p0 patch in the root-dir of the source-dist -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
DO NOT REPLY [Bug 32587] New: - [PATCH] SmbAuthAction
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32587. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32587 Summary: [PATCH] SmbAuthAction Product: Cocoon 2 Version: Current SVN 2.2 Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Authenticates arbitrary user credentials against an NT domain based on the a href=http://jcifs.samba.org/;The Java CIFS Client Library (jCIFS)/a project. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
DO NOT REPLY [Bug 32587] - [PATCH] SmbAuthAction
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32587. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32587 --- Additional Comments From [EMAIL PROTECTED] 2004-12-08 15:03 --- Created an attachment (id=13683) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13683action=view) SmbAuthAction -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
RE: [portal] Need for CachingPortletAdapter
Hi, I got finally into PageLabels that are implemented in portal block in cocoon 2.1.6 and documented at http://wiki.apache.org/cocoon/PortalPageLabels. Ralf Goers wrote on http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110191154925434w=2: Main issue I see in implementing CachingPortletAdapter is link translation. 1.) links that are sent to browser are valid only for the next request 2.) translated links are part of generated content 3.) portlet content cannot be cached since its links will not be valid after next request If you use PageLabels the above is not true. Events are valid until they are regenerated on the next request to that page label. It is not exactly so. Lifecycle of links when using PageLabels is very simmilar to that in the original DefaultEventConverter. They are genereated and stored to ENCODE hashmap in the coplet generation phase and live until the portal tab page is generated again. Links are preserved ONLY when switching form one tagged page to another tagged page. Therefore I refine my statements of issues for implementing CachingPortletAdapter (using PageLabels): 1.) links that are sent to browser are valid only for the next request (unless the tagged page is switched) 2.) translated links are part of generated content 3.) portlet content cannot be cached since its links will not be valid after next request to the same tagged page I have CachingPortletAdapter finished, but I must solve the problem with links to make it working. I see these possibilities: A.) invert the responsibility and let the coplets to maintain lifecycle of their events/links - coplet will add the event to store (EventConverter) on content generation - coplet will remember its own list of its events - coplet will remove its remembered old events from the store when regenerating or removing (logout) - EventConverter will not remove events B.) enhance PageLabelEventConverter and add name of coplet instance to key for events store - currently only page tab name is used for pageLabel parameter i.e. portal?pageLabel=Gallerycocoon-portal-event=3 - after adding coplet instance name the link would look like this portal?pageLabel=Gallery.Gallery-Viewercocoon-portal-event=3 - new events for one coplet now don't replace old events for another coplet on the same page C.) add compare method to event interface - before new event is stored to events store compare new event with old events whether same event not already present in the store - if same event is found between old events it will be returned instead of new on and the link will stay the same (index to store does not change) - gradually all links from portal are stored in the events store but there is no duplicate and the indexes to events are preserved between requests D.) name one :) I find the case A.) is little bit harder to implement but it was my first thought :-) case B.) is nice and clean way how to prevent that events for cached portlet without focus will not be overriden by currently focused coplet case C.) is only one that also allows the browser back button to work properly because repeated http requests will invoke same action as the event will be still alive in the store. Of course, internal coplet states are not taken into account. This simplified view solves only situation when coplet state is maintained exclusivelly through request parameters. I would like to know, if anyone has any preference to one or other solution. Also all cases can have some issues that am not aware of and I would be happy if you could also point them out. Thank you, Michal
Re: happy nikolaus
Torsten Curdt wrote: ...we have auto-compiling javaflow!! snip/ You are now officially *MY* hero. No, wait, you need to allow me to have dynamically autorecompiled sitemap components and at *that* point you are my hero :-) AFAIU, this could easily be done by adding a per-sitemap autocompiling classloader. We could even have per-sitemap lib and src directories. Read BLOCK-INF/lib and BLOCK-INF/src ;-) you volunteering? sounds like that to me? ;o) ...but I am not sure if it's that easy. the container needs to be notified. The roles might have changed and so on. Now, I'm scratching my head thinking of what it would take for you and Pier to get together and try to integrate that into the new kernel... hmmm any idea? ;-) -- Stefano.
RE: [portal] Need for CachingPortletAdapter
Michal, Unfortunately, I have a lot on my plate right now. I'm going to have to do some research to look into your proposals below and so I won't be able to give you my opinion for a few days. But I don't want you to think I am ignoring this. Ralph ÏURDINA Michal said: Hi, I got finally into PageLabels that are implemented in portal block in cocoon 2.1.6 and documented at http://wiki.apache.org/cocoon/PortalPageLabels. Ralf Goers wrote on http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110191154925434w=2: Main issue I see in implementing CachingPortletAdapter is link translation. 1.) links that are sent to browser are valid only for the next request 2.) translated links are part of generated content 3.) portlet content cannot be cached since its links will not be valid after next request If you use PageLabels the above is not true. Events are valid until they are regenerated on the next request to that page label. It is not exactly so. Lifecycle of links when using PageLabels is very simmilar to that in the original DefaultEventConverter. They are genereated and stored to ENCODE hashmap in the coplet generation phase and live until the portal tab page is generated again. Links are preserved ONLY when switching form one tagged page to another tagged page. Therefore I refine my statements of issues for implementing CachingPortletAdapter (using PageLabels): 1.) links that are sent to browser are valid only for the next request (unless the tagged page is switched) 2.) translated links are part of generated content 3.) portlet content cannot be cached since its links will not be valid after next request to the same tagged page I have CachingPortletAdapter finished, but I must solve the problem with links to make it working. I see these possibilities: A.) invert the responsibility and let the coplets to maintain lifecycle of their events/links - coplet will add the event to store (EventConverter) on content generation - coplet will remember its own list of its events - coplet will remove its remembered old events from the store when regenerating or removing (logout) - EventConverter will not remove events B.) enhance PageLabelEventConverter and add name of coplet instance to key for events store - currently only page tab name is used for pageLabel parameter i.e. portal?pageLabel=Gallerycocoon-portal-event=3 - after adding coplet instance name the link would look like this portal?pageLabel=Gallery.Gallery-Viewercocoon-portal-event=3 - new events for one coplet now don't replace old events for another coplet on the same page C.) add compare method to event interface - before new event is stored to events store compare new event with old events whether same event not already present in the store - if same event is found between old events it will be returned instead of new on and the link will stay the same (index to store does not change) - gradually all links from portal are stored in the events store but there is no duplicate and the indexes to events are preserved between requests D.) name one :) I find the case A.) is little bit harder to implement but it was my first thought :-) case B.) is nice and clean way how to prevent that events for cached portlet without focus will not be overriden by currently focused coplet case C.) is only one that also allows the browser back button to work properly because repeated http requests will invoke same action as the event will be still alive in the store. Of course, internal coplet states are not taken into account. This simplified view solves only situation when coplet state is maintained exclusivelly through request parameters. I would like to know, if anyone has any preference to one or other solution. Also all cases can have some issues that am not aware of and I would be happy if you could also point them out. Thank you, Michal
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Leszek Gawron wrote: about 2nd: YAGNI (thanks Stefano for new cool phrase :)) I guess it was Sylvain that introduced me to it, so thank him :-) -- Stefano.
RE: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
http://c2.com/cgi/wiki?YouArentGonnaNeedIt -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 4:53 PM To: [EMAIL PROTECTED] Subject: Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF Leszek Gawron wrote: about 2nd: YAGNI (thanks Stefano for new cool phrase :)) I guess it was Sylvain that introduced me to it, so thank him :-) -- Stefano.
DO NOT REPLY [Bug 32586] - [Patch] Allow ImageReader to process other image formats than JPEG
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32586. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32586 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Allow ImageReader to process|[Patch] Allow ImageReader to |other image formats than|process other image formats |JPEG|than JPEG -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[RT] since we are at it, more irons in the template fire: Xenon
Now, let me tell you a story about templates. My group here at MIT has the same problem with templates. We are currently using velocity, but we are moving our metadata browser (longwell, http://simile.mit.edu/longwell/) to cocoon. The first (and easy porting) solution would be to keep using velocity, but in the longer run, it would be much better to use CTemplate. At the same time, we are in the process of creating a RDF presentation ontology that we call Fresnel (kudos for our friend Mark Butler for the name). You can think of Fresnel as CSS for RDF. Fresnel is supposed to bring some more unity to the force in the space of RDF visualization, work pioneered by some other projecs like the Haystack project at MIT (http://haystack.lcs.mit.edu/), the IsaViz project at W3C (http://www.w3.org/2001/11/IsaViz/), the work by Chris Bizer and his group at the University of Berlin and Longwell itself. Recently, a proposal for an RDF template language was put forth by the original creators of Haystack. It's called Xenon and it's basically XSLT for RDF. Find a copy of the paper here: http://simile.mit.edu/mail/GetAttachment?listName=GeneralmsgId=2687attachId=1 WARNING: this will look at your eyes as extremely weird, but there are a few things inside that I consider valuable, so bear with me. - o - First of all, Xenon is an RDF ontology. If you don't know what that is, you can think at an ontology as a schema for RDF (even if there is no validation!, it just gives you a list of classes and properties that belong to a particular namespace). The above means that, just like XSLT is XML, Xenon is RDF. As a result, you have to use RDF syntaxes (RDF, unlike XML has more than one) to write it. How does that look like? Here is with the N3 syntax: :DefaultNameLens a xe:LensTemplate ; xe:role xe:nameLens ; xe:size xe:inline ; xe:match () ; # Matches everything xe:body [ a xhtml:Text ; xe:body [ a xe:Select ; xe:singleResult true ; xe:filter PREFIX xe: http://haystack.lcs.mit.edu/schemata/xenon# PREFIX dc: http://purl.org/dc/elements/1.1/ SELECT ?TARGET WHERE ($xe:target dc:title ?TARGET) ] ] It is not important here to discuss Xenon per se (if you are curious, read my reply below. http://simile.mit.edu/mail/ReadMsg?listName=GeneralmsgNo=138 but there is definately a few things that are innovative (and came from the Haystack experience) and might be valuable in our current template discussion. - o - The mental model of Xenon is composed of these elements: 1) a template 2) a query language for RDF models 3) higher-level abstractions: lenses and views We match on 1 and that's why I'm talking about ithere: Xenon is not meant to be an 'RDF transformation language' but it's meant to be a way to describe how you should annotate existing RDF with enough presentation information to allow visual browsers to display it and users to interact with it. We match on 2) also, even if the approaches start to diverge: Xenon uses SPARQL (the still-working-draft W3C RDF query language. you can think of it as the alternative of XPath for RDF, since the notion of paths in RDF doesn't apply very well). We do match on 2) even if Xenon names it query language and we name it expression language. Both are a way to identify a particular datum or data in a model (Xenon expects everything to be an RDF model, we expet it to be either a collection of java beans or an XML DOM tree). Note how, in this respect, Xenon is more straightforward since it has only one 'query language' while we have agreed to have at least two (the java-like and the xpath-like). On the other hand, we expect our expression languages to be easy enough for non-programmers to understand, while this is clearly not true for Xenon where writing a single SPARQL query requires extensive knowledge of both RDF and the mental model of querying. In this respect, Xenon is clearly inferior (even with a non-RDF syntax), since no template designer will be able to write a Xenon template. The big difference and the main reason why I brought it up is that Xenon has #3 which is something we might be interested in. - 0 - The haystack project soon realized that there are several ways to look at the same data. They tried to create a model where those views could be reused and applied even to data that was not meant to be displayed that way. Example: you have a calendar view and a collection of events. Pretty straightforward. But then you have a collection of emails, with dates, and you apply the calendar view: result might be, for example, the chronological layout of emails, as they were events. As views represent a way to look at a collection of data, they also realize the need to have single data objects or smaller datasets, as another form of visual granularity. They call
Fwd: Re: JDK 1.3, Forrest and Cocoon Upgrade
Reinhard Poetz wrote: Rick Tessner wrote: Hi all, With the latest cocoon upgrade, I compiled and tested everything using JDK 1.4. Unfortunately if someone is using JDK 1.3 and rebuilds forrest, they run into this issue: http://issues.cocoondev.org/browse/FOR-407 After looking through the cocooon mailing lists, I get the impression that jdk 1.3 is no longer supported for cocoon 2.2 (but is supported for Cocoon 2.1.x). Unfortunately, the @pass-through attribute that we use in the sitemaps for plugins does not currently work under Cocoon 2.1.6. Does someone know for certain what the state of the support for jdk 1.3 is under Cocoon 2.2? AFAIK there was no official vote but I found these mails by Carsten and Sylvain: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109681547626264w=2 Have I missed the vote? -- Reinhard
Re: svn commit: r111272 - /cocoon/trunk/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java /cocoon/trunk/src/java/org/apache/cocoon/components/flow/WebContinuation.java /cocoon/trunk/src/webapp/WEB-INF/cocoon.xconf /cocoon/trunk/status.xml
On 08.12.2004 15:58, [EMAIL PROTECTED] wrote: Author: lgawron Date: Wed Dec 8 06:58:35 2004 New Revision: 111272 URL: http://svn.apache.org/viewcvs?view=revrev=111272 Log: implement 2 modes of work for continuations manager: - standard, as it was up till now - secure in which continuations are bound to session. Only the session that created a continuation can invoke it. All continuations bound to session are invalidated w Modified: cocoon/trunk/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java cocoon/trunk/src/java/org/apache/cocoon/components/flow/WebContinuation.java cocoon/trunk/src/webapp/WEB-INF/cocoon.xconf cocoon/trunk/status.xml - continuations-manager logger=flow.manager time-to-live=360 + continuations-manager logger=flow.manager time-to-live=360 + session-bound-continuations=false + continuation-sharing-bug-compatible=false Can you document it somewhere (inside and outside of cocoon.xconf)? Thanks, Joerg
Re: [RT] since we are at it, more irons in the template fire: Xenon
On Dec 8, 2004, at 11:10 AM, Stefano Mazzocchi wrote: I think we should call our CTemplates taglibs lenses instead. Call them what you will. It doesn't change the core issue. If lenses allow you access databases, send emails, invoke business methods, etc. you still are inviting JSP/XSP like abuse, albeit, syntacticly not as ugly. It is not what you want to use them for, but what they can be used for and how they are introduced into the system that lead to potential problems. That said, lenses as a name would at least not encourage anyone to abuse the system. In that sense, it is superior to taglib. Unfortunately, they would be semantically the same. So here you have my non-voting +1 Using taglibs in the implementation of expression languages makes sense until you start with attribute based languages. Using lenses in the implementation just sounds weird. And here you have my non-voting -1 And another bit about the issue of needing user defined java backed taglibs/lenses: Lenses and views are exactly what I want in order to provide reusability and the building of pages from components. These seem to be micro and mini templates. What is it that you cannot do with a library of jx:macros that causes you to need a full fledged Java object? Glen Ezkovich -- who has to much time on his hands at the moment. HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: Issue with cocoon views -- Using views to debug not really possible?
On 08.12.2004 11:38, Sylvain Wallez wrote: Ok, so cocoon:raw behaves exaclty as the regular cocoon: regarding views. QUESTION What could be the best practice, if I want to look at the XML of a certain pipeline, before its transformation is being called? All I need is a good debugger view for any matcher. I am just wondering why nobody else had this same issue before... The answer with the current view handling is to only use view with final pipelines, i.e. ones that don't rely on cocoon: URLs. Now the question is what behaviour is to be considered correct regarding views and internal pipeline calls. Should we consider that view should be taken into account only for external requests? The current behaviour makes no sense as you can not specify views/labels on the pipeline, but also on the components. Thomas' use case already shows this leads to stupid behaviour as the duplicate usage of a component with @label leads to duplicate usage of view pipe components. IIRC this behaviour also was different, wasn't it? Wasn't only the last view taken into account if it is multiple times in a pipeline? Why should this behaviour different if an internal pipeline is involved? I would not restrict the usage to external requests as we might break usages of that feature - if it is implementable otherwise. Joerg
Re: svn commit: r111272 - /cocoon/trunk/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java /cocoon/trunk/src/java/org/apache/cocoon/components/flow/WebContinuation.java /cocoon/trunk/src/webapp/WEB-INF/cocoon.xconf /cocoon/trunk/status.xml
Joerg Heinicke wrote: On 08.12.2004 15:58, [EMAIL PROTECTED] wrote: Author: lgawron Date: Wed Dec 8 06:58:35 2004 New Revision: 111272 URL: http://svn.apache.org/viewcvs?view=revrev=111272 Log: implement 2 modes of work for continuations manager: - standard, as it was up till now - secure in which continuations are bound to session. Only the session that created a continuation can invoke it. All continuations bound to session are invalidated w Modified: cocoon/trunk/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java cocoon/trunk/src/java/org/apache/cocoon/components/flow/WebContinuation.java cocoon/trunk/src/webapp/WEB-INF/cocoon.xconf cocoon/trunk/status.xml - continuations-manager logger=flow.manager time-to-live=360 + continuations-manager logger=flow.manager time-to-live=360 + session-bound-continuations=false + continuation-sharing-bug-compatible=false Can you document it somewhere (inside and outside of cocoon.xconf)? I have already put some description at ContinuationsManagerImpl javadoc. I will also add some info to cocoon.xconf. Is there any more place to add it? -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [RT] since we are at it, more irons in the template fire: Xenon
Glen Ezkovich said: On Dec 8, 2004, at 11:10 AM, Stefano Mazzocchi wrote: I think we should call our CTemplates taglibs lenses instead. Call them what you will. It doesn't change the core issue. If lenses allow you access databases, send emails, invoke business methods, etc. you still are inviting JSP/XSP like abuse, albeit, syntacticly not as ugly. It is not what you want to use them for, but what they can be used for and how they are introduced into the system that lead to potential problems. Actually, I always thought that taglibs were the good part of JSPs. It is the fact that you can code Java in them that makes them dangerous. If one can control what tag libraries are available and not allow java code in the template then SOC is possible. Of course, a tag library that allows you to code a select statement as a parameter would be awful, but you can't control everything in life. Ralph
DO NOT REPLY [Bug 32266] - [Link] NameOfMyCocoonSite
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32266. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32266 --- Additional Comments From [EMAIL PROTECTED] 2004-12-08 21:22 --- Sorry, Tom, didn't I mention that we are still on document v10? To others, maybe David: Does a mixture harm in any way? Can Forrest handle this? Do we already have the external link feature? Joerg -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
Re: [RT] since we are at it, more irons in the template fire: Xenon
On Wed, 08 Dec 2004 12:10:09 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Now, let me tell you a story about templates. As the sound of the theme music from Beverly Hillbillies rises in the background? snipstory/snip I like the name (and the concept) of lenses. We have identified the need to have isolated and reusable programmatic artifacts that know how to transform something into SAX events. They were named 'taglib' because the syntax normally used to identify them is a namespaced element (a 'tag'). The problem with the name is that it has been used (and abused!) in too many systems and brings memories of abuse and FS. Like the infamous if tag (also abused by XSLT) I think we should call our CTemplates taglibs lenses instead. WDYT? For our internal templating system we're currently implementing a concept we call filters that lets one declaratively define conditional portions of a template/view. As I read your story (:-) I kept thinking that lenses and filters lined up pretty much the same. Then I jumped over to the Xenon description and found a xe:filter as part of the lens description. I won't have time to dissect everything completely, but semantically a lens as used in Xenon seems to be a filter (and filters as used in Xenon seem to be conditionals). If so, I think the idea makes perfect sense, at least for our system However, I'm not quite sure that the lens concept maps exactly to everything that is being discussed WRT Cocoon? In particular, there seems to be more of a active modifier role (ie turn something into SAX events) to what people are looking for for Cocoon? Then again, maybe that's part of the problem and why you like the name lens? I'll also note that if you take the optical analogy literally, you want both lenses and filters working together as separate components and not mixed together the way Xenon seems to do. I wonder if there's some SOC in the view model that really remains to be completely abstracted? I'm not sure lens is an abstraction I find completely understandable... -- Peter Hunsberger
DO NOT REPLY [Bug 32541] - [Patch] HTTPIncludeTransformer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32541 --- Additional Comments From [EMAIL PROTECTED] 2004-12-08 21:28 --- So you have a different use case in mind. But sending one request and including the XML response or doing it multiple times - is it that different? And we have some proxy generators which might also copy much of your functionality. They even use HttpClient too: http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/blocks/proxy/java/org/apache/cocoon/generation/ Ok, this are now generators and not transformers, but maybe we can merge them alltogether to one component (read: not sitemap component) and have both a transformer and a generator using that component. Makes sense? Joerg -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
Re: svn commit: r111272 - /cocoon/trunk/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java /cocoon/trunk/src/java/org/apache/cocoon/components/flow/WebContinuation.java /cocoon/trunk/src/webapp/WEB-INF/cocoon.xconf /cocoon/trunk/status.xml
On 08.12.2004 21:18, Leszek Gawron wrote: - continuations-manager logger=flow.manager time-to-live=360 + continuations-manager logger=flow.manager time-to-live=360 + session-bound-continuations=false + continuation-sharing-bug-compatible=false Can you document it somewhere (inside and outside of cocoon.xconf)? I have already put some description at ContinuationsManagerImpl javadoc. I will also add some info to cocoon.xconf. Is there any more place to add it? I had our real documentation in mind, somewhere in the xdocs if it is appropriate. Ovidiu and Chris have written much about flow and continuations, maybe there is somewhere a place to add it: http://cocoon.apache.org/2.1/userdocs/flow/index.html. Joerg
Re: [RT] since we are at it, more irons in the template fire: Xenon
Glen Ezkovich wrote:
On Dec 8, 2004, at 11:10 AM, Stefano Mazzocchi wrote:
I think we should call our CTemplates taglibs lenses instead.
I like it.
Call them what you will. It doesn't change the core issue. If lenses
allow you access databases, send emails, invoke business methods, etc.
you still are inviting JSP/XSP like abuse, albeit, syntacticly not as
ugly. It is not what you want to use them for, but what they can be used
for and how they are introduced into the system that lead to potential
problems.
Even right now you can call arbitrary Java code in JXTG by simple
jx:set var=ignore value=${Packages.org.apache.cocoon.Foo.bar()/.
You would have to disallow to reference ANY method. In that case the
template language would be very restrictive which I am not that great
fan of.
That said, lenses as a name would at least not encourage anyone to
abuse the system. In that sense, it is superior to taglib.
Unfortunately, they would be semantically the same.
So here you have my non-voting +1
+1. Good name which does not raise wrong emotions.
And another bit about the issue of needing user defined java backed
taglibs/lenses:
Lenses and views are exactly what I want in order to provide reusability
and the building of pages from components. These seem to be micro and
mini templates. What is it that you cannot do with a library of
jx:macros that causes you to need a full fledged Java object?
If talking about proper tag implemenetation (one that does only
allowed actions) probably you could switch to macros. JXTG lacks only
one feature that would make macro system complete: the ability to invoke
a macro which name is resolved by expression. I will create another post
about that.
Still there is one other this that jx:macro is not that suitable for:
convertors. See previous threads for the problem description.
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Issue with cocoon views -- Using views to debug not really possible?
Joerg, thank you for your response. It seems that my problem seems not to be solved with the current version of cocoon. Is this correct? I am wondering if this is a bug or a feature. As a cocoon user I would say this is a MAJOR bug in the view concept or implementation. Should I add this bug to the bugtracker? Cheers, Thomas On 08.12.2004, at 21:18, Joerg Heinicke wrote: On 08.12.2004 11:38, Sylvain Wallez wrote: Ok, so cocoon:raw behaves exaclty as the regular cocoon: regarding views. QUESTION What could be the best practice, if I want to look at the XML of a certain pipeline, before its transformation is being called? All I need is a good debugger view for any matcher. I am just wondering why nobody else had this same issue before... The answer with the current view handling is to only use view with final pipelines, i.e. ones that don't rely on cocoon: URLs. Now the question is what behaviour is to be considered correct regarding views and internal pipeline calls. Should we consider that view should be taken into account only for external requests? The current behaviour makes no sense as you can not specify views/labels on the pipeline, but also on the components. Thomas' use case already shows this leads to stupid behaviour as the duplicate usage of a component with @label leads to duplicate usage of view pipe components. IIRC this behaviour also was different, wasn't it? Wasn't only the last view taken into account if it is multiple times in a pipeline? Why should this behaviour different if an internal pipeline is involved? I would not restrict the usage to external requests as we might break usages of that feature - if it is implementable otherwise. Joerg Schoene Gruesse, Thomas
RE: [RT] since we are at it, more irons in the template fire: Xenon
Hi All, I suspect as this topic is discussed more and more we'll find that many people within the Cocoon community have implemented their own templating / view model. Like Peter, we're using a model based on filters - which are basically dynamically evaluated XPath fragments. The document which holds these fragments is called a skin. The filters are contained within the markup document to be used as the skeleton for the final output. This approach has a couple of advantages: 1. It only operates on the data given it - so there's not a lot of point in trying to mangle it to produce SQL results 2. People writing skins don't need to know the ins and outs of XSLT - the majority of what they involves simple XPath statements. The approach we have taken is as follows: Data Access - RDF (XML) Document generated || SkinData | Document Aggregated (including Skin and Data) | XSLT document applied In our case the same mechanism is used for generating both skin and data component (although for the purposes of this discussion that's not really important.) Xalan is used as the engine for applying the skin's XPath components to the data set provided it. We do this dynamic evaluation by using (unsurprisingly) the dyn:map XSLT extension. The XSLT document which performs this evaluation is surprisingly small (about 200 lines - including a huge number of comments ;) From our perspective this approach gives us all the SOC we need. Having said that, Java calls can still be made (and sometimes are) but these calls operate solely on the data available and don't really encapsulate business logic - they're more calls of convenience. We've been using this model in production for over a year now on an interesting variety of platforms (including Teletext). The majority of the development is being done by web developers with little or no XSLT experience. If there's interest, I'd be happy to provide an example of a skin / data aggregated document. Regards, Corin -Original Message- From: Peter Hunsberger [mailto:[EMAIL PROTECTED] Sent: Thursday, 9 December 2004 9:27 a.m. To: [EMAIL PROTECTED] Cc: SIMILE General Subject: Re: [RT] since we are at it, more irons in the template fire: Xenon On Wed, 08 Dec 2004 12:10:09 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Now, let me tell you a story about templates. As the sound of the theme music from Beverly Hillbillies rises in the background? snipstory/snip I like the name (and the concept) of lenses. We have identified the need to have isolated and reusable programmatic artifacts that know how to transform something into SAX events. They were named 'taglib' because the syntax normally used to identify them is a namespaced element (a 'tag'). The problem with the name is that it has been used (and abused!) in too many systems and brings memories of abuse and FS. Like the infamous if tag (also abused by XSLT) I think we should call our CTemplates taglibs lenses instead. WDYT? For our internal templating system we're currently implementing a concept we call filters that lets one declaratively define conditional portions of a template/view. As I read your story (:-) I kept thinking that lenses and filters lined up pretty much the same. Then I jumped over to the Xenon description and found a xe:filter as part of the lens description. I won't have time to dissect everything completely, but semantically a lens as used in Xenon seems to be a filter (and filters as used in Xenon seem to be conditionals). If so, I think the idea makes perfect sense, at least for our system However, I'm not quite sure that the lens concept maps exactly to everything that is being discussed WRT Cocoon? In particular, there seems to be more of a active modifier role (ie turn something into SAX events) to what people are looking for for Cocoon? Then again, maybe that's part of the problem and why you like the name lens? I'll also note that if you take the optical analogy literally, you want both lenses and filters working together as separate components and not mixed together the way Xenon seems to do. I wonder if there's some SOC in the view model that really remains to be completely abstracted? I'm not sure lens is an abstraction I find completely understandable... -- Peter Hunsberger CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For
JXTG: invoke macro by name from expression
I would like to add one feature to JXTG that would allow not to promote
hacks like [1]. Example:
jx:macro name=fooBar
somecontent/some
/jx:macro
you can only invoke it by fooBar/
If I were able to do jx:invoke macro=fooBar/ I would be able to pass
macro name as a parameter to other macro which allows quite powerful
data injection technique:
jx:macro name=superPrettyPrintedTable
jx:parameter name=headerTemplate/
jx:parameter name=elements/
jx:parameter name=rowTemplate/
!-- fancy code with lots of graphics here --
table
tr
jx:invoke macro=${headerTemplate}/
/tr
jx:forEach var=currentElement
items=elements
varStatus=status
tr
td${status.index}/td
jx:invoke macro=${rowTemplate} element=${currentElement}/
/tr
/jx:forEach
/table
!-- fancy code with lots of graphics there --
/jx:macro
then use the macro like this:
jx:macro name=addressesHeaderTemplate
thCity/ththStreet/th
/jx:macro
jx:macro name=addressRowTemplate
jx:parameter name=address/
td${address.city}/td
td${address.street}/td
/jx:macro
jx:invoke macro=superPrettyPrintedTable
headerTemplate=addressHeaderTemplate
elements=${addresses}
rowTemplate=addressRowTemplate/
WDYT? We could deprecate jx:eval then which is not fully supported as
additional Map structure has to be used as [1] shows.
It does not seem that much coding is needed. I could also strip all
inner classes from JXTG at the same time as the first step for JXTG
refactoring.
[1] http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#eval
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r111272 - /cocoon/trunk/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java /cocoon/trunk/src/java/org/apache/cocoon/components/flow/WebContinuation.java /cocoon/trunk/src/webapp/WEB-INF/cocoon.xconf /cocoon/trunk/status.xml
Joerg Heinicke wrote: On 08.12.2004 21:18, Leszek Gawron wrote: - continuations-manager logger=flow.manager time-to-live=360 + continuations-manager logger=flow.manager time-to-live=360 + session-bound-continuations=false + continuation-sharing-bug-compatible=false Can you document it somewhere (inside and outside of cocoon.xconf)? I have already put some description at ContinuationsManagerImpl javadoc. I will also add some info to cocoon.xconf. Is there any more place to add it? I had our real documentation in mind, somewhere in the xdocs if it is appropriate. Ovidiu and Chris have written much about flow and continuations, maybe there is somewhere a place to add it: http://cocoon.apache.org/2.1/userdocs/flow/index.html. Good point. A TODO for tomorrow. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
RE: JXTG: invoke macro by name from expression
Leszek Gawron wrote: I would like to add one feature to JXTG that would allow not to promote hacks like [1]. Example: jx:macro name=fooBar somecontent/some /jx:macro you can only invoke it by fooBar/ If I were able to do jx:invoke macro=fooBar/ I would be able to pass macro name as a parameter to other macro which allows quite powerful data injection technique: Yes! Functional programming! +100 Though I would suggest jx:call-macro name=fooBar/ which would make it clear that the attribute is the NAME of the macro to be invoked, rather than the macro itself.
Re: JXTG: invoke macro by name from expression
Conal Tuohy wrote: Leszek Gawron wrote: I would like to add one feature to JXTG that would allow not to promote hacks like [1]. Example: jx:macro name=fooBar somecontent/some /jx:macro you can only invoke it by fooBar/ If I were able to do jx:invoke macro=fooBar/ I would be able to pass macro name as a parameter to other macro which allows quite powerful data injection technique: Yes! Functional programming! +100 Though I would suggest jx:call-macro name=fooBar/ which would make it clear that the attribute is the NAME of the macro to be invoked, rather than the macro itself. That's good. If noone objects I will start tomorrow and hopefully commit tomorrow. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [RT] since we are at it, more irons in the template fire: Xenon
Le 8 déc. 04, à 22:03, Corin Moss a écrit : ...If there's interest, I'd be happy to provide an example of a skin / data aggregated document... Would you be able to package a small sample that we could add to the scratchpad? It might be interesting to have a live comparison of all these things that are being discussed these days (at least those that actually exist ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: Re: JDK 1.3, Forrest and Cocoon Upgrade
On Mie, 8 de Diciembre de 2004, 12:52, Reinhard Poetz dijo: AFAIK there was no official vote but I found these mails by Carsten and Sylvain: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109681547626264w=2 Have I missed the vote? I don't wrote this ;-) http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107821710911262w=2 Follow the thread and seems we had an agreement. :-D Best Regards, Antonio Gallardo
Re: [RT] since we are at it, more irons in the template fire: Xenon
On Dec 8, 2004, at 2:22 PM, Ralph Goers wrote: Glen Ezkovich said: On Dec 8, 2004, at 11:10 AM, Stefano Mazzocchi wrote: I think we should call our CTemplates taglibs lenses instead. Call them what you will. It doesn't change the core issue. If lenses allow you access databases, send emails, invoke business methods, etc. you still are inviting JSP/XSP like abuse, albeit, syntacticly not as ugly. It is not what you want to use them for, but what they can be used for and how they are introduced into the system that lead to potential problems. Actually, I always thought that taglibs were the good part of JSPs. It is the fact that you can code Java in them that makes them dangerous. I stand corrected. Its the html that is the bad part. ;-) Tags are good in the sense that they offer encapsulation and thus promote reusability. What exactly is the difference if I encapsulate my java code in a tag or in a method? Mainly usability. It is easier for a non-programer to use tags then invoke methods. Ultimately it comes down to a method invocation. There is just one more level of indirection. The point I attempted to make was that a template should be a template and not a controller or an entryway for model manipulation. JSP is MV and C. A template engine should just fill in the blanks with provided data with the assistance of metadata if necessary. As a bonus it would be nice to have some form of encapsulation where a template could be built out of other templates. If one can control what tag libraries are available and not allow java code in the template then SOC is possible. unfortunately if we want to get data out of java objects we have to allow some code. Of course, a tag library that allows you to code a select statement as a parameter would be awful, but you can't control everything in life. And again you are right, you can't control everything. What you can do is limit how tags are introduced into the system. If taglibs are introduced by just adding a declaration in the template they are more likely to be abused then requiring them to be part of component configuration. They would be even fewer cases of abuse if one had to add the taglibs at compile time. I think it is reasonable to ask who is making the decisions on including the libraries and how easy does it have to be to add the libraries. I really don't have a problem with taglibs. I don't even have a problem with the name. ;-) All I would like is for the community to consider the ramifications. I know that no one who works with me will get away with doing something so egregious as using a taglib that allows select statements as a parameter. In the end that is all I care about. On a large project, I would like some way other then threats, to prevent my people from using such a library. Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
how to list all sitemap components
I am trying to create a list of all sitemap components in the Cocoon core and blocks. So far i have tried to use 'find and grep' by looking for well-known filenames, e.g. *Transformer.java and also searching in well-known directories, e.g. /transformation/ However, that misses some components and gets too much extra stuff. Using the package name inside the *.java also misses some components. Is there a way to uniquely identify the sitemap components by grepping the *.java e.g. perhaps a unique method name? --David
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Antonio Gallardo wrote: On Mie, 8 de Diciembre de 2004, 5:47, [EMAIL PROTECTED] dijo: Author: lgawron Date: Wed Dec 8 03:47:12 2004 New Revision: 111262 URL: http://svn.apache.org/viewcvs?view=revrev=111262 ... cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf --- cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf(original) +++ cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconfWed Dec 8 03:47:12 2004 @@ -1,4 +1,4 @@ -?xml version=1.0 encoding=UTF-8? +?xml version=1.0 encoding=UTF-8? ^ | What is that? Please, be carefull next time. :-D Best Regards, Antonio Gallardo. This is BOM (byte ordering mark). It is being written by some of xml editors to the beginning of the multibyte encoded (i.e. utf-8) xml file. The file I commited is a valid xml. Check in any xml editor/browser. The question is do we allow BOMs in xml files? If not I will have to look for a way to disable the feature for cocoon files. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
[RT] MVC Contexts (Was Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?))
This one is long folks. Sorry, can't be helped. Sylvain Wallez wrote: Stefano Mazzocchi wrote: Sure, but the question is: once the syntax starts to get ugly for both because of changes we made to the language that make sense only on transformation and not on generation, would it still be the case? remember that the generation stage has a scripted population stage first, the transformation stage does not! I don't see this distinction: if you look at the global processing chain, there is always a population stage in front of the template engine: 1/ template as a generator ++ +---+ + Flowscript |--(objects)--| Template | ... + data | | generator | ++ +---+ ^ | Template file 2/ template as a transformer +---+ +-+ | Generator |--(xml data)--| Template | ... | | | transformer | +---+ +-+ ^ | Template file Where is the difference? The template lays out some data. In the case of the generator, it's controller-provided data, in the case of the transformer, it's pipeline-produced data. Note that is not limited to a generator, but can also be aggregation, prior transformation, etc, or even some preliminary processing of some controller-provided data. snip/ Is this indeed the case? The flow data is, strictly speaking in this case, the model? The template *may or may not* follow the flow data structure closely. In fact, the flow data is merely a hint or an indicator. The template file has the final say on the data structure. You can send the exact same flow data via sendPage* to two different JXTG template pipelines and get functionally different XML structures (depending on which objects are accessed and how). MVC contexts. That's my new buzzword for the day. When you pull an RSS feed from another site for inclusion in your own site, what is that RSS feed to you? A model right? But to the remote site, the RSS is a view (to a remote database for example), not a model. It's the final form for others to use. But it's still RSS data isn't it? How can it be both a model and a view? Because it's used in a different context. The web browser is the same thing. To Cocoon, HTML is absolutely the view. But to a web browser, it's the model. The HTML renderer+CSS is the view, and the client-side Javascript is clearly the controller. Isn't this all true and MVC is actually dependant upon the scope of the problem at hand. In a high-level view of Cocoon, the model is the object model (Hibernate et al.), the view is the pipeline, and the controller is Flow. But what is a generator in a pipeline? The model? But the model from Cocoon came from Flow? But the pipeline is under no obligation to use that data from Flow. It can use a subset of that data, iterate a data structure multiple times or ignore the data altogether. In addition, it has access to data that Flow didn't give it (Actions). So while it is the view for Cocoon at large, it is in fact it's own MVC context that grabs data as needed just as a client-side Javascript can grab updated information from the server without refreshing the main page (GMail). Who decides if that data is to be used? The pipeline logic as controller. (Ack!) The generator determines which template to use. In the case of JXTG, it loads the template file *and* injects data. The difference between displaying a template file raw or with data is the choice of pipeline components in the sitemap, not Flow. Flow can only produce it's view of the working data set and request a particular pipeline that presumably would put that data structure to good use. The pipeline is the controller here. A browser makes separate requests for the HTML, Javascript files and CSS stylesheets to produce the final view for your pleasure. You don't see the MVC in a browser, you see the result of the MVC, the view. Wasn't this the entire point of the last ten years of the W3C? To specify HTML as a model, Javascript as a controller and CSS as a view? In a different MVC context of course. ;-) So in a pipeline MVC context you have a model, the inital XML (static or a template) that determines the initial structure of the data events (generating SAX events where there previously were none), the controller with modular logic (pipeline-specified transformers and actions), and the serializer as view (what the outside world sees). Cocoon had MVC before the advent of Flow. It simply had a single complete MVC context. Flow gave rise to a new concept I've heard on this list repeatedly, MVC+. But are we really defining M, V, C and some new, unnamed
[GUMP@brutus]: Project cocoon-block-poi (in module cocoon) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-poi *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-poi/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [poi-block.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/cocoon/cocoon-block-poi/gump_work/build_cocoon_cocoon-block-poi.html Work Name: build_cocoon_cocoon-block-poi (Type: Build) Work ended in a state of : Success Elapsed: 6 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=08122004 -Dblock-name=poi gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[GUMP@brutus]: Project cocoon-block-webdav (in module cocoon) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-webdav *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-webdav/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [webdav-block.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/cocoon/cocoon-block-webdav/gump_work/build_cocoon_cocoon-block-webdav.html Work Name: build_cocoon_cocoon-block-webdav (Type: Build) Work ended in a state of : Success Elapsed: 8 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=08122004 -Dblock-name=webdav gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[GUMP@brutus]: Project cocoon-block-slide (in module cocoon) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-slide *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-slide/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [slide-block.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/cocoon/cocoon-block-slide/gump_work/build_cocoon_cocoon-block-slide.html Work Name: build_cocoon_cocoon-block-slide (Type: Build) Work ended in a state of : Success Elapsed: 6 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=08122004 -Dblock-name=slide gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
RE: JXTG: invoke macro by name from expression
On Mie, 8 de Diciembre de 2004, 15:17, Conal Tuohy dijo: Leszek Gawron wrote: Though I would suggest jx:call-macro name=fooBar/ which would make it clear that the attribute is the NAME of the macro to be invoked, rather than the macro itself. +1 here. But please keep in mind we need still support the old ways. We need to deprecate and later remove the old support. That is the way to keep contracts working with current users. :-D Best Regards, Antonio Gallardo
DO NOT REPLY [Bug 32266] - [Link] NameOfMyCocoonSite
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32266. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32266 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
Re: JXTG: invoke macro by name from expression
On Dec 8, 2004, at 3:04 PM, Leszek Gawron wrote:
I would like to add one feature to JXTG that would allow not to
promote hacks like [1]. Example:
jx:macro name=fooBar
somecontent/some
/jx:macro
you can only invoke it by fooBar/
If I were able to do jx:invoke macro=fooBar/ I would be able to
pass macro name as a parameter to other macro which allows quite
powerful data injection technique:
jx:macro name=superPrettyPrintedTable
jx:parameter name=headerTemplate/
jx:parameter name=elements/
jx:parameter name=rowTemplate/
!-- fancy code with lots of graphics here --
table
tr
jx:invoke macro=${headerTemplate}/
/tr
jx:forEach var=currentElement
items=elements
varStatus=status
tr
td${status.index}/td
jx:invoke macro=${rowTemplate} element=${currentElement}/
/tr
/jx:forEach
/table
!-- fancy code with lots of graphics there --
/jx:macro
then use the macro like this:
jx:macro name=addressesHeaderTemplate
thCity/ththStreet/th
/jx:macro
jx:macro name=addressRowTemplate
jx:parameter name=address/
td${address.city}/td
td${address.street}/td
/jx:macro
jx:invoke macro=superPrettyPrintedTable
headerTemplate=addressHeaderTemplate
elements=${addresses}
rowTemplate=addressRowTemplate/
WDYT? We could deprecate jx:eval then which is not fully supported as
additional Map structure has to be used as [1] shows.
It does not seem that much coding is needed. I could also strip all
inner classes from JXTG at the same time as the first step for JXTG
refactoring.
Sounds good to me. a non-voting +1
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com
A Proverb for Paranoids:
If they can get you asking the wrong questions, they don't have to
worry about answers.
- Thomas Pynchon Gravity's Rainbow
DO NOT REPLY [Bug 32266] - [Link] NameOfMyCocoonSite
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32266. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32266 --- Additional Comments From [EMAIL PROTECTED] 2004-12-09 05:27 --- Fixed - attached v10. No external-reference attributes are needed for this version. Are there additional sites you'd like me to add to this? HTH, Tom -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Le 9 déc. 04, à 01:03, Leszek Gawron a écrit : ... +?xml version=1.0 encoding=UTF-8? ... This is BOM (byte ordering mark). It is being written by some of xml editors to the beginning of the multibyte encoded (i.e. utf-8) xml file. The file I commited is a valid xml. Check in any xml editor/browser... BOM has no meaning for UTF-8, see http://www.unicode.org/unicode/faq/utf_bom.html#BOM It is certainly better *not* to use it, to avoid any confusion. On unixish OSes, many tools check the first four bytes of a file and expect them to be ?xm -Bertrand smime.p7s Description: S/MIME cryptographic signature
Can't stop validation of links
Hi all: I am not a member of this mailing list, so please include my BEA address in any responses. I am trying to override Forrest's default validation behavior when it comes to links. In particular I am trying to skip validation of links that include the string reference: netui label=Page Flow Javadoc href=reference/classref_pageflows/index.html/ netui label=lt;netui Tags href=reference/taglib/index.html/ I have used two techniques: (1) I have tried to set the property forrest.validate=false But when I run forrest -v I see this in the build echoes: validation-props: Override ignored for property forrest.validate Is there something else I need to do to make the override stick? (2) I have also tried creating the file: src\documentation\conf\cli.xconf and adding the element exclude pattern=**reference**/ But that fails too. Any suggestions would be appreciated. Thanks, Steve Hanson, The Apache Beehive Project.
Re: Fwd: Re: JDK 1.3, Forrest and Cocoon Upgrade
Antonio Gallardo wrote: On Mie, 8 de Diciembre de 2004, 12:52, Reinhard Poetz dijo: AFAIK there was no official vote but I found these mails by Carsten and Sylvain: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109681547626264w=2 Have I missed the vote? I don't wrote this ;-) maybe my second ego (I think Bertrand already got acquainted with him ...) ;-) http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107821710911262w=2 Follow the thread and seems we had an agreement. :-D Here the missing summary: +1 : Antonio, Stefano, Unico, Bruno -0.5: Ugo, Jörg, Leo (nb), Reinhard, Pier People who voted with -0.5 were not against 1.4 but said that this really needs a good usecase that can only be implemented (easily) with 1.4 and not with 1.3. Not to end in a chicken-egg-situation, we agreed that 1.4 is the minimum for 2.2 for now. When we are ready to release Cocoon 2.2 we will look through the code of Cocoon _core_ and if there is no major blocker we will support 1.3 again, if this is not possible, 1.4 will remain the minimum. -- Reinhard
Re: Fwd: Re: JDK 1.3, Forrest and Cocoon Upgrade
On Jue, 9 de Diciembre de 2004, 1:26, Reinhard Poetz dijo: Antonio Gallardo wrote: On Mie, 8 de Diciembre de 2004, 12:52, Reinhard Poetz dijo: AFAIK there was no official vote but I found these mails by Carsten and Sylvain: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109681547626264w=2 Have I missed the vote? I don't wrote this ;-) maybe my second ego (I think Bertrand already got acquainted with him ...) ;-) :-D http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107821710911262w=2 Follow the thread and seems we had an agreement. :-D Here the missing summary: +1 : Antonio, Stefano, Unico, Bruno -0.5: Ugo, Jörg, Leo (nb), Reinhard, Pier People who voted with -0.5 were not against 1.4 but said that this really needs a good usecase that can only be implemented (easily) with 1.4 and not with 1.3. Not to end in a chicken-egg-situation, we agreed that 1.4 is the minimum for 2.2 for now. When we are ready to release Cocoon 2.2 we will look through the code of Cocoon _core_ and if there is no major blocker we will support 1.3 again, if this is not possible, 1.4 will remain the minimum. Doing the maths, the vote was in favor of 1.4. :-D Seriously, I understand the concerns at that time (9 months ago). The user's POLL showed that most of them are using 1.4: http://marc.theaimsgroup.com/?t=10782168692r=1w=2 I just found 1 vote against and the reasons was not so good to me: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=107831280121346w=2 Because I guess SAP already (or soon will) ship a new version supporting 1.4 I read some time ago, that Sun will not release newer version for 1.3 and 1.4. Maybe that was only a rumor. Not sure, but the problem is that open bugs in older JVM will remain open forever. The complexity for us (committers) is a little bit hard: 2 branches: 1-with 3 JVM (1.3, 1.4 and 1.5) 2-with 2 JVM (1.4 and 1.5). In short 5 compilations of cca. 10 minuts each one to check changes! This is the current situation. :-( In any case: Do you think we need a new vote again? :-) Best Regards, Antonio Gallardo.
