#1
the test-module supports execution without scope-handling already and for
the scheduler module you added it yourself.
-> i'm not sure about your issue here...

#2
if you suggest a cdi-interceptor, then i don't agree at all -> -1 because
it leads to an extra config step (at least for weld-users) and imo there is
no real benefit which justifies it.
even encapsulating the logic in helper/util classes won't improve a lot for
the existing use-cases, because the common parts aren't that huge.

e.g.
in case of the schedule module you start scopes per scheduler-job.
in case of the test-module you can start scopes per test-method or a whole
test-class (more exotic, but sometimes needed e.g. to fill read-only caches
just once per test-class).

however, if you have an approach which keeps the flexibility without
introducing an additional config-step (per default), i would be happy to
see a prototype (based on [1]).

regards,
gerhard

[1]
http://deltaspike.apache.org/suggested-git-workflows.html#discussion-workflow-optional



2014-09-10 2:42 GMT+02:00 John D. Ament <[email protected]>:

> Hi all,
>
> I was looking through our code base and I noticed one interesting theme -
> currently we have several different ways to annotate methods to cause
> scopes to start - namely scheduler and TestControl; as well as a sevlet
> listener (my fault).  i was wondering if it makes more sense to add a
> capability to CdiCtrl to start a scope, via annotation, and remove
> (deprecate) from the other modules?  I was thinking it would also help in
> case you want to use these features without starting scopes.
>
> WDYT?
>
> John
>

Reply via email to