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 <txmik...@gmail.com > <javascript:>> 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 clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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 clojure+u...@googlegroups.com <javascript:>. >> 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 clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com 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 clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
