springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Preparing for 1.0.2

[<jue...@we...>]

Repeated complaints that there were no default editors for =
java.lang.Boolean, java.lang.Integer etc prompted that change. What we =
register by default now are standard instances of CustomBooleanEditor =
and CustomNumberEditor; in the latter case, using =
Integer.parseInt/toString and co rather than a NumberFormat instance.
=20
Of course, those defaults can still be overridden by the usual =
registerCustomEditor calls, typically with custom instances of =
CustomBooleanEditor and CustomNumberEditor. What makes those editors =
"custom" is that they're configurable, in contrast to most other =
PropertyEditors. We just provide default instances of them now, but =
still allow for registering customized instances.
=20
All things considered, that change should be completely =
backward-compatible.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Seth Ladd
Gesendet: Fr 28.05.2004 19:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.2



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

j=FCrgen h=F6ller [werk3AT] wrote:

| I plan to release 1.0.2 tomorrow morning - finally...
|
| BTW, I'm committing a couple of minor refinements during the course of
today. Among them is that BeanWrapperImpl registers default editors for
Boolean and Number objects now, using Integer.valueOf/toString etc.

Interesting... what prompted the change?  The javadocs previously
mentioned that they weren't meant for system wide property editors.

Will we still be able to bind a NumberFormat w/ a Locale (per request)
as a property editor to override the default property editor?

Thanks!
Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAt3zsKZsFSwtW+wIRAokOAJ4gHiJ6DnMoqCp4el3sTXN0eLozNgCfTXBZ
ryg/UsA2aTfw8lEdEGY3AkM=3D
=3D7tKb
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Ibatis integration corrections needed

[<jue...@we...>]

I've actually added the "queryWithRowHandler" method in the course of my =
changes today, and deprecated the "queryForList(..., RowHandler)" =
version. I've noticed the deprecation already at the time of SQL Maps =
2.0 RC4, but somehow forgot to adapt Spring's support classes =
immediately (although I promised to do it on the iBATIS forums).
=20
So if you fetch the DataSource/TransactionManager changes, you should =
get the "queryWithRowHandler" version too. Once we ship SQL Maps 2.0 =
final (probably in Spring 1.0.3?), I'll probably remove the =
"queryForList(..., RowHandler)" method entirely.
=20
Regarding SqlMapClientCallback: That's mainly used for implementing =
SqlMapClientTemplate's one-line operations. It's also available for =
applications, but the only scenario where I actually recommend this is =
statement batching: executor.startBatch, various operations, =
executor.executeBatch(). Such a batch needs to be executed on one single =
SqlMapExecutor, which SqlMapClientCallback provides.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Brandon Goodin
Gesendet: So 30.05.2004 01:53
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections =
needed



Sorry if this was received 2 or 3 times. I received a message email back =
2
times that said the last one I sent was too large. So, I felt it =
important
to post again.

Followin are some issues that need to be resolved...

Line 54 of SqlMapClientOperations:

List queryForList(String statementName, Object parameterObject, =
RowHandler
rowHandler)
                  throws DataAccessException;
                =20
should be..

void queryWithRowhandler(String statementName, Object parameterObject,
RowHandler rowHandler)
                  throws DataAccessException;
                =20
Line 185-192 of SqlMapClientTemplate needs to be changed in a similar
manner:

public List queryForList(final String statementName, final Object
parameterObject,

final RowHandler rowHandler) throws DataAccessException {
  return executeWithListResult(new SqlMapClientCallback() {
    public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {
      return executor.queryForList(statementName, parameterObject,
rowHandler);
    }
  });
}

Should be:

I am assuming you do not want to implement another method on your
SqlMapClientCallback just to accommodate the queryWithRowHandler. So, I
simply pass back a null from the doInSqlMapClient of the
SqlMapClientCallback implementation and ignore it.

public void queryWithRowHandler(final String statementName, final Object
parameterObject,
final RowHandler rowHandler) throws DataAccessException {
  executeWithRowHandler(new SqlMapClientCallback() {
    public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {
      executor.queryWithRowHandler(statementName, parameterObject,
rowHandler);
      return null;
    }
  });
}

Also, the following should be added to the SqlMapClientTemplate

/**
 * Execute the given data access action on a SqlMapSession
 * with a RowHandler.
 * @param action callback object that specifies the data access action
 * @return the List result
 * @throws DataAccessException in case of SQL Maps errors
 */

public void executeWithRowHandler(SqlMapClientCallback action) throws
DataAccessException {
  execute(action);
}

Apart from all of this I am rather curious about the purpose the
SqlMapClientCallback? I read the javadoc and am wondering what role it =
plays
in the process of Spring integration with iBatis. Could you provide me =
with
a explanation of it's role?

Thanks,
Brandon Goodin
http://www.ibatis.com




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Ibatis integration corrections needed

[Brandon G. <ma...@ph...>]

Sorry if this was received 2 or 3 times. I received a message email back 2
times that said the last one I sent was too large. So, I felt it important
to post again.

Followin are some issues that need to be resolved...

Line 54 of SqlMapClientOperations:

List queryForList(String statementName, Object parameterObject, RowHandler
rowHandler)
                  throws DataAccessException;
                  
should be..

void queryWithRowhandler(String statementName, Object parameterObject,
RowHandler rowHandler)
                  throws DataAccessException;
                  
Line 185-192 of SqlMapClientTemplate needs to be changed in a similar
manner:

public List queryForList(final String statementName, final Object
parameterObject,

final RowHandler rowHandler) throws DataAccessException {
  return executeWithListResult(new SqlMapClientCallback() {
    public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {
      return executor.queryForList(statementName, parameterObject,
rowHandler);
    }
  });
} 

Should be:

I am assuming you do not want to implement another method on your
SqlMapClientCallback just to accommodate the queryWithRowHandler. So, I
simply pass back a null from the doInSqlMapClient of the
SqlMapClientCallback implementation and ignore it.

public void queryWithRowHandler(final String statementName, final Object
parameterObject,
final RowHandler rowHandler) throws DataAccessException {
  executeWithRowHandler(new SqlMapClientCallback() {
    public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {
      executor.queryWithRowHandler(statementName, parameterObject,
rowHandler);
      return null;
    }
  });
}

Also, the following should be added to the SqlMapClientTemplate

/**
 * Execute the given data access action on a SqlMapSession 
 * with a RowHandler.
 * @param action callback object that specifies the data access action
 * @return the List result
 * @throws DataAccessException in case of SQL Maps errors
 */

public void executeWithRowHandler(SqlMapClientCallback action) throws
DataAccessException {
  execute(action);
}

Apart from all of this I am rather curious about the purpose the
SqlMapClientCallback? I read the javadoc and am wondering what role it plays
in the process of Spring integration with iBatis. Could you provide me with
a explanation of it's role?

Thanks,
Brandon Goodin
http://www.ibatis.com

RE: [Springframework-developer] Ibatis integration corrections needed

[Brandon G. <ma...@ph...>]

Sorry if this was received twice. I received a message email back that said
the last one I sent was too large. So, I felt it important to post again.

 

I know I should be adding these to a bug report. But, I figured that I could
do it all in one bug report once the more complex issue of transaction
management is resolved.

 

I have found another issue that needs to be remedied.

 

Line 54 of SqlMapClientOpertaions:

 

List queryForList(String statementName, Object parameterObject, RowHandler
rowHandler)

                  throws DataAccessException;

 

should be..

 

void queryWithRowhandler(String statementName, Object parameterObject,
RowHandler rowHandler)

                  throws DataAccessException;

 

 

Line 185-192 of SqlMapClientTemplate needs to be changed in a similar
manner:

 

public List queryForList(final String statementName, final Object
parameterObject,

final RowHandler rowHandler) throws DataAccessException {

      return executeWithListResult(new SqlMapClientCallback() {

            public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {

                  return executor.queryForList(statementName,
parameterObject, rowHandler);

            }

      });

}

 

Should be:

 

I am assuming you do not want to implement another method on your
SqlMapClientCallback just to accommodate the queryWithRowHandler. So, I
simply pass back a null from the doInSqlMapClient of the
SqlMapClientCallback implementation and ignore it.

 

public void queryWithRowHandler(final String statementName, final Object
parameterObject,

final RowHandler rowHandler) throws DataAccessException {

            executeWithRowHandler(new SqlMapClientCallback() {

            public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {

                  executor.queryWithRowHandler(statementName,
parameterObject, rowHandler);

                  return null;

            }

      });

}

 

Also, the following should be added to the SqlMapClientTemplate

/**

 * Execute the given data access action on a SqlMapSession 

 * with a RowHandler.

 * @param action callback object that specifies the data access action

 * @return the List result

 * @throws DataAccessException in case of SQL Maps errors

 */

public void executeWithRowHandler(SqlMapClientCallback action) throws
DataAccessException {

      execute(action);

}

 

 

Apart from all of this I am rather curious about the purpose the
SqlMapClientCallback? I read the javadoc and am wondering what role it plays
in the process of Spring integration with iBatis. Could you provide me with
a explanation of it's role?

 

Thanks,

Brandon Goodin

http://www.ibatis.com

RE: [Springframework-developer] Ibatis integration corrections needed

[Brandon G. <ma...@ph...>]

Juergen,

Did you get the changes for the executeWithRowHandler changes committed?
Those are important. Because once the final release of ibatis is out the
current integration with Spring will break. I wasn't sure if you got the
email because I received an email from the list that said my posting was =
too
large and it was awaiting approval by the moderator.

Brandon

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of j=FCrgen h=F6ller [werk3AT]
> Sent: Saturday, May 29, 2004 2:31 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Ibatis integration =
corrections
> needed
>=20
> :-))
>=20
> The difference is: This time it's gonna happen. I know, I already said
> that earlier too ;-) Argh, release management, argh, time planning... =
and
> the ability to say "rien ne va plus" for a specific release.
>=20
> Some of the stuff that I've still considered for 1.0.2, like Keith's
> BatchSqlUpdate class or opening up the ApplicationEventMulticaster, is =
now
> *not* gonna happen for 1.0.2. But today's iBATIS SQL Maps refinements =
will
> be included!
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> Fernando Martins
> Gesendet: Sa 29.05.2004 23:11
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Ibatis integration =
corrections
> needed
>=20
>=20
>=20
>=20
> On Saturday 29 May 2004 22:38, j=FCrgen h=F6ller [werk3AT] wrote:
> > ... Just in time for 1.0.2, to be released tomorrow.
>=20
> http://imdb.com/title/tt0107048/
>=20
> ;-)
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Ibatis integration corrections needed

[<jue...@we...>]

:-))
=20
The difference is: This time it's gonna happen. I know, I already said =
that earlier too ;-) Argh, release management, argh, time planning... =
and the ability to say "rien ne va plus" for a specific release.
=20
Some of the stuff that I've still considered for 1.0.2, like Keith's =
BatchSqlUpdate class or opening up the ApplicationEventMulticaster, is =
now *not* gonna happen for 1.0.2. But today's iBATIS SQL Maps =
refinements will be included!
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Fernando Martins
Gesendet: Sa 29.05.2004 23:11
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections =
needed




On Saturday 29 May 2004 22:38, j=FCrgen h=F6ller [werk3AT] wrote:
> ... Just in time for 1.0.2, to be released tomorrow.

http://imdb.com/title/tt0107048/

;-)



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Ibatis integration corrections needed

[<jue...@we...>]

Just committed. As I said, might take a while before it's available from =
public CVS.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Brandon Goodin
Gesendet: Sa 29.05.2004 22:59
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections =
needed



excellent, thanks a ton j=FCrgen.

Brandon

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 2:39 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


I've just tried with a lazy-loading PaginatedList - works like a charm! =
And
it still works nicely with the old usage pattern too.

Gonna commit it within the next 30 minutes... might take about 2 or 3 =
hours
to be available from public CVS, though.

Brandon, thanks for that really valuable hint :-) Just in time for =
1.0.2, to
be released tomorrow.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Brandon Goodin
Gesendet: Sa 29.05.2004 22:25
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



excellent, i'll give it a try.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 2:07 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Actually, this seems to work great: Specify the DataSource once on
SqlMapClientFactoryBean rather than on each DAO, and still set the
UserConnection in SqlMapClientTemplate. The latter simply fetches the
DataSource from the SqlMapClient in this case. As far as I understand =
that,
this should allow for proper lazy loading...

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:46
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections
needed



What about initializing the iBATIS TransactionManager in the way that =
you
suggested, and *still* pass in transactional Connections via
setUserConnection? That could give the best of both worlds: =
participating in
all kinds of Spring-managed transactions, and allowing for lazy loading. =
It
would also avoid the need to pass the DataSource to each and every
SQL-Maps-based DAO; a single passing of the DataSource to the
SqlMapClientFactoryBean would then be sufficient.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:24
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections
needed



The problem is that we'd pass the DataSource to the iBATIS
TransactionManager here, but not Spring-managed transactional =
Connections.
SQL Maps would fetch its own Connections from the given DataSource, =
failing
to participate in Spring-managed transactions (other than JTA).

