Gabriel Gruber wrote:
Hi Joe,
well, I don't have a replayable scenario yet (f.i. testcase), but it
seems that the exception comes after heavy use of cocoon pages within
our application.
I suspect that cocoon:/ protocol usage AND/OR inheritence of sitemap
calling (we extend
Reinhard Pötz wrote:
Gabriel Gruber wrote:
Hi Joe,
well, I don't have a replayable scenario yet (f.i. testcase), but it
seems that the exception comes after heavy use of cocoon pages within
our application.
I suspect that cocoon:/ protocol usage AND/OR inheritence of sitemap
calling (we
Hello comunity,
I found a serious bug in JNET / servlet service framework in our cocoon
2.2 based application. After some time the following Exception pops up and
the only way to resolve is to restart the web application...
java.lang.NullPointerException
Hi Gabriel,
Very strange to have that exception there!
When does it happen? Is it predictable?
Kind regards,
Jos
On Tue, 2010-02-02 at 19:44 +0100, Gabriel Gruber wrote:
Hello comunity,
I found a serious bug in JNET / servlet service framework in our
cocoon 2.2 based application. After
(since then no changes have been comitted).
The problems reported here (exact same problem we have)
http://jira.dspace.org/jira/browse/DS-253?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
suspects that some classes within SSF are not threadsafe?
best regards,
Gabriel
Hi all,
I have problems to configure two cocoon blocks, where one is a
descendant of the other (via the special super connection) as
described in [1]. Following the description there I would expect that
accessing an URL block1/testURL, for which no matcher in the block1s
sitemap exists, should be
to say what wrong is going on here. Have you checked cocoon logs? I
believe SSF logs quite a
lot of information about its super attempts.
Also, full stack-trace for 404 http error would be helpful.
--
Grzegorz Kossakowski
concept looks
correct. Actually, it's
hard to say what wrong is going on here. Have you checked cocoon logs? I
believe SSF logs quite a
lot of information about its super attempts.
You expect sth like
INFO servletservice.ServletServiceContext - Enter processing in servlet
service super
Alexander Daniel wrote:
In October 2007 SSF did not support passing SAX events directly from one
block to another and also caching was not supported. I did some research
on the web site and in the users and dev mailing list but I can't find a
clear statement whether these issues have already
In October 2007 SSF did not support passing SAX events directly from
one block to another and also caching was not supported. I did some
research on the web site and in the users and dev mailing list but I
can't find a clear statement whether these issues have already been
addressed
Hi All,
Consider this pipeline matcher:
map:match pattern=xq/*/-/**
map:generate type=servletService src=cocoon:/list-
category-tag.xq
map:parameter name=service
value=servlet:exist:/db/feeds/{1}/entries?terms={2}/
/map:generate
map:serialize
Hi Robin
Robin Wyles schrieb:
Hi All,
[...]
So, my questions are
a) Should ServletSource be encoding the URL it receives ? I would've
thought probably not...
just my personal opinion: No. It would cause SSF to treat URLs different from
other protocols.
matching happens on de-coded URLS
On 6 May 2008, at 12:59, Rainer Pruy wrote:
Hi Robin
Robin Wyles schrieb:
Hi All,
[...]
So, my questions are
a) Should ServletSource be encoding the URL it receives ? I would've
thought probably not...
just my personal opinion: No. It would cause SSF to treat URLs
different from other
Yepp,
Hi,
Reading with interest this thread [1] and wondering how it might
relate to my situation...
I have a servlet (eXist XML DB) mounted as a block and would like
dependent blocks to use http basic auth when calling it via SSF. Each
dependent block will have its own username
be such a solution.
Grzegorz: I've just read the AOP-approach. I like the idea, but agree that a
generic (configureable) solution would be nice, since such usage-scenarios
could be refined to patterns (e.g. special SSF-beans, already proxied or the
like). Of course, bloat something up should
: Carsten Ziegeler [EMAIL PROTECTED]
An: users@cocoon.apache.org
Betreff: Re: SSF
Cocoon-auth is very simple and dates back to the early days of Cocoon. I
suggest to have a look at Spring Security (acegi) - it picked up most
of the ideas of cocoon auth, but provides much much more in a better way
Patrick Heiden schrieb:
Hi Carsten!
I would love to use acegi, but the acegi auth-block sample is not running (got
a fresh trunk 5 days ago). Any further references on howto come to grasp with
acegi inside cocoon?
Hi Patrick,
no, sorry, I never used it in real live :) But as Cocoon is
Patrick Heiden schrieb:
Hi Carsten!
I would love to use acegi, but the acegi auth-block sample is not
running (got a fresh trunk 5 days ago). Any further references on howto come
to
grasp with acegi inside cocoon?
Hi Patrick,
no, sorry, I never used it in real live :) But as
Patrick Heiden schrieb:
Patrick Heiden schrieb:
Hi Carsten!
I would love to use acegi, but the acegi auth-block sample is not
running (got a fresh trunk 5 days ago). Any further references on howto come to
grasp with acegi inside cocoon?
Hi Patrick,
no, sorry, I never used it in real live :)
that a
generic (configureable) solution would be nice, since such usage-scenarios
could be refined to patterns (e.g. special SSF-beans, already proxied or the
like). Of course, bloat something up should not be in goal-direction.
I am still left on my way to auth so far,
best greetings
Patrick
Hi,
Reading with interest this thread [1] and wondering how it might
relate to my situation...
I have a servlet (eXist XML DB) mounted as a block and would like
dependent blocks to use http basic auth when calling it via SSF. Each
dependent block will have its own username and password
be refined to patterns (e.g. special SSF-beans,
already proxied or the like). Of course, bloat something up should
not be in goal-direction.
I am still left on my way to auth so far,
best greetings
Patrick
-
To unsubscribe
. I like the idea, but agree
that a generic (configureable) solution would be nice, since such
usage-scenarios could be refined to patterns (e.g. special SSF-beans,
already proxied or the like). Of course, bloat something up should
not be in goal-direction.
I am still left on my way to auth so
Vadim Gritsenko wrote:
On Mar 26, 2008, at 5:19 PM, Luca Morandini wrote:
... though... why is it returning every document in sight, instead of
limiting itself to the *.jx ones ?
map:match pattern=pages.xml
map:generate type=xpathtraversable src=blockcontext:/
On Mar 27, 2008, at 4:31 AM, Luca Morandini wrote:
Vadim Gritsenko wrote:
On Mar 26, 2008, at 5:19 PM, Luca Morandini wrote:
... though... why is it returning every document in sight, instead
of limiting itself to the *.jx ones ?
map:match pattern=pages.xml
map:generate
Hello together!
What should one do, if he/she wants to let all requests get routed through a
mainController block first and therefor disabling direct calls to connected
blocks (registered at some mount-path)?
Best regards
Patrick
--
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der
On Mar 27, 2008, at 10:36 AM, Patrick Heiden wrote:
What should one do, if he/she wants to let all requests get routed
through a mainController block first and therefor disabling direct
calls to connected blocks (registered at some mount-path)?
Sounds like you want to 'mount' a block from
Vadim Gritsenko wrote:
On Mar 27, 2008, at 4:31 AM, Luca Morandini wrote:
So, it seems the correct behavior, given my setup, would be: add
*.jx files to the known list of XML resources within the depth of 4
and perform the XPath query.
I think you just need to set
On Mar 27, 2008, at 12:16 PM, Luca Morandini wrote:
Vadim Gritsenko wrote:
On Mar 27, 2008, at 4:31 AM, Luca Morandini wrote:
So, it seems the correct behavior, given my setup, would be: add
*.jx files to the known list of XML resources within the depth
of 4 and perform the XPath query.
On Mar 27, 2008, at 12:55 PM, Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
On Mar 27, 2008, at 10:36 AM, Patrick Heiden wrote:
What should one do, if he/she wants to let all requests get routed
through a mainController block first and therefor disabling direct
calls to connected
Vadim Gritsenko pisze:
On Mar 27, 2008, at 12:55 PM, Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
On Mar 27, 2008, at 10:36 AM, Patrick Heiden wrote:
What should one do, if he/she wants to let all requests get routed
through a mainController block first and therefor disabling direct
Hi you both!
Vadim Gritsenko pisze:
On Mar 27, 2008, at 12:55 PM, Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
On Mar 27, 2008, at 10:36 AM, Patrick Heiden wrote:
What should one do, if he/she wants to let all requests get routed
through a mainController block first and therefor
The other possibility (maybe better one) could be to let the auth-block and
rendering block stand alone and then let the service blocks depend on them.
WDYT?
Greetings,
Patrick
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
Luca Morandini wrote:
I'll add a bit of doc then, to avoid others falling into the same trap.
I have updated the doc for both Traversable and XPathTraversable
generators, could someone please check ?
One more thing: in the XPathTraversableGenerator.java there is a little
typo in the
Luca Morandini pisze:
Luca Morandini wrote:
I'll add a bit of doc then, to avoid others falling into the same trap.
I have updated the doc for both Traversable and XPathTraversable
generators, could someone please check ?
I noticed your activity on docs mailing list. Many thanks Luca! :)
The other possibility (maybe better one) could be to let the auth-block
and rendering block stand alone and then let the service blocks depend on
them.
This has still the 'disadvantage' of users beeing able to call blocks directly.
Grzegorz: I recognized the updated SSF-documentation with new
(concretely: before advice) for stuff like
this (more below).
Grzegorz: I recognized the updated SSF-documentation with new image about
DispatcherServlet[1]
(nice!).
Thanks. Those images are little bit messed up. Will have to look what's
happening out there.
There it is pointed out, that ONLY
Since Grzegorz is in the mood of bestowing upon us the arcana of SSF, I
have an use case that may be of interest:
1) Suppose you have an admin UI (some static pages, a login form, some
admin forms).
2) Suppose you want your users to add specialized forms and static pages
for configuring some
Vadim Gritsenko wrote:
On Mar 26, 2008, at 11:44 AM, Luca Morandini wrote:
As far as I understand, this boils down to let the father block know
about the children and let it access them somehow (like a
DirectoryGenerator spanning all blocks declared in the
servlet-service.xml to collect all
Luca Morandini pisze:
Since Grzegorz is in the mood of bestowing upon us the arcana of SSF, I
have an use case that may be of interest:
1) Suppose you have an admin UI (some static pages, a login form, some
admin forms).
2) Suppose you want your users to add specialized forms and static pages
in my head and even SSF lacked necessary features contrary to what
we have now.
As soon as I have understood something I can help conjuring up some docs
on it.
Regards,
Luca Morandini
www.lucamorandini.it
On Mar 26, 2008, at 5:19 PM, Luca Morandini wrote:
Vadim Gritsenko wrote:
On Mar 26, 2008, at 11:44 AM, Luca Morandini wrote:
As far as I understand, this boils down to let the father block
know about the children and let it access them somehow (like a
DirectoryGenerator spanning all
42 matches
Mail list logo
