springframework-developer — Spring Framework developers list

Re: [Springframework-developer] OpenSessionInViewFilter

[Les A. H. <le...@ha...>]

It is not recommended to implement this type of behavior in a Hibernate
application.  An application-transaction is scoped to a few connected
request/response cycles and shouldn't be used across a user's entire
interaction with the system - doing otherwise creates much greater
conflict for stale data and versioning conflicts. 

On Sun, 20 Nov 2005 20:29:21 -0500, "Artem Ploujnikov"
<bla...@ca...> said:
>   Some Web application frameworks like JSF might require you to extend
>   the
> lifetime of a persistent entity beyond a single HTTP request. What I am
> proposing is an alternative implementation of OpenSessionInViewFilter
> that
> opens one Hibernate session per HTTP session instead of one session per
> request. JDBC connection management should not be a problem because it is
> possible to disconnect and reconnect Hibernate sessions without closing
> them.
> 
> Here is the filter that I'm using in my application... I think it would
> be a
> good idea to include something similar in a future release of Spring.
> Please
> note that it hasn't been well tested, and it requires a session filter
> that
> closes orphaned sessions.
> 
> public class HibernateSessionFilter extends OncePerRequestFilter {
>  public static final String DEFAULT_SESSION_FACTORY_BEAN_NAME =
> "sessionFactory";
>  public static final String SESSION_KEY = "org.foo.web.hibernateSession";
> 
>  private String sessionFactoryBeanName =
>  DEFAULT_SESSION_FACTORY_BEAN_NAME;
> 
>  /**
>   * @return Returns the sessionFactoryBeanName.
>   */
>  protected String getSessionFactoryBeanName() {
>   return sessionFactoryBeanName;
>  }
> 
> 
>  /**
>   * @param sessionFactoryBeanName The sessionFactoryBeanName to set.
>   */
>  public void setSessionFactoryBeanName(String sessionFactoryBeanName) {
>   this.sessionFactoryBeanName = sessionFactoryBeanName;
>  }
> 
> 
>  protected SessionFactory lookupSessionFactory() {
>   if (logger.isDebugEnabled()) {
>    logger.debug("Using SessionFactory '" + getSessionFactoryBeanName() +
>    "'
> for OpenSessionInViewFilter");
>   }
>   WebApplicationContext wac =
>     WebApplicationContextUtils.getRequiredWebApplicationContext(getServletContext());
>   return (SessionFactory) wac.getBean(getSessionFactoryBeanName(),
> SessionFactory.class);
>  }
> 
>  protected void doFilterInternal(
>    HttpServletRequest request, HttpServletResponse response, FilterChain
> filterChain)
>    throws ServletException, IOException {
>   SessionFactory sessionFactory = lookupSessionFactory();
>   HttpSession httpSession = request.getSession();
>   Session session =
>    (Session) httpSession.getAttribute(SESSION_KEY);
>   if (session == null) {
>    session = sessionFactory.openSession();
>    httpSession.setAttribute(SESSION_KEY, session);
>   }
>                 if (!session.isConnected()) {
>                     session.reconnect();
>                 }
>   TransactionSynchronizationManager.bindResource(sessionFactory, new
> SessionHolder(session));
>   try {
>    filterChain.doFilter(request, response);
>   } finally {
>    TransactionSynchronizationManager.unbindResource(sessionFactory);
>                         session.disconnect();
>   }
> 
>  }
> 
> }
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] OpenSessionInViewFilter

[Artem P. <bla...@ca...>]

  Some Web application frameworks like JSF might require you to extend the
lifetime of a persistent entity beyond a single HTTP request. What I am
proposing is an alternative implementation of OpenSessionInViewFilter that
opens one Hibernate session per HTTP session instead of one session per
request. JDBC connection management should not be a problem because it is
possible to disconnect and reconnect Hibernate sessions without closing
them.

Here is the filter that I'm using in my application... I think it would be a
good idea to include something similar in a future release of Spring. Please
note that it hasn't been well tested, and it requires a session filter that
closes orphaned sessions.

public class HibernateSessionFilter extends OncePerRequestFilter {
 public static final String DEFAULT_SESSION_FACTORY_BEAN_NAME =
"sessionFactory";
 public static final String SESSION_KEY = "org.foo.web.hibernateSession";

 private String sessionFactoryBeanName = DEFAULT_SESSION_FACTORY_BEAN_NAME;

 /**
  * @return Returns the sessionFactoryBeanName.
  */
 protected String getSessionFactoryBeanName() {
  return sessionFactoryBeanName;
 }


 /**
  * @param sessionFactoryBeanName The sessionFactoryBeanName to set.
  */
 public void setSessionFactoryBeanName(String sessionFactoryBeanName) {
  this.sessionFactoryBeanName = sessionFactoryBeanName;
 }


