| commit | 103f794ed126e135f2fe0ff1bde04a4093413521 | [log] [tgz] |
|---|---|---|
| author | Bill Farner <wfarner@apache.org> | Thu Dec 07 09:50:22 2017 -0800 |
| committer | Bill Farner <wfarner@apache.org> | Thu Dec 07 09:50:22 2017 -0800 |
| tree | a43b12cb4675996cb79074bbc346aa2a2196b6d9 | |
| parent | 2754636c674a9912475edafe01669602125fbee3 [diff] |
Update to guice 4.1.0, switch from jersey to resteasy Upgrading guice was the original goal with this patch, which pulled along several other dependencies. Guice 3 [suffers from obscure errors](https://github.com/google/guice/issues/757) when creating binding error messages with java 8 and lambdas. This has been a frequent source of frustration since we first upgraded to java 8 mid-2015. I've gone spelunking down this path numerous times, and frequently hit a wall with jersey. We needed to upgrade jersey-guice, to upgrade jersey, to upgrade guice. jersey introduced their own dependency injection (HK2) in jersey 2.0, which complicated matters. There have been some promising developments since (hk2-guice [bridge](https://javaee.github.io/hk2/guice-bridge.html#bi-directional-hk2-guice-bridge), 2.26 [abstracted HK2](https://jersey.github.io/release-notes/2.26.html), and several [projects](https://github.com/Squarespace/jersey2-guice) have emerged to solve the issue). Unfortunately, each avenue failed with some combination of not working well with our application design, or i just plain couldn't get it working. I began to look beyond jersey. This left restlet and resteasy as the most common alternatives. I balked early at restlet due to their guice integration being [apparently](https://github.com/restlet/restlet-framework-java/commits/master/modules/org.restlet.ext.guice) [dormant](https://stackoverflow.com/questions/8227583/what-is-the-status-of-org-restlet-ext-guice). Fortunately i achieved some early wins with resteasy! Migrating was straightforward with a small patch based on some examples. However, i hit a hurdle with shiro-guice. It [needed to be updated](https://issues.apache.org/jira/browse/SHIRO-493) to work with guice 4, and there were some necessary API changes. No big deal, just the `filterConfig()` nesting you see in this patch. This revealed a deeper issue with binding custom `Filter`s with `ShiroWebModule`. Previously, `ShiroWebModule` would effectively only `bind()` keys [they define](https://github.com/apache/shiro/blob/f326fd3814f672464deb11c3dadadb27af618eec/support/guice/src/main/java/org/apache/shiro/guice/web/ShiroWebModule.java#L65-L86), allowing the API user to `bind()` custom keys. The [patch](https://github.com/apache/shiro/commit/f2dfa7ff39c9870e7b9856ceca8690c5398080fa#diff-359a7b20d3b7fdcc0ffce11ad57d6e1c) to support guice 4 changed that, and `bind()` will be [called](https://github.com/apache/shiro/commit/f2dfa7ff39c9870e7b9856ceca8690c5398080fa#diff-359a7b20d3b7fdcc0ffce11ad57d6e1cR183) on these custom keys. In our case, this caused a duplicate binding. The simplest workaround to this was to avoid `bind()`ing the custom `afterAuthFilter` key, and use the custom type as the key type (e.g. `Key.get(CountingFilter.class)` rather than `Key.get(Filter.class)`). Lastly, `GuiceResteasyBootstrapServletContextListener` does not integrate with `GuiceServletContextListener` in the way `GuiceFilter` [demands](https://github.com/google/guice/blob/e7bef34ef6379735e2a58df1b23f351bb7e30e44/extensions/servlet/src/com/google/inject/servlet/ServletModule.java#L322-L323), which necessitated the passing of `ServletContext` you see in this patch. I can't say i'm happy with the outcome here, but i am overall happier given that guice is upgraded. Reviewed at https://reviews.apache.org/r/64362/
Apache Aurora lets you use an Apache Mesos cluster as a private cloud. It supports running long-running services, cron jobs, and ad-hoc jobs. Aurora aims to make it extremely quick and easy to take a built application and run it on machines in a cluster, with an emphasis on reliability. It provides basic operations to manage services running in a cluster, such as rolling upgrades.
To very concisely describe Aurora, it is like a distributed monit or distributed supervisord that you can instruct to do things like run 100 of these, somewhere, forever.
Aurora is built for users and operators.
User-facing Features:
Under the hood, to help you rest easy:
Aurora can take over for most uses of software like monit and chef. Aurora can manage applications, while these tools are still useful to manage Aurora and Mesos themselves.
However, if you have very specific scheduling requirements, or are building a system that looks like a scheduler itself, you may want to explore developing your own framework.
Are you using Aurora too? Let us know, or submit a patch to join the list!
If you have questions that aren‘t answered in our documentation, you can reach out to one of our mailing lists. We’re also often available in IRC: #aurora on irc.freenode.net.
You can also file bugs/issues in our JIRA queue.
Except as otherwise noted this software is licensed under the Apache License, Version 2.0
Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.