This is the design of the plugins. Today I'm working on a new
JAASAuthenticationConfiguratorPlugin. To keep this sane, I have configurator
beans associated with the plugins which reflect things like the default
values (avoids having to check for nulls and then convert stuff like "true"
to Booleans. Just extending the class provides that capability.

I realize that CXF is falling out of favor so having cfg configurable busses
is probably not something the community has much interest in. I'm dealing
with a lot of legacy code and multiple systems with different requirements
for integration so it still makes a lot of sense in my world. 

The plugins are highly testable and it was JB's sample code that really
kicked it loose for me. I've use the JAX factory beans for testing before
and even created fluent wrapper classes for them but was unsure about using
them in production. I don't need a Bus to do everything in a code-based
world. If I can have a small handful of CXF Busses in the registry that get
80% of the way, I'm fine with instantiating various interceptors and
providers and attaching them to endpoints for those oddball cases or cases
like the Swagger2Feture which requires that the endpoint URL be set per
endpoint (which is a bit unfortunate).

1. Anyone know if the deprecation on the logging interceptors is serious?
I'd never noticed that before because that sort of information gets hidden
in Blueprint.
2. Any interest in generalizing this as sample code for Karaf/CXF or to
create a framework bundle that can be deployed to monitor cfg files of the
right name and then bootstrap Busses to the registry?

I've done basic verification that the configuration and configuration
changes get picked up correctly but if it was a community project there
would be more eyes on it.



public abstract class AbstractBusConfiguratorPlugin implements
BusConfiguratorPlugin {

        private ObjectMapper mapper = new
ObjectMapper().configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES,false);

        protected <T> T getBean(Map<String,Object> properties, Class<T> clazz) {
                return mapper.convertValue(properties, clazz);
        }
}


public class LoggingBusConfiguratorPlugin extends
AbstractBusConfiguratorPlugin implements BusConfiguratorPlugin {


        public void init(Bus bus, Map<String, Object> properties) {

                LoggingBean logConfigBean = 
super.getBean(properties,LoggingBean.class);
                

                if (logConfigBean.loggingIsRequired()) {
                        //TODO These are deprecated but still commonly used. 
Important to
refactor?
                        LoggingInInterceptor loggingIn = new 
LoggingInInterceptor();
                        LoggingOutInterceptor loggingOut = new 
LoggingOutInterceptor();
                        if (logConfigBean.getLogIn())
                                bus.getInInterceptors().add(loggingIn);
                        if (logConfigBean.getLogOut())
                                bus.getOutInterceptors().add(loggingOut);
                        if (logConfigBean.getErrorLogOut())
                                bus.getOutFaultInterceptors().add(loggingOut);
                        if (logConfigBean.getErrorLogIn())
                                bus.getInFaultInterceptors().add(loggingIn);
                }
        }


}



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Reply via email to