Help understanding the OSGi based CXF rest service registration

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Help understanding the OSGi based CXF rest service registration

Martin Nielsen
Hello

I am looking into creating a service-discovery method to register rest
endpoints in cxf running in OSGi, as an alternative to
org.apache.cxf.transport.http_jetty.osgi.HTTPJettyTransportActivator.

I realize dosgi-cxf exists, but it doesn't quite cover my use case.

But to be honest I could really use some help understanding the different
components at play here.

Can someone give me an overview over the responsibilities of the different
components at play, mainly the JettyHTTPServerEngineFactory and
JettyHTTPServerEngine.
Anything insigt you can give me into the workings and possibly caveats with
these clases would be helpful, but I also have a couple of concrete
questions:

In the documentation on this page
https://cwiki.apache.org/confluence/display/CXF20DOC/Standalone+HTTP+Transport
it seems that the TLSParameters can be registered for each "Endpoint". Is
that the JettyHTTPServerEngine engine in the code?

Is it possible to set new TLSParameters while the endpoint/engine/whichever
after services are registered to it?

How does the HTTPJettyTransportActivator clean up when it shuts down? I
don't see any cleanup in the code. Does it just garbage-collect the
endpoints if the bundle stops?

Can you point me to the classes that takes care of registering services
through blueprints? I have never really dabbled in blueprints and I am
having a hard time getting my head around it.

Thank you
-Martin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help understanding the OSGi based CXF rest service registration

Martin Nielsen
I forgot to add that considering the blueprint/spring configuration, what i
really need is for someone to point me towards the xml parsing that takes
the serviceBeans and registers them through cxf to Jetty.

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"
           xmlns:cxf="http://cxf.apache.org/blueprint/core"
           xsi:schemaLocation="
             http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
             http://cxf.apache.org/blueprint/jaxrs
http://cxf.apache.org/schemas/blueprint/jaxrs.xsd
             http://cxf.apache.org/blueprint/core
http://cxf.apache.org/schemas/blueprint/core.xsd
             ">

    <cxf:bus>
        <cxf:features>
            <cxf:logging/>
        </cxf:features>
    </cxf:bus>

     <jaxrs:server id="customerService" address="/customers">
        <jaxrs:serviceBeans>
           <ref component-id="serviceBean" />
        </jaxrs:serviceBeans>
     </jaxrs:server>

     <bean id="serviceBean" class="service.CustomerService"/>
</blueprint>

On Tue, Jun 6, 2017 at 12:03 PM, Martin Nielsen <[hidden email]> wrote:

> Hello
>
> I am looking into creating a service-discovery method to register rest
> endpoints in cxf running in OSGi, as an alternative to
> org.apache.cxf.transport.http_jetty.osgi.HTTPJettyTransportActivator.
>
> I realize dosgi-cxf exists, but it doesn't quite cover my use case.
>
> But to be honest I could really use some help understanding the different
> components at play here.
>
> Can someone give me an overview over the responsibilities of the different
> components at play, mainly the JettyHTTPServerEngineFactory and
> JettyHTTPServerEngine.
> Anything insigt you can give me into the workings and possibly caveats
> with these clases would be helpful, but I also have a couple of concrete
> questions:
>
> In the documentation on this page https://cwiki.apache.org/
> confluence/display/CXF20DOC/Standalone+HTTP+Transport it seems that the
> TLSParameters can be registered for each "Endpoint". Is that the
> JettyHTTPServerEngine engine in the code?
>
> Is it possible to set new TLSParameters while the
> endpoint/engine/whichever after services are registered to it?
>
> How does the HTTPJettyTransportActivator clean up when it shuts down? I
> don't see any cleanup in the code. Does it just garbage-collect the
> endpoints if the bundle stops?
>
> Can you point me to the classes that takes care of registering services
> through blueprints? I have never really dabbled in blueprints and I am
> having a hard time getting my head around it.
>
> Thank you
> -Martin
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help understanding the OSGi based CXF rest service registration

Randy Leonard
Martini:

I am using Apache CXF SOAP services with OSGI enRoute, with multiple CXF buses.  My work on this pre-dates DOSGI and works just fine.

If you wish, I can put some sample code together for you… you can convert to REST and post to the group?  Let me know.

Randy


> On Jun 6, 2017, at 7:17 AM, Martin Nielsen <[hidden email]> wrote:
>
> I forgot to add that considering the blueprint/spring configuration, what i
> really need is for someone to point me towards the xml parsing that takes
> the serviceBeans and registers them through cxf to Jetty.
>
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>           xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"
>           xmlns:cxf="http://cxf.apache.org/blueprint/core"
>           xsi:schemaLocation="
>             http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>             http://cxf.apache.org/blueprint/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd
>             http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>             ">
>
>    <cxf:bus>
>        <cxf:features>
>            <cxf:logging/>
>        </cxf:features>
>    </cxf:bus>
>
>     <jaxrs:server id="customerService" address="/customers">
>        <jaxrs:serviceBeans>
>           <ref component-id="serviceBean" />
>        </jaxrs:serviceBeans>
>     </jaxrs:server>
>
>     <bean id="serviceBean" class="service.CustomerService"/>
> </blueprint>
>
> On Tue, Jun 6, 2017 at 12:03 PM, Martin Nielsen <[hidden email]> wrote:
>
>> Hello
>>
>> I am looking into creating a service-discovery method to register rest
>> endpoints in cxf running in OSGi, as an alternative to
>> org.apache.cxf.transport.http_jetty.osgi.HTTPJettyTransportActivator.
>>
>> I realize dosgi-cxf exists, but it doesn't quite cover my use case.
>>
>> But to be honest I could really use some help understanding the different
>> components at play here.
>>
>> Can someone give me an overview over the responsibilities of the different
>> components at play, mainly the JettyHTTPServerEngineFactory and
>> JettyHTTPServerEngine.
>> Anything insigt you can give me into the workings and possibly caveats
>> with these clases would be helpful, but I also have a couple of concrete
>> questions:
>>
>> In the documentation on this page https://cwiki.apache.org/
>> confluence/display/CXF20DOC/Standalone+HTTP+Transport it seems that the
>> TLSParameters can be registered for each "Endpoint". Is that the
>> JettyHTTPServerEngine engine in the code?
>>
>> Is it possible to set new TLSParameters while the
>> endpoint/engine/whichever after services are registered to it?
>>
>> How does the HTTPJettyTransportActivator clean up when it shuts down? I
>> don't see any cleanup in the code. Does it just garbage-collect the
>> endpoints if the bundle stops?
>>
>> Can you point me to the classes that takes care of registering services
>> through blueprints? I have never really dabbled in blueprints and I am
>> having a hard time getting my head around it.
>>
>> Thank you
>> -Martin
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help understanding the OSGi based CXF rest service registration

Martin Nielsen
I would be very interested to see that if you feel up to it. And yes if i
get something even remotely functional i will post back here.

On 7 Jun 2017 09:42, "Randy Leonard" <[hidden email]> wrote:

