Karaf CXF SCR REST example...

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Karaf CXF SCR REST example...

Ranx0r0x
https://github.com/apache/karaf/tree/master/examples/karaf-rest-example/karaf-rest-example-scr

I was just checking out this latest example and have to say I like it quite
a bit. One thing I'm trying to focus on is being able to set up more than
one Bus in a bus-centric bundle and then reuse them via injection. It would
seem that this mechanism should permit that if I export the Busses to the
registry with a JNDI filter name and then inject it here instead of using
the BusFactory.getDefaultBus()

Would this be on the right track? I know that with Hibernate and PAX JDBC I
have to set a "capability" statement in the features file but that may be
because of Hibernate and PAX JDBC interoperation and be unnecessary in this
case. If I set up the Busses and use an @Service with a name. I'm a bit
uncertain though about the Service/Refence syntax that would be correct.

        <capability>

osgi.service;effective:=active;objectClass=javax.sql.DataSource;osgi.jndi.service.name=jdbc/fooDS
        </capability>


@Component
public class RestService {

@Reference(target = "(&(objectclass=org.cxf.Bus)(bus.name=foo))"))
Bus bus;
    @Activate
    public void activate() throws Exception {
        JAXRSServerFactoryBean bean = new JAXRSServerFactoryBean();
        bean.setAddress("/booking");
       // bean.setBus(BusFactory.getDefaultBus());
bean.setBus(bus);
       // Providers, interceptors set up in Bus bundle...
       // bean.setProvider(new JacksonJsonProvider());
        bean.setServiceBean(new BookingServiceRest());
        bean.create();
    }

}





--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

Ranx0r0x
I noticed that when I stopped/uninstalled the bundle the CXF endpoint was
still up and the bundle couldn't be reinstalled. By saving the Server and
destroying it on @Deactivate it correctly went away. There may be a more
elegant or better way to do this but it may be that it should be part of the
sample code.

@Component
public class RestServiceBootstrap {

        private MyInjectedService injectedService;
        private Server server;
        @Activate
        public void activate() throws Exception {
                System.out.println("Activate the MemberServiceImpl");
                JAXRSServerFactoryBean bean = new JAXRSServerFactoryBean();
                bean.setAddress("/foo");
                bean.setBus(BusFactory.getDefaultBus());
                bean.setServiceBean(new RestServiceImpl(injectService));
                server = bean.create();
        }

