Please cast your votes:
here's mine +1
+1
-Ard
--
Best regards,
Grzegorz Kossakowski
Apart from the link-rewrite block he will also migrate the
webdav block.
Any thoughts or recommendations on this? The plan is that all
Avalon components are migrated to Spring and that Jackrabbit
is used as webdav server.
I remember Jasha and Jereon have started to work on
Dear community,
it's a great honor for me to propose Steven Dolg as a committer.
+1
-Ard
David Crossley wrote:
I would like to propose Luca Morandini as a new Cocoon
committer and
PMC member.
+1 from me.
+1
-Ard
-David
I propose Andreas Hartmann as a new Cocoon committer and PMC member.
+1
-Ard
I propose Thorsten Scherler as a new Cocoon committer and PMC member.
+1
-Ard
the 2.1 days... :-). So if it makes the
architecture of the blocks better, you ahead
-Ard
Regards,
Lukas
Ard Schrijvers schrieb:
Hello Lukas,
Sry for my late respond
Hello,
I'm wondering, why the eventcache block has dependencies
on the JMS
block and not the other way round
Hi,
It's my pleasure to propose Jasha Joachimsthal as a new
committer on the Apache Cocoon project.
My unbiased +1
-Ard
Hello Lukas,
Sry for my late respond
Hello,
I'm wondering, why the eventcache block has dependencies on
the JMS block and not the other way round?
I do not know what you would win by switching the dependency around. JMS
seems to me more uncoupled from eventcache then eventcache to jms.
Now that the vote to switch to a more recent baseline JDK
has passed,
I'd like to upgrade to ehcache 1.3.0, which gives us nicer shutdown
and jmx instrumentation.
+1 (Please, please)
+0, we are using JCSCache anyway :-). Hopefully you can configure
ehcache 1.3.0 its maximum disk
Usually, if unsubscribe to a list doesn't work it's because
one's trying to unsubscribe from a different address than the
one used to subscribe.
For more info, send a message to [EMAIL PROTECTED] -
that includes a command to unsubscribe a different address
than the sender's.
Indeed:
Hello,
Unfortunately, I am not aware about Cocoon 2.2.x specific
(event)caching, but will it use a similar caching strategy as Cocoon
2.1.x or is this still under discussion? Also, I am not sure wether the
webdav block, or event validities will be used/supported in Cocoon
2.2.x. If not, this mail
To be honest, I don't care about caching or how complex it
is. It has
to work and it does it nicely in Cocoon. If your name isn't
Ard ( ;-)
:-)
) you usually don't need to know more details. And that's
what it is
as Vadim pointed out: implementation details.
My name is not
[
https://issues.apache.org/jira/browse/COCOON-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549394
]
Ard Schrijvers commented on COCOON-2153:
slide is closed so updating the slide webdav client
[
https://issues.apache.org/jira/browse/COCOON-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546223
]
Ard Schrijvers commented on COCOON-2152:
Since you found the problem my comment from COCOON-2146 can
[
https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545761
]
Ard Schrijvers commented on COCOON-2146:
Presumably though, if site-usage is fairly uniform, stuff
[
https://issues.apache.org/jira/browse/COCOON-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545763
]
Ard Schrijvers commented on COCOON-2151:
I commented on COCOON-2146, I'll repeat my text over here
[
https://issues.apache.org/jira/browse/COCOON-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545767
]
Ard Schrijvers commented on COCOON-2151:
Only if you're generating lots of unique pages or short-lived
[
https://issues.apache.org/jira/browse/COCOON-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545809
]
Ard Schrijvers commented on COCOON-2151:
The problem with (1) is that it did not work for me for ehcache
[
https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545962
]
Ard Schrijvers commented on COCOON-2146:
H, I am really confident that persistent caches with the event
Sorry Grek, that I supplanted you. I only saw on closing the issue
that you actually assigned it to you. I hope you don't mind :-)
Grzegorz Kossakowski wrote:
No problem, Jörg! I assigned it to myself because I thought
that the issue was trivial but recent comments confused me
[
https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545506
]
Ard Schrijvers commented on COCOON-2146:
FYI : IMO, the AbstractDoubleMapEventRegistry is a very bad
Vadim Gritsenko wrote:
Have you seen this part?
return key == null? I: I + key;
}
I never realized this specifically, but used to solve it similar (see
below)
All you need to do is to pass in extra key:
map:match pattern=main
map:generate src=someXML.xml/
Ralph Goers wrote:
Actually, this may be exactly the reason my developer
couldn't get the IncludeTransformer to work. I'll have to
have hime take a look at it again.
If he still has problems let me know, I might be able to help you out.
Regards Ard
Ralph
Hello,
Grzegorz Kossakowski wrote:
Could you elaborate on the known differences between CInclude
and Include transformers? Was it discussed somewhere?
I am not sure if it was ever discussed somewhere, but I can elaborate a
little on it ( though it has been a while, so I might be a little off
AFAIU, the
IncludeTransformer can only be cached by defining some
Above is ofcourse a typo...I was talking about the CIncludeTransformer
which can only be cached by some expires...
expires. Clearly, you cannot really know how to set this, or
if you fetch an external http source, just
Vadim Gritsenko wrote:
Indeed. I think this is a failure on CocoonSource part.
CocoonSource content depends on the sitemap.xmap, but
CocoonSource validity does not include validity of the
sitemap. As a result, even if sitemap is changed,
CocoonSource validity stays valid.
I'm not
Hi all,
Please cast your votes on both the location and the time for
this year's Cocoon GetTogether conference:
A) The Netherlands, Amsterdam
-1
B) Italy, Rome / Milano
+10
C) England, London / Norwich
-100 :-)
When:
A) Late september
+1
B) Beginning of October
Ard Schrijvers wrote:
Yes, this is exactly my point. The extra problem is that
the StoreJanitor
never has access to the eviction policy of the cache, and
just starts
throwing out entries at random.
That's incorrect statement. I'd say that StoreJanitor always
has access
IIUC, EHCache allows you to set only the number of items in
cache, and not the
maximum amount of memory to use, or minimum amount of free
memory to leave.
true (but the cache can't know the size of objects it gets stuffed with (you
say it is possible with java 1.5? ) )
In other
Vadim,
I think you are reasoning from a POV of the cocoon cache, but I think you are
in the minority compared to the number of users which are using EHCache.
I tried to explain the inevitable OOM of the StoreJanitor in combination of
EHCache and
the event registry in a high volume site.
Strictly speaking, you don't need access to the eviction
policy itself - but
only some exposed method on Store, something like
purgeLastElementAccordingToEvictionPolicy -- can't they add
something like that?
I of course did ask this, because this is obviously the way to go:
Configurable Store registration with StoreJanitor alleviates
somewhat that
problem, but not solves completely as you still have to
properly configure all
your cache sizes correctly to avoid OOM.
I think you can try combining Cocoon's MRU cache and EHCache
to get best of both
Reinhard Poetz wrote:
P.S. Ard, answering to your mails is very difficult because
there are no
I am very sorry...I hardly dare saying i am using outlook :-)
I'll try to find a way in the stupid program for linebreaks or make the switch
to Thunderbird.
Ard
line breaks. Is
Reinhard Poetz wrote:
P.S. Ard, answering to your mails is very difficult because
there are no
line breaks. Is anybody else experiencing the same problem
or is it only
me?
Jörg pointed me to the rewrap function of Thunderbird.
Using it fixes all my
problems with never
Ard Schrijvers wrote:
Reinhard Poetz wrote:
P.S. Ard, answering to your mails is very difficult because
there are no
line breaks. Is anybody else experiencing the same problem
or is it only
me?
Jörg pointed me to the rewrap function of Thunderbird.
Using it fixes all my
AFAICS there are two freeing algorithms in trunk: round-robin
and all-stores.
I already thought it would be something like this
/snip
and this is IMO one of the major weakenesses of ehcache (or I
missed it
completely), I did not find any way to limit the number of
disk store
I suggest that we don't register them at StoreJanitor by
default anymore but
make it configureable for users who rely on it in their custom Store
implementations/configurations.
+1
AFAIU, StoreJanitor only runs if at least one store is
registered so we don't
have to remove it.
On 4/4/07, Reinhard Poetz [EMAIL PROTECTED] wrote:
Ard Schrijvers wrote:
yes please, I would be interested in more comments too! Are
more comments like in wiki or in the cocoon.xconf more
comment for different configurations?
I can try to write extended documentation on what
Hello,
Ard Schrijvers wrote:
i would be glad to share the code and my ideas, for example
about this whole
StoreJanitor idea :-) )
Just curious, what did you mean by this whole StoreJanitor idea?
Before I say things that are wrong, please consider that the StoreJanitor was
invented
/snip
?? my mail got sended by accident :Sfinishing it now
be implemented quite easily, but might take long start up times)
6) JCSCache has a complex configuration IMO. Therefor, I
added default configurations to choose from, for example:
store logger=core.store
parameter
Ard
[1] https://issues.apache.org/jira/browse/COCOON-1619
Could you Ard use e-mail client that is standard compliant
and produces
valid In-Reply-To headers? It's second time this week I have to raise
this issue (and I really don't like doing it) but it's really crucial
for me
several requests on the users list) I want to propose to move it to
cocoon-core.
+1
Ard
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log):
Reinhard Poetz wrote:
I propose making the status code attribute of serializers
expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
+1. Should have actually been there right from the start!
big +1
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in the serializer, like:
map:serialize type=xhtml pragma={cache} cache-control={cache}
I would like to store in a variable wether I am dealing with something that is
not
Ard Schrijvers wrote:
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in
the serializer, like:
map:serialize type=xhtml pragma={cache}
cache-control={cache}
I would like to store in a variable wether
Ard Schrijvers napisał(a):
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in
the serializer, like:
map:serialize type=xhtml pragma={cache}
cache-control={cache}
I would like to store in a variable
Hello,
regarding the cache-expires and async thing in the cachingsource block, there
are some things that are strange and seem bugs to me:
1) The expires value is always -1 (eternal), no matter what you define in the
queryString. You can see this happen in getSource of the
This if statement checks if a parameter starts with
cocoon:cache and if yes,
it add it to the params object and removes it from the
normal request
parameters. It looks fine for me and the expires value is set
correctly at the
source AFAICS. BTW, I'm working on trunk.
Yes I saw
Hello Reinhard,
The repository block contains a the CachingSource. Does
anybody have experiences
with it?
Yes, we do have a lot of experience with it (though we have a slightly
different version (Max Pfingsthorn changed it: the public SourceValidity
getValidity() returns an
yes, the broken connection scenario is that what I want. If
you say that it
doesn't really fit into the caching source, what do you
propose instead?
It does fit in the current caching source without touching the caching source I
think :-)
Writing
another source wrapping source
Hello,
http://www.mindquarry.org/repos/mindquarry-jcr/trunk/mindquarr
y-jcr-source/
I'd say add it to the cocoon-jcr block but maybe one of the
original authors of
the jcr block can give some comments.
And various components:
- RunningModeDependentPipeline: (Pipeline)
to
Please cast your votes.
my unbiased +1!!
Ard
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/
Sourcesense: http://www.sourcesense.com/
Please cast your votes!
+1!
Ard
--
Reinhard
___
Telefonate ohne weitere Kosten vom PC zum PC:
http://messenger.yahoo.de
Please cast your votes.
+1
Ard
/Daniel
Hello,
Ard Schrijvers wrote:
snip/
This is actually almost the same hack we used, but
instead of a transformer a selector, and if some value set in
flowscript, an action to set headers. Because we are
outsourcing/other parties using our best practices, and I
did not want them
Hello,
Ard Schrijvers wrote:
is there any best practice to have cforms in urls you do not know on
beforehand, with continuations?
Continuation is just randomly generated token, unique to each user
interaction (like as session Id). Even if it is cached, even
if GET is used
If it's for CForms, we can add the setting of no-cache headers in
Form.js since it's very unlikely that a form pipeline will be
cacheable.
Think we tried similar things (in flowscript), but we found
the problem Bertrand also faced about the fact, that you have
to set the
--
Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel +31 (0)20 5224466
-
[EMAIL PROTECTED] / http://www.hippo.nl
--
-Original Message-
From: Sylvain Wallez
Hello,
now we are talking about httpd mod_cache already, is there any best practice to
have cforms in urls you do not know on beforehand, with continuations? For
high-traffic sites, we obviously want to use mod_cache, but, at the same time,
mod_cache shouldn't cache pages with a continuation
Hello Bertrand,
For high-traffic sites, we obviously want to use mod_cache,
but, at the same time,
mod_cache shouldn't cache pages with a continuation in it
The problem is making the HTTP cache headers variable according to
which pipeline is executed.
But, in principle, you
Hello,
Cocoon 2.1.9 introduced the concept of a lock in
AbstractCachingProcessingPipeline, an optimization to prevent
two concurrent requests from generating the same cached
content. The first request adds the pipeline key to the
transient cache to 'lock' the cache entry for that
.
Ard Schrijvers wrote:
Hello,
Cocoon 2.1.9 introduced the concept of a lock in
AbstractCachingProcessingPipeline, an optimization to prevent
two concurrent requests from generating the same cached
content. The first request adds the pipeline key to the
transient cache to 'lock
(and the aggregate thing), and your solution
Have fun!
I doubt it :-)
Ellis.
Regards Ard
Ard Schrijvers wrote:
Hi,
The crux is that the sub-pipeline is called twice within the
context of
the master pipeline (once by the root pipeline, once by an
include);
thus the pipeline
in here..
Ard
On Mon, 2007-01-08 at 10:30 +0100, Ard Schrijvers wrote:
Hello,
think I kind of missed this WildcardMatcherHelper untill
now. From which cocoon version on is this available? Can you
define in your matcher wether it should use this
WildcardMatcherHelper
Sry for the delay.
Shall I commit the StripNameSpaceTransformer to
trunk/core/cocoon-pipeline/cocoon-pipeline-components/./transformation , or
is there a more preferable location? Should I also add it to the branch?
Ard
1) The lightweight StripNameSpaceTransformer ... Add
this
Ard Schrijvers skrev:
Sry for the delay.
Shall I commit the StripNameSpaceTransformer to
trunk/core/cocoon-pipeline/cocoon-pipeline-components/./tr
ansformation , or is there a more preferable location? Should
I also add it to the branch?
Seem like a reasonable place
On 1/3/07, Ard Schrijvers [EMAIL PROTECTED] wrote:
...Not sure wether it is common practice to create a jira
issue for it when committing
something new and resolve it?...
I don't think it's common practice here but IMHO it's a Good Thing.
Locally we added this svn 'pre-commit' hook
1) The lightweight StripNameSpaceTransformer ... Add
this to trunk/branch or not?
If no objections, I'll add my version of the StripNameSpaceTransformer to the
trunk/branch on short notice
+1
2) The XHTML serializer: Make it by default strip the list of
namespaces we know people
Hello PIotr,
I am double posting your message because it is clearly meant for the [EMAIL
PROTECTED]
There are some threads already on this at
http://marc.theaimsgroup.com/?l=xml-cocoon-usersr=1w=2
Also why we discourage the use of doc() in xsl, and point to include or
cinclude transformer,
Recapitulating this thread:
1) The lightweight StripNameSpaceTransformer is an option to strip intermediate
namespaces you want to get rid of (like after sql transformer, I would like to
get rid of them as fast as possible). Add this to trunk/branch or not?
2) The XHTML serializer: Make it by
You should add an extra stylesheet that removes superfluous namespace
attributes. This is what I've done:
I used to use this strategy as well, though recently I replaced this xsl
transformer with a custom StripNameSpacesTransformer (about just 10 lines),
which outperforms the slow xsl
...I replaced this xsl transformer with a custom
StripNameSpacesTransformer
(about just 10 lines), which outperforms the slow xsl
transformation a factor 30...
This would be useful to have in Cocoon, go for it!
I thought it was too trivial :-)
Will add it to trunk/branch
Ard
Hello,
I am wondering if there is anybody using the cocoon eventcache block (without
using hippo jars), or are planning to do so in the future?
Regards Ard
--
Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel +31 (0)20 5224466
Joerg Heinicke wrote:
Yes, that should be the way to go. Furthermore (if it is
possible) you
should add a dependency on the xmlutil issue to the Cocoon
issue, so
that we get informed when xmlutil is fixed.
Yes that sounds about right to me. Create the ticket and I'll
see to
[
http://issues.apache.org/jira/browse/COCOON-1909?page=comments#action_12441677
]
Ard Schrijvers commented on COCOON-1909:
The bug is in XSLTProcessorImpl in public javax.xml.transform.Source resolve(
String href, String base
On 10/11/06, Antonio Gallardo [EMAIL PROTECTED] wrote:
...IMHO, we should leave open this bug, because the fixi is
not finished
yet until we update excalibur...
Same here. If update excalibur is a Jira or bugzilla issue
somewhere, I'd make a link or a dependency to it to indicate
So please cast your votes!
--
+1, welcome!
--
Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel +31 (0)20 5224466
-
[EMAIL PROTECTED] / http://www.hippo.nl
--
Leszek Gawron escribió:
If user wants to make JXTG automatically cacheable he/she must
explicitly state it in configuration:
map:generator src=org.apache.cocoon.template.JXTemplateGenerator
automatic-cache-key
use-sitemap-parameterstrue/use-sitemap-parameters
[
http://issues.apache.org/jira/browse/COCOON-1909?page=comments#action_12433063
]
Ard Schrijvers commented on COCOON-1909:
The problem is a little more sophisticated then depicted above:
First of all, the TraxTransformer allows you
This has come up a few times before, independent of it being used in
hibernate's session factory.
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110846153823635w=2
This problem now seems to be on the ehcache list as well:
Ard Schrijvers wrote:
[ snip ]
Ard, if you accept your nomination, please get familiar with
http://www.apache.org/dev/new-committers-guide.html and send
your signed CLA to the ASF Secretary.
The secretary recorded your CLA late last week, so now
ready to go
Ard Schrijvers wrote:
I did not know all this, and addressing it in this way to
the dev list might not be the most appropriate way :S. All I
need to know now, is how I can reach the correct person, from
infrastructure I suppose, that the issue can be resolved.
Try
Ard Schrijvers wrote:
Hello,
everybody using mirror http://apache.cs.uu.nl/ in his maven
build.properties should be aware of downloading wrong jars.
There seem to be strange rewrite rules configured, which
rewrites you a couple of times when you want to download
certain jakarta
everybody using mirror http://apache.cs.uu.nl/ in his maven
build.properties should be aware of downloading wrong jars. There
seem to be strange rewrite rules configured, which rewrites you a
couple of times when you want to download certain jakarta
jars, and
then just
is recorded
as Ard Schryuers ... is that correct?
Is it hard to change is into Ard Schrijvers :-)
Please also let us know which user id you prefer and what
your forwarding email address is.
Please provide that info to private AT cocoon.apache.org
Alternative committer IDs too please
About the broken mirror http://apache.cs.uu.nl/, I was premature: The flaw
seems to be way more serious, and seems to be apache-dist/jakarta/.htaccess in
general!
Ard,
you are spreading disinformation.
In dist/jakarta there is a .htaccess file that does the redirects.
You can check
/snip
And, in defense, our building needs to be empty by tomorrow
afternoon.
Renovation, reconstruction, network upgrade etc. It's a mess
over here
right now! I was surprised he found the time to respond, and so soon!!
I did not know all this, and addressing it in this way to the dev
Hello,
everybody using mirror http://apache.cs.uu.nl/ in his maven build.properties
should be aware of downloading wrong jars. There seem to be strange rewrite
rules configured, which rewrites you a couple of times when you want to
download certain jakarta jars, and then just downloads
Hello,
the ehcache-1.2 version currently in branch_2_1_X needs to be updated to
ehcache-1.2.2. The 1.2 version has a problem that the spool thread dies
(happened for me every few days, leaving your ehcache effectively being a
memoryStore only: it is as if overflow-to-disk=false).
Updating to
!
Reinhard Poetz wrote:
I want to propose Ard Schrijvers as a new Cocoon committer.
People who
followed our mailing lists will find _many_ quality answers
to users
questions. But that's not all: Ard is an expert for
well-cached Cocoon
applications. His latest work on caching
On 8/1/06, Ard Schrijvers [EMAIL PROTECTED] wrote:
(Quantification of spatiotemporal phenomena resulting from
reaction-diffusion processes was my project...
Wow! Looks like we'll have to keep you busy to prevent you from
writing a QuantificationOfSpatiotemporalPhenomenaTransformer
Hello,
+1, much simpler to implement, much simpler to use, no hidden
side effects.
Ard, you carrying this out? :) :)
Yes, I will try, but I have some doubts/questions/ideas that I would like to
share and find the best solution to implement this new janitor:
1) I will try to implement
of cocoon community) have any other idea about
this? Continuation pollution is actually a problem in flow
implementations.
I do not have any ideas that you haven't pictured above :-)
Regards Ard
Simone
Ard Schrijvers wrote:
Hello Simone,
talking about continuations, did you already find
The third option aims to solve the common situation of having a flow
that initializes some variables, sends a form or a page (creating a
continuation) and then waits for the user to click on a
button, that 90%
of time never gets pushed. This is quite common in
aggregated pages with
snip/
So, in the StoreJanitor, I check now wether the store is
instanceof EHDefaultStore,
That's a really bad idea, in and by itself. Never rely on concrete
implementations, always work against contracts (interfaces).
Ok. I try and see if there is another way to get this in. I
snip/
IMO the only way to solve this transparently is to more accressively
expire and limit the number of continuations. It would make sense to
come up with a LRU list of continuations per session. This list has a
maximum size that can defined. So the required maximum can is
predictable.
Ard Schrijvers escribió:
/snip
If there are better alternatives to ehcache we should
consider them of
course. Personally I would like that this work will be
done in trunk
only. We could build an own maven project for each cache
implementation
which will reduce
Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.9
Reporter: Ard Schrijvers
Priority: Critical
The excalibut store interface defines a size() method for a store:
/**
* Returns count of the objects in the store, or -1 if could
[ http://issues.apache.org/jira/browse/COCOON-1885?page=all ]
Ard Schrijvers updated COCOON-1885:
---
Attachment: EHDefaultStore.patch
Fix for EHDefaultStore returning wrong number in the size() method
The EHDefaultStore returns in the size() method
1 - 100 of 130 matches
Mail list logo
