@Mark: lambda are serializable (java.lang.invoke.SerializedLambda)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-08 13:03 GMT+02:00 John D. Ament <johndam...@apache.org>:

> On the subject of serializable.  We fail one of the comments in the MP
> Spec (but not in the TCK!) our injected Config class is *not* serializable.
> But for that to work, all config sources and all converters must be
> serializable.
>
>
> On Tue, Aug 8, 2017 at 6:57 AM Mark Struberg <strub...@yahoo.de> wrote:
>
>> Another thing I noticed:
>>
>> While using a Lambda as impl for Provider is very elegant, it still
>> misses an important functionality: it is not Serializable, and thus
>> injecting a @ConfigProperty Provider<String> into a @SessionScoped bean
>> would blow up at runtime.
>>
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 08.08.2017 um 12:35 schrieb Mark Struberg <strub...@yahoo.de>:
>> >
>> > I fear that's exactly not possible. CDI resolves with type + qualifier.
>> Since the type is not unique (mulitple Provider<String>) you would need to
>> make the Qualifier unique. Means for each of them you need to dynamically
>> create a new binding ConfigProperty Implementation.
>> > There are 2 problems:
>> > a.) I have no clue how you can dynamically remove the @Nonbinding from
>> the ConfigProperty annotation.
>> > b.) you have to register tons of such qualifiers, which makes the whole
>> resolving slower again. You just moved the effort from the Bean#create to
>> BeanManager#getBeans, that's all
>> >
>> > LieGrue,
>> > strub
>> >
>> >> Am 08.08.2017 um 12:16 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>> >>
>> >> b.) the default naming (name="") would break it anyway. You again
>> would need to create dynamic qualifiers for each of those injection points.
>> >>
>> >> Not true since you handle it in the extension precomputing it
>> >>
>> >
>>
>>

Reply via email to