Thanks! No concrete plans around any sort of hot code swapping for now. That gets into lots of classloader stuff that, to be honest, seems like it adds a lot of complexity that we'd like to avoid. Also, we are deploying all of our apps as uberjars for the time being, so we don't have a concrete use case for swapping out an individual service jar for now.
I'd love to see trapperkeeper be able to support this kind of thing for users who are interested in it, but I'd envision that a lot of the implementation would be done as a separate, optional TK service that wouldn't be mandatory for users who didn't feel they needed to introduce the extra complexity. (There'd probably be a few changes necessary to the core framework to support such a service, though.) I think it would be fairly easy to write a notification/restart service that could drop into the existing framework today, for things like reloading a service when configuration changes. Loading up new code for a running service would be more challenging. Anyway, it's something that we're definitely keeping in mind and would be interested in hearing ideas about how it might look, but no concrete plans. Next few things on our list are: making the jetty9 service support multiple jetty instances (e.g. to support running two web apps on two different ports, with different SSL configurations), a new service that allows you to configure all of your web routes in a single place, and some plumbing work to improve the way we're currently interacting with Prismatic Graph. On Friday, May 30, 2014 6:40:02 AM UTC-7, Sarwar Bhuiyan wrote: > > I really like it. It reminds me of OSGi Declarative Services where we use > the @Reference to inject stuff in. Also the init, start, and stop are > really nice in keeping with the OSGi component interface without all its > other baggage. Keep it up. > > I was wondering if you had any ideas on solving the zero-downtime > deployment/redeployment problem? In OSGi, individual bundles can be updated > individually and that could in effect be used to do some form of > zero-downtime deployments in the sense that only the services that need to > restart will restart based on the dependency tree. Of course, it might not > work for all cases and we might need some form of rolling restarts as well. > Just wondering if you had any ideas or plans around that for Trapperkeeper. > > Thank you. > > Sarwar > > On Tuesday, April 15, 2014 4:55:09 PM UTC+1, Chris Price wrote: >> >> Yep, you've pretty much nailed it... the design was heavily inspired by >> the OSGi service registry, but we didn't really have a need for most of the >> other functionality that OSGi offers. So we basically just came up with a >> way to describe services via Clojure protocols, and then we wire them >> together with Prismatic graph (thanks, Prismatic!). Hope folks find it >> useful! >> >> >> On Mon, Apr 14, 2014 at 9:24 PM, Mike Haney <[email protected]> wrote: >> >>> Great timing on the new blog post. I'm ramping up on my first "real" >>> clojure app, and have been planning to use Component for this piece. I >>> read the first blog post yesterday and it sounded interesting, but I've >>> pretty much locked down the stack I'm going to use (you can evaluate >>> libraries forever, but at some point you just have to stop looking and pick >>> one to go with). >>> >>> But after reading the new post, I think it's worth taking a look at >>> Trapperkeeper. Even if I don't switch now, if all goes well I would like >>> to turn this app into a larger SaS offering, possibly multi-tenant, and I >>> could see something like Trapperkeeper helping there. >>> >>> I get the distinct impression you have some former OSGI users on your >>> team? This reminds me a lot of the service registry in OSGI. And I don't >>> mean that as an insult - the service registry was the best part, it was all >>> the other crap that made it painful to use (particularly anything from >>> eclipse, which ruined OSGI in my opinion, but that's another rant). >>> >>> Anyway, this looks like something that could be useful in many cases, >>> and thank you for open-sourcing it. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to [email protected] >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
