springframework-developer — Spring Framework developers list

[Springframework-developer] InvokerInterceptor --> ??

[Alef A. <al...@jt...>]

Rod,

I saw the InvokerInterceptor has been removed about two weeks ago. We
used to use that to do method interceptions. I saw it was replaced by
the TargetSource. My colleague asked me what replaced it. Since I am
supposed to be the Spring expert here, but actually don't know anything
about the AOP stuff :), you give me a hint how to do the method
interceptions right now? We used to have something like this:

    <bean id="WorkflowInterceptor"
          class="icatch.workflow.interceptor.WorkflowInterceptor" //
extending InvokerInterceptor
          init-method="init">
        <!-- set the workflow manager to handle all method interceptions
-->
        <property name="workflowManager">
            <ref bean="WorkflowManager"/>
        </property>
        <!-- the definition of all methods that should be intercepted
-->
        <property name="interceptedMethods">
            <props>
                <prop key="load"></prop>
                <prop key="create"></prop>
                <prop key="update"></prop>
                <prop key="remove"></prop>
                <prop key="findAll"></prop>
                <prop key="findBy"></prop>
                <prop key="isUnique"></prop>
                <prop key="executeBusinessLogic"></prop>
            </props>
        </property>
    </bean>

Thanx,

Alef

[Springframework-developer] Caching interceptor

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

I've just been writing a chapter on performance and thinking that a generic
caching interceptor would be very useful. Ideally this would allow for
pluggable implementations, even using a fancy distributed cache if
necessary.

But a simple caching interceptor would be a good start.

Any thoughts on this? Sounds useful? I think treating caching as an aspect,
and having an efficient generic implementation totally distinct from
application code could be very useful.

We could use pointcuts to target caching, but might also need additional
information on a per-method level. E.g. how long the return value could be
kept for a particular method. Source-level attributes could help a lot here,
but unfortunately we're not there yet.

Has anyone implemented something like this?

Regards,
Rod

Re: [Springframework-developer] Reworkings and new features

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

The big problem is related to which layers handle what. You say that the 
view code should simply not catch any exception but let them through, 
and that's it's inappropriate for the view layer to call down to code 
that handles data access exception. I disagree. If the view code is 
calling down to use-case driven service code which is doing its own 
transactions, etc., it may often be entirely appropriate that the 
service code catch and handle SQLExceptions/DataAccessException, and 
rethrow it as something else, perhaps a checked exception which the view 
layer may try to recover from and do something else. The point is, the 
view code doesn't even know that persistence (Hibernate) code is 
involved;  a layer even above it is what's handling the Hibernate 
session, which will be destroyed by an action in a layer down below the 
view code. As far as the view code is concerned, it may be totally 
reasonable to then call another service (which may or may not do db 
access) at that point, and it would be trying to do it with a munged 
Hibernate session.

Now the fact that using this pattern doesn't bit people in the ass more 
often is probably due to a number of factors. First of all, my gut feel 
is that some of the time when Hibernate throws an Exception that session 
is still perfectly fine after that (ie it is not necessarilly 
inconsistent). Secondly, many apps are probably pretty simplistic, and 
do let errors percolate all the way up, that is, the view code would 
never try call down to more service code doing db work after an error 
made its way up. But this is just luck to some extent, and using the 
pattern encourages a potential future problem...



jürgen höller [werk3AT] wrote:

>Colin,
>
>I'm not sure if I understand the issue. If view code simply doesn't catch any exceptions but always lets them through, the OpenSessionInView handler will be able to properly close the Session in any case. It would just be dangerous if the view code tried to handle exceptions itself, or called down to code that tried to handle data access exceptions - a proper web MVC view should *never* do such things.
>
>Essentially, this isn't different from normal business and data access code based on Spring: Fatal runtime exceptions like DataAccessException or TransactionExceptions should not be handled by application code but always be propagated to the surrounding transaction or data access template. I don't see why views are different in that respect, but maybe I just don't get the point...
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Tuesday, December 09, 2003 3:23 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Reworkings and new features
>
>
>While I know people are always asking for the Open Session in View 
>pattern support, I personally think it is a pretty dangerous pattern to 
>use. As per the Hibernate docs,
>  
>http://www.hibernate.org/hib_docs/reference/html/manipulating-data.html#manipulating-data-s13-4
>if Session throws an exception, the Session should be closed and 
>discarded, as it will be inconsistent. The Open Session in View pattern 
>will work ok if the view code ensures that once a Hibernate exception is 
>handled no more db related code is used, but since the session handling 
>is above all the other code, it does not enforce this in any way. In 
>fact, if the view code is calling down to some service code that does 
>the db access itself, the view code may not even know that db access is 
>being done.
>
>At a minimum, I recommend we annotate the Javadocs for these classes 
>with a warning about this aspect...
>
>Regards,
>Colin
>  
>

Re: [Springframework-developer] RE: Reworkings and new features

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

People are bound to want to do it. As I make clear in E 1:1 I think doing
smart stuff in views is pretty vile.

I vote we support it but warn against the dangers.

Regards,
Rod

----- Original Message -----=20
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Wednesday, December 10, 2003 7:43 PM
Subject: RE: [Springframework-developer] RE: Reworkings and new features


Chris,

No doubt about that: I've been reluctant to add OpenSessionInView support=
 to
Spring for quite a while, as I don't want to offer to keep transactions o=
pen
during view rendering - or even worse, to dispense with transactions
altogether just to get lazy-loading in views.

But now, I consider our solution of keeping a non-transactional Session o=
pen
as appropriate for the case where you simply don't care about data loadin=
g
exceptions in the view: Such exceptions don't affect transactions anymore
but "just" cause a broken view page if additional data can't be loaded - =
and
that won't happen too often. Accepting that risk is a valid tradeoff for
view-driven lazy loading.

Personally, I prefer appropriate initialization of the model in the
controller too. The point is that we don't force users into a single choi=
ce
anymore: It's up to them now. I consider this an important new feature th=
at
turns Spring's Hibernate support into a viable option for Hibernate users
who prefer lazy-loading in views.

I believe that the tradeoff that our OpenSessionInView handling offers is=
 as
good as possible: After all, you can't have lazy loading in views without
the drawback of risking broken views in case of exceptions. Ad-hoc soluti=
ons
as typically seen with Hibernate, involving custom ThreadLocals and the
like, are arguably worse choices than our out-of-the-box solution.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Chris Nokleberg
Sent: Wednesday, December 10, 2003 8:18 PM
To: spr...@li...
Subject: [Springframework-developer] RE: Reworkings and new features


j=FCrgen h=F6ller [werk3AT] wrote:
> Essentially, this isn't different from normal business and data access
> code based on Spring: Fatal runtime exceptions like DataAccessException=
 or
> TransactionExceptions should not be handled by application code but alw=
ays
> be propagated to the surrounding transaction or data access template. I
> don't see why views are different in that respect, but maybe I just don=
't
> get the point...

It can lead to broken pages if the exception occurs after the view writes
enough to cause a flush of the underlying response buffer. Either you get
half a page with an appended stack trace or you have to do some tricks to
close all open tags and write out a meta tag to redirect.

For these reasons I agree it is better to avoid "open session in view" bu=
t
in practice it can be difficult to make sure all of the lazy-loading
objects in your model have been initialized.

Chris




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] RE: Reworkings and new features

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

Chris,

No doubt about that: I've been reluctant to add OpenSessionInView =
support to Spring for quite a while, as I don't want to offer to keep =
transactions open during view rendering - or even worse, to dispense =
with transactions altogether just to get lazy-loading in views.

But now, I consider our solution of keeping a non-transactional Session =
open as appropriate for the case where you simply don't care about data =
loading exceptions in the view: Such exceptions don't affect =
transactions anymore but "just" cause a broken view page if additional =
data can't be loaded - and that won't happen too often. Accepting that =
risk is a valid tradeoff for view-driven lazy loading.

Personally, I prefer appropriate initialization of the model in the =
controller too. The point is that we don't force users into a single =
choice anymore: It's up to them now. I consider this an important new =
feature that turns Spring's Hibernate support into a viable option for =
Hibernate users who prefer lazy-loading in views.

I believe that the tradeoff that our OpenSessionInView handling offers =
is as good as possible: After all, you can't have lazy loading in views =
without the drawback of risking broken views in case of exceptions. =
Ad-hoc solutions as typically seen with Hibernate, involving custom =
ThreadLocals and the like, are arguably worse choices than our =
out-of-the-box solution.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Chris Nokleberg
Sent: Wednesday, December 10, 2003 8:18 PM
To: spr...@li...
Subject: [Springframework-developer] RE: Reworkings and new features


j=FCrgen h=F6ller [werk3AT] wrote:
> Essentially, this isn't different from normal business and data access
> code based on Spring: Fatal runtime exceptions like =
DataAccessException or
> TransactionExceptions should not be handled by application code but =
always
> be propagated to the surrounding transaction or data access template. =
I
> don't see why views are different in that respect, but maybe I just =
don't
> get the point...

It can lead to broken pages if the exception occurs after the view =
writes
enough to cause a flush of the underlying response buffer. Either you =
get
half a page with an appended stack trace or you have to do some tricks =
to
close all open tags and write out a meta tag to redirect.

For these reasons I agree it is better to avoid "open session in view" =
but
in practice it can be difficult to make sure all of the lazy-loading
objects in your model have been initialized.

Chris




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] RE: Reworkings and new features

[Chris N. <ch...@si...>]

