Ross Gardler wrote:
> David Crossley wrote:
> >Joerg Heinicke wrote:
> >
> >>Antonio Fiol Bonn?n wrote:
> >>
> >>
> >>>This can't possibly be what we need, as anyone would have done it
> >>>faster than me, but anyway, here it goes.
> >>
> >>IIRC the problem was not the pure removal, but the mention
David Crossley wrote:
Joerg Heinicke wrote:
Antonio Fiol Bonn?n wrote:
This can't possibly be what we need, as anyone would have done it
faster than me, but anyway, here it goes.
IIRC the problem was not the pure removal, but the mentioning of the
authors in a contrib file file.
Exactl
Joerg Heinicke wrote:
> Antonio Fiol Bonn?n wrote:
>
> >This can't possibly be what we need, as anyone would have done it
> >faster than me, but anyway, here it goes.
>
> IIRC the problem was not the pure removal, but the mentioning of the
> authors in a contrib file file.
Exactly. If it was an
On 11/23/05, Jorg Heymans <[EMAIL PROTECTED]> wrote:
>
> Antonio Fiol Bonnín wrote:
>
> >>
> >>
> >>
> >>
> >>
> >>
> >>This can't possibly be what we need, as anyone would have done it
> >>faster than me, but anyway, here it goes.
>
> I'ld say just give it a spin on a checked out copy of tru
Jörg Heinicke (JIRA) wrote:
[ http://issues.apache.org/jira/browse/COCOON-1529?page=all ]
Jörg Heinicke closed COCOON-1529:
-
Resolution: Invalid
So I hope your are ok with closing the bug. Issues with superfluous namespace
declarations have to b
Antonio Fiol Bonnín wrote:
>>
>>
>>
>>
>>
>>
>>This can't possibly be what we need, as anyone would have done it
>>faster than me, but anyway, here it goes.
I'ld say just give it a spin on a checked out copy of trunk, then have a
look at the diff. It should be fairly easy to spot if things
On 23.11.2005 16:33, Antonio Fiol Bonnín wrote:
This can't possibly be what we need, as anyone would have done it
faster than me, but anyway, here it goes.
IIRC the problem was not the pure removal, but the mentioning of the
authors in a contrib file file.
Jörg
Allow request parameters to be used in "for (var k in h)" kind of Javascript
Loops
--
Key: COCOON-1697
URL: http://issues.apache.org/jira/browse/COCOON-1697
Project: Cocoon
Type: Improve
[ http://issues.apache.org/jira/browse/COCOON-1694?page=all ]
Pier Fumagalli updated COCOON-1694:
---
Attachment: patch.txt
The previous patch wouldn't have fixed the problem in all cases: a race
condition might have occurred between checking the status,
[ http://issues.apache.org/jira/browse/COCOON-1694?page=all ]
Pier Fumagalli updated COCOON-1694:
---
Attachment: (was: patch.txt)
> Error decommissioning component:
> org.apache.cocoon.components.store.impl.EHDefaultStore
> -
[ http://issues.apache.org/jira/browse/COCOON-1520?page=all ]
Vadim Gritsenko closed COCOON-1520:
---
Resolution: Won't Fix
> Database / avalon problems
> --
>
> Key: COCOON-1520
> URL: http://issues.apache.o
[ http://issues.apache.org/jira/browse/COCOON-1520?page=all ]
Vadim Gritsenko reopened COCOON-1520:
-
changing resolution
> Database / avalon problems
> --
>
> Key: COCOON-1520
> URL: http://issues.apache.or
[ http://issues.apache.org/jira/browse/COCOON-1520?page=all ]
Vadim Gritsenko closed COCOON-1520:
---
Fix Version: 2.1.9-dev (current SVN)
Resolution: Fixed
The issue is caused by database pool configuration. You should not be using
blocking po
[ http://issues.apache.org/jira/browse/COCOON-1363?page=all ]
Vadim Gritsenko closed COCOON-1363:
---
Fix Version: 2.2-dev (Current SVN)
Resolution: Fixed
fixed
> [Scratchpad] bugs in CookieCreatorAction
> --
Bruno Dumon wrote:
Are you sure this is unnecessary? The current setup shares the same
documents in the new docs and the legacy docs. Thus when the new docs
are updated, refactored, retired etc, this influences the legacy docs
too. This was fine as long as the legacy docs served exactly for this
On Wed, 2005-11-23 at 12:58 +0100, hepabolu wrote:
> Regarding the documentation of 2.2:
>
> Let me first give you some Daisy background to clarify things, before I
> explain what I have in mind.
> Note that this is the quick & dirty explanation. The Outerthought boys
> can give a much more deta
On Sat, 2005-11-19 at 12:05 +0100, Bertrand Delacretaz wrote:
> I have copied important config files (maybe not all of them, a
> double-check would be welcome) to the committer's private SVN area, see
> https://svn.apache.org/repos/private/committers/pmc/cocoon/
> cocoon.zones.apache.org/READM
[ http://issues.apache.org/jira/browse/COCOON-1529?page=all ]
Jörg Heinicke closed COCOON-1529:
-
Resolution: Invalid
So I hope your are ok with closing the bug. Issues with superfluous namespace
declarations have to be fixed in the pipeline (if the
Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
...
> > Source | Topic | Listener
> > -
> > foo| bar | baz << means topic bar from source foo
> should be delivered to listerner baz
> > * | barr | baz << baz should also get any message
> with topic barr f
On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
>
>
> Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> ...
> > > > Would it be sufficient to configure JMSEventMessageListener with a
> > > > list of EventAwares? If the EAManager is necessary, I
> > guess it would
> > > > have to be configure
Try using src="./flow.xmap"
It worked for me, and I sent an e-mail on that some time ago (I use 2.1.7).
--
Antonio
2005/11/23, Rob Berens <[EMAIL PROTECTED]>:
> I just ported our application from cocoon 2.1.6 to 2.1.8.
>
> Most things work fine, there only seems to be a problem with the cocoon
I just ported our application from cocoon 2.1.6 to 2.1.8.
Most things work fine, there only seems to be a problem with the cocoon:
protocol.
My root sitemap called sitemap.xmap contains the following fragment:
So if a uri starts with "flow", it is offered to the flow.xmap
Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
...
> > > Would it be sufficient to configure JMSEventMessageListener with a
> > > list of EventAwares? If the EAManager is necessary, I
> guess it would
> > > have to be configured with such a list unless you can
> think of a way
> > > for it to d
2005/11/23, Antonio Fiol Bonnín <[EMAIL PROTECTED]>:
> 2005/11/23, Sylvain Wallez <[EMAIL PROTECTED]>:
> > Antonio Fiol Bonnín wrote:
> > >>> - Remove author tags
> > >>>
> > >> +1, but who does it? Do we want to split the blocks among ourselves, or
> > >> does anyone have enough time to do it all?
2005/11/23, Sylvain Wallez <[EMAIL PROTECTED]>:
> Antonio Fiol Bonnín wrote:
> >>> - Remove author tags
> >>>
> >> +1, but who does it? Do we want to split the blocks among ourselves, or
> >> does anyone have enough time to do it all?
> >>
> >
> > This looks quite simple. Tedious but simple. If som
On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
>
> Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> > On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> > >
> > > Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> > > > On 11/21/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> ...
> >
>
Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> >
> > Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> > > On 11/21/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
...
>
> I missed the deprecation of the Stores discussion. Do you have some
>
[ http://issues.apache.org/jira/browse/COCOON-1350?page=all ]
Vadim Gritsenko updated COCOON-1350:
Bugzilla Id: (was: 32274)
Component: Blocks: XML-DB
(was: Blocks: (Undefined))
Description:
XUpdate does not remove th
Antonio Fiol Bonnín wrote:
- Remove author tags
+1, but who does it? Do we want to split the blocks among ourselves, or
does anyone have enough time to do it all?
This looks quite simple. Tedious but simple. If someone could explain
exactly what to do (private e-mail is OK), it wou
> > - Remove author tags
>
> +1, but who does it? Do we want to split the blocks among ourselves, or
> does anyone have enough time to do it all?
This looks quite simple. Tedious but simple. If someone could explain
exactly what to do (private e-mail is OK), it would be a way for me to
make a firs
Good idea, thanks. I'll do that.
Cheers, Alfred.
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 23. November 2005 14:10
To: dev@cocoon.apache.org
Subject: Re: [jira] Updated: (COCOON-1691) ESQL compilation error
Alfred Nathaniel (JIRA) wrote:
> [
Alfred Nathaniel (JIRA) wrote:
[ http://issues.apache.org/jira/browse/COCOON-1691?page=all ]
Alfred Nathaniel updated COCOON-1691:
-
Component: Blocks: Databases
(was: Blocks: XSP)
Fix Version: 2.1.9-dev (current SVN)
Damn
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-cron has an issue affecting its community integration.
This issue af
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-cron has an issue affecting its community integration.
This issue af
On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
>
> Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> > On 11/21/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> > > Hi Cocooners!
> > >
> > > I have a question: I couldn't find a nice EventAware object
> > cache in Cocoon, the eventcache block
[
http://issues.apache.org/jira/browse/COCOON-1529?page=comments#action_12358357
]
Juan Jose Pablos commented on COCOON-1529:
--
It is a superfluous namespace declaration.
> I18ntranformation output xmlns:i18n in the first element
> ---
[ http://issues.apache.org/jira/browse/COCOON-1689?page=all ]
Giacomo Pati closed COCOON-1689:
Resolution: Fixed
> Cannot save a cform containing a multivalued field with more than 9 values !
> ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 22 Nov 2005, Sylvain Wallez wrote:
Date: Tue, 22 Nov 2005 17:58:01 +0100
From: Sylvain Wallez <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [jira] Commented: (COCOON-1689) Cannot save a cform cont
Regarding the documentation of 2.2:
Let me first give you some Daisy background to clarify things, before I
explain what I have in mind.
Note that this is the quick & dirty explanation. The Outerthought boys
can give a much more detailed overview.
Daisy supports "sites" (the already mentioned
Geoff Howard [mailto:[EMAIL PROTECTED] wrote:
> On 11/21/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> > Hi Cocooners!
> >
> > I have a question: I couldn't find a nice EventAware object
> cache in Cocoon, the eventcache block only implements the
> o.a.c.caching.Cache which I need to pass a b
was: Re: Planning 2.2
Ezkovich Glen wrote:
...
I agree. But if you release today, then no one except those that have
touched those things or followed the developer list will know what
those features are much less how to use them.
A 2.2 M1 is for the benefit of the community and early adapt
Hi,
Would it make sense to package up the entities stuff and include it in
cocoon-core.jar or perhaps in cocoon-entities.jar ? Is this possible at
all ?
It would make it easier to manage them from a maven point of view, as
the more we can put in jars the less we have to manage ourselves during
de
[ http://issues.apache.org/jira/browse/COCOON-1691?page=all ]
Alfred Nathaniel updated COCOON-1691:
-
Component: Blocks: Databases
(was: Blocks: XSP)
Fix Version: 2.1.9-dev (current SVN)
Damn it, the ESQL logicsheet escaped
43 matches
Mail list logo
