already shared the link for xbean: https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-reflect/src/main/java/org/apache/xbean/propertyeditor/PropertyEditors.java and more particularly https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-reflect/src/main/java/org/apache/xbean/propertyeditor/CollectionUtil.java (of course this code is very old but the format shoudnt change). For spring it uses commons-lang code (fork surely?): http://grepcode.com/file/repo1.maven.org/maven2/org.springframework/spring-core/3.0.2.RELEASE/org/springframework/util/StringUtils.java#StringUtils.commaDelimitedListToSet%28java.lang.String%29
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-20 17:50 GMT+01:00 Anatole Tresch <[email protected]>: > Hi Romain > > 2015-01-20 17:39 GMT+01:00 Romain Manni-Bucau <[email protected]>: > >> to be honest I don't see where is the hard part here: >> 1) type registration: we adopt 2 registrations mode as for property sources >> 1a) direct mode MyImpl -> use reflection (or meta if we want to be >> verbose) to get the Type >> > > -> Once more: Reflection will not work. The other things tbd. > > > >> 1b) kind of provider where we pass a context which register in the >> config (config context ATM) the converter: >> >> public class MyConverters implements ConvertersProvider { >> public void registerConverters(ConverterBootsrapContext ctx) { >> ctx.register(new MyTypeLiteral<List<String>>() {}, new >> MyConverter(true, 1)); >> } >> } >> > > -> No this apporach is not part of the current API. We can register > directly PropertyConverter. There is no such thing like > a ConverterProvider. If so we could add the target type to the > ConverterProvider I agree. That was one of my proposals. > > > > 2) about list, map etc modelling: here we don't have much the choice >> we should just do what is common (and if we still think to a spec this >> is the way to go instead of thinking we are better than everything >> existing). References I commonly use or used are xbean and spring and >> both are more or less aligned. >> > > Just a short personal advice: If you want people to have an idea about > what to you talk you should either copy some code or at least add some > direct links to the APIs you are talking of. If not your efforts will be > not reflected. Most of the guys do not have time to search the exact > locations of what you are talking about ;( > > 3) agree about events but this one should be tackled after the first >> release IMO >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-20 17:28 GMT+01:00 Anatole Tresch <[email protected]>: >> > I think guys we really have more important things to discuss than these. >> > There are wuestion open about how to deal with type registration for >> > ProeprtyConverters, list property modelling and we did not even started >> > with event handling. I propose you guys put your energy on these tasks >> and >> > stop restarting the same discussion again and again. >> > >> > 2015-01-20 17:17 GMT+01:00 Romain Manni-Bucau <[email protected]>: >> > >> >> yep, our build is complicated and we finally dont propose anything >> >> valuable thanks to it so why continuing this way? >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-01-20 17:06 GMT+01:00 Werner Keil <[email protected]>: >> >> >> >> >> >> >> >> >> >> >> >> In all cases you break java 8 lambdas, not an issue by itself but we >> >> >> should maybe think removing this java 8 module which will soon be >> only >> >> >> justified by Optional which is highly controversed. >> >> >> >> >> >> >> >> > What exactly do you mean by that, do you suggest merging the codebase >> >> here >> >> > because except for Optional there is little value of a Java 8+ >> >> approach?;-) >> >> >> > >> > >> > >> > -- >> > *Anatole Tresch* >> > Java Engineer & Architect, JSR Spec Lead >> > Glärnischweg 10 >> > CH - 8620 Wetzikon >> > >> > *Switzerland, Europe Zurich, GMT+1* >> > *Twitter: @atsticks* >> > *Blogs: **http://javaremarkables.blogspot.ch/ >> > <http://javaremarkables.blogspot.ch/>* >> > >> > *Google: atsticksMobile +41-76 344 62 79* >> > > > > -- > *Anatole Tresch* > Java Engineer & Architect, JSR Spec Lead > Glärnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > <http://javaremarkables.blogspot.ch/>* > > *Google: atsticksMobile +41-76 344 62 79*