jürgen höller [werk3AT] wrote:
> Essentially, this isn't different from normal business and data access
> code based on Spring: Fatal runtime exceptions like DataAccessException or
> TransactionExceptions should not be handled by application code but always
> be propagated to the surrounding transaction or data access template. I
> don't see why views are different in that respect, but maybe I just don't
> get the point...

It can lead to broken pages if the exception occurs after the view writes
enough to cause a flush of the underlying response buffer. Either you get
half a page with an appended stack trace or you have to do some tricks to
close all open tags and write out a meta tag to redirect.

For these reasons I agree it is better to avoid "open session in view" but
in practice it can be difficult to make sure all of the lazy-loading
objects in your model have been initialized.

Chris

RE: [Springframework-developer] Reworkings and new features

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

Colin,

I'm not sure if I understand the issue. If view code simply doesn't =
catch any exceptions but always lets them through, the OpenSessionInView =
handler will be able to properly close the Session in any case. It would =
just be dangerous if the view code tried to handle exceptions itself, or =
called down to code that tried to handle data access exceptions - a =
proper web MVC view should *never* do such things.

Essentially, this isn't different from normal business and data access =
code based on Spring: Fatal runtime exceptions like DataAccessException =
or TransactionExceptions should not be handled by application code but =
always be propagated to the surrounding transaction or data access =
template. I don't see why views are different in that respect, but maybe =
I just don't get the point...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Tuesday, December 09, 2003 3:23 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Reworkings and new features


While I know people are always asking for the Open Session in View=20
pattern support, I personally think it is a pretty dangerous pattern to=20
use. As per the Hibernate docs,
 =20
http://www.hibernate.org/hib_docs/reference/html/manipulating-data.html#m=
anipulating-data-s13-4
if Session throws an exception, the Session should be closed and=20
discarded, as it will be inconsistent. The Open Session in View pattern=20
will work ok if the view code ensures that once a Hibernate exception is =

handled no more db related code is used, but since the session handling=20
is above all the other code, it does not enforce this in any way. In=20
fact, if the view code is calling down to some service code that does=20
the db access itself, the view code may not even know that db access is=20
being done.

At a minimum, I recommend we annotate the Javadocs for these classes=20
with a warning about this aspect...

Regards,
Colin




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] OpenSessionInViewFilter

[Cameron B. <ca...@da...>]

There is a way to access sorceforge and never receive an IOException : 
use the following pserver details :

Server : cvs-pserver.sourceforge.net
Port : 443

This was mentioned on the sf site somewhere in regards to getting access 
to cvs from behind a firewall.

Since I have changed over to this server/port, I havn't had any problems 
with access.

Cameron

Matthew E. Porter wrote:

> You are welcome.   FWIW: The bruise from banging my head against this  
> is healing nicely.  Thanks for fixing it.  Now, only if cvs at  
> sourceforge would ever work....
>
>
>
> Cheers,
>   matthew
>
> On Dec 9, 2003, at 2:22 PM, jürgen höller [werk3AT] wrote:
>
>> BTW, that didn't affect normal HibernateTransactionManager  
>> transactions at all, just ones with pre-bound Session - for which  
>> OpenSessionInViewFilter is the first practical use case. And thanks  
>> for early-adopting the filter! :-)
>>
>> Mike, please update from CVS too if you're trying the  
>> OpenSessionInViewFilter!
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im 
>> Auftrag  von jürgen höller [werk3AT]
>> Gesendet: Di 09.12.2003 21:14
>> An: Matthew E. Porter
>> Cc: spr...@li...
>> Betreff: Re: [Springframework-developer] OpenSessionInViewFilter
>>
>>
>>
>> Matthew,
>>
>> It's indeed a bug: I've just tried a few scenarios, and it doesn't  
>> work with multiple transactions within one pre-bound Session.  
>> Fortunately, it was easy enough to find and fix:  
>> HibernateTransactionManager didn't properly reset the transaction  
>> object of a pre-bound Session, therefore the next transaction didn't  
>> open a new Hibernate transaction because it thought there was 
>> already  an active one - thus, no flushing.
>>
>> It works nicely for me now, for example with Petclinic. I hope the  
>> public CVS server shows the changed HibernateTransactionManager 
>> source  file promptly.
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: Matthew E. Porter [mailto:ma...@me...]
>> Gesendet: Di 09.12.2003 20:56
>> An: jürgen höller [werk3AT]
>> Betreff: Fwd: [Springframework-developer] OpenSessionInViewFilter
>>
>>
>> Do you think this is a bug with Spring?
>>
>>
>> Cheers,
>> matthew
>>
>> Begin forwarded message:
>>
>>
>>         From: Matthew E. Porter <ma...@me...>
>>         Date: December 9, 2003 7:35:04 AM CST
>>         To: spr...@li...
>>         Subject: Re: [Springframework-developer]  
>> OpenSessionInViewFilter
>>         Reply-To: spr...@li...
>>
>>         Juergen:
>>         FWIW: I am using the OpenSessionInViewFilter with Webwork2.
>>
>>         Anyways, when the filter is applied, flushing never happens  
>> even when using the transactionproxy factory. If I remove the filter  
>> from the web.xml, everything works perfectly.
>>
>>         Any guesses?
>>
>>
>>         Cheers,
>>         matthew
>>
>>         On Dec 9, 2003, at 7:03 AM, jürgen höller [werk3AT] wrote:
>>
>>
>>                 Matthew,
>>
>>                 TransactionProxyFactoryBean can just be used to 
>> proxy  Spring-managed Java objects: in the web case, at best a whole  
>> Controller. The view rendering is initiated by DispatcherServlet,  
>> delegating to View.render. There is no single entry point in form of 
>> a  Spring-managed bean to catch the whole request processing. But 
>> there  is the HandlerInterceptor facility to intercept that 
>> processing at  various points.
>>
>>                 It's important to stress that  
>> OpenSessionInViewInterceptor for Spring's web MVC respectively  
>> OpenSessionInViewFilter for any web processing still lets  
>> Spring-managed business methods perform their transactions as usual.  
>> The interceptor/filter just pre-binds a Hibernate Session that all  
>> transactions will use to the current thread, and which will stay 
>> open  until view rendering has been completed.
>>
>>                 Your TransactionProxyFactoryBean setup should work,  
>> with or without OpenSessionInViewFilter. Note that you need to 
>> access  the "OSUserDao" bean to get transactional behavior, not the  
>> "OSUserDaoTarget" directly. And you need to get the method pattern 
>> in  the transactionAttributes right - in the simplest case, specify:
>>
>>                 <property name="transactionAttributes">
>>                 <props>
>>                 <prop key="*">PROPAGATION_REQUIRED</prop>
>>                 </props>
>>                 </property>
>>
>>                 That should open transactions for all methods, not  
>> just ones whose names start with "find" etc. And don't specify  
>> "readOnly" for transactions that should persist changes: "readOnly"  
>> will switch the underlying Hibernate Sessions to FLUSH_NEVER. A good  
>> way is to start with the general pattern above and go more  
>> fine-granular when you've managed to make the general case work.
>>
>>                 Juergen
>>
>>
>>                 -----Original Message-----
>>                 From: Matthew E. Porter [mailto:ma...@me...]
>>                 Sent: Tuesday, December 09, 2003 1:51 PM
>>                 To: jürgen höller [werk3AT]
>>                 Subject: Re: [Springframework-developer]  
>> OpenSessionInViewFilter
>>
>>
>>                 Juergen:
>>                 Here is what I currently have that is not working.
>>
>>                 <bean id="OSUserDaoTarget"
>>                  
>> class="com.metissian.security.principal.provider.osuser.configuration.O 
>> S
>>                 UserManagerDAO">
>>                 <property name="sessionFactory">
>>                 <ref local="MetalSessionFactory"/>
>>                 </property>
>>                 </bean>
>>
>>                 <bean id="OSUserDao"
>>                  
>> class="org.springframework.transaction.interceptor.TransactionProxyFact 
>> o
>>                 ryBean">
>>                 <property name="transactionManager">
>>                 <ref local="MetalTransactionManager"/>
>>                 </property>
>>                 <property name="target">
>>                 <ref local="OSUserDaoTarget"/>
>>                 </property>
>>                 <property name="transactionAttributes">
>>                 <props>
>>                 <prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
>>                 <prop key="delete*">PROPAGATION_REQUIRED</prop>
>>                 <prop key="update*">PROPAGATION_REQUIRED</prop>
>>                 <prop key="save*">PROPAGATION_REQUIRED</prop>
>>                 </props>
>>                 </property>
>>                 </bean>
>>
>>
>>                 For some reason, I believed that wrapping an object 
>> in  a
>>                 TransactionProxyFactoryBean provided the  
>> transactionality you talked
>>                 about. Am I wrong?
>>
>>
>>                 Cheers,
>>                 matthew
>>
>>                 On Dec 9, 2003, at 12:45 AM, jürgen höller [werk3AT]  
>> wrote:
>>
>>
>>                         Matthew,
>>
>>                         You should either use Spring-managed  
>> transactions (via
>>                         HibernateTransactionManager or  
>> JtaTransactionManager), which will
>>                         automatically flush a Session at transaction  
>> commit, or set
>>                         HibernateTemplate's/HibernateInterceptor's  
>> "flushMode" property to
>>                         FLUSH_EAGER (respectively "flushModeName" to  
>> "FLUSH_EAGER" in a
>>                         textual bean definition). This will 
>> guarantee  to flush as early as
>>                         possible, not after view rendering: After 
>> all,  a view should not
>>                         modify the model, so there should be no need  
>> to flush afterwards.
>>
>>                         Juergen
>>
>>
>>                         ________________________________
>>
>>                         Von:  
>> spr...@li... im Auftrag
>>                         von Matthew E. Porter
>>                         Gesendet: Di 09.12.2003 02:20
>>                         An:  
>> spr...@li...
>>                         Betreff: [Springframework-developer]  
>> OpenSessionInViewFilter
>>
>>
>>
>>                         I am attempting to use the  
>> OpenSessionInViewFilter. According to the
>>                         javadoc, the session is not flush at the end  
>> of the filter. Therefore,
>>                         without overriding the closeSession() method  
>> in the filter, how do I
>>                         get the session to flush? I am currently  
>> accessing DAOs wrapped as a
>>                         ProxyFactoryBean with a HibernateInterceptor.
>>
>>                         Please help!
>>
>>
>>                         Cheers,
>>                         matthew
>>
>>
>>
>>                          
>> -------------------------------------------------------
>>                         This SF.net email is sponsored by: IBM Linux  
>> Tutorials.
>>                         Become an expert in LINUX or just sharpen 
>> your  skills. Sign up for
>>                         IBM's
>>                         Free Linux Tutorials. Learn everything from  
>> the bash shell to sys
>>                         admin.
>>                         Click now!  
>> http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>>                         _______________________________________________
>>                         Springframework-developer mailing list
>>                         Spr...@li...
>>                          
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>                          
>> -------------------------------------------------------
>>                         This SF.net email is sponsored by: IBM Linux  
>> Tutorials.
>>                         Become an expert in LINUX or just sharpen 
>> your  skills. Sign up for
>>                         IBM's
>>                         Free Linux Tutorials. Learn everything from  
>> the bash shell to sys
>>                         admin.
>>                         Click now!  
>> http://ads.osdn.com/?ad_id78&alloc_id371&op=click
>>                         _______________________________________________
>>                         Springframework-developer mailing list
>>                         Spr...@li...
>>                          
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>                 -------------------------------------------------------
>>                 This SF.net email is sponsored by: IBM Linux Tutorials.
>>                 Become an expert in LINUX or just sharpen your 
>> skills.  Sign up for IBM's
>>                 Free Linux Tutorials. Learn everything from the bash  
>> shell to sys admin.
>>                 Click now!  
>> http://ads.osdn.com/?ad_id78&alloc_id371&op=click
>>                 _______________________________________________
>>                 Springframework-developer mailing list
>>                 Spr...@li...
>>                  
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>         -------------------------------------------------------
>>         This SF.net email is sponsored by: IBM Linux Tutorials.
>>         Become an expert in LINUX or just sharpen your skills. Sign 
>> up  for IBM's
>>         Free Linux Tutorials. Learn everything from the bash shell 
>> to  sys admin.
>>         Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
>>         _______________________________________________
>>         Springframework-developer mailing list
>>         Spr...@li...
>>          
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IBM Linux Tutorials.
>> Become an expert in LINUX or just sharpen your skills.  Sign up for  
>> IBM's
>> Free Linux Tutorials.  Learn everything from the bash shell to sys  
>> admin.
>> Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=ick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IBM Linux Tutorials.
>> Become an expert in LINUX or just sharpen your skills.  Sign up for  
>> IBM's
>> Free Linux Tutorials.  Learn everything from the bash shell to sys  
>> admin.
>> Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]

