Re: Logkit jvadocs

Vadim Gritsenko wrote: > > ATM, I'd say do what you want as long as: > > * Cocoon 2.1 stays as it is. > * Cocoon 2.2 can be run with LogKit. > > I.e., I'm ok if you switch default to Log4J and remove logkit.jar, as long as > I > can put it back and change the default back to LogKit. > Ye

Re: Logkit jvadocs

Niclas Hedhman wrote: > > IMHO, the long-term(!) strategy should be to use the JDK Logging as the API, > and "innovative people" will figure out how to redirect that to Log4J or > something else. > Yes, my thoughts go in the same direction: why not use the JDK logging? It's available and doesn

Re: svn commit: r179405 - in /cocoon/blocks/portal/trunk/java/org/apache/cocoon/portal/event: EventManager.java Publisher.java Receiver.java Register.java aspect/EventAspectContext.java impl/DefaultEventManager.java

Ralph Goers wrote: > > Do you have any details of where you want to go with this? Is it safe > to assume you want to deprecate Subscriber? Yepp - the whole event manager/subscriber/publisher/register thing is imho way too complex. So I merged publisher and register into the event manager and si

Re: svn commit: r179405 - in /cocoon/blocks/portal/trunk/java/org/apache/cocoon/portal/event: EventManager.java Publisher.java Receiver.java Register.java aspect/EventAspectContext.java impl/DefaultEventManager.java

[EMAIL PROTECTED] wrote: Author: cziegeler Date: Wed Jun 1 12:40:16 2005 New Revision: 179405 URL: http://svn.apache.org/viewcvs?rev=179405&view=rev Log: Start new, simpler event infrastructure Do you have any details of where you want to go with this? Is it safe to assume you want to de

Re: Logkit jvadocs

On Wednesday 01 June 2005 15:00, Ralph Goers wrote: > I'm also -1.  I might consider replacing logkit with UGLI, but not LOG4J > directly. However, (a) UGLI is part of LOG4J 1.3 which is still alpha, > (b) an analysis needs to be done to determine how UGLI performs compared > to logkit, and (c) it

Re: ImageMap widget for CForms

Hi Luca > I made my first Cocoon widget :) > > It isn't at all that hard, though I managed to waste time by trying to > subclass my widget from the Action class :( Congratulations , I'll definitly be looking into this > > Anyway, here's how to use it: > 1) Definition document: > > > refresh.hi

Re: ImageMap widget for CForms

Vadim Gritsenko wrote: Luca Morandini wrote: Thanks for the suggestion, I'll work on it. MapEvent will allow to use event.x, event.y or some such instead of 'cocoon.request.getParameter("map.y")', which is eww ;-) Understood: I'll amend the ImageMap widget early next week. Regards,

Re: XSP: EclipseJavaCompiler chokes on warings

Jochen Kuhnle wrote: BTW: What is the preferred way to report bugs in both 2.1 and 2.2? Create an entry for 2.1, one for 2.2, or one for each? Only one bug for both, please, with version set to "2.1". Description might mention that it should be applied to 2.2 as well. Vadim

Re: ImageMap widget for CForms

Luca Morandini wrote: Vadim Gritsenko wrote: Luca Morandini wrote: function onClickMap () { var x= Number(cocoon.request.getParameter("map.x")); var y= Number(cocoon.request.getParameter("map.y")); Eww! Ahem... what "Eww!", exactly, means ? :-) http://www.urbandictionary.com

Re: Logkit jvadocs

Carsten Ziegeler wrote: Antonio Gallardo wrote: Well, I think it is time to discuss again. I still think we should remove the dependency to LogKit in 2.2 - we all see now that it's a dead project. So is there any reason to keep it? Noone else is using it and removing the dependency to LogKit

Re: xslt and jxtg performance

Peter Hunsberger wrote: On 5/31/05, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: BURGHARD Éric wrote: Daniel Fagerstrom wrote: If you want to help making JXTG faster you need to submit more information. We need examples that reproduce this behaviour with the JXTG template and the correspond

RE: XSP: EclipseJavaCompiler chokes on warings

"Antonio Gallardo" <[EMAIL PROTECTED]> wrote on 31.05.2005 17:15:20: > On Mar, 31 de Mayo de 2005, 9:22, Nathaniel Alfred dijo: > > I wouldn't want to tolerate warnings in all XSPs only because it cannot be > > avoided in some of them. It should be a configuration parameter on the > > ServerPag

DO NOT REPLY [Bug 35162] - EclipseJavaCompiler chokes on warnings

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35162] New: - EclipseJavaCompiler chokes on warnings

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35161] - EclipseJavaCompiler chokes on warnings

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35161] New: - EclipseJavaCompiler chokes on warnings

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: xslt and jxtg performance

On 5/31/05, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: > BURGHARD Éric wrote: > > Daniel Fagerstrom wrote: > > > >>If you want to help making JXTG faster you need to submit more > >>information. We need examples that reproduce this behaviour with the > >>JXTG template and the corresponding XSLT.

