Le 24 déc. 2017 21:40, "Andriy Redko" <drr...@gmail.com> a écrit :
No API sounds good. Just to clarify the second part. "By reflection" you mean just go with classpath scan? No, CXF must never scan anything, it is already done and would defeat any integration and user experience to redo it. Just meant test deltaspike, if no value test microprofile, if no value cxf properties and last system properties. The first two needs to be done by reflection to avoid to enforce them as dependency. A spi can be 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" <drr...@gmail.com> 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" <sberyoz...@gmail.com> 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. SB>>> CXF SpringBoot module does not do any auto-discovery. The code is in the SB>>> rt/frontend/jaxrs/.../spring which can be loaded by the spring boot SB>>> module, and it does what I said in the prev email, scans for the classes SB>>> annotated as providers in the user-requested packages... SB>>> Cheers, Sergey 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 JDA>>> I would do nothing but document a strategy that users can implement. The JDA>>> biggest question I have is whether a provider like this should be JDA>>> registered automatically? Does that happen with spring based runtimes? JDA>>> What about when there is no DI framework present? Is it clear enough that JDA>>> user would need to list it in their Application class as a singleton/class? JDA>>> John JDA>>> On Fri, Dec 22, 2017 at 5:08 PM Andriy Redko <drr...@gmail.com> 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 JDA>>> Personally, I would actually recommend removing the beans.xml from RMB>> open tracing (and really any module that isn't JDA>>> a cdi specific module). While it does allow for a bit more automatic RMB>> binding, my question was more around what is JDA>>> missing. I missed the fact that there is no build in automatic RMB>> discovery of providers in CDI if they're not CDI JDA>>> managed - which is OK and the answer I was working through. JDA>>> And realistically, this issue is not specific to the open tracing RMB>> integration, I can replicate it with other JDA>>> providers. Its just a matter of documenting and knowing what to RMB>> setup. 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. JDA>>> John JDA>>> On 2017-12-22 15:24, Romain Manni-Bucau <rmannibu...@gmail.com> 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" <drr...@gmail.com> 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 SB>>> Hi Andriy SB>>> So how was a JAX-RS (OpenTracing) Feature discovered without RMB>> beans.xml RMB>> ? SB>>> Cheers, Sergey 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 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 JDA>>> so that they register it makes more sense. Ultimately to RMB>> solve RMB>> it, I think we should be moving server JDA>>> customizations outside of CDI to ensure that it can be auto RMB>> registered. JDA>>> John JDA>>> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko < RMB>> wrote: JDA>>> Hey John, JDA>>> The OpenTracingFeature RMB>> (org.apache.cxf.tracing.opentracing.jaxrs RMB>> package) is JAX-RS feature, JDA>>> which JAXRS CDI extension should recognize out of the box. RMB>> There RMB>> is also CXF feature ( JDA>>> in org.apache.cxf.tracing.opentracing package) to be used for RMB>> JAX-WS services. The only explanation 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 JDA>>> take a look shorly (if you haven't figured this one out RMB>> already). RMB>> Thanks. JDA>>> Best Regards, 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>> sberyoz...@gmail.com> 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>> sberyoz...@gmail.com> 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>> johndam...@apache.org> 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>> sberyoz...@gmail.com> 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>> >>> >>
