springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Bugs

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

The new Hibernate stuff is working ok for me (with JtaTransactionManager).

jürgen höller [werk3AT] wrote:

>I've already fixed the Hibernate one: It's what the discussion on commit/rollback was about, i.e. a flushing failure on Hibernate commit that left the database transaction in an unfinished state. It could be considered a Hibernate peculiarity, but fortunately it's quite easy to work around it by triggering an explict flush before commit (and turning the Hibernate session FlushMode.NEVER afterwards to avoid an unnecessary flush attempt at actual commit).
> 
>I've generally revised the flushing behavior. There was a situation when combining HibernateTemplate and JtaTransactionManager that would not have flushed the latest changes if the user code did not trigger flush itself. It does flush now at JTA transaction commit too, via a new beforeCommit callback in the TransactionSynchronization interface. That took me quite some time to analyze and solve; I hope it behaves correct in all situations now.
> 
>Please, everybody working with Hibernate either with HibernateTransactionManager and JtaTransactionManager, give your apps a retry with the current codebase. I'd even wait with the release till early next week to be able to double-check the current behavior.
> 
>Regarding the com.interface21 definition in PetClinic: There is no such reference in the current codebase, and there was none in the 1.0 M1 snapshot. I guess the reporter of that bug had an old Petclinic lying around and tried to drop in the new org.springframework jar files.
> 
>Juergen
> 
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: Rod Johnson [mailto:rod...@in...] 
>	Gesendet: Fr 17.10.2003 10:29 
>	An: spr...@li... 
>	Cc: 
>	Betreff: [Springframework-developer] Bugs
>	
>	
>
>	Guys,
>	
>	I've added bug categories in the bug tracker and assignees.
>	
>	We currently have 4 open bugs. The MDB one is low priority, debatable and
>	doesn't break anyone's code. Assigned to me.
>	
>	The prototype/singleton bean factory one shouldn't be a showstopper for
>	anyone, and I'll try to look at it next week. I've assigned it to me.
>	
>	Can someone please try to resolve the PetClinic one and the Hibernate one?
>	
>	Regards,
>  
>

Re: [Springframework-developer] Bugs

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

SSd2ZSBhbHJlYWR5IGZpeGVkIHRoZSBIaWJlcm5hdGUgb25lOiBJdCdzIHdoYXQgdGhlIGRpc2N1
c3Npb24gb24gY29tbWl0L3JvbGxiYWNrIHdhcyBhYm91dCwgaS5lLiBhIGZsdXNoaW5nIGZhaWx1
cmUgb24gSGliZXJuYXRlIGNvbW1pdCB0aGF0IGxlZnQgdGhlIGRhdGFiYXNlIHRyYW5zYWN0aW9u
IGluIGFuIHVuZmluaXNoZWQgc3RhdGUuIEl0IGNvdWxkIGJlIGNvbnNpZGVyZWQgYSBIaWJlcm5h
dGUgcGVjdWxpYXJpdHksIGJ1dCBmb3J0dW5hdGVseSBpdCdzIHF1aXRlIGVhc3kgdG8gd29yayBh
cm91bmQgaXQgYnkgdHJpZ2dlcmluZyBhbiBleHBsaWN0IGZsdXNoIGJlZm9yZSBjb21taXQgKGFu
ZCB0dXJuaW5nIHRoZSBIaWJlcm5hdGUgc2Vzc2lvbiBGbHVzaE1vZGUuTkVWRVIgYWZ0ZXJ3YXJk
cyB0byBhdm9pZCBhbiB1bm5lY2Vzc2FyeSBmbHVzaCBhdHRlbXB0IGF0IGFjdHVhbCBjb21taXQp
Lg0KIA0KSSd2ZSBnZW5lcmFsbHkgcmV2aXNlZCB0aGUgZmx1c2hpbmcgYmVoYXZpb3IuIFRoZXJl
IHdhcyBhIHNpdHVhdGlvbiB3aGVuIGNvbWJpbmluZyBIaWJlcm5hdGVUZW1wbGF0ZSBhbmQgSnRh
VHJhbnNhY3Rpb25NYW5hZ2VyIHRoYXQgd291bGQgbm90IGhhdmUgZmx1c2hlZCB0aGUgbGF0ZXN0
IGNoYW5nZXMgaWYgdGhlIHVzZXIgY29kZSBkaWQgbm90IHRyaWdnZXIgZmx1c2ggaXRzZWxmLiBJ
dCBkb2VzIGZsdXNoIG5vdyBhdCBKVEEgdHJhbnNhY3Rpb24gY29tbWl0IHRvbywgdmlhIGEgbmV3
IGJlZm9yZUNvbW1pdCBjYWxsYmFjayBpbiB0aGUgVHJhbnNhY3Rpb25TeW5jaHJvbml6YXRpb24g
aW50ZXJmYWNlLiBUaGF0IHRvb2sgbWUgcXVpdGUgc29tZSB0aW1lIHRvIGFuYWx5emUgYW5kIHNv
bHZlOyBJIGhvcGUgaXQgYmVoYXZlcyBjb3JyZWN0IGluIGFsbCBzaXR1YXRpb25zIG5vdy4NCiAN
ClBsZWFzZSwgZXZlcnlib2R5IHdvcmtpbmcgd2l0aCBIaWJlcm5hdGUgZWl0aGVyIHdpdGggSGli
ZXJuYXRlVHJhbnNhY3Rpb25NYW5hZ2VyIGFuZCBKdGFUcmFuc2FjdGlvbk1hbmFnZXIsIGdpdmUg
eW91ciBhcHBzIGEgcmV0cnkgd2l0aCB0aGUgY3VycmVudCBjb2RlYmFzZS4gSSdkIGV2ZW4gd2Fp
dCB3aXRoIHRoZSByZWxlYXNlIHRpbGwgZWFybHkgbmV4dCB3ZWVrIHRvIGJlIGFibGUgdG8gZG91
YmxlLWNoZWNrIHRoZSBjdXJyZW50IGJlaGF2aW9yLg0KIA0KUmVnYXJkaW5nIHRoZSBjb20uaW50
ZXJmYWNlMjEgZGVmaW5pdGlvbiBpbiBQZXRDbGluaWM6IFRoZXJlIGlzIG5vIHN1Y2ggcmVmZXJl
bmNlIGluIHRoZSBjdXJyZW50IGNvZGViYXNlLCBhbmQgdGhlcmUgd2FzIG5vbmUgaW4gdGhlIDEu
MCBNMSBzbmFwc2hvdC4gSSBndWVzcyB0aGUgcmVwb3J0ZXIgb2YgdGhhdCBidWcgaGFkIGFuIG9s
ZCBQZXRjbGluaWMgbHlpbmcgYXJvdW5kIGFuZCB0cmllZCB0byBkcm9wIGluIHRoZSBuZXcgb3Jn
LnNwcmluZ2ZyYW1ld29yayBqYXIgZmlsZXMuDQogDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVy
c3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogUm9kIEpvaG5zb24gW21haWx0bzpy
b2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb21dIA0KCUdlc2VuZGV0OiBGciAxNy4xMC4yMDAzIDEw
OjI5IA0KCUFuOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5l
dCANCglDYzogDQoJQmV0cmVmZjogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEJ1Z3MNCgkN
CgkNCg0KCUd1eXMsDQoJDQoJSSd2ZSBhZGRlZCBidWcgY2F0ZWdvcmllcyBpbiB0aGUgYnVnIHRy
YWNrZXIgYW5kIGFzc2lnbmVlcy4NCgkNCglXZSBjdXJyZW50bHkgaGF2ZSA0IG9wZW4gYnVncy4g
VGhlIE1EQiBvbmUgaXMgbG93IHByaW9yaXR5LCBkZWJhdGFibGUgYW5kDQoJZG9lc24ndCBicmVh
ayBhbnlvbmUncyBjb2RlLiBBc3NpZ25lZCB0byBtZS4NCgkNCglUaGUgcHJvdG90eXBlL3Npbmds
ZXRvbiBiZWFuIGZhY3Rvcnkgb25lIHNob3VsZG4ndCBiZSBhIHNob3dzdG9wcGVyIGZvcg0KCWFu
eW9uZSwgYW5kIEknbGwgdHJ5IHRvIGxvb2sgYXQgaXQgbmV4dCB3ZWVrLiBJJ3ZlIGFzc2lnbmVk
IGl0IHRvIG1lLg0KCQ0KCUNhbiBzb21lb25lIHBsZWFzZSB0cnkgdG8gcmVzb2x2ZSB0aGUgUGV0
Q2xpbmljIG9uZSBhbmQgdGhlIEhpYmVybmF0ZSBvbmU/DQoJDQoJUmVnYXJkcywNCglSb2QNCgkN
CgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQoJVGhpcyBTRi5uZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBFbnRlcnByaXNlIExp
bnV4IEZvcnVtIENvbmZlcmVuY2UgJiBFeHBvDQoJVGhlIEV2ZW50IEZvciBMaW51eCBEYXRhY2Vu
dGVyIFNvbHV0aW9ucyAmIFN0cmF0ZWdpZXMgaW4gVGhlIEVudGVycHJpc2UNCglMaW51eCBpbiB0
aGUgQm9hcmRyb29tOyBpbiB0aGUgRnJvbnQgT2ZmaWNlOyAmIGluIHRoZSBTZXJ2ZXIgUm9vbQ0K
CWh0dHA6Ly93d3cuZW50ZXJwcmlzZWxpbnV4Zm9ydW0uY29tDQoJX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVy
IG1haWxpbmcgbGlzdA0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9y
Z2UubmV0DQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3By
aW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KCQ0KDQo=

