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=37005.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
-Oorspronkelijk bericht-
Van: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Verzonden: maandag 17 oktober 2005 18:30
Aan: dev@cocoon.apache.org
Onderwerp: Startable components
Hi all,
I changed the lazy loading so that preload=true is no more needed
for
components that *must* be
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=37005.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Bart Molenkamp wrote:
Why are marker interfaces preferred over this configuration style? These
interfaces introduce another dependency on Avalon. I think it is better
to not have these code dependencies, but to use configuration. This
makes it easier to host those components in other
-Oorspronkelijk bericht-
Van: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Bart Molenkamp wrote:
Why are marker interfaces preferred over this configuration style?
These
interfaces introduce another dependency on Avalon. I think it is
better
to not have these code dependencies,
Sylvain Wallez wrote:
* portal block, pluto/adapter/PortletAdapter:
Same as above, for the hypothetical case where Pluto would create
threads. Now this variable is set() but never get()!!! So we could
remove it completely. Carsten?
Removed - it seems to be a relict of an older version.
*
Bart Molenkamp wrote:
-Oorspronkelijk bericht-
Van: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Verzonden: maandag 17 oktober 2005 18:30
Aan: dev@cocoon.apache.org
Onderwerp: Startable components
Hi all,
I changed the lazy loading so that preload=true is no more needed for
components
Carsten Ziegeler wrote:
Bart Molenkamp wrote:
And I thought that people here rather move away from Avalon's
interfaces. Then why introduce another dependency on it, when
configuration can do the same?
Yes, I tend to agree with you. So let's forget about the new interface
and use the
Ralph Goers wrote:
In this case I don't believe I agree. Configuration is great when
things need to be configurable. But if a component can only operate
when configured a certain way then what is gained by that? In that case
it should be hard-wired.
Hmm, yes but the problem is
Carsten Ziegeler wrote:
Bart Molenkamp wrote:
Why are marker interfaces preferred over this configuration style? These
interfaces introduce another dependency on Avalon. I think it is better
to not have these code dependencies, but to use configuration. This
makes it easier to host those
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
* portal block, pluto/adapter/PortletAdapter:
Same as above, for the hypothetical case where Pluto would create
threads. Now this variable is set() but never get()!!! So we could
remove it completely. Carsten?
Removed - it seems to be a
Sylvain Wallez wrote:
And I don't think we should be using it. As said in my previous post,
Avalon has always used interfaces to specify the lifecycle. Moving this
information in the configuration brings the responsibility of defining
the lifestyle to configuration writers that up to now
Hi,
I've noticed that compared with Cocoon 2.1.7, exceptions that are thrown
in flow code (apples in my case) are now wrapped into an additional
ProcessingException (to add the location information). For actions this
does not seem to be the case (an oversight?) but when they are in a
subsitemap
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
While working on the block architecture yesterday, I saw that most of
the test cases
(org.apache.cocoon.test.components.blocks.BlocksManagerTestCase)
failed. The problem was that block local files where resolved in
wrong context. After having
On Mon, 2005-10-17 at 14:01 +0200, Sylvain Wallez wrote:
Carsten Ziegeler wrote:
I briefly looked at the Ajax and the cforms block and I think there are
two problems here:
a) cforms depends on ajax block (which is ok), so why is there a
CForms: new Object(), in the cocoon-ajax.js?
Bruno Dumon wrote:
On Mon, 2005-10-17 at 14:01 +0200, Sylvain Wallez wrote:
Carsten Ziegeler wrote:
I briefly looked at the Ajax and the cforms block and I think there are
two problems here:
a) cforms depends on ajax block (which is ok), so why is there a
CForms: new Object(), in the
-Oorspronkelijk bericht-
Van: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 18 oktober 2005 10:18
Aan: dev@cocoon.apache.org
Onderwerp: Re: Startable components
Carsten Ziegeler wrote:
Bart Molenkamp wrote:
Why are marker interfaces preferred over this
Bart Molenkamp wrote:
I understand that both the configuration and the marker interface
options are working, great. But I'm still not satisfied by your answer,
sorry. My points:
1. I don't see that much difference between a developer and a
configuration writer.
That's because you are a
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 has an issue affecting its community integration.
This issue affects 55
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 has an issue affecting its community integration.
This issue affects 55
On 10/18/05, Sylvain Wallez [EMAIL PROTECTED] wrote:
snip/
Yes! Basically, this is a retro-factoring of the JS library to the
pre-Scriptaculous version.
I've been following your activities WRT to AJAX with some interest.
We've got our own forms and screen management system that we are also
Hi,
Does anyone know what's involved in converting the repository at [1] to
use m2 layout ?
Any plans to create an apache m2 repository that is synced automatically
to ibiblio ?
Thanks
Jorg
[1] http://www.apache.org/dist/java-repository/
Jorg Heymans wrote:
Hi,
Does anyone know what's involved in converting the repository at [1] to
use m2 layout ?
Any plans to create an apache m2 repository that is synced automatically
to ibiblio ?
The repository [1] is synced with ibiblio. Actually it should only be
used to upload
I want to deprecate the AbstractUserProfileManager and the
AuthenticationProfileManager in the portal in 2.1.8 (and remove them in
2.2).
The newer GroupBasedProfileManager provides the same functionality in a
much cleaner way. With deprecating the old stuff, we can get rid of a
lot of things in
Ok, this is the result we have so far:
HTML: 8x +1
Just PDF: 2x -1
Both: 5x +1
So it seems that we just want to have HTML docs for the distribution.
Now as 6 committers suggested/voted to separate the docs from the
release, I think this is a good idea.
Actually, I'm now searching for a
Carsten Ziegeler wrote:
I want to deprecate the AbstractUserProfileManager and the
AuthenticationProfileManager in the portal in 2.1.8 (and remove them in
2.2).
The newer GroupBasedProfileManager provides the same functionality in a
much cleaner way. With deprecating the old stuff, we can get
Carsten Ziegeler wrote:
The repository [1] is synced with ibiblio. Actually it should only be
used to upload stuff to ibiblio and then removed from [1]. m2 is able to
read m1 repositories. What are your ideas?
Well experiments with the recent m2 RC shows that we will be getting
tons of
Carsten Ziegeler schrieb:
I want to deprecate the AbstractUserProfileManager and the
AuthenticationProfileManager in the portal in 2.1.8 (and remove them in
2.2).
The newer GroupBasedProfileManager provides the same functionality in a
much cleaner way. With deprecating the old stuff, we can
Jorg Heymans wrote:
Well experiments with the recent m2 RC shows that we will be getting
tons of these during each execution of build/compile/whatevertarget :
[WARNING] POM for:
'excalibur-sourceresolve:excalibur-sourceresolve:pom:2.1' does not
appear to be valid. Its will be ignored for
* Carsten Ziegeler:
I want to deprecate the AbstractUserProfileManager and the
AuthenticationProfileManager in the portal in 2.1.8 (and remove
them in 2.2).
What does it mean for us poor users? Just a change in
cocoon.xconf?
--
Jean-Baptiste Quenot
Systèmes d'Information
Jean-Baptiste Quenot wrote:
* Carsten Ziegeler:
I want to deprecate the AbstractUserProfileManager and the
AuthenticationProfileManager in the portal in 2.1.8 (and remove
them in 2.2).
What does it mean for us poor users? Just a change in
cocoon.xconf?
Yepp, just
Leszek Gawron wrote:
...
I have commited an initial version of javascript support in jxtg.
Looks like it's working although I have not tested it much.
just as the commit message says:
use @{expression} for jxtg and {js:expression} for CTemplate
(CTemplate is not available without some .xconf
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
...
Currently, both the resolvers (in setup() and in the manager) use the
same base URL. I'm afraid that changing this would break a lot of
things...
Yes, you are right, the risk is to high. Also it seem to be a lot
Daniel Fagerstrom wrote:
Ok, I guess that we have to go for your solution of having several
variants of the source resolver:
SourceResolver.ROLE + /static - resolve relative to the defining
manager, and is implemented as I indicated above. We could modify
CoreComponentManager so that it
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Ok, I guess that we have to go for your solution of having several
variants of the source resolver:
SourceResolver.ROLE + /static - resolve relative to the defining
manager, and is implemented as I indicated above. We could modify
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=37149.
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=37149.
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=37149.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Daniel Fagerstrom wrote:
The current behaviour is flawed as we already know from e.g. the case
with the I18N transformer where dynamic resolution is used when static
is what would have been expected. With lazy loading things get even
worse as resolution during the setup phase also can
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
...
I have commited an initial version of javascript support in jxtg.
Looks like it's working although I have not tested it much.
just as the commit message says:
use @{expression} for jxtg and {js:expression} for CTemplate
(CTemplate is not
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
The current behaviour is flawed as we already know from e.g. the case
with the I18N transformer where dynamic resolution is used when static
is what would have been expected. With lazy loading things get even
worse as resolution during the
Sylvain Wallez wrote:
And actually 3 resolvers, as we also have the one in setup() of
sitemap components :-)
Here's another suggestion that doesn't need a new component.
First of all, when a component is setup (i.e. Avalon lifecycle
interfaces), the relative path must *always* be the one
Hoping to focus the current momentum on cocoon application generators,
scaffolds and the like, I thought I'ld just clarify what exactly m2
archetypes are and what they can do for us.
What are they ?
---
From the m2 docs : An archetype is simply a JAR file that contains
the project
Steven Noels wrote:
Carsten Ziegeler wrote:
As our documentation is now managed by Daisy, we don't have the docs in
the source repository anymore. For the release we should include docs
in
the distributions.
It seems to me that we have three choices (please correct me if I'm
wrong):
Hi,
I've created an archetype that sets up a working cocoon core
webapplication without any blocks.
Basically what you would do is run
m2 archetype:create -DarchetypeGroupId=apache-cocoon
-DarchetypeArtifactId=cocoon-archetype-core
-DarchetypeVersion=2.2-SNAPSHOT -DgroupId=my.application.com
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
* All threads will be created in the ThreadGroup of the request
processing thread, will attempt to modify said group, and
can fail with SecurityException (you can create thread in a
thread group only if you have modifyThreadGroup
Sylvain Wallez wrote:
Bart Molenkamp wrote:
snip/
Knowing the configuration settings of a component
can also require (deep) knowledge about the implementation. And,
configuration writers don't need to write the configuration from
scratch, the already configured defaults are sufficient.
Bertrand Delacretaz wrote:
Le 15 oct. 05, à 19:00, Antonio Gallardo a écrit :
...If users got the time to report the bugs, I think at least we owe
them a real bug review. Just request more info if needed.
WDYT?
I think that issues are piling up in bugzilla and we obviously don't
have
48 matches
Mail list logo