> Martini:
>
> I am using Apache CXF SOAP services with OSGI enRoute, with multiple CXF
> buses.  My work on this pre-dates DOSGI and works just fine.
>
> If you wish, I can put some sample code together for you… you can convert
> to REST and post to the group?  Let me know.
>
> Randy
>
>
> > On Jun 6, 2017, at 7:17 AM, Martin Nielsen <[hidden email]> wrote:
> >
> > I forgot to add that considering the blueprint/spring configuration,
> what i
> > really need is for someone to point me towards the xml parsing that takes
> > the serviceBeans and registers them through cxf to Jetty.
> >
> > <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> >           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >           xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"
> >           xmlns:cxf="http://cxf.apache.org/blueprint/core"
> >           xsi:schemaLocation="
> >             http://www.osgi.org/xmlns/blueprint/v1.0.0
> > http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> >             http://cxf.apache.org/blueprint/jaxrs
> > http://cxf.apache.org/schemas/blueprint/jaxrs.xsd
> >             http://cxf.apache.org/blueprint/core
> > http://cxf.apache.org/schemas/blueprint/core.xsd
> >             ">
> >
> >    <cxf:bus>
> >        <cxf:features>
> >            <cxf:logging/>
> >        </cxf:features>
> >    </cxf:bus>
> >
> >     <jaxrs:server id="customerService" address="/customers">
> >        <jaxrs:serviceBeans>
> >           <ref component-id="serviceBean" />
> >        </jaxrs:serviceBeans>
> >     </jaxrs:server>
> >
> >     <bean id="serviceBean" class="service.CustomerService"/>
> > </blueprint>
> >
> > On Tue, Jun 6, 2017 at 12:03 PM, Martin Nielsen <[hidden email]>
> wrote:
> >
> >> Hello
> >>
> >> I am looking into creating a service-discovery method to register rest
> >> endpoints in cxf running in OSGi, as an alternative to
> >> org.apache.cxf.transport.http_jetty.osgi.HTTPJettyTransportActivator.
> >>
> >> I realize dosgi-cxf exists, but it doesn't quite cover my use case.
> >>
> >> But to be honest I could really use some help understanding the
> different
> >> components at play here.
> >>
> >> Can someone give me an overview over the responsibilities of the
> different
> >> components at play, mainly the JettyHTTPServerEngineFactory and
> >> JettyHTTPServerEngine.
> >> Anything insigt you can give me into the workings and possibly caveats
> >> with these clases would be helpful, but I also have a couple of concrete
> >> questions:
> >>
> >> In the documentation on this page https://cwiki.apache.org/
> >> confluence/display/CXF20DOC/Standalone+HTTP+Transport it seems that the
> >> TLSParameters can be registered for each "Endpoint". Is that the
> >> JettyHTTPServerEngine engine in the code?
> >>
> >> Is it possible to set new TLSParameters while the
> >> endpoint/engine/whichever after services are registered to it?
> >>
> >> How does the HTTPJettyTransportActivator clean up when it shuts down? I
> >> don't see any cleanup in the code. Does it just garbage-collect the
> >> endpoints if the bundle stops?
> >>
> >> Can you point me to the classes that takes care of registering services
> >> through blueprints? I have never really dabbled in blueprints and I am
> >> having a hard time getting my head around it.
> >>
> >> Thank you
> >> -Martin
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help understanding the OSGi based CXF rest service registration

Martin Nielsen
So! I have now created a relatively restrictive proof of concept.

https://github.com/mnybon/cxf-osgi-activator

The project looks for service registrations with jax-rs annotations on
their services. When it finds one it builds a server for it and registers
it in CXF. There is not much doc yet but there is a simple integration test
and test resources which works well as a sample.

Basically, what is possible right now is the following:
Registering classes as services by registering them as an OSGi service.
Registering services at runtime.
Registering several resource classes with different paths on the same
server.
Registering classes with several jax-rs interfaces as several services at
once.
Registering services on userdefined paths, using annotations or service
properties.
Unregistering services at runtime.
Setting TLSServerParameters on specific ports, allowing for on-the-fly SSL
configuration of any unused port.