Re: [Springframework-developer] Whoops, we still have a com.interface21 class somewhere

[Ken K. <kk...@kk...>]

This has been resolved. An old 0.9 applicationContext.xml was being used.

Ken

Rod Johnson wrote:

>Can someone involve in the PetClinic please check this out and fix it?
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "SourceForge.net" <no...@so...>
>To: <no...@so...>
>Sent: Friday, October 17, 2003 4:11 PM
>Subject: [springframework - Help] Error deploying petclinic : Tomcat 4.0
>
>
>  
>
>>Read and respond to this message at:
>>https://sourceforge.net/forum/message.php?msg_id=2242596
>>By: dahlia
>>
>>Hi,
>>  I just downloaded this project (1.0) and tried to deloy the petclinic
>>    
>>
>sample
>  
>
>>in tomcat server. I got the following error. I copied the
>>    
>>
>spring-context.jar
>  
>
>>to common/lib, but still have the same error. Could you please help me.
>>
>>2003-10-17 10:50:39 StandardContext[/petclinic]: Exception sending context
>>initialized event to listener instance of class
>>org.springframework.web.context.ContextLoaderListener
>>java.lang.ClassNotFoundException:
>>com.interface21.context.support.ResourceBundleMessageSource
>>at
>>    
>>
>org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
>  
>
>>a:1406)
>>at
>>    
>>
>org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
>  
>
>>a:1254)
>>at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
>>at java.lang.Class.forName0(Native Method)
>>at java.lang.Class.forName(Class.java:217)
>>at
>>    
>>
>org.springframework.beans.factory.xml.XmlBeanFactory.parseBeanDefinition(Xml
>  
>
>>BeanFactory.java:326)
>>
>>
>>Thanks.
>>
>>______________________________________________________________________
>>You are receiving this email because you elected to monitor this forum.
>>To stop monitoring this forum, login to SourceForge.net and visit:
>>https://sourceforge.net/forum/unmonitor.php?forum_id=250340
>>    
>>
>
>
>
>
>-------------------------------------------------------
>This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
>The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
>Linux in the Boardroom; in the Front Office; & in the Server Room 
>http://www.enterpriselinuxforum.com
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

Re: [lists] [Springframework-developer] Expression language for use in ApplicationContext

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

Rod Johnson wrote:

>Peter,
>
>> richer expression language would have its use cases. The right thing to
>>    
>>
>do
>  
>
>>might be to make the language pluggable :^)
>>    
>>
>
>Yes, it could certainly be powerful. It has crossed my mind from time to
>time (except I didn't think of pluggability), but I was a bit concerned that
>the whole thing might get complex. However, I think it may be worthwhile.
>  
>
I've used OGNL with Tapestry, and I find it quite useful and powerful. I 
know WebWork2 also uses it now. While pluggability isn't a bad idea, I 
would be happy even with just OGNL... W/regards to the complexity 
aspect, where do you see issues? One area that's a bit grey relates to 
the lifecycles of the other beans...

>  
>
>>On a not entirely unrelated note, one of the things I've been missing from
>>Spring is what you might call "anonymous beans". In some situations, I
>>    
>>
>don't
>  
>
>>really want to pollute the namespace with beans that will only ever be
>>    
>>
>used
>  
>
>>in one place:
>>
>>   <bean id="foo" class="eg.Foo">
>>    <property name="bar"><ref bean="bar"/></property>
>>   </bean>
>>
>>   <bean id="bar" class="eg.Bar"/>
>>
>>But would like to be able to write something like
>>
>>   <bean id="foo" class="eg.Foo">
>>    <property name="bar"><bean class="eg.Bar"/></property>
>>   </bean>
>>
>>Has this been discussed before?
>>    
>>
>
>I don't think it's been discussed on the list, but I've considered the idea
>of reducing bean visibility. Nesting this way would be one way to do it
>(although it might involve substantial refactoring). Another way I've
>considered is the notion of "protected" and/or "private" beans, that can't
>be accessed outside that factory, but can be used in references. Certainly I
>think agree in some cases it would be good to avoid filling the namespace
>with single-use beans.
>
>What do others think?
>  
>
Actually just the other day I was wondering why beans couldn't be 
defined inline like this. I think it's a lot cleaner when you want to do 
one-off bean definitions...

>I suspect that this is a 1.1 thing, as I think we need to focus on existing
>functionality for 1.0. But it's a good suggestion nonetheless.
>  
>

[Springframework-developer] Bugs

[Rod J. <rod...@in...>]

Guys,

I've added bug categories in the bug tracker and assignees.

We currently have 4 open bugs. The MDB one is low priority, debatable and
doesn't break anyone's code. Assigned to me.

The prototype/singleton bean factory one shouldn't be a showstopper for
anyone, and I'll try to look at it next week. I've assigned it to me.

Can someone please try to resolve the PetClinic one and the Hibernate one?

Regards,
Rod

[Springframework-developer] Whoops, we still have a com.interface21 class somewhere

[Rod J. <rod...@in...>]

Can someone involve in the PetClinic please check this out and fix it?

Regards,
Rod

----- Original Message ----- 
From: "SourceForge.net" <no...@so...>
To: <no...@so...>
Sent: Friday, October 17, 2003 4:11 PM
Subject: [springframework - Help] Error deploying petclinic : Tomcat 4.0


>
> Read and respond to this message at:
> https://sourceforge.net/forum/message.php?msg_id=2242596
> By: dahlia
>
> Hi,
>   I just downloaded this project (1.0) and tried to deloy the petclinic
sample
> in tomcat server. I got the following error. I copied the
spring-context.jar
> to common/lib, but still have the same error. Could you please help me.
>
> 2003-10-17 10:50:39 StandardContext[/petclinic]: Exception sending context
> initialized event to listener instance of class
> org.springframework.web.context.ContextLoaderListener
> java.lang.ClassNotFoundException:
> com.interface21.context.support.ResourceBundleMessageSource
> at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
> a:1406)
> at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
> a:1254)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:217)
> at
org.springframework.beans.factory.xml.XmlBeanFactory.parseBeanDefinition(Xml
> BeanFactory.java:326)
>
>
> Thanks.
>
> ______________________________________________________________________
> You are receiving this email because you elected to monitor this forum.
> To stop monitoring this forum, login to SourceForge.net and visit:
> https://sourceforge.net/forum/unmonitor.php?forum_id=250340

