Re: Puppet Labs and Trapperkeeper
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.
Re: Puppet Labs and Trapperkeeper
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 txmik...@gmail.com 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 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 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. 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
Re: Puppet Labs and Trapperkeeper
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 txmikes...@gmail.com 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 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. -- 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.
Re: Puppet Labs and Trapperkeeper
We published a follow-up post this morning, with a lot more detail on the Clojure side of things: https://puppetlabs.com/blog/clojure-nerds-puppet-labs-application-services On Sunday, April 13, 2014 6:48:10 PM UTC-7, Walter Heck wrote: As a non-clojure user, but a Puppet expert (ahum ;) ) I wrote a blog post about this announcement that might be interesting for some folks here. I'd also love to see comments on the post itself if I have drawn any wrong conclusions: http://www.olindata.com/blog/2014/04/clojure-outsiders-investigation On Sunday, 13 April 2014 16:24:28 UTC+2, Brendan Younger wrote: I just saw that there's a library called TrapperKeeper https://github.com/puppetlabs/trapperkeeper from the folks at Puppet Labs. It looks to be a more opinionated and complete version of Stuart Sierra's Component library https://github.com/stuartsierra/component, in that it explicitly pays attention to things like logging configuration and JBoss support. Brendan Younger -- 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.
Re: Puppet Labs and Trapperkeeper
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 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.
Puppet Labs and Trapperkeeper
I just saw that there's a library called TrapperKeeper https://github.com/puppetlabs/trapperkeeper from the folks at Puppet Labs. It looks to be a more opinionated and complete version of Stuart Sierra's Component library https://github.com/stuartsierra/component, in that it explicitly pays attention to things like logging configuration and JBoss support. Brendan Younger -- 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.
Re: Puppet Labs and Trapperkeeper
related http://puppetlabs.com/blog/new-era-application-services-puppet-labs On Monday, 14 April 2014 00:24:28 UTC+10, Brendan Younger wrote: I just saw that there's a library called TrapperKeeper https://github.com/puppetlabs/trapperkeeper from the folks at Puppet Labs. It looks to be a more opinionated and complete version of Stuart Sierra's Component library https://github.com/stuartsierra/component, in that it explicitly pays attention to things like logging configuration and JBoss support. Brendan Younger -- 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.
Re: Puppet Labs and Trapperkeeper
As a non-clojure user, but a Puppet expert (ahum ;) ) I wrote a blog post about this announcement that might be interesting for some folks here. I'd also love to see comments on the post itself if I have drawn any wrong conclusions: http://www.olindata.com/blog/2014/04/clojure-outsiders-investigation On Sunday, 13 April 2014 16:24:28 UTC+2, Brendan Younger wrote: I just saw that there's a library called TrapperKeeper https://github.com/puppetlabs/trapperkeeper from the folks at Puppet Labs. It looks to be a more opinionated and complete version of Stuart Sierra's Component library https://github.com/stuartsierra/component, in that it explicitly pays attention to things like logging configuration and JBoss support. Brendan Younger -- 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.
