Try to use Unmanaged e.g for injecting into unit test instances ;)
> Am 25.09.2016 um 20:57 schrieb John D. Ament <[email protected]>:
>
> On Sun, Sep 25, 2016 at 12:30 PM Mark Struberg <[email protected]>
> wrote:
>
>>> Basically, one sticking target I see continually is BeanManagerProvider.
>> We already use CDI.current() internally if it is available (via
>> reflection).
>> So no need to upgrade it just for this feature.
>
> Reflection is inherently slower than direct method calls. Hence slows down
> deltaspike's execution. I'll also note that:
>
> - It implies that we need a wrapper. It would be great if we didn't.
> - Its second in the list, first is JNDI. JNDI will work generally
> everywhere but SE apps.
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/provider/BeanManagerProvider.java#L224
>
>
>>
>>
>>> but its because we didn't make a DS version
>>
>>> that was CDI 1.1+ compatible.
>> Nope, ALL our versions since day one are CDI-1.1+ compatible.
>> And we also already make use of a few important features. But only via
>> reflection.
>
> I'll clarify this - we didn't release a DS version that was only CDI 1.1+
> compatible. We've always carried around the "baggage" of CDI 1.0.
>
>
>>
>>
>>
>>
>>> features like manual injection of fields, which
>>
>>> could be replaced by Unmaanaged.
>>
>> I don't like Unmanaged as it can easily create mem leaks. It is imo as
>> unnecessary as @New used to be...
>> I already expressed my concerns in the EG, but it's too late to get rid of
>> it now.
>> Also note that Unmanaged always creates a newInstance while the DeltaSpike
>> utility method injects into a given EXISTING instance. That is a *huge*
>> difference.
>
> CDI's pretty funny, its the only spec I can think of that inherently
> creates memory leaks. Unmanaged shouldn't create memory leaks. Maybe the
> underlying problem is that the impls treat it as a dependent scoped bean?
>
> Anyways, most cases I've seen for BeanProvider.injectFields uses this
> format:
>
> SomeBean someBean = BeanProvider.injectFields(new SomeBean(someOtherDep));
>
> E.g. the object isn't really valid until the injection points are satisfied.
>
>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>> On Sunday, 25 September 2016, 17:37, John D. Ament <
>> [email protected]> wrote:
>>>> On Sun, Sep 25, 2016 at 11:34 AM Thomas Andraschko <
>>> [email protected]> wrote:
>>>
>>>> not sure if a cdi2-module is enough
>>>> we should also get rid of some of our api's which are in CDI 2.0 now
>>>
>>> Yes. I agree. Basically, one sticking target I see continually is
>>> BeanManagerProvider. Maybe we keep it around as a utility and for
>>> backwards compatibility, but its now available as CDI.current(), to do
>>> programmatic look up.
>>>
>>> In addition, there are features like manual injection of fields, which
>>> could be replaced by Unmaanaged. I know as a user of CDI 1.2, seeing
>> both
>>> available makes me confused, but its because we didn't make a DS version
>>> that was CDI 1.1+ compatible.
>>>
>>> John
>>>
>>>
>>>
>>>>
>>>> 2016-09-25 17:28 GMT+02:00 Romain Manni-Bucau
>>> <[email protected]>:
>>>>
>>>>> 2016-09-25 17:22 GMT+02:00 John D. Ament
>>> <[email protected]>:
>>>>>
>>>>>> Hey guys,
>>>>>>
>>>>>> Since its inception, DeltaSpike has targeted Java EE 6 and lower,
>>> and
>>>> as
>>>>> a
>>>>>> result the CDI 1.0 runtime. We have maintained a pretty
>>> backwards
>>>>>> compatible code base for 5 years now.
>>>>>>
>>>>>> CDI 2.0 is going to wrap up in January, if current schedules
>>> align
>>>>>> correctly.
>>>>>>
>>>>>> I'd like to propose that we start a branch for 2.0
>>> development now. It
>>>>>> would be a good place to put fixes for
>>>>>> https://issues.apache.org/jira/browse/DELTASPIKE-1206 and other
>>>>>> enhancements that we can make to our core runtime to better
>>> integrate
>>>>> with
>>>>>> CDI 1.1/1.2/2.0 features that have been added. In addition to
>>> the
>>>> Java 8
>>>>>> upgrade taking place there.
>>>>>>
>>>>>> We can keep master on 1.x for patches that may be needed for the
>>> 1.x
>>>>> line,
>>>>>> and rebase them with a 2.0 branch to make sure both branches get
>>> the
>>>>> fixes.
>>>>>>
>>>>>> WDYT?
>>>>>
>>>>> What feature do we target and need CDI 2.0 for it? If none I think we
>>>> don't
>>>>> need the branch yet, if enough we should also think to have a cdi2
>>> module
>>>>> to avoid to fork code while 1.0/1.1 is maintained
>>>>>
>>>>>
>>>>>>
>>>>>> John
>>
