springframework-developer — Spring Framework developers list

[Springframework-developer] Nicolas BONVIN is out of the office.

[Nicolas B. <nb...@pi...>]

I will be out of the office starting  17.06.2005 and will not return until
04.07.2005.

I will respond to your message when I return.
My teammate Laurent Rolaz (lr...@pi...) can be contacted for WebLogic
matters.
My teammate Jean Kunz (jk...@pi...) can be contacted for urgent
matters.


________________________________________________________________

Pictet & Cie, Banquiers                  Tel. +41 (0)58 323 2323
29, boulevard Georges-Favon              Fax  +41 (0)58 323 2324
CH-1204 GENEVE                            http://www.pictet.com/
________________________________________________________________

This document should only be read by those persons to whom it is
addressed  and  is  not intended to be relied upon by any person
without  subsequent written confirmation of its contents. If you
have  received  this  e-mail message in error, please destroy it
and delete it from your computer.
Any  form of  reproduction, dissemination, copying,  disclosure,
modification,  distribution  and/or  publication  of this E-mail
message is strictly prohibited.
________________________________________________________________

[Springframework-developer] spring build.285 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050618001656Lbuild.285

Re: [Springframework-developer] Stale JTA transaction still attached to a tread

[Dave B. <dba...@on...>]

Hi Juergen,

There was a failure involving the Spring transactional cleanup code 
which may be of interest.

Background: My application architecture is in transition from stateless 
session beans (for transaction demarcation) and entity beans, to Spring 
managed services (and transaction demarcation) and dao's. So currently, 
I've got a mix of both. In some cases, I've got a session bean starting 
a transaction, then that session bean calling a Spring service 
(resulting in the JTA transaction being joined). In other newer code, 
Spring starts the transaction.

The thread in question is ExecuteThread: '5'. The first sign of trouble 
with this thread is a failure of an insert statement. I've seen this 
'PreparedStatement' exception once before a number of months ago. I 
don't *think* this is a Hibernate bug, as the last time the error 
involved an entity bean.  It may be a problem with my JDBC driver.

Spring didn't start this transaction, but at this point in processing, 
SessionFactoryUtils.getSession(sessionFactory, true) has been called 
from the session bean, and a Spring managed service (with a 
JtaTransactionManager transaction interceptor) has also been called.

---
ERROR 13:34:55,789 [ExecuteThread: '5' for queue: 'default'] [mariew_] 
(MoneyTransactionSessionEJB.java:459) - Error creating advance
net.sf.hibernate.JDBCException: could not insert: 
[LedgerEntryClass#LEN000061465159]
    at 
net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:478)
    at 
net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:442)
    at 
net.sf.hibernate.impl.ScheduledInsertion.execute(ScheduledInsertion.java:29)
    at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2414)
    at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2367)
    at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2236)
    at 
MoneyTransactionSessionEJB.createLedgerEntriesForNewContractItems(MoneyTransactionSessionEJB.java:5661)
    at 
MoneyTransactionSessionEJB.processTransactionInternal(MoneyTransactionSessionEJB.java:704)
    at 
MoneyTransactionSessionEJB.processTransaction(MoneyTransactionSessionEJB.java:454)
    at 
MoneyTransactionSessionEJB_xvjdlx_ELOImpl.processTransaction(MoneyTransactionSessionEJB_xvjdlx_ELOImpl.java:1037)
    at java.lang.reflect.Method.invoke(Native Method)
    at 
org.springframework.ejb.access.LocalSlsbInvokerInterceptor.invoke(LocalSlsbInvokerInterceptor.java:66)
    at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
    at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
    at $Proxy126.processTransaction(Unknown Source)
    at AdvanceCreate.execute(AdvanceCreate.java:109)
    at AdvanceCommit.createAdvance(AdvanceCommit.java:368)
    at AdvanceCommit.process(AdvanceCommit.java:118)
    at 
jsp_servlet._jsp._advance.__advance_confirm._jspService(__advance_confirm.java:125)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at 
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at 
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2708)
    at 
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2427)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
Caused by:
java.sql.SQLException: [JTurbo 3.1d9 JDBC 2.1 Driver]: PreparedStatement 
is closed
    at com.newatlanta.jturbo.driver.u.executeUpdate(u.java)
    at weblogic.jdbc.jts.Statement.executeUpdate(Statement.java:508)
    at 
net.sf.hibernate.impl.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:22)
    at 
net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:468)
    ... 29 more
---

One minute later, this same thread was used for a different request (the 
username is different):

---
ERROR 13:35:56,805 [ExecuteThread: '5' for queue: 'default'] [dan101_] 
(AbstractPlatformTransactionManager.java:585) - Rollback exception 
overridden by synchronization exception
java.lang.IllegalStateException: No value for key 
[net.sf.hibernate.impl.SessionFactoryImpl@55f3ea] bound to thread 
[ExecuteThread: '5' for queue: 'default']
    at 
org.springframework.transaction.support.TransactionSynchronizationManager.unbindResource(TransactionSynchronizationManager.java:175)
    at 
org.springframework.orm.hibernate.SessionFactoryUtils$SpringSessionSynchronization.beforeCompletion(SessionFactoryUtils.java:871)
    at 
org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerBeforeCompletion(AbstractPlatformTransactionManager.java:580)
    at 
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:425)
    at 
org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(TransactionAspectSupport.java:258)
    at 
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:67)
    at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
    at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
    at $Proxy114.findContract(Unknown Source)
    at AdvanceView.load(AdvanceView.java:228)
    at AdvanceView.process(AdvanceView.java:141)
    at 
jsp_servlet._jsp._advance.__advanceview._jspService(__advanceview.java:139)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at 
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at 
weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:289)
    at 
webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:222)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at 
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at 
weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:289)
    at 
weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:119)
    at 
jsp_servlet._jsp._advance.__advance_confirm._jspService(__advance_confirm.java:165)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at 
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at 
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2708)
    at 
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2427)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
    ---
   
There are no nested exceptions. In the previous stack trace, the 
presentation layer called a Spring  managed service (which started its 
own transaction).
   
After this point, each time ExecuteThread: '5' is used,  it fails with a 
org.springframework.jdbc.UncategorizedSQLException wrapping a WebLogic 
TimedOutException. The transaction ID (496219) is always the same. This 
happens over and over again. As I was investigating this problem, I 
began to ask myself "why are all of these timeouts on the same thread?". 
Restarting the app server corrected the problem. The timeout information 
looks like:
   
    ---
    ERROR 13:37:04,650 [ExecuteThread: '5' for queue: 'default'] 
[torry_] (HibernateSpringContractDAO.java:235) -
      org.springframework.jdbc.UncategorizedSQLException:
      executing PreparedStatementCallback: encountered SQLException
      [The transaction is no longer active (status = Rolled back.
      [Reason=weblogic.transaction.internal.TimedOutException:
      Transaction timed out after 29 seconds
Xid=4954:766e8eae3c8bdd4d(496219),
      Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds 
since begin=29,
      seconds left=30,activeThread=Thread[ExecuteThread: '5' for queue: 
'default',5,
      Thread Group for Queue: 
'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=
      
(state=started,assigned=none),SCInfo[myappserver+appserver]=(state=active),
      
properties=({weblogic.jdbc=t3://192.168.1.1:80}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=
      (CoordinatorURL=appserver+192.168.1.1:80+myappserver+, Resources={})],
      CoordinatorURL=appserver+192.168.1.1:80+myappserver+)]).
      No further JDBC access is allowed  within this transaction.];
      nested exception is java.sql.SQLException: The transaction is no 
longer active
      (status = Rolled back. 
[Reason=weblogic.transaction.internal.TimedOutException:
      Transaction timed out after 29 seconds
Xid=4954:766e8eae3c8bdd4d(496219),Status=Active,
      numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since 
begin=29,seconds left=30,
      activeThread=Thread[ExecuteThread: '5' for queue: 
'default',5,Thread Group for Queue: 'default'],
      
ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=none),
      
SCInfo[myappserver+appserver]=(state=active),properties=({weblogic.jdbc=t3://192.168.1.1:80}),
      
OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=appserver+192.168.1.1:80+myappserver+, 
Resources={})],
      CoordinatorURL=appserver+192.168.1.1:80+myappserver+)]).
      No further JDBC access is allowed  within this transaction.
    ---
   
    The nested exception is:
   
    ---
     
