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>>> >>> >>
