DO NOT REPLY [Bug 24247] New: - signal handling on Solaris 5.8
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24247. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24247 signal handling on Solaris 5.8 Summary: signal handling on Solaris 5.8 Product: Commons Version: 1.0 Alpha Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Daemon AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] in the handler() function (jsvc-unix.c) is after catching the relevant signal the flag stopping set and the handler tries to call itself once again (over the func.pointer handler_xxx). In this case, the stop/restart daemon doesn't work correctly on Solaris, and ends with a status 143 (129) instead of 0 (123), without calling a java_stop()/java_destroy(). If those duplicate calls from handler are removed, the daemon stop/restart works fine and correct. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons-logging classloading (continued)
Hello,
i currently use Tomcat 4.1.27 bundled with commons-logging 1.0.3. My own webapp i'm
working on also uses commons-logging, so i include a copy of the jar file into the
WEB-INF/lib directory to be protable to other servlet containers that does not include
the commons-logging package. I found some discussions in the mail archive that is
about commons-logging and its class loading strategy. But as i could not found an
anwser to my problem, i post my problem here again, hoping to get a hint for a
solution (or maybe to settle on a new consens).
The problem is, that when tomcat wants to anser a HTTPS request it instantiates a
Http11ConnectionHandler which processes the connection.
The Http11ConnectionHandler instance itself instantiates a JSSE14Support class which
itself instantiates a org.apache.commons.logging.Log implementation class. Because the
thread that runs the Http11ConnectionHandler has the WebappClassloader of my web
application as its
context class loader (which ist used by commons-logging to load the Log implementation
(logClass)), BUT the org.apache.commons.logging.Log interface itself was loaded from
the Common StandardClassLoader, the predicate in LogFactoryImpl.getLogConstructor()
(!Log.class.isAssignableFrom(logClass))
is false, so that LogFactoryImpl.getLogConstructor() throws a
LogConfigurationException. Because both classes are loaded from different
classloaders.
IMHO what commons-logging MUST ensure to work correctly is, that the logClass is
loaded from the same classloader than the Log.class is and this is not guaranteed by
the current implementation! For example
protected static ClassLoader getContextClassLoader()
throws LogConfigurationException
{
return Log.class.getClassLoader();
}
would do. BUT to keep the current implementation what about changing
LogFactoryImpl.getLogConstructor(), so that the correct predicate is evaluated?
protected Constructor getLogConstructor()
throws LogConfigurationException {
...
logClass = loadClass(logClassName);
___logClass___ = loadClass(org.apache.commons.logging.Log)
// something like this...
if (logClass == null) {
throw new LogConfigurationException
(No suitable Log implementation for + logClassName);
}
if (!___logClass___.class.isAssignableFrom(logClass)) {
...
}
...
}
The problem with the current implementation is, that commons-logging can not rely on
the fact that the threads current context class loader is the classloader that the
class (like the JSSE14Support above) wants to get its logging implementation from!!!
Is there a chance to get a consens on that, or at least to think about changing the
current implemetation making it more reliable ?
Kindly regards,
Norbert.
--
__
Sign-up for your own personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] new list for cvs commits? (was Re: commons-configuration)
I think the mailing list guidelines at http://jakarta.apache.org/site/mail2.html#Commons could include at least a warning like some other lists at Jakarta. Something like Subscribers to this list will also get notices of every CVS checkin of new or changed code modules. Emmanuel smime.p7s Description: S/MIME Cryptographic Signature
RE: commons-logging classloading (continued)
Well put Norbert.
I think that since classloading and threads are such complex
issues there should be a way to not use the pattern
of loading the implementation from thread's context classloader.
(Hint to Craig :)
- rami
-Original Message-
From: Norbert Klose [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: commons-logging classloading (continued)
Hello,
i currently use Tomcat 4.1.27 bundled with commons-logging
1.0.3. My own webapp i'm working on also uses commons-logging,
so i include a copy of the jar file into the WEB-INF/lib
directory to be protable to other servlet containers that does
not include the commons-logging package. I found some
discussions in the mail archive that is about commons-logging
and its class loading strategy. But as i could not found an
anwser to my problem, i post my problem here again, hoping to
get a hint for a solution (or maybe to settle on a new consens).
The problem is, that when tomcat wants to anser a HTTPS
request it instantiates a Http11ConnectionHandler which
processes the connection.
The Http11ConnectionHandler instance itself instantiates a
JSSE14Support class which itself instantiates a
org.apache.commons.logging.Log implementation class. Because
the thread that runs the Http11ConnectionHandler has the
WebappClassloader of my web application as its
context class loader (which ist used by commons-logging to
load the Log implementation (logClass)), BUT the
org.apache.commons.logging.Log interface itself was loaded
from the Common StandardClassLoader, the predicate in
LogFactoryImpl.getLogConstructor()
(!Log.class.isAssignableFrom(logClass))
is false, so that LogFactoryImpl.getLogConstructor() throws a
LogConfigurationException. Because both classes are loaded
from different classloaders.
IMHO what commons-logging MUST ensure to work correctly is,
that the logClass is loaded from the same classloader than the
Log.class is and this is not guaranteed by the current
implementation! For example
protected static ClassLoader getContextClassLoader()
throws LogConfigurationException
{
return Log.class.getClassLoader();
}
would do. BUT to keep the current implementation what about
changing LogFactoryImpl.getLogConstructor(), so that the
correct predicate is evaluated?
protected Constructor getLogConstructor()
throws LogConfigurationException {
...
logClass = loadClass(logClassName);
___logClass___ =
loadClass(org.apache.commons.logging.Log)//
something like this...
if (logClass == null) {
throw new LogConfigurationException
(No suitable Log implementation for +
logClassName);
}
if (!___logClass___.class.isAssignableFrom(logClass)) {
...
}
...
}
The problem with the current implementation is, that
commons-logging can not rely on the fact that the threads
current context class loader is the classloader that the class
(like the JSSE14Support above) wants to get its logging
implementation from!!!
Is there a chance to get a consens on that, or at least to
think about changing the current implemetation making it more
reliable ?
Kindly regards,
Norbert.
--
__
Sign-up for your own personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
CareerBuilder.com has over 400,000 jobs. Be smarter about your
job search
http://corp.mail.com/careers
-
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 22304] - FTPClient.listFiles intermittently locks up
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22304. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22304 FTPClient.listFiles intermittently locks up --- Additional Comments From [EMAIL PROTECTED] 2003-10-30 10:42 --- I'v made a mistake. After I use method setDataTimeout, listFiles never blocks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] new list for cvs commits? (was Re: commons-configuration)
It seems some prefer to keep the commit messages in the list, and others prefer a clean list with just the discussions. So what about this : - commons-dev : discussions + cvs messages - commons-cvs : only the cvs messages - commons-talk: only the discussions or maybe easier to set up : - commons-dev : only the discussions - commons-cvs : only the cvs messages - commons-commiters : discussions + cvs messages (this list is subscribed to commons-dev and commons-cvs with a Reply-To header set to commons-dev) This would suit to everyone. Emmanuel smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] Promote DbUtils to Commons Proper
+1 Quoting David Graham [EMAIL PROTECTED]: DbUtils exhibits all of the qualities of a component that should be in Commons proper: - It's small and focused. - It's API is well defined - It has a group of existing Jakarta committers providing code, ideas, and support. - It has good unit test coverage. It has also been tested in real world database applications. - It has automated nightly builds, website, and Maven all working - It has incubated in the sandbox for long enough to become stable DbUtils is a mature component that should move to Commons proper so it can be released to the public. Here's my +1. The website has additional information: http://jakarta.apache.org/commons/sandbox/dbutils/index.html Here's the component proposal for reference: (0) Rationale Correct JDBC coding is time consuming and error prone. Many JDBC coding tasks can be simplified with a small helper library that factors out the mundane resource cleanup steps. DbUtils is focused on providing such a library without any heavyweight framework surrounding it. (1) Scope of the Package This proposal is to create a package of Java utility classes for various types of JDBC related activity. DbUtils will not be an OO representation of database objects nor will it be an Object/Relational framework. It will be a lightweight JDBC library that helps developers write correct database code. (1.5) Interaction With Other Packages DBUtils relies only on standard Java 1.2 (or later) APIs for production deployment. It utilizes the JUnit testing framework for developing and executing unit tests, but this is of interest only to developers of the component. Being dependent on Java 1.2 means that this code is expected to be of JDBC 2.0 level. No external configuration files are utilized. (2) Initial Source of the Package Potential source code for this package will come from the initial committers' personal libraries. The proposed package name for the new component is codeorg.apache.commons.dbutils/code. (3) Required Jakarta-Commons Resources CVS Repository - New directory dbutils in the jakarta-commons CVS repository. Mailing List - Discussions will take place on the general [EMAIL PROTECTED] mailing list. To help list subscribers identify messages of interest, it is suggested that the message subject of messages about this component be prefixed with [dbutils]. Bugzilla - New component DBUtils under the Commons product category, with appropriate version identifiers as needed. (4) Initial Committers The initial committers on the DBUtils component shall be: Henri Yandell Steven Caswell Juozas Baliuka David Graham __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Steven Caswell (Hobbit name Mungo Knotwise of Michel Delving) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: commons-logging classloading (continued)
It's a kind of growing pain with the success of Commons.
Some servers have some commons jars while others not. In the
application you always include jars you needed. At the end of
day, situation like that seems inevitable, not just logging,
not mention the version problem.
Is it possible some standard be set or a classloader component
in Commons?
- sean
--- Ojares Rami EINT [EMAIL PROTECTED] wrote:
Well put Norbert.
I think that since classloading and threads are such complex
issues there should be a way to not use the pattern
of loading the implementation from thread's context classloader.
(Hint to Craig :)
- rami
-Original Message-
From: Norbert Klose [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: commons-logging classloading (continued)
Hello,
i currently use Tomcat 4.1.27 bundled with commons-logging
1.0.3. My own webapp i'm working on also uses commons-logging,
so i include a copy of the jar file into the WEB-INF/lib
directory to be protable to other servlet containers that does
not include the commons-logging package. I found some
discussions in the mail archive that is about commons-logging
and its class loading strategy. But as i could not found an
anwser to my problem, i post my problem here again, hoping to
get a hint for a solution (or maybe to settle on a new consens).
The problem is, that when tomcat wants to anser a HTTPS
request it instantiates a Http11ConnectionHandler which
processes the connection.
The Http11ConnectionHandler instance itself instantiates a
JSSE14Support class which itself instantiates a
org.apache.commons.logging.Log implementation class. Because
the thread that runs the Http11ConnectionHandler has the
WebappClassloader of my web application as its
context class loader (which ist used by commons-logging to
load the Log implementation (logClass)), BUT the
org.apache.commons.logging.Log interface itself was loaded
from the Common StandardClassLoader, the predicate in
LogFactoryImpl.getLogConstructor()
(!Log.class.isAssignableFrom(logClass))
is false, so that LogFactoryImpl.getLogConstructor() throws a
LogConfigurationException. Because both classes are loaded
from different classloaders.
IMHO what commons-logging MUST ensure to work correctly is,
that the logClass is loaded from the same classloader than the
Log.class is and this is not guaranteed by the current
implementation! For example
protected static ClassLoader getContextClassLoader()
throws LogConfigurationException
{
return Log.class.getClassLoader();
}
would do. BUT to keep the current implementation what about
changing LogFactoryImpl.getLogConstructor(), so that the
correct predicate is evaluated?
protected Constructor getLogConstructor()
throws LogConfigurationException {
...
logClass = loadClass(logClassName);
___logClass___ =
loadClass(org.apache.commons.logging.Log) //
something like this...
if (logClass == null) {
throw new LogConfigurationException
(No suitable Log implementation for +
logClassName);
}
if (!___logClass___.class.isAssignableFrom(logClass)) {
...
}
...
}
The problem with the current implementation is, that
commons-logging can not rely on the fact that the threads
current context class loader is the classloader that the class
(like the JSSE14Support above) wants to get its logging
implementation from!!!
Is there a chance to get a consens on that, or at least to
think about changing the current implemetation making it more
reliable ?
Kindly regards,
Norbert.
--
__
Sign-up for your own personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
CareerBuilder.com has over 400,000 jobs. Be smarter about your
job search
http://corp.mail.com/careers
-
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 you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote DbUtils to Commons Proper
David Graham wrote: DbUtils exhibits all of the qualities of a component that should be in Commons proper: - It's small and focused. - It's API is well defined - It has a group of existing Jakarta committers providing code, ideas, and support. - It has good unit test coverage. It has also been tested in real world database applications. - It has automated nightly builds, website, and Maven all working - It has incubated in the sandbox for long enough to become stable DbUtils is a mature component that should move to Commons proper so it can be released to the public. Here's my +1. Looks like this is likely to pass. Are there any committers on dbutils that have karma for the jakarta-commons-sandbox repository but don't have karma on jakarta-commons itself? If so, I can clean that up when the code gets promoted as well. Craig The website has additional information: http://jakarta.apache.org/commons/sandbox/dbutils/index.html Here's the component proposal for reference: (0) Rationale Correct JDBC coding is time consuming and error prone. Many JDBC coding tasks can be simplified with a small helper library that factors out the mundane resource cleanup steps. DbUtils is focused on providing such a library without any heavyweight framework surrounding it. (1) Scope of the Package This proposal is to create a package of Java utility classes for various types of JDBC related activity. DbUtils will not be an OO representation of database objects nor will it be an Object/Relational framework. It will be a lightweight JDBC library that helps developers write correct database code. (1.5) Interaction With Other Packages DBUtils relies only on standard Java 1.2 (or later) APIs for production deployment. It utilizes the JUnit testing framework for developing and executing unit tests, but this is of interest only to developers of the component. Being dependent on Java 1.2 means that this code is expected to be of JDBC 2.0 level. No external configuration files are utilized. (2) Initial Source of the Package Potential source code for this package will come from the initial committers' personal libraries. The proposed package name for the new component is codeorg.apache.commons.dbutils/code. (3) Required Jakarta-Commons Resources CVS Repository - New directory dbutils in the jakarta-commons CVS repository. Mailing List - Discussions will take place on the general [EMAIL PROTECTED] mailing list. To help list subscribers identify messages of interest, it is suggested that the message subject of messages about this component be prefixed with [dbutils]. Bugzilla - New component DBUtils under the Commons product category, with appropriate version identifiers as needed. (4) Initial Committers The initial committers on the DBUtils component shall be: Henri Yandell Steven Caswell Juozas Baliuka David Graham __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - 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: [VOTE] Promote DbUtils to Commons Proper
--- Craig R. McClanahan [EMAIL PROTECTED] wrote: David Graham wrote: DbUtils exhibits all of the qualities of a component that should be in Commons proper: - It's small and focused. - It's API is well defined - It has a group of existing Jakarta committers providing code, ideas, and support. - It has good unit test coverage. It has also been tested in real world database applications. - It has automated nightly builds, website, and Maven all working - It has incubated in the sandbox for long enough to become stable DbUtils is a mature component that should move to Commons proper so it can be released to the public. Here's my +1. Looks like this is likely to pass. Are there any committers on dbutils that have karma for the jakarta-commons-sandbox repository but don't have karma on jakarta-commons itself? If so, I can clean that up when the code gets promoted as well. I did a quick check of the CVS avail file and it looks like all DbUtils folks have karma in commons and sandbox. David Craig The website has additional information: http://jakarta.apache.org/commons/sandbox/dbutils/index.html Here's the component proposal for reference: (0) Rationale Correct JDBC coding is time consuming and error prone. Many JDBC coding tasks can be simplified with a small helper library that factors out the mundane resource cleanup steps. DbUtils is focused on providing such a library without any heavyweight framework surrounding it. (1) Scope of the Package This proposal is to create a package of Java utility classes for various types of JDBC related activity. DbUtils will not be an OO representation of database objects nor will it be an Object/Relational framework. It will be a lightweight JDBC library that helps developers write correct database code. (1.5) Interaction With Other Packages DBUtils relies only on standard Java 1.2 (or later) APIs for production deployment. It utilizes the JUnit testing framework for developing and executing unit tests, but this is of interest only to developers of the component. Being dependent on Java 1.2 means that this code is expected to be of JDBC 2.0 level. No external configuration files are utilized. (2) Initial Source of the Package Potential source code for this package will come from the initial committers' personal libraries. The proposed package name for the new component is codeorg.apache.commons.dbutils/code. (3) Required Jakarta-Commons Resources CVS Repository - New directory dbutils in the jakarta-commons CVS repository. Mailing List - Discussions will take place on the general [EMAIL PROTECTED] mailing list. To help list subscribers identify messages of interest, it is suggested that the message subject of messages about this component be prefixed with [dbutils]. Bugzilla - New component DBUtils under the Commons product category, with appropriate version identifiers as needed. (4) Initial Committers The initial committers on the DBUtils component shall be: Henri Yandell Steven Caswell Juozas Baliuka David Graham __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - 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 you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Complex implementation
Hi It has not been mentioned in this thread, but Mark Hale's complex implementation is still being maintained over at sourceforge: http://sourceforge.net/projects/jsci I might also have some complex number code/knowledge/experience but unfortunately not much time. Roger Endo -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 7:39 PM To: Mark R. Diggory Cc: Jakarta Commons Developers List Subject: Re: [math] Complex implementation Mark R. Diggory wrote: I think the hesitancy was simply out of manpower and in interest of getting out a release soon. I'm somewhat surprised that Phil's Complex implementation didn't get added if he had already written it (which I had missed in the thread). Phil, Are you willing to donate your Complex number implementation to the Math library? Not in its current state. The outline described here: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=15msgNo=28132 is what I was working on. This represents a refactoring and significant extension of some old code of mine. Most importantly, my classes are neither C9x compliant nor numerically sound (the reason that I did not include them in the initial submission) and they don't implement the transcendental functions. Given that the outline is for a fairly unsophisticated implementation using static utility classes for complex operations, I doubt that the structure itself would have much value to commons-math today. Therefore, it is probably best to start from scratch (or from VNI, it they are willing), designing something that both fits the current direction and provides decent numerics. Phil -Mark Henri Yandell wrote: As an answer to the thread mentioned, it suggests that two implementations of the Complex number functionality are available: 1) VNI's. 2) Colt's. This is no longer true, and the reason for me starting this thread. VNI no longer have their implementation online and the url provided in the email thread no longer takes you to the javadoc. This is made worse by the fact that Colt's implementation is in fact nothing but the VNI implementation. There is 1 implementation from 2 sources, the original of which just shut up shop. I agree with Roger Endo on Complex number usage. We're using it in FFT's amongst other places. So I'm left with Colt. This has legal problems. While VNI's licence is unspecified, Colt includes GPL licenced works. So this rules it out for some uses. In fact, as people here at work are starting to suggest applets rather than flash interfaces, I could be facing a situation in which I cannot download a fresh Complex number implementation which I can legally use. I see no reason not to go with Phil's classes, unless it's to ask VNI if they'd like to submit their popular Complex class. Hen On Wed, 22 Oct 2003, Mark R. Diggory wrote: I'm going to start a list of references to these threads in the xdoc, so we can always get back to it from the home page. When people have questions about the decisions and issues about complex, we'll be able to point them at the history of discussion on the topic. -Mark Brent Worden wrote: Here's the previous complex thread is was referring to http://nagoya.apache.org/eyebrowse/ReadMsg?listId=15msgNo=28132 Brent Worden http://www.brent.worden.org -Original Message- From: Brent Worden [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 10:53 PM To: Jakarta Commons Developers List Subject: RE: [math] Complex implementation I know we've talked about this before, It's not fresh in my mind why we decided against it. -Mark Looking back at the mail archives, it appears we decided against a complex class mainly for two reasons: 1) Not too many RW applications warrant a complex class and can be accommodated with two double values. 2) There are plenty of other OS, complex implementations available so it wasn't crucial to having one in commons-math. Brent Worden http://www.brent.worden.org - 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: [all] new list for cvs commits? (was Re: commons-configuration)
Emmanuel Bourg wrote: It seems some prefer to keep the commit messages in the list, and others prefer a clean list with just the discussions. So what about this : - commons-dev : discussions + cvs messages - commons-cvs : only the cvs messages - commons-talk: only the discussions or maybe easier to set up : - commons-dev : only the discussions - commons-cvs : only the cvs messages - commons-commiters : discussions + cvs messages (this list is subscribed to commons-dev and commons-cvs with a Reply-To header set to commons-dev) This would suit to everyone. Emmanuel -1. Doing things this way (and it's been this way for several years now on nearly every Jakarta project) is a critical success factor in assuring the quality and popularity of the software created here. Developer lists are for the people developing the packages, and those folks need to see the commits at all times in order to understand what is changing, in addition to their responsibility to review commits at all times. Because it's open source, we're perfectly happy for non-developers to listen in, offer suggestions, and do their own reviews as well -- but a dev list is the fundamental working tool for the people actually developing the code. It therefore needs to be set up to meet *their* needs. If you want discussions and conversations about packages, without the commit messages, that's what the user list is for. On most user lists, the developers hang out as well, and will answer questions about what's coming up in addition to how to use the package. If you want to see isolated discussions for a particular commons package, encourage the developers for that package to create their own specialized -dev and -user lists, like the httpclient folks did. (I personally wouldn't mind if the [math] folks did that, but it's totally up to them -- I've got a filter for their traffic, which includes a whole lot more discussion than it does CVS commits, by the way :-). If you just want to lurk on the developer lists, but still reduce the message count, subscribe in digest mode instead. Then, you'll get all the messages for each day in one single message instead of individually. If you've got NNTP access, consider reading the groups through a newsgroup interface. For example, the news server at http://gmane.org mirrors many mailing lists, including this one (news host is news.gmane.org, newsgroup is gmane.comp.jakarta.commons.devel). But, at the end of the day, if you are using a mail reader that can't filter, get a new mail reader. I'm sorry, but it's hard to be sympathetic with that argument in this day and age. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] 1.0 RC1 available
Great, thanks. A couple of minor comments inline: On Thu, 30 Oct 2003, Stephen Colebourne wrote: I have checked the src and bin zip files. They seem OK. The only (minor) issue is that the text files have unix line endings. We fixed this on [lang] using an ant call. By fixed, do you mean switch to windows/dos line endings? It seems the files will have to be one or the other. I use unix, and so didn't have an md5 utility. The one I found (claims to be a GNU port), rejected the src md5 file until I added '* commons-primitives-1.0-RC1.zip' after the checksum. Then it was OK. However looking at the other jakarta md5s they don't seem to use this format, so I assume its particular to this program. Anyone recommend a better/alternative md5 program for Windows? Doesn't cygwin have an md5 impl? Otherwise I think I've seen Java based impls as well. If we find one that works well, we should add a link to it on the http://jakarta.apache.org/commons/releases/release.html page. Stephen Thanks to Robert by the way for his docs on the mirrored/signed release process. So far it's been very easy to follow. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration]Enhanced patch and some thoughts
Hi, I have added an enhanced version of the HierarchicalConfiguration patch to bugzilla (because of its size): Bug 24262. In this patch there is also an XMLReader implementation that operates on a BaseConfiguration instance rather than HierarchicalConfiguration. This makes it possible to perform XML processing on all kind of Confiugration objects and e.g. pass them to a Digester. The new parsing functionality for (Base)Configuration objects is implemented in the BaseConfigurationXMLReader class. There is also a new base class ConfigurationXMLReader that provides common functionality of the specific XMLReader classes. An additional class HierarchicalConfigurationConverter is used by BaseConfigurationXMLReader and provides means to iterate over the keys defined in a Configuration and treat them in a structured manner. I am expecting your feedback... Finally some thoughts about ConfigurationFactory: This class and some of the Configuration classes that can be created by this factory load their data from files. I think that will cause problems for applications that are deloyed in jars (and that have their configuration also stored in these archives), e.g. web applications. Wouldn't it be better if the affected classes used URLs instead? Then it would be possible to determine a URL to a configuration file (even if it is located in a jar) in a simmilar way as ClassPropertiesConfiguration work and let the classes read their data from that URL. And still another point: I am not very happy with ConfigurationFactory in the way that it not really constructs a union of the properties it reads. For instance if two XML files are read that contain similar elements you cannot obtain the data in the second file because the search for properties stops when values in the first file are found. I would prefer to get all properties. The BasePropertiesConfiguration class provides a way of including other files into a property file. I think it would be very useful to implement this feature for other configuration classes, too. Maybe a generic approach could be found to allow includes of arbirary files in all configuration classes (e.g. include .properties files in XML files and vice versa, XML files in XML files etc.). With this approach a developer could access all properties in his application through a single configuration object; this is similar to a Unix file system which allows to mount different disks into one logic directory tree. As a use case consider web frameworks like struts. Those frameworks typically define lots of configuration information in a monolithic file (struts-config.xml), which can be a bottle neck in large projects with lots of developers. With the generic include facility it would be very simple to split these large files into arbitrary small portions and link them together. For the code that processes the configuration these portions occur as a single logic file. What do you think? Regards Oli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Complex implementation
Brent just fired off an implementation in the bug track. I think I'm going to add it to the CVS and let the discussion evolve around it. -Mark Endo, Roger wrote: Hi It has not been mentioned in this thread, but Mark Hale's complex implementation is still being maintained over at sourceforge: http://sourceforge.net/projects/jsci I might also have some complex number code/knowledge/experience but unfortunately not much time. Roger Endo -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 7:39 PM To: Mark R. Diggory Cc: Jakarta Commons Developers List Subject: Re: [math] Complex implementation Mark R. Diggory wrote: I think the hesitancy was simply out of manpower and in interest of getting out a release soon. I'm somewhat surprised that Phil's Complex implementation didn't get added if he had already written it (which I had missed in the thread). Phil, Are you willing to donate your Complex number implementation to the Math library? Not in its current state. The outline described here: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=15msgNo=28132 is what I was working on. This represents a refactoring and significant extension of some old code of mine. Most importantly, my classes are neither C9x compliant nor numerically sound (the reason that I did not include them in the initial submission) and they don't implement the transcendental functions. Given that the outline is for a fairly unsophisticated implementation using static utility classes for complex operations, I doubt that the structure itself would have much value to commons-math today. Therefore, it is probably best to start from scratch (or from VNI, it they are willing), designing something that both fits the current direction and provides decent numerics. Phil -Mark Henri Yandell wrote: As an answer to the thread mentioned, it suggests that two implementations of the Complex number functionality are available: 1) VNI's. 2) Colt's. This is no longer true, and the reason for me starting this thread. VNI no longer have their implementation online and the url provided in the email thread no longer takes you to the javadoc. This is made worse by the fact that Colt's implementation is in fact nothing but the VNI implementation. There is 1 implementation from 2 sources, the original of which just shut up shop. I agree with Roger Endo on Complex number usage. We're using it in FFT's amongst other places. So I'm left with Colt. This has legal problems. While VNI's licence is unspecified, Colt includes GPL licenced works. So this rules it out for some uses. In fact, as people here at work are starting to suggest applets rather than flash interfaces, I could be facing a situation in which I cannot download a fresh Complex number implementation which I can legally use. I see no reason not to go with Phil's classes, unless it's to ask VNI if they'd like to submit their popular Complex class. Hen On Wed, 22 Oct 2003, Mark R. Diggory wrote: I'm going to start a list of references to these threads in the xdoc, so we can always get back to it from the home page. When people have questions about the decisions and issues about complex, we'll be able to point them at the history of discussion on the topic. -Mark Brent Worden wrote: Here's the previous complex thread is was referring to http://nagoya.apache.org/eyebrowse/ReadMsg?listId=15msgNo=28132 Brent Worden http://www.brent.worden.org -Original Message- From: Brent Worden [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 10:53 PM To: Jakarta Commons Developers List Subject: RE: [math] Complex implementation I know we've talked about this before, It's not fresh in my mind why we decided against it. -Mark Looking back at the mail archives, it appears we decided against a complex class mainly for two reasons: 1) Not too many RW applications warrant a complex class and can be accommodated with two double values. 2) There are plenty of other OS, complex implementations available so it wasn't crucial to having one in commons-math. Brent Worden http://www.brent.worden.org - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration]Enhanced patch and some thoughts
Wow! Lots of good feedback.. Let me start with the ConfigurationFactory. Okay.. CF sucks.. I discovered the problem with the files myself recently. What it really should work with is an InputStream or Url.. , since the xml file that digester uses could be in a jar. So, I totally agree with you on that. Okay, second bit, whether a configfactory returns the merged set or properties, or overrides.. I guess there are two seperate usecases. The first usecase, which is what it implements now is that you have a standard set of properties, so you include them in a jar file and use them. But, you want to give the user/deployer the ability to override them, so you put either another properties file or jndi or what not ahead of the standard. And voila! You can override all your properties. Second use case.. I want to collect all the properties from multiple locations and then merge them into one super Configuration object. This would allow me to dynamically add to what is already setup. I think that the ConfigurationFactory should deal with both cases.. I see something like: override list of locations to look for properties that override the onces that come after it. Similar to what is there now. /override additional list of locations to add all the properties into one uber Configuration object. /additonal This would then allow me the ability to do both usecases. I would love to see some patches for ConfigurationFactory, that could support this. As an aside, I wrote an Avalon wrapper for the ConfigurationFactory based Configuration objects: http://jakarta.apache.org/turbine/fulcrum/fulcrum-configuration/index.html I made it part of fulcrum as I didn't want to bloat c-c with a ton of extra dependencies for something that is just a wrapper. Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Thursday, October 30, 2003 7:15 PM To: Jakarta Commons Developer List Subject: [configuration]Enhanced patch and some thoughts Hi, I have added an enhanced version of the HierarchicalConfiguration patch to bugzilla (because of its size): Bug 24262. In this patch there is also an XMLReader implementation that operates on a BaseConfiguration instance rather than HierarchicalConfiguration. This makes it possible to perform XML processing on all kind of Confiugration objects and e.g. pass them to a Digester. The new parsing functionality for (Base)Configuration objects is implemented in the BaseConfigurationXMLReader class. There is also a new base class ConfigurationXMLReader that provides common functionality of the specific XMLReader classes. An additional class HierarchicalConfigurationConverter is used by BaseConfigurationXMLReader and provides means to iterate over the keys defined in a Configuration and treat them in a structured manner. I am expecting your feedback... Finally some thoughts about ConfigurationFactory: This class and some of the Configuration classes that can be created by this factory load their data from files. I think that will cause problems for applications that are deloyed in jars (and that have their configuration also stored in these archives), e.g. web applications. Wouldn't it be better if the affected classes used URLs instead? Then it would be possible to determine a URL to a configuration file (even if it is located in a jar) in a simmilar way as ClassPropertiesConfiguration work and let the classes read their data from that URL. And still another point: I am not very happy with ConfigurationFactory in the way that it not really constructs a union of the properties it reads. For instance if two XML files are read that contain similar elements you cannot obtain the data in the second file because the search for properties stops when values in the first file are found. I would prefer to get all properties. The BasePropertiesConfiguration class provides a way of including other files into a property file. I think it would be very useful to implement this feature for other configuration classes, too. Maybe a generic approach could be found to allow includes of arbirary files in all configuration classes (e.g. include .properties files in XML files and vice versa, XML files in XML files etc.). With this approach a developer could access all properties in his application through a single configuration object; this is similar to a Unix file system which allows to mount different disks into one logic directory tree. As a use case consider web frameworks like struts. Those frameworks typically define lots of configuration information in a monolithic file (struts-config.xml), which can be a bottle neck in large projects with lots of developers. With the generic include facility it would be very simple to split these large files into arbitrary small portions and link them together. For the code that processes the configuration these portions occur as a single logic file.
DO NOT REPLY [Bug 24264] New: - JDBCDynaClass should support column label.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24264.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24264
JDBCDynaClass should support column label.
Summary: JDBCDynaClass should support column label.
Product: Commons
Version: Nightly Builds
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Bean Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
JDBCDynaClass should support column label, not just using the column name as
the DynaProperty name. Currently if you joing two tables and the two tables
have the same column name, then the current implementation fails. The fix is
included below
Index: JDBCDynaClass.java
===
RCS file: /home/cvspublic/jakarta-
commons/beanutils/src/java/org/apache/commons/beanutils/JDBCDynaClass.java,v
retrieving revision 1.3
diff -u -r1.3 JDBCDynaClass.java
--- JDBCDynaClass.java 9 Oct 2003 20:43:15 - 1.3
+++ JDBCDynaClass.java 30 Oct 2003 18:53:27 -
@@ -87,6 +91,13 @@
*/
protected boolean lowerCase = true;
+ /**
+* pFlag defining whether column names should be the column name
+* or the column label./p
+*/
+protected boolean useName = true;
+
+
/**
* pThe set of dynamic properties that are part of this
* [EMAIL PROTECTED] DynaClass}./p
@@ -199,12 +210,12 @@
int i)
throws SQLException {
-String name = null;
+String name = ( useName ) ? metadata.getColumnName(i) :
metadata.getColumnLabel(i);
+
if (lowerCase) {
-name = metadata.getColumnName(i).toLowerCase();
-} else {
-name = metadata.getColumnName(i);
+ name = name.toLowerCase();
}
+
String className = null;
try {
className = metadata.getColumnClassName(i);
Index: ResultSetDynaClass.java
===
RCS file: /home/cvspublic/jakarta-
commons/beanutils/src/java/org/apache/commons/beanutils/ResultSetDynaClass.java,
v
retrieving revision 1.13
diff -u -r1.13 ResultSetDynaClass.java
--- ResultSetDynaClass.java 9 Oct 2003 20:43:15 - 1.13
+++ ResultSetDynaClass.java 30 Oct 2003 18:53:54 -
/**
* pImplementation of codeDynaClass/code for DynaBeans that wrap the
@@ -146,7 +149,7 @@
*/
public ResultSetDynaClass(ResultSet resultSet) throws SQLException {
-this(resultSet, true);
+this(resultSet, true, false);
}
@@ -166,13 +169,14 @@
*
* @param resultSet The result set to be wrapped
* @param lowerCase Should property names be lower cased?
- *
+ * @param useName Should property names b ethe column name of the
+ * label name?
* @exception NullPointerException if coderesultSet/code
* is codenull/code
* @exception SQLException if the metadata for this result set
* cannot be introspected
*/
-public ResultSetDynaClass(ResultSet resultSet, boolean lowerCase)
+public ResultSetDynaClass(ResultSet resultSet, boolean lowerCase, boolean
useName)
throws SQLException {
if (resultSet == null) {
@@ -180,6 +184,7 @@
}
this.resultSet = resultSet;
this.lowerCase = lowerCase;
+this.useName = useName;
introspect(resultSet);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24264] - JDBCDynaClass should support column label.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24264. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24264 JDBCDynaClass should support column label. --- Additional Comments From [EMAIL PROTECTED] 2003-10-30 19:24 --- Created an attachment (id=8837) JDBCDynaClass.java.fix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24264] - JDBCDynaClass should support column label.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24264. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24264 JDBCDynaClass should support column label. --- Additional Comments From [EMAIL PROTECTED] 2003-10-30 19:24 --- Created an attachment (id=8838) ResultSetDynaClass.fix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] new list for cvs commits? (was Re: commons-configuration)
gmane.org is great, that's how I access the apache mailing lists. A good filtering technique is to mark all messages as read, except for projects that you're interested in. I apologize for going off topic, but has anyone experienced delays when sending with gmane? My sent messages show up almost instantly on commons-dev and commons-user, but on the maven lists it takes 15 minutes or so, and on the ant lists it sometimes takes up to 12 hours. Is there a known reason for the delay? Craig R. McClanahan wrote: Emmanuel Bourg wrote: It seems some prefer to keep the commit messages in the list, and others prefer a clean list with just the discussions. So what about this : - commons-dev : discussions + cvs messages - commons-cvs : only the cvs messages - commons-talk: only the discussions or maybe easier to set up : - commons-dev : only the discussions - commons-cvs : only the cvs messages - commons-commiters : discussions + cvs messages (this list is subscribed to commons-dev and commons-cvs with a Reply-To header set to commons-dev) This would suit to everyone. Emmanuel -1. Doing things this way (and it's been this way for several years now on nearly every Jakarta project) is a critical success factor in assuring the quality and popularity of the software created here. Developer lists are for the people developing the packages, and those folks need to see the commits at all times in order to understand what is changing, in addition to their responsibility to review commits at all times. Because it's open source, we're perfectly happy for non-developers to listen in, offer suggestions, and do their own reviews as well -- but a dev list is the fundamental working tool for the people actually developing the code. It therefore needs to be set up to meet *their* needs. If you want discussions and conversations about packages, without the commit messages, that's what the user list is for. On most user lists, the developers hang out as well, and will answer questions about what's coming up in addition to how to use the package. If you want to see isolated discussions for a particular commons package, encourage the developers for that package to create their own specialized -dev and -user lists, like the httpclient folks did. (I personally wouldn't mind if the [math] folks did that, but it's totally up to them -- I've got a filter for their traffic, which includes a whole lot more discussion than it does CVS commits, by the way :-). If you just want to lurk on the developer lists, but still reduce the message count, subscribe in digest mode instead. Then, you'll get all the messages for each day in one single message instead of individually. If you've got NNTP access, consider reading the groups through a newsgroup interface. For example, the news server at http://gmane.org mirrors many mailing lists, including this one (news host is news.gmane.org, newsgroup is gmane.comp.jakarta.commons.devel). But, at the end of the day, if you are using a mail reader that can't filter, get a new mail reader. I'm sorry, but it's hard to be sympathetic with that argument in this day and age. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/complex - New directory
mdiggory2003/10/30 11:42:41 jakarta-commons-sandbox/math/src/java/org/apache/commons/math/complex - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math/complex - New directory
mdiggory2003/10/30 11:42:41 jakarta-commons-sandbox/math/src/test/org/apache/commons/math/complex - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/src/test/org/apache/commons/math/complex ComplexTest.java
mdiggory2003/10/30 11:42:43
Modified:math/src/java/org/apache/commons/math/util MathUtils.java
Added: math/src/java/org/apache/commons/math/complex Complex.java
ComplexMath.java
math/src/test/org/apache/commons/math/complex
ComplexTest.java
Log:
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24241
Submitted by: Brent Worden
Revision ChangesPath
1.1
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/complex/Complex.java
Index: Complex.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgment:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names Apache and Apache Software Foundation and
*Apache Geronimo must not be used to endorse or promote products
*derived from this software without prior written permission. For
*written permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache,
*Apache Geronimo, nor may Apache appear in their name, without
*prior written permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*
*/
package org.apache.commons.math.complex;
/**
* Reference:
* http://myweb.lmu.edu/dmsmith/ZMLIB.pdf
*
* @version $Revision: 1.1 $ $Date: 2003/10/30 19:42:43 $
*/
public class Complex {
/** The square root of -1. */
public static final Complex I = new Complex(0.0, 1.0);
/** */
public static final Complex NaN = new Complex(Double.NaN, Double.NaN);
/** 1. */
public static final Complex ONE = new Complex(1.0, 0.0);
/** The imaginary part. */
protected double imaginary;
/** The real part. */
protected double real;
/**
* Create a complex number given the real and imaginary parts.
* @param real the real part.
* @param imaginary the imaginary part.
*/
public Complex(double real, double imaginary) {
super();
this.real = real;
this.imaginary = imaginary;
}
/**
* Return the absolute value of this complex number.
* @return the absolute value.
*/
public double abs() {
if (isNaN()) {
return Double.NaN;
}
return Math.sqrt(squareSum());
}
/**
* Return the sum of this complex number and the given complex number.
* @param rhs the other complex number.
* @return the complex number sum.
*/
public Complex add(Complex rhs) {
if (isNaN() ||
DO NOT REPLY [Bug 24241] - [math] complex proposal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24241. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24241 [math] complex proposal [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-30 19:46 --- Applied and build tested - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/xdocs tasks.xml
mdiggory2003/10/30 11:51:17 Modified:math/xdocs tasks.xml Log: Comments about Complex Revision ChangesPath 1.11 +19 -2 jakarta-commons-sandbox/math/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons-sandbox/math/xdocs/tasks.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- tasks.xml 22 Oct 2003 15:00:44 - 1.10 +++ tasks.xml 30 Oct 2003 19:51:16 - 1.11 @@ -46,11 +46,28 @@ /dd dtDistributions./dt ddFinalize the contents of MathUtils and StatUtils. Suggest any additions -- ideally with patches -- to these utility classes./dd +dtComplex Number Library./dt + dd + An initial a href=http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24241;submission/a + of a complex number library has been donated by Brent Worden. It has been added + and is open to be reviewed/tested by others for feedback. + The implementation is based on the following source: + a href=http://myweb.lmu.edu/dmsmith/ZMLIB.pdf;http://myweb.lmu.edu/dmsmith/ZMLIB.pdf/a. + + ul + lia href=http://nagoya.apache.org/eyebrowse/ReadMsg?listId=15amp;msgNo=28132; + Thread Subject: [math] Complex dilemmas + /a/li + lia href=http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=36293 + Thread Subject: [math] Complex implementation + /a/li + /ul + /dd /dl /subsection /section section name=Future Goals - subsection name=Delayed Tasks + subsection name=Delayed Tasks slated for the next release of the Math library pWhile we are interested in implementing these aspects of the library, we have decided to hold off on their development at this time./p dl dtComplex Number Library./dt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/math/xdocs tasks.xml
mdiggory2003/10/30 11:52:06 Modified:math/xdocs tasks.xml Log: Comments about Complex Revision ChangesPath 1.12 +4 -17 jakarta-commons-sandbox/math/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons-sandbox/math/xdocs/tasks.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- tasks.xml 30 Oct 2003 19:51:16 - 1.11 +++ tasks.xml 30 Oct 2003 19:52:06 - 1.12 @@ -66,24 +66,11 @@ /dl /subsection /section -section name=Future Goals +!--section name=Future Goals subsection name=Delayed Tasks slated for the next release of the Math library -pWhile we are interested in implementing these aspects of the library, we have decided to hold off on their development at this time./p -dl - dtComplex Number Library./dt - ddA great deal of thought has gone into the issues surrounding a Complex Implementation. As discussions on the subject continue to grow, we will make them available so new user, contributors, etc will have an idea of the issues surrounding this subject. - ul - lia href=http://nagoya.apache.org/eyebrowse/ReadMsg?listId=15amp;msgNo=28132; - Thread Subject: [math] Complex dilemmas - /a/li - lia href=http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=36293 - Thread Subject: [math] Complex implementation - /a/li - /ul - /dd -/dl + /subsection -/section +/section-- section name=Completed subsection name=Since Conception ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/src/java/org/apache/commons/jelly TagSupport.java
dion2003/10/30 12:04:49 Modified:jelly/src/java/org/apache/commons/jelly TagSupport.java Log: Make docs more understandable Revision ChangesPath 1.28 +7 -9 jakarta-commons/jelly/src/java/org/apache/commons/jelly/TagSupport.java Index: TagSupport.java === RCS file: /home/cvs/jakarta-commons/jelly/src/java/org/apache/commons/jelly/TagSupport.java,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- TagSupport.java 9 Oct 2003 21:21:27 - 1.27 +++ TagSupport.java 30 Oct 2003 20:04:48 - 1.28 @@ -260,8 +260,7 @@ } /** - * Evaluates the given body using a buffer and returns the String - * of the result. + * Executes the body of the tag and returns the result as a String. * * @return the text evaluation of the body */ @@ -272,8 +271,7 @@ } /** - * Evaluates the given body using a buffer and returns the String - * of the result. + * Executes the body of the tag and returns the result as a String. * * @param shouldEscape Signal if the text should be escaped. * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] 1.0 RC1 available
From: Rodney Waldhoff [EMAIL PROTECTED] On Thu, 30 Oct 2003, Stephen Colebourne wrote: I have checked the src and bin zip files. They seem OK. The only (minor) issue is that the text files have unix line endings. We fixed this on [lang] using an ant call. By fixed, do you mean switch to windows/dos line endings? It seems the files will have to be one or the other. What we did was zip file to have 'windows' endings and targz to have 'uniz' endings. I reckon this keeps most people happy. Stephen I use unix, and so didn't have an md5 utility. The one I found (claims to be a GNU port), rejected the src md5 file until I added '* commons-primitives-1.0-RC1.zip' after the checksum. Then it was OK. However looking at the other jakarta md5s they don't seem to use this format, so I assume its particular to this program. Anyone recommend a better/alternative md5 program for Windows? Doesn't cygwin have an md5 impl? Otherwise I think I've seen Java based impls as well. If we find one that works well, we should add a link to it on the http://jakarta.apache.org/commons/releases/release.html page. Stephen Thanks to Robert by the way for his docs on the mirrored/signed release process. So far it's been very easy to follow. - Rod http://radio.weblogs.com/0122027/ - 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: [all] new list for cvs commits? (was Re: commons-configuration)
__matthewHawthorne wrote: gmane.org is great, that's how I access the apache mailing lists. A good filtering technique is to mark all messages as read, except for projects that you're interested in. I apologize for going off topic, but has anyone experienced delays when sending with gmane? My sent messages show up almost instantly on commons-dev and commons-user, but on the maven lists it takes 15 minutes or so, and on the ant lists it sometimes takes up to 12 hours. Is there a known reason for the delay? The most likely reason is that they're going through a moderator. In the case of COMMONS-DEV (where I am the moderator) I've got you on the allow list that allows postings through even though you're not directly subscribed (which I tend to do when unsubscribed folks continue to send on-topic postings :-). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [primitives] 1.0 RC1 available
On Thu, 30 Oct 2003, Stephen Colebourne wrote: From: Rodney Waldhoff [EMAIL PROTECTED] On Thu, 30 Oct 2003, Stephen Colebourne wrote: I have checked the src and bin zip files. They seem OK. The only (minor) issue is that the text files have unix line endings. We fixed this on [lang] using an ant call. By fixed, do you mean switch to windows/dos line endings? It seems the files will have to be one or the other. What we did was zip file to have 'windows' endings and targz to have 'uniz' endings. I reckon this keeps most people happy. Sounds reasonable. I used maven to build this distro, but I'll have a look at the lang build.xml and see if I can't get it to do the same. Stephen -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] logic for determing log level
This is a general use question about [logging]. I'm looking through the
source for [betwixt], and I see lines like the following:
if ( log.isTraceEnabled() ) {
log.trace( Is + descriptor + empty? );
}
What is the purpose of doing this check? If trace *is* enabled, then
isn't the same check done inside of the underlying logging implementation?
Is this some type of trick to improve performance? I'm probably
misunderstanding it, but I just think that it adds clutter.
Any insights?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] logic for determing log level
Assuming the if() clause isn't there, then:
Is + descriptor + empty?
is evaluated before the call to log.trace(), whether or not that call will
actually yield any output. Putting the if() { } around it prevents the
arguments to log.trace() from being executed if log.isTraceEnabled() is
false.
See
http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Category.html#isDebugEnabled()
for example.
On Thu, 30 Oct 2003, __matthewHawthorne wrote:
This is a general use question about [logging]. I'm looking through the
source for [betwixt], and I see lines like the following:
if ( log.isTraceEnabled() ) {
log.trace( Is + descriptor + empty? );
}
What is the purpose of doing this check? If trace *is* enabled, then
isn't the same check done inside of the underlying logging implementation?
Is this some type of trick to improve performance? I'm probably
misunderstanding it, but I just think that it adds clutter.
Any insights?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
- Rod http://radio.weblogs.com/0122027/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] logic for determing log level
--- __matthewHawthorne [EMAIL PROTECTED] wrote:
This is a general use question about [logging]. I'm looking through the
source for [betwixt], and I see lines like the following:
if ( log.isTraceEnabled() ) {
log.trace( Is + descriptor + empty? );
}
What is the purpose of doing this check? If trace *is* enabled, then
isn't the same check done inside of the underlying logging
implementation?
Yes, this code is doing the check twice.
Is this some type of trick to improve performance? I'm probably
misunderstanding it, but I just think that it adds clutter.
This is an attempt to optimize the logging but I would be *very* surprised
if it actually acheived any noticable performance benefits in most cases.
Much Jakarta code I've seen uses the if checks on logging calls except in
catch blocks. If you're in the catch block, you've already incurred the
cost of the exception mechanism so optimizing the logging doesn't make
much sense.
In my own code, I never use the if check because of the clutter.
David
Any insights?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] logic for determing log level
In this case you would save the cost of concatenating the Strings and
the descriptor.toString() operation.
You need to figure out if that is a big cost where the code is going to
be used.
Log4J has a faq entry that discusses this subject:
http://jakarta.apache.org/log4j/docs/FAQ.html#fastLogging
Steve
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: October 30, 2003 2:40 PM
To: Jakarta Commons Developers List
Subject: Re: [logging] logic for determing log level
--- __matthewHawthorne [EMAIL PROTECTED] wrote:
This is a general use question about [logging]. I'm
looking through the
source for [betwixt], and I see lines like the following:
if ( log.isTraceEnabled() ) {
log.trace( Is + descriptor + empty? );
}
What is the purpose of doing this check? If trace *is*
enabled, then
isn't the same check done inside of the underlying logging
implementation?
Yes, this code is doing the check twice.
Is this some type of trick to improve performance? I'm probably
misunderstanding it, but I just think that it adds clutter.
This is an attempt to optimize the logging but I would be
*very* surprised
if it actually acheived any noticable performance benefits in
most cases.
Much Jakarta code I've seen uses the if checks on logging
calls except in
catch blocks. If you're in the catch block, you've already
incurred the
cost of the exception mechanism so optimizing the logging doesn't make
much sense.
In my own code, I never use the if check because of the clutter.
David
Any insights?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
-
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 14409] - Add support for stuff like [target [target2 [target3] ...]]
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14409. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14409 Add support for stuff like [target [target2 [target3] ...]] [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-30 23:51 --- This is fixed in CLI 2. See the Ant test for an example. Essentially you can add an anonymous option i.e. by not defining a parent Option. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24272] New: - Enum/ValueEnum class needs functionality to load values from a properties file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24272.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24272
Enum/ValueEnum class needs functionality to load values from a properties file
Summary: Enum/ValueEnum class needs functionality to load values
from a properties file
Product: Commons
Version: 2.0 Final
Platform: All
OS/Version: Windows XP
Status: NEW
Severity: Enhancement
Priority: Other
Component: Lang
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
It would be good to have an implementation of Enum that can load the possible
values from a properties file, instead of having to change the code everytime a
new value is added. This properties file could be named the same as the Enum
class being implemented, e.g., if MyEnum.java extends Enum or ValuedEnum, it
should be able to load the values from MyEnum.properties file located in the
same directory as the class itself and be packaged in the jar along with the
class.
I took a crack at solving the problem, as follows:
import java.io.Serializable;
import java.io.InputStream;
import java.io.IOException;
import java.util.Properties;
import java.util.Iterator;
import java.util.Map;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import org.apache.commons.lang.enum.*;
public abstract class ConfigEnum extends ValuedEnum {
protected static void loadEnumConfig(Class enumClass)
throws IOException, InstantiationException,
IllegalAccessException, Throwable {
Properties p = new Properties();
String propFilename = enumClass.getName().replace('.', '/')
+ .properties;
InputStream is = null;
ClassLoader loader = enumClass.getClassLoader();
is = ((loader != null) ? loader.getResourceAsStream(propFilename) :
ClassLoader.getSystemResourceAsStream(propFilename));
if (is == null) {
throw new RuntimeException(No such resource);
}
p.load(is);
is.close();
for(Iterator pIter = p.entrySet().iterator(); pIter.hasNext(); ) {
// Read the entries from the properties file and create Objects of
that type
Map.Entry entry = (Map.Entry) pIter.next();
int enumValue = Integer.parseInt((String) entry.getKey());
String enumStr = (String) entry.getValue();
Class[] constructorArgTypes = new Class[] { String.class,
int.class };
try {
Constructor constructor = enumClass.getConstructor
(constructorArgTypes);
Object[] constructorArgs = new Object [] { enumStr, new Integer
(enumValue) };
constructor.newInstance(constructorArgs);
} catch (NoSuchMethodException nsme) {
System.err.println(Caught Exception in loadEnumConfig: +
nsme);
} catch (InvocationTargetException ite) {
throw ite.getTargetException();
}
}
}
protected ConfigEnum(String name, int value) {
super(name, value);
}
}
The only problem with this implementation is that it requires the MyEnum.java
class to have a public constructor with MyEnum(String, int) signature. This
defeats the very purpose of protecting creation of new values. Another solution
is to make the ConfigEnum class non-abstract, but it doesn't seem elegant or
fool-proof. Any suggestions/ideas.
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/bugs - New directory
jkeyes 2003/10/30 16:20:02 jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/bugs - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2 ApplicationTest.java
jkeyes 2003/10/30 16:20:08
Modified:cli/src/test/org/apache/commons/cli2 ApplicationTest.java
Added: cli/src/test/org/apache/commons/cli2/bugs Bug15046.java
Log:
- added bugs test package
- added test
Revision ChangesPath
1.1
jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/bugs/Bug15046.java
Index: Bug15046.java
===
package org.apache.commons.cli2.bugs;
import junit.framework.TestCase;
import org.apache.commons.cli2.ArgumentBuilder;
import org.apache.commons.cli2.CommandLine;
import org.apache.commons.cli2.CommandLineParser;
import org.apache.commons.cli2.DefaultOptionBuilder;
import org.apache.commons.cli2.Group;
import org.apache.commons.cli2.GroupBuilder;
import org.apache.commons.cli2.Option;
public class Bug15046 extends TestCase {
public Bug15046(String name) {
super(name);
}
public void testParamNamedAsOption() throws Exception {
final String[] CLI_ARGS = new String[] { -z, c };
DefaultOptionBuilder obuilder = new DefaultOptionBuilder();
ArgumentBuilder abuilder = new ArgumentBuilder();
Option option =
obuilder
.withShortName(z)
.withLongName(timezone)
.withDescription(affected option)
.withArgument(abuilder.withName(timezone).create())
.create();
GroupBuilder gbuilder = new GroupBuilder();
Group options =
gbuilder.withName(bug15046).withOption(option).create();
CommandLineParser parser = new CommandLineParser();
parser.setGroup(options);
CommandLine line = parser.parse(CLI_ARGS);
assertEquals(c, line.getValue(-z));
Option c =
obuilder
.withShortName(c)
.withLongName(conflict)
.withDescription(conflicting option)
.withArgument(abuilder.withName(conflict).create())
.create();
options =
gbuilder
.withName(bug15046)
.withOption(option)
.withOption(c)
.create();
parser.setGroup(options);
line = parser.parse(CLI_ARGS);
assertEquals(c, line.getValue(-z));
}
}
1.5 +12 -3
jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/ApplicationTest.java
Index: ApplicationTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/cli/src/test/org/apache/commons/cli2/ApplicationTest.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ApplicationTest.java 28 Oct 2003 22:53:59 - 1.4
+++ ApplicationTest.java 31 Oct 2003 00:20:08 - 1.5
@@ -60,6 +60,9 @@
*/
package org.apache.commons.cli2;
+import java.util.ArrayList;
+import java.util.List;
+
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
@@ -249,6 +252,12 @@
assertEquals(mybuild.xml, line.getValue(-buildfile));
assertTrue(line.hasOption(-projecthelp));
assertFalse(line.hasOption(-help));
+
+ assertTrue(line.hasOption(target));
+ final List targets = new ArrayList();
+ targets.add(compile);
+ targets.add(docs);
+ assertEquals(targets, line.getValues(target));
}
public void testCVS() throws OptionException {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15046] - MissingArgumentException: no argument for option is thrown when the option's parameter equals to an existing option.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15046. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15046 MissingArgumentException: no argument for option is thrown when the option's parameter equals to an existing option. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 00:24 --- This is resolved in CLI 2. I have added a test case (see the bugs package) - check out the source in the sandbox for more information. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sql] anyone around?
I spent some time checking out the [sql] project in the commons sandbox today. I may try it out in a project that I'm working on. [sql] seems to be pretty dead lately, are there any active committers listening? I have a few documentation fixes, and also the project.xml needed some updates in order to build successfully. It needed jelly-SNAPSHOT in order to property process the xdocs. Is it alright if I go ahead and commit these changes? Is there a standard procedure to follow in this situation? If a project has become stagnant, and another committer wants to do some work on it, should they just send a message to the dev list, and if no response is given in a few days, go ahead and start working? Thanks for any info. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections AbstractTestCollection.java
scolebourne2003/10/30 17:23:11
Modified:collections/src/test/org/apache/commons/collections
AbstractTestCollection.java
Log:
Improve error messages in verify
Fix bug when TreeMap EntrySet used
Revision ChangesPath
1.7 +13 -5
jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestCollection.java
Index: AbstractTestCollection.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestCollection.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- AbstractTestCollection.java 19 Oct 2003 00:25:11 - 1.6
+++ AbstractTestCollection.java 31 Oct 2003 01:23:10 - 1.7
@@ -69,6 +69,8 @@
import java.util.Map;
import java.util.NoSuchElementException;
+import org.apache.commons.collections.pairs.DefaultMapEntry;
+
/**
* Abstract test class for [EMAIL PROTECTED] java.util.Collection} methods and
contracts.
* p
@@ -321,7 +323,8 @@
// no match found!
if(!match) {
fail(Collection should not contain a value that the +
- confirmed collection does not have: + o);
+ confirmed collection does not have: + o +
+ \nTest: + collection + \nReal: + confirmed);
}
}
@@ -329,8 +332,8 @@
for(int i = 0; i confirmedSize; i++) {
if(!matched[i]) {
// the collection didn't match all the confirmed values
-fail(Collection should contain all values that are in the +
- confirmed collection);
+fail(Collection should contain all values that are in the
confirmed collection +
+ \nTest: + collection + \nReal: + confirmed);
}
}
}
@@ -844,6 +847,11 @@
Iterator iter = collection.iterator();
while (iter.hasNext()) {
Object o = iter.next();
+// TreeMap reuses the Map Entry, so the verify below fails
+// Clone it here if necessary
+if (o instanceof Map.Entry) {
+o = new DefaultMapEntry((Map.Entry) o);
+}
iter.remove();
// if the elements aren't distinguishable, we can just remove a
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections AbstractTestMap.java
scolebourne2003/10/30 17:24:33
Modified:collections/src/test/org/apache/commons/collections
AbstractTestMap.java
Log:
Allow subclasses to change the confirmed map
Ensure views pickup correct serialization methods
Revision ChangesPath
1.9 +33 -12
jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestMap.java
Index: AbstractTestMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestMap.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- AbstractTestMap.java 10 Oct 2003 21:19:39 - 1.8
+++ AbstractTestMap.java 31 Oct 2003 01:24:32 - 1.9
@@ -412,6 +412,15 @@
return makeEmptyMap();
}
+/**
+ * Override to return a map other than HashMap as the confirmed map.
+ *
+ * @return a map that is known to be valid
+ */
+protected Map makeConfirmedMap() {
+return new HashMap();
+}
+
//---
/**
* Test to ensure the test setup is working properly. This method checks
@@ -841,7 +850,7 @@
resetEmpty();
-m2 = new HashMap();
+m2 = makeConfirmedMap();
Object[] keys = getSampleKeys();
Object[] values = getSampleValues();
for(int i = 0; i keys.length; i++) {
@@ -1056,7 +1065,7 @@
private Map.Entry[] makeEntryArray(Object[] keys, Object[] values) {
Map.Entry[] result = new Map.Entry[keys.length];
for (int i = 0; i keys.length; i++) {
-Map map = new HashMap();
+Map map = makeConfirmedMap();
map.put(keys[i], values[i]);
result[i] = (Map.Entry) map.entrySet().iterator().next();
}
@@ -1107,11 +1116,16 @@
// Collection views don't support add operations.
return false;
}
-
protected boolean isRemoveSupported() {
// Entry set should only support remove if map does
return AbstractTestMap.this.isRemoveSupported();
}
+protected boolean supportsEmptyCollections() {
+return AbstractTestMap.this.supportsEmptyCollections();
+}
+protected boolean supportsFullCollections() {
+return AbstractTestMap.this.supportsFullCollections();
+}
protected void resetFull() {
AbstractTestMap.this.resetFull();
@@ -1167,14 +1181,18 @@
protected boolean isNullSupported() {
return AbstractTestMap.this.isAllowNullKey();
}
-
protected boolean isAddSupported() {
return false;
}
-
protected boolean isRemoveSupported() {
return AbstractTestMap.this.isRemoveSupported();
}
+protected boolean supportsEmptyCollections() {
+return AbstractTestMap.this.supportsEmptyCollections();
+}
+protected boolean supportsFullCollections() {
+return AbstractTestMap.this.supportsFullCollections();
+}
protected void resetEmpty() {
AbstractTestMap.this.resetEmpty();
@@ -1232,14 +1250,18 @@
protected boolean isNullSupported() {
return AbstractTestMap.this.isAllowNullKey();
}
-
protected boolean isAddSupported() {
return false;
}
-
protected boolean isRemoveSupported() {
return AbstractTestMap.this.isRemoveSupported();
}
+protected boolean supportsEmptyCollections() {
+return AbstractTestMap.this.supportsEmptyCollections();
+}
+protected boolean supportsFullCollections() {
+return AbstractTestMap.this.supportsFullCollections();
+}
protected boolean areEqualElementsDistinguishable() {
// equal values are associated with different keys, so they are
@@ -1287,10 +1309,9 @@
protected void resetEmpty() {
this.map = makeEmptyMap();
views();
-this.confirmed = new HashMap();
+this.confirmed = makeConfirmedMap();
}
-
/**
* Resets the [EMAIL PROTECTED] #map}, [EMAIL PROTECTED] #entrySet}, [EMAIL
PROTECTED] #keySet},
* [EMAIL PROTECTED] #values} and [EMAIL PROTECTED] #confirmed} fields to full.
@@ -1298,7 +1319,7 @@
protected void resetFull() {
this.map = makeFullMap();
views();
-this.confirmed = new HashMap();
+this.confirmed = makeConfirmedMap();
Object[] k =
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections AbstractTestBidiMap.java
scolebourne2003/10/30 17:25:24
Modified:collections/src/test/org/apache/commons/collections
AbstractTestBidiMap.java
Log:
Ensure that values returned are in same order as keys
Revision ChangesPath
1.3 +17 -2
jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestBidiMap.java
Index: AbstractTestBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestBidiMap.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AbstractTestBidiMap.java 29 Oct 2003 00:06:25 - 1.2
+++ AbstractTestBidiMap.java 31 Oct 2003 01:25:24 - 1.3
@@ -58,6 +58,7 @@
package org.apache.commons.collections;
import java.util.HashMap;
+import java.util.Iterator;
import java.util.Map;
import java.util.NoSuchElementException;
@@ -287,6 +288,20 @@
final Object key = map.removeKey(value);
assertTrue(Key was not removed., !map.containsKey(key));
assertNull(Value was not removed., map.getKey(value));
+}
+
+//---
+public void testBidiKeySetValuesOrder() {
+resetFull();
+Iterator keys = map.keySet().iterator();
+Iterator values = map.values().iterator();
+for (; keys.hasNext() values.hasNext();) {
+Object key = keys.next();
+Object value = values.next();
+assertSame(map.get(key), value);
+}
+assertEquals(false, keys.hasNext());
+assertEquals(false, values.hasNext());
}
//---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections AbstractTestSortedMap.java
scolebourne2003/10/30 17:25:45
Modified:collections/src/test/org/apache/commons/collections
AbstractTestSortedMap.java
Log:
Add a lot of tests
Revision ChangesPath
1.4 +216 -4
jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestSortedMap.java
Index: AbstractTestSortedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestSortedMap.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AbstractTestSortedMap.java7 Oct 2003 22:20:57 - 1.3
+++ AbstractTestSortedMap.java31 Oct 2003 01:25:45 - 1.4
@@ -57,8 +57,13 @@
*/
package org.apache.commons.collections;
+import java.util.ArrayList;
+import java.util.Arrays;
import java.util.Iterator;
+import java.util.List;
+import java.util.Map;
import java.util.SortedMap;
+import java.util.TreeMap;
/**
* Abstract test class for [EMAIL PROTECTED] java.util.SortedMap} methods and
contracts.
@@ -88,8 +93,15 @@
return false;
}
-// TODO: Add the SortedMap tests!
-
+/**
+ * SortedMap uses TreeMap as its known comparison.
+ *
+ * @return a map that is known to be valid
+ */
+protected Map makeConfirmedMap() {
+return new TreeMap();
+}
+
//---
public void testComparator() {
SortedMap sm = (SortedMap) makeFullMap();
@@ -108,6 +120,206 @@
obj = (Object) it.next();
}
assertSame(obj, sm.lastKey());
+}
+
+//---
+public BulkTest bulkTestHeadMap() {
+return new TestHeadMap(this);
+}
+
+public BulkTest bulkTestTailMap() {
+return new TestTailMap(this);
+}
+
+public BulkTest bulkTestSubMap() {
+return new TestSubMap(this);
+}
+
+public static abstract class TestViewMap extends AbstractTestSortedMap {
+protected final AbstractTestMap main;
+protected final List subSortedKeys = new ArrayList();
+protected final List subSortedValues = new ArrayList();
+protected final List subSortedNewValues = new ArrayList();
+
+public TestViewMap(String name, AbstractTestMap main) {
+super(name);
+this.main = main;
+}
+protected void resetEmpty() {
+// needed to init verify correctly
+main.resetEmpty();
+super.resetEmpty();
+}
+protected void resetFull() {
+// needed to init verify correctly
+main.resetFull();
+super.resetFull();
+}
+protected void verify() {
+// cross verify changes on view with changes on main map
+super.verify();
+main.verify();
+}
+public BulkTest bulkTestHeadMap() {
+return null; // block infinite recursion
+}
+public BulkTest bulkTestTailMap() {
+return null; // block infinite recursion
+}
+public BulkTest bulkTestSubMap() {
+return null; // block infinite recursion
+}
+
+protected Object[] getSampleKeys() {
+return subSortedKeys.toArray();
+}
+protected Object[] getSampleValues() {
+return subSortedValues.toArray();
+}
+protected Object[] getNewSampleValues() {
+return subSortedNewValues.toArray();
+}
+
+protected String getCompatibilityVersion() {
+return main.getCompatibilityVersion();
+}
+protected boolean isAllowNullKey() {
+return main.isAllowNullKey();
+}
+protected boolean isAllowNullValue() {
+return main.isAllowNullValue();
+}
+protected boolean isPutAddSupported() {
+return main.isPutAddSupported();
+}
+protected boolean isPutChangeSupported() {
+return main.isPutChangeSupported();
+}
+protected boolean isRemoveSupported() {
+return main.isRemoveSupported();
+}
+protected boolean supportsEmptyCollections() {
+return false;
+}
+protected boolean supportsFullCollections() {
+return false;
+}
+}
+
+public static class TestHeadMap extends TestViewMap {
+static final int SUBSIZE = 6;
+final Object toKey;
+
+public TestHeadMap(AbstractTestMap
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections AbstractTestSortedBidiMap.java TestDualTreeBidiMap.java TestAll.java
scolebourne2003/10/30 17:26:25
Modified:collections/src/test/org/apache/commons/collections/decorators
TestFixedSizeSortedMap.java
TestTransformedSortedMap.java
collections/src/java/org/apache/commons/collections
AbstractDualBidiMap.java
collections/src/test/org/apache/commons/collections
TestAll.java
Added: collections/src/java/org/apache/commons/collections
DualTreeBidiMap.java
collections/src/test/org/apache/commons/collections
AbstractTestSortedBidiMap.java
TestDualTreeBidiMap.java
Log:
Add DualTreeBidiMap implementation and tests
Revision ChangesPath
1.6 +4 -4
jakarta-commons/collections/src/test/org/apache/commons/collections/decorators/TestFixedSizeSortedMap.java
Index: TestFixedSizeSortedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/decorators/TestFixedSizeSortedMap.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TestFixedSizeSortedMap.java 7 Oct 2003 22:20:58 - 1.5
+++ TestFixedSizeSortedMap.java 31 Oct 2003 01:26:25 - 1.6
@@ -62,9 +62,9 @@
import java.util.TreeMap;
import junit.framework.Test;
-import junit.framework.TestSuite;
import org.apache.commons.collections.AbstractTestSortedMap;
+import org.apache.commons.collections.BulkTest;
/**
* Extension of [EMAIL PROTECTED] TestSortedMap} for exercising the [EMAIL
PROTECTED] FixedSizeSortedMap}
@@ -82,7 +82,7 @@
}
public static Test suite() {
-return new TestSuite(TestFixedSizeSortedMap.class);
+return BulkTest.makeSuite(TestFixedSizeSortedMap.class);
}
public static void main(String args[]) {
1.5 +4 -4
jakarta-commons/collections/src/test/org/apache/commons/collections/decorators/TestTransformedSortedMap.java
Index: TestTransformedSortedMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/decorators/TestTransformedSortedMap.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TestTransformedSortedMap.java 6 Oct 2003 23:44:23 - 1.4
+++ TestTransformedSortedMap.java 31 Oct 2003 01:26:25 - 1.5
@@ -62,9 +62,9 @@
import java.util.TreeMap;
import junit.framework.Test;
-import junit.framework.TestSuite;
import org.apache.commons.collections.AbstractTestSortedMap;
+import org.apache.commons.collections.BulkTest;
/**
* Extension of [EMAIL PROTECTED] AbstractTestSortedMap} for exercising the [EMAIL
PROTECTED] TransformedSortedMap}
@@ -82,7 +82,7 @@
}
public static Test suite() {
-return new TestSuite(TestTransformedSortedMap.class);
+return BulkTest.makeSuite(TestTransformedSortedMap.class);
}
public static void main(String args[]) {
1.5 +82 -10
jakarta-commons/collections/src/java/org/apache/commons/collections/AbstractDualBidiMap.java
Index: AbstractDualBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/AbstractDualBidiMap.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- AbstractDualBidiMap.java 29 Oct 2003 00:06:25 - 1.4
+++ AbstractDualBidiMap.java 31 Oct 2003 01:26:25 - 1.5
@@ -94,6 +94,10 @@
*/
protected transient Set keySet = null;
/**
+ * View of the values.
+ */
+protected transient Collection values = null;
+/**
* View of the entries.
*/
protected transient Set entrySet = null;
@@ -248,7 +252,10 @@
}
public Collection values() {
-return inverseBidiMap().keySet();
+if (values == null) {
+values = new Values(this);
+}
+return values;
}
public Set entrySet() {
@@ -304,12 +311,13 @@
}
return modified;
}
-
+
public void clear() {
map.clear();
}
}
+//---
/**
* Inner class KeySet.
*/
@@ -323,8 +331,12 @@
return new KeySetIterator(super.iterator(), map);
}
+public boolean contains(Object key) {
+return map.maps[0].containsKey(key);
+}
+
public boolean remove(Object
Re: [digester] plugins: patch for logging
Hi,
Regarding logging in Digester; I may have found a solution that will
keep all parties happy. Let me know what you think
Currently this class exists in the plugins module to handle logging:
public class LogUtils {
public static Log getLogger(Digester digester) {
if (digester == null) {
return new org.apache.commons.logging.impl.NoOpLog();
}
return digester.getLogger();
}
}
If it was changed to the code below, promoted to the main digester
package, and used by all code, then:
(a)
For applications which never call Digester.setLogger(...), logging would
be done via different categories, which would make me happy, and
(b)
For applications which call Digester.setLogger(log) things would work as
currently; all logging for all related objects gets redirected to a
single Log object (ie a single category). I think this sucks, but as my
applications don't redirect logging, I don't care.
(c)
It would be 100% backwards-compatible as far as I can see. No API change
occurs on the Digester (users can still call Digester.setLogger as
before). Code which directly accesses
public class LogUtils {
/** default log category is specified string */
public static Log getLogger(Digester digester, String dfltCategory) {
if (digester == null) {
return new org.apache.commons.logging.impl.NoOpLog();
}
else {
Log log = digester.getLogger();
if (log == null) {
log = LogFactory.getLog(dfltCategory)
}
return log;
}
/** default log category is class name */
public static Log getLogger(Digester digester, Class klass) {
...
}
}
As icing on the cake, I suggest the RulesBase class be modified to
manage the log object.
The code below sets the log up as a NoOpLog initially, then when the
digester object is set, it changes the log object to either the
user-specified log object or a log category for the class.
class RulesBase .. {
protected Log log;
public RulesBase() {
log = LogUtils.getLogger(null, this.getClass());
}
public void setDigester(Digester d) {
log = LogUtils.getLogger(d, this.getClass())
}
}
This has a *slightly* different effect from my usual convention of
having a static private Log object on each class; with the code above,
the log category used for logging from inherited methods comes out with
the category of the derived class, not the category of the class on
which the method was actually declared. However that's close enough for
me...
In addition, making the RulesBase object keep track of the log object
means that derived classes are insulated from the actual details of how
the log object is derived. And the implementation is fairly efficient; a
lookup of log object is only done once at construction, and once in
setDigester.
There is a constraint on the above: it is that Digester.setLog must be
called before any objects (such as Rule objects) are added to the
digester. Changing the Log object later may not have the desired effect.
This seems reasonable to me, and may have been the original intention:
it's not explicitly specified, though.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] thread-safe?
Hi I'm looking to use the configuration package and wanted to wrap it in my own Singleton e.g. MyConfiguration.getInstance().getProperty(key). The ConfigurationFactory, referencing various Properties files, would get setup in the constructor of MyConfiguration. If I do not intend to add properties at run time, is it ok to use MyConfiguration in a mutli-threaded environment, i.e. once the ConfigurationFactory has been loaded up, is it safe for multiple threads to retrieve properties at the same time. I'd really appreciate some advice if the Singleton pattern is not the recommend approach. I'm trying to centralise where the Configuration is setup and also trying to ensure that the Properties files would only get read in once, rather than each call to retrieve a property. Thanks in advance Charles _ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateRequired.js
rleland 2003/10/30 22:20:34
Modified:validator/src/javascript/org/apache/commons/validator/javascript
validateRequired.js
Log:
Bug 24202
Add required check for single checkbox,
Bug report/patch by Saul Q Yuan
Revision ChangesPath
1.7 +8 -3
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateRequired.js
Index: validateRequired.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateRequired.js,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- validateRequired.js 22 Oct 2003 07:20:57 - 1.6
+++ validateRequired.js 31 Oct 2003 06:20:34 - 1.7
@@ -16,6 +16,7 @@
if (field.type == 'text' ||
field.type == 'textarea' ||
field.type == 'file' ||
+field.type == 'checkbox' ||
field.type == 'select-one' ||
field.type == 'password') {
@@ -25,6 +26,10 @@
var si = field.selectedIndex;
if (si = 0) {
value = field.options[si].value;
+}
+} else if (field.type == 'checkbox') {
+if (field.checked) {
+value = field.value;
}
} else {
value = field.value;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cactus-13-1.5-rc and commons-httpclient-2.0-rc2.jar works on jdk1.4 and above only?
Personally I think one should not replace a release with a new version without changing its name. This causes confusion. So at least call it RC2-build2 or something like that. To ensure this does not happen again in the future, should we include a check in the build.xml for the JavaC version used? Odi Michael Becke wrote: Assuming this new build fixes the problem, what is everyones' opinion about how we should proceed? As I see it we have the following options: - replace the existing 2.0 RC2 distributions with the new ones and add a note about the change to the HttpClient site - create a new release 2.0 RC3 and proceed with the normal release process - do nothing. leave the unofficial build in my directory for the time being and wait for 2.0 final. What does everyone think? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24081] - Manually set 'Cookie' 'Authorization' headers get discarded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24081.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24081
Manually set 'Cookie' 'Authorization' headers get discarded
--- Additional Comments From [EMAIL PROTECTED] 2003-10-30 08:35 ---
Hello Oleg,
I have just taken a look at it. In combination with pluggable cookie policies,
this patch provides everything I would need. Cookies can be set manually, with
or without being extended by the cookies from the HttpState. Resolving clashes
between manually set cookies and those in the state is the responsibility of
whom who sets cookies manually. And someone who wants his cookie header to be
removed automatically shouldn't set it in the first place :-)
No, wait, there is one thing: RFC 2965 in section 3.3.4 (last paragraph before
the note) specifies that cookies shall be sent in a defined order, those with
more specific paths preceeding those with less specific paths.
Considering the fuss of parsing manually set cookie headers, I wouldn't want
this to be implemented by the HTTP Client. But that should at least be pointed
out somewhere in the JavaDocs. In HttpMethod.{set|add}RequestHeader?
cheers,
Roland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cactus-13-1.5-rc and commons-httpclient-2.0-rc2.jar works on jdk1.4 and above only?
Non-binding +1 to both suggestions. Thanks -Vincent -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: 30 October 2003 09:13 To: Commons HttpClient Project Subject: Re: cactus-13-1.5-rc and commons-httpclient-2.0-rc2.jar works on jdk1.4 and above only? Personally I think one should not replace a release with a new version without changing its name. This causes confusion. So at least call it RC2-build2 or something like that. To ensure this does not happen again in the future, should we include a check in the build.xml for the JavaC version used? Odi Michael Becke wrote: Assuming this new build fixes the problem, what is everyones' opinion about how we should proceed? As I see it we have the following options: - replace the existing 2.0 RC2 distributions with the new ones and add a note about the change to the HttpClient site - create a new release 2.0 RC3 and proceed with the normal release process - do nothing. leave the unofficial build in my directory for the time being and wait for 2.0 final. What does everyone think? Mike - To unsubscribe, e-mail: commons-httpclient-dev- [EMAIL PROTECTED] For additional commands, e-mail: commons-httpclient-dev- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cactus-13-1.5-rc and commons-httpclient-2.0-rc2.jar works on jdk1.4 and above only?
Personally I think one should not replace a release with a new version without changing its name. This causes confusion. So at least call it RC2-build2 or something like that. It's very common in such cases to append an 'a' to the version. So I suggest you name it -rc2a. Regards, Ingo To ensure this does not happen again in the future, should we include a check in the build.xml for the JavaC version used? Odi Michael Becke wrote: Assuming this new build fixes the problem, what is everyones' opinion about how we should proceed? As I see it we have the following options: - replace the existing 2.0 RC2 distributions with the new ones and add a note about the change to the HttpClient site - create a new release 2.0 RC3 and proceed with the normal release process - do nothing. leave the unofficial build in my directory for the time being and wait for 2.0 final. What does everyone think? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HttpRecoverableException
Hi, I'm using the nightly builds version of HttpClient and I have noticed that, when a timeout occurs, neither ConnectTimeoutException nor IOTimeoutException are ever thrown. Instead, HttpConnection.ConnectionTimeoutException and java.net.SocketTimeoutException are thrown in their place. Is this the expected behaviour? If yes, when is HttpRecoverableException thrown? thanks, Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpRecoverableException
Fabio, HttpConnection.ConnectionTimeoutException should have been replaced with ConnectTimeoutException. It's my oversight, for which I'll provide a fix. IOTimeoutException usually is a wrapper for java.io.InterruptedIOException. I guess the name does not adequately reflect the nature of this exception. All read I/O exceptions that occur while a connection is open are (should be re) rethrown as HttpRecoverableException. Please let me know under what circumstances you are getting java.net.SocketTimeoutException. Wire log would be appreciated. I am planning to do some cleaning up on the HttpConnection class. Expect a patch by Monday. Oleg On Thu, 2003-10-30 at 14:09, [EMAIL PROTECTED] wrote: Hi, I'm using the nightly builds version of HttpClient and I have noticed that, when a timeout occurs, neither ConnectTimeoutException nor IOTimeoutException are ever thrown. Instead, HttpConnection.ConnectionTimeoutException and java.net.SocketTimeoutException are thrown in their place. Is this the expected behaviour? If yes, when is HttpRecoverableException thrown? thanks, Fabio - 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]
