Re: What about webapp commons?
What are you thinking about? I thought it would not be required to get approval from PMC for a new commons component, is it? Oliver On 6/14/05, Noel J. Bergman [EMAIL PROTECTED] wrote: i think that either martin or noel were going to head over to taglibs Wasn't me. Martin, possibly. It wouldn't take much to set this up, so why not propose this to the PMC and get it started? --- Noel - 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]
[math] SummerOfCode2005 commons-math project
Hi! I spent some days exemining existing Math package, MathWishList and commons-dev Mailing List. Afterall, I want to represent at your disposal the project I am going to apply in the Summer Of Code 2005. PROJECT TITLE: Alternative Random Number Generators Implementation For Jakata Commons Math SYNOPSIS: Generation of completely unpredictable random numbers is impossible. But there is a wide range of good-working algorithms which allow to achieve more or less randomness. In the Jakarta-commons Wiki MathWishList there is a request for implementing alternative pseudo-random number generators (PRNG) http://wiki.apache.org/jakarta-commons/MathWishList. Considering this request I chose this project for the Google SummerOfCode 2005. DELIVERABLES: During the phase of the project I am going to implement next algorithms: I. Uniform Deviates PRNG: 1) Minimal random number generator of Park and Miller with Bays-Durham shuffle 2) Long period random number generator of L'Ecuyer with Bays-Durham shuffle 3) Knuth's subtractive Random Number Generation algorithm II. Binomial Distribution PRNG. PROJECT DESCRIPTION: As for the background for the project I chose the resourse Numerical Recipes: The Art Of Scientific Computing and the book of Knuth's The Art of Programming. I put before myself a goal to write: -- efficient -- fully documented algorithms. All the code will be written according to the Code Conventions for the Java Programming Language and documented with full javadoc included. In this project my logo is: To make GOOD rathen that to make MUCH. PROJECT SCHEDULE: I hope the algorithms I will implement will be included to the Jakarta Commons-Math subpackage Random. To achieve this goal I divide the project time into two periods: 1. Writing the code - lasting a month, but not more than August,3 2. Updating with the proposals from the Commons-Math Mailing List - lasting a month, but not more than September,1. Please, let me know what do you think about my project. Thanks, Rostyslav. - Original Message - From: Al Chou [EMAIL PROTECTED] To: commons-dev@jakarta.apache.org; [EMAIL PROTECTED] Sent: Saturday, June 11, 2005 2:38 AM Subject: [math] FW: [interest in] SummerOfCode2005 commons-math project Rostyslav, I'm sure we'd be happy to have you join the project. I've copied this message to the Jakarta commons-dev mailing list. Al -Original Message- From: Uzhgorod [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 3:16 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: SummerOfCode2005 commons-math project Rostyslav Slipetskyy Dobrianskogo St, 10/21, Uzhgorod, Ukraine. Hi! I'm a 3rd year student of Computer Science Dept in Kyiv-Mogyla University (Ukraine, Kyiv). I'm interested in the commons-math project of SummerOfCode2005. I am one of three members of a university ACM programming team. ACM (Association of Computer Machinery) is a world-famous organization which guides World Programming Contests. In September our team will fight for a grant to the world semi-finals. During numerous contests, I could see the advantages of well-written code libraries. Moreover, our team felt huge unsufficience of : -- efficiently implemented -- fully documented libraries which cover a wide range of different algorithmic areas. That is why we started to implement Graph Library, which was our student course paper at our university. The experience we gained, I really hope, will help me to do well if I have the opportunity to take part in the commons-math project. We wrote our Graph Library using C/C++, but personally I know Java syntax, and some percent of the contest problems during ACM contests we write on Java. Really a huge amount of ACM contest problems have in general mathematical background. That is why I think I obtain some mathematical skills. Frankly speaking, I have rather poor knowledge of Statistics :( , but I think I will manage to bridge this gap :) I'm really very interested in this project. It will a great chance for me to try my programming skills in a real challenge. Please, give me to know if the commons-math project is still available, if my abilities and knowledge satisfy the needs to do this project, and if it is possible for me to apply for this project. Thank you! -- Rostyslav __ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] FW: [interest in] SummerOfCode2005 commons-math project
Hi! I spent some days exemining existing Math package, MathWishList and commons-dev Mailing List. Afterall, I want to represent at your disposal the project I am going to apply in the Summer Of Code 2005. PROJECT TITLE: Alternative Random Number Generators Implementation For Jakata Commons Math SYNOPSIS: Generation of completely unpredictable random numbers is impossible. But there is a wide range of good-working algorithms which allow to achieve more or less randomness. In the Jakarta-commons Wiki MathWishList there is a request for implementing alternative pseudo-random number generators (PRNG) http://wiki.apache.org/jakarta-commons/MathWishList. Considering this request I chose this project for the Google SummerOfCode 2005. DELIVERABLES: During the phase of the project I am going to implement next algorithms: I. Uniform Deviates PRNG: 1) Minimal random number generator of Park and Miller with Bays-Durham shuffle 2) Long period random number generator of L'Ecuyer with Bays-Durham shuffle 3) Knuth's subtractive Random Number Generation algorithm II. Binomial Distribution PRNG. PROJECT DESCRIPTION: As for the background for the project I chose the resourse Numerical Recipes: The Art Of Scientific Computing and the book of Knuth's The Art of Programming. I put before myself a goal to write: -- efficient -- fully documented algorithms. All the code will be written according to the Code Conventions for the Java Programming Language and documented with full javadoc included. In this project my logo is: To make GOOD rathen that to make MUCH. PROJECT SCHEDULE: I hope the algorithms I will implement will be included to the Jakarta Commons-Math subpackage Random. To achieve this goal I divide the project time into two periods: 1. Writing the code - lasting a month, but not more than August,3 2. Updating with the proposals from the Commons-Math Mailing List - lasting a month, but not more than September,1. Please, let me know what do you think about my project. Thanks, Rostyslav. - Original Message - From: Al Chou [EMAIL PROTECTED] To: commons-dev@jakarta.apache.org; [EMAIL PROTECTED] Sent: Saturday, June 11, 2005 2:38 AM Subject: [math] FW: [interest in] SummerOfCode2005 commons-math project Rostyslav, I'm sure we'd be happy to have you join the project. I've copied this message to the Jakarta commons-dev mailing list. Al -Original Message- From: Uzhgorod [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 3:16 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: SummerOfCode2005 commons-math project Rostyslav Slipetskyy Dobrianskogo St, 10/21, Uzhgorod, Ukraine. Hi! I'm a 3rd year student of Computer Science Dept in Kyiv-Mogyla University (Ukraine, Kyiv). I'm interested in the commons-math project of SummerOfCode2005. I am one of three members of a university ACM programming team. ACM (Association of Computer Machinery) is a world-famous organization which guides World Programming Contests. In September our team will fight for a grant to the world semi-finals. During numerous contests, I could see the advantages of well-written code libraries. Moreover, our team felt huge unsufficience of : -- efficiently implemented -- fully documented libraries which cover a wide range of different algorithmic areas. That is why we started to implement Graph Library, which was our student course paper at our university. The experience we gained, I really hope, will help me to do well if I have the opportunity to take part in the commons-math project. We wrote our Graph Library using C/C++, but personally I know Java syntax, and some percent of the contest problems during ACM contests we write on Java. Really a huge amount of ACM contest problems have in general mathematical background. That is why I think I obtain some mathematical skills. Frankly speaking, I have rather poor knowledge of Statistics :( , but I think I will manage to bridge this gap :) I'm really very interested in this project. It will a great chance for me to try my programming skills in a real challenge. Please, give me to know if the commons-math project is still available, if my abilities and knowledge satisfy the needs to do this project, and if it is possible for me to apply for this project. Thank you! -- Rostyslav __ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35338] - [net] FTPClient.listFiles() hangs on Red Hat Linux
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=35338. 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=35338 --- Additional Comments From [EMAIL PROTECTED] 2005-06-14 09:22 --- You are correct, the problem was with listNames() (I didn't try listFiles()). The FTP server is Suse Linux. I'm not sure of the version (using an ISP). The server is public. However, my app uses a private password and username (I can email the info to you, but don't want to post it here). The list of files in the directory is small: incoming DreamBeans_Windows.exe DreamBeans_Solaris_x86.sh DreamBeans_Solaris_sparc.sh DreamBeans_MacOS.sit DreamBeans_Linux_x86.sh DreamBeans_Generic_Installer.sh DreamBeans_Linux_x86_test.sh I can access the server using ftp at the command line from Fedora Linux and use commands such as ls etc. Thus, I know the network connection is okay. One confusing thing though is that on both Windows XP and Linux, when I use ftp at the command line to log in, the initial pwd is one directory level higher than that entered by commons-net (same ftp account). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven.compile.source
On Tue, 2005-06-14 at 15:24 +1000, Brett Porter wrote: Firstly, I still believe if you've got sufficient testing, this isn't really necessary, and this discussion is getting a little carried away. The problem is that testing is supposed to be done by the unit tests. But the unit tests won't pick this up, even when testers download the source onto a machine with jdk1.3 and run maven test. The only way this would be picked up is if someone downloads a RC jar file pre-built and then runs it in an application that uses the class that has the problem. And that can't be relied upon for commons projects with fairly small user bases. Having problems that aren't found by the unit tests isn't good. There are very limited cases where this is a problem in the current JDKs (theoretically there could be more, but it seems so far that StringBuffer one is the primary one). Yes, but that one problem is a nasty one. It is not at all unlikely for code to pass a StringBuffer object to a PrintStream. Using compile.executable is going to be sufficient in Maven. Yes, I think so too. I can't think of any problems with this approach. I certainly wouldn't like to move back to Ant builds, and don't see any reason why that would be necessary as long as maven.compile.executable is available. The other issue is what is generated in the manifest under Build-jdk. Well, that's not even documented in http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#JAR%20Manifest. It appears to be something Ant and Maven both set, but the JAR tools doesn't. It should *not* be used as an indication of what JDK it was designed to run on. So I don't see this as a problem. I agree. It's a nice-to-have but not necessary. The project documentation should describe what JVM is supported. Of course if this suggestion were implemented then this would be solved completely: http://marc.theaimsgroup.com/?l=turbine-maven-devm=111870499228817w=2 Let's not forget the downsides of using JDK 1.3 to compile the sources. That's now an EOL'd JDK. Someone has already mentioned (I have no idea if it is true), that a newer javac could have less bugs and generate better bytecode even when targetting an older JVM. Not to mention the massive inconvenience it is to maintain a separate JDK, and to swtich to it for certain builds and not others. True, newer javac versions should be better. That's why I wanted to avoid compiling on old systems - but I believe the StringBuffer example proves that it's just not avoidable. Wouldn't it be nice if javac could utilise all those @since tags in rt.jar to do this for you? :) Agreed! I've been thinking about enhancing clirr to detect exactly these sorts of issues. The @since tags just aren't reliable enough, but it should be possible to compare two rt.jar files with clirr and generate a list of methods added, then flag code which calls an added method. IMO, I think compile.source|target is good enough, as long as you have enough coverage and someone is testing on the JDKs you intend to target. Unfortunately I can't agree - for commons projects at least. Maybe for bigger projects with more thorough release cycles such as Tomcat and Maven it can be assumed that someone out there will test a binary download against all the supported JVMs. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven.compile.source
Simon Kitching wrote on Tuesday, June 14, 2005 9:13 AM: On Tue, 2005-06-14 at 15:24 +1000, Brett Porter wrote: Firstly, I still believe if you've got sufficient testing, this isn't really necessary, and this discussion is getting a little carried away. The problem is that testing is supposed to be done by the unit tests. But the unit tests won't pick this up, even when testers download the source onto a machine with jdk1.3 and run maven test. The only way this would be picked up is if someone downloads a RC jar file pre-built and then runs it in an application that uses the class that has the problem. And that can't be relied upon for commons projects with fairly small user bases. It seems we need a new Maven plugin jdktest. You configure the SDKs to be tested and the plugin uses those for the test code only. This might automatically ensure compatibility also with non-Sun JDKs. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Commons Jelly 1.0 based on RC4
On Sun, 2005-06-12 at 13:27 +1000, Brett Porter wrote: Hi, There are release candidates here: http://people.apache.org/~brett/commons-jelly-1.0-RCs/ In commons-jelly-1.0-rc4.tar.gz, file bin/jelly has dos line-endings. This means the file cannot be run: output [EMAIL PROTECTED]:~/downloads/jelly/commons-jelly-1.0/bin$ sh jelly : command not found jelly: line 39: syntax error: unexpected end of file /output The file is also not executable (though that may not be a bad thing). BTW: I've not tested running the binary jelly.jar with java 1.3 :-) Otherwise everything looks fine to me. I would be happy to see this one issue fixed without another RC. +1 on release, assuming jelly script fixed. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site][email] Broken link on Jakarta site.
On Mon, 2005-06-13 at 20:37 +0530, Bindul Bhowmik wrote: Now, to my original problem: since brutus is out of action, where do I get nightly builds for commons-email (if it is getting built at all)? http://cvs.apache.org/builds/jakarta-commons/nightly/ Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] distribution format
I'll try to help directly and keep things moving for this week.
I hence propose to:
- change the script to $@, I am positive moving to $1 $2 is what
you wish (the quote gets removed by the script-invocation, see PS for a
test)
- drop or not drop classpath whichever you wish.
- also, in the archive, as noted:
- the scripts are in Windows end-of-lines
- the x-bit in the tar.gz for the bin/jelly is missing (and in the
zip if possible, ant allows that)
- make a README for binaries saying which taglibs are installed and
that extensibility is either done by hand following dependencies or
using src.
An example I made is at:
http://people.apache.org/~polx/README-binary-jelly.txt
Brett, I really hope not to kill your efforts! Sorry to look so
constraining. Do tell me if I should either commit this or let you do
so so that it streams in the releases...
Btw, how can, in a vote, be answered: yes with the changes made
already as opposed to the release-candidates presented in the home
page ???
paul
PS: here's a test for $* vs $@:
j:jelly xmlns:j=jelly:core
Arg[0] is ${args[0]}.
Arg[1] is ${args[1]}.
Arg[2] is ${args[2]}.
/j:jelly
If invoked with binary-delivered bin/jelly with the parameters a b
c it gives the output:
: Arg[0] is /tmp/blop.jelly.
: Arg[1] is a.
: Arg[2] is b.
If the bin is changed to $@ you get the output:
Arg[0] is /tmp/blop.jelly.
Arg[1] is a b.
Arg[2] is c.
Le 14 juin 05, à 01:59, Brett Porter a écrit :
Paul - thanks for your feedback, comments below. Can I ask you to
formally vote on the vote thread, too - do these comments lead to a -1
(hold the release until fixed), -0 (prefer them fixed, but not
essential) or +1 (these can wait until next time) ? This *has* to be
on the [vote] thread.
I'll also point out I have limited time to work on this now, and
starting with JavaOne I'll be away for 3 weeks - so either this is out
this week, someone else steps up to finish it, or it waits until
August. I'm not in anyway trying to influence the vote here - just to
give necessary perspective and make sure we keep moving.
Paul Libbrecht wrote:
My first comments on the binary:
- packaging is simple and straightforward, that's good!
- last line of the sh script should have $@ around instead of $* I
believe
(otherwise you don't allow spaces in parameters, should I commit
this?)
I thought it was correct ($@ expands to $1 $2 ... which I don't
think works when $1 is already quoted, but I may be wrong).
- do we not want to include an endorsed directory since it would
allow to circumvent the shipped parser and a possibly too old version
of xalan??
... or require 1.4 for the standalone and get rid of all of them and
halve the distribution size :)
In the current situation, I think the JDK 1.4 or JDK 5.0 parser will
be used which is probably a good thing (at least with 5.0 it has a
newer Xerces built in). From what I can tell, Jelly works just fine
under the built in parsers of these JDKs.
- I would resign to take in account an existing CLASSPATH variable in
the script ... it tends to add unpredictability. People can still
hack the script if they wish.
I don't really mind either way.
- the README is for the source... we need to have one for the binary,
or?
It should include:
- which taglibs are included (not sure of the list, looks like xml
is not for example)
- which examples can be run
-- about this, I feel we should include examples, or maybe
examples with URLs ??
- how to download (and install) more taglibs (if possible)
-- about this, I fear forehead will not support this... why not
use shell
script to define the classpath using a command that takes all jars
in the
lib directory ? (or let it be with extensibility and refer to the
source for it,
not very nice)
This seems reasonable, though I'd hope the site gives them enough info
and is easy enough to find. I think the one README can be used for
both, starting with the binary instructions.
But really, I don't have the time to spend on this, this week.
... just to catch up quickly on talk exchanges about the
documentation inclusion: I think we should include the produced
web-site in both the source and binary distribution since it cannot
be built with either of them.
You can build the documentation in the source with maven xdoc.
Perhaps the README should be adjusted accordingly.
Sorry for the late replies.
Better late than never! :)
Cheers,
Brett
-
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]
[configuration] What about live-update of config data?
Folks, I was wondering if there is something like a live update for classes depending on configuration data that might change while the application is running? I was thinking of something like a registry mechanism where an object tells a central service that it depends on this and that property and gets a call back as soon as the property changes. Is there something like that in the configuration component? If not, would it be an option to include it in future releases? Thanks in advance and cheers Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r190565 - in /jakarta/commons/proper/logging/trunk/src: java/org/apache/commons/logging/impl/LogFactoryImpl.java test/org/apache/commons/logging/LoadTest.java test/org/apache/commons/logging/NullClassLoaderTest.java test/org/apache/commons/logging/UserClass.java
Author: skitching
Date: Tue Jun 14 03:03:48 2005
New Revision: 190565
URL: http://svn.apache.org/viewcvs?rev=190565view=rev
Log:
Merge in the allow-flawed branch, as there were no objections.
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/LoadTest.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/NullClassLoaderTest.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/UserClass.java
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java?rev=190565r1=190564r2=190565view=diff
==
---
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
Tue Jun 14 03:03:48 2005
@@ -20,8 +20,6 @@
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
-import java.security.AccessController;
-import java.security.PrivilegedAction;
import java.util.Enumeration;
import java.util.Hashtable;
import java.util.Vector;
@@ -99,6 +97,49 @@
protected static final String LOG_PROPERTY_OLD =
org.apache.commons.logging.log;
+/**
+ * The name of the system property which can be set true/false to
+ * determine system behaviour when a bad context-classloader is
encountered.
+ * When set to false
+ *
+ * Default behaviour: true (tolerates bad context classloaders)
+ *
+ * See also method setAttribute.
+ */
+public static final String ALLOW_FLAWED_CONTEXT_PROPERTY =
+org.apache.commons.logging.Log.allowFlawedContext;
+
+/**
+ * The name of the system property which can be set true/false to
+ * determine system behaviour when a bad logging adapter class is
+ * encountered during logging discovery. When set to false, an
+ * exception will be thrown and the app will fail to start. When set
+ * to true, discovery will continue (though the user might end up
+ * with a different logging implementation than they expected).
+ *
+ * Default behaviour: true (tolerates bad logging adapters)
+ *
+ * See also method setAttribute.
+ */
+public static final String ALLOW_FLAWED_DISCOVERY_PROPERTY =
+org.apache.commons.logging.Log.allowFlawedDiscovery;
+
+/**
+ * The name of the system property which can be set true/false to
+ * determine system behaviour when a logging adapter class is
+ * encountered which has bound to the wrong Log class implementation.
+ * When set to false, an exception will be thrown and the app will fail
+ * to start. When set to true, discovery will continue (though the user
+ * might end up with a different logging implementation than they
expected).
+ *
+ * Default behaviour: true (tolerates bad Log class hierarchy)
+ *
+ * See also method setAttribute.
+ */
+public static final String ALLOW_FLAWED_HIERARCHY_PROPERTY =
+org.apache.commons.logging.Log.allowFlawedHierarchy;
+
+
// - Instance Variables
@@ -158,6 +199,21 @@
protected Class logMethodSignature[] =
{ LogFactory.class };
+/**
+ * See getBaseClassLoader and initConfiguration.
+ */
+private boolean allowFlawedContext;
+
+/**
+ * See handleFlawedDiscovery and initConfiguration.
+ */
+private boolean allowFlawedDiscovery;
+
+/**
+ * See handleFlawedHierarchy and initConfiguration.
+ */
+private boolean allowFlawedHierarchy;
+
// - Public Methods
@@ -272,6 +328,21 @@
* Set the configuration attribute with the specified name. Calling
* this with a codenull/code value is equivalent to calling
* coderemoveAttribute(name)/code.
+ * p
+ * This method can be used to set logging configuration programmatically
+ * rather than via system properties. It can also be used in code running
+ * within a container (such as a webapp) to configure behaviour on a
+ * per-component level instead of globally as system properties would do.
+ * To use this method instead of a system property, call
+ * pre
+ * LogFactory.getFactory().setAttribute(...)
+ * /pre
+ * This must be done before the first Log object is created; configuration
+ * changes after that point will be ignored.
+ * p
+ * This method is also called automatically if LogFactory detects a
+
svn commit: r190569 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
Author: skitching
Date: Tue Jun 14 03:23:08 2005
New Revision: 190569
URL: http://svn.apache.org/viewcvs?rev=190569view=rev
Log:
Avoid wrapping exception - patch by Brian Stansberry
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java?rev=190569r1=190568r2=190569view=diff
==
---
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
Tue Jun 14 03:23:08 2005
@@ -878,6 +878,10 @@
+ :
+ msg.trim());
break;
+} catch(LogConfigurationException e) {
+// call to handleFlawedHierarchy above must have thrown
+// a LogConfigurationException, so just throw it on
+throw e;
} catch(Throwable t) {
// handleFlawedDiscovery will determine whether this is a fatal
// problem or not. If it is fatal, then a
LogConfigurationException
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35346] - [net] NTFTPEntryParser parses directory names starting with a number followed by space incorrectly.
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=35346. 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=35346 --- Additional Comments From [EMAIL PROTECTED] 2005-06-14 13:08 --- I think your patch solves this problem (it correctly notes that we should expect EITHER a DIR OR a number indicating size, not two optional fields) but I don't think your patch goes far enough. I think we need to solve for the fact that there can be spaces anywhere within an NT filename. 123 xyz works, but how about 123 abc xyz? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r190581 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
Author: skitching
Date: Tue Jun 14 04:09:44 2005
New Revision: 190581
URL: http://svn.apache.org/viewcvs?rev=190581view=rev
Log:
Fixed copy-and-paste error in getConfigurationValue when getting from system
property.
Thanks to Brian Stansberry for spotting this.
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
Modified:
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java?rev=190581r1=190580r2=190581view=diff
==
---
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
Tue Jun 14 04:09:44 2005
@@ -626,7 +626,7 @@
logDiagnostic(Looking for system property + property);
try {
-String value = System.getProperty(LOG_PROPERTY);
+String value = System.getProperty(property);
logDiagnostic(Found value [ + value + ] for + property);
return value;
} catch (SecurityException e) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] What about live-update of config data?
Oliver Zeigermann wrote: Folks, I was wondering if there is something like a live update for classes depending on configuration data that might change while the application is running? I was thinking of something like a registry mechanism where an object tells a central service that it depends on this and that property and gets a call back as soon as the property changes. Is there something like that in the configuration component? If not, would it be an option to include it in future releases? Thanks in advance and cheers Oliver What we have thought about are observable configurations, i.e. you register an event listener at a configuration and get then notified about changes at properties. But there is nothing concrete yet. Your suggestion goes a bit further by allowing a listener to exactly specify in which events it is interested. I think this is a good idea because typically not all portions of a configuration are important enough to react on every change. If we had a generic event notification mechanism, your registry could be implemented on top of that. A similar point I had in mind is a combination of such an event notification mechanism and our reloading facilities. If a reloading strategy could be triggered (by some external sources) to periodically check configuration files, it could send events whenever a change is detected. In short, I would like to see features like that in future releases of commons-configuration. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34661] - [logging][PATCH] Improvements to LogFactoryImpl
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=34661. 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=34661 --- Additional Comments From [EMAIL PROTECTED] 2005-06-14 13:20 --- Re the InvocationTargetException for LogKitLogger: Does it actually matter whether ExceptionInInitializerError or InvocationTargetException occurs for LogKitLogger? It does for logadapters that are part of auto-discovery as we want to continue discovery in the former case but not the latter. But LogKitLogger is not part of auto-discovery, and obviously no out-of-tree logger will be. So the only way LogFactoryImpl will ever try these loggers is when specificLogClassName != null - but in that case, we throw an LCE regardless of whether ExceptionInInitializerError or InvocationTargetException occurred, yes? And all the auto-discovered loggers should now be working as expected. So I think (hope) things are ok as they are.. Re comment #33 point 3: Yep, I pretty much agree with your analysis. However there is another option: just choose not to support this, and make the users fix their problem properly. Most of the problems reported against JCL are by users who are trying to use JCL out of the box and are confused it doesn't work. And I sympathise with them - they don't *want* to use JCL, it just came with a library and they just want it to shut up and not interfere with them running their app. I think people who are explicitly specifying logadapters via commons-logging.properties files are generally likely to be able to fix their classpath problems. And the next release of JCL should include a separate adapters-only jar which is the *correct* solution to this problem. So I'm inclined to just ignore this problem. People who specify a log class will be no worse off than JCL 1.0.4 if they throw commons-logging.jar in their webapp, and won't have any problems at all if they use commons-logging-adapters.jar (or whatever we choose to call it). Comments? NB: I think it would be a good idea to wind up this bugzilla entry sometime soon. It's getting rather clumsy to read/navigate. We could start another entry for the next topic - or just move to the mailing list until we need to start attaching new patches. PS: thanks a lot for your comments/discussion of logging. It's really making me think :-). For such a small project this really is quite difficult isn't it?! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] What about live-update of config data?
Fully agreed. Concerning a triggered thing, what would be the source for such a trigger. Considering this http://www.jcp.org/en/jsr/detail?id=236 java.util.Timer might cause problems in a J2EE environment and there is no Timer for Application Servers, yet. By the way how is the reloading facility triggered right now? Is it triggered at all or is it checked upon every access to the config. Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Folks, I was wondering if there is something like a live update for classes depending on configuration data that might change while the application is running? I was thinking of something like a registry mechanism where an object tells a central service that it depends on this and that property and gets a call back as soon as the property changes. Is there something like that in the configuration component? If not, would it be an option to include it in future releases? Thanks in advance and cheers Oliver What we have thought about are observable configurations, i.e. you register an event listener at a configuration and get then notified about changes at properties. But there is nothing concrete yet. Your suggestion goes a bit further by allowing a listener to exactly specify in which events it is interested. I think this is a good idea because typically not all portions of a configuration are important enough to react on every change. If we had a generic event notification mechanism, your registry could be implemented on top of that. A similar point I had in mind is a combination of such an event notification mechanism and our reloading facilities. If a reloading strategy could be triggered (by some external sources) to periodically check configuration files, it could send events whenever a change is detected. In short, I would like to see features like that in future releases of commons-configuration. Oliver - 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 35346] - [net] NTFTPEntryParser parses directory names starting with a number followed by space incorrectly.
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=35346. 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=35346 --- Additional Comments From [EMAIL PROTECTED] 2005-06-14 13:39 --- (In reply to comment #3) I think your patch solves this problem (it correctly notes that we should expect EITHER a DIR OR a number indicating size, not two optional fields) but I don't think your patch goes far enough. I think we need to solve for the fact that there can be spaces anywhere within an NT filename. 123 xyz works, but how about 123 abc xyz? By the way, excuse my manners. I should have thanked you for your patch. You've found a real problem. The problem was just bigger than you thought it was. If you feel like it, please submit another patch that solves for all the names-with-spaces cases and includes tests for them in the Test class and then I will commit it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] What about live-update of config data?
Oliver Zeigermann wrote: Fully agreed. Concerning a triggered thing, what would be the source for such a trigger. Considering this http://www.jcp.org/en/jsr/detail?id=236 java.util.Timer might cause problems in a J2EE environment and there is no Timer for Application Servers, yet. Right, this is a problem and that's the reason why I very unspecifically wrote by some external sources ;-) My idea was to approach this in a very abstract way. A reloading strategy would define a tick() method, which would cause it to check its source file. Then it would be left to a concrete application to ensure that this method gets called periodically. E.g. for non managed environments a simple timer based service could be provided. In an AppSvr a different approach must be used (e.g. a servlet filter that triggers the reloading strategy at each request? or a server specific extension?). By the way how is the reloading facility triggered right now? Is it triggered at all or is it checked upon every access to the config. It is indeed checked for each access (which causes a very tight coupling between a configuration and its reloading strategy). Oliver Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Folks, I was wondering if there is something like a live update for classes depending on configuration data that might change while the application is running? I was thinking of something like a registry mechanism where an object tells a central service that it depends on this and that property and gets a call back as soon as the property changes. Is there something like that in the configuration component? If not, would it be an option to include it in future releases? Thanks in advance and cheers Oliver What we have thought about are observable configurations, i.e. you register an event listener at a configuration and get then notified about changes at properties. But there is nothing concrete yet. Your suggestion goes a bit further by allowing a listener to exactly specify in which events it is interested. I think this is a good idea because typically not all portions of a configuration are important enough to react on every change. If we had a generic event notification mechanism, your registry could be implemented on top of that. A similar point I had in mind is a combination of such an event notification mechanism and our reloading facilities. If a reloading strategy could be triggered (by some external sources) to periodically check configuration files, it could send events whenever a change is detected. In short, I would like to see features like that in future releases of commons-configuration. Oliver - 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] What about live-update of config data?
On the other hand http://www.cenqua.com/clover/eg/jboss/report/org/jboss/util/TimedCachePolicy.html e.g. the JBoss people do not seem to care about not using java.util.Timer themselves ;) Oliver On 6/14/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: Fully agreed. Concerning a triggered thing, what would be the source for such a trigger. Considering this http://www.jcp.org/en/jsr/detail?id=236 java.util.Timer might cause problems in a J2EE environment and there is no Timer for Application Servers, yet. By the way how is the reloading facility triggered right now? Is it triggered at all or is it checked upon every access to the config. Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Folks, I was wondering if there is something like a live update for classes depending on configuration data that might change while the application is running? I was thinking of something like a registry mechanism where an object tells a central service that it depends on this and that property and gets a call back as soon as the property changes. Is there something like that in the configuration component? If not, would it be an option to include it in future releases? Thanks in advance and cheers Oliver What we have thought about are observable configurations, i.e. you register an event listener at a configuration and get then notified about changes at properties. But there is nothing concrete yet. Your suggestion goes a bit further by allowing a listener to exactly specify in which events it is interested. I think this is a good idea because typically not all portions of a configuration are important enough to react on every change. If we had a generic event notification mechanism, your registry could be implemented on top of that. A similar point I had in mind is a combination of such an event notification mechanism and our reloading facilities. If a reloading strategy could be triggered (by some external sources) to periodically check configuration files, it could send events whenever a change is detected. In short, I would like to see features like that in future releases of commons-configuration. Oliver - 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] What about live-update of config data?
Thanks for the interesting information. I still think this might be a valuable addition. If I find some time soon I will implement something for further consideration. Cheers Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Fully agreed. Concerning a triggered thing, what would be the source for such a trigger. Considering this http://www.jcp.org/en/jsr/detail?id=236 java.util.Timer might cause problems in a J2EE environment and there is no Timer for Application Servers, yet. Right, this is a problem and that's the reason why I very unspecifically wrote by some external sources ;-) My idea was to approach this in a very abstract way. A reloading strategy would define a tick() method, which would cause it to check its source file. Then it would be left to a concrete application to ensure that this method gets called periodically. E.g. for non managed environments a simple timer based service could be provided. In an AppSvr a different approach must be used (e.g. a servlet filter that triggers the reloading strategy at each request? or a server specific extension?). By the way how is the reloading facility triggered right now? Is it triggered at all or is it checked upon every access to the config. It is indeed checked for each access (which causes a very tight coupling between a configuration and its reloading strategy). Oliver Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Folks, I was wondering if there is something like a live update for classes depending on configuration data that might change while the application is running? I was thinking of something like a registry mechanism where an object tells a central service that it depends on this and that property and gets a call back as soon as the property changes. Is there something like that in the configuration component? If not, would it be an option to include it in future releases? Thanks in advance and cheers Oliver What we have thought about are observable configurations, i.e. you register an event listener at a configuration and get then notified about changes at properties. But there is nothing concrete yet. Your suggestion goes a bit further by allowing a listener to exactly specify in which events it is interested. I think this is a good idea because typically not all portions of a configuration are important enough to react on every change. If we had a generic event notification mechanism, your registry could be implemented on top of that. A similar point I had in mind is a combination of such an event notification mechanism and our reloading facilities. If a reloading strategy could be triggered (by some external sources) to periodically check configuration files, it could send events whenever a change is detected. In short, I would like to see features like that in future releases of commons-configuration. Oliver - 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]
DO NOT REPLY [Bug 35359] New: - tomcat5.exe crashes
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=35359. 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=35359 Summary: tomcat5.exe crashes Product: Commons Version: 1.0.1 Final Platform: PC OS/Version: Windows 2000 Status: NEW Severity: major Priority: P2 Component: Daemon AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] tomcat5.exe (a.k.a. Commons Daemon's prunsrv.exe) version 2.0.0.0 crashes when started as a service with Environment variables that do not contain %. Reason: prunsrv.c line 365: apxFree(e) crashes because prunsrv.c line 363: e = apxExpandStrW(gPool, p) may return input parameter p instead of newly allocated. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] What about live-update of config data?
Any idea how the source of the ticks might look like apart from java.util.Timer or what is being worked on in http://www.jcp.org/en/jsr/detail?id=236? Oliver On 6/14/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: Thanks for the interesting information. I still think this might be a valuable addition. If I find some time soon I will implement something for further consideration. Cheers Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Fully agreed. Concerning a triggered thing, what would be the source for such a trigger. Considering this http://www.jcp.org/en/jsr/detail?id=236 java.util.Timer might cause problems in a J2EE environment and there is no Timer for Application Servers, yet. Right, this is a problem and that's the reason why I very unspecifically wrote by some external sources ;-) My idea was to approach this in a very abstract way. A reloading strategy would define a tick() method, which would cause it to check its source file. Then it would be left to a concrete application to ensure that this method gets called periodically. E.g. for non managed environments a simple timer based service could be provided. In an AppSvr a different approach must be used (e.g. a servlet filter that triggers the reloading strategy at each request? or a server specific extension?). By the way how is the reloading facility triggered right now? Is it triggered at all or is it checked upon every access to the config. It is indeed checked for each access (which causes a very tight coupling between a configuration and its reloading strategy). Oliver Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Folks, I was wondering if there is something like a live update for classes depending on configuration data that might change while the application is running? I was thinking of something like a registry mechanism where an object tells a central service that it depends on this and that property and gets a call back as soon as the property changes. Is there something like that in the configuration component? If not, would it be an option to include it in future releases? Thanks in advance and cheers Oliver What we have thought about are observable configurations, i.e. you register an event listener at a configuration and get then notified about changes at properties. But there is nothing concrete yet. Your suggestion goes a bit further by allowing a listener to exactly specify in which events it is interested. I think this is a good idea because typically not all portions of a configuration are important enough to react on every change. If we had a generic event notification mechanism, your registry could be implemented on top of that. A similar point I had in mind is a combination of such an event notification mechanism and our reloading facilities. If a reloading strategy could be triggered (by some external sources) to periodically check configuration files, it could send events whenever a change is detected. In short, I would like to see features like that in future releases of commons-configuration. Oliver - 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: [site][email] Broken link on Jakarta site.
I downloaded the latest source file from the commons-email from that source and ran a diff on the existing code from SVN repository. The only 2 differences were a compiled code existing on a bin/ folder and a build.properties file: both did not exist on the SVN repository. So, for development purposes we can assume that the repository to be used is the SVN http://svn.apache.org/repos/asf/jakarta/commons/proper/email/trunk instead of the CVS one? Ramiro Pereira de Magalhães Simon Kitching wrote: On Mon, 2005-06-13 at 20:37 +0530, Bindul Bhowmik wrote: Now, to my original problem: since brutus is out of action, where do I get nightly builds for commons-email (if it is getting built at all)? http://cvs.apache.org/builds/jakarta-commons/nightly/ Regards, Simon Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Someone on commons-email?
robert burrell donkin wrote: On Mon, 2005-06-13 at 10:18 -0300, Ramiro Pereira de Magalhaes wrote: I'm interested in contributing with Email because I began to write a service on a project I'm working on that would benefit mutch of it's features. What I really need to know is if there is someone to add fixes and make changes to this project while the community (including myself) contributes with it. So, anyone here knows who is the commiter/in charge of commons-email? everyone's in change and no one ;) eric was managing the last release (but i haven't heard anything from him for a while). if eric's not around at the moment then it's a case of someone finding the energy to pick it up. unfortunately, everyone seems very busy... hopefully, if you persevere this'll happen someone soon. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Well, that's quite bad... :( Isn't anyone with managing powers interested in pushing email towards a release? I can checkout this project and start fixing anything by myself as (if) needed but this way I'll be working alone and in a branch that will probably be thrown away when the project start moving again... Awaiting for answers, Ramiro Pereira de Magalhães Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven.compile.source
Thanks all for clarifying the issues here. Assuming the unit tests have good coverage, what would be the risks of the following strategy: 0. Test compile and unit tests using generated ant build running under minimum jdk 1. Build release jar using 1.4/5 JDK with compile target set 2. Compile and run unit tests under minimum JDK against the release jar Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] What about live-update of config data?
Nothing too concrete yet. Depending on an application's needs there are multiple possibilites one can think of. It may even not be necessary to check the configuration at regular intervals, but an admin could manually force a reload e.g. by invoking a JMX method. JMX could be an option for a timer service, too. Another option would be a scheduler like quarzt. In J2EE 1.4 there is an EJB timer service. Is this the same as the one you refered to (JCP 236)? Oliver Oliver Zeigermann wrote: Any idea how the source of the ticks might look like apart from java.util.Timer or what is being worked on in http://www.jcp.org/en/jsr/detail?id=236? Oliver On 6/14/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: Thanks for the interesting information. I still think this might be a valuable addition. If I find some time soon I will implement something for further consideration. Cheers Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Fully agreed. Concerning a triggered thing, what would be the source for such a trigger. Considering this http://www.jcp.org/en/jsr/detail?id=236 java.util.Timer might cause problems in a J2EE environment and there is no Timer for Application Servers, yet. Right, this is a problem and that's the reason why I very unspecifically wrote by some external sources ;-) My idea was to approach this in a very abstract way. A reloading strategy would define a tick() method, which would cause it to check its source file. Then it would be left to a concrete application to ensure that this method gets called periodically. E.g. for non managed environments a simple timer based service could be provided. In an AppSvr a different approach must be used (e.g. a servlet filter that triggers the reloading strategy at each request? or a server specific extension?). By the way how is the reloading facility triggered right now? Is it triggered at all or is it checked upon every access to the config. It is indeed checked for each access (which causes a very tight coupling between a configuration and its reloading strategy). Oliver Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Folks, I was wondering if there is something like a live update for classes depending on configuration data that might change while the application is running? I was thinking of something like a registry mechanism where an object tells a central service that it depends on this and that property and gets a call back as soon as the property changes. Is there something like that in the configuration component? If not, would it be an option to include it in future releases? Thanks in advance and cheers Oliver What we have thought about are observable configurations, i.e. you register an event listener at a configuration and get then notified about changes at properties. But there is nothing concrete yet. Your suggestion goes a bit further by allowing a listener to exactly specify in which events it is interested. I think this is a good idea because typically not all portions of a configuration are important enough to react on every change. If we had a generic event notification mechanism, your registry could be implemented on top of that. A similar point I had in mind is a combination of such an event notification mechanism and our reloading facilities. If a reloading strategy could be triggered (by some external sources) to periodically check configuration files, it could send events whenever a change is detected. In short, I would like to see features like that in future releases of commons-configuration. Oliver - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33591] - [dbcp] Connection leak in PoolableConnection.close() (Oracle 10g driver)
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=33591.
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=33591
--- Additional Comments From [EMAIL PROTECTED] 2005-06-14 15:56 ---
I also had some issues with this bug, has this bug solution been accepted yet?
When will the new fix be included in a new release of dbcp?
I recently fixed the problem myself with the code shown below for
PoolableConection.close() (i didn't notice Dirk Verbeeck had already posted a
solution),
I just invalidate any connection found to be already closed.
The JUnit tests all still pass with my fix, BUT if someone can see something
wrong with it please let me know. I've been using it for a while now and it
seems to have fixed the connection leak problem i was experiencing.
public synchronized void close() throws SQLException {
boolean isClosed = false;
try {
isClosed = isClosed();
} catch (SQLException e) {
try {
_pool.invalidateObject(this);
} catch (Exception ie) {
// DO NOTHING the original exception will be rethrown
}
throw new SQLNestedException(Cannot close connection (isClosed
check failed), e);
}
if (isClosed) {
try {
_pool.invalidateObject(this);
} catch (Exception ie) {
// DO NOTHING, Already closed exception thrown below
}
throw new SQLException(Already closed.);
} else {
try {
_pool.returnObject(this);
} catch(SQLException e) {
throw e;
} catch(RuntimeException e) {
throw e;
} catch(Exception e) {
throw new SQLNestedException(Cannot close connection (return to
pool failed), e);
}
}
}
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] What about live-update of config data?
Yes, the timer service is the one in JCP 236. You are right, just a tick to check at the registry togther with some configurable providers for the tick. Possbile implementations may include one for - javax.management.timer.Timer - java.util.Timer - JMX Agreed? Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Nothing too concrete yet. Depending on an application's needs there are multiple possibilites one can think of. It may even not be necessary to check the configuration at regular intervals, but an admin could manually force a reload e.g. by invoking a JMX method. JMX could be an option for a timer service, too. Another option would be a scheduler like quarzt. In J2EE 1.4 there is an EJB timer service. Is this the same as the one you refered to (JCP 236)? Oliver Oliver Zeigermann wrote: Any idea how the source of the ticks might look like apart from java.util.Timer or what is being worked on in http://www.jcp.org/en/jsr/detail?id=236? Oliver On 6/14/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: Thanks for the interesting information. I still think this might be a valuable addition. If I find some time soon I will implement something for further consideration. Cheers Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Fully agreed. Concerning a triggered thing, what would be the source for such a trigger. Considering this http://www.jcp.org/en/jsr/detail?id=236 java.util.Timer might cause problems in a J2EE environment and there is no Timer for Application Servers, yet. Right, this is a problem and that's the reason why I very unspecifically wrote by some external sources ;-) My idea was to approach this in a very abstract way. A reloading strategy would define a tick() method, which would cause it to check its source file. Then it would be left to a concrete application to ensure that this method gets called periodically. E.g. for non managed environments a simple timer based service could be provided. In an AppSvr a different approach must be used (e.g. a servlet filter that triggers the reloading strategy at each request? or a server specific extension?). By the way how is the reloading facility triggered right now? Is it triggered at all or is it checked upon every access to the config. It is indeed checked for each access (which causes a very tight coupling between a configuration and its reloading strategy). Oliver Oliver On 6/14/05, Oliver Heger [EMAIL PROTECTED] wrote: Oliver Zeigermann wrote: Folks, I was wondering if there is something like a live update for classes depending on configuration data that might change while the application is running? I was thinking of something like a registry mechanism where an object tells a central service that it depends on this and that property and gets a call back as soon as the property changes. Is there something like that in the configuration component? If not, would it be an option to include it in future releases? Thanks in advance and cheers Oliver What we have thought about are observable configurations, i.e. you register an event listener at a configuration and get then notified about changes at properties. But there is nothing concrete yet. Your suggestion goes a bit further by allowing a listener to exactly specify in which events it is interested. I think this is a good idea because typically not all portions of a configuration are important enough to react on every change. If we had a generic event notification mechanism, your registry could be implemented on top of that. A similar point I had in mind is a combination of such an event notification mechanism and our reloading facilities. If a reloading strategy could be triggered (by some external sources) to periodically check configuration files, it could send events whenever a change is detected. In short, I would like to see features like that in future releases of commons-configuration. Oliver - 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] - 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: What about webapp commons?
On 6/13/05, Noel J. Bergman [EMAIL PROTECTED] wrote: i think that either martin or noel were going to head over to taglibs Wasn't me. Martin, possibly. Yes, it was me. I've been swamped with day job stuff, but will lob something over to Taglibs today. -- Martin Cooper It wouldn't take much to set this up, so why not propose this to the PMC and get it started? --- Noel - 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: What about webapp commons?
On 6/13/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: What are you thinking about? I thought it would not be required to get approval from PMC for a new commons component, is it? We're talking about a new Jakarta subproject, not a new Commons component. The latter was already largely rejected in earlier discussions. -- Martin Cooper Oliver On 6/14/05, Noel J. Bergman [EMAIL PROTECTED] wrote: i think that either martin or noel were going to head over to taglibs Wasn't me. Martin, possibly. It wouldn't take much to set this up, so why not propose this to the PMC and get it started? --- Noel - 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: What about webapp commons?
Oh, yes? Isn't a new subproject a bit too heavy weight? Anyway, if no one wants a commons web component it I will shut up. Is that really the case? Oliver On 6/14/05, Martin Cooper [EMAIL PROTECTED] wrote: On 6/13/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: What are you thinking about? I thought it would not be required to get approval from PMC for a new commons component, is it? We're talking about a new Jakarta subproject, not a new Commons component. The latter was already largely rejected in earlier discussions. -- Martin Cooper Oliver On 6/14/05, Noel J. Bergman [EMAIL PROTECTED] wrote: i think that either martin or noel were going to head over to taglibs Wasn't me. Martin, possibly. It wouldn't take much to set this up, so why not propose this to the PMC and get it started? --- Noel - 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]
jxpath ?
hi, is this project dead? no need for integration with jaxp1.3? ciao ricky ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What about webapp commons?
On 6/14/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: Oh, yes? Isn't a new subproject a bit too heavy weight? Anyway, if no one wants a commons web component it I will shut up. Is that really the case? You might want to catch up on some of the earlier discussions on this subject. ;-) The point is that servlets, filters, listeners, and related utilities don't really fit the charter of Jakarta Commons. Since there isn't a good place for those things to go today, the proposal on the table is to create a new WebApp Commons subproject. In addition, since Jakarta Taglibs is not in the best of health, the idea is to invite Taglibs to become a part of the new Webapp Commons subproject, potentially revitalising that community as well. I have just sent a feeler out to the Taglibs folks to see what they think of the idea. I'll report back when there's news. ;-) -- Martin Cooper Oliver On 6/14/05, Martin Cooper [EMAIL PROTECTED] wrote: On 6/13/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: What are you thinking about? I thought it would not be required to get approval from PMC for a new commons component, is it? We're talking about a new Jakarta subproject, not a new Commons component. The latter was already largely rejected in earlier discussions. -- Martin Cooper Oliver On 6/14/05, Noel J. Bergman [EMAIL PROTECTED] wrote: i think that either martin or noel were going to head over to taglibs Wasn't me. Martin, possibly. It wouldn't take much to set this up, so why not propose this to the PMC and get it started? --- Noel - 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: What about webapp commons?
OK. Got that! I think a was mislead by the word Commons in WebApp Commons. So, a Jakarta subproject is fine with me. Cheers Oliver On 6/14/05, Martin Cooper [EMAIL PROTECTED] wrote: On 6/14/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: Oh, yes? Isn't a new subproject a bit too heavy weight? Anyway, if no one wants a commons web component it I will shut up. Is that really the case? You might want to catch up on some of the earlier discussions on this subject. ;-) The point is that servlets, filters, listeners, and related utilities don't really fit the charter of Jakarta Commons. Since there isn't a good place for those things to go today, the proposal on the table is to create a new WebApp Commons subproject. In addition, since Jakarta Taglibs is not in the best of health, the idea is to invite Taglibs to become a part of the new Webapp Commons subproject, potentially revitalising that community as well. I have just sent a feeler out to the Taglibs folks to see what they think of the idea. I'll report back when there's news. ;-) -- Martin Cooper Oliver On 6/14/05, Martin Cooper [EMAIL PROTECTED] wrote: On 6/13/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: What are you thinking about? I thought it would not be required to get approval from PMC for a new commons component, is it? We're talking about a new Jakarta subproject, not a new Commons component. The latter was already largely rejected in earlier discussions. -- Martin Cooper Oliver On 6/14/05, Noel J. Bergman [EMAIL PROTECTED] wrote: i think that either martin or noel were going to head over to taglibs Wasn't me. Martin, possibly. It wouldn't take much to set this up, so why not propose this to the PMC and get it started? --- Noel - 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: [site][email] Broken link on Jakarta site.
SVN is the current source repository for all Jakarta Commons projects (proper and sandbox). The CVS repository was frozen at the time that migration to SVN took place, and is in read only state as a convenience for people that still had references to it. As for nightly builds, I run them for nearly all the commons packages ... but cannot for email because the developers haven't provided an Ant build.xml script where ant clean dist succeeds -- it compiles ok, but fails in the unit tests, and the script is set up such that this fails the build. The portion of the build output documenting this failure: [junit] Testsuite: org.apache.commons.mail.HtmlEmailTest [junit] Tests run: 6, Failures: 1, Errors: 1, Time elapsed: 3.807 sec [junit] Testcase: testGetSetTextMsg took 0.154 sec [junit] Testcase: testGetSetHtmlMsg took 0 sec [junit] Testcase: testGetSetMsg took 0.001 sec [junit] Testcase: testEmbed took 0.678 sec [junit] Testcase: testSend took 2.24 sec [junit] FAILED [junit] Unexpected exception thrown [junit] junit.framework.AssertionFailedError: Unexpected exception thrown [junit] at org.apache.commons.mail.HtmlEmailTest.testSend(HtmlEmailTest.java:302) [junit] Testcase: testSend2 took 0.694 sec [junit] Caused an ERROR [junit] javax.mail.NoSuchProviderException: smtp [junit] org.apache.commons.mail.EmailException: javax.mail.NoSuchProviderException: smtp [junit] at org.apache.commons.mail.Email.send(Email.java:822) [junit] at org.apache.commons.mail.MultiPartEmail.send(MultiPartEmail.java:224) [junit] at org.apache.commons.mail.HtmlEmail.send(HtmlEmail.java:227) [junit] at org.apache.commons.mail.HtmlEmailTest.testSend2(HtmlEmailTest.java:380) [junit] Caused by: javax.mail.NoSuchProviderException: smtp [junit] at javax.mail.Session.getService(Session.java:750) [junit] at javax.mail.Session.getTransport(Session.java:689) [junit] at javax.mail.Session.getTransport(Session.java:632) [junit] at javax.mail.Session.getTransport(Session.java:612) [junit] at javax.mail.Session.getTransport(Session.java:667) [junit] at javax.mail.Transport.send0(Transport.java:148) [junit] at javax.mail.Transport.send(Transport.java:80) [junit] at org.apache.commons.mail.Email.send(Email.java:818) [junit] ... 18 more Craig On 6/14/05, Ramiro Pereira de Magalhaes [EMAIL PROTECTED] wrote: I downloaded the latest source file from the commons-email from that source and ran a diff on the existing code from SVN repository. The only 2 differences were a compiled code existing on a bin/ folder and a build.properties file: both did not exist on the SVN repository. So, for development purposes we can assume that the repository to be used is the SVN http://svn.apache.org/repos/asf/jakarta/commons/proper/email/trunk instead of the CVS one? Ramiro Pereira de Magalhães Simon Kitching wrote: On Mon, 2005-06-13 at 20:37 +0530, Bindul Bhowmik wrote: Now, to my original problem: since brutus is out of action, where do I get nightly builds for commons-email (if it is getting built at all)? http://cvs.apache.org/builds/jakarta-commons/nightly/ Regards, Simon Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br - 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: What about webapp commons?
a Jakarta subproject is fine with me. I posted a proposal to the PMC list. Although, in retrospect, it should probably have been posted to [EMAIL PROTECTED] No need for it on the PMC list. Do we have enough PMC members here to vote (albeit on general@)? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site][email] Broken link on Jakarta site.
Ramiro, Thats what even I expected. Just that someone needs to update the email site to point to the correct location. ~Bindul On 6/14/05, Ramiro Pereira de Magalhaes [EMAIL PROTECTED] wrote: I downloaded the latest source file from the commons-email from that source and ran a diff on the existing code from SVN repository. The only 2 differences were a compiled code existing on a bin/ folder and a build.properties file: both did not exist on the SVN repository. So, for development purposes we can assume that the repository to be used is the SVN http://svn.apache.org/repos/asf/jakarta/commons/proper/email/trunk instead of the CVS one? Ramiro Pereira de Magalhães Simon Kitching wrote: On Mon, 2005-06-13 at 20:37 +0530, Bindul Bhowmik wrote: Now, to my original problem: since brutus is out of action, where do I get nightly builds for commons-email (if it is getting built at all)? http://cvs.apache.org/builds/jakarta-commons/nightly/ Regards, Simon Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br - 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]
svn commit: r190637 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpConnection.java
Author: olegk
Date: Tue Jun 14 11:43:13 2005
New Revision: 190637
URL: http://svn.apache.org/viewcvs?rev=190637view=rev
Log:
PR #35322 (Stale connection check does not work with IBM JSSE/JRE)
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpConnection.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpConnection.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpConnection.java?rev=190637r1=190636r2=190637view=diff
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpConnection.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpConnection.java
Tue Jun 14 11:43:13 2005
@@ -499,7 +499,7 @@
// assume the connection is not stale.
isStale = false;
try {
-if (inputStream.available() == 0) {
+if (inputStream.available() = 0) {
try {
socket.setSoTimeout(1);
inputStream.mark(1);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r190640 - /jakarta/commons/proper/httpclient/trunk/release_notes.txt
Author: olegk Date: Tue Jun 14 11:47:11 2005 New Revision: 190640 URL: http://svn.apache.org/viewcvs?rev=190640view=rev Log: PR #35322 Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/release_notes.txt?rev=190640r1=190639r2=190640view=diff == --- jakarta/commons/proper/httpclient/trunk/release_notes.txt (original) +++ jakarta/commons/proper/httpclient/trunk/release_notes.txt Tue Jun 14 11:47:11 2005 @@ -1,5 +1,8 @@ Changes since Release Candidate 2: + * 35322 - Stale connection check now correctly works with IBM JSSE/JRE 1.4.x + Contributed by Oleg Kalnichevski olegk at apache.org + * 35225 - Fixed a major problem with the browser compatibility policy leaking cookies to 3rd party domains (.mydomain.com - .notmydomain.com) Contributed by Oleg Kalnichevski olegk at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] What about live-update of config data?
Oliver Zeigermann wrote: On the other hand http://www.cenqua.com/clover/eg/jboss/report/org/jboss/util/TimedCachePolicy.html e.g. the JBoss people do not seem to care about not using java.util.Timer themselves ;) Yes, we can provide a Timer based and an event based strategy, and let the user pick the one that suits its needs. I see nothing wrong in using a background thread in a simple web application for example, as long as the thread is properly stopped when the application is undeployed or stopped. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35335] - [codec] Source tarball spews files all over the place
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=35335. 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=35335 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Source tarball of Commons |[codec] Source tarball spews |Codec spews files all over |files all over the place |the place | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] FW: [interest in] SummerOfCode2005 commons-math project
Uzhgorod wrote: When i was speaking about the Graph Library I meant the algorithmistsc implementation of a powerfull package for operations with graphs as mathematical object (graph - a set of vertexes, and a set of edges and a function which for two given vertexes returns true if they are connected ) There's already jakarta commons graph2, although it could certainly use a new contributor. You might also want to check freshmeat for various projects, a quick search for java based packages gives http://www.jgraph.com/ http://jgrapht.sourceforge.net/ http://openjgraph.sourceforge.net/ http://web.mit.edu/bshi/Public/nv2d/ GraphMapper (appears to be dead) There are various packages in other languages, including a very sophisticated C++ library. If you could afford it, I'd be rather interested in an OSI licensed Eclipse plugin similar to OptimalJ http://javacentral.compuware.com/pasta/ preferably with some clever UI which leverages the graphic representation of calls/dependencies for refactoring (I can hopefully point you to several papers for ideas). Or build a really good graphic page flow visualization for Cocoon's flow, also as Eclipse plugin. :-) Regards J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] FW: [interest in] SummerOfCode2005 commons-math project
Funny... Yet another definition we forgot about! Just to revert to my original post, i was proposing a function-plotter... which is not the same, indeed! paul Le 13 juin 05, à 23:22, Uzhgorod a écrit : Graphs, however, have an entirely different meaning in mathematics. When i was speaking about the Graph Library I meant the algorithmistsc implementation of a powerfull package for operations with graphs as mathematical object (graph - a set of vertexes, and a set of edges and a function which for two given vertexes returns true if they are connected ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] FW: [interest in] SummerOfCode2005 commons-math project
Paul Libbrecht wrote: There's a difference between a graph plotter and a chart plotter: the source data. To me a chart-plotter is fed by a bunch of numbers whereas a graph-plotter is fed by a bunch of functions. Ah, I see. Well, at least the screen shots from http://vofce.sourceforge.net/ look promising. Although I lived well with GnuPlot for this purpose until now. That characteristic is probably a very high requirement and is probably the reason why it's mostly only found in more general purpose computer-algebra-systems There are a few general purpose CAS written in Java available. (yacas et al, plunder sourceforge as usual). I'm not sure whether any of them has a plotting component. I'd still be very surprised if there isn't even an attempt at a java graph plotter on sourceforge. If not, ripping code off GnuPlot and/or GNU plotutils should be easy enough. :-) You might also ask here (not OSS) http://www.accesscom.com/~lillge/pgc/ or here http://www.pa.uky.edu/~phy211/graph_applets/plot_graph.html or here http://www.rddvs.com/RICHplot.html http://dsaka20.kushiro-ct.ac.jp/~yanto/java/surface/ http://sol.cs.wcu.edu/~par/grapher/GrapherUtility.html or a dozen or so of other websites (making plotting applets must be *really* fun!) HTH J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What about webapp commons?
I don't remember where is was largely rejected. I'm not arguing the validity of that statement, more than likely I missed a thread, but do you have a reference to such a thread you could point us at where that decision was made? -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, June 14, 2005 11:54 am, Oliver Zeigermann said: Oh, yes? Isn't a new subproject a bit too heavy weight? Anyway, if no one wants a commons web component it I will shut up. Is that really the case? Oliver On 6/14/05, Martin Cooper [EMAIL PROTECTED] wrote: On 6/13/05, Oliver Zeigermann [EMAIL PROTECTED] wrote: What are you thinking about? I thought it would not be required to get approval from PMC for a new commons component, is it? We're talking about a new Jakarta subproject, not a new Commons component. The latter was already largely rejected in earlier discussions. -- Martin Cooper Oliver On 6/14/05, Noel J. Bergman [EMAIL PROTECTED] wrote: i think that either martin or noel were going to head over to taglibs Wasn't me. Martin, possibly. It wouldn't take much to set this up, so why not propose this to the PMC and get it started? --- Noel - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35363] New: - DBCP BasicDataSource : setter for connectionProperties
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=35363. 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=35363 Summary: DBCP BasicDataSource : setter for connectionProperties Product: Commons Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Dbcp AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Adding a javabean-style setter for connectionProperties would certainly ease the configuration of a BasicDataSource within a Dependency Injection framework (eg Spring). see: http://article.gmane.org/gmane.comp.java.springframework.user/6501/ Thanks, Maarten -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35359] - [daemon] tomcat5.exe crashes
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=35359. 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=35359 [EMAIL PROTECTED] changed: What|Removed |Added Summary|tomcat5.exe crashes |[daemon] tomcat5.exe crashes -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jxpath ?
Ricardo, Very good questions. Do you believe such integration would be useful? The JAXP 1.3 spec allows for non-DOM object models to be supported, so I don't see a technical reason why we could not integrate JXPath with it. Do you see JXPath adding a compatibility module to map JAXP 1.3 APIs to JXPath APIs? Or, alternatively, should JXPath itself morph to adapt to the JAXP APIs. If we did that, would we preserve compatibility with JXPath 1.2, or go straight to JXPath 2? Or, better, skip a version and go to JXPath 3.0 to avoid confusion with XPath 2? Thank you, - Dmitri - Original Message - From: Ricardo [EMAIL PROTECTED] To: commons-dev@jakarta.apache.org Sent: Tuesday, June 14, 2005 11:52 AM Subject: jxpath ? hi, is this project dead? no need for integration with jaxp1.3? ciao ricky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] javadoc for prior releases.
I'll hold off committing my changes in light of these previous discussions. What is the status for a javadoc archive location? Would it be unreasonable to place javadoc in the java-repository? Brent -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 31, 2005 10:53 PM To: Jakarta Commons Developers List Subject: Re: [math] javadoc for prior releases. Brent, I like the outcome that you are after and mentioned on the site-dev list that I had been toying with patching the maven site plugin to optionally do exactly what you are describing. Others - Hen, Brett - responded that while it is good to have versioned javadoc available on the site, having the site build pull and regenerate it each time is not the best approach, since it never changes. Hen suggested that we might be better off establishing an apache javadoc repo where we can publish these things *once* and then link to them definitively. Hen, Brett pls chime in if I have misrepresented anything. Can we agree on a definitive location on minotaur/www where we can place versioned javadoc? How about jakarta.apache.org/commons/javadoc/component/release? I am personally OK with committing your changes if you have this working (including the SCM plugin dependency, as long as it works on both Windoz and linux) and changing to use the repo once we have that sorted. Phil On 5/31/05, Brent Worden [EMAIL PROTECTED] wrote: I've been working on automating the the generation of javadoc for prior releases for inclusion on the website. The change involves adding a post goal to the javadoc report goal. The post goal performs a checkout from the repository for a tagged version of the project. Javadoc is then executed on the checked out source, placing the generated HTML in a directory at the same level as the default javadoc. One downside to this change is that it requires using version 1.5-beta-3 of the Maven SCM Plugin. This is needed because prior versions do not support Subversion. If there are no objections, I will commit these changes. - 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: [math] javadoc for prior releases.
I'll hold off committing my changes in light of these previous discussions. What is the status for a javadoc archive location? Would it be unreasonable to place javadoc in the java-repository? Brent -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 31, 2005 10:53 PM To: Jakarta Commons Developers List Subject: Re: [math] javadoc for prior releases. Brent, I like the outcome that you are after and mentioned on the site-dev list that I had been toying with patching the maven site plugin to optionally do exactly what you are describing. Others - Hen, Brett - responded that while it is good to have versioned javadoc available on the site, having the site build pull and regenerate it each time is not the best approach, since it never changes. Hen suggested that we might be better off establishing an apache javadoc repo where we can publish these things *once* and then link to them definitively. Hen, Brett pls chime in if I have misrepresented anything. Can we agree on a definitive location on minotaur/www where we can place versioned javadoc? How about jakarta.apache.org/commons/javadoc/component/release? I am personally OK with committing your changes if you have this working (including the SCM plugin dependency, as long as it works on both Windoz and linux) and changing to use the repo once we have that sorted. Phil On 5/31/05, Brent Worden [EMAIL PROTECTED] wrote: I've been working on automating the the generation of javadoc for prior releases for inclusion on the website. The change involves adding a post goal to the javadoc report goal. The post goal performs a checkout from the repository for a tagged version of the project. Javadoc is then executed on the checked out source, placing the generated HTML in a directory at the same level as the default javadoc. One downside to this change is that it requires using version 1.5-beta-3 of the Maven SCM Plugin. This is needed because prior versions do not support Subversion. If there are no objections, I will commit these changes. - 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: [math] FW: [interest in] SummerOfCode2005 commons-math project
One thing you should know is the algorithms implemented in Numerical Recipes are copyrighted under terms that are incompatible with the Apache license. As such, commons-math can not contain any code derived from these routines. The precedent we have established is to not allow any code developed using NR as a source and instead find alternate citations for the algorithms detailed in NR. I would suggest you change your focus from the PRNG routines laid out in NR and research some other routines. Two that come to my mind that have been released under public domain terms are George Marsaglia's The Mother of All Random Number Generators and the Mersenne Twister. Brent Worden -Original Message- From: Uzhgorod [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 12:39 AM To: commons-dev@jakarta.apache.org Subject: Re: [math] FW: [interest in] SummerOfCode2005 commons-math project Hi! I spent some days exemining existing Math package, MathWishList and commons-dev Mailing List. Afterall, I want to represent at your disposal the project I am going to apply in the Summer Of Code 2005. PROJECT TITLE: Alternative Random Number Generators Implementation For Jakata Commons Math SYNOPSIS: Generation of completely unpredictable random numbers is impossible. But there is a wide range of good-working algorithms which allow to achieve more or less randomness. In the Jakarta-commons Wiki MathWishList there is a request for implementing alternative pseudo-random number generators (PRNG) http://wiki.apache.org/jakarta-commons/MathWishList. Considering this request I chose this project for the Google SummerOfCode 2005. DELIVERABLES: During the phase of the project I am going to implement next algorithms: I. Uniform Deviates PRNG: 1) Minimal random number generator of Park and Miller with Bays-Durham shuffle 2) Long period random number generator of L'Ecuyer with Bays-Durham shuffle 3) Knuth's subtractive Random Number Generation algorithm II. Binomial Distribution PRNG. PROJECT DESCRIPTION: As for the background for the project I chose the resourse Numerical Recipes: The Art Of Scientific Computing and the book of Knuth's The Art of Programming. I put before myself a goal to write: -- efficient -- fully documented algorithms. All the code will be written according to the Code Conventions for the Java Programming Language and documented with full javadoc included. In this project my logo is: To make GOOD rathen that to make MUCH. PROJECT SCHEDULE: I hope the algorithms I will implement will be included to the Jakarta Commons-Math subpackage Random. To achieve this goal I divide the project time into two periods: 1. Writing the code - lasting a month, but not more than August,3 2. Updating with the proposals from the Commons-Math Mailing List - lasting a month, but not more than September,1. Please, let me know what do you think about my project. Thanks, Rostyslav. - Original Message - From: Al Chou [EMAIL PROTECTED] To: commons-dev@jakarta.apache.org; [EMAIL PROTECTED] Sent: Saturday, June 11, 2005 2:38 AM Subject: [math] FW: [interest in] SummerOfCode2005 commons-math project Rostyslav, I'm sure we'd be happy to have you join the project. I've copied this message to the Jakarta commons-dev mailing list. Al -Original Message- From: Uzhgorod [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 3:16 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: SummerOfCode2005 commons-math project Rostyslav Slipetskyy Dobrianskogo St, 10/21, Uzhgorod, Ukraine. Hi! I'm a 3rd year student of Computer Science Dept in Kyiv-Mogyla University (Ukraine, Kyiv). I'm interested in the commons-math project of SummerOfCode2005. I am one of three members of a university ACM programming team. ACM (Association of Computer Machinery) is a world-famous organization which guides World Programming Contests. In September our team will fight for a grant to the world semi-finals. During numerous contests, I could see the advantages of well-written code libraries. Moreover, our team felt huge unsufficience of : -- efficiently implemented -- fully documented libraries which cover a wide range of different algorithmic areas. That is why we started to implement Graph Library, which was our student course paper at our university. The experience we gained, I really hope, will help me to do well if I have the opportunity to take part in the commons-math project. We wrote our Graph Library using C/C++, but personally I know Java syntax, and some percent of the contest problems during ACM contests we write on Java. Really a huge amount of ACM contest problems have in general mathematical background. That is why I think I obtain some mathematical skills. Frankly speaking, I have rather poor knowledge
RE: [math] FW: [interest in] SummerOfCode2005 commons-math project
One thing you should know is the algorithms implemented in Numerical Recipes are copyrighted under terms that are incompatible with the Apache license. As such, commons-math can not contain any code derived from these routines. The precedent we have established is to not allow any code developed using NR as a source and instead find alternate citations for the algorithms detailed in NR. I would suggest you change your focus from the PRNG routines laid out in NR and research some other routines. Two that come to my mind that have been released under public domain terms are George Marsaglia's The Mother of All Random Number Generators and the Mersenne Twister. Brent Worden -Original Message- From: Uzhgorod [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 12:39 AM To: commons-dev@jakarta.apache.org Subject: Re: [math] FW: [interest in] SummerOfCode2005 commons-math project Hi! I spent some days exemining existing Math package, MathWishList and commons-dev Mailing List. Afterall, I want to represent at your disposal the project I am going to apply in the Summer Of Code 2005. PROJECT TITLE: Alternative Random Number Generators Implementation For Jakata Commons Math SYNOPSIS: Generation of completely unpredictable random numbers is impossible. But there is a wide range of good-working algorithms which allow to achieve more or less randomness. In the Jakarta-commons Wiki MathWishList there is a request for implementing alternative pseudo-random number generators (PRNG) http://wiki.apache.org/jakarta-commons/MathWishList. Considering this request I chose this project for the Google SummerOfCode 2005. DELIVERABLES: During the phase of the project I am going to implement next algorithms: I. Uniform Deviates PRNG: 1) Minimal random number generator of Park and Miller with Bays-Durham shuffle 2) Long period random number generator of L'Ecuyer with Bays-Durham shuffle 3) Knuth's subtractive Random Number Generation algorithm II. Binomial Distribution PRNG. PROJECT DESCRIPTION: As for the background for the project I chose the resourse Numerical Recipes: The Art Of Scientific Computing and the book of Knuth's The Art of Programming. I put before myself a goal to write: -- efficient -- fully documented algorithms. All the code will be written according to the Code Conventions for the Java Programming Language and documented with full javadoc included. In this project my logo is: To make GOOD rathen that to make MUCH. PROJECT SCHEDULE: I hope the algorithms I will implement will be included to the Jakarta Commons-Math subpackage Random. To achieve this goal I divide the project time into two periods: 1. Writing the code - lasting a month, but not more than August,3 2. Updating with the proposals from the Commons-Math Mailing List - lasting a month, but not more than September,1. Please, let me know what do you think about my project. Thanks, Rostyslav. - Original Message - From: Al Chou [EMAIL PROTECTED] To: commons-dev@jakarta.apache.org; [EMAIL PROTECTED] Sent: Saturday, June 11, 2005 2:38 AM Subject: [math] FW: [interest in] SummerOfCode2005 commons-math project Rostyslav, I'm sure we'd be happy to have you join the project. I've copied this message to the Jakarta commons-dev mailing list. Al -Original Message- From: Uzhgorod [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 3:16 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: SummerOfCode2005 commons-math project Rostyslav Slipetskyy Dobrianskogo St, 10/21, Uzhgorod, Ukraine. Hi! I'm a 3rd year student of Computer Science Dept in Kyiv-Mogyla University (Ukraine, Kyiv). I'm interested in the commons-math project of SummerOfCode2005. I am one of three members of a university ACM programming team. ACM (Association of Computer Machinery) is a world-famous organization which guides World Programming Contests. In September our team will fight for a grant to the world semi-finals. During numerous contests, I could see the advantages of well-written code libraries. Moreover, our team felt huge unsufficience of : -- efficiently implemented -- fully documented libraries which cover a wide range of different algorithmic areas. That is why we started to implement Graph Library, which was our student course paper at our university. The experience we gained, I really hope, will help me to do well if I have the opportunity to take part in the commons-math project. We wrote our Graph Library using C/C++, but personally I know Java syntax, and some percent of the contest problems during ACM contests we write on Java. Really a huge amount of ACM contest problems have in general mathematical background. That is why I think I obtain some mathematical skills. Frankly speaking, I have rather poor knowledge
DO NOT REPLY [Bug 35366] - [lang][patch] Implementation of escape/unescapeHtml methods with Writer
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=35366. 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=35366 --- Additional Comments From [EMAIL PROTECTED] 2005-06-15 06:03 --- Created an attachment (id=15412) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15412action=view) Patch for the 'Entities.java' file. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35366] - [lang][patch] Implementation of escape/unescapeHtml methods with Writer
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=35366. 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=35366 --- Additional Comments From [EMAIL PROTECTED] 2005-06-15 06:03 --- Created an attachment (id=15413) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15413action=view) Patch for the 'StringEscapeUtils.java' file. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35366] - [lang][patch] Implementation of escape/unescapeHtml methods with Writer
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=35366. 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=35366 --- Additional Comments From [EMAIL PROTECTED] 2005-06-15 06:04 --- Created an attachment (id=15414) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15414action=view) Patch for the 'StringEscapeUtilsTest.java' file. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r190706 - in /jakarta/commons/proper/net/trunk/src: java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java test/org/apache/commons/net/ftp/parser/NTFTPEntryParserTest.java
Author: scohen
Date: Tue Jun 14 21:17:03 2005
New Revision: 190706
URL: http://svn.apache.org/viewcvs?rev=190706view=rev
Log:
Fix defect 35346. Patch submitted by Sergey Smimov
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/NTFTPEntryParserTest.java
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java?rev=190706r1=190705r2=190706view=diff
==
---
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
(original)
+++
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
Tue Jun 14 21:17:03 2005
@@ -39,8 +39,7 @@
*/
private static final String REGEX =
(\\S+)\\s+(\\S+)\\s+
-+ (DIR)?\\s*
-+ ([0-9]+)?\\s+
++ (?:(DIR)|([0-9]+))\\s+
+ (\\S.*);
/**
Modified:
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/NTFTPEntryParserTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/NTFTPEntryParserTest.java?rev=190706r1=190705r2=190706view=diff
==
---
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/NTFTPEntryParserTest.java
(original)
+++
jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/NTFTPEntryParserTest.java
Tue Jun 14 21:17:03 2005
@@ -199,4 +199,14 @@
FTPFile f = getParser().parseFTPEntry(directoryBeginningWithNumber);
assertEquals(name, 123xyz, f.getName());
}
+
+public void testDirectoryBeginningWithNumberFollowedBySpaces() throws
Exception
+{
+FTPFile f = getParser().parseFTPEntry(12-03-96 06:38AM DIR
123 xyz);
+assertEquals(name, 123 xyz, f.getName());
+f = getParser().parseFTPEntry(12-03-96 06:38AM DIR
123 abc xyz);
+assertNotNull(f);
+assertEquals(name, 123 abc xyz, f.getName());
+}
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35346] - [net] NTFTPEntryParser parses directory names starting with a number followed by space incorrectly.
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=35346. 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=35346 --- Additional Comments From [EMAIL PROTECTED] 2005-06-15 06:19 --- Actually, there was nothing at all wrong with your patch. The problem I had thought existed did not, in fact, exist. I should have read the regular expression more carefully. I have committed your patch verbatim except that I added one more test assert to prove that the scenario I had envisioned was not a problem. Thanks again for your patch. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Someone on commons-email?
On Tue, 2005-06-14 at 10:24 -0300, Ramiro Pereira de Magalhaes wrote: Well, that's quite bad... :( Isn't anyone with managing powers interested in pushing email towards a release? I can checkout this project and start fixing anything by myself as (if) needed but this way I'll be working alone and in a branch that will probably be thrown away when the project start moving again... Unfortunately it looks like no committer here has the spare time or interest in email to help you out. And unfortunately that includes me too. You are perfectly entitled to take a copy of the code and start a project on sourceforge (or elsewhere) as long as the license is complied with (the easiest way to do that is just continue to use the APL 2.0 license). If you do this, then I would be happy to see a note on the email project wiki pointing to the sourceforge branch. If the sourceforge fork is successful (builds a community of a few developers, has happy users) then there is every chance that the maintainers of that project (esp. you) might be invited to become commons committers and merge the code back in here -- if you wanted to. Or as you say you could just maintain a private copy. That's still an improvement over starting from nothing. It's always a shame to see a commons project die because the original committers went away when users actively want to become developers (not to mention bad for jakarta's reputation). But unfortunately it also takes some time and effort from existing commons committers to check that potential contributors are actually people we do want to give commit rights to and to allow to perform releases in Apache's name. And unlike some open-source projects, there aren't any people paid to work on commons AFAIK. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] FIXED commons-email tests for nightly builds script
Craig, after having some fight with the commons-email project I discovered the problem that breaks it: you're compiling the project with the javamail_path/lib/mailapi.jar package instead of javamail_path/mail.jar (check the build.properties file). The first one does not have the necessary Providers (in this case the SMTP provider) required by Dumbster, the fake mail server used for testing. The other one does. Once I fixed this, all tests passed. My source of information was http://www.javaworld.com/javaworld/jw-10-2001/jw-1026-javamail.html, quoted below: The |mailapi.jar| file contains the core API classes, while the |pop3.jar| and |smtp.jar| files contain the provider implementations for the respective mail protocols. (We won't use the |imap.jar| file in this article.) Think of the provider implementations as similar to JDBC (Java Database Connectivity) drivers, but for messaging systems rather than databases. As for the |mail.jar| file, it contains each of the above jar files, so you could restrict your classpath to just the |mail.jar| and |activation.jar| files. I hope this helps make things move again... Ramiro Pereira de Magalhães Craig McClanahan wrote: SVN is the current source repository for all Jakarta Commons projects (proper and sandbox). The CVS repository was frozen at the time that migration to SVN took place, and is in read only state as a convenience for people that still had references to it. As for nightly builds, I run them for nearly all the commons packages ... but cannot for email because the developers haven't provided an Ant build.xml script where ant clean dist succeeds -- it compiles ok, but fails in the unit tests, and the script is set up such that this fails the build. The portion of the build output documenting this failure: [junit] Testsuite: org.apache.commons.mail.HtmlEmailTest [junit] Tests run: 6, Failures: 1, Errors: 1, Time elapsed: 3.807 sec [junit] Testcase: testGetSetTextMsg took 0.154 sec [junit] Testcase: testGetSetHtmlMsg took 0 sec [junit] Testcase: testGetSetMsg took 0.001 sec [junit] Testcase: testEmbed took 0.678 sec [junit] Testcase: testSend took 2.24 sec [junit] FAILED [junit] Unexpected exception thrown [junit] junit.framework.AssertionFailedError: Unexpected exception thrown [junit] at org.apache.commons.mail.HtmlEmailTest.testSend(HtmlEmailTest.java:302) [junit] Testcase: testSend2 took 0.694 sec [junit] Caused an ERROR [junit] javax.mail.NoSuchProviderException: smtp [junit] org.apache.commons.mail.EmailException: javax.mail.NoSuchProviderException: smtp [junit] at org.apache.commons.mail.Email.send(Email.java:822) [junit] at org.apache.commons.mail.MultiPartEmail.send(MultiPartEmail.java:224) [junit] at org.apache.commons.mail.HtmlEmail.send(HtmlEmail.java:227) [junit] at org.apache.commons.mail.HtmlEmailTest.testSend2(HtmlEmailTest.java:380) [junit] Caused by: javax.mail.NoSuchProviderException: smtp [junit] at javax.mail.Session.getService(Session.java:750) [junit] at javax.mail.Session.getTransport(Session.java:689) [junit] at javax.mail.Session.getTransport(Session.java:632) [junit] at javax.mail.Session.getTransport(Session.java:612) [junit] at javax.mail.Session.getTransport(Session.java:667) [junit] at javax.mail.Transport.send0(Transport.java:148) [junit] at javax.mail.Transport.send(Transport.java:80) [junit] at org.apache.commons.mail.Email.send(Email.java:818) [junit] ... 18 more Craig On 6/14/05, Ramiro Pereira de Magalhaes [EMAIL PROTECTED] wrote: I downloaded the latest source file from the commons-email from that source and ran a diff on the existing code from SVN repository. The only 2 differences were a compiled code existing on a bin/ folder and a build.properties file: both did not exist on the SVN repository. So, for development purposes we can assume that the repository to be used is the SVN http://svn.apache.org/repos/asf/jakarta/commons/proper/email/trunk instead of the CVS one? Ramiro Pereira de Magalhães Simon Kitching wrote: On Mon, 2005-06-13 at 20:37 +0530, Bindul Bhowmik wrote: Now, to my original problem: since brutus is out of action, where do I get nightly builds for commons-email (if it is getting built at all)? http://cvs.apache.org/builds/jakarta-commons/nightly/ Regards, Simon Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br - 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: [email] FIXED commons-email tests for nightly builds script
On Wed, 2005-06-15 at 01:31 -0300, Ramiro Pereira de Magalhaes wrote: Craig, after having some fight with the commons-email project I discovered the problem that breaks it: you're compiling the project with the javamail_path/lib/mailapi.jar package instead of javamail_path/mail.jar (check the build.properties file). The first one does not have the necessary Providers (in this case the SMTP provider) required by Dumbster, the fake mail server used for testing. The other one does. Once I fixed this, all tests passed. My source of information was http://www.javaworld.com/javaworld/jw-10-2001/jw-1026-javamail.html, quoted below: The |mailapi.jar| file contains the core API classes, while the |pop3.jar| and |smtp.jar| files contain the provider implementations for the respective mail protocols. (We won't use the |imap.jar| file in this article.) Think of the provider implementations as similar to JDBC (Java Database Connectivity) drivers, but for messaging systems rather than databases. As for the |mail.jar| file, it contains each of the above jar files, so you could restrict your classpath to just the |mail.jar| and |activation.jar| files. I hope this helps make things move again... Sorry, Ramiro, but to use an old expression: I think you're beating a dead horse. Craig kindly runs the nightly builds for commons projects, but isn't an email developer. And while your fix may well be right, no-one should make that change without spending some time thinking about what the implications are, and why it wasn't done that way before. And no-one seems to have the enthusiasm or time to do that. In any case, that would just make the nightly builds work again. That isn't much use when there are no changes being applied to the project source. Unless an existing commons committer is willing to volunteer their time to work on this for no particular reason, or a committer happens to *need* the email project in some of their other work, or some non-committer with a good open-source track record comes along (someone we could feel comfortable with granting committer access to immediately) there just isn't likely to be any progress on commons-email here. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] FIXED commons-email tests for nightly builds script
I think it's a bit pessimistic to say it's a dead horse. I should have some free time for email later this week On 6/15/05, Simon Kitching [EMAIL PROTECTED] wrote: On Wed, 2005-06-15 at 01:31 -0300, Ramiro Pereira de Magalhaes wrote: Craig, after having some fight with the commons-email project I discovered the problem that breaks it: you're compiling the project with the javamail_path/lib/mailapi.jar package instead of javamail_path/mail.jar (check the build.properties file). The first one does not have the necessary Providers (in this case the SMTP provider) required by Dumbster, the fake mail server used for testing. The other one does. Once I fixed this, all tests passed. My source of information was http://www.javaworld.com/javaworld/jw-10-2001/jw-1026-javamail.html, quoted below: The |mailapi.jar| file contains the core API classes, while the |pop3.jar| and |smtp.jar| files contain the provider implementations for the respective mail protocols. (We won't use the |imap.jar| file in this article.) Think of the provider implementations as similar to JDBC (Java Database Connectivity) drivers, but for messaging systems rather than databases. As for the |mail.jar| file, it contains each of the above jar files, so you could restrict your classpath to just the |mail.jar| and |activation.jar| files. I hope this helps make things move again... Sorry, Ramiro, but to use an old expression: I think you're beating a dead horse. Craig kindly runs the nightly builds for commons projects, but isn't an email developer. And while your fix may well be right, no-one should make that change without spending some time thinking about what the implications are, and why it wasn't done that way before. And no-one seems to have the enthusiasm or time to do that. In any case, that would just make the nightly builds work again. That isn't much use when there are no changes being applied to the project source. Unless an existing commons committer is willing to volunteer their time to work on this for no particular reason, or a committer happens to *need* the email project in some of their other work, or some non-committer with a good open-source track record comes along (someone we could feel comfortable with granting committer access to immediately) there just isn't likely to be any progress on commons-email here. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Someone on commons-email?
Don't count email as dead yet.see my email on the other thread. On 6/15/05, Simon Kitching [EMAIL PROTECTED] wrote: On Tue, 2005-06-14 at 10:24 -0300, Ramiro Pereira de Magalhaes wrote: Well, that's quite bad... :( Isn't anyone with managing powers interested in pushing email towards a release? I can checkout this project and start fixing anything by myself as (if) needed but this way I'll be working alone and in a branch that will probably be thrown away when the project start moving again... Unfortunately it looks like no committer here has the spare time or interest in email to help you out. And unfortunately that includes me too. You are perfectly entitled to take a copy of the code and start a project on sourceforge (or elsewhere) as long as the license is complied with (the easiest way to do that is just continue to use the APL 2.0 license). If you do this, then I would be happy to see a note on the email project wiki pointing to the sourceforge branch. If the sourceforge fork is successful (builds a community of a few developers, has happy users) then there is every chance that the maintainers of that project (esp. you) might be invited to become commons committers and merge the code back in here -- if you wanted to. Or as you say you could just maintain a private copy. That's still an improvement over starting from nothing. It's always a shame to see a commons project die because the original committers went away when users actively want to become developers (not to mention bad for jakarta's reputation). But unfortunately it also takes some time and effort from existing commons committers to check that potential contributors are actually people we do want to give commit rights to and to allow to perform releases in Apache's name. And unlike some open-source projects, there aren't any people paid to work on commons AFAIK. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] FIXED commons-email tests for nightly builds script
On Wed, 2005-06-15 at 15:18 +1000, Dion Gillard wrote: I think it's a bit pessimistic to say it's a dead horse. I should have some free time for email later this week Ah .. sorry, Dion. Good to know you're still interested. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