I'm aware that lazy loading won't work with Spring's current iBATIS
integration strategy. However, I'm not aware of any other disadvantages; =
can
you give details in that respect?

I wouldn't mind letting SQL Maps create its own Connections from the
DataSource for lazy loading, if told to do so. But we'd need to figure =
out a
way to pass a transactional Connection in for the actual operation (like =
we
do currently) and still allow for lazy loading via a given DataSource.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Brandon Goodin
Gesendet: Sa 29.05.2004 20:48
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



The issue here of setting the datasource still remains. If you set the
connection via the setUserConnection it doesn't take full advantage of
ibatis. However, it is possible to allow for Spring to be the iBatis
TransactionManager. You simply need to set up an EXTERNAL =
TransactionConfig
to use in the TransactionManager. Please review my previous code. It =
shows
exactly how that is set. If you feel that iBatis may need to provide =
better
integrtion points for Spring to take advantage of... feel free to =
provide
suggestions.

Thanks,
Brandon Goodin
http://www.ibatis.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Hi again, Brandon,

While I agree that Spring allows iBATIS users to choose between Spring's =
own
transaction management and iBATIS transaction management, this does not
necessarily affect the iBATIS support classes that we provide: Those =
classes
are specifically meant to integrate SQL Maps into Spring's resource and
transaction management, potentially sharing transactions with other data
access strategies within Spring (for example, plain JDBC or Hibernate).

As far as I understand, the SqlMapClient API already allows for simple
one-line operations when using its own resource and transaction =
management.
So effectively, you don't need to use Spring's SqlMapClientTemplate in =
that
scenario: Simply use the SqlMapClient instance directly. Of course, you =
can
still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient =
in
the application context, passing it to your DAOs via bean references.

A disadvantage that I see with direct SqlMapClient usage is that you =
have to
deal with checked SQLExceptions that your DAOs throw. However, that's =
also
the case with your iBATIS transaction demarcation code, so that will be
consistent throughout the application. The alternative is to use =
Spring's
resource and transaction management: throwing unchecked =
DataAccessExceptions
from DAOs (like SqlMapClientTemplate does), and unchecked
TransactionExceptions from transaction demarcation code (like Spring's
PlatformTransactionManager interface and declarative demarcation =
facilities
do).

So in the end, there are two choices for using Spring in combination =
with
iBATIS SQL Maps: either Spring resource and transaction management (->
coding your DAOs with SqlMapClientTemplate), or iBATIS resource and
transaction management (-> coding your DAOs with SqlMapClient directly). =
I
don't see a need to rework SqlMapClientTemplate here: Simply use
SqlMapClient directly in your scenario; you can still leverage all of
Spring's IoC facilities.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



Also, after some exploration I have discovered that Spring requires that =
the
Datasource be set via the <property name=3D"dataSource"> on the =
SqlMapDaos.
This is not good. What happens when someone wants to allow iBatis to =
manage
transactions on it's own? I think that the datasource requirement needs =
to
be removed. Setting the datasource via spring should be optional not
required.



Brandon Goodin

http://www.ibatis.com



________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections =
needed



Greetings,



My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had
time recently I've become increasingly more familiar with the Spring =
product
and began to explore the code base. I specifically have examined the =
iBatis
integration and noticed a problem in how the datasource is being set.



In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).



The short explanation is that Spring needs to set the the Datasource via =
the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig =
which
contains the datasource and various other pertinent config info for
transactions.



Following is a chunk from the XmlSqlMapClientBuilder that demonstrates =
how
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) =
Resources.instantiate(type);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
cti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could =
not
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---



From what I can tell Spring allows for iBatis users to take advantage of =
the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is =
left
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)=

for the configuration of the datasource. The ExternalTransactionConfig =
will
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).



I'd be happy to work on the Spring code base if you would like or =
provide
you with more insight if you need. Let me know.



Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Ibatis integration corrections needed

[Fernando M. <fm...@ar...>]

On Saturday 29 May 2004 22:38, j=FCrgen h=F6ller [werk3AT] wrote:
> ... Just in time for 1.0.2, to be released tomorrow.

http://imdb.com/title/tt0107048/

;-)

RE: [Springframework-developer] Ibatis integration corrections needed

[Brandon G. <ma...@ph...>]

excellent, thanks a ton j=FCrgen.

Brandon

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 2:39 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


I've just tried with a lazy-loading PaginatedList - works like a charm! A=
nd
it still works nicely with the old usage pattern too.

Gonna commit it within the next 30 minutes... might take about 2 or 3 hou=
rs
to be available from public CVS, though.

Brandon, thanks for that really valuable hint :-) Just in time for 1.0.2,=
 to
be released tomorrow.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Brandon Goodin
Gesendet: Sa 29.05.2004 22:25
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



excellent, i'll give it a try.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 2:07 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Actually, this seems to work great: Specify the DataSource once on
SqlMapClientFactoryBean rather than on each DAO, and still set the
UserConnection in SqlMapClientTemplate. The latter simply fetches the
DataSource from the SqlMapClient in this case. As far as I understand tha=
t,
this should allow for proper lazy loading...

Juergen


________________________________

Von: spr...@li... im Auftrag von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:46
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections
needed



What about initializing the iBATIS TransactionManager in the way that you
suggested, and *still* pass in transactional Connections via
setUserConnection? That could give the best of both worlds: participating=
 in
all kinds of Spring-managed transactions, and allowing for lazy loading. =
It
would also avoid the need to pass the DataSource to each and every
SQL-Maps-based DAO; a single passing of the DataSource to the
SqlMapClientFactoryBean would then be sufficient.

Juergen


________________________________

Von: spr...@li... im Auftrag von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:24
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections
needed



The problem is that we'd pass the DataSource to the iBATIS
TransactionManager here, but not Spring-managed transactional Connections.
SQL Maps would fetch its own Connections from the given DataSource, faili=
ng
to participate in Spring-managed transactions (other than JTA).

I'm aware that lazy loading won't work with Spring's current iBATIS
integration strategy. However, I'm not aware of any other disadvantages; =
can
you give details in that respect?

I wouldn't mind letting SQL Maps create its own Connections from the
DataSource for lazy loading, if told to do so. But we'd need to figure ou=
t a
way to pass a transactional Connection in for the actual operation (like =
we
do currently) and still allow for lazy loading via a given DataSource.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Brandon Goodin
Gesendet: Sa 29.05.2004 20:48
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



The issue here of setting the datasource still remains. If you set the
connection via the setUserConnection it doesn't take full advantage of
ibatis. However, it is possible to allow for Spring to be the iBatis
TransactionManager. You simply need to set up an EXTERNAL TransactionConf=
ig
to use in the TransactionManager. Please review my previous code. It show=
s
exactly how that is set. If you feel that iBatis may need to provide bett=
er
integrtion points for Spring to take advantage of... feel free to provide
suggestions.

Thanks,
Brandon Goodin
http://www.ibatis.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Hi again, Brandon,

While I agree that Spring allows iBATIS users to choose between Spring's =
own
transaction management and iBATIS transaction management, this does not
necessarily affect the iBATIS support classes that we provide: Those clas=
ses
are specifically meant to integrate SQL Maps into Spring's resource and
transaction management, potentially sharing transactions with other data
access strategies within Spring (for example, plain JDBC or Hibernate).

As far as I understand, the SqlMapClient API already allows for simple
one-line operations when using its own resource and transaction managemen=
t.
So effectively, you don't need to use Spring's SqlMapClientTemplate in th=
at
scenario: Simply use the SqlMapClient instance directly. Of course, you c=
an
still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient in
the application context, passing it to your DAOs via bean references.

A disadvantage that I see with direct SqlMapClient usage is that you have=
 to
deal with checked SQLExceptions that your DAOs throw. However, that's als=
o
the case with your iBATIS transaction demarcation code, so that will be
consistent throughout the application. The alternative is to use Spring's
resource and transaction management: throwing unchecked DataAccessExcepti=
ons
from DAOs (like SqlMapClientTemplate does), and unchecked
TransactionExceptions from transaction demarcation code (like Spring's
PlatformTransactionManager interface and declarative demarcation faciliti=
es
do).

So in the end, there are two choices for using Spring in combination with
iBATIS SQL Maps: either Spring resource and transaction management (->
coding your DAOs with SqlMapClientTemplate), or iBATIS resource and
transaction management (-> coding your DAOs with SqlMapClient directly). =
I
don't see a need to rework SqlMapClientTemplate here: Simply use
SqlMapClient directly in your scenario; you can still leverage all of
Spring's IoC facilities.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



Also, after some exploration I have discovered that Spring requires that =
the
Datasource be set via the <property name=3D"dataSource"> on the SqlMapDao=
s.
This is not good. What happens when someone wants to allow iBatis to mana=
ge
transactions on it's own? I think that the datasource requirement needs t=
o
be removed. Setting the datasource via spring should be optional not
required.



Brandon Goodin

http://www.ibatis.com



________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections neede=
d



Greetings,



My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had
time recently I've become increasingly more familiar with the Spring prod=
uct
and began to explore the code base. I specifically have examined the iBat=
is
integration and noticed a problem in how the datasource is being set.



In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).



The short explanation is that Spring needs to set the the Datasource via =
the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig which
contains the datasource and various other pertinent config info for
transactions.



Following is a chunk from the XmlSqlMapClientBuilder that demonstrates ho=
w
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) Resources.instantiate(ty=
pe);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
cti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could n=
ot
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---



From what I can tell Spring allows for iBatis users to take advantage of =
the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is lef=
t
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)
for the configuration of the datasource. The ExternalTransactionConfig wi=
ll
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).



I'd be happy to work on the Spring code base if you would like or provide
you with more insight if you need. Let me know.



Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Ibatis integration corrections needed

[<jue...@we...>]

I've just tried with a lazy-loading PaginatedList - works like a charm! =
And it still works nicely with the old usage pattern too.
=20
Gonna commit it within the next 30 minutes... might take about 2 or 3 =
hours to be available from public CVS, though.
=20
Brandon, thanks for that really valuable hint :-) Just in time for =
1.0.2, to be released tomorrow.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Brandon Goodin
Gesendet: Sa 29.05.2004 22:25
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections =
needed



excellent, i'll give it a try.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 2:07 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Actually, this seems to work great: Specify the DataSource once on
SqlMapClientFactoryBean rather than on each DAO, and still set the
UserConnection in SqlMapClientTemplate. The latter simply fetches the
DataSource from the SqlMapClient in this case. As far as I understand =
that,
this should allow for proper lazy loading...

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:46
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections
needed



What about initializing the iBATIS TransactionManager in the way that =
you
suggested, and *still* pass in transactional Connections via
setUserConnection? That could give the best of both worlds: =
participating in
all kinds of Spring-managed transactions, and allowing for lazy loading. =
It
would also avoid the need to pass the DataSource to each and every
SQL-Maps-based DAO; a single passing of the DataSource to the
SqlMapClientFactoryBean would then be sufficient.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:24
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections
needed



The problem is that we'd pass the DataSource to the iBATIS
TransactionManager here, but not Spring-managed transactional =
Connections.
SQL Maps would fetch its own Connections from the given DataSource, =
failing
to participate in Spring-managed transactions (other than JTA).

I'm aware that lazy loading won't work with Spring's current iBATIS
integration strategy. However, I'm not aware of any other disadvantages; =
can
you give details in that respect?

I wouldn't mind letting SQL Maps create its own Connections from the
DataSource for lazy loading, if told to do so. But we'd need to figure =
out a
way to pass a transactional Connection in for the actual operation (like =
we
do currently) and still allow for lazy loading via a given DataSource.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Brandon Goodin
Gesendet: Sa 29.05.2004 20:48
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



The issue here of setting the datasource still remains. If you set the
connection via the setUserConnection it doesn't take full advantage of
ibatis. However, it is possible to allow for Spring to be the iBatis
TransactionManager. You simply need to set up an EXTERNAL =
TransactionConfig
to use in the TransactionManager. Please review my previous code. It =
shows
exactly how that is set. If you feel that iBatis may need to provide =
better
integrtion points for Spring to take advantage of... feel free to =
provide
suggestions.

Thanks,
Brandon Goodin
http://www.ibatis.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Hi again, Brandon,

While I agree that Spring allows iBATIS users to choose between Spring's =
own
transaction management and iBATIS transaction management, this does not
necessarily affect the iBATIS support classes that we provide: Those =
classes
are specifically meant to integrate SQL Maps into Spring's resource and
transaction management, potentially sharing transactions with other data
access strategies within Spring (for example, plain JDBC or Hibernate).

As far as I understand, the SqlMapClient API already allows for simple
one-line operations when using its own resource and transaction =
management.
So effectively, you don't need to use Spring's SqlMapClientTemplate in =
that
scenario: Simply use the SqlMapClient instance directly. Of course, you =
can
still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient =
in
the application context, passing it to your DAOs via bean references.

A disadvantage that I see with direct SqlMapClient usage is that you =
have to
deal with checked SQLExceptions that your DAOs throw. However, that's =
also
the case with your iBATIS transaction demarcation code, so that will be
consistent throughout the application. The alternative is to use =
Spring's
resource and transaction management: throwing unchecked =
DataAccessExceptions
from DAOs (like SqlMapClientTemplate does), and unchecked
TransactionExceptions from transaction demarcation code (like Spring's
PlatformTransactionManager interface and declarative demarcation =
facilities
do).

