Hi
On 11/01/13 01:16, geecxf wrote:
Hi Sergey,
I got it to work! I almost can't believe that it does but I'm staring at the
HTTPS response page as I'm typing this email. Thank you for pointing in me in
the right direction.
Sorry I did not answer yesterday, I had some vague idea that having the
bus configured explicitly within the application context may work, and
I'm glad to see you've made it work,
Of course, I had to take a detour to learn about spring during which I spent at
least an hour of time chasing my tail till I realized that I had to enable this
feature in Karaf with:
feature:install spring
feature:install spring-dm
I have included these details and the contents of my META-INF/spring/spring.xml
file below in the hope that this will be useful to someone else. I reused the
keystore in samples/jax_rs/basic_https. I don't however fully understand why
this solution works. My best guess, based on my feeble understanding of the
BusFactory code, is that it somehow knows how to search the for the SpringBus
instance I loaded via the bean in my spring DM file. I still haven't figured
out how to run this code in the debugger (I'm very new to development in the
Java world) but that will be my next challenge. In the meanwhile if you can
help shed some light on why it's working I would appreciate it.
I'm not exactly sure myself too, I guess only Dan knows why it works, it
is magic :-),
> <httpj:engine-factory bus="cxf">
is probably the main link between the default bus loaded within the
context and the Jetty engine.
By the way, try
"<cxf:bus id="myid"/>"
<httpj:engine-factory bus="myid">
This may let you drop the original bus configuration
Cheers, Sergey
Here's my spring.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<beans xmlns="http://www.springframework.org/schema/beans";
xmlns:beans="http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:osgi="http://www.springframework.org/schema/osgi";
xmlns:sec="http://cxf.apache.org/configuration/security";
xmlns:http="http://cxf.apache.org/transports/http/configuration";
xmlns:httpj="http://cxf.apache.org/transports/http-jetty/configuration";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/osgi
http://www.springframework.org/schema/osgi/spring-osgi.xsd
http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://cxf.apache.org/transports/http-jetty/configuration
http://cxf.apache.org/schemas/configuration/http-jetty.xsd";>
<!--<import resource="classpath:META-INF/cxf/cxf.xml"/>
<import resource="classpath:META-INF/cxf/cxf-extension-xml.xml"/>
<import resource="classpath:META-INF/cxf/cxf-servlet.xml"/>-->
<!-- Sanity check to make sure Spring DM is working. -->
<bean id="hello" class="org.apache.cxf.dosgi.samples.greeter.impl.rest.PrintHello"
init-method="init"/>
<bean id="cxf" class="org.apache.cxf.bus.spring.SpringBus"
destroy-method="shutdown"/>
<bean id="org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor"
class="org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor"/>
<bean id="org.apache.cxf.bus.spring.Jsr250BeanPostProcessor"
class="org.apache.cxf.bus.spring.Jsr250BeanPostProcessor"/>
<bean id="org.apache.cxf.bus.spring.BusExtensionPostProcessor"
class="org.apache.cxf.bus.spring.BusExtensionPostProcessor"/>
<httpj:engine-factory bus="cxf">
<httpj:engine port="9093">
<httpj:tlsServerParameters>
<sec:keyManagers keyPassword="skpass">
<sec:keyStore file="certs/serviceKeystore.jks" password="sspass" type="JKS"/>
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore file="certs/serviceKeystore.jks" password="sspass" type="JKS"/>
</sec:trustManagers>
<sec:cipherSuitesFilter>
<!-- these filters ensure that a ciphersuite with
export-suitable or null encryption is used,
but exclude anonymous Diffie-Hellman key change as
this is vulnerable to man-in-the-middle attacks -->
<sec:include>.*_EXPORT_.*</sec:include>
<sec:include>.*_EXPORT1024_.*</sec:include>
<sec:include>.*_WITH_DES_.*</sec:include>
<sec:include>.*_WITH_AES_.*</sec:include>
<sec:include>.*_WITH_NULL_.*</sec:include>
<sec:exclude>.*_DH_anon_.*</sec:exclude>
</sec:cipherSuitesFilter>
<sec:clientAuthentication want="false" required="false"/>
</httpj:tlsServerParameters>
</httpj:engine>
</httpj:engine-factory>
<!--<httpj:engine-factory bus="cxf">
<httpj:identifiedTLSServerParameters id="secure">
<httpj:tlsServerParameters>
<sec:keyManagers keyPassword="skpass">
<sec:keyStore type="JKS" password="sspass"
file="certs/serviceKeystore.jks"/>
</sec:keyManagers>
</httpj:tlsServerParameters>
</httpj:identifiedTLSServerParameters>
<httpj:engine port="9093">
<httpj:tlsServerParametersRef id="secure" />
<httpj:threadingParameters minThreads="5"
maxThreads="15" />
<httpj:connector>
<beans:bean class="org.eclipse.jetty.server.bio.SocketConnector">
<beans:property name="port" value="9093" />
</beans:bean>
</httpj:connector>
<httpj:handlers>
<beans:bean class="org.eclipse.jetty.server.handler.DefaultHandler"/>
</httpj:handlers>
<httpj:sessionSupport>true</httpj:sessionSupport>
</httpj:engine>
</httpj:engine-factory>-->
<osgi:service
interface="org.apache.cxf.dosgi.samples.greeter.rest.GreeterService">
<osgi:service-properties>
<entry key="service.exported.interfaces" value="*" />
<entry key="service.exported.configs" value="org.apache.cxf.rs" />
<entry key="service.exported.intents" value="HTTP" />
<entry key="org.apache.cxf.rs.address" value="https://localhost:9093/greeter"; />
</osgi:service-properties>
<bean class="org.apache.cxf.dosgi.samples.greeter.impl.rest.GreeterServiceImpl"
/>
</osgi:service>
</beans>
From: "Sergey Beryozkin-5 [via
CXF]"<ml-node+s547215n572141...@n5.nabble.com<mailto:ml-node+s547215n572141...@n5.nabble.com>>
Date: Thursday, January 10, 2013 9:29 AM
To: GE GE<am...@ge.com<mailto:am...@ge.com>>
Subject: Re: SSL with DOSGi
On 10/01/13 17:27, Sergey Beryozkin wrote:
Hi
On 10/01/13 17:07, geecxf wrote:
Hi Sergey,
Thanks for the prompt response. The more I read through the CXF DOSGi
code the more your revelation makes sense. It seems like the only
configuration file that affects cxf.dosgi.dsw is the cxf-dsw.cfg
through Felix FileInstall. However, I can't see any properties that
affects the default bus when using an absolute addresses.
So it looks like I would have to affect the BusFactory class which
seems to read some bus configuration from external sources. Which begs
the question:
Could I alter the default bus configuration to support https though a
META-INF/cxf/cxf.xml file in the manner described here
http://cxf.apache.org/docs/configuration.html? Then build a new
cxf-dosgi-ri-singlebundle-distribution that by default will create
HTTPS endpoints instead of HTTP when specifying absolute addresses?
Would this approach work?
I wonder if that will work even if you declare cxf:bus in your
application context, alongside http-jetty configuration and DOSGi will
pick up it, but I'm not sure; you may need to experiment, but I doubt
that rebuilding a single bundle distro would be the right approach,
ideally, there was some way to get DOSGi picking up the SSL-aware
default bus
My follow-up question is that if the approach described above works,
it is obviously a hack. Was there a vision for SSL support when using
absolute addresses? What would such a feature look like? Or is any
solution OK as long as it does not violate the DOSGi specification?
As far as I recall, no support for HTTPS was on the map at a time,
By the way, why using OSGI HTTP Service does meet the requirements ?
does *not* meet ?
Cheers, Sergey
Thanks,
D
From: "Sergey Beryozkin-5 [via
CXF]"<[hidden email]</user/SendEmail.jtp?type=node&node=5721416&i=0><mailto:[hidden
email]</user/SendEmail.jtp?type=node&node=5721416&i=1>>>
Date: Thursday, January 10, 2013 8:31 AM
To: GE GE<[hidden email]</user/SendEmail.jtp?type=node&node=5721416&i=2><mailto:[hidden
email]</user/SendEmail.jtp?type=node&node=5721416&i=3>>>
Subject: Re: SSL with DOSGi
Or rather, no one has looked yet into trying to get the bus aware of
such configuration found and selected somehow when absolute
org.apache.cxf.rs/ws.addresses are used :-)
--
View this message in context:
http://cxf.547215.n5.nabble.com/SSL-with-DOSGi-tp5721344p5721413.html
Sent from the cxf-user mailing list archive at Nabble.com.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://cxf.547215.n5.nabble.com/SSL-with-DOSGi-tp5721344p5721416.html
To unsubscribe from SSL with DOSGi, click
here<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5721344&code=YW1pcmlAZ2UuY29tfDU3MjEzNDR8LTE3ODgxMjU0NzM=>.
NAML<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
