Hi,
I think what you're asking for is to intercept at the container
level and
change how they initialize. I'm curious, under what cases do you not have
an active request?
My primary case is to compensate for container differences regarding a
ServerAuthModule (JSR 196/JASPIC). Such ServerAuthModule is called before
the first Servlet Filter is, and gets an HttpServletRequest passed in. In
many servers (JBoss, GlassFish, TomEE) the CDI default scopes (request,
session, etc) are active at that point, but not in all (Liberty, WebLogic).
With this proposed API a library such as Soteria could possibly start those
scopes earlier on Liberty and WebLogic and do nothing on JBoss, GlassFish
and TomEE.
Kind regards,
Arjan Tijms
In addition, I think you're looking for the equivalent of
Context.isActive. Part of me even wonders if swapping around the impl to be
Context.activate() and Context.deactivate() may be better from a domain
standpoint.
What I'm looking for is a way to start contexts possibly earlier than a
> specific container implementation normally starts them, and stop them
> possibly later. If the context is started earlier in say a request, then
> eventually the container will also start that same context later in the
> request. If that will throw an exception the request will not proceed,
> which is of course not intended.
> Likewise, when the container stops the context this will thus be too
> early.
> With a wrapped context controller, the startContexts and stopContexts
> calls can be ignored for those contexts the application (extension/library)
> wanted to start earlier and stop later. This does of course assume that the
> container itself will also use this context controller instead of the
> current proprietary code.
> Additionally, the PR does not contain the check anymore to see if the
> context is already active or already stopped. Is that still intended to be
> added? This would be particularly useful for code that needs to be portable
> between different containers, where one container may already have started
> the context at a given point, where another container has not (catching the
> exception would be an alternative here but is obviously not so nice).
> Another point, what about letting the caller of the startContexts method
> optionally pass in the objects (or a lambda to obtain them) on which that
> context primarily depends (if any). E.g. for the request scope, pass in an
> HttpServletRequest instance.
Would it be an idea to set a wrapped (or decorated) context controller?
On Sun, May 15, 2016 at 6:33 PM, John D. Ament
<john.d.ament(a)gmail.com
wrote:
All,
I've started a PR for API changes to support starting/stopping the built in
It's visibly based on what is in DeltaSpike's CDI Ctrl plus some of the
I don't suspect that this will be an SE only feature, today I use
programmatic context starting even while on an app server. Even
though I'm
not using whats provided in DS, it was identified as a clear cross cutting
concern hence why there's an interceptor as well.
John
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.