Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
On 10 May 2004, at 21:26, Stephen Colebourne wrote: This looks like a very neat solution to the problem to me. The Class.forName worries me a little though, as I believe that its not too happy in class loaders. it should probably try the context classloader first. note: it is *very* important to remember that beanutils is used indirectly by a *very* large user base. (think about the user base for strut and tomcat at the very least.) i'd be *very* likely to veto any changes that risk breaking a release without adequate time for testing. (it took a lot of work to make commons-logging work anywhere near reasonably in complex container environments.) i would definitely prefer a service release which would allow downstream developers to resolve any possible issues with collections 3.0 before moving on to looking at commons-logging. so, i'd strong suggest that any ideas for altering the way that logging works are committed into a branch. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server SimpleHttpServer.java SimpleHttpServerConnection.java
olegk 2004/05/11 13:43:55
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpConnection.java HttpMethod.java
HttpMethodBase.java
httpclient/src/test/org/apache/commons/httpclient
TestNoHost.java
httpclient/src/test/org/apache/commons/httpclient/server
SimpleHttpServer.java
SimpleHttpServerConnection.java
Added: httpclient/src/test/org/apache/commons/httpclient
TestMethodAbort.java
Log:
PR #20288 (httpMethod.abort needed)
Added ability to abort the execution of HTTP methods
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision ChangesPath
1.90 +6 -4
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java
Index: HttpConnection.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -r1.89 -r1.90
--- HttpConnection.java 18 Apr 2004 23:51:34 - 1.89
+++ HttpConnection.java 11 May 2004 20:43:54 - 1.90
@@ -1035,6 +1035,8 @@
/**
* Attempts to shutdown the [EMAIL PROTECTED] Socket}'s output, via
Socket.shutdownOutput()
* when running on JVM 1.3 or higher.
+ *
+ * @deprecated unused
*/
public void shutdownOutput() {
LOG.trace(enter HttpConnection.shutdownOutput());
1.37 +12 -5
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethod.java
Index: HttpMethod.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethod.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- HttpMethod.java 18 Apr 2004 23:51:35 - 1.36
+++ HttpMethod.java 11 May 2004 20:43:54 - 1.37
@@ -33,7 +33,7 @@
import java.io.InputStream;
import org.apache.commons.httpclient.auth.AuthState;
-import org.apache.commons.httpclient.params.*;
+import org.apache.commons.httpclient.params.HttpMethodParams;
/**
* p
@@ -433,6 +433,13 @@
*/
int execute(HttpState state, HttpConnection connection)
throws HttpException, IOException;
+
+/**
+ * Aborts the execution of the HTTP method.
+ *
+ * @see #execute(HttpState, HttpConnection)
+ */
+void abort();
/**
* Recycles the HTTP method so that it can be used again.
1.206 +39 -8
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
Index: HttpMethodBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.205
retrieving revision 1.206
diff -u -r1.205 -r1.206
--- HttpMethodBase.java 8 May 2004 10:12:07 - 1.205
+++ HttpMethodBase.java 11 May 2004 20:43:54 - 1.206
@@ -168,6 +168,9 @@
/** HTTP protocol version used for execution of this method. */
private HttpVersion effectiveVersion = null;
+/** Whether the execution of this method has been aborted */
+private transient boolean aborted = false;
+
// --- Constructors
/**
@@ -917,10 +920,9 @@
if (conn == null) {
throw new IllegalArgumentException(HttpConnection parameter may not be
null);
}
-// TODO: do we care
-//if (hasBeenUsed()) {
-//throw new IllegalStateException(Already used, but not recycled.);
-//}
+if (this.aborted) {
+throw new IllegalStateException(Method has been aborted);
+}
if (!validate()) {
throw new ProtocolException(HttpMethodBase object not valid);
}
@@ -974,6 +976,21 @@
}
/**
+ * Aborts the execution of this method.
+ */
+
+public void abort() {
+if (this.aborted) {
+return;
+}
+this.aborted = true;
+HttpConnection conn = this.responseConnection;
+if (conn != null) {
+conn.close();
+}
+}
+
+/**
* Returns tttrue/tt if the HTTP method has been already [EMAIL PROTECTED]
#execute executed},
* but not [EMAIL PROTECTED] #recycle recycled}.
*
@@ -1004,6 +1021,8 @@
getResponseHeaderGroup().clear();
getResponseTrailerHeaderGroup().clear();
statusLine
cvs commit: jakarta-commons/httpclient release_notes.txt
olegk 2004/05/11 13:48:12 Modified:httpclient release_notes.txt Log: Release notes updated Revision ChangesPath 1.23 +5 -0 jakarta-commons/httpclient/release_notes.txt Index: release_notes.txt === RCS file: /home/cvs/jakarta-commons/httpclient/release_notes.txt,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- release_notes.txt 8 May 2004 10:32:28 - 1.22 +++ release_notes.txt 11 May 2004 20:48:12 - 1.23 @@ -15,6 +15,8 @@ * Support for tunneled HTTP proxies via the ProxyClient + * Ability to abort execution of HTTP methods + (2) Connection management * Support for closing idle connections @@ -47,6 +49,9 @@ Changes on the CVS trunk: - + + * 20288 - Added ability to abort execution of HTTP methods + Contributed by Oleg Kalnichevski olegk at apache.org * 24154 - Socket timeout can be specified at the connection manager, connection or method level Contributed by Oleg Kalnichevski olegk at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Math] Cloning statistics
I'm playing with commons-math to implement a data mining algorithm and I
am having a performance problem.
I am doing running statistics over an ordered set of data, storing the
statistics at each new value I come across. One way of doing this would
be to have an array of SummaryStatistics and do
for (int i = 0; i length; i++)
{
for (int j = i; j length; j++)
{
statsArray[j].addValue(values[i]);
}
}
another way is to do
for (int i = 0; i length; i++)
{
stats.addValue(values[i]);
statsArray[i] = SerializationUtils.clone(stats);
}
A lot of these objects are marked Serializable, but clone methods do not
exist. That's why I use commons-lang SerializationUtils.
Unfortunately, that makes the cloning take up 50% of my runtime because
(de)serialization is expensive.
I will probably patch the statistics classes, implementing enough of
clone() to make me happy. Would you like this patch?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
robert burrell donkin wrote:
On 10 May 2004, at 21:26, Stephen Colebourne wrote:
This looks like a very neat solution to the problem to me. The
Class.forName
worries me a little though, as I believe that its not too happy in class
loaders.
it should probably try the context classloader first.
note: it is *very* important to remember that beanutils is used
indirectly by a *very* large user base. (think about the user base for
strut and tomcat at the very least.) i'd be *very* likely to veto any
changes that risk breaking a release without adequate time for testing.
Hmm, Struts is bad example here because it's already using
commons-logging ;)
(it took a lot of work to make commons-logging work anywhere near
reasonably in complex container environments.)
And I'm worry that this will be the same process but code will be split
across different modules.
One more note - I don't know how many 'server applications' are not
using commons-logging, directly or not. Please, take a look at Gump
email and a list of projects depending on o.a.c.l. All of the projects
depending on those projects depends on o.a.c.l.
Also, some recent RIs from Sun using o.a.c.l.
And for them running 'wrapper' around o.a.c.l will be a waste of
force.
Also, o.a.c.l is probably the biggest success of Jakarta Commons team
and I don't think that such solution is the best in the 'marketing'
terms ('whole world using it so we're going not to use it...').
Just my 2cents,
Tomek
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
Tomasz Pik wrote:
Also, o.a.c.l is probably the biggest success of Jakarta Commons team
and I don't think that such solution is the best in the 'marketing'
terms ('whole world using it so we're going not to use it...').
The fact that many servers already include commons-logging isn't the point.
I typically have at least 10 commons jars in my classpath at all times, but
it isn't fair to assume that everyone else does the same.
Also, I don't think any decision has been made to stop using
commons-logging.
All that is occurring is a conversion of the commons-logging dependency
from mandatory to optional.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
On 11 May 2004, at 21:57, Tomasz Pik wrote:
robert burrell donkin wrote:
On 10 May 2004, at 21:26, Stephen Colebourne wrote:
This looks like a very neat solution to the problem to me. The
Class.forName
worries me a little though, as I believe that its not too happy in
class
loaders.
it should probably try the context classloader first.
note: it is *very* important to remember that beanutils is used
indirectly by a *very* large user base. (think about the user base
for strut and tomcat at the very least.) i'd be *very* likely to veto
any changes that risk breaking a release without adequate time for
testing.
Hmm, Struts is bad example here because it's already using
commons-logging ;)
the point i was trying (but failed) to make was that both tomcat and
struts use beanutils. that's a lot of users.
(it took a lot of work to make commons-logging work anywhere near
reasonably in complex container environments.)
And I'm worry that this will be the same process but code will be split
across different modules.
i'd definitely agree with that.
that's why the key is keeping the bootstrap code very, very simple. all
the sophistication needs to be in the LogFactory implementation. this
may mean generating the bootstrap source from a common template.
One more note - I don't know how many 'server applications' are not
using commons-logging, directly or not. Please, take a look at Gump
email and a list of projects depending on o.a.c.l. All of the projects
depending on those projects depends on o.a.c.l.
Also, some recent RIs from Sun using o.a.c.l.
And for them running 'wrapper' around o.a.c.l will be a waste of
force.
true.
hopefully it wouldn't be a wrapper, just a bit of dependency magic...
Also, o.a.c.l is probably the biggest success of Jakarta Commons team
and I don't think that such solution is the best in the 'marketing'
terms ('whole world using it so we're going not to use it...').
i'm glad someone appreciates it. we went through (political) hell
creating it :)
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] remove dependency on commons-logging
1. if we're going to look at logging again, i'd prefer to think about making beanutils a little more easy to use in a managed environment. this means giving more programmatic control over logging. 2. (for reasons given in a previous mail) i'd prefer it if this goes into a branch rather than the head. 3. i'd prefer a service release for downstream developers to solve any possible problems with commons-collections before looking at logging. logging is a very delicate problem. it's crucial that it's quick, simple and robust. 4. i'd want to be certain that it'd work with tomcat before any changes to logging went into head. - robert On 11 May 2004, at 08:17, Simon Kitching wrote: Hi, As no-one shot down my proposal as posted earlier, here is a proposed patch to beanutils to make commons-logging a completely optional dependency. The Log class is a copy of o.a.c.l.Log, and is intended to be committed to the beanutils cvs tree as o.a.c.l.Log. The LogSource class is intended to be added in o.a.c.beanutils. logging.patch changes all calls to LogFactory.getLog into calls on LogSource.getLog. The build.xml.patch removes commons-logging from the buildfile, as after this patch it is neither a compile-time nor a runtime dependency. I'm expecting comments (maybe screams :-). The only *possible* concern I am aware of about this patch is where multiple libs containing copies of o.a.c.l.Log are used and they have different security policies applied. Cheers, Simon - 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]
cvs commit: jakarta-commons/httpclient/xdocs sslguide.xml
olegk 2004/05/11 14:46:38 Modified:httpclient/xdocs Tag: HTTPCLIENT_2_0_BRANCH sslguide.xml Log: Fixes the problem with SSL guide referring to the code samples in the CVS HEAD instead of 2.0 branch Contributed by Oleg Kalnichevski Revision ChangesPath No revision No revision 1.2.2.3 +3 -3 jakarta-commons/httpclient/xdocs/sslguide.xml Index: sslguide.xml === RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/sslguide.xml,v retrieving revision 1.2.2.2 retrieving revision 1.2.2.3 diff -u -r1.2.2.2 -r1.2.2.3 --- sslguide.xml 15 Apr 2004 21:08:36 - 1.2.2.2 +++ sslguide.xml 11 May 2004 21:46:38 - 1.2.2.3 @@ -174,13 +174,13 @@ ul li - a href=http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/EasySSLProtocolSocketFactory.java?rev=HEAD; + a href=http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/?only_with_tag=HTTPCLIENT_2_0_BRANCH; EasySSLProtocolSocketFactory/a can be used to create SSL connections that allow the target server to authenticate with a self-signed certificate. /li li - a href=http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/StrictSSLProtocolSocketFactory.java?rev=HEAD; + a href=http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/?only_with_tag=HTTPCLIENT_2_0_BRANCH; StrictSSLProtocolSocketFactory/a can be used to create SSL connections that can optionally perform host name verification in order to help preventing man-in-the-middle type of attacks. /li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils] remove dependency on commons-logging
Hi, Sorry to step in late but has anyone considered the use of a generic event callback interface for use in monitoring. Beanutil classes can expose a BeanutilsMonitor interface with methods that are called by the executing code to monitor notable events such as failures and successful operations. A while back Paul Hammant had written a little wiki page about this called NoLogging. Here's a link to it: http://wiki.apache.org/avalon/AvalonNoLogging The use of a callback interface (monitor) was very compelling because it removed any dependency on a logging package. Also the monitor interface is a way for a piece of software to publish those events that are important. Implementations of the monitor interface can then do whatever they like with the event. The most common monitor implementation will simply log the event. It's a bit of a PITA to write monitors for components as an author but you give maximal flexibility to users that will implement different monitors for different circumstances or environments. I have decided to use it while building IoC container independent components within the Eve directory server. I've written a little about the technique here: http://incubator.apache.org/directory/subprojects/eve/components.html The technique is quite useful and keeps code that would otherwise use a logger looking much cleaner. I just thought I'd let you guys know of this option in case it might interest you. There are however some very important guidelines to follow: o If providing monitor adapters print the stack traces of any arguments that are descendents of Throwable. This way at a minimum some notification about errors is given to the developer that just wants to use an adapter for the time being instead of a logging monitor. o Like the Heisenberg Uncertainty Principle your measurements will effect the thing you're measuring so don't spend too much time measuring or don't do anything that would change the execution path of the code (i.e. throwing exceptions). As a matter of fact everything just in case (within a callback) should be surrounded by a try catch on all Throwables. This way you are guaranteed to not drastically affect the code you're monitoring. Hope this is useful to ya if not any feedback on the technique is welcome. I'm sort of new to using it so there may be problems with the approach that I'm unaware of. So far it seems pretty neat. Cheers, Alex -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 11, 2004 5:12 PM To: Jakarta Commons Developers List Subject: Re: [beanutils] remove dependency on commons-logging 1. if we're going to look at logging again, i'd prefer to think about making beanutils a little more easy to use in a managed environment. this means giving more programmatic control over logging. 2. (for reasons given in a previous mail) i'd prefer it if this goes into a branch rather than the head. 3. i'd prefer a service release for downstream developers to solve any possible problems with commons-collections before looking at logging. logging is a very delicate problem. it's crucial that it's quick, simple and robust. 4. i'd want to be certain that it'd work with tomcat before any changes to logging went into head. - robert On 11 May 2004, at 08:17, Simon Kitching wrote: Hi, As no-one shot down my proposal as posted earlier, here is a proposed patch to beanutils to make commons-logging a completely optional dependency. The Log class is a copy of o.a.c.l.Log, and is intended to be committed to the beanutils cvs tree as o.a.c.l.Log. The LogSource class is intended to be added in o.a.c.beanutils. logging.patch changes all calls to LogFactory.getLog into calls on LogSource.getLog. The build.xml.patch removes commons-logging from the buildfile, as after this patch it is neither a compile-time nor a runtime dependency. I'm expecting comments (maybe screams :-). The only *possible* concern I am aware of about this patch is where multiple libs containing copies of o.a.c.l.Log are used and they have different security policies applied. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] remove dependency on commons-logging
Alex Karasulu wrote: Sorry to step in late but has anyone considered the use of a generic event callback interface for use in monitoring. Beanutil classes can expose a BeanutilsMonitor interface with methods that are called by the executing code to monitor notable events such as failures and successful operations. [snip] This sounds interesting, and for lower-level libraries I think it actually makes more sense -- giving more power to the user. For example, I think that beanutils is justified in defining the types of events that occur, but not necessarily in assigning logging levels to these events. For example, sometimes when things aren't working with betwixt, I'll enable debug logging for org.apache.* (forgetting the huge mistake that I'm making) and then I'll be assaulted by millions of statements from betwixt, digester, beanutils, etc. Perhaps this is a bad example, but my point is it would be nice to allow deeper customization of logging, without getting too fancy. However, I'm not sure that everyone will like this sort of thing -- some may think it's a bit too complicated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils] remove dependency on commons-logging
Hi Alex,
On Wed, 2004-05-12 at 09:55, Alex Karasulu wrote:
Hi,
Sorry to step in late but has anyone considered the use of a generic
event callback interface for use in monitoring.
If a library has a couple of major events that it can report, then
callbacks are a nice idea.
However I see logging as something *pervasive*. Libraries like log4j
make logging very quick, with the explicit intent that lots of log calls
are scattered through code and left there in production releases so that
it can be enabled if needed. I suspect you see logging as something that
is done once in every 1000 lines of code?
I think there are a number of major limitations to this Monitor
approach. When I use the verb log below, you can also read this as
report a significant event to a Monitor object via a callback.
(a)
Every object that wants to log needs to have an addMonitor method on it.
And it needs to be *every* object, because otherwise if you want to add
logging later, you need to add the method which can break ABI (on
interfaces at least).
It's not clear whether you suggest having a single Monitor interface
with a generic API, like public void reportEvent(Object event), or
many different Monitor classes, with methods like public void
reportFailedToOpenConfigFile(). If the latter, then API stability is
going to be an even worse issue.
(b)
Code needs to be written to call that addMonitor method, for *every*
object that can log. This is a lot of work. Worse, it exposes the
callback concept to the calling code. Suppose that BeanUtils adds an
addLogListener() method to every class in BeanUtils. Wouldn't every
library or application which uses beanutils then need to be modified to
call those methods?
(c)
What happens if an object wants to log before its addLogListener method
is called?
(d)
Where is the equivalent of:
if (log.isDebugEnabled()) {
// build complex description of problem
}
Ok, you could say that the message building goes on within the callback
method, but in that case sufficient context needs to be passed to that
callback object to allow that to be done, which is more complex, and
probably slower.
The issue you raise in your webpage about wanting to set different
logging behaviours for different instances of some class is simple to
implement with logging:
public void setLog(Log log);
This is equivalent to setting a Monitor with a generic API. However it
also leads to the same issues I list above, so I think it should be
avoided wherever possible.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] remove dependency on commons-logging
On 11 May 2004, at 23:29, Simon Kitching wrote: snip The issue you raise in your webpage about wanting to set different logging behaviours for different instances of some class is simple to implement with logging: public void setLog(Log log); This is equivalent to setting a Monitor with a generic API. However it also leads to the same issues I list above, so I think it should be avoided wherever possible. IMHO setLog is the price paid by OOP library who want to be used by frameworks using (some kind of) IoC. it won't be long before most frameworks use some variation of those ideas which is one reason why i'm keen to see support for this kind of thing. how to support it efficiently is (of course) another question... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] remove dependency on commons-logging
interesting :) (but that's not to say that monitors are the right solution for beanutils) BTW we *really* need to do something about moving our wiki so that we can use it to play around with ideas and designs. maybe i'll have to start a vote on that tomorrow... - robert On 11 May 2004, at 22:55, Alex Karasulu wrote: Hi, Sorry to step in late but has anyone considered the use of a generic event callback interface for use in monitoring. Beanutil classes can expose a BeanutilsMonitor interface with methods that are called by the executing code to monitor notable events such as failures and successful operations. A while back Paul Hammant had written a little wiki page about this called NoLogging. Here's a link to it: http://wiki.apache.org/avalon/AvalonNoLogging The use of a callback interface (monitor) was very compelling because it removed any dependency on a logging package. Also the monitor interface is a way for a piece of software to publish those events that are important. Implementations of the monitor interface can then do whatever they like with the event. The most common monitor implementation will simply log the event. It's a bit of a PITA to write monitors for components as an author but you give maximal flexibility to users that will implement different monitors for different circumstances or environments. I have decided to use it while building IoC container independent components within the Eve directory server. I've written a little about the technique here: http://incubator.apache.org/directory/subprojects/eve/components.html The technique is quite useful and keeps code that would otherwise use a logger looking much cleaner. I just thought I'd let you guys know of this option in case it might interest you. There are however some very important guidelines to follow: o If providing monitor adapters print the stack traces of any arguments that are descendents of Throwable. This way at a minimum some notification about errors is given to the developer that just wants to use an adapter for the time being instead of a logging monitor. o Like the Heisenberg Uncertainty Principle your measurements will effect the thing you're measuring so don't spend too much time measuring or don't do anything that would change the execution path of the code (i.e. throwing exceptions). As a matter of fact everything just in case (within a callback) should be surrounded by a try catch on all Throwables. This way you are guaranteed to not drastically affect the code you're monitoring. Hope this is useful to ya if not any feedback on the technique is welcome. I'm sort of new to using it so there may be problems with the approach that I'm unaware of. So far it seems pretty neat. Cheers, Alex -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 11, 2004 5:12 PM To: Jakarta Commons Developers List Subject: Re: [beanutils] remove dependency on commons-logging 1. if we're going to look at logging again, i'd prefer to think about making beanutils a little more easy to use in a managed environment. this means giving more programmatic control over logging. 2. (for reasons given in a previous mail) i'd prefer it if this goes into a branch rather than the head. 3. i'd prefer a service release for downstream developers to solve any possible problems with commons-collections before looking at logging. logging is a very delicate problem. it's crucial that it's quick, simple and robust. 4. i'd want to be certain that it'd work with tomcat before any changes to logging went into head. - robert On 11 May 2004, at 08:17, Simon Kitching wrote: Hi, As no-one shot down my proposal as posted earlier, here is a proposed patch to beanutils to make commons-logging a completely optional dependency. The Log class is a copy of o.a.c.l.Log, and is intended to be committed to the beanutils cvs tree as o.a.c.l.Log. The LogSource class is intended to be added in o.a.c.beanutils. logging.patch changes all calls to LogFactory.getLog into calls on LogSource.getLog. The build.xml.patch removes commons-logging from the buildfile, as after this patch it is neither a compile-time nor a runtime dependency. I'm expecting comments (maybe screams :-). The only *possible* concern I am aware of about this patch is where multiple libs containing copies of o.a.c.l.Log are used and they have different security policies applied. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/optional/bean-collections/src/test/org/apache/commons/beanutils BeanCollectionsTestSuite.java
rdonkin 2004/05/11 15:45:39
Modified:beanutils/optional/bean-collections build.properties.sample
build.xml project.xml
beanutils/optional/bean-collections/src/test/org/apache/commons/beanutils
BeanCollectionsTestSuite.java
Log:
Added BeanMap from collections. (Thanks Stephen)
Revision ChangesPath
1.2 +1 -0
jakarta-commons/beanutils/optional/bean-collections/build.properties.sample
Index: build.properties.sample
===
RCS file:
/home/cvs/jakarta-commons/beanutils/optional/bean-collections/build.properties.sample,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.properties.sample 10 May 2004 19:54:53 - 1.1
+++ build.properties.sample 11 May 2004 22:45:39 - 1.2
@@ -17,6 +17,7 @@
# The pathname of the collections classes JAR file
commons-collections.jar = ${commons-collections.home}/commons-collections.jar
+commons-collections.jar =
${commons-collections.home}/commons-collections-testframework-3.0-dev.jar
# The home directory for the Commons logging classes distribution
commons-logging.home = ../logging/dist
1.2 +7 -2 jakarta-commons/beanutils/optional/bean-collections/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/beanutils/optional/bean-collections/build.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.xml 10 May 2004 19:55:30 - 1.1
+++ build.xml 11 May 2004 22:45:39 - 1.2
@@ -48,7 +48,11 @@
!-- == Derived Values --
!-- The pathname of the collections classes JAR file --
- property name=commons-collections.jar
value=${commons-collections.home}/commons-collections.jar/
+ property name=commons-collections.jar
value=${commons-collections.home}/commons-collections-3.0-dev.jar/
+
+ !-- The pathname of the collections testframework classes JAR file --
+ property name=commons-collections-testframework.jar
value=${commons-collections.home}/commons-collections-testframework-3.0-dev.jar/
+
!-- The pathname of the logging classes JAR file --
property name=commons-logging.jar
value=${commons-logging.home}/commons-logging.jar/
@@ -118,6 +122,7 @@
pathelement location=${build.home}/tests/
pathelement location=${commons-logging.jar}/
pathelement location=${commons-collections.jar}/
+pathelement location=${commons-collections-testframework.jar}/
pathelement location=${commons-beanutils-core.jar}/
pathelement location=${junit.jar}/
/path
1.2 +7 -0 jakarta-commons/beanutils/optional/bean-collections/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/beanutils/optional/bean-collections/project.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.xml 10 May 2004 19:55:30 - 1.1
+++ project.xml 11 May 2004 22:45:39 - 1.2
@@ -39,5 +39,12 @@
idcommons-beanutils/id
version1.6/version
/dependency
+!-- Test Only --
+dependency
+artifactIdcommons-collections-testframework/artifactId
+groupIdcommons-collections/groupId
+versionSNAPSHOT/version
+/dependency
+
/dependencies
/project
1.2 +2 -2
jakarta-commons/beanutils/optional/bean-collections/src/test/org/apache/commons/beanutils/BeanCollectionsTestSuite.java
Index: BeanCollectionsTestSuite.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/optional/bean-collections/src/test/org/apache/commons/beanutils/BeanCollectionsTestSuite.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- BeanCollectionsTestSuite.java 10 May 2004 20:01:50 - 1.1
+++ BeanCollectionsTestSuite.java 11 May 2004 22:45:39 - 1.2
@@ -48,7 +48,7 @@
suite.addTestSuite(BeanToPropertyValueTransformerTest.class);
suite.addTestSuite(BeanPropertyValueEqualsPredicateTest.class);
suite.addTestSuite(BeanPropertyValueChangeClosureTest.class);
-
+suite.addTestSuite(TestBeanMap.class);
return suite;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/optional/bean-collections/src/java/org/apache/commons/beanutils BeanMap.java
rdonkin 2004/05/11 15:46:13
Added:
beanutils/optional/bean-collections/src/java/org/apache/commons/beanutils
BeanMap.java
Log:
Added BeanMap from collections. (Thanks Stephen)
Revision ChangesPath
1.1
jakarta-commons/beanutils/optional/bean-collections/src/java/org/apache/commons/beanutils/BeanMap.java
Index: BeanMap.java
===
/*
* Copyright 2001-2004 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.beanutils;
import java.beans.BeanInfo;
import java.beans.IntrospectionException;
import java.beans.Introspector;
import java.beans.PropertyDescriptor;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.AbstractMap;
import java.util.AbstractSet;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Set;
import org.apache.commons.collections.list.UnmodifiableList;
import org.apache.commons.collections.keyvalue.AbstractMapEntry;
import org.apache.commons.collections.set.UnmodifiableSet;
import org.apache.commons.collections.Transformer;
/**
* An implementation of Map for JavaBeans which uses introspection to
* get and put properties in the bean.
* p
* If an exception occurs during attempts to get or set a property then the
* property is considered non existent in the Map
*
* @since Commons Collections 1.0
* @version $Revision: 1.1 $ $Date: 2004/05/11 22:46:13 $
*
* @author James Strachan
* @author Stephen Colebourne
*/
public class BeanMap extends AbstractMap implements Cloneable {
private transient Object bean;
private transient HashMap readMethods = new HashMap();
private transient HashMap writeMethods = new HashMap();
private transient HashMap types = new HashMap();
/**
* An empty array. Used to invoke accessors via reflection.
*/
public static final Object[] NULL_ARGUMENTS = {};
/**
* Maps primitive Class types to transformers. The transformer
* transform strings into the appropriate primitive wrapper.
*/
public static HashMap defaultTransformers = new HashMap();
static {
defaultTransformers.put(
Boolean.TYPE,
new Transformer() {
public Object transform( Object input ) {
return Boolean.valueOf( input.toString() );
}
}
);
defaultTransformers.put(
Character.TYPE,
new Transformer() {
public Object transform( Object input ) {
return new Character( input.toString().charAt( 0 ) );
}
}
);
defaultTransformers.put(
Byte.TYPE,
new Transformer() {
public Object transform( Object input ) {
return Byte.valueOf( input.toString() );
}
}
);
defaultTransformers.put(
Short.TYPE,
new Transformer() {
public Object transform( Object input ) {
return Short.valueOf( input.toString() );
}
}
);
defaultTransformers.put(
Integer.TYPE,
new Transformer() {
public Object transform( Object input ) {
return Integer.valueOf( input.toString() );
}
}
);
defaultTransformers.put(
Long.TYPE,
new Transformer() {
public Object transform( Object input ) {
return Long.valueOf( input.toString() );
}
}
);
defaultTransformers.put(
Float.TYPE,
new Transformer() {
public Object transform( Object input ) {
return Float.valueOf( input.toString() );
}
}
);
defaultTransformers.put(
Double.TYPE,
cvs commit: jakarta-commons/beanutils/optional/bean-collections/src/test/org/apache/commons/beanutils TestBeanMap.java
rdonkin 2004/05/11 15:46:26
Added:
beanutils/optional/bean-collections/src/test/org/apache/commons/beanutils
TestBeanMap.java
Log:
Added BeanMap from collections. (Thanks Stephen)
Revision ChangesPath
1.1
jakarta-commons/beanutils/optional/bean-collections/src/test/org/apache/commons/beanutils/TestBeanMap.java
Index: TestBeanMap.java
===
/*
* Copyright 2001-2004 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.beanutils;
import java.io.Serializable;
import java.lang.reflect.Method;
import java.util.Map;
import junit.framework.Test;
import junit.textui.TestRunner;
import org.apache.commons.collections.map.AbstractTestMap;
import org.apache.commons.collections.BulkTest;
/**
* Test cases for BeanMap
*
* @version $Revision: 1.1 $ $Date: 2004/05/11 22:46:26 $
*
* @author Morgan Delagrange
* @author Stephen Colebourne
*/
public class TestBeanMap extends AbstractTestMap {
public TestBeanMap(String testName) {
super(testName);
}
public static void main(String[] args) {
TestRunner.run(suite());
}
public static Test suite() {
return BulkTest.makeSuite(TestBeanMap.class);
}
/*
note to self. The getter and setter methods were generated by copying the
field declarations and using the following regular expression search and
replace:
From:
private \(.*\) some\(.*\);
To:
public \1 getSome\2Value() {
return some\2;
}
public void setSome\2Value(\1 value) {
some\2 = value;
}
Also note: The sample keys and mappings were generated manually.
*/
public static class BeanWithProperties implements Serializable {
private int someInt;
private long someLong;
private double someDouble;
private float someFloat;
private short someShort;
private byte someByte;
private char someChar;
private Integer someInteger;
private String someString;
private Object someObject;
public int getSomeIntValue() {
return someInt;
}
public void setSomeIntValue(int value) {
someInt = value;
}
public long getSomeLongValue() {
return someLong;
}
public void setSomeLongValue(long value) {
someLong = value;
}
public double getSomeDoubleValue() {
return someDouble;
}
public void setSomeDoubleValue(double value) {
someDouble = value;
}
public float getSomeFloatValue() {
return someFloat;
}
public void setSomeFloatValue(float value) {
someFloat = value;
}
public short getSomeShortValue() {
return someShort;
}
public void setSomeShortValue(short value) {
someShort = value;
}
public byte getSomeByteValue() {
return someByte;
}
public void setSomeByteValue(byte value) {
someByte = value;
}
public char getSomeCharValue() {
return someChar;
}
public void setSomeCharValue(char value) {
someChar = value;
}
public String getSomeStringValue() {
return someString;
}
public void setSomeStringValue(String value) {
someString = value;
}
public Integer getSomeIntegerValue() {
return someInteger;
}
public void setSomeIntegerValue(Integer value) {
someInteger = value;
}
public Object getSomeObjectValue() {
return someObject;
}
public void setSomeObjectValue(Object value) {
someObject = value;
}
}
// note to self. The Sample keys were generated by copying the field
// declarations and using the following regular expression search and replace:
//
// From:
Re: [beanutils] remove dependency on commons-logging
Hi Robert, On Wed, 2004-05-12 at 09:11, robert burrell donkin wrote: 1. if we're going to look at logging again, i'd prefer to think about making beanutils a little more easy to use in a managed environment. this means giving more programmatic control over logging. Can you give some more detail? My proposal is not a major change to logging; *all* it does is allow BeanUtils to be used without having commons-logging in the classpath, and allow BeanUtils releases to promise that they will work with any commons-logging version that has a LogFactory class with a getLog(String name) method. And it does this without any changes to the commons-logging library. I thought that this was what people wanted, and was what you yourself suggested in an email a few days ago. 2. (for reasons given in a previous mail) i'd prefer it if this goes into a branch rather than the head. 3. i'd prefer a service release for downstream developers to solve any possible problems with commons-collections before looking at logging. logging is a very delicate problem. it's crucial that it's quick, simple and robust. 4. i'd want to be certain that it'd work with tomcat before any changes to logging went into head. If you think it better to postpone evaluating this patch until after BeanUtils1.7 and Digester1.6 are released, then I'm ok with that. I just thought that as you were putting so much effort into breaking the BeanUtils-Collections dependency you would also be interested in breaking the other lib dependency at the same time. But I would strongly recommend not adding this code on a branch; the only way to know if it works is for it to be used. Put in trunk, GUMP will (presumably) run tomcat unit tests using it, struts developers will use it, etc. As you point out, there are lots of BeanUtils users running the code with potentially weird classloader setups. Put on a branch, this testing will never occur and this patch will just wither away (pun intended). Or we could just drop the concept. It's not something I need personally; I write java server code, where distributing a few extra libraries with my apps is not a significant issue. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP@brutus]: jakarta-commons/commons-logging failed
Hi All, Not sure if this will get sufficient attention without bringing it here, so doing so... Yes, there has been a few changes under the hood in log4j recently. We'll have to chat internally to see what we can do, and get back to you. All hail gump for picking it up. cheers, Paul Smith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] remove dependency on commons-logging
On Wed, 2004-05-12 at 00:53, David Graham wrote: I was reluctantly in favor of copying certain Collections classes as a temporary solution to removing that dependency but I don't see why we want to permanently copy Logging classes to other projects. Commons Logging is an abstraction for Log4j and java.util.logging; now we're going to add yet another abstraction above Commons Logging? That doesn't make any sense to me. I understand your concerns. A layer between libs and commons-logging does seem a little odd at first. It would be nice if commons-logging were so small that it could be copied in its entirety into each project, allowing every project to access any logging library. However that isn't the case. Commons-logging is small and stable, but not small and stable enough for that. Duplication of code *is* a reasonable solution, sometimes. If you wanted to sum up the values in an array of ints, would you find, download and use a library that had that code in it, or would you just write the necessary 3 lines of code? But of course anyone duplicating a complex piece of code like a fourier transform would deserve a good LARTing. It's a grey line. I think duplicating one simple class and one interface in order to avoid a dependency on commons-logging is reasonable. However I'm happy to go with the majority opinion on that; as I said in another email, for the work *I* do with java, bundling commons-logging is not an issue. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] remove dependency on commons-logging
I haven't heard any complaints from the community that commons components are tied to commons-logging so I'm a bit confused about why we need to decouple it. We created logging to isolate us from specific logging packages in the first place. Now we need to decouple from our own library? IMO, the most compelling reasons for decoupling collections from other commons components were: 1. The dependency wasn't really needed 2. So we don't trap users in dependency hell when 2 different commons components use different versions of collections. I don't see either of those benefits in removing a logging dependency. David --- Simon Kitching [EMAIL PROTECTED] wrote: On Wed, 2004-05-12 at 00:53, David Graham wrote: I was reluctantly in favor of copying certain Collections classes as a temporary solution to removing that dependency but I don't see why we want to permanently copy Logging classes to other projects. Commons Logging is an abstraction for Log4j and java.util.logging; now we're going to add yet another abstraction above Commons Logging? That doesn't make any sense to me. I understand your concerns. A layer between libs and commons-logging does seem a little odd at first. It would be nice if commons-logging were so small that it could be copied in its entirety into each project, allowing every project to access any logging library. However that isn't the case. Commons-logging is small and stable, but not small and stable enough for that. Duplication of code *is* a reasonable solution, sometimes. If you wanted to sum up the values in an array of ints, would you find, download and use a library that had that code in it, or would you just write the necessary 3 lines of code? But of course anyone duplicating a complex piece of code like a fourier transform would deserve a good LARTing. It's a grey line. I think duplicating one simple class and one interface in order to avoid a dependency on commons-logging is reasonable. However I'm happy to go with the majority opinion on that; as I said in another email, for the work *I* do with java, bundling commons-logging is not an issue. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] : [primitives] IntHashMap -- A hash map that uses primitive interger for the key rather than objects.
I initially wrote this for Axion. But I think this is a good candidate for commons collection-primitives. I searched around to get similar implementation, but I did not found a complete implementation for the same. Any improvement suggestion will be greatly appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Equalator?
I suggest you simply implement the Comparator interface since it is a
superset of your suggested Equalator interface. Therefore, I would
implement your MetaphoneEqualator as EncodingComparator. The class name
prefix is changed from Metaphone to Encoding since you are not actually
comparing Metaphones, but rather two encodings produced by a single
Metaphone. More generally, you are actually comparing two encodings
produced by a single Encoder:
public class EncodingComparator implements Comparator {
private Encoder encoder;
public EncodingComparator(Encoder encoder) {
if (encoder == null) {
throw new IllegalArgumentExcpetion(encoder is null);
}
this.encoder = encoder;
}
public int compare(Object a, Object b) {
int result = 1;
try {
// TODO: Handle null values (inputs and outputs)?
Object encoding1 = this.encoder.encode(a);
Object encoding2 = this.encoder.encode(b);
result = encoding1.equals(encoding2) ? 0 : 1;
} catch (EncoderException e) {
// TODO: Log this?
}
return result;
}
// TODO: implement equals and hashCode?
}
Note that the EncodingComparator effectively contains no more code than your
suggested MetaphoneEqualator. Further, it leverages an interface that
already exists in the core API.
The only difference in the client code is that rather than using the
MetaphoneEqualator's equals method, you use the EncodingComparator's compare
method and compare the return value to zero in order to determine equality
of the encodings.
-- Chuck
-Original Message-
From: Edelson, Justin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 3:32 PM
To: Jakarta Commons Developers List
Subject: RE: [lang] Equalator?
That could be one implementation of the Equalator interface. Another
trivial impelmetantion might do return (a == b); and be called
IdentityEqualator
The specific case I'm working on is using Metaphone (from codec). The
impelemtatnion of MetaphoneEqualator looks like this:
...
private Metaphone mEncoder = new Metaphone();
...
public boolean equals(Object a, Object b) {
try {
Object encoded0 = mEncoder.encode(a);
Object encoded1 = mEncoder.encode(b);
if (encoded0.equals(encoded1)) {
return true;
} else {
return false;
}
} catch (EncoderException exception) {
return false;
}
}
-Original Message-
From: Hookom, Jacob [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 2:47 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] Equalator?
There's this method on Object called equals... I suppose you could
write a single object called Equalator that does:
Public Boolean equals(object a, object b) {
Return a.equals(b);
}
-Original Message-
From: Edelson, Justin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 1:25 PM
To: Jakarta Commons Developers List
Subject: [lang] Equalator?
I'm writing a few classes that currently implement Comparator, but I
really don't care about comparisons - I just want to use an object to
test equality, ergo Equalator. Does such an interface exist somewhere in
lang (I can't find anything similar).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils] remove dependency on commons-logging
-Original Message- From: matthew.hawthorne [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 11, 2004 6:27 PM To: Jakarta Commons Developers List Subject: Re: [beanutils] remove dependency on commons-logging Alex Karasulu wrote: Sorry to step in late but has anyone considered the use of a generic event callback interface for use in monitoring. Beanutil classes can expose a BeanutilsMonitor interface with methods that are called by the executing code to monitor notable events such as failures and successful operations. [snip] For example, I think that beanutils is justified in defining the types of events that occur, but not necessarily in assigning logging levels to these events. Exactly the logging implementation of the monitor interface would handle the specifics of logging events at the various levels. For example, sometimes when things aren't working with betwixt, I'll enable debug logging for org.apache.* (forgetting the huge mistake that I'm making) and then I'll be assaulted by millions of statements from betwixt, digester, beanutils, etc. Perhaps this is a bad example, but my point is it would be nice to allow deeper customization of logging, without getting too fancy. I think technique is as simple as it can get plus it gives you so much besides just being able to log. However, I'm not sure that everyone will like this sort of thing -- some may think it's a bit too complicated. Hope not :-). It's out there if it takes and it might not but at least it has been considered with the rest of the options. Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils] remove dependency on commons-logging
Sorry to step in late but has anyone considered the use of a generic event callback interface for use in monitoring. If a library has a couple of major events that it can report, then callbacks are a nice idea. However I see logging as something *pervasive*. Libraries like log4j make logging very quick Where does that differ? What Alex seems to be suggesting is that the logging behavior be moved from the component to a helper component. The logging helper (monitor) exposes a higher-level and component-specific semantic. The question appears to be who translates the event into a log item, and calls something to emit that item. In Alex's proposal, it would be the monitor. Every object that wants to log needs to have an addMonitor method on it. That's standard IoC. But propose another way for the object to get its monitor. I don't think that's the key difference. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] TreeList
I was thinking of using AbstractLinkedList as it might save the need to have dedicated TreeList iterator classes, ie. the ones from AbstractLinkedList could be used instead. What is more important is to get the Fadelung code into the CVS version before release 3.1 ;-) Stephen - Original Message - From: Jörg Schmücker [EMAIL PROTECTED] I am sorry, that I did not do the Fädelung-code on the tidied up version. I must admit I am not familiar with the AbstractLinkedList contract. I just checked it. What would be the advantage of doing so? It does not extend the interface/contract just helps implementing it. Am I missing something? Joerg -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, May 10, 2004 10:44 PM To: Jörg Schmücker Cc: Jakarta Commons Developers List Subject: Re: [collections] TreeList I have checked in the version of TreeList that I had been working on (tidied up from your original code). The Fädelung code looks interesting, so should probably replace the checked in code. Also, I think that it might be possible to have TreeList subclass AbstractLinkedList, which would be nice. Stephen - Original Message - From: Jörg Schmücker [EMAIL PROTECTED] Stephen, I have added a fast implementation for iterator() and listIterator() using a thing called Fädelung in German. Please copy the Apache license into the files. Thanks, Joerg -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 05, 2004 1:46 AM To: Jörg Schmücker Cc: Jakarta Commons Developers List Subject: Re: [collections] TreeList The default iterator is picked up from AbstractList. For each next() it uses get(index) on the list to retrieve the element. As you might imagine, ArrayList can easily beat this with a dedicated implementation going straight to the array. The two possible solutions are to have each node in the tree refer to its parent, or to have the iterator dynamically use an ArrayStack to build up the parent structure as it navigates it. I favour the latter if possible. Stephen - Original Message - From: Jörg Schmücker [EMAIL PROTECTED] Can you tell me how the iterator is implemented? Currently, I have not implemented such forward/backward linking to improve iteration performance. Regards, Joerg -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, May 03, 2004 4:00 PM To: Jakarta Commons Developers List Cc: Jörg Schmücker Subject: Re: [collections] TreeList Thanks. Forwarded to commons-dev for reference. I will be checking the class in shortly. It does need a proper iterator implementation, as the default is slow. This can be added later though. Stephen - Original Message - From: Jörg Schmücker [EMAIL PROTECTED] Sorry for the hassle. I am very happy to contribute the code. Next time I will contribute with the standard Apache licence. I am hoping that I'll have the time to finish the tree-based class to implement a ordered subset of a set witht the same order and fast insertion. That was the original reason I started implementing it as a tree. The idea that it will be much faster came to me only during the development. Don't know if it is a standard algorithm, but I did not copy it anywhere. AVL-Trees should not be a problem. Regards, Joerg -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Sunday, May 02, 2004 11:34 AM To: Jörg Schmücker Subject: Re: [collections] TreeList You're essentially stating that you haven't blatently ripped the code off from somewhere else (except standard computer science algorithm books). Also that, if it was written for a company, that the company doesn't claim any ownership. IANAL, but my understanding is that legally you are donating a COPY of your code to Apache that will then be OWNED by Apache. Both you and Apache can then do as they please with the code - in Apache's case release it with commons collections. Effectively, you are saying that you COULD sign http://www.apache.org/licenses/#clas without having to go through the hassle of doing so. BTW, I am only having to mail you this because you didn't submit your original code with an Apache licence. If you had, I would have taken that as the sign of donation! Stephen - Original Message - From: Jörg Schmücker [EMAIL PROTECTED] Stephen, Could you give me a reason, why I should not be in the position to donate the class? I don't think there is one but I just want to make sure. Joerg -Original Message- From: Stephen Colebourne
RE: [beanutils] remove dependency on commons-logging
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 6:29 PM
To: Jakarta Commons Developers List
Subject: RE: [beanutils] remove dependency on commons-logging
Hi Alex,
On Wed, 2004-05-12 at 09:55, Alex Karasulu wrote:
Hi,
Sorry to step in late but has anyone considered the use of a generic
event callback interface for use in monitoring.
If a library has a couple of major events that it can report, then
callbacks are a nice idea.
However I see logging as something *pervasive*. Libraries like log4j
make logging very quick, with the explicit intent that lots of log calls
are scattered through code and left there in production releases so that
it can be enabled if needed. I suspect you see logging as something that
is done once in every 1000 lines of code?
Naw could be every 10 lines, 100 lines whatever depending on the
density of notable events to let the outside world know about.
I think there are a number of major limitations to this Monitor
approach. When I use the verb log below, you can also read this as
report a significant event to a Monitor object via a callback.
log != callback event for monitoring
log == logging implementation of callback interface
(a)
Every object that wants to log needs to have an addMonitor method on it.
And it needs to be *every* object, because otherwise if you want to add
logging later, you need to add the method which can break ABI (on
interfaces at least).
Good point.
It's not clear whether you suggest having a single Monitor interface
with a generic API, like public void reportEvent(Object event), or
many different Monitor classes, with methods like public void
reportFailedToOpenConfigFile(). If the latter, then API stability is
going to be an even worse issue.
The later: i.e. reportFailedToOpenConfigFile( with some relevant args )
(b)
Code needs to be written to call that addMonitor method, for *every*
object that can log. This is a lot of work. Worse, it exposes the
Not necessarily an adapter can be used when a specific monitor is
not set or added et. cetera.
callback concept to the calling code. Suppose that BeanUtils adds an
addLogListener() method to every class in BeanUtils. Wouldn't every
library or application which uses beanutils then need to be modified to
call those methods?
No again this does not need to happen and your example of addLogListener
worries me - I think we're off base a bit. Basically every monitored
class depending on how its used can have either a static or instance method
to get and set a single monitor instance. No need to make it handle more
than one monitor. If need be a Teeing monitor can be created to propagate
events to a bunch of monitors et cetera. But for now presume you can
get/set a monitor. If nothing is set then the default no-op monitor
(adapter) is used internally by the monitored object/class.
(c)
What happens if an object wants to log before its addLogListener method
is called?
Good point then you should have the monitor instance required as
a constructor argument.
(d)
Where is the equivalent of:
if (log.isDebugEnabled()) {
// build complex description of problem
}
That's in the implementation of the monitor interface that is defined
by the software that is monitored. So for example say we have a Foo
class. Foo class has FooMonitor interface. FooMonitor may define the
following methods:
void barAdded( Foo monitored, Bar added ) ;
void barRemoved(Foo monitored, Bar removed ) ;
Then FooMonitor can have an implementation let's say LoggingFooMonitor
that handles the logging like so:
public void barAdded( Foo monitored, Bar added )
{
if ( log.isDebugEnabled() )
{
log.debug( Bar + added + to Foo + monitored ) ;
}
}
Ok, you could say that the message building goes on within the callback
method, but in that case sufficient context needs to be passed to that
callback object to allow that to be done, which is more complex, and
probably slower.
Well theirs an extra call and a stack so yeah it's slower but not really
enough to effect anything.
This is equivalent to setting a Monitor with a generic API. However it
also leads to the same issues I list above, so I think it should be
avoided wherever possible.
No problem at all these are just recommendations I thought I'd
get out there. It's up to you guys who deal with the day in day
out work to determine what's best for you. Good luck with your
efforts.
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [beanutils] remove dependency on commons-logging
On Wed, 2004-05-12 at 13:38, Noel J. Bergman wrote:
Sorry to step in late but has anyone considered the use of a generic
event callback interface for use in monitoring.
If a library has a couple of major events that it can report, then
callbacks are a nice idea.
However I see logging as something *pervasive*. Libraries like log4j
make logging very quick
Where does that differ? What Alex seems to be suggesting is that the
logging behavior be moved from the component to a helper component. The
logging helper (monitor) exposes a higher-level and component-specific
semantic. The question appears to be who translates the event into a log
item, and calls something to emit that item. In Alex's proposal, it would
be the monitor.
Consider a library with 50 classes.
With the current commons logging approach, whether a class logs or not
is an internal matter for that class. Adding or removing logging does
not affect the API of that class. And the code calling the library
doesn't need to care whether logging is used in those classes or not.
With the approach Alex is suggesting, every one of those 50 classes in
the library needs an addMonitor(Monitor m) method on it, and every time
an instance of any of those classes is created, the creator must call
addMonitor(myMonitor) in order to enable logging.
And that's assuming there is a single Monitor interface that is used,
that looks something like:
class Monitor {
public void reportEvent(int level, String msg);
}
If each of the 50 library classes actually has its own Monitor subclass,
with APIs like:
class FooMonitor {
public void reportBadConfigFile();
public void reportInvalidUserName();
}
then the library needs 50 Monitor class definitions.
Or have I misunderstood?
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28918] New: - SoftReferenceObjectPool broken?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28918.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28918
SoftReferenceObjectPool broken?
Summary: SoftReferenceObjectPool broken?
Product: Commons
Version: 1.1 Final
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Pool
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hello,
I have not been able to get SoftReferenceObjectPool to work as expected. Below
you can find a test case that supports this assertion. Technically, when there
is severe memory requirements on the JVM, the objects in the pool should be
garbage collected, but they are not. Even when OutOfMemory exception is caught
and the status of the pool examined, it still contains these objects.
I examined the source code but could not locate any obvious errors. However, I
did find this message:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02174.html
which uses an ObjectHolder for the soft referenced objects. This approach
seems to work, as can be tested by using the code in the post.
Regards,
Vikram
import junit.framework.TestCase;
import junit.framework.TestSuite;
import org.apache.commons.pool.PoolableObjectFactory;
import org.apache.commons.pool.impl.SoftReferenceObjectPool;
import java.util.HashMap;
public class TestSoftRef extends TestCase {
private SoftReferenceObjectPool pool;
public static TestSuite suite() {
return new TestSuite(TestSoftRef.class);
}
public static void main(String[] args) {
String[] testClassName = { TestSoftRef.class.getName() };
junit.textui.TestRunner.main(testClassName);
}
public TestSoftRef(String s) {
super(s);
}
public void testOutOfMemory() throws Exception {
Object obj = pool.borrowObject();
pool.returnObject(obj);
obj = null;
assertEquals(1, pool.getNumIdle());
try {
HashMap map = new HashMap();
int divisor = 15;
for(int i = 0; i 100; i++) {
map.put(new Integer(i), new String(Fred
Flintstone + i));
}
}catch(OutOfMemoryError ex) {
assertEquals(0, pool.getNumIdle());
}
}
public void setUp() throws Exception {
this.pool = new SoftReferenceObjectPool(new
PoolableObjectFactory() {
int counter;
public Object makeObject() { return
String.valueOf(counter++); }
public void destroyObject( Object obj ) {}
public boolean validateObject( Object obj ) { return
true; }
public void activateObject( Object obj ) {}
public void passivateObject( Object obj ){}
});
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: jakarta-commons/commons-logging failed
performed this work: http://cvs.apache.org/builds/gump/nightly/jakarta-commons/commons-logging/gump_work/build_jakarta-commons_commons-logging.html Work Name: build_jakarta-commons_commons-logging (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 2 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/logging] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-xalan2.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-chainsaw-20040511.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-20040511.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-lf5-20040511.jar:/usr/local/gump/public/workspace/avalon-logkit/target/avalon-logkit-20040511.jar- [javac] getLogger().log(FQCN, Priority.INFO, message, t ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:129: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,nulltype) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.WARN, message, null ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:137: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,java.lang.Throwable) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.WARN, message, t ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:145: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,nulltype) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.ERROR, message, null ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:153: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,java.lang.Throwable) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.ERROR, message, t ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:161: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,nulltype) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.FATAL, message, null ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:169: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,java.lang.Throwable) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.FATAL, message, t ); [javac] ^ [javac] 24 errors BUILD FAILED /usr/local/gump/public/workspace/jakarta-commons/logging/build.xml:246: Compile failed; see the compiler error output for details. at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268) at org.apache.tools.ant.Task.perform(Task.java:363) at org.apache.tools.ant.Target.execute(Target.java:321) at org.apache.tools.ant.Target.performTasks(Target.java:348) at org.apache.tools.ant.Project.executeTarget(Project.java:1212) at org.apache.tools.ant.Project.executeTargets(Project.java:1060) at org.apache.tools.ant.Main.runBuild(Main.java:666
Re: [beanutils] remove dependency on commons-logging
I was reluctantly in favor of copying certain Collections classes as a temporary solution to removing that dependency but I don't see why we want to permanently copy Logging classes to other projects. Commons Logging is an abstraction for Log4j and java.util.logging; now we're going to add yet another abstraction above Commons Logging? That doesn't make any sense to me. I'm not a BeanUtils committer but as a user and Commons committer here's my -1. David --- Simon Kitching [EMAIL PROTECTED] wrote: Hi, As no-one shot down my proposal as posted earlier, here is a proposed patch to beanutils to make commons-logging a completely optional dependency. The Log class is a copy of o.a.c.l.Log, and is intended to be committed to the beanutils cvs tree as o.a.c.l.Log. The LogSource class is intended to be added in o.a.c.beanutils. logging.patch changes all calls to LogFactory.getLog into calls on LogSource.getLog. The build.xml.patch removes commons-logging from the buildfile, as after this patch it is neither a compile-time nor a runtime dependency. I'm expecting comments (maybe screams :-). The only *possible* concern I am aware of about this patch is where multiple libs containing copies of o.a.c.l.Log are used and they have different security policies applied. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] remove dependency on commons-logging
David Graham wrote: I was reluctantly in favor of copying certain Collections classes as a temporary solution to removing that dependency but I don't see why we want to permanently copy Logging classes to other projects. Commons Logging is an abstraction for Log4j and java.util.logging; now we're going to add yet another abstraction above Commons Logging? That doesn't make any sense to me. I'm not a BeanUtils committer but as a user and Commons committer here's my -1. I don't see it so much as an abstraction, but instead as the conversion of a dependency from mandatory to optional. If a [beanutils] user doesn't care about logging, they shouldn't have to worry about including commons-logging in the classpath. The solution to this problem may seem a bit strange to some, but I think that it's worth the trouble. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] remove dependency on commons-logging
Converting mandatory dependencies to optional is a key part of solving some of the dilemas with commons. And yes, some solutions will be different from those we would adopt in our day jobs. This solution is neat and simple - if you want logging for beanutils then add commons-logging to your classpath, if you don't want logging then don't add it. Perfect! +1 from commons committer Stephen --- matthew.hawthorne [EMAIL PROTECTED] wrote: David Graham wrote: I was reluctantly in favor of copying certain Collections classes as a temporary solution to removing that dependency but I don't see why we want to permanently copy Logging classes to other projects. Commons Logging is an abstraction for Log4j and java.util.logging; now we're going to add yet another abstraction above Commons Logging? That doesn't make any sense to me. I'm not a BeanUtils committer but as a user and Commons committer here's my -1. I don't see it so much as an abstraction, but instead as the conversion of a dependency from mandatory to optional. If a [beanutils] user doesn't care about logging, they shouldn't have to worry about including commons-logging in the classpath. The solution to this problem may seem a bit strange to some, but I think that it's worth the trouble. +1 - 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]
[email] is email in bugzilla?
I'm trying to find where to submit a patch for email. It doesn't seem to
be in bugzilla.
In any case, I'd like to add a setHostPort(int) method to the
o.a.c.m.Email class. Here's the patch:
Index: Email.java
===
retrieving revision 1.15
diff -u -r1.15 Email.java
--- Email.java 19 Feb 2004 22:38:09 - 1.15
+++ Email.java 11 May 2004 16:11:03 -
@@ -58,6 +58,7 @@
public static final String CONTENT_TYPE = content.type;
public static final String MAIL_HOST = mail.host;
+public static final String MAIL_PORT = mail.smtp.port;
public static final String MAIL_SMTP_FROM = mail.smtp.from;
public static final String MAIL_SMTP_AUTH = mail.smtp.auth;
public static final String MAIL_TRANSPORT_PROTOCOL =
mail.transport.protocol;
@@ -110,6 +111,11 @@
* to get property from system.properties. If still null, quit
*/
private String hostName = null;
+
+/**
+ * The port of the mail server with which to connect.
+ */
+private int hostPort = 25;
/** List of to email adresses */
private ArrayList toList = null;
@@ -258,6 +264,7 @@
properties.setProperty(MAIL_HOST, hostName);
properties.setProperty(MAIL_DEBUG,new
Boolean(this.debug).toString());
+properties.setProperty(MAIL_PORT, +hostPort);
if (this.authenticator!= null)
{
@@ -753,5 +760,15 @@
(InternetAddress[]) aList.toArray(new InternetAddress[0]);
return ia;
+}
+
+/**
+ * Set the port of the outgoing mail server
+ *
+ * @param aHostPort
+ */
+public void setHostPort(int aHostPort)
+{
+this.hostPort = aHostPort;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28902] New: - Minor typoon versioning doc
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28902. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28902 Minor typoon versioning doc Summary: Minor typoon versioning doc Product: Commons Version: unspecified Platform: All URL: http://jakarta.apache.org/commons/releases/versioning.ht ml OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Site AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I found a minor copy and paste typo on the versioning doc: - section Milestone Release Numbers says: Beta releases are denoted by adding If should be: Milestone releases are denoted by adding Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] is email in bugzilla?
On Tue, 11 May 2004, Edelson, Justin wrote:
I'm trying to find where to submit a patch for email. It doesn't seem to
be in bugzilla.
The email component is still in the sandbox, so you should choose
'sandbox' as the component name in Bugzilla, and preferably prefix the
summary with '[email]' to make the actual component clear.
--
Martin Cooper
In any case, I'd like to add a setHostPort(int) method to the
o.a.c.m.Email class. Here's the patch:
Index: Email.java
===
retrieving revision 1.15
diff -u -r1.15 Email.java
--- Email.java19 Feb 2004 22:38:09 - 1.15
+++ Email.java11 May 2004 16:11:03 -
@@ -58,6 +58,7 @@
public static final String CONTENT_TYPE = content.type;
public static final String MAIL_HOST = mail.host;
+public static final String MAIL_PORT = mail.smtp.port;
public static final String MAIL_SMTP_FROM = mail.smtp.from;
public static final String MAIL_SMTP_AUTH = mail.smtp.auth;
public static final String MAIL_TRANSPORT_PROTOCOL =
mail.transport.protocol;
@@ -110,6 +111,11 @@
* to get property from system.properties. If still null, quit
*/
private String hostName = null;
+
+/**
+ * The port of the mail server with which to connect.
+ */
+private int hostPort = 25;
/** List of to email adresses */
private ArrayList toList = null;
@@ -258,6 +264,7 @@
properties.setProperty(MAIL_HOST, hostName);
properties.setProperty(MAIL_DEBUG,new
Boolean(this.debug).toString());
+properties.setProperty(MAIL_PORT, +hostPort);
if (this.authenticator!= null)
{
@@ -753,5 +760,15 @@
(InternetAddress[]) aList.toArray(new InternetAddress[0]);
return ia;
+}
+
+/**
+ * Set the port of the outgoing mail server
+ *
+ * @param aHostPort
+ */
+public void setHostPort(int aHostPort)
+{
+this.hostPort = aHostPort;
}
}
-
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 28906] New: - [email] add hostPort property to Email class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28906. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28906 [email] add hostPort property to Email class Summary: [email] add hostPort property to Email class Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It would be useful (to me at least) for the o.a.c.m.Email class to have a setHostPort(int) method that would allow for a non-standard SMTP port to be easily set. Yes, this can be done with system properties, but this way is easier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28906] - [email] add hostPort property to Email class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28906. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28906 [email] add hostPort property to Email class --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 17:32 --- Created an attachment (id=11512) patch to Email.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] Equalator?
I'm writing a few classes that currently implement Comparator, but I really don't care about comparisons - I just want to use an object to test equality, ergo Equalator. Does such an interface exist somewhere in lang (I can't find anything similar). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Equalator?
There's this method on Object called equals... I suppose you could write a
single object called Equalator that does:
Public Boolean equals(object a, object b) {
Return a.equals(b);
}
-Original Message-
From: Edelson, Justin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 1:25 PM
To: Jakarta Commons Developers List
Subject: [lang] Equalator?
I'm writing a few classes that currently implement Comparator, but I
really don't care about comparisons - I just want to use an object to
test equality, ergo Equalator. Does such an interface exist somewhere in
lang (I can't find anything similar).
-
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: [lang] Equalator?
I think he is might be looking for something like:
Float f = new Float(1.0);
Double d = new Double(1.0);
Equalator.equals(f, d);
and have it return true.
On May 11, 2004, at 11:46 AM, Hookom, Jacob wrote:
There's this method on Object called equals... I suppose you could
write a
single object called Equalator that does:
Public Boolean equals(object a, object b) {
Return a.equals(b);
}
-Original Message-
From: Edelson, Justin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 1:25 PM
To: Jakarta Commons Developers List
Subject: [lang] Equalator?
I'm writing a few classes that currently implement Comparator, but I
really don't care about comparisons - I just want to use an object to
test equality, ergo Equalator. Does such an interface exist somewhere
in
lang (I can't find anything similar).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: jakarta-commons/commons-logging failed
/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/logging] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-xalan2.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-chainsaw-20040511.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-20040511.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-lf5-20040511.jar:/usr/local/gump/public/workspace/avalon-logkit/target/avalon-logkit-20040511.jar- [javac] getLogger().log(FQCN, Priority.INFO, message, t ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:129: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,nulltype) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.WARN, message, null ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:137: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,java.lang.Throwable) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.WARN, message, t ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:145: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,nulltype) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.ERROR, message, null ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:153: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,java.lang.Throwable) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.ERROR, message, t ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:161: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,nulltype) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.FATAL, message, null ); [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java:169: cannot resolve symbol [javac] symbol : method log (java.lang.String,org.apache.log4j.Priority,java.lang.Object,java.lang.Throwable) [javac] location: class org.apache.log4j.Logger [javac] getLogger().log(FQCN, Priority.FATAL, message, t ); [javac] ^ [javac] 24 errors BUILD FAILED /usr/local/gump/public/workspace/jakarta-commons/logging/build.xml:246: Compile failed; see the compiler error output for details. at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268) at org.apache.tools.ant.Task.perform(Task.java:363) at org.apache.tools.ant.Target.execute(Target.java:321) at org.apache.tools.ant.Target.performTasks(Target.java:348) at org.apache.tools.ant.Project.executeTarget(Project.java:1212) at org.apache.tools.ant.Project.executeTargets(Project.java:1060) at org.apache.tools.ant.Main.runBuild(Main.java:666) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.Main.start(Main.java:151) at org.apache.tools.ant.Main.main(Main.java:234) Total time: 2 seconds - To subscribe to this information via syndicated
RE: [lang] Equalator?
You would probably want to piggy back your implementation off of
ConvertUtils
-Original Message-
From: Luke Chastain [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 1:55 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] Equalator?
I think he is might be looking for something like:
Float f = new Float(1.0);
Double d = new Double(1.0);
Equalator.equals(f, d);
and have it return true.
On May 11, 2004, at 11:46 AM, Hookom, Jacob wrote:
There's this method on Object called equals... I suppose you could
write a
single object called Equalator that does:
Public Boolean equals(object a, object b) {
Return a.equals(b);
}
-Original Message-
From: Edelson, Justin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 1:25 PM
To: Jakarta Commons Developers List
Subject: [lang] Equalator?
I'm writing a few classes that currently implement Comparator, but I
really don't care about comparisons - I just want to use an object to
test equality, ergo Equalator. Does such an interface exist somewhere
in
lang (I can't find anything similar).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28912] New: - Connection re-use conflates logical and physical connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28912. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28912 Connection re-use conflates logical and physical connections Summary: Connection re-use conflates logical and physical connections Product: Commons Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Dbcp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] [Let me say up front that you may already know about this, but I couldn't find anything like this in the dev list or the bug DB. I may just be using different terms than you. If so, sorry.] I just debugged a problem with a finalizer closing a connection that had been re-allocated from the pool to a different use, and what this made clear to me is the following: DBCP is pooling physical connections and using them as logical connections. This will cause all sorts of problems like this. First, my terms: A physical connection is a lower-level JDBC Connection object that talks to a database. A logical connection is a user level concept that flows from using getConnection() and continues until the user code invokes close(). (User here means programmer using DBCP.) Physical connections are expensive to establish and so need pooling. But logical connections can be cheap. What I would recommend is that you put an object representing the logical connection between the user and the physical connection. The physical connections would be pooled, but the logical ones would be created during getConnection() to represent the user's notion of a single connection. The logical connection would maintain state for the logical connection, such as isClosed(). Here is an example of code that, while stupid, should work -- it does work in the absence of a pooled connection: Connection conn = getConnection(); conn.executeQuery(query); conn.close(); Thread.sleep(30 * 1000); conn.close(); While dumb, this is exactly what happened to me, except that the delay between close() calls was the delay between the explicit close and when the garbage collector invoked a finalize() method. The problem here is that someone else may have picked up the physical connection after the first clase, and be using it when the second close occurrs. The reason this problem exists is that you are handing me phyiscal connections. If instead you put a logical connection object in the middle, the logical connection object would know that it was closed and the second close would act appropriately (throwing an exception, I think, is correct). This is because the second use of the physical connection would be using a different object implementing Connection with its own state, and so my old Connection object would not be accessing the physical connection any more. In other words, as a user, I should never get my hands on physical connection objects. This reduces the number of ways I can screw up myself or, in this case, others. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Equalator?
That could be one implementation of the Equalator interface. Another
trivial impelmetantion might do return (a == b); and be called
IdentityEqualator
The specific case I'm working on is using Metaphone (from codec). The
impelemtatnion of MetaphoneEqualator looks like this:
...
private Metaphone mEncoder = new Metaphone();
...
public boolean equals(Object a, Object b) {
try {
Object encoded0 = mEncoder.encode(a);
Object encoded1 = mEncoder.encode(b);
if (encoded0.equals(encoded1)) {
return true;
} else {
return false;
}
} catch (EncoderException exception) {
return false;
}
}
-Original Message-
From: Hookom, Jacob [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 2:47 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] Equalator?
There's this method on Object called equals... I suppose you could
write a single object called Equalator that does:
Public Boolean equals(object a, object b) {
Return a.equals(b);
}
-Original Message-
From: Edelson, Justin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 1:25 PM
To: Jakarta Commons Developers List
Subject: [lang] Equalator?
I'm writing a few classes that currently implement Comparator, but I
really don't care about comparisons - I just want to use an object to
test equality, ergo Equalator. Does such an interface exist somewhere in
lang (I can't find anything similar).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate ProbeLocator.java FeedReference.java ResourceExpander.java
burton 2004/05/11 12:53:18
Modified:feedparser/src/java/org/apache/commons/feedparser/locate
FeedReference.java ResourceExpander.java
Added: feedparser/src/java/org/apache/commons/feedparser/locate
ProbeLocator.java
Log:
support for livejournal atom feeds
Revision ChangesPath
1.6 +4 -0
jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate/FeedReference.java
Index: FeedReference.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate/FeedReference.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- FeedReference.java16 Apr 2004 20:20:01 - 1.5
+++ FeedReference.java11 May 2004 19:53:18 - 1.6
@@ -46,5 +46,9 @@
this.resource = resource;
this.type = type;
}
+
+public String toString() {
+return resource;
+}
}
1.3 +32 -1
jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate/ResourceExpander.java
Index: ResourceExpander.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate/ResourceExpander.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ResourceExpander.java 15 Apr 2004 16:57:20 - 1.2
+++ ResourceExpander.java 11 May 2004 19:53:18 - 1.3
@@ -183,6 +183,37 @@
}
/**
+ * Given a URL get the domain name.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Kevin Burton/a
+ */
+public static String getDomain( String resource ) {
+
+String site = getSite( resource );
+
+int firstIndex = -1;
+int indexCount = 0;
+
+int index = site.length();
+
+while ( (index = site.lastIndexOf( ., index-1 )) != -1 ) {
+
+++indexCount;
+
+if ( indexCount == 2 )
+break;
+
+}
+
+int begin = 7; // http:// length
+if ( indexCount = 2 )
+begin = index + 1;
+
+return site.substring( begin, site.length() );
+
+}
+
+/**
* Get the base of this URL. For example if we are given:
*
* http://www.foo.com/directory/index.html
1.1
jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate/ProbeLocator.java
Index: ProbeLocator.java
===
/*
* Copyright 1999,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.feedparser.locate;
import org.apache.commons.feedparser.*;
import java.io.*;
import java.util.*;
import java.util.regex.*;
/**
* Locator which uses Link probing
*
* @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton/a
*/
public class ProbeLocator {
static HashMap probeMapping = new HashMap();
static {
//FIXME: Live Journal has both FOAF and Atom... We need support for BOTH
probeMapping.put( blogspot.com, /atom.xml );
probeMapping.put( livejournal.com, /data/atom );
}
/**
*
* @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton/a
*/
public static final List locate( String resource, String content, FeedList list )
throws Exception {
//FIXME:
String domain = ResourceExpander.getDomain( resource );
if ( probeMapping.containsKey( domain ) ) {
String mapping = (String)probeMapping.get( domain );
String href = resource;
if ( href.endsWith( / ) )
href = href.substring( 0, href.length() - 1 );
href += mapping;
FeedReference feedReference = new FeedReference( href,
DiscoveryLocator.ATOM_MEDIA_TYPE );
list.add( feedReference );
cvs commit: jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate ProbeLocator.java
burton 2004/05/11 12:54:27
Modified:feedparser/src/java/org/apache/commons/feedparser/locate
ProbeLocator.java
Log:
changed to atom probe mapping
Revision ChangesPath
1.2 +5 -5
jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate/ProbeLocator.java
Index: ProbeLocator.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/locate/ProbeLocator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ProbeLocator.java 11 May 2004 19:53:18 - 1.1
+++ ProbeLocator.java 11 May 2004 19:54:27 - 1.2
@@ -29,13 +29,13 @@
*/
public class ProbeLocator {
-static HashMap probeMapping = new HashMap();
+static HashMap atomProbeMapping = new HashMap();
static {
//FIXME: Live Journal has both FOAF and Atom... We need support for BOTH
-probeMapping.put( blogspot.com, /atom.xml );
-probeMapping.put( livejournal.com, /data/atom );
+atomProbeMapping.put( blogspot.com, /atom.xml );
+atomProbeMapping.put( livejournal.com, /data/atom );
}
@@ -50,9 +50,9 @@
String domain = ResourceExpander.getDomain( resource );
-if ( probeMapping.containsKey( domain ) ) {
+if ( atomProbeMapping.containsKey( domain ) ) {
-String mapping = (String)probeMapping.get( domain );
+String mapping = (String)atomProbeMapping.get( domain );
String href = resource;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20288] - httpMethod.abort needed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=20288. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=20288 httpMethod.abort needed [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 20:46 --- Patch committed with the changes suggested by Mike Sample Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HTTP 302 Console output handle question
Hello all! I'm currently developing an application that uses the HTTPClient library. I've found that whilst using it to return the status codes of URI's that when it encouters a 302 return code it also gives out additional information on the console as well: 10-May-2004 12:32:46 org.apache.commons.httpclient.HttpMethodBase checkValidRedirect WARNING: Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host www.bgis.gov.bb to www.barbados.gov.bb is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBa se.java:1243) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMet hodBase.java:1191) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.ja va:977) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:109 5) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:675) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529) at URLStatusCheck.run(URLStatusCheck.java:57) at FrontGUI$TimerListen.actionPerformed(FrontGUI.java:292) at javax.swing.Timer.fireActionPerformed(Unknown Source) at javax.swing.Timer$DoPostEvent.run(Unknown Source) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) 10-May-2004 12:32:46 org.apache.commons.httpclient.HttpMethodBase processRedirectResponse WARNING: Invalid Redirect URI from: http://www.bgis.gov.bb:80/ to: http://www.barbados.gov.bb/bgis.htm My question is, how do I get a handle on this output within in my code? Since I want to be able to display to the end user the redirected website that they should be referencing to. The website below talks somthing about logging, but again I have no idea how to use it: http://jakarta.apache.org/commons/httpclient/logging.html Thanks for you time! Cheers, Saad. The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Energis in partnership with MessageLabs. On leaving the GSi this email was certified virus-free - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP 302 Console output handle question
Mahamood, Saad (SD) wrote: org.apache.commons.httpclient.HttpException: Redirect from host www.bgis.gov.bb to www.barbados.gov.bb is not supported WARNING: Invalid Redirect URI from: http://www.bgis.gov.bb:80/ to: http://www.barbados.gov.bb/bgis.htm My question is, how do I get a handle on this output within in my code? Since I want to be able to display to the end user the redirected website that they should be referencing to. Please read: http://jakarta.apache.org/commons/httpclient/redirects.html The website below talks somthing about logging, but again I have no idea how to use it: Please refer to the Commons Logging and the Log4J websites. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28645] - Move Content-Type to the RequestEntity
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28645. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28645 Move Content-Type to the RequestEntity --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 14:42 --- Created an attachment (id=11511) Patch (take 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28645] - Move Content-Type to the RequestEntity
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28645. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28645 Move Content-Type to the RequestEntity --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 14:45 --- I tweaked StringRequestEntity(String, String, String) constructor a little to make it parse out the charset attribute out of the content type if not charset parameter explicitly specified Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20288] - httpMethod.abort needed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=20288. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=20288 httpMethod.abort needed --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 14:47 --- If nobody complains loudly I'll commit the patch tonight (~ 20:00 GMT) Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][RESULT] Migrate HttpClient issue tracking from Bugzilla to Jira
HttpClient project voted in favour of migration from Bugzilla to Jira +1 votes - Jeff Dever jsdever -at- apache.org Ortwin Glück oglueck -at -apache.org Adrian Sutton adrian -at- apache.org Oleg Kalnichevski olegk -at- apache.org Michael Becke mbecke -at- apache.org *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20288] - httpMethod.abort needed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=20288. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=20288 httpMethod.abort needed --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 16:37 --- Oleg, if the abort request comes from a different thread than the code that acts on the abort flag (probably does) then you may want the 'aborted' boolean field to be volatile so it'll get updated immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20288] - httpMethod.abort needed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=20288. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=20288 httpMethod.abort needed --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 16:53 --- Even though there are enough people out there who claim volatile variable implementation to be completely broken in many JDKs, and even though there's no harm in calling abort multiple times, you are completely right. I'll mark aborted flag as volatile before committing the patch Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][RESULT] Migrate HttpClient issue tracking from Bugzilla to Jira
Folks I have filed a request with the infrastructure to migrate HttpClient issue tracking from Bugzilla to Jira http://nagoya.apache.org/jira/browse/INFRA-74 I hope we'll get luckier this time around Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][RESULT] Migrate HttpClient issue tracking from Bugzilla to Jira
Looks like you will indeed get luckier, the status on the report says: Comment by Serge Knystautas [11/May/04 10:24 AM] [ Permlink ] I should be able to get this migrated by tomorrow. Thanks, Sam On Tuesday, May 11, 2004, at 01:22 PM, Kalnichevski, Oleg wrote: Folks I have filed a request with the infrastructure to migrate HttpClient issue tracking from Bugzilla to Jira http://nagoya.apache.org/jira/browse/INFRA-74 I hope we'll get luckier this time around Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - 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 28645] - Move Content-Type to the RequestEntity
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28645. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28645 Move Content-Type to the RequestEntity --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 17:42 --- Hi Oleg, This looks good to me... I have only one other item to add. I think we also wanted to add the charset to the content-type, if it was missing. I have a version of StringRequestEntity at home that does this, which I will attach tonight. Other than this change, I think the patch is ready to go. Any objections if I apply tonight? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28645] - Move Content-Type to the RequestEntity
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28645. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28645 Move Content-Type to the RequestEntity --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 18:18 --- None from me. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
