[ 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
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
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
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 byte array.
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
-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
[ 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 !
[
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
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 only implements
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
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
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)
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:
[
- 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 first
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
[ 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
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
pointers in
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:
...
I missed the
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 someone could explain
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?
This looks
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 discover all
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:
map:match pattern=flow/**
map:mount src=flow.xmap uri-prefix=
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:
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 configured with such a list
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 from any
[ 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
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/
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 detailed
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
[ 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
[ 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
[ 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.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.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-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
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:
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
Antonio Fiol Bonnín wrote:
replaceregexp byline=true
regexp pattern=\*([EMAIL PROTECTED])/
substitution expression=*/
fileset dir=. includes=**/*.java /
/replaceregexp
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
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
On 11/23/05, Jorg Heymans [EMAIL PROTECTED] wrote:
Antonio Fiol Bonnín wrote:
replaceregexp byline=true
regexp pattern=\*([EMAIL PROTECTED])/
substitution expression=*/
fileset dir=. includes=**/*.java /
/replaceregexp
This can't possibly be what we need, as anyone would have
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 easy
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.
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 mentioning of the
authors in a
43 matches
Mail list logo
