I'd also like to see the HTTP header module brought into the core. Palantir also has their own module that allows configuring the headers at https://github.com/palantir/dropwizard-web-security
-Justin On Wednesday, May 1, 2019 at 3:09:26 PM UTC-4, babc...@umich.edu wrote: > > While I'd prefer and wait until after 2.0 is out before including them > into dropwizard, these modules seem well thought out: finer grained > healthchecks with the ability to have them cached, and deeper support for > HTTP headers seem great! > > How backwards compatible are these changes? > > Are you thinking submitting the healthcheck code against the metrics repo, > the dropwizard repo, or a new repo under the dropwizard organization? > > On Monday, April 29, 2019 at 6:52:01 PM UTC-5, mza...@apple.com wrote: >> >> > We would publish these apps using the Apache License 2.0, as all other >> Dropwizard projects do. >> >> Not apps, libraries. :) >> >> On Monday, April 29, 2019 at 4:49:33 PM UTC-7, mza...@apple.com wrote: >>> >>> Hey Jochen! >>> >>> >>> > Do you have a list and description of the modules you're planning to >>> open-source? >>> >>> We do! >>> >>> >>> So we have three modules that we think make sense to live in the core >>> Dropwizard project. Two of which are in a pretty ready state to be >>> contributed, but because 2.0.0 is already in RC stage, might not make sense >>> until that ships. >>> >>> >>> The ones we have are: >>> >>> >>> >>> - A module containing a bundle that allows for configuration of >>> various headers that are important for services that are accessed by web >>> browsers. This includes: HTTP Strict Transport Security (HSTS), >>> X-Frame-Options, X-Content-Type-Options, X-XSS-Protection (XSS), Content >>> Security Policy (CSP), and Cross-Origin Resource Sharing (CORS). >>> - A module containing a more-feature rich and extendable admin page, >>> in short. This would need a little bit more work before we could >>> contribute >>> it, because there’s some cleanup work we’d need to do, and some changes >>> to >>> make it more flexible in how it’s used. >>> - A bundle containing improved health check functionality. Provides >>> functionality to allow a user to associate a schedule with any >>> registered >>> health checks to run on a recurring basis, and to allow marking which >>> checks are critical to service health (i.e., if a dependency is down, it >>> should bring the service down with it). The bundle then allows exposing >>> another health check URL on the server port, which simply returns the >>> aggregated view of the application’s health, rather than trigger checks >>> on >>> every health check. >>> >>> >>> We also have some additional potential contributions that we don’t think >>> would make sense to live in the core Dropwizard project, but rather >>> (hopefully) could live in the Dropwizard organization. Our reasoning for >>> including these would be that we already maintain these internally, and >>> keep them up to date with the underlying client libraries we’re wrapping, >>> AND we do so in a consistent way, so we figured it might make sense to >>> broaden the audience for these, as there’s no good reason not to. >>> >>> >>> >>> - A module providing integration with Kafka. >>> - A module providing integration with Redis. >>> - A module providing integration with Cassandra. >>> - A module providing integration with FoundationDB. >>> >>> >>> There may be some others I’m missing here, that we may propose down the >>> line, but this should be the majority of what we’d like to publish >>> initially. >>> >>> >>> > Also, what license are they currently under or which licenses do you >>> plan to use for them? All projects under the Dropwizard umbrella are using >>> the Apache License 2.0. >>> >>> Are there any other things to consider copyright- or license-wise when >>> you're contributing these modules? >>> >>> >>> We would publish these apps using the Apache License 2.0, as all other >>> Dropwizard projects do. >>> >>> >>> > And finally, do you plan to keep contributing to the modules you're >>> going to open-source or will it be more or less a "code drop" without any >>> further involvement? >>> >>> >>> We plan to keep contributing to the modules we contribute. We maintain >>> these internally on an ongoing basis already, so we’d just continue to do >>> so. >>> >>> On Sunday, April 28, 2019 at 2:23:09 PM UTC-7, Jochen Schalanda wrote: >>>> >>>> Hi Michael, >>>> >>>> Thanks for reaching out! >>>> >>>> Depending on the specific modules, it might make sense to adopt them in >>>> the Dropwizard organization on GitHub. Alternatively, you can also host >>>> them in your own accounts and add them to the module directory at >>>> https://modules.dropwizard.io/, as Nick described in his last email. >>>> >>>> Do you have a list and description of the modules you're planning to >>>> open-source? >>>> >>>> Also, what license are they currently under or which licenses do you >>>> plan to use for them? All projects under the Dropwizard umbrella are using >>>> the Apache License 2.0. >>>> Are there any other things to consider copyright- or license-wise when >>>> you're contributing these modules? >>>> >>>> And finally, do you plan to keep contributing to the modules you're >>>> going to open-source or will it be more or less a "code drop" without any >>>> further involvement? >>>> >>>> >>>> Best regards, >>>> Jochen >>>> >>>> Am 27.04.2019 um 23:14 schrieb mzamani via dropwizard-dev < >>>> dropwiz...@googlegroups.com>: >>>> >>>> Hey dropwizard-dev, >>>> >>>> We've got some modules we'd like to open source that we use internally >>>> at Apple. Some of those might make sense to be included in the core >>>> Dropwizard project, but others definitely don't, and it would make much >>>> more sense to have them live outside of the Dropwizard repo. >>>> >>>> We're hoping we might be able to contribute these to the Dropwizard >>>> organization (https://github.com/dropwizard) instead, as that seems >>>> like a place where it would make sense for Dropwizard extensions to live. >>>> However, we wanted to consult you guys to see if you had any strong >>>> preferences one way or another, or if there's any process we should be >>>> aware of in order to add a project to the Dropwizard GitHub organization. >>>> >>>> It might be worth mentioning that it would be easier for us to open >>>> source them if they can live in the Dropwizard organization, rather than a >>>> brand new spot, due to how our corporate open source policy works. >>>> >>>> Thanks! >>>> >>>> -- You received this message because you are subscribed to the Google Groups "dropwizard-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
