Good idea. I tried this, but failed.
When my component is looked up, I try to fetch the objectModel (to get the
context as you suggested). Therefore I implement Contextualizable:
public void contextualize(Context context) {
Map objectModel = ContextHelper.getObjectModel(context);
I'm sorry, I still don't completely get it. I assume that SessionData is the
class that implements HTTPSessionBindingListener?
So you call getInstance() during login, which adds the component
(SessionData) to the Session. It will then be notified, when it is unbound
from the session, which allows
Dear Cocooners,
I would like to start rejuventating the webdav block. We have some code to do
cool things like event caching and a more general purpose WebDAVTransformer
(which can also do propfind, proppatch, etc).
If you know anything you would like to see in the webdav block, please say so
On 12/16/05, Max Pfingsthorn [EMAIL PROTECTED] wrote:
Dear Cocooners,
I would like to start rejuventating the webdav block. We have some code to do
cool things like event caching and a more general purpose WebDAVTransformer
(which can also do propfind, proppatch, etc).
If you know
Hi cocoon-ers,
Few days ago I updated groovy and asm. I also replaced excalibur-io
with commons-io. But this changes are not showed here:
http://cocoon.zones.apache.org/demos/21branch/samples/status.html
Help! :-)
Seriously, somebody can take care of this? Thanks in advance.
Best Regards,
Le 16 déc. 05, à 16:10, Antonio Gallardo a écrit :
...Few days ago I updated groovy and asm. I also replaced
excalibur-io with commons-io. But this changes are not showed here:
http://cocoon.zones.apache.org/demos/21branch/samples/status.html
Found the problem in
Ralph Goers wrote:
Thanks Vadim. I'm posting this back to the Cocoon list as it seems what
you are telling me is that the problem is either with the XMLFileModule
or with running out of components in the pool on the pipeline being
invoked.
What I am not clear on is what you are trying to
* Stefan Pietschmann:
When my component is looked up, I try to fetch the objectModel (to get the
context as you suggested). Therefore I implement Contextualizable:
public void contextualize(Context context) {
Map objectModel = ContextHelper.getObjectModel(context);
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
As far as pools go, I feel like a complete idiot. See my comments below.
Vadim Gritsenko wrote:
Ralph Goers wrote:
Thanks Vadim. I'm posting this back to the Cocoon list as it seems
Bertrand,
Thanks for fixing the demo site.
Bertrand Delacretaz wrote:
Le 16 déc. 05, à 16:10, Antonio Gallardo a écrit :
...Few days ago I updated groovy and asm. I also replaced
excalibur-io with commons-io. But this changes are not showed here:
Le 16 déc. 05, à 17:12, Antonio Gallardo a écrit :
...Found the problem in
http://cocoon.zones.apache.org/logs/cocoon-demos/21branch/stderr.log:
I was not aware we have this link. It is great!
BTW is this stderr or stdout? ;-)
This is stderr, see the links to all logs in the yellow box at
Also, Do you know why Document helper is declared static?
Ralph
Vadim Gritsenko wrote:
I've not looked into pool source code yesterday to double check all
points myself. I'm suggesting you to check:
* What type of pool is really used
* Why it is blocking (I guessed it is blocking due
* Max Pfingsthorn:
I would like to start rejuventating the webdav block. We have
some code to do cool things like event caching and a more
general purpose WebDAVTransformer (which can also do propfind,
proppatch, etc).
If you know anything you would like to see in the webdav
Ralph Goers wrote:
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
It's *good*. You don't really want several threads trying to load *same*
document.
It's not perfect though. I see that XMLFileModule, when used in conjunction with
Ralph Goers wrote:
Also, Do you know why Document helper is declared static?
DocumentHelper *class* is static. Why it should not be?
Vadim
SVN)
Reporter: Jean-Baptiste Quenot
Attachments: 20051216-continuationsmanager, contierror
Build Cocoon without any block.
When starting Cocoon with cocoon.sh cli there is an error:
NoClassDefFoundError javax/servlet/http/HttpSessionBindingListener, see error
log attached. The attached
Vadim Gritsenko wrote:
Ralph Goers wrote:
Also, Do you know why Document helper is declared static?
DocumentHelper *class* is static. Why it should not be?
Just never seen it before the way it is being used. After reading about
it I guess it is OK.
Vadim
Jorg Heymans wrote:
Andreas Hochsteger wrote:
But how would it be possible to say that the samples block depends on
any implementation which implements a certain API, like the roles
are used in Cocoon today? For example, my-block-samples-block needs
an XSL:FO processor but does not
Vadim Gritsenko wrote:
Ralph Goers wrote:
Also, Do you know why Document helper is declared static?
DocumentHelper *class* is static. Why it should not be?
Is DocumentHelper an inner class? If so I agree, all that the static on
a class means is that the inner class can (should?) be in
Ralph Goers wrote:
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
As far as pools go, I feel like a complete idiot. See my comments below.
Vadim Gritsenko wrote:
Ralph Goers wrote:
Thanks Vadim. I'm posting this back to the Cocoon
Vadim Gritsenko wrote:
Ralph Goers wrote:
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
It's *good*. You don't really want several threads trying to load
*same* document.
It's not perfect though. I see that XMLFileModule, when
Berin Loritsch wrote:
Vadim Gritsenko wrote:
Ralph Goers wrote:
My guess is that the requests are simply coming in faster than
XMLFileModule is taking to release the lock.
That's not important, IMHO. Problem is in pool's lock, not
XMLFileModule's lock.
Are you sure?
90% sure. Have a
Vadim Gritsenko wrote:
http-8080-Processor17 daemon prio=1 tid=0x2e3d58c8 nid=0x19eb waiting
for monitor entry [2d7f3000..2d7f587c]
at
org.apache.avalon.excalibur.pool.ResourceLimitingPool.get(ResourceLimitingPool.java:262)
- waiting to lock 0x60088180 (a java.lang.Object)
...
The only
Vadim and Berin,
Thank you both for your assistance. We got past this. The problem was
actually simple. The XMLFileModule was configured with reloadable false
and cacheable false. Since this file is read at the beginning of every
user session it was causing a huge bottleneck. After
On Friday 16 December 2005 00:53, Jorg Heymans wrote:
well it's not just the cocoon artifact i'm talking about. Various of our
dependent libs aren't on ibiblio yet, so i uploaded them to
cvs.apache.org.
Ok. But even better if you coordinate with the Maven peeps, so that everyone
else gets
Sorry for not getting back to you sooner. I was swamped doing some
performance tuning.
I am using the authentication-fw and I have my own generator that calls
our authentication component and then generates the appropriate XML
response. During that proces the getInstance() is called. I also
Ralph Goers wrote:
snip/
Glad it worked out.
However, I still have a feeling that holding the lock while checking the
validity will create some contention in our usage since multiple threads
do want to read the file simultaneously.
Yup; try this delay validity idea.
If you want to fly
27 matches
Mail list logo
