>-Original Message-
>From: Ralph Goers [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 12. Januar 2005 17:30
>To: dev@cocoon.apache.org
>Subject: Re: [VOTE] Creation of a french-speaking users list
>As far as the list goes, I'm generally OK with it but it makes me
wonder
>what happens when some
[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, pleas
Sylvain Wallez wrote:
> So I propose to remove src/core and move all its content to src/java.
Good idea also on purely technical grounds. When importing a snapshot of the
Cocoon sources as vendor branch into CVS one has to do some special gymnastics
to avoid that the "core" directory falls vic
> -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.
>
> Usi
> -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 adva
> 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
> 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
> -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
>
>
> All of the tasks can optionally take one or more remote
> repositories to download
> -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 agre
> -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
>-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 differen
> -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 re
> -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
>
> -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 y
>-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 apache.org> writes:
>>
>>>Or more simply we
>-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
>-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-checke
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.th
n.getId();
> syncronized(map) {
> if (!map.contains(id)) {
> return (Session)map.get(id);
> }
> else {
> Session session = new HttpSession(serverSession);
> map.put(id, session);
> return session;
> }
> }
>
&g
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();
...
synchron
> -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 rep
ache.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
> coor
> -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:
> >>
> >>
> >
>-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 i
> -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 f
>-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:attribut
>-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-i
> -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. Th
> -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
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
> -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 "}".
> -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 t
>-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 a
>-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 'publi
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/ja
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 informatio
> 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
> 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 confidentialit
-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 compati
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
> 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 mist
> -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:
> >
> >> Ma
> 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 n
> 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 r
> 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 re
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
>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 o
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:
> [
-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-Bapti
>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 no
> 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 c
> 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 re
> 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 privil
Wouldn't it make sense to put the jars back into SVN that a checkout
itself is used as the local master M2 repository?
Distributions for user installation could still be kept small by
downloading there dependencies from a public M2 site at build time.
Cheers, Alfred.
This message is for the na
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+
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
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
+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!
Thi
> 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 pri
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 styl
The head of 2.1 contains a new WildcardMatcherHelper [1] to replace the
rather obscure WildcardHelper [2] implementation. WMH is now used for
matching wildcard patterns in map:match.
Although the code is a lot clearer than WH, it is still very complex
logic. A number of bugs in the original WM
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
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
>Re: code reuse. I'm quite eager too reuse code, usually, but I'm -1 on
>adding another JAR (and another dependency) only for 30 lines of code.
>
> Ugo
The 30 lines are already in an available JAR, only normalize() is
currently private there:
http://cvs.apache.org/viewcvs.cgi/avalon-excali
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
> -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
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
ompared 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 1
> 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 mistran
+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
> 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'
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
72 matches
Mail list logo