RE: [lists] [Springframework-developer] Expression language for use in ApplicationContext

[Alef A. \(JTeam\) <al...@jt...>]

> A little while ago I rolled a simple generic Validator implementation
-- 
configured using the Spring configuration file -- using JEX
(http://www.plotnix.com/jex/). This a little pluggable expression
language framework. I added JEX plugins for regexps and the JSTL
expression language so I could use these (in addition to JavaScript,
BEXL and JXPath) to formulate validation rules.

I've never seen JEX before, but it sounds and looks really interesting.
Also, I thnk integration of expression language(s) in the context stuff
would be great somehow. But these would definitely be 1.1 features.

Re: [lists] [Springframework-developer] Expression language for use in ApplicationContext

[Rod J. <rod...@in...>]

Peter,

> A richer expression language would have its use cases. The right thing to
do
> might be to make the language pluggable :^)

Yes, it could certainly be powerful. It has crossed my mind from time to
time (except I didn't think of pluggability), but I was a bit concerned that
the whole thing might get complex. However, I think it may be worthwhile.

> On a not entirely unrelated note, one of the things I've been missing from
> Spring is what you might call "anonymous beans". In some situations, I
don't
> really want to pollute the namespace with beans that will only ever be
used
> in one place:
>
>    <bean id="foo" class="eg.Foo">
>     <property name="bar"><ref bean="bar"/></property>
>    </bean>
>
>    <bean id="bar" class="eg.Bar"/>
>
> But would like to be able to write something like
>
>    <bean id="foo" class="eg.Foo">
>     <property name="bar"><bean class="eg.Bar"/></property>
>    </bean>
>
> Has this been discussed before?

I don't think it's been discussed on the list, but I've considered the idea
of reducing bean visibility. Nesting this way would be one way to do it
(although it might involve substantial refactoring). Another way I've
considered is the notion of "protected" and/or "private" beans, that can't
be accessed outside that factory, but can be used in references. Certainly I
think agree in some cases it would be good to avoid filling the namespace
with single-use beans.

What do others think?

I suspect that this is a 1.1 thing, as I think we need to focus on existing
functionality for 1.0. But it's a good suggestion nonetheless.


> Spring is the best thing I've come across for a while and I'd love to
> contribute something back :^)
Thanks.

Regards,
Rod

Re: [lists] [Springframework-developer] Expression language for use in ApplicationContext

[Peter d. H. <pe...@de...>]

A richer expression language would have its use cases. The right thing to do
might be to make the language pluggable :^)

A little while ago I rolled a simple generic Validator implementation -- 
configured using the Spring configuration file -- using JEX
(http://www.plotnix.com/jex/). This a little pluggable expression language
framework. I added JEX plugins for regexps and the JSTL expression language
so I could use these (in addition to JavaScript, BEXL and JXPath) to
formulate validation rules. I never fed this back to the list because the
implementation is not quite generic enough (eg there's no i18n support), but
having used it for a while it seems there's a fair bit of mileage in the
idea. A decent expression language is IMHO exactly what's missing from the
brilliant-idea-but-flawed-execution Struts Validator.

In any case, I can think of a number of reasons why it might be good to
adopt JEX or a Spring equivalent of it.

On a not entirely unrelated note, one of the things I've been missing from
Spring is what you might call "anonymous beans". In some situations, I don't
really want to pollute the namespace with beans that will only ever be used
in one place:

   <bean id="foo" class="eg.Foo">
    <property name="bar"><ref bean="bar"/></property>
   </bean>

   <bean id="bar" class="eg.Bar"/>

But would like to be able to write something like

   <bean id="foo" class="eg.Foo">
    <property name="bar"><bean class="eg.Bar"/></property>
   </bean>

Has this been discussed before?

Spring is the best thing I've come across for a while and I'd love to
contribute something back :^)

 - Peter


----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Wednesday, October 15, 2003 8:17 PM
Subject: [lists] [Springframework-developer] Expression language for use in
ApplicationContext


> Has an expression language available for use in the app context ever
> been considered? (as per email below)
>
> -------- Original Message --------
> Subject: Re: Spring XMLBeanFactory
> Date: Wed, 15 Oct 2003 15:14:42 -0400
> From: Colin Sampaleanu <col...@ex...>
> To: Vladimir Blagojevic <vla...@cs...>
> References: <Pin...@bl...>
>
>
>
> It can't do this (to the best of my knowledge). There is an expression
> language available for use in the JSP tags, but this is not accessible
> in the contexts.
>
> If there is enough of a use case for this it could certainly be done.
> One way would be to try leveraging the existing expression language
> code. I have no idea how easy this would be to do since I've actually
> never touched the web ui code. Another mechanism would be to bring in
> something like OGNL, which is quite powerful...
>
> What is your usage scenario?
>
>
> Vladimir Blagojevic wrote:
>
> >Colin,
> >
> >Does XMLBeanFactory support reading property of bean X and assigning it
> >to bean Y within declarative xml config file? I don't think so, but is
> >there any chatter on the lists about that?
> >
> >Cheers
> >
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

RE: [Springframework-developer] Transactions / AOP / Hibernate

[Kopylenko, D. <dko...@ac...>]

Petra,

a little correction

1) Rollback/Commit rule (-) or (+) should be a prefix of Exception name
2) You should not specify FQN of the exception. You just do it like this:

+MyException1,-MyException2

3) If you do not declare any "rollback/commit" rules for the exceptions, the
default behaviour of the framework is to rollback on the RuntimeExceptions
and commit otherwise (if you applying AOP Tx interceptor)

Regards,
Dmitriy.

-----Original Message-----
From: Kopylenko, Dmitry
To: 'petra staub'; 'spr...@li...'
Sent: 10/16/2003 3:48 PM
Subject: RE: [Springframework-developer] Transactions / AOP / Hibernate

Petra,

> In my case I have now business/management object which make use of
more
than only one DAO (is this ok?)

That is perfectly ok.

>Can I somehow get control of the actual transaction functionality? What
possiblities do I have? Are rollbacks automatically performed if 
>something goes wrong?

In general, if the Exception is thrown by the DAO (usually unchecked)
and is
caught by Tx interceptor, then the transaction is rolled back
automatically.
But you could declaratively specify the Exceptions for which you want to
rollback and for which you want to commit if caught by Tx AOP e.g.

<bean id="exampleTransactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionIntercepto
r">
		<property name="transactionManager"><ref
bean="myTransactionManager"/></property>
		<property name="transactionAttributeSource">
			<value>
	
example.ExampleBusinessInterface.exampleMethod=PROPAGATION_REQUIRED,com.
myco
mpany.MyException1+,com.mycompany.MyException2-
	
example.ExampleBusinessInterface.anotherExampleMethod=PROPAGATION_REQUIR
ED
			</value>
		</property>
</bean>

