Rice Yeh schrieb:
Thank you for your solution. But I still feel weird for a brand new request
being created for a called block (servlet), at least for a super block
(servlet). Having a look at the source code, each new brand request and
response are supposed to be stored in its call frame
Reinhard Poetz wrote:
Reinhard Poetz wrote:
Because of dependencies on the event-cache block, the caching source
was added to the repository block when it moved out from scratchpad.
After some refactorings I should be able now to move it to cocoon-core
without having to add any new
Hi Servlet Hackers,
I am switching from our old block servlet config to the current servlet
services in trunk and have problems with the configuration. I have two problems:
1)
I changed the spring configuration to look like the following snippet, but I
get an exception (see below).
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
Further debugging shows that the method ServletFactoryBean.getObject() is
called by Spring (DefaultListableBeanFactory.getObjectFromFactoryBean(...))
*before* the embeddedServlet or any other property was set. So
embeddedServlet is null, which makes the code inside getObject() fail:
Oh, I got it: there was a circular dependency in the servlet connections (A
using B, B using A as super). It did work with the old block servlets, but
now you get the very unhelpful exception. I don't think we actually need
this circular connection in particular. But generally, two solutions
Alexander Klimetschek napisał(a):
Oh, I got it: there was a circular dependency in the servlet connections
(A using B, B using A as super). It did work with the old block
servlets, but now you get the very unhelpful exception. I don't think we
actually need this circular connection in
Handle circular dependencies in servlet connections
---
Key: COCOON-2036
URL: https://issues.apache.org/jira/browse/COCOON-2036
Project: Cocoon
Issue Type: Bug
Components: - Servlet
Grzegorz Kossakowski schrieb:
My opinion is that circular dependencies should not be allowed and I
agree that more meaningful exception is needed here.
We do need the circular dependency: the basic principle is a super block
that runs cforms that are mainly defined in a child block - the
Ard Schrijvers wrote:
Before I say things that are wrong, please consider that the StoreJanitor was
invented long before I looked into the cocoon code, so probably a lot of
discussion and good ideas has been around which I am not aware of. But still, my
ideas about the StoreJanitor (and sorry
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 [1] and put it in
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 ending lines. Thanks
Alexander Klimetschek napisał(a):
Grzegorz Kossakowski schrieb:
We do need the circular dependency: the basic principle is a super
block that runs cforms that are mainly defined in a child block - the
model lies in the child block and it contains a selection-list whose
source is
14 matches
Mail list logo