DO NOT REPLY [Bug 35144] - Database / avalon problems

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [SUMMARY] Caching DynamicSelectionList

Antonio Gallardo agssa.net> writes: > > I don't think having a shorter cache period than a > > form processing (as part of one request) makes no sense as it leads > > to inconsistent forms when a selection list is reused. > > Please explain. More this. Are you telling a cache life shorter than a

Re: Logkit jvadocs

On Mie, 1 de Junio de 2005, 9:40, Carsten Ziegeler dijo: > Daniel Fagerstrom wrote: >> >> Would be hard to stop you I guess ;) >> >> Could you write a summary of the main issues and solution suggestions >> from that thread? So that we don't need to repeat that discussion again. >> > IMHO, we should

Re: Logkit jvadocs

Daniel Fagerstrom wrote: > > Would be hard to stop you I guess ;) > > Could you write a summary of the main issues and solution suggestions > from that thread? So that we don't need to repeat that discussion again. > IMHO, we should split the vote: a) remove dependency to LogKit b) select anoth

Re: [SUMMARY] Caching DynamicSelectionList

On Mar, 31 de Mayo de 2005, 16:26, Joerg Heinicke dijo: > Vadim's comments made me think again about the caching of selection > lists. And I don't think having a shorter cache period than a > form processing (as part of one request) makes no sense as it leads > to inconsistent forms when a selectio

Re: Logkit jvadocs

Antonio Gallardo wrote: On Mar, 31 de Mayo de 2005, 13:53, Daniel Fagerstrom dijo: Antonio Gallardo wrote: IMHO, that means Logkit is dead. Is time to moving setup log4j as our default logging package. Is that OK? Antonio, Logkit has been dead for quite some time and we hav

Re: Logkit jvadocs

On Mar, 31 de Mayo de 2005, 13:53, Daniel Fagerstrom dijo: > Antonio Gallardo wrote: > >> IMHO, that means Logkit is dead. >> >> Is time to moving setup log4j as our default logging package. >> >> Is that OK? > > Antonio, > > Logkit has been dead for quite some time and we have long discussions >

Re: mod_cache and Content-length

On 1 Jun 2005, at 06:25, Bertrand Delacretaz wrote: Le 31 mai 05, à 23:12, Pier Fumagalli a écrit : ...Erm... Apache caches also without "Content-Length" (it actually calculates that for you)... In production, this is my configuration:.. Do you know which of these options cause this beh

Re: Google Summer of Code - projects and mentors wanted

Le 1 juin 05, à 13:51, Mark Leicester a écrit : I have entered a project at http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc An excellent proposal! I'll be around during that period and am keen to offer my 2p also. Thanks! Of course, all technical discussions about these projec

[OT] Re: FYI: searches in May

Le 1 juin 05, à 14:02, Mark Leicester a écrit : ...7gianugo rabellino... So, it looks like Gianugo is the only one here to have a fan's club...sigh... -Bertrand smime.p7s Description: S/MIME cryptographic signature

FYI: searches in May