So the (+) in the declaration: "com.mycompany.MyException1+" directs Tx
AOP
infrastructure to commit the transaction if this exception is caught and
respectively (-): com.mycompany.MyException1- says roll it back.

Hope this helps,
Dmitriy. 





-----Original Message-----
From: petra staub [mailto:ca...@ho...] 
Sent: Thursday, October 16, 2003 3:21 PM
To: spr...@li...
Subject: [Springframework-developer] Transactions / AOP / Hibernate


Hi

I have a question to the transaction handling with Springframework, in
details, applying Declarative Transaction Demarcation (as outlined in
the
"Data Access with the Spring Framework" on Hibernates site).

In advance, sorry for my little knowledge on AOP which may be the main
reason for my question here... ;

Well, as I understood, you can declare an "Interceptor" which inserts/
"weaves in" transaction management code into the appropriate class
methods.
I think this happens when entering and exiting the methods or am I
wrong?

In my little application, I have (as suggested by Dmitry in an earlier
posting) created DAO objects, which do not know anything about trans-
actions and soley perform "basic" database work, and business objects,
or
"management beans" which use these DAO objects and provide the final
interface for persisting methods to the user.

In my case I have now business/management object which make use of more
than
only one DAO (is this ok?). I would like to things like

BusinessObject {
   a_Method {
		(Transactions start by Interceptor??)

		DAO_A.do_something;      ---> requires transactions

		DAO_B.do_something_else; ---> must not be transaction
oriented

		(Transaction commit by Interceptor??)
   }
}

Can I somehow get control of the actual transaction functionality? What
possiblities do I have? Are rollbacks automatically performed if
something
goes wrong?

This AOP stuff does for me some "magic" stuff, I just can't grasp
somehow...

:-)


Thanks for any Springframework-brush ups! ;-)

_________________________________________________________________
MSN Hotmail  -  Absolut kostenfrei! Der weltweit grösste E-Mail-Anbieter
im 
Netz:  http://www.msn.ch/hotmail



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net
hosts over 70,000 Open Source Projects. See the people who have HELPED
US
provide better services: Click here:
http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Transactions / AOP / Hibernate

[Kopylenko, D. <dko...@ac...>]

Petra,

> In my case I have now business/management object which make use of =
more
than only one DAO (is this ok?)

That is perfectly ok.

>Can I somehow get control of the actual transaction functionality? =
What
possiblities do I have? Are rollbacks automatically performed if=20
>something goes wrong?

In general, if the Exception is thrown by the DAO (usually unchecked) =
and is
caught by Tx interceptor, then the transaction is rolled back =
automatically.
But you could declaratively specify the Exceptions for which you want =
to
rollback and for which you want to commit if caught by Tx AOP e.g.

<bean id=3D"exampleTransactionInterceptor"
class=3D"org.springframework.transaction.interceptor.TransactionIntercep=
tor">
		<property name=3D"transactionManager"><ref
bean=3D"myTransactionManager"/></property>
		<property name=3D"transactionAttributeSource">
			<value>
=09
example.ExampleBusinessInterface.exampleMethod=3DPROPAGATION_REQUIRED,co=
m.myco
mpany.MyException1+,com.mycompany.MyException2-
=09
example.ExampleBusinessInterface.anotherExampleMethod=3DPROPAGATION_REQU=
IRED
			</value>
		</property>
</bean>

So the (+) in the declaration: "com.mycompany.MyException1+" directs Tx =
AOP
infrastructure to commit the transaction if this exception is caught =
and
respectively (-): com.mycompany.MyException1- says roll it back.

Hope this helps,
Dmitriy.=20





-----Original Message-----
From: petra staub [mailto:ca...@ho...]=20
Sent: Thursday, October 16, 2003 3:21 PM
To: spr...@li...
Subject: [Springframework-developer] Transactions / AOP / Hibernate


Hi

I have a question to the transaction handling with Springframework, in
details, applying Declarative Transaction Demarcation (as outlined in =
the
"Data Access with the Spring Framework" on Hibernates site).

In advance, sorry for my little knowledge on AOP which may be the main
reason for my question here... ;

Well, as I understood, you can declare an "Interceptor" which inserts/
"weaves in" transaction management code into the appropriate class =
methods.
I think this happens when entering and exiting the methods or am I =
wrong?

In my little application, I have (as suggested by Dmitry in an earlier
posting) created DAO objects, which do not know anything about trans-
actions and soley perform "basic" database work, and business objects, =
or
"management beans" which use these DAO objects and provide the final
interface for persisting methods to the user.

In my case I have now business/management object which make use of more =
than
only one DAO (is this ok?). I would like to things like

BusinessObject {
   a_Method {
		(Transactions start by Interceptor??)

		DAO_A.do_something;      ---> requires transactions

		DAO_B.do_something_else; ---> must not be transaction
oriented

		(Transaction commit by Interceptor??)
   }
}

Can I somehow get control of the actual transaction functionality? What
possiblities do I have? Are rollbacks automatically performed if =
something
goes wrong?

This AOP stuff does for me some "magic" stuff, I just can't grasp =
somehow...

:-)


Thanks for any Springframework-brush ups! ;-)

_________________________________________________________________
MSN Hotmail=A0 - =A0Absolut kostenfrei! Der weltweit gr=F6sste =
E-Mail-Anbieter im=20
Netz:  http://www.msn.ch/hotmail



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. =
SourceForge.net
hosts over 70,000 Open Source Projects. See the people who have HELPED =
US
provide better services: Click here: =
http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Transactions / AOP / Hibernate

[petra s. <ca...@ho...>]

Hi

I have a question to the transaction handling with Springframework,
in details, applying Declarative Transaction Demarcation (as outlined
in the "Data Access with the Spring Framework" on Hibernates site).

In advance, sorry for my little knowledge on AOP which may be the
main reason for my question here... ;

Well, as I understood, you can declare an "Interceptor" which inserts/
"weaves in" transaction management code into the appropriate class
methods. I think this happens when entering and exiting the methods
or am I wrong?

In my little application, I have (as suggested by Dmitry in an earlier
posting) created DAO objects, which do not know anything about trans-
actions and soley perform "basic" database work, and business
objects, or "management beans" which use these DAO objects and provide
the final interface for persisting methods to the user.

In my case I have now business/management object which make use of
more than only one DAO (is this ok?). I would like to things like

BusinessObject {
   a_Method {
		(Transactions start by Interceptor??)

		DAO_A.do_something;      ---> requires transactions

		DAO_B.do_something_else; ---> must not be transaction oriented

		(Transaction commit by Interceptor??)
   }
}

Can I somehow get control of the actual transaction functionality?
What possiblities do I have? Are rollbacks automatically performed if
something goes wrong?

This AOP stuff does for me some "magic" stuff, I just can't grasp somehow... 
:-)


Thanks for any Springframework-brush ups! ;-)

_________________________________________________________________
MSN Hotmail  -  Absolut kostenfrei! Der weltweit grösste E-Mail-Anbieter im 
Netz:  http://www.msn.ch/hotmail

Re: [Springframework-developer] Documentation

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

