Issue 1:
Celal Ziftci opened SPR-5696 and commented

Currently there are methods that take in "Object[]" for the execution of operations in most of the jdbc.object classes, such as:

SqlUpdate.update(Object[])

MappingSqlQuery.execute(Object[])

It would be very beneficial to have a similar method in StoredProcedure as "execute(Object[])".

I understand that there is a distinction in terms of update or query, and stored procedures in that stored procs can have a mixture of input and output params. However, this can be handled quite easily by using the already existing metadata provided to construct the StoredProcedure.

Below is a sample implementation:

/**
* Avoids having to use a Map, hence to duplicate the keys of the map, which are the parameter names already
* provided while registering the parameters to the {@link StoredProcedure}.
*
* @param values
* the values for the <b>input</b> parameters defined on this stored procedure, in the order of
* registration. It is legal for map entries to be null, and this will produce the correct behavior using
* a NULL argument to the stored procedure.
* @return map of output params, keyed by name as in parameter declarations. Output parameters will appear here,
* with their values after the stored procedure has been called.
*/
public Map execute(Object[] values) {
if (values == null) {
return execute(Collections.EMPTY_MAP);
} else {
List<SqlParameter> params = this.getDeclaredParameters();
List<SqlParameter> inputParams = new ArrayList<SqlParameter>();
// filter the input params
for (SqlParameter sqlParameter : params) {
if (sqlParameter.isInputValueProvided()) {
inputParams.add(sqlParameter);
}
}

// Make sure exactly correct number of arguments are provided
if (inputParams.size() != values.length) {
throw new IllegalArgumentException("There are " + inputParams.size() + " input arguments, but "
+ values.length + " values are provided");
}

// Create a map, and call existing execute method
Map<String, Object> valuesToReturn = new HashMap<String, Object>();
for (int i = 0; i < inputParams.size(); i++) {
valuesToReturn.put(inputParams.get(i).getName(), values[i]);
}
return execute(valuesToReturn);
}
}

The use-case for this is: this avoids having to duplicate the input parameter names twice:

once during the registration of the input parameter with name to StoredProcedure

second, when we construct the Map for values to pass values to StoredProcedure.execute(Map) method

Affects: 3.0 M1

Referenced from: commits 7c05312

Issue 2:
Grzegorz Borkowski opened SPR-5327 and commented

Currently Spring Framework depends on Commons-Logging. All of us know that for long time Commons-Logging has very bad reputation and is the source of many problems, bug, memory leaks etc.

The SLF4j is the newer implementation of similar idea, and many people claim it works much better than Commons-Logging. It contain even some adapter for Commons-Logging users, allowing for gradual transition. Perhaps with Spring 3, along with migration to Java 5, is the best time to migrate also to SLF4J and remove dependency on Commons-Logging?

In fact, you can probably do it somehow automatically, writing the script that will replace in all java files the imports and logger types.

Affects: 3.0 M4

Attachments:

SPR-5327.patch (511.88 kB)

Issue Links:

#12774 Revisit subsystem-oriented logging

#19081 Revisit Commons Logging vs java.util.logging vs SLF4J vs Log4j 2

Referenced from: commits f4763a8, 1a06b6a, ad3fa50, 604a9f0, b7e37dd, 1202f67, 0400ccc

20 votes, 13 watchers