 protected SessionFactory lookupSessionFactory() {
  if (logger.isDebugEnabled()) {
   logger.debug("Using SessionFactory '" + getSessionFactoryBeanName() + "'
for OpenSessionInViewFilter");
  }
  WebApplicationContext wac =
    WebApplicationContextUtils.getRequiredWebApplicationContext(getServletContext());
  return (SessionFactory) wac.getBean(getSessionFactoryBeanName(),
SessionFactory.class);
 }

 protected void doFilterInternal(
   HttpServletRequest request, HttpServletResponse response, FilterChain
filterChain)
   throws ServletException, IOException {
  SessionFactory sessionFactory = lookupSessionFactory();
  HttpSession httpSession = request.getSession();
  Session session =
   (Session) httpSession.getAttribute(SESSION_KEY);
  if (session == null) {
   session = sessionFactory.openSession();
   httpSession.setAttribute(SESSION_KEY, session);
  }
                if (!session.isConnected()) {
                    session.reconnect();
                }
  TransactionSynchronizationManager.bindResource(sessionFactory, new
SessionHolder(session));
  try {
   filterChain.doFilter(request, response);
  } finally {
   TransactionSynchronizationManager.unbindResource(sessionFactory);
                        session.disconnect();
  }

 }

}

[Springframework-developer] spring build.377 Build Successful

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

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

[Springframework-developer] About WebSphere 6.0 JMS Listener asynchronously (urgent)

[<j2e...@ya...>]

TXkgZGVhciBTcHJpbmcgQ29tbXVuaXR5LCANCg0KQXMgZmFyIGFzIEkga25vdywgU3ByaW5nIDEu
MyB3aWxsIHByb3ZpZGUgSk1TIExpc3RlbmVyIHN1cHBvcnQgYXN5bmNocm9ub3VzbHkuDQoNCkJ1
dCBpbiBXZWJTcGhlcmUgNi4wIFdlYiBDb250YWluZXIsIHRoaXMgaXNuJ3QgcG9zc2libGUgZm9y
IHRoZSBmb2xsb3dpbmcgcmVhc29uLg0KDQpDYW4ndCBVc2UgTWVzc2FnZUxpc3RlbmVycyBpbiBK
MkVFDQoNCnBvc3RlZCBieSBCb2JieSBXb29sZiANClBlcm1hbGluayANCg0KSGVyZSdzIGFuIGlu
dGVyZXN0aW5nIGNvbmZsaWN0IGJldHdlZW4gSk1TIGFuZCBKMkVFIHRoYXQgSSBqdXN0IHJlZGlz
Y292ZXJlZDoNCg0KWW91IGNhbid0IHJ1biBhbiBpbXBsZW1lbnRvciBvZiBNZXNzYWdlTGlzdGVu
ZXIgaW4gYSBKMkVFIGNvbnRhaW5lci4gSjJFRSAxLjMgc2F5cyBub3QgdG8gZG8gaXQgaW4gdGhl
IEVKQiBjb250YWluZXIuIEoyRUUgMS40IHNheXMgbm90IHRvIGRvIGl0IGluIHRoZSBXZWIgY29u
dGFpbmVyIGVpdGhlci4gQmFzaWNhbGx5LCB5b3UgY2FuJ3QgdXNlIGl0IGluIGFueSBjb250YWlu
ZXIgdGhhdCBjb250cm9scyB0aHJlYWQgY3JlYXRpb24sIHdoaWNoIGlzIGFueSBjb250YWluZXIg
ZXhjZXB0IGFuIGFwcGxpY2F0aW9uIGNsaWVudCBjb250YWluZXIuDQoNCldBUyA1IGFuZCA2IGRv
bid0IGFsbG93IE1lc3NhZ2VMaXN0ZW5lcnMgdG8gYmUgdXNlZCBpbiBlaXRoZXIgY29udGFpbmVy
LiBXaGVuIHlvdSB0cnksIHlvdSBnZXQgYW4gZXJyb3IgbGlrZSB0aGlzOg0KDQoNCg0KICBqYXZh
eC5qbXMuSWxsZWdhbFN0YXRlRXhjZXB0aW9uOiBNZXRob2Qgc2V0TWVzc2FnZUxpc3RlbmVyIG5v
dCBwZXJtaXR0ZWQNCiAgYXQgY29tLmlibS5lanMuam1zLkpNU0NNVXRpbHMubWV0aG9kTm90UGVy
bWl0dGVkRXhjZXB0aW9uKEpNU0NNVXRpbHMuamF2YToyMDIpDQogIGF0IGNvbS5pYm0uZWpzLmpt
cy5KTVNNZXNzYWdlQ29uc3VtZXJIYW5kbGUuc2V0TWVzc2FnZUxpc3RlbmVyKEpNU01lc3NhZ2VD
b25zdW1lckhhbmRsZS5qYXZhOjE5MykNCiAgYXQgTXlNZXNzYWdlTGlzdGVuZXJJbXBsLmNvbm5l
Y3QoTXlNZXNzYWdlTGlzdGVuZXJJbXBsLmphdmE6MzkpDQogIC4gLiAuDQoNCg0KU28gV0FTIGRv
ZXNuJ3QgYWN0dWFsbHkgcHJldmVudCB5b3UgZnJvbSBkZXBsb3lpbmcgYSBjbGFzcyB0aGF0IGlt
cGxlbWVudHMgTWVzc2FnZUxpc3RlbmVyLCBidXQgd2hlbiB5b3UgdHJ5IHRvIHJ1biB5b3VyIGNv
ZGUsIFdBUyBwcmV2ZW50cyB0aGUgTWVzc2FnZUNvbnN1bWVyLnNldE1lc3NhZ2VMaXN0ZW5lcihN
ZXNzYWdlTGlzdGVuZXIpIG1ldGhvZCBmcm9tIHJ1bm5pbmcgYnkgdGhyb3dpbmcgYW4gSWxsZWdh
bFN0YXRlRXhjZXB0aW9uLiBGb3IgZGV0YWlscywgc2VlIElCTSBXTVEgRkFRIGFuc3dlciAjOTIg
YW5kIElCTSBUZWNobm90ZSAjMTExNDIzOS4NCg0KU28gd2hlbiB5b3UgZ2V0IHRoaXMgZXJyb3Is
IHRoZSBwcm9ibGVtIGlzbid0IGEgYnVnIGluIHlvdXIgY29kZSwgaXQncyB5b3VyIGVudGlyZSBh
cHByb2FjaC4gSW4gYSBudXRzaGVsbCwgaWYgeW91IHdhbnQgdG8gcnVuIGEgTWVzc2FnZUxpc3Rl
bmVyIGluIEoyRUUsIGRvbid0IGltcGxlbWVudCBhIE1lc3NhZ2VMaXN0ZW5lciwgaW1wbGVtZW50
IGEgKGNhbiB5b3UgZ3Vlc3M/KSBtZXNzc2FnZS1kcml2ZW4gYmVhbiAodGhlIEpNUyBraW5kLCB3
aGljaCBpbXBsZW1lbnRzIE1lc3NhZ2VMaXN0ZW5lcikuIEFuZCBpZiB5b3UgZG9uJ3QgbGlrZSB1
c2luZyBFSkJzPyBHZXQgdXNlZCB0byBpdC4gTURCcyB3b3JrIGluIEoyRUU7IE1lc3NhZ2VMaXN0
ZW5lcnMgZG9uJ3QuDQoNCihmcm9tIEJvYmJ5IFdvb2xmIEJsb2cpDQoNCmh0dHA6Ly93d3ctMTI4
LmlibS5jb20vZGV2ZWxvcGVyd29ya3MvYmxvZ3MvZHdfYmxvZ19jb21tZW50cy5qc3BhP2Jsb2c9
MzkyJmVudHJ5PTcxODYxDQoNCkJlY2F1c2UgbXkgY3VycmVudCBwcm9qZWN0IG1heSB1c2UgV2Vi
U3BoZXJlIDYuMCxhbmQgaXQgbXVzdCBsaXN0ZW5lciBtZXNzYWdlcyBmcm9tIFdlYiBDb250YWlu
ZXIgYXN5bmNocm9ub3VzbHksIFNvIHRoZSANCmFuc3dlciBpcyB1cmdlbnQgdG8gbWUuIEJ5IHRo
ZSB3YXksIHdlIGhhdmUgbm90IHVzZSBNREIgdG8gbGlzdGVuZXIgbWVzc2FnZXMuDQoNCkRvIFNw
cmluZyAxLjMgcGxhbiBwcm92aWRpbmcgd29ya2Fyb3VuZCBmb3IgdGhpcyBvciBzb21lIG90aGVy
IHNvbHV0aW9ucz8NCg0KdGh4Lg0KDQrC3sqxt8kNCg0KSmF2YSBFRSBBcmNoaXRlY3QNCg0KaHR0
cDovL3d3dy5vcGVuLXYuY29tDQoNCteo16LT2kphdmEgRUXGvcyooaLD9L3dt723qLywT3BlbiBT
b3VyY2W8vMr118nRrw0KDQpFX21haWw6IGoyZWViZWFuc0B5YWhvby5jb20uY24gu/IgamF2YWVl
QG9wZW4tdi5jb20NCg0KwarPtbXnu7CjuigwKTEzOTI0MjA3OTc4

[Springframework-developer] Spring IntelliBean(tm) support

[Alef A. <ale...@in...>]

All,

Arjen and I have just added IntelliBean(tm) support to Spring!

Error messages resulting from typos in XML files will now be accompanied 
with suggestions. Some examples:

class Person {

