In practice from a SE design standpoint you would claim Serializability within JavaDoc/spec. Serializable as marker interface is added on implementation level!
2014-12-27 11:18 GMT+01:00 Romain It w Manni-Bucau <[email protected]>: > So seems we agree to have only local handling in the api so no serializable > ;) > Le 27 déc. 2014 11:02, "Anatole Tresch" <[email protected]> a écrit : > > > Dear all > > i dont think it makes sense to make OropertySource serializable, because > > when its a dynamic one there is not much sense in doing so. What I > propose > > and have implemented is that you created a frozen instance of a source > > (containing the scannable parts ), which then is serializable. In most > > cases I nevertheless would expect some JSON/xml based format to tranfer > > property sources/config remotely ... > > Romain Manni-Bucau <[email protected]> schrieb am Sa., 27. Dez. 2014 > > um > > 10:52: > > > > > Well it should be but it shouldnt be serialized to let it be > injectable. > > > Having AppScope or equivalent sounds the main constraint when we ll > > > integrate it with IoCs. > > > Le 27 déc. 2014 10:45, "Mark Struberg" <[email protected]> a écrit : > > > > > > > What is the benefit of having all the things Serializable? > > > > > > > > > > > > Usually the configuration will be rebuilt on every node and if > > something > > > > needs to be serializable then only the configured values. The > > > configuration > > > > system itself imo doesn't need to be Serializable. And sometimes it's > > > even > > > > impossible/counter-productive to do so. E.g. sometimes the > > configuration > > > > differs depending on the cluster node you are on... > > > > > > > > LieGrue, > > > > strub > > > > > > > > > > -- *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 <%2B41-76%20344%2062%2079>*