ERROR 13:37:04,650 [ExecuteThread: '5' for queue: 'default'] [torry_] 
(ServletUtils.java:221) - Error
[trimmed verbose timeout info referencing Xid=4954:766e8eae3c8bdd4d(496219)]
    at 
HibernateSpringContractDAO.findContract(HibernateSpringContractDAO.java:236)
    at java.lang.reflect.Method.invoke(Native Method)
    at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:288)
    at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:155)
    at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:122)
    at 
org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateInterceptor.java:164)
    at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
    at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
    at $Proxy93.findContract(Unknown Source)
    at ContractServiceImpl.findContract(ContractServiceImpl.java:59)
    at java.lang.reflect.Method.invoke(Native Method)
    at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:288)
    at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:155)
    at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:122)
    at 
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:57)
    at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
    at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
    at $Proxy114.findContract(Unknown Source)
    at AdvanceView.load(AdvanceView.java:228)
    at AdvanceView.process(AdvanceView.java:141)
    at 
jsp_servlet._jsp._advance.__advanceview._jspService(__advanceview.java:139)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at 
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at 
weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:289)
    at 
webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:222)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at 
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
    at AccessControlFilter.doFilter(AccessControlFilter.java:79)
    at 
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
    at 
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2708)
    at 
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2427)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
Caused by:
[trimmed verbose timeout info referencing Xid=4954:766e8eae3c8bdd4d(496219)]
    at weblogic.jdbc.jts.Connection.checkIfRolledBack(Connection.java:526)
    at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:122)
    at 
org.springframework.jdbc.core.JdbcTemplate$SimplePreparedStatementCreator.createPreparedStatement(JdbcTemplate.java:992)
    at 
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:444)
    at 
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:491)
    at 
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:530)
    at 
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:548)
    at 
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:553)
    at 
HibernateSpringContractDAO.findActiveNSF(HibernateSpringContractDAO.java:716)
    at 
HibernateSpringContractDAO.findContract(HibernateSpringContractDAO.java:231)
    ---
   
  Please let me know what additional information I can provide.
 
  Thanks again for your help,
  Dave

Juergen Hoeller wrote:

>Hi Dave,
>
>That's indeed odd, in particular as Spring does not explicitly associate JTA
>transactions with the current thread (of course the JTA provider itself will
>use ThreadLocals underneath).
>
>The only thing that could be bound to the thread by Spring within a JTA
>transaction is a transactional resource, such as a JDBC Connection or a
>Hibernate Session. Such resources should _always_ get removed from the
>thread by Spring's corresponding synchronization classes, though: So if such
>a resource would be the root cause, this would mean some bug in Spring's
>resource cleanup code.
>
>If you can track down any details, I'm gonna address this immediately (even
>during the weekend). It would be great to clarify this before the upcoming
>Spring 1.2.2 release...
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Dave Ballard
>Sent: Friday, June 17, 2005 7:06 PM
>To: spr...@li...
>Subject: [Springframework-developer] Stale JTA transaction still
>attached to a tread
>
>
>Hi Juergen,
>
>Using Spring 1.2.1 with JtaTransactionManager with WebLogic 6.1. A
>review of my logs showed a large number of JTA timeouts. The odd thing
>is that the timeouts seem all to be occurring on the same thread. What
>WebLogic reports as the transaction ID is always the same.
>
>It appears to me that there is stale Spring JTA transaction attached to
>this particular thread. Each time WebLogic releases this thread to a
>request, and attempts to run some SQL (via Spring), it gets a JTA
>timeout with the same transaction ID.
>
>I'm about to restart our server, and I expect this to clear up the
>problem. However, this is a pretty serious problem. I am going to go
>back through the logs and attempt to locate the root error for this thread.
>
>Thanks for your help,
>Dave
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

RE: [Springframework-developer] enums, styler, comparator

[Keith D. <ke...@in...>]

We're missing a convenience method to call from styling code.

e.g

ToStringStyler.style(value);

Doing this: ToStringStyler.DEFAULT_VALUE_STYLER.style(value) is a bit
lengthy :-)

How about StylerUtils.style(value)?

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Juergen Hoeller
Sent: Friday, June 17, 2005 5:30 AM
To: spr...@li...
Subject: Re: [Springframework-developer] enums, styler, comparator

I share that view. Making the styling strategies pluggable is nice for
ToStringCreator itself (for creating a custom instance of it through the
overloaded constructor), but I doubt that anyone will want to change the
global default styling strategies.

I've already added a public static DEFAULT_VALUE_STYLER field to
ToStringCreator, exposing the default ValueStyler alongside the default
ToStringStyler. I've also added a further convenience constructor to
ToStringCreator, allowing to specify a specific ValueStyler to use (instead
of specifying the entire ToStringStyler).

So we have shared default instances now, plus the option to specify custom
instances on ToStringCreator or on direct ValueStyler use. The only thing
missing is overriding the global default stylers, which I consider
acceptable. I don't want people to be able to override static global
instances - at any time - in the first place.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Erwin Vervaet
Sent: Friday, June 17, 2005 9:19 AM
To: spr...@li...
Subject: Re: [Springframework-developer] enums, styler, comparator


> Creating objects with new is arguably a bad idea here, as now I've got
> that
> new operator spread around everywhere with no capability to plug in custom
> value styling strategies for my own types of objects, for example.

Agreed, but is making the styling strategies pluggable something users would
ever do in practice? Seems to be a bit of an exotic feature.

>
> On the other hand, with a loader to easily plug-in a custom global
> implementation, users can easily switch on custom string styling
> algorithms
> for types they use but don't have control over without any hassle.  They
> simply switch it in at runtime when their application is bootstrapped.
>
> In any case, what's most appropriate to customize here is the ValueStyler
> strategy, not the ToStringCreator strategy.  It's where the magic for
> pretty
> printing objects of different types happen...
>
> Keith
>
> -----Original Message-----
> From: Keith Donald [mailto:ke...@in...]
> Sent: Thursday, June 16, 2005 6:23 PM
> To: 'spr...@li...'
> Subject: RE: [Springframework-developer] enums, styler, comparator
>
> Yeah, but injection there is not at al practical.  Singleton usage for
> this
> kind of usage is acceptable IMO.  The singleton has a default that is not
> expensive to initialize (its just a POJO with no other dependencies).
> Furthermore, that default is still configurable through a static load
> method.  I don't see the problem there.
>
> Now, I am up for just changing the exception messages in webflow to rely
> on
> the standard collections toString implementations.  However I admit that
> would be a bit of a step back, especially after someone just remarked in a
> training how descriptive and "great looking" that one exception message
> was
> ;-)
>
> Keith
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of
> Juergen Hoeller
> Sent: Thursday, June 16, 2005 2:07 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] enums, styler, comparator
>
> It's been replaced by the ValueStyler interface and DefaultValueStyler
> implementation, in the "core.style" package.
>
> I'm currently discussing with Keith whether a ValueStyler singleton should
> be re-introduced. Currently, the only singleton held is ToStringCreator's
> DefaultToStringStyler, which in turn holds a DefaultValueStyler instance.
>
> I'd like to keep singletons as minimal as possible. There's always the
> option to use "new DefaultValueStyler()" / "new DefaultToStringStyler()"
> or
> even receive a ValueStyler / ToStringStyler through dependency injection.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Colin Sampaleanu
> Sent: Thursday, June 16, 2005 6:02 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] enums, styler, comparator
>
>
> Juergen Hoeller wrote:
>
>>Everybody,
>>
>>Keith's LabeledEnum and ToStringCreator stuff has been moved over from the
>>sandbox, to be shipped with Spring 1.2.2 (and to be used by Web Flow PR4).
>>
>>I've rearranged the structure and also reworked the implementations /
>>interfaces quite a bit. ToStringCreator and its helpers reside in the
>>"core.style" package now; LabeledEnum and LabeledEnumResolver in
>>"core.enums" (without separate support subpackage; it's all in one package
>>name).
>>
>>I've also reworked the generic comparators: they reside in
> "util.comparator"
>>now. The biggest change there is that there is no SortDefinition class
>>anymore. Instead, an InvertibleComparator decorator takes over the same
>>role. SortDefinition already was a Comparator decorator before, so was
>>arguably misnamed.
>>
>>Keith / Erwin, could you please make sure that everything's compiling
>>again
>>on the Web Flow side of things. Once the Web Flow module has found its
> final
>>home in the CVS structure, that is ;-)
>>
>>
>
> What happened to the 'Styler' class?
>
>
http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springf
> ramework/core/Attic/Styler.java?view=markup
> I tried to make the SWF code compile against current Spring CVS while on
> a plane ride back to Toronto yesterday, but Styler seems to be gone. So
> right now the SWF code is still building against a snapshot from June
> 13th.
>
> Colin
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Stale JTA transaction still attached to a tread

