Just some ideas out of my head ... Meybe focusing more on a hibernate connection provider can make your problem easier. c3p0 : http://sourceforge.net/projects/c3p0 might be extensible enough.
Since Hibernate sessions are, or should be used per thread and not retained for a long period. for configuration that needs reload create your own services to provide it. Tapestry is about static structure and dynamic behaviour, so if you can keep the static structure ... no need for reload. these are just some ideas... Davor Hrg On Jan 21, 2008 7:13 PM, Franz Amador <[EMAIL PROTECTED]> wrote: > Actually, for me there is something above. My use case is unusual. Our > customers often belong to large organizations that have autocratic IT > departments. The customer buys and is responsible for our app, but IT owns > and controls access to the hardware. Simple things like editing config > files, viewing logs, and restarting the app become difficult. The customer > must schedule time with IT, and only IT can make the changes. > > Accordingly, I'm trying for "IT-free" installation, configuration, and > maintenance. All IT does is set up the box, install the app server and > database, and drop in our war file. The customer completes the installation > and does all subsequent configuration and maintenance *through the app*. > This means the app must be able to start without a working database > connection, allow the customer to specify that connection, and then switch to > using the new connection, all without a restart (which would require IT). > The app must also be able to fall back to a minimal "safe mode" if the > database connection later fails, such as when IT changes the database > password, which some do monthly. > > Amazingly, I've found a way to actually do this. I wrapped TapestryFilter in > a filter of my own (I suppose the GoF would call it a decorator). My > filter's init method inits TapestryFilter, which, of course, brings up the > IOC registry. I have a service which uses Hibernate during its > initialization, so if Hibernate can't talk to the database, it dies. The > exception propagates up through the IOC registry and TapestryFilter to my > filter, which discards the TapestryFilter instance (and thus the IOC > registry), adjusts the Hibernate settings to safe mode (i.e. hsqldb), and > creates a new TapestryFilter. The app can then allow login via a special > admin account (which is defined in a file so it works without a database). > The admin fixes the database parameters, and my filter discards the safe-mode > TapestryFilter and creates yet another new TapestryFilter using the new > parameters. If that fails, back to safe mode and try again. > > This all works hunky dory, provided that when Hibernate fails I get the > exception. Usually I do, but if the failure happens during the ending > commit, ThreadCleanupHubImpl.cleanup swallows it, per my original message, > and my filter has no way of knowing that something went wrong. I understand > your point, though, that all services must be allowed to finish their > cleanups. Perhaps ThreadCleanupHubImpl could save any exception and re-throw > it after it's done. > > As a last add-on to an already overlong note, I wonder if there's a more > elegant way of achieving my goal. Perhaps there's some way of discarding and > recreating only those services that depend, directly or indirectly, on > Hibernate, rather than tossing the entire IOC registry and TapestryFilter. I > do get an error message when I do this, as somebody (I forget who) retains a > weak static reference to part of the IOC registry and complains at what > appears to be my attempt at creating two registries. > > > ----- Original Message ---- > From: Howard Lewis Ship <[EMAIL PROTECTED]> > To: Tapestry users <users@tapestry.apache.org> > Sent: Sunday, January 20, 2008 9:01:07 AM > Subject: Re: T5.0.7: ThreadCleanupHubImpl.cleanup swallows exceptions > > > By the time it executes, it is too late to render a response with the > exception. There's nothing that can catch the exception ... the only > thing "above" ThreadCleanupHubImpl is the servlet and then the servlet > container. Further, it is very important that every cleanup listener > be invoked, or you could experience some memory leaks in the > application, as threads hold onto objects inside ThreadLocals. > > On Jan 11, 2008 2:33 PM, Franz Amador <[EMAIL PROTECTED]> wrote: > > ThreadCleanupHubImpl.cleanup (line 53) catches exceptions thrown by > service initialization cleanup. It logs them, which is good, but it > doesn't pass them up, which is causing me problems. I want to know if > Hibernate initialized successfully, but this prevents me from seeing > exceptions thrown during the transaction commit in > HibernateSessionManagerImpl.threadDidCleanup. Is this an oversight or is > there a design goal of > having the Registry come up no matter what? > > > > > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
