Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Can anybody tell me where to get the daisy-maven-plugin please?
Sorry, should be fixed now.
You only need the Daisy plugin, when you build the documentation as desribed at
Daniel Fagerstrom wrote:
What about reversing the logic: Instead of
map:match pattern=test5
map:generate type=servletService src=test.html
map:parameter name=service
value=servlet:test2:/extract-html/
/map:generate
map:serialize type=xml/
/map:match
we could use
map:match
Daniel Fagerstrom wrote:
hmm, the src attribute of generators desribes, what is feed into the
component. In the case of a servlet service generator, the output
stream of a servlet is used as stream input.
Rather something that is transformed to SAX output.
The data parameter defines the
[moving over a discussion from [EMAIL PROTECTED] to [EMAIL PROTECTED]
Bruno Dumon wrote:
Which also makes me think of it: the Cocoon zone is still running Daisy
1.5. I could do the upgrade, but I'm not sure on the impact this might
have. The maven plugin should be easy to upgrade, but I think
I'm currently working on the our build system and it might happen that it is
temporarily broken. I'll let you know when it is stable again.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
hepabolu wrote:
Reinhard Poetz said the following on 10/5/07 09:33:
[moving over a discussion from [EMAIL PROTECTED] to [EMAIL PROTECTED]
Bruno Dumon wrote:
Which also makes me think of it: the Cocoon zone is still running Daisy
1.5. I could do the upgrade, but I'm not sure on the impact
hepabolu wrote:
I don't see a reason why we need the namespace in our published URLs
at all. The Daisy plugin could cut them off.
Sure, and I'm all for cutting it off, but in Daisy the namespace is
there so backlink from the published page should go to the namespaced
version.
Now:
Daisy:
Grzegorz Kossakowski wrote:
Alexander Klimetschek pisze:
Grzegorz Kossakowski schrieb:
I only wonder why you did put docs in wiki instead of Daisy? I
believe that all the tips should be part of our documentation. Is my
assumption wrong anyhow?
I cannot edit daisy and find the Wiki easier
Reinhard Poetz wrote:
I'm currently working on the our build system and it might happen that
it is temporarily broken. I'll let you know when it is stable again.
done.
I created a profile daisy that contains everything which is necessary to
create our site. This has the advantage
Alexander Klimetschek wrote:
Hi Reinhard,
although it's a full webapplication and not a live site, it would be
cool to have Mindquarry (http://www.mindquarry.com - The OpenSource
Collaborative Software) listed as using Cocoon 2.2-dev on
Grzegorz Kossakowski wrote:
snip/
What do you think?
IIUC there are two use cases for servlet services: They can be used from within
Cocoon using special sitemap components or from outside using the http protocol.
Whatever the best solution for passing environment data is, is it possible
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
snip/
What do you think?
IIUC there are two use cases for servlet services: They can be used
from within Cocoon using special sitemap components or from outside
using the http protocol. Whatever the best
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Actually, HTTP protocol is always used in service calls but
components just hide low-level details of HTTP and integrate calls
with pipelining model. In current (and basic) state of implementation
one could call
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
* I noticed the cocoon-maven-plugin is at 1.0.0-M1-SNAPSHOT while the
rest of trunk seems to be talking about 1.0.0-RC1-SNAPSHOT, any
compelling reason?
I want to see more user feedback before we release a RC because doing
all those
Marc Portier wrote:
Reinhard Poetz wrote:
Marc Portier wrote:
Reinhard Poetz wrote:
I've started to split up our tutorials into smaller pieces in order to
make them more comprehensible:
* Your first Cocoon application using Maven 2
* Your first XML pipeline (publishing
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
As long as the fallback mechanism as described by you above works, I
don't see a problem with your solution.
I'm little puzzled with your resposne, I was talking about fallback
mechanism only for passing SAX events.
What other fallback
Marc Portier wrote:
Reinhard Poetz wrote:
Marc Portier wrote:
Reinhard Poetz wrote:
Marc Portier wrote:
Reinhard Poetz wrote:
I've started to split up our tutorials into smaller pieces in
order to
make them more comprehensible:
* Your first Cocoon application using Maven 2
hepabolu wrote:
[EMAIL PROTECTED] said the following on 8/5/07 00:09:
+tt {
+font-size: 1.3em;
}
Reinhard,
it's best to keep the font sizes in percentages to keep things
consistent. The only em value is in the body selector.
thanks, I will change this ASAP (if you don't beat me).
--
I've created two pages that need the assistance of everybody who wants to get
listed there:
- Blog
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g1/1272.html
- Professional Services
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g1/1271.html
Do we have any procedures for
Marc Portier wrote:
Reinhard Poetz wrote:
I've started to split up our tutorials into smaller pieces in order to
make them more comprehensible:
* Your first Cocoon application using Maven 2
* Your first XML pipeline (publishing)
* Modularize Cocoon apps (Using blocks
Grzegorz Kossakowski wrote:
Hi,
Henri Yandell has just informed that he upgraded Maven to 2.0.6 on
vmbuild machine so Continuum is usable for us, again.
It seems that currently no build happens at all because maven is runned
in non-recursive mode. Do you know why it's done that way and how
I've started to split up our tutorials into smaller pieces in order to make them
more comprehensible:
* Your first Cocoon application using Maven 2
* Your first XML pipeline (publishing)
* Modularize Cocoon apps (Using blocks)
* Deploying a Cocoon application
Additionally we
Felix Knecht wrote:
I don't think it's a specific problem only for e.g. ageci filters. I can
reproduce the same error in a different way:
snip/
Understand. As already explained in a previous email, I think that we need a
wrapper around the actual app context. This wrapper will simulate that
Hipkiss JR (Mr) wrote:
Hi,
Can someone help me regarding which are the latest docs and how can I
contribute to them?
I started with http://cocoon.apache.org/2.1/ but the link at the bottom
of these pages to edit the docs points to the Daisy Legacy docs.
Then there's the Wiki at
Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
Now this seems to me that some changes with the RCL prevents third
party servlet filters to access
the ApplicationContext, or am I wrong?
no, that's my interpretation of the stacktrace
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
Reinhard Poetz wrote:
I've had some more thoughts about this and I believe that we don't need
to go that far. We only have to make sure that all servlets, filters and
listeners
Grek,
Andrew (OsX) and I (Win32) run into a problem with current trunk. It's
reproducible with the block archetype. Are you aware of any changes that causes
this:
javax.servlet.ServletException: Unable to read Avalon configuration from
'sitemap.xmap'.;
nested exception is
Carsten Ziegeler wrote:
Is this bug caused by the latest source resolver or by some of the
changes in Cocoon?
yes, unfortunatly it is. I reverted sourceresolve to 2.2.1 in our root pom.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open
Reinhard Poetz wrote:
I will provide a configuration parameter that switches of reloading.
You can use
configuration
reloadingSpringEnabledfalse/reloadingSpringEnabled
/configuration
now in order to deactivate the reload of the Spring application context.
This doesn't switch off
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm still trying to migrate my project from deployer to rcl plugin with no
success (and now not even
the old one works) :-(
Reinhard Poetz wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
BTW: Can we have a released
Giacomo Pati wrote:
Reinhard Poetz wrote:
The second one allows patching the web.xml by adding snippets from
META-INF/cocoon/xpatch to it. It also supports a feature that reverses
the classloader hierarchy in a web application by using a shielding
classloader.
But can only be used if packaging
Giacomo Pati wrote:
Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
Reinhard Poetz wrote:
The second one allows patching the web.xml by adding snippets from
META-INF/cocoon/xpatch to it. It also supports a feature that reverses
the classloader hierarchy in a web application
Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
Is it ok to set the path back to what it was or did you had some
reason to change it?
some time ago we decided to have all or stuff under META-INF/cocoon. I
don't think that this should be an exception, shouldn't it?
Ok.
Sure
Reinhard Poetz wrote:
Giacomo Pati wrote:
BTW: Can we have a released deployer plugin as well.
I think that Cocoon should only have one Maven plugin with as many goals
as needed. Hence I propose that we merge the deployer and the reloading
classloader plugin into a single one
Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
Now this seems to me that some changes with the RCL prevents third
party servlet filters to access
the ApplicationContext, or am I wrong?
no, that's my interpretation of the stacktrace too
Any pointers?
The problem
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
BTW: Can we have a released deployer plugin as well.
I think that Cocoon should only have one Maven plugin with as many goals
as needed. Hence I propose that we merge the deployer
Andrew Savory wrote:
Hi,
On 1 May 2007, at 12:47, [EMAIL PROTECTED] wrote:
Author: reinhard
Date: Tue May 1 04:47:14 2007
New Revision: 534018
URL: http://svn.apache.org/viewvc?view=revrev=534018
Log:
keep the old maven plugins easily accessible
for some time
Added:
Grzegorz Kossakowski wrote:
I'm not sure why svn merge produced this changes. Do they harm and should be
reverted?
no, please merge them.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
Grzegorz Kossakowski wrote:
Reinhard Poetz napisaÅ(a):
Giacomo Pati wrote:
BTW: Can we have a released deployer plugin as well.
I think that Cocoon should only have one Maven plugin with as many goals
as needed. Hence I propose that we merge the deployer and the reloading
classloader plugin
Reinhard Poetz wrote:
Giacomo Pati wrote:
BTW: Can we have a released deployer plugin as well.
I think that Cocoon should only have one Maven plugin with as many goals
as needed.
I've done the work (sorry Andrew that I committed at the wrong moment) today. I
successfully run mvn clean
Giacomo Pati wrote:
Reinhard Poetz wrote:
This problem doesn't seem to be rcl related but I'm not sure. Will you
attend at the ApacheCon next week?
No, I will not be there.
I've started to merge the deployer and the rcl plugin. I suggest that we debug
from there again as soon as I'm able
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
BTW: Can we have a released deployer plugin as well. I know it will be
deprecated but there are
projects using it and the last released version is functional not the
same as the one
Alexander Klimetschek wrote:
Grzegorz Kossakowski schrieb:
That's weird. Any clue about that?
The problem is a missing HTTP status code when the response is
committed. This happens due to Reinhard's change for the dynamic setting
of the status code (see below), that I just got when updating
Reinhard Poetz wrote:
Alexander Klimetschek wrote:
Grzegorz Kossakowski schrieb:
That's weird. Any clue about that?
The problem is a missing HTTP status code when the response is
committed. This happens due to Reinhard's change for the dynamic
setting of the status code (see below), that I
Reinhard Poetz wrote:
There was some discussion off-list when the next series of C22 modules
will happen. I plan to do the release work next week but have to spend
the next two days on fixing things here and there and to get the 2.2
documentation online because I don't want to release
Andrew Savory wrote:
Hi,
Following up on the thread about archetypes etc, I'd love to hear from
others on how they are approaching application building with 2.2 and
what they see as 'best practise' - primarily because I'm concerned that
the route the current setup sends people down might
Giacomo Pati wrote:
The fact is that it is annoying that I have to add all those repositories to my
project block pom.
As soon as there are official releases of commons-jci and xreporter, we don't
need them anymore.
Adding the repoitory above leads to a missing
Giacomo Pati wrote:
BTW: Can we have a released deployer plugin as well.
I think that Cocoon should only have one Maven plugin with as many goals as
needed. Hence I propose that we merge the deployer and the reloading classloader
plugin into a single one:
cocoon:deploy . provides
Giacomo Pati wrote:
BTW: Can we have a released deployer plugin as well. I know it will be
deprecated but there are
projects using it and the last released version is functional not the same as
the one currently in
trunk. And I've also tried to switch to the rcl plugin with no success.
How
Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
BTW: Can we have a released deployer plugin as well. I know it will be
deprecated but there are
projects using it and the last released version is functional not the
same as the one currently in
trunk. And I've also tried to switch
Helma (and others),
I created a small module (tools/cocoon-daisy-export-strategy) that provides our
Cocoon specific customization strategies for the Daisy export plugin.
It contains a Java class that gets called for each extracted document. Using it
you get a chance to apply any transformation
Alexander Klimetschek wrote:
Hi all,
I am currently debugging and fixing
https://issues.apache.org/jira/browse/COCOON-2044, and I want to know if
it is feasible to configure multiple caches, one for each sitemap?
You can configure the cache-role for each pipeline.
--
Reinhard Pötz
[
https://issues.apache.org/jira/browse/COCOON-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinhard Poetz reassigned COCOON-2047:
--
Assignee: Reinhard Poetz
StatusGenerator shows a list of Spring beans
[
https://issues.apache.org/jira/browse/COCOON-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinhard Poetz reassigned COCOON-1354:
--
Assignee: Reinhard Poetz (was: Cocoon Developers Team)
[Patch] status-code
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all
I'm trying to test the new poms (without version element in dependencies
section). But it seem trunk
dosn't build. It say it misses
org.daisycms:daisy-java-adapter:jar:1.0.0-SNAPSHOT
Do I have to switch any
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all
I'm trying to test the new poms (without version element in
dependencies section). But it seem trunk
dosn't build. It say
[
https://issues.apache.org/jira/browse/COCOON-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinhard Poetz closed COCOON-2047.
--
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
patch applied. thanks Alexander
Grek, what was your intention with this change? Since the status-code property
stops working, I reverted your change.
[EMAIL PROTECTED] wrote:
Author: reinhard
Date: Thu Apr 19 06:28:04 2007
New Revision: 530409
URL: http://svn.apache.org/viewvc?view=revrev=530409
Log:
we can't set the
Giacomo Pati wrote:
The repository definition had to be in the repositories section. Now I can build trunk.
That's funny :-/ I did a mvn install with an empty repository today without any
problems.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Grek, what was your intention with this change? Since the status-code
property stops working, I reverted your change.
My intention was to have http status code set in every case. Before this
change, if serializer (or other component) did
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Grzegorz Kossakowski wrote:
In short: reverting my change will break caching of servlet: source in
some
cases.
currently, the status code is set in the SerializeNode class and has the
default value of -1. Changing this to 200 would
[
https://issues.apache.org/jira/browse/COCOON-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489796
]
Reinhard Poetz commented on COCOON-2044:
Actually the XSLT transformer supports all our protocols AFAIK
There was some discussion off-list when the next series of C22 modules will
happen. I plan to do the release work next week but have to spend the next two
days on fixing things here and there and to get the 2.2 documentation online
because I don't want to release anything that we label
Andrew Savory wrote:
I suppose it's all relative. Those big scary mvn lines make it seem like
a lot, even if it isn't. And what you end up with is a template
application, and not a template publishing framework.
The emphasis with the demo is to show content from a Spring bean, and
not for
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
That wasn't much of a hard work. The harder work will come next. I
thought making it the same way:
an XSLT that filters out all version elements from the dependencies
(and probably
Alexander Klimetschek wrote:
I commented out all the cocoon deps in the root pom's
dependencyManagement section and a -Dallblocks build runs through
(CachingSourceTestCase still disabled).
when I checked in, all tests run through (started with Maven or Eclipse) but
will have a look at it
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
That wasn't much of a hard work. The harder work will come next. I
thought making
Andrew Savory wrote:
Hi,
Trying to do a clean build of C2.2 I'm seeing errors building
cocoon-javaflow because of a missing
org.apache.commons:commons-jci-core:jar:1.0-RC1.
jci-core 1.0-SNAPSHOT seems to be commented out of cocoon-core. The
below fixes it and allows c2.2 to build, but as I
Giacomo Pati wrote:
Ok, so just for readybility. Do you use the eclipse XML-Formatter?
no, I use OxygenXML but I do the formatting by hand. Basically I add empty lines
between the different sections and try to move the important parts to the top
(though it could be discussed what important
Giacomo Pati wrote:
That wasn't much of a hard work. The harder work will come next. I thought
making it the same way:
an XSLT that filters out all version elements from the dependencies (and
probably from the plugins
sections as well). WDYT
Please make sure that the xslt transformation
Grzegorz Kossakowski wrote:
first, thanx you for the work!
4. go to block/cocoon-forms and make a svn switch:
svn switch
https://svn.apache.org/repos/asf/cocoon/whiteboard/ajax-forms-refactoring/cocoon-forms/
Why is that needed? If I do mvn install at the refactored projects, the new
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Grzegorz Kossakowski wrote:
4. go to block/cocoon-forms and make a svn switch:
svn switch
https://svn.apache.org/repos/asf/cocoon/whiteboard/ajax-forms-refactoring/cocoon-forms/
Why is that needed? If I do mvn install at the refactored
Ralph Goers wrote:
Giacomo Pati wrote:
I'v committed an initial dependencyManagement section in the root pom.
The deps were gathered by concatenating all relevant poms into a big
xml document and run through an
xsl stylesheet which extracted all dependencies sorting them by
artifactId
Arje Cahn wrote:
Hi all,
Please cast your votes on both the location and the time for this year's Cocoon
GetTogether conference:
A) The Netherlands, Amsterdam
+0,5
B) Italy, Rome / Milano
+1
C) England, London / Norwich
+0,5
When:
A) Late september
-1
B) Beginning of October
Ralph Goers wrote:
Get rid of the versions in all the poms. Create a dependencyManagement
section in the root pom. Add all Cocoon dependencies to the
dependencyManagement section and specify the version there.
Could this be automatized? Doing this by hand sounds like an awful lot of work
to
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
I also had some idea that the shielding stuff seem to be rather
orthogonal to the servlet service stuff. So maybe it would be better
to reimplement it as an interceptor that is applied before
Ralph Goers wrote:
Given the number of projects in Cocoon I'm sure it is.
Just for grins run mvn -P allblocks dependency:analyze. It will take a
while but has tons of useful output.
As an example, I've shown part of it below. You can see that
commons-logging 1.1 is used as a transitive
Alexander Klimetschek wrote:
Reinhard Poetz schrieb:
After thinking more about this, I believe that one main distinction is
that cocoon-rcl creates an environment which is used at development
time. Alex' solution is used in production too, IIUC.
It's actually not that important to have
Ralph Goers wrote:
Reinhard Poetz wrote:
If we use the dependency management section in our root pom, what will
happen when we release one of our modules? Is the version information
used and added to the dependency or is the fallback to the parent's
pom depdencyManagement section still
Ralph Goers wrote:
Well, it is actually quite a bit worse than this. The below was actually
from running mvn idea:idea. After doing mvn -Dmaven.test.skip=true -P
allblocks install I ended up with 7 different version of xercesImpl, 3
versions of xerces and xalan, 5 versions of maven-artifact
Max Pfingsthorn wrote:
Hi everyone,
I've been looking at trunk to find out how things work these days and
it looks great, but I am a bit confused. It seems like the blocks can
register their own servlet to handle requests, is that true?
yes There is
a suspicious xml file in
Daniel Fagerstrom wrote:
I also had some idea that the shielding stuff seem to be rather
orthogonal to the servlet service stuff. So maybe it would be better to
reimplement it as an interceptor that is applied before the servlet
service proxy.
+1
--
Reinhard Pötz Independent
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
I also had some idea that the shielding stuff seem to be rather
orthogonal to the servlet service stuff. So maybe it would be better
to reimplement it as an interceptor that is applied before the
servlet service proxy
Grzegorz Kossakowski wrote:
Joerg Heinicke napisał(a):
On 07.04.2007 15:10, Grzegorz Kossakowski wrote:
Why not? What should be different about this block?
As I'm still in administration mode I'll do it now. I do not see any
reason to keep shared, either.
Don't hesitate to remove any
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
the only thing which is 'broken' compared with 2.1
is logging.
... which forces the user to recompile. Do we want or do we have to accept this?
Although the change is a very simple one, it would be better to have
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
the only thing which is 'broken' compared with 2.1 is logging.
(I meant logkit - log4j, as well as lost URI and other information
which makes it really hard to read log files)
... which forces the user to recompile
As discusses with Ard and Peter (http://marc.info/?t=11756324784r=1w=2), I
patched EHDefaultStore and MRUMemoryStore:
action dev=reinhard type=fix
MRUMemoryStore registers at StoreJanitor only in that case, if StoreJanitor
is set as dependency. Assuming that in many cases the
Alexander Klimetschek wrote:
Hi all!
I want to use spring-2.0.3, but although all cocoon poms in trunk now
reference 2.0.3, the dependency to cocoon-spring-configurator in release
version 1.0.0 still pulls in 2.0.2, so effectively that older one is used.
Now I changed the dependency to
Jorg Heymans wrote:
Reinhard Poetz wrote:
The limiting factor is that nobody has done it yet. It would be great
if you create the artifact and put it into the Apache snapshot repo.
Then we have some time to test it and if everything works fine, Marc will
I've created a 1.3-SNAPSHOT off
Leszek Gawron wrote:
Reinhard Poetz wrote:
Rice Yeh wrote:
Hi,
Here is another problem when using servlet protocol. A servlet S1
extends another servlet S2. A web continuation k is generated in S2.
When k returns back, k is matched in S1 with match pattern
*.continue which exists in S2
Reinhard Poetz wrote:
As discusses with Ard and Peter
(http://marc.info/?t=11756324784r=1w=2), I patched EHDefaultStore
and MRUMemoryStore:
I think we need further discussions what the default behaviour should be
(registration at StoreJanitor or not). If we want to change something, we
Vadim Gritsenko wrote:
When we are going to stop block sharing, again?
as soon as somebody does the actual work of replacing svn:externals with real
stuff. Two months ago we agreed that we do it at the end of March and then
release 2.1.11.
--
Reinhard Pötz Independent Consultant,
Reinhard Poetz wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
Rice Yeh wrote:
Hi,
Here is another problem when using servlet protocol. A servlet S1
extends another servlet S2. A web continuation k is generated in S2.
When k returns back, k is matched in S1 with match pattern
[
https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486579
]
Reinhard Poetz commented on COCOON-1425:
Does session replication work for you as expected? Have you been
Rice Yeh wrote:
Hi,
Here is another problem when using servlet protocol. A servlet S1
extends another servlet S2. A web continuation k is generated in S2.
When k returns back, k is matched in S1 with match pattern *.continue
which exists in S2 also. Then comes an error with message like k
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
problems
[
https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486589
]
Reinhard Poetz commented on COCOON-1425:
The problem is that the Continuations object has object references
[
https://issues.apache.org/jira/browse/COCOON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486601
]
Reinhard Poetz commented on COCOON-1425:
I believe that Javaflow would be the best bet to use continuations
Ard Schrijvers wrote:
snip/
- introduce a maxPersistentObjects parameter and use it in
EHDefaultCache to set maxElementsOnDisk
+1
that's easy
- make the registration of stores at StoreJanitor configureable
(Though I wonder what the default value should be, true or false?)
0 : I
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 IMO is best for configuration, and tricks to
avoid the
601 - 700 of 2579 matches
Mail list logo