[Juergen H. <ju...@in...>]

Hi Dave,

That's indeed odd, in particular as Spring does not explicitly associate JTA
transactions with the current thread (of course the JTA provider itself will
use ThreadLocals underneath).

The only thing that could be bound to the thread by Spring within a JTA
transaction is a transactional resource, such as a JDBC Connection or a
Hibernate Session. Such resources should _always_ get removed from the
thread by Spring's corresponding synchronization classes, though: So if such
a resource would be the root cause, this would mean some bug in Spring's
resource cleanup code.

If you can track down any details, I'm gonna address this immediately (even
during the weekend). It would be great to clarify this before the upcoming
Spring 1.2.2 release...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Dave Ballard
Sent: Friday, June 17, 2005 7:06 PM
To: spr...@li...
Subject: [Springframework-developer] Stale JTA transaction still
attached to a tread


Hi Juergen,

Using Spring 1.2.1 with JtaTransactionManager with WebLogic 6.1. A
review of my logs showed a large number of JTA timeouts. The odd thing
is that the timeouts seem all to be occurring on the same thread. What
WebLogic reports as the transaction ID is always the same.

It appears to me that there is stale Spring JTA transaction attached to
this particular thread. Each time WebLogic releases this thread to a
request, and attempts to run some SQL (via Spring), it gets a JTA
timeout with the same transaction ID.

I'm about to restart our server, and I expect this to clear up the
problem. However, this is a pretty serious problem. I am going to go
back through the logs and attempt to locate the root error for this thread.

Thanks for your help,
Dave


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Memory consumption using JmsTemplate

[Juergen H. <ju...@in...>]

That's indeed a bug: JmsTemplate should always explicitly close the
MessageProducers it creates. It currently relies on implicit close through
the JMS Session (i.e. that Session.close also closes all its producers), but
that's obviously not the case with all JMS providers.

I've fixed this already, to be released in the upcoming Spring 1.2.2.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Claus Ibsen
Sent: Friday, June 17, 2005 2:29 PM
To: spr...@li...
Subject: [Springframework-developer] Memory consumption using
JmsTemplate


A person on the forum have a memory leak using the JmsTemplate.

http://forum.springframework.org/viewtopic.php?t=6365

Sorry for posting it here but if there really is a leak it would be nice to
be
fixed. And the best persons to look at this is the mighty core developers.

/Claus



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Stale JTA transaction still attached to a tread

[Dave B. <dba...@on...>]

Hi Juergen,

Using Spring 1.2.1 with JtaTransactionManager with WebLogic 6.1. A 
review of my logs showed a large number of JTA timeouts. The odd thing 
is that the timeouts seem all to be occurring on the same thread. What 
WebLogic reports as the transaction ID is always the same.

It appears to me that there is stale Spring JTA transaction attached to 
this particular thread. Each time WebLogic releases this thread to a 
request, and attempts to run some SQL (via Spring), it gets a JTA 
timeout with the same transaction ID.

I'm about to restart our server, and I expect this to clear up the 
problem. However, this is a pretty serious problem. I am going to go 
back through the logs and attempt to locate the root error for this thread.

Thanks for your help,
Dave

[Springframework-developer] Re: Spring binding and validation for Struts

[Matt S. <sga...@us...>]

I prefer the Delegating Action mechanism which defines Struts Actions in 
the Spring application context.  To me this is the most natural solution 
because then Struts Actions are beans just like anything else in a 
Spring application.  It's very conceptually simple.

I think Spring should only provide a single mechanism to inject 
dependencies into Struts actions.  This is easiest for users of Spring 
because there's only one mechanism to learn and no choices to make. 
It's also easiest for the development team because only one mechanism 
needs to be coded, tested, maintained and documented.  Since the current 
Delegating Action mechanism has been around for a long time, I think it 
would make the most sense to keep it and not introduce new ways to 
inject dependencies into Struts Actions.

Matt

