Cilquirm. That's really helpful! Thans a lot! I can understand the most part your post and I still have question for the last sentense.
"For those that you do, reattach them early on, and watch your transaction boundaries. " The session is open, why do I need to reattach them? And could you please be more specific about the 'watch transaction boundaries'. Sorry, that might be stupid questions. Really appreciate your help and time. cilquirm wrote: > > Assuming your S2 actions are 'pathed' differently ( i.e. s2 actions are > mapped to .action , while s1 actions are mapped to .do ), then specifying > the url pattern only for s2 actions ( /*.action ) will have the intended > effect. > > As far as side effects go, it's really dependent on your application. The > ones they mention on the docs relate to moving an application that hasn't > been using open session in view to that pattern. You may have objects > that you keep around for a long time ( i.e. in a http session ), which > you then reattach to the session when you want to do do work against it. > When you have ad-hoc session management, you might have gotten away with > reattaching/detaching/flushing/updating whenever you feel like it because > you're creating a new hib session whenever you need to.. > > With OSFV, since the session is already created upon request, you may end > up with a couple exceptions because the session is always there and those > operations ( depending on when you do it, and in what order ) may throw > exceptions. > > At best I can tell you, as the docs do, is to minimize the objects you > keep around for a while. For those that you do, reattach them early on, > and watch your transaction boundaries. > > Ask away if you have particular questions :-) > > hth, > -a > > panpan wrote: >> >> Thank you cilquirm. I think i'm a little bit confused and the filter is >> the one I needed. >> There is one thing which is unclear to me. If I only apply the filter to >> the new developed struts2 action, it will not affect the rest existed >> application(struts1), right? I saw there are some side effect of using >> the OSVF in the Spring docs. Do you have any good idea how to avoid those >> side effects? >> Thanks again! >> >> >> >> >> cilquirm wrote: >>> >>> I think you may be confusing Struts2 (S2) interceptors with Spring >>> Interceptors. >>> The two are not the same. >>> >>> S2 interceptors provide some "aop-like" functionality by allowing code >>> to modify request processing in some fashion; however it's not truly >>> based around an aop standard ( i.e. aopallliance ) ( s2 devs, please >>> feel free to correct and chide me. ) >>> >>> The OpenSessionInViewInterceptor ( OSVI ) is an analog to the >>> OpenSessionInViewFilter (OSVF), but I belive it's primarily used for >>> SpringMVC ( and possibly related, like Grails ). >>> >>> OSVF is more generic and designed to be used in a larger number of >>> frameworks. >>> I believe, in this case, what you probably want is the filter. >>> >>> hth, >>> -a >>> >>> >>> >>> >>> >>> >>> panpan wrote: >>>> >>>> Thank you Toni for your example. >>>> I'm just wondering about the OpenViewInSessionInterceptor. Don't know >>>> how to configure it in struts2. >>>> >>>> Thanks again! >>>> >>>> >>> >> >> > > -- View this message in context: http://www.nabble.com/-S2--how-to-configure-Spring%27s-OpenViewInSessionInterceptor-for-struts2-tf4050042.html#a11508283 Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