[Springframework-developer] Website Hibernate Links

[Matthew E. P. <ma...@me...>]

At one point, Gavin from Hibernate mentioned that 
http://hibernate.bluemars.net would no longer work.  In an effort to be 
proactive, can someone change the URLs on the website to hibernate.org?


Cheers,
   matthew

Re: [Springframework-developer] OpenSessionInViewFilter

[Matthew E. P. <ma...@me...>]

You are welcome.   FWIW: The bruise from banging my head against this =20=

is healing nicely.  Thanks for fixing it.  Now, only if cvs at =20
sourceforge would ever work....



Cheers,
   matthew

On Dec 9, 2003, at 2:22 PM, j=FCrgen h=F6ller [werk3AT] wrote:

> BTW, that didn't affect normal HibernateTransactionManager =20
> transactions at all, just ones with pre-bound Session - for which =20
> OpenSessionInViewFilter is the first practical use case. And thanks =20=

> for early-adopting the filter! :-)
>
> Mike, please update from CVS too if you're trying the =20
> OpenSessionInViewFilter!
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =20=

> von j=FCrgen h=F6ller [werk3AT]
> Gesendet: Di 09.12.2003 21:14
> An: Matthew E. Porter
> Cc: spr...@li...
> Betreff: Re: [Springframework-developer] OpenSessionInViewFilter
>
>
>
> Matthew,
>
> It's indeed a bug: I've just tried a few scenarios, and it doesn't =20
> work with multiple transactions within one pre-bound Session. =20
> Fortunately, it was easy enough to find and fix: =20
> HibernateTransactionManager didn't properly reset the transaction =20
> object of a pre-bound Session, therefore the next transaction didn't =20=

> open a new Hibernate transaction because it thought there was already =20=

> an active one - thus, no flushing.
>
> It works nicely for me now, for example with Petclinic. I hope the =20
> public CVS server shows the changed HibernateTransactionManager source =
=20
> file promptly.
>
> Juergen
>
>
> ________________________________
>
> Von: Matthew E. Porter [mailto:ma...@me...]
> Gesendet: Di 09.12.2003 20:56
> An: j=FCrgen h=F6ller [werk3AT]
> Betreff: Fwd: [Springframework-developer] OpenSessionInViewFilter
>
>
> Do you think this is a bug with Spring?
>
>
> Cheers,
> matthew
>
> Begin forwarded message:
>
>
>         From: Matthew E. Porter <ma...@me...>
>         Date: December 9, 2003 7:35:04 AM CST
>         To: spr...@li...
>         Subject: Re: [Springframework-developer] =20
> OpenSessionInViewFilter
>         Reply-To: spr...@li...
>
>         Juergen:
>         FWIW: I am using the OpenSessionInViewFilter with Webwork2.
>
>         Anyways, when the filter is applied, flushing never happens =20=

> even when using the transactionproxy factory. If I remove the filter =20=

> from the web.xml, everything works perfectly.
>
>         Any guesses?
>
>
>         Cheers,
>         matthew
>
>         On Dec 9, 2003, at 7:03 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>
>
>                 Matthew,
>
>                 TransactionProxyFactoryBean can just be used to proxy =20=

> Spring-managed Java objects: in the web case, at best a whole =20
> Controller. The view rendering is initiated by DispatcherServlet, =20
> delegating to View.render. There is no single entry point in form of a =
=20
> Spring-managed bean to catch the whole request processing. But there =20=

> is the HandlerInterceptor facility to intercept that processing at =20
> various points.
>
>                 It's important to stress that =20
> OpenSessionInViewInterceptor for Spring's web MVC respectively =20
> OpenSessionInViewFilter for any web processing still lets =20
> Spring-managed business methods perform their transactions as usual. =20=

> The interceptor/filter just pre-binds a Hibernate Session that all =20
> transactions will use to the current thread, and which will stay open =20=

> until view rendering has been completed.
>
>                 Your TransactionProxyFactoryBean setup should work, =20=

> with or without OpenSessionInViewFilter. Note that you need to access =20=

> the "OSUserDao" bean to get transactional behavior, not the =20
> "OSUserDaoTarget" directly. And you need to get the method pattern in =20=

> the transactionAttributes right - in the simplest case, specify:
>
>                 <property name=3D"transactionAttributes">
>                 <props>
>                 <prop key=3D"*">PROPAGATION_REQUIRED</prop>
>                 </props>
>                 </property>
>
>                 That should open transactions for all methods, not =20
> just ones whose names start with "find" etc. And don't specify =20
> "readOnly" for transactions that should persist changes: "readOnly" =20=

> will switch the underlying Hibernate Sessions to FLUSH_NEVER. A good =20=

> way is to start with the general pattern above and go more =20
> fine-granular when you've managed to make the general case work.
>
>                 Juergen
>
>
>                 -----Original Message-----
>                 From: Matthew E. Porter [mailto:ma...@me...]
>                 Sent: Tuesday, December 09, 2003 1:51 PM
>                 To: j=FCrgen h=F6ller [werk3AT]
>                 Subject: Re: [Springframework-developer] =20
> OpenSessionInViewFilter
>
>
>                 Juergen:
>                 Here is what I currently have that is not working.
>
>                 <bean id=3D"OSUserDaoTarget"
>                 =20
> =
class=3D"com.metissian.security.principal.provider.osuser.configuration.O=20=

> S
>                 UserManagerDAO">
>                 <property name=3D"sessionFactory">
>                 <ref local=3D"MetalSessionFactory"/>
>                 </property>
>                 </bean>
>
>                 <bean id=3D"OSUserDao"
>                 =20
> =
class=3D"org.springframework.transaction.interceptor.TransactionProxyFact=20=

> o
>                 ryBean">
>                 <property name=3D"transactionManager">
>                 <ref local=3D"MetalTransactionManager"/>
>                 </property>
>                 <property name=3D"target">
>                 <ref local=3D"OSUserDaoTarget"/>
>                 </property>
>                 <property name=3D"transactionAttributes">
>                 <props>
>                 <prop key=3D"find*">PROPAGATION_REQUIRED,readOnly</prop>=