Keith Donald wrote:
> Awesome, Juergen, glad to see this cleanup here as I was always in to what
> that code was doing (allowing us to use Spring's data binding with Struts)
> but never really happy with the implementation.  Nice work.
> 
> I think the autowire option is important enough to keep in.  It really is
> the simplest way to get DI on your actions.
> 
> Keith
> 
> 
>>I've now also given a Juergen treatment ;-) to the Spring
>>binding/validation
>>adapter for Struts that Keith committed to the main source tree.
>>
>>For everybody not familiar with this from the Web Flow side of things: The
>>idea here is to allow for using Spring's DataBinder/Errors mechanism
>>within
>>a Struts web tier, seamlessly exposing the result to traditional Struts
>>views (with "html:form", "html:errors", etc).
>>
>>I've significantly reworked this: In contrast to its original inception
>>where there've been a special RequestProcessor, a special PlugIn and a
>>special ActionForm, what's left now is - a single SpringBindingActionForm
>>adapter. SpringBindingActionForm cares for everything necessary: from
>>extending Commons BeanUtils to exposing the Spring-managed errors as
>>Struts
>>ActionMessages.
>>
>>There is no special RequestProcessor necessary anymore, which I consider
>>as
>>a must: Too many Struts extensions subclass the RequestProcessor
>>themselves,
>>including Tiles and our own Delegating Action mechanism.
>>
>>The final usage style looks as follows. In "struts-config.xml", a single
>>ActionForm is defined for all Actions:
>>
>><form-beans>
>>  <form-bean name="actionForm"
>>type="org.springframework.web.struts.SpringBindingActionForm"/>
>></form-beans>
>>
>>In each Struts Action that wants to use Spring binding/validation for a
>>plain POJO form object, the following pattern can be used:
>>
>>public ActionForward execute(ActionMapping actionMapping, ActionForm
>>actionForm, HttpServletRequest request, HttpServletResponse response)
>>throws
>>Exception {
>>  SpringBindingActionForm form = (SpringBindingActionForm) actionForm;
>>  MyPojoBean bean = ...;
>>  ServletRequestDataBinder binder = new ServletRequestDataBinder(bean,
>>"myPojo");
>>  binder.bind(request);
>>  form.expose(binder.getErrors(), request);
>>  return actionMapping.findForward("success");
>>}
>>
>>Keith/Erwin, please give this reworked version a try in Web Flow's Struts
>>adapter. As far as I can see, it should still work nicely for those needs.
>>
>>---
>>
>>Regarding the further Struts support classes added alongside the
>>binding/validation support:
>>
>>The TemplateAction class essentially duplicated what our existing
>>ActionSupport already did, plus a view convenience mirrors of static
>>utility
>>methods (which I consider unnecessary - why not access the corresponding
>>static RequestUtils methods directly). The "preExecute" and "postExecute"
>>are fine in general, but it's not Spring's business to provide such Struts
>>stuff that's not related to Spring mechanisms... Hence, I've dropped
>>TemplateAction completely.
>>
>>DependencyInjectedAction, which autowires the Action instance by type, is
>>not a bad idea. I don't think that it should be a dedicated class, though,
>>so I've removed it as well. If we intend to recommend such an autowiring
>>pattern for Struts Actions, we should build it as an option into the
>>existing ActionSupport class. However, there's DispatchActionSupport and
>>Lookup/MappingDispatchActionSupport as well, so we'd need to duplicate
>>quite
>>a bit...
>>
>>Note that we also offer a Delegating Action mechanism, which completely
>>defines Struts Actions in a Spring context. Of course, any kind of
>>autowiring is available to those instances already. Hence, I'm not sure
>>whether we should provide yet another dependency injection for Struts
>>Actions out-of-the-box. If we consider this important enough, I won't
>>mind,
>>but we should strive for integrating this into the existing
>>XxxActionSupport
>>classes - if at all.
>>
>>Juergen
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
> 
> 
> 

[Springframework-developer] Eclipse project source level

[Colin S. <col...@ex...>]

Note that I have had to set the Eclipse project for Spring to JDK 1.5 
compliance so that it doesn't complain about the Annotations related 
code. It also puts out JDK 1.5 specific code. When you enable this on a 
project specific basis, eclipse puts the stuff in some files in a 
.settings subdirectory, which I've now checke din.

The other option would have been for people to all set their default 
eclipse preferences to JDK 1.5, but I think that's less desireable, when 
we can explicitly indicate in the project prefs that it's 1.5 support is 
needed.

Since we're mixing source trees at this point, this is being done for 
the whole codebase.

If you're building Spring to give out to other people, make sure to 
build from Ant and do a clean, so that all non 1.5 code gets built as 
JDK 1.3 compatible code.

Colin

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Re: [Springframework-developer] Re: Building webflow under spring-projects

[Colin S. <col...@ex...>]

Ivy 1.1, which came out about a week ago, adds about a month's worth of 
fixes and tweaks to Ivy 1.0. Among the enhancements there is for example 
the ability to set a property to specify (per repository) that even if 
the cache has a version of a requested artifact, Ivy should look in the 
repo for a newer (by date) version of the same artifact with the same 
revision number. Generally there are no downsides to using Ivy 1.1 
instead of 1.0.

As for the snapshot, I discovered yesterday that when you customize the 
location where Ivy places 'delivered' ivy.xml files for the current 
build which show all the final resolved artifacts, the subsequent 
publish operation fails as it looks for the ivy.xml file in the default 
location. This is problematic as for the Spring build I need to 
customize this location (to be hierarchical) so that the output of 
multiple builds (including the ivy.xml files with transitive 
dependencies) can all be combined. Unless somebody is using the 
'publish' functionality this is irrelevant, but I'm working on the 
general build for Spring, and for building webflow and all the related 
samples.

Colin

Keith Donald wrote:

>Just curious - what's new in Ivy 1.1? How come we're relying on a ivy
>snapshot?
>
>Keith
>
>  
>
>>Yes. I'm just getting confirmation from Torsten/Christian that the old
>>spring-ide module in CVS can be kileld (all the Spring-IDE) source is in
>>their own Subversion repo now, then I'll publish a list of what modules
>>are staying and which are being pruned, and submit a service request to
>>SF.
>>
>>
>>Erwin Vervaet wrote:
>>
>>    
>>
>>>Okay, I've moved my Eclipse over to use the new spring-projects module.
>>>So I guess we can have the SF people clean up those bogus modules?
>>>
>>>Erwin Vervaet
>>>erw...@er...
>>>----- Original Message ----- From: "Colin Sampaleanu"
>>><col...@ex...>
>>>To: "Keith Donald" <ke...@in...>; "Erwin Vervaet"
>>><erw...@er...>
>>>Cc: <spr...@li...>
>>>Sent: Friday, June 17, 2005 4:44 AM
>>>Subject: Building webflow under spring-projects
>>>
>>>
>>>      
>>>
>>>>Keith/Erwin,
>>>>
>>>>I moved (copied really) all common-build, spring-binding, and
>>>>spring-webflow sources to live under a new spring-projects module in
>>>>CVS.
>>>>
>>>>Note that the build relies on the use of a nightly snapshot of ivy
>>>>  ivy-20050616204129.jar
>>>>which may be found in
>>>>  spring-projects\repository\jayasoft\ivy\jars
>>>>This should be dropped into your ant lib dir to replace the older ivy
>>>>1.1. This If you try to use ivy 1.1 you'll get a failure when trying
>>>>to do a publish of the generated artifact.
>>>>
>>>>--
>>>>Colin Sampaleanu
>>>>Interface21 Principal Consultant
>>>>Spring Training, Consulting and Support - "From the Source"
>>>>http://www.springframework.com
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>>informative Webcasts and more! Get everything you need to get up to
>>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>      
>>>
>>
>>--
>>Colin Sampaleanu
>>Interface21 Principal Consultant
>>Spring Training, Consulting and Support - "From the Source"
>>http://www.springframework.com
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>    
>>
>
>
>  
>


-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Re: [Springframework-developer] Re: Building webflow under spring-projects

[Keith D. <ke...@in...>]

Just curious - what's new in Ivy 1.1? How come we're relying on a ivy
snapshot?

Keith

> Yes. I'm just getting confirmation from Torsten/Christian that the old
> spring-ide module in CVS can be kileld (all the Spring-IDE) source is in
> their own Subversion repo now, then I'll publish a list of what modules
> are staying and which are being pruned, and submit a service request to
> SF.
>
>
> Erwin Vervaet wrote:
>
>> Okay, I've moved my Eclipse over to use the new spring-projects module.
>> So I guess we can have the SF people clean up those bogus modules?
>>
>> Erwin Vervaet
>> erw...@er...
>> ----- Original Message ----- From: "Colin Sampaleanu"
>> <col...@ex...>
>> To: "Keith Donald" <ke...@in...>; "Erwin Vervaet"
>> <erw...@er...>
>> Cc: <spr...@li...>
>> Sent: Friday, June 17, 2005 4:44 AM
>> Subject: Building webflow under spring-projects
>>
>>
>>> Keith/Erwin,
>>>
>>> I moved (copied really) all common-build, spring-binding, and
>>> spring-webflow sources to live under a new spring-projects module in
>>> CVS.
>>>
>>> Note that the build relies on the use of a nightly snapshot of ivy
>>>   ivy-20050616204129.jar
>>> which may be found in
>>>   spring-projects\repository\jayasoft\ivy\jars
>>> This should be dropped into your ant lib dir to replace the older ivy
>>> 1.1. This If you try to use ivy 1.1 you'll get a failure when trying
>>> to do a publish of the generated artifact.
>>>
>>> --
>>> Colin Sampaleanu
>>> Interface21 Principal Consultant
>>> Spring Training, Consulting and Support - "From the Source"
>>> http://www.springframework.com
>>>
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> --
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-- 
Keith Donald
Principal Consultant, Interface21
http://www.springframework.com - Spring Services From the Source

Re: [Springframework-developer] Re: Building webflow under spring-projects

[Colin S. <col...@ex...>]

Yes. I'm just getting confirmation from Torsten/Christian that the old 
spring-ide module in CVS can be kileld (all the Spring-IDE) source is in 
their own Subversion repo now, then I'll publish a list of what modules 
are staying and which are being pruned, and submit a service request to SF.


Erwin Vervaet wrote:

> Okay, I've moved my Eclipse over to use the new spring-projects module.
> So I guess we can have the SF people clean up those bogus modules?
>
> Erwin Vervaet
> erw...@er...
> ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...>
> To: "Keith Donald" <ke...@in...>; "Erwin Vervaet" 
> <erw...@er...>
> Cc: <spr...@li...>
> Sent: Friday, June 17, 2005 4:44 AM
> Subject: Building webflow under spring-projects
>
>
>> Keith/Erwin,
>>
>> I moved (copied really) all common-build, spring-binding, and 
>> spring-webflow sources to live under a new spring-projects module in 
>> CVS.
>>
>> Note that the build relies on the use of a nightly snapshot of ivy
>>   ivy-20050616204129.jar
>> which may be found in
>>   spring-projects\repository\jayasoft\ivy\jars
>> This should be dropped into your ant lib dir to replace the older ivy 
>> 1.1. This If you try to use ivy 1.1 you'll get a failure when trying 
>> to do a publish of the generated artifact.
>>
>> -- 
>> Colin Sampaleanu
>> Interface21 Principal Consultant
>> Spring Training, Consulting and Support - "From the Source"
>> http://www.springframework.com
>>
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Re: [Springframework-developer] Spring binding and validation for Struts

[Keith D. <ke...@in...>]

Awesome, Juergen, glad to see this cleanup here as I was always in to what
that code was doing (allowing us to use Spring's data binding with Struts)
but never really happy with the implementation.  Nice work.

I think the autowire option is important enough to keep in.  It really is
the simplest way to get DI on your actions.

Keith

> I've now also given a Juergen treatment ;-) to the Spring
> binding/validation
> adapter for Struts that Keith committed to the main source tree.
>
> For everybody not familiar with this from the Web Flow side of things: The
> idea here is to allow for using Spring's DataBinder/Errors mechanism
> within
> a Struts web tier, seamlessly exposing the result to traditional Struts
> views (with "html:form", "html:errors", etc).
>
> I've significantly reworked this: In contrast to its original inception
> where there've been a special RequestProcessor, a special PlugIn and a
> special ActionForm, what's left now is - a single SpringBindingActionForm
> adapter. SpringBindingActionForm cares for everything necessary: from
> extending Commons BeanUtils to exposing the Spring-managed errors as
> Struts
> ActionMessages.
>
> There is no special RequestProcessor necessary anymore, which I consider
> as
> a must: Too many Struts extensions subclass the RequestProcessor
> themselves,
> including Tiles and our own Delegating Action mechanism.
>
> The final usage style looks as follows. In "struts-config.xml", a single
> ActionForm is defined for all Actions:
>
> <form-beans>
>   <form-bean name="actionForm"
> type="org.springframework.web.struts.SpringBindingActionForm"/>
> </form-beans>
>
> In each Struts Action that wants to use Spring binding/validation for a
> plain POJO form object, the following pattern can be used:
>
> public ActionForward execute(ActionMapping actionMapping, ActionForm
> actionForm, HttpServletRequest request, HttpServletResponse response)
> throws
> Exception {
>   SpringBindingActionForm form = (SpringBindingActionForm) actionForm;
>   MyPojoBean bean = ...;
>   ServletRequestDataBinder binder = new ServletRequestDataBinder(bean,
> "myPojo");
>   binder.bind(request);
>   form.expose(binder.getErrors(), request);
>   return actionMapping.findForward("success");
> }
>
> Keith/Erwin, please give this reworked version a try in Web Flow's Struts
> adapter. As far as I can see, it should still work nicely for those needs.
>
> ---
>
> Regarding the further Struts support classes added alongside the
> binding/validation support:
>
> The TemplateAction class essentially duplicated what our existing
> ActionSupport already did, plus a view convenience mirrors of static
> utility
> methods (which I consider unnecessary - why not access the corresponding
> static RequestUtils methods directly). The "preExecute" and "postExecute"
> are fine in general, but it's not Spring's business to provide such Struts
> stuff that's not related to Spring mechanisms... Hence, I've dropped
> TemplateAction completely.
>
> DependencyInjectedAction, which autowires the Action instance by type, is
> not a bad idea. I don't think that it should be a dedicated class, though,
> so I've removed it as well. If we intend to recommend such an autowiring
> pattern for Struts Actions, we should build it as an option into the
> existing ActionSupport class. However, there's DispatchActionSupport and
> Lookup/MappingDispatchActionSupport as well, so we'd need to duplicate
> quite
> a bit...
>
> Note that we also offer a Delegating Action mechanism, which completely
> defines Struts Actions in a Spring context. Of course, any kind of
> autowiring is available to those instances already. Hence, I'm not sure
> whether we should provide yet another dependency injection for Struts
> Actions out-of-the-box. If we consider this important enough, I won't
> mind,
> but we should strive for integrating this into the existing
> XxxActionSupport
> classes - if at all.
>
> Juergen
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-- 
Keith Donald
Principal Consultant, Interface21
http://www.springframework.com - Spring Services From the Source

[Springframework-developer] Memory consumption using JmsTemplate

[Claus I. <cib...@ya...>]

A person on the forum have a memory leak using the JmsTemplate.

http://forum.springframework.org/viewtopic.php?t=6365

Sorry for posting it here but if there really is a leak it would be nice to be
fixed. And the best persons to look at this is the mighty core developers.

/Claus

Re: [Springframework-developer] Spring binding and validation for Struts

[Mark St G. <stg...@ca...>]

Hi Juergen,

One quick question regarding the reworked Struts Binding support used in
SWF...
Can the Struts binding be used in a non-SWF scenario?  (I assume it could,
since SWF is layer above the actual web framework? )

As we all know, FormBeans are still a pain... I just wanted to confirm if
this is a Spring-value add for a Struts app with DomainObject binding...

Thoughts?
Cheers

Mark



                                                                           
             "Juergen Hoeller"                                             
             <juergen@interfac                                             
             e21.com>                                                   To 
             Sent by:                  <spr...@li... 
             springframework-d         urceforge.net>                      
             eveloper-admin@li                                          cc 
             sts.sourceforge.n                                             
             et                                                    Subject 
                                       [Springframework-developer] Spring  
                                       binding and validation for Struts   
             06/17/2005 03:37                                              
             AM                                                            
                                                                           
                                                                           
             Please respond to                                             
             springframework-d                                             
                 eveloper                                                  
                                                                           
                                                                           




I've now also given a Juergen treatment ;-) to the Spring
binding/validation
adapter for Struts that Keith committed to the main source tree.

For everybody not familiar with this from the Web Flow side of things: The
idea here is to allow for using Spring's DataBinder/Errors mechanism within
a Struts web tier, seamlessly exposing the result to traditional Struts
views (with "html:form", "html:errors", etc).

I've significantly reworked this: In contrast to its original inception
where there've been a special RequestProcessor, a special PlugIn and a
special ActionForm, what's left now is - a single SpringBindingActionForm
adapter. SpringBindingActionForm cares for everything necessary: from
extending Commons BeanUtils to exposing the Spring-managed errors as Struts
ActionMessages.

There is no special RequestProcessor necessary anymore, which I consider as
a must: Too many Struts extensions subclass the RequestProcessor
themselves,
including Tiles and our own Delegating Action mechanism.

The final usage style looks as follows. In "struts-config.xml", a single
ActionForm is defined for all Actions:

<form-beans>
  <form-bean name="actionForm"
type="org.springframework.web.struts.SpringBindingActionForm"/>
</form-beans>

In each Struts Action that wants to use Spring binding/validation for a
plain POJO form object, the following pattern can be used:

public ActionForward execute(ActionMapping actionMapping, ActionForm
actionForm, HttpServletRequest request, HttpServletResponse response)
throws
Exception {
  SpringBindingActionForm form = (SpringBindingActionForm) actionForm;
  MyPojoBean bean = ...;
  ServletRequestDataBinder binder = new ServletRequestDataBinder(bean,
"myPojo");
  binder.bind(request);
  form.expose(binder.getErrors(), request);
  return actionMapping.findForward("success");
}

Keith/Erwin, please give this reworked version a try in Web Flow's Struts
adapter. As far as I can see, it should still work nicely for those needs.

---

Regarding the further Struts support classes added alongside the
binding/validation support:

The TemplateAction class essentially duplicated what our existing
ActionSupport already did, plus a view convenience mirrors of static
utility
methods (which I consider unnecessary - why not access the corresponding
static RequestUtils methods directly). The "preExecute" and "postExecute"
are fine in general, but it's not Spring's business to provide such Struts
stuff that's not related to Spring mechanisms... Hence, I've dropped
TemplateAction completely.

DependencyInjectedAction, which autowires the Action instance by type, is
not a bad idea. I don't think that it should be a dedicated class, though,
so I've removed it as well. If we intend to recommend such an autowiring
pattern for Struts Actions, we should build it as an option into the
existing ActionSupport class. However, there's DispatchActionSupport and
Lookup/MappingDispatchActionSupport as well, so we'd need to duplicate
quite
a bit...

Note that we also offer a Delegating Action mechanism, which completely
defines Struts Actions in a Spring context. Of course, any kind of
autowiring is available to those instances already. Hence, I'm not sure
whether we should provide yet another dependency injection for Struts
Actions out-of-the-box. If we consider this important enough, I won't mind,
but we should strive for integrating this into the existing
XxxActionSupport
classes - if at all.

Juergen



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JdoDialect and detach?

[Marc L. <ma...@lo...>]

Juergen Hoeller wrote:
> We did consider supporting attach/detach hooks as well, but decided not to
> do so, because the exact syntax and behavior of those operations weren't
> clear back then. In contrast to that, almost all JDO 1.0 implementations had
> JDBC Connection exposure and flushing for ages.

I thought that the syntax differences would be the initial motivation to 
write JdoDialect. But i can think of very different approaches of 
detach/attach back then.

> At this point of time, our plan is to not extend JdoDialect any further,
> because JDO 2.0 is just around the corner. Our JdoTemplate and
> DefaultJdoDialect already support the standard JDO 2.0 API, so once you get
> a JDO impl that supports JDO 2.0, that's gonna be immediately available to
> you.

Of course, this is also my thinking, however right now we are in a sad 
situation which i will exaplain below. Right now it would be very nice 
to have a JdoDialect handling this too, then JdoTemplate could use this 
dialect and we would be able to abstract away the differences between 
current detach/attach approaches between vendors. But i agree that this 
would only be a short-time benefit.

> For JDO 2.0 previews such as current Kodo versions, you can always implement
> a JdoCallback and cast the passed-in PersistenceManager to the
> vendor-specific PM interface, calling attach/detach and other JDO 2.0
> preview operations there. This can of course be replaced with straight
> JdoTemplate calls once the particular JDO impl officially supports the
> standard JDO 2.0 API.

Yeah i saw that JdoTemplate allready provides JDO2 public draft style 
attach/detach API (i heard that the JCP-EG might want to change the 
detach API naming for the final spec) but right now i, as a kodo user, 
cant use the convenience methods, because kodo detach API is different 
to the public draft. They said that they wont change to the public JDO2 
draft API spec, because chances are high that it will change ;-)

Of course, implementing an own Callback is possible, you can also create 
a child of JdoTemplate and override the attach/detach methods in there.

All in all its an unhealthy situation in the JDO area, we still dont 
have JDO2 and it seems this will take a while and we have different 
vendors supporting different parts of JDO2, this mixed with unstable 
public draft seems not the ideal situation. All in there we have spring 
trying to cope with that situation ;-)