I actually have a lot of experience with Maven, having tinkered with it 
a bunch over the last year (unfortunately, the multiproject support, 
where I think Maven becomes the most useful (along with the docs) to me, 
is still broken in some respects (property and repository overrides, for 
one), but that would not have an effect on Spring.

If there is consensus on this, I am willing to put in some time to 
finish this up, as necessary.


Rod Johnson wrote:

>I believe Luke Tayler did a Maven build script which works. So we certainly
>have a starting point.
>
>Rod
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: "'Spring Developers'" <spr...@li...>
>Sent: Thursday, October 16, 2003 5:17 PM
>Subject: Re: [Springframework-developer] Documentation
>
>
>  
>
>>From my point of view, while of course there is a general need for more
>>documentation and samples, what would also be of some use is some
>>general infrastructure for producing consistent and relatively
>>professional looking docs and a website. I am not a big fan of Maven
>>generated websites with nothing in them, but on the other hand, if
>>people are willing to write documentation, Maven (and other alternatives
>>like Forrest) make it pretty easy to put out documentation without
>>having to worry too much about the look and feel, linking it into the
>>site, etc.
>>
>>W/regards to the possibility of using Maven, one option would be to use
>>it just for doc generation, if doing the entire build with it is too
>>onerous. This approach has been used by other projects...
>>
>>Regards,
>>Colin
>>
>>Alef Arendsen (JTeam) wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>Since I am busy closing 2002's financial year (doing all the
>>>accounting and stuff; I never should have started a company :), I
>>>desperately need some things I can do when I'm totally sick of all
>>>those numbers and spreadsheets. No internal projects here, so I was
>>>wondering if there already is a plan for how to improve our
>>>documentation base or if there are if there other important things
>>>that need to be addressed…
>>>
>>>Juergen, other people, any thoughts?
>>>
>>>Thanx,
>>>
>>>Alef
>>>
>>>      
>>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: SF.net Giveback Program.
>>SourceForge.net hosts over 70,000 Open Source Projects.
>>See the people who have HELPED US provide better services:
>>Click here: http://sourceforge.net/supporters.php
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>    
>>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>SourceForge.net hosts over 70,000 Open Source Projects.
>See the people who have HELPED US provide better services:
>Click here: http://sourceforge.net/supporters.php
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] Documentation

[Rod J. <rod...@in...>]

I believe Luke Tayler did a Maven build script which works. So we certainly
have a starting point.

Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: "'Spring Developers'" <spr...@li...>
Sent: Thursday, October 16, 2003 5:17 PM
Subject: Re: [Springframework-developer] Documentation


> From my point of view, while of course there is a general need for more
> documentation and samples, what would also be of some use is some
> general infrastructure for producing consistent and relatively
> professional looking docs and a website. I am not a big fan of Maven
> generated websites with nothing in them, but on the other hand, if
> people are willing to write documentation, Maven (and other alternatives
> like Forrest) make it pretty easy to put out documentation without
> having to worry too much about the look and feel, linking it into the
> site, etc.
>
> W/regards to the possibility of using Maven, one option would be to use
> it just for doc generation, if doing the entire build with it is too
> onerous. This approach has been used by other projects...
>
> Regards,
> Colin
>
> Alef Arendsen (JTeam) wrote:
>
> > Hi all,
> >
> > Since I am busy closing 2002's financial year (doing all the
> > accounting and stuff; I never should have started a company :), I
> > desperately need some things I can do when I'm totally sick of all
> > those numbers and spreadsheets. No internal projects here, so I was
> > wondering if there already is a plan for how to improve our
> > documentation base or if there are if there other important things
> > that need to be addressed…
> >
> > Juergen, other people, any thoughts?
> >
> > Thanx,
> >
> > Alef
> >
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Hibernate commit/rollback

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

What happens if you provoke a Connection.commit failure, is there an =
implicit rollback then on the two databases? The question is probably: =
How to make the commit call fail?

Juergen


-----Original Message-----
From: tri...@tr... [mailto:tri...@tr...]
Sent: Thursday, October 16, 2003 6:15 PM
To: tri...@tr...
Cc: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: RE: [Springframework-developer] Hibernate commit/rollback


Juergen,

>=20
> I just found this in Oracle9i JDBC Developer's Guide and Reference
>=20
> Important:
>  =01 If auto-commit mode is disabled and you close the connection
>    without explicitly committing or rolling back your last changes,
>    then an implicit COMMIT operation is executed.
>=20
> That's the opposite behavior from what I read in a JDBC book this =
morning -
> who
> do you trust??  I'm going to try this when I get some time.
>=20

I ran this sequence in both Oracle and HSQL:

getConnection
setAutoCommit(false)
createStatement()
statement.execute("insert ...")
statement.execute("insert ...")
statement.execute("insert ...")
statement.close()
/* no commit here */
connection.close()

In Oracle I get the rows committed to the database and in HSQL I do not. =
 So
there is a big difference between the implementations here.

So my earlier statement:

>> My understanding is that unless you explicitly call a commit on the =
JDBC
>> connection, you should _never_ see any changes in the database.

was wrong - Oracle "conveniently" commits them for you :-)

Thomas

Re: [Springframework-developer] Documentation

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

 From my point of view, while of course there is a general need for more 
documentation and samples, what would also be of some use is some 
general infrastructure for producing consistent and relatively 
professional looking docs and a website. I am not a big fan of Maven 
generated websites with nothing in them, but on the other hand, if 
people are willing to write documentation, Maven (and other alternatives 
like Forrest) make it pretty easy to put out documentation without 
having to worry too much about the look and feel, linking it into the 
site, etc.

W/regards to the possibility of using Maven, one option would be to use 
it just for doc generation, if doing the entire build with it is too 
onerous. This approach has been used by other projects...

Regards,
Colin

Alef Arendsen (JTeam) wrote:

> Hi all,
>
> Since I am busy closing 2002's financial year (doing all the 
> accounting and stuff; I never should have started a company :), I 
> desperately need some things I can do when I'm totally sick of all 
> those numbers and spreadsheets. No internal projects here, so I was 
> wondering if there already is a plan for how to improve our 
> documentation base or if there are if there other important things 
> that need to be addressed…
>
> Juergen, other people, any thoughts?
>
> Thanx,
>
> Alef
>

RE: [Springframework-developer] Hibernate commit/rollback

[<tri...@tr...>]

Juergen,

> 
> I just found this in Oracle9i JDBC Developer’s Guide and Reference
> 
> Important:
>  
 If auto-commit mode is disabled and you close the connection
>    without explicitly committing or rolling back your last changes,
>    then an implicit COMMIT operation is executed.
> 
> That's the opposite behavior from what I read in a JDBC book this morning -
> who
> do you trust??  I'm going to try this when I get some time.
> 

I ran this sequence in both Oracle and HSQL:

getConnection
setAutoCommit(false)
createStatement()
statement.execute("insert ...")
statement.execute("insert ...")
statement.execute("insert ...")
statement.close()
/* no commit here */
connection.close()

In Oracle I get the rows committed to the database and in HSQL I do not.  So
there is a big difference between the implementations here.

So my earlier statement:

>> My understanding is that unless you explicitly call a commit on the JDBC
>> connection, you should _never_ see any changes in the database.

was wrong - Oracle "conveniently" commits them for you :-)

Thomas

RE: [Springframework-developer] Hibernate commit/rollback

[<tri...@tr...>]

Juergen,

A lot of the JDBC behavior seems to be implementation dependent - especially
more tricky situations.

I just found this in Oracle9i JDBC Developer’s Guide and Reference

Important:
 
 If auto-commit mode is disabled and you close the connection
   without explicitly committing or rolling back your last changes,
   then an implicit COMMIT operation is executed.

That's the opposite behavior from what I read in a JDBC book this morning - who
do you trust??  I'm going to try this when I get some time.

> 
> Of course, in the case of a flushing failure a rollback call makes sense. But
> what if the Connection.commit call fails? Does it add any value to
> additionally invoke rollback then?
> 

I would be surprised if a rollback call was necessary after a commit failed for
any database or driver implementation - but you never know and if you call
rollback inside it's own try/catch block then you can always ignore any
exceptions thrown during rollback.

Here is basically our question answered by someone at SAP (don't now if this
applies to all driver implementations):

