William and all-- I'm sorry this reply is so late; it was the long weekend here in the States and some urgent stuff at $work.
Firstly, thanks William very much! Your advice was wonderfully helpful. I had been tinkering along after I wrote my last email and I had come to what I think is the same as your first conclusion: that it's worth investing in some framework to wire up CDI and JAX-RS instead of wrestling them oneself. I had already chosen Thorntail (Wildfly Swarm) and had a semi-working example, in which JAX-RS and CDI and Tamaya were all starting correctly up together. But I just couldn't find anything but nulls in my @Config-ured fields. Sounds familiar? :) But it hadn't occurred to me at all that constructor and field injection couldn't be ordered as I would need-- I should have realized that if the constructor hadn't run, how would the CDI impl code get a reference to an object to inject? I hadn't done the reading I should have. Your second point about the injection schedule got me working. (It's the main branch in that repo now.) Now that I understand what was happening, I see that there is no test case here; I've submitted a doc patch via Github. Thanks again-- I have a working application using Tamaya now. ajs6f > On Sep 1, 2018, at 8:33 AM, William Lieurance > <[email protected]> wrote: > > Hi there, > > I've got some seemingly working code based on your branch at > https://github.com/ajs6f/trellis-cassandra-webapp/compare/TamayaConfig...peculater:TamayaConfig > . Take a look and tell me what you think. > > The problems I noticed are in two areas. The first one is the most > frustrating to me, and is the one you alluded to in your most recent email. > Namely, balancing all of the CDI providers and consumers when spanning weld, > jersey-cdi1x, JSF, the different -servlet packages, all their express and > implied dependencies, and finally version conflicts, is really hard and often > subtly broken. For most of the tests that we run on CDI in managed contexts, > we default to some pre-packaged combos with Arquillian. While that is > somewhat heavier weight, it comes with the notable benefit of wiring up CDI > with way fewer surprises and generally less work. If you're not big on EE, > the various "microprofile" servers do just CDI+JaxRS+Json which sounds like > it might be useful if for no other reason than it's clear which versions of > which maven artifacts work together. > > The second place I spent some time was looking at why using the > "cassandraHostAddy" variable at > https://github.com/ajs6f/trellis-cassandra-webapp/blob/TamayaConfig/src/main/java/edu/si/trellis/cassandra/CassandraSession.java#L80 > wasn't actually providing any data, nor did it seem like dependency > injection was ever getting called at all. The answer there is in Weld's > documentation at > https://docs.jboss.org/weld/reference/latest/en-US/html/injection.html > section 4.1. The important part is: > >> Dependency injection always occurs when the bean instance is first >> instantiated by the container. Simplifying just a little, things happen in >> this order: >> >> First, the container calls the bean constructor (the default constructor or >> the one annotated @Inject), to obtain an instance of the bean. >> Next, the container initializes the values of all injected fields of the >> bean. > > Note that any bean, including the @ApplicationScope CassandraSession from > your example has to have its constructor called before any fields get > injected. That means references to the injected fields in the constructor > necessarily come back null, and if those fields are never referenced again it > might look like the injection never took place at all. I've got an example > of how to get Configuration object out of CDI in the constructor in that > diff, but it's more than an annotation. Moving the call to cassandraHostAddy > out of the constructor and giving it a default value made it work for me. > > There is still some weirdness around missing Integer converters that I was > never able to pin down, but I really think that has to do with problem one > above. > > I hope this helps! > > --William > > ________________________________________ > From: ajs6f <[email protected]> > Sent: Wednesday, August 29, 2018 10:07 AM > To: [email protected] > Subject: Re: Tamaya CDI question > > Just as an update, I was able to get tamaya-cdi working with Weld 3.0.5.Final > in a setup driven by Pax Exam (no complications from JAX-RS or servlet > containers), so I don't think it's a problem with that version of Weld. I > will now try building back up towards my real problem to hopefully find the > relevant condition that stops Tamaya's CDI extensions from loading. > > ajs6f > >> On Aug 28, 2018, at 2:28 PM, Anatole Tresch <[email protected]> wrote: >> >> Awesome👍 >> >> <[email protected]> schrieb am Di., 28. Aug. 2018, 19:56: >> >>> More than ok-- I am really grateful. You are surely correct that it is a >>> very simple project, but I will keep tinkering and see if I can set up a >>> more minimal example that could evolve into a test case if needed. >>> >>> Thanks! >>> >>> ajs6f >>> >>> On Mon, Aug 27, 2018, 3:36 PM Anatole Tresch <[email protected]> wrote: >>> >>>> OK. somehow sounds a it tricky. Good thing is, your example is really >>>> pretty simple. I am happy to look into further and play around with it as >>>> well, but I will not have a chance to do so before end of week, because I >>>> am completely absorbed with education and work... >>>> If someone else can have a look a it beforehand, I would be pretty happy >>> as >>>> well ;-) >>>> >>>> OK for you? >>>> >>>> Best Anatole >>>> >>>> Am Mo., 27. Aug. 2018 um 20:23 Uhr schrieb ajs6f <[email protected]>: >>>> >>>>> Okay, it doesn't seem to be a version problem, or at least I could get >>> no >>>>> different result working with Weld 3.0.1.Final. >>>>> >>>>> I also tried adding an org.apache.tamaya.spi.ServiceContext file in >>>>> META-INF/services containing just: >>>>> >>>>> org.apache.tamaya.cdi.CDIAwareServiceContext >>>>> >>>>> because I saw that done in the Tamaya CDI module code, as well as every >>>>> possible combination of different entries in >>>>> javax.enterprise.inject.spi.Extension. No change-- in every single >>>>> case,TamayaCDIAccessor get registered as an extension, whether or not >>> it >>>> is >>>>> mentioned in j.e.inject.spi.Extension, and neither >>>>> TamayaCDIInjectionExtension nor >>>>> TamayaSEInjectionExtension do, whether or not they are mentioned. I've >>>>> triplechecked the assembly of the web-app, and it is correctly putting >>>> the >>>>> service files into META-INF/services, so I'm a bit flummoxed. I suspect >>>>> that the reason that TamayaCDIAccessor is getting registered is >>> connected >>>>> ot the reason the other extensions aren't getting registered, but I >>> don't >>>>> know what that is… CDI's extension lifecycle is really well-defined. >>>>> >>>>> ajs6f >>>>> >>>>>> On Aug 27, 2018, at 12:33 PM, John D. Ament <[email protected]> >>>>> wrote: >>>>>> >>>>>> On Mon, Aug 27, 2018, 10:32 ajs6f <[email protected]> wrote: >>>>>> >>>>>>> I'm afraid not-- I changed javax.enterprise.inject.spi.Extension to: >>>>>>> >>>>>>> # Register Tamaya to perform injection >>>>>>> org.apache.tamaya.cdi.TamayaCDIInjectionExtension >>>>>>> org.apache.tamaya.cdi.TamayaSEInjectionExtension >>>>>>> >>>>>>> and now no extension from Tamaya is registered at all! I _do_ see >>>>> various >>>>>>> beans being registered, e.g. >>>>>>> >>>>>>> Aug 27, 2018 10:27:23 AM org.apache.catalina.core.ApplicationContext >>>> log >>>>>>> INFO: 10:27:23.024 [main] DEBUG org.jboss.weld.Bootstrap - >>>> WELD-000106: >>>>>>> Bean: Producer Method [Object] with qualifiers [@Config @Any] >>> declared >>>>> as >>>>>>> [[BackedAnnotatedMethod] @Produces @Config public >>>>>>> >>>>> >>>> >>> org.apache.tamaya.cdi.ConfigurationProducer.resolveAndConvert(InjectionPoint)] >>>>>>> >>>>>>> It looks like the Tamaya example is using Weld 3.0.1.Final as >>> opposed >>>> to >>>>>>> my Weld 3.0.5.Final, but I can't imagine that would make any >>>> difference. >>>>>>> >>>>>> >>>>>> >>>>>> It very well could. Weld had some major changes in classloading to >>>>> support >>>>>> Java 9 and up. There could be a regression issue there. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>>> ajs6f >>>>>>> >>>>>>>> On Aug 24, 2018, at 6:04 PM, Anatole Tresch <[email protected]> >>>>> wrote: >>>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> As far as I see there is no registration for the CDI extension >>>> present. >>>>>>>> Look at our test case for an example: >>>>>>>> >>>>>>> >>>>> >>>> >>> https://github.com/apache/incubator-tamaya-extensions/blob/master/modules/injection/cdi/src/test/resources/META-INF/services/javax.enterprise.inject.spi.Extension >>>>>>>> >>>>>>>> >>>>>>>> Give ad a hint if that solved your problem...😊 >>>>>>>> >>>>>>>> Best, Anatole >>>>>>>> >>>>>>>> ajs6f <[email protected]> schrieb am Fr., 24. Aug. 2018, 17:39: >>>>>>>> >>>>>>>>> Hi, Anatole-- >>>>>>>>> >>>>>>>>> Thank you very much! Please find my branch here: >>>>>>>>> >>>>>>>>> >>> https://github.com/ajs6f/trellis-cassandra-webapp/tree/TamayaConfig >>>>>>>>> >>>>>>>>> and the bean field where I'm using @Config is here: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> https://github.com/ajs6f/trellis-cassandra-webapp/blob/TamayaConfig/src/main/java/edu/si/trellis/cassandra/CassandraSession.java#L47 >>>>>>>>> >>>>>>>>> I'm sorry for the somewhat chaotic code-- this is a very >>>> experimental >>>>>>>>> project, although of course CDI and JAX-RS are not the >>> experimental >>>>>>> part. >>>>>>>>> >>>>>>>>> Please let me know what more info would be useful, and thank you >>> for >>>>>>> your >>>>>>>>> help! (If you would like some log output, I can certainly package >>>>> that >>>>>>> up >>>>>>>>> somewhere for you.) >>>>>>>>> >>>>>>>>> ajs6f >>>>>>>>> >>>>>>>>>> On Aug 24, 2018, at 2:34 AM, Anatole Tresch <[email protected]> >>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Thanks for your mail. Basically the extension must load properly >>>> for >>>>>>>>> Tamaya >>>>>>>>>> CDI to work. If you can provide some kind of sample project it >>>> would >>>>> be >>>>>>>>>> perfect and I am happy to help. >>>>>>>>>> >>>>>>>>>> J Anatole >>>>>>>>>> >>>>>>>>>> ajs6f <[email protected]> schrieb am Do., 23. Aug. 2018, 22:00: >>>>>>>>>> >>>>>>>>>>> Hi, Tamaya-folks! >>>>>>>>>>> >>>>>>>>>>> I'm tinkering with Tamaya (0.3-incubating) for a webapp I'm >>>> writing >>>>>>>>>>> (deployed as a WAR in a servlet container). I'm using JAX-RS >>>> (Jersey >>>>>>>>> 2.27) >>>>>>>>>>> and CDI (Weld 3.0.5.Final) and I would love to use tamaya-cdi, >>> but >>>>> I'm >>>>>>>>>>> running into an odd problem. >>>>>>>>>>> >>>>>>>>>>> I'm not seeing TamayaCDIInjectionExtension properly initialized >>>> as a >>>>>>> CDI >>>>>>>>>>> extension, but oddly, I _am_ seeing the TamayaCDIAccessor >>>> extension >>>>>>>>> show up >>>>>>>>>>> and get initialized. So when my bean wirings are validated, >>>>> injection >>>>>>>>>>> points with a @Config @Inject are failing because CDI doesn't >>> know >>>>> to >>>>>>>>> go to >>>>>>>>>>> Tamaya for such injections. >>>>>>>>>>> >>>>>>>>>>> Has anyone seen anything like this? I can certainly put my >>> current >>>>>>>>> branch >>>>>>>>>>> up somewhere if that would be useful. My >>>>>>>>>>> javax.enterprise.inject.spi.Extension is as simple as: >>>>>>>>>>> >>>>>>>>>>> # Register Tamaya to perform injection >>>>>>>>>>> org.apache.tamaya.cdi.TamayaCDIAccessor >>>>>>>>>>> org.apache.tamaya.cdi.TamayaCDIInjectionExtension >>>>>>>>>>> >>>>>>>>>>> but only one of those guys seems to come to life! :grin: >>>>>>>>>>> >>>>>>>>>>> ajs6f >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> -- >>>> *Anatole Tresch* >>>> PPMC Member Apache Tamaya >>>> JCP Star Spec Lead >>>> *Switzerland, Europe Zurich, GMT+1* >>>> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * >>>> *Twitter: @atsticks, @tamayaconf* >>>> >>>> *Speaking at:* >>>> >>>> [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con] >>>> >>> >