        @Deactivate
        public void deactivate() {
                System.out.println("Deactivating server: " + server);
                server.destroy();
        }



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

jbonofre
Hi

Good point, I forgot to destroy the CXF RS server.

I created https://issues.apache.org/jira/browse/KARAF-6523 for the
tracking and I'm fixing that.

Thanks
Regards
JB

On 20/11/2019 00:54, Ranx0r0x wrote:

> I noticed that when I stopped/uninstalled the bundle the CXF endpoint was
> still up and the bundle couldn't be reinstalled. By saving the Server and
> destroying it on @Deactivate it correctly went away. There may be a more
> elegant or better way to do this but it may be that it should be part of the
> sample code.
>
> @Component
> public class RestServiceBootstrap {
>
> private MyInjectedService injectedService;
> private Server server;
> @Activate
> public void activate() throws Exception {
> System.out.println("Activate the MemberServiceImpl");
> JAXRSServerFactoryBean bean = new JAXRSServerFactoryBean();
> bean.setAddress("/foo");
> bean.setBus(BusFactory.getDefaultBus());
> bean.setServiceBean(new RestServiceImpl(injectService));
> server = bean.create();
> }
>
> @Deactivate
> public void deactivate() {
> System.out.println("Deactivating server: " + server);
> server.destroy();
> }
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

cschneider
In reply to this post by Ranx0r0x
The elegant way is to use the Aries JAXRS Whiteboard.

Christian

Am Mi., 20. Nov. 2019 um 00:54 Uhr schrieb Ranx0r0x <[hidden email]>:
I noticed that when I stopped/uninstalled the bundle the CXF endpoint was
still up and the bundle couldn't be reinstalled. By saving the Server and
destroying it on @Deactivate it correctly went away. There may be a more
elegant or better way to do this but it may be that it should be part of the
sample code.

@Component
public class RestServiceBootstrap {

        private MyInjectedService injectedService;
        private Server server;
        @Activate
        public void activate() throws Exception {
                System.out.println("Activate the MemberServiceImpl");
                JAXRSServerFactoryBean bean = new JAXRSServerFactoryBean();
                bean.setAddress("/foo");
                bean.setBus(BusFactory.getDefaultBus());
                bean.setServiceBean(new RestServiceImpl(injectService));
                server = bean.create();
        }

        @Deactivate
        public void deactivate() {
                System.out.println("Deactivating server: " + server);
                server.destroy();
        }



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


--
--
Christian Schneider

http://www.liquid-reality.de

Computer Scientist

Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

jbonofre
That's another approach depending of the "control" you want.

The examples also show jaxrs whiteboard approach.

Regards
JB

On 20/11/2019 15:35, Christian Schneider wrote:

> The elegant way is to use the Aries JAXRS Whiteboard.
>
> Christian
>
> Am Mi., 20. Nov. 2019 um 00:54 Uhr schrieb Ranx0r0x
> <[hidden email] <mailto:[hidden email]>>:
>
>     I noticed that when I stopped/uninstalled the bundle the CXF
>     endpoint was
>     still up and the bundle couldn't be reinstalled. By saving the
>     Server and
>     destroying it on @Deactivate it correctly went away. There may be a more
>     elegant or better way to do this but it may be that it should be
>     part of the
>     sample code.
>
>     @Component
>     public class RestServiceBootstrap {
>
>             private MyInjectedService injectedService;
>             private Server server;
>             @Activate
>             public void activate() throws Exception {
>                     System.out.println("Activate the MemberServiceImpl");
>                     JAXRSServerFactoryBean bean = new
>     JAXRSServerFactoryBean();
>                     bean.setAddress("/foo");
>                     bean.setBus(BusFactory.getDefaultBus());
>                     bean.setServiceBean(new RestServiceImpl(injectService));
>                     server = bean.create();
>             }
>
>             @Deactivate
>             public void deactivate() {
>                     System.out.println("Deactivating server: " + server);
>                     server.destroy();
>             }
>
>
>
>     --
>     Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

Ranx0r0x
In reply to this post by cschneider
Christian,

That's probably not going to happen as we migrate over with all the plugins,
providers and interceptors setup in the current environment to a better more
decoupled design but still using CXF. I'm not even 100% positive I'm free of
SOAP endpoints yet.

We a number of endpoints with different authentication mechanics and
different logging requirements and that's why I'm trying to find a good way
to implement and share bus configurations. I have one way of doing it via
Blueprint that works and with the DS JAX RS I'll be working today on seeing
if I can't create a standard mechanic for it that might have a number of
defaults that can be set via cfg much like PAX JDBC. As an example, being
able to enable/disable logging at the in/out interceptors would be nice.
JAAS Authentication may be another. Haven't cracked it open yet.


But I can easily bootstrap a similar component for SOAP if I needed using
the same interface.

I'm certainly wiling to be convinced that JAXRS Witeboard is more elegant if
I see some compelling examples showing different security and logging
configurations that snap into place for different use cases. Then I can sell
it to my colleagues as a better way of refactoring the project.

Honestly I've seen snippets and some examples of JAX RS Whitebaord but can
say I never went "Wow! That's so cool. I have to use that...." That might be
due to my lack of exposure or just that the samples weren't particularly
overwhelming.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

Oliver Schweitzer
I understand where you’re coming from.

So Christian is basically right, the Jax-RS Whiteboard, like the whole DS approach, feels somewhat like the future - a clean, elegant form of building dynamic modular, standards-based services with Java. For me, the Wow! happened.

But it’s only almost, not quite there yet, in terms of working, understandable but, and maybe that’s the point, more feature-complete or complex examples or projects, or even ready-made features. Not snippets.

For my own “enterprisey" setup I believe I have everything working I need right now - e.g. Cors, Jaas, Serialisation, OpenAPI - but a lot of that I had to write myself or scrounge from all over the 'net, and the “fluency” and the feeling of full control isn’t yet there for me.

What made things easier for me was that I tried to use an “almost pure” Jax-RS approach from the beginning, even before moving to Karaf. Migrating from a proprietary, custom CXF setup to this brave new world might well be a challenge and involve a whole lot of "basic research" right now.

As for me, a new REST Service I’d gladly build with DS/Jax-RS Whiteboard again, and for an existing, proprietary system with a long enough expected lifetime I’d give a serious look at migrating.

Best regards,

Oliver

On 20. Nov 2019, at 15:53, Ranx0r0x <[hidden email]> wrote:

>
> Christian,
>
> That's probably not going to happen as we migrate over with all the plugins,
> providers and interceptors setup in the current environment to a better more
> decoupled design but still using CXF. I'm not even 100% positive I'm free of
> SOAP endpoints yet.
>
> We a number of endpoints with different authentication mechanics and
> different logging requirements and that's why I'm trying to find a good way
> to implement and share bus configurations. I have one way of doing it via
> Blueprint that works and with the DS JAX RS I'll be working today on seeing
> if I can't create a standard mechanic for it that might have a number of
> defaults that can be set via cfg much like PAX JDBC. As an example, being
> able to enable/disable logging at the in/out interceptors would be nice.
> JAAS Authentication may be another. Haven't cracked it open yet.
>
>
> But I can easily bootstrap a similar component for SOAP if I needed using
> the same interface.
>
> I'm certainly wiling to be convinced that JAXRS Witeboard is more elegant if
> I see some compelling examples showing different security and logging
> configurations that snap into place for different use cases. Then I can sell
> it to my colleagues as a better way of refactoring the project.
>
> Honestly I've seen snippets and some examples of JAX RS Whitebaord but can
> say I never went "Wow! That's so cool. I have to use that...." That might be
> due to my lack of exposure or just that the samples weren't particularly
> overwhelming.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

Scott Lewis
FWIW,

Another approach is to use OSGi Remote Services [1]...specifically ECF's
JaxRS distribution provider impls [2]. Remote Services Admin creates a
proxy for the remote service and this proxy is/may be treated as a local
service by SCR.

The ECF impl allows pluggable distribution providers, and the repo here
[2] uses Jersey or CXF along with the JaxRS-standard annotations + the
OSGi standard remote service properties.  See examples and tutorials [2].

Although remote services wasn't built with JaxRS transport specifically
in mind, it does IMHO integrate naturally with service registry and
SCR...especially WRT service discovery, proxy creation, API versioning,
and service dynamics.

ECF's impl allows the creation of new distribution providers, or
extension/customization of the existing providers (using JaxRS extension
mechanisms and/or Jersey or CXF extension mechanisms).

For more info please see [3]

Scott

[1]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html

[2] https://github.com/ECF/JaxRSProviders

[3] http://eclipseecf.blogspot.com/2019/11/ecf-3146-released_2.html

On 11/20/2019 8:29 AM, Oliver Schweitzer wrote:

> I understand where you’re coming from.
>
> So Christian is basically right, the Jax-RS Whiteboard, like the whole DS approach, feels somewhat like the future - a clean, elegant form of building dynamic modular, standards-based services with Java. For me, the Wow! happened.
>
> But it’s only almost, not quite there yet, in terms of working, understandable but, and maybe that’s the point, more feature-complete or complex examples or projects, or even ready-made features. Not snippets.
>
> For my own “enterprisey" setup I believe I have everything working I need right now - e.g. Cors, Jaas, Serialisation, OpenAPI - but a lot of that I had to write myself or scrounge from all over the 'net, and the “fluency” and the feeling of full control isn’t yet there for me.
>
> What made things easier for me was that I tried to use an “almost pure” Jax-RS approach from the beginning, even before moving to Karaf. Migrating from a proprietary, custom CXF setup to this brave new world might well be a challenge and involve a whole lot of "basic research" right now.
>
> As for me, a new REST Service I’d gladly build with DS/Jax-RS Whiteboard again, and for an existing, proprietary system with a long enough expected lifetime I’d give a serious look at migrating.
>
> Best regards,
>
> Oliver
>
> On 20. Nov 2019, at 15:53, Ranx0r0x <[hidden email]> wrote:
>> Christian,
>>
>> That's probably not going to happen as we migrate over with all the plugins,
>> providers and interceptors setup in the current environment to a better more
>> decoupled design but still using CXF. I'm not even 100% positive I'm free of
>> SOAP endpoints yet.
>>
>> We a number of endpoints with different authentication mechanics and
>> different logging requirements and that's why I'm trying to find a good way
>> to implement and share bus configurations. I have one way of doing it via
>> Blueprint that works and with the DS JAX RS I'll be working today on seeing
>> if I can't create a standard mechanic for it that might have a number of
>> defaults that can be set via cfg much like PAX JDBC. As an example, being
>> able to enable/disable logging at the in/out interceptors would be nice.
>> JAAS Authentication may be another. Haven't cracked it open yet.
>>
>>
>> But I can easily bootstrap a similar component for SOAP if I needed using
>> the same interface.
>>
>> I'm certainly wiling to be convinced that JAXRS Witeboard is more elegant if
>> I see some compelling examples showing different security and logging
>> configurations that snap into place for different use cases. Then I can sell
>> it to my colleagues as a better way of refactoring the project.
>>
>> Honestly I've seen snippets and some examples of JAX RS Whitebaord but can
>> say I never went "Wow! That's so cool. I have to use that...." That might be
>> due to my lack of exposure or just that the samples weren't particularly
>> overwhelming.
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

Ranx0r0x
Thanks for all the feedback. I'm sure the JAX RS Whiteboard is much cleaner.
I've got legacy code I'm dealing with and can only go so far. JBs code would
also be applicable to a JAXWSFactoryBean if I have to set up a related SOAP
service. I commonly annotate my interfaces with both SOAP and REST
annotations. The only thing they commonly share is some bus with bus ID -
either the default Bus or, more commonly, a Bus by ID that is shared across
some subset of the web services.

What I'm currently working on is a CXF Bus managed service factory that is
more like PAX JDBC but for CXF Busses. This service factory is listening for
PIDs starting with org.apache.cxf.bus-* which will trigger the update.

I'm going to create a plugin interface that takes the properties and Bus
interface and I can then configure things for JAASAuthentication, logging,
etc.

@Override
public void updated(String pid, Dictionary<String, ?> properties) throws
ConfigurationException {


So this might be my logging plugin. Just a change in the cfg changes what is
logged (most organizations don't want production stuff logged but want to
log during dev and QA). This let's me keep the same bus ID but change the
logging.

Since I'm developing this for a specific business use case I don't have to
have plugin support of everything in the world. The Bus factory just has to
support the superset of features/providers/interceptors required  for the
instance and this let's me also keep it so that I can install 1...N services
in the container but not require any particular mix.


I can unit test these individual plugins with Mockito mocks of the Bus via
the plugin interface. Basically just checking that the properties are
resulting in correct configuration of interceptors.

Just switching to code helps a lot. In Blueprint you don't see that these
interceptors are deprecated, for example.

        private final LoggingInInterceptor loggingIn = new
LoggingInInterceptor();
        private final LoggingOutInterceptor loggingOut = new
LoggingOutInterceptor();
       
        public void initBus(Bus bus, Dictionary<String, ?> properties) {
                Boolean logIn = (Boolean) properties.get("logIn");
                Boolean logOut=(Boolean) properties.get("logOut");
                Boolean errorLogIn =(Boolean) properties.get("errorLogIn");
                Boolean errorLogOut =(Boolean) properties.get("errorLogIn");
                if(logIn)
                        bus.getInInterceptors().add(loggingIn);
                if(logOut)
                        bus.getOutInterceptors().add(loggingOut);
                if(errorLogOut)
                        bus.getOutFaultInterceptors().add(loggingOut);
                if(errorLogIn)
                        bus.getInFaultInterceptors().add(loggingIn);
        }



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

jbonofre
Hi,

you have the same for SOAP already available in the example:

https://github.com/apache/karaf/tree/master/examples/karaf-soap-example/karaf-soap-example-scr

Regards
JB

On 21/11/2019 17:31, Ranx0r0x wrote:

> Thanks for all the feedback. I'm sure the JAX RS Whiteboard is much cleaner.
> I've got legacy code I'm dealing with and can only go so far. JBs code would
> also be applicable to a JAXWSFactoryBean if I have to set up a related SOAP
> service. I commonly annotate my interfaces with both SOAP and REST
> annotations. The only thing they commonly share is some bus with bus ID -
> either the default Bus or, more commonly, a Bus by ID that is shared across
> some subset of the web services.
>
> What I'm currently working on is a CXF Bus managed service factory that is
> more like PAX JDBC but for CXF Busses. This service factory is listening for
> PIDs starting with org.apache.cxf.bus-* which will trigger the update.
>
> I'm going to create a plugin interface that takes the properties and Bus
> interface and I can then configure things for JAASAuthentication, logging,
> etc.
>
> @Override
> public void updated(String pid, Dictionary<String, ?> properties) throws
> ConfigurationException {
>
>
> So this might be my logging plugin. Just a change in the cfg changes what is
> logged (most organizations don't want production stuff logged but want to
> log during dev and QA). This let's me keep the same bus ID but change the
> logging.
>
> Since I'm developing this for a specific business use case I don't have to
> have plugin support of everything in the world. The Bus factory just has to
> support the superset of features/providers/interceptors required  for the
> instance and this let's me also keep it so that I can install 1...N services
> in the container but not require any particular mix.
>
>
> I can unit test these individual plugins with Mockito mocks of the Bus via
> the plugin interface. Basically just checking that the properties are
> resulting in correct configuration of interceptors.
>
> Just switching to code helps a lot. In Blueprint you don't see that these
> interceptors are deprecated, for example.
>
>         private final LoggingInInterceptor loggingIn = new
> LoggingInInterceptor();
> private final LoggingOutInterceptor loggingOut = new
> LoggingOutInterceptor();
>
> public void initBus(Bus bus, Dictionary<String, ?> properties) {
> Boolean logIn = (Boolean) properties.get("logIn");
> Boolean logOut=(Boolean) properties.get("logOut");
> Boolean errorLogIn =(Boolean) properties.get("errorLogIn");
> Boolean errorLogOut =(Boolean) properties.get("errorLogIn");
> if(logIn)
> bus.getInInterceptors().add(loggingIn);
> if(logOut)
> bus.getOutInterceptors().add(loggingOut);
> if(errorLogOut)
> bus.getOutFaultInterceptors().add(loggingOut);
> if(errorLogIn)
> bus.getInFaultInterceptors().add(loggingIn);
> }
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

Ranx0r0x
In reply to this post by Ranx0r0x
If I'm correct this will get the behavior I'm after with any cfg file
associated with org.apache.cxf.bus-*.cfg triggering this.

This seems to work correctly but is a rather different design than what I'd
envisioned but that may only be due to older understanding of services,
managed service factories, trackers, etc. It appears that I don't need that
really. Any org.apache.cxf.bus-*.cfg file will trigger the creation of a new
component and service.  And the update works correctly from what I can see.

In karaf, when I type the cxf:list-busses I see a bus per cfg file. If I do
something like change the id in the cfg file, I see that reflect in the
cxf:list-busses.

This also means I can use an @Reference with id= filter to inject the Bus
interface into the correct location and then use that to instantiate CXF
components per the example DS code that JB put up.

It's possible I'm missing something here however as I have a lot more
experience with Blueprint and even regular Java activator based OSGi and
less with DS.

The plugins implement an interface with a single method of init(Bus,
Map<String,Object>).  So each is testable independently.




@Component(
                service = Bus.class,
                configurationPid = "org.apache.cxf.bus"
                         
)
public class StandardBus extends ExtensionManagerBus implements Bus{

        public StandardBus() {
                super(null, null, StandardBus.class.getClassLoader());
    }

    private List<BusConfiguratorPlugin> plugins = new
ArrayList<BusConfiguratorPlugin>();

    private void initPlugins() {
                // TODO Could take package/class list from the cfg associated with this
factory.
                plugins.add(new BusIdentifierPlugin());
                plugins.add(new LoggingBusConfiguratorPlugin());
                // TODO Add plugins for JAASAuthenticationFeature and others as needed..

        }
       


        @Activate
        public void init(Map<String, Object> properties) {
                initPlugins();
                init(this,properties);
        }
        @Modified
    public void modified(Map<String, Object> properties) {
        init(this,properties);
    }
 
    @Deactivate
    public void deactivate() {
   
    }
   
    private void init(Bus bus,Map<String, Object> properties) {
    plugins.forEach((plugin) -> plugin.init(bus, properties));
    }
   
}




--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Reply | Threaded
Open this post in threaded view
|

Re: Karaf CXF SCR REST example...

Ranx0r0x
In reply to this post by Ranx0r0x
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