[Hawkular-dev] Hawkular Commons 0.7.3.Final released

[Lukas Krejci]

On Friday, June 10, 2016 10:24:33 AM Stefan Negrea wrote:
> Hello,
> 
> Thanks for the clarifications and the PR for Metrics. I looked at the code
> and module they are really minimal, nice work!
> 
> In the long run Metrics would benefit from adopting it however at this time
> the project is not ready to get additional external dependencies. I closed
> the PR for now, we will reopen the PR once we are ready to adopt the filter.
> 

With the pending PR https://github.com/hawkular/hawkular-commons/pull/77 the 
tenant filter introduces no new dependency compared to what metrics is already 
depending on.

I assume that would remove all the barriers for you to adopt a common way of 
handling tenants in all Hawkular components?

> 
> Thank you,
> Stefan Negrea
> 
> Software Engineer
> 
> 
> On Fri, Jun 10, 2016 at 1:36 AM, Juraci Paixão Kröhling <
> 
> jpkroehling at redhat.com> wrote:
> > On 10.06.2016 05:07, Stefan Negrea wrote:
> >> Can you please give more details about the proposed changes to use the
> >> Commons filter in other projects? What dependencies need to be
> >> introduced? Where is the filter located (module, code)?
> > 
> > The tenant filter is a JAX-RS filter and the dependency is defined as
> > org.hawkular.commons:hawkular-tenant-jaxrs-filter [1]. It's a "pure" Java
> > EE module, depending on nothing else.
> > 
> > All you need to do is to have your WAR module depending on this filter
> > module and the filter will be applied automatically to all JAX-RS
> > endpoints
> > in your application. If you have an endpoint or method that you don't want
> > to protect, use the `@TenantRequired(false)` annotation.
> > 
> > 1 - https://git.io/vosci
> > 
> > Also, what are the implications of not using the filter from Commons?
> > 
> > 
> > If you don't use the filter, you risk having a different behavior when
> > comparing to other modules. For instance, you might return JSON when no
> > JSON is expected (or vice-versa), or you might have a slightly different
> > semantic than the current agreement, ...
> > 
> > - Juca.

-- 
Lukas Krejci