Hello, I think it's really useful to use search statistics as a way to work out what a community is thinking about/looking for (a zeitgeist, if you like). So, I've published a summary of the top 25 search keywords used to access Planet Cocoon during May (out of a total of 1828 referrals from

Re: Google Summer of Code - projects and mentors wanted

I have entered a project at http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc An excellent proposal! I'll be around during that period and am keen to offer my 2p also. Mark

Re: Google Summer of Code - projects and mentors wanted

Hi Ross, Bertrand Delacretaz wrote: I have entered a project at http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc, and I'm looking for at least one co-mentor, as I'll be partially offline in July and August. If someone's available for this, please let me know. Bertrand, I w

Re: Logkit jvadocs

On Mie, 1 de Junio de 2005, 6:13, Carsten Ziegeler dijo: > Antonio Gallardo wrote: > >> >> Perhaps telling to replace with log4j was not good. We can change it >> with >> whatever else, but I don't want to have a non-suported jar in our >> distro. >> > Yes, but there are only a few possibilities th

Re: Logkit jvadocs

On Mie, 1 de Junio de 2005, 2:00, Ralph Goers dijo: > Antonio Gallardo wrote: > >>On Mar, 31 de Mayo de 2005, 14:05, Vadim Gritsenko dijo: >> >> >Is time to moving setup log4j as our default logging package. > >Is that OK? > > >>>-1 >>> >>> > I'm also -1. I might consider repla

Re: Logkit jvadocs

Antonio Gallardo wrote: > > Perhaps telling to replace with log4j was not good. We can change it with > whatever else, but I don't want to have a non-suported jar in our distro. > Yes, but there are only a few possibilities that make sense: log4j, commons logging, jdk14 - we can still support al

Re: Logkit jvadocs

On Mie, 1 de Junio de 2005, 1:58, Carsten Ziegeler dijo: > Antonio Gallardo wrote: >> >> Well, I think it is time to discuss again. >> > I still think we should remove the dependency to LogKit in 2.2 - we all > see now that it's a dead project. So is there any reason to keep it? This is the idea,

Re: Logkit jvadocs

On Mar, 31 de Mayo de 2005, 13:50, Reinhard Poetz dijo: > Antonio Gallardo wrote: >> IMHO, that means Logkit is dead. >> >> Is time to moving setup log4j as our default logging package. >> >> Is that OK? > > haven't we already discussed this several times and always decided not to > change it? I t

Re: Google Summer of Code - projects and mentors wanted

Bertrand Delacretaz wrote: Cocoonistas, You might have noticed yesterday's announcement at http://code.google.com/ about the Summer of Code initiative, http://code.google.com/summerofcode.html We should have more detailed info for the ASF communities in the next few days (we're still ironin

could someone change the topic on the IRC #cocoon channel?

heymjo rightly points out that the current topic Apache Cocoon (http://cocoon.apache.org/) and related matters (XSP, XSLT, XML, ...) is not "mainstream-compliant" ;-) could someone with admin rights change it to something like Apache Cocoon (http://cocoon.apache.org/) and related matters (Fl

Re: Server-side image map in CForms ?

oceatoon wrote: I am not at all from the GIS , and project Geoid seems to be just that, If I'm not mistaken it allows to plug into existing ArcIMS and others with Cocoon. I'm really looking to find a Map system I can integrate directly into my(and others) project. I really think a simple Mapping

DO NOT REPLY [Bug 35144] - Database / avalon problems

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: ImageMap widget for CForms

Vadim Gritsenko wrote: Luca Morandini wrote: function onClickMap () { var x= Number(cocoon.request.getParameter("map.x")); var y= Number(cocoon.request.getParameter("map.y")); Eww! Ahem... what "Eww!", exactly, means ? var uri; uri= ""; frm.getWidget().lookupWidg

RE: [RFE] Some enhancements to XSP

> -Original Message- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 31. Mai 2005 15:30 > To: dev@cocoon.apache.org > Subject: Re: [RFE] Some enhancements to XSP > > Instead of "?" one could also use another character provided it is > > sufficiently > > unlikely that t

Google Summer of Code - projects and mentors wanted

Cocoonistas, You might have noticed yesterday's announcement at http://code.google.com/ about the Summer of Code initiative, http://code.google.com/summerofcode.html We should have more detailed info for the ASF communities in the next few days (we're still ironing out the details about proj

RE: [RFE] Some enhancements to XSP

> -Original Message- > From: Jochen Kuhnle [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 31. Mai 2005 14:07 > To: dev@cocoon.apache.org > Subject: RE: [RFE] Some enhancements to XSP > > Any preferrences which character to use? > > Out of purely unrational affection, I prefer "#{" and "}".

Re: Logkit jvadocs

On 01 Jun 2005, at 09:00, Ralph Goers wrote: Your statement implies that once a project matures and fulfills its purpose that it should then be abandoned because no new development is being done. That doesn't make sense. +1 -- Steven Noelshttp://outerthought.org/

Re: Logkit jvadocs

Ralph Goers wrote: >> > If you are talking about keeping the dependency on > org.apache.avalon.excalibur.logger.LoggerManager and > org.apache.avalon.framework.logger.Logger in CocoonServlet, then I don't > really care as those are the two interfaces I implement to use my own > logging framework.

Re: Logkit jvadocs

Il giorno 01/giu/05, alle 08:58, Carsten Ziegeler ha scritto: I still think we should remove the dependency to LogKit in 2.2 - we all see now that it's a dead project. So is there any reason to keep it? Noone else is using it and removing the dependency to LogKit does *not* mean that our logging

Re: Logkit jvadocs

Carsten Ziegeler wrote: Antonio Gallardo wrote: Well, I think it is time to discuss again. I still think we should remove the dependency to LogKit in 2.2 - we all see now that it's a dead project. So is there any reason to keep it? Noone else is using it and removing the

Re: Logkit jvadocs

Ralph Goers wrote: Antonio Gallardo wrote: On Mar, 31 de Mayo de 2005, 14:05, Vadim Gritsenko dijo: Is time to moving setup log4j as our default logging package. Is that OK? -1 I'm also -1. I might consider replacing logkit with UGLI, but not LOG4J directly. However, (a) UG

Re: Logkit jvadocs

Leszek Gawron wrote: > > Not that totally: we do not have a cocoon log formatter giving the same > functionality as the logkit one. > You're right. But I guess it would be easy to provide a formatter for whatever logging system we decide to use. Carsten -- Carsten Ziegeler - Open Source Group

Re: Logkit jvadocs

Antonio Gallardo wrote: On Mar, 31 de Mayo de 2005, 14:05, Vadim Gritsenko dijo: Is time to moving setup log4j as our default logging package. Is that OK? -1 I'm also -1. I might consider replacing logkit with UGLI, but not LOG4J directly. However, (a) UGLI is part of LOG4J

Re: Logkit jvadocs

Carsten Ziegeler wrote: Antonio Gallardo wrote: Well, I think it is time to discuss again. I still think we should remove the dependency to LogKit in 2.2 - we all see now that it's a dead project. So is there any reason to keep it? Noone else is using it and removing the dependency to LogKit