Hi see my answers inline:
Anatole 2015-04-11 22:47 GMT+02:00 Oliver B. Fischer <[email protected]>: > Hi guys, > > sorry, I know it is already late, but here are the topics from our last > hangout: > > * - Do we need a type literal? We assume that we don't need it know. > Therefore we will remove it from the API. But we can keep it in the core > module* > -1: Possible, but it may require collection support to depend on core, which I think is not a better alternative, or collection support to introduce another dependency to have TypeLiteral in again, which also may add additional artifacts not making the overall size smaller. Additionally there are several code parts in core making use of it. The ones that want to remove it, have to adapt all code (in Java 7 and Java 8) and ensure all tests run well again ;) > * - Do we really need ConfigOperator and ConfigQuery? If yes, we need a > much better documentation for both to illustrate their usage* > -1: These concepts have proven to be very effective for attaching external functionality to a given artifact, especially when programming in a more functional styles (JSR 310 and JSR 354 are using them for example). They allow additional functionality to be added very easily, which I think is a very important aspect, when thinking on writing modules that extend/add functionality to Tamaya. As an example every kind of views, subsets that are use case specific (they depend on state not managed by Tamaya and it makes no sense to implement them as filters acting more generally) can be implemented using operators. E.g. think on the following example: Configuration config = ...; Configuration areasOnly = config.with(ConfigVIews.selectAreas("com.mycomp.*", "legacy.*.settings.*")); Similarly you can use the same mechanism to perform configuration filtering based on the current user's role, e.g. within a servlet filter: Configuration config = ...; Configuration userConf = config.with(ConfigVIews.selectAreas("com.mycomp.*", "legacy.*.settings.*"); The configuration query basically targets a similar mechanism but is more flexible, e.g. one might write a ObjectFactory that creates/instantiates preconfigured objects: MyConfiguredObject o = ConfigurationProvider.getConfiguration().with(MyObjectFactory.of(MyConfiguredObject.class); Summarizing these 2 simple (functional) interfaces have shown to be very effective and elegant regarding future extensions. So I would strictly vote against removing them (you have to do a vote ;) ). * - We should remove the explicit provided PropertyConverter in the > Configuration interface. Afterwards we can move the PropertyConverter to > the SPI package* > +1: As said this is basically possible, since I can access a value simply as String and do any customized conversion later... * - It might be usefull to document the maturity of the single parts of the > API. There are two possible ways to achive this: a) via annotations and b) > via JavaDoc* > For me *use JavaDoc *as done by other JSRs. I agree that a common annotation would be nicer, since more explicit, but as of now there is no such annot in the JDK, so we should not add one ourselves. > * - Our documentation and how all parts of Tamaya play together. Often we > must explain the same decisions again and again* > I started to write quite a couple of things and guides and also tried to keep the homepage as much updated as I have time. The last 2 weeks time was somehow rare because I prepared the final release of JSR354. This was submitted yesterday, so thinks should now significantly improve again... >From my talk at Javaland there is a small component like diagram and a couple of simplicistic examples, which I think is a good start... Feel free to join me ;) > Did I miss something? > > Bye, > > Oliver > > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E [email protected] > S oliver.b.fischer > J [email protected] > X http://xing.to/obf > > -- *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*
