[GitHub] [aries-cdi] rmannibucau edited a comment on issue #35: [DISCUSS] proposal for adapted code style

[GitBox <gi...@apache.org>]

rmannibucau edited a comment on issue #35: [DISCUSS] proposal for adapted code style
URL: https://github.com/apache/aries-cdi/pull/35#issuecomment-569089660
 
 
   @rotty3000 I'm still experimenting a bit, the other option I have is composed of 2 parts:
   
   1. A new SkipServices annotation for extensions:
   
   ```
       @SkipServices
       public class JaxrsCDIExtension implements Extension {
       	void application(
       		@Observes @WithAnnotations(ApplicationPath.class)
       		ProcessAnnotatedType<? extends Application> pat, BeanManager beanManager) {
       		// only called if no @Service
       	}
       ....
   ```
   
   2. a new built-in extension to handle the merge:
   
   ```
       public class ServiceAdapterExtension implements Extension {
   	    private boolean started;
   	    <T> void onMergeServiceTypes(@Observes final MergeServiceTypes<T> mergeServiceTypes) {
   		    if (started) {
   			    throw new IllegalStateException("Container already started");
   		    }
   		    final AdaptedService adaptedService = mergeServiceTypes.getProcessAnnotatedType()
   				    .getAnnotatedType().getAnnotation(AdaptedService.class);
   		    final AnnotatedTypeConfigurator<T> configurator = mergeServiceTypes.getProcessAnnotatedType().configureAnnotatedType();
   		    final Class<?>[] services;
   		    if (adaptedService != null) {
   			    configurator.remove(a -> a.annotationType() == AdaptedService.class);
   			    services = Stream.concat(
   					    Stream.of(mergeServiceTypes.getTypes()),
   					    Stream.of(adaptedService.value()))
   					    .toArray(Class[]::new);
   		    } else {
   			    services = mergeServiceTypes.getTypes();
   		    }
   		    configurator.add(AdaptedService.Literal.of(services));
   	    }
   	    void started(@Observes final AfterDeploymentValidation afterDeploymentValidation) {
   		    started = true;
   	    }
       }
   ```
   
   It looks more elegant and avoid that static part but at the end it requires a bit more work (since it the 1 will require to switch the extension instance - but we already have extension point in both weld and owb). So for me criteria is: is this API for end users - in this case I think we should try to refine it, or is it an internal for our extensions - in this case we can keep a static utility a bit less elegant but we shouldn't document it IMHO.
   
   wdyt?
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services