>                 <prop key=3D"delete*">PROPAGATION_REQUIRED</prop>
>                 <prop key=3D"update*">PROPAGATION_REQUIRED</prop>
>                 <prop key=3D"save*">PROPAGATION_REQUIRED</prop>
>                 </props>
>                 </property>
>                 </bean>
>
>
>                 For some reason, I believed that wrapping an object in =
=20
> a
>                 TransactionProxyFactoryBean provided the =20
> transactionality you talked
>                 about. Am I wrong?
>
>
>                 Cheers,
>                 matthew
>
>                 On Dec 9, 2003, at 12:45 AM, j=FCrgen h=F6ller =
[werk3AT] =20
> wrote:
>
>
>                         Matthew,
>
>                         You should either use Spring-managed =20
> transactions (via
>                         HibernateTransactionManager or =20
> JtaTransactionManager), which will
>                         automatically flush a Session at transaction =20=

> commit, or set
>                         HibernateTemplate's/HibernateInterceptor's =20
> "flushMode" property to
>                         FLUSH_EAGER (respectively "flushModeName" to =20=

> "FLUSH_EAGER" in a
>                         textual bean definition). This will guarantee =20=

> to flush as early as
>                         possible, not after view rendering: After all, =
=20
> a view should not
>                         modify the model, so there should be no need =20=

> to flush afterwards.
>
>                         Juergen
>
>
>                         ________________________________
>
>                         Von: =20
> spr...@li... im Auftrag
>                         von Matthew E. Porter
>                         Gesendet: Di 09.12.2003 02:20
>                         An: =20
> spr...@li...
>                         Betreff: [Springframework-developer] =20
> OpenSessionInViewFilter
>
>
>
>                         I am attempting to use the =20
> OpenSessionInViewFilter. According to the
>                         javadoc, the session is not flush at the end =20=

> of the filter. Therefore,
>                         without overriding the closeSession() method =20=

> in the filter, how do I
>                         get the session to flush? I am currently =20
> accessing DAOs wrapped as a
>                         ProxyFactoryBean with a HibernateInterceptor.
>
>                         Please help!
>
>
>                         Cheers,
>                         matthew
>
>
>
>                         =20
> -------------------------------------------------------
>                         This SF.net email is sponsored by: IBM Linux =20=

> Tutorials.
>                         Become an expert in LINUX or just sharpen your =
=20
> skills. Sign up for
>                         IBM's
>                         Free Linux Tutorials. Learn everything from =20=

> the bash shell to sys
>                         admin.
>                         Click now! =20
> http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
>                         =
_______________________________________________
>                         Springframework-developer mailing list
>                         =
Spr...@li...
>                         =20
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>                         =20
> -------------------------------------------------------
>                         This SF.net email is sponsored by: IBM Linux =20=

> Tutorials.
>                         Become an expert in LINUX or just sharpen your =
=20
> skills. Sign up for
>                         IBM's
>                         Free Linux Tutorials. Learn everything from =20=

> the bash shell to sys
>                         admin.
>                         Click now! =20
> http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
>                         =
_______________________________________________
>                         Springframework-developer mailing list
>                         =
Spr...@li...
>                         =20
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>                 =
-------------------------------------------------------
>                 This SF.net email is sponsored by: IBM Linux =
Tutorials.
>                 Become an expert in LINUX or just sharpen your skills. =
=20
> Sign up for IBM's
>                 Free Linux Tutorials. Learn everything from the bash =20=

> shell to sys admin.
>                 Click now! =20
> http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
>                 _______________________________________________
>                 Springframework-developer mailing list
>                 Spr...@li...
>                 =20
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>         -------------------------------------------------------
>         This SF.net email is sponsored by: IBM Linux Tutorials.
>         Become an expert in LINUX or just sharpen your skills. Sign up =
=20
> for IBM's
>         Free Linux Tutorials. Learn everything from the bash shell to =20=

> sys admin.
>         Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclic=
k
>         _______________________________________________
>         Springframework-developer mailing list
>         Spr...@li...
>         =20
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for =20=

> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys =20
> admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for =20=

> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys =20
> admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] OpenSessionInViewFilter

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

BTW, that didn't affect normal HibernateTransactionManager transactions =
at all, just ones with pre-bound Session - for which =
OpenSessionInViewFilter is the first practical use case. And thanks for =
early-adopting the filter! :-)
=20
Mike, please update from CVS too if you're trying the =
OpenSessionInViewFilter!
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Di 09.12.2003 21:14
An: Matthew E. Porter
Cc: spr...@li...
Betreff: Re: [Springframework-developer] OpenSessionInViewFilter



Matthew,

It's indeed a bug: I've just tried a few scenarios, and it doesn't work =
with multiple transactions within one pre-bound Session. Fortunately, it =
was easy enough to find and fix: HibernateTransactionManager didn't =
properly reset the transaction object of a pre-bound Session, therefore =
the next transaction didn't open a new Hibernate transaction because it =
thought there was already an active one - thus, no flushing.

It works nicely for me now, for example with Petclinic. I hope the =
public CVS server shows the changed HibernateTransactionManager source =
file promptly.

Juergen


________________________________

Von: Matthew E. Porter [mailto:ma...@me...]
Gesendet: Di 09.12.2003 20:56
An: j=FCrgen h=F6ller [werk3AT]
Betreff: Fwd: [Springframework-developer] OpenSessionInViewFilter


Do you think this is a bug with Spring?


Cheers,
matthew

Begin forwarded message:


        From: Matthew E. Porter <ma...@me...>
        Date: December 9, 2003 7:35:04 AM CST
        To: spr...@li...
        Subject: Re: [Springframework-developer] OpenSessionInViewFilter
        Reply-To: spr...@li...

        Juergen:
        FWIW: I am using the OpenSessionInViewFilter with Webwork2.

        Anyways, when the filter is applied, flushing never happens even =
when using the transactionproxy factory. If I remove the filter from the =
web.xml, everything works perfectly.

        Any guesses?


        Cheers,
        matthew

        On Dec 9, 2003, at 7:03 AM, j=FCrgen h=F6ller [werk3AT] wrote:


                Matthew,

                TransactionProxyFactoryBean can just be used to proxy =
Spring-managed Java objects: in the web case, at best a whole =
Controller. The view rendering is initiated by DispatcherServlet, =
delegating to View.render. There is no single entry point in form of a =
Spring-managed bean to catch the whole request processing. But there is =
the HandlerInterceptor facility to intercept that processing at various =
points.

                It's important to stress that =
OpenSessionInViewInterceptor for Spring's web MVC respectively =
OpenSessionInViewFilter for any web processing still lets Spring-managed =
business methods perform their transactions as usual. The =
interceptor/filter just pre-binds a Hibernate Session that all =
transactions will use to the current thread, and which will stay open =
until view rendering has been completed.

                Your TransactionProxyFactoryBean setup should work, with =
or without OpenSessionInViewFilter. Note that you need to access the =
"OSUserDao" bean to get transactional behavior, not the =
"OSUserDaoTarget" directly. And you need to get the method pattern in =
the transactionAttributes right - in the simplest case, specify:

                <property name=3D"transactionAttributes">
                <props>
                <prop key=3D"*">PROPAGATION_REQUIRED</prop>
                </props>
                </property>

                That should open transactions for all methods, not just =
ones whose names start with "find" etc. And don't specify "readOnly" for =
transactions that should persist changes: "readOnly" will switch the =
underlying Hibernate Sessions to FLUSH_NEVER. A good way is to start =
with the general pattern above and go more fine-granular when you've =
managed to make the general case work.

                Juergen


                -----Original Message-----
                From: Matthew E. Porter [mailto:ma...@me...]
                Sent: Tuesday, December 09, 2003 1:51 PM
                To: j=FCrgen h=F6ller [werk3AT]
                Subject: Re: [Springframework-developer] =
OpenSessionInViewFilter


                Juergen:
                Here is what I currently have that is not working.

                <bean id=3D"OSUserDaoTarget"
                =
class=3D"com.metissian.security.principal.provider.osuser.configuration.O=
S
                UserManagerDAO">
                <property name=3D"sessionFactory">
                <ref local=3D"MetalSessionFactory"/>
                </property>
                </bean>

                <bean id=3D"OSUserDao"
                =
class=3D"org.springframework.transaction.interceptor.TransactionProxyFact=
o
                ryBean">
                <property name=3D"transactionManager">
                <ref local=3D"MetalTransactionManager"/>
                </property>
                <property name=3D"target">
                <ref local=3D"OSUserDaoTarget"/>
                </property>
                <property name=3D"transactionAttributes">
                <props>
                <prop key=3D"find*">PROPAGATION_REQUIRED,readOnly</prop>
                <prop key=3D"delete*">PROPAGATION_REQUIRED</prop>
                <prop key=3D"update*">PROPAGATION_REQUIRED</prop>
                <prop key=3D"save*">PROPAGATION_REQUIRED</prop>
                </props>
                </property>
                </bean>


                For some reason, I believed that wrapping an object in a
                TransactionProxyFactoryBean provided the =
transactionality you talked
                about. Am I wrong?


                Cheers,
                matthew

                On Dec 9, 2003, at 12:45 AM, j=FCrgen h=F6ller [werk3AT] =
wrote:


                        Matthew,

                        You should either use Spring-managed =
transactions (via
                        HibernateTransactionManager or =
JtaTransactionManager), which will
                        automatically flush a Session at transaction =
commit, or set
                        HibernateTemplate's/HibernateInterceptor's =
"flushMode" property to
                        FLUSH_EAGER (respectively "flushModeName" to =
"FLUSH_EAGER" in a
                        textual bean definition). This will guarantee to =
flush as early as
                        possible, not after view rendering: After all, a =
