Thinking out loud: did we check we can use @CxfXXX on application class? Do we respect it for properties?
Le 24 déc. 2017 22:22, "Andriy Redko" <[email protected]> a écrit : > Oh you mean, the configuration implementation. Sure, I think if the > general approach make sense, starting > from cxf properties would be as simple as it can get. We just need to plug > it with CDI extension part. > > > RMB> Le 24 déc. 2017 21:40, "Andriy Redko" <[email protected]> a écrit : > > RMB> No API sounds good. Just to clarify the second part. "By reflection" > you mean just go with classpath scan? > > > > > RMB> No, CXF must never scan anything, it is already done and would defeat > any integration and user experience to redo > RMB> it. Just meant test deltaspike, if no value test microprofile, if no > value cxf properties and last system > RMB> properties. The first two needs to be done by reflection to avoid to > enforce them as dependency. A spi can be > RMB> tested as well first but not having to impl it would be a big plus > and is easy technically, no? > > > > RMB>> No hard dep on any api would be nice but a chain can work even if > by reflection no? Kind of test them all. Then > RMB>> put the active ones in the server map to be able to reuse it later > no? > > RMB>> Le 24 déc. 2017 19:07, "Andriy Redko" <[email protected]> a écrit : > > RMB>> Hey guys, > > RMB>> So I have been looking around to understand how the activation > around CDI is worked out by others, > RMB>> including ConfigResolver and Jersey. Here is what I have > discovered so far. > > RMB>> #1. Deltaspike. Uses own ConfigResolver approach: among other > things, allows to deactivate beans / extensions > RMB>> using a list of config sources. Because Deltaspike is pure CDI, > all extensions are automatically discovered but > RMB>> could be deactivated by means of ConfigResolver. In case of CXF, > we could take a similar approach by activating > RMB>> the necessary beans (as most of our components are non-beans > archives and as such, won't be discovered by CDI), > RMB>> f.e.: > > RMB>> <full.class.name>.active = true > RMB>> <full.class.name>.active = true > RMB>> <full.class.name>.active = true > > RMB>> Once the JAXRS extension is picked up by CDI runtime, it would add > annotated types during the discovery phase for > RMB>> activated providers / features. In the future, this could be done > using beans.xml (https://issues.jboss.org/browse/CDI-526), > RMB>> hopefully, but as Romain pointed out, it is problematic at the > moment. > > RMB>> We could make it per-module (so each component would provide such > configuration) or bundle as a single module > RMB>> (f.e. cxf-cdi-discovery, or cxf-cdi-beans, ...). Surely, each > application would be able to override any of the > RMB>> activations and/or provide its own if necessary. > > RMB>> #2. Jersey. Uses own mechanism to autodiscover and register > features and providers. Essentially, in a simplified form, it could > RMB>> be summarized like this. Each module (component) provides binding > (in a form contract -> class -> scope) which it thinks should be > RMB>> autodiscovered by the runtime (in this case, CDI). The bindings > are brought into context using service loader. In this case, every > RMB>> component has a compile-time dependency on CDI API. > > RMB>> No doubts, there are more options available. Picking between the > ones above, could/should we implement #1? If yes, should we build it > RMB>> on top of Microprofile Config API (https://github.com/eclipse/ > microprofile-config)? Or just keep it as simple as > RMB>> possible (around new/use existing property file)? What do you > think guys? > > > RMB>> Thanks. > > RMB>> Best Regards, > RMB>> Andriy Redko > > RMB>>> Something like deltaspike where it is on by default and > deactivable by config is not bad for such modules. Issue > RMB>>> is: what is config? For spring it is obvious but for cdi it must > be the 2 mentionned solution and maybe a 3rd fallback with a cxf specific > solution - or system props. > > > RMB>>> An alternate more advanced option can be a cxf-autoload module > which would read some classpath file like a spi > RMB>>> where cxf modules could register such feature but would be on > only when this module is in the cp. Maybe something > RMB>>> to study but to be honest i believe more in the previous > integrations (as a user). > > RMB>>> Le 23 déc. 2017 20:29, "Sergey Beryozkin" <[email protected]> > a écrit : > > RMB>>> Well, was not clear what you meant, the whole conversation was > about optionally choosing whether to auto-load a > RMB>>> given provider or not with CDI and you referred to SpringBoot > which could do some magic and CXF having the related > RMB>>> module and possibly getting some ideas from there and I thought > I'd clarify that there was no magic there in the > RMB>>> Spring-Boot starters/auto-configuration, nothing SpringBoot or > Spring specific (well we do refer to Spring to scan > RMB>>> but CDI can scan too) about optionally loading specific providers > from the specific packages. > > RMB>>> CXF itself ships many providers in different modules and > packages and it is hard to see how one can let users > RMB>>> control auto-loading them (which is) without letting users choose > at the config time... > > RMB>>> Cheers, Sergey > > > RMB>>> On 22/12/17 23:15, Andriy Redko wrote: > > RMB>>> That is right, I was not refering to autodiscovery but Spring > Boot module we > RMB>>> have. As per my understading, CDI has different means for > achieving the desired > RMB>>> outcomes but Spring is more flexible in this regard. > > RMB> SB>>> CXF SpringBoot module does not do any auto-discovery. The > code is in the > RMB> SB>>> rt/frontend/jaxrs/.../spring which can be loaded by the > spring boot > RMB> SB>>> module, and it does what I said in the prev email, scans for > the classes > RMB> SB>>> annotated as providers in the user-requested packages... > > RMB> SB>>> Cheers, Sergey > RMB> SB>>> On 22/12/17 22:40, Andriy Redko wrote: > > RMB>>> Documenting make sense. To project it to Spring-based runtime, > fe, without > RMB>>> Spring-specific annotations + configuration the discovery won't > happen ... > RMB>>> But there is Spring Boot which could do magic here, and CXF does > have a > RMB>>> module for it. Same, in theory, could be possible with CXF+CDI > (let say by > RMB>>> adding `cxf-cdi` module where we could supply the limited, > handcrafted > RMB>>> set of CDI beans available for discovery in the beans.xml). Do > you think it > RMB>>> is worth exploring the idea? > > > > > RMB>>> Best Regards, > RMB>>> Andriy Redko > > > > > RMB> JDA>>> I would do nothing but document a strategy that users can > implement. The > RMB> JDA>>> biggest question I have is whether a provider like this > should be > RMB> JDA>>> registered automatically? Does that happen with spring > based runtimes? > RMB> JDA>>> What about when there is no DI framework present? Is it > clear enough that > RMB> JDA>>> user would need to list it in their Application class as a > singleton/class? > > > > > RMB> JDA>>> John > > > > > RMB> JDA>>> On Fri, Dec 22, 2017 at 5:08 PM Andriy Redko < > [email protected]> wrote: > > > > > RMB>>> Sure, removed/reverted. So here are the general thoughts. Yes, > most (if > RMB>>> not all) of the providers/features/... are not CDI > RMB>>> specific and as such, they are not bean archives (and it make > sense). Now, > RMB>>> how could we make the CXF more CDIish? There > RMB>>> are a couple of option we could explore, but what would be the > idiomatic > RMB>>> CDI way? > > > > > > > RMB>>> Best Regards, > RMB>>> Andriy Redko > > > > > > > RMB> JDA>>> Personally, I would actually recommend removing the > beans.xml from > RMB>>> open tracing (and really any module that isn't > RMB> JDA>>> a cdi specific module). While it does allow for a bit more > automatic > RMB>>> binding, my question was more around what is > RMB> JDA>>> missing. I missed the fact that there is no build in > automatic > RMB>>> discovery of providers in CDI if they're not CDI > RMB> JDA>>> managed - which is OK and the answer I was working through. > > > > > > > RMB> JDA>>> And realistically, this issue is not specific to the open > tracing > RMB>>> integration, I can replicate it with other > RMB> JDA>>> providers. Its just a matter of documenting and knowing > what to > RMB>>> setup. > > > > > > > RMB> JDA>>> So if you don't mind, I'd like to revert that commit; and > add some > RMB>>> docs around how to create an automatically registered provider. > > > > > > > RMB> JDA>>> John > > > > > > > RMB> JDA>>> On 2017-12-22 15:24, Romain Manni-Bucau < > [email protected]> > RMB>>> wrote: > > RMB>>> How can i disable it now? Tink that cxf feature - even if in > separate > RMB>>> modules - shouldnt be auto registered until it has a deactivable > flag - > RMB>>> classpath properties + overridable through system prop. > > > > > > > > > RMB>>> Wdyt? > > > > > > > > > RMB>>> Le 22 déc. 2017 18:38, "Andriy Redko" <[email protected]> a > écrit : > > > > > > > > > RMB>>> Hi Sergey, > > > > > > > > > > RMB>>> It wasn't (for CDI only), but it could have been always included > > > > RMB>>> manually. > > RMB>>> Thanks. > > > > > > > > > > RMB>>> Best Regards, > RMB>>> Andriy Redko > > > > > > > > > > RMB> SB>>> Hi Andriy > > > > > > > > > > RMB> SB>>> So how was a JAX-RS (OpenTracing) Feature discovered without > > > > RMB>>> beans.xml > > RMB>>> ? > > > > > > > > > > RMB> SB>>> Cheers, Sergey > RMB> SB>>> On 22/12/17 17:24, Andriy Redko wrote: > > RMB>>> The beans.xml was missed indeed, I added it and > OpenTracingFeature > > > > > > RMB>>> has > > RMB>>> been discovered right away. > > RMB>>> The commit is on its way. Thanks! > > > > > > > > > > > > RMB>>> Best Regards, > RMB>>> Andriy Redko > > > > > > > > > > > > RMB> JDA>>> I'm holding off on doing anything to fix it. For one, a > user > > > > > > RMB>>> may > > RMB>>> not want to use the global tracer so making it > > RMB> JDA>>> so that they register it makes more sense. Ultimately to > > > > > > RMB>>> solve > > RMB>>> it, I think we should be moving server > > RMB> JDA>>> customizations outside of CDI to ensure that it can be auto > > > RMB>>> registered. > > > > > > > > > > > RMB> JDA>>> John > > > > > > > > > > > > > RMB> JDA>>> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko < > > > > > > > > RMB>>> wrote: > > > > > > > > > > RMB> JDA>>> Hey John, > > > > > > > > > > > > RMB> JDA>>> The OpenTracingFeature > > > > > > RMB>>> (org.apache.cxf.tracing.opentracing.jaxrs > > RMB>>> package) is JAX-RS feature, > > RMB> JDA>>> which JAXRS CDI extension should recognize out of the box. > > > > > > RMB>>> There > > RMB>>> is also CXF feature ( > > RMB> JDA>>> in org.apache.cxf.tracing.opentracing package) to be used > for > > > RMB>>> JAX-WS services. The only explanation > > RMB> JDA>>> I have why it is not being picked up it the absense of > > > > > > RMB>>> bean.xml > > RMB>>> so we could fix that. I will > > RMB> JDA>>> take a look shorly (if you haven't figured this one out > > > > > > RMB>>> already). > > RMB>>> Thanks. > > > > > > > > > > RMB> JDA>>> Best Regards, > RMB> JDA>>> Andriy Redko > > > > > > > > > > > > > RMB>>> JDA>> I'm not sure either, this is the behavior I see in the > > > > > > RMB>>> code: > > > > > > > RMB>>> JDA>> - Register JAX-RS resources (with @ApplicationPath) > RMB>>> JDA>> - Register JAX-RS resources (with @Path) > RMB>>> JDA>> - Register JAX-RS providers (with JAX-RS @Provider) > RMB>>> JDA>> - Register JAX-RS features (with JAX-RS @Feature) > RMB>>> JDA>> - Register CXF features (doesn't care if it has a CXF > > > > > > RMB>>> @Provider > > RMB>>> annotation but I see the OpenTracing one does have it) > > RMB>>> JDA>> - Otherwise we assume its the CXF Bus object > > > > > > > > > > > > RMB>>> JDA>> There's not much happening with a CXF @Provider > > > > > > RMB>>> declaration in > > RMB>>> the extension. But at the end of the day, I'm only > > RMB>>> JDA>> dealing with a JAX-RS @Provider and that doesn't get > > > > > > RMB>>> registered > > RMB>>> since it's not a CDI bean. I don't see any issue > > RMB>>> JDA>> registering CXF @Provider this way as well, but its > > > > > > RMB>>> possible > > RMB>>> it's not a CDI bean still, but that's ultimately what the > customizer > > > > RMB>>> was > > RMB>>> put in for. > > > > > > > > > > RMB>>> JDA>> John > > > > > > > > > > > > RMB>>> JDA>> On 2017-12-22 09:56, Sergey Beryozkin < > > > > > > RMB>>> [email protected]> > > RMB>>> wrote: > > RMB>>> >>> Sure, I just don't understand what is the difference > between > > > > > > RMB>>> a > > RMB>>> JAX-RS > > RMB>>> >>> feature and CXF feature, as far as the CXF CDI code is > > > > > > RMB>>> concerned. > > RMB>>> If it > > RMB>>> >>> can load the JAX-RS features which have not been written > > > > > > RMB>>> with CDI > > RMB>>> in > > RMB>>> >>> mind, why can't it load CXF features without some extra > work > > > RMB>>> going into > > RMB>>> >>> these features... > > > > > > > > > > > > RMB>>> >>> Thanks, Sergey > RMB>>> >>> On 22/12/17 14:50, John D. Ament wrote: > RMB>>> >>> > That's not really the issue though. The extension will > > > > > > RMB>>> only > > RMB>>> receive CDI managed beans. Take a look at my pull to see what I > had > > > > RMB>>> to do > > RMB>>> to get it to register automatically. If nothing else, this is an > > > > RMB>>> argument > > RMB>>> for moving JAXRSServer Customization into core and using service > > > > RMB>>> loader > > RMB>>> :-) Perhaps after the new year. > > RMB>>> >>> > > RMB>>> >>> > On 2017-12-22 09:23, Sergey Beryozkin < > > > > > > RMB>>> [email protected]> > > RMB>>> wrote: > > RMB>>> >>> >> I was not referring the OpenTracing module offering a > CDI > > > RMB>>> extension, but > > RMB>>> >>> >> to the work Andriy did in the CXF CDI integration > where > > > > > > RMB>>> the > > RMB>>> providers > > RMB>>> >>> >> and feature are picked up. Thought, when we were > > > > > > RMB>>> discussing > > RMB>>> the SSE > > RMB>>> >>> >> feature I thought Andriy said it was looking at the > CXF > > > RMB>>> @Provider as > > RMB>>> >>> >> well, may be I misunderstood. > RMB>>> >>> >> Updating the CDI code to check CXF @Provider, if it > is not > > > RMB>>> already > > RMB>>> >>> >> checked, makes sense IMHO > RMB>>> >>> >> > RMB>>> >>> >> Sergey > RMB>>> >>> >> On 22/12/17 14:08, John D. Ament wrote: > RMB>>> >>> >>> Actually one more thing. The CDI extension only > looks > > > > > > RMB>>> for > > RMB>>> JAX-RS @Provider not CXF @Provider. > > RMB>>> >>> >>> > RMB>>> >>> >>> On 2017-12-22 09:06, "John D. Ament"< > > > > > > RMB>>> [email protected]> > > RMB>>> wrote: > > RMB>>> >>> >>>> I'm not sure what the CDI extension has to do with > > > > > > RMB>>> this. It > > RMB>>> has no bean defining annotations, and there is no beans.xml in > the > > > > RMB>>> JAR that > > RMB>>> it ships with so I'm not sure it would be picked up by the > extension. > > RMB>>> >>> >>>> > RMB>>> >>> >>>> There's nothing special done for TomcatwarTest to > make > > > > > > RMB>>> more > > RMB>>> JARs available, right? > > RMB>>> >>> >>>> > RMB>>> >>> >>>> On 2017-12-22 08:15, Sergey Beryozkin < > > > > > > RMB>>> [email protected]> > > RMB>>> wrote: > > RMB>>> >>> >>>>> It is annotated with CXF @Provider annotation - > should > > > > > > RMB>>> be > > RMB>>> picked up by > > RMB>>> >>> >>>>> the CXF CDI extension > RMB>>> >>> >>>>> > RMB>>> >>> >>>>> Sergey > RMB>>> >>> >>>>> On 22/12/17 13:07, John D. Ament wrote: > RMB>>> >>> >>>>>> I'm trying to finish up testing CDI injection of > > > > > > RMB>>> Context > > RMB>>> objects. The one > > RMB>>> >>> >>>>>> area I'm struggling with is the automatic > > > > > > RMB>>> registration of > > RMB>>> this feature. I > > RMB>>> >>> >>>>>> added a dependency on OpenTracing, just to confirm > > > > > > RMB>>> that > > RMB>>> injection via CDI > > RMB>>> >>> >>>>>> works (and to be honest, this is one of my use > cases, > > > RMB>>> working with > > RMB>>> >>> >>>>>> tracing). However, it seems that this feature > isn't > > > RMB>>> automatically > > RMB>>> >>> >>>>>> registered via CDI. Is there something I have to > do > > > > > > RMB>>> to > > RMB>>> make it work? > > RMB>>> >>> >>>>>> > RMB>>> >>> >>>>>> John > RMB>>> >>> >>>>>> > RMB>>> >>> >>>>> > RMB>>> >>> >>>> > RMB>>> >>> >> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