> 
> As a side note: The pluggable JDBC Connection exposure in JdoDialect can
> still be valuable even with JDO 2.0. For example, you might want to expose
> the native JDBC Connection to JDBC data access code, which could be casted
> to OracleConnection or the like. In this case, you still need
> vendor-specific extraction calls, because standard JDO 2.0 always exposes a
> wrapped handle...

Hmm, yeah you get a handle which you can ask for a java.sql.Connection 
(ok its Object in reality but most implementations will return a JDBC 
connection) in the method getNativeConnection(). There is not much of a 
difference between a properietary vendor call for a JDBC connection and 
the JDO2 one, except for some connection methods which will throw an 
exception like getMetaData() or rollback(). But perhaps i am missing 
something.


-- 
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

[Springframework-developer] Re: Building webflow under spring-projects

[Erwin V. <erw...@er...>]

Okay, I've moved my Eclipse over to use the new spring-projects module.
So I guess we can have the SF people clean up those bogus modules?

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: "Keith Donald" <ke...@in...>; "Erwin Vervaet" 
<erw...@er...>
Cc: <spr...@li...>
Sent: Friday, June 17, 2005 4:44 AM
Subject: Building webflow under spring-projects


> Keith/Erwin,
>
> I moved (copied really) all common-build, spring-binding, and 
> spring-webflow sources to live under a new spring-projects module in CVS.
>
> Note that the build relies on the use of a nightly snapshot of ivy
>   ivy-20050616204129.jar
> which may be found in
>   spring-projects\repository\jayasoft\ivy\jars
> This should be dropped into your ant lib dir to replace the older ivy 1.1. 
> This If you try to use ivy 1.1 you'll get a failure when trying to do a 
> publish of the generated artifact.
>
> -- 
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com
>
>
> 