view should not
                        modify the model, so there should be no need to =
flush afterwards.

                        Juergen


                        ________________________________

                        Von: =
spr...@li... im Auftrag
                        von Matthew E. Porter
                        Gesendet: Di 09.12.2003 02:20
                        An: =
spr...@li...
                        Betreff: [Springframework-developer] =
OpenSessionInViewFilter



                        I am attempting to use the =
OpenSessionInViewFilter. According to the
                        javadoc, the session is not flush at the end of =
the filter. Therefore,
                        without overriding the closeSession() method in =
the filter, how do I
                        get the session to flush? I am currently =
accessing DAOs wrapped as a
                        ProxyFactoryBean with a HibernateInterceptor.

                        Please help!


                        Cheers,
                        matthew



                        =
-------------------------------------------------------
                        This SF.net email is sponsored by: IBM Linux =
Tutorials.
                        Become an expert in LINUX or just sharpen your =
skills. Sign up for
                        IBM's
                        Free Linux Tutorials. Learn everything from the =
bash shell to sys
                        admin.
                        Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
                        _______________________________________________
                        Springframework-developer mailing list
                        Spr...@li...
                        =
https://lists.sourceforge.net/lists/listinfo/springframework-developer




                        =
-------------------------------------------------------
                        This SF.net email is sponsored by: IBM Linux =
Tutorials.
                        Become an expert in LINUX or just sharpen your =
skills. Sign up for
                        IBM's
                        Free Linux Tutorials. Learn everything from the =
bash shell to sys
                        admin.
                        Click now! =
http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
                        _______________________________________________
                        Springframework-developer mailing list
                        Spr...@li...
                        =
https://lists.sourceforge.net/lists/listinfo/springframework-developer




                -------------------------------------------------------
                This SF.net email is sponsored by: IBM Linux Tutorials.
                Become an expert in LINUX or just sharpen your skills. =
Sign up for IBM's
                Free Linux Tutorials. Learn everything from the bash =
shell to sys admin.
                Click now! =
http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
                _______________________________________________
                Springframework-developer mailing list
                Spr...@li...
                =
https://lists.sourceforge.net/lists/listinfo/springframework-developer




        -------------------------------------------------------
        This SF.net email is sponsored by: IBM Linux Tutorials.
        Become an expert in LINUX or just sharpen your skills. Sign up =
for IBM's
        Free Linux Tutorials. Learn everything from the bash shell to =
sys admin.
        Click now! =
http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
        _______________________________________________
        Springframework-developer mailing list
        Spr...@li...
        =
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] OpenSessionInViewFilter

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

Matthew,
=20
It's indeed a bug: I've just tried a few scenarios, and it doesn't work =
with multiple transactions within one pre-bound Session. Fortunately, it =
was easy enough to find and fix: HibernateTransactionManager didn't =
properly reset the transaction object of a pre-bound Session, therefore =
the next transaction didn't open a new Hibernate transaction because it =
thought there was already an active one - thus, no flushing.
=20
It works nicely for me now, for example with Petclinic. I hope the =
public CVS server shows the changed HibernateTransactionManager source =
file promptly.
=20
Juergen
=20

________________________________

Von: Matthew E. Porter [mailto:ma...@me...]
Gesendet: Di 09.12.2003 20:56
An: j=FCrgen h=F6ller [werk3AT]
Betreff: Fwd: [Springframework-developer] OpenSessionInViewFilter


Do you think this is a bug with Spring?=20


Cheers,=20
matthew=20

Begin forwarded message:=20


	From: Matthew E. Porter <ma...@me...>=20
	Date: December 9, 2003 7:35:04 AM CST=20
	To: spr...@li...=20
	Subject: Re: [Springframework-developer] OpenSessionInViewFilter=20
	Reply-To: spr...@li...=20

	Juergen:=20
	FWIW: I am using the OpenSessionInViewFilter with Webwork2.=20

	Anyways, when the filter is applied, flushing never happens even when =
using the transactionproxy factory. If I remove the filter from the =
web.xml, everything works perfectly.=20

	Any guesses?=20


	Cheers,=20
	matthew=20

	On Dec 9, 2003, at 7:03 AM, j=FCrgen h=F6ller [werk3AT] wrote:=20


		Matthew,=20

		TransactionProxyFactoryBean can just be used to proxy Spring-managed =
Java objects: in the web case, at best a whole Controller. The view =
rendering is initiated by DispatcherServlet, delegating to View.render. =
There is no single entry point in form of a Spring-managed bean to catch =
the whole request processing. But there is the HandlerInterceptor =
facility to intercept that processing at various points.=20

		It's important to stress that OpenSessionInViewInterceptor for =
Spring's web MVC respectively OpenSessionInViewFilter for any web =
processing still lets Spring-managed business methods perform their =
transactions as usual. The interceptor/filter just pre-binds a Hibernate =
Session that all transactions will use to the current thread, and which =
will stay open until view rendering has been completed.=20

		Your TransactionProxyFactoryBean setup should work, with or without =
OpenSessionInViewFilter. Note that you need to access the "OSUserDao" =
bean to get transactional behavior, not the "OSUserDaoTarget" directly. =
And you need to get the method pattern in the transactionAttributes =
right - in the simplest case, specify:=20

		<property name=3D"transactionAttributes">=20
		<props>=20
		<prop key=3D"*">PROPAGATION_REQUIRED</prop>=20
		</props>=20
		</property>=20

		That should open transactions for all methods, not just ones whose =
names start with "find" etc. And don't specify "readOnly" for =
transactions that should persist changes: "readOnly" will switch the =
underlying Hibernate Sessions to FLUSH_NEVER. A good way is to start =
with the general pattern above and go more fine-granular when you've =
managed to make the general case work.=20

		Juergen=20


		-----Original Message-----=20
		From: Matthew E. Porter [mailto:ma...@me...]=20
		Sent: Tuesday, December 09, 2003 1:51 PM=20
		To: j=FCrgen h=F6ller [werk3AT]=20
		Subject: Re: [Springframework-developer] OpenSessionInViewFilter=20


		Juergen:=20
		Here is what I currently have that is not working.=20

		<bean id=3D"OSUserDaoTarget"=20
		=
class=3D"com.metissian.security.principal.provider.osuser.configuration.O=
S=20
		UserManagerDAO">=20
		<property name=3D"sessionFactory">=20
		<ref local=3D"MetalSessionFactory"/>=20
		</property>=20
		</bean>=20

		<bean id=3D"OSUserDao"=20
		=
class=3D"org.springframework.transaction.interceptor.TransactionProxyFact=
o=20
		ryBean">=20
		<property name=3D"transactionManager">=20
		<ref local=3D"MetalTransactionManager"/>=20
		</property>=20
		<property name=3D"target">=20
		<ref local=3D"OSUserDaoTarget"/>=20
		</property>=20
		<property name=3D"transactionAttributes">=20
		<props>=20
		<prop key=3D"find*">PROPAGATION_REQUIRED,readOnly</prop>=20
		<prop key=3D"delete*">PROPAGATION_REQUIRED</prop>=20
		<prop key=3D"update*">PROPAGATION_REQUIRED</prop>=20
		<prop key=3D"save*">PROPAGATION_REQUIRED</prop>=20
		</props>=20
		</property>=20
		</bean>=20


		For some reason, I believed that wrapping an object in a=20
		TransactionProxyFactoryBean provided the transactionality you talked=20
		about. Am I wrong?=20


		Cheers,=20
		matthew=20

		On Dec 9, 2003, at 12:45 AM, j=FCrgen h=F6ller [werk3AT] wrote:=20


			Matthew,=20

			You should either use Spring-managed transactions (via=20
			HibernateTransactionManager or JtaTransactionManager), which will=20
			automatically flush a Session at transaction commit, or set=20
			HibernateTemplate's/HibernateInterceptor's "flushMode" property to=20
			FLUSH_EAGER (respectively "flushModeName" to "FLUSH_EAGER" in a=20
			textual bean definition). This will guarantee to flush as early as=20
			possible, not after view rendering: After all, a view should not=20
			modify the model, so there should be no need to flush afterwards.=20

			Juergen=20


			________________________________=20

			Von: spr...@li... im Auftrag =

			von Matthew E. Porter=20
			Gesendet: Di 09.12.2003 02:20=20
			An: spr...@li...=20
			Betreff: [Springframework-developer] OpenSessionInViewFilter=20



			I am attempting to use the OpenSessionInViewFilter. According to the=20
			javadoc, the session is not flush at the end of the filter. =
Therefore,=20
			without overriding the closeSession() method in the filter, how do I=20
			get the session to flush? I am currently accessing DAOs wrapped as a=20
			ProxyFactoryBean with a HibernateInterceptor.=20

			Please help!=20


			Cheers,=20
			matthew=20



			-------------------------------------------------------=20
			This SF.net email is sponsored by: IBM Linux Tutorials.=20
			Become an expert in LINUX or just sharpen your skills. Sign up for=20
			IBM's=20
			Free Linux Tutorials. Learn everything from the bash shell to sys=20
			admin.=20
			Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick=20
			_______________________________________________=20
			Springframework-developer mailing list=20
			Spr...@li...=20
			=
https://lists.sourceforge.net/lists/listinfo/springframework-developer=20




			-------------------------------------------------------=20
			This SF.net email is sponsored by: IBM Linux Tutorials.=20
			Become an expert in LINUX or just sharpen your skills. Sign up for=20
			IBM's=20
			Free Linux Tutorials. Learn everything from the bash shell to sys=20
			admin.=20
			Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick=20
			_______________________________________________=20
			Springframework-developer mailing list=20
			Spr...@li...=20
			=