So in the end, there are two choices for using Spring in combination =
with
iBATIS SQL Maps: either Spring resource and transaction management (->
coding your DAOs with SqlMapClientTemplate), or iBATIS resource and
transaction management (-> coding your DAOs with SqlMapClient directly). =
I
don't see a need to rework SqlMapClientTemplate here: Simply use
SqlMapClient directly in your scenario; you can still leverage all of
Spring's IoC facilities.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



Also, after some exploration I have discovered that Spring requires that =
the
Datasource be set via the <property name=3D"dataSource"> on the =
SqlMapDaos.
This is not good. What happens when someone wants to allow iBatis to =
manage
transactions on it's own? I think that the datasource requirement needs =
to
be removed. Setting the datasource via spring should be optional not
required.



Brandon Goodin

http://www.ibatis.com



________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections =
needed



Greetings,



My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had
time recently I've become increasingly more familiar with the Spring =
product
and began to explore the code base. I specifically have examined the =
iBatis
integration and noticed a problem in how the datasource is being set.



In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).



The short explanation is that Spring needs to set the the Datasource via =
the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig =
which
contains the datasource and various other pertinent config info for
transactions.



Following is a chunk from the XmlSqlMapClientBuilder that demonstrates =
how
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) =
Resources.instantiate(type);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
cti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could =
not
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---



From what I can tell Spring allows for iBatis users to take advantage of =
the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is =
left
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)=

for the configuration of the datasource. The ExternalTransactionConfig =
will
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).



I'd be happy to work on the Spring code base if you would like or =
provide
you with more insight if you need. Let me know.



Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Ibatis integration corrections needed

[Brandon G. <ma...@ph...>]

excellent, i'll give it a try.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 2:07 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Actually, this seems to work great: Specify the DataSource once on
SqlMapClientFactoryBean rather than on each DAO, and still set the
UserConnection in SqlMapClientTemplate. The latter simply fetches the
DataSource from the SqlMapClient in this case. As far as I understand tha=
t,
this should allow for proper lazy loading...

Juergen


________________________________

Von: spr...@li... im Auftrag von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:46
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections
needed



What about initializing the iBATIS TransactionManager in the way that you
suggested, and *still* pass in transactional Connections via
setUserConnection? That could give the best of both worlds: participating=
 in
all kinds of Spring-managed transactions, and allowing for lazy loading. =
It
would also avoid the need to pass the DataSource to each and every
SQL-Maps-based DAO; a single passing of the DataSource to the
SqlMapClientFactoryBean would then be sufficient.

Juergen


________________________________

Von: spr...@li... im Auftrag von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:24
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections
needed



The problem is that we'd pass the DataSource to the iBATIS
TransactionManager here, but not Spring-managed transactional Connections.
SQL Maps would fetch its own Connections from the given DataSource, faili=
ng
to participate in Spring-managed transactions (other than JTA).

I'm aware that lazy loading won't work with Spring's current iBATIS
integration strategy. However, I'm not aware of any other disadvantages; =
can
you give details in that respect?

I wouldn't mind letting SQL Maps create its own Connections from the
DataSource for lazy loading, if told to do so. But we'd need to figure ou=
t a
way to pass a transactional Connection in for the actual operation (like =
we
do currently) and still allow for lazy loading via a given DataSource.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Brandon Goodin
Gesendet: Sa 29.05.2004 20:48
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



The issue here of setting the datasource still remains. If you set the
connection via the setUserConnection it doesn't take full advantage of
ibatis. However, it is possible to allow for Spring to be the iBatis
TransactionManager. You simply need to set up an EXTERNAL TransactionConf=
ig
to use in the TransactionManager. Please review my previous code. It show=
s
exactly how that is set. If you feel that iBatis may need to provide bett=
er
integrtion points for Spring to take advantage of... feel free to provide
suggestions.

Thanks,
Brandon Goodin
http://www.ibatis.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Hi again, Brandon,

While I agree that Spring allows iBATIS users to choose between Spring's =
own
transaction management and iBATIS transaction management, this does not
necessarily affect the iBATIS support classes that we provide: Those clas=
ses
are specifically meant to integrate SQL Maps into Spring's resource and
transaction management, potentially sharing transactions with other data
access strategies within Spring (for example, plain JDBC or Hibernate).

As far as I understand, the SqlMapClient API already allows for simple
one-line operations when using its own resource and transaction managemen=
t.
So effectively, you don't need to use Spring's SqlMapClientTemplate in th=
at
scenario: Simply use the SqlMapClient instance directly. Of course, you c=
an
still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient in
the application context, passing it to your DAOs via bean references.

A disadvantage that I see with direct SqlMapClient usage is that you have=
 to
deal with checked SQLExceptions that your DAOs throw. However, that's als=
o
the case with your iBATIS transaction demarcation code, so that will be
consistent throughout the application. The alternative is to use Spring's
resource and transaction management: throwing unchecked DataAccessExcepti=
ons
from DAOs (like SqlMapClientTemplate does), and unchecked
TransactionExceptions from transaction demarcation code (like Spring's
PlatformTransactionManager interface and declarative demarcation faciliti=
es
do).

So in the end, there are two choices for using Spring in combination with
iBATIS SQL Maps: either Spring resource and transaction management (->
coding your DAOs with SqlMapClientTemplate), or iBATIS resource and
transaction management (-> coding your DAOs with SqlMapClient directly). =
I
don't see a need to rework SqlMapClientTemplate here: Simply use
SqlMapClient directly in your scenario; you can still leverage all of
Spring's IoC facilities.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



Also, after some exploration I have discovered that Spring requires that =
the
Datasource be set via the <property name=3D"dataSource"> on the SqlMapDao=
s.
This is not good. What happens when someone wants to allow iBatis to mana=
ge
transactions on it's own? I think that the datasource requirement needs t=
o
be removed. Setting the datasource via spring should be optional not
required.



Brandon Goodin

http://www.ibatis.com



________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections neede=
d



Greetings,



My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had
time recently I've become increasingly more familiar with the Spring prod=
uct
and began to explore the code base. I specifically have examined the iBat=
is
integration and noticed a problem in how the datasource is being set.



In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).



The short explanation is that Spring needs to set the the Datasource via =
the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig which
contains the datasource and various other pertinent config info for
transactions.



Following is a chunk from the XmlSqlMapClientBuilder that demonstrates ho=
w
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) Resources.instantiate(ty=
pe);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
cti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could n=
ot
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---



From what I can tell Spring allows for iBatis users to take advantage of =
the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is lef=
t
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)
for the configuration of the datasource. The ExternalTransactionConfig wi=
ll
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).



I'd be happy to work on the Spring code base if you would like or provide
you with more insight if you need. Let me know.



Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Ibatis integration corrections needed

[<jue...@we...>]

Actually, this seems to work great: Specify the DataSource once on =
SqlMapClientFactoryBean rather than on each DAO, and still set the =
UserConnection in SqlMapClientTemplate. The latter simply fetches the =
DataSource from the SqlMapClient in this case. As far as I understand =
that, this should allow for proper lazy loading...
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:46
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections =
needed



What about initializing the iBATIS TransactionManager in the way that =
you suggested, and *still* pass in transactional Connections via =
setUserConnection? That could give the best of both worlds: =
participating in all kinds of Spring-managed transactions, and allowing =
for lazy loading. It would also avoid the need to pass the DataSource to =
each and every SQL-Maps-based DAO; a single passing of the DataSource to =
the SqlMapClientFactoryBean would then be sufficient.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:24
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections =
needed



The problem is that we'd pass the DataSource to the iBATIS =
TransactionManager here, but not Spring-managed transactional =
Connections. SQL Maps would fetch its own Connections from the given =
DataSource, failing to participate in Spring-managed transactions (other =
than JTA).

I'm aware that lazy loading won't work with Spring's current iBATIS =
integration strategy. However, I'm not aware of any other disadvantages; =
can you give details in that respect?

I wouldn't mind letting SQL Maps create its own Connections from the =
DataSource for lazy loading, if told to do so. But we'd need to figure =
out a way to pass a transactional Connection in for the actual operation =
(like we do currently) and still allow for lazy loading via a given =
DataSource.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Brandon Goodin
Gesendet: Sa 29.05.2004 20:48
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections =
needed



The issue here of setting the datasource still remains. If you set the
connection via the setUserConnection it doesn't take full advantage of
ibatis. However, it is possible to allow for Spring to be the iBatis
TransactionManager. You simply need to set up an EXTERNAL =
TransactionConfig
to use in the TransactionManager. Please review my previous code. It =
shows
exactly how that is set. If you feel that iBatis may need to provide =
better
integrtion points for Spring to take advantage of... feel free to =
provide
suggestions.

Thanks,
Brandon Goodin
http://www.ibatis.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Hi again, Brandon,

While I agree that Spring allows iBATIS users to choose between Spring's =
own
transaction management and iBATIS transaction management, this does not
necessarily affect the iBATIS support classes that we provide: Those =
classes
are specifically meant to integrate SQL Maps into Spring's resource and
transaction management, potentially sharing transactions with other data
access strategies within Spring (for example, plain JDBC or Hibernate).

As far as I understand, the SqlMapClient API already allows for simple
one-line operations when using its own resource and transaction =
management.
So effectively, you don't need to use Spring's SqlMapClientTemplate in =
that
scenario: Simply use the SqlMapClient instance directly. Of course, you =
can
still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient =
in
the application context, passing it to your DAOs via bean references.

A disadvantage that I see with direct SqlMapClient usage is that you =
have to
deal with checked SQLExceptions that your DAOs throw. However, that's =
also
the case with your iBATIS transaction demarcation code, so that will be
consistent throughout the application. The alternative is to use =
Spring's
resource and transaction management: throwing unchecked =
DataAccessExceptions
from DAOs (like SqlMapClientTemplate does), and unchecked
TransactionExceptions from transaction demarcation code (like Spring's
PlatformTransactionManager interface and declarative demarcation =
facilities
do).

So in the end, there are two choices for using Spring in combination =
with
iBATIS SQL Maps: either Spring resource and transaction management (->
coding your DAOs with SqlMapClientTemplate), or iBATIS resource and
transaction management (-> coding your DAOs with SqlMapClient directly). =
I
don't see a need to rework SqlMapClientTemplate here: Simply use
SqlMapClient directly in your scenario; you can still leverage all of
Spring's IoC facilities.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



Also, after some exploration I have discovered that Spring requires that =
the
Datasource be set via the <property name=3D"dataSource"> on the =
SqlMapDaos.
This is not good. What happens when someone wants to allow iBatis to =
manage
transactions on it's own? I think that the datasource requirement needs =
to
be removed. Setting the datasource via spring should be optional not
required.



Brandon Goodin

http://www.ibatis.com



________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections =
needed



Greetings,



My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had
time recently I've become increasingly more familiar with the Spring =
product
and began to explore the code base. I specifically have examined the =
iBatis
integration and noticed a problem in how the datasource is being set.



In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).



The short explanation is that Spring needs to set the the Datasource via =
the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig =
which
contains the datasource and various other pertinent config info for
transactions.



Following is a chunk from the XmlSqlMapClientBuilder that demonstrates =
how
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) =
Resources.instantiate(type);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
cti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could =
not
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---



From what I can tell Spring allows for iBatis users to take advantage of =
the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is =
left
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)=

for the configuration of the datasource. The ExternalTransactionConfig =
will
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).



I'd be happy to work on the Spring code base if you would like or =
provide
you with more insight if you need. Let me know.



Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Ibatis integration corrections needed

[<jue...@we...>]

What about initializing the iBATIS TransactionManager in the way that =
you suggested, and *still* pass in transactional Connections via =
setUserConnection? That could give the best of both worlds: =
participating in all kinds of Spring-managed transactions, and allowing =
for lazy loading. It would also avoid the need to pass the DataSource to =
each and every SQL-Maps-based DAO; a single passing of the DataSource to =
the SqlMapClientFactoryBean would then be sufficient.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 29.05.2004 21:24
An: spr...@li...
Betreff: Re: [Springframework-developer] Ibatis integration corrections =
needed



The problem is that we'd pass the DataSource to the iBATIS =
TransactionManager here, but not Spring-managed transactional =
Connections. SQL Maps would fetch its own Connections from the given =
DataSource, failing to participate in Spring-managed transactions (other =
than JTA).

I'm aware that lazy loading won't work with Spring's current iBATIS =
integration strategy. However, I'm not aware of any other disadvantages; =
can you give details in that respect?

I wouldn't mind letting SQL Maps create its own Connections from the =
DataSource for lazy loading, if told to do so. But we'd need to figure =
out a way to pass a transactional Connection in for the actual operation =
(like we do currently) and still allow for lazy loading via a given =
DataSource.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Brandon Goodin
Gesendet: Sa 29.05.2004 20:48
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections =
needed



