On 4 January 2018 at 14:19, Steve Ebersole wrote:
> Well there seems to be some disagreement about that. I personally think we
> do not need anything other than a pre-shutdown hook so that we can release
> our CDI references. Sanne seemed to think we needed something more
> "integrated". I thin
On 4 January 2018 at 16:39, Sanne Grinovero wrote:
> On 4 January 2018 at 14:19, Steve Ebersole wrote:
>> Well there seems to be some disagreement about that. I personally think we
>> do not need anything other than a pre-shutdown hook so that we can release
>> our CDI references. Sanne seemed
Well there seems to be some disagreement about that. I personally think we
do not need anything other than a pre-shutdown hook so that we can release
our CDI references. Sanne seemed to think we needed something more
"integrated". I think we should start with the simple and add deeper
integratio
I can arrange to keep access to the specific
ExtendedBeanManager/LifecycleListener,
that is not difficult.
What changes do we need from the CDI implementation?
On Jan 3, 2018 4:36 PM, "Steve Ebersole" wrote:
If you have access to the specific ExtendedBeanManager/LifecycleListener,
that should a
If you have access to the specific ExtendedBeanManager/LifecycleListener,
that should already be enough. Those things are already properly scoped to
the SessionFactory, unless you are passing the same instance to multiple
SessionFactory instances.
On Wed, Jan 3, 2018 at 10:09 AM Scott Marlow wro
On Tue, Jan 2, 2018 at 2:42 PM, Steve Ebersole wrote:
> Scott, how would we register a listener for this event?
>
If we want a standard solution, we could ask for an earlier CDI pre-destroy
listener.
The problem we have had with most CDI "listeners" so far is that they are
> non-contextual, mea
Scott, how would we register a listener for this event? The problem we
have had with most CDI "listeners" so far is that they are non-contextual,
meaning there has been no way to link that back to a specific
SessionFactory.. If I can register this listener with a reference back to
the Sessionfact
On Wed, Dec 20, 2017 at 9:48 AM, Sanne Grinovero
wrote:
> Any dependency injection framework will have some capability to define
> the graph of dependencies across components, and such graph could be
> very complex, with details only known to the framework.
>
> I don't think we can solve the inte
On 20 December 2017 at 15:08, Yoann Rodiere wrote:
>> we need to find a way to have the DI framework
>> take in consideration our additional components both in terms of DI
>> consumers and providers
>
> Not sure what you mean by that. Currently the DI framework doesn't know who
> uses these compon
> we need to find a way to have the DI framework
> take in consideration our additional components both in terms of DI
> consumers and providers
Not sure what you mean by that. Currently the DI framework doesn't know who
uses these components, and therefore it's up to us to tell the DI framework
w
Any dependency injection framework will have some capability to define
the graph of dependencies across components, and such graph could be
very complex, with details only known to the framework.
I don't think we can solve the integration by having "before all
others" / "after all others" phases a
11 matches
Mail list logo
