@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 <[email protected]>: > 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 <[email protected]> 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 <[email protected]>: >> > >> > 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 < >> [email protected]>: >> >> >> >> 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 >> >> >> > >> >>
