It works,thanks!
Roy Huang
- Original Message -
From: Marco Rolappe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 10, 2004 3:58 PM
Subject: AW: Configuration of own roles in external file?
cocoon user-roles=/WEB-INF/myroles.xconf
...
is working for me
Am Di, den 09.03.2004 schrieb Sylvain Wallez um 16:27:
Bertrand Delacretaz wrote:
Le Mardi, 9 mars 2004, à 16:05 Europe/Zurich, Torsten Curdt a écrit :
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of
Am Di, den 09.03.2004 schrieb Bertrand Delacretaz um 16:37:
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+0.5 (=good idea, won't be able to help)
I can offer some help, if nobody on it, then I can try it?!
Stephan.
I think here goes something wrong ;-)
Am Mi, den 10.03.2004 schrieb [EMAIL PROTECTED] um 10:48:
1.2 +48 -33cocoon-2.2/src/resources/dev/i18n/simple_dict.xml
Index: simple_dict.xml
===
RCS file:
Ups, yes, will fix that. Thanks!
Carsten
-Original Message-
From: Stephan Michels [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 10, 2004 10:55 AM
To: Cocoon Developers
Subject: Re: cvs commit:
cocoon-2.2/src/resources/javadoc/avalonpackage-list
I think here goes
Stephan Michels wrote:
Am Di, den 09.03.2004 schrieb Bertrand Delacretaz um 16:37:
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+0.5 (=good idea, won't be able to help)
I can offer some help, if nobody on it, then I can try it?!
Awsome, I'm
Unico Hommes wrote:
Awsome, I'm willing to do some stuff as well. I think that
besides just moving code around it involves some work
regarding quite a few core samples that use XSP. Here's a list:
./common/view-source.xsp
./flow/calc/screens/displayResult.xsp
Carsten Ziegeler wrote:
Unico Hommes wrote:
Awsome, I'm willing to do some stuff as well. I think that
besides just moving code around it involves some work
regarding quite a few core samples that use XSP. Here's a list:
./common/view-source.xsp
./flow/calc/screens/displayResult.xsp
Unico Hommes wrote:
Carsten Ziegeler wrote:
Unico Hommes wrote:
Awsome, I'm willing to do some stuff as well. I think that besides
just moving code around it involves some work regarding quite a few
core samples that use XSP. Here's a list:
./common/view-source.xsp
Stephan Michels wrote:
Am Di, den 09.03.2004 schrieb Sylvain Wallez um 16:27:
Bertrand Delacretaz wrote:
Le Mardi, 9 mars 2004, à 16:05 Europe/Zurich, Torsten Curdt a écrit :
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27564.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25114.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Steve Krulewitz wrote:
Hey folks --
I just spent some time debugging a problem (which turned out to be a
classpath issue, as always) and I just wanted to share my experience.
First of all, the way I develop with Cocoon is that I build the cocoon
jar, and jars for all the blocks I use, and I
Stefano Mazzocchi wrote:
2) we created tools to ease the migration [we need to put some docs
on how to do this]
Initial docs are in Wiki:
http://wiki.cocoondev.org/Wiki.jsp?page=Woody2CocoonForms
--
Reinhard
On 10.03.2004 10:36, [EMAIL PROTECTED] wrote:
Modified:tools/src blocks-build.xsl
...
Using one classpath for all blocks instead of one classpath for each block.
Any particular reason for this? I thought this was already in
preparation of real blocks.
Joerg
Tim Larson wrote:
A few more points:
+1 to keep the Woody* wiki pages and any other Woody documentation
for as long as we keep the Woody block.
Good point. I will leave the Woody* wiki pages as is, and create Forms*
pages as well.
Upayavira
Torsten Curdt wrote:
Stephan Michels wrote:
Am Di, den 09.03.2004 schrieb Sylvain Wallez um 16:27:
Bertrand Delacretaz wrote:
Le Mardi, 9 mars 2004, à 16:05 Europe/Zurich, Torsten Curdt a écrit :
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
Upayavira wrote:
Tim Larson wrote:
A few more points:
+1 to keep the Woody* wiki pages and any other Woody documentation
for as long as we keep the Woody block.
Good point. I will leave the Woody* wiki pages as is, and create
Forms* pages as well.
Is it worth to replace their content with
On 10.03.2004 12:46, Unico Hommes wrote:
BTW, what about xmlform and jxforms. Are they still necessary?!
Perhaps its time for some clean up.
Sounds like a good idea. But I guess we have to deprecate
them first like we do with the former-woody block now.
xmlform has already been deprecated for
On 10.03.2004 12:49, Unico Hommes wrote:
+1 to keep the Woody* wiki pages and any other Woody documentation
for as long as we keep the Woody block.
Good point. I will leave the Woody* wiki pages as is, and create
Forms* pages as well.
Is it worth to replace their content with a link to the
Is there possibility to get access to the getClass() method in flow ? I am
trying to do some tests with Hibernate and this method is not accessible and
while Hibernate makes a heavy use on reflection I have to wrap everything in
some faade (getUser( id ), getRole( id ) instead of simple
Am Mi, den 10.03.2004 schrieb Joerg Heinicke um 12:41:
On 10.03.2004 10:36, [EMAIL PROTECTED] wrote:
Modified:tools/src blocks-build.xsl
...
Using one classpath for all blocks instead of one classpath for each block.
Any particular reason for this? I thought this was already
Hi,
now that the Wiki is on the move to a new location, it's a excellent time to
not only clean up some pages, but also add information for which version (of
Cocoon, Tomcat, Eclipse ) the information is valid.
Upayavira already suggested to add tags to the template to add this kind of
I've now got most if not all links working. It was kinda tough, as Moin
is more strict about what it considers a link. And embedding CamelCase
into a page automatically makes a link, which is complitated to handle.
I know there's more loose ends, including the Woody stuff.
Anyway, please check
[EMAIL PROTECTED] wrote:
Hi,
now that the Wiki is on the move to a new location, it's a excellent time to
not only clean up some pages, but also add information for which version (of
Cocoon, Tomcat, Eclipse ) the information is valid.
Upayavira already suggested to add tags to the template
Joerg Heinicke wrote:
On 10.03.2004 12:49, Unico Hommes wrote:
+1 to keep the Woody* wiki pages and any other Woody documentation
for as long as we keep the Woody block.
Good point. I will leave the Woody* wiki pages as is, and create
Forms* pages as well.
Is it worth to replace their
Joerg Heinicke wrote:
On 10.03.2004 12:46, Unico Hommes wrote:
BTW, what about xmlform and jxforms. Are they still necessary?!
Perhaps its time for some clean up.
Sounds like a good idea. But I guess we have to deprecate
them first like we do with the former-woody block now.
xmlform has
On 10 Mar 2004, at 13:01, Upayavira wrote:
Anyway, please check the site at wiki.apache.org/cocoon and report
back anything you find.
http://wiki.apache.org/cocoon/GeneralizedFlow looks funny
the first code block in http://wiki.apache.org/cocoon/ApacheModProxy
has some extra . and before and
Simon Mieth wrote:
On Thu, 04 Mar 2004 09:06:17 +
Upayavira [EMAIL PROTECTED] wrote:
Okay, Simon, sorry for my delay in replying.
Here's my idea of what I'd like to see.
Firstly, I'd ___love___ to see a really thin GUI, with no
editors (or a really cut down notepad style editor) living
now that the Wiki is on the move to a new location, it's a
excellent time to
not only clean up some pages, but also add information for
which version (of
Cocoon, Tomcat, Eclipse ) the information is valid.
Upayavira already suggested to add tags to the template to
add this kind of
Am Mi, den 10.03.2004 schrieb Reinhard Pötz um 11:03:
Stephan Michels wrote:
Am Di, den 09.03.2004 schrieb Bertrand Delacretaz um 16:37:
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+0.5 (=good idea, won't be able to help)
I
Stephan Michels wrote:
Am Mi, den 10.03.2004 schrieb Reinhard Pötz um 11:03:
Stephan Michels wrote:
Am Di, den 09.03.2004 schrieb Bertrand Delacretaz um 16:37:
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+0.5
I have following problem, that
src/blocks/session-fw/conf/xsp-session-fw.xconf
depends on the xsp block, but won't be executed before the
patch files
of the xsp block :-/
This may require a change to the build system. Hmm.
What about moving *all* xsp stuff into the xsp block?
Am Mi, den 10.03.2004 schrieb Carsten Ziegeler um 14:24:
I have following problem, that
src/blocks/session-fw/conf/xsp-session-fw.xconf
depends on the xsp block, but won't be executed before the
patch files
of the xsp block :-/
This may require a change to the build
Reinhard Pötz wrote:
Stephan Michels wrote:
Am Di, den 09.03.2004 schrieb Bertrand Delacretaz um 16:37:
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+0.5 (=good idea, won't be able to help)
I can offer some help, if nobody on it, then I can try
Unico Hommes wrote:
Unico Hommes wrote:
Carsten Ziegeler wrote:
...
Interestingly some of these samples (e.g. flow) are ported in 2.2
from xsp to jx...
Yep I already started doing some work in that department :-)
BTW. this was done only in the flow samples and regarding me wanting
to test
Vadim Gritsenko wrote:
Please note that currently jxtransformer/generator is not up
to speed in non-flow environment. It has to be extended /
completed first in order to be xsp replacement.
I hope to come up with a solution in the next weeks
Carsten
Vadim Gritsenko wrote:
Unico Hommes wrote:
Unico Hommes wrote:
Carsten Ziegeler wrote:
...
Interestingly some of these samples (e.g. flow) are ported in 2.2
from xsp to jx...
Yep I already started doing some work in that department :-)
BTW. this was done only in the flow samples and
Leszek Gawron wrote:
Is there possibility to get access to the getClass() method in flow ? I am
trying to do some tests with Hibernate and this method is not accessible and
while Hibernate makes a heavy use on reflection I have to wrap everything in
some faade (getUser( id ), getRole( id ) instead
Unico Hommes wrote:
I tend to think the dependency is from session-fw on xsp, not
the other way around. Unless this becomes really difficult to
accomplish I'd prefer keeping it the way it is now. I will do
some research as to what would be involved to change the
build system to
As discussed recently, our internal redirects don't work
the way one would usually suspect. If you do an internal
redirect, like:
map:redirect-to uri=cocoon://some-pipeline/
and the called pipeline has an error, then the error handler
of the calling pipeline (containing the redirect) is called
The code above does not actively ignore the exception, even less
silently swallow anything. Errors are uncecked type exceptions in Java.
I don't presume you suggest this is the place you want to log any
throwable down the execution path? If I were to take a guess, this one
will end up in the
generating, generation, what the . Its all the same ;-) Thanks.
Am Mi, den 10.03.2004 schrieb [EMAIL PROTECTED] um 16:20:
unico 2004/03/10 07:20:54
Added: src/blocks/xsp/java/org/apache/cocoon/generation
AbstractServerPage.java
Do real forwards have the ability to stay within the same sitemap? I'm
assuming this method would call the RequestDispatcher's forward method? If
so, would this finally allow constructs such as map:redirect-to
uri=cocoon:/../parent-pipeline ? This would seem logical as you'd have
to construct
Joerg Heinicke wrote:
Hello,
below you will find the mail I wanted to send first, but after having written it
I found the solution myself:
I thought about the correct event instead of on-value-changed, I came to on-bind
and in the binding docu I found wb:javascript and came to following code that
Tim Larson [EMAIL PROTECTED] writes:
At my workplace they are worried that pairing their slow
upgrade cycle with the fast pace of open source projects
could cause maintenance problems for their custom code.
I find the premise a tad strange; you've got the source, what's to
prevent you
Please note that currently jxtransformer/generator is not up to speed in
non-flow environment. It has to be extended / completed first in order
to be xsp replacement.
Yes, this is certainly needed to help the jxtransformer/generator
conquer XSP. I am currently using the JXTemplateGenerator to
After yesterday's message from Brian Behlendorf, and reviewing the mozilla
license, it seems pretty clear that Cocoon 2.1.x is covered under the
Mozilla license rather than apache's by its inclusion of Rhino. Since I
have seen no responses here to his message I have to assume that discussions
If I use "wildcard" matcher (e.g. */*), a
self-developed Transformer doesn't work...
I've defined the transformer inthe
sitemap:
map:transformer name="xyz_components"
pool-grow="2" pool-max="16" pool-min="2"
src=""
parameter name="disable-caching"
type="boolean" value="true" /
parameter
Ugo Cei u.cei at cbim.it writes:
wb:javascript id=filter.object path=objects direction=load
wb:load-form
var objects = jxpathPointer.getNode();
widget.setSelectionList(objects, id, name)
/wb:load-form
/wb:javascript
The question is just if this could be added with a
There remain a few issues that need resolving.
- InputModuleAction had to move along with xsp because it has a
dependency on some xsp helper class. This is unfortunate and maybe
unnecessary. Perhaps someone with more knowledge about this class could
take a look and see if they can solve this?
On 10 Mar 2004, at 17:08, Ralph Goers wrote:
After yesterday's message from Brian Behlendorf, and reviewing the
mozilla
license, it seems pretty clear that Cocoon 2.1.x is covered under the
Mozilla license rather than apache's by its inclusion of Rhino. Since
I
have seen no responses here to
On 10.03.2004 13:20, Upayavira wrote:
Why not adding just a prominent warning at the beginning of each page:
This documentation is no further maintained. Go to Forms* pages.
Gosh. This is getting complicated! I'll add a warning.
:) Thanks for your effort.
Joerg
On 10.03.2004 13:35, Torsten Curdt wrote:
xmlform has already been deprecated for quite a while now. I think it
is safe to remove it.
It's only half a year:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107662678916017w=4.
I would deprecate jxforms block now and remove both for 2.2 (which is
On 10.03.2004 13:01, Upayavira wrote:
Anyway, please check the site at wiki.apache.org/cocoon and report back
anything you find.
http://wiki.apache.org/cocoon/FAQs:
The list at the beginning is broken. The numbering of the sections is
also strange in the file: 1. 1. Meta-FAQ instead of 1.
Steven,
I wasn't looking for panic mode. Just some info. This exact problem,
although somewhat less serious, showed up just a few days earlier with Jisp
and folks on this list were actively discussing alternatives. Since Brian's
post not a single follow-up on Rhino here.
Ralph
-Original
Thanks, Joerg. That's just the kind of info I was looking for.
Ralph
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 10, 2004 11:01 AM
To: [EMAIL PROTECTED]
Subject:Re: Rhino
On the other hand there is no need (license POV)
On 10.03.2004 17:09, [EMAIL PROTECTED] wrote:
If I use wildcard matcher (e.g. */*) , a self-developed Transformer doesn't work...
I've defined the transformer in the sitemap:
map:transformer name=xyz_components pool-grow=2 pool-max=16 pool-min=2
On 10 Mar 2004, at 20:02, Ralph Goers wrote:
Thanks, Joerg. That's just the kind of info I was looking for.
Also, the Rhino case triggered a whole lot of related discussions about
additional policy requirements laid upon ASL-licensed projects w.r.t.
the licenses of their dependencies. And that
On 09 Mar 2004, at 19:38, Brian Behlendorf wrote:
On Mon, 8 Mar 2004, Steven Noels wrote:
This is troubled partly by the license status of Rhino itself. Upon
personal investigation a while ago, I found some source files which
where licensed using the NPL1.1
Joerg Heinicke wrote:
Thanks for your answer, Ugo, I only do not get your point.
My problem was about binding and I solved it with the above wb:javascript code
and it works for the moment. But I could imagine that I'm not the only one
binding selection lists to a collection, so maybe adding an
On 10.03.2004 16:20, Carsten Ziegeler wrote:
a) Make an internal redirect a real forward (This is an
incompatible change)
+1 This is indeed what I expect!
Joerg
On 10.03.2004 22:01, Ugo Cei wrote:
Not it's me that's not getting your point here ;-).
Ok, let me clarify. I think I do nothing unusual. Yes, I have a form
with a simple dynamic selection list. And I do the binding against a bean.
There are two known ways to set the selection list dynamically:
Joerg Heinicke wrote:
On 04.03.2004 12:45, Unico Hommes wrote:
And what happens if I dont specify an element map:pipes/ in the
root sitemap? ;-)
AFAICT this would generate an error. Doesn't it?
Is it possible to express a real error message for map:pipes too? I
guess so, just need
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
As discussed recently, our internal redirects don't work the way one
would usually suspect. If you do an internal
redirect, like:
map:redirect-to uri=cocoon://some-pipeline/
and the called pipeline has an error, then the error handler
of the
On 11.03.2004 00:40, Unico Hommes wrote:
For not setting default pipe I get:
org.apache.avalon.framework.component.ComponentException: pipes:
ComponentSelector Attempted to retrieve component with null hint.
For not setting default generator I get:
On 05.03.2004 17:45, Marc Portier wrote:
Yes, I only see that wb:unique-row (grouped by type: unique or not
unique) is
outside of wb:on-bind (grouped by event: on-bind, on-insert,
on-delete) though
it is executed also at on-bind event.
yes, but do you find that surprising?
(in fact all of the
Title: JCS Store - new issues
Hi Guys,
You may or may not have seen my recent posts about performance with JCS store, but I've gotten a little further into diagnosing what looks like a deadlock issue.
After about 30mins of load testing I'm seeing everything lock up (iowait of ~ 100%) the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Guys,
I think I've been leading myself up the garden path a bit here. After
some more in-depth analysis I've noticed that this is directly related
to mem usage and garbage collection. It would seem that the store
janitor and GC is kicking in at about the same time (which makes sense.)
The
[repost with correct recipient list]
Carsten Ziegeler wrote:
Hi Stephen,
I had a quick glance at your finder stuff but are absolutely clueless
what I should do with it :) I guess from your description that if this
finder is used inside Merlin I can use the ECM configuration files
for defining my
Nacho Jimenez wrote:
Jan Hoskens wrote:
I'm not sure you mean this, but I'll give it anyway:
If you're using woody and thus the woody stylesheet, there are several
javascripts that are added (eg the popup window). These javascripts
are to
be added in your html header and thus the woody
Anyone have any insight into what the performance impact is of turning on the
Instrumentation feature in web.xml (Ver 2.1.4)?
Thanks!
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
OK. I posted the same question earlier but re-framed it so that someone can me
suggestions.
I have coplet which accepts some input keys and shoud generate a excel file.
When I click on submit it takes to the ill formatted html file but does not
generate a excel file.
I use the same
75 matches
Mail list logo