https://lists.sourceforge.net/lists/listinfo/springframework-developer=20




		-------------------------------------------------------=20
		This SF.net email is sponsored by: IBM Linux Tutorials.=20
		Become an expert in LINUX or just sharpen your skills. Sign up for =
IBM's=20
		Free Linux Tutorials. Learn everything from the bash shell to sys =
admin.=20
		Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick=20
		_______________________________________________=20
		Springframework-developer mailing list=20
		Spr...@li...=20
		https://lists.sourceforge.net/lists/listinfo/springframework-developer =





	-------------------------------------------------------=20
	This SF.net email is sponsored by: IBM Linux Tutorials.=20
	Become an expert in LINUX or just sharpen your skills. Sign up for =
IBM's=20
	Free Linux Tutorials. Learn everything from the bash shell to sys =
admin.=20
	Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick=20
	_______________________________________________=20
	Springframework-developer mailing list=20
	Spr...@li...=20
	https://lists.sourceforge.net/lists/listinfo/springframework-developer=20

[Springframework-developer] Test coverage

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

To all developers:

Can we please make an effort to raise test coverage as a priority from now
on. We're at 76.8% with warn logging (close to 79 I think with debug
logging).

Please all run the clover target . The weakest packages are:
- jdbc.support.incrementer (0)
- jdbc.support.log (0)
- nativejdbc (0)
- mail.cos (0)
- ibatis.support (0)
- web.multipart(0)
- view.document (0)

The coverage report is also quite informative about what code is not being
exercised. I think we should think about what of that code is no longer
required; now is our last opportunity to get rid of unused features.

I think the coverage on the core is excellent, but I would feel happier if
we could get beyond 80% overall.

If anyone else would like to contribute tests, that's most welcome too!

Regards,
Rod

[Springframework-developer] CLOB support

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

Juergen,

may be we need to think/look into CLOB support similar to the BLOB support
that you created?

Regards,
Dmitriy.

Re: [Springframework-developer] Passivating statefull session beans

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

Tim McAuley wrote:

> Colin Sampaleanu wrote:
>
>> I've modified the EJB support code to allow a user subclass of 
>> AbstractStatelessSessionBean to call a new method unloadBeanFactory() 
>> from ejbPassivate (which it should implement itself). The subclass 
>> should call the existing loadBeanFactory()  from ejbCreate() and 
>> ejbActivate().   As well, the default implementation of ejbRemove 
>> which is in AbstractEnterpriseBean now calls the new 
>> unloadBeanFactory() method.     There is one change that may affect 
>> some existing code, and that is that in the process of adding the 
>> above, I modified the existing BeanFactoryLoader interface to handle 
>> unloading as well as loading of a beanfactory.
>>
>> These changes should allow you to use a Stateful Session bean 
>> properly even  wtih passivation and activation happening.
>>
>> Regards,
>> Colin
>
>
> Colin and others,
>
> We've come across another issue to do with the passivation of beans. 
> While our stateful session bean holds an instance of the bean factory 
> itself (and can control re-initialising it), it is very possible that 
> other standalone beans have a copy of the bean factory as well. If the 
> stateful session bean has references to these other beans then it 
> becomes very difficult to handle.
>
> Is there any reason that the BeanFactory (and Loader) is not 
> serializable. It would make it much easier to handle if they were.
>
> Example of problem:
>
> StatefulSessionBeanA HAS BusinessBeanB HAS BusinessBeanC HAD DAOBeanD
>
> + The Stateful Session bean will load the BeanFactory and lookup 
> BusinessBeanB.
> + BusinessBeanB has the BeanFactory initialised through the 
> ApplicationContext.xml file.
> + BusinessBeanB looks up BusinessBeanC using the BeanFactory.
> + BusinessBeanC initialising DAOBeanD through the 
> ApplicationContext.xml file.
>
> In this case, the stateful session bean has problems serializing 
> BusinessBeanB due to the BeanFactory (XMLBeanFactory in this case).
>
> Any thoughts?
>
> Many thanks!
>
> Tim
>
> PS did you mean AbstractStatelessSessionBean or 
> AbstractStatefulSessionBean above? Stateless beans are not 
> passivated/activated.
>
Of course I meant AbstractStatefulSessionBean, not Stateless...

W/regards to making BeanFactory serializable, Rod and Juergen would 
probably be able to best answer as to why it's not. I can't see much of 
a reason, to tell you the truth, so it's probably just historical. 
ApplicationContext (or most of its implementations rather) can not be 
serializable due to all the non-serializable classes used. So whether 
making BeanFactory serializable is useful to you depends on where you 
are actually using just a BeanFactory, with basic serializable beans in 
it, or are in fact using an ApplicationContext, with AOP, and things 
like interceptors and transaction managers inside it.

Regards,
Colin

RE: [Springframework-developer] Description element in XML bean definitions

[Mark P. <mar...@co...>]

Hi,

It would be nice to access programatically if we expose any beans via
jmx...although we could also get the same functionality by using a
default "JavaDoc" attribute that would capture the comments from the
source code and expose them at runtime.... This might a good approach if
keeping these descriptions in sync is important.  It could be the
default mechanism if no other description is provided.

Cheers,
- Mark

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Rod Johnson
Sent: Tuesday, December 09, 2003 6:21 AM
To: spr...@li...
Subject: [Springframework-developer] Description element in XML bean
definitions


I've added optional <description> elements to allow user documentation
in XML bean definition documents.  The string values are not currently
available programmatically, although I'll add this if there's a
compelling reason. (I was tempted to add it anyway, but then I
remembered YAGNI!)

Following discussion on the web site, I've used an element
everywhere--no attributes.

Description can now be the first element for any beans, bean, property
or constructor-arg element, like this:

<beans>
    <description>
        Parent application context for my very special web application.
        Contains transactioin definitions...
    <description>

    <bean id="x" class="y">
        <description>My special x bean</description>
        <property name="foo">
            <description>xxxx</description>
           <value>bar</value>
        </property>
    </bean>

Thomas, can you please update the DTD on the web site?

Regards,
Rod




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's Free Linux Tutorials.  Learn everything from the bash shell to sys
admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Remaining bean factory suggestions?

[Mark P. <mar...@co...>]

Hi,

I was thinking to add this myself, but you are so quick at implementing
stuff maybe you would like to do it.  I really need (and added to my own
private branch) "Services" like functionality to have some classes go
through a full service lifecycle after all beans have been initialized.
These are for things like starting up a JMS connection and a JMX agent.
We spoke about this in the past, I could contribute my code and move it
in line with the suggestions you had in the past (if I could dig up that
email...)  I finally have time to devote to spring this week after a
long busy period..., so maybe we can agree on the format/scope if you
think it is a good idea.  I am using spring outside an app server
context, where these "mini-server" like issues are important.  Other
frameworks have them, Avalon and pico-container plus others I'm sure...

I envision something like this,

A Service interface, just like the JBoss one.  A specially named bean
"Services" that will have a comma delimited list of other bean names to
run through the lifecycle.

The interface is optional, you can also specify the method signatures
for "init, start, stop, dispose".  There is some overlap here with
integrating JMX, not only since the JMX agent should be started after
all beans are initialized but the services are typically to be managed
by JMX. =20



Cheers,
Mark



=20

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Tuesday, December 09, 2003 4:51 AM
To: spr...@li...;
spr...@li...
Subject: [Springframework-developer] Remaining bean factory suggestions?


Everybody,
=20
1.0 M3 already introduced significant reworkings and new features in the
bean factory / application context area, like support for autowiring.
1.0 M4 will go one step further, factoring out bean definition readers
into separate objects that work on a bean factory, and offering
autowiring of existing bean instances. After the M4 release in about a
week, our next goal is 1.0 RC1 in early January.
=20
On this occasion, I'd like to ask if we have missed any enhancements in
this area that have been suggested on the mailing lists or forums, not
only in terms of bean factory functionality but also in terms of
extensibility and pluggability. You're invited to check out the current
CVS contents, in particular the changelog, to find out what has already
been addressed. I've also tried to answer all corresponding mails and
postings - if something's left, please yell!
=20
Juergen
=20


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's Free Linux Tutorials.  Learn everything from the bash shell to sys
admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=CCk
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Reworkings and new features

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

jürgen höller [werk3AT] wrote:

>Everybody,
> 
>I've reworked quite significant parts in the last couple of days, and also added a few new features:
> 
>...
> 
>- I've added support for the "Open Session in View" pattern with Hibernate: OpenSessionInViewInterceptor is a HandlerInterceptor for Spring's web MVC, OpenSessionInViewFilter a generic Servlet 2.3 Filter. Both can simply be used together with HibernateTransactionManager or JtaTransactionManager: The latter will automatically detect the pre-bound Sessions and leave their lifecycle management to the original binder. In the course of implementing OpenSessionInViewFilter, I've also added generic Filter base classes, namely GenericFilterBean and OncePerRequestFilter. Those classes are now also used for MultipartFilter.
>
>  
>
Jürgen,

While I know people are always asking for the Open Session in View 
pattern support, I personally think it is a pretty dangerous pattern to 
use. As per the Hibernate docs,
  
http://www.hibernate.org/hib_docs/reference/html/manipulating-data.html#manipulating-data-s13-4
if Session throws an exception, the Session should be closed and 
discarded, as it will be inconsistent. The Open Session in View pattern 
will work ok if the view code ensures that once a Hibernate exception is 
handled no more db related code is used, but since the session handling 
is above all the other code, it does not enforce this in any way. In 
fact, if the view code is calling down to some service code that does 
the db access itself, the view code may not even know that db access is 
being done.

