Tony Collen dijo:
Antonio Gallardo wrote:
Hi:
I want to point out what really means Free Maillist Support.
At first sight when we said Cocoon has support trought free maillist,
it seems like it is less than Company Support. Many of us saw this as
a lack instead of a feature, just before
Le Jeudi, 11 sep 2003, à 20:11 Europe/Zurich, Bruno Dumon a écrit :
...Component lookup
I'm wondering how component lookup will work. For example, suppose I
have a block where I want to use FOP, i.e. the fo2pdf serializer. I'll
make my block depend on the fop blok (or the more
Le Jeudi, 18 sep 2003, à 21:09 Europe/Zurich, Reinhard Poetz a écrit :
...I understand that I can't load a class from another block. My
question:
Is it possible to load classes from Cocoon core (whatever we will
consider as core) from within my block via new or are there arguments
against
Although I'm too late: +1 for both from me as well.
Carsten
(Back from holidays and going through 6000 mails with warp speed)
-Original Message-
From: David Crossley [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 7:38 AM
To: [EMAIL PROTECTED]
Subject: [Vote] Antonio
Tony Collen wrote:
Antonio Gallardo wrote:
Hi:
I want to point out what really means Free Maillist Support.
At first sight when we said Cocoon has support trought free maillist, it
seems like it is less than Company Support. Many of us saw this as a
lack
instead of a feature, just before we
After comments made on forrest-dev, I have looked (for the first time)
at logging in the CLI/bean. It seems to me that nothing is getting
logged, even when log messages are sent.
I know next to nothing about logging, but I will try to look into this.
If anyone is more clued up, please have a
Steven Noels wrote:
Hi folks,
forgive me for putting on my BOFH hat, while making the following
observations...
1) We suck at freezing and stabilizing the codebase prior to releases.
I would suggest that, from now on, the Release Manager puts forward a
release date after discussion
Upayavira wrote:
I have committed a partly working auth-fw/flow sample. I think it is
basically there, but I am gettting stuck with:
SessionManager.streamContextFragment: Context 'authentication' not found.
I've never used the session manager (nor sessions for that matter), so
I'm a
Carsten Ziegeler wrote:
Upayavira wrote:
I have committed a partly working auth-fw/flow sample. I think it is
basically there, but I am gettting stuck with:
SessionManager.streamContextFragment: Context 'authentication' not found.
I've never used the session manager (nor sessions for that
Carsten Ziegeler wrote:
snip type=happy agreement/
I tried to address this issue several times in the last weeks, well,
without much success.
One thing I want to stress again: *if* we would make a new repository
for 2.2 and duplicate all code, this would include the blocks as well.
So we would
Sylvain Wallez wrote:
Hi all,
A short post to say that I've been working intensively on event handling
on Woody since yesterday. I'm nearly finished with it, and obtained
something powerful-yet-simple, that allows to define event handlers on
actions (ActionEvent) and fields
Le Vendredi, 19 sep 2003, à 11:25 Europe/Zurich, Carsten Ziegeler a
écrit :
...Now to the docs:
Yes, looking back it was a very stupid idea to reorganize the docs. I
didn't thought about links pointing to the old docs. I'm very sorry
for that!
I don't think it was a stupid idea - after so much
I know, this has been discussed before and we decided to keep the docs
mailing list, but:
-The traffic on the docs list is almost nil
-I suspect people unsubscribe from it to avoid the many wiki update
messages
-People writing to docs tend to copy important messages to dev as
well so they
Hi all,
i trying to integrate Cocoon via CocoonBean into my application. This work really
fine, but the followLinks don't process every last link in every page.
After trying with CLI, i got the same problem. I looked into the Source
CocoonBean.java and found in the method process() the
Le Vendredi, 19 sep 2003, à 14:47 Europe/Zurich, Sylvain Wallez a écrit
:
...So what about the following (somewhat already expressed, BTW) :
- start a 2.2 repo with only the Cocoon core (i.e. src/java)
- copy blocks in the 2.2 repo only if they require substantial changes
that would break the
Simon,
Thank you very much for this! I was aware of this being a problem (it
has been reported by people on the Forrest list), but had suspected it
to be something much deeper than what you have shown it to be.
You've also explained why, when using confirm-extensions=true gave a
different
Sylvain Wallez wrote:
Steven Noels wrote:
Carsten Ziegeler wrote:
snip type=happy agreement/
I tried to address this issue several times in the last weeks, well,
without much success.
...
So, whatever we decide, I'm -1 on duplicating the block code.
My problem with the blocks code is that
On Friday, Sep 19, 2003, at 11:39 Europe/Rome, Steven Noels wrote:
Carsten Ziegeler wrote:
snip type=happy agreement/
I tried to address this issue several times in the last weeks, well,
without much success.
One thing I want to stress again: *if* we would make a new repository
for 2.2 and
Geoff Howard wrote:
+1 let's give it a shot. This is probably what Carsten was picturing
all along. :)
Yeah. That's one of my qualities/defaults (depending on the context) : I
hear all opinions, make a synthesis and sometimes claim that it's my own
idea ;-)
Sylvain
--
Sylvain Wallez
On Friday, Sep 19, 2003, at 15:05 Europe/Rome, Geoff Howard wrote:
Sylvain Wallez wrote:
Steven Noels wrote:
Carsten Ziegeler wrote:
snip type=happy agreement/
I tried to address this issue several times in the last weeks,
well, without much success.
...
So, whatever we decide, I'm -1 on
Bertrand Delacretaz wrote:
I suggest closing the docs list to humans (using the dev list instead),
keeping it only for wiki update messages.
+1 either way. I subscribe to both and assumed others did too.
Geoff
On Friday, Sep 19, 2003, at 09:35 Europe/Rome, Bertrand Delacretaz
wrote:
Le Jeudi, 11 sep 2003, à 20:11 Europe/Zurich, Bruno Dumon a écrit :
...Component lookup
I'm wondering how component lookup will work. For example, suppose I
have a block where I want to use FOP, i.e. the
On Thursday, Sep 18, 2003, at 21:09 Europe/Rome, Reinhard Poetz wrote:
From: Stefano Mazzocchi
snip/
3) persistent service behavior with hot deployment
One of the big issues with hot deployment is the potentially
inconsistent state of the persistent services contained by one block
and used
--- Stefano Mazzocchi [EMAIL PROTECTED] wrote:
After a little more thinking, I think that we should avoid placing
block code in cocoon-2.2 alltogether because we need to start talking
about the 'community process' of accepting new blocks, where they fit,
how they get 'certified' and all
On Thursday, Sep 18, 2003, at 04:51 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:
Ok, after reaching some stasis on wiring.xml, starting the discussion
on cob.xml (or whatever). I expect that both of these will be much
more interesting discussions after real implementation starts.
Stefano Mazzocchi wrote:
A few points:
1) there is no *block* code in cocoon 2.1, everything is done by the
builder.
Hey, I knew that already! ;-)
2) blocks in 2.1 and blocks in 2.2 are a single block.xml file away.
Given all this stuff of block-specific classloading and much more
technical
Sylvain Wallez wrote:
Yeah. That's one of my qualities/defaults (depending on the context) : I
hear all opinions, make a synthesis and sometimes claim that it's my own
idea ;-)
Ha. :-)
You couldn't get away with it this time! :-D
/Steven
--
Steven Noels
Sylvain Wallez wrote:
Marc Portier wrote:
in fact I thought about this from the start, but failed to explain to
myself how it should look like (I also kept on mixing it up with
client-side javascript)
Well, if you fail to explain to yourself, I understand why we sometimes
don't understand
Stefano Mazzocchi wrote:
SNIP/
+1 let's give it a shot. This is probably what Carsten was picturing
all along. :)
+1 as well. the magic build script that gets missing blocks from 2.1
would simply be a cvs checkout, followed with a few file copy
operations.
Yes, I thought of that,
+1
Carsten
Steven Noels wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
in fact I thought about this from the start, but failed to explain to
myself how it should look like (I also kept on mixing it up with
client-side javascript)
Well, if you fail to explain to yourself, I understand why we
Bertrand Delacretaz wrote:
I suggest closing the docs list to humans (using the dev list instead),
keeping it only for wiki update messages.
+1
Thoughts?
We wouldn't even need archives of the list then, would we? Rather, new
archives.. the old archives may still have some use from the
Marc Portier wrote:
Sylvain Wallez wrote:
snip/
hm, this makes these listeners totally stateless, no?
what I mean:
- probably woody is going to instantiate them with a Class.forname()
and newInstance() sequence, correct?
- as such they have no initial state other then some defaults
Le Vendredi, 19 sep 2003, à 18:08 Europe/Zurich, Tony Collen a écrit :
...We wouldn't even need archives of the list then, would we? Rather,
new archives.. the old archives may still have some use from the
conversations that did occur
Not sure if I understand, I thought we'd just keep the
From: Bertrand Delacretaz
Le Jeudi, 18 sep 2003, à 21:09 Europe/Zurich, Reinhard Poetz a écrit :
...I understand that I can't load a class from another block. My
question:
Is it possible to load classes from Cocoon core (whatever we will
consider as core) from within my block via new
From: Bertrand Delacretaz
Le Vendredi, 19 sep 2003, à 05:36 Europe/Zurich, Niclas
Hedhman a écrit
:
...a continously evolving Feature or Evaluation
Overview page is
something else, and a good thing that is coming out of this, which
should not be confrontational nor compared with X
On Friday, Sep 19, 2003, at 15:54 Europe/Rome, Geoff Howard wrote:
Hmmm... I've been assuming that the way a block actually gets coded
may need to change in order to interact with other real blocks, etc.
If this is not the case, then the whole issue of back-compatibility of
blocks goes away
On Friday, Sep 19, 2003, at 19:31 Europe/Rome, Reinhard Poetz wrote:
From: Bertrand Delacretaz
Le Jeudi, 18 sep 2003, à 21:09 Europe/Zurich, Reinhard Poetz a écrit :
...I understand that I can't load a class from another block. My
question:
Is it possible to load classes from Cocoon core
Referencing the following discussions:
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=106326623205960w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=106400306728111w=2
It appears that the WSProxy (and possibly the HttpProxyGenerator) are getting decoded request
parameters (i.e.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23283.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
snip/
hm, this makes these listeners totally stateless, no?
what I mean:
- probably woody is going to instantiate them with a Class.forname()
and newInstance() sequence, correct?
- as such they have no initial state other then
Stefano Mazzocchi wrote:
On Thursday, Sep 18, 2003, at 04:51 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:
I wasn't sure what uses component meant functionally.
the blocks declares what component is going to use from that block and
will name it. This is the inverse of the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9728.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
43 matches
Mail list logo
