Created attachment 837659 [details] reproducer Problem: Secured service with http binding does not require authentication header. The switchyard.xml (see switchyard-original.xml) defines the http binding on service "CustomService", component "Performance". The bean scanner adds to the switchyard.xml new component named "CustomService" (The java bean defines annotation @Service(CustomService.class), so it is ok). There is difference between switchayrd.xml generated in ER6 and ER7. The request to secured service published using switchyard.xml from previous version (ER6) requires authentication header, but the service published using switchyard.xml from ER7 does not, so the service can be requested without security. ER6 switchyard: the request to "http://localhost:8080/performance-binding-http-secured-basic/CustomService/sayHello" invokes the CustomService defined in Performance component, so it requires authentication. ER7 switchyard: the request to "http://localhost:8080/performance-binding-http-secured-basic/CustomService/sayHello" invokes the CustomService defined in new added CustomService component, so it does not require authentication. This is interesting, because the binding is defined for "Performance/CustomService" switchyard-original.xml - original switchyard.xml switchyard-ER6.xml - generated ER6 switchyard-ER7.xml - generated ER7 The reproducer attached.
Created attachment 837660 [details] switchyard original
Created attachment 837661 [details] switchyard ER6
Created attachment 837662 [details] switchyard ER7
A few comments on this project: 1) If you already have your bean service defined in switchyard.xml, there's no point in using BeanScanner in your pom.xml to generate config. 2) If you really want to use BeanScanner for some reason, it's important to make sure that the config that will be generated from annotations in the bean class matches any predefined config in switchyard.xml. In this case, that means adding the componentName element to your annotation: @Service(value = CustomService.class, componentName = "Performance") What's happening at runtime here is that two instances of 'CustomService' are registered, one for each component definition in the generated switchyard.xml. The promoted service is also named 'CustomService' so it is going to match based on name and that will provide two possibilities. Deployment happens in document order, so that's likely why the first, unsecured service is being invoked with your app.
Hey Kevin, I think this should be nack'd and marked as won't fix.
nacking on behalf of dev given Keith's and Rob's comments