-----
http://listserv.sap.com/pipermail/sapdb.general/2002-June/006822.html
Raimund Jacob wrote:

> 
> this is a JDBC question but i suspect that other client 
> libraries have 
> the same problem.
> 
> when i commit() a transaction in jdbc i consider my data safe 
> when the 
> method returns. but what if this method throws an SQLException (a 
> multi-purpse exception you usually just pass to the user) ?
> 
> is the transaction rolled back automatically ? do i have to do that ? 
> what if rollback() throws an exception ?
> 
> i cannot find a hint in the JDBC API doc nor in in the JDBC 
> spec. what 
> am i supposed to do when commit() fails ?

If an error was found in the kernel during commit, it is one of a number
of severe errors, the user should not work with the database any longer.
Therefore an implicit rollback release is done besides sending the found
error back to the application.
This is done no matter which kind of application is on top of the kernel.

Elke
SAP Labs Berlin
-----



This is from J2EE Developer's Guide - Transactions:

-----
 JDBC Transactions
A JDBC transaction is controlled by the transaction manager of the DBMS. You may
want to use JDBC transactions when wrapping legacy code inside a session bean.
To code a JDBC transaction, you invoke the commit and rollback methods of the
javax.sql.Connection interface. The beginning of a transaction is implicit. A
transaction begins with the first SQL statement that follows the most recent
commit, rollback, or connect statement. (This rule is generally true, but may
vary with DBMS vendor.)

The following code is from the WarehouseEJBexample, a session bean that uses the
Connection interface's methods to delimit bean-managed transactions. The ship
method starts by invoking setAutoCommit on the Connection object con. This
invocation tells the DBMS not to automatically commit every SQL statement. Next,
the ship method calls routines that update the order_item and inventory database
tables. If the updates succeed, the transaction is committed. But if an
exception is thrown, the transaction is rolled back.

public void ship (String productId, String orderId, int quantity) {

   try {
      con.setAutoCommit(false);
      updateOrderItem(productId, orderId);
      updateInventory(productId, quantity);
      con.commit();
   } catch (Exception ex) {
       try {
          con.rollback();
          throw new EJBException("Transaction failed: " +
             ex.getMessage());
       } catch (SQLException sqx) {
           throw new EJBException("Rollback failed: " +
              sqx.getMessage());
       }
   }
} 
-----
  

Thomas

[Springframework-developer] Documentation

[Alef A. \(JTeam\) <al...@jt...>]

Hi all,

Since I am busy closing 2002's financial year (doing all the accounting
and stuff; I never should have started a company :), I desperately need
some things I can do when I'm totally sick of all those numbers and
spreadsheets. No internal projects here, so I was wondering if there
already is a plan for how to improve our documentation base or if there
are if there other important things that need to be addressed.

Juergen, other people, any thoughts?

Thanx,

Alef



==
JTeam B.V.
Donker Curtiusstraat 7-412
1051 JL  Amsterdam
T: +31 20 486 20 36
M: +31 6 24 11 1996
F: +31 84 837 00 00
E: al...@jt...
W: http://www.jteam.nl

RE: [Springframework-developer] Hibernate commit/rollback

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

> I think the exception is thrown during execute on some statement and =
not the
actual commit call to the JDBC connection, so at this point the =
transaction is
still active and a rollback would make sense.  Additional rollback calls =
on a
JDBC connection should not cause any problems - you are basically =
rolling back a
new transaction that has not had any work performed.

Of course, in the case of a flushing failure a rollback call makes =
sense. But what if the Connection.commit call fails? Does it add any =
value to additionally invoke rollback then?

> I might be wrong here (have not looked at the code), but my impression =
is that
the Spring code is not actually managing the transaction - it is =
delegating to
Hibernate to manage the transaction.  If that is the case, then I would =
see what
the Hibernate guys think about this and have them add a rollback call if =
the
flush fails.  In the mean time I would leave it as it is since the =
transaction
should be rolled back either way barring an explicit commit call on the
connection itself.  What dou you mean by "cause an explicit rollback" - =
call
rollback on the connection or ask Hibernate to roll back?

Right, it delegates to the Hibernate transaction. We can easily solve =
the issue by explictly calling Session.flush before invoking =
Transaction.commit, wrapping the flush call with its own try/catch block =
that invokes Transaction.rollback if it fails (not Connection.rollback). =
If the flush succeeds, we'll invoke Transaction.commit, *not* invoking =
Transaction.rollback if there's a failure. The additional flush in =
Transaction.commit will then not issue any SQL statements anymore; a =
failure can thus be attributed to the actual commit call.

> I think they should cause a rollback if the flush failed, unless there =
is
another transaction manager involved.

Someone else has already opened the discussion on the Hibernate forum =
:-) A Spring developer list subscriber has quoted my mail from yesterday =
there; I've already added additional comments.

Juergen

Re: [Springframework-developer] Hibernate commit/rollback

[<tri...@tr...>]

Juergen,

My understanding is that unless you explicitly call a commit on the JDBC
connection, you should _never_ see any changes in the database.  If you close
the connection without calling rollback or committ, the transaction should roll
back automatically.  I suspect the reason there are changes made to the database
is because the table is non-transactional.

> If I understand correctly, a JDBC driver should behave the same: If a commit
> has failed, rollback does not have to be invoked anymore. Would it actually
> hurt if one still invoked rollback? Would that get ignored with most drivers,
> or would it cause yet another exception, a la "transaction is already rolled
> back" or "no transaction anymore"?

I think the exception is thrown during execute on some statement and not the
actual commit call to the JDBC connection, so at this point the transaction is
still active and a rollback would make sense.  Additional rollback calls on a
JDBC connection should not cause any problems - you are basically rolling back a
new transaction that has not had any work performed.

> I intend to fix the Hibernate transaction issue like this: First invoke flush
> manually and treat it like data access, i.e. just commit if it succeeded,
> else cause an explicit rollback. 

I might be wrong here (have not looked at the code), but my impression is that
the Spring code is not actually managing the transaction - it is delegating to
Hibernate to manage the transaction.  If that is the case, then I would see what
the Hibernate guys think about this and have them add a rollback call if the
flush fails.  In the mean time I would leave it as it is since the transaction
should be rolled back either way barring an explicit commit call on the
connection itself.  What dou you mean by "cause an explicit rollback" - call
rollback on the connection or ask Hibernate to roll back?

> Aren't the semantics of Hibernate's commit
> method a bit odd? Shouldn't it cause a rollback itself if the flush failed?

I think they should cause a rollback if the flush failed, unless there is
another transaction manager involved.

Thomas

[Springframework-developer] Re: [Springframework-user] How to use velocity?

[<dar...@hs...>]

<Rod>
Certainly Darren. This would be great.

Regards,
Rod

----- Original Message -----
From: "Darren Davison" <da...@da...>
To: <spr...@li...>
Sent: Thursday, October 16, 2003 7:00 AM
Subject: Re: [Springframework-user] How to use velocity?


> On Wednesday 15 October 2003 17:58, Rod Johnson wrote:
> > We should look at improving the error message or logging.
> >
> > R
>
> would an example velocity config as part of the drive for more
documentation
> be of use?  I use velocity a lot and could provide a short commented
example
> if you think it will.
</Rod>


It would be useful if someone could cast a critical eye over it for stupid
errors, but it's based on the config from a live project (some names
changed to protect the innocent!) and should therefore be ok.

(See attached file: spring-velocity.html)

Regards,
Darren.



_____________________________________________________

This transmission has been issued by a member of the HSBC Group 
"HSBC" for the information of the addressee only and should not be 
reproduced and / or distributed to any other person. Each page attached 
hereto must be read in conjunction with any disclaimer which forms part 
of it. Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. Its contents are 
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability as 
to its completeness or accuracy.