Re: [Springframework-developer] Retrying transactions with OpenSessionInViewFilter

[Juergen H. <ju...@in...>]

If you intend to retry transactions where Hibernate operations have failed,
it's recommended to either not use OpenSessionInViewFilter in the first
place, or to use it in "deferred close mode" (singleSession=false). The
latter is particularly viable with Hibernate 3, in particular with the
"merge" operation used instead of the classic "saveOrUpdate" (avoiding
conflicts between multiple open Sessions for the same thread).

That said, to the best of my knowledge, Session.clear() is a pretty
aggressive reset of the Session's internal state. Effectively, it's
analogous to opening a new Session in many respects. So even if the
Hibernate team dogmatically says "you need to close the Session on any
HibernateException", that's doesn't seem to be quite true when looking at
the semantics of the "clear" operation. And of course, "clear" perfectly
works for any other exception.

Anyway, I recommend to use OpenSessionInViewFilter's "deferred close mode"
when trying to recover transactions while still relying on lazy loading in
views. Just watch out regarding reassociation of existing persistent objects
with new transactions (i.e. "update"/"saveOrUpdate"), which might cause
"already associated with Session" failures here. Preferably use Hibernate3's
"merge" instead, which I would generally recommend.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Chris Richardson
Sent: Friday, June 17, 2005 1:16 AM
To: spr...@li...
Subject: [Springframework-developer] Retrying transactions with
OpenSessionInViewFilter


Did anyone have any comments the issue I raised in this post:
http://forum.springframework.org/viewtopic.php?t=6311&highlight=

The Hibernate documentation recommends closing the Session after a
HibernateException is thrown. That was also the recommendation of
someone on the Hibernate team:
http://forum.hibernate.org/viewtopic.php?p=2246627#2246627

However, I noticed that HibernateTransactionManager calls
Session.clear() with the intent to reset the Session to a known state
so that it can be reused by another transaction. This seems to be at
odds with the Hibernate documentation unless the goal was to only
reuse a Session when a non-HibernateException was thrown.

Does anyone have any comments on how to retry transactions when using
OpenSessionInViewFilter?


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] enums, styler, comparator

[Juergen H. <ju...@in...>]

I share that view. Making the styling strategies pluggable is nice for
ToStringCreator itself (for creating a custom instance of it through the
overloaded constructor), but I doubt that anyone will want to change the
global default styling strategies.

I've already added a public static DEFAULT_VALUE_STYLER field to
ToStringCreator, exposing the default ValueStyler alongside the default
ToStringStyler. I've also added a further convenience constructor to
ToStringCreator, allowing to specify a specific ValueStyler to use (instead
of specifying the entire ToStringStyler).

So we have shared default instances now, plus the option to specify custom
instances on ToStringCreator or on direct ValueStyler use. The only thing
missing is overriding the global default stylers, which I consider
acceptable. I don't want people to be able to override static global
instances - at any time - in the first place.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Erwin Vervaet
Sent: Friday, June 17, 2005 9:19 AM
To: spr...@li...
Subject: Re: [Springframework-developer] enums, styler, comparator


> Creating objects with new is arguably a bad idea here, as now I've got
> that
> new operator spread around everywhere with no capability to plug in custom
> value styling strategies for my own types of objects, for example.

