Reading again I would really encourage to write a short proposal ;) I think we are not far away from each other... ---------- Forwarded message --------- From: Anatole Tresch <atsti...@gmail.com> Date: Sa., 6. Dez. 2014 um 10:25 Subject: Re: "annotation" instead of "annot" To: <dev@tamaya.incubator.apache.org>
Sure? A @Config qualifier cannot be isolated (without additional qualifiers), so given 2 configurations all change events sre sent to each observer. Additionally using a qualifier adds a dependency to cdi for the Qualifier meta annotation. Given that we are at square. 0 again: diy... And last I think it is not good to reinvent cdi (though some similarities/intersections cannot be avoided. Also this makes it clearer in a cdi context, which functionality is provided by which part. Finally Imo config is a more general concept. We should not try to build it on top of cdi, but use the parterns like ioc/events as well and ensure it interoperates with cdi, java ee well. Perhaps you can do a short code proposal here on the mail (api only). I am not sure if all people here on the list are so familiar with cdi...;) Chees Anatole Romain Manni-Bucau <rmannibu...@gmail.com> schrieb am Sa., 6. Dez. 2014 um 10:02: actually with CDI 1.0 we can already do advanced things using a Config > qualifier so we can send the event to listeners of 1 bean, 1 area, 1 > property... > > Only issue is: how do we do in standalone. I would design it the same > way but without the @Observes (= need configBus.register(myListener). > > wdyt? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-06 9:47 GMT+01:00 Anatole Tresch <atsti...@gmail.com>: > > I know ;) Looking at the integration with CDI, where we do probably parts > > of the injection ourself (especially to support CDI earlier to CDI 2.0), > I > > would propose @ConfigUpdate (working title) to be a config related > feature. > > We can additionally publish any *ConfigChange *events on the CDI bus/to > > Spring listeners. *ConfigChange *is already designed in a way, where I > can > > evaluate, which config is affected. That way I think we have both the > nice > > features for configuration and seemless integration for components that > > want to listen on the "standard" event buses. If we get filtering event > > listeners in CDI 2.0 we might have additional possibilities open... > > > > 2014-12-06 9:40 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > > > >> The point is the "bus" design is different "by framework". Standalone > >> -> DIY, CDI -> @Observes with an event you expect and config > >> management is delegated to another bean (in the idea), Spring -> > >> listener interface... > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2014-12-06 9:26 GMT+01:00 Anatole Tresch <atsti...@gmail.com>: > >> > I would like to see a similar feature set in SE only as well as with > >> > CDI/Spring. Also the listener/event functionality will probably not be > >> 100% > >> > similar as in CDI (I see use cases, where an instance is only > informed on > >> > config changes affecting the instance, but not the rest of the > system). I > >> > also struggled with the name of this annotation, but let it be since I > >> knew > >> > we will discuss on it for sure here... As an alternative we could also > >> call > >> > it differently, e.g. @ConfigUpdate . > >> > > >> > WDYT? > >> > > >> > 2014-12-06 8:43 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > >> > > >> >> Ok. Wonder if the listener annotation makes sense btw. We can use an > >> >> interface in standalone and I am sure we ll strongly type it to > >> integrate > >> >> it with spring cdi etc.. giving the property change event and the > config > >> >> object instance. > >> >> > >> >> Wdyt? > >> >> Le 6 déc. 2014 02:13, "Anatole Tresch" <atsti...@gmail.com> a écrit > : > >> >> > >> >> > Hi all > >> >> > > >> >> > I would simply put all into a package called *mapping*, based on > the > >> >> > discussions we had this looks most feasible for me For met that > looks > >> >> good. > >> >> > If we have more event related annotations, we might reconsider > adding > >> an > >> >> > additional one. > >> >> > > >> >> > WDYT? > >> >> > > >> >> > Anatole > >> >> > > >> >> > > >> >> > 2014-12-05 19:44 GMT+01:00 Romain Manni-Bucau < > rmannibu...@gmail.com > >> >: > >> >> > > >> >> > > annotation or annotations? :p. > >> >> > > > >> >> > > More seriously: what's the issue with "mapping" for @ConfiguredX, > >> >> > > @WithX - we'll surely need to rename it to something more > >> intuitive - > >> >> > > and dynamic, event, listener for @ConfigChangeListener? > >> >> > > > >> >> > > > >> >> > > Romain Manni-Bucau > >> >> > > @rmannibucau > >> >> > > http://www.tomitribe.com > >> >> > > http://rmannibucau.wordpress.com > >> >> > > https://github.com/rmannibucau > >> >> > > > >> >> > > > >> >> > > 2014-12-05 19:26 GMT+01:00 Oliver B. Fischer < > >> o.b.fisc...@swe-blog.net > >> >> >: > >> >> > > > +1 because it helps us to find what we need... IMHO > >> >> > > > > >> >> > > > Am 05.12.14 15:38, schrieb Otávio Gonçalves de Santana: > >> >> > > >> > >> >> > > >> full name is really better. > >> >> > > >> "org.apache.tamaya.annotation", > >> >> > > >> > >> >> > > >> On Wed, Dec 3, 2014 at 11:51 AM, Werner Keil < > >> werner.k...@gmail.com > >> >> > > >> >> > > >> wrote: > >> >> > > >> > >> >> > > >>> Hi, > >> >> > > >>> > >> >> > > >>> Looking not only at Java EE ( > >> http://docs.oracle.com/javaee/7/api/) > >> >> > > you'll > >> >> > > >>> find plenty of packages from "javax.annotation" to > >> >> > > >>> "javax.servlet.annotation", etc. > >> >> > > >>> > >> >> > > >>> I already raised this to Anatole before Tamaya, that > >> >> > > >>> "org.apache.tamaya.annot" should be called > >> >> > > >>> "org.apache.tamaya.annotation", > >> >> > > >>> too. > >> >> > > >>> > >> >> > > >>> Anybody against that?;-) > >> >> > > >>> > >> >> > > >>> I could also create a JIRA ticket for that. > >> >> > > >>> > >> >> > > >>> Werner > >> >> > > >>> > >> >> > > >> > >> >> > > >> > >> >> > > > > >> >> > > > -- > >> >> > > > N Oliver B. Fischer > >> >> > > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > >> >> > > > P +49 30 44793251 > >> >> > > > M +49 178 7903538 > >> >> > > > E o.b.fisc...@swe-blog.net > >> >> > > > S oliver.b.fischer > >> >> > > > J oliver.b.fisc...@jabber.org > >> >> > > > 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* > >> >> > > >> >> > >> > > >> > > >> > > >> > -- > >> > *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* >
