Geoff Howard wrote:
Unico,
Thanks for taking a look at this with me, comments inline:
Unico Hommes wrote:
I've checked out your event-cache code just now and like to
make some
comments.
One thing I found was that the EventRegistry.init() method
breaks IoC
in Avalon. I
Hi Upayavira,
I missed your email somehow. Yep this one is used by the Lucene block.
It depends on a link view being available in the sitemap and crawls
cocoon over http. I had started implementing a publisher block in the
same vein as the Lucene block because I couldn't really see how to
achieve
Hi all,
I would like to be able to response.setStatus from the flow. I have two
scenarios I would like to use this:
1) In an authentication module where failure to authenticate should
result in 401 in order to give the browser the chance to recover from
being denied access to a certain
On a related note: the cocoon.process(uri,object,outStream) FOM function
is always resolved as cocoon:// . Do you think this should behave as
sendPage(AndWait)?
Regards,
Unico
-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
Sent: maandag 4 augustus 2003 14:21
To:
Hi vadim,
I'm experiencing the same problem. Views on resources seems to be
broken. I will put this in bugzilla.
Unico
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: dinsdag 29 juli 2003 16:03
To: [EMAIL PROTECTED]
Hi guys,
Check out the samples.
Upayavira wrote:
Vadim wrote:
big snip/
* Make Cocoon work with an external Cocoon object, again for the
sake of a PublishingService
I don't get this. What Cocoon with which external Cocoon?
This is something that Unico talked about in relation to a
publishing service
Reinhard Poetz wrote:
-Original Message-
From: Berin Loritsch [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2003 2:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Ant/Maven/Centipede discussion
Kevin O'Neill wrote:
Again, I am not pressing for Maven, but these
Geoff Howard wrote:
Unico Hommes wrote:
...
The thing is that Ant 1.6 as promissing as it sounds is not
released yet. If we keep the same build system, thats fine.
However, I would prefer we do this with something we can
expect to find *installed* on a developer's machine
Hi,
Using TraversableGenerator I noticed a limitation and a potential bug.
The limitation is that generate() throws a SourceNotFoundException if the input Source
is not a collection. I'd like to use this generator also to view some meta information
on collection:resources without having to
OK, patch in bugzilla. :)
Gianugo Rabellino wrote:
Unico Hommes wrote:
Gianugo Rabellino wrote:
The limitation is that generate() throws a
SourceNotFoundException if the input Source is not a
collection. I'd like to use this generator also to view some
meta information
Hi,
This is to let you know I've just submitted a patch [1] to cocoon bugzilla for some
enhancements to the SourceInspector code. It solves the problem of more efficiently
finding specific properties than is the case now. You may also be interested in a
related patch [2] I submitted earlier
Hi Guido,
Thanks for your reply. See the comments inline.
Guido Casper wrote:
Hi Unico,
first let me say thank you for all you efforts in this area. I'm very
excited about that (I start wondering ...). I'm sorry I cannot help
out
more currently.
Unico Hommes [EMAIL PROTECTED] wrote
Looks like Slides bug report. Last week the Velocity people apparently
received it too. I've notified slide-dev.
-Original Message-
From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
Sent: zondag 19 oktober 2003 16:32
To: [EMAIL PROTECTED]
Subject: Re: Bug report for Cocoon 2
Carsten Ziegeler wrote:
Now, I think we can make it simpler :)
a) A sitemap component gets a Cocoon source resolver anyway.
We can provide in the setup() method a wrapper for
the Avalon SourceResolver that knows it's sitemap. This
is simply and doesn't need thread locals etc.
PROTECTED]
Subject: [VOTE RESULTS] Unico Hommes as a Cocoon/Forrest Committer
The vote passed :-)
Unico has already faxed the CLA and I have requested karma for him as
described here: http://www.apache.org/dev/pmc.html
In the meantime, while waiting for access, Unico can take his time to
read
One thing I can see right away is that the fullPipe pipeline is missing
a serializer. All valid pipelines have at least one generator and one
serializer. Calling a subpipeline using the cocoon: protocol will then
connect the pipeline component to the subpipeline minus the serializer.
Hope that
currently working on a simple JdbcSourceInspector for mutable
SourceProperties and a RepositorySource that acts as a Source wrapper
and adds Inspectability.
-- Unico
Guido
Unico Hommes [EMAIL PROTECTED] wrote:
Guido Casper wrote:
Unico Hommes [EMAIL PROTECTED] wrote:
One
Carsten Ziegeler wrote:
Berin Loritsch wrote:
I'm running into an issue here with RequestLifecycle components.
I want to
write the handler and such, and we can assume one handler to one
component definition (configuration, etc.). Right now the helper
classes assume we have
Carsten Ziegeler wrote:
Unico Hommes wrote:
What about transactional components? I have a situation
where I use a
GRL to wrap a session façade type object and rely on
recycle() being called at the end of the request in order to
commit/rollback work done. How would I achieve
Berin Loritsch wrote:
Unico Hommes wrote:
Ok, anyway, we could keep the GRL which can be modelled in
fortress
using a thread component (one component per thread), but
skip the RLC
which caused a lot of trouble to get it working and which
might still
cause us more
Berin Loritsch wrote:
/**
* This component depends on the following:
*
* @avalon.dependency type=Generator
* @avalon.dependency type=Transformer
* @avalon.dependency type=Serializer
*/
public void service(ServiceManager manager) throws ServiceException
{
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: donderdag 23 oktober 2003 10:29
To: [EMAIL PROTECTED]
Another question :)
Currently with ECM we have to implement the Component
interface even if we only use Serviceable (because of the
internal
As this interface was moved to excalibur sourceresolve, I'd like to
remove it, off course moving all dependencies to the excalibur one. Any
objections?
-- Unico
OK, I'll do that.
Carsten Ziegeler wrote:
Perhaps moving it into the deprecated section, first.
We can then remove it for 2.2.
Carsten
-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 23, 2003 11:13 AM
To: [EMAIL PROTECTED
. To change all this is quite some work and I
for one don't see much point in doing so at this point.
So unless someone comes up with a beter idea I am going to move these
two interfaces back with the slide block and tag them as deprecated.
-- Unico
Unico Hommes wrote:
OK, I'll do that.
Carsten
There was a related thread on Avalon dev a few weeks ago that may
interest you:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg08037.html
It also mentions this project on sourceforge:
http://sourceforge.net/projects/aaa4avalon/
Although it's a phoenix block it may be interesting to look at.
Guido Casper wrote:
Unico Hommes [EMAIL PROTECTED] wrote:
Guido Casper wrote:
I would like to make the following changes to the 2.1 repo
and will
go ahead if noone objects (as soon I find some time):
-Creating a repository block and moving there all source
interfaces
-Original Message-
From: Guido Casper [mailto:[EMAIL PROTECTED]
Sent: donderdag 23 oktober 2003 20:22
To: [EMAIL PROTECTED]
Subject: Re: repository block (was Re: [RT] Source extensions)
Unico Hommes [EMAIL PROTECTED] wrote:
-Adding a setSourceProperty() method
-Original Message-
From: Guido Casper [mailto:[EMAIL PROTECTED]
Sent: vrijdag 24 oktober 2003 12:41
To: [EMAIL PROTECTED]
Unico Hommes [EMAIL PROTECTED] wrote:
A related change I need to make is described here:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23699
Guido Casper wrote:
I don't really see a
way to avoid the looping (Is it really that costly?).
Yes, it can be. This is the one of the reasons WebDAV
specifies a way
to PROPFIND specific properties. Consider a PROPFIND call on a
collection with depth 1. The collection
Berin Loritsch wrote:
Daniel Fagerstrom wrote:
Did you miss Sylvains (and my) answer to your earlier
question about
the TreeProcessor?
http://marc.theaimsgroup.com/?t=10664158681r=1w=2
AFAIK Sylvain has written nearly all of (or maybe all of) the
TreeProcessor, Ovidiu
-Original Message-
From: Berin Loritsch [mailto:[EMAIL PROTECTED]
Sent: vrijdag 24 oktober 2003 18:26
To: [EMAIL PROTECTED]
Geoff Howard wrote:
Unico Hommes wrote:
Ok, I am running into the following situation: Looking at
components.modules.input.AbstractMetaModule
:-D Actually, based on the code, as far as I could see this is how it
should be done. I just made a change from pooled to singleton that was
already pending.
See more comments inline.
-Original Message-
From: Geoff Howard [mailto:[EMAIL PROTECTED]
Sent: zondag 26 oktober 2003 0:11
Open questions:
- What do sitemap components get for @x-avalon-info? A new made up
string like cookie-matcher? The @name/type from the default sitemap
in
2.1?
I use the name of the component that it is currently registered with
the
sitemap if I can find an entry for it.
What
Guido Casper wrote:
The only change to your proposal to allow for both behaviours would be
to not prohibit ambiguities.
Deal? :-)
Yes, that was my bad. It had been a long day.
This would handle for example the situation we currently have with
the
GIF- and JPEGSourceInspectors
with you?
-- Unico
-Original Message-
From: Unico Hommes
Sent: maandag 27 oktober 2003 14:52
To: [EMAIL PROTECTED]
I am looking into extending SourcePropsWritingTransformer to
also be able to remove SourceProperties. One thing I need to
decide is how to access SourceProperties
It seems that all loggers assigned to sitemap components are getting
their category prepended with 'sitemap'.
Defining transformer name=xslt logger=sitemap.transformer.xslt /
the transformer will get a logger in the category
sitemap.sitemap.transformer.xslt
Is this intentensional?
I am running
Blush... Thanks for catching that. I'll change it right away.
-- Unico
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: dinsdag 28 oktober 2003 17:34
To: [EMAIL PROTECTED]
On 28.10.2003 15:09, [EMAIL PROTECTED] wrote:
unico 2003/10/28 06:09:49
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: dinsdag 28 oktober 2003 1:47
To: [EMAIL PROTECTED]
Subject: Re: sitemap logging?
Unico Hommes wrote:
It seems that all loggers assigned to sitemap components are getting
their category prepended
Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
We must refactor the XSLTProcessor so that:
- it returns a MultiSourceValidity if needed (see in
o.a.c.c.source.impl in scratchpad).
I moved it out into repository block in case anybody
Sylvain Wallez wrote:
Sorry to jump in late, but I would like you to consider the
VersionedSource interface I wrote for the CVSSource over at
cocoondev.org ([1], damn LGPL constraints which forces it to
be hosted out of Cocoon's CVS!) as a replacement for the
VersionableSource.
Sylvain Wallez wrote:
Unico Hommes wrote:
-Original Message-
From: Guido Casper [mailto:[EMAIL PROTECTED]
Sent: donderdag 23 oktober 2003 20:22
To: [EMAIL PROTECTED]
Subject: Re: repository block (was Re: [RT] Source extensions)
Unico Hommes [EMAIL PROTECTED] wrote
Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
Sorry to jump in late, but I would like you to consider the
VersionedSource interface I wrote for the CVSSource over at
cocoondev.org ([1], damn LGPL constraints which forces it
to be hosted
out of Cocoon's
Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
Sorry to jump in late, but I would like you to consider
the VersionedSource interface I wrote for the CVSSource over
at cocoondev.org ([1], damn LGPL
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Unico Hommes wrote:
snip/
I see a slight advantage as you point out but to me it's
not worth the
confusion that will arise.
Others?
I see Vadims point, but I don't prefer it. We should try to
get the old
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
It seems that all loggers assigned to sitemap components
are getting
their category prepended with 'sitemap'.
Defining transformer name=xslt
logger=sitemap.transformer.xslt
/ the transformer will get
Trying to figure out how to use the Cocoon build system to most
conveniently develop samples I first added a way to invoke an individual
${block.name}-samples target.
If you do:
# build -Dblock.name call-block-samples
The samples of the ${block.name} block will be built into the
build/webapp
That was my fault. I'm sorry about that, I wasn't aware that
dependencies should be specified in the blocks properties file.
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: donderdag 30 oktober 2003 12:46
To: Apache Cocoon
I tried to compile the
I'm in the process of refactoring and furthering the davmap samples in
the WebDAV block. Methods that I've added are DELETE and MKCOL, and will
be adding a PROPPATCH in the following few days and look into LOCK, COPY
and MOVE methods as well. I've also made some general improvements to
PROPFIND,
Stefano Mazzocchi wrote:
Talking about perfect timing ;-)
On Thursday, Oct 30, 2003, at 15:46 Europe/Rome, Unico Hommes wrote:
I'm in the process of refactoring and furthering the davmap
samples in
the WebDAV block. Methods that I've added are DELETE and MKCOL
;)
--
Konstantin
- Original Message -
From: Unico Hommes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 31, 2003 16:44
Subject: RE: cvs commit: cocoon-2.2/src/webapp/WEB-INF cocoon.xconf
Yes, that would be even better. I didn't realize extending
AbstractJXPathModule
Is this the way it's done in Fortress too? I vaguely remember it passes
the LoggerManager in the Context object? I would prefer the way Fortress
exposes the LoggerManager for consistency with 2.2.
-- Unico
-Original Message-
From: peter royal [mailto:[EMAIL PROTECTED]
Sent:
Stefano Mazzocchi wrote:
In my doco wandering, I tried to mount the cocoon DAV repository
(found
in the 'davmap' directory of the webdav block) under macosx as a disk,
but fails. I tried with mod_dav on httpd 2.0.47 and it works.
Further inspection (with the good old tcpflow) indicates
Guido Casper wrote:
Stefano Mazzocchi [EMAIL PROTECTED] wrote:
snip/
Now, the first thing to ask is:
1) is DAV: DAV:1 correct? I would expect DAV: 1 to be the correct
header
Checking the spec at
http://ftp.ics.uci.edu/pub/ietf/webdav/protocol/rfc2518.html#HEADER_DAV
it
Gianugo Rabellino wrote:
Unico Hommes wrote:
Should we strive for strict compatibility in the short term?
IMO, yes. We are now building a foundation for Cocoon to be a viable
DAV
server, and this should include finding all the possible shortcomings
and solve them now instead than
Unico Hommes wrote:
As for the empty response body. It would be a matter of having a
serializer supressing it.
Another option is to set the response headers in the flow and refrain
from sending any page at all.
Hmm, but this seems not to be possibly :-( I get no pipeline matched
Stefano Mazzocchi wrote:
On Saturday, Nov 1, 2003, at 16:16 Europe/Rome, Unico Hommes wrote:
Unico Hommes wrote:
As for the empty response body. It would be a matter of having a
serializer supressing it.
Another option is to set the response headers in the flow and
refrain
Sylvain Wallez wrote:
Unico Hommes wrote:
Stefano Mazzocchi wrote:
snip/
No, not really. In fact, if we want cocoon to take care of lower
level
HTTP details (like proxies sending HEAD requests to get URL etags),
sending empty responses is a big help.
I just had a look
Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
snip/
I just had a look at the code, seems it was already a FIXME on
Sylvain's list. Can I go ahead and make this change?
Uh? Where's that list??
CallFunctionNode.java ln 166/184
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: maandag 3 november 2003 9:52
To: [EMAIL PROTECTED]
Unico Hommes wrote:
snip/
We were talking about the fact that it seemed impossible to
serve a request without also sending an entity body along
Berin Loritsch wrote:
Unico Hommes wrote:
- Recomposable / Reconfigurable interfaces: no solution yet, needs
refactoring.
We need to make these unneeded.
- Support for current sitemap syntax instead of Fortress shorthand
syntax (?)
Easy enough to do. All you need to do
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: maandag 3 november 2003 12:45
To: [EMAIL PROTECTED]
Unico Hommes wrote:
snip/
IMO, this should be handled at the pipeline level, i.e. on
a HEAD request, the pipeline should be built and setup
}
/format
appendfalse/append
/cocoon
/targets
categories
category log-level=DEBUG name=mycategory
log-target id-ref=mycomponent/
log-target id-ref=error/
/category
/categories
Whats happening?
-Tuomo
On Tue, 4 Nov 2003, Unico Hommes wrote:
Either
, that fixed it! :) But what is the logic of this?
-Tuomo
On Tue, 4 Nov 2003, Unico Hommes wrote:
In your logkit.xconf try category
name=sitemap.mycategory instead
of just category name=mycategory
-- Unico
-Original Message-
From: Tuomo L [mailto:[EMAIL PROTECTED
I've done what Peter suggested. It was a minimal change in Cocoon class
and SitemapLanguage class. I've also verified that Fortress also makes
the LoggerManager available from the ServiceManager. I believe we should
fix this now instead of later and have it included in the upcoming 2.1.3
release.
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 0:12
To: [EMAIL PROTECTED]
On Tuesday, Nov 4, 2003, at 14:21 Europe/Rome, Unico Hommes wrote:
Working on davmap I noticed that the way I was setting the
status code
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: maandag 3 november 2003 13:16
To: [EMAIL PROTECTED]
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
snip/
Uh (again)? I'm wondering if there's not a misunderstanding
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 12:42
To: [EMAIL PROTECTED]
On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote:
setStatus' friends the sendError brothers are also be
eligible for FOM
-Original Message-
From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 14:02
To: [EMAIL PROTECTED]
Stefano Mazzocchi wrote:
setStatus' friends the sendError brothers are also be eligible for
FOM membership. But this change has a dependency
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 13:55
To: [EMAIL PROTECTED]
Le Mercredi, 5 nov 2003, à 13:11 Europe/Zurich, Reinhard
Poetz a écrit :
...I'm +1 with the idea to send pages without payload but -0 with
-Original Message-
From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 14:29
To: [EMAIL PROTECTED]
Unico Hommes wrote:
-Original Message-
From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 14:02
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 15:12
To: [EMAIL PROTECTED]
Unico Hommes wrote:
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 13:55
I know, I did that. The repository block depends on the databases block.
Look for the inspector configuration entry in cocoon.xconf. Inside is a
configuration for a SimpleJdbcSourceDescriptor. It uses the personel
datasource. Should I comment the offending configuration? Or should the
user?
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 15:25
To: [EMAIL PROTECTED]
Subject: Re: [Vote] empty HTTP responses [was Re: Cannot
easily set http status]
On Wednesday, Nov 5, 2003, at 14:20 Europe/Rome, Unico Hommes
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 21:23
To: [EMAIL PROTECTED]
(moving the discussion to @dev)
Unico Hommes wrote:
snip/
Mmmh... careful here : you're relying on a unspecified
behaviour that allows a flow
, Unico Hommes wrote:
I've done what Peter suggested. It was a minimal change in Cocoon
class and SitemapLanguage class. I've also verified that Fortress
also makes the LoggerManager available from the ServiceManager. I
believe we should fix this now instead of later and have
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: donderdag 6 november 2003 13:31
To: Avalon Developers List
Cc: Cocoon-Dev
Volker found recently a hugh performance problem in the
current DefaultComponentFactory in Excalibur.
You can find more
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: donderdag 6 november 2003 14:16
To: [EMAIL PROTECTED]; Avalon Developers List
Unico Hommes wrote:
I thought this proxy was needed for migration from component to
service package? So that users can
Sylvain Wallez wrote:
Ryan Hoegg wrote:
peter royal wrote:
Anyone:
Any thoughts about using Jelly as the builder for the sitemap?
Its usage can be completely hidden, but as a tag processor, it might
work very well. We could use it to construct a bean-graph to model
the sitemap.
-pete
Me felt stupid too once ;-)
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=106500375605928w=2
-Original Message-
From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
Sent: maandag 10 november 2003 1:26
To: [EMAIL PROTECTED]
Subject: Newbie flow question: calling a delete() method
Unico Hommes wrote:
- cocoon.sendStatus(status)
- cocoon.sendStatus(status, message)
- cocoon.response.setStatus(status)
- cocoon.response.setStatus(status,message)
The vote passed. (I think) I counted 6 positive votes and no negative
ones. I will be making the changes right after the code
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: maandag 10 november 2003 11:50
To: [EMAIL PROTECTED]
Unico Hommes wrote:
Unico Hommes wrote:
- cocoon.sendStatus(status)
- cocoon.sendStatus(status, message)
- cocoon.response.setStatus(status
I know, I was thinking there will be so many changes going on there and
that it will work itself out by itself when we move to Fortress.
Unico
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: vrijdag 7 november 2003 23:21
To: [EMAIL PROTECTED]
Unico
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: maandag 10 november 2003 16:44
To: [EMAIL PROTECTED]
Unico Hommes wrote:
Sylvain Wallez wrote:
Ryan Hoegg wrote:
peter royal wrote:
Anyone:
Any thoughts about using Jelly
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: maandag 10 november 2003 17:31
To: [EMAIL PROTECTED]
Unico Hommes wrote:
snip/
Here the match element both represents a component
declaration of a MatchNode to the container _and_ a
configuration
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: maandag 10 november 2003 18:30
To: [EMAIL PROTECTED]
Subject: Re: Migrating TreeProcessor to Fortress
Unico Hommes wrote:
Sorry, but I'm a bit lost here. Aren't we mixing processing
nodes and
sitemap
I am still learing to vote properly ;-)
Sylvain Wallez wrote:
Let's reformulate this into a proper vote.
Do you want to enforce the fact that flowscript calls (either
function
or continuation) *must* redirect using sendPage,
sendPageAndWait or redirectTo and that, should it not be the
O dear, did I just break the code freeze? Or what does it actually mean
a code freeze? (Still not clear after discussion on the other thread)
Does it include changes like this?
Actually this could have waited 'till after the release. I just forgot.
Sorry about this.
Unico
-Original
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: dinsdag 11 november 2003 0:30
To: [EMAIL PROTECTED]
On 10.11.2003 21:27, Unico Hommes wrote:
* sitemap-container.xconf:
fortress
pipeline id=p1
match id-ref=p1-m1 /
match id-ref=p1
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: dinsdag 11 november 2003 21:48
To: [EMAIL PROTECTED]
Hi all,
Here's a RT about Unico's proposal of flattening the
sitemap for the migration to Fortress. Please read carefully,
this has a lot of
-Original Message-
From: Unico Hommes
Sent: maandag 10 november 2003 12:11
To: [EMAIL PROTECTED]
snip/
Sylvain Wallez wrote:
Furthermore, I would like this feature to be defined at the
environment level and not only in the flowscript. Methods of
the
cocoon object
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: donderdag 13 november 2003 16:31
To: [EMAIL PROTECTED]
Subject: Re: Bastardized URL protocol
Carsten Ziegeler wrote:
Berin Loritsch wrote:
Just because we have one protocol that is messed up and
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: vrijdag 14 november 2003 18:05
To: [EMAIL PROTECTED]
Subject: Re: [VOTE RESULTS] FOM sendStatus/setStatus
Unico Hommes wrote:
-Original Message-
From: Unico Hommes
Sent: maandag 10
Aw blast, I meant to say Composable - Serviceable off course.
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: maandag 17 november 2003 12:07
To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
unico 2003/11/16 10:52:36
Modified:
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: maandag 17 november 2003 17:08
To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
unico 2003/11/14 10:58:18
Modified:
src/java/org/apache/cocoon/components/flow/javascript/fom
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: maandag 17 november 2003 19:05
To: [EMAIL PROTECTED]
Subject: Re: cvs commit:
cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascri
pt/fom FOM_Cocoon.java
Unico Hommes wrote:
snip/
Yeah
Nice article!
We do basically the same thing. Note that with MountTableMatcher you no
longer need to patch the cocoon root sitemap.
It is too bad that Ant does not itself support a pluggable architecture.
Now you end up replicating such a build environment in every new
project. If something
Giacomo Pati wrote
Unico Hommes wrote:
Nice article!
We do basically the same thing. Note that with
MountTableMatcher you
no longer need to patch the cocoon root sitemap.
Why people often say so? There is no need to patch the root sitemap
anyway as it is simply trying
Jeremy Quinn wrote:
On 19 Nov 2003, at 18:37, Upayavira wrote:
Jeremy,
Splendid article. Stuff I've been thinking about a lot recently too.
Just one useful quote from the Ant manual:
property environment=env/
echo message=Number of Processors =
${env.NUMBER_OF_PROCESSORS}/
It should be. Just do it.
Unico
-Original Message-
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Sent: maandag 24 november 2003 14:18
To: [EMAIL PROTECTED]
Hi:
It is OK the following libs changes in cocoon 2.2:
Add (from cocoon 2.1):
excalibur-event-api-1.0.4-dev.jar
1 - 100 of 414 matches
Mail list logo
