[cdi-dev] API Only PR for Context management

[John D. Ament]

On Mon, May 16, 2016 at 4:21 AM arjan tijms <arjan.tijms at gmail.com> wrote:

> 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.
>

That sounds like a separate issue.  We want all of the app servers to
behave the same way, I wouldn't expect this change to fix that, or even to
make it so that libraries could fix that.

Maybe there's a missing TCK assertion?


>
> 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 at gmail.com>
>> wrote:
>
> All,
>
> I've started a PR for API changes to support starting/stopping the built
>> in contexts, which you can find here:
>> https://github.com/cdi-spec/cdi/pull/291/files
>
> It's visibly based on what is in DeltaSpike's CDI Ctrl plus some of the
>> external stuff (e.g.
>> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/api/src/main/java/org/apache/deltaspike/scheduler/api/Scheduled.java#L40 )
>> so I'd like to get some input.
>
> 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 at 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.
>
>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160516/11acf123/attachment.html