The issue here of setting the datasource still remains. If you set the
connection via the setUserConnection it doesn't take full advantage of
ibatis. However, it is possible to allow for Spring to be the iBatis
TransactionManager. You simply need to set up an EXTERNAL =
TransactionConfig
to use in the TransactionManager. Please review my previous code. It =
shows
exactly how that is set. If you feel that iBatis may need to provide =
better
integrtion points for Spring to take advantage of... feel free to =
provide
suggestions.

Thanks,
Brandon Goodin
http://www.ibatis.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Hi again, Brandon,

While I agree that Spring allows iBATIS users to choose between Spring's =
own
transaction management and iBATIS transaction management, this does not
necessarily affect the iBATIS support classes that we provide: Those =
classes
are specifically meant to integrate SQL Maps into Spring's resource and
transaction management, potentially sharing transactions with other data
access strategies within Spring (for example, plain JDBC or Hibernate).

As far as I understand, the SqlMapClient API already allows for simple
one-line operations when using its own resource and transaction =
management.
So effectively, you don't need to use Spring's SqlMapClientTemplate in =
that
scenario: Simply use the SqlMapClient instance directly. Of course, you =
can
still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient =
in
the application context, passing it to your DAOs via bean references.

A disadvantage that I see with direct SqlMapClient usage is that you =
have to
deal with checked SQLExceptions that your DAOs throw. However, that's =
also
the case with your iBATIS transaction demarcation code, so that will be
consistent throughout the application. The alternative is to use =
Spring's
resource and transaction management: throwing unchecked =
DataAccessExceptions
from DAOs (like SqlMapClientTemplate does), and unchecked
TransactionExceptions from transaction demarcation code (like Spring's
PlatformTransactionManager interface and declarative demarcation =
facilities
do).

So in the end, there are two choices for using Spring in combination =
with
iBATIS SQL Maps: either Spring resource and transaction management (->
coding your DAOs with SqlMapClientTemplate), or iBATIS resource and
transaction management (-> coding your DAOs with SqlMapClient directly). =
I
don't see a need to rework SqlMapClientTemplate here: Simply use
SqlMapClient directly in your scenario; you can still leverage all of
Spring's IoC facilities.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



Also, after some exploration I have discovered that Spring requires that =
the
Datasource be set via the <property name=3D"dataSource"> on the =
SqlMapDaos.
This is not good. What happens when someone wants to allow iBatis to =
manage
transactions on it's own? I think that the datasource requirement needs =
to
be removed. Setting the datasource via spring should be optional not
required.



Brandon Goodin

http://www.ibatis.com



________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections =
needed



Greetings,



My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had
time recently I've become increasingly more familiar with the Spring =
product
and began to explore the code base. I specifically have examined the =
iBatis
integration and noticed a problem in how the datasource is being set.



In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).



The short explanation is that Spring needs to set the the Datasource via =
the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig =
which
contains the datasource and various other pertinent config info for
transactions.



Following is a chunk from the XmlSqlMapClientBuilder that demonstrates =
how
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) =
Resources.instantiate(type);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
cti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could =
not
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---



From what I can tell Spring allows for iBatis users to take advantage of =
the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is =
left
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)=

for the configuration of the datasource. The ExternalTransactionConfig =
will
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).



I'd be happy to work on the Spring code base if you would like or =
provide
you with more insight if you need. Let me know.



Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Ibatis integration corrections needed

[Brandon G. <ma...@ph...>]

Thanks for the clarification of Spring's mode of operation. I need to loo=
k
at the iBatis code and see how we can accomodate.

Thanks
Brandon Goodin

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 1:25 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


The problem is that we'd pass the DataSource to the iBATIS
TransactionManager here, but not Spring-managed transactional Connections.
SQL Maps would fetch its own Connections from the given DataSource, faili=
ng
to participate in Spring-managed transactions (other than JTA).

I'm aware that lazy loading won't work with Spring's current iBATIS
integration strategy. However, I'm not aware of any other disadvantages; =
can
you give details in that respect?

I wouldn't mind letting SQL Maps create its own Connections from the
DataSource for lazy loading, if told to do so. But we'd need to figure ou=
t a
way to pass a transactional Connection in for the actual operation (like =
we
do currently) and still allow for lazy loading via a given DataSource.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Brandon Goodin
Gesendet: Sa 29.05.2004 20:48
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



The issue here of setting the datasource still remains. If you set the
connection via the setUserConnection it doesn't take full advantage of
ibatis. However, it is possible to allow for Spring to be the iBatis
TransactionManager. You simply need to set up an EXTERNAL TransactionConf=
ig
to use in the TransactionManager. Please review my previous code. It show=
s
exactly how that is set. If you feel that iBatis may need to provide bett=
er
integrtion points for Spring to take advantage of... feel free to provide
suggestions.

Thanks,
Brandon Goodin
http://www.ibatis.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Hi again, Brandon,

While I agree that Spring allows iBATIS users to choose between Spring's =
own
transaction management and iBATIS transaction management, this does not
necessarily affect the iBATIS support classes that we provide: Those clas=
ses
are specifically meant to integrate SQL Maps into Spring's resource and
transaction management, potentially sharing transactions with other data
access strategies within Spring (for example, plain JDBC or Hibernate).

As far as I understand, the SqlMapClient API already allows for simple
one-line operations when using its own resource and transaction managemen=
t.
So effectively, you don't need to use Spring's SqlMapClientTemplate in th=
at
scenario: Simply use the SqlMapClient instance directly. Of course, you c=
an
still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient in
the application context, passing it to your DAOs via bean references.

A disadvantage that I see with direct SqlMapClient usage is that you have=
 to
deal with checked SQLExceptions that your DAOs throw. However, that's als=
o
the case with your iBATIS transaction demarcation code, so that will be
consistent throughout the application. The alternative is to use Spring's
resource and transaction management: throwing unchecked DataAccessExcepti=
ons
from DAOs (like SqlMapClientTemplate does), and unchecked
TransactionExceptions from transaction demarcation code (like Spring's
PlatformTransactionManager interface and declarative demarcation faciliti=
es
do).

So in the end, there are two choices for using Spring in combination with
iBATIS SQL Maps: either Spring resource and transaction management (->
coding your DAOs with SqlMapClientTemplate), or iBATIS resource and
transaction management (-> coding your DAOs with SqlMapClient directly). =
I
don't see a need to rework SqlMapClientTemplate here: Simply use
SqlMapClient directly in your scenario; you can still leverage all of
Spring's IoC facilities.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



Also, after some exploration I have discovered that Spring requires that =
the
Datasource be set via the <property name=3D"dataSource"> on the SqlMapDao=
s.
This is not good. What happens when someone wants to allow iBatis to mana=
ge
transactions on it's own? I think that the datasource requirement needs t=
o
be removed. Setting the datasource via spring should be optional not
required.



Brandon Goodin

http://www.ibatis.com



________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections neede=
d



Greetings,



My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had
time recently I've become increasingly more familiar with the Spring prod=
uct
and began to explore the code base. I specifically have examined the iBat=
is
integration and noticed a problem in how the datasource is being set.



In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).



The short explanation is that Spring needs to set the the Datasource via =
the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig which
contains the datasource and various other pertinent config info for
transactions.



Following is a chunk from the XmlSqlMapClientBuilder that demonstrates ho=
w
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) Resources.instantiate(ty=
pe);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
cti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could n=
ot
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---



From what I can tell Spring allows for iBatis users to take advantage of =
the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is lef=
t
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)
for the configuration of the datasource. The ExternalTransactionConfig wi=
ll
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).



I'd be happy to work on the Spring code base if you would like or provide
you with more insight if you need. Let me know.



Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Ibatis integration corrections needed

[<jue...@we...>]

The problem is that we'd pass the DataSource to the iBATIS =
TransactionManager here, but not Spring-managed transactional =
Connections. SQL Maps would fetch its own Connections from the given =
DataSource, failing to participate in Spring-managed transactions (other =
than JTA).
=20
I'm aware that lazy loading won't work with Spring's current iBATIS =
integration strategy. However, I'm not aware of any other disadvantages; =
can you give details in that respect?
=20
I wouldn't mind letting SQL Maps create its own Connections from the =
DataSource for lazy loading, if told to do so. But we'd need to figure =
out a way to pass a transactional Connection in for the actual operation =
(like we do currently) and still allow for lazy loading via a given =
DataSource.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Brandon Goodin
Gesendet: Sa 29.05.2004 20:48
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections =
needed



The issue here of setting the datasource still remains. If you set the
connection via the setUserConnection it doesn't take full advantage of
ibatis. However, it is possible to allow for Spring to be the iBatis
TransactionManager. You simply need to set up an EXTERNAL =
TransactionConfig
to use in the TransactionManager. Please review my previous code. It =
shows
exactly how that is set. If you feel that iBatis may need to provide =
better
integrtion points for Spring to take advantage of... feel free to =
provide
suggestions.

Thanks,
Brandon Goodin
http://www.ibatis.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Hi again, Brandon,

While I agree that Spring allows iBATIS users to choose between Spring's =
own
transaction management and iBATIS transaction management, this does not
necessarily affect the iBATIS support classes that we provide: Those =
classes
are specifically meant to integrate SQL Maps into Spring's resource and
transaction management, potentially sharing transactions with other data
access strategies within Spring (for example, plain JDBC or Hibernate).

As far as I understand, the SqlMapClient API already allows for simple
one-line operations when using its own resource and transaction =
management.
So effectively, you don't need to use Spring's SqlMapClientTemplate in =
that
scenario: Simply use the SqlMapClient instance directly. Of course, you =
can
still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient =
in
the application context, passing it to your DAOs via bean references.

A disadvantage that I see with direct SqlMapClient usage is that you =
have to
deal with checked SQLExceptions that your DAOs throw. However, that's =
also
the case with your iBATIS transaction demarcation code, so that will be
consistent throughout the application. The alternative is to use =
Spring's
resource and transaction management: throwing unchecked =
DataAccessExceptions
from DAOs (like SqlMapClientTemplate does), and unchecked
TransactionExceptions from transaction demarcation code (like Spring's
PlatformTransactionManager interface and declarative demarcation =
facilities
do).

So in the end, there are two choices for using Spring in combination =
with
iBATIS SQL Maps: either Spring resource and transaction management (->
coding your DAOs with SqlMapClientTemplate), or iBATIS resource and
transaction management (-> coding your DAOs with SqlMapClient directly). =
I
don't see a need to rework SqlMapClientTemplate here: Simply use
SqlMapClient directly in your scenario; you can still leverage all of
Spring's IoC facilities.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



Also, after some exploration I have discovered that Spring requires that =
the
Datasource be set via the <property name=3D"dataSource"> on the =
SqlMapDaos.
This is not good. What happens when someone wants to allow iBatis to =
manage
transactions on it's own? I think that the datasource requirement needs =
to
be removed. Setting the datasource via spring should be optional not
required.



Brandon Goodin

http://www.ibatis.com



________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections =
needed



Greetings,



My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had
time recently I've become increasingly more familiar with the Spring =
product
and began to explore the code base. I specifically have examined the =
iBatis
integration and noticed a problem in how the datasource is being set.



In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).



The short explanation is that Spring needs to set the the Datasource via =
the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig =
which
contains the datasource and various other pertinent config info for
transactions.



Following is a chunk from the XmlSqlMapClientBuilder that demonstrates =
how
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) =
Resources.instantiate(type);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
cti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could =
not
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---



From what I can tell Spring allows for iBatis users to take advantage of =
the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is =
left
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)=

for the configuration of the datasource. The ExternalTransactionConfig =
will
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).



I'd be happy to work on the Spring code base if you would like or =
provide
you with more insight if you need. Let me know.



Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Ibatis integration corrections needed

[Brandon G. <ma...@ph...>]

The issue here of setting the datasource still remains. If you set the
connection via the setUserConnection it doesn't take full advantage of
ibatis. However, it is possible to allow for Spring to be the iBatis
TransactionManager. You simply need to set up an EXTERNAL TransactionConf=
ig
to use in the TransactionManager. Please review my previous code. It show=
s
exactly how that is set. If you feel that iBatis may need to provide bett=
er
integrtion points for Spring to take advantage of... feel free to provide
suggestions.

Thanks,
Brandon Goodin
http://www.ibatis.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Hi again, Brandon,

While I agree that Spring allows iBATIS users to choose between Spring's =
own
transaction management and iBATIS transaction management, this does not
necessarily affect the iBATIS support classes that we provide: Those clas=
ses
are specifically meant to integrate SQL Maps into Spring's resource and
transaction management, potentially sharing transactions with other data
access strategies within Spring (for example, plain JDBC or Hibernate).

As far as I understand, the SqlMapClient API already allows for simple
one-line operations when using its own resource and transaction managemen=
t.
So effectively, you don't need to use Spring's SqlMapClientTemplate in th=
at
scenario: Simply use the SqlMapClient instance directly. Of course, you c=
an
still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient in
the application context, passing it to your DAOs via bean references.

A disadvantage that I see with direct SqlMapClient usage is that you have=
 to