Re: [Springframework-developer] Hibernate commit/rollback

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

WW91J3JlIHJpZ2h0LCBvZiBjb3Vyc2UsIGJ1dCB0aGVyZSdzIGEgZ2VuZXJhbCBpc3N1ZS4gSSd2
ZSBjaGVja2VkIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBIaWJlcm5hdGUncyBKREJDVHJhbnNhY3Rp
b246IEl0IHJlYWxseSBiZWhhdmVzIHRoZSB3YXkgSSd2ZSBvdXRsaW5lZCwgaS5lLiBpZiB0aGVy
ZSdzIGEgZmx1c2hpbmcgZmFpbHVyZSBvbiBjb21taXQsIHRoZSBjb21taXQgY2FsbCByZXR1cm5z
IHdpdGhvdXQgaGF2aW5nIHJvbGxlZCBiYWNrIHRoZSBkYXRhYmFzZSB0cmFuc2FjdGlvbi4gV2Ug
bmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgZGF0YWJhc2UgdHJhbnNhY3Rpb24gaXMgY29tcGxl
dGVkLCBpLmUuIGVpdGhlciBjb21taXR0ZWQgb3Igcm9sbGVkIGJhY2ssIGFmdGVyIHRoZSB0cmFu
c2FjdGlvbiBtYW5hZ2VyIGhhcyBmaW5pc2hlZCBpdHMgd29yay4NCiANCkp1ZXJnZW4NCiANCg0K
CS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiB0cmlzYmVyZ0B0cmlk
Yi5jb20gW21haWx0bzp0cmlzYmVyZ0B0cmlkYi5jb21dIA0KCUdlc2VuZGV0OiBEbyAxNi4xMC4y
MDAzIDAyOjM0IA0KCUFuOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdIA0KCUNjOiBzcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglCZXRyZWZmOiBSZTog
W1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEhpYmVybmF0ZSBjb21taXQvcm9sbGJhY2sNCgkN
CgkNCg0KCUp1ZXJnZW4sDQoJDQoJVGhlIGxvZyBzaG93cyB0aGF0IGl0IGlzIGEgTXlTUUwgZGF0
YWJhc2UgLSBkbyB3ZSBrbm93IHRoYXQgdGhlIHRhYmxlIGlzIG9uZQ0KCXRoYXQgc3VwcG9ydCB0
cmFuc2FjdGlvbnM/ICBJZiBub3QgdGhlbiBubyBtYXR0ZXIgd2hhdCB3ZSBvciBoaWJlcm5hdGUg
ZG8gaXMNCglnb2luZyB0byBoZWxwLg0KCQ0KCVRob21hcw0KCQ0KCT4gVGhlcmUncyBhIGJ1ZyBl
bnRyeSBvbiBTb3VyY2VGb3JnZSByZWdhcmRpbmcgSGliZXJuYXRlVHJhbnNhY3Rpb25NYW5hZ2Vy
J3MNCgk+IGNvbW1pdHRpbmc6DQoJPiANCgk+IElmIHRoZSBmbHVzaGluZyBvZiBjaGFuZ2VzIGlz
IGRlbGF5ZWQgKGkuZS4gSGliZXJuYXRlVGVtcGxhdGUgaXMgaW4NCgk+IEZMVVNIX0FVVE8gbW9k
ZSwgbm90IGluIEZMVVNIX0VBR0VSKSwgdGhlIEhpYmVybmF0ZSBjb21taXQgY2FsbCB3aWxsIGZp
cnN0DQoJPiBpbXBsaWN0bHkgY2F1c2UgYSBmbHVzaC4gVGhlIHByb2JsZW0gaXMgdGhhdCB0aGF0
IGZsdXNoIG1pZ2h0IHRocm93IGFuDQoJPiBleGNlcHRpb24gd2hpY2ggY2F1c2VzIEhpYmVybmF0
ZSdzIGNvbW1pdCBpbXBsZW1lbnRhdGlvbiB0byByZXR1cm4gd2l0aCB0aGUNCgk+IGV4Y2VwdGlv
biwgd2l0aG91dCBhIGNvbW1pdCBidXQgdW5mb3J0dW5hdGVseSBhbHNvIHdpdGhvdXQgYSByb2xs
YmFjay4NCgk+IA0KCT4gVGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgSGliZXJuYXRlVHJh
bnNhY3Rpb25NYW5hZ2VyIHdpbGwgbm90IGNhdXNlIGFuDQoJPiBleHBsaWNpdCByb2xsYmFjayBp
biB0aGF0IGNhc2UsIGFzIGl0IGFzc3VtZXMgdGhhdCB0aGUgY29tbWl0IGhhcyBmYWlsZWQgYW5k
DQoJPiBjYXVzZWQgYW4gaW1wbGljaXQgcm9sbGJhY2suIEl0IHRha2VzIHRoYXQgYXNzdW1wdGlv
biBmcm9tIEpUQTogQWZ0ZXIgYQ0KCT4gZmFpbGVkIGNvbW1pdCwgeW91IGRvbid0IGhhdmUgdG8g
aW52b2tlIHJvbGxiYWNrIGFueW1vcmU7IHRoZSBmYWlsZWQgY29tbWl0DQoJPiBoYXMgYWxyZWFk
eSBjb21wbGV0ZWQgdGhlIHRyYW5zYWN0aW9uIHdpdGggYSByb2xsYmFjay4NCgk+IA0KCT4gSWYg
SSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgYSBKREJDIGRyaXZlciBzaG91bGQgYmVoYXZlIHRoZSBz
YW1lOiBJZiBhIGNvbW1pdA0KCT4gaGFzIGZhaWxlZCwgcm9sbGJhY2sgZG9lcyBub3QgaGF2ZSB0
byBiZSBpbnZva2VkIGFueW1vcmUuIFdvdWxkIGl0IGFjdHVhbGx5DQoJPiBodXJ0IGlmIG9uZSBz
dGlsbCBpbnZva2VkIHJvbGxiYWNrPyBXb3VsZCB0aGF0IGdldCBpZ25vcmVkIHdpdGggbW9zdCBk
cml2ZXJzLA0KCT4gb3Igd291bGQgaXQgY2F1c2UgeWV0IGFub3RoZXIgZXhjZXB0aW9uLCBhIGxh
ICJ0cmFuc2FjdGlvbiBpcyBhbHJlYWR5IHJvbGxlZA0KCT4gYmFjayIgb3IgIm5vIHRyYW5zYWN0
aW9uIGFueW1vcmUiPw0KCT4gDQoJPiBJIGludGVuZCB0byBmaXggdGhlIEhpYmVybmF0ZSB0cmFu
c2FjdGlvbiBpc3N1ZSBsaWtlIHRoaXM6IEZpcnN0IGludm9rZSBmbHVzaA0KCT4gbWFudWFsbHkg
YW5kIHRyZWF0IGl0IGxpa2UgZGF0YSBhY2Nlc3MsIGkuZS4ganVzdCBjb21taXQgaWYgaXQgc3Vj
Y2VlZGVkLA0KCT4gZWxzZSBjYXVzZSBhbiBleHBsaWNpdCByb2xsYmFjay4gQXJlbid0IHRoZSBz
ZW1hbnRpY3Mgb2YgSGliZXJuYXRlJ3MgY29tbWl0DQoJPiBtZXRob2QgYSBiaXQgb2RkPyBTaG91
bGRuJ3QgaXQgY2F1c2UgYSByb2xsYmFjayBpdHNlbGYgaWYgdGhlIGZsdXNoIGZhaWxlZD8NCgk+
IA0KCT4gSSdtIG5vdCBzdXJlIGFib3V0IEpETyBpbiB0aGF0IHJlc3BlY3QuIEl0IHdpbGwgYWxz
byBmbHVzaCBjaGFuZ2VzIGF0IGNvbW1pdCwNCgk+IGFuZCB0aGVyZSBpcyBubyBjaGFuY2UgdG8g
Y2F1c2UgYW4gZXhwbGljaXQgZmx1c2ggYmVmb3JlLiBUaGUgc3BlYyBhbmQgdGhlDQoJPiBqYXZh
ZG9jcyBhcmUgdW5jbGVhciBhYm91dCB3aGV0aGVyIGEgZmx1c2hpbmcgZmFpbHVyZSBjYXVzZXMg
YSByb2xsYmFjayBvZg0KCT4gdGhlIGRhdGFzdG9yZSB0cmFuc2FjdGlvbiwgYnV0IEkgYXNzdW1l
IHNvLiBBdCBsZWFzdCwgaXQgc2VlbXMgdGhhdCByb2xsYmFjaw0KCT4gY2FuIGFuZCBzaG91bGQg
bm90IGJlIGludm9rZWQgYWZ0ZXIgYW4gZXhjZXB0aW9uIG9uIGNvbW1pdC4NCgk+IA0KCT4gSGFz
IGFueW9uZSBwcmFjdGljYWwgZXhwZXJpZW5jZSB3aXRoIHRoZXNlIGlzc3Vlcz8NCgk+IA0KCT4g
SnVlcmdlbg0KCT4gDQoJPiANCgk+IA0KCT4gDQoJPg0KCQ0KCQ0KCQ0KCQ0KDQo=

