@Romain

Can explain to me what difference it will make (what the fix does)
On Feb 28, 2015 3:49 PM, "Romain Manni-Bucau" <[email protected]> wrote:

> PS: to be complete CDI 1.x, x > 0 added destroy(X) in Instance API to fix
> it
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-02-28 11:20 GMT+01:00 Karl Kildén <[email protected]>:
>
>> Got it, thanks all!
>>
>> On 27 February 2015 at 19:54, John D. Ament <[email protected]>
>> wrote:
>>
>>> It's a good approach, I do something similar at times.  However, you
>>> need to make sure the beans have scopes to avoid this memory leak.
>>>
>>>
>>> On Fri, Feb 27, 2015 at 1:47 PM Karl Kildén <[email protected]>
>>> wrote:
>>>
>>>> Hrmm not sure what you mean. This is not a framework it is business
>>>> logic and I really like to put validators in a list like this instead of if
>>>> else if else if else if
>>>>
>>>> On 27 February 2015 at 19:37, Romain Manni-Bucau <[email protected]
>>>> > wrote:
>>>>
>>>>> Mark will surely say you that configuring anyThingCriterion will make
>>>>> your iterable size (if i can say it) = 1 even if you have 100 criterions 
>>>>> ;)
>>>>>
>>>>> this is not a real spi
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>> <https://www.linkedin.com/in/rmannibucau>
>>>>>
>>>>> 2015-02-27 19:34 GMT+01:00 Karl Kildén <[email protected]>:
>>>>>
>>>>>> Hi John!
>>>>>>
>>>>>> Summary: we use it as iterable
>>>>>>
>>>>>> Long story for completeness:
>>>>>>
>>>>>> Basically we get a thing from our business partner (inputThing) and
>>>>>> map it to our representation of thing (ProcessedThing)
>>>>>>
>>>>>> Each ThingCriterion can veto the processedThing and then they used
>>>>>> inputThing to print a pretty error message. When the Thing is enhanced
>>>>>> (happens all the time) we implement new ThingCriterion  and they get 
>>>>>> picked
>>>>>> up automatically...
>>>>>>
>>>>>>
>>>>>>
>>>>>>     @Inject
>>>>>>     private Instance<ThingCriterion> thingCriteria;
>>>>>>
>>>>>>
>>>>>>     public List<ValidationProblem> validateList(final ProcessedThing
>>>>>> thing, final InputThing inputThing) {
>>>>>>         List<ValidationProblem> results = new ArrayList<>();
>>>>>>         for (final ThingCriterion criterion : thingCriteria) {
>>>>>>             results.addAll(criterion.validate(thing, inputThing));
>>>>>>         }
>>>>>>         return results;
>>>>>>     }
>>>>>>
>>>>>>
>>>>>> Romain,
>>>>>>
>>>>>> Thanks for your help. Great suggestion will it have better perf then
>>>>>> just putting @ApplicationScoped on my ThingCriterion beans? Probably not
>>>>>> important just curious.
>>>>>>
>>>>>> cheers
>>>>>>
>>>>>> On 27 February 2015 at 19:25, Romain Manni-Bucau <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> When I used this pattern I always did (for perf reason but side
>>>>>>> effect is  behavior is what you want):
>>>>>>>
>>>>>>> @PostConstruct
>>>>>>> private void resolve() {
>>>>>>>    value = instance......get();
>>>>>>> }
>>>>>>>
>>>>>>> then in the code don't use instance at all but value.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>>> <https://www.linkedin.com/in/rmannibucau>
>>>>>>>
>>>>>>> 2015-02-27 19:15 GMT+01:00 John D. Ament <[email protected]>:
>>>>>>>
>>>>>>>> Are you calling get() on the Instance with each request (or
>>>>>>>> whatever0 that comes into this bean?
>>>>>>>>
>>>>>>>> On Fri, Feb 27, 2015 at 1:13 PM Karl Kildén <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> To explain myself further ALL I had on my heap was my
>>>>>>>>> Instance<MyInterface>... and gc released 0.5% memory :)
>>>>>>>>>
>>>>>>>>> I had 200 000 of them at least. They where supposed to be four
>>>>>>>>> singletons. My idea was inject into @ApplicationScoped and omit to 
>>>>>>>>> give
>>>>>>>>> them scope because they will be @ApplicationScoped anyways... Seems 
>>>>>>>>> every
>>>>>>>>> invocation of my @ApplicationScoped bean recreated all instances.
>>>>>>>>>
>>>>>>>>> What I had was unrecoverable mem leak. Now I could be doing
>>>>>>>>> something stupid or Instance<MyInterface> has a problem or something 
>>>>>>>>> else...
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 27 February 2015 at 19:05, Romain Manni-Bucau <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> If dependent it will be kept in enclosing bean.
>>>>>>>>>>  Le 27 févr. 2015 19:00, "Lars-Fredrik Smedberg" <
>>>>>>>>>> [email protected]> a écrit :
>>>>>>>>>>
>>>>>>>>>> So does this mean that there will be a memory leak in the case
>>>>>>>>>>> Karl described?
>>>>>>>>>>>
>>>>>>>>>>> I have used similar constructs before so im curios (@Inject
>>>>>>>>>>> @Provider <some dep scoped bean> in an @ApplicationScoped bean and 
>>>>>>>>>>> called
>>>>>>>>>>> get () on the injected provider).
>>>>>>>>>>>
>>>>>>>>>>> I thought for a while that it might get garbage collected when
>>>>>>>>>>> the created bean is outof scope or maybe then there is no way for
>>>>>>>>>>> @PreDestroy to be called?
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> LF
>>>>>>>>>>>
>>>>>>>>>>> I thought that the created dep scoped bean would be
>>>>>>>>>>> On Feb 27, 2015 6:07 PM, "Romain Manni-Bucau" <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Yes.
>>>>>>>>>>>>
>>>>>>>>>>>> Will be destoyed with the bean where it is injected IIRC so the
>>>>>>>>>>>> app here.
>>>>>>>>>>>> Le 27 févr. 2015 16:59, <[email protected]> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello! I have a bean with @ApplicationScoped. When I inject
>>>>>>>>>>>>> Instance<MyInterface> instance and my actual beans implementing 
>>>>>>>>>>>>> MyInstance
>>>>>>>>>>>>> are dependentscoped they get recreated over and over and are not 
>>>>>>>>>>>>> gc'd.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Expected behavior?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>

Reply via email to