deal with checked SQLExceptions that your DAOs throw. However, that's als=
o
the case with your iBATIS transaction demarcation code, so that will be
consistent throughout the application. The alternative is to use Spring's
resource and transaction management: throwing unchecked DataAccessExcepti=
ons
from DAOs (like SqlMapClientTemplate does), and unchecked
TransactionExceptions from transaction demarcation code (like Spring's
PlatformTransactionManager interface and declarative demarcation faciliti=
es
do).

So in the end, there are two choices for using Spring in combination with
iBATIS SQL Maps: either Spring resource and transaction management (->
coding your DAOs with SqlMapClientTemplate), or iBATIS resource and
transaction management (-> coding your DAOs with SqlMapClient directly). =
I
don't see a need to rework SqlMapClientTemplate here: Simply use
SqlMapClient directly in your scenario; you can still leverage all of
Spring's IoC facilities.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



Also, after some exploration I have discovered that Spring requires that =
the
Datasource be set via the <property name=3D"dataSource"> on the SqlMapDao=
s.
This is not good. What happens when someone wants to allow iBatis to mana=
ge
transactions on it's own? I think that the datasource requirement needs t=
o
be removed. Setting the datasource via spring should be optional not
required.



Brandon Goodin

http://www.ibatis.com



________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections neede=
d



Greetings,



My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had
time recently I've become increasingly more familiar with the Spring prod=
uct
and began to explore the code base. I specifically have examined the iBat=
is
integration and noticed a problem in how the datasource is being set.



In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).



The short explanation is that Spring needs to set the the Datasource via =
the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig which
contains the datasource and various other pertinent config info for
transactions.



Following is a chunk from the XmlSqlMapClientBuilder that demonstrates ho=
w
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) Resources.instantiate(ty=
pe);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
cti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could n=
ot
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---



From what I can tell Spring allows for iBatis users to take advantage of =
the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is lef=
t
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)
for the configuration of the datasource. The ExternalTransactionConfig wi=
ll
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).



I'd be happy to work on the Spring code base if you would like or provide
you with more insight if you need. Let me know.



Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Ibatis integration corrections needed

[Brandon G. <br...@za...>]

The issue here of setting the datasource still remains. If you set the
connection via the setUserConnection it doesn't take full advantage of
ibatis. However, it is possible to allow for Spring to be the iBatis
TransactionManager. You simply need to set up an EXTERNAL TransactionConf=
ig
to use in the TransactionManager. Please review my previous code. It show=
s
exactly how that is set. If you feel that iBatis may need to provide bett=
er
integrtion points for Spring to take advantage of... feel free to provide
suggestions.

Thanks,
Brandon Goodin
http://www.ibatis.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Saturday, May 29, 2004 11:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Ibatis integration corrections
needed


Hi again, Brandon,

While I agree that Spring allows iBATIS users to choose between Spring's =
own
transaction management and iBATIS transaction management, this does not
necessarily affect the iBATIS support classes that we provide: Those clas=
ses
are specifically meant to integrate SQL Maps into Spring's resource and
transaction management, potentially sharing transactions with other data
access strategies within Spring (for example, plain JDBC or Hibernate).

As far as I understand, the SqlMapClient API already allows for simple
one-line operations when using its own resource and transaction managemen=
t.
So effectively, you don't need to use Spring's SqlMapClientTemplate in th=
at
scenario: Simply use the SqlMapClient instance directly. Of course, you c=
an
still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient in
the application context, passing it to your DAOs via bean references.

A disadvantage that I see with direct SqlMapClient usage is that you have=
 to
deal with checked SQLExceptions that your DAOs throw. However, that's als=
o
the case with your iBATIS transaction demarcation code, so that will be
consistent throughout the application. The alternative is to use Spring's
resource and transaction management: throwing unchecked DataAccessExcepti=
ons
from DAOs (like SqlMapClientTemplate does), and unchecked
TransactionExceptions from transaction demarcation code (like Spring's
PlatformTransactionManager interface and declarative demarcation faciliti=
es
do).

So in the end, there are two choices for using Spring in combination with
iBATIS SQL Maps: either Spring resource and transaction management (->
coding your DAOs with SqlMapClientTemplate), or iBATIS resource and
transaction management (-> coding your DAOs with SqlMapClient directly). =
I
don't see a need to rework SqlMapClientTemplate here: Simply use
SqlMapClient directly in your scenario; you can still leverage all of
Spring's IoC facilities.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections
needed



Also, after some exploration I have discovered that Spring requires that =
the
Datasource be set via the <property name=3D"dataSource"> on the SqlMapDao=
s.
This is not good. What happens when someone wants to allow iBatis to mana=
ge
transactions on it's own? I think that the datasource requirement needs t=
o
be removed. Setting the datasource via spring should be optional not
required.



Brandon Goodin

http://www.ibatis.com



________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections neede=
d



Greetings,



My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had
time recently I've become increasingly more familiar with the Spring prod=
uct
and began to explore the code base. I specifically have examined the iBat=
is
integration and noticed a problem in how the datasource is being set.



In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).



The short explanation is that Spring needs to set the the Datasource via =
the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig which
contains the datasource and various other pertinent config info for
transactions.



Following is a chunk from the XmlSqlMapClientBuilder that demonstrates ho=
w
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) Resources.instantiate(ty=
pe);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
cti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could n=
ot
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---



From what I can tell Spring allows for iBatis users to take advantage of =
the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is lef=
t
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)
for the configuration of the datasource. The ExternalTransactionConfig wi=
ll
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).



I'd be happy to work on the Spring code base if you would like or provide
you with more insight if you need. Let me know.



Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Cleanup of context resources on webapp reload

[<jue...@we...>]

Guillaume,
=20
I've prototypically added an Introspector.flushCaches call to context =
shutdown: I don't see any difference in the profiler. That's not too =
surprising, as the originally leaking classes are not managed by beans =
facilities in the first place: for example, SQLErrorCodesFactory, which =
is just used internally by SQLErrorCodeSQLExceptionTranslator.
=20
Of course, since my changes from a week ago, those classes don't leak =
anymore, as they hold their singleton instance in a WeakReference now... =
I still don't understand why this is necessary, but I'm 100% sure that =
it does make a difference on both Sun JDK 1.4.2 and Sun JDK 1.3.1. I've =
also tried various GC configuration options - always the same effect.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Guillaume Poirier
Gesendet: Sa 29.05.2004 06:12
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on =
webapp reload



I experimented some more about this cleanup issue, and I was able to =
narrow
down the problem to the caching done by the java.beans.Introspector.  It
stores the BeanInfo instances in a WeakHashMap, but in that Map
implementation, only the keys uses WeakReference, the values are stored =
with
hard references since BeanInfo has an hard reference on the class it =
gives
info about (indirectly through BeanDescriptor and others), any time
Introspector.getBeanInfo(Class) is used, that class and it's static =
members
will not ever be able to be garbage collected.  I kind of remember =
someone
mentioning something related to this in the mailling list, but I cannot =
find
the mail.  I wonder if there's other case where the java[x] classes =
might
have an hard reference on a class or its instances.  A fix for this
particular problem is to have a ServletContextListener call
Introspector.flushCaches() when the context is destroyed.

It seems like a known issue at Sun :

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4291376
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4730581
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4809008

So, unless I'm missing something here, that means fixes like using
synchronization and WeakReference on singleton probably won't help much =
if
at all.  The only way that I can see for a class not to be gargage =
collected
when no more active thread use it, is if another ClassLoader has an hard
reference to the class instance, or an instance of that class.  Having =
the
class itself have an hard reference on a its own singleton has no =
effect,
it's a circular reference that will not prevent the class or the =
instance to
be gargabe collected when neither is being refered to by something else.

Guillaume




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Ibatis integration corrections needed

[<jue...@we...>]

Hi again, Brandon,
=20
While I agree that Spring allows iBATIS users to choose between Spring's =
own transaction management and iBATIS transaction management, this does =
not necessarily affect the iBATIS support classes that we provide: Those =
classes are specifically meant to integrate SQL Maps into Spring's =
resource and transaction management, potentially sharing transactions =
with other data access strategies within Spring (for example, plain JDBC =
or Hibernate).
=20
As far as I understand, the SqlMapClient API already allows for simple =
one-line operations when using its own resource and transaction =
management. So effectively, you don't need to use Spring's =
SqlMapClientTemplate in that scenario: Simply use the SqlMapClient =
instance directly. Of course, you can still use Spring's =
SqlMapClientFactoryBean to set up your SqlMapClient in the application =
context, passing it to your DAOs via bean references.
=20
A disadvantage that I see with direct SqlMapClient usage is that you =
have to deal with checked SQLExceptions that your DAOs throw. However, =
that's also the case with your iBATIS transaction demarcation code, so =
that will be consistent throughout the application. The alternative is =
to use Spring's resource and transaction management: throwing unchecked =
DataAccessExceptions from DAOs (like SqlMapClientTemplate does), and =
unchecked TransactionExceptions from transaction demarcation code (like =
Spring's PlatformTransactionManager interface and declarative =
demarcation facilities do).
=20
So in the end, there are two choices for using Spring in combination =
with iBATIS SQL Maps: either Spring resource and transaction management =
(-> coding your DAOs with SqlMapClientTemplate), or iBATIS resource and =
transaction management (-> coding your DAOs with SqlMapClient directly). =
I don't see a need to rework SqlMapClientTemplate here: Simply use =
SqlMapClient directly in your scenario; you can still leverage all of =
Spring's IoC facilities.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Brandon Goodin
Gesendet: Sa 29.05.2004 07:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Ibatis integration corrections =
needed



Also, after some exploration I have discovered that Spring requires that =
the Datasource be set via the <property name=3D"dataSource"> on the =
SqlMapDaos. This is not good. What happens when someone wants to allow =
iBatis to manage transactions on it's own? I think that the datasource =
requirement needs to be removed. Setting the datasource via spring =
should be optional not required.

=20

Brandon Goodin

http://www.ibatis.com

=20

________________________________

From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections =
needed

=20

Greetings,

=20

My name is Brandon Goodin. I am committer on the iBatis project. As I've =
had time recently I've become increasingly more familiar with the Spring =
product and began to explore the code base. I specifically have examined =
the iBatis integration and noticed a problem in how the datasource is =
being set.

=20

In the  SqlMapClientTemplate the execute method is using =
session.setUserConnection(con);. Setting the connection using =
setUserConnection on the SqlMapSession will not take full advantage of =
ibatis functionality (i.e. lazy loading will not work).

=20

The short explanation is that Spring needs to set the the Datasource via =
the TransactionConfig which is stored in the TransactionManager. The =
TransactionManager needs to be set via the SqlMapExecutorDelegate of the =
SqlMapClient. The TransactionManager contains the TransactionConfig =
which contains the datasource and various other pertinent config info =
for transactions.

=20

Following is a chunk from the XmlSqlMapClientBuilder that demonstrates =
how the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager =3D null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config =3D (TransactionConfig) =
Resources.instantiate(type);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa=
ctions());
errorCtx.setMoreInfo("Check the transactio nmanager properties or =
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager =3D new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could =
not instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---

=20

From what I can tell Spring allows for iBatis users to take advantage of =
the iBatis transaction facilities if they choose (i.e. avoid using =
spring transaction management if they so choose). So, the only thing =
that is left is for Spring to use the proper implementation of the =
TransactionConfig =
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)=
 for the configuration of the datasource. The ExternalTransactionConfig =
will allow for Spring to manage the commit and rollback functionality =
without losing valuable functionality in iBatis (lazy loading).

=20

I'd be happy to work on the Spring code base if you would like or =
provide you with more insight if you need. Let me know.

=20

Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/>=20

=20

RE: [Springframework-developer] Ibatis integration corrections needed

[Brandon G. <ma...@ph...>]

I know I should be adding these to a bug report. But, I figured that I could
do it all in one bug report once the more complex issue of transaction
management is resolved.

 

I have found another issue that needs to be remedied.

 

Line 54 of SqlMapClientOpertaions:

 

List queryForList(String statementName, Object parameterObject, RowHandler
rowHandler)

                  throws DataAccessException;

 

should be..

 

void queryWithRowhandler(String statementName, Object parameterObject,
RowHandler rowHandler)

                  throws DataAccessException;

 

 

Line 185-192 of SqlMapClientTemplate needs to be changed in a similar
manner:

 

public List queryForList(final String statementName, final Object
parameterObject,

final RowHandler rowHandler) throws DataAccessException {

      return executeWithListResult(new SqlMapClientCallback() {

            public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {

                  return executor.queryForList(statementName,
parameterObject, rowHandler);

            }

      });

}

 

Should be:

 

I am assuming you do not want to implement another method on your
SqlMapClientCallback just to accommodate the queryWithRowHandler. So, I
simply pass back a null from the doInSqlMapClient of the
SqlMapClientCallback implementation and ignore it.

 

public void queryWithRowHandler(final String statementName, final Object
parameterObject,

final RowHandler rowHandler) throws DataAccessException {

            executeWithRowHandler(new SqlMapClientCallback() {

            public Object doInSqlMapClient(SqlMapExecutor executor) throws
SQLException {

                  executor.queryWithRowHandler(statementName,
parameterObject, rowHandler);

                  return null;

            }

      });

}

 