   public setName(String name);
   public setMyString(String string);
   public setMyStrings(String string);
}

<bean class="Person">
   <property name="names" value="John"/>
</bean>

--> exception message: Invalid property 'names' ..... Did you mean 'name'?

<bean class="Person">
   <!-- notice the lowercase mystring property -->
   <property name="mystring" value="blah"/>
</bean>

--> exception message: Invalid property 'mystring' ..... Did you mean 
'myString' or 'myStrings'?

Juergen, there's a findPossibleAlternatives() method in the 
BeanWrapperImpl and we've added an additional constructor to the 
NotWritablePropertyException taking a String[] containing possible 
alternatives. A corresponding message is generated at construction time. 
I could only find one place to generate possible alternatives in the 
BeanWrapperImpl (in the setPropertyValue() method).

There might be some possible optimizations in the Levenshtein algorithms 
(using a three-dimensional array instead of a two-dimensional one two 
prevent the algorithm from being executed once for every property), but 
since the generation of alternatives is only done when throwing an 
exception anyway, that's not a big deal I guess for now.

Comments welcome!

regards,
Alef

p.s. modifications in BeanWrapperImpl, BeanWrapperTests, 
NotWriteablePropertyException

[Springframework-developer] spring build.376 Build Successful

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

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

Re: [Springframework-developer] New JDBC functionality for 1.3

[Thomas R. <tho...@tr...>]

Alef,

We already have two APIs - JdbcTemplate and the classes in the  
"object" package.  The new SqlCommand would more ore less replace the  
"object" classes.  As for the .NET version of the SqlCommand - I'm  
not a .NET expert and I haven't really used this class in any real  
app, but I thought the basic idea and API was pretty clean and looked  
easy to grasp and use..

I'm starting to lean more towards Juergens idea of having the named  
parameter support separate from the JdbcTemplate and apply the  
transformation to positional parameters done in the command layer.   
That way we could specify the SqlType information directly on the  
command object rather than with the parameters passed in.

Thomas


On Nov 19, 2005, at 5:12 PM, Alef Arendsen wrote:

> Isn't this just like introducing a 'lite' version of the  
> JdbcTemplate (without exposing the actual template pattern) in  
> order to keep things clean and simple for users? I agree there's a  
> lot of methods on the JdbcTemplate, but every time I take about 5  
> minutes to explain the interface, users seem to grasp the API quite  
> quickly... If the SqlCommand were around already I had to explain  
> users two classes to interact instead of one.
>
> About the SqlCommand class (it's a class), I don't exactly call  
> this a nice and clean interface by the way, isn't it specific to  
> SQLServer?? :-).
>
> regards,
> Alef
>
> Juergen Hoeller wrote:
>> Thomas,
>> Looks interesting! Isn't this quite similar to our current  
>> operation objects
>> in the "jdbc.object" package, just more generic? A SqlCommand  
>> instance seems
>> to be thread-safe, parameters passed in through execute calls...
>> In any case, I do see your point: I guess it's worth keeping the  
>> named
>> parameter support restricted to such a command class, not in  
>> JdbcTemplate
>> itself. If that command class is close enough to the existing  
>> operation
>> objects in style, we could also put it into the "jdbc.object" package
>> directly...
>> Juergen
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On  
>> Behalf Of
>> Thomas Risberg
>> Sent: Saturday, November 19, 2005 5:50 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] New JDBC functionality for 1.3
>> I was talking to Mark last weekend about data access for  
>> Spring.NET and we
>> discussed the .NET class SqlCommand that provides a nice and clean  
>> interface
>> to the ADO.NET functionality.  It got me thinking, and after  
>> adding the
>> support for named parameters, I counted over 75 different methods for
>> interfacing with the JdbcTemplate - that's a lot :)
>> So, I started looking at providing a SqlCommand interface on top of
>> JdbcTemplate to just present the most used features and limit the  
>> sometimes
>> bewildering number of options for how to pass in the parameters  
>> etc.  I
>> decided to only support the new named parameter support.  The old  
>> position
>> based array style is still available from the JdbcTemplate  
>> directly.  I
>> added a new class org.springframework.jdbc.command.SqlCommand to the
>> sandbox.  It's  simply a number of one-line wrappers on top of the  
>> JdbcTemplate.   Combined with the new named parameter support, it  
>> provides a simpler
>> interface IMHO.
>> Here are a few examples:
>>          SqlCommand listOfBeersCommand = new SqlCommand("select  
>> id, brand,
>> price from beers", dataSource);
>>          List beerList = listOfBeersCommand.executeQuery(new
>> BeerMapper());
>>          SqlCommand priceCommand = new SqlCommand("select price  
>> from beers
>> where brand = :brand", dataSource);
>>          Map parameters = new HashMap();
>>          parameters.put("brand", "Heineken");
>>          Number price = (Number)priceCommand.executeScalar 
>> (parameters);
>> Also, with the new option of passing in a JavaBean as the holder  
>> of the
>> parameter values (SqlParameterBeanWrapper) it does provide the  
>> option of
>> using the following code:
>>          SqlCommand readCommand = new SqlCommand("select id,  
>> brand, price
>> from beers where id = :id", dataSource);
>>          SqlCommand saveCommand = new SqlCommand("update beers set  
>> brand =
>> :brand, price = :price where id = :id", dataSource);
>>          Map parameters = new HashMap();
>>          parameters.put("id", new Long(2));
>>          Beer beer = (Beer)readCommand.executeObject(new  
>> BeerMapper (),
>> parameters);
>>          beer.setPrice(new BigDecimal("49.87"));
>>          SqlNamedParameters updateValues = new  
>> SqlParameterBeanWrapper
>> (beer);
>>          int updateCount = saveCommand.executeUpdate(updateValues);
>> All this is in CVS now (SqlCommand is in the sandbox) and if you  
>> have any
>> feedback, I'm all ears.
>> Thomas
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
>> Register for a JBoss Training Course.  Free Certification Exam for  
>> All
>> Training Attendees Through End of 2005. For more info visit:
>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>> developer
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
>> Register for a JBoss Training Course.  Free Certification Exam
>> for All Training Attendees Through End of 2005. For more info visit:
>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>> developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Re: [Springframework-developer] New JDBC functionality for 1.3

[Alef A. <ale...@in...>]

Isn't this just like introducing a 'lite' version of the JdbcTemplate 
(without exposing the actual template pattern) in order to keep things 
clean and simple for users? I agree there's a lot of methods on the 
JdbcTemplate, but every time I take about 5 minutes to explain the 
interface, users seem to grasp the API quite quickly... If the 
SqlCommand were around already I had to explain users two classes to 
interact instead of one.

About the SqlCommand class (it's a class), I don't exactly call this a 
nice and clean interface by the way, isn't it specific to SQLServer?? :-).

regards,
Alef

Juergen Hoeller wrote:
> Thomas,
> 
> Looks interesting! Isn't this quite similar to our current operation objects
> in the "jdbc.object" package, just more generic? A SqlCommand instance seems
> to be thread-safe, parameters passed in through execute calls...
> 
> In any case, I do see your point: I guess it's worth keeping the named
> parameter support restricted to such a command class, not in JdbcTemplate
> itself. If that command class is close enough to the existing operation
> objects in style, we could also put it into the "jdbc.object" package
> directly...
> 
> Juergen
>  
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Thomas Risberg
> Sent: Saturday, November 19, 2005 5:50 PM
> To: spr...@li...
> Subject: [Springframework-developer] New JDBC functionality for 1.3
> 
> I was talking to Mark last weekend about data access for Spring.NET and we
> discussed the .NET class SqlCommand that provides a nice and clean interface
> to the ADO.NET functionality.  It got me thinking, and after adding the
> support for named parameters, I counted over 75 different methods for
> interfacing with the JdbcTemplate - that's a lot :)
> 
> So, I started looking at providing a SqlCommand interface on top of
> JdbcTemplate to just present the most used features and limit the sometimes
> bewildering number of options for how to pass in the parameters etc.  I
> decided to only support the new named parameter support.  The old position
> based array style is still available from the JdbcTemplate directly.  I
> added a new class org.springframework.jdbc.command.SqlCommand to the
> sandbox.  It's  
> simply a number of one-line wrappers on top of the JdbcTemplate.   
> Combined with the new named parameter support, it provides a simpler
> interface IMHO.
> 
> Here are a few examples:
> 
>          SqlCommand listOfBeersCommand = new SqlCommand("select id, brand,
> price from beers", dataSource);
>          List beerList = listOfBeersCommand.executeQuery(new
> BeerMapper());
> 
>          SqlCommand priceCommand = new SqlCommand("select price from beers
> where brand = :brand", dataSource);
>          Map parameters = new HashMap();
>          parameters.put("brand", "Heineken");
>          Number price = (Number)priceCommand.executeScalar(parameters);
> 
> Also, with the new option of passing in a JavaBean as the holder of the
> parameter values (SqlParameterBeanWrapper) it does provide the option of
> using the following code:
> 
>          SqlCommand readCommand = new SqlCommand("select id, brand, price
> from beers where id = :id", dataSource);
>          SqlCommand saveCommand = new SqlCommand("update beers set brand =
> :brand, price = :price where id = :id", dataSource);
> 
>          Map parameters = new HashMap();
>          parameters.put("id", new Long(2));
>          Beer beer = (Beer)readCommand.executeObject(new BeerMapper (),
> parameters);
> 
>          beer.setPrice(new BigDecimal("49.87"));
> 
>          SqlNamedParameters updateValues = new SqlParameterBeanWrapper
> (beer);
>          int updateCount = saveCommand.executeUpdate(updateValues);
> 
> All this is in CVS now (SqlCommand is in the sandbox) and if you have any
> feedback, I'm all ears.
> 
> Thomas
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam for All
> Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] New JDBC functionality for 1.3

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

Thomas,

I'm wondering whether the named parameter support is really a candidate for
JdbcTemplate itself, due to the latter's one-line operation style that
doesn't really fit the named parameter building so well. And as you
indicated, JdbcTemplate has so many overloaded methods already...

I rather see the named parameter support as a thin level above JdbcTemplate,
with an API explicitly dedicated to named parameter handling. A command or
builder style API seems to be a good match here.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Saturday, November 19, 2005 8:19 PM
To: spr...@li...
Subject: Re: [Springframework-developer] New JDBC functionality for 1.3

Juergen,

For the moment the named parameter support is part of the JdbcTemplate, but
we could move it to the SqlCommand class.  That would eliminate 11 methods
from the JdbcTemplate.  Another question is if we provide the option of
supporting named parameters in the classes that are part of the "object"
package.  They already support naming the parameters in the parameter
declaration but we could add support for using the name instead of the
placeholder '?' in the sql itself.  This would eliminate the need for
specifying the parameters in the correct order since we could associate them
by name.

If we add the SqlCommand then I would consider the "object" package more or
less deprecated and the new "command" style would be the way to go for the
future.  We could provide SqlBatchCommand and SqlCallableCommand to provide
everything that is currently provided in the "object" package.

The batch support needs some work anyway.  We are currently building up all
the parameter values internally and then calling addBatch on the jdbc
prepared statement which in turn build some memory structure  
to hold the parameters before the entire batch is executed later.   
This leads to some additional memory and cpu usage which is a problem
dealing with large batches.

Thomas

On Nov 19, 2005, at 12:02 PM, Juergen Hoeller wrote:

> Thomas,
>
> Looks interesting! Isn't this quite similar to our current operation 
> objects in the "jdbc.object" package, just more generic? A SqlCommand 
> instance seems to be thread-safe, parameters passed in through execute 
> calls...
>
> In any case, I do see your point: I guess it's worth keeping the named 
> parameter support restricted to such a command class, not in 
> JdbcTemplate itself. If that command class is close enough to the 
> existing operation objects in style, we could also put it into the 
> "jdbc.object" package directly...
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of Thomas Risberg
> Sent: Saturday, November 19, 2005 5:50 PM
> To: spr...@li...
> Subject: [Springframework-developer] New JDBC functionality for 1.3
>
> I was talking to Mark last weekend about data access for Spring.NET 
> and we discussed the .NET class SqlCommand that provides a nice and 
> clean interface to the ADO.NET functionality.  It got me thinking, and 
> after adding the support for named parameters, I counted over 75 
> different methods for interfacing with the JdbcTemplate - that's a lot 
> :)
>
> So, I started looking at providing a SqlCommand interface on top of 
> JdbcTemplate to just present the most used features and limit the 
> sometimes bewildering number of options for how to pass in the 
> parameters etc.  I decided to only support the new named parameter 
> support.  The old position based array style is still available from 
> the JdbcTemplate directly.  I added a new class 
> org.springframework.jdbc.command.SqlCommand to the sandbox.  It's 
> simply a number of one-line wrappers on top of the JdbcTemplate.
> Combined with the new named parameter support, it provides a simpler 
> interface IMHO.
>
> Here are a few examples:
>
>          SqlCommand listOfBeersCommand = new SqlCommand("select id, 
> brand, price from beers", dataSource);
>          List beerList = listOfBeersCommand.executeQuery(new
> BeerMapper());
>
>          SqlCommand priceCommand = new SqlCommand("select price from 
> beers where brand = :brand", dataSource);
>          Map parameters = new HashMap();
>          parameters.put("brand", "Heineken");
>          Number price = (Number)priceCommand.executeScalar
> (parameters);
>
> Also, with the new option of passing in a JavaBean as the holder of 
> the parameter values (SqlParameterBeanWrapper) it does provide the 
> option of using the following code:
>
>          SqlCommand readCommand = new SqlCommand("select id, brand, 
> price from beers where id = :id", dataSource);
>          SqlCommand saveCommand = new SqlCommand("update beers set 
> brand = :brand, price = :price where id = :id", dataSource);
>
>          Map parameters = new HashMap();
>          parameters.put("id", new Long(2));
>          Beer beer = (Beer)readCommand.executeObject(new BeerMapper 
> (), parameters);
>
>          beer.setPrice(new BigDecimal("49.87"));
>
>          SqlNamedParameters updateValues = new SqlParameterBeanWrapper 
> (beer);
>          int updateCount = saveCommand.executeUpdate(updateValues);
>
> All this is in CVS now (SqlCommand is in the sandbox) and if you have 
> any feedback, I'm all ears.
>
> Thomas
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today 
> Register for a JBoss Training Course.  Free Certification Exam for All 
> Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today 
> Register for a JBoss Training Course.  Free Certification Exam for All 
> Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam for All
Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] New JDBC functionality for 1.3

[Thomas R. <tho...@tr...>]

Juergen,

For the moment the named parameter support is part of the  
JdbcTemplate, but we could move it to the SqlCommand class.  That  
would eliminate 11 methods from the JdbcTemplate.  Another question  
is if we provide the option of supporting named parameters in the  
classes that are part of the "object" package.  They already support  
naming the parameters in the parameter declaration but we could add  
support for using the name instead of the placeholder '?' in the sql  
itself.  This would eliminate the need for specifying the parameters  
in the correct order since we could associate them by name.

If we add the SqlCommand then I would consider the "object" package  
more or less deprecated and the new "command" style would be the way  
to go for the future.  We could provide SqlBatchCommand and  
SqlCallableCommand to provide everything that is currently provided  
in the "object" package.

The batch support needs some work anyway.  We are currently building  
up all the parameter values internally and then calling addBatch on  
the jdbc prepared statement which in turn build some memory structure  
to hold the parameters before the entire batch is executed later.   
This leads to some additional memory and cpu usage which is a problem  
dealing with large batches.

Thomas

On Nov 19, 2005, at 12:02 PM, Juergen Hoeller wrote:

> Thomas,
>
> Looks interesting! Isn't this quite similar to our current  
> operation objects
> in the "jdbc.object" package, just more generic? A SqlCommand  
> instance seems
> to be thread-safe, parameters passed in through execute calls...
>
> In any case, I do see your point: I guess it's worth keeping the named
> parameter support restricted to such a command class, not in  
> JdbcTemplate
> itself. If that command class is close enough to the existing  
> operation
> objects in style, we could also put it into the "jdbc.object" package
> directly...
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On  
> Behalf Of
> Thomas Risberg
> Sent: Saturday, November 19, 2005 5:50 PM
> To: spr...@li...
> Subject: [Springframework-developer] New JDBC functionality for 1.3
>
> I was talking to Mark last weekend about data access for Spring.NET  
> and we
> discussed the .NET class SqlCommand that provides a nice and clean  
> interface
> to the ADO.NET functionality.  It got me thinking, and after adding  
> the
> support for named parameters, I counted over 75 different methods for
> interfacing with the JdbcTemplate - that's a lot :)
>
> So, I started looking at providing a SqlCommand interface on top of
> JdbcTemplate to just present the most used features and limit the  
> sometimes
> bewildering number of options for how to pass in the parameters  
> etc.  I
> decided to only support the new named parameter support.  The old  
> position
> based array style is still available from the JdbcTemplate  
> directly.  I
> added a new class org.springframework.jdbc.command.SqlCommand to the
> sandbox.  It's
> simply a number of one-line wrappers on top of the JdbcTemplate.
> Combined with the new named parameter support, it provides a simpler
> interface IMHO.
>
> Here are a few examples:
>
>          SqlCommand listOfBeersCommand = new SqlCommand("select id,  
> brand,
> price from beers", dataSource);
>          List beerList = listOfBeersCommand.executeQuery(new
> BeerMapper());
>
>          SqlCommand priceCommand = new SqlCommand("select price  
> from beers
> where brand = :brand", dataSource);
>          Map parameters = new HashMap();
>          parameters.put("brand", "Heineken");
>          Number price = (Number)priceCommand.executeScalar 
> (parameters);
>
> Also, with the new option of passing in a JavaBean as the holder of  
> the
> parameter values (SqlParameterBeanWrapper) it does provide the  
> option of
> using the following code:
>
>          SqlCommand readCommand = new SqlCommand("select id, brand,  
> price
> from beers where id = :id", dataSource);
>          SqlCommand saveCommand = new SqlCommand("update beers set  
> brand =
> :brand, price = :price where id = :id", dataSource);
>
>          Map parameters = new HashMap();
>          parameters.put("id", new Long(2));
>          Beer beer = (Beer)readCommand.executeObject(new BeerMapper  
> (),
> parameters);
>
>          beer.setPrice(new BigDecimal("49.87"));
>
>          SqlNamedParameters updateValues = new SqlParameterBeanWrapper
> (beer);
>          int updateCount = saveCommand.executeUpdate(updateValues);
>
> All this is in CVS now (SqlCommand is in the sandbox) and if you  
> have any
> feedback, I'm all ears.
>
> Thomas
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam for All
> Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Re: [Springframework-developer] New JDBC functionality for 1.3

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

Thomas,

Looks interesting! Isn't this quite similar to our current operation objects
in the "jdbc.object" package, just more generic? A SqlCommand instance seems
to be thread-safe, parameters passed in through execute calls...

In any case, I do see your point: I guess it's worth keeping the named
parameter support restricted to such a command class, not in JdbcTemplate
itself. If that command class is close enough to the existing operation
objects in style, we could also put it into the "jdbc.object" package
directly...

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Saturday, November 19, 2005 5:50 PM
To: spr...@li...
Subject: [Springframework-developer] New JDBC functionality for 1.3

I was talking to Mark last weekend about data access for Spring.NET and we
discussed the .NET class SqlCommand that provides a nice and clean interface
to the ADO.NET functionality.  It got me thinking, and after adding the
support for named parameters, I counted over 75 different methods for
interfacing with the JdbcTemplate - that's a lot :)

So, I started looking at providing a SqlCommand interface on top of
JdbcTemplate to just present the most used features and limit the sometimes
bewildering number of options for how to pass in the parameters etc.  I
decided to only support the new named parameter support.  The old position
based array style is still available from the JdbcTemplate directly.  I
added a new class org.springframework.jdbc.command.SqlCommand to the
sandbox.  It's  
simply a number of one-line wrappers on top of the JdbcTemplate.   
Combined with the new named parameter support, it provides a simpler
interface IMHO.

Here are a few examples:

         SqlCommand listOfBeersCommand = new SqlCommand("select id, brand,
price from beers", dataSource);
         List beerList = listOfBeersCommand.executeQuery(new
BeerMapper());

         SqlCommand priceCommand = new SqlCommand("select price from beers
where brand = :brand", dataSource);
         Map parameters = new HashMap();
         parameters.put("brand", "Heineken");
         Number price = (Number)priceCommand.executeScalar(parameters);

Also, with the new option of passing in a JavaBean as the holder of the
parameter values (SqlParameterBeanWrapper) it does provide the option of
using the following code:

         SqlCommand readCommand = new SqlCommand("select id, brand, price
from beers where id = :id", dataSource);
         SqlCommand saveCommand = new SqlCommand("update beers set brand =
:brand, price = :price where id = :id", dataSource);

         Map parameters = new HashMap();
         parameters.put("id", new Long(2));
         Beer beer = (Beer)readCommand.executeObject(new BeerMapper (),
parameters);

         beer.setPrice(new BigDecimal("49.87"));

         SqlNamedParameters updateValues = new SqlParameterBeanWrapper
(beer);
         int updateCount = saveCommand.executeUpdate(updateValues);

All this is in CVS now (SqlCommand is in the sandbox) and if you have any
feedback, I'm all ears.

Thomas



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam for All
Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] New JDBC functionality for 1.3

[Thomas R. <tho...@tr...>]

I was talking to Mark last weekend about data access for Spring.NET  
and we discussed the .NET class SqlCommand that provides a nice and  
clean interface to the ADO.NET functionality.  It got me thinking,  
and after adding the support for named parameters, I counted over 75  
different methods for interfacing with the JdbcTemplate - that's a  
lot :)

So, I started looking at providing a SqlCommand interface on top of  
JdbcTemplate to just present the most used features and limit the  
sometimes bewildering number of options for how to pass in the  
parameters etc.  I decided to only support the new named parameter  
support.  The old position based array style is still available from  
the JdbcTemplate directly.  I added a new class  
org.springframework.jdbc.command.SqlCommand to the sandbox.  It's  
simply a number of one-line wrappers on top of the JdbcTemplate.   
Combined with the new named parameter support, it provides a simpler  
interface IMHO.

Here are a few examples:

         SqlCommand listOfBeersCommand = new SqlCommand("select id,  
brand, price from beers", dataSource);
         List beerList = listOfBeersCommand.executeQuery(new  
BeerMapper());

         SqlCommand priceCommand = new SqlCommand("select price from  
beers where brand = :brand", dataSource);
         Map parameters = new HashMap();
         parameters.put("brand", "Heineken");
         Number price = (Number)priceCommand.executeScalar(parameters);

Also, with the new option of passing in a JavaBean as the holder of  
the parameter values (SqlParameterBeanWrapper) it does provide the  
option of using the following code:

         SqlCommand readCommand = new SqlCommand("select id, brand,  
price from beers where id = :id", dataSource);
         SqlCommand saveCommand = new SqlCommand("update beers set  
brand = :brand, price = :price where id = :id", dataSource);

         Map parameters = new HashMap();
         parameters.put("id", new Long(2));
         Beer beer = (Beer)readCommand.executeObject(new BeerMapper 
(), parameters);

         beer.setPrice(new BigDecimal("49.87"));

         SqlNamedParameters updateValues = new SqlParameterBeanWrapper 
(beer);
         int updateCount = saveCommand.executeUpdate(updateValues);

All this is in CVS now (SqlCommand is in the sandbox) and if you have  
any feedback, I'm all ears.

Thomas

[Springframework-developer] spring build.375 Build Successful

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

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

[Springframework-developer] FAILED BUILD: x86-linux2 (last 30 lines included)

[Darren D. <da...@sh...>]

1132310239
FAILED
    [junit] Testcase: testNaming took 0,01 sec
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,014 sec
    [junit] Testsuite: org.springframework.jmx.export.naming.PropertiesFileNamingStrategyTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,014 sec

    [junit] Testcase: testNaming took 0,004 sec
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,015 sec
    [junit] Testsuite: org.springframework.jmx.export.naming.PropertiesNamingStrategyTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,015 sec

    [junit] Testcase: testNaming took 0 sec
    [junit] Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 0,118 sec
    [junit] Testsuite: org.springframework.jmx.support.ConnectorServerFactoryBeanTests
    [junit] Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 0,118 sec

    [junit] Testcase: testStartupWithLocatedServer took 0,058 sec
    [junit] Testcase: testStartupWithSuppliedServer took 0,028 sec
    [junit] Testcase: testRegisterWithMBeanServer took 0,014 sec
    [junit] 	Caused an ERROR
    [junit] Address already in use
    [junit] java.net.BindException: Address already in use
    [junit] 	at java.net.PlainSocketImpl.socketBind(Native Method)
    [junit] 	at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331)
    [junit] 	at java.net.ServerSocket.bind(ServerSocket.java:318)
    [junit] 	at com.sun.jmx.remote.socket.SocketConnectionServer.start(SocketConnectionServer.java:128)
    [junit] 	at com.sun.jmx.remote.generic.SynchroMessageConnectionServerImpl.start(SynchroMessageConnectionServerImpl.java:39)
    [junit] 	at javax.management.remote.generic.GenericConnectorServer.start(GenericConnectorServer.java:235)
    [junit] 	at org.springframework.jmx.support.ConnectorServerFactoryBean.afterPropertiesSet(ConnectorServerFactoryBean.java:183)
    [junit] 	at org.springframework.jmx.support.ConnectorServerFactoryBeanTests.testRegisterWithMBeanServer(ConnectorServerFactoryBeanTests.java:78)

Last CVS updates prior to this build were:
1132308781
? ?
? junit423465713.properties
? junittestcases2136842450.properties
? sandbox/src/org/springframework/core/closure/ElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGeneratorWorkflow.java
? sandbox/src/org/springframework/core/closure/support/IfBlock.java
? sandbox/src/org/springframework/jms/listener
? test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml
C sandbox/src/org/springframework/jms/listener/AbstractMessageListenerContainer.java
C sandbox/src/org/springframework/jms/listener/SessionAwareMessageListener.java
C sandbox/src/org/springframework/jms/listener/SimpleMessageListenerContainer.java
C sandbox/src/org/springframework/jms/listener/SimpleMessageListenerContainer102.java
C sandbox/src/org/springframework/jms/listener/package.html
C sandbox/src/org/springframework/jms/listener/server/AbstractPoolingServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/CommonsPoolServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/ListenerSessionManager.java
C sandbox/src/org/springframework/jms/listener/server/ServerMessageListenerContainer.java
C sandbox/src/org/springframework/jms/listener/server/ServerMessageListenerContainer102.java
C sandbox/src/org/springframework/jms/listener/server/ServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/SimpleServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/package.html
C test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml

This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
successful build occurs on the machine in question.

See http://springframework.sourceforge.net/test/ for further
information.

Re: [Springframework-developer] deprecated PropertiesBeanDefinitionReader's "class" and "parent" keywords in favor of "(class)" and "(parent)"

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

This is deliberate. We have deprecated the usage of plain "class" and
"parent" in favor of "(class)" and "(parent)", respectively, to bring those
settings in line with the other special properties: "(abstract)",
"(singleton)", etc. Plain names indicate bean properties there, which was
confusing with the special keys "class" and "parent". After all, a bean
class has every right to have an actual "parent" bean property, that is, a
"setParent" method... which of course is completely different from setting
the parent of a bean definition.
 
As a consequence, I would suggest to perform a renaming on all your
properties files there: simply replace ".class=" with ".(class)=" and
".parent=" with ".(parent)=". It's likely that we are gonna remove the
entire support for the former special keys in Spring 1.3, to actually allow
for a true "parent" bean property.
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Magnus Heino
Sent: Friday, November 18, 2005 10:18 AM
To: spr...@li...
Subject: [Springframework-developer] deprecated
PropertiesBeanDefinitionReader's "class" and "parent" keywords in favor of
"(class)" and "(parent)"



Hi.

I am using ResourceBundleViewResolver.

The deprecation to "class" in favor of "(class)" in Spring 1.2.6 means that
entries in views.properties that used to be

Index.class=org.springframework.web.servlet.view.JstlView
Index.url=/WEB-INF/views/Index.jsp

now has to be

Index.(class)=org.springframework.web.servlet.view.JstlView
Index.url=/WEB-INF/views/Index.jsp

Otherwise you get a deprecation warning:

WARN  Use of 'class' property in
org.springframework.beans.factory.support.PropertiesBeanDefinitionReader is
deprecated in favor of '(class)'. at
org.springframework.beans.factory.support.PropertiesBeanDefinitionReader.isC
lassKey(PropertiesBeanDefinitionReader.java:506)

Bug or feature?

-- 

  /Magnus Heino 

[Springframework-developer] deprecated PropertiesBeanDefinitionReader's "class" and "parent" keywords in favor of "(class)" and "(parent)"

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

Hi.

I am using ResourceBundleViewResolver.

The deprecation to "class" in favor of "(class)" in Spring 1.2.6 means that
entries in views.properties that used to be

Index.class=3Dorg.springframework.web.servlet.view.JstlView
Index.url=3D/WEB-INF/views/Index.jsp

now has to be

Index.(class)=3Dorg.springframework.web.servlet.view.JstlView
Index.url=3D/WEB-INF/views/Index.jsp

Otherwise you get a deprecation warning:

WARN Use of 'class' property in
org.springframework.beans.factory.support.PropertiesBeanDefinitionReader is
deprecated in favor of '(class)'. at
org.springframework.beans.factory.support.PropertiesBeanDefinitionReader.is=
ClassKey
(PropertiesBeanDefinitionReader.java:506)

Bug or feature?

--

/Magnus Heino

Re: [Springframework-developer] spring build.374 Build Fixed

[Seth L. <set...@gm...>]

On 11/17/05, al...@in... <al...@in...> wrote:
> View results here -> http://opensource.jteam.nl/build/buildresults/spring=
?log=3Dlog20051118001631Lbuild.374
>

Just a FYI, I'm getting a 500 error when accessing the above link.

Thanks,
Seth

[Springframework-developer] Web Flow JSF integration mostly done

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

I've gotten the Web Flow JSF integration and sellitem-jsf sample (in 
spring cvs in the spring-projects module) fully working at this time, 
for the most part.

One thing it does not do is use the continuation storage as does the 
normal sellitem sample. While continuation storage works fine even in 
the JSF environment, the problem is that the JSF component tree itself 
has state, and would itself need to be stored out client side (or to 
some sort of continuation storage) for free form use of browser back and 
forward buttons. So for the time being the sellitem-jsf sample is just 
set to use normal session storage for the flow execution.

Note that as far as I know MyFaces and/or the JSF RI do implement client 
side component state storage as an alternative to session storage. I 
just haven't had time to investigate this yet...

There is at this time no example of validation. Where the original 
sellitem used normal Spring Validators, in the JSF world you would 
normally use JSF validators to validate visible fields and show input 
errors in a JSF proper fashion. There is probably still value in 
allowing Spring validators to be used in some fashion. This does not 
necessarilly need any infrastructure support; a flow action could simply 
apply a normal validator.

One final question concerns auto-creation of flow-scoped variables by 
reference from JSF pages. Currently when a flow scoped variable is 
referenced from a page, and it doesn't already exist in the flow, the 
variable is expected to be a bean (prototype typically) in the flow's 
app context. There probably needs to be some sort of namespace mechanism 
here so people don't accidentally refer to just any bean in the app 
context, and accidentally use it, without realizing it.

Colin



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

RE: [Springframework-developer] HandlerExceptionResolver not catching taglib exceptions?

[Herryanto S. <her...@gm...>]

Just to add on to this, for logging, other alternative is to set the
errorPage=3D"/error.jsp" in the jsp file, and use log tag from Apache.

Cheers.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Juergen Hoeller
Sent: 18 November 2005 00:24
To: spr...@li...
Subject: Re: [Springframework-developer] HandlerExceptionResolver not
catching taglib exceptions?

Well, a HandlerExceptionResolver is just expected to resolve exceptions
thrown by the actual handlers: that is, the Controllers or other handler
objects executed by a HandlerAdapter. The main reason for this is that a
HandlerExceptionResolver assumes to be able to redirect to a =
ModelAndView,
which is only cleanly possible as long as view rendering hasn't started =
yet.

If an exception is raised during view rendering, parts of the view are
likely to already have been sent to the client, so redirecting to an =
error
view is not possible anymore. If you nevertheless want to handle such
exceptions, for example for logging, consider implementing a standard
Servlet Filter for this, which will catch exceptions thrown during view
rendering as well.

Juergen
=20

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Tim Kettering
Sent: Tuesday, November 15, 2005 9:32 PM
To: spr...@li...
Subject: [Springframework-developer] HandlerExceptionResolver not =
catching
taglib exceptions?


I'm doing some work with the spring-portlet MVC in our current project, =
and
one thing I ran across recently is that apparently the
HandlerExceptionResolver on the portlet side does not catch Exceptions
thrown from a taglib (a custom taglib for example).  I've tested this =
out by
issuing the same exception from inside the handler itself, which was =
caught
as expected, but throwing that exception from a taglib itself is not =
caught.

So it seems that the HandlerExceptionResolver does not handle exceptions
that are issued after the flow of control is handed over to the view =
phase.

I e-mailed John Lewis about this, and he said he thinks this is how it =
also
performs on the servlet-MVC side as well.  Since we do not have any
servlet-MVC code here, I thought I'd ask on the list to see if this is
indeed true as well.

If so, what would be the correct way to handle exceptions issued by =
taglibs,
using spring MVC? =20

Thanks!

-tim



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam for All
Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring build.374 Build Fixed

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

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

Re: [Springframework-developer] HandlerExceptionResolver not catching taglib exceptions?

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

Well, a HandlerExceptionResolver is just expected to resolve exceptions
thrown by the actual handlers: that is, the Controllers or other handler
objects executed by a HandlerAdapter. The main reason for this is that a
HandlerExceptionResolver assumes to be able to redirect to a ModelAndView,
which is only cleanly possible as long as view rendering hasn't started yet.

If an exception is raised during view rendering, parts of the view are
likely to already have been sent to the client, so redirecting to an error
view is not possible anymore. If you nevertheless want to handle such
exceptions, for example for logging, consider implementing a standard
Servlet Filter for this, which will catch exceptions thrown during view
rendering as well.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Tim Kettering
Sent: Tuesday, November 15, 2005 9:32 PM
To: spr...@li...
Subject: [Springframework-developer] HandlerExceptionResolver not catching
taglib exceptions?


I'm doing some work with the spring-portlet MVC in our current project, and
one thing I ran across recently is that apparently the
HandlerExceptionResolver on the portlet side does not catch Exceptions
thrown from a taglib (a custom taglib for example).  I've tested this out by
issuing the same exception from inside the handler itself, which was caught
as expected, but throwing that exception from a taglib itself is not caught.

So it seems that the HandlerExceptionResolver does not handle exceptions
that are issued after the flow of control is handed over to the view phase.

I e-mailed John Lewis about this, and he said he thinks this is how it also
performs on the servlet-MVC side as well.  Since we do not have any
servlet-MVC code here, I thought I'd ask on the list to see if this is
indeed true as well.

If so, what would be the correct way to handle exceptions issued by taglibs,
using spring MVC?  

Thanks!

-tim



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam for All
Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Scripting support (in sandbox)

[Kristofer E. <kri...@gm...>]

Rob,

thanks a lot, it is great news indeed. Please let us know when this is in
cvs.

Cheers

Kristofer Eriksson


On 11/15/05, Rob Harrop <rob...@in...> wrote:
>
> I wasn't much really - instantiation aware BPP doesn't work for
> factory-methods so I just moved that piece of functionality to a
> different part of the logic. I did a general walk through the code
> seeing where we could simplify things at the same time. Hopefully, I
> will be able to add this to the main tree very soon.
>
> Rob
> On 14 Nov 2005, at 18:26, Seth Ladd wrote:
>
>
> > Rob,
> >
> >
> >
> >> This issue will be resolved as part of the 1.3RC1 release. I have
> >> mostly
> >> resolved the problem now and I will be updating the code when it
> >> moves over into
> >> the main source tree.
> >>
> >>
> >
> > Great news. Can you explain what you did to fix it? IIR it was a
> > couple of reasons why the reload didn't work.
> >
> > Or, I guess I can just wait for the code to drop. :)
> >
> > Seth
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by:
> > Tame your development challenges with Apache's Geronimo App Server.
> > Download
> > it for free - -and be entered to win a 42" plasma tv or your very own
> > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
> Register for a JBoss Training Course. Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] FAILED BUILD: x86-linux2 (last 30 lines included)

[Darren D. <da...@sh...>]

1132194843
FAILED
Buildfile: build.xml

clean:
   [delete] Deleting directory /var/local/home/users/d/da/davison/checkouts/spring/target/classes
   [delete] Deleting directory /var/local/home/users/d/da/davison/checkouts/spring/target

compileattr:
[attribute-compiler] Generated attribute information for 1 classes. Ignored 0 classes.

buildmain:
    [mkdir] Created dir: /var/local/home/users/d/da/davison/checkouts/spring/target/classes
    [mkdir] Created dir: /var/local/home/users/d/da/davison/checkouts/spring/target/classes/META-INF
    [javac] Compiling 1130 source files to /var/local/home/users/d/da/davison/checkouts/spring/target/classes
    [javac] /var/local/home/users/d/da/davison/checkouts/spring/src/org/springframework/util/ReflectionUtils.java:96: cannot resolve symbol
    [javac] symbol  : constructor IllegalStateException (java.lang.String,java.lang.IllegalAccessException)
    [javac] location: class java.lang.IllegalStateException
    [javac] 			throw new IllegalStateException("Should not get here.", e);
    [javac]                               ^
    [javac] /var/local/home/users/d/da/davison/checkouts/spring/src/org/springframework/util/ReflectionUtils.java:100: cannot resolve symbol
    [javac] symbol  : constructor IllegalStateException (java.lang.String,java.lang.reflect.InvocationTargetException)
    [javac] location: class java.lang.IllegalStateException
    [javac] 			throw new IllegalStateException("Should not get here.", e);
    [javac]                               ^
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -deprecation for details.
    [javac] 2 errors
Last CVS updates prior to this build were:
1132193581
? ?
? junit423465713.properties
? junittestcases2136842450.properties
? sandbox/src/org/springframework/core/closure/ElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGeneratorWorkflow.java
? sandbox/src/org/springframework/core/closure/support/IfBlock.java
? sandbox/src/org/springframework/jms/listener
? test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml
C sandbox/src/org/springframework/jms/listener/AbstractMessageListenerContainer.java
C sandbox/src/org/springframework/jms/listener/SessionAwareMessageListener.java
C sandbox/src/org/springframework/jms/listener/SimpleMessageListenerContainer.java
C sandbox/src/org/springframework/jms/listener/SimpleMessageListenerContainer102.java
C sandbox/src/org/springframework/jms/listener/package.html
C sandbox/src/org/springframework/jms/listener/server/AbstractPoolingServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/CommonsPoolServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/ListenerSessionManager.java
C sandbox/src/org/springframework/jms/listener/server/ServerMessageListenerContainer.java
C sandbox/src/org/springframework/jms/listener/server/ServerMessageListenerContainer102.java
C sandbox/src/org/springframework/jms/listener/server/ServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/SimpleServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/package.html
C test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml

This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
successful build occurs on the machine in question.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: x86-solaris1 (last 30 lines included)

[Darren D. <da...@sh...>]

1132191260
FAILED
Buildfile: build.xml

clean:
   [delete] Deleting directory /home/users/d/da/davison/checkouts/spring/target/classes
   [delete] Deleting directory /home/users/d/da/davison/checkouts/spring/target

compileattr:
[attribute-compiler] Generated attribute information for 1 classes. Ignored 0 classes.

buildmain:
    [mkdir] Created dir: /home/users/d/da/davison/checkouts/spring/target/classes
    [mkdir] Created dir: /home/users/d/da/davison/checkouts/spring/target/classes/META-INF
    [javac] Compiling 1130 source files to /home/users/d/da/davison/checkouts/spring/target/classes
    [javac] /home/users/d/da/davison/checkouts/spring/src/org/springframework/util/ReflectionUtils.java:96: cannot resolve symbol
    [javac] symbol  : constructor IllegalStateException (java.lang.String,java.lang.IllegalAccessException)
    [javac] location: class java.lang.IllegalStateException
    [javac] 			throw new IllegalStateException("Should not get here.", e);
    [javac]                               ^
    [javac] /home/users/d/da/davison/checkouts/spring/src/org/springframework/util/ReflectionUtils.java:100: cannot resolve symbol
    [javac] symbol  : constructor IllegalStateException (java.lang.String,java.lang.reflect.InvocationTargetException)
    [javac] location: class java.lang.IllegalStateException
    [javac] 			throw new IllegalStateException("Should not get here.", e);
    [javac]                               ^
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -deprecation for details.
    [javac] 2 errors
Last CVS updates prior to this build were:
1132189982
? ?
? junit423465713.properties
? junittestcases2136842450.properties
? sandbox/src/org/springframework/core/closure/ElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGeneratorWorkflow.java
? sandbox/src/org/springframework/core/closure/support/IfBlock.java
? sandbox/src/org/springframework/jms/listener
? test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml
C sandbox/src/org/springframework/jms/listener/AbstractMessageListenerContainer.java
C sandbox/src/org/springframework/jms/listener/SessionAwareMessageListener.java
C sandbox/src/org/springframework/jms/listener/SimpleMessageListenerContainer.java
C sandbox/src/org/springframework/jms/listener/SimpleMessageListenerContainer102.java
C sandbox/src/org/springframework/jms/listener/package.html
C sandbox/src/org/springframework/jms/listener/server/AbstractPoolingServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/CommonsPoolServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/ListenerSessionManager.java
C sandbox/src/org/springframework/jms/listener/server/ServerMessageListenerContainer.java
C sandbox/src/org/springframework/jms/listener/server/ServerMessageListenerContainer102.java
C sandbox/src/org/springframework/jms/listener/server/ServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/SimpleServerSessionFactory.java
C sandbox/src/org/springframework/jms/listener/server/package.html
C test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml

This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
successful build occurs on the machine in question.

See http://springframework.sourceforge.net/test/ for further
information.

Re: [Springframework-developer] Re: unable to turn off automatic detection of all handler adaptors?

[Darren D. <da...@da...>]

On Tue, 2005-11-15 at 20:42 -1000, Seth Ladd wrote:
> Hi Juergen,
>=20
> > I've just added a corresponding "detectAllHandlerAdapters" property.
>=20
> By any chance did this get checked in?  I know sometimes there's a
> delay between public and private CVS repos.  I don't see it in the
> public CVS.

yes, it's there :)

--=20
Darren Davison
Public Key: 0xDD356B0D