Agreed, but is making the styling strategies pluggable something users would
ever do in practice? Seems to be a bit of an exotic feature.

>
> On the other hand, with a loader to easily plug-in a custom global
> implementation, users can easily switch on custom string styling
> algorithms
> for types they use but don't have control over without any hassle.  They
> simply switch it in at runtime when their application is bootstrapped.
>
> In any case, what's most appropriate to customize here is the ValueStyler
> strategy, not the ToStringCreator strategy.  It's where the magic for
> pretty
> printing objects of different types happen...
>
> Keith
>
> -----Original Message-----
> From: Keith Donald [mailto:ke...@in...]
> Sent: Thursday, June 16, 2005 6:23 PM
> To: 'spr...@li...'
> Subject: RE: [Springframework-developer] enums, styler, comparator
>
> Yeah, but injection there is not at al practical.  Singleton usage for
> this
> kind of usage is acceptable IMO.  The singleton has a default that is not
> expensive to initialize (its just a POJO with no other dependencies).
> Furthermore, that default is still configurable through a static load
> method.  I don't see the problem there.
>
> Now, I am up for just changing the exception messages in webflow to rely
> on
> the standard collections toString implementations.  However I admit that
> would be a bit of a step back, especially after someone just remarked in a
> training how descriptive and "great looking" that one exception message
> was
> ;-)
>
> Keith
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of
> Juergen Hoeller
> Sent: Thursday, June 16, 2005 2:07 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] enums, styler, comparator
>
> It's been replaced by the ValueStyler interface and DefaultValueStyler
> implementation, in the "core.style" package.
>
> I'm currently discussing with Keith whether a ValueStyler singleton should
> be re-introduced. Currently, the only singleton held is ToStringCreator's
> DefaultToStringStyler, which in turn holds a DefaultValueStyler instance.
>
> I'd like to keep singletons as minimal as possible. There's always the
> option to use "new DefaultValueStyler()" / "new DefaultToStringStyler()"
> or
> even receive a ValueStyler / ToStringStyler through dependency injection.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Colin Sampaleanu
> Sent: Thursday, June 16, 2005 6:02 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] enums, styler, comparator
>
>
> Juergen Hoeller wrote:
>
>>Everybody,
>>
>>Keith's LabeledEnum and ToStringCreator stuff has been moved over from the
>>sandbox, to be shipped with Spring 1.2.2 (and to be used by Web Flow PR4).
>>
>>I've rearranged the structure and also reworked the implementations /
>>interfaces quite a bit. ToStringCreator and its helpers reside in the
>>"core.style" package now; LabeledEnum and LabeledEnumResolver in
>>"core.enums" (without separate support subpackage; it's all in one package
>>name).
>>
>>I've also reworked the generic comparators: they reside in
> "util.comparator"
>>now. The biggest change there is that there is no SortDefinition class
>>anymore. Instead, an InvertibleComparator decorator takes over the same
>>role. SortDefinition already was a Comparator decorator before, so was
>>arguably misnamed.
>>
>>Keith / Erwin, could you please make sure that everything's compiling
>>again
>>on the Web Flow side of things. Once the Web Flow module has found its
> final
>>home in the CVS structure, that is ;-)
>>
>>
>
> What happened to the 'Styler' class?
>
>
http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springf
> ramework/core/Attic/Styler.java?view=markup
> I tried to make the SWF code compile against current Spring CVS while on
> a plane ride back to Toronto yesterday, but Styler seems to be gone. So
> right now the SWF code is still building against a snapshot from June
> 13th.
>
> Colin
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SimpleConnectionHandle

[Marc L. <ma...@lo...>]

Hi,

ok i see. I didnt noticed that releaseConnection() gets called on 
getConnection(). Ok this makes sense and i will have a look at the 
mentioned DataStoreConnectionHandle.

thanks.



Juergen Hoeller wrote:
> The purpose of SimpleConnectionHandle is to hold an existing Connection
> reference. We can't close that reference in "releaseConnection", because
> "releaseConnection" is gonna be called once per "getConnection" call. So if
> the SimpleConnectionHandle will be access multiple times, it's always gonna
> return the same Connection, and we can't close until the original creator of
> the handle (who also supplied the Connection) decides to shut the handle
> down.
> 
> For an alternative implementation of ConnectionHandle, have a look at
> DefaultJdoDialect's DataStoreConnectionHandle: this illustrates how a handle
> can behave that fetches a fresh Connection for every "getConnection" call
> and consequently also closes the Connection for every "releaseConnection"
> call. In that particular, it uses JDO 2.0's Connection "borrowing", where
> the Connection needs to be returned to the PersistenceManager immediately
> after each operation; else the PersistenceManager would complain that we
> didn't return the Connection.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Marc Logemann
> Sent: Thursday, June 16, 2005 10:43 PM
> To: spr...@li...
> Subject: [Springframework-developer] SimpleConnectionHandle
> 
> 
> Hi,
> 
> is there a reason that SimpleConnectionHandle does not supply a default
> releaseConnection implementation?
> 
> I wonder why releaseConnection() cant simply close the Connection it got
> upon creation. Instead people tend to close the connection in
> JDODialect childs in method releaseJdbcConnection() by getting the
> connection from the handle and close it there.


-- 
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

Re: [Springframework-developer] JdoDialect and detach?

[Juergen H. <ju...@in...>]

We did consider supporting attach/detach hooks as well, but decided not to
do so, because the exact syntax and behavior of those operations weren't
clear back then. In contrast to that, almost all JDO 1.0 implementations had
JDBC Connection exposure and flushing for ages.

At this point of time, our plan is to not extend JdoDialect any further,
because JDO 2.0 is just around the corner. Our JdoTemplate and
DefaultJdoDialect already support the standard JDO 2.0 API, so once you get
a JDO impl that supports JDO 2.0, that's gonna be immediately available to
you.

For JDO 2.0 previews such as current Kodo versions, you can always implement
a JdoCallback and cast the passed-in PersistenceManager to the
vendor-specific PM interface, calling attach/detach and other JDO 2.0
preview operations there. This can of course be replaced with straight
JdoTemplate calls once the particular JDO impl officially supports the
standard JDO 2.0 API.

As a side note: The pluggable JDBC Connection exposure in JdoDialect can
still be valuable even with JDO 2.0. For example, you might want to expose
the native JDBC Connection to JDBC data access code, which could be casted
to OracleConnection or the like. In this case, you still need
vendor-specific extraction calls, because standard JDO 2.0 always exposes a
wrapped handle...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Thursday, June 16, 2005 10:56 PM
To: spr...@li...
Subject: [Springframework-developer] JdoDialect and detach?


Hi,

forget something in my last email a few minutes ago. JdoDialect only
handles vendor differences regarding JdbcConnection obtaining, it would
be nice to have the same for attach/detach APIs. This is of course
non-existant when we all have JDO2, but the same goes for the JDBC
connection issue.

Or is this allready handled somewhere else? Have not found something yet.


--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SimpleConnectionHandle

[Juergen H. <ju...@in...>]

The purpose of SimpleConnectionHandle is to hold an existing Connection
reference. We can't close that reference in "releaseConnection", because
"releaseConnection" is gonna be called once per "getConnection" call. So if
the SimpleConnectionHandle will be access multiple times, it's always gonna
return the same Connection, and we can't close until the original creator of
the handle (who also supplied the Connection) decides to shut the handle
down.

For an alternative implementation of ConnectionHandle, have a look at
DefaultJdoDialect's DataStoreConnectionHandle: this illustrates how a handle
can behave that fetches a fresh Connection for every "getConnection" call
and consequently also closes the Connection for every "releaseConnection"
call. In that particular, it uses JDO 2.0's Connection "borrowing", where
the Connection needs to be returned to the PersistenceManager immediately
after each operation; else the PersistenceManager would complain that we
didn't return the Connection.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Thursday, June 16, 2005 10:43 PM
To: spr...@li...
Subject: [Springframework-developer] SimpleConnectionHandle


Hi,

is there a reason that SimpleConnectionHandle does not supply a default
releaseConnection implementation?

