You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "John D. Ament" <jo...@gmail.com> on 2014/09/10 02:42:46 UTC
General purpose start scopes interceptor
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
Re: General purpose start scopes interceptor
Posted by Gerhard Petracek <ge...@gmail.com>.
i'm talking about the bda-rules and their implementation in weld.
furthermore, the majority of users would need to use an additional
annotation without a real benefit.
(+ they would need to enable the interceptor)
moreover, in case of dependent scoped beans an interceptor forces a proxy
-> you get the proxy-overhead in addition.
regards,
gerhard
2014-09-14 16:14 GMT+02:00 John D. Ament <jo...@gmail.com>:
> Can you explain what weld specific issue you're referring to?
>
> On Wed, Sep 10, 2014 at 4:10 AM, Gerhard Petracek <
> gerhard.petracek@gmail.com> wrote:
>
> > #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 <jo...@gmail.com>:
> >
> > > 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
> > >
> >
>
Re: General purpose start scopes interceptor
Posted by "John D. Ament" <jo...@gmail.com>.
Can you explain what weld specific issue you're referring to?
On Wed, Sep 10, 2014 at 4:10 AM, Gerhard Petracek <
gerhard.petracek@gmail.com> wrote:
> #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 <jo...@gmail.com>:
>
> > 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
> >
>
Re: General purpose start scopes interceptor
Posted by Karl Kildén <ka...@gmail.com>.
Hrrmm I have not used the scheduler, but it looks like you don't really
start scopes in the docs?
For test-control it feels pretty natural the way it is now imo. No idea
about the Servlet Listener, what module / feature is that?
On 10 September 2014 10:10, Gerhard Petracek <ge...@gmail.com>
wrote:
> #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 <jo...@gmail.com>:
>
> > 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
> >
>
Re: General purpose start scopes interceptor
Posted by Gerhard Petracek <ge...@gmail.com>.
#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 <jo...@gmail.com>:
> 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
>