Re: [jexl] how to access properties of nested java dataobject
Clouduser,
(that doesn't taste like a name),
provided a is in context of type A and class A has a getter getB() then ${A.b}
gives you the return of getB().
That's how I always accessed nested java objects.
I don't understand your XML-example though... at least not its relevance for
jexl.
Can you maybe say which language it is in?
paul
On 25 oct. 2010, at 04:05, cloudsuser cloudsuser wrote:
Using the syntax ${status} as defined below i can able to access the value
of status form JavaBeanObject(A)
column name=STATUS type=string
value${status}/value
/column
But how to get the value of nested bean object.Example...
public class A {
private String status;
private B b;
.
..
}
How to get the value of b.getStatus(); ? Need to replace
${status} to ${b.status}
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Daemon 1.0.4 based on RC1
-- From: Mladen Turk mt...@apache.org Sent: Thursday, October 21, 2010 12:57 AM To: Commons Developers List dev@commons.apache.org Subject: [VOTE] Release Daemon 1.0.4 based on RC1 Hi, Commons Daemon 1.0.4 RC1 release is available for testing at: http://people.apache.org/~mturk/daemon/ The SVN tag is: https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_4_RC1 (If voted will be renamed to COMMONS_DAEMON_1_0_4) So here is the vote: [X] +1 [ ] =0 [ ] -1 Vote is open for 72 hours. (Well since there's a weekend in between, till Monday noon GMT) Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Daemon 1.0.4 based on RC1
On 10/21/10 3:57 AM, Mladen Turk wrote: Hi, Commons Daemon 1.0.4 RC1 release is available for testing at: http://people.apache.org/~mturk/daemon/ The SVN tag is: https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_4_RC1 (If voted will be renamed to COMMONS_DAEMON_1_0_4) So here is the vote: [ ] +1 [ ] =0 [ ] -1 Vote is open for 72 hours. (Well since there's a weekend in between, till Monday noon GMT) Regards +1 Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Reusing Config
Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good way to do that =) Cheers, S Hi Steven, No offense even considered from this end :) I'm glad we are going through this exercise. This will improve the software I am sure. Gary On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory ggreg...@seagullsoftware.comwrote: -Original Message- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Thursday, October 21, 2010 06:29 To: Commons Developers List Subject: Re: [pool] Reusing Config On 10/21/10, Simone Tripodi simone.trip...@gmail.com wrote: it seems you've been doing a very good work, the only thing I *suggest* is * simplifying the mutable/immutable interfaces, one interface for already known common (im)mutable fields should be enough; * adding/renaming the interfaces with the PoolName`MBean` postfix to be ready for JMX support; btw it seems you're now much more deep inside the topic than me ;) WDYT? Simo Sorry I have been a little slow on this. I will have a careful look this eve. Based on a very quick review, I am +1 on the idea and approach to separate mutable / immutable. Also +1 for JMX support. Two quick things to keep top of mind: 1. Please make sure not to lose documentation. Whatever is documented today in protected field / internal getters / setters docs needs to be carried forward. Check. I did not check as I refactored that Javadocs were in the right places. That would be a requirement for a real patch. I only meant this as an experiment that went a lot further than I thought. 2. Somewhat related - I am fine just plowing ahead for now using existing API concepts, but some of those concepts are anachronistic or broken, IMO, so we may later decide to revamp much of the accounting aspects of the API. That we should and will discuss on other threads. One thing that might be good to think about at this point, however, is getting rid of primitive properties (we started that with whenExhaustedAction). I think there is a DBCP issue on this raised by Dain a couple of years ago. It would be nice to track this someplace, I am not sure if Javadoc is the right place. Gary Thanks all for moving this along! Phil http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Oct 21, 2010 at 8:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Simone Tripodi [mailto:simone.trip...@gmail.com] Sent: Wednesday, October 20, 2010 22:41 To: Commons Developers List Subject: Re: [pool] Reusing Config Hi Gary! unfortunately the link replied with 404 code, can you give me please the issue ID? It's https://issues.apache.org/jira/browse/POOL-173 I've updated the diff file a couple of times since my initial msg. Gary Many thanks in advance, have a nice day!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Oct 21, 2010 at 12:16 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: Hi Simone, Please see my experiment in progress here https://issues.apache.org/jira/secure/attachment/12457710/pool2config.diff Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA Tel: +1.404.760.1560 Email: ggreg...@seagullsoftware.com Web: seagull.rocketsoftware.com -Original Message- From: Simone Tripodi
Re: [RESULT] was [VOTE] Release Daemon 1.0.4 based on RC1
Mladen Turk wrote: With my vote we have 5 binding votes. (Sebastian, Niall, Phil, Bill and I) You had 6: http://thread.gmane.org/gmane.comp.jakarta.commons.devel/116173/focus=116189 - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT] was [VOTE] Release Daemon 1.0.4 based on RC1
On 10/25/2010 02:42 PM, Jörg Schaible wrote: Mladen Turk wrote: With my vote we have 5 binding votes. (Sebastian, Niall, Phil, Bill and I) You had 6: http://thread.gmane.org/gmane.comp.jakarta.commons.devel/116173/focus=116189 Sorry I was automatically rule out non @apache.org address well, actually I have a TB filter for that, cause just cannot memorize all 30+ PMC members :) Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Reusing Config
Hi Simone, You have two +1's waiting for you in the JIRA comments =) My comments from tracker: I took a look at this last night but didn't get a chance to comment =) I like the patch, I believe this does indeed satisfy the issue. One question I have, since we're eliminating the primitive configuration properties within the pool/factory classes, we're making the Config objects publicly accessible, and possibly accessing through JMX is the idea of making the Config objects thread-safe. This would certainly reduce the need to have to externally synchronize (and possibly introduce bugs) every time. Another issue we probably need to open another ticket for is to deprecate the constructors we've eliminated in 1.5. Last suggestion/question is about making inner (public static final) Builder pattern classes within the concrete Config classes (and possibly defining an abstract T extends Abstract*Config create() method in the Abstract class). This would further simplify the programmatic creation of the Config classes. Thoughts? +1 on Simones patch...we can add any of the above after it has been committed. Respectfully, Steve On Mon, Oct 25, 2010 at 8:36 AM, Simone Tripodi simone.trip...@gmail.comwrote: Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/http://people.apache.org/%7Esimonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good way to do that =) Cheers, S Hi Steven, No offense even considered from this end :) I'm glad we are going through this exercise. This will improve the software I am sure. Gary On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory ggreg...@seagullsoftware.comwrote: -Original Message- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Thursday, October 21, 2010 06:29 To: Commons Developers List Subject: Re: [pool] Reusing Config On 10/21/10, Simone Tripodi simone.trip...@gmail.com wrote: it seems you've been doing a very good work, the only thing I *suggest* is * simplifying the mutable/immutable interfaces, one interface for already known common (im)mutable fields should be enough; * adding/renaming the interfaces with the PoolName`MBean` postfix to be ready for JMX support; btw it seems you're now much more deep inside the topic than me ;) WDYT? Simo Sorry I have been a little slow on this. I will have a careful look this eve. Based on a very quick review, I am +1 on the idea and approach to separate mutable / immutable. Also +1 for JMX support. Two quick things to keep top of mind: 1. Please make sure not to lose documentation. Whatever is documented today in protected field / internal getters / setters docs needs to be carried forward. Check. I did not check as I refactored that Javadocs were in the right places. That would be a requirement for a real patch. I only meant this as an experiment that went a lot further than I thought. 2. Somewhat related - I am fine just plowing ahead for now using existing API concepts, but some of those concepts are anachronistic or broken, IMO, so we may later decide to revamp much of the accounting aspects of the API. That we should and will discuss on other threads. One thing that might be good to think about at this point, however, is getting rid of primitive properties (we started that with whenExhaustedAction). I think there is a DBCP issue on this raised by Dain a couple of years ago. It would be nice to track this someplace, I am not sure if Javadoc is the right place. Gary Thanks all
[io] missing java.io.PrintWriter.close() in org.apache.commons.io.testtools.FileBasedTestCase.checkWrite()
Dear Apache Commons IO developers,
I found there might be a close method missing in the source code of test cases,
which may be an issue.
No patch seems to be applied till revision 1026932.
How do you guys think?
The original code here is:
In io/trunk/src/test/java/org/apache/commons/io/testtools/FileBasedTestCase.java
Line 203-223 (revision 1026932)
protected void checkWrite(OutputStream output) throws Exception {
try {
new java.io.PrintStream(output).write(0);
} catch (Throwable t) {
throw new AssertionFailedError(
The copy() method closed the stream
+ when it shouldn't have.
+ t.getMessage());
}
}
protected void checkWrite(Writer output) throws Exception {
try {
new java.io.PrintWriter(output).write('a');
} catch (Throwable t) {
throw new AssertionFailedError(
The copy() method closed the stream
+ when it shouldn't have.
+ t.getMessage());
}
}
The java.io.PrintWriter is initialized without being closed after use. So does
the java.io.PrintStream instance.
Thanks Best regards,
Huxing
Re: [pool] Reusing Config
Hi Steven, very sorry to have missed the Jira notifications, just checked now after read your email. Sorry! :( I thought the idea was adding JMX support directly on factory/pool and not on Configuration, btw not being JMX expert this will be a good chance to learn... I'll fill a new Jira issue for adding thread safety support on configuration classes, and start to study how to do it in the best way. I like the Builder idea, my +1 for that, take it in consideration as already done :P Have a nice day and thanks for the feedbacks! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Oct 25, 2010 at 3:06 PM, Steven Siebert smsi...@gmail.com wrote: Hi Simone, You have two +1's waiting for you in the JIRA comments =) My comments from tracker: I took a look at this last night but didn't get a chance to comment =) I like the patch, I believe this does indeed satisfy the issue. One question I have, since we're eliminating the primitive configuration properties within the pool/factory classes, we're making the Config objects publicly accessible, and possibly accessing through JMX is the idea of making the Config objects thread-safe. This would certainly reduce the need to have to externally synchronize (and possibly introduce bugs) every time. Another issue we probably need to open another ticket for is to deprecate the constructors we've eliminated in 1.5. Last suggestion/question is about making inner (public static final) Builder pattern classes within the concrete Config classes (and possibly defining an abstract T extends Abstract*Config create() method in the Abstract class). This would further simplify the programmatic creation of the Config classes. Thoughts? +1 on Simones patch...we can add any of the above after it has been committed. Respectfully, Steve On Mon, Oct 25, 2010 at 8:36 AM, Simone Tripodi simone.trip...@gmail.comwrote: Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/http://people.apache.org/%7Esimonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good way to do that =) Cheers, S Hi Steven, No offense even considered from this end :) I'm glad we are going through this exercise. This will improve the software I am sure. Gary On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory ggreg...@seagullsoftware.comwrote: -Original Message- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Thursday, October 21, 2010 06:29 To: Commons Developers List Subject: Re: [pool] Reusing Config On 10/21/10, Simone Tripodi simone.trip...@gmail.com wrote: it seems you've been doing a very good work, the only thing I *suggest* is * simplifying the mutable/immutable interfaces, one interface for already known common (im)mutable fields should be enough; * adding/renaming the interfaces with the PoolName`MBean` postfix to be ready for JMX support; btw it seems you're now much more deep inside the topic than me ;) WDYT? Simo Sorry I have been a little slow on this. I will have a careful look this eve. Based on a very quick review, I am +1 on the idea and approach to separate mutable / immutable. Also +1 for JMX support. Two quick things to keep top of mind: 1. Please make sure not to lose documentation. Whatever is documented today in protected field / internal getters / setters docs needs to be carried forward. Check. I did not check as I refactored that Javadocs were in the right places. That would be a requirement for a real patch. I only meant this as an experiment that went a
Re: [pool] Reusing Config
Simone, I'm sorry I'm confusing, so many thoughts going though my mind =) yes, I think the best approach is to provide a separate class for the JMX...but I'm thinking that doing a private inner class (non-static) in each pool would be the cleanest way to do so. This way, the MBean (instance) would have direct access to both the config values (read/write) as well as the ability to invoke pool methods (such as getNumwaiters(), POOL-159). This would significantly cut down on the bootstrapping of having to register the config and pool with the MBean. Once I get home, I'll attach a JMX patch to POOL-172 using your latest commit. I noticed your two JIRA tickets for the concurrency and builder patternshould one be submitted to add the @deprecated tag to the 1.5 API for the various classes, methods, and constructors we're blowing away? On Mon, Oct 25, 2010 at 9:30 AM, Simone Tripodi simone.trip...@gmail.comwrote: Hi Steven, very sorry to have missed the Jira notifications, just checked now after read your email. Sorry! :( I thought the idea was adding JMX support directly on factory/pool and not on Configuration, btw not being JMX expert this will be a good chance to learn... I'll fill a new Jira issue for adding thread safety support on configuration classes, and start to study how to do it in the best way. I like the Builder idea, my +1 for that, take it in consideration as already done :P Have a nice day and thanks for the feedbacks! Simo http://people.apache.org/~simonetripodi/http://people.apache.org/%7Esimonetripodi/ http://www.99soft.org/ On Mon, Oct 25, 2010 at 3:06 PM, Steven Siebert smsi...@gmail.com wrote: Hi Simone, You have two +1's waiting for you in the JIRA comments =) My comments from tracker: I took a look at this last night but didn't get a chance to comment =) I like the patch, I believe this does indeed satisfy the issue. One question I have, since we're eliminating the primitive configuration properties within the pool/factory classes, we're making the Config objects publicly accessible, and possibly accessing through JMX is the idea of making the Config objects thread-safe. This would certainly reduce the need to have to externally synchronize (and possibly introduce bugs) every time. Another issue we probably need to open another ticket for is to deprecate the constructors we've eliminated in 1.5. Last suggestion/question is about making inner (public static final) Builder pattern classes within the concrete Config classes (and possibly defining an abstract T extends Abstract*Config create() method in the Abstract class). This would further simplify the programmatic creation of the Config classes. Thoughts? +1 on Simones patch...we can add any of the above after it has been committed. Respectfully, Steve On Mon, Oct 25, 2010 at 8:36 AM, Simone Tripodi simone.trip...@gmail.comwrote: Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/http://people.apache.org/%7Esimonetripodi/ http://people.apache.org/%7Esimonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good way to do that =) Cheers, S Hi Steven, No offense even considered from this end :) I'm glad we are going through this exercise. This will improve the software I am sure. Gary On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory ggreg...@seagullsoftware.comwrote: -Original Message- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Thursday, October 21, 2010 06:29 To: Commons Developers List Subject: Re: [pool]
Re: [pool] Reusing Config
Hi Steven :) thanks for the explanation, as far as I understand there are a lot of things I can learn from you about JMX so I started feeling impatient to see your commits :P I don't think we should mark with @Deprecate removed ctors, classes are now living in a fresh new package so, as user, I wouldn't expect retro-compatibility at all. When upgrading a major revision, I expect a completely (or partially, in that case) new version of the library... maybe I'm wrong but my instinct suggests me a 2.0 version could be even a completely rewrite of the 1.5. BTW that's just my opinion :P Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Oct 25, 2010 at 3:51 PM, Steven Siebert smsi...@gmail.com wrote: Simone, I'm sorry I'm confusing, so many thoughts going though my mind =) yes, I think the best approach is to provide a separate class for the JMX...but I'm thinking that doing a private inner class (non-static) in each pool would be the cleanest way to do so. This way, the MBean (instance) would have direct access to both the config values (read/write) as well as the ability to invoke pool methods (such as getNumwaiters(), POOL-159). This would significantly cut down on the bootstrapping of having to register the config and pool with the MBean. Once I get home, I'll attach a JMX patch to POOL-172 using your latest commit. I noticed your two JIRA tickets for the concurrency and builder patternshould one be submitted to add the @deprecated tag to the 1.5 API for the various classes, methods, and constructors we're blowing away? On Mon, Oct 25, 2010 at 9:30 AM, Simone Tripodi simone.trip...@gmail.comwrote: Hi Steven, very sorry to have missed the Jira notifications, just checked now after read your email. Sorry! :( I thought the idea was adding JMX support directly on factory/pool and not on Configuration, btw not being JMX expert this will be a good chance to learn... I'll fill a new Jira issue for adding thread safety support on configuration classes, and start to study how to do it in the best way. I like the Builder idea, my +1 for that, take it in consideration as already done :P Have a nice day and thanks for the feedbacks! Simo http://people.apache.org/~simonetripodi/http://people.apache.org/%7Esimonetripodi/ http://www.99soft.org/ On Mon, Oct 25, 2010 at 3:06 PM, Steven Siebert smsi...@gmail.com wrote: Hi Simone, You have two +1's waiting for you in the JIRA comments =) My comments from tracker: I took a look at this last night but didn't get a chance to comment =) I like the patch, I believe this does indeed satisfy the issue. One question I have, since we're eliminating the primitive configuration properties within the pool/factory classes, we're making the Config objects publicly accessible, and possibly accessing through JMX is the idea of making the Config objects thread-safe. This would certainly reduce the need to have to externally synchronize (and possibly introduce bugs) every time. Another issue we probably need to open another ticket for is to deprecate the constructors we've eliminated in 1.5. Last suggestion/question is about making inner (public static final) Builder pattern classes within the concrete Config classes (and possibly defining an abstract T extends Abstract*Config create() method in the Abstract class). This would further simplify the programmatic creation of the Config classes. Thoughts? +1 on Simones patch...we can add any of the above after it has been committed. Respectfully, Steve On Mon, Oct 25, 2010 at 8:36 AM, Simone Tripodi simone.trip...@gmail.comwrote: Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/http://people.apache.org/%7Esimonetripodi/ http://people.apache.org/%7Esimonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once
[VFS] Softening the exceptions...
What do you folks think about making the exceptions extend RuntimeException in 2.0? I really find it tedious to do try/catch everywhere I want to ask a FileObject something (like if it exists or not). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
+1 on this issue. I use VFS on a couple projects and this is always a bit burdensome, and on several occasions have indeed caught and rethrew RuntimeExceptions. Even if we can't/shouldn't soften them, what about typing them to be more specific? Having every method throwing a FileSystemException isn't always the most helpful =) Steve On Mon, Oct 25, 2010 at 10:46 AM, James Carman ja...@carmanconsulting.comwrote: What do you folks think about making the exceptions extend RuntimeException in 2.0? I really find it tedious to do try/catch everywhere I want to ask a FileObject something (like if it exists or not). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Reusing Config
On 10/25/10 10:51 AM, Steven Siebert wrote: Simo, You make a good point, especially with the groupId/package change. POOL-169 did implement some deprecations for changes from 1.5 to 2.0, so this isn't without precedent and consistency (even for the sake of consistency in commons-* subprojects, IMO) is important. Honestly, I could go either way...just wanted to make sure it was considered =) I agree with both of you. Probably best to give the signal, consistently with what we have been doing up to now. More information to help people plan for the upgrade is better. Phil S On Mon, Oct 25, 2010 at 10:02 AM, Simone Tripodi simone.trip...@gmail.comwrote: Hi Steven :) thanks for the explanation, as far as I understand there are a lot of things I can learn from you about JMX so I started feeling impatient to see your commits :P I don't think we should mark with @Deprecate removed ctors, classes are now living in a fresh new package so, as user, I wouldn't expect retro-compatibility at all. When upgrading a major revision, I expect a completely (or partially, in that case) new version of the library... maybe I'm wrong but my instinct suggests me a 2.0 version could be even a completely rewrite of the 1.5. BTW that's just my opinion :P Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Oct 25, 2010 at 3:51 PM, Steven Siebertsmsi...@gmail.com wrote: Simone, I'm sorry I'm confusing, so many thoughts going though my mind =) yes, I think the best approach is to provide a separate class for the JMX...but I'm thinking that doing a private inner class (non-static) in each pool would be the cleanest way to do so. This way, the MBean (instance) would have direct access to both the config values (read/write) as well as the ability to invoke pool methods (such as getNumwaiters(), POOL-159). This would significantly cut down on the bootstrapping of having to register the config and pool with the MBean. Once I get home, I'll attach a JMX patch to POOL-172 using your latest commit. I noticed your two JIRA tickets for the concurrency and builder patternshould one be submitted to add the @deprecated tag to the 1.5 API for the various classes, methods, and constructors we're blowing away? On Mon, Oct 25, 2010 at 9:30 AM, Simone Tripodi simone.trip...@gmail.comwrote: Hi Steven, very sorry to have missed the Jira notifications, just checked now after read your email. Sorry! :( I thought the idea was adding JMX support directly on factory/pool and not on Configuration, btw not being JMX expert this will be a good chance to learn... I'll fill a new Jira issue for adding thread safety support on configuration classes, and start to study how to do it in the best way. I like the Builder idea, my +1 for that, take it in consideration as already done :P Have a nice day and thanks for the feedbacks! Simo http://people.apache.org/~simonetripodi/ http://people.apache.org/%7Esimonetripodi/ http://www.99soft.org/ On Mon, Oct 25, 2010 at 3:06 PM, Steven Siebertsmsi...@gmail.com wrote: Hi Simone, You have two +1's waiting for you in the JIRA comments =) My comments from tracker: I took a look at this last night but didn't get a chance to comment =) I like the patch, I believe this does indeed satisfy the issue. One question I have, since we're eliminating the primitive configuration properties within the pool/factory classes, we're making the Config objects publicly accessible, and possibly accessing through JMX is the idea of making the Config objects thread-safe. This would certainly reduce the need to have to externally synchronize (and possibly introduce bugs) every time. Another issue we probably need to open another ticket for is to deprecate the constructors we've eliminated in 1.5. Last suggestion/question is about making inner (public static final) Builder pattern classes within the concrete Config classes (and possibly defining an abstractT extends Abstract*Config create() method in the Abstract class). This would further simplify the programmatic creation of the Config classes. Thoughts? +1 on Simones patch...we can add any of the above after it has been committed. Respectfully, Steve On Mon, Oct 25, 2010 at 8:36 AM, Simone Tripodi simone.trip...@gmail.comwrote: Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/
Re: [pool] Reusing Config
Phil, I don't think we have removed the ability to access the config options programmatically from the config instance. You can either get a reference to it post-construct/build or from the getConfig() method on the pool. Non-config properties remain the same, accessible through the pool API. The JMX instance would be the only class not exposed public (internal to the pool instance), which would access the config properties through the accessors/mutators (which is why I requested the config classes be made thread-safe). (come to think of it, I don't see a getConfig() on at least one pooladd this?) I could very well be missing something, though. I'm working from home now, working on a separate project with nothing to do with pool, and trying to consider this at the same time =) S On Mon, Oct 25, 2010 at 11:10 AM, Phil Steitz phil.ste...@gmail.com wrote: On 10/25/10 9:06 AM, Steven Siebert wrote: Hi Simone, You have two +1's waiting for you in the JIRA comments =) My comments from tracker: I took a look at this last night but didn't get a chance to comment =) I like the patch, I believe this does indeed satisfy the issue. One question I have, since we're eliminating the primitive configuration properties within the pool/factory classes, we're making the Config objects publicly accessible, and possibly accessing through JMX is the idea of making the Config objects thread-safe. This would certainly reduce the need to have to externally synchronize (and possibly introduce bugs) every time. Sorry, I missed this before commenting on POOL-174. I don't see it working this way - i.e., providing public access to the config instance used to construct the pool at runtime for JMX or other purposes. Pool properties should still be exposed via threadsafe accessors / mutators, including runtime properties not set by the config (e.g. numActive, numIdle). Phil Another issue we probably need to open another ticket for is to deprecate the constructors we've eliminated in 1.5. Last suggestion/question is about making inner (public static final) Builder pattern classes within the concrete Config classes (and possibly defining an abstractT extends Abstract*Config create() method in the Abstract class). This would further simplify the programmatic creation of the Config classes. Thoughts? +1 on Simones patch...we can add any of the above after it has been committed. Respectfully, Steve On Mon, Oct 25, 2010 at 8:36 AM, Simone Tripodisimone.trip...@gmail.com wrote: Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://people.apache.org/%7Esimonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good way to do that =) Cheers, S Hi Steven, No offense even considered from this end :) I'm glad we are going through this exercise. This will improve the software I am sure. Gary On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory ggreg...@seagullsoftware.comwrote: -Original Message- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Thursday, October 21, 2010 06:29 To: Commons Developers List Subject: Re: [pool] Reusing Config On 10/21/10, Simone Tripodisimone.trip...@gmail.com wrote: it seems you've been doing a very good work, the only thing I *suggest* is * simplifying the mutable/immutable interfaces, one interface for already known common (im)mutable fields should be enough; * adding/renaming the interfaces with thePoolName`MBean` postfix to be ready for JMX support; btw it seems you're now much more deep inside the topic than me ;) WDYT? Simo Sorry I have been a little slow on this. I will have a careful look this eve.
[pool] Reusing Config part 2
Thank you for working through this Simone. I would like to discuss something I took for granted in my experimental patch for [POOL-173]. I can see that you took and a more conservative (and safer ;) approach in your version. I am glad to see this because we can now more easily discuss it because it is obvious in the code now, where we have the following config hierarchy: AbstractGenericObjectPoolConfig GenericKeyedObjectPoolConfig GenericObjectPoolConfig IMO, there should be one Config class (call it GenericObjectPoolConfig for example.) This hierarchy reflects that the actual two generic pool classes are out of sync. For example, why should softMinEvictableIdleTimeMillis exist in GenericObjectPool but not in GenericKeyedObjectPoolConfig? When I think about a keyed pool vs. not, I think about a map of pools vs. a single pool. It does not make sense that they the have the different configurations as reflected by the current hierarchy. Thoughts? Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 • Atlanta, GA 30326 • USA Tel: +1.404.760.1560 Email: ggreg...@seagullsoftware.com Web: seagull.rocketsoftware.com -Original Message- From: Simone Tripodi [mailto:simone.trip...@gmail.com] Sent: Monday, October 25, 2010 05:36 To: Commons Developers List Subject: Re: [pool] Reusing Config Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good way to do that =) Cheers, S Hi Steven, No offense even considered from this end :) I'm glad we are going through this exercise. This will improve the software I am sure. Gary On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory ggreg...@seagullsoftware.comwrote: -Original Message- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Thursday, October 21, 2010 06:29 To: Commons Developers List Subject: Re: [pool] Reusing Config On 10/21/10, Simone Tripodi simone.trip...@gmail.com wrote: it seems you've been doing a very good work, the only thing I *suggest* is * simplifying the mutable/immutable interfaces, one interface for already known common (im)mutable fields should be enough; * adding/renaming the interfaces with the PoolName`MBean` postfix to be ready for JMX support; btw it seems you're now much more deep inside the topic than me ;) WDYT? Simo Sorry I have been a little slow on this. I will have a careful look this eve. Based on a very quick review, I am +1 on the idea and approach to separate mutable / immutable. Also +1 for JMX support. Two quick things to keep top of mind: 1. Please make sure not to lose documentation. Whatever is documented today in protected field / internal getters / setters docs needs to be carried forward. Check. I did not check as I refactored that Javadocs were in the right places. That would be a requirement for a real patch. I only meant this as an experiment that went a lot further than I thought. 2. Somewhat related - I am fine just plowing ahead for now using existing API concepts, but some of those concepts are anachronistic or broken, IMO, so we may later decide to revamp much of the accounting aspects of the API. That we should and will discuss on other threads. One thing that might be good to think about at this point, however, is getting rid of primitive properties (we started that with whenExhaustedAction). I think there is a DBCP issue on this raised by Dain a couple of years ago. It would be nice to track
Re: [pool] Reusing Config
On 10/25/10 11:22 AM, Steven Siebert wrote: Phil, I don't think we have removed the ability to access the config options programmatically from the config instance. You can either get a reference to it post-construct/build or from the getConfig() method on the pool. Non-config properties remain the same, accessible through the pool API. The JMX instance would be the only class not exposed public (internal to the pool instance), which would access the config properties through the accessors/mutators (which is why I requested the config classes be made thread-safe). (come to think of it, I don't see a getConfig() on at least one pooladd this?) I could very well be missing something, though. I'm working from home now, working on a separate project with nothing to do with pool, and trying to consider this at the same time =) There is no getConfig() and the point I was making is that I don't think we should add that. Better separation of concerns, IMO, is to have the Config classes available only to the constructors and have the pool expose runtime properties directly, more or less as it does now. I also agree with James' comment on POOL-174 that logically the Config classes should be immutable. I say logically because some use cases may require that they can have properties injected by setters. Phil S On Mon, Oct 25, 2010 at 11:10 AM, Phil Steitzphil.ste...@gmail.com wrote: On 10/25/10 9:06 AM, Steven Siebert wrote: Hi Simone, You have two +1's waiting for you in the JIRA comments =) My comments from tracker: I took a look at this last night but didn't get a chance to comment =) I like the patch, I believe this does indeed satisfy the issue. One question I have, since we're eliminating the primitive configuration properties within the pool/factory classes, we're making the Config objects publicly accessible, and possibly accessing through JMX is the idea of making the Config objects thread-safe. This would certainly reduce the need to have to externally synchronize (and possibly introduce bugs) every time. Sorry, I missed this before commenting on POOL-174. I don't see it working this way - i.e., providing public access to the config instance used to construct the pool at runtime for JMX or other purposes. Pool properties should still be exposed via threadsafe accessors / mutators, including runtime properties not set by the config (e.g. numActive, numIdle). Phil Another issue we probably need to open another ticket for is to deprecate the constructors we've eliminated in 1.5. Last suggestion/question is about making inner (public static final) Builder pattern classes within the concrete Config classes (and possibly defining an abstractT extends Abstract*Config create() method in the Abstract class). This would further simplify the programmatic creation of the Config classes. Thoughts? +1 on Simones patch...we can add any of the above after it has been committed. Respectfully, Steve On Mon, Oct 25, 2010 at 8:36 AM, Simone Tripodisimone.trip...@gmail.com wrote: Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://people.apache.org/%7Esimonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good way to do that =) Cheers, S Hi Steven, No offense even considered from this end :) I'm glad we are going through this exercise. This will improve the software I am sure. Gary On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory ggreg...@seagullsoftware.comwrote: -Original Message- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Thursday, October 21, 2010 06:29 To: Commons Developers List Subject: Re: [pool] Reusing Config On 10/21/10, Simone
Re: [pool] Reusing Config part 2
Gary, I tossed this around as well, and noted these fields as a possible promote to the Abstract configuration, because I agree that there probably isn't a good reason why one pool has those features and the other doesn't. (if this is indeed the case, these would probably best be tracked in two separate issues IMHO). That said, they are two concrete pools, and I worry that having just a single Config class may complicate the 2.0 API down the line if, for example, one pool gets a new feature that isn't logical for the other (logically bound or even generically typed). Even if we promote both conflicting issues to the abstract config class, and the two concrete config classes are simply shell implementations, I would be happy to know we have this wiggle room to expand later without having to introduce a new class into the mix. Further, we can type safety this config-to-[pool|factory] pairing, and not receive the wrong config type (if and when one config diverges from the other). I'm interested to know your thoughts on this, since I pondered this very issue as well before giving the +1 =) S On Mon, Oct 25, 2010 at 11:26 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: Thank you for working through this Simone. I would like to discuss something I took for granted in my experimental patch for [POOL-173]. I can see that you took and a more conservative (and safer ;) approach in your version. I am glad to see this because we can now more easily discuss it because it is obvious in the code now, where we have the following config hierarchy: AbstractGenericObjectPoolConfig GenericKeyedObjectPoolConfig GenericObjectPoolConfig IMO, there should be one Config class (call it GenericObjectPoolConfig for example.) This hierarchy reflects that the actual two generic pool classes are out of sync. For example, why should softMinEvictableIdleTimeMillis exist in GenericObjectPool but not in GenericKeyedObjectPoolConfig? When I think about a keyed pool vs. not, I think about a map of pools vs. a single pool. It does not make sense that they the have the different configurations as reflected by the current hierarchy. Thoughts? Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 • Atlanta, GA 30326 • USA Tel: +1.404.760.1560 Email: ggreg...@seagullsoftware.com Web: seagull.rocketsoftware.com -Original Message- From: Simone Tripodi [mailto:simone.trip...@gmail.com] Sent: Monday, October 25, 2010 05:36 To: Commons Developers List Subject: Re: [pool] Reusing Config Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good way to do that =) Cheers, S Hi Steven, No offense even considered from this end :) I'm glad we are going through this exercise. This will improve the software I am sure. Gary On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory ggreg...@seagullsoftware.comwrote: -Original Message- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Thursday, October 21, 2010 06:29 To: Commons Developers List Subject: Re: [pool] Reusing Config On 10/21/10, Simone Tripodi simone.trip...@gmail.com wrote: it seems you've been doing a very good work, the only thing I *suggest* is * simplifying the mutable/immutable interfaces, one interface for already known common (im)mutable fields should be enough; * adding/renaming the interfaces with the PoolName`MBean` postfix to be ready for JMX support; btw it seems you're now much more
Re: [VFS] Softening the exceptions...
On Oct 25, 2010, at 8:10 AM, James Carman wrote: On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: Do we want the APIs to be quieter than using java.io.File for example? Or, should exceptions be thrown from similar places? Definitely quieter than java.io.File! I *hate* that API for its checked exceptions. I am worried that we would make all APIs quiet (unchecked exceptions) as a opposed to really thinking where exceptions should be checked or return an Boolean error code (like File mkdir) I'm one of those folks who think the checked exceptions are evil, so I am fine with getting rid of them entirely (think about how much nicer your Hibernate code looks without the checked exceptions). Boolean returns are fine I guess. No real strong opinion on that one. I'm not in favor of changing much at this point. I'd really like to get a release done without too many more changes. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Reusing Config part 2
On 10/25/10 11:26 AM, Gary Gregory wrote: Thank you for working through this Simone. I would like to discuss something I took for granted in my experimental patch for [POOL-173]. I can see that you took and a more conservative (and safer ;) approach in your version. I am glad to see this because we can now more easily discuss it because it is obvious in the code now, where we have the following config hierarchy: AbstractGenericObjectPoolConfig GenericKeyedObjectPoolConfig GenericObjectPoolConfig IMO, there should be one Config class (call it GenericObjectPoolConfig for example.) This hierarchy reflects that the actual two generic pool classes are out of sync. For example, why should softMinEvictableIdleTimeMillis exist in GenericObjectPool but not in GenericKeyedObjectPoolConfig? When I think about a keyed pool vs. not, I think about a map of pools vs. a single pool. It does not make sense that they the have the different configurations as reflected by the current hierarchy. Thoughts? Good point, Gary. The softMin property could and probably should be extended to GKOP. The latter does have one property though - maxTotal - that only makes sense for a keyed pool. Unfortunately, another problem that we really have here is that several of the config parameters mean different things for keyed vs non-keyed pools. For example, maxActive in a keyed pool really means max active *per key*. This is why maxTotal has to exist. Same holds for maxIdle (but there is no maxTotalIdle). I have thought about suggesting that we rename these parameters to maxActivePerKey and maxIdlePerKey, resp. Then we could dispense with maxTotal (and keep maxIdle meaning for the union). We might want to think about doing that (though enforcing maxIdle so defined will add a little overhead). The nice thing about having the hierarchy is that that is an easy change at this point (while we are breaking stuff ;). Phil Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 • Atlanta, GA 30326 • USA Tel: +1.404.760.1560 Email: ggreg...@seagullsoftware.com Web: seagull.rocketsoftware.com -Original Message- From: Simone Tripodi [mailto:simone.trip...@gmail.com] Sent: Monday, October 25, 2010 05:36 To: Commons Developers List Subject: Re: [pool] Reusing Config Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good way to do that =) Cheers, S Hi Steven, No offense even considered from this end :) I'm glad we are going through this exercise. This will improve the software I am sure. Gary On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory ggreg...@seagullsoftware.comwrote: -Original Message- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Thursday, October 21, 2010 06:29 To: Commons Developers List Subject: Re: [pool] Reusing Config On 10/21/10, Simone Tripodisimone.trip...@gmail.com wrote: it seems you've been doing a very good work, the only thing I *suggest* is * simplifying the mutable/immutable interfaces, one interface for already known common (im)mutable fields should be enough; * adding/renaming the interfaces with thePoolName`MBean` postfix to be ready for JMX support; btw it seems you're now much more deep inside the topic than me ;) WDYT? Simo Sorry I have been a little slow on this. I will have a careful look this eve. Based on a very quick review, I am +1 on the idea and approach to separate mutable / immutable. Also +1 for JMX support. Two quick things to keep top of mind: 1. Please make sure not to lose documentation. Whatever is documented today in protected field / internal getters / setters docs needs to be carried forward.
Re: [VFS] Softening the exceptions...
true =) BTW, I'll be at ApacheCon, if the VFS crew would like another warm body to assist in getting the release out. Just let me know when/where to be On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.comwrote: On Oct 25, 2010, at 8:10 AM, James Carman wrote: On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: Do we want the APIs to be quieter than using java.io.File for example? Or, should exceptions be thrown from similar places? Definitely quieter than java.io.File! I *hate* that API for its checked exceptions. I am worried that we would make all APIs quiet (unchecked exceptions) as a opposed to really thinking where exceptions should be checked or return an Boolean error code (like File mkdir) I'm one of those folks who think the checked exceptions are evil, so I am fine with getting rid of them entirely (think about how much nicer your Hibernate code looks without the checked exceptions). Boolean returns are fine I guess. No real strong opinion on that one. I'm not in favor of changing much at this point. I'd really like to get a release done without too many more changes. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
+1 for softening all exceptions. The fact is, what reasonable recourse is there to the user if a file operation fails? That's what checked exceptions were supposed to be for -- mandate handling code. It's tough to say we need to mandate handling these errors. Paul On Mon, Oct 25, 2010 at 10:49 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Oct 25, 2010, at 8:10 AM, James Carman wrote: On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: Do we want the APIs to be quieter than using java.io.File for example? Or, should exceptions be thrown from similar places? Definitely quieter than java.io.File! I *hate* that API for its checked exceptions. I am worried that we would make all APIs quiet (unchecked exceptions) as a opposed to really thinking where exceptions should be checked or return an Boolean error code (like File mkdir) I'm one of those folks who think the checked exceptions are evil, so I am fine with getting rid of them entirely (think about how much nicer your Hibernate code looks without the checked exceptions). Boolean returns are fine I guess. No real strong opinion on that one. I'm not in favor of changing much at this point. I'd really like to get a release done without too many more changes. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.com wrote: I'm not in favor of changing much at this point. I'd really like to get a release done without too many more changes. There's a problem with that, Ralph. If we publish a 2.0, we can't break the API later. So, we'd have to go to 3.0 if we wanted to break anything. So, we need to figure out if this is the way we want to go and do it. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Reusing Config
On 10/25/10 11:34 AM, Phil Steitz wrote: On 10/25/10 11:22 AM, Steven Siebert wrote: Phil, I don't think we have removed the ability to access the config options programmatically from the config instance. You can either get a reference to it post-construct/build or from the getConfig() method on the pool. Non-config properties remain the same, accessible through the pool API. The JMX instance would be the only class not exposed public (internal to the pool instance), which would access the config properties through the accessors/mutators (which is why I requested the config classes be made thread-safe). (come to think of it, I don't see a getConfig() on at least one pooladd this?) I could very well be missing something, though. I'm working from home now, working on a separate project with nothing to do with pool, and trying to consider this at the same time =) There is no getConfig() and the point I was making is that I don't think we should add that. Better separation of concerns, IMO, is to have the Config classes available only to the constructors and have the pool expose runtime properties directly, more or less as it does now. I also agree with James' comment on POOL-174 that logically the Config classes should be immutable. I say logically because some use cases may require that they can have properties injected by setters. I notice now what I missed on initial review of Simo's patch - the pool accessors now manage the config properties via persisted Config members. I am OK with this, but it now means that the Config classes have to be mutable. What needs to be threadsafe, however, is the pool itself. Given that you can't rely on Config locks to ensure correctness for the pool (i.e. the pool-exposed mutators are still going to have to lock the pool itself), making Config accessors synchronized is just adding extra synch. Phil Phil S On Mon, Oct 25, 2010 at 11:10 AM, Phil Steitzphil.ste...@gmail.com wrote: On 10/25/10 9:06 AM, Steven Siebert wrote: Hi Simone, You have two +1's waiting for you in the JIRA comments =) My comments from tracker: I took a look at this last night but didn't get a chance to comment =) I like the patch, I believe this does indeed satisfy the issue. One question I have, since we're eliminating the primitive configuration properties within the pool/factory classes, we're making the Config objects publicly accessible, and possibly accessing through JMX is the idea of making the Config objects thread-safe. This would certainly reduce the need to have to externally synchronize (and possibly introduce bugs) every time. Sorry, I missed this before commenting on POOL-174. I don't see it working this way - i.e., providing public access to the config instance used to construct the pool at runtime for JMX or other purposes. Pool properties should still be exposed via threadsafe accessors / mutators, including runtime properties not set by the config (e.g. numActive, numIdle). Phil Another issue we probably need to open another ticket for is to deprecate the constructors we've eliminated in 1.5. Last suggestion/question is about making inner (public static final) Builder pattern classes within the concrete Config classes (and possibly defining an abstractT extends Abstract*Config create() method in the Abstract class). This would further simplify the programmatic creation of the Config classes. Thoughts? +1 on Simones patch...we can add any of the above after it has been committed. Respectfully, Steve On Mon, Oct 25, 2010 at 8:36 AM, Simone Tripodisimone.trip...@gmail.com wrote: Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://people.apache.org/%7Esimonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my
Re: [pool] Reusing Config
On Mon, Oct 25, 2010 at 12:25 PM, Phil Steitz phil.ste...@gmail.com wrote: I notice now what I missed on initial review of Simo's patch - the pool accessors now manage the config properties via persisted Config members. I am OK with this, but it now means that the Config classes have to be mutable. What needs to be threadsafe, however, is the pool itself. Given that you can't rely on Config locks to ensure correctness for the pool (i.e. the pool-exposed mutators are still going to have to lock the pool itself), making Config accessors synchronized is just adding extra synch. I haven't had a chance to review the proposed code changes yet, but why not just use a reconfigure(Config) method on the pool objects which is called by the constructor and by the outside world (including JMX stuff)? There are two options with this approach: 1. Make a copy of the Config object so that outside changes (if Config is left mutable) don't make an impact. 2. Don't refer directly to the Config object at all inside the pool's implementation. You'd have to copy the config information somewhere else obviously. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Reusing Config
On 10/25/10 12:36 PM, James Carman wrote: On Mon, Oct 25, 2010 at 12:25 PM, Phil Steitzphil.ste...@gmail.com wrote: I notice now what I missed on initial review of Simo's patch - the pool accessors now manage the config properties via persisted Config members. I am OK with this, but it now means that the Config classes have to be mutable. What needs to be threadsafe, however, is the pool itself. Given that you can't rely on Config locks to ensure correctness for the pool (i.e. the pool-exposed mutators are still going to have to lock the pool itself), making Config accessors synchronized is just adding extra synch. I haven't had a chance to review the proposed code changes yet, but why not just use a reconfigure(Config) method on the pool objects which is called by the constructor and by the outside world (including JMX stuff)? There are two options with this approach: 1. Make a copy of the Config object so that outside changes (if Config is left mutable) don't make an impact. 2. Don't refer directly to the Config object at all inside the pool's implementation. You'd have to copy the config information somewhere else obviously. I like 2. better. That is how it worked before (pool properties were held in individual fields). I missed that part of the change. Not all properties are mutable and we want to be able to set / get individual properties at runtime. That would be awkward under option 1. Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
-1 At the risk of playing Devils Advocate here, what's the downside to checked exceptions? A few extra lines of code? I can foresee a problem with unchecked exceptions though. Imagine that you're using the API to build a desktop application. You want to display a dialog box to the user indicating that some problem has occurred. With an unchecked exception, the stack trace and exception message may appear in a log file or in the console, but the user would in all likelihood never see it. Moreover if a developer is unfamiliar with the API, with a checked exception, they would be able to make an informed decision about how to handle the exception. The developer can easily trap the exception, and display a semi-informative dialog indicating that something has gone wrong. Although the user may not be able to fix it, they would still know that a problem occurred, and would hopefully be able to file a bug report to that effect. If you don't want the user informed, you can always swallow the exception. But at least, as a developer, you have a choice about how to deal with it, and it's not something that just pops up out of no where and surprises both user and developer. Mark card.ly: http://card.ly/phidias51 On Mon, Oct 25, 2010 at 9:01 AM, James Carman ja...@carmanconsulting.comwrote: On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.com wrote: I'm not in favor of changing much at this point. I'd really like to get a release done without too many more changes. There's a problem with that, Ralph. If we publish a 2.0, we can't break the API later. So, we'd have to go to 3.0 if we wanted to break anything. So, we need to figure out if this is the way we want to go and do it. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
I agree with Mark's point about unfamiliar developers benefiting from checked exceptions. Unlike James, I like checked exceptions =), and I have established elegant recoveries from various resource exceptions (IO, for example) under many use cases (at least in the enterprise arena). What's everyones opinion on more descriptive Exception typing to allow me to handle specific failures easier (without additional testing)? I can probably go through my code and find some examples if necessary... S On Mon, Oct 25, 2010 at 12:49 PM, Mark Fortner phidia...@gmail.com wrote: -1 At the risk of playing Devils Advocate here, what's the downside to checked exceptions? A few extra lines of code? I can foresee a problem with unchecked exceptions though. Imagine that you're using the API to build a desktop application. You want to display a dialog box to the user indicating that some problem has occurred. With an unchecked exception, the stack trace and exception message may appear in a log file or in the console, but the user would in all likelihood never see it. Moreover if a developer is unfamiliar with the API, with a checked exception, they would be able to make an informed decision about how to handle the exception. The developer can easily trap the exception, and display a semi-informative dialog indicating that something has gone wrong. Although the user may not be able to fix it, they would still know that a problem occurred, and would hopefully be able to file a bug report to that effect. If you don't want the user informed, you can always swallow the exception. But at least, as a developer, you have a choice about how to deal with it, and it's not something that just pops up out of no where and surprises both user and developer. Mark card.ly: http://card.ly/phidias51 On Mon, Oct 25, 2010 at 9:01 AM, James Carman ja...@carmanconsulting.com wrote: On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.com wrote: I'm not in favor of changing much at this point. I'd really like to get a release done without too many more changes. There's a problem with that, Ralph. If we publish a 2.0, we can't break the API later. So, we'd have to go to 3.0 if we wanted to break anything. So, we need to figure out if this is the way we want to go and do it. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
Very much -1 on unchecked exceptions. On Mon, Oct 25, 2010 at 10:33 AM, James Carman ja...@carmanconsulting.com wrote: What do people typically do with those exceptions? Seriously, do you retry stuff on a regular basis in your catch blocks? Yes! Very much so. It's quite useful when dealing with stale nfs, locked files,... I would say that it's pretty rare that folks actually do something locally meaningful when a checked exception occurs. Maybe I'm the exception, but I'd be really sad to see the proper exceptions go. I do very much agree with one of the other posters that they could be more specific so you can easier throw groups of them under the rug should you wish to. - Filip - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort filip...@cirquedigital.com wrote: Yes! Very much so. It's quite useful when dealing with stale nfs, locked files,... Do you implement the retry logic in every place where you need it or do you have a helper method that takes some sort of functor and it wraps it in the try/catch/retry logic? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 1:17 PM, Steven Siebert smsi...@gmail.com wrote: I agree with Mark's point about unfamiliar developers benefiting from checked exceptions. Unlike James, I like checked exceptions =), and I have established elegant recoveries from various resource exceptions (IO, for example) under many use cases (at least in the enterprise arena). Sure, a newbie might enjoy the warm fuzziness they feel when they know what type of exception they have to catch when they call a certain method. However, that newbie, when they get familiar with said API, will start writing work-arounds so they don't have to have all those pesky catch blocks in their code. They will quickly realize that typically there isn't a darn thing they can really do when this type of exception occurs. Mostly, the exceptions are best handled up the call stack by some global means. So, in order to do that, you either have to allow all your methods to throw the exception or tunnel the exception up the call stack by wrapping it in a runtime exception and throwing that. Even if there is a retry/recovery option, you'd use some utility method to do that, so you'd only have the try/catch in one place as opposed to everywhere. What's everyones opinion on more descriptive Exception typing to allow me to handle specific failures easier (without additional testing)? I can probably go through my code and find some examples if necessary... I like the idea of a more descriptive hierarchy of exceptions. Exception classes are cheap, really. Hibernate does this (optimistic locking exception comes to mind) and it seems to work pretty well. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 10:45 AM, James Carman ja...@carmanconsulting.com wrote: On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort filip...@cirquedigital.com wrote: Yes! Very much so. It's quite useful when dealing with stale nfs, locked files,... Do you implement the retry logic in every place where you need it or do you have a helper method that takes some sort of functor and it wraps it in the try/catch/retry logic? Depends. I do have a bunch of wrappers for common types of retries, but often the remedy really is different depending on the operation (I'm dealing a lot with search indexes, updating them and transaction locking). - Filip - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
Checked exceptions throw a burden onto the developer. He is forced to do something. Why force this burden? It assumes something SHOULD be done for these particular errors. I don't think that's realistic (they're OS errors -- not business errors), which is why checked exceptions have fallen well out of favor in the last decade. On Mon, Oct 25, 2010 at 12:48 PM, Filip Defoort filip...@cirquedigital.com wrote: On Mon, Oct 25, 2010 at 10:45 AM, James Carman ja...@carmanconsulting.com wrote: On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort filip...@cirquedigital.com wrote: Yes! Very much so. It's quite useful when dealing with stale nfs, locked files,... Do you implement the retry logic in every place where you need it or do you have a helper method that takes some sort of functor and it wraps it in the try/catch/retry logic? Depends. I do have a bunch of wrappers for common types of retries, but often the remedy really is different depending on the operation (I'm dealing a lot with search indexes, updating them and transaction locking). - Filip - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort filip...@cirquedigital.com wrote: Depends. I do have a bunch of wrappers for common types of retries, but often the remedy really is different depending on the operation (I'm dealing a lot with search indexes, updating them and transaction locking). Again, you can use try/catch if you want to with runtime exceptions. I'd say your usage is not typical. Most folks don't do anything meaningful at the local level (in the immediate catch block). They let the exception go up the call stack or take care of it by other means (aspects, thread group's unchecked exception, etc). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 10:51 AM, Paul Benedict pbened...@apache.org wrote: Checked exceptions throw a burden onto the developer. He is forced to do something. Why force this burden? It assumes something SHOULD be done for these particular errors. I don't think that's realistic (they're OS errors -- not business errors), which is why checked exceptions have fallen well out of favor in the last decade. In my view, it is the developer's job to provide an solid experience to the user. That includes properly dealing with underlying system errors in the least cryptic possible way and recovering where possible. And those errors aren't always OS errors - could very well be incorrect usage/... I do agree that that is extra work, but if you just sweep exceptions under the rug all the time, you end up with really crappy software. - Filip - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 10:52 AM, James Carman ja...@carmanconsulting.com wrote: On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort filip...@cirquedigital.com wrote: Depends. I do have a bunch of wrappers for common types of retries, but often the remedy really is different depending on the operation (I'm dealing a lot with search indexes, updating them and transaction locking). Again, you can use try/catch if you want to with runtime exceptions. No, you can't. Yes you can catch them, but you really want to start parsing the text of the exception just to know what situation you're in ? I already have to do that with some of the exceptions in the mysql driver and it's a royal PITA. I'd say your usage is not typical. Most folks don't do anything meaningful at the local level (in the immediate catch block). They let the exception go up the call stack or take care of it by other means (aspects, thread group's unchecked exception, etc). Typical or not, at least in my immediate work environment I know quite a few people that deal with the same problems. - Filip - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 1:53 PM, Filip Defoort filip...@cirquedigital.com wrote: In my view, it is the developer's job to provide an solid experience to the user. That includes properly dealing with underlying system errors in the least cryptic possible way and recovering where possible. And those errors aren't always OS errors - could very well be incorrect usage/... So, fix your incorrect usage during testing. I do agree that that is extra work, but if you just sweep exceptions under the rug all the time, you end up with really crappy software. That's not our job to police folks' code. If they want to write crappy software, then let them. Maybe someone will hire us to come fix it! :) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 10:56 AM, James Carman ja...@carmanconsulting.com wrote: On Mon, Oct 25, 2010 at 1:53 PM, Filip Defoort filip...@cirquedigital.com wrote: In my view, it is the developer's job to provide an solid experience to the user. That includes properly dealing with underlying system errors in the least cryptic possible way and recovering where possible. And those errors aren't always OS errors - could very well be incorrect usage/... So, fix your incorrect usage during testing. Not _my_ incorrect usage. I write multi user applications and sometimes one user does something that causes problem for another user. Due to business constraints it's not always possible to avoid letter them shoot themselves in the foot, but I still need to recover from it (lest I get all the blame for the problem). I do agree that that is extra work, but if you just sweep exceptions under the rug all the time, you end up with really crappy software. That's not our job to police folks' code. If they want to write crappy software, then let them. Maybe someone will hire us to come fix it! :) Well, it's my job to write proper code. Other people can do all they want, but with just a runtime exception I wouldn't be able to do what I'd need to do. Just my .02$. - Filip - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 2:00 PM, Filip Defoort filip...@cirquedigital.com wrote: Well, it's my job to write proper code. Other people can do all they want, but with just a runtime exception I wouldn't be able to do what I'd need to do. Again, I think you're misunderstanding my suggestion. I'm suggesting to do this: public class FileSystemException extends RuntimeException as opposed to public class FileSystemException extends IOException This makes all VFS's exceptions unchecked. They can be caught if you want or they can be propagated up the call stack without having to wrap them up and do it yourself. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1027007 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/exception/ main/java/org/apache/commons/math/optimization/ main/java/org/apache/commons/math/optimizatio
Le 25/10/2010 11:42, er...@apache.org a écrit :
Author: erans
Date: Mon Oct 25 09:42:33 2010
New Revision: 1027007
URL: http://svn.apache.org/viewvc?rev=1027007view=rev
Log:
MATH-428
Refactoring of DirectSearchOptimizer to separate the optimization and
simplex management aspects. Old classes are deprecated.
Added:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/AbstractSimplex.java
(with props)
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/MultiDirectionalSimplex.java
(with props)
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/NelderMeadSimplex.java
(with props)
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/SimplexOptimizer.java
(with props)
commons/proper/math/trunk/src/test/java/org/apache/commons/math/optimization/direct/SimplexOptimizerMultiDirectionalTest.java
(with props)
commons/proper/math/trunk/src/test/java/org/apache/commons/math/optimization/direct/SimplexOptimizerNelderMeadTest.java
(with props)
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/exception/MathIllegalArgumentException.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/RealPointValuePair.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/DirectSearchOptimizer.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/MultiDirectional.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/NelderMead.java
commons/proper/math/trunk/src/site/xdoc/changes.xml
[snip]
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/DirectSearchOptimizer.java
URL:
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/DirectSearchOptimizer.java?rev=1027007r1=1027006r2=1027007view=diff
==
---
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/DirectSearchOptimizer.java
(original)
+++
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/direct/DirectSearchOptimizer.java
Mon Oct 25 09:42:33 2010
@@ -80,6 +80,7 @@ import org.apache.commons.math.optimizat
* @see MultiDirectional
* @version $Revision$ $Date$
* @since 1.2
+ * @deprecated in 2.2 (to be removed in 3.0). Please use {...@link
SimplexOptimizer} instead.
*/
For now, none of these changes have been committed in the 2.X branch. Do
you intend to add them later on ?
Luc
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
RE: [pool] Reusing Config part 2
-Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Monday, October 25, 2010 08:43 To: Commons Developers List Subject: Re: [pool] Reusing Config part 2 Gary, I tossed this around as well, and noted these fields as a possible promote to the Abstract configuration, because I agree that there probably isn't a good reason why one pool has those features and the other doesn't. (if this is indeed the case, these would probably best be tracked in two separate issues IMHO). That said, they are two concrete pools, and I worry that having just a single Config class may complicate the 2.0 API down the line if, for example, one pool gets a new feature that isn't logical for the other (logically bound or even generically typed). Even if we promote both conflicting issues to the abstract config class, and the two concrete config classes are simply shell implementations, I would be happy to know we have this wiggle room to expand later without having to introduce a new class into the mix. Further, we can type safety this config-to-[pool|factory] pairing, and not receive the wrong config type (if and when one config diverges from the other). I'm interested to know your thoughts on this, since I pondered this very issue as well before giving the +1 =) S Hm... I now understand that there is actually a need for at least one subclass (see Phil's message WRT maxTotal and so on.) So having both subclasses gives us a nice symmetry. It would feel odd to have just one subclass when everywhere else in the package we have a pairs of plain and keyed pool classes. That said, if I were to only Steven's message, I would err on the side of the XP tenet of not creating code for the future that is not needed now. That /that/ said, my opinion on this XP mantra is usually softened when I consider library code instead of application code. This is moot in this case since we need at least one subclass... Good chat though! :) Gary On Mon, Oct 25, 2010 at 11:26 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: Thank you for working through this Simone. I would like to discuss something I took for granted in my experimental patch for [POOL-173]. I can see that you took and a more conservative (and safer ;) approach in your version. I am glad to see this because we can now more easily discuss it because it is obvious in the code now, where we have the following config hierarchy: AbstractGenericObjectPoolConfig GenericKeyedObjectPoolConfig GenericObjectPoolConfig IMO, there should be one Config class (call it GenericObjectPoolConfig for example.) This hierarchy reflects that the actual two generic pool classes are out of sync. For example, why should softMinEvictableIdleTimeMillis exist in GenericObjectPool but not in GenericKeyedObjectPoolConfig? When I think about a keyed pool vs. not, I think about a map of pools vs. a single pool. It does not make sense that they the have the different configurations as reflected by the current hierarchy. Thoughts? Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA Tel: +1.404.760.1560 Email: ggreg...@seagullsoftware.com Web: seagull.rocketsoftware.com -Original Message- From: Simone Tripodi [mailto:simone.trip...@gmail.com] Sent: Monday, October 25, 2010 05:36 To: Commons Developers List Subject: Re: [pool] Reusing Config Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good
RE: [pool] Reusing Config part 2
-Original Message- From: Phil Steitz [mailto:phil.ste...@gmail.com] Sent: Monday, October 25, 2010 08:50 To: Commons Developers List Subject: Re: [pool] Reusing Config part 2 On 10/25/10 11:26 AM, Gary Gregory wrote: Thank you for working through this Simone. I would like to discuss something I took for granted in my experimental patch for [POOL-173]. I can see that you took and a more conservative (and safer ;) approach in your version. I am glad to see this because we can now more easily discuss it because it is obvious in the code now, where we have the following config hierarchy: AbstractGenericObjectPoolConfig GenericKeyedObjectPoolConfig GenericObjectPoolConfig IMO, there should be one Config class (call it GenericObjectPoolConfig for example.) This hierarchy reflects that the actual two generic pool classes are out of sync. For example, why should softMinEvictableIdleTimeMillis exist in GenericObjectPool but not in GenericKeyedObjectPoolConfig? When I think about a keyed pool vs. not, I think about a map of pools vs. a single pool. It does not make sense that they the have the different configurations as reflected by the current hierarchy. Thoughts? Good point, Gary. The softMin property could and probably should be extended to GKOP. The latter does have one property though - maxTotal - that only makes sense for a keyed pool. OK, that gives validity to one subclass and it feels good to have the other for symmetry even though it would be initially empty. Created tix for GKOP softMin: https://issues.apache.org/jira/browse/POOL-176 Unfortunately, another problem that we really have here is that several of the config parameters mean different things for keyed vs non-keyed pools. For example, maxActive in a keyed pool really means max active *per key*. This is why maxTotal has to exist. Same holds for maxIdle (but there is no maxTotalIdle). I have thought about suggesting that we rename these parameters to maxActivePerKey and maxIdlePerKey, resp. Then we could dispense with maxTotal (and keep maxIdle meaning for the union). We might want to think about doing that (though enforcing maxIdle so defined will add a little overhead). The nice thing about having the hierarchy is that that is an easy change at this point (while we are breaking stuff ;). Phil Hm... if they do mean different things, it would be most helpful if that was reflected in the names. I like your PerKey names. I also like prefixes because names then sort together nicely in tools. getKeyedMaxActive()? It only makes sense to reuse the names if the semantics match up. So can we go through the exercise of naming things properly? We could then clearly see what is in common between the two pools. Gary Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 • Atlanta, GA 30326 • USA Tel: +1.404.760.1560 Email: ggreg...@seagullsoftware.com Web: seagull.rocketsoftware.com -Original Message- From: Simone Tripodi [mailto:simone.trip...@gmail.com] Sent: Monday, October 25, 2010 05:36 To: Commons Developers List Subject: Re: [pool] Reusing Config Hi all mates, I updated the jira issue uploading my patch; it contains the configuration extraction and some code modification. IMHO we shouldn't replicate the same data in both configuration AND factory/pool, when creating the factory/pool it is enough storing the configuration reference, just use it. I intentionally missed the interfaces layer, since they can be added directly in the JMX support in the required form. Please take a look at the patch and provide feedbacks, if you agree I could start committing the modifications and proceed on JMX support. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Thursday, October 21, 2010 18:08 To: Commons Developers List Subject: Re: [pool] Reusing Config Gary, Great work so far. I'm checking out the diffs now, I'm gonna hack out some simple UML diffs, if only to wrap my head around it all. I'll upload the file to the issue once complete. BTW, I hope I didn't offend with the 'academic' comment, I most certainly did not intend to infer that there weren't functional importances to this issue. I was mostly trying to delineate the two issues in my mind, and putting it to paper was a good way to do that =) Cheers, S Hi Steven, No offense even considered from this end :) I'm glad we are going through this exercise. This will improve the software I am sure. Gary On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory ggreg...@seagullsoftware.comwrote: -Original Message- From: Phil Steitz
RE: [VFS] Softening the exceptions...
-Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: Monday, October 25, 2010 08:10 To: Commons Developers List Subject: Re: [VFS] Softening the exceptions... On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory ggreg...@seagullsoftware.com wrote: Do we want the APIs to be quieter than using java.io.File for example? Or, should exceptions be thrown from similar places? Definitely quieter than java.io.File! I *hate* that API for its checked exceptions. I am worried that we would make all APIs quiet (unchecked exceptions) as a opposed to really thinking where exceptions should be checked or return an Boolean error code (like File mkdir) I'm one of those folks who think the checked exceptions are evil, so I am fine with getting rid of them entirely (think about how much nicer your Hibernate code looks without the checked exceptions). Boolean returns are fine I guess. No real strong opinion on that one. So for VFS, you would prefer that all error handling be done with unchecked exceptions? Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory ggreg...@seagullsoftware.com wrote: So for VFS, you would prefer that all error handling be done with unchecked exceptions? In a nutshell, yes. So, it's a pretty easy change. You'd just change the superclass of FileSystemException. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory ggreg...@seagullsoftware.com wrote: So for VFS, you would prefer that all error handling be done with unchecked exceptions? This is probably a question better asked on the user list so we can get a feel for how people feel about it. I just wanted to start the discussion here among the development team. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VFS] Softening the exceptions...
-Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: Monday, October 25, 2010 10:33 To: Commons Developers List Subject: Re: [VFS] Softening the exceptions... On Mon, Oct 25, 2010 at 12:49 PM, Mark Fortner phidia...@gmail.com wrote: -1 At the risk of playing Devils Advocate here, what's the downside to checked exceptions? A few extra lines of code? I can foresee a problem with unchecked exceptions though. Imagine that you're using the API to build a desktop application. You want to display a dialog box to the user indicating that some problem has occurred. With an unchecked exception, the stack trace and exception message may appear in a log file or in the console, but the user would in all likelihood never see it. I think about this using Murphy's law: What do I want my application to do when the API throws an exception? It will, sooner than I think. While it is true that I can catch unchecked exceptions, these are /supposed/ to be programmer errors (IllegalStateException) or catastrophic (OutOfMemoryError). Checked exceptions are expected (this file is missing, the network goes down in the middle of processing, for example.) The distinction is important. Tossing checked exceptions out the window is like hiding something under the rug. You're gonna trip on it! Gary It's not a few extra lines of code. It's a few extra lines of code everywhere you call the API (like asking if a file exists for example). That gets old really quickly. For cases where you want to display a message to the user that says something bad happened, my bad, then you would probably want to use a custom uncaughtException() method on your thread groups. Also, you can always choose to catch unchecked exceptions if you want. Nothing is stopping you. You're just not forced to do it. Moreover if a developer is unfamiliar with the API, with a checked exception, they would be able to make an informed decision about how to handle the exception. The developer can easily trap the exception, and display a semi-informative dialog indicating that something has gone wrong. Although the user may not be able to fix it, they would still know that a problem occurred, and would hopefully be able to file a bug report to that effect. If you don't want the user informed, you can always swallow the exception. But at least, as a developer, you have a choice about how to deal with it, and it's not something that just pops up out of no where and surprises both user and developer. What do people typically do with those exceptions? Seriously, do you retry stuff on a regular basis in your catch blocks? I would say that it's pretty rare that folks actually do something locally meaningful when a checked exception occurs. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
Hi! Am 25.10.2010 um 21:13 schrieb James Carman ja...@carmanconsulting.com: On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory ggreg...@seagullsoftware.com wrote: So for VFS, you would prefer that all error handling be done with unchecked In a nutshell, yes. So, it's a pretty easy change. You'd just change the superclass of FileSystemException. To bring in my two 2ct. I foo think that the FileSystemException could be a runtime exception. As long as it represents a non-recoverable exception. Something which might throw things like a filenotfoundexception should be checked, still. What I would like to say is, simply changing the exception inheritance is not sufficient and for no ones help. We need to work out a concept which method throws which checked or unchecked exception. As we had Hibernate in the thread, I think Hibernate has gone too far in this question and you have to be very familiar with the API to know which exception to catch when. This does not help if you are going to translate a technical exception to something meaningful for the user. The problem with VFS is that it throws mostly just a FSE without any chance to get the real cause in you program - you have to parse the message - which is bad. Ciao, Mario - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Oct 25, 2010, at 9:01 AM, James Carman wrote: On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.com wrote: I'm not in favor of changing much at this point. I'd really like to get a release done without too many more changes. There's a problem with that, Ralph. If we publish a 2.0, we can't break the API later. So, we'd have to go to 3.0 if we wanted to break anything. So, we need to figure out if this is the way we want to go and do it. This code has been sitting here for a year. Commons Configuration would like to do a release but cannot until VFS is released. I'd like to work on the VFS release during the hackathon next week. If you believe you can change how VFS does exception handling and then make the necessary changes (if any) to Commons Configuration so that we can work on a release next week then go for it. Will you be at ApacheCon? Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 7:44 PM, Ralph Goers ralph.go...@dslextreme.com wrote: This code has been sitting here for a year. Commons Configuration would like to do a release but cannot until VFS is released. I'd like to work on the VFS release during the hackathon next week. If you believe you can change how VFS does exception handling and then make the necessary changes (if any) to Commons Configuration so that we can work on a release next week then go for it. I didn't come up with the softening exceptions idea until just today when I was coding using VFS. Our project at work uses VFS extensively. I don't mind helping, but I don't think we have a consensus about what we are going to do. We should probably figure out what the plan of attack is before we start hacking around. I really think the exceptions should be softened, because it makes working with VFS a real pain, IMHO. The only place where you'll see a problem in Configuration is where you used to use IOException as a catch-all to catch VFS exceptions too. Otherwise, you can still do try/catch with FileSystemException and those will work. You just don't have to do the try/catch. Will you be at ApacheCon? Unfortunately, I will not. We have a newborn at home, so I don't think I should try leaving the wife at home alone right now. :) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ANNOUNCE] Commons Daemon 1.0.4 Released
The Commons Daemon team is pleased to announce the commons-daemon-1.0.4 release! Version 1.0.4 is primarily a bug fix release with some new features added. Source and binary distributions are available for download from the Apache Commons download site: http://commons.apache.org/daemon/download_daemon.cgi When downloading, please verify signatures using the KEYS file available at the above location when downloading the release. For more information on Apache Commons Daemon, visit the Commons Daemon home page: http://commons.apache.org/daemon/ Changes: See RELEASE-NOTES.txt for the list of fixed bugs and new features inside download area. -- Commons Daemon team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] missing java.io.PrintWriter.close() in org.apache.commons.io.testtools.FileBasedTestCase.checkWrite()
Hi Huxing,
since the PrintStream/PrintWriter are built around an existing (open)
OutputStream/Writer: the parameter passed to the method,
it is the responsibility of the caller to close the OutputStream/Writer.
Thus, there is no need to close the PrintStream/PrintWriter (they
would close the underlying OutputStream/Writer, which is not what
would be expected when the method is called).
Regards,
Julien
2010/10/25 Zhang, Huxing huxing.zh...@intel.com:
Dear Apache Commons IO developers,
I found there might be a close method missing in the source code of test
cases, which may be an issue.
No patch seems to be applied till revision 1026932.
How do you guys think?
The original code here is:
In
io/trunk/src/test/java/org/apache/commons/io/testtools/FileBasedTestCase.java
Line 203-223 (revision 1026932)
protected void checkWrite(OutputStream output) throws Exception {
try {
new java.io.PrintStream(output).write(0);
} catch (Throwable t) {
throw new AssertionFailedError(
The copy() method closed the stream
+ when it shouldn't have.
+ t.getMessage());
}
}
protected void checkWrite(Writer output) throws Exception {
try {
new java.io.PrintWriter(output).write('a');
} catch (Throwable t) {
throw new AssertionFailedError(
The copy() method closed the stream
+ when it shouldn't have.
+ t.getMessage());
}
}
The java.io.PrintWriter is initialized without being closed after use. So
does the java.io.PrintStream instance.
Thanks Best regards,
Huxing
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