Also, the following should be added to the SqlMapClientTemplate

/**

 * Execute the given data access action on a SqlMapSession 

 * with a RowHandler.

 * @param action callback object that specifies the data access action

 * @return the List result

 * @throws DataAccessException in case of SQL Maps errors

 */

public void executeWithRowHandler(SqlMapClientCallback action) throws
DataAccessException {

      execute(action);

}

 

 

Apart from all of this I am rather curious about the purpose the
SqlMapClientCallback? I read the javadoc and am wondering what role it plays
in the process of Spring integration with iBatis. Could you provide me with
a explanation of it's role?

 

Thanks,

Brandon Goodin

http://www.ibatis.com

 

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Brandon Goodin
Sent: Friday, May 28, 2004 10:42 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Ibatis integration corrections
needed

 

Also, after some exploration I have discovered that Spring requires that the
Datasource be set via the <property name="dataSource"> on the SqlMapDaos.
This is not good. What happens when someone wants to allow iBatis to manage
transactions on it's own? I think that the datasource requirement needs to
be removed. Setting the datasource via spring should be optional not
required.

 

Brandon Goodin

http://www.ibatis.com

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections needed

 

Greetings,

 

My name is Brandon Goodin. I am committer on the iBatis project. As I've had
time recently I've become increasingly more familiar with the Spring product
and began to explore the code base. I specifically have examined the iBatis
integration and noticed a problem in how the datasource is being set.

 

In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).

 

The short explanation is that Spring needs to set the the Datasource via the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig which
contains the datasource and various other pertinent config info for
transactions.

 

Following is a chunk from the XmlSqlMapClientBuilder that demonstrates how
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager = null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config = (TransactionConfig) Resources.instantiate(type);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransacti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager = new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could not
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---

 

From what I can tell Spring allows for iBatis users to take advantage of the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is left
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)
for the configuration of the datasource. The ExternalTransactionConfig will
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).

 

I'd be happy to work on the Spring code base if you would like or provide
you with more insight if you need. Let me know.

 

Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/> 

 

RE: [Springframework-developer] Ibatis integration corrections needed

[Brandon G. <ma...@ph...>]

Also, after some exploration I have discovered that Spring requires that the
Datasource be set via the <property name="dataSource"> on the SqlMapDaos.
This is not good. What happens when someone wants to allow iBatis to manage
transactions on it's own? I think that the datasource requirement needs to
be removed. Setting the datasource via spring should be optional not
required.

 

Brandon Goodin

http://www.ibatis.com

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Brandon Goodin
Sent: Friday, May 28, 2004 6:57 PM
To: spr...@li...
Subject: [Springframework-developer] Ibatis integration corrections needed

 

Greetings,

 

My name is Brandon Goodin. I am committer on the iBatis project. As I've had
time recently I've become increasingly more familiar with the Spring product
and began to explore the code base. I specifically have examined the iBatis
integration and noticed a problem in how the datasource is being set.

 

In the  SqlMapClientTemplate the execute method is using
session.setUserConnection(con);. Setting the connection using
setUserConnection on the SqlMapSession will not take full advantage of
ibatis functionality (i.e. lazy loading will not work).

 

The short explanation is that Spring needs to set the the Datasource via the
TransactionConfig which is stored in the TransactionManager. The
TransactionManager needs to be set via the SqlMapExecutorDelegate of the
SqlMapClient. The TransactionManager contains the TransactionConfig which
contains the datasource and various other pertinent config info for
transactions.

 

Following is a chunk from the XmlSqlMapClientBuilder that demonstrates how
the datasource should be configured in ibatis:


---- start code ---
TransactionManager txManager = null;
try {
errorCtx.setMoreInfo("Check the transaction manager type or class.");
TransactionConfig config = (TransactionConfig) Resources.instantiate(type);
config.setDataSource(dataSource);
config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransacti
ons());
errorCtx.setMoreInfo("Check the transactio nmanager properties or
configuration.");
config.initialize(initProperties);
errorCtx.setMoreInfo(null);
txManager = new TransactionManager(config);
} catch (Exception e) {
if (e instanceof SqlMapException) {
throw (SqlMapException) e;
} else {
throw new SqlMapException("Error initializing TransactionManager. Could not
instantiate TransactionConfig. Cause: " + e, e);
}
}

client.getDelegate().setTxManager(txManager);

--- end code ---

 

From what I can tell Spring allows for iBatis users to take advantage of the
iBatis transaction facilities if they choose (i.e. avoid using spring
transaction management if they so choose). So, the only thing that is left
is for Spring to use the proper implementation of the TransactionConfig
(com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)
for the configuration of the datasource. The ExternalTransactionConfig will
allow for Spring to manage the commit and rollback functionality without
losing valuable functionality in iBatis (lazy loading).

 

I'd be happy to work on the Spring code base if you would like or provide
you with more insight if you need. Let me know.

 

Thanks,

Brandon Goodin

http://www.ibatis.com <http://www.ibatis.com/> 

 

RE: [Springframework-developer] Spring / Mule integration - step 1

[Keith D. <kd...@cs...>]

Ben,

If you would, let me know when you begin your journey developing a Swing GUI
built on top of Spring.  As the developer for Spring's in-development rich
client support (which is built directly on Swing), I'd love to be able to
combine what we've done so far and our future plans with your expertise and
the ideas you have in mind.  I could really use a sharp mind like yours to
critique and help further evolve the code base!

Right now there is already a substantial amount of functionality in our
project that should considerably jumpstart any swing application development
effort.  The codebase is actively (daily) progressing and will continue to
do so over the coming weeks/months as we work towards release candidate
form.  The mailing list is also starting to get some traffic; and I will be
checking in our first set of real samples later this weekend.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Ben Alex
Sent: Friday, May 28, 2004 7:02 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Spring / Mule integration - step 1

> I am in the thick of things at work so can't really put 
> enough thought into this to comment much, but I would prefer 
> to hold this until after
> 1.0.3 is out...

I just wanted to chime in here and mention what Ross is working towards is
strategically very useful for Spring users.

By simply adding Mule (which BTW is now configurable directly from a Spring
ApplicationContext) Spring users will have the ability to receive events
from external sources (JMS, DB, HTTP etc), then transform them into native
ApplicationEvents and publish them in the ApplicationContext, and then send
ApplicationEvent replies to the ApplicationContext and have Mule send them
off to external sources. So Mule acts as an adapter between
ApplicationEvents and the external world. Mule can also be used directly to
take advantage of the growing library of Mule objects that perform message
transformation etc.

I recently added some ApplicationEvent support to Acegi Security CVS (login
success/password fail events), and am about to embark on a Swing GUI built
on top of Spring where it will be used again. It's nice for these sort of
internal-to-the-ApplicationContext usages, but if I want to publish a
CustomerOrder to a remote CustomerOrderConsumer, it will be nice when Mule
can deliver it for me.

Best regards
Ben



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Cleanup of context resources on webapp reload

[Guillaume P. <gpo...@gl...>]

I experimented some more about this cleanup issue, and I was able to narrow
down the problem to the caching done by the java.beans.Introspector.  It
stores the BeanInfo instances in a WeakHashMap, but in that Map
implementation, only the keys uses WeakReference, the values are stored with
hard references since BeanInfo has an hard reference on the class it gives
info about (indirectly through BeanDescriptor and others), any time
Introspector.getBeanInfo(Class) is used, that class and it's static members
will not ever be able to be garbage collected.  I kind of remember someone
mentioning something related to this in the mailling list, but I cannot find
the mail.  I wonder if there's other case where the java[x] classes might
have an hard reference on a class or its instances.  A fix for this
particular problem is to have a ServletContextListener call
Introspector.flushCaches() when the context is destroyed.

It seems like a known issue at Sun :

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4291376
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4730581
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809008

So, unless I'm missing something here, that means fixes like using
synchronization and WeakReference on singleton probably won't help much if
at all.  The only way that I can see for a class not to be gargage collected
when no more active thread use it, is if another ClassLoader has an hard
reference to the class instance, or an instance of that class.  Having the
class itself have an hard reference on a its own singleton has no effect,
it's a circular reference that will not prevent the class or the instance to
be gargabe collected when neither is being refered to by something else.

Guillaume

RE: [Springframework-developer] Spring / Mule integration - step 1

[Mason, R. <ros...@vi...>]

TmljZWx5IHB1dCBCZW4gOi0pIA0KIA0KU3RyYXRlZ2ljYWxseSwgSSB0aGluayBTcHJpbmcgYW5k
IE11bGUgYXJlIGEgcG93ZXJmdWwgY29tYmluYXRpb24uICBGcm9tIGFuICdhcHBsaWNhdGlvbiB3
aXJpbmcnIHBlcnNwZWN0aXZlIFNwcmluZyBjYW4gYmUgc2VlbiBhcyBhIGZyYW1ld29yayBmb3Ig
d2lyaW5nIGJlYW5zIHdpdGhpbiBhIEpWTSBhbmQgTXVsZSBjYW4gYmUgc2VlbiBhcyBhIHdheSBv
ZiB3aXJpbmcgYmVhbnMvYXBwbGljYXRpb24gbm9kZXMgb3ZlciB0aGUgbmV0d29yay4gTXVsZSBw
cm92aWRlcyBhIHZlcnNhdGlsZSBnYXRld2F5IGZvciBTcHJpbmcgYmVhbnMgdG8gZXh0ZXJuYWwg
YXBwbGljYXRpb25zIGFuZCBoYW5kbGVzIHRoZSBjb21wbGV4aXRpZXMgb2YgY29ubmVjdGlvbnMs
IHRyYW5zZm9ybWF0aW9ucyBhbmQgcm91dGluZyB0cmFuc3BhcmVudGx5LiBQbHVzIHRoZXJlIGlz
IHZlcnkgbGl0dGxlIG92ZXJsYXAgaW4gZnVuY3Rpb25hbGl0eSBiZXR3ZWVuIHRoZSB0d28gZnJh
bWV3b3Jrcy4gDQogDQpDaGVlcnMsDQogDQpSb3NzDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLSANCglGcm9tOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNv
dXJjZWZvcmdlLm5ldCBvbiBiZWhhbGYgb2YgQmVuIEFsZXggDQoJU2VudDogU2F0IDI5LzA1LzIw
MDQgMTI6MDIgQU0gDQoJVG86IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNl
Zm9yZ2UubmV0IA0KCUNjOiANCglTdWJqZWN0OiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9w
ZXJdIFNwcmluZyAvIE11bGUgaW50ZWdyYXRpb24gLSBzdGVwIDENCgkNCgkNCg0KCT4gSSBhbSBp
biB0aGUgdGhpY2sgb2YgdGhpbmdzIGF0IHdvcmsgc28gY2FuJ3QgcmVhbGx5IHB1dA0KCT4gZW5v
dWdoIHRob3VnaHQgaW50byB0aGlzIHRvIGNvbW1lbnQgbXVjaCwgYnV0IEkgd291bGQgcHJlZmVy
DQoJPiB0byBob2xkIHRoaXMgdW50aWwgYWZ0ZXINCgk+IDEuMC4zIGlzIG91dC4uLg0KCQ0KCUkg
anVzdCB3YW50ZWQgdG8gY2hpbWUgaW4gaGVyZSBhbmQgbWVudGlvbiB3aGF0IFJvc3MgaXMgd29y
a2luZyB0b3dhcmRzIGlzDQoJc3RyYXRlZ2ljYWxseSB2ZXJ5IHVzZWZ1bCBmb3IgU3ByaW5nIHVz
ZXJzLg0KCQ0KCUJ5IHNpbXBseSBhZGRpbmcgTXVsZSAod2hpY2ggQlRXIGlzIG5vdyBjb25maWd1
cmFibGUgZGlyZWN0bHkgZnJvbSBhIFNwcmluZw0KCUFwcGxpY2F0aW9uQ29udGV4dCkgU3ByaW5n
IHVzZXJzIHdpbGwgaGF2ZSB0aGUgYWJpbGl0eSB0byByZWNlaXZlIGV2ZW50cw0KCWZyb20gZXh0
ZXJuYWwgc291cmNlcyAoSk1TLCBEQiwgSFRUUCBldGMpLCB0aGVuIHRyYW5zZm9ybSB0aGVtIGlu
dG8gbmF0aXZlDQoJQXBwbGljYXRpb25FdmVudHMgYW5kIHB1Ymxpc2ggdGhlbSBpbiB0aGUgQXBw
bGljYXRpb25Db250ZXh0LCBhbmQgdGhlbiBzZW5kDQoJQXBwbGljYXRpb25FdmVudCByZXBsaWVz
IHRvIHRoZSBBcHBsaWNhdGlvbkNvbnRleHQgYW5kIGhhdmUgTXVsZSBzZW5kIHRoZW0NCglvZmYg
dG8gZXh0ZXJuYWwgc291cmNlcy4gU28gTXVsZSBhY3RzIGFzIGFuIGFkYXB0ZXIgYmV0d2Vlbg0K
CUFwcGxpY2F0aW9uRXZlbnRzIGFuZCB0aGUgZXh0ZXJuYWwgd29ybGQuIE11bGUgY2FuIGFsc28g
YmUgdXNlZCBkaXJlY3RseSB0bw0KCXRha2UgYWR2YW50YWdlIG9mIHRoZSBncm93aW5nIGxpYnJh
cnkgb2YgTXVsZSBvYmplY3RzIHRoYXQgcGVyZm9ybSBtZXNzYWdlDQoJdHJhbnNmb3JtYXRpb24g
ZXRjLg0KCQ0KCUkgcmVjZW50bHkgYWRkZWQgc29tZSBBcHBsaWNhdGlvbkV2ZW50IHN1cHBvcnQg
dG8gQWNlZ2kgU2VjdXJpdHkgQ1ZTIChsb2dpbg0KCXN1Y2Nlc3MvcGFzc3dvcmQgZmFpbCBldmVu
dHMpLCBhbmQgYW0gYWJvdXQgdG8gZW1iYXJrIG9uIGEgU3dpbmcgR1VJIGJ1aWx0DQoJb24gdG9w
IG9mIFNwcmluZyB3aGVyZSBpdCB3aWxsIGJlIHVzZWQgYWdhaW4uIEl0J3MgbmljZSBmb3IgdGhl
c2Ugc29ydCBvZg0KCWludGVybmFsLXRvLXRoZS1BcHBsaWNhdGlvbkNvbnRleHQgdXNhZ2VzLCBi
dXQgaWYgSSB3YW50IHRvIHB1Ymxpc2ggYQ0KCUN1c3RvbWVyT3JkZXIgdG8gYSByZW1vdGUgQ3Vz
dG9tZXJPcmRlckNvbnN1bWVyLCBpdCB3aWxsIGJlIG5pY2Ugd2hlbiBNdWxlDQoJY2FuIGRlbGl2
ZXIgaXQgZm9yIG1lLg0KCQ0KCUJlc3QgcmVnYXJkcw0KCUJlbg0KCQ0KCQ0KCQ0KCS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIFNG
Lk5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IE9yYWNsZSAxMGcNCglHZXQgY2VydGlmaWVkIG9u
IHRoZSBob3R0ZXN0IHRoaW5nIGV2ZXIgdG8gaGl0IHRoZSBtYXJrZXQuLi4gT3JhY2xlIDEwZy4N
CglUYWtlIGFuIE9yYWNsZSAxMGcgY2xhc3Mgbm93LCBhbmQgd2UnbGwgZ2l2ZSB5b3UgdGhlIGV4
YW0gRlJFRS4NCglodHRwOi8vYWRzLm9zZG4uY29tLz9hZF9pZD0zMTQ5JmFsbG9jX2lkPTgxNjYm
b3A9Y2xpY2sNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3
b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJj
ZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoN
Cg==

RE: [Springframework-developer] Spring / Mule integration - step 1

[Mason, R. <ros...@vi...>]

SGksDQoNCiBJIGNhbid0IGhlbHAgYmUgZmVlbCB0aGUgQXBwbGljYXRpb25FdmVudE11bHRpY2Fz
dGVyIGlzIG9uZSBvYmplY3Qgd2l0aCB0d28gcm9sZXMgdGhhdCBtaWdodCBiZSBiZXN0IGltcGxl
bWVudGF0ZWQgYXMgdHdvIG9iamVjdHMuIE1heWJlIHRoZSB0aGUgRXZlbnRNdWx0aWNhc3RlciBv
biB0aGUgQWJzdHJhY3RBcHBsaWNhdGlvbkNvbnRleHQgc2hvdWxkIHJlYWxseSBiZSBhICdTaW1w
bGVFdmVudE1hbmFnZXInIGltcGxlbWVudGluZyAnU3ByaW5nRXZlbnRNYW5hZ2VyJyBhbmQgdGhl
IHRoZSBBcHBsaWNhdGlvbkV2ZW50TXVsdGljYXN0ZXIgaXMganVzdCBhbm90aGVyIHR5cGUgb2Yg
bGlzdGVuZXIgdGhhdCBkaXNwYXRjaGVzIHRvIG90aGVyIGxpc3RlbmVycy4gICBNdWxlIGNvdWxk
IGltcGxlbWxlbWVudCBpdCdzIG93biBTcHJpbmdFdmVudE1hbmFnZXIsIHNheSBNdWxlRXZlbnRN
YW5hZ2VyLCB0aGF0IGNvdWxkIGJlIG9idGFpbmVkIGZyb20gdGhlIGNvbnRleHQuICBBcyBTcHJp
bmdFdmVudE1hbmFnZXIgZG9lc24ndCBpbXBsZW1lbnQgQXBwbGljYXRpb25FdmVudExpc3RlbmVy
IHRoZXJlIHdvdWxkIGJlIG5vIG5lZWQgbmVlZCB0byBtYWtlIHNwZWNpYWwgY2hlY2tzIHRvIG1h
a2Ugc3VyZSB0aGUgTXVsZUV2ZW50TWFuYWdlciBpc24ndCByZWdpc3RlcmVkIGFzIGEgbGlzdGVu
ZXIgdG8gaXRzZWxmLg0KDQpPYnZpb3VzbHksIEkgd291bGQgbGlrZSB0byBzZWUgdGhpcyBpbiB0
aGUgbmV4dCByZWxlYXNlIDotKSBidXQgSSB0b3RhbGx5IHVuZGVyc3RhbmQgQ29saW4ncyBjb25j
ZXJucy4gIEkgdGhpbmsgdGhpcyBhcHByb2FjaCBpcyBwcmV0dHkgc29saWQgYW5kIGJhY2t3YXJk
IGNvbXBhdGlibGUgZm9yIHVzZXJzIHdobyBhcmUgdXNpbmcgdGhlIGV4aXN0aW5nIEFwcGxpY2F0
aW9uRXZlbnRNdWx0aWNhc3Rlci4NCg0KQ2hlZXJzLA0KDQpSb3NzDQoNCiANCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0gDQpGcm9tOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFkbWlu
QGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBvbiBiZWhhbGYgb2YgasO8cmdlbiBow7ZsbGVyIFt3ZXJr
M0FUXSANClNlbnQ6IEZyaSAyOC8wNS8yMDA0IDIxOjMxIA0KVG86IHNwcmluZ2ZyYW1ld29yay1k
ZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KQ2M6IA0KU3ViamVjdDogUmU6IFtTcHJp
bmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBTcHJpbmcgLyBNdWxlIGludGVncmF0aW9uIC0gc3RlcCAx
DQoNCg0KT0ssIGxldCdzIG9wZW4gdXAgdGhlIEFwcGxpY2F0aW9uRXZlbnRNdWx0aWNhc3Rlciwg
d2hpY2ggaXMgY3VycmVudGx5IG1vcmUgb3IgbGVzcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwg
b2YgQWJzdHJhY3RBcHBsaWNhdGlvbkNvbnRleHQuIEZpcnN0IHRoaW5nIEkndmUganVzdCBkb25l
IGlzIHJlbmFtZWQgQXBwbGljYXRpb25FdmVudE11bHRpY2FzdGVySW1wbCB0byBTaW1wbGVBcHBs
aWNhdGlvbkV2ZW50TXVsdGljYXN0ZXIsIHRvIHJlZmxlY3QgdGhlIHBvc3NpYmlsaXR5IGZvciBv
dGhlciBpbXBsZW1lbnRhdGlvbnMuDQoNClRoZSBjZW50cmFsIHF1ZXN0aW9uIGlzOiBIb3cgdG8g
c3BlY2lmeSB0aGUgQXBwbGljYXRpb25FdmVudE11bHRpY2FzdGVyIGltcGxlbWVudGF0aW9uIHRo
YXQgYSBjb250ZXh0IHNob3VsZCB1c2U/IEEgdHlwaWNhbCBTcHJpbmcgd2F5IHdvdWxkIGJlIGEg
c3BlY2lhbCBiZWFuIGluIHRoZSBjb250ZXh0LCBzaW1pbGFyIHRvIHRoZSBNZXNzYWdlU291cmNl
IChhbmQgRGlzcGF0Y2hlclNlcnZsZXQncyBzcGVjaWFsIGJlYW5zKTogQSBsb2dpY2FsIGJlYW4g
bmFtZSB3b3VsZCBiZSAiYXBwbGljYXRpb25FdmVudE11bHRpY2FzdGVyIi4NCg0KU291bmRzIGxp
a2UgdGhlIGxvZ2ljYWwgc3ByaW5nIHdheSB0byBnbyA6LSkNCg0KU28gZmFyLCBzbyBnb29kLCBz
byBwcm90b3R5cGljYWxseSBpbXBsZW1lbnRlZCA6LSkgV29ya3MgbmljZWx5LCBhbmQgaXMgYWN0
dWFsbHkganVzdCBhIG1pbm9yIGNoYW5nZSB0aGF0IGRvZXMgbm90IGFmZmVjdCB0aGUgcmVzdCBv
ZiB0aGUgZnJhbWV3b3JrLCBiZXNpZGVzIHJlc2VydmluZyB0aGUgYmVhbiBuYW1lICJhcHBsaWNh
dGlvbkV2ZW50TXVsdGljYXN0ZXIiLg0KDQpUaGUgb25seSByZW1haW5pbmcgcHJvYmxlbSBpcyB0
aGF0IEFwcGxpY2F0aW9uRXZlbnRNdWx0aWNhc3RlciBkZXJpdmVzIGZyb20gQXBwbGljYXRpb25M
aXN0ZW5lci4gT24gc3RhcnR1cCwgdGhlIGNvbnRleHQgcmV0cmlldmVzIGFsbCBBcHBsaWNhdGlv
bkxpc3RlbmVyIGJlYW5zIGFuZCByZWdpc3RlcnMgdGhlbSB3aXRoIHRoZSBtdWx0aWNhc3Rlci4g
VW5mb3J0dW5hdGVseSwgdGhpcyBtZWFucyB0aGF0IHRoZXJlIG5lZWRzIHRvIGJlIGFuIGV4cGxp
Y2l0IGNoZWNrIHRoYXQgdGhlIG11bHRpY2FzdGVyIGlzIG5vdCByZWdpc3RlcmVkIGFzIGEgbGlz
dGVuZXIgd2l0aCBpdHNlbGYuDQoNCg0KV2hpbGUgdGhlIGxhdHRlciBkb2VzIHdvcmssIGl0IGZl
ZWxzIGEgYml0IHVuY2xlYW4uIEhvd2V2ZXIsIHJlZ2lzdGVyaW5nIHRoZSBtdWx0aWNhc3RlciB2
aWEgYSBzZXRBcHBsaWNhdGlvbkV2ZW50TXVsdGljYXN0ZXIgbWV0aG9kIGlzbid0IHRvbyBjb252
aW5jaW5nIGVpdGhlciwgYXMgdGhlIG11bHRpY2FzdGVyIHNob3VsZCBub3QgY2hhbmdlIGFmdGVy
IGEgcmVmcmVzaC4gSGF2aW5nIGl0IGFzIHNwZWNpYWwgYmVhbiBpbiB0aGUgY29udGV4dCBqdXN0
IHNlZW1zIHRvIGJlIHRoZSBuYXR1cmFsIFNwcmluZyB3YXkuDQoNCk9mIGNvdXJzZSwgdW5sZXNz
IGl0IGlzIGFic29sdXRlbHkgY3Jpc3RhbCBjbGVhciBob3cgd2UncmUgZ29ubmEgYXBwcm9hY2gg
dGhpcywgdGhlIEFwcGxpY2F0aW9uRXZlbnRNdWx0aWNhc3RlciBiZWFuIG1lY2hhbmlzbSB3aWxs
IG5vdCBiZWNvbWUgcGFydCBvZiBhIHJlbGVhc2UuIEludHJvZHVjaW5nIGEgcHJvZ3JhbW1hdGlj
IGhvb2sgdG8gc2V0IGFuIEFwcGxpY2F0aW9uRXZlbnRNdWx0aWNhc3RlciBmb3IgdGhlIHRpbWUg
YmVpbmcgY291bGQgYmUgdW5kZXNpcmFibGUgdG9vIGlmIHdlIGNvbnNpZGVyIGRlZmluaW5nIGEg
YmVhbiBtZWNoYW5pc20gZm9yIDEuMC4zIChvciB0aGUgbGlrZSkuDQoNClRob3VnaHRzPw0KDQpK
dWVyZ2VuIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpWb246IHNwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IGltIEF1ZnRy
YWcgdm9uIE1hc29uLCBSb3NzDQpHZXNlbmRldDogRnIgMjguMDUuMjAwNCAxNTo0Mw0KQW46IHNw
cmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0OyBzcHJpbmdmcmFt
ZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KQmV0cmVmZjogUkU6IFtTcHJp
bmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBTcHJpbmcgLyBNdWxlIGludGVncmF0aW9uIC0gc3RlcCAx
DQoNCg0KSGkgSnVlcmdlbiwNCg0KRm9yIGV2ZW50cyBiZWluZyBwdWJsaXNoZWQgYnkgU3ByaW5n
IGJlYW5zIHRoZSBNdWxlRXZlbnRNYW5hZ2VyIGNhbiBzaW1wbHkgaW1wbGVtZW50IHRoZSBBcHBs
aWNhdGlvbkxpc3RlbmVyIGludGVyZmFjZS4gQnV0IGluIG9yZGVyIGZvciBNdWxlIHRvIHB1Ymxp
c2ggZXZlbnRzIHRvIHNwcmluZyBiZWFucyBiYXNlZCBvbiBzdWJzY3JpcHRpb25zLCB5b3Ugd291
bGQgbmVlZCB0byBwcm92aWRlIGFub3RoZXIgaW1wbGVtZW50YXRpb24gb2YgRXZlbnRNdWx0aWNh
c3RlciB0aGF0IHB1Ymxpc2hlZCBldmVudHMgYmFzZWQgb24gbGlzdGVuZXIgdHlwZSBhbmQgc3Vi
c2NyaXB0aW9uLiAgIEZvciBleGFtcGxlLCB5b3UgbWF5IGhhdmUgdHdvIGJlYW5zIGxpc3Rlbmlu
ZyBvbiBzZXBhcmF0ZSBqbXMgcXVldWVzIGkuZS4gYW4gb3JkZXJzLnF1ZXVlIGFuZCBleGNlcHRp
b24ucXVldWUsIHlvdSBkb24ndCB3YW50IHlvdXIgb3JkZXJzIGJlYW4gcmVjZWl2aW5nIGV4Y2Vw
dGlvbnMgYW5kIHZpY2UgdmVyc2EuIA0KDQpBbHNvLCB0aGUgY3VycmVudCBFdmVudE11bHRpY2Fz
dGVyIG9ubHkgYWxsb3dzIG9uZSBsaXN0ZXJuZXIgdG8gYmUgcmVnaXN0ZXJlZCBmb3IgZWFjaCB0
eXBlLCB3aGljaCBtZWFucyB5b3UgY291bGRuJ3QgaGF2ZSB0d28gYmVhbnMgbGlzdGVuaW5nIG9u
IGptcyB0b3BpY3MvcXVldWVzLg0KDQpDaGVlcnMsDQoNClJvc3MNCg0KICAgICAgICAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgICAgICBGcm9tOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBvbiBiZWhhbGYgb2YgasO8cmdlbiBow7Zs
bGVyIFt3ZXJrM0FUXQ0KICAgICAgICBTZW50OiBGcmkgMjgvMDUvMjAwNCAxOjQ5IFBNDQogICAg
ICAgIFRvOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0K
ICAgICAgICBDYzoNCiAgICAgICAgU3ViamVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyXSBTcHJpbmcgLyBNdWxlIGludGVncmF0aW9uIC0gc3RlcCAxDQogICAgICAgDQogICAgICAg
DQoNCiAgICAgICAgSGkgUm9zcywNCiAgICAgICANCiAgICAgICAgSW50ZXJlc3Rpbmcgc3R1ZmYh
IE91dCBvZiBjdXJpb3NpdHksIGFyZSB5b3UgdXNpbmcgTXVsZSB5b3Vyc2VsZiBpbiBhIGNvbmNy
ZXRlIGFwcGxpY2F0aW9uIGF0IEF0bGFzc2lhbj8NCiAgICAgICANCiAgICAgICAgUmVnYXJkaW5n
IGdldHRpbmcgbm90aWZpZWQgb2YgZXZlbnRzIHB1Ymxpc2hlZCBieSBTcHJpbmcgYmVhbnM6IFdo
eSBub3Qgc2ltcGx5IG1ha2UgdGhlIE11bGVFdmVudE1hbmFnZXIgaW1wbGVtZW50IHRoZSBBcHBs
aWNhdGlvbkxpc3RlbmVyIGludGVyZmFjZT8gSXQgd291bGQgYXV0b21hdGljYWxseSByZWNlaXZl
IGFsbCBBcHBsaWNhdGlvbkV2ZW50cyB0aGVuIChsaWtlIGFueSBvdGhlciBBcHBsaWNhdGlvbkxp
c3RlbmVyIGluIHRoZSBjb250ZXh0KSwgYmVpbmcgYWJsZSB0byBwcm9jZXNzIHRoZW0gYWNjb3Jk
aW5nbHkgKGFsbCBvdGhlciBsaXN0ZW5lcnMgd2lsbCBpZ25vcmUgZXZlbnRzIHRoYXQgdGhleSBk
b24ndCBrbm93IGFueXdheSkuDQogICAgICAgDQogICAgICAgIFNvIEkgZG9uJ3QgcmVhbGx5IHNl
ZSBhIHJlYXNvbiB3aHkgeW91J2QgbmVlZCB0byBob29rIGludG8gdGhlIEFwcGxpY2F0aW9uRXZl
bnRNdWx0aWNhc3RlciBoZXJlLiBQbGVhc2UgdGVsbCBtZSBpZiBJIG1pc3NlZCB5b3VyIHBvaW50
IDotKQ0KICAgICAgIA0KICAgICAgICBKdWVyZ2VuDQogICAgICAgDQogICAgICAgDQogICAgICAg
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgDQogICAgICAgIFZvbjog
c3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgaW0g
QXVmdHJhZyB2b24gTWFzb24sIFJvc3MNCiAgICAgICAgR2VzZW5kZXQ6IEZyIDI4LjA1LjIwMDQg
MTM6NDINCiAgICAgICAgQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNl
Zm9yZ2UubmV0DQogICAgICAgIEJldHJlZmY6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBT
cHJpbmcgLyBNdWxlIGludGVncmF0aW9uIC0gc3RlcCAxDQogICAgICAgDQogICAgICAgDQogICAg
ICAgIEhpLA0KICAgICAgICBJJ20gd3JpdGluZyBzb21lIGV4dGVuc2lvbnMgdG8gaW50ZWdyYXRl
IFNwcmluZyB3aXRoIE11bGUgKE11bGUgaXMgYW4gRVNCIC0gd3d3Lm11bGV1bW8ub3JnKS4gSSdt
IHN0YXJ0aW5nIHdpdGggYW4gZXh0ZW5zaW9uIHRvIFNwcmluZydzIEFwcGxpY2F0aW9uRXZlbnQg
aW1wbGVtZW50YXRpb24gdG8gYWxsb3cgYmVhbnMgdG8gcmVjZWl2ZSBNdWxlIGV2ZW50cy4NCiAg
ICAgICANCiAgICAgICAgTXVsZSBldmVudHMgY2FuIGJlIHNlbnQgb3ZlciB0cmFuc3BvcnRzIHN1
Y2ggYXMgam1zLCBodHRwLCBzbXRwLCBwb3AzLCB0Y3AsIGV0YyBzbyBhIGJlYW4gaW4gYSBTcHJp
bmcgY29udGV4dCBjb3VsZCBpbXBsZW1lbnQgYSBKbXNFdmVudExpc3RlbmVyLCBwb3AzRXZlbnRM
aXN0ZW5lciwgZXRjIHRvIHJlY2VpdmUgZXZlbnRzIHB1Ymxpc2hlZCBpbiBNdWxlLiAgUGx1cyB0
aGUgb2JzZXJ2ZXIgaW50ZXJmYWNlIGNvdWxkIGV4cG9zZSBzdWJzY3JpcHRpb24gbWV0aG9kcyB0
byBlbmFibGUgTXVsZSB0byBwdWJsaXNoIHRvIGRpZmZlcmVudCBzdWJzY3JpcHRpb25zLCBpLmUu
DQogICAgICAgDQogICAgICAgIHB1YmxpYyBjbGFzcyBKbXNFdmVudExpc3RlbmVyIGltcGxlbWVu
dHMgQXBwbGljYXRpb25FdmVudCB7DQogICAgICAgDQogICAgICAgICAgICBwdWJsaWMgdm9pZCBz
ZXRTdWJzY3JpcHRpb24oU3RyaW5nIHN1YnNjcmlwdGlvbik7DQogICAgICAgDQogICAgICAgICAg
ICBwdWJsaWMgU3RyaW5nIGdldFN1YnNjcmlwdGlvbigpOw0KICAgICAgICB9DQogICAgICAgDQog
ICAgICAgIFRoaXMgd291bGQgYWxsb3cgc3ByaW5ncyBiZWFucyB0byByZWNlaXZlIEptcyBtZXNz
YWdlcywgZW1haWxzLCBkYXRhIG92ZXIgaHR0cC4gTXVsZSBoYW5kbGVzIHRoZSB0cmFuc2Zvcm1h
dGlvbiBvZiB0aGVzZSBldmVudHMgdHJhbnNwYXJlbnRseS4NCiAgICAgICANCiAgICAgICAgZm9y
IHB1Ymxpc2hpbmcgZXZlbnRzLCB0aGUgYXBwbGljYXRpb24gY29kZSBjb3VsZCBwdWJsaXNoIGEg
TXVsZUV2ZW50IHdpdGggYW4gZW5kcG9pbnQgYW5kIGEgdHJhbnNwb3J0ICB0byB0aGUgYXBwbGlj
YXRpb25Db250ZXh0LCB3aGljaCBjb3VsZCBiZSByZWNpZXZlZCBieSBhIE11bGVFdmVudE1hbmFn
ZXIgYmVhbi4NCiAgICAgICANCiAgICAgICAgVGhlIHByb2JsZW0gaXMgdGhhdCBJJ20gaGF2aW5n
IHRyb3VibGUgc2VlaW5nIGhvdyB0byBjaGFuZ2UgdGhlIHdheSBTcHJpbmcgbWFuYWdlcyBldmVu
dHMuICBJZGVhbGx5LCB0aGUgRXZlbnRNdWx0aWNhc3RlciBvbiB0aGUgQWJzdHJhY3RBcHBsaWNh
dGlvbkNvbnRleHQgd291bGQgYmUgYWNjZXNzaWJsZSB3aXRoIGdldHRlciBhbmQgc2V0dGVyIG1l
dGhvZHMgc28gdGhhdCB0aGUgJ011bGVFdmVudE1hbmFnZXInIGJlYW4gY291bGQgaG9vayBpbiBp
dCdzIG93biBldmVudE11bHRpY2FzdGVyIHRoYXQga25vd3MgaG93IHRvIGRlYWwgc3Vic2NyaXB0
aW9uIGV2ZW50cyBhbmQgaG93IHRvIG1hbmFnZSBNdWxlRXZlbnRzIHB1Ymxpc2hlZCBieSBTcHJp
bmcgQmVhbnMuDQogICAgICAgDQogICAgICAgIEkgdGhpbmsgdGhpcyBzb3J0IG9mIGV4dGVuc2lv
biB3b3VsZCBhZGQgdmFsdWUgdG8gU3ByaW5nLCB3b3VsZCB5b3UgZ3V5cyBjb25zaWRlciBleHBv
c2luZyB0aGUgRXZlbnRNdWx0aWNhc3Rlcj8NCiAgICAgICANCiAgICAgICAgQ2hlZXJzLA0KICAg
ICAgIA0KICAgICAgICBSb3NzDQogICAgICAgDQogICAgICAgDQogICAgICAgIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgVGhp
cyBTRi5OZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBPcmFjbGUgMTBnDQogICAgICAgIEdldCBj
ZXJ0aWZpZWQgb24gdGhlIGhvdHRlc3QgdGhpbmcgZXZlciB0byBoaXQgdGhlIG1hcmtldC4uLiBP
cmFjbGUgMTBnLg0KICAgICAgICBUYWtlIGFuIE9yYWNsZSAxMGcgY2xhc3Mgbm93LCBhbmQgd2Un
bGwgZ2l2ZSB5b3UgdGhlIGV4YW0gRlJFRS4NCiAgICAgICAgaHR0cDovL2Fkcy5vc2RuLmNvbS8/
YWRfaWQxNDkmYWxsb2NfaWTCgTY2Jm9wPWljaw0KICAgICAgICBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICBTcHJpbmdmcmFtZXdvcmstZGV2
ZWxvcGVyIG1haWxpbmcgbGlzdA0KICAgICAgICBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxp
c3RzLnNvdXJjZWZvcmdlLm5ldA0KICAgICAgICBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5l
dC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQogICAgICAgDQoNCg0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpUaGlzIFNGLk5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IE9yYWNsZSAxMGcNCkdldCBjZXJ0
aWZpZWQgb24gdGhlIGhvdHRlc3QgdGhpbmcgZXZlciB0byBoaXQgdGhlIG1hcmtldC4uLiBPcmFj
bGUgMTBnLg0KVGFrZSBhbiBPcmFjbGUgMTBnIGNsYXNzIG5vdywgYW5kIHdlJ2xsIGdpdmUgeW91
IHRoZSBleGFtIEZSRUUuDQpodHRwOi8vYWRzLm9zZG4uY29tLz9hZF9pZDE0OSZhbGxvY19pZMKB
NjYmb3A9aWNrDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNClNwcmluZ2ZyYW1ld29y
ay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpodHRwczovL2xpc3RzLnNvdXJjZWZv
cmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoNCg0K