RE: Re: About recent commits to 2_1_X
Minimum Java version is now 1.6.
That's the version needed for POI 3.14.
It also solves a (mainly academic) issue in the XSP block.
Still the question whether we shouldn't go straight to 1.8.
It's frustrating to develop and then fail the build on Jenkins.
I doubt that anyone bothering to upgrade Cocoon wouldn't want to go to a more
recent JDK.
Cheers, Alfred.
-Original Message-
From: Cédric Damioli
Sent: Mittwoch, 20. Februar 2019 19:56
To: dev@cocoon.apache.org
Subject: [External Sender] Re: About recent commits to 2_1_X
I'm a bit lost here :)
After your recent commits, what is now the minimum Java version : 1.5,
1.6, 1.8 ?
Cédric
Le 19/02/2019 à 12:25, Nathaniel, Alfred a écrit :
> Thanks, it was quite a long shot to develop on Java 8 and then Jenkins on 1.5.
>
> -Original Message-
> From: Francesco Chicchiriccò
> Sent: Dienstag, 19. Februar 2019 12:10
> To: dev@cocoon.apache.org
> Subject: [External Sender] Re: About recent commits to 2_1_X
>
> FYI I have just updated the job to run with JDK 1.6 (it used to be 1.5).
>
> Now it seems to be back working, cool!
>
> Regards.
>
> On 19/02/19 11:36, Nathaniel, Alfred wrote:
>> Yes, that's me although I don't know this error came into being.
>> Must be a time bomb set off by a deeper recompile.
>> I'll put in a fix.
>>
>> Cheers, Alfred.
>>
>> -Original Message-
>> From: Francesco Chicchiriccò
>> Sent: Dienstag, 19. Februar 2019 08:42
>> To: dev@cocoon.apache.org
>> Subject: [External Sender] About recent commits to 2_1_X
>>
>> Hi guys,
>> glad to see some activity raising again in the old roots for 2_1_X;
>> please take care of what Jenkins says about that:
>>
>> https://builds.apache.org/view/A-D/view/Cocoon/job/Cocoon%202.1.X/
>>
>> Recent builds seem to fail due to error
>>
>> compile-core:
>> Compiling 461 source files to
>> /home/jenkins/jenkins-slave/workspace/Cocoon
>> 2.1.X/BRANCH_2_1_X/build/cocoon/classes
>> /home/jenkins/jenkins-slave/workspace/Cocoon
>> 2.1.X/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java:665:
>> unreported exception org.apache.regexp.RESyntaxException; must be caught
>> or declared to be thrown
>> REProgram encodingRE = new
>> RECompiler().compile("^.*encoding\\s*=\\s*([^\\s]*)");
>> ^
>> Note: Some input files use or override a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> 1 error
>>
>> BUILD FAILED
>> /home/jenkins/jenkins-slave/workspace/Cocoon
>> 2.1.X/BRANCH_2_1_X/tools/targets/compile-build.xml:68: The following
>> error occurred while executing this line:
>> /home/jenkins/jenkins-slave/workspace/Cocoon
>> 2.1.X/BRANCH_2_1_X/tools/targets/compile-build.xml:51: Compile failed;
>> see the compiler error output for details.
>>
>> I have also re-enabled notifications to c...@cocoon.apache.org, hope it's
>> working now.
>>
>> Regards.
>>
--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org
The content of this e-mail is intended only for the confidential use of the
person addressed.
If you are not the intended recipient, please notify the sender and delete this
email immediately.
Thank you.
RE: Re: About recent commits to 2_1_X
Thanks, it was quite a long shot to develop on Java 8 and then Jenkins on 1.5.
-Original Message-
From: Francesco Chicchiriccò
Sent: Dienstag, 19. Februar 2019 12:10
To: dev@cocoon.apache.org
Subject: [External Sender] Re: About recent commits to 2_1_X
FYI I have just updated the job to run with JDK 1.6 (it used to be 1.5).
Now it seems to be back working, cool!
Regards.
On 19/02/19 11:36, Nathaniel, Alfred wrote:
> Yes, that's me although I don't know this error came into being.
> Must be a time bomb set off by a deeper recompile.
> I'll put in a fix.
>
> Cheers, Alfred.
>
> -Original Message-
> From: Francesco Chicchiriccò
> Sent: Dienstag, 19. Februar 2019 08:42
> To: dev@cocoon.apache.org
> Subject: [External Sender] About recent commits to 2_1_X
>
> Hi guys,
> glad to see some activity raising again in the old roots for 2_1_X;
> please take care of what Jenkins says about that:
>
> https://builds.apache.org/view/A-D/view/Cocoon/job/Cocoon%202.1.X/
>
> Recent builds seem to fail due to error
>
> compile-core:
> Compiling 461 source files to
> /home/jenkins/jenkins-slave/workspace/Cocoon
> 2.1.X/BRANCH_2_1_X/build/cocoon/classes
> /home/jenkins/jenkins-slave/workspace/Cocoon
> 2.1.X/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java:665:
> unreported exception org.apache.regexp.RESyntaxException; must be caught
> or declared to be thrown
> REProgram encodingRE = new
> RECompiler().compile("^.*encoding\\s*=\\s*([^\\s]*)");
> ^
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 error
>
> BUILD FAILED
> /home/jenkins/jenkins-slave/workspace/Cocoon
> 2.1.X/BRANCH_2_1_X/tools/targets/compile-build.xml:68: The following
> error occurred while executing this line:
> /home/jenkins/jenkins-slave/workspace/Cocoon
> 2.1.X/BRANCH_2_1_X/tools/targets/compile-build.xml:51: Compile failed;
> see the compiler error output for details.
>
> I have also re-enabled notifications to c...@cocoon.apache.org, hope it's
> working now.
>
> Regards.
>
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
The content of this e-mail is intended only for the confidential use of the
person addressed.
If you are not the intended recipient, please notify the sender and delete this
email immediately.
Thank you.
RE: About recent commits to 2_1_X
Yes, that's me although I don't know this error came into being.
Must be a time bomb set off by a deeper recompile.
I'll put in a fix.
Cheers, Alfred.
-Original Message-
From: Francesco Chicchiriccò
Sent: Dienstag, 19. Februar 2019 08:42
To: dev@cocoon.apache.org
Subject: [External Sender] About recent commits to 2_1_X
Hi guys,
glad to see some activity raising again in the old roots for 2_1_X;
please take care of what Jenkins says about that:
https://builds.apache.org/view/A-D/view/Cocoon/job/Cocoon%202.1.X/
Recent builds seem to fail due to error
compile-core:
Compiling 461 source files to
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/build/cocoon/classes
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java:665:
unreported exception org.apache.regexp.RESyntaxException; must be caught
or declared to be thrown
REProgram encodingRE = new
RECompiler().compile("^.*encoding\\s*=\\s*([^\\s]*)");
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/tools/targets/compile-build.xml:68: The following
error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/tools/targets/compile-build.xml:51: Compile failed;
see the compiler error output for details.
I have also re-enabled notifications to c...@cocoon.apache.org, hope it's
working now.
Regards.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
The content of this e-mail is intended only for the confidential use of the
person addressed.
If you are not the intended recipient, please notify the sender and delete this
email immediately.
Thank you.
RE: [DISCUSS] Set minimum JDK version to 1.5 for Cocoon 2.1
+1 but I would go straight to 6, 7, or even 8. Past experience is that it is a real nuisance trying to support an ancient JDK no developer is actually using anymore. Cheers, Alfred. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 7. Oktober 2016 11:46 To: dev@cocoon.apache.org Subject: [DISCUSS] Set minimum JDK version to 1.5 for Cocoon 2.1 Hi all, as recently noticed during the (unfortunately rejected) patch for COCOON-2354 [1], it might make sense to upgrade the current minimum JDK requirement for Cocoon 2.1 from 1.4 to 1.5, mainly to ease some upgrades and help Cocoon 2.1 living in the modern world. Besides 3rd part library updates, some work could be needed to upgrade our Java code, so help would be appreciated. WDYT? Regards. [1] https://lists.apache.org/thread.html/c03a2390ddd45b801a25e9946a49276693652870f4f4fbe732d8@%3Cdev.cocoon.apache.org%3E -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/ The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this email immediately. Thank you.
RE: Doubt about file upload in Cocoon 2.2
Hi Miguel, In a file upload request, there is no length indicator which would allow to detect oversized files immediately. The file data is embedded with a special multipart encoding in the normal HTTP request stream. There may be more requests following in the same persistent HTTP connection. Therefore one is obliged to drain the data from the request stream even for only throwing it away. HTH, Alfred. From: Miguel [mailto:miguel.valen...@juntadeandalucia.es] Sent: Donnerstag, 6. Juni 2013 14:24 To: dev@cocoon.apache.org Subject: Doubt about file upload in Cocoon 2.2 Hi At present, I work on project based on cocoon 2.2 and I want to use file upload option to send an email with cocoon. Documentation of cocoon indicates about the parameters: org.apache.cocoon.uploads.enable=true org.apache.cocoon.uploads.autosave=true org.apache.cocoon.uploads.maxsize=1000 The last parameter is very interesting because limit the size of files to upload the platform, so I think cocoon would be safe if people try upload ver big files. I have checked that the MultipartParser java class manage this upload process, but it seems that the file is readed fully although size of file is higher than parameter maxsize, ¿it is correct this behaviour? After debugging MultipartParser class, I see the process is: 1) if (oversized) , so if size of file is higher than parameter maxsize, then it is created object out = new NullOutputStream(); 2) stream of file is readed and put into object out, and variable lenght is size of readed content. 3) if (oversized) then it is created object RejectedPart. I don't understand because read full file if in this case always it's created RejectedPart object. it's necesary length variable for RejectedPart object?. if at the begining of process you know content length of file and this number is higher of limit then it's better option not read file and create RejectedPart object with length = 0, isn't it?. Maybe, I don't know source of cocoon fully, and I am wrong. Issue COCOON-1109https://issues.apache.org/jira/browse/COCOON-1109, is about this same topic, but is closed because bug may be invalid. Anybody can explain me. thanks The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this email immediately. Thank you.
RE: REST view and weird error
Wild guess: somewhere you add the map to itself
map.put(map, map);
creating an infinite recursion in map.toString().
HTH, Alfred.
-Original Message-
From: Robby Pelssers [mailto:robby.pelss...@nxp.com]
Sent: Freitag, 22. Februar 2013 11:54
To: dev@cocoon.apache.org
Subject: RE: REST view and weird error
Hi Thorsten,
Just one question.
I'm a making a few assumptions here but is Settings not a HashMap already?
Can't you just do
@Override
public RestResponse doGet() throws Exception {
return new URLResponse(VIEW, getProps());
}
I don't see the point in putting a hashmap in another hashmap just for the sake
of it ;-)
Robby
-Original Message-
From: Thorsten Scherler [mailto:scher...@gmail.com]
Sent: Friday, February 22, 2013 10:13 AM
To: dev@cocoon.apache.org
Subject: REST view and weird error
Hi all,
in one view of a REST service of mine I get:
SLF4J: Failed toString() invocation on an object of type [java.util.HashMap]
java.lang.StackOverflowError
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:639)
at java.lang.StringBuilder.append(StringBuilder.java:224)
at
org.apache.cocoon.configuration.MutableSettings.toString(MutableSettings.java:312)
at java.lang.String.valueOf(String.java:2902)
...
at java.lang.StringBuilder.append(StringBuilder.java:128)
at java.util.AbstractMap.toString(AbstractMap.java:523)
at java.lang.String.valueOf(String.java:2902)
where the last 3 lines will repeat a lot till the end.
I am doing:
@Override
public RestResponse doGet() throws Exception {
HashMapString, Object data = new HashMapString, Object();
data.put(properties, getProps());
return new URLResponse(VIEW, data);
}
where getProps() basically is a helper for getting this.settings.getProperties.
As soon I do return new URLResponse(VIEW) the error is gone.
I have the standard logging activated (via rcl-config), using jetty:run and no
override for es.codebusters.droids.rest.DroidsInvoker in my logback.xml
root
level value=WARN/
appender-ref ref=CORE/
/root
Any ideas?
salu2
--
Thorsten Scherler scherler.at.gmail.com codeBusters S.L. - web based systems
consulting, training and solutions
http://www.codebusters.es/
The content of this e-mail is intended only for the confidential use of the
person addressed.
If you are not the intended recipient, please notify the sender and delete this
email immediately.
Thank you.
RE: [VOTE] Javier Puerto as cocoon committer
+1 Cheers, Alfred. -Original Message- From: Thorsten Scherler [mailto:thors...@apache.org] Sent: Montag, 28. Mai 2012 10:26 To: dev@cocoon.apache.org Subject: [VOTE] Javier Puerto as cocoon committer I propose Javier Puerto as a new Cocoon committer and PMC member. Connect to our new co-location service and benefit from the low latency and high capacity of X-stream INET by Nasdaq OMX, the worlds most advanced trading technology. www.six-swiss-exchange.com/trading The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this email immediately. Thank you.
RE: Website management [WAS Re: resurrect the Cocoon documentation]
I am also for (2) although I can't promis much help. I think moving the docs to a CMS was one of the big mis-decisions of C2. The wishful thinking was that non-developers would come forward to improve the documentation which were before discouraged by the xdoc and svn. Sad reality was that the CMS created an extra threshold for any documentation update that it almost completely stopped. We should come back to where code and doc changes can be committed and published together. One major improvement over the past scheme would be if doc changes could be previewed live without a build cycle. Cheers, Alfred. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 16. März 2012 10:46 To: dev@cocoon.apache.org Subject: Website management [WAS Re: resurrect the Cocoon documentation] Hi all, yesterday, while looking at cocoon.zones.apache.org, I've spent some time at our website, and the e-mail below came into my mind. I believe we should act in this respect as soon as possible, since our outdated website is all but attractive and informative: think only that every page reports Errors and Improvements? If you see any errors or potential improvements in this document please help us: View, Edit or comment on the latest development version (registration required). pointing to a non-existing Daisy instance. Taking the attached e-mail into account, I think we should choose whether: 1. try to resurrect a Daisy instance in our jail - with Betrand's help / manage somehow 2.1 docs with forrest; 2. use Cocoon to parse existing HTML files (for C2.2 and C2.1) and generate a bunch of xdoc/apt files that will serve as a basis for managing a whole maven / svnsubpub based website (like as we're currently doing for C3); 3. use Apache CMS and try to import all existing documentation (including C3's, in this case) - as suggested by David in the e-mail below; I am for (2) and can spend some time for this, with some other volunteer, of course ;-) WDYT? Regards. On 16/01/2012 14:21, David Crossley wrote: TL;DNR Use the Apache CMS for at least our top-level docs and the stalled 2.1 and 2.2 docs. However, i cannot actually do this work, just explain and guide. I have done some background research to try to gather the various past threads and docs. Perhaps this will help us to bring the Cocoon documentation back to life. In the past we had the sources for the docs in xml format and then processed by Apache Forrest to generate the html pages. A few years ago we moved to using the Daisy CMS to store/edit all content for 2.1 and 2.2 versions, as well as the top-level project non-version-specific stuff. For Cocoon-2.2, and the top-level stuff, the Maven site plugin extracted the content from Daisy and generated the html pages. [4] For Cocoon-2.1, the Forrest plugin Daisy input plugin extracted the content from Daisy and generated the html pages. [5] For Cocoon-3, the source content is stored in xml files and the Maven site plugin generates the html pages. All generated html was (and still is) committed to the Cocoon site SVN [1]. Then 'svn up' on the people.apache.org machine does the publishing step. (Later that step could move to using svnpubsub.) The Daisy server operated on our Zones machine cocoon.zones.apache.org (which also housed the demonstrations for Cocoon 2.1 and 2.2). The Zones server is managed by the Cocoon project. See [2]. However, the machine that provided the zones for a set of projects needed to be upgraded. The Cocoon project did not move our services in time. IIRC we do now have a freebsd jail which is basically configured, but not yet re-installed Daisy or Cocoon demo examples, nor the web server. IIRC we did get a backup of the Daisy data [3] if that helps. The Forrest forrestbot neededi to be turned off, as it could not access the source content for the 2.1 documentation. For the 2.2 documentation, i presume that Maven also has troubles. So unless someone can re-instate the new cocoon.zones.apache.org and the Daisy server, then we need some other solution. Suggestion to use the Apache CMS: One other solution would be to use the new Apache CMS. [7] It can have source content in either Markdown format or in HTML format and perhaps others. To resurrect the content, we might be able to use the last published generated set of html documents, strip off the outer headers and menu stuff, replace with basic header, and use that set of content to seed the CMS. (Some of these resources are only available to Cocoon PMC members.) [1] http://svn.apache.org/repos/asf/cocoon/site/site/ [2] https://svn.apache.org/repos/private/pmc/cocoon/cocoon.zones.apache.org/ [3] Search the PMC archive for various email from Bertrand [4] http://cocoon.apache.org/1418_1_1.html How to publish docs to cocoon.apache.org (i.e. for Cocoon-2.2 and the top-level of c.a.o) [5]
RE: [C3] new pipeline component: variabelExpander
Hi Simone,
Why this special API call to add it to the pipeline?
I think is should be a regular transformer you can add any number of time
wherever you need it:
VariableExpander expander = new VariableExpander();
expander.addProperty( build.base, /Users/cocoon );
expander.addProperty( build.home, ${build.base}/workspace );
expander.addProperty( dist.home, ${build.base}/downloads );
expander.addProperty( text.property, Cocoon3 rocks! );
then creating and run their pipeline adding the VariableExpander:
newNonCachingPipeline().setURLGenerator(
getClass().getResource( /variables-expander.xml ) )
.addTransformer( expander )
.addSerializer()
.withEmptyConfiguration()
.setup( System.out )
.execute();
That makes it also easier to add configuration to the expander, for example:
* use other marker than ${}, in case you may want generate generate a file
using that syntax for its own purposes
* what to do if there if the property name is undefined: replace it by nothing
/ leave as is / throw exception
Also by not just using a stupid property map, it is much easier to avoid
infinite recursions such as
setProperty(build.home,${build.home}/workspace).
Cheers, Alfred.
-Original Message-
From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of
Simone Tripodi
Sent: Donnerstag, 15. Dezember 2011 18:02
To: dev@cocoon.apache.org
Subject: Re: [C3] new pipeline component: variabelExpander
Hi Robby :)
On Thu, Dec 15, 2011 at 5:56 PM, Robby Pelssers robby.pelss...@nxp.com wrote:
Would it be justified to say that it acts as some kind of transformer
(although non-xslt based) in this case which replaces all variable references
with the value from the Map or Properties provided?
exactly, it just replaces plain text inside attributes/body elements :P
And I suppose it works on any text, not just XML?!
Not ATM, it works as XmlTransformer :(
Bring it on ;-)
I'll do, thanks! :)
best;
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
The content of this e-mail is intended only for the confidential use of the
person addressed.
If you are not the intended recipient, please notify the sender and delete this
e-mail immediately.
Thank you.
RE: [2.1] Future of Cocoon 2.1.x... again :)
Cocoon 2.1.11 should be working with any JVM 1.3 and up. Because nobody is actually using 1.3 anymore for development, there were several occasions that library features not available in 1.3 crept in. Therefore it was decided that the next release 2.1.12 should require 1.4. I would not recommend actually using 1.3 or 1.4 anymore because of its non-existent memory model. Cheers, Alfred. From: Cédric Damioli [mailto:cedric.dami...@anyware-services.com] Sent: Montag, 12. Dezember 2011 11:37 To: dev@cocoon.apache.org Subject: Re: [2.1] Future of Cocoon 2.1.x... again :) Cocoon 2.1.x was meant to be used with 1.3 But the release notes file of the current 2.1.12-dev mention 1.4 as minimum requirement ! Le 12/12/2011 11:24, Robby Pelssers a écrit : What JDK are you using? It seems like you will need a very old JDK for this branch to work. Robby From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Monday, December 12, 2011 11:22 AM To: dev@cocoon.apache.orgmailto:dev@cocoon.apache.org Subject: Re: [2.1] Future of Cocoon 2.1.x... again :) On 12/12/2011 11:00, Cédric Damioli wrote: Hi team, I recently came again across annoying 2.1 bugs, which I have proposed patches for, and realized that I received almost no answers to my what's the future of Cocoon 2.1 e-mail, and that my patches have not been reviewed nor committed. I have found and patched a new one this morning : https://issues.apache.org/jira/browse/COCOON-2319 As I previously said, I fully understand that current Cocoon committers are focused on Cocoon 3, and that they probably have no great interest to old maintenance releases. Again, I totally volunteer to help to maintain and release 2.1.x branch, as I have dozens of production applications on top of it, running with a a-lot-patched Cocoon. Please tell me what I can do to help. Hi Cedric, as I wrote in [8], here it follows what I did for building C2.1 trunk (in order to start applying your patches, of course): 1. svn co https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X cocoon-2_1_X 2. cp blocks.properties local.blocks.properties 3. set include.all.blocks=true 4. ./build.sh 5. ./build.sh test resulted in 6 test failures (DefaultRunnableManagerTestCase) Am I doing something wrong? [8] http://mail-archives.apache.org/mod_mbox/cocoon-dev/201108.mbox/%3c4e4a7273.2020...@apache.org%3E Le 11/08/2011 15:36, Cédric Damioli a écrit : Hi Cocoon team, A little more than one year ago, I sent a mail [1] to this list, to get feedbacks about usage of Cocoon 2.1.x, 3 years after the last release. I must admit that I received many more answers (privately and publicly on the list) than I could have expected first. This proved me the vitality of the 2.1.x community. So I began to open some tickets [2] [3] [4] [5] [6] [7] and provide some patches gathered during the last years on my projects, but unfortunately, I received nearly no feedback from committers around here. Is there still any interest from devs for the 2.1.x branch ? Could someone review the patches ? I obviously volunteer to help, to stop having to run dozen apps with a patched Cocoon. Has someone interest to prepare and schedule a 2.1.12 maintenance release ? Best regards, Cédric [1] http://markmail.org/thread/hizllvbjdeurr2de [2] https://issues.apache.org/jira/browse/COCOON-2288, allow to use SLF4J [3] https://issues.apache.org/jira/browse/COCOON-2307, bug in the ResourceReader [4] https://issues.apache.org/jira/browse/COCOON-2309, possible bug with SitemapSource under certain circumstances [5] https://issues.apache.org/jira/browse/COCOON-2310, XHTMLSerializer from serializers block does not handle HTML5 [6] https://issues.apache.org/jira/browse/COCOON-2313, subclassing of org.apache.cocoon.Cocoon [7] https://issues.apache.org/jira/browse/COCOON-2314, override upload params in CocoonServlet -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/http://people.apache.org/%7Eilgrosso/ -- [cid:image001.png@01CCB8DC.9D3BF550]http://www.anyware-services.com www.anyware-services.comhttp://www.anyware-services.com [cid:image002.png@01CCB8DC.9D3BF550]http://www.twitter.com/anywareservices[cid:image003.png@01CCB8DC.9D3BF550]http://www.facebook.com/AnywareServices[cid:image004.png@01CCB8DC.9D3BF550]http://eepurl.com/eyrpkhttp://eepurl.com/eyrpk Inscrivez-vous à notre newsletterhttp://eepurl.com/eyrpk Cédric Damioli Directeur technique cedric.dami...@anyware-services.commailto:cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Innopole 13 - 254 avenue de l'Occitane - B.P 97672 - 31676 LABEGE CEDEX - France Ametys: Smart Web CMS [cid:image005.gif@01CCB8DC.9D3BF550]http://www.ametys.orgwww.ametys.orghttp://www.ametys.org Ce message et toutes les pièces jointes (le Message) sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification,
RE: Sitemap Node Traversal Logging?
Have a look at the a.o.c.util.location package. That provides the machinery to print the sitemap component / filename / line number / column in an exception traceback. That should allow you to learn how to get hold of these values at component entry. Instrument the code with logger.debug calls and enable it in the logging config. HTH, Alfred. From: Sands Alden Fish [mailto:sa...@mit.edu] Sent: Dienstag, 6. Dezember 2011 16:42 To: dev@cocoon.apache.org Subject: Sitemap Node Traversal Logging? Hey all, I'm trying to get Cocoon (2) to spit out a log entry of each sitemap file/line/line-number that it hits while processing a pipeline request. I've been digging around in the logkit config and sitemap logger configs, but there doesn't seem to be an easy way to do this globally. Any suggestions? I will patch Cocoon source, if necessary... Thanks! -- sands fish Senior Software Engineer MIT Libraries Technology Research Development sa...@mit.edumailto:sa...@mit.edu E25-131 The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
RE: PermGen memory leak in cocoon-jnet
Hi all,
URL.setURLStreamHandlerFactory is singleton call which should only be used when
you own the JVM.
Calling it from C3 which is expected to play nicely with other servlets in the
same container, it is a no-no.
Jnet should be changed, for example by providing a createURL(String spec)
factory method which calls the
URL(protocol,host,port,file,handler) with the handler matching the custom
protocol.
Cheers, Alfred.
-Original Message-
From: Andreas Hartmann [mailto:andr...@apache.org]
Sent: Mittwoch, 30. November 2011 14:10
To: dev@cocoon.apache.org
Subject: Re: PermGen memory leak in cocoon-jnet
Am 29.11.11 02:55, schrieb Andreas Hartmann:
Hi everyone,
when undeploying a C3 app, I'm experiencing a PermGen memory leak due to
cocoon-jnet. You find more general info on the subject at [1].
This is the reference chain:
class java.net.URL
-
org.apache.cocoon.jnet.URLStreamHandlerFactoryInstaller$ParentableURLStreamHandlerFactory
-
org.apache.cocoon.jnet.URLStreamHandlerFactoryInstaller$ParentableURLStreamHandlerFactory
- org.apache.catalina.loader.WebappClassLoader
The problem is this line of code in URLStreamHandlerFactoryInstaller;
commenting it out resolves the memory leak:
URL.setURLStreamHandlerFactory(new
ParentableURLStreamHandlerFactory(factory, null));
Here the static reference from java.net.URL to a Cocoon class is set.
Does anyone know if and how the reference can be removed, or if we can
achieve the same behaviour without registering the factory with
java.net.URL?
The following patch avoids the memory leak, but I have the feeling that
it has functional drawbacks, otherwise the code would already look like
this :)
Does anybody know how I can test if the class still fulfils its purpose?
Maybe it's possible to provide a unit test?
TIA!
-- Andreas
N��{^�� ��zf��+�קu�h�\���ay�'~'^�ؚ�� ��az�u�ǝ!ޞ�m�觵��y��r*bz{i���zz-� �jw]zW�z�b�隊X���bjץ�8Z�L�
[RESULT] [VOTE] Require Java 1.6 for Cocoon3
Hi all, Here are the results for the vote [1]. There were 9 binding +1 from: * Alfred Nathaniel * David Crossley * David Legg * Francesco Chicchiriccò * Joerg Heinicke * Peter Hunsberger * Reinhard Pötz * Steven Dolg * Thorsten Scherler There were no other votes. It is accepted that Cocoon3 requires Java 1.6 as minimum version. Cheers, Alfred. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg59906.html The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
[VOTE] Require Java 1.6 for Cocoon3
Hi all, A few weeks ago we had a discussion [1] whether to increase for Cocoon3 the minimum Java version from 1.5 to 1.6. There were a number of advantages identified to be gained by using Java6, which I don't want to repeat here, The only downside is the exclusion of potential C3 users locked in to Java5. A survey on the user list [2] asking users to step forward if that really applied to anybody did not yield any response. Therefore I' call the vote on Code Modification [3]: +1 = Yes, Cocoon3 shall require Java 1.6 -1 = No, Cocoon3 must remain usable with Java 1.5 (with justification for the veto) This change is targeted only at Cocoon3. Cocoon2.1 and Cocoon2.2 are not affected. Please cast your votes before Mon 3 Oct 06:00 UTC. Here is mine: +1 Cheers, Alfred. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg59791.html [2] http://www.mail-archive.com/users@cocoon.apache.org/msg46231.html [3] http://www.apache.org/foundation/voting.html The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
RE: Failing build
+1 Is there an option to delay the dev@ mail to give the committer a head start for fixing his own mess? Cheers, Alfred. -Original Message- From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of Simone Tripodi Sent: Freitag, 16. September 2011 17:13 To: dev@cocoon.apache.org Subject: Re: Failing build I received the Jenkins notification that build came normal, I guess it is configured to send email only to last committer that commits, not the dev ML :S I think we should ping INFRA to change that setting and receive the failures on dev ML, WDYT? thanks for the fix!! :) All the best, Simo The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
RE: svn commit: r1162745 - in /cocoon/cocoon3/trunk: cocoon-optional/pom.xml cocoon-stax/pom.xml parent/pom.xml
-Original Message- From: Thorsten Scherler [mailto:scher...@gmail.com] Sent: Montag, 29. August 2011 14:16 To: dev@cocoon.apache.org Subject: Re: svn commit: r1162745 - in /cocoon/cocoon3/trunk: cocoon- optional/pom.xml cocoon-stax/pom.xml parent/pom.xml On Mon, 2011-08-29 at 14:00 +0200, Francesco Chicchiriccò wrote: ... Since Jakarta RegExp is retired (see [1]), do you think it would be hard to rework the DirectoryGenerator in order to make use of java.util.regexp.* instead? Otherwise you can just add this dependency - with version - in parent/pom.xml and with optional modifier in cocoon-optional/pom.xml. One less dependency - even though optional - is better :-) Hmm, Jakarta RegExp does some things different and IMO much better then java.util. Even if it is retired that does not mean it is not worth using it, more since this way the component works exactly as in our prior versions. Not sure when I will find the time to look into a rewrite to use java regex. I second Francesco that we should get rid of Jakarta RegExp before 3.0. In the long run will pay off to use a good standard rather than a better non-standard. When you say Jakarta does it different and better do you refer to the API or the regexp syntax? If it is just converting the API calls, I can help. I wonder whether for the average user it would not be more convenient if DirectoryGenerator would accept the same Ant-style globs as map:match rather than full-blown Perl-style regexps. Cheers, Alfred. The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
RE: Cocoon GetTogether?
Please plan it as a 2-day event with a late morning start on day1 and an early afternoon finish on day2 that one can fly in and out with one overnight stay for the social GT. NB traditional GT dinner is spare ribs. Do you have those in L'Aquila? Cheers, Alfred. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 5. August 2011 08:14 To: dev@cocoon.apache.org Subject: Re: Cocoon GetTogether? Hi Simone, as per our recent discussion about this topic, I would personally love this Cocoon GT in L'Aquila :-) If other people agree, I can of course help organizing, either personally and by contacting some people at the University - it has been my University too :-P. Gents, WDYT? The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
RE: Springification of C3 - proof of concept
Hi Igor, It's a nice show case that C3 has reached one of its design goals to be embeddable in other frameworks. Whilst C2 is the 500lb gorilla squatting the driverseat, C3 is a neat little monkey who knows how to driver but also fits onto the backseat. I was first confused by the term springification which I understood as using more Spring in C3. In fact it is the other way around. It should rather be called the cocoonification of Spring. Calling C3 pipelines from frameworks such as Spring MVC is a welcome perspective for people who are stuck to an MVC framework but want the power of Cocoon plumbing for the rendering. But saying that our neat little monkey should stay on the backseat because Spring knows so much better to drive is too restrictive. C2 has many more use cases than just REST and MVC and C3 should be able to drive these as well. I think your POC is worthwhile keeping but certainly not in C3 core. I wouldn't even put it under cocoon-samples because it gives the wrong impression that one has to swallow Spring before tasting Cocoon. How about calling it the cocoon-on-the-backseat module? Cheers, Alfred. -Original Message- From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of Simone Tripodi Sent: Donnerstag, 4. August 2011 15:08 To: dev@cocoon.apache.org Subject: Re: Springification of C3 - proof of concept Hi Igor!!! congrats for your committership and your dedication to this work!!! I really appreciate you shared your results with us! Just my *personal* POV: even if I'm NOT a SpringFramework fan (and I won't be :P) your work shall be included in a way or another in C3. Anyway I would prefer Spring doesn't play the main role: I mean, having 3rd parties integrations it more than fine - we already have indeed modules with 3rd parties integrations, like StringTemplate, JAX-RS, Optionals (Solr, JAXB) - but IMHO Cocoon *core* components should not be dependent by any framework, I wouldn't force C3 users learning Cocoon AND Spring as a starting point, or require Spring as knowledge base to get started with Cocoon. I think that should sound reasonable, WDYT? So, my suggestions, if you are happy to continue on contributing - and I really hope you are :) - is: * checkout the latest C3 code from /trunk; * understand how it is actually organized and check what has been already implemented (for sure you can help us on improving actual JAXB implementation, for example) * starting proposing and discussing modifications/additional components step by step, not sure everybody would agree on adding everything as a single big commit ;) Many thanks in advance, all the best!!! Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Aug 2, 2011 at 1:32 AM, Igor Malinin igor...@gmail.com wrote: Hello. I've promised some (not so long) time ago to share my experiments with C3 and Spring, and now I am ready to show some interesting achievements. Here is the source code: https://github.com/igorzep/cocoon-springification What it does... 1) Use traditional annotated Spring Controllers I think it is better REST than Cocoon today. Those days when Cocoon was a leader in this respect has passed, and it really was the best REST framework from day one when nobody even used this word. But now Spring is really powerful and I think Cocoon should not try to invent own things but integrate with Spring as much as possible. In current form it disables Spring functionality and replace with own much more limited solution. 2) Use Cocoon Sitemap as Spring View Again - traditional Spring way. Also i map Cocoon to WEB-INF so that sitemap is hidden for direct browser access (good trick to workaround lack of private pipelines in C3). 3) Use Spring FORM tag library in SAX pipeline When it is very simple implementation it works quite good already, much better than I expect from it myself... 4) Integrated Validation with Spring and Hibernate Validator Again - traditional Spring 3 way of handling forms, together with previous item can be a good foundation for replacing old Cocoon forms module... 5) EclipseLink JPA Just my favorite, as it implements both JPA and JAXB... 6) Mapping Spring model to XML with JAXB annotations Just a quick hack as everything else... 7) JRebel compatible, just generate rebel.xml for main module Unfortunately EclipseLink JRebel plugin does not work with latest EclipseLink, but can be switched off easily. Otherwise I did a small fix to XSLT transformer, so it rechecks for modifications correctly (not included with sources) and it works much better than Cocoon RCL. Actually Cocoon RCL destroyed root spring context on first invocation and any future requests to EclipseLink didn't work at all. I think that Cocoon RCL should be dropped at all - it is unusable for something serious, if you do something more than totally trivial it takes more time to fight with it, works almost always
RE: [C3] Java version 1.6
Peter Hunsberger wrote: We seem to have this discussion every few years. There's always people that can't upgrade. Personally I think it's time to do it and I wish we had done it long ago. With C3 in particular, people should have no dependencies in production since it is still officially Beta. Even if they do, they can stay on a previous version after all, if it is good enough to use at all why can't they stick with what they are using? Unless someone can come up with a reason not to I'd say it's time to start a vote. True, we had the same discussion years ago to me C2.1 from J1.3 to J1.4. Apart from the improvements we get when using 1.6, my main point is that real 1.5 support is not achieved by using a 1.6 javac with -source=1.5 and -target=1.5. That happily compiles and generates 1.5 byte code containing calls to String.isEmpty. Only when you run that jar in a 1.5 JVM it will die with a method-not-found exception. Unless we have a good crowd of developers who voluntarily stick to 1.5 all the way, it is just wishful thinking that C3 is and remains 1.5 compatible. Even if that hypothetical poor guy exists who would love to use C3 but is stuck at Java5, I don't think we do him a favor. Better force them to go 1.6 than to have them chase the next odd String.isEmpty which leaked into the release. Hands up who is / is willing to run jdk1.5 for C3 development. NB Jenkins is setup with 1.6. Does infra support real 1.5 builds? Cheers, Alfred. The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
[C3] Java version 1.6
Hi all, C3 is still set to 1.5 as source and target version. Java5 is end of life since almost two years now. Is there any good reason not to go 1.6? Cheers, Alfred. The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
RE: Re: -Dmaven.test.skip=true
Jorg Heymans wrote: We aren't providing snapshot builds and people want to try out the new features. This currently means they have to compile themselves. Failing unit tests are a hurdle that might stop their attempt to explore completely - the huge 'BUILD FAILED' banner at the end doesn't always convey the right message. So, suggestions: We should start providing snapshots again and push the archetype as main entry point for those wanting to explore. Why can't we just get the test suite to run through? - If the test is no longer applicable, remove the test. - If the test fails because the test is wrong, fix the test. - If the test fails because the testee is broken, fix the testee. - If fixing the testee is too much effort, disable the block. - If the block is too important to be disabled, spend the effort to fix it. - When all tests pass, then it may be time to invite beta testers. - Write more tests. Am I too naïve? IMHO our current image problem is that there are too frequent BUILD FAILED even without running the tests. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Release roadmap
+1 to release 2.2-M2 +1 to release 2.1.10 +1 to drop block sharing -1 to put 2.1.x into *pure* bug fixing mode We should try to attract people to 2.2 rather than pushing them away from 2.1 (because they may go somewhere else). I expect to be stuck with 2.1.x for the next 1-2 years. That's a bit too long to be forbidden to add enhancements we might need along the way for new projects. Going to 2.2 anytime soon is unlikely for us because we just finished migrating from 2.1.m3 to 2.1.10-dev. Selling to management another migration project before 2008 would be very hard, especially since the current 2.2 has new feature really interesting to us. Also, everytime I try to dive into 2.2 I hit a brick wall of Maven magic. Cocoon documentation is important but currently even more lacking is Maven2 documentation. Carsten, Daniel, Reinhard, and few others seem to get along pretty well with M2 which gives me hope that the rest of us can follow too. But currently I have the feeling that for the majority of committers 2.2 is still uncharted territory. (Or is it only me?) So my proposal is simply use a different wording and to declare 2.1.x to be in maintenance mode. Only bug fixing *and minor enhancements* will be applied and we continue to make 1-2 releases/year. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Release roadmap
From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Selling to management another migration project before 2008 would be very hard, especially since the current 2.2 has new feature really interesting to us. Something is wrong with that sentence I guess. I miss the logic: You can't sell another migration, because the version potentially migrated to has interesting features? Oops, missing negation. *no* new feature really interesting to *us*. Isn't it just wording? It has always been the case that the old branch has not been closed. If there is any interest in applying an enhancement to an old branch, just do it. Nobody will prevent you from doing it. But you simply can't expect from every committer to also do the back porting. So any maintenance of the older branch is up to the individual one still having interest in it. At the end interest will simply decrease and the branch will be going to sleep - as it happened with 2.0.x. Yes, it's all about wording. Let 2.1.x go to sleep but don't kill it. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [VOTE] Lars Trieloff as a new Cocoon committer
I think time has come for Lars Trieloff to become a Cocoon committer, +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Wildcard matcher matching wild things
I did a quick benchmark on a 1.8 GHz Pentium running 1'000'000 iterations for matching/not-matching simple/complex wildcards. (Theo WH is the original WildcardHelper where the compiled pattern is cached.) assertNull(WildcardMatcherHelper.match(menu/*.xml, menu/foo.html)); New WMH: 281ms Old WMH: 1472ms Orig WH: 1833ms Theo WH: 1192ms assertNotNull(WildcardMatcherHelper.match(menu/*.xml, menu/foo.xml)); New WMH: 1622ms Old WMH: 2103ms Orig WH: 2423ms Theo WH: 1824ms assertNull(WildcardMatcherHelper.match(menu/**/*.xml, menu/foo/bar.html)); New WMH: 240ms Old WMH: 2574ms Orig WH: 2704ms Theo WH: 1954ms assertNull(WildcardMatcherHelper.match(menu/**/*.xml, menu/bar.xml)); New WMH: 2413ms Old WMH: 1633ms Orig WH: 1983ms Theo WH: 1312ms assertNotNull(WildcardMatcherHelper.match(menu/**/*.xml, menu/foo/bar.xml)); New WMH: 7271ms Old WMH: 3155ms Orig WH: 3454ms Theo WH: 2744ms Bottomline is that the new implementation is between 10 times faster and 3 time slower than previous implementations. In a typical mix of patterns and input strings all should perform within a very narrow range. The absolute number of a few *microseconds* per iteration makes anyway any difference peanuts compared to the complete request handling taking tens of milliseconds. Cheers, Alfred. -Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 21. September 2006 19:53 To: dev@cocoon.apache.org Subject: Re: Wildcard matcher matching wild things On 20.09.2006 10:39, Nathaniel Alfred wrote: Since map:match is the most frequently executed pipeline instruction, speed is an issue. That can be mastered by a) caching the compiled regexps and b) handling the simple pattern with a single * or ** as special cases without using regexps. Just wondering, did you actually do some performance comparisons? Regards, Jörg This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Wildcard matcher matching wild things
I committed the new code. It passes all test including the new one which illustrated the reason for the rewrite. We are currently migrating our corporate websites to 2.1.10-dev that core and the XSP block will get pretty good real-life test coverage. Cheers, Alfred. -Original Message- From: Reinhard Poetz [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 21. September 2006 07:50 To: dev@cocoon.apache.org Subject: Re: Wildcard matcher matching wild things ... As you and Bertrand said, speed and compatibility are very important. If your new implementation takes care of both and is proved by tests, I don't see a problem. -- Reinhard Pötz Independent Consultant, Trainer (IT)-Coach This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: patch for an entityResolver problem in xsl stylesheets ...
Hi Hussayn, thanks for sharing your patch. I'll have a look at it. Cheers, Alfred. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Hussayn dabbous Sent: Mittwoch, 30. August 2006 22:48 To: dev@cocoon.apache.org Subject: patch for an entityResolver problem in xsl stylesheets ... Hi; I tried to use external entities like uuml; etc. in xsl stylesheets. For this purpose in first place i added a DOCTYPE definition on top of my stylesheet, i.e.: ?xml version=1.0? !DOCTYPE mydoc [ !ENTITY % ISOlat1 PUBLIC ISO 8879:1986//ENTITIES Added Latin 1//EN//XML ISOlat1.pen %ISOlat1; ]xsl:stylesheet version=1.0 ... I assumed, the default entity resolver would resolve the ISOlat1.pen, but it did not! I tracked this down and found, that entity resolution only works correctly when i set the SYSTEM identifier to the absolute location of the external entity file. I did not like this hack, hence i tracked the problem further down and eventually found one location in TraxProcessor.java which apparently needs a modification in order to inject the correct EntityResolver to work as expected. I finally created a patch, which adds Entity resolving within XSLT processing wherever a document(), import or include is performed. i did not check whether this patch works recursively (follows an import within an imported xsl), but it looks like it would do ... The patch has been created against cocoon/branches/BRANCH_2_1_X It works for me. Hopefully it is usefull for others and does not break code at other places. If anyone would like to review the patch and give some feedback, That would be great ;-) best regards, Hussayn This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Cocoon 2.2 and Java 5
What do people think about making Java 5, which was released almost _2 years ago_, the minimum requirement for trunk? +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [Vote] Ard Schrijvers as a new Cocoon committer
+1, even though he doesn't want to work for me :-) Cheers, Alfred. -Original Message- From: Reinhard Poetz [mailto:[EMAIL PROTECTED] Sent: Freitag, 28. Juli 2006 07:45 To: dev@cocoon.apache.org Subject: [Vote] Ard Schrijvers as a new Cocoon committer ... Please cast your votes! This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
[JOB] Cocoon developer in Geneva
The Geneva branch office of SWX Swiss Exchange has a job opening for an experienced developer. We are using Cocoon as framework for building highly dynamic websites containing financial data. The post requires skills in Cocoon, Java, XSP, XSLT, JDBC, and related technologies. More details and how to apply can be found at http://www.swx.com/careers/description/g06gbi_lsc01.html. Best regards, Alfred Nathaniel SWX Swiss Exchange This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [RANT] This Maven thing is killing us....
Why not keep the MVN repo in the Cocoon SVN repository like we used to do with the lib directory? That would allow close control of updates only by committers, and with a MVN file repo pointing to the user's Cocoon checkout, builds remain stable between SVN updates. Sure that requires again 100+ MB downloads from SVN. But that seems more stable than downloading 20 MB from SVN only and then 80+ MB from shakey MVN servers. Cheers, Alfred. -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Montag, 3. Juli 2006 10:42 To: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us Simone Gianni wrote: Niclas Hedhman wrote: What happens *if* Mergere runs out of juice and flip the switch off? IIUC, maven repos are nothing more than HTTP servers, and SVN is accessible thru HTTP, so we can create a folder named repository in our svn repo, copy the folders of artifacts we need from ibiblio, and have complete control over it. This is technically possible (and would also solve mny other problems), but does not solve the legal stuff maven repos solve about redistributing others work. A good idea, but I can't see any way in which infrastructure would allow this. That is because it would prevent any useful partitioning of resources. Maven is likely to become a resource hog, and could easily bring SVN down to its knees. Much better that it only be the MVN repo that goes down at such a time, and not our SVN repo too. Upayavira This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [RANT] This Maven thing is killing us....
Either I am really thick here, or we talk about different things. I don't want to use the Apache SVN server as MVN repository. I propose to commit again all JARs into, say, cocoon/trunk/m2repo and then tell Maven at build time to use that directory in the checkout area as first repository server in the search list. cocoon/trunk/pom.xml: repositories repository idcocoon-private/id nameCocoon private Maven repository/name urlfile:/my/path/to/m2repo/url /repository repository idcentral/id nameMaven central repository/name urlhttp://ibiblio.org/maven2/url /repository ... /repositories I am a Maven newbie that I don't know whether file: repositories are actually supported. A relative locator would even be nicer. The Internet repositories can still be used for thoses JARs for which the are legal reasons not to store them on ASF servers. I don't see, how storing some 100 jarfiles totaling 100 MB like it is now for 2.1 should endanger the SVN infrastructure, if it is used on the SVN checkouts and commits. The drawback is of course that one has to checkout the whole thing even for building a mini-subset of Cocoon blocks. But that is something to worry about when the blocks a-la-carte actually works. Until then a reliable build system is much more important. Cheers, Alfred. -Original Message- From: Simone Gianni [mailto:[EMAIL PROTECTED] Sent: Montag, 3. Juli 2006 11:27 To: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us Hi Alfred, see the previous mail by Upayavira : A good idea, but I can't see any way in which infrastructure would allow this.That is because it would prevent any useful partitioning of resources. Maven is likely to become a resource hog, and could easily bring SVN down to its knees. Much better that it only be the MVN repo that goes down at such a time, and not our SVN repo too. Simone Nathaniel Alfred wrote: Why not keep the MVN repo in the Cocoon SVN repository like we used to do with the lib directory? That would allow close control of updates only by committers, and with a MVN file repo pointing to the user's Cocoon checkout, builds remain stable between SVN updates. Sure that requires again 100+ MB downloads from SVN. But that seems more stable than downloading 20 MB from SVN only and then 80+ MB from shakey MVN servers. Cheers, Alfred. -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Montag, 3. Juli 2006 10:42 To: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us Simone Gianni wrote: Niclas Hedhman wrote: What happens *if* Mergere runs out of juice and flip the switch off? IIUC, maven repos are nothing more than HTTP servers, and SVN is accessible thru HTTP, so we can create a folder named repository in our svn repo, copy the folders of artifacts we need from ibiblio, and have complete control over it. This is technically possible (and would also solve mny other problems), but does not solve the legal stuff maven repos solve about redistributing others work. A good idea, but I can't see any way in which infrastructure would allow this. That is because it would prevent any useful partitioning of resources. Maven is likely to become a resource hog, and could easily bring SVN down to its knees. Much better that it only be the MVN repo that goes down at such a time, and not our SVN repo too. Upayavira This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. -- Simone Gianni
RE: [vote] Simone Gianni as a new Cocoon committer
It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. +1 I think I know Simone from my earlier life at CERN? Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [vote] Niclas Hedhman as a new Cocoon committer
I'd like to propose Niclas Hedhman as a new Cocoon committer. +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [Vote] Release plan for 2.1.9
So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
-Original Message- From: Andrew Savory [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 22. Dezember 2005 14:43 To: dev@cocoon.apache.org Subject: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline) Hi, On 20 Dec 2005, at 15:56, Jean-Baptiste Quenot wrote: See patch attached. WDYT? I think you should become a committer, so you can work on these things without patches :-) Everyone: Jean-Baptiste is becoming more and more active on the dev list, and has been diligently filing bugs and patches for the last few months. The first post about his activity is from July, 2004 [1]. He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. [1] http://marc.theaimsgroup.com/?a=10893038224r=3w=2 Please cast your votes! Here's mine: +1 Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/ This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Please cast your votes! +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [jira] Updated: (COCOON-1691) ESQL compilation error
Good idea, thanks. I'll do that.
Cheers, Alfred.
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 23. November 2005 14:10
To: dev@cocoon.apache.org
Subject: Re: [jira] Updated: (COCOON-1691) ESQL compilation error
Alfred Nathaniel (JIRA) wrote:
[ http://issues.apache.org/jira/browse/COCOON-1691?page=all ]
Alfred Nathaniel updated COCOON-1691:
-
Component: Blocks: Databases
(was: Blocks: XSP)
Fix Version: 2.1.9-dev (current SVN)
Damn it, the ESQL logicsheet escaped my renaming exercise. Our pre-release
testing really sucks...
Fix for 2.1.9-dev and trunk committed.
Still this change can break existing 3rd party logicsheets relying on existance
of xspAttr. I'd suggest adding a line...
138:public void generate() throws ... {
139: final AttributesImpl xspAttr = _xspAttr;
As well as changing line 122 to add final modifier:
122:private final AttributesImpl _xspAttr = new AttributesImpl();
Vadim
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender’s company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender’s company.
JIRA encoding problem
The JIRA import seems to have a UTF-8 vs. LATIN-1 encoding problem. The reporter field is messed up in http://issues.apache.org/jira/browse/COCOON-1603 http://issues.apache.org/jira/browse/COCOON-1627 On the hand Jörg is spelled correctly in http://issues.apache.org/jira/browse/COCOON-1624 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [2.1.8 release] all htmlunit tests pass on macosx, how about other platforms?
Le 20 oct. 05, à 10:54, Bertrand Delacretaz a écrit : I have fixed a few things so that all htmlunit-tests pass here (JDK 1.4.2, macosx 10.3.8). It would be cool if people could run these tests on other platforms and report results here... FWIW, I've received a success report off-list, that the tests also pass on winXP / java 1.4.2_09 JDK 1.4.2_09 on SPARC Solaris also passes all htlmunit tests. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [VOTE] new committer: Max Pfingsthorn
So I have the pleasure of proposing Max as our new committer! +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [vote] Ross Gardler as a new Cocoon committer
I'd like to propose Ross Gardler as a Cocoon committer. Sure +1. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [vote] Arje Cahn as a new Cocoon committer
Please cast your votes! +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: JUnit Tests and maven status
-Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Freitag, 26. August 2005 13:53 To: dev@cocoon.apache.org Subject: Re: JUnit Tests and maven status Le 26 août 05, à 13:17, Daniel Fagerstrom a écrit : Bertrand Delacretaz wrote: Maybe we could dedicate the second day of the GT hackathon to this? Dedicate is a little bit strong for my taste, I would like to see some more work on the block stuff also. Sure - I was more meaning form a team to work on this with those who want to join ;-) -Bertrand Count me in on that. Maybe I even find some time to work a bit on it before the GT. There are also a few more htmlunit related tasks on my agenda: -- Move junit testcases one directory level down to separate them from htmlunit. -- Update to latest htmlunit version. -- Check licenses whether we can bundle htmlunit with Cocoon. (I guess m2 solves that for trunk?) -- Remove anteater. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: java 1.3 and cocoon 2.1.x branch.
-Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Sonntag, 31. Juli 2005 09:27 To: dev@cocoon.apache.org Subject: java 1.3 and cocoon 2.1.x branch. Hi: I know most of us usually write java code for 1.4. We need keep a contract with our users, the backward compatibility with java 1.3. If you ask me, I will vote to move directly to 1.5. ;-) I was not able to make a quick fix for: blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java at line 228: CharSequence -- was introduced in 1.4 -- http://java.sun.com/j2se/1.4.2/docs/api/java/lang/CharSequence.html Can someone help me here? Best Regards, Antonio Gallardo. PS: Plase don't take it personally, ok? ;-) This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: java 1.3 and cocoon 2.1.x branch.
Hi Antonio, The fix was actually quite simple: replace CharSequence by String because that is the only type for which consume is called. 1.3 compatibility is becoming more and more of a problem since most developers are now using 1.4 or even 1.5. One more reason to stabilize C2.2 and release it that we can freeze 2.1.x and get rid of JDK1.3. Until then your role as J1.3 gatekeeper is appreciated. Cheers, Alfred. -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Sonntag, 31. Juli 2005 09:27 To: dev@cocoon.apache.org Subject: java 1.3 and cocoon 2.1.x branch. Hi: I know most of us usually write java code for 1.4. We need keep a contract with our users, the backward compatibility with java 1.3. If you ask me, I will vote to move directly to 1.5. ;-) I was not able to make a quick fix for: blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java at line 228: CharSequence -- was introduced in 1.4 -- http://java.sun.com/j2se/1.4.2/docs/api/java/lang/CharSequence.html Can someone help me here? Best Regards, Antonio Gallardo. PS: Plase don't take it personally, ok? ;-) This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [VOTE] Jorg Heymans as new committer
So, I'm pleased to propose Jorg Heymans, as a committer. Please cast your votes: +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Moving TraversableGenerator into Cocoon core
I think we should really start seeing branch as what it should be: a maintenance branch ;) And try to get a 2.2 out asap. Carsten +1 Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [VOTE] Give Robert Graham temporary and restricted commit privileges to our code repository
Please cast your votes! -Bertrand +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [GT2005] News, vote and more news
Yes, I'm thinking of attending the Cocoon GetTogether 2005 in Amsterdam, preferably on [X] 3/4/5 October (Mon-Wed) [ ] 5/6/7 October (Wed-Fri) Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
FW: svn commit: r191131 - /cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java
Twice static final int MODE_xxx = 8 looks like copy-waste error? Cheers, Alfred. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Freitag, 17. Juni 2005 13:46 To: cvs@cocoon.apache.org Subject: svn commit: r191131 - /cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mai l/transformation/SendMailTransformer.java Author: unico Date: Fri Jun 17 04:46:08 2005 New Revision: 191131 URL: http://svn.apache.org/viewcvs?rev=191131view=rev Log: Make smtp port configurable Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java URL: http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java?rev=191131r1=191130r2=191131view=diff == --- cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java (original) +++ cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java Fri Jun 17 04:46:08 2005 @@ -188,6 +188,7 @@ public static final String NAMESPACE = http://apache.org/cocoon/transformation/sendmail;; public static final String ELEMENT_SENDMAIL = sendmail; public static final String ELEMENT_SMTPHOST = smtphost; +public static final String ELEMENT_SMTPPORT = smtpport; public static final String ELEMENT_MAILFROM = from; public static final String ELEMENT_MAILTO = to; public static final String ELEMENT_REPLYTO= reply-to; @@ -215,11 +216,13 @@ protected static final int MODE_ATTACHMENT = 6; protected static final int MODE_ATTACHMENT_CONTENT = 7; protected static final int MODE_REPLY_TO = 8; +protected static final int MODE_SMTPPORT = 8; ^ This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The senders company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the senders company.
RE: Why does XSPMarkupLanguage wrap text in xsp:text?
-Original Message-
From: Jochen Kuhnle [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 8. Juni 2005 19:04
To: dev@cocoon.apache.org
Subject: Re: Why does XSPMarkupLanguage wrap text in xsp:text?
Hope I'm not too annoying on this issue, but on further work on logic
sheets, I believe the auto-wrapping is not only complicating
things a bit, it is actually introducing problems.
ContentHandler.characters specification [1] says that the character data
can be fed in chunks, so autowrapping text .a..b..c..d. ('.' stands for
space) might not rsult in xsp:text.a..b..c..d./xsp:text, but in
xsp:text.a..b..c/xsp:textxsp:text..d/xsp:text or some other
partitioning. It actually gets chunked in the current implementation if
there are newlines in the text.
Now consider e.g. the python xsp.xsl, which has a space='strip' option,
where the template for xsp:text does a normalize-space(). So partitioning
xsp:text.a..b..c..d./xsp:text results in a.b.c.d, while partitioning
xsl:text.a..b/xsl:textxsl:text../xsl:textxsl:textc..d./xsl:text
results in a.bc.d.
I would think there are some more side effects like this somewhere, so I
would suggest either fixing the PreProcessFilter, so it fixes chunking, or
remove it alltogether.
Regards,
Jochen
I can only guess that the autowrapping was intended to allow logicsheets
match=xsp:text/text() for text content and match=text() for program
code. It remains a mystery to me why none of the builtin logicsheets
actually uses this.
Removing the autowrapping may break a few custom logicsheets depending
on this, but since it is a rather obscure feature nowhere mentioned in
the user docs, I am +1 for dropping the autowrapping. Is does indeed
make logicsheet input more predictable.
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: [VOTE] Document Editors, and a new Committer
-Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 9. Juni 2005 11:52 To: dev@cocoon.apache.org Subject: [VOTE] Document Editors, and a new Committer On this basis, I'd like to propose Helma Van Der Linden as a Cocoon committer, and thus our first 'publisher'. She has been participating regularly in our community, and has shown a quiet but steady interest in helping with our documentation, as well as an increasingly clear understanding of how our community works. As granting committership requires a vote, please cast your votes now: [ ] Helma Van Der Linden as a Cocoon committer Sure +1 and welcome. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The senders company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the senders company.
RE: [RFE] Some enhancements to XSP
-Original Message-
From: Jochen Kuhnle [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 31. Mai 2005 14:07
To: dev@cocoon.apache.org
Subject: RE: [RFE] Some enhancements to XSP
Any preferrences which character to use?
Out of purely unrational affection, I prefer #{ and }.
The fact that I have implemented the prototype using this syntax really has
nothing to do with this ;). } is quoted by #}, # by ## and #x
results in an error if x != '}' and x != '#'.
Putting the special character before the opening brace leads to more
possibilies for collisions in existing logicsheets.
For example, with name and text being XSLT variables:
a href=page.html#{$name}xsl:value-of select=$text//a
By putting the special character, which cannot be at the start of an XSLT
expression, after the opening brace avoids these problems altogether.
Cheers, Alfred.
RE: [RFE] Some enhancements to XSP
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 31. Mai 2005 15:30
To: dev@cocoon.apache.org
Subject: Re: [RFE] Some enhancements to XSP
Instead of ? one could also use another character provided it is
sufficiently
unlikely that the sequence curly-char appears in XSP-embedded content or
where
XSP can be embedded (XSL). The special character should not be valid at the
beginning of an expression at least for CSS, HTML, Java, Javascript, Perl,
and XSLT. That excludes
+ * % ` @ ' ^ ~ ! [ $ - . ( /
but leaves as sensible alternatives
{#expr}
{=expr}
{:expr}
{?expr}
Whatever special character we agree on, it should be always the same in all
contexts and always enabled.
Any preferrences which character to use?
Yes. Given that (a) XSLT already has '{foo}' syntax, and uses '{{foo}}' for
escaping; and given that the only other XSP implementation (AxKit) uses same
syntax as in XSLT, I'm for using that same syntax too.
I think it is a bad idea to use exactly the same syntax as for XSLT because it
makes really awkward to use XSP attribute interpolation inside logicsheets.
You end up wasting your time figuring out which curly mountain is needed to
get the expression to be interpreted by the right engine.
It should be easy for both humans and the XSP processor to distinguish between
XSP and XSLT expressions.
I don't know AxKit in detail but I assume that them using {foo} syntax means
that they are not using XSLT-based logicsheets. Anyway, we can still claim to
use a common standard by defining:
interpolated-expr ::= '{' language-expr '}'
language-expr ::= perl-expr | '?' java-expr | '?' javascript-expr | '?'
python-expr
As for backward compatibility, is is already solved by:
xsp:page attribute-value-interpolation=no
But the default value should be attribute-value-interpolation=yes, provided
we can agree on a syntax which is highly unlikely to be used in existing XSPs.
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: XSP: EclipseJavaCompiler chokes on warings
-Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Dienstag, 31. Mai 2005 15:47 To: dev@cocoon.apache.org Subject: Re: XSP: EclipseJavaCompiler chokes on warings Jochen Kuhnle wrote: Vadim Gritsenko [EMAIL PROTECTED] wrote on 31.05.2005 05:00:36: Jochen Kuhnle wrote: the EclipseJavaCompiler chokes on warnings, resulting in the XSP not working. This is because in line 365 (cocoon-2.1.8-dev), it checks against result.hasProblems() instead of result.hasErrors(). I'd like to propose an option so the compiler ignores warnings and fails only if there are errors. However, there is more than one way to do this, so 'd like to ask before I create a patch: 1. Add a property setIgnoreWarnings to LanguageCompiler, configure the property in the programming-language section of cocoon.xconf and have CompiledProgrammingLanguage set it. 2. Avalonize the Compiler itself and make it configurable. 3. Other suggestions? Why not dump warnings into the log file (as WARNings), and stop only on errors - will this be possible? This gives us three warning handling states: ignore, log and fail. I would like to keep the current behaviour, because if the user does not want to tolerate warnings, he has the fail hard and fast option and immediatly gets an error page. On the other hand, if he has decided to live with warnings, we should make it possible for him to prevent log cluttering. This can be part of the configurable options, but I'd like to have your opinions on how to make the compiler configurable, by option 1. or 2.? 1. is fine. Vadim I wouldn't want to tolerate warnings in all XSPs only because it cannot be avoided in some of them. It should be a configuration parameter on the ServerPagesGenerator to allow using either possibility depending on the pipeline. There are only two warning handling states: ignore and fail. Warning should be logged with level WARN, errors with level ERROR to let the logger config decide what is actually written to the logfile. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Unknown-thread/CocoonServlet: Problem with Cocoon servlet
The server is waiting for data from the client and times out. Could be the client being stuck, or a protocol mismatch that both sides wait for each other. Putting on a network trace and analysing the HTTP exchange could give the answer. File upload is quite a complicated part of the HTTP protocol. Maybe your load runner just isn't up to it? HTH, Alfred. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Dienstag, 31. Mai 2005 18:19 To: dev@cocoon.apache.org Subject: Unknown-thread/CocoonServlet: Problem with Cocoon servlet Hello Cocooners! We are working on a big problem, please help: Stats: IBM Websphere 5.0.2 (runtime IBM 1.3.1) Cocoon 2.1.5 wrapped by our own RSFCocoonServlet (mostly for GZIP support, but it is not used in the moment) This Error occured while posting a big form (120 request parameters) without any attachment. the form isn´t defined as multipart. unfortunally this error happens only sometimes. eg running our load runner test during the night only two times!! There is an upload in this application, but the uploaded file isn´t stored on disk - a webservice saves it to a database. Please see the web.xml at the end for details Have you ever heard about this kind of error? ERROR (2005-05-30) 22:06.29:044 [access] (Unknown-URI) Unknown-thread/CocoonServlet: Problem with Cocoon servlet java.io.InterruptedIOException: Read timed out at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java(Compiled Code)) at com.ibm.ws.io.Stream.read(Stream.java(Compiled Code)) at com.ibm.ws.io.ReadStream.read(ReadStream.java(Compiled Code)) at com.ibm.ws.http.ContentLengthInputStream.read(ContentLengthInpu tStream.java(Compiled Code)) at com.ibm.ws.io.ReadStream.read(ReadStream.java(Compiled Code)) at com.ibm.ws.webcontainer.http.HttpConnection.read(HttpConnection .java(Inlined Compiled Code)) at com.ibm.ws.webcontainer.srp.SRPConnection.read(SRPConnection.ja va(Compiled Code)) at com.ibm.ws.webcontainer.srt.SRTInputStream.read(SRTInputStream. java(Compiled Code)) at com.ibm.ws.webcontainer.srt.http.HttpInputStream.read(HttpInput Stream.java(Compiled Code)) at java.io.BufferedInputStream.fill(BufferedInputStream.java(Compi led Code)) at java.io.BufferedInputStream.read(BufferedInputStream.java(Compi led Code)) at java.io.FilterInputStream.read(FilterInputStream.java(Inlined Compiled Code)) at java.io.PushbackInputStream.read(PushbackInputStream.java(Compi led Code)) at org.apache.cocoon.servlet.multipart.TokenStream.readToBoundary( TokenStream.java(Compiled Code)) at org.apache.cocoon.servlet.multipart.TokenStream.read(TokenStrea m.java(Inlined Compiled Code)) at org.apache.cocoon.servlet.multipart.TokenStream.read(TokenStrea m.java(Inlined Compiled Code)) at org.apache.cocoon.servlet.multipart.MultipartParser.parseMultiP art(MultipartParser.java(Compiled Code)) at org.apache.cocoon.servlet.multipart.MultipartParser.getParts(Mu ltipartParser.java:139) at org.apache.cocoon.servlet.multipart.MultipartParser.getParts(Mu ltipartParser.java(Inlined Compiled Code)) at org.apache.cocoon.servlet.multipart.RequestFactory.getServletRe quest(RequestFactory.java(Compiled Code)) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.j ava(Compiled Code)) ... thanks in advance! mit freundlichen Grüßen / kind regards Manfred Weigel Raiffeisen Zentralbank Österreich AG ORG/IT - Software Development A-1030 Vienna, Am Stadtpark 9 This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [RFE] Some enhancements to XSP
-Original Message-
From: Jochen Kuhnle [mailto:[EMAIL PROTECTED]
Sent: Freitag, 27. Mai 2005 15:02
To: dev@cocoon.apache.org
Subject: RE: [RFE] Some enhancements to XSP
If we filter the logic sheets, too, we can still move code back and forth
between XSP and logic sheet. There is one problem, though: since XSL uses
curlies, too, you have to escape them even more, and if(expr)
code really starts to look bad. In this case, would rather go
for a new syntax. Something like ~{expression}~ or more esoteric quotes,
like the single characters and , or ` and ´. Any suggestions
welcome...
XSP attribute interpolation makes on sense for Java expressions. Therefore
if(expr){code} is not really an issue.
I would suggest a syntax as {?expr} which must be transformed by a
preprocessor
applied to XSPs and logicsheets:
img src={?logo}.gif/
== imgxsp:attribute
name=srcxsp:expr(logo)+/xsp:expr.gifxsp:attribute/img
h1Hello {?username}/h1
== h1Hello xsp:expr(username)+/xsp:expr/h1
The prepocessor should not introduce any new line breaks in order to preserve
the correct line number count for XSLT error messages from the logicsheet.
The preprocessor must understand string and character constants and nested
braces.
Here are a few valid non-trivial expressions:
{?foo.indexOf('}')}
{?foo.indexOf(})}
{?new String[]{foo,bar}[index]}
If the closing brace is missing, the preprocessor shall generate XSP code which
leads to a compilation error:
h1Hello {?username}/h1
== h1Hello xsp:expr(username)+}/xsp:expr/h1
The replacement can be suppressed, by duplication the ?:
ttlt;h1gt;Hello {??username}lt;/h1gt;/tt is transformed to
ttlt;h1gt;Hello
lt;xsp:exprgt;usernamelt;/xsp:exprgt;lt;/h1gt;/tt
Instead of ? one could also use another character provided it is sufficiently
unlikely that the sequence curly-char appears in XSP-embedded content or where
XSP can be embedded (XSL). The special character should not be valid at the
beginning of an expression at least for CSS, HTML, Java, Javascript, Perl,
and XSLT. That excludes
+ * % ` @ ' ^ ~ ! [ $ - . ( /
but leaves as sensible alternatives
{#expr}
{=expr}
{:expr}
{?expr}
Whatever special character we agree on, it should be always the same in all
contexts and always enabled.
Any preferrences which character to use?
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: [RFE] Some enhancements to XSP
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 25. Mai 2005 20:47
To: dev@cocoon.apache.org
Subject: Re: [RFE] Some enhancements to XSP
3. A mechanism for expression replacement as in XSLT or JXTG, replacing
{expression} with a xsp:attribute element in attributes and with a
xsp:expr element in character data. This could be implemented in the
PreProcessFilter of XSPMarkupLanguage. The feature would be disabled by
default and enabled on a per-XSP-basis, maybe through a processing
instruction.
Example:
!-- Hey, this looks almost like JXTG :) --
img src={source} width={width} height={height}/
h1Hello {username}/h1
is more readable and easier to use than
img
xsp:attribute
name=srcxsp:exprsource/xsp:expr/xsp:attribute
xsp:attribute
name=widthxsp:exprwidth/xsp:expr/xsp:attribute
xsp:attribute
name=heightxsp:exprheight/xsp:expr/xsp:attribute
/img
h1Hello xsp:exprusername/xsp:expr/h1
Any comments?
I'm not in favour of h1Hello {username}/h1.
(I hope this hasn't been proposed already, but I
didn't find anything about it)
See [1].
Don't think in-text replacement is a good idea.
I think it's great idea, and, moreover, it is already implemented in another
XSP
implementation - AxKit [1]. So implementing the feature makes sense - it will
consolidate XSP standard.
The preprocess would
need too much knowledge about xsp markup in order not to try expanding
curlies inside xsp:logic, xsp:expr etc.
Curlies (should) are always expanded in the attribute values only - same as in
XSLT. No evaluation in any other place - so in this case it is very simple.
I think I was too terse to make myself understand. With in-text replacement
I meant
h1Hello {username}/h1
as shortcut for
h1Hello xsp:exprusername/xsp:expr/h1
I am against that because it risks to break too many existing XSP containing
curlies for whatever reason in text nodes. I am also -1 on activating that
feature on a per-page. Whilst I am all for improving XSPs I would want to
avoid creating a second dialect. (Of course a temporary safeguard as in [1],
with the intention to make it the default later, is okay.)
Also for the src={source} shortcut I am sceptic. It breaks when
you want to move your img content markup from XSP to logicsheet.
Please elaborate, what breaks and why?
I was just thinking of XSP as staging ground for code which later might be
moved to a logicsheet. One can move a sniplet like
img
xsp:attribute name=srcxsp:exprsource/xsp:expr/xsp:attribute
/img
unchanged from XSP and logicsheet whilst img src={source}/ needs to
be adaption.
But I had the misconception that there was the danger that in the logicsheet
it would silently generate img src=/. However, XSLT will signal source
as invalid expression to catch the error at compile time.
So I changed my mind and now, I am in favor of it.
But I agree that the xsp:attribute markup is too verbose. I'd rather
wish for the XSLT analogy:
xsp:attribute name=src value=source/
That can be trivially added - on top of what we have now. Not sure why it was
missing...
Vadim
Shall we add it then?
Here's my +1.
Cheers, Alfred.
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105783302326147
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: [RT] Block usage
-Original Message- From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 26. Mai 2005 15:42 To: dev@cocoon.apache.org Subject: Re: [RT] Block usage a block deployer block Basically the block deployer will be a stand-alone application (Ant task, Maven plug-in, Eclipse plug-in, ...). Of course somebody could write a web interface for it which could be a cocoon block. As you can see in my original message I proposed: a block deployer block, a block depoyer webapp block. Web interface and functinality should cleary be kept separately. Having read the OSGi whitepaper but not having followed in detail the discussion about the vision of real blocks, I am confused now. Aren't OSGi bundles already what Cocoon blocks want to be? Just package each block into a bundle with the right dependencies and deploy it into the OSGi kernel. What am I missing? Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [RFE] Some enhancements to XSP
-Original Message-
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 24. Mai 2005 23:53
To: dev@cocoon.apache.org
Subject: RE: [RFE] Some enhancements to XSP
On Mar, 24 de Mayo de 2005, 15:40, Nathaniel Alfred dijo:
Also for the src={source} shortcut I am sceptic. It breaks when
you want to move your img content markup from XSP to logicsheet.
But I agree that the xsp:attribute markup is too verbose.
I'd rather
wish for the XSLT analogy:
xsp:attribute name=src value=source/
Howto insert there some xsp:logic?
The only idea is to calculate the field value before. But
this will be OK?
Best Regards,
Antonio Gallardo
Sure, source must be a String assigned before in a xsp:logic.
In fact the value attribute could be any String valued Java expression.
If you don't mind the single-quotes:
xsp:attribute name=src value='request.getParameter(source)'/
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: [RT] Micro kernel based Cocoon
-Original Message- From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Sent: Dienstag, 24. Mai 2005 13:40 To: dev@cocoon.apache.org Subject: Re: [RT] Micro kernel based Cocoon Sylvain Wallez wrote: Daniel Fagerstrom wrote: Sylvain Wallez wrote: snip/ We should also consider if blocks should be _similar_ to Eclipse plugins, of if they should _be_ such plugins, which would remove us a log of work, both for code, docs and support. I have read some Eclipse docu, but it is not obvious to me what Eclipse plugins will help us more specifically with. Care to flesh out some more details? The extension point system can be of great value: a plugin declares an extension point (e.g. the core can declare a source-factory extension point), and plugins can provide contributions to this extension point (e.g. the JCR block will contribute a jcr: source factory). The source resolver can then know all protocols that are provided by plugins somewhere in the system. For this specific usecase, the URL service of OSGi could also be of interest. But in general extension points could be useful. AFAIU the plugin management stuff (download, update, etc) is specific, even if built on top of OSGi. Version management also. Ok. One one hand it is good to leverage on whats in Eclipse. OTH it seem to introduce quite a lot of bulk, even the platform download from Eclipse is some tens of MBs. Maybe one can use a much smaller part of Eclipse. To me it seem atractive to being able to chose between several implementations of OSGi and that e.g. the framework implementation from Knopplerfish starts at 200KB. /Daniel I'm afraid history is repeating itself. In my perception the Cocoon core dependency on Avalon/Excalibur was a major PITA even before the community breakdown. A separate community (although large overlap with Cocoon), separate release cycles, separate repository, separate agenda, ... Everytime I wanted to debug something I hit a wall with no way to get at the source code. Always a datestamped JAR with some private fixes, completely unreproducable. With Eclipse, Knopplerfish, Spring or other it might be the same and even worse because of the missing insider links. Instead of a micro kernel which is going to have again a large footprint to do anything useful I'd rather prefer a small kernel to do just what Cocoon needs. After all Cocoon is just a super-servlet which needs a bit of container services for managing component reuse and state information. We should not make it again the playground for container academics. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [RFE] Some enhancements to XSP
-Original Message-
From: Jochen Kuhnle [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 24. Mai 2005 13:45
To: dev@cocoon.apache.org
Subject: [RFE] Some enhancements to XSP
Hi, I know XSPs are supposed to go away, but I still like 'em... I would
like to propose some enhancements, and if they're accepted also volunteer
to implement them (including documentation and examples :).
1. A logicsheet for cache key control to have an easy way to override
getKey. Something like:
key
valuexsp:request-param name=userId//value
valuexsp:request-param name=companyId//value
/key
2. A logicsheet to do the same for getValidity, so you can do:
validity
file src=/etc/configfile/
expires seconds=3600/
/validity
Tags would be available for all classes in the distribution
that extend SourceValidity.
We are also heavy XSP users but up to now I never came around to try
caching. Do just want to generate the getKey/Validity methods or did
you forsee to have some sort of chaining/overriding mechanism?
3. A mechanism for expression replacement as in XSLT or JXTG, replacing
{expression} with a xsp:attribute element in attributes and with a
xsp:expr element in character data. This could be implemented in the
PreProcessFilter of XSPMarkupLanguage. The feature would be disabled by
default and enabled on a per-XSP-basis, maybe through a processing
instruction.
Example:
!-- Hey, this looks almost like JXTG :) --
img src={source} width={width} height={height}/
h1Hello {username}/h1
is more readable and easier to use than
img
xsp:attribute
name=srcxsp:exprsource/xsp:expr/xsp:attribute
xsp:attribute
name=widthxsp:exprwidth/xsp:expr/xsp:attribute
xsp:attribute
name=heightxsp:exprheight/xsp:expr/xsp:attribute
/img
h1Hello xsp:exprusername/xsp:expr/h1
Any comments? (I hope this hasn't been proposed already, but I
didn't find anything about it)
Don't think in-text replacement is a good idea. The preprocess would
need too much knowledge about xsp markup in order not to try expanding
curlies inside xsp:logic, xsp:expr etc.
Also for the src={source} shortcut I am sceptic. It breaks when
you want to move your img content markup from XSP to logicsheet.
But I agree that the xsp:attribute markup is too verbose. I'd rather
wish for the XSLT analogy:
xsp:attribute name=src value=source/
Regards,
Jochen
Looking forward to hear more from you.
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: Synchronization on session object (was svn commit: r169856 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java)
To quote Servlet spec SRV.7.7.3 Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time. I read that as Concurrent requests must be dispatched to the same JVM - otherwise all bets are off. So any upstream load balancing in a cluster must use some sort of session affinity, and in the same JVM the internalized session id is guaranteed to be unique. Cheers, Alfred. -Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: Montag, 23. Mai 2005 20:45 To: dev@cocoon.apache.org Subject: Re: Synchronization on session object (was svn commit: r169856 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/htt p/HttpRequest.java) On 13.05.2005 11:37, Nathaniel Alfred wrote: I think synchronized(session) should never be used as vehicle to coordinate concurrent requests because there is no convincing guarantee that it is always working as expected. Joerg, if you want to do it in your usercode, I don't mind, but please don't use it in common Cocoon code. My propesed alternative of synchronized(session.getId().intern()) may look obscure but at least it is guaranteed to work. I think we don't get a final answer to whether synchronized(session) is supposed to work or not. Your main concern seems to be complex environments like clusters. But how is session.getId().intern() supposed to work? Have the cluster nodes running by different JVMs and it does neither work. Or am I wrong? Joerg This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [IMP] synchronization on session object in Cocoon
You are proposing to pollute the container session with a parasitic
attribute. Even if the Serialable issue of that wrapper object was
solved, that is still a -1 for me. Let's keep the session clean!
Cheers, Alfred.
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 12. Mai 2005 18:27
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
In addition, I really don't like the implementation that was checked
in. Frankly, this is a case where I would look into leveraging
backport-util-concurrent
(http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent
/) if that
code can be made to work in JDK 1.3.
What I would look to do is to add the wrapper to a Map using
the session
id as the key, and then add an attribute to the session that is an
instance of a class that implements SessionBindingListener. Then when
the sessionDestroyed method is called the wrapper can be removed from
the Map.
Thus the Map would be the object being synchronized, such as
String id = serverSession.getId();
syncronized(map) {
if (!map.contains(id)) {
return (Session)map.get(id);
}
else {
Session session = new HttpSession(serverSession);
map.put(id, session);
return session;
}
}
Nathaniel Alfred wrote:
I have an implementation with map in HttpRequest and without
double-checked
locking idiom. Shall I commit it?
Joerg
I think there is a memory leak in
http://svn.apache.org/viewcvs?rev=169806view=rev.
There is a strong reference session.wrappedSession from
value to key in
// create new wrapper
session = new HttpSession(serverSession);
sessions.put(serverSession, session);
which causes the WeakHashMap to keep the entries forever.
See the Implementation Note in
http://java.sun.com/j2se/1.4.2/docs/api/java/util/WeakHashMap.html.
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: svn commit: r169856 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java
One must synchonize the put and get operation on the map itself
in order to protect its internal consistency.
Map map = Collections.synchronizedMap(new HashMap());
...
map.put(key, value);
...
value = map.get(key);
is just easier to read than
Map map = new HashMap();
...
synchronized(map) { map.put(key, value); }
...
synchronized(map) { value = map.get(key); }
although with just one get and one put the significance may be argued.
You don't want to replace the outer synchronized(serverSession) by
synchronized(sessions) because that blocks all threads without being
necessary (although the effect will be immeasurable).
You must have synchronized(serverSession) (or block all threads) to
avoid calling sessions.put twice for the same serverSession.
Cheers, Alfred.
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Freitag, 13. Mai 2005 01:51
To: dev@cocoon.apache.org
Subject: Re: svn commit: r169856 -
/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/envir
onment/htt
p/HttpRequest.java
Why is sessions a synchronized map if you are only
accessing it in a
block synchronized on the session. I would much prefer that you
a) not use a synchronized map
b) synchronize on the map instead of the session.
Is there a reason that this wouldn't work?
Ralph
[EMAIL PROTECTED] wrote:
Author: joerg
Date: Thu May 12 10:50:20 2005
New Revision: 169856
URL: http://svn.apache.org/viewcvs?rev=169856view=rev
Log:
fixed weak referencing (thanks to Alfred Nathaniel)
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/enviro
nment/http/HttpRequest.java
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/enviro
nment/http/HttpRequest.java
URL:
http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src
/java/org/apache/cocoon/environment/http/HttpRequest.java?rev=169856r1=169855r2=169856view=diff
==
---
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java
(original)
+++
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java
Thu May 12 10:50:20 2005
@@ -230,11 +230,11 @@
// synch on server session assures only one wrapper per session
synchronized (serverSession) {
// retrieve existing wrapper
-session = (HttpSession)sessions.get(serverSession);
+session =
(HttpSession)((WeakReference)sessions.get(serverSession)).get();
if (session == null) {
// create new wrapper
session = new HttpSession(serverSession);
-sessions.put(serverSession, session);
+sessions.put(serverSession, new WeakReference(session));
}
}
} else {
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The senders company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the senders
company.
RE: Synchronization on session object (was svn commit: r169856 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java)
-Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Freitag, 13. Mai 2005 08:57 To: dev@cocoon.apache.org Subject: Re: svn commit: r169856 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java You don't want to replace the outer synchronized(serverSession) by synchronized(sessions) because that blocks all threads without being necessary (although the effect will be immeasurable). Yes, I do. The alternative is to synchronize on the servlet container's session object, which could have far more horrifying results. Do you have any idea how that will impact the container? I don't because I cannot know. For all I know it is conceivable that doing that could cause a deadlock in some wierd scenario. I also fail to see how locking the map causes any more of a performance hit than locking the session. Since the map is only used by this one method its effect should be far less of an impact that locking the session. Besides, you ARE blocking all threads on the get and put anyway, since it has been declared a synchronized hash map. In fact, it is being done twice inside of a synchronized block. Global synchronization on sessions saves two lock operations and gives better single-threaded performance. Local synchronization on serverSession/sessions.get/sessions.put gives better multi-threaded concurrency. Both effects are really minute. I now tend to favour your proposal to use the global lock because is saves a lot of brain cycles during code inspection. However, I am amazed by your categoric opposition to locking the serverSession. The whole story started because Joerg wants to use the session object in order to coordinate concurrent requests belonging to the same session. I had a difference of opinion with him as well about the object identity guarantees in HttpRequest.getSession. I now read it up in the Servlet specs. Both 2.3 and 2.4 use the same wording in SRV.7.7.1 Threading Issues: Multiple servlets executing request threads may have active access to a single session object at the same time. The Developer has the responsability for synchronizing access to session resources as appropriate. That clearly states that synchronized(serverSession) is allowed and must be used when necessary. It does not settle my dispute with Joerg though. One may read the first sentence as Concurrent requests for the same session may happen and they must all be given the same session object. (Joerg) or as Concurrent requests for the same session *may* (but need not) be given the same session object. (Alfred) I think we agree that during the lifetime of a session it is not necessarily represented always by the same Java object. A clever container may move it to another cluster node or backing store, and can hardly be expected to restore it into the same object. If there is no guarantee that the session object stays the same between sequential requests, why should there be such a guarantee for concurrent requests? Even if the people doing the specs intended to provide that guarantee, there are still the implementators to read it the same way as I do or to mess it up. For example, in Tomcat's PersistenceManager I can't see any protection against two requests racing in swapIn and restoring the same session into two different Java objects. So it is a shakey assumption that the session object returned from the container can be used to coordinate concurrent threads. It works in normal environments but there is a small chance that it can fail for complex environments. I wouldn't bet my head on it. Now you may argue that Joerg is not using the container session but the Cocoon wrapper for which the hashmap guarantees that it is always the same Java object for the same session. Well, no, not really. It depends on how equals() is implemented by the container session object. If it does string compares of the session ids it is fine. If it inherits Object.equals, then you loose because the current version will produce a new wrapper for every session object. Since normally one does not need to compare session objects for equality I doubt that container implementers usually bother to override equals and hashCode. To be safe one should use the sessions.put(serverSession.getId(), session) but then I don't know anymore how to use weak references for solving the memory leak problem. And does the container react if the request uses a different session object than intended even if it represents the same session. Bottomline: I think synchronized(session) should never be used as vehicle to coordinate concurrent requests because there is no convincing guarantee that it is always working as expected. Joerg, if you want to do it in your usercode, I don't mind, but please don't use it in common Cocoon code. My propesed alternative of synchronized(session.getId().intern()) may look obscure
RE: Community health
-Original Message- From: Sebastien Arbogast [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 11. Mai 2005 23:16 To: dev@cocoon.apache.org Subject: Re: Community health Personally I think of mailing lists as really old-fashioned ways of communicate, all the more so as they are more and more often attacked by spam filters and as there is no way to moderate them and assess contributors' participation. That's why I don't really understand the reason why so many Open Source projects continue to use them instead of forums. It's so easy to use, so much easier to moderate and there are very few technical problems like spam blocking. Mailing lists may be old-fashioned but they are still the best instrument for neartime discussion between busy people. Personally I cannot imagine to browse a forum more often than maybe twice a week whilst my email inbox is open continously. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Re: [IMP] synchronization on session object in Cocoon
-Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke Sent: Donnerstag, 12. Mai 2005 11:16 To: dev@cocoon.apache.org Subject: Re: [IMP] synchronization on session object in Cocoon I have an implementation with map in HttpRequest and without double-checked locking idiom. Shall I commit it? Joerg I think there is a memory leak in http://svn.apache.org/viewcvs?rev=169806view=rev. There is a strong reference session.wrappedSession from value to key in // create new wrapper session = new HttpSession(serverSession); sessions.put(serverSession, session); which causes the WeakHashMap to keep the entries forever. See the Implementation Note in http://java.sun.com/j2se/1.4.2/docs/api/java/util/WeakHashMap.html. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [Vote] POJOfied Environment
Daniel Fagerstrom wrote: To simplify and make the environment handling in flow, jxtg, modules and possibly other places more coherent, I propose that we extend the Cocoon environment apis with some utility methods that makes the environment more reflection friendly. See http://marc.theaimsgroup.com/?t=11158198321r=1w=2 for motivation, discussion and technical issues. snip/ Please cast your votes: [+1] Go ahead and implement the environment extensions proposed above. [ ] Implement the environment extensions but use the *Map() syntax instead. [ ] Don't extend the environment. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [IMP] synchronization on session object in Cocoon
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
Sent: Dienstag, 10. Mai 2005 18:56
To: dev@cocoon.apache.org
Subject: [IMP] synchronization on session object in Cocoon
As you can see on every request a new wrapper is instantiated
which is really
bad. It is not possible to synchronize on Cocoon session
objects. What we
probably need is a Map mapping the server sessions to the
wrapper objects.
WDYT?
Joerg
-1
Servlet API [1] says Session information is scoped only to the current web
application (ServletContext), so information stored in one context will not be
directly visible in another. I read that as A new session object must be
create for requests in different contexts and may be create for requests in the
same context.
So the circumstances under which synchronized(session) works is dependent on
the servlet implementation.
But the String pool comes to the rescue. This should work for all sessions
within the same JVM:
synchronized(session.getId().intern()) {
...
}
Cheers, Alfred.
[1]:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/servletapi/javax/servlet/http/HttpSession.html
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: Re: [IMP] synchronization on session object in Cocoon
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
Sent: Mittwoch, 11. Mai 2005 13:50
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
...
But the String pool comes to the rescue. This should work for all
sessions within the same JVM:
synchronized(session.getId().intern()) {
...
}
That's not more than a work around IMO.
Furthermore your interpretation seems not to be common sense in Cocoon
project:
synchronized[ ]?\(session\) - 16 matches in project Cocoon 2.1.7
core:
org.apache.cocoon.Cocoon (1 match)
authentication-fw:
org.apache.cocoon.webapps.authentication.generation.Configurat
ionGenerator
(1 match)
portal-fw:
org.apache.cocoon.webapps.portal.components.PortalManagerImpl
(4 matches)
session-fw:
org.apache.cocoon.webapps.session.components.DefaultFormManage
r (2 matches)
org.apache.cocoon.webapps.session.components.DefaultContextManager (5
matches)
org.apache.cocoon.webapps.session.components.DefaultSessionMan
ager (1 match)
xsp:
org.apache.cocoon.components.xscript.XScriptManagerImpl (1 match)
org.apache.cocoon.components.language.markup.xsp.XSPUtil (1 match)
Joerg
AFAIKS is the purpose of the existing synchronized(session) bits to
protect the consistency of the session object in case it is shared
between parallel executing requests.
IIUC you need a lock object to really synchronize parallel requests.
There I'd say the session is the wrong candidate due to the mentioned
possible dependency on the servlet container.
I am just afraid that keeping the wrapped sessions in a private map
may introduce a memory leak. But maybe WeakHashMap would take care
of this...
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: Re: [IMP] synchronization on session object in Cocoon
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
Sent: Mittwoch, 11. Mai 2005 17:22
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
I have implemented the session attribute solution. Would be
nice if you can
review it:
public Session getSession(boolean create) {
// we must assure a 1:1-mapping of server session to
cocoon session
javax.servlet.http.HttpSession serverSession =
this.req.getSession(create);
if (serverSession != null) {
synchronized (serverSession) {
// retrieve existing wrapper
this.session =
(HttpSession)serverSession.getAttribute(HTTP_SESSION);
if (this.session == null) {
// create wrapper
this.session = new HttpSession(serverSession);
serverSession.setAttribute(HTTP_SESSION,
this.session);
}
}
} else {
// invalidate
this.session = null;
}
return this.session;
}
Looks good to me.
Cheers, Alfred.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: [IMP] synchronization on session object in Cocoon
-Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 11. Mai 2005 18:04 To: dev@cocoon.apache.org Subject: Re: [IMP] synchronization on session object in Cocoon Joerg Heinicke wrote: Sylvain Wallez sylvain at apache.org writes: Or more simply we could store the wrapper in the session itself using an attribute. That way it would be guaranteed to be created only once. Yes, that's another possibility I also had in mind. But on the one hand this smells a bit (storing a wrapper in the object that the wrapper wraps), on the other hand you can not restrict access to it, so it can be manipulated from somewhere else. But the Map solution can indeed be very resource consuming and a bottle neck. I am having second thoughts about the proposed solution. If the Cocoon session is stored as parasitic session attribute, the container can no longer serialize it for persistance or cluster replication. Not that one really needs to save/restore this particular attribute but it will cause nasty log messages at the very least. I think now that a private WeakHashMap (to leave session timeout to the container) should be the preferred solution. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Managing credits for contributors
-Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Montag, 9. Mai 2005 18:26 To: dev@cocoon.apache.org Subject: Re: Managing credits for contributors IMO status.xml and the svn logs serve different purpose. seriously? ...are the commit message much different from what is in the status.xml? I don't think so. ... ...I am always a big fan of as little maintenance as possible :) Of course it *does* require some discipline on the commit messages. Why not just do it the other way around? Formulate the status.xml entry such that it can be pasted as is into the commit message. If input from a non-committer was used, mention his/her name (as is already common practice today). I think it's futile to try anything more elaborate to have a fair appreciation of the importance of each individual contribution. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: How do I unsubscribe from this mailing list
-Original Message- From: Rajaneesh [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 4. Mai 2005 08:04 To: dev@cocoon.apache.org Subject: How do I unsubscribe from this mailing list How do I unsubscribe from this mailing list Send an emtpy mail to [EMAIL PROTECTED] and acknowlege the confirmation mail you will receive. HTH, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [VOTE] Removing author tags
-Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] Sent: Montag, 2. Mai 2005 23:53 To: dev@cocoon.apache.org Subject: [VOTE] Removing author tags So I propose to remove @author tags with people names from all our source files. +1 Additionally, if you agree with removing names, do you want source files to have: [x] no @author tag at all, [ ] @author The Cocoon development team [ ] @author . (something else) Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [PROPOSAL] Download of jars with Maven ant tasks
-Original Message- From: Leszek Gawron [mailto:[EMAIL PROTECTED] Sent: Montag, 25. April 2005 20:54 To: dev@cocoon.apache.org Subject: Re: [PROPOSAL] Download of jars with Maven ant tasks quote All of the tasks can optionally take one or more remote repositories to download from and upload to and a local repository to store downloaded and installed archives to./quote So in order to be totally safe we could introduce cocoon specific jar repository. -- Leszek Gawron +1 Would it be legally acceptable to link also to non-Apache licensed stuff? (Provided it is made available in a repository somewhere.) Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [VOTE RESULTS] Alfred Nathaniel as committer
I counted eighteen +1s and no other votes, welcome Alfred! -Bertrand With my account in the works, it's time to introduce myself. I am team leader of Internet Service Development at SWX Swiss Exchange. Our business unit SWX e-Services (current staff 18, half of them developers) is in charge of the corporate websites of SWX and a number of related companies. Our expertise lies in the processing of stock quotes and other financial data. In the old days we have been using mainly Perl CGIs and scripts for the generation of dynamic content. Beginning of 2002 I started looking at Cocoon. After a successful pilot to integrate a new Cocoon-based application into the existing website, Java and Cocoon became our technology of choice for all new developments. In the meantime more than 80% of our content volume, including the two biggest sites www.swx.com and www.eurexchange.com, are Cocoon-based, and the rest is scheduled to follow. For us XSP is still a key technology and I am hesitating to go the flowscript way for various reasons. With my SWX hat on the committership is therefore an important instrument to make sure that the XSP block stays production quality, even if declared legacy by the Cocoon avantgarde. Another professional itch is to optimize multi-threaded performance on 4-8 CPU servers. Among the more personal interests I hope to combine with Cocoon during my copious sparetime are Relax NG (to fight the evil XML Schema moloch), findbugs (to fight bugs which should not be), and automatic unit tests (to fight those annoying regressions). As non-committer I was always wondering at the long list of [PATCH] entries in Bugzilla. Now I better have a closer look whether I can't do something about that myself. Anyway, thanks to all you guys for creating Cocoon which makes my daytime job so much more interesting. I hope I am up to contributing to it a bit myself now. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [VOTE] Alfred Nathaniel as committer
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] So, I'm pleased to propose Alfred, should he accept the nomination, as a committer. Of course, my secret hope is that he will contribute many additional automated tests, but the committment is to the project, not to a particular task! Of course I am happy to accept the nomination, although currently only as privateer. The HtmlUnit contribution was a mental exercise I did on my copious spare time. Hopefully I can convince my bosses to back my committership also in the name of the company. At work we have been using Cocoon since almost 3 years and it has indeed become our strategic platform for developing and maintaining high-profile websites. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Directory layout problem with htmlunit tests
-Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] To solve this problem and clarify the different test categories, I propose to split them into disctinct directories : - src/test/internal for current junit tests - src/test/external for htmlunit tests. Using the external name rather than htmlunit leaves room for other external test tools such as httpunit. WDYT ? Sylvain Absolutely. Already to keep the junit-tests target working, I had to hack the batchtest to start off at test/org/apache to avoid picking up test/htmlunit. I didn't want to wrap that into the htmlunit patch but my proposal would have been later to move the component tests up one level: - src/test/htmlunit/org/... - src/test/junit/org/... but that's mainly because I prefer flat hierarchies. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Directory layout problem with htmlunit tests
-Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] I think the crucial bit you missed is embedded. Jetty is (aparently - I haven't yet tried) easy to embed into other Java apps. So, when the junit JVM stops, so does Jetty. Currently htmlunit requires a more advanced version of httpclient and Rhino than Cocoon allows. So you don't really want to run both in the same JVM. But what about simply having ant targets to start and stop jetty which are wrapped as dependendies around the htmlunit-tests target. cocoon.sh servlet would then become a synonym for build.sh start-cocoon. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Cocoon Hackathon at ApacheCon
[x] there is a chance I gonna make it Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: [IMP] Performance problems with TraxTransformer
Checking all dependencies sounds first to be the right thing to do but it can introduce a new performance bottleneck. Just think of a well structured hierarchy of stylesheets stored on a filer, where now the cache validity check requires dozens of NFS-stat calls. Caching on a production server is important but there must be also a possibility to flush the cache short of restarting the server. May I suggest to extend the TraxTransformer configuration to allow specifying a touchfile whose filestamp is checked for the validity mechanism. In production one can then use a global touchfiles to flush the cache manually whenever there might have been an update of a stylesheet. If needed, a finer granularity can be obtained by using application specific touchfiles. If the touchfile is not specified, it defaults to the root stylesheet - that is the effect of Carsten's current implementation. Cheers, Alfred. -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 29. Oktober 2003 10:05 To: [EMAIL PROTECTED] Subject: RE: [IMP] Performance problems with TraxTransformer Stefan Seifert wrote: Wouldn't it be better to extend the validity mechanism? When the master xslt does not change, the includes does not change either. It should be possible to use an extended validity object that, when parsing the xslt for imports/includes is finished, stores the modification date of the main xslt *and* the modification dates of all (recursivly) found depended XSLT pages as well. The validity check would have to check a couple of modification dates, but it is not needed to parse any XSLT again if it is not changed. I planned the implementation of such a mechanisme some time ago, but due to the lack of time i did not got very far. I hope to find the time in the next days/weeks, but i cannot promise anthing right now, unfortunately. Yes, that mechanism would work also and might be a little bit better from the user perspective. But of course, it makes the whole thing more complicated. Carsten This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: We still need the Pizza compiler?
The Eclipse compiler has not yet resolved the issue of generating larger bytecode than Pizza or Javac: https://bugs.eclipse.org/bugs/show_bug.cgi?id=38637 Last time I tried, Javac wouldn't work for XSPs, so Pizza seems to be the best shot for those borderline cases of complex XSPs. Please remove Pizza only, if Javac is a real alternative to Eclipse. Cheers, Alfred. -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Sonntag, 12. Oktober 2003 19:02 To: [EMAIL PROTECTED] Subject: We still need the Pizza compiler? Hi: I saw there is still the pizza compiler in lib/optional. It this compiler still needed? If not, can we remove it from the distribution? Best Regards, Antonio Gallardo. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Woody - Validation of 2 fields to be equals....
-Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 16. Juli 2003 07:31 To: [EMAIL PROTECTED] Subject: Woody - Validation of 2 fields to be equals How to make Woody to validate 2 fields when the 2 fields can have the same value to be correct. For example the tipical case of: New password: Retype the new password: Woody's wd:assert construct allows to validate constraints between fields. See http://wiki.cocoondev.org/Wiki.jsp?page=WoodyNotes for more. HTH, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
SourceResolver in M3 and symbolic links
The latest version of excalibur.source.SourceResolver packaged with Cocoon-2.1m3 normalizes URIs containing /foo/../bar to /bar. At first sight this looks a good idea and is according to RFC 2396. But when dealing with file: URIs foo can be a symbolic link (aka short-cut) such as foo - some/where/else. Following filesystem semantics, /foo/../bar results in /some/where/bar. Used with care this can be a powerful feature, which got lost now. (My setup is currently royally screwed due to that.) So is file:/foo/../bar going to stay a URI as per RFC 2396, or shall we have an exception to suppress the segment/.. normalization step for file:. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
