You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Umberto Nicoletti <un...@prometeo.it> on 2003/07/09 12:11:15 UTC
[SCAFFOLD] StorageBeanBase feature request
I am in the middle of the process of defining the data access layer to
be used for a new Struts-based application, for which we already use
Scaffold's ProcessBeans.
We decided not to go with Hibernate as a persistence layer (to my
disappointment) and to choose Scaffold Access/StorageBean approach instead.
Reading on this list I found an email by Ted Husted saying that he was
(maybe still is?) not happy with the StorageBean deployment.
So my question is what should I do? I quite like the Scaffold data
access layer and more importantly my DBA trusts it too.
I'd prefer to go with StorageBeanBase, but in this case I should make
minor modifications to the Scaffold code (which I will give back to the
community of course). The other option is the Access approach, but it is
deprecated and it is not nice to compile an application with lots of
warnings.
The modifications I have to introduce in the StorageBeanBase are:
replace all calls to
StatementUtils.executeUpdate(null,etc);
with:
StatementUtils.executeUpdate(getResource(),etc);
and add a static String resource=null; with getters and setters
that can be overriden by subclasses. This is motivated by tha fact that
I have tables located in many different schemas/db hosts and want
ConnectionAdaptor to return the right connection for that schema/db host.
Thank you,
Umberto
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [SCAFFOLD] StorageBeanBase feature request
Posted by Ted Husted <hu...@apache.org>.
Umberto Nicoletti wrote:
> So when ResultSetUtils call getMetaData() the resultSet throws
> SQLException: connection closed.
Yes, that's one of the patches I need to apply. The JDBC driver I was
using is buggy and allowed it to be closed early than the specification
permits.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [SCAFFOLD] StorageBeanBase feature request
Posted by Umberto Nicoletti <un...@prometeo.it>.
Thanks Ted,
I already generated an in-house version of Scaffold with my patch, but
got into another trouble.
I got my StorageBeanBase working, but get ResourceExcptions when
executing findCollection(), which in turns call getCollection.
What I see is that the prepared statement is closed before the
collection is populated from the ResultSet.
So when ResultSetUtils call getMetaData() the resultSet throws
SQLException: connection closed.
What am I missing? Please bear with me, even though I am posting on the
wrong ml (but I knew you were here).
Code snippet from StatementUtils:
public static final ResultSet executeQuery(
Connection connection,
String command,
Object[] parameters)
throws SQLException {
Statement statement = null;
PreparedStatement preparedStatement = null;
ResultSet resultSet = null;
try {
if ((parameters==null) || (parameters.length==0)) {
statement = connection.createStatement();
resultSet = statement.executeQuery(command);
}
else {
preparedStatement = connection.prepareStatement(command);
for (int i=0; i<parameters.length; i++) {
preparedStatement.setObject(i+1, parameters[i]);
}
resultSet = preparedStatement.executeQuery();
}
}
finally {
try {
//
// WHY ARE YOU CLOSING THE STATEMENT HERE????
// CLOSING THE STATEMENT HERE RELEASE THE RESULTSET TOO...
//
if (statement != null) statement.close();
if (preparedStatement != null) preparedStatement.close();
}
catch (SQLException sqle) {}
}
return resultSet;
} // end executeQuery
Thank you in advance,
Umberto
Ted Husted wrote:
> I'm not using the SQL parts of Scaffold in new development. For new
> development, I'm now using Hiberate.
>
> I'm away next week, but later this month, I'll apply some outstanding
> patches to Scaffold, and look at providing a direct alternative to the
> SQL package using either Commons SQL/Dynabeans, the new Mapping package
> in the Jakarta Commons sandbox, or Ibatis. There are just too many other
> likely alternatives now to keep this package alive.
>
> Of course, you can always check-out the code yourself and use as part of
> in-house development.
>
> The Access paradigm is not strongly linked to the StorageBeans.
> Essentially, it's just a facade, and you could use anything you like
> behind the facade. (Say Hibernate, for example.)
>
> -Ted.
>
> Umberto Nicoletti wrote:
>
>> I am in the middle of the process of defining the data access layer to
>> be used for a new Struts-based application, for which we already use
>> Scaffold's ProcessBeans.
>>
>> We decided not to go with Hibernate as a persistence layer (to my
>> disappointment) and to choose Scaffold Access/StorageBean approach
>> instead.
>> Reading on this list I found an email by Ted Husted saying that he was
>> (maybe still is?) not happy with the StorageBean deployment.
>>
>> So my question is what should I do? I quite like the Scaffold data
>> access layer and more importantly my DBA trusts it too.
>> I'd prefer to go with StorageBeanBase, but in this case I should make
>> minor modifications to the Scaffold code (which I will give back to
>> the community of course). The other option is the Access approach, but
>> it is deprecated and it is not nice to compile an application with
>> lots of warnings.
>>
>> The modifications I have to introduce in the StorageBeanBase are:
>>
>> replace all calls to
>>
>> StatementUtils.executeUpdate(null,etc);
>>
>> with:
>>
>> StatementUtils.executeUpdate(getResource(),etc);
>>
>> and add a static String resource=null; with getters and setters
>> that can be overriden by subclasses. This is motivated by tha fact
>> that I have tables located in many different schemas/db hosts and want
>> ConnectionAdaptor to return the right connection for that schema/db host.
>>
>> Thank you,
>> Umberto
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [SCAFFOLD] StorageBeanBase feature request
Posted by Ted Husted <hu...@apache.org>.
I'm not using the SQL parts of Scaffold in new development. For new
development, I'm now using Hiberate.
I'm away next week, but later this month, I'll apply some outstanding
patches to Scaffold, and look at providing a direct alternative to the
SQL package using either Commons SQL/Dynabeans, the new Mapping package
in the Jakarta Commons sandbox, or Ibatis. There are just too many other
likely alternatives now to keep this package alive.
Of course, you can always check-out the code yourself and use as part of
in-house development.
The Access paradigm is not strongly linked to the StorageBeans.
Essentially, it's just a facade, and you could use anything you like
behind the facade. (Say Hibernate, for example.)
-Ted.
Umberto Nicoletti wrote:
> I am in the middle of the process of defining the data access layer to
> be used for a new Struts-based application, for which we already use
> Scaffold's ProcessBeans.
>
> We decided not to go with Hibernate as a persistence layer (to my
> disappointment) and to choose Scaffold Access/StorageBean approach instead.
> Reading on this list I found an email by Ted Husted saying that he was
> (maybe still is?) not happy with the StorageBean deployment.
>
> So my question is what should I do? I quite like the Scaffold data
> access layer and more importantly my DBA trusts it too.
> I'd prefer to go with StorageBeanBase, but in this case I should make
> minor modifications to the Scaffold code (which I will give back to the
> community of course). The other option is the Access approach, but it is
> deprecated and it is not nice to compile an application with lots of
> warnings.
>
> The modifications I have to introduce in the StorageBeanBase are:
>
> replace all calls to
>
> StatementUtils.executeUpdate(null,etc);
>
> with:
>
> StatementUtils.executeUpdate(getResource(),etc);
>
> and add a static String resource=null; with getters and setters
> that can be overriden by subclasses. This is motivated by tha fact that
> I have tables located in many different schemas/db hosts and want
> ConnectionAdaptor to return the right connection for that schema/db host.
>
> Thank you,
> Umberto
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [SCAFFOLD] StorageBeanBase feature request
Posted by Umberto Nicoletti <un...@prometeo.it>.
I have submitted a patch to Bugzilla
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21433) for this issue.
Is there anyone interested in it?
Thanks,
Umberto
Umberto Nicoletti wrote:
> I am in the middle of the process of defining the data access layer to
> be used for a new Struts-based application, for which we already use
> Scaffold's ProcessBeans.
>
> We decided not to go with Hibernate as a persistence layer (to my
> disappointment) and to choose Scaffold Access/StorageBean approach instead.
> Reading on this list I found an email by Ted Husted saying that he was
> (maybe still is?) not happy with the StorageBean deployment.
>
> So my question is what should I do? I quite like the Scaffold data
> access layer and more importantly my DBA trusts it too.
> I'd prefer to go with StorageBeanBase, but in this case I should make
> minor modifications to the Scaffold code (which I will give back to the
> community of course). The other option is the Access approach, but it is
> deprecated and it is not nice to compile an application with lots of
> warnings.
>
> The modifications I have to introduce in the StorageBeanBase are:
>
> replace all calls to
>
> StatementUtils.executeUpdate(null,etc);
>
> with:
>
> StatementUtils.executeUpdate(getResource(),etc);
>
> and add a static String resource=null; with getters and setters
> that can be overriden by subclasses. This is motivated by tha fact that
> I have tables located in many different schemas/db hosts and want
> ConnectionAdaptor to return the right connection for that schema/db host.
>
> Thank you,
> Umberto
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org