Igor, I think that letting Spring handle transactions in your service methods sounds like the ideal solution. No transaction code in the web framework.
However, for my current project I do not use Spring or an EJB container so I need to handle transaction boundaries myself. In these cases it is still nice to have transaction handling code somewhere (in one place) so I don't need to think about it at all. Just realised that DefaultExceptionResponseProcessor is final so I will need to use delegation instead of inheritance to add my transaction support to the default error page behaviour. This whole thing is getting VERY messy! So I am back to where I was before - I can struggle to implement this with many subclassed objects etc OR I could simply override one method to catch exceptions. I know which solution is quickest, easiest to understand and maintain. I feel like the framework is working against me here! Can you please explain to me why you prefer the complicated method I described before? I just don't get it. And I don't like to customise core framework code which becomes a maintenance nightmare. Cheers, John On Saturday 17 Dec 2005 19:24, Igor Vaynberg wrote: > On 12/17/05, John Patterson <[EMAIL PROTECTED]> wrote: > > Ahh yes this does sound like a better approach. I have never used Spring > > before. a couple of questions: > > > > Can you call multiple operations on your service interfaces in the same > > transaction? Or is this not done? > > yes. if you mark your service method as PROPOGATION_REQUIRED it will join a > transaction if one exists, or start a new one if one doesnt. > > you can also specify what types of exceptions should or should not rollback > the transaction, by default any runtime exception will. > > spring has excellent documentation of all the propogation modes/exception > handling. > > it also has excellent annotation support which drastically cuts down on the > size of the xml file if you are lucky enough to be building on jdk5. > > Can you leave the hibernate session open for the view to be rendered? > > > yes, you either add an OpenSessionInView filter to web.xml or an > OpenSessionInterceptor to the context. both are provided by spring. > > > wicket-contrib-phonebook is an example of a wicket/spring/hibernate app if > you are interested. > > we also provide, what i think, is a pretty good spring integration support > in wicket-contrib-spring. you can see it in phonebook, the gist is here: > http://www.wicket-wiki.org.uk/wiki/index.php/Spring > > there is also a wicket-contrib-spring-jdk5 which makes integration even > more transparent. > > -Igor ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