A kind of important caveat: I don't have all that much experience with the
deeper levels of CXF, and as such, I assume that there are several things
that could have been done a lot smarter. The obvious one is that if you
register a new service on a running endpoint (for example
http://localhost:3456/services) then the entire
http://localhost:3456/services will be taken down momentarily while the
server is rebuilt.



I haven't tested any advanced features of CXF yet, as I said, it is a proof
of concept and work in progress.

But take a look and tell me what you think. I can think of more than a few
places where I could use this and i hope i'm not alone.

-Martin



On Wed, Jun 7, 2017 at 5:40 PM, Martin Nielsen <[hidden email]> wrote:

> I would be very interested to see that if you feel up to it. And yes if i
> get something even remotely functional i will post back here.
>
> On 7 Jun 2017 09:42, "Randy Leonard" <[hidden email]> wrote:
>
>> Martini:
>>
>> I am using Apache CXF SOAP services with OSGI enRoute, with multiple CXF
>> buses.  My work on this pre-dates DOSGI and works just fine.
>>
>> If you wish, I can put some sample code together for you… you can convert
>> to REST and post to the group?  Let me know.
>>
>> Randy
>>
>>
>> > On Jun 6, 2017, at 7:17 AM, Martin Nielsen <[hidden email]> wrote:
>> >
>> > I forgot to add that considering the blueprint/spring configuration,
>> what i
>> > really need is for someone to point me towards the xml parsing that
>> takes
>> > the serviceBeans and registers them through cxf to Jetty.
>> >
>> > <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>> >           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> >           xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"
>> >           xmlns:cxf="http://cxf.apache.org/blueprint/core"
>> >           xsi:schemaLocation="
>> >             http://www.osgi.org/xmlns/blueprint/v1.0.0
>> > http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>> >             http://cxf.apache.org/blueprint/jaxrs
>> > http://cxf.apache.org/schemas/blueprint/jaxrs.xsd
>> >             http://cxf.apache.org/blueprint/core
>> > http://cxf.apache.org/schemas/blueprint/core.xsd
>> >             ">
>> >
>> >    <cxf:bus>
>> >        <cxf:features>
>> >            <cxf:logging/>
>> >        </cxf:features>
>> >    </cxf:bus>
>> >
>> >     <jaxrs:server id="customerService" address="/customers">
>> >        <jaxrs:serviceBeans>
>> >           <ref component-id="serviceBean" />
>> >        </jaxrs:serviceBeans>
>> >     </jaxrs:server>
>> >
>> >     <bean id="serviceBean" class="service.CustomerService"/>
>> > </blueprint>
>> >
>> > On Tue, Jun 6, 2017 at 12:03 PM, Martin Nielsen <[hidden email]>
>> wrote:
>> >
>> >> Hello
>> >>
>> >> I am looking into creating a service-discovery method to register rest
>> >> endpoints in cxf running in OSGi, as an alternative to
>> >> org.apache.cxf.transport.http_jetty.osgi.HTTPJettyTransportActivator.
>> >>
>> >> I realize dosgi-cxf exists, but it doesn't quite cover my use case.
>> >>
>> >> But to be honest I could really use some help understanding the
>> different
>> >> components at play here.
>> >>
>> >> Can someone give me an overview over the responsibilities of the
>> different
>> >> components at play, mainly the JettyHTTPServerEngineFactory and
>> >> JettyHTTPServerEngine.
>> >> Anything insigt you can give me into the workings and possibly caveats
>> >> with these clases would be helpful, but I also have a couple of
>> concrete
>> >> questions:
>> >>
>> >> In the documentation on this page https://cwiki.apache.org/
>> >> confluence/display/CXF20DOC/Standalone+HTTP+Transport it seems that
>> the
>> >> TLSParameters can be registered for each "Endpoint". Is that the
>> >> JettyHTTPServerEngine engine in the code?
>> >>
>> >> Is it possible to set new TLSParameters while the
>> >> endpoint/engine/whichever after services are registered to it?
>> >>
>> >> How does the HTTPJettyTransportActivator clean up when it shuts down? I
>> >> don't see any cleanup in the code. Does it just garbage-collect the
>> >> endpoints if the bundle stops?
>> >>
>> >> Can you point me to the classes that takes care of registering services
>> >> through blueprints? I have never really dabbled in blueprints and I am
>> >> having a hard time getting my head around it.
>> >>
>> >> Thank you
>> >> -Martin
>> >>
>>
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help understanding the OSGi based CXF rest service registration

cschneider
In reply to this post by Martin Nielsen
Before creating something completely new I recommend you explain what your
requirements are. Maybe there is an existing project you can help improve
instead of creating another way to export JAX-RS services.

You mention that CXF-DOSGi does not cover your case. What are you missing?

There is also https://github.com/apache/aries-jax-rs-whiteboard which
covers a similar case as DOSGi in a slighty different way.

Christian

2017-06-06 12:03 GMT+02:00 Martin Nielsen <[hidden email]>:

> Hello
>
> I am looking into creating a service-discovery method to register rest
> endpoints in cxf running in OSGi, as an alternative to
> org.apache.cxf.transport.http_jetty.osgi.HTTPJettyTransportActivator.
>
> I realize dosgi-cxf exists, but it doesn't quite cover my use case.
>
> But to be honest I could really use some help understanding the different
> components at play here.
>
> Can someone give me an overview over the responsibilities of the different
> components at play, mainly the JettyHTTPServerEngineFactory and
> JettyHTTPServerEngine.
> Anything insigt you can give me into the workings and possibly caveats with
> these clases would be helpful, but I also have a couple of concrete
> questions:
>
> In the documentation on this page
> https://cwiki.apache.org/confluence/display/CXF20DOC/
> Standalone+HTTP+Transport
> it seems that the TLSParameters can be registered for each "Endpoint". Is
> that the JettyHTTPServerEngine engine in the code?
>
> Is it possible to set new TLSParameters while the endpoint/engine/whichever
> after services are registered to it?
>
> How does the HTTPJettyTransportActivator clean up when it shuts down? I
> don't see any cleanup in the code. Does it just garbage-collect the
> endpoints if the bundle stops?
>
> Can you point me to the classes that takes care of registering services
> through blueprints? I have never really dabbled in blueprints and I am
> having a hard time getting my head around it.
>
> Thank you
> -Martin
>



--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help understanding the OSGi based CXF rest service registration

Martin Nielsen
The main reason i started this project is that i could not i find a project
which allowed me to control the SSL context of hosted services
programatically. I needed a way to configure Key -and Trust managers
programmatically. Then only solutions i could find allowed me to point to
keystores somewhere on the filesystem. What i need is to inject my own
trust and keystore implementations.

So that is the reason I decided to attempt my own version. I actually
started out by trying to figure out how to introduce that functionality
into cxf-dosgi, but there is no access to to the actual cxf engine. So it
didn't seem to be in tune with the overall design of the project.



On Fri, Jun 23, 2017 at 7:14 AM, Christian Schneider <
[hidden email]> wrote:

> Before creating something completely new I recommend you explain what your
> requirements are. Maybe there is an existing project you can help improve
> instead of creating another way to export JAX-RS services.
>
> You mention that CXF-DOSGi does not cover your case. What are you missing?
>
> There is also https://github.com/apache/aries-jax-rs-whiteboard which
> covers a similar case as DOSGi in a slighty different way.
>
> Christian
>
> 2017-06-06 12:03 GMT+02:00 Martin Nielsen <[hidden email]>:
>
> > Hello
> >
> > I am looking into creating a service-discovery method to register rest
> > endpoints in cxf running in OSGi, as an alternative to
> > org.apache.cxf.transport.http_jetty.osgi.HTTPJettyTransportActivator.
> >
> > I realize dosgi-cxf exists, but it doesn't quite cover my use case.
> >
> > But to be honest I could really use some help understanding the different
> > components at play here.
> >
> > Can someone give me an overview over the responsibilities of the
> different
> > components at play, mainly the JettyHTTPServerEngineFactory and
> > JettyHTTPServerEngine.
> > Anything insigt you can give me into the workings and possibly caveats
> with
> > these clases would be helpful, but I also have a couple of concrete
> > questions:
> >
> > In the documentation on this page
> > https://cwiki.apache.org/confluence/display/CXF20DOC/
> > Standalone+HTTP+Transport
> > it seems that the TLSParameters can be registered for each "Endpoint". Is
> > that the JettyHTTPServerEngine engine in the code?
> >
> > Is it possible to set new TLSParameters while the
> endpoint/engine/whichever
> > after services are registered to it?
> >
> > How does the HTTPJettyTransportActivator clean up when it shuts down? I
> > don't see any cleanup in the code. Does it just garbage-collect the
> > endpoints if the bundle stops?
> >
> > Can you point me to the classes that takes care of registering services
> > through blueprints? I have never really dabbled in blueprints and I am
> > having a hard time getting my head around it.
> >
> > Thank you
> > -Martin
> >
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e
> 46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e
> 46&URL=http%3a%2f%2fwww.talend.com>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Help understanding the OSGi based CXF rest service registration

Andrei Shakirin
Hi Christian,

An option to configure SSL contexts programmatically seems to be discussable DOSGi extension.
What do you think?

Regards,
Andrei

> -----Original Message-----
> From: Martin Nielsen [mailto:[hidden email]]
> Sent: Freitag, 23. Juni 2017 09:46
> To: [hidden email]
> Subject: Re: Help understanding the OSGi based CXF rest service registration
>
> The main reason i started this project is that i could not i find a project which
> allowed me to control the SSL context of hosted services programatically. I
> needed a way to configure Key -and Trust managers programmatically. Then
> only solutions i could find allowed me to point to keystores somewhere on the
> filesystem. What i need is to inject my own trust and keystore implementations.
>
> So that is the reason I decided to attempt my own version. I actually started out
> by trying to figure out how to introduce that functionality into cxf-dosgi, but
> there is no access to to the actual cxf engine. So it didn't seem to be in tune
> with the overall design of the project.
>
>
>
> On Fri, Jun 23, 2017 at 7:14 AM, Christian Schneider < chris@die-
> schneider.net> wrote:
>
> > Before creating something completely new I recommend you explain what
> > your requirements are. Maybe there is an existing project you can help
> > improve instead of creating another way to export JAX-RS services.
> >
> > You mention that CXF-DOSGi does not cover your case. What are you
> missing?
> >
> > There is also https://github.com/apache/aries-jax-rs-whiteboard which
> > covers a similar case as DOSGi in a slighty different way.
> >
> > Christian
> >
> > 2017-06-06 12:03 GMT+02:00 Martin Nielsen <[hidden email]>:
> >
> > > Hello
> > >
> > > I am looking into creating a service-discovery method to register
> > > rest endpoints in cxf running in OSGi, as an alternative to
> > > org.apache.cxf.transport.http_jetty.osgi.HTTPJettyTransportActivator.
> > >
> > > I realize dosgi-cxf exists, but it doesn't quite cover my use case.
> > >
> > > But to be honest I could really use some help understanding the
> > > different components at play here.
> > >
> > > Can someone give me an overview over the responsibilities of the
> > different
> > > components at play, mainly the JettyHTTPServerEngineFactory and
> > > JettyHTTPServerEngine.
> > > Anything insigt you can give me into the workings and possibly
> > > caveats
> > with
> > > these clases would be helpful, but I also have a couple of concrete
> > > questions:
> > >
> > > In the documentation on this page
> > > https://cwiki.apache.org/confluence/display/CXF20DOC/
> > > Standalone+HTTP+Transport
> > > it seems that the TLSParameters can be registered for each
> > > "Endpoint". Is that the JettyHTTPServerEngine engine in the code?
> > >
> > > Is it possible to set new TLSParameters while the
> > endpoint/engine/whichever
> > > after services are registered to it?
> > >
> > > How does the HTTPJettyTransportActivator clean up when it shuts
> > > down? I don't see any cleanup in the code. Does it just
> > > garbage-collect the endpoints if the bundle stops?
> > >
> > > Can you point me to the classes that takes care of registering
> > > services through blueprints? I have never really dabbled in
> > > blueprints and I am having a hard time getting my head around it.
> > >
> > > Thank you
> > > -Martin
> > >
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7
> > e 46&URL=http%3a%2f%2fwww.liquid-reality.de>
> >
> > Open Source Architect
> > http://www.talend.com
> >
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7
> > e
> > 46&URL=http%3a%2f%2fwww.talend.com>
> >
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help understanding the OSGi based CXF rest service registration

cschneider
I also think there is demand for such an option. Lets discuss how to
implement this.

Christian

2017-06-26 22:54 GMT+02:00 Andrei Shakirin <[hidden email]>:

> Hi Christian,
>
> An option to configure SSL contexts programmatically seems to be
> discussable DOSGi extension.
> What do you think?
>
> Regards,
> Andrei
>
> > -----Original Message-----
> > From: Martin Nielsen [mailto:[hidden email]]
> > Sent: Freitag, 23. Juni 2017 09:46
> > To: [hidden email]
> > Subject: Re: Help understanding the OSGi based CXF rest service
> registration
> >
> > The main reason i started this project is that i could not i find a
> project which
> > allowed me to control the SSL context of hosted services
> programatically. I
> > needed a way to configure Key -and Trust managers programmatically. Then
> > only solutions i could find allowed me to point to keystores somewhere
> on the
> > filesystem. What i need is to inject my own trust and keystore
> implementations.
> >
> > So that is the reason I decided to attempt my own version. I actually
> started out
> > by trying to figure out how to introduce that functionality into
> cxf-dosgi, but
> > there is no access to to the actual cxf engine. So it didn't seem to be
> in tune
> > with the overall design of the project.
> >
> >
> >
> > On Fri, Jun 23, 2017 at 7:14 AM, Christian Schneider < chris@die-
> > schneider.net> wrote:
> >
> > > Before creating something completely new I recommend you explain what
> > > your requirements are. Maybe there is an existing project you can help
> > > improve instead of creating another way to export JAX-RS services.
> > >
> > > You mention that CXF-DOSGi does not cover your case. What are you
> > missing?
> > >
> > > There is also https://github.com/apache/aries-jax-rs-whiteboard which
> > > covers a similar case as DOSGi in a slighty different way.
> > >
> > > Christian
> > >
> > > 2017-06-06 12:03 GMT+02:00 Martin Nielsen <[hidden email]>:
> > >
> > > > Hello
> > > >
> > > > I am looking into creating a service-discovery method to register
> > > > rest endpoints in cxf running in OSGi, as an alternative to
> > > > org.apache.cxf.transport.http_jetty.osgi.
> HTTPJettyTransportActivator.
> > > >
> > > > I realize dosgi-cxf exists, but it doesn't quite cover my use case.
> > > >
> > > > But to be honest I could really use some help understanding the
> > > > different components at play here.
> > > >
> > > > Can someone give me an overview over the responsibilities of the
> > > different
> > > > components at play, mainly the JettyHTTPServerEngineFactory and
> > > > JettyHTTPServerEngine.
> > > > Anything insigt you can give me into the workings and possibly
> > > > caveats
> > > with
> > > > these clases would be helpful, but I also have a couple of concrete
> > > > questions:
> > > >
> > > > In the documentation on this page
> > > > https://cwiki.apache.org/confluence/display/CXF20DOC/
> > > > Standalone+HTTP+Transport
> > > > it seems that the TLSParameters can be registered for each
> > > > "Endpoint". Is that the JettyHTTPServerEngine engine in the code?
> > > >
> > > > Is it possible to set new TLSParameters while the
> > > endpoint/engine/whichever
> > > > after services are registered to it?
> > > >
> > > > How does the HTTPJettyTransportActivator clean up when it shuts
> > > > down? I don't see any cleanup in the code. Does it just
> > > > garbage-collect the endpoints if the bundle stops?
> > > >
> > > > Can you point me to the classes that takes care of registering
> > > > services through blueprints? I have never really dabbled in
> > > > blueprints and I am having a hard time getting my head around it.
> > > >
> > > > Thank you
> > > > -Martin
> > > >
> > >
> > >
> > >
> > > --
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > >
> > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7
> > > e 46&URL=http%3a%2f%2fwww.liquid-reality.de>
> > >
> > > Open Source Architect
> > > http://www.talend.com
> > >
> > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7
> > > e
> > > 46&URL=http%3a%2f%2fwww.talend.com>
> > >
>



--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Loading...