Re: [Springframework-developer] Hibernate commit/rollback

[<tri...@tr...>]

Juergen,

The log shows that it is a MySQL database - do we know that the table is one
that support transactions?  If not then no matter what we or hibernate do is
going to help. 

Thomas

> There's a bug entry on SourceForge regarding HibernateTransactionManager's
> committing:
>  
> If the flushing of changes is delayed (i.e. HibernateTemplate is in
> FLUSH_AUTO mode, not in FLUSH_EAGER), the Hibernate commit call will first
> implictly cause a flush. The problem is that that flush might throw an
> exception which causes Hibernate's commit implementation to return with the
> exception, without a commit but unfortunately also without a rollback.
>  
> The current implementation of HibernateTransactionManager will not cause an
> explicit rollback in that case, as it assumes that the commit has failed and
> caused an implicit rollback. It takes that assumption from JTA: After a
> failed commit, you don't have to invoke rollback anymore; the failed commit
> has already completed the transaction with a rollback.
>  
> If I understand correctly, a JDBC driver should behave the same: If a commit
> has failed, rollback does not have to be invoked anymore. Would it actually
> hurt if one still invoked rollback? Would that get ignored with most drivers,
> or would it cause yet another exception, a la "transaction is already rolled
> back" or "no transaction anymore"?
>  
> I intend to fix the Hibernate transaction issue like this: First invoke flush
> manually and treat it like data access, i.e. just commit if it succeeded,
> else cause an explicit rollback. Aren't the semantics of Hibernate's commit
> method a bit odd? Shouldn't it cause a rollback itself if the flush failed?
>  
> I'm not sure about JDO in that respect. It will also flush changes at commit,
> and there is no chance to cause an explicit flush before. The spec and the
> javadocs are unclear about whether a flushing failure causes a rollback of
> the datastore transaction, but I assume so. At least, it seems that rollback
> can and should not be invoked after an exception on commit.
>  
> Has anyone practical experience with these issues?
>  
> Juergen
>  
>  
>  
>  
> 

Re: [Springframework-developer] new bean factory and application context features

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

Colin Sampaleanu wrote:

> Colin Sampaleanu wrote:
>
>> Rod Johnson wrote:
>>
>>>> W/regards to redefining TransactionAttributeSourceEditor to allow for
>>>> wildcards also in the classname, that's a useful feature, but the
>>>> internal workings of the class would have to change. Right now, 
>>>> using a
>>>> MethodMapTransactionAttributeSource, essentially all the methods of 
>>>> the
>>>> specified classes get added to the transactional method map (if they
>>>> match the method regex). So this approach wouldn't work for regexes at
>>>> the class level. You'd probably have to do matches at runtime, with
>>>> consequently slower performance (although I guess you could cache the
>>>> hits and misses, to alleviate this, making the performance pretty well
>>>> identical on second and subsequent calls to the same method). What do
>>>> you think of this idea
>>>>   
>>>
>>>
>>>
>>> I prototyped such an approach a couple of months ago. The 
>>> performance seemed
>>> not too bad. I haven't committed it. However, maybe I should when I get
>>> time, if people are interested.
>>>  
>>>
>> I think this would be useful to some people (although the ability to 
>> handle the 'all' case with another mechanism like the specialized 
>> TransactionalAttributeSource would cover most of my needs)..
>>
>> If there are performance concerns, it could use a dual approach where 
>> regexes on methods only (ie everything up to and including the class 
>> name is specified) get handled as they do now, and other regexes get 
>> handled with a runtime lookup with cache. My feeling is that the 
>> runtime lookup with cache would perform well enough though. One 
>> consideration is that the config semantics would change in terms of 
>> typos. Right now MethodMapTransactionalAttributeSource gives you an 
>> exception if you feed it a FQN which can't be resolved, or there are 
>> no matching methods. I like the idea of detecting typos in this 
>> fashion, if at all possible. Considering that your code may appear to 
>> run fine even without the transaction, if you mess up the regex, I 
>> think the error detection is valuable.  So if the code is extended, 
>> maybe one way to do it would be to have two sets of properties, one 
>> which behaves exactly like the present property (config time regexes 
>> on methods only), and a new one which adds runtime regex matching on 
>> the package and class portion as well.
>>
>> Regards,
>> Colin
>
>
> For the time being I have added a new class 
> MatchAllwaysTransactionAttributeSource, which will always return the 
> same TransactionAttribute (which may be set, otherwise it will default 
> to PROPOGATION_REQUIRED).
>
> I also tried to check in a unit test for it, but Eclipse barfed, then 
> Tortoise as well on a re-attempt, with the error you get when there is 
> a file in the attic wth the same name but a different case. This is 
> definitely not the case, since this is a new file. Here's the error 
> message from Tortoise. I don't know what to do since we don't have 
> physical access to the repo to see what is going on.
>
> -----
> In D:\src\open\spring-colin\spring: cvs -q commit -m "add 
> MatchAllwaysTransactionAttributeSource, which returns the same 
> TransactionAttribute for all methods" 
> test/org/springframework/transaction/interceptor/MatchAllwaysTransactionAttributeSourceTest.java 
>
> CVSROOT=:ext:co...@cv...:/cvsroot/springframework
>
> cvs: hash.c:312: findnode: Assertion `key != ((void *)0)' failed.
> cvs [server aborted]: received abort signal
>
> Error, CVS operation failed
>
> Tortoise Tip: This error can be caused because there used to be a file 
> in the repository with a name differing only by case from the one you 
> are adding. For example TEST.EXE rather than test.exe. To fix this go 
> into the repository, or get your administrator to, and rename that 
> file to have the same case. It will be in the Attic folder underneath 
> the folder you are in. You will also need to get the local sandbox 
> folder you are in out of CVS again, as it may have bogus entries to 
> the misspelt filename.
> -----
>
>
Never mind. Maybe it didn't like the spelling error :-). When I changed 
the name to MatchAlways..., both files checked in...