I wonder why releaseConnection() cant simply close the Connection it got
upon creation. Instead people tend to close the connection in
JDODialect childs in method releaseJdbcConnection() by getting the
connection from the handle and close it there.

--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring binding and validation for Struts

[Juergen H. <ju...@in...>]

I've now also given a Juergen treatment ;-) to the Spring binding/validation
adapter for Struts that Keith committed to the main source tree.

For everybody not familiar with this from the Web Flow side of things: The
idea here is to allow for using Spring's DataBinder/Errors mechanism within
a Struts web tier, seamlessly exposing the result to traditional Struts
views (with "html:form", "html:errors", etc).

I've significantly reworked this: In contrast to its original inception
where there've been a special RequestProcessor, a special PlugIn and a
special ActionForm, what's left now is - a single SpringBindingActionForm
adapter. SpringBindingActionForm cares for everything necessary: from
extending Commons BeanUtils to exposing the Spring-managed errors as Struts
ActionMessages.

There is no special RequestProcessor necessary anymore, which I consider as
a must: Too many Struts extensions subclass the RequestProcessor themselves,
including Tiles and our own Delegating Action mechanism.

The final usage style looks as follows. In "struts-config.xml", a single
ActionForm is defined for all Actions:

<form-beans>
  <form-bean name="actionForm"
type="org.springframework.web.struts.SpringBindingActionForm"/>
</form-beans>

In each Struts Action that wants to use Spring binding/validation for a
plain POJO form object, the following pattern can be used:

public ActionForward execute(ActionMapping actionMapping, ActionForm
actionForm, HttpServletRequest request, HttpServletResponse response) throws
Exception {
  SpringBindingActionForm form = (SpringBindingActionForm) actionForm;
  MyPojoBean bean = ...;
  ServletRequestDataBinder binder = new ServletRequestDataBinder(bean,
"myPojo");
  binder.bind(request);
  form.expose(binder.getErrors(), request);
  return actionMapping.findForward("success");
}

Keith/Erwin, please give this reworked version a try in Web Flow's Struts
adapter. As far as I can see, it should still work nicely for those needs.

---

Regarding the further Struts support classes added alongside the
binding/validation support:

The TemplateAction class essentially duplicated what our existing
ActionSupport already did, plus a view convenience mirrors of static utility
methods (which I consider unnecessary - why not access the corresponding
static RequestUtils methods directly). The "preExecute" and "postExecute"
are fine in general, but it's not Spring's business to provide such Struts
stuff that's not related to Spring mechanisms... Hence, I've dropped
TemplateAction completely.

DependencyInjectedAction, which autowires the Action instance by type, is
not a bad idea. I don't think that it should be a dedicated class, though,
so I've removed it as well. If we intend to recommend such an autowiring
pattern for Struts Actions, we should build it as an option into the
existing ActionSupport class. However, there's DispatchActionSupport and
Lookup/MappingDispatchActionSupport as well, so we'd need to duplicate quite
a bit...

Note that we also offer a Delegating Action mechanism, which completely
defines Struts Actions in a Spring context. Of course, any kind of
autowiring is available to those instances already. Hence, I'm not sure
whether we should provide yet another dependency injection for Struts
Actions out-of-the-box. If we consider this important enough, I won't mind,
but we should strive for integrating this into the existing XxxActionSupport
classes - if at all.

Juergen

Re: [Springframework-developer] enums, styler, comparator

[Erwin V. <erw...@er...>]

> Creating objects with new is arguably a bad idea here, as now I've got 
> that
> new operator spread around everywhere with no capability to plug in custom
> value styling strategies for my own types of objects, for example.

Agreed, but is making the styling strategies pluggable something users would 
ever do in practice? Seems to be a bit of an exotic feature.

>
> On the other hand, with a loader to easily plug-in a custom global
> implementation, users can easily switch on custom string styling 
> algorithms
> for types they use but don't have control over without any hassle.  They
> simply switch it in at runtime when their application is bootstrapped.
>
> In any case, what's most appropriate to customize here is the ValueStyler
> strategy, not the ToStringCreator strategy.  It's where the magic for 
> pretty
> printing objects of different types happen...
>
> Keith
>
> -----Original Message-----
> From: Keith Donald [mailto:ke...@in...]
> Sent: Thursday, June 16, 2005 6:23 PM
> To: 'spr...@li...'
> Subject: RE: [Springframework-developer] enums, styler, comparator
>
> Yeah, but injection there is not at al practical.  Singleton usage for 
> this
> kind of usage is acceptable IMO.  The singleton has a default that is not
> expensive to initialize (its just a POJO with no other dependencies).
> Furthermore, that default is still configurable through a static load
> method.  I don't see the problem there.
>
> Now, I am up for just changing the exception messages in webflow to rely 
> on
> the standard collections toString implementations.  However I admit that
> would be a bit of a step back, especially after someone just remarked in a
> training how descriptive and "great looking" that one exception message 
> was
> ;-)
>
> Keith
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf 
> Of
> Juergen Hoeller
> Sent: Thursday, June 16, 2005 2:07 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] enums, styler, comparator
>
> It's been replaced by the ValueStyler interface and DefaultValueStyler
> implementation, in the "core.style" package.
>
> I'm currently discussing with Keith whether a ValueStyler singleton should
> be re-introduced. Currently, the only singleton held is ToStringCreator's
> DefaultToStringStyler, which in turn holds a DefaultValueStyler instance.
>
> I'd like to keep singletons as minimal as possible. There's always the
> option to use "new DefaultValueStyler()" / "new DefaultToStringStyler()" 
> or
> even receive a ValueStyler / ToStringStyler through dependency injection.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Colin Sampaleanu
> Sent: Thursday, June 16, 2005 6:02 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] enums, styler, comparator
>
>
> Juergen Hoeller wrote:
>
>>Everybody,
>>
>>Keith's LabeledEnum and ToStringCreator stuff has been moved over from the
>>sandbox, to be shipped with Spring 1.2.2 (and to be used by Web Flow PR4).
>>
>>I've rearranged the structure and also reworked the implementations /
>>interfaces quite a bit. ToStringCreator and its helpers reside in the
>>"core.style" package now; LabeledEnum and LabeledEnumResolver in
>>"core.enums" (without separate support subpackage; it's all in one package
>>name).
>>
>>I've also reworked the generic comparators: they reside in
> "util.comparator"
>>now. The biggest change there is that there is no SortDefinition class
>>anymore. Instead, an InvertibleComparator decorator takes over the same
>>role. SortDefinition already was a Comparator decorator before, so was
>>arguably misnamed.
>>
>>Keith / Erwin, could you please make sure that everything's compiling 
>>again
>>on the Web Flow side of things. Once the Web Flow module has found its
> final
>>home in the CVS structure, that is ;-)
>>
>>
>
> What happened to the 'Styler' class?
>
> http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springf
> ramework/core/Attic/Styler.java?view=markup
> I tried to make the SWF code compile against current Spring CVS while on
> a plane ride back to Toronto yesterday, but Styler seems to be gone. So
> right now the SWF code is still building against a snapshot from June 
> 13th.
>
> Colin
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> 

RE: [Springframework-developer] Annotation to validate required bean attributes

[Magnus H. <ma...@fi...>]

 

> I like the ideas of attributes to help the container perform 
> some of my work for me.  That is, I'm already asking the 
> container to inject my dependencies.  It's logical (to me) to 
> also ask the container to let me know if I've misconfigured 
> the dependencies somehow.

This is the main reason why I want this too. Spring reminds me if I try to
inject something that doesn't have a setter, I want it to tell me when I
forget to inject something too.

I don't want to pollute afterPropertiesSet with these kind of things. And
even if I did, I probably would forget to add checks for some attributes at
some point. It's more easy to remember to add something at the source, with
an annotation imho.

> You bring up good points.  I don't think the annotations 
> method is perfect for all cases, but I do think it handles 

I agree. One size does not fit all.

Things like this would fit nice in a Spring Wiki Cookbook though...

/Magnus