At a minimum, I recommend we annotate the Javadocs for these classes 
with a warning about this aspect...

Regards,
Colin

Re: [Springframework-developer] OpenSessionInViewFilter

[Matthew E. P. <ma...@me...>]

Juergen:
   FWIW: I am using the OpenSessionInViewFilter with Webwork2.

   Anyways, when the filter is applied, flushing never happens even when =
=20
using the transactionproxy factory.  If I remove the filter from the =20
web.xml, everything works perfectly.

   Any guesses?


Cheers,
   matthew

On Dec 9, 2003, at 7:03 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Matthew,
>
> TransactionProxyFactoryBean can just be used to proxy Spring-managed =20=

> Java objects: in the web case, at best a whole Controller. The view =20=

> rendering is initiated by DispatcherServlet, delegating to =20
> View.render. There is no single entry point in form of a =20
> Spring-managed bean to catch the whole request processing. But there =20=

> is the HandlerInterceptor facility to intercept that processing at =20
> various points.
>
> It's important to stress that OpenSessionInViewInterceptor for =20
> Spring's web MVC respectively OpenSessionInViewFilter for any web =20
> processing still lets Spring-managed business methods perform their =20=

> transactions as usual. The interceptor/filter just pre-binds a =20
> Hibernate Session that all transactions will use to the current =20
> thread, and which will stay open until view rendering has been =20
> completed.
>
> Your TransactionProxyFactoryBean setup should work, with or without =20=

> OpenSessionInViewFilter. Note that you need to access the "OSUserDao" =20=

> bean to get transactional behavior, not the "OSUserDaoTarget" =20
> directly. And you need to get the method pattern in the =20
> transactionAttributes right - in the simplest case, specify:
>
>          <property name=3D"transactionAttributes">
>              <props>
>                  <prop key=3D"*">PROPAGATION_REQUIRED</prop>
>              </props>
>          </property>
>
> That should open transactions for all methods, not just ones whose =20
> names start with "find" etc. And don't specify "readOnly" for =20
> transactions that should persist changes: "readOnly" will switch the =20=

> underlying Hibernate Sessions to FLUSH_NEVER. A good way is to start =20=

> with the general pattern above and go more fine-granular when you've =20=

> managed to make the general case work.
>
> Juergen
>
>
> -----Original Message-----
> From: Matthew E. Porter [mailto:ma...@me...]
> Sent: Tuesday, December 09, 2003 1:51 PM
> To: j=FCrgen h=F6ller [werk3AT]
> Subject: Re: [Springframework-developer] OpenSessionInViewFilter
>
>
> Juergen:
>    Here is what I currently have that is not working.
>
>      <bean id=3D"OSUserDaoTarget"
> =
class=3D"com.metissian.security.principal.provider.osuser.configuration.O=20=

> S
> UserManagerDAO">
>          <property name=3D"sessionFactory">
>              <ref local=3D"MetalSessionFactory"/>
>          </property>
>      </bean>
>
>      <bean id=3D"OSUserDao"
> =
class=3D"org.springframework.transaction.interceptor.TransactionProxyFact=20=

> o
> ryBean">
>          <property name=3D"transactionManager">
>              <ref local=3D"MetalTransactionManager"/>
>          </property>
>          <property name=3D"target">
>              <ref local=3D"OSUserDaoTarget"/>
>          </property>
>          <property name=3D"transactionAttributes">
>              <props>
>                  <prop =
key=3D"find*">PROPAGATION_REQUIRED,readOnly</prop>
>                  <prop key=3D"delete*">PROPAGATION_REQUIRED</prop>
>                  <prop key=3D"update*">PROPAGATION_REQUIRED</prop>
>                  <prop key=3D"save*">PROPAGATION_REQUIRED</prop>
>              </props>
>          </property>
>      </bean>
>
>
>    For some reason, I believed that wrapping an object in a
> TransactionProxyFactoryBean provided the transactionality you talked
> about.  Am I wrong?
>
>
> Cheers,
>    matthew
>
> On Dec 9, 2003, at 12:45 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>
>> Matthew,
>>
>> You should either use Spring-managed transactions (via
>> HibernateTransactionManager or JtaTransactionManager), which will
>> automatically flush a Session at transaction commit, or set
>> HibernateTemplate's/HibernateInterceptor's "flushMode" property to
>> FLUSH_EAGER (respectively "flushModeName" to "FLUSH_EAGER" in a
>> textual bean definition). This will guarantee to flush as early as
>> possible, not after view rendering: After all, a view should not
>> modify the model, so there should be no need to flush afterwards.
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag
>> von Matthew E. Porter
>> Gesendet: Di 09.12.2003 02:20
>> An: spr...@li...
>> Betreff: [Springframework-developer] OpenSessionInViewFilter
>>
>>
>>
>> I am attempting to use the OpenSessionInViewFilter.  According to the
>> javadoc, the session is not flush at the end of the filter.  =20
>> Therefore,
>> without overriding the closeSession() method in the filter, how do I
>> get the session to flush?  I am currently accessing DAOs wrapped as a
>> ProxyFactoryBean with a HibernateInterceptor.
>>
>> Please help!
>>
>>
>> Cheers,
>>    matthew
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IBM Linux Tutorials.
>> Become an expert in LINUX or just sharpen your skills.  Sign up for
>> IBM's
>> Free Linux Tutorials.  Learn everything from the bash shell to sys
>> admin.
>> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick=

>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IBM Linux Tutorials.
>> Become an expert in LINUX or just sharpen your skills.  Sign up for
>> IBM's
>> Free Linux Tutorials.  Learn everything from the bash shell to sys
>> admin.
>> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for =20=

> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys =20
> admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] OpenSessionInViewFilter

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

Matthew,

TransactionProxyFactoryBean can just be used to proxy Spring-managed =
Java objects: in the web case, at best a whole Controller. The view =
rendering is initiated by DispatcherServlet, delegating to View.render. =
There is no single entry point in form of a Spring-managed bean to catch =
the whole request processing. But there is the HandlerInterceptor =
facility to intercept that processing at various points.

It's important to stress that OpenSessionInViewInterceptor for Spring's =
web MVC respectively OpenSessionInViewFilter for any web processing =
still lets Spring-managed business methods perform their transactions as =
usual. The interceptor/filter just pre-binds a Hibernate Session that =
all transactions will use to the current thread, and which will stay =
open until view rendering has been completed.

Your TransactionProxyFactoryBean setup should work, with or without =
OpenSessionInViewFilter. Note that you need to access the "OSUserDao" =
bean to get transactional behavior, not the "OSUserDaoTarget" directly. =
And you need to get the method pattern in the transactionAttributes =
right - in the simplest case, specify:

         <property name=3D"transactionAttributes">
             <props>
                 <prop key=3D"*">PROPAGATION_REQUIRED</prop>
             </props>
         </property>

That should open transactions for all methods, not just ones whose names =
start with "find" etc. And don't specify "readOnly" for transactions =
that should persist changes: "readOnly" will switch the underlying =
Hibernate Sessions to FLUSH_NEVER. A good way is to start with the =
general pattern above and go more fine-granular when you've managed to =
make the general case work.

Juergen


-----Original Message-----
From: Matthew E. Porter [mailto:ma...@me...]
Sent: Tuesday, December 09, 2003 1:51 PM
To: j=FCrgen h=F6ller [werk3AT]
Subject: Re: [Springframework-developer] OpenSessionInViewFilter


Juergen:
   Here is what I currently have that is not working.

     <bean id=3D"OSUserDaoTarget" =20
class=3D"com.metissian.security.principal.provider.osuser.configuration.O=
S=20
UserManagerDAO">
         <property name=3D"sessionFactory">
             <ref local=3D"MetalSessionFactory"/>
         </property>
     </bean>

     <bean id=3D"OSUserDao" =20
class=3D"org.springframework.transaction.interceptor.TransactionProxyFact=
o=20
ryBean">
         <property name=3D"transactionManager">
             <ref local=3D"MetalTransactionManager"/>
         </property>
         <property name=3D"target">
             <ref local=3D"OSUserDaoTarget"/>
         </property>
         <property name=3D"transactionAttributes">
             <props>
                 <prop =
key=3D"find*">PROPAGATION_REQUIRED,readOnly</prop>
                 <prop key=3D"delete*">PROPAGATION_REQUIRED</prop>
                 <prop key=3D"update*">PROPAGATION_REQUIRED</prop>
                 <prop key=3D"save*">PROPAGATION_REQUIRED</prop>
             </props>
         </property>
     </bean>


   For some reason, I believed that wrapping an object in a =20
TransactionProxyFactoryBean provided the transactionality you talked =20
about.  Am I wrong?


Cheers,
   matthew

On Dec 9, 2003, at 12:45 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Matthew,
>
> You should either use Spring-managed transactions (via =20
> HibernateTransactionManager or JtaTransactionManager), which will =20
> automatically flush a Session at transaction commit, or set =20
> HibernateTemplate's/HibernateInterceptor's "flushMode" property to =20
> FLUSH_EAGER (respectively "flushModeName" to "FLUSH_EAGER" in a =20
> textual bean definition). This will guarantee to flush as early as =20
> possible, not after view rendering: After all, a view should not =20
> modify the model, so there should be no need to flush afterwards.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag  =

> von Matthew E. Porter
> Gesendet: Di 09.12.2003 02:20
> An: spr...@li...
> Betreff: [Springframework-developer] OpenSessionInViewFilter
>
>
>
> I am attempting to use the OpenSessionInViewFilter.  According to the
> javadoc, the session is not flush at the end of the filter.  =
Therefore,
> without overriding the closeSession() method in the filter, how do I
> get the session to flush?  I am currently accessing DAOs wrapped as a
> ProxyFactoryBean with a HibernateInterceptor.
>
> Please help!
>
>
> Cheers,
>    matthew
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for =20
> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys =20
> admin.
> Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for =20
> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys =20
> admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Passivating statefull session beans

[Tim M. <tec...@mo...>]

Colin Sampaleanu wrote:

> I've modified the EJB support code to allow a user subclass of 
> AbstractStatelessSessionBean to call a new method unloadBeanFactory() 
> from ejbPassivate (which it should implement itself). The subclass 
> should call the existing loadBeanFactory()  from ejbCreate() and 
> ejbActivate().   As well, the default implementation of ejbRemove which 
> is in AbstractEnterpriseBean now calls the new unloadBeanFactory() 
> method.     There is one change that may affect some existing code, and 
> that is that in the process of adding the above, I modified the existing 
> BeanFactoryLoader interface to handle unloading as well as loading of a 
> beanfactory.
> 
> These changes should allow you to use a Stateful Session bean properly 
> even  wtih passivation and activation happening.
> 
> Regards,
> Colin

Colin and others,

We've come across another issue to do with the passivation of beans. 
While our stateful session bean holds an instance of the bean factory 
itself (and can control re-initialising it), it is very possible that 
other standalone beans have a copy of the bean factory as well. If the 
stateful session bean has references to these other beans then it 
becomes very difficult to handle.

Is there any reason that the BeanFactory (and Loader) is not 
serializable. It would make it much easier to handle if they were.

Example of problem:

StatefulSessionBeanA HAS BusinessBeanB HAS BusinessBeanC HAD DAOBeanD

+ The Stateful Session bean will load the BeanFactory and lookup 
BusinessBeanB.
+ BusinessBeanB has the BeanFactory initialised through the 
ApplicationContext.xml file.
+ BusinessBeanB looks up BusinessBeanC using the BeanFactory.
+ BusinessBeanC initialising DAOBeanD through the ApplicationContext.xml 
file.

In this case, the stateful session bean has problems serializing 
BusinessBeanB due to the BeanFactory (XMLBeanFactory in this case).

Any thoughts?

Many thanks!

Tim

PS did you mean AbstractStatelessSessionBean or 
AbstractStatefulSessionBean above? Stateless beans are not 
passivated/activated.

[Springframework-developer] Description element in XML bean definitions

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

I've added optional <description> elements to allow user documentation in
XML bean definition documents.  The string values are not currently
available programmatically, although I'll add this if there's a compelling
reason. (I was tempted to add it anyway, but then I remembered YAGNI!)

Following discussion on the web site, I've used an element everywhere--no
attributes.

Description can now be the first element for any beans, bean, property or
constructor-arg element, like this:

<beans>
    <description>
        Parent application context for my very special web application.
        Contains transactioin definitions...
    <description>

    <bean id="x" class="y">
        <description>My special x bean</description>
        <property name="foo">
            <description>xxxx</description>
           <value>bar</value>
        </property>
    </bean>

Thomas, can you please update the DTD on the web site?

Regards,
Rod

[Springframework-developer] Remaining bean factory suggestions?

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

Everybody,
=20
1.0 M3 already introduced significant reworkings and new features in the =
bean factory / application context area, like support for autowiring. =
1.0 M4 will go one step further, factoring out bean definition readers =
into separate objects that work on a bean factory, and offering =
autowiring of existing bean instances. After the M4 release in about a =
week, our next goal is 1.0 RC1 in early January.
=20
On this occasion, I'd like to ask if we have missed any enhancements in =
this area that have been suggested on the mailing lists or forums, not =
only in terms of bean factory functionality but also in terms of =
extensibility and pluggability. You're invited to check out the current =
CVS contents, in particular the changelog, to find out what has already =
been addressed. I've also tried to answer all corresponding mails and =
postings - if something's left, please yell!
=20
Juergen
=20

Re: [Springframework-developer] Spring Wiki

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

Mike

Confluence sounds like an excellent option, especially as it's built on
Spring!

I think the problem with the old wiki was that it looked so unprofessional.
I'm sure you guys can manage something much better.

Regards,
Rod

----- Original Message ----- 
From: "Mike Cannon-Brookes" <mi...@at...>
To: "Spring" <spr...@li...>
Sent: Monday, December 08, 2003 10:24 PM
Subject: Re: [Springframework-developer] Spring Wiki


> I agree - the OpenSymphony wiki has been invaluble in generating useful
> documentation and 'cookbook' style information from users, in less than 6
> months it has truly become a very useful resource.
>
> If you're liking JIRA *g* we have another product coming up called
> Confluence which I'd be happy to host for Spring too. It's like a wiki but
> built on similar principles to JIRA (ease of use, inability to 'get things
> wrong', simplicity etc). It can export PDFs from collections of pages, so
> might be useful for documentation needs.
>
> Don't worry, no Camel Case unless you want to turn it on and the best
> part... it's built on Spring as one of the core components! :)
>
> Anyway - just an idea. +1 to get rid of the existing Wiki, but I think
that
> having 'some sort' of wiki is a good idea, websites get static very
quickly.
> In an Open Source project, Wiki's are a fantastic way to harness the
> community to generate documentation.
>
> Cheers,
> Mike
>
> On 9/12/03 5:16 AM, "Colin Sampaleanu" (col...@ex...) penned the
words:
>
> > I don't have an issue with removing this incarnation of the wiki. To
> > some extent though, I think the reasons people don't use it have to do
> > with visibility and ease of use. End-users do seem to use the Hibernate
> > wiki (which is also the web site) quite a bit, and I think that's
> > because it _is_ the web site, and it's easy to add stuff without the
> > CamelCase page names...
> >
> >
> > tri...@tr... wrote:
> >
> >> All,
> >>
> >> There is not a whole lot of activity on the wiki - I'd prefer to remove
the
> >> link
> >> to the wiki from the website and at some point turn off the wiki
itself.
> >> What
> >> do you all think, would you miss it?
> >>
> >> Thomas
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: IBM Linux Tutorials.
> >> Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
> >> Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
> >> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> >> _______________________________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Reworkings and new features

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

Everybody,
=20
I've reworked quite significant parts in the last couple of days, and =
also added a few new features:
=20
- I've dissolved support for ContextOptions, "config" objects exposed to =
the ServletContext, and UrlAwareHandler. They were all effectively =
undocumented and assumably completely unused.
=20
- WebApplicationContext initialization works via a =
ConfigurableWebApplicationContext interface now, instead of via =
constructor requirements (actually, this a second attempt: there have =
been separate interfaces for root and nested web application contexts =
last week). ConfigurableWebApplicationContext supports a =
"configLocations" property, to be able to override the default locations =
with specific ones. FrameworkServlet is able to drive this via its new =
"contextConfigLocation" property, potentially with multiple config files =
per servlet. XmlWebApplicationContext's and =
StaticWebApplicationContext's initialization procedure is completely =
reworked towards this.
=20
- I've introduced support for WebWork/Maverick-style "throwaway =
controllers", in addition to our existing Servlet/Struts-style reusable =
controllers. ThrowawayController and ValidatableThrowawayController in =
the web.servlet.mvc.throwaway package serve both as command and =
controller: They get populated with request parameters themselves and =
have execute methods to determine a ModelAndView - being completely =
unaware of the Servlet API. Obviously, they need to be defined as =
prototype beans in the DispatcherServlet context. As they have their own =
HandlerAdapters, they are very simply to set up, as they don't require =
Controller wrappers around them. Their main advantage as I see it =
testability: no need for Servlet API mocks for testing them, just like =
with WebWork actions. If you do need the Servlet API or more =
sophisticated workflows like session form objects, our "classic" =
controllers are the way to go.
=20
- I've added support for the "Open Session in View" pattern with =
Hibernate: OpenSessionInViewInterceptor is a HandlerInterceptor for =
Spring's web MVC, OpenSessionInViewFilter a generic Servlet 2.3 Filter. =
Both can simply be used together with HibernateTransactionManager or =
JtaTransactionManager: The latter will automatically detect the =
pre-bound Sessions and leave their lifecycle management to the original =
binder. In the course of implementing OpenSessionInViewFilter, I've also =
added generic Filter base classes, namely GenericFilterBean and =
OncePerRequestFilter. Those classes are now also used for =
MultipartFilter.
=20
- I've restructured the internals of the jdbc package: The JDBC-specific =
DataAccessException subclasses are now in the root jdbc package; =
SQLExceptionTranslator and associated classes are now in jdbc.support; =
the DataFieldMaxValueIncrementer stuff is in jdbc.support.incrementer. =
I've reworked the former QueryExecutor into the more generic =
NativeJdbcExtractor, in jdbc.support.nativejdbc: an abstraction to =
retrieve native JDBC objects from a connection pool that returns wrapped =
objects, with out-of-the-box SimpleNativeJdbcExtractor and =
CommonsDbcpNativeJdbcExtractor. A new feature is BlobCreator in =
jdbc.support.lob, with out-of-the-box DefaultBlobCreator and =
OracleBlobCreator.
=20
Please try your apps on the current CVS version, and possibly have a =
look at the new features. Feedback *before* the M4 release is very =
welcome :-)
=20
Juergen