cvs commit: avalon-excalibur/instrument-manager/src/java/org/apache/excalibur/instrument/manager/http SampleChartHandler.java LineChart.java

leif2004/01/29 22:39:35 Modified:instrument-manager/src/java/org/apache/excalibur/instrument/manager/http SampleChartHandler.java LineChart.java Log: Display the year for sample intervals over 24 hours. Revision ChangesPath 1.3 +20 -13

cvs commit: avalon-excalibur/instrument-manager/src/java/org/apache/excalibur/instrument/manager AbstractInstrumentSample.java

leif2004/01/29 22:39:00 Modified:instrument-manager/src/java/org/apache/excalibur/instrument/manager AbstractInstrumentSample.java Log: Make sure that the allignment of large sample periods takes the current timezone into account. Revision Changes

[GUMP@lsd]: avalon-sandbox/avalon-cache failed

Project: avalon-cache State: Failed URL: http://lsd.student.utwente.nl/gump/avalon-sandbox/avalon-cache.html RSS: http://lsd.student.utwente.nl/gump/avalon-sandbox/avalon-cache.rss Atom: http://lsd.student.utwente.nl/gump/avalon-sandbox/avalon-cache.atom

[GUMP@lsd]: avalon-sandbox/avalon-cache failed

Project: avalon-cache State: Failed URL: http://lsd.student.utwente.nl/gump/avalon-sandbox/avalon-cache.html RSS: http://lsd.student.utwente.nl/gump/avalon-sandbox/avalon-cache.rss Atom: http://lsd.student.utwente.nl/gump/avalon-sandbox/avalon-cache.atom

cvs commit: avalon-excalibur/instrument-manager/src/java/org/apache/excalibur/instrument/manager/altrmi InstrumentManagerAltrmiConnector.java

leif2004/01/29 22:05:53 Modified: instrument-manager/src/java/org/apache/excalibur/instrument/manager/altrmi InstrumentManagerAltrmiConnector.java Log: Change the AltRMI warning message so it is obvious it is a notice. The previous warning log level is

Wiki Problems...

I and Leo has tried to restore the Wiki after my sad mistake of assuming too much about a computer. I am NOT confident that everything is exactly back to as it was, but I think it is pretty close. I therefor now declare the Wiki open for business as usual. http://wiki.apache.org/avalon/Front

Re: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Leo: There is an existing VETO against this change. http://marc.theaimsgroup.com/?l=avalon-dev&m=107480523229097&w=2 Could you please rollback the changes and then put something together in sandbox. Please note that I am not opposed to the interface itself - but I have serious concerns about

[release managers] Rsync with Apache's Maven repository

Release Managers, rsync is now active between apache and www.ibiblio.org/maven every 4 hours. minotaur.apache.org:/www/www.apache.org/dist/java-repository contents are now rsynced directly to www.ibibilio/maven. by ibibilio. This means anything you place into java-repository will be available

[Gump@dotnot.org]: avalon/avalon-framework failed

-Dgump.merge=/home/gump/jakarta-gump/work/merge.xml -Dbuild.sysclasspath=only -Dproject.version=20040129 dist CWD: /var/gump/avalon/framework - [echo] project.name = avalon-framework-impl [echo] project.version = 20040129

[Gump@dotnot.org]: avalon/avalon-framework failed

-Dgump.merge=/home/gump/jakarta-gump/work/merge.xml -Dbuild.sysclasspath=only -Dproject.version=20040129 dist CWD: /var/gump/avalon/framework - [echo] project.name = avalon-framework-impl [echo] project.version = 20040129

Re: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

Niclas Hedhman wrote: proper due process. bleh. Let's not let ourself get hampered by "proper due process" unless its got something to do with "due diligence", legalities, or anything like that. Let's focus on getting work done. -- cheers, - Leo Simons -

Re: [VOTE] RE: MutableConfiguration

On Thursday 29 January 2004 13:37, Alex Karasulu wrote: > Leo, > > Ok this is getting too complex for me. I figured a MutableConfiguration is > one that can change regardless of who is doing the changing. We have to > presume anything can be inducing the change. Any time a configuration > change

Re: cvs commit: avalon/framework/api/src/java/org/apache/avalon/f ramework/configuration MutableConfiguration.java

On Thursday 29 January 2004 13:55, Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote: > -Mensagem original- > De: Niclas Hedhman [mailto:[EMAIL PROTECTED] > > > WTF is going on now > Attention to ours manners :-) Typo error. Should been WitF = "What in the Framework" 8-) Chee

RE: RE: [VOTE] RE: MutableConfiguration

Leo, Ok this is getting too complex for me. I figured a MutableConfiguration is one that can change regardless of who is doing the changing. We have to presume anything can be inducing the change. Any time a configuration changes the component responds to those changes whether or not it itself

Re: Re: [VOTE] RE: MutableConfiguration

Oh yeah I forgot this one! Good catch. Basically we'll apply a blanket statement that applies to any change induced by anything other than the Configurable itself by any means. > > From: "Hamilton Verissimo de Oliveira (Engenharia - SPO)" ><[EMAIL PROTECTED]> > Date: 2004/01/29 Thu PM 0

RE: RE: [VOTE] RE: MutableConfiguration

> From: Alex Karasulu [mailto:[EMAIL PROTECTED] > > > 4. The only actor changing the configuration is the component. > -1 I realized this was what caused us to miss each other's points when I read your previous email. (See my other email for reply.) /LS

Re: [VOTE] RE: MutableConfiguration

-Mensagem original- De: Alex Karasulu [mailto:[EMAIL PROTECTED] > The container can change the configuration as well. Again if the > component is Reconfigurable the container may allow alterations to > the components configuration by outside forces like users on a > JMX UI for the applic

Re: cvs commit: avalon/framework/api/src/java/org/apache/avalon/f ramework/configuration MutableConfiguration.java

-Mensagem original- De: Niclas Hedhman [mailto:[EMAIL PROTECTED] > WTF is going on now > > Something went from a VOTE into [Too Early] and has now went into the > Framework API Easy, Niclas. You're not *the framework keeper*. I think it was faster than normal - or expected - bu

RE: RE: [VOTE] RE: MutableConfiguration

Alex, then we are talking about a third interface. See: Configuration: A configuration that *you* can't change, and that *doesn't* change. MutableConfiguration: A configuration that *you* can change. (And that changes, because of that.) What you wa

RE: RE: [VOTE] RE: MutableConfiguration

Leo, > From: "Leo Sutic" <[EMAIL PROTECTED]> > We agree on this: > > 1. The MutableConfiguration interface is passed from container to > component. +1 > 2. The component accesses the MutableConfiguration interface, and > doesn't know what the real impl class is. +1 > 3. The container

Re: [VOTE] RE: MutableConfiguration

On Thursday 29 January 2004 05:49, Leo Sutic wrote: > I propose to: > > 1. add the following MutableConfiguration interface to framework > (see below). > > 2. Add the getMutableChild and getMutableChildren methods to > the DefaultConfiguration class. > > 3. Have DefaultConfiguration impl

RE: RE: [VOTE] RE: MutableConfiguration

Leo, > > From: "Leo Sutic" <[EMAIL PROTECTED]> > > From: Hamilton Verissimo de Oliveira (Engenharia - SPO) > > De: Leo Sutic [mailto:[EMAIL PROTECTED] > > > > > I think it should be in the implementation. I don't think > > the client > > > doing the writing to the MutableConfiguration need to

RE: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

> From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > > On Thursday 29 January 2004 08:27, [EMAIL PROTECTED] wrote: > > leosutic2004/01/29 08:27:39 > > > > Added: > > framework/api/src/java/org/apache/avalon/framework/configuration > > MutableConfiguration.java > > Log: > > Added a

Re: cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

On Thursday 29 January 2004 08:27, [EMAIL PROTECTED] wrote: > leosutic2004/01/29 08:27:39 > > Added: > framework/api/src/java/org/apache/avalon/framework/configuration > MutableConfiguration.java > Log: > Added a MutableConfiguration interface. WTF is going on now Something we

RE: RE: [VOTE] RE: MutableConfiguration

> From: Hamilton Verissimo de Oliveira (Engenharia - SPO) > [mailto:[EMAIL PROTECTED] > > There is not to stop the "client" from holding the > Configuration instance in a member field and change it as > he/she wishes. The container can make a MutableConfiguration read-only, or intercept any

[Gump@dotnot.org]: avalon/avalon failed

/gump/xml-xerces2/java/build/xercesImpl.jar:/var/gump/xml-xerces2/java/build/xmlParserAPIs.jar org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/home/gump/jakarta-gump/work/merge.xml -Dbuild.sysclasspath=only -Dproject.version=20040129 dist CWD: /var/gump/avalon/framework

[Gump@dotnot.org]: avalon/avalon failed

/gump/xml-xerces2/java/build/xercesImpl.jar:/var/gump/xml-xerces2/java/build/xmlParserAPIs.jar org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/home/gump/jakarta-gump/work/merge.xml -Dbuild.sysclasspath=only -Dproject.version=20040129 dist CWD: /var/gump/avalon/framework

RES: RE: [VOTE] RE: MutableConfiguration

There is not to stop the "client" from holding the Configuration instance in a member field and change it as he/she wishes. Sorry, but seems that your seeing only your use case. regards, hammett -Mensagem original- De: Leo Sutic [mailto:[EMAIL PROTECTED] Enviada em: quinta-feira, 29 de

RE: RE: [VOTE] RE: MutableConfiguration

> From: Hamilton Verissimo de Oliveira (Engenharia - SPO) > > -Mensagem original- > De: Leo Sutic [mailto:[EMAIL PROTECTED] > > > I think it should be in the implementation. I don't think > the client > > doing the writing to the MutableConfiguration need to know > if it has > > ch

RES: RE: [VOTE] RE: MutableConfiguration

-Mensagem original- De: Leo Sutic [mailto:[EMAIL PROTECTED] > I think it should be in the implementation. I don't think the > client doing the writing to the MutableConfiguration need to know > if it has changed or not. > > The container knows the impl class, and can see if something >

RE: RE: [VOTE] RE: MutableConfiguration

> From: Alex Karasulu [mailto:[EMAIL PROTECTED] > > Leo, > > > The default implementation, although often (almost always) > built from > > an XML file, has *no* link to the XML file that created it. > Thus, in > > the default impl, changes are never stored. > > The don't you need some sor

RE: RE: [VOTE] RE: MutableConfiguration

Leo, > The default implementation, although often (almost always) > built from an XML file, has *no* link to the XML file that > created it. Thus, in the default impl, changes are never > stored. The don't you need some sort of marker to indicate the config has changed since it has been created.

RE: RE: [VOTE] RE: MutableConfiguration

+1 from me, Leo Simons and Alex: I've implemented the proposal. If there are any late -1's coming in, just let me know and I'll roll back changes. /LS > From: Leo Sutic [mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EM

cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

leosutic2004/01/29 08:29:27 Modified:framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java Log: Added a @since tag to the interface. Revision ChangesPath 1.2 +2 -1 avalon/framework/api/src/java/org/a

cvs commit: avalon/framework/impl/src/test/org/apache/avalon/framework/configuration/test DefaultConfigurationTestCase.java

leosutic2004/01/29 08:28:21 Modified:framework/impl/src/test/org/apache/avalon/framework/configuration/test DefaultConfigurationTestCase.java Log: Added unit tests for the MutableConfiguration interface of the DefaultConfiguration class. Revision Chang

cvs commit: avalon/framework/impl/src/java/org/apache/avalon/framework/configuration DefaultConfiguration.java

leosutic2004/01/29 08:27:13 Modified:framework/impl/src/java/org/apache/avalon/framework/configuration DefaultConfiguration.java Log: Implemented the MutableConfiguration interface. Revision ChangesPath 1.40 +176 -60 avalon/framework/impl/s

cvs commit: avalon/framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java

leosutic2004/01/29 08:27:39 Added: framework/api/src/java/org/apache/avalon/framework/configuration MutableConfiguration.java Log: Added a MutableConfiguration interface. Revision ChangesPath 1.1 avalon/framework/api/src/java/or

RE: RE: [VOTE] RE: MutableConfiguration

> From: Alex Karasulu [mailto:[EMAIL PROTECTED] > > Could you though answer the question with regard to the > defualt implementation? The default implementation, although often (almost always) built from an XML file, has *no* link to the XML file that created it. Thus, in the default impl, cha

Re: RE: [VOTE] RE: MutableConfiguration

Leo, Right I kinda knew that. But I guess I was referring to the DefaultConfiguration sorry for the confusion. I'm fine with the interface addition btw and have wanted this feature for some time. +1 for the additions you propose. Could you though answer the question with regard to the defualt

DO NOT REPLY [Bug 26521] - Logger.isXXXEnabled() always returns TRUE using Log4J with the ECM

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://nagoya.apache.org/bugzilla/show_bu

RE: [VOTE] RE: MutableConfiguration

Alex, there are no store semantics associated with the interface. An implementation may store on a per-mutator basis, on a batch update basis or not at all. Just as the Configuration interface doesn't imply any kind of persisten storage backing it, the MutableConfiguration interface doesn't eith

Re: [VOTE] RE: MutableConfiguration

Leo, What are the store semantics to these operations? Does each mutator persist the change to the backing store: in this case the XML configuration file? Or are the changes cached for a batch update? Alex - To unsubscribe, e

[VOTE] RE: MutableConfiguration

I propose to: 1. add the following MutableConfiguration interface to framework (see below). 2. Add the getMutableChild and getMutableChildren methods to the DefaultConfiguration class. 3. Have DefaultConfiguration implement the MutableConfiguration interface. +1 from me. package

DO NOT REPLY [Bug 26521] - Logger.isXXXEnabled() always returns TRUE using Log4J with the ECM

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://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 26521] New: - Logger.isXXXEnabled() always returns TRUE using Log4J with the ECM

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://nagoya.apache.org/bugzilla/show_bu

Re: MutableConfiguration

Leo Sutic wrote: Or are we good to go for a vote? +1 (on procedure and issue at hand :D) -- cheers, - Leo Simons - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RT] Component Types

== now what? == Leo Sutic wrote: >>now what? > > I thought I'd leave that up to you... > > OK, now that we know what to build, let's start thinking about how > to get there. The concepts are getting too big to fit into memory (or an e-mail) fast. We need some working code :D. I won't have much mo

RE: MutableConfiguration

All, any further comments on the MutableConfiguration issue? Or are we good to go for a vote? /LS > From: Alex Karasulu [mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: