This seems like something that could be handled with a special lifecycle, but I always have nagging questions.
For example, if you invoke a service and its is currently "failing", what does it do? What do the methods return? How do you know it is failing? To me, this is not something the container can or should solve; the service itself should (as Kalle pointed out) provide diagnostic methods and provide a strategy for dealing with failure. Tapestry mostly just instantiates things; that is not expected to fail. If you constructor is, for example, opening up a database connection, that may itself be a problem. My general approach would be to refactor out the "failable" parts into carefully isolated services. On Mon, Dec 10, 2012 at 12:00 PM, Kalle Korhonen <kalle.o.korho...@gmail.com > wrote: > On Mon, Dec 10, 2012 at 11:25 AM, Daniel Jue <teamp...@gmail.com> wrote: > > > I was wondering if there are some examples out there for handling > services > > that may intermittently fail or even fail to start up, which would > normally > > The idea is this: You have an application that connects to one or more > > external resources which may be unavailable at any time. In the case > that > > your service is unavailable, your application could either catch the > fault > > or otherwise have some introspection into the health of the service (your > > job to introspect at the appropriate points). This way your application > > could go into limp-mode and still carry on as much as possible. On > > subsequent requests, failed services that weren't properly realized would > > be re-tried (which I supposed could potentially lead to DOS situation) > > > > The times I've needed this I've implemented it as a stateful service, > rather than trying to make generic tapestry-ioc service infrastructure > fault tolerant. The majority of the service isn't going to need it and the > ones that are, will likely want to handle exceptions and their status > differently. Your service could have getStatus() or isRunning() operation > and if you see a similar need in other services, you could wrap the > operations under a unified interface. I'm doubtful that it'd be the right > approach to make Tapestry IoC handle this. Perhaps OSGi if you want > something more generic. > > Kalle > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
