batchee-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject bye bye security service?
Date Wed, 17 Aug 2016 14:41:17 GMT
Hi guys,

Mark and Reinhard spotted a perf issue in getJobNamed() - basically we were
fetching all jobs to then filter the names.

Origin is the ability to filter the shown jobs per *id*. This was very
flexible cause it allows to get job metadata and filter with all these
meta. In these meta you have jbatch meta (name, startedAt etc..) but also
user meta since the id is accessible through the batch so it can be used
for business logic as well.

Reviwing the security service usage it seems to me we could drop it
completely since I think we should enable to secure JobOperator and nothing
under that level to give business value to the security API.

So here is the proposal I have:

- to not break users who could rely on that we keep current SecurityService
API for next release (R) but @Deprecate it (impl can use shortcuts/flags to
deactiavte it for jobNames temporarly)
- in release R+1 we completely remove it
- *if* we get request to secure JobOperator we build a security either on
top of JobOperator or directly on persistence layer (= at query level and
not java level which prevents any perf optim).

Any objection? Other idea?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message