Re: [configuration] ConfigurationFactory namespaces
I don't use ConfigurationFactory but it's definitely useful as a central place to configure an application. I think we could even push the concept a bit further, after all, the configuration descriptor read by ConfigurationFactory *is* a configuration, it's even a file based configuration that should be automatically reloaded when the file is changed. So, what about the following ideas: - remove the namespace handling - make ConfigurationFactory implement FileConfiguration (it already has the set/getBasePath() and setGetFileName() methods, load() is easy to implement with the current code and there is no need to implement save() since it's read only) - add a composite element to load another composite configuration descriptor - not sure about this one, but ConfigurationFactory and CompositeConfiguration could maybe be merged... Emmanuel Bourg Eric Pugh wrote: Simplicity I think is always a good idea.. I don't use it.. I will say, I am not too keen on the ConfiguraitonFactory anyway... I think I made a hash of things when first writing it... Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 3:52 PM To: Jakarta Commons Developers List Subject: [configuration] ConfigurationFactory namespaces While reviewing ConfigurationFactory I stumbled on the namespace logic, may I ask who is actually using it ? It looks like an unnecessary complexity to me, imho it's easier to have several configuration descriptors rather than a single namespaced descriptor. What do you think ? Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
cvs commit: jakarta-commons/daemon/src/native/unix INSTALL.txt
jfclere 2004/10/21 01:27:24 Modified:daemon/src/native/unix INSTALL.txt Log: Add some explainations for the ones using gcj. Revision ChangesPath 1.5 +6 -1 jakarta-commons/daemon/src/native/unix/INSTALL.txt Index: INSTALL.txt === RCS file: /home/cvs/jakarta-commons/daemon/src/native/unix/INSTALL.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- INSTALL.txt 21 Jan 2004 15:57:25 - 1.4 +++ INSTALL.txt 21 Oct 2004 08:27:24 - 1.5 @@ -5,7 +5,7 @@ GNU AutoConf A Java Platform 2 compliant SDK -First of all you need to build the configure program with: +When building from CVS sources you need to build the configure program with: sh support/buildconf.sh (Note it is possible to replace sh by any compatible shell like bash, ksh). @@ -20,6 +20,11 @@ JAVA_HOME=/usr/java export JAVA_HOME + ./configure + +or (when using gcj (use fastjar for jar)) + JAVAC=gcj; export JAVAC + JAVACFLAGS=-c; export JAVACFLAGS ./configure If your operating system is supported, configure will go thru cleanly, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cache
We're using it relatively successfully in ActiveMath. I can put you in contact with the knowledgeable person, if wished. I think there was discussions of a release about two months ago paul Le 21 oct. 04, à 06:45, matthew.hawthorne a écrit : John Lucky wrote: Have any of you used Cache from Commons Sendbox? The API documentation built from JavaDocs is not very helpful. I'd love to get some guidance how to use the Cache propertly. I've never used it, but from what I've seen on the list, it isn't very actively used or developed. You may want to consider using something like ehcache instead: http://ehcache.sourceforge.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [feedparser] Getting Brad Neuberg CVS commit
I know it feels like a chicken and an egg sort of problem... One of the historical aspects of commons is that half the code came from other projects, and half started from scratch. At least for the code that came from other projects meant that they already had committers involved, facilitating access. And those started from scratch where started by people involved in Commons already. I always recommend that someone pick up one or two projects to be involved with. That way, as traction is lost on one, progress can be made on the other, and you don't get too siloed... I am sure that with a periond of involvement the demonstrates his abilities and that he gets the Apache Way that he will gain access. We just all need to get to know him! Eric -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 2:26 AM To: Jakarta Commons Developers List Subject: Re: [feedparser] Getting Brad Neuberg CVS commit On Wed, 20 Oct 2004 17:14:33 -0700, Kevin A. Burton [EMAIL PROTECTED] wrote: Brad is working full time on feedparser and you're essentially telling him he can't get CVS access until its 1.0. How are we supposed to GET it to 1.0 it he can't get CVS access? That's certainly not clear from the email history. For example, you could help this cause a lot if you mentioned (in your CVS commit messages) which one were applied because Brad did them instead of you. Nobody can tell that he did *any* of the work. Do you see the problem here? I think the issue is that right now for the jakarta sandbox if you give Brad access then you're giving him access to a number of other projects. He doesn't want access to other projects he just wants access to FeedParser. The deeper issue is that you seem to expect Apache to work like SourceForge, which it doesn't. Committer access is earned (based on demonstrated contributions), not requested -- and it's voted on by other committers (in this particular case, those who commit to Jakarta Commons projects), not granted to non-current-committers simply because of asking. The fact that jakarta-commons-sandbox is all under the control of a single set of karma is an unfortunate fact of our current CVS implementation, but it makes absolutely no difference to the case. Any prospective Commons committer who couldn't be trusted to play by the rules shouldn't be a committer on *any* Apache project. On the other hand, granting sandbox-wide or commons-wide (which happens when sandbox projects get promoted) karma is a key tool in increasing the community of active developers on individual packages, because it reduces the barrier to jump in and help. Kevin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] ConfigurationFactory namespaces
Re: [configuration] ConfigurationFactory namespacesI agree with everything excelpt the last one, merging the two.. CompositeConfiguration is a very simple holder for configurations. You can easily use it programatically for example. However, ConfigurationFactory brings a lot more with it.. Including with what you propose the ability to reload itself.. Something to think about is that if ConfigurationFactory is going to start reloading itself, then maybe we need to think about how we are going to bolt in out event handling stuff. On a related note, now that Vector has been removed, and you have tossed in a bunch of small features and stuff that had been sitting around. Should we think about a 1.1 release? I know, it seems soon, but... Release early/release often... Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 8:45 AM To: Jakarta Commons Developers List Subject: Re: [configuration] ConfigurationFactory namespaces I don't use ConfigurationFactory but it's definitely useful as a central place to configure an application. I think we could even push the concept a bit further, after all, the configuration descriptor read by ConfigurationFactory *is* a configuration, it's even a file based configuration that should be automatically reloaded when the file is changed. So, what about the following ideas: - remove the namespace handling - make ConfigurationFactory implement FileConfiguration (it already has the set/getBasePath() and setGetFileName() methods, load() is easy to implement with the current code and there is no need to implement save() since it's read only) - add a composite element to load another composite configuration descriptor - not sure about this one, but ConfigurationFactory and CompositeConfiguration could maybe be merged... Emmanuel Bourg Eric Pugh wrote: Simplicity I think is always a good idea.. I don't use it.. I will say, I am not too keen on the ConfiguraitonFactory anyway... I think I made a hash of things when first writing it... Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 3:52 PM To: Jakarta Commons Developers List Subject: [configuration] ConfigurationFactory namespaces While reviewing ConfigurationFactory I stumbled on the namespace logic, may I ask who is actually using it ? It looks like an unnecessary complexity to me, imho it's easier to have several configuration descriptors rather than a single namespaced descriptor. What do you think ? Emmanuel Bourg
Re: [configuration] ConfigurationFactory namespaces
Eric Pugh wrote: Re: [configuration] ConfigurationFactory namespacesI agree with everything excelpt the last one, merging the two.. CompositeConfiguration is a very simple holder for configurations. You can easily use it programatically for example. Even if CompositeConfiguration had a persistence mechanism we could still use it programatically independently of any configuration file. I'm not convinced this is a good idea yet, I just wanted to throw it there and discuss it. However, ConfigurationFactory brings a lot more with it.. Including with what you propose the ability to reload itself.. Something to think about is that if ConfigurationFactory is going to start reloading itself, then maybe we need to think about how we are going to bolt in out event handling stuff. I haven't really started studying the event handling yet. What are the needs ? Notify about properties added, changed or removed ? Notify about configurations reloaded ? Should we trigger a single event with a list of all the properties modified, or an event per property changed ? The design choices of the [event] component in the sandbox might help us in implementing this feature. On a related note, now that Vector has been removed, and you have tossed in a bunch of small features and stuff that had been sitting around. Should we think about a 1.1 release? I know, it seems soon, but... Release early/release often... Hmmm once I land INIConfiguration why not. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31824] New: - [sql] Add name property to ForeignKey
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=31824. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31824 [sql] Add name property to ForeignKey Summary: [sql] Add name property to ForeignKey Product: Commons Version: 1.0 Alpha Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Provided patch add support for name property of ForeignKey attribute. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31824] - [sql] Add name property to ForeignKey
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=31824. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31824 [sql] Add name property to ForeignKey --- Additional Comments From [EMAIL PROTECTED] 2004-10-21 10:16 --- Created an attachment (id=13166) Add name property to ForeignKey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Concerns with ConfigurationRuntimeException
Hi All, I recently noticed the addition of the ConfigurationException ConfigurationRuntimeException exception classes. The API now throws a mixture of both of these. As I mentioned earlier, I'm still concerned with throwing a RuntimeException in the API. Currently, ConfigurationRuntimeException are used to signal that an unrecoverable error has occured in the underlying data access layer (i.e. it wraps an SQLException when an error occurs in the database layer, or an FileException in the file i/o layer, etc). I would argue that we should instead use the nestable ConfigurationException to nest exceptions thrown when reading/writing to the underlying data access API. All methods that potentially access data should declare that they throw a ConfigurationException (which is nearly all the method declartions in the Configuration interface). Runtime exceptions can be catastrophic especially for applications that aren't expecting them (and, since they aren't declared in the class interface or the javadoc, there is no reason for people to expect them). They can cause whole applications to crash when they could otherwise have handled or ignored the exception, or simply exited gracefully. I can understand why people would want to throw runtime exceptions instead of regular exceptions during application initialisation when the config API is normally used. After all, if you are missing important configuration information you probably want to report this error, However, there are also many cases where I can imagine you would want to ignore configuration exceptions, for example, when reading configuration information that is not mandatory to execute an application. Someone else mentioned that one of the reasons that the configuration interface does not declare any exceptions is that it would make code too messy catching exceptions. However, I do not agree that this is a sufficient reason to not declare thrown exceptions, for the following reasons: http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html Kind regards, -- Ricardo Gladwell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
About MavenTagLibrary
Hi I don't succeed to find in CVS MavenTagLibrary.java corresponding to org.apache.maven.jelly.tags.maven.MavenTagLibrary What's happen to this class ? Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Concerns with ConfigurationRuntimeException
Hi Ricardo, Ricardo Gladwell wrote: Hi All, I recently noticed the addition of the ConfigurationException ConfigurationRuntimeException exception classes. The API now throws a mixture of both of these. As I mentioned earlier, I'm still concerned with throwing a RuntimeException in the API. Currently ConfigurationException is only thrown when loading and saving a configuration. Runtime exceptions are throw in: - XMLConfiguration() when the XML APIs are missing (ConfigurationRuntimeException). This case is quite rare but I don't mind using a checked exception here, the other constructors throw a ConfigurationException. - PropertiesConfiguration.unescapeJava(String) when a malformed unicode value is found (ConfigurationRuntimeException). This should not throw an exception, I would drop the character from the string and log a warning. However this happens only on loading the configuration, this may be assimilated to a parsing exception when loading an XMLConfiguration. - JNDIConfiguration.getKeys() when a NamingException occurs (ConfigurationRuntimeException). Let's make it consistent with DatabaseConfiguration and just log the error. - In Configuration/DataConfiguration getters when the property is incompatible with the requested type (ConversionException). This is documented. - For unsupported write operations in read only configurations like JNDIConfiguration and the o.a.c.c.web configurations (UnsupportedOperationException). This is documented too. Should we just log an error ? - For missing properties (NoSuchElementException) if throwExceptionOnMissing is set. It's unavoidable for the primitive getters if no default value is provided. Let me know if I missed an exception. Currently, ConfigurationRuntimeException are used to signal that an unrecoverable error has occured in the underlying data access layer (i.e. it wraps an SQLException when an error occurs in the database layer, or an FileException in the file i/o layer, etc). I would argue that we should instead use the nestable ConfigurationException to nest exceptions thrown when reading/writing to the underlying data access API. All methods that potentially access data should declare that they throw a ConfigurationException (which is nearly all the method declartions in the Configuration interface). I'm not fond of this. It only affects the configurations using an unreliable communication channel to access the properties, that's JNDIConfiguration and DatabaseConfiguration, the most widely used configurations are file based and not affected by this issue, why annoying their users ? Also this may prevent us from making Configurations implement the Map interface, I still want to try this. Runtime exceptions can be catastrophic especially for applications that aren't expecting them (and, since they aren't declared in the class interface or the javadoc, there is no reason for people to expect them). They can cause whole applications to crash when they could otherwise have handled or ignored the exception, or simply exited gracefully. I agree I can understand why people would want to throw runtime exceptions instead of regular exceptions during application initialisation when the config API is normally used. After all, if you are missing important configuration information you probably want to report this error, However, there are also many cases where I can imagine you would want to ignore configuration exceptions, for example, when reading configuration information that is not mandatory to execute an application. If a property is not mandatory a default value should always be specified, this eliminates the NoSuchElementException from the problem. Now what should we do when a ConversionException occurs ? If a default value is provided, we may want to return it instead of throwing the exception, this could be configured with a throwExceptionOnIncompatibleProperty flag, or using a special decorator (NoExceptionConfiguration ?) Someone else mentioned that one of the reasons that the configuration interface does not declare any exceptions is that it would make code too messy catching exceptions. However, I do not agree that this is a sufficient reason to not declare thrown exceptions, for the following reasons: http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html I don't want to declare a ConfigurationException on every method of the Configuration interface, logging data access errors is fine imho, but there are some unexpected and undocumented runtime exceptions that should be removed (the most important is in JNDIConfiguration.getKeys()). The case of ConversionException should also be examined. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About MavenTagLibrary
This has certainly moved in the maven source-tree. For example, what about the following: http://maven.apache.org/xref/org/apache/maven/jelly/tags/jeez/ MavenJeezTagLibrary.html Jeez has not much tags of its own, I think... it's combining Werkz (also outside) and ant taglibs. paul Le 21 oct. 04, à 14:04, A Leg a écrit : I don't succeed to find in CVS MavenTagLibrary.java corresponding to org.apache.maven.jelly.tags.maven.MavenTagLibrary What's happen to this class ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About MavenTagLibrary
Hi Paul Yes but it is in package org.apache.maven.jelly.tags.jeez and MavenJellyContext.java import org.apache.maven.jelly.tags.maven.MavenTagLibrary; So I don't understand how it can work. Suppose some old jar is somewhere. But after ? Andre Paul Libbrecht wrote: This has certainly moved in the maven source-tree. For example, what about the following: http://maven.apache.org/xref/org/apache/maven/jelly/tags/jeez/ MavenJeezTagLibrary.html Jeez has not much tags of its own, I think... it's combining Werkz (also outside) and ant taglibs. paul Le 21 oct. 04, à 14:04, A Leg a écrit : I don't succeed to find in CVS MavenTagLibrary.java corresponding to org.apache.maven.jelly.tags.maven.MavenTagLibrary What's happen to this class ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Concerns with ConfigurationRuntimeException
Emmanuel Bourg wrote: Let me know if I missed an exception. AFAIK, all actions throw the runtime exception ConversionException. I'm not fond of this. It only affects the configurations using an unreliable communication channel to access the properties, that's JNDIConfiguration and DatabaseConfiguration, the most widely used configurations are file based and not affected by this issue, why annoying their users ? Also this may prevent us from making Configurations implement the Map interface, I still want to try this. I would argue that all communcation channels have the potential to be unreliable especially when you consider the IO API can be extended to read/write data from variety of source types. We cannot exclude the possiblity of, for example, reading configuration information over (unreliable) network connections. I don't this is an argument against reporting exceptions in the underlying layer. Otherwise, would the various IOException and SQLException also be runtime exceptions? I think, rather than force users to exit their programs on a configuration error we should give them the option of either exiting gracefully themselves or handling configuration exceptions unless we can guanrantee that no exceptions will be thrown be by the code under all circumstances (i.e. if disk is full, if hard disk is corrupted, etc) in which case *we* have to handle the exception and recover from it. There are many reasons for doing this, more importantly, so that users can handle and recover from configuration read/write exceptions themselves. Another option would be to create an exception reporting mechanism within the Configuration interface. Perhaps a method call getExceptionsThrown() that returns a list of exceptions thrown during the last few operations. Of course, this does mean that we are re-creating the exception throwing mechanism implemented within Java itself. I don't want to declare a ConfigurationException on every method of the Configuration interface, logging data access errors is fine imho, but there are some unexpected and undocumented runtime exceptions that should be removed (the most important is in JNDIConfiguration.getKeys()). The case of ConversionException should also be examined. It depends on why you are opposed to adding ConfigurationException to all methods declartions in Configuration. If it's because it would clutter the code with various try/catch blocks for users then I would argue that this should not be an issue: reporting and handling exceptions is a hassle but there is a very specific reason we have them. I think the users would object more to the fact that Kind regards, -- Ricardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31828] New: - Size Threshold in Commons Upload not Working
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=31828. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31828 Size Threshold in Commons Upload not Working Summary: Size Threshold in Commons Upload not Working Product: Commons Version: Nightly Builds Platform: PC OS/Version: Windows XP Status: NEW Severity: Critical Priority: Other Component: File Upload AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I upload a file size of 0 even though the size threshold is set at 4096, commons upload still uploads the file. FileUploadBase parseRequest(HttpServletRequest) appears not to interface the the threshold setting. Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Concerns with ConfigurationRuntimeException
Ricardo Gladwell wrote: Emmanuel Bourg wrote: Let me know if I missed an exception. AFAIK, all actions throw the runtime exception ConversionException. The typed getters only. getProperty, getKeys, isEmpty, addProperty, setProperty, clear, clearProperty, subset, containsKey do not throw ConversionException. I would argue that all communcation channels have the potential to be unreliable especially when you consider the IO API can be extended to read/write data from variety of source types. We cannot exclude the possiblity of, for example, reading configuration information over (unreliable) network connections. I don't this is an argument against reporting exceptions in the underlying layer. Otherwise, would the various IOException and SQLException also be runtime exceptions? PropertyConfiguration reads from a Map, I think we can assume it reliably read it ;) Logging the errors isn't enough ? I think, rather than force users to exit their programs on a configuration error we should give them the option of either exiting gracefully themselves or handling configuration exceptions unless we can guanrantee that no exceptions will be thrown be by the code under all circumstances (i.e. if disk is full, if hard disk is corrupted, etc) in which case *we* have to handle the exception and recover from it. There are many reasons for doing this, more importantly, so that users can handle and recover from configuration read/write exceptions themselves. What about the flag I suggested to hide ConversionExceptions and return the default value if available ? Another option would be to create an exception reporting mechanism within the Configuration interface. Perhaps a method call getExceptionsThrown() that returns a list of exceptions thrown during the last few operations. Of course, this does mean that we are re-creating the exception throwing mechanism implemented within Java itself. I'm not sure this provides the right reporting mechanism, because the application will have to poll this method frequently to check if an exception occured. I would prefer a notification mechanism with an event listener. It depends on why you are opposed to adding ConfigurationException to all methods declartions in Configuration. If it's because it would clutter the code with various try/catch blocks for users then I would argue that this should not be an issue: reporting and handling exceptions is a hassle but there is a very specific reason we have them. I think the users would object more to the fact that That's the issue to me. Also if we add a checked exception on isEmpty or containsKey, the Configuration interface can no longer extend the Map interface, I don't want to block this potential evolution. I believe we can find a compromise preserving the ease of use and providing a rigorous error reporting. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Concerns with ConfigurationRuntimeException
I think both arguments are valid. It depends on your use case. One of the
obstacles with an interface like Configuration is that you don't know who is
going to implement it. And some are reliable, and some are not. For the
same reasons that the Map,Set,List interface don't throw checked exceptions,
so Configuration doesn't throw. Especially since I think that the most
common use would be:
try {
conf.getString(hi);
}
catch (ConfigurationException ce){
throw new RuntimeException(ce)
}
and so on.. It most apps the graceful shutdown aspects are never
implemented. ON a webapp I often just bubble the error up and say try
again.. However, there are apps, like a public facing app, where you
can't do that.
Could we have two interfaces? Configuration and StrictConfiguration?
StrictConfiguration would declare checked methods?
Eric
-Original Message-
From: Ricardo Gladwell [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 21, 2004 2:11 PM
To: Jakarta Commons Developers List
Subject: Re: [configuration] Concerns with ConfigurationRuntimeException
Emmanuel Bourg wrote:
Let me know if I missed an exception.
AFAIK, all actions throw the runtime exception ConversionException.
I'm not fond of this. It only affects the configurations using an
unreliable communication channel to access the properties, that's
JNDIConfiguration and DatabaseConfiguration, the most widely used
configurations are file based and not affected by this issue, why
annoying their users ? Also this may prevent us from making
Configurations implement the Map interface, I still want to try this.
I would argue that all communcation channels have the potential to be
unreliable especially when you consider the IO API can be extended to
read/write data from variety of source types. We cannot exclude the
possiblity of, for example, reading configuration information over
(unreliable) network connections. I don't this is an argument against
reporting exceptions in the underlying layer. Otherwise, would the
various IOException and SQLException also be runtime exceptions?
I think, rather than force users to exit their programs on a
configuration error we should give them the option of either exiting
gracefully themselves or handling configuration exceptions unless we can
guanrantee that no exceptions will be thrown be by the code under all
circumstances (i.e. if disk is full, if hard disk is corrupted, etc) in
which case *we* have to handle the exception and recover from it. There
are many reasons for doing this, more importantly, so that users can
handle and recover from configuration read/write exceptions themselves.
Another option would be to create an exception reporting mechanism
within the Configuration interface. Perhaps a method call
getExceptionsThrown() that returns a list of exceptions thrown during
the last few operations. Of course, this does mean that we are
re-creating the exception throwing mechanism implemented within
Java itself.
I don't want to declare a ConfigurationException on every method of the
Configuration interface, logging data access errors is fine imho, but
there are some unexpected and undocumented runtime exceptions that
should be removed (the most important is in
JNDIConfiguration.getKeys()). The case of ConversionException should
also be examined.
It depends on why you are opposed to adding ConfigurationException to
all methods declartions in Configuration. If it's because it would
clutter the code with various try/catch blocks for users then I would
argue that this should not be an issue: reporting and handling
exceptions is a hassle but there is a very specific reason we have them.
I think the users would object more to the fact that
Kind regards,
-- Ricardo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[chain] Configuration idea
I had an idea about how we could improve the default configuration of commons-chain. It would be nice if we could have the following catalog.xml: catalog chains chain name=foobar.chain command name=foo className=Foo/ command name=bar className=Bar/ /chain chain name=biz.chain chain name=foobar.chain command name=biz className=Biz/ /chain /chains /catalog The idea is that once a chain has been created through the Digester it is available for subsequent chains that need to be created. Thus you could reference an existing chain (as is done in the biz.chain). This way you could reuse chains as you see fit. This could come in handy eventually in the struts-chain project. You could group several related commands together and then offer different chain combinations to the user depending on what they need. Any thoughts on that? sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Dumbster problems
Has anyone managed to get maven and dumbster to work together? I currently have a project which the unit test run fine (using eclipse and ant) but when i run the same tests using maven it cannot find the fake smpt server started by dumbster. Anyone have any ideas? Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Concerns with ConfigurationRuntimeException
Hi fellows, Eric Pugh wrote on Thursday, October 21, 2004 4:30 PM: I think both arguments are valid. It depends on your use case. [snip] Could we have two interfaces? Configuration and StrictConfiguration? StrictConfiguration would declare checked methods? What about a monitor concept? Logging itself is useless, the application cannot react. Throwing checked exceptions is annoying for the memory or file based configurations (i.e. nothing can really fail after the file is read). Registering a listener for a Configuration, that supports error events may solve these problems. Probably a logging listener should be provided by default. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [feedparser] Getting Brad Neuberg CVS commit
Hi folks. Thanks for all the feedback. One thing is I've been hired by Kevin at his startup company, Rojo, and one of my main full-time responsibilities is to help maintain and improve the Jakarta Feed Parser. I'll continue posting all of my patches here. One of the issues is that the quantity and size of my patches is increasing, such as one I am going to land this morning; it is getting difficult for Kevin to hand apply all of the patches since he is quite busy with getting other parts of Rojo going. This was starting to affect my work since I was waiting for him to apply some patches before moving on to the next ones, but it was taking him awhile to do so because of his work load. I understand, though, that the Apache Jakarta community has its own process that I must respect. At 01:54 AM 10/21/2004, you wrote: I know it feels like a chicken and an egg sort of problem... One of the historical aspects of commons is that half the code came from other projects, and half started from scratch. At least for the code that came from other projects meant that they already had committers involved, facilitating access. And those started from scratch where started by people involved in Commons already. I always recommend that someone pick up one or two projects to be involved with. That way, as traction is lost on one, progress can be made on the other, and you don't get too siloed... I am sure that with a periond of involvement the demonstrates his abilities and that he gets the Apache Way that he will gain access. We just all need to get to know him! Eric -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 2:26 AM To: Jakarta Commons Developers List Subject: Re: [feedparser] Getting Brad Neuberg CVS commit On Wed, 20 Oct 2004 17:14:33 -0700, Kevin A. Burton [EMAIL PROTECTED] wrote: Brad is working full time on feedparser and you're essentially telling him he can't get CVS access until its 1.0. How are we supposed to GET it to 1.0 it he can't get CVS access? That's certainly not clear from the email history. For example, you could help this cause a lot if you mentioned (in your CVS commit messages) which one were applied because Brad did them instead of you. Nobody can tell that he did *any* of the work. Do you see the problem here? I think the issue is that right now for the jakarta sandbox if you give Brad access then you're giving him access to a number of other projects. He doesn't want access to other projects he just wants access to FeedParser. The deeper issue is that you seem to expect Apache to work like SourceForge, which it doesn't. Committer access is earned (based on demonstrated contributions), not requested -- and it's voted on by other committers (in this particular case, those who commit to Jakarta Commons projects), not granted to non-current-committers simply because of asking. The fact that jakarta-commons-sandbox is all under the control of a single set of karma is an unfortunate fact of our current CVS implementation, but it makes absolutely no difference to the case. Any prospective Commons committer who couldn't be trusted to play by the rules shouldn't be a committer on *any* Apache project. On the other hand, granting sandbox-wide or commons-wide (which happens when sandbox projects get promoted) karma is a key tool in increasing the community of active developers on individual packages, because it reduces the barrier to jump in and help. Kevin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Brad Neuberg, [EMAIL PROTECTED] Senior Software Engineer, Rojo Networks Weblog: http://www.codinginparadise.org = Check out Rojo, an RSS and Atom news aggregator that I work on. Visit http://rojo.com for more info. Feel free to ask me for an invite! Rojo is Hiring! If you're interested in RSS, Weblogs, Social Networking, Java, Open Source, etc... then come work with us at Rojo. If you recommend someone and we hire them you'll get a free iPod! See http://www.rojonetworks.com/JobsAtRojo.html. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
At 06:25 PM 10/20/2004, you wrote: On Wed, 20 Oct 2004 17:14:33 -0700, Kevin A. Burton [EMAIL PROTECTED] wrote: Brad is working full time on feedparser and you're essentially telling him he can't get CVS access until its 1.0. How are we supposed to GET it to 1.0 it he can't get CVS access? That's certainly not clear from the email history. For example, you could help this cause a lot if you mentioned (in your CVS commit messages) which one were applied because Brad did them instead of you. Nobody can tell that he did *any* of the work. I've submitted alot of patches to Kevin for the Feed Parser (through this list), but when he did the CVS commits he did not make it clear that I had developed the code. I've asked him to make this clearer on CVS commits in the future. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[feedparser] Patch to Improve Build System
The following is a patch for the feed parser's build system. It does the
following:
* Changes build.xml to use a build.properties file for the following two
properties:
* feedparser.home - The location of the feed parser installation;
defaults to .. Needed so that we can update our unit tests to run
cross-platform (they used to only run on Kevins Linux box :)
* ext.lib.path - The location of external JARs needed by the feed
parser but which are not included, such as junit.jar. The location to these
used to be hard coded in the build.xml file, which is nasty and doesn't
work cross-platform.
* Added help to the build.xml file - essentially this is an ant task,
'help', that provides information on the available tasks and how to
configure your system to get the feed parser to work.
* Added ant-contrib.jar to the lib directory and wire it in. Ant-contrib is
a nice collection of advanced ant tags, such as an if tag, that can help to
make more maintainable ant files. It is opensource.
* Cleaned up the unit testing targets. Right now we have several testing
targets that aren't rationalized. I've created a single task, test, that
by default runs every available task. This task allows an optional
argument, test.only.local, that will only test the local tasks and not
the remote ones so that they run faster (Kevin asked for this).
To make this patch work you will also need to add ant-contrib-0.6.jar to
the lib directory, since I can't attach JARs to emails for this list:
http://p2psockets.jxta.org/source/browse/p2psockets/lib/ant-contrib-0.6.jar?rev=1.1http://p2psockets.jxta.org/source/browse/p2psockets/lib/ant-contrib-0.6.jar?rev=1.1
Here is the patch:
Index build.xml
===
RCS file /home/cvspublic/jakarta-commons-sandbox/feedparser/build.xml,v
retrieving revision 1.9
diff -u -B -r1.9 build.xml
--- build.xml 18 Oct 2004 001223 -1.9
+++ build.xml 21 Oct 2004 011158 -
@@ -1,6 +1,10 @@
?xml version=1.0 encoding=ISO-8859-1?
-project name=feedparser default=jakarta-feedparser.jar basedir=.
+project name=feedparser default=help basedir=.
+
+property environment=env/
+
+property file=build.properties/
property name=project value=feedparser/
@@ -28,36 +32,76 @@
/fileset
-!--
-fileset dir=c/usr/local/ksa/lib
+fileset dir=${ext.lib.path}
include name=*.jar/
/fileset
- --
+
+fileset dir=${ant.home}/lib
+include name=*.jar/
+/fileset
/path
+!-- ant-contrib tasks path http//ant-contrib.sourceforge.net;
+ this includes custom tags, such as an 'if' tag --
+property name=ant-contrib.jar value=./lib/ant-contrib-0.6.jar/
+taskdef resource=net/sf/antcontrib/antcontrib.properties
+classpath
+pathelement location=${ant-contrib.jar}/
+/classpath
+/taskdef
+
+taskdef name=junit
+
classname=org.apache.tools.ant.taskdefs.optional.junit.JUnitTask/
+
target name=compile
mkdir dir=compile/
-javac srcdir=src/java/
+javac srcdir=src/java/
classpathref=project.classpath
- destdir=compile
+ destdir=compile
debug=true/
/target
+target name=clean
+delete dir=compile/
+/target
+
+target name=clobber
+delete dir=compile/
+/target
+
+target name=jakarta-feedparser.jar depends=compile
+
+mkdir dir=lib/
+
+jar compress=yes jarfile=lib/jakarta-feedparser.jar
+
+fileset dir=compile
+
+include name=org/**/
+include name=feedparser/**/
+include name=*.class/
+
+/fileset
+
+/jar
+
+/target
+
target name=run-example description=Runs the example feed parser
class
depends=jakarta-feedparser.jar
java classpathref=project.classpath
classname=org.apache.commons.feedparser.example.HelloFeedParser
fork=true
failonerror=true
- /java
+ /java
/target
-
+
target name=debug-feed description=Debugs a feed
depends=jakarta-feedparser.jar
java classpathref=project.classpath
@@ -65,77 +109,50 @@
fork=true
failonerror=true
arg value=${feed-url}/
- /java
+ /java
/target
-
+
target name=test-autodiscover description=Runs the testing class
for autodiscovery
depends=jakarta-feedparser.jar
java classpathref=project.classpath
- classname=org.apache.commons.feedparser.locate.FeedLocator
+ classname=org.apache.commons.feedparser.locate.TestFeedLocator
fork=true
failonerror=true
- /java
+sysproperty key=feedparser.home value=${feedparser.home}/
+ /java
/target
-
- target name=test-probing description=Runs
[feedparser] Patch to Improve Unit Tests
The following patch improves the feed parser's unit tests. It does the
following:
* Gets the tests to run cross-platform
* Modifies the tests to use the new BlogService system, which I will post
as a patch after this email.
The patch:
The following patch updates the unit tests
Index src/java/org/apache/commons/feedparser/test/TestFeedFilter.java
===
RCS file
/home/cvspublic/jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/test/TestFeedFilter.java,v
retrieving revision 1.4
diff -u -B -r1.4 TestFeedFilter.java
--- src/java/org/apache/commons/feedparser/test/TestFeedFilter.java 14
Sep 2004 013204 -1.4
+++ src/java/org/apache/commons/feedparser/test/TestFeedFilter.java 21
Oct 2004 011306 -
@@ -1,12 +1,12 @@
/*
* Copyright 1999,2004 The Apache Software Foundation.
- *
+ *
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
- *
+ *
* http//www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -44,12 +44,19 @@
* @version $Id TestFeedFilter.java,v 1.4 2004/09/14 013204 burton Exp $
*/
public class TestFeedFilter extends TestCase {
-
-public static int current = 0;
+protected String feedparserHome;
+public static int current = 0;
+
public TestFeedFilter( String name ) throws Exception {
super( name );
-
+
+feedparserHome = System.getProperty(feedparser.home, .);
+// these come in as forward slashes, even on Windows, because of Ant,
+// so it is safe to check them as / rather than File.separator
+// Brad Neuberg
+if (feedparserHome.endsWith(/) == false)
+feedparserHome = feedparserHome + /;
}
private void doTest( String resource ) throws Exception {
@@ -59,14 +66,14 @@
URL url = new URL( resource );
FileOutputStream fos = new FileOutputStream(
/tmp/test-feed-filter- + current + .html );
-
+
PrintStream out = new PrintStream( fos, true, UTF-8 );
out.println( META HTTP-EQUIV=\Content-Type\
CONTENT=\text/html; charset=UTF-8\ );
out.println( pre );
DebugFeedParserListener listener = new DebugFeedParserListener(
out );
-
+
FeedParser.parse( listener, url.openStream(), resource );
out.println( /pre );
@@ -74,36 +81,37 @@
++current;
}
-
+
public void test1() throws Exception {
+String path = file + feedparserHome;
-doTest( filetests/feeds/rss-1.0-EUC-JP.rdf );
+doTest( path + tests/feeds/rss-1.0-EUC-JP.rdf );
-doTest( filetests/filter/nbsp-1.xml );
+doTest( path + tests/filter/nbsp-1.xml );
-doTest( filetests/filter/entity-atom-1.xml );
+doTest( path + tests/filter/entity-atom-1.xml );
-doTest( filetests/filter/prolog-atom-1.xml );
-doTest( filetests/filter/prolog-atom-2.xml );
-doTest( filetests/filter/prolog-opml-1.xml );
+doTest( path + tests/filter/prolog-atom-1.xml );
+doTest( path + tests/filter/prolog-atom-2.xml );
+doTest( path + tests/filter/prolog-opml-1.xml );
-doTest( filetests/filter/lisa.opml );
+doTest( path + tests/filter/lisa.opml );
-doTest( filetests/feeds/utf16.rss1 );
-doTest( filetests/feeds/utf16.rss2 );
-doTest( filetests/feeds/i18n.atom );
-doTest( filetests/feeds/utf16.atom );
+doTest( path + tests/feeds/utf16.rss1 );
+doTest( path + tests/feeds/utf16.rss2 );
+doTest( path + tests/feeds/i18n.atom );
+doTest( path + tests/feeds/utf16.atom );
-doTest( filetests/feeds/atom-1.xml );
-doTest( filetests/feeds/rss-1.0-EUC-JP.rdf );
-doTest( filetests/feeds/rss-1.0-international-1.rdf );
+doTest( path + tests/feeds/atom-1.xml );
+doTest( path + tests/feeds/rss-1.0-EUC-JP.rdf );
+doTest( path + tests/feeds/rss-1.0-international-1.rdf );
}
public static void main( String[] args ) throws Exception {
TestFeedFilter test = new TestFeedFilter( null );
-
+
//test.testGetWeblogLinkForResource();
test.test1();
Index src/java/org/apache/commons/feedparser/test/TestFeedLocator.java
===
RCS file
/home/cvspublic/jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/test/TestFeedLocator.java,v
retrieving revision 1.5
diff -u -B -r1.5 TestFeedLocator.java
--- src/java/org/apache/commons/feedparser/test/TestFeedLocator.java31
Aug 2004 210032 -1.5
+++
[feedparser] Patch to Feed Parser 'Locate' System
The following patch updates the org.apache.commons.feedparser.locate system
to use the new BlogService refactoring described earlier. It mostly
consists of patches to BlogServiceDiscovery and ProbeLocator.
The following patch updates the org.apache.commons.feedparser.locate
package to correctly use the new 'blogservice' subpackage
Index src/java/org/apache/commons/feedparser/locate/BlogServiceDiscovery.java
===
RCS file
/home/cvspublic/jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate/BlogServiceDiscovery.java,v
retrieving revision 1.4
diff -u -B -r1.4 BlogServiceDiscovery.java
---
src/java/org/apache/commons/feedparser/locate/BlogServiceDiscovery.java
30 Sep 2004 192738 -1.4
+++
src/java/org/apache/commons/feedparser/locate/BlogServiceDiscovery.java
21 Oct 2004 011457 -
@@ -16,310 +16,34 @@
package org.apache.commons.feedparser.locate;
-import java.util.regex.*;
+import org.apache.commons.feedparser.*;
+import org.apache.commons.feedparser.locate.blogservice.*;
/**
- *
* Determines what blog provider a given URI is using,
* such as whether it is hosted on Blogspot, Radio Userland, etc.
*
* @author a href=[EMAIL PROTECTED]Brad Neuberg/a
*/
public class BlogServiceDiscovery {
-/** Locates all the generator meta tags
- * (i.e. meta content=generator content=someGenerator/)
- */
-private static Pattern metaTagsPattern =
-Pattern.compile([\\s]*meta[\\w\\s=\']*name=['\
]generator[\' ][\\w\\s=\']*[^]*,
-Pattern.CASE_INSENSITIVE | Pattern.MULTILINE);
-
-/** A pattern used to discover PMachine blogs. */
-private static Pattern pmachinePattern =
-Pattern.compile(pmachine, Pattern.CASE_INSENSITIVE);
-/** A pattern used to discover Blosxom blogs. */
-private static Pattern blosxomPattern =
-Pattern.compile(alt=[\' ]powered by blosxom[\' ],
-Pattern.CASE_INSENSITIVE);
-
-/** Uses the given resource and content to determine what blog provider
- * a given URI is using.
- */
-public static BlogService discover( String resource, String content ) {
-return discoverService( resource, content );
-}
-
-/** Uses the given resource to determine what blog provider
- * a given URI is using; useful if you have no content but still want
- * to do a best guess of what blog service is being used.
- */
-public static BlogService discover( String resource ) {
-return discoverService( resource, null );
+public static BlogService discover( String resource )
+throws FeedParserException {
+return discover(resource, null);
}
-// NOTE ALL of this code should change to a visitor pattern. Bad design.
-
-protected static BlogService discoverService( String resource,
- String content ) {
+public static BlogService discover( String resource,
+String content )
+throws FeedParserException {
resource = resource.toLowerCase();
-
-// check the weblogs in order of their popularity
-if (isBlogger(resource, content)) {
-return BlogService.BLOGGER;
-}
-else if (isLiveJournal(resource, content)) {
-return BlogService.LIVEJOURNAL;
-}
-else if (isDiaryLand(resource, content)) {
-return BlogService.DIARYLAND;
-}
-else if (isMovableType(resource, content)) {
-return BlogService.MOVABLE_TYPE;
-}
-else if (isXanga(resource, content)) {
-return BlogService.XANGA;
-}
-else if (isWordPress(resource, content)) {
-return BlogService.WORDPRESS;
-}
-else if (isAOLJournals(resource, content)) {
-return BlogService.AOL_JOURNAL;
-}
-else if (isTypePad(resource, content)) {
-return BlogService.TYPEPAD;
-}
-else if (isPMachine(resource, content)) {
-return BlogService.PMACHINE;
-}
-/* FIXME No way to detect Expression Engine weblogs right now
-else if (isExpressionEngine(resource, content)) {
-return BlogService.EXPRESSION_ENGINE;
-}*/
-else if (isGreyMatter(resource, content)) {
-return BlogService.GREYMATTER;
-}
-/* FIXME We can't detect iBlog sites
-else if (isIBlog(resource, content)) {
-return BlogService.IBLOG;
-}*/
-else if (isBlosxom(resource, content)) {
-return BlogService.BLOSXOM;
-}
-/* FIXME We can't detect Manila sites.
-else if (isManila(resource, content)) {
-return BlogService.MANILA;
-}*/
-
[feedparser] What I'm Working on Today
Howdy. I've mapped out today (Thursday) to hack on the feed parser here at work, and just wanted to tell folks whats on my plate, rather than just keep it as conversations between Kevin and I. Here is what I would like to achieve today: * Roll in unit tests for Flickr and Yahoo Groups into TestProbeLocator * Make Flickr support more robust (they support several different kinds of feeds, such as for tags, groups, etc., some which support autodiscovery correctly and some which don't) * Some of the unit tests won't run on Windows due to some file path expansion issues; I am going to try to fix these * The autodiscovery code is a bit flaky, breaking when the attributes are in the wrong order. I want to fix this and improve the unit tests to be test more variations. There might also be some issues with Feedster and Topix support that I will take a look at today and tommorrow. Brad Neuberg, [EMAIL PROTECTED] Senior Software Engineer, Rojo Networks Weblog: http://www.codinginparadise.org = Check out Rojo, an RSS and Atom news aggregator that I work on. Visit http://rojo.com for more info. Feel free to ask me for an invite! Rojo is Hiring! If you're interested in RSS, Weblogs, Social Networking, Java, Open Source, etc... then come work with us at Rojo. If you recommend someone and we hire them you'll get a free iPod! See http://www.rojonetworks.com/JobsAtRojo.html. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons-id Using ClassLoader.getSystemResourceAsStream()
Hi all, I'm having a little trouble with the fact that commons-id's ReadOnlyResourceStateImpl uses ClassLoader.getSystemResourceAsStream to load the config file containing MAC addresses. Is that intentional? When I'm testing my app with Maven, the only thing in the system class loader's path is Maven's forehead jar. Perhaps I can/should change that, but it causes my test to fail because my config file isn't found. If I use this.getClass().getResourceAsStream(), things are fine. I can understand why the system class loader is used, however, for that particular file-- because it's based on where the app is deployed and therefore is not portable, like the rest of the app is. If you think it should change to use the app's class loader, I'll submit a patch. If you think it should stay the way it is, I might consider refactoring the load() method to use inversion of control so I can better test with mock objects and not worry about environmental concerns. If I do that I'll submit a patch. thanks john
Re: [chain] Configuration idea
It's possible to delegate to a previously defined chain (or command) already, if you do two things: * (Optional) you don't need chains any more ... that was there in the original examples solely to satisfy XML's requirement for a single root element. * Use the existing lookup command to delegate execution to the foobar chain: command catalog=... name=foobar.chain className=org.apache.commons.chain.generic.LookupCommand/ which causes foobar.chain to be looked up and executed. Looking at this, though, we'll probably want to clean up some of the existing command definitions that currently assume a catalog is present in the context ... thanks to CatalogFactory that is no longer necessary, so we can change that to optionally specify a catalog name (with a default to the standard one). In struts-chain there's an example of this sort of thing in the 'servlet-complete' chain. Craig On Thu, 21 Oct 2004 10:31:24 -0400, Sean Schofield [EMAIL PROTECTED] wrote: I had an idea about how we could improve the default configuration of commons-chain. It would be nice if we could have the following catalog.xml: catalog chains chain name=foobar.chain command name=foo className=Foo/ command name=bar className=Bar/ /chain chain name=biz.chain chain name=foobar.chain command name=biz className=Biz/ /chain /chains /catalog The idea is that once a chain has been created through the Digester it is available for subsequent chains that need to be created. Thus you could reference an existing chain (as is done in the biz.chain). This way you could reuse chains as you see fit. This could come in handy eventually in the struts-chain project. You could group several related commands together and then offer different chain combinations to the user depending on what they need. Any thoughts on that? sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31831] New: - Otiose Code in ParameterParser
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=31831.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31831
Otiose Code in ParameterParser
Summary: Otiose Code in ParameterParser
Product: Commons
Version: Nightly Builds
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: File Upload
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The line paramValue = null is, I think, otiose in ParameterParser and
constitutes an operation that really does nothing except take up CPU space,
unless the VM catches it, which I doubt, and ignores it. Not sure if people
want to look at code this closely, but, if you do, then the code is:
public Map parse(final char[] chars,
int offset,
int length,
char separator) {
if (chars == null) {
return new HashMap();
}
HashMap params = new HashMap();
this.chars = chars;
this.pos = offset;
this.len = length;
String paramName = null;
String paramValue = null;
while (hasChar()) {
paramName = parseToken(new char[] { '=', separator });
paramValue = null;
if (hasChar() (chars[pos] == '=')) {
pos++; // skip '='
paramValue = parseQuotedToken(new char[] { separator });
}
if (hasChar() (chars[pos] == separator)) {
pos++; // skip separator
}
if ((paramName != null) (paramName.length() 0)) {
if (this.lowerCaseNames) {
paramName = paramName.toLowerCase();
}
params.put(paramName, paramValue);
}
}
return params;
}
Michael McGrady
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] Configuration idea
At 10:31 AM -0400 10/21/04, Sean Schofield wrote: I had an idea about how we could improve the default configuration of commons-chain. It would be nice if we could have the following catalog.xml: catalog chains chain name=foobar.chain command name=foo className=Foo/ command name=bar className=Bar/ /chain chain name=biz.chain chain name=foobar.chain command name=biz className=Biz/ /chain /chains /catalog I think it's basically a good idea, although I'd want a different attribute for references; reusing name with the same element and different semantics would be pretty confusing. How about ref? chain name=biz.chain chain ref=foobar.chain command name=biz className=Biz/ /chain Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
DO NOT REPLY [Bug 31831] - Otiose Code in ParameterParser
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=31831. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31831 Otiose Code in ParameterParser --- Additional Comments From [EMAIL PROTECTED] 2004-10-21 17:46 --- I think this was a mistake. My apologies. Please nuke this bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration/src/java/org/apache/commons/configuration DatabaseConfiguration.java
ebourg 2004/10/21 11:02:09
Modified:configuration/xdocs changes.xml
configuration/src/java/org/apache/commons/configuration
DatabaseConfiguration.java
Log:
DatabaseConfiguration.isEmpty() now returns true if an SQLException occurs.
This is consistent with JNDIConfiguration.isEmpty() and the empty iterator returned
by getKeys() in this case.
Revision ChangesPath
1.67 +3 -0 jakarta-commons/configuration/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/jakarta-commons/configuration/xdocs/changes.xml,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -r1.66 -r1.67
--- changes.xml 19 Oct 2004 13:41:44 - 1.66
+++ changes.xml 21 Oct 2004 18:02:09 - 1.67
@@ -8,6 +8,9 @@
body
release version=1.1-dev date=in CVS
+ action dev=ebourg type=fix
+DatabaseConfiguration.isEmpty() now returns true if an SQLException occurs.
+ /action
action dev=ebourg type=add
Added two methods copy(Configuration, Configuration) and
append(Configuration, Configuration) in ConfigurationUtils to copy
1.12 +2 -2
jakarta-commons/configuration/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
Index: DatabaseConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/DatabaseConfiguration.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- DatabaseConfiguration.java18 Oct 2004 14:05:23 - 1.11
+++ DatabaseConfiguration.java21 Oct 2004 18:02:09 - 1.12
@@ -208,7 +208,7 @@
*/
public boolean isEmpty()
{
-boolean empty = false;
+boolean empty = true;
// build the query
StringBuffer query = new StringBuffer(SELECT count(*) FROM + table);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] JNDIConfiguration.getProperties not supported ?
I just noticed that getProperties() is overridden in JNDIConfiguration to throw an UnsupportedOperationException. What's wrong with this method ? The implementation inherited from AbstractConfiguration doesn't work here ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] Configuration idea
At 10:27 AM -0500 10/21/04, Joe Germuska wrote: At 10:31 AM -0400 10/21/04, Sean Schofield wrote: I had an idea about how we could improve the default configuration of commons-chain. It would be nice if we could have the following catalog.xml: catalog chains chain name=foobar.chain command name=foo className=Foo/ command name=bar className=Bar/ /chain chain name=biz.chain chain name=foobar.chain command name=biz className=Biz/ /chain /chains /catalog I think it's basically a good idea, although I'd want a different attribute for references; reusing name with the same element and different semantics would be pretty confusing. How about ref? chain name=biz.chain chain ref=foobar.chain command name=biz className=Biz/ /chain Craig has since responded on this issue pointing out that it can be done. However, I have had in the back of my head a bit of a nagging concern that the XML syntax for commons-chain is verbose, if not confusing. Then again, I haven't set out to make a new chain myself yet, so I don't have a good feel about just how serious the issue is. So, Craig -- would you object to something like the above, which is more concise, even though there is another way to do it? How about anyone else who has been interested in Chain? Is it too early to optimize the config syntax? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
cvs commit: jakarta-commons/configuration/src/java/org/apache/commons/configuration JNDIConfiguration.java
ebourg 2004/10/21 11:36:14
Modified:configuration/xdocs changes.xml
configuration/src/java/org/apache/commons/configuration
JNDIConfiguration.java
Log:
JNDIConfiguration.getKeys() now returns an empty iterator instead of throwing a
ConfigurationRuntimeException when a NamingException occurs.
The NamingExceptions are now all logged.
Added a more explicit javadoc on the methods throwing an
UnsupportedOperationException.
Revision ChangesPath
1.68 +5 -0 jakarta-commons/configuration/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/jakarta-commons/configuration/xdocs/changes.xml,v
retrieving revision 1.67
retrieving revision 1.68
diff -u -r1.67 -r1.68
--- changes.xml 21 Oct 2004 18:02:09 - 1.67
+++ changes.xml 21 Oct 2004 18:36:14 - 1.68
@@ -9,6 +9,11 @@
release version=1.1-dev date=in CVS
action dev=ebourg type=fix
+JNDIConfiguration.getKeys() now returns an empty iterator instead of
+throwing a ConfigurationRuntimeException when a NamingException occurs.
+The NamingExceptions are now logged.
+ /action
+ action dev=ebourg type=fix
DatabaseConfiguration.isEmpty() now returns true if an SQLException occurs.
/action
action dev=ebourg type=add
1.20 +22 -23
jakarta-commons/configuration/src/java/org/apache/commons/configuration/JNDIConfiguration.java
Index: JNDIConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/JNDIConfiguration.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- JNDIConfiguration.java4 Oct 2004 20:06:09 - 1.19
+++ JNDIConfiguration.java21 Oct 2004 18:36:14 - 1.20
@@ -26,10 +26,8 @@
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NameClassPair;
-import javax.naming.NameNotFoundException;
import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
-import javax.naming.NotContextException;
import org.apache.commons.lang.StringUtils;
import org.apache.commons.logging.Log;
@@ -110,10 +108,10 @@
}
/**
- * JNDIConfigurations can not be added to.
+ * pstrongThis operation is not supported and will throw an
+ * UnsupportedOperationException./strong/p
*
- * @param key The Key to add the property to.
- * @param token The Value to add.
+ * @throws UnsupportedOperationException
*/
public void addProperty(String key, Object token)
{
@@ -221,7 +219,8 @@
}
catch (NamingException e)
{
-throw new ConfigurationRuntimeException(e.getMessage(), e);
+log.error(e.getMessage(), e);
+return new ArrayList().iterator();
}
}
@@ -278,9 +277,10 @@
}
/**
- * [EMAIL PROTECTED]
+ * pstrongThis operation is not supported and will throw an
+ * UnsupportedOperationException./strong/p
*
- * bThis operation is not supported/b
+ * @throws UnsupportedOperationException
*/
public Properties getProperties(String key)
{
@@ -310,9 +310,9 @@
}
}
}
-catch (NamingException ne)
+catch (NamingException e)
{
-log.warn(ne);
+log.error(e.getMessage(), e);
return true;
}
}
@@ -326,7 +326,10 @@
}
/**
- * [EMAIL PROTECTED]
+ * pstrongThis operation is not supported and will throw an
+ * UnsupportedOperationException./strong/p
+ *
+ * @throws UnsupportedOperationException
*/
public void setProperty(String key, Object value)
{
@@ -357,8 +360,9 @@
getBaseContext().lookup(key);
return true;
}
-catch (NamingException ne)
+catch (NamingException e)
{
+log.error(e.getMessage(), e);
return false;
}
}
@@ -399,23 +403,18 @@
key = StringUtils.replace(key, ., /);
return getBaseContext().lookup(key);
}
-catch (NameNotFoundException e)
-{
-return null;
-}
-catch (NotContextException e)
-{
-return null;
-}
catch (NamingException e)
{
-e.printStackTrace();
+log.error(e.getMessage(), e);
return null;
}
}
/**
- * [EMAIL PROTECTED]
+ * pstrongThis
DO NOT REPLY [Bug 31831] - Otiose Code in ParameterParser
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=31831. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31831 Otiose Code in ParameterParser [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] Configuration idea
See intermixed. On Thu, 21 Oct 2004 13:00:20 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 10:27 AM -0500 10/21/04, Joe Germuska wrote: At 10:31 AM -0400 10/21/04, Sean Schofield wrote: I had an idea about how we could improve the default configuration of commons-chain. It would be nice if we could have the following catalog.xml: catalog chains chain name=foobar.chain command name=foo className=Foo/ command name=bar className=Bar/ /chain chain name=biz.chain chain name=foobar.chain command name=biz className=Biz/ /chain /chains /catalog I think it's basically a good idea, although I'd want a different attribute for references; reusing name with the same element and different semantics would be pretty confusing. How about ref? chain name=biz.chain chain ref=foobar.chain command name=biz className=Biz/ /chain Craig has since responded on this issue pointing out that it can be done. However, I have had in the back of my head a bit of a nagging concern that the XML syntax for commons-chain is verbose, if not confusing. Then again, I haven't set out to make a new chain myself yet, so I don't have a good feel about just how serious the issue is. One nitpick ... a ref thing like this probably ought to be on command because you don't necessarily know whether what you are referring to is actually a chain or just a singleton command. So, Craig -- would you object to something like the above, which is more concise, even though there is another way to do it? How about anyone else who has been interested in Chain? Is it too early to optimize the config syntax? There has been some interest, but not a lot of commentary on the configuration syntax so far. One thing that is in place (but not well documented) is the define capability, which essentially lets you create aliases for command elements that you might use over and over again. It's used in the unit test cases (src/test/org/apache/commons/chain/config/*.xml) but goes like this. Let's assume you're going to use this lookup mechanism a lot. So, you can create a shortcut for it like this: define name=lookup className=org.apache.commons.chain.generic.LookupCommand/ and then, in your actual chain definitions, you can say: lookup name=foobar.chain/ Essentially, the implementation creates new Digester rules on the fly. Does that help? Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31828] - Size Threshold in Commons Upload not Working
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=31828. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31828 Size Threshold in Commons Upload not Working [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-21 18:42 --- The threshold has nothing to do with whether or not something gets uploaded. FileUpload has no control over that, since the browser determines what to send. The threshold is used to determine whether the content of the item, once uploaded, should be retained in memory or written to disk. That is, if your threshold is 4096 bytes, then anything smaller than that will be retained in memory, and anything larger will be written to disk. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration/src/java/org/apache/commons/configuration/web AppletConfiguration.java ServletConfiguration.java ServletContextConfiguration.java ServletFilterConfiguration.java ServletRequestConfiguration.java
ebourg 2004/10/21 11:42:09
Modified:configuration/src/java/org/apache/commons/configuration/web
AppletConfiguration.java ServletConfiguration.java
ServletContextConfiguration.java
ServletFilterConfiguration.java
ServletRequestConfiguration.java
Log:
explicit javadoc for unsupported methods
Revision ChangesPath
1.3 +13 -1
jakarta-commons/configuration/src/java/org/apache/commons/configuration/web/AppletConfiguration.java
Index: AppletConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/web/AppletConfiguration.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AppletConfiguration.java 14 Oct 2004 15:54:06 - 1.2
+++ AppletConfiguration.java 21 Oct 2004 18:42:09 - 1.3
@@ -51,6 +51,12 @@
return applet.getParameter(key);
}
+/**
+ * pstrongThis operation is not supported and will throw an
+ * UnsupportedOperationException./strong/p
+ *
+ * @throws UnsupportedOperationException
+ */
protected void addPropertyDirect(String key, Object obj)
{
throw new UnsupportedOperationException(Read only configuration);
@@ -66,6 +72,12 @@
return getPropertyDirect(key) != null;
}
+/**
+ * pstrongThis operation is not supported and will throw an
+ * UnsupportedOperationException./strong/p
+ *
+ * @throws UnsupportedOperationException
+ */
public void clearProperty(String key)
{
throw new UnsupportedOperationException(Read only configuration);
1.3 +13 -1
jakarta-commons/configuration/src/java/org/apache/commons/configuration/web/ServletConfiguration.java
Index: ServletConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/web/ServletConfiguration.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ServletConfiguration.java 14 Oct 2004 15:54:06 - 1.2
+++ ServletConfiguration.java 21 Oct 2004 18:42:09 - 1.3
@@ -62,6 +62,12 @@
return config.getInitParameter(key);
}
+/**
+ * pstrongThis operation is not supported and will throw an
+ * UnsupportedOperationException./strong/p
+ *
+ * @throws UnsupportedOperationException
+ */
protected void addPropertyDirect(String key, Object obj)
{
throw new UnsupportedOperationException(Read only configuration);
@@ -77,6 +83,12 @@
return getPropertyDirect(key) != null;
}
+/**
+ * pstrongThis operation is not supported and will throw an
+ * UnsupportedOperationException./strong/p
+ *
+ * @throws UnsupportedOperationException
+ */
public void clearProperty(String key)
{
throw new UnsupportedOperationException(Read only configuration);
1.3 +13 -1
jakarta-commons/configuration/src/java/org/apache/commons/configuration/web/ServletContextConfiguration.java
Index: ServletContextConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/web/ServletContextConfiguration.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ServletContextConfiguration.java 14 Oct 2004 15:54:06 - 1.2
+++ ServletContextConfiguration.java 21 Oct 2004 18:42:09 - 1.3
@@ -63,6 +63,12 @@
return context.getInitParameter(key);
}
+/**
+ * pstrongThis operation is not supported and will throw an
+ * UnsupportedOperationException./strong/p
+ *
+ * @throws UnsupportedOperationException
+ */
protected void addPropertyDirect(String key, Object obj)
{
throw new UnsupportedOperationException(Read only configuration);
@@ -78,6 +84,12 @@
return getPropertyDirect(key) != null;
}
+/**
+ * pstrongThis operation is not supported and will throw an
+ * UnsupportedOperationException./strong/p
+ *
+ * @throws UnsupportedOperationException
+ */
public void clearProperty(String key)
{
throw new UnsupportedOperationException(Read only configuration);
1.3 +13 -1
jakarta-commons/configuration/src/java/org/apache/commons/configuration/web/ServletFilterConfiguration.java
Index: ServletFilterConfiguration.java
===
RCS file:
[dbutils] Anyone working on this project?
I made a MapMapHandler and wanted someone to look at it to see if it is worth submitting. = Norris Shelton Software Engineer Sun Certified Java 1.1 Programmer Appriss, Inc. ICQ# 26487421 AIM NorrisEShelton YIM norrisshelton ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
Craig McClanahan wrote: On Wed, 20 Oct 2004 17:14:33 -0700, Kevin A. Burton [EMAIL PROTECTED] wrote: Brad is working full time on feedparser and you're essentially telling him he can't get CVS access until its 1.0. How are we supposed to GET it to 1.0 it he can't get CVS access? That's certainly not clear from the email history. For example, you could help this cause a lot if you mentioned (in your CVS commit messages) which one were applied because Brad did them instead of you. Nobody can tell that he did *any* of the work. I've documented the patches Brad has given me in everyone of my commits. Sorry if it wasn't in the email... Do you see the problem here? I think the issue is that right now for the jakarta sandbox if you give Brad access then you're giving him access to a number of other projects. He doesn't want access to other projects he just wants access to FeedParser. The deeper issue is that you seem to expect Apache to work like SourceForge, which it doesn't. Committer access is earned (based on demonstrated contributions), not requested -- and it's voted on by other committers (in this particular case, those who commit to Jakarta Commons projects), not granted to non-current-committers simply because of asking. Brad is one of the lead developers on the FeedParser. Its a NEW project and we're both working on it. FeedParser is a contribution from Rojo and we're both working on it here! Its very difficult for us to make forward progress if I can't give a lead developer CVS commit. The fact that jakarta-commons-sandbox is all under the control of a single set of karma is an unfortunate fact of our current CVS implementation, but it makes absolutely no difference to the case. When a new projects is created are you telling me that you don't give CVS commit to the lead developers? How would IBM feel if when they contributed Xerces that you wouldn't give their lead engineers access to CVS? Any prospective Commons committer who couldn't be trusted to play by the rules shouldn't be a committer on *any* Apache project. On the other hand, granting sandbox-wide or commons-wide (which happens when sandbox projects get promoted) karma is a key tool in increasing the community of active developers on individual packages, because it reduces the barrier to jump in and help. Listen... I'm sorry if we're trying to move too fast. We're a startup and on a very aggressive schedule. We're trying to get FeedParser to 1.0 ASAP because its a critical portion of Rojo. Brad is a lead developer and its becoming difficult to synchronize our work without CVS commits. We're constantly having to coordinate our commits due to CVS limitations. If we were using a more anarchic revision control system like bitkeeper or arch this wouldn't be as much of a problem. -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
Re: [dbutils] Anyone working on this project?
What does MapMapHandler do? David --- Norris Shelton [EMAIL PROTECTED] wrote: I made a MapMapHandler and wanted someone to look at it to see if it is worth submitting. = Norris Shelton Software Engineer Sun Certified Java 1.1 Programmer Appriss, Inc. ICQ# 26487421 AIM NorrisEShelton YIM norrisshelton ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] What I'm Working on Today
Brad Neuberg wrote: Howdy. I've mapped out today (Thursday) to hack on the feed parser here at work, and just wanted to tell folks whats on my plate, rather than just keep it as conversations between Kevin and I. Here is what I would like to achieve today: * Roll in unit tests for Flickr and Yahoo Groups into TestProbeLocator We really need to talk to Flickr about correctly implementing HTTP and RSS/Atom autodiscovery. They've been very bad about this ... * Make Flickr support more robust (they support several different kinds of feeds, such as for tags, groups, etc., some which support autodiscovery correctly and some which don't) I didnt' realize this when I did my first implementation thanks. * Some of the unit tests won't run on Windows due to some file path expansion issues; I am going to try to fix these Yeah... my bad ;) * The autodiscovery code is a bit flaky, breaking when the attributes are in the wrong order. I want to fix this and improve the unit tests to be test more variations. Could you come up with some unit tests for this? I think I came up with some and it passed all attribute ordering passes but you might be right. There might also be some issues with Feedster and Topix support that I will take a look at today and tommorrow. Topix is important. I asked Feedster to make their changes to their site but they seem lazy :-/ Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] Configuration idea
snip There has been some interest, but not a lot of commentary on the configuration syntax so far. One thing that is in place (but not well documented) is the define capability, which essentially lets you create aliases for command elements that you might use over and over again. It's used in the unit test cases (src/test/org/apache/commons/chain/config/*.xml) but goes like this. Let's assume you're going to use this lookup mechanism a lot. So, you can create a shortcut for it like this: define name=lookup className=org.apache.commons.chain.generic.LookupCommand/ and then, in your actual chain definitions, you can say: lookup name=foobar.chain/ Essentially, the implementation creates new Digester rules on the fly. Does that help? Craig /snip I think that's a good solution to Joe's concern. I haven't taken a close look at the test cases but I suspect there are plenty of configuration scenarios that remain untested. Maybe I will work up some a additional ones. Somewhere in the documentation we can point the user to the test cases as Craig mentions for some examples. sean PS. Craig, I liked what you did with the configuration rule sets and how they use ChainFactory. The other day when I went to modify ChainListener to add the catalog to the factory I discovered you handled it in the rule set. That was a nice touch! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] Configuration idea
At 11:37 AM -0700 10/21/04, Craig McClanahan wrote: Let's assume you're going to use this lookup mechanism a lot. So, you can create a shortcut for it like this: define name=lookup className=org.apache.commons.chain.generic.LookupCommand/ and then, in your actual chain definitions, you can say: lookup name=foobar.chain/ Essentially, the implementation creates new Digester rules on the fly. Does that help? It seems like it would -- and in any case, it's pretty cool! Like I said, I'm probably jumping the gun myself asking about syntax changes. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
Re: [feedparser] Getting Brad Neuberg CVS commit
Kevin A. Burton wrote: Listen... I'm sorry if we're trying to move too fast. We're a startup and on a very aggressive schedule. We're trying to get FeedParser to 1.0 ASAP because its a critical portion of Rojo. Brad is a lead developer and its becoming difficult to synchronize our work without CVS commits. We're constantly having to coordinate our commits due to CVS limitations. If we were using a more anarchic revision control system like bitkeeper or arch this wouldn't be as much of a problem. I apologize in advance if I'm out of line, but has anyone considered if the jakarta-commons-sandbox is truly the best place for [feedparser]? Based on recent emails, it doesn't seem to be a good fit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [feedparser] Getting Brad Neuberg CVS commit
Hi, Yeah, the sandbox is not the best place for something that's on the critical path for something else's release. One suggestion: take feedparser in-house. Finish it. Ship your product. Then submit it back, probably right into the commons proper (not sandbox), and possibly into the incubator if you want it to be a non-commons jakarta project. The discussion on where it should go will take place at the time. But for now, you'll have control and can work at your own pace. Yoav Shapira http://www.yoavshapira.com -Original Message- From: matthew.hawthorne [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 4:34 PM To: Jakarta Commons Developers List Subject: Re: [feedparser] Getting Brad Neuberg CVS commit Kevin A. Burton wrote: Listen... I'm sorry if we're trying to move too fast. We're a startup and on a very aggressive schedule. We're trying to get FeedParser to 1.0 ASAP because its a critical portion of Rojo. Brad is a lead developer and its becoming difficult to synchronize our work without CVS commits. We're constantly having to coordinate our commits due to CVS limitations. If we were using a more anarchic revision control system like bitkeeper or arch this wouldn't be as much of a problem. I apologize in advance if I'm out of line, but has anyone considered if the jakarta-commons-sandbox is truly the best place for [feedparser]? Based on recent emails, it doesn't seem to be a good fit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
On Thu, 21 Oct 2004 13:00:56 -0700, Kevin A. Burton [EMAIL PROTECTED] wrote: [snip] When a new projects is created are you telling me that you don't give CVS commit to the lead developers? How would IBM feel if when they contributed Xerces that you wouldn't give their lead engineers access to CVS? If you had gone through the incubation process (http://incubator.apache.org) the way that IBM is doing for Derby, or BEA is doing for Beehive, that is indeed what would have happened. However, I suspect there would have been pushback on a project with only two active developers, both working for the same company. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
It might be helpful to look at the Warning Signs portion of this page: http://jakarta.apache.org/site/newproject.html Several of them seem to apply to feedparser. David --- Craig McClanahan [EMAIL PROTECTED] wrote: On Thu, 21 Oct 2004 13:00:56 -0700, Kevin A. Burton [EMAIL PROTECTED] wrote: [snip] When a new projects is created are you telling me that you don't give CVS commit to the lead developers? How would IBM feel if when they contributed Xerces that you wouldn't give their lead engineers access to CVS? If you had gone through the incubation process (http://incubator.apache.org) the way that IBM is doing for Derby, or BEA is doing for Beehive, that is indeed what would have happened. However, I suspect there would have been pushback on a project with only two active developers, both working for the same company. Craig __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
matthew.hawthorne wrote: Kevin A. Burton wrote: Listen... I'm sorry if we're trying to move too fast. We're a startup and on a very aggressive schedule. We're trying to get FeedParser to 1.0 ASAP because its a critical portion of Rojo. Brad is a lead developer and its becoming difficult to synchronize our work without CVS commits. We're constantly having to coordinate our commits due to CVS limitations. If we were using a more anarchic revision control system like bitkeeper or arch this wouldn't be as much of a problem. I apologize in advance if I'm out of line, but has anyone considered if the jakarta-commons-sandbox is truly the best place for [feedparser]? Based on recent emails, it doesn't seem to be a good fit. I've had a bit of discussion about this with Sam Ruby and other people within Apache. The FeedParser was too early to go though the incubator and I just really wanted a solid place to make a lot of progress at the time. Anyway... opening this up might be a can of worms but it seems that the FeedParser would have to go through the incubator to make it into a project. Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
Shapira, Yoav wrote: Hi, Yeah, the sandbox is not the best place for something that's on the critical path for something else's release. The critical path is FeedParsers 1.0 release. We're just working very hard on it because we need it for work... One suggestion: take feedparser in-house. Finish it. Ship your product. Then submit it back, probably right into the commons proper (not sandbox), and possibly into the incubator if you want it to be a non-commons jakarta project. The discussion on where it should go will take place at the time. But for now, you'll have control and can work at your own pace. Man... this is very difficult. Back in the day it didn't have to be so hard... commons, incubator, sandbox... What I need is a Apache contrib for dummies HOWTO :) Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
Craig McClanahan wrote: On Thu, 21 Oct 2004 13:00:56 -0700, Kevin A. Burton [EMAIL PROTECTED] wrote: [snip] When a new projects is created are you telling me that you don't give CVS commit to the lead developers? How would IBM feel if when they contributed Xerces that you wouldn't give their lead engineers access to CVS? If you had gone through the incubation process (http://incubator.apache.org) the way that IBM is doing for Derby, or BEA is doing for Beehive, that is indeed what would have happened. However, I suspect there would have been pushback on a project with only two active developers, both working for the same company. Yes... which is why I wanted a place to make forward progression until we're ready to push it through the incubator. Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
Re: About MavenTagLibrary
It's in the maven-jelly-tags cvs repository, part of the Maven project. A Leg wrote: Hi Paul Yes but it is in package org.apache.maven.jelly.tags.jeez and MavenJellyContext.java import org.apache.maven.jelly.tags.maven.MavenTagLibrary; So I don't understand how it can work. Suppose some old jar is somewhere. But after ? Andre Paul Libbrecht wrote: This has certainly moved in the maven source-tree. For example, what about the following: http://maven.apache.org/xref/org/apache/maven/jelly/tags/jeez/ MavenJeezTagLibrary.html Jeez has not much tags of its own, I think... it's combining Werkz (also outside) and ant taglibs. paul Le 21 oct. 04, à 14:04, A Leg a écrit : I don't succeed to find in CVS MavenTagLibrary.java corresponding to org.apache.maven.jelly.tags.maven.MavenTagLibrary What's happen to this class ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
David Graham wrote: It might be helpful to look at the Warning Signs portion of this page: http://jakarta.apache.org/site/newproject.html Several of them seem to apply to feedparser. I realize that a few of them apply but they also apply to most early projects. Our goal was to start building a community while it was under development and as we moved towards 1.0. Its partly my fault in that I haven't had time to blog about FeedParser or attract more of a community. Theres a HUGE effort behind RSS/Atom right now and we need to do a better job at getting FeedParser out there. Right now its VERY stable and I feel a 1.0 is around the corner we're still trying to stabilize it (which is difficult since the specs keep changing). Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31838] New: - Guide (Current) link on home page is broken
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=31838. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31838 Guide (Current) link on home page is broken Summary: Guide (Current) link on home page is broken Product: Commons Version: 1.6 Final Platform: Other URL: http://jakarta.apache.org/commons/digester/index.html OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Digester AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The Guide (Current) link on the navigation pane/menu points to: http://jakarta.apache.org/commons/digester/commons-digester- 1.6/apidocs/org/apache/commons/digester/package-summary.html I think this is what we want: http://jakarta.apache.org/commons/digester/commons-digester- 1.6/docs/api/org/apache/commons/digester/package-summary.html The difference being commons-digester-1.6/apidocs vs commons-digester- 1.6/docs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31838] - [Digester] Guide (Current) link on home page is broken
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=31838. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31838 [Digester] Guide (Current) link on home page is broken [EMAIL PROTECTED] changed: What|Removed |Added Summary|Guide (Current) link on |[Digester] Guide (Current) |home page is broken |link on home page is broken - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31791] - [Resources] Provide a way to query the actual Locale used
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=31791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31791 [Resources] Provide a way to query the actual Locale used [EMAIL PROTECTED] changed: What|Removed |Added Summary|Provide a way to query the |[Resources] Provide a way to |actual Locale used |query the actual Locale used - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31816] - Certain EL statements cause an apparant infinite loop in the EL parser.
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=31816. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31816 Certain EL statements cause an apparant infinite loop in the EL parser. --- Additional Comments From [EMAIL PROTECTED] 2004-10-21 22:55 --- Created an attachment (id=13172) This JSP contains and EL expression that hangs tomcat. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [feedparser] Getting Brad Neuberg CVS commit
Several of them seem to apply to feedparser. I realize that a few of them apply but they also apply to most early projects. Our goal was to start building a community while it was under development and as we moved towards 1.0. Its partly my fault in that I haven't had time to blog about FeedParser or attract more of a community. Theres a HUGE effort behind RSS/Atom right now and we need to do a better job at getting FeedParser out there. Right now its VERY stable and I feel a 1.0 is around the corner we're still trying to stabilize it (which is difficult since the specs keep changing). I can sympathise with your difficulties. Sometimes writing the code seems like the trivial part - the community building is a *lot* of work, albeit essential. Cheers, Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration project.properties
ebourg 2004/10/21 17:59:19 Modified:configuration project.properties Log: Changed the default source target set by Maven to compile with the JDK 1.5 (Jira MPJAVA-22) Revision ChangesPath 1.18 +2 -0 jakarta-commons/configuration/project.properties Index: project.properties === RCS file: /home/cvs/jakarta-commons/configuration/project.properties,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- project.properties12 Oct 2004 00:33:06 - 1.17 +++ project.properties22 Oct 2004 00:59:19 - 1.18 @@ -30,3 +30,5 @@ maven.jar.override=on maven.jar.resources=conf/resources.jar + +maven.compile.source = 1.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration/conf testDigesterBadXML.xml testDigesterConfigurationNamespaceAware.xml testDigesterConfigurationWJNDI.xml testEqualDigester.xml testSequenceDigester.xml
ebourg 2004/10/21 18:19:52 Modified:configuration/xdocs overview.xml configuration/conf testDigesterBadXML.xml testDigesterConfigurationNamespaceAware.xml testDigesterConfigurationWJNDI.xml testEqualDigester.xml testSequenceDigester.xml Log: Removed the unused className attributes from the configuration descriptors Revision ChangesPath 1.5 +6 -6 jakarta-commons/configuration/xdocs/overview.xml Index: overview.xml === RCS file: /home/cvs/jakarta-commons/configuration/xdocs/overview.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- overview.xml 12 Jul 2004 12:14:38 - 1.4 +++ overview.xml 22 Oct 2004 01:19:52 - 1.5 @@ -65,9 +65,9 @@ ?xml version=1.0 encoding=ISO-8859-1 ? configuration - jndi className=org.apache.commons.configuration.JNDIConfiguration prefix=java:comp/env/ - properties className=org.apache.commons.configuration.PropertiesConfiguration fileName=conf/test.properties/ - xml className=org.apache.commons.configuration.XMLConfiguration fileName=conf/test.xml/ + jndi prefix=java:comp/env/ + properties fileName=conf/test.properties/ + xml fileName=conf/test.xml/ /configuration ]] /source @@ -94,7 +94,7 @@ subsection name=Classic Properties File source ![CDATA[ - properties className=org.apache.commons.configuration.PropertiesConfiguration fileName=conf/test.properties/ + properties fileName=conf/test.properties/ ]] /source p @@ -104,7 +104,7 @@ subsection name=XML Properties File source ![CDATA[ - xml className=org.apache.commons.configuration.XMLConfiguration fileName=conf/test.xml/ + xml fileName=conf/test.xml/ ]] /source p @@ -134,7 +134,7 @@ subsection name=JNDI Properties File source ![CDATA[ - jndi className=org.apache.commons.configuration.JNDIConfiguration prefix=java:comp/env/ + jndi prefix=java:comp/env/ ]] /source p 1.3 +1 -7 jakarta-commons/configuration/conf/testDigesterBadXML.xml Index: testDigesterBadXML.xml === RCS file: /home/cvs/jakarta-commons/configuration/conf/testDigesterBadXML.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- testDigesterBadXML.xml12 Jul 2004 12:14:37 - 1.2 +++ testDigesterBadXML.xml22 Oct 2004 01:19:52 - 1.3 @@ -5,12 +5,6 @@ configuration additional -xml className=org.apache.commons.configuration.HierarchicalXMLConfiguration fileName=testHierarchicalXMLConfiguration.xml/ +hierarchicalXml fileName=testHierarchicalXMLConfiguration.xml/ /configuration - - - - - - 1.3 +2 -2 jakarta-commons/configuration/conf/testDigesterConfigurationNamespaceAware.xml Index: testDigesterConfigurationNamespaceAware.xml === RCS file: /home/cvs/jakarta-commons/configuration/conf/testDigesterConfigurationNamespaceAware.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- testDigesterConfigurationNamespaceAware.xml 12 Jul 2004 12:14:37 - 1.2 +++ testDigesterConfigurationNamespaceAware.xml 22 Oct 2004 01:19:52 - 1.3 @@ -2,6 +2,6 @@ configuration xmlns:foo=namespace-one xmlns:bar=namespace-two - foo:properties className=org.apache.commons.configuration.PropertiesConfiguration fileName=conf/test.properties/ - bar:dom className=org.apache.commons.configuration.XMLConfiguration fileName=conf/test.xml/ + foo:properties fileName=conf/test.properties/ + bar:xml fileName=conf/test.xml/ /configuration 1.3 +3 -3 jakarta-commons/configuration/conf/testDigesterConfigurationWJNDI.xml Index: testDigesterConfigurationWJNDI.xml === RCS file: /home/cvs/jakarta-commons/configuration/conf/testDigesterConfigurationWJNDI.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- testDigesterConfigurationWJNDI.xml12 Jul 2004 12:14:37 - 1.2 +++ testDigesterConfigurationWJNDI.xml22 Oct 2004 01:19:52 - 1.3 @@ -1,7 +1,7 @@ ?xml version=1.0 encoding=ISO-8859-1 ? configuration - jndi className=org.apache.commons.configuration.JNDIConfiguration prefix=java:comp/env/ - properties className=org.apache.commons.configuration.PropertiesConfiguration fileName=conf/test.properties/ - dom
cvs commit: jakarta-commons/configuration/xdocs howto_compositeconfiguration.xml howto_configurationfactory.xml howto_properties.xml howto_xml.xml overview.xml
ebourg 2004/10/21 18:40:49
Modified:configuration/xdocs howto_compositeconfiguration.xml
howto_configurationfactory.xml howto_properties.xml
howto_xml.xml overview.xml
Log:
Removed the extra empty lines in the source blocks
Revision ChangesPath
1.2 +6 -14
jakarta-commons/configuration/xdocs/howto_compositeconfiguration.xml
Index: howto_compositeconfiguration.xml
===
RCS file:
/home/cvs/jakarta-commons/configuration/xdocs/howto_compositeconfiguration.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_compositeconfiguration.xml 24 Feb 2004 13:08:03 - 1.1
+++ howto_compositeconfiguration.xml 22 Oct 2004 01:40:48 - 1.2
@@ -20,15 +20,13 @@
Defaults are very simple. You can just add them as your last
configuration object,
either through the ConfigurationFactory or manually:
/p
- source
-![CDATA[
+ source![CDATA[
Configuration defaults = new PropertiesConfiguration(fileToDefaults);
Configuration otherProperties = new PropertiesConfiguration(fileToOtherProperties);
CompositeConfiguration cc = new CompositeConfiguration();
cc.addConfiguration(otherProperties);
cc.addDefaults(fileToDefaults);
-]]
- /source
+]]/source
/subsection
subsection name=Saving Changes
@@ -39,20 +37,17 @@
the constructor of the CompositeConfiguration what
Configuration
to save the changes via.
/p
- source
-![CDATA[
+ source![CDATA[
PropertiesConfiguration saveConfiguration = new
PropertiesConfiguration(fileToSaveChangesIn);
Configuration cc = new CompositeConfiguration(saveConfiguration);
cc.setProperty(newProperty,new value);
saveConfiguration.save();
-]]
- /source
+]]/source
p
Alternatively, you can just request the
inMemoryConfiguration that stores the changes:
- source
-![CDATA[
+ source![CDATA[
Configuration changes = myCompositeConfiguration.getInMemoryConfiguration();
DatabaseConfiguration config = new DatabaseConfiguration(datasource,
configuration, key, value);
for (Iterator i = changes.getKeys().iterator();i.hasNext()){
@@ -60,10 +55,7 @@
Object value = changes.get(key);
config.setProperty(key,value);
}
-
-
-]]
- /source
+]]/source
/p
/subsection
1.4 +14 -28
jakarta-commons/configuration/xdocs/howto_configurationfactory.xml
Index: howto_configurationfactory.xml
===
RCS file:
/home/cvs/jakarta-commons/configuration/xdocs/howto_configurationfactory.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- howto_configurationfactory.xml12 Jul 2004 12:14:38 - 1.3
+++ howto_configurationfactory.xml22 Oct 2004 01:40:48 - 1.4
@@ -35,15 +35,13 @@
the properties are to be collected. The following
listing shows
the content of this file:
/p
- source
-![CDATA[
+ source![CDATA[
?xml version=1.0 encoding=ISO-8859-1 ?
configuration
properties fileName=usergui.properties/
/configuration
-]]
- /source
+]]/source
p
Definition files for codeConfigurationFactory/code
are
normal XML files. The root element must be named
@@ -65,14 +63,12 @@
Just create a new instance and set the name of the
definition
file with the codesetConfigurationFileName()/code
method.
/p
- source
-![CDATA[
+ source![CDATA[
ConfigurationFactory factory = new ConfigurationFactory();
URL configURL = new File(config.xml).toURL();
factory.setConfigurationFileName(configURL.toString());
Configuration config = factory.getConfiguration();
-]]
- /source
+]]/source
p
As this code fragment shows the file name passed to
the factory
Re: [math] Questions regarding probability distributions
Do you have any references for the quantum physics cases? I certainly didn't specialize in quantum physics (plasma physics typically uses almost everything _but_ quantum physics), but I did get as far as a EE graduate course in QED and never encountered such probability models. Maybe it's because I wasn't in a physics department or ever really encountered molecular models in what I was studying? I don't have any references handy (not my area of expertise), but it's often mentioned as an application area in articles dealing with these distributions. For instance, I guess physics models that uses Brownian motion models could use these distributions as they do show up in connection with Brownian motion theory. Honestly, I doubt most of the users of Commons Math will be needing this kind of distribution, but I guess if we merge in (parts of) Colt, we might end up attracting that kind of user. As a matter of fact, many concepts in probability theory that at first sight may seem rather obscure can actually be used for practical applications. Stochastic modeling of the financial markets is a good example where very advanced mathematics is actually put to practical use. /FN - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31844] New: - [chain] CopyCommand should use new CatalogFactory
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=31844. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31844 [chain] CopyCommand should use new CatalogFactory Summary: [chain] CopyCommand should use new CatalogFactory Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: chain AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CopyCommand is using context instead of newly available CatalogFactory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31844] - [chain] CopyCommand should use new CatalogFactory
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=31844. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31844 [chain] CopyCommand should use new CatalogFactory --- Additional Comments From [EMAIL PROTECTED] 2004-10-22 03:31 --- Created an attachment (id=13180) [chain] [patch] LookupCommand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31844] - [chain] LookupCommand should use new CatalogFactory
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=31844. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31844 [chain] LookupCommand should use new CatalogFactory [EMAIL PROTECTED] changed: What|Removed |Added Summary|[chain] CopyCommand should |[chain] LookupCommand should |use new CatalogFactory |use new CatalogFactory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31844] - [chain] LookupCommand should use new CatalogFactory
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=31844. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31844 [chain] LookupCommand should use new CatalogFactory --- Additional Comments From [EMAIL PROTECTED] 2004-10-22 03:42 --- Sorry - original bug description is incorrect. Fix should be made to LookupCommand (not CopyCommand). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31844] - [chain] LookupCommand should use new CatalogFactory
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=31844. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31844 [chain] LookupCommand should use new CatalogFactory [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||31845 nThis|| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Questions regarding probability distributions
--- F Norin [EMAIL PROTECTED] wrote: Do you have any references for the quantum physics cases? I certainly didn't specialize in quantum physics (plasma physics typically uses almost everything _but_ quantum physics), but I did get as far as a EE graduate course in QED and never encountered such probability models. Maybe it's because I wasn't in a physics department or ever really encountered molecular models in what I was studying? I don't have any references handy (not my area of expertise), but it's often mentioned as an application area in articles dealing with these distributions. For instance, I guess physics models that uses Brownian motion models could use these distributions as they do show up in connection with Brownian motion theory. Thanks. My engineering physics curriculum was a little non-standard (when compared to physics departments' programs), and the statistical thermodynamics course didn't actually cover statistical mechanics (hence the peculiar course title, I suppose), which is where I presume one would ordinarily encounter the analysis of Brownian motion. Honestly, I doubt most of the users of Commons Math will be needing this kind of distribution, but I guess if we merge in (parts of) Colt, we might end up attracting that kind of user. As a matter of fact, many concepts in probability theory that at first sight may seem rather obscure can actually be used for practical applications. Stochastic modeling of the financial markets is a good example where very advanced mathematics is actually put to practical use. Ah, interesting point. I only just learned a teeny bit about integration of stochastic equations in portfolio value projection from a couple of C/C++ Users Journal articles earlier this year. A graduate complex analysis course I sat in on just the first week of started out with numerous examples of applications to reasonably real-world problems that I never would have thought of (not the ones I learned about in other courses that used complex analysis, for sure). Math certainly does have an uncanny way of connecting both with other areas of itself and the real world. I think Commons Math will be unusually hard pressed (compared to other math libraries) to choose what we feel are the most useful / commonly used features for inclusion in the library. If we were working on a more general purpose math library, the constraints obviously wouldn't be as tight. Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
{snip}
What I need is a Apache contrib for dummies HOWTO
I couldnt agree more with this. I am new here and I had somethings to
add to the email project recently but after searching the commons and
sandox project I was confused with exactly what to do and why. a
decent HOWTO would help immensely.
Just me 2 cents
-Corey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
On Fri, 22 Oct 2004 12:51:59 +0800, Corey Scott [EMAIL PROTECTED] wrote:
{snip}
What I need is a Apache contrib for dummies HOWTO
I couldnt agree more with this. I am new here and I had somethings to
add to the email project recently but after searching the commons and
sandox project I was confused with exactly what to do and why. a
decent HOWTO would help immensely.
This would be the obvious place to start:
http://www.apache.org/dev/contributors.html
This isn't what you're looking for?
--
Martin Cooper
Just me 2 cents
-Corey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
too many TCP connections using httpClient?
Hi everybody, this is my code:
private void notifyTimeServer() {
//
logger.debug(notifyTimeServer, + timerURL);
//
HttpClient client = new HttpClient();
HttpMethod method = new GetMethod(timerURL);
int statusCode = -1;
for (int attempt = 0; statusCode == -1 attempt
MAX_CALLING_ATTEMPTS; attempt++) {
//
logger.debug(Establishing connection);
//
try {
statusCode = client.executeMethod(method);
}
catch (Exception e) {
//
logger.error(Error calling jsp);
//
}
}
if (statusCode != -1) {
//
logger.debug(Connection estabilished);
//
byte[] responseBody = method.getResponseBody();
method.releaseConnection();
}
}
I was looking with TCPView the number of TCP connections that this piece of
code is opening when talking to the server and I saw that opens an
incredible number of connections. All TCP connections are in TIME_WAIT
state.
Is there something wrong in this code? Or I'm forgetting something?
Best regards,
Massimo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: too many TCP connections using httpClient?
Make sure to *always* call method.releaseConnection() e.g. a finally
block. Even if the request was unsuccessful.
Massimo Signori wrote:
Hi everybody, this is my code:
private void notifyTimeServer() {
//
logger.debug(notifyTimeServer, + timerURL);
//
HttpClient client = new HttpClient();
HttpMethod method = new GetMethod(timerURL);
int statusCode = -1;
for (int attempt = 0; statusCode == -1 attempt
MAX_CALLING_ATTEMPTS; attempt++) {
//
logger.debug(Establishing connection);
//
try {
statusCode = client.executeMethod(method);
}
catch (Exception e) {
//
logger.error(Error calling jsp);
//
}
}
if (statusCode != -1) {
//
logger.debug(Connection estabilished);
//
byte[] responseBody = method.getResponseBody();
method.releaseConnection();
}
}
I was looking with TCPView the number of TCP connections that this piece of
code is opening when talking to the server and I saw that opens an
incredible number of connections. All TCP connections are in TIME_WAIT
state.
Is there something wrong in this code? Or I'm forgetting something?
Best regards,
Massimo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
_
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: too many TCP connections using httpClient?
Massimo,
Calling HttpMethod#releaseConnection() does not guarantee that the
active connection will be closed. HttpClient _always_ tries its best to
reuse open connections. Whenever a connection can be kept alive,
HttpClient will keep it alive. That effectively means that when an
HttpClient instance goes out of scope, the underlying connection (or
several connections) may be left open until GC-ed.
Therefore, we recommend to have only one HttpClient instance per
application/component. New HttpClient instance per request approach is
HIGHLY discouraged:
class MyCommunicationComponent {
private HttpClient agent = new HttpClient();
private void doStuff() {
HttpMethod method = new GetMethod(timerURL);
this.agent.executeMethod(method);
...
}
}
If you absolutely have to create new instances of HttpClient we
recommend explicitly shutting down the connection manager, whenever you
are done using an HttpClient instance:
class MyCommunicationComponent {
private void doStuff() {
MultiThreadedHttpConnectionManager connman =
new MultiThreadedHttpConnectionManager();
HttpClient agent = new HttpClient(connman);
HttpMethod method = new GetMethod(timerURL);
agent.executeMethod(method);
...
connman.shutdown();
}
}
Hope this helps
Oleg
On Thu, 2004-10-21 at 15:34, Massimo Signori wrote:
Hi everybody, this is my code:
private void notifyTimeServer() {
//
logger.debug(notifyTimeServer, + timerURL);
//
HttpClient client = new HttpClient();
HttpMethod method = new GetMethod(timerURL);
int statusCode = -1;
for (int attempt = 0; statusCode == -1 attempt
MAX_CALLING_ATTEMPTS; attempt++) {
//
logger.debug(Establishing connection);
//
try {
statusCode = client.executeMethod(method);
}
catch (Exception e) {
//
logger.error(Error calling jsp);
//
}
}
if (statusCode != -1) {
//
logger.debug(Connection estabilished);
//
byte[] responseBody = method.getResponseBody();
method.releaseConnection();
}
}
I was looking with TCPView the number of TCP connections that this piece of
code is opening when talking to the server and I saw that opens an
incredible number of connections. All TCP connections are in TIME_WAIT
state.
Is there something wrong in this code? Or I'm forgetting something?
Best regards,
Massimo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it possible to send and email using HTTPCLIENT?
How about FTP through an HTTP proxy? Thanks, Steve Steve Johnson, Software Engineer, [EMAIL PROTECTED] direct 720.564.6532 www.mercury.com www.mercury.com -Original Message- From: Gerdes, Tom [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 8:08 AM To: Commons HttpClient Project Subject: RE: Is it possible to send and email using HTTPCLIENT? Thanks! -Original Message- From: Roland Weber [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 1:03 AM To: Commons HttpClient Project Subject: Re: Is it possible to send and email using HTTPCLIENT? Hello Tom, no it is not. Protocols for transferring EMail are SMTP or IMAP. HttpClient implements HTTP. Browsers do lots more than just HTTP, that's why most of them chose to implement mailing functionality as well. But HttpClient is intentionally focused on HTTP alone, which is tricky enough. There is a standard Java API for sending EMail in J2EE: http://java.sun.com/products/javamail/ You can probably get it running with J2SE as well. It includes support for multipart mail: http://java.sun.com/j2ee/1.4/docs/api/javax/mail/package-tree.html http://java.sun.com/j2ee/1.4/docs/api/javax/mail/Multipart.html hope that helps, Roland Gerdes, Tom [EMAIL PROTECTED] 19.10.2004 21:10 Please respond to Commons HttpClient Project To Commons HttpClient Project [EMAIL PROTECTED] cc Subject Is it possible to send and email using HTTPCLIENT? Can I just send a multipart post to an email server with attached files using Httpclient? Would this work for an email? If so, does anyone have an example of doing this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
