[jira] [Commented] (SANDBOX-423) [BeanUtils2] Wrap checked exceptions from BeanAccessor.get() into BeanReflectionException
[
https://issues.apache.org/jira/browse/SANDBOX-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13408874#comment-13408874
]
Simone Tripodi commented on SANDBOX-423:
Hi Bene,
{quote}
We discussed to throw exceptions as soon as possible to get rid of all the
try/catch code in DefaultBeanAccessor. I started to implement that, but things
got way out of hand, so I decided to go back to the first solution to make it
easier to review.
We can change the exception handling later.
{quote}
I like the way you are implementing that feature, go ahead in that way!!! :)
{quote}
One thing I don't like about my solution is, that an IntrospectionException
will be wrapped in a NoSuchPropertyException, but this is due to the
Introspection API.
{quote}
Let's keep it as it is - hopefully a (maybe?) better solution will come up
later...
{quote}
Also constructing a Property[Setter|Getter]InvocationException feels clumsy
because one has to pass in both, the property name and the property accessor
method name. Maybe you have a suggestion how to improve that?
{quote}
I am not sure there's a better/automatic way... take in consideration that via
the {{*BeanInfo}} classes, users can alter accessor methods, so users'
beans/POJOs not necessarily respect the code conventions...
Positive feedback from my side, I think you can go ahead with on getting rid of
checked exceptions on other {{BeanAccessor}} methods, so I will apply the
patch. Well done! :)
[BeanUtils2] Wrap checked exceptions from BeanAccessor.get() into
BeanReflectionException
-
Key: SANDBOX-423
URL: https://issues.apache.org/jira/browse/SANDBOX-423
Project: Commons Sandbox
Issue Type: Sub-task
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Fix For: Nightly Builds
Attachments: SANDBOX-423.patch, SANDBOX-423v2.patch
* Change method signature of BeanAccessor.get()
* in DefaultBeanAccessor.get() catch all checked exceptions
* modify GetPropertyTestCase accordingly
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-188) Improved Exceptionhandling for unsupported zip compression methods
[ https://issues.apache.org/jira/browse/COMPRESS-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Kuhn updated COMPRESS-188: - Attachment: ZipMethod.java Variant of ZipMethod as enum Improved Exceptionhandling for unsupported zip compression methods -- Key: COMPRESS-188 URL: https://issues.apache.org/jira/browse/COMPRESS-188 Project: Commons Compress Issue Type: Improvement Components: Compressors Affects Versions: 1.4.1 Reporter: Harald Kuhn Priority: Minor Attachments: UnsupportedZipFeatureException.java.patch, ZipMethod.java If an unsupported zip compression methods, the created exception is not very helpfull for analysing why a zip archive could not be opend. Giving a name or description of the method can be very helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-74) New ListResultSetHandler with a ResultSetHandler as parameter
[
https://issues.apache.org/jira/browse/DBUTILS-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13408901#comment-13408901
]
Stevo Slavic commented on DBUTILS-74:
-
Olivier described solution, but I believe what he really wants (please correct
me if wrong) is to have {{ResultSetHandler}} and it's implementations agnostic
of whether it will be used to handle a single result or a collection - it just
needs to focus on handling single {{ResultSet}} row to single object regardless
if that object is a POJO, {{Object}} {{Array}}, or a {{Map}}. In that case
{{QueryRunner}}, like JPA's {{Query}}, should have this logic and separate API
for retrieving a single result, and separate one for retrieving a collection.
IMO this would be major refactoring of the dbutils so it's probably best to
schedule it for next major (2.0) release.
New ListResultSetHandler with a ResultSetHandler as parameter
-
Key: DBUTILS-74
URL: https://issues.apache.org/jira/browse/DBUTILS-74
Project: Commons DbUtils
Issue Type: Improvement
Affects Versions: 1.3
Reporter: Olivier Grégoire
Fix For: 1.5
Original Estimate: 1h
Remaining Estimate: 1h
It would be great if we could have such a class:
public class DefaultListResultSetHandlerT extends AbstractListHandlerT {
public DefaultListResultSetHandler (ResultSetHandlerT handler) {
if (handler == null) throw new NullPointerException();
this.handler = handler;
}
protected T handleRow (ResultSet rs) {
return handler.handle(rs);
}
}
This way, we avoid having two classes, one for the object handler itself and
one for the list handler. It's a all at once.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-92) Align maven groupId with rest of the apache commons projects
[ https://issues.apache.org/jira/browse/DBUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic updated DBUTILS-92: Attachment: pom.xml DBUTILS-92.patch Here's [^DBUTILS-92.patch] with changed groupId (and myself listed as contributor), and minimal relocation [^pom.xml]. Align maven groupId with rest of the apache commons projects Key: DBUTILS-92 URL: https://issues.apache.org/jira/browse/DBUTILS-92 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.4 Reporter: Stevo Slavic Attachments: DBUTILS-92.patch, pom.xml It seems to be the trend (maybe there's even some convention/agreement among Apache Commons developers) that with new releases Apache Commons projects use org.apache.commons as Maven artifact groupId. Please consider aligning commons-dbutils Maven artifacts groupId with this practice. If decided to use org.apache.commons groupId, for the first release with new groupId also consider publishing relocation pom file too with old groupId (see [this|http://maven.apache.org/guides/mini/guide-relocation.html#Releasing_the_next_version] for more info). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-74) New ListResultSetHandler with a ResultSetHandler as parameter
[
https://issues.apache.org/jira/browse/DBUTILS-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13408907#comment-13408907
]
Stevo Slavic commented on DBUTILS-74:
-
[jdbc-helper project @ Google
Code|http://code.google.com/p/jdbc-helper/wiki/Examples] seems to provide
exactly this sort of API.
New ListResultSetHandler with a ResultSetHandler as parameter
-
Key: DBUTILS-74
URL: https://issues.apache.org/jira/browse/DBUTILS-74
Project: Commons DbUtils
Issue Type: Improvement
Affects Versions: 1.3
Reporter: Olivier Grégoire
Fix For: 1.5
Original Estimate: 1h
Remaining Estimate: 1h
It would be great if we could have such a class:
public class DefaultListResultSetHandlerT extends AbstractListHandlerT {
public DefaultListResultSetHandler (ResultSetHandlerT handler) {
if (handler == null) throw new NullPointerException();
this.handler = handler;
}
protected T handleRow (ResultSet rs) {
return handler.handle(rs);
}
}
This way, we avoid having two classes, one for the object handler itself and
one for the list handler. It's a all at once.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-92) Align maven groupId with rest of the apache commons projects
[ https://issues.apache.org/jira/browse/DBUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13408913#comment-13408913 ] Sebb commented on DBUTILS-92: - Unfortunately relocation poms don't work properly (they are not guaranteed to be used), so changing the Maven coords may result in jar hell unless we also change the package name. Align maven groupId with rest of the apache commons projects Key: DBUTILS-92 URL: https://issues.apache.org/jira/browse/DBUTILS-92 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.4 Reporter: Stevo Slavic Attachments: DBUTILS-92.patch, pom.xml It seems to be the trend (maybe there's even some convention/agreement among Apache Commons developers) that with new releases Apache Commons projects use org.apache.commons as Maven artifact groupId. Please consider aligning commons-dbutils Maven artifacts groupId with this practice. If decided to use org.apache.commons groupId, for the first release with new groupId also consider publishing relocation pom file too with old groupId (see [this|http://maven.apache.org/guides/mini/guide-relocation.html#Releasing_the_next_version] for more info). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-92) Align maven groupId with rest of the apache commons projects
[ https://issues.apache.org/jira/browse/DBUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13408963#comment-13408963 ] Stevo Slavic commented on DBUTILS-92: - Oh, right, that's why commons-lang and similar have added numbers to the package names in relocated releases. I think though, unlike commons-lang, that it's much less likely that one would use one variant of dbutils directly and get the other one transitively. Nevertheless, to stay on the safe side, probably better to follow the pattern and include in coordinates change also package change, and do that in a major (2.0) release. Align maven groupId with rest of the apache commons projects Key: DBUTILS-92 URL: https://issues.apache.org/jira/browse/DBUTILS-92 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.4 Reporter: Stevo Slavic Attachments: DBUTILS-92.patch, pom.xml It seems to be the trend (maybe there's even some convention/agreement among Apache Commons developers) that with new releases Apache Commons projects use org.apache.commons as Maven artifact groupId. Please consider aligning commons-dbutils Maven artifacts groupId with this practice. If decided to use org.apache.commons groupId, for the first release with new groupId also consider publishing relocation pom file too with old groupId (see [this|http://maven.apache.org/guides/mini/guide-relocation.html#Releasing_the_next_version] for more info). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-188) Improved Exceptionhandling for unsupported zip compression methods
[ https://issues.apache.org/jira/browse/COMPRESS-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-188. - Resolution: Fixed Fix Version/s: 1.5 slightly modified version of your patch went in with svn revision 1358814 Thanks! Improved Exceptionhandling for unsupported zip compression methods -- Key: COMPRESS-188 URL: https://issues.apache.org/jira/browse/COMPRESS-188 Project: Commons Compress Issue Type: Improvement Components: Compressors Affects Versions: 1.4.1 Reporter: Harald Kuhn Priority: Minor Fix For: 1.5 Attachments: UnsupportedZipFeatureException.java.patch, ZipMethod.java If an unsupported zip compression methods, the created exception is not very helpfull for analysing why a zip archive could not be opend. Giving a name or description of the method can be very helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-188) Improved Exceptionhandling for unsupported zip compression methods
[ https://issues.apache.org/jira/browse/COMPRESS-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409029#comment-13409029 ] Stefan Bodewig commented on COMPRESS-188: - Oh, we used to require Java 1.4 compatibility up until Compress 1.3 and are at Java5 right now. Improved Exceptionhandling for unsupported zip compression methods -- Key: COMPRESS-188 URL: https://issues.apache.org/jira/browse/COMPRESS-188 Project: Commons Compress Issue Type: Improvement Components: Compressors Affects Versions: 1.4.1 Reporter: Harald Kuhn Priority: Minor Fix For: 1.5 Attachments: UnsupportedZipFeatureException.java.patch, ZipMethod.java If an unsupported zip compression methods, the created exception is not very helpfull for analysing why a zip archive could not be opend. Giving a name or description of the method can be very helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
