Hi Dan,
There are some differences between CXF-922 and CXF-955.
1. The http-conduit bean object in CXF-922 just a object instance that
marshaled by JAXB, you still need use the ConfigureImpl which hold the
application context of the spring bean to set this object to the
httpConduit.
The key issue of CXF-922 is that we setup the configureImpl with the
application context after the bus is loaded and at the same time the
HttpConduit is created by the ClientProxyFactoryBean which uses the
default bus instead.
If we do not load the bus with the configuration file and set the
bus to the ClientProxyFactoryBean, we can't configure the http-conduit
as we wished.
2. In CXF-955, we create the JettyHTTPServerEngine , the
JettyHTTPServerEngineFactory directly in spring , and we just retrieve
the JettyHTTPServerEngineFactory when ServerFactoryBean create the server.
There is no ConfigureImpl as the mediation. In this case we just make
sure the JettyHTTPServerEngine and the JettyHTTPServerEngineFactory are
created before the ServerFactoryBean. So the spring's depend-on help us :).
I am just thinking about we could resolve the CXF-922 by the way that
CXF-955 did, that is to say we can take the dependency of the
ApplicationContext from the ConfigureImpl by creating the ConfigureImpl
in the spring context as the JettyHTTPServerEngineFactory did (but I
don't know how to pass the beans instances to it yet) .
Willem.
Daniel Kulp wrote:
Willem,
Are you sure? Looking at CXF-922, it looks VERY similar. They are
using the "bean" format, but most likely, the the non-bean format would
have the same issue. Could they add the depend-on thing to their bean
and have that work?
Dan
On Wednesday 05 September 2007, Willem Jiang wrote:
I just went through the patch, we still need to add the same support
for the jaxws:server and simple:server, I will work on it :)
Because it just work for the CXF server side, specially the Jetty
engine. I don't think it also relates to the client side.
Willem.
Daniel Kulp (JIRA) wrote:
[
https://issues.apache.org/jira/browse/CXF-955?page=com.atlassian.jir
a.plugin.system.issuetabpanels:comment-tabpanel#action_12525274 ]
Daniel Kulp commented on CXF-955:
---------------------------------
Fred: do you know if this also needs to be done for jaxws:server and
simple:server or the clients?
Implicit dependency from jaxws:endpoint on httpj:engine-factory is
not encoded in Spring
-------------------------------------------------------------------
---------------------
Key: CXF-955
URL: https://issues.apache.org/jira/browse/CXF-955
Project: CXF
Issue Type: Bug
Reporter: Fred Dushin
Attachments: cxf-955.patch
Suppose an application spring-loads a jaxws:endpoint, as in:
{{{
<jaxws:endpoint
id="HttpsEndpoint"
implementor="org.apache.cxf.systest.https.GreeterImpl"
address="https://localhost:9001/SoapContext/SoapPort";
serviceName="s:SOAPService"
endpointName="e:SoapPort"
xmlns:e="http://apache.org/hello_world";
xmlns:s="http://apache.org/hello_world"/>
}}}
(IMPORTANT: Note the https protocol)
And suppose further the application tries to define the TLS
parameters for servicing listing on the IP port 9001, as follows:
{{{
<httpj:engine-factory bus="cxf" id="foo">
<!-- -->
<!-- https://localhost:9001/... -->
<!-- -->
<httpj:engine port="9001">
<httpj:tlsServerParameters>
<sec:keyManagers keyPassword="password">
<sec:keyStore type="jks"
resource="keys/server.jks" password="password"/> </sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="jks"
resource="keys/truststore.jks"/> </sec:trustManagers>
<sec:clientAuthentication want="true"
required="true"/> </httpj:tlsServerParameters>
</httpj:engine>
}}}
What will happen is that jaxws:endpoint will get instantiated
before the httpj:engine-factory (at least on the JVM I am using).
This will cause the implicit endpoint.publish to fail, because at
the time the publish occurs, there are no TLS settings established
with the Bus for that physical port. The error you will typically
see is:
{{{
Caused by: java.io.IOException: Protocol mismatch: engine's
protocol is http, the url protocol is https }}}
We need to define an implicit (or explicit) Spring dependency
between these beans. A simple Spring "depends-on" would work, but
both elements are custom XML spring beans, so schema needs to be
modified, and the beans themselves need the DependsOn bean
attribute, at a minimum. Additional work may be needed to inform
Spring of the actual dependency, so that it Does the Right Thing
(r), and instantiates the httpj:engine-factory before the
jaxws:endpoint. I have a test case for this, which I will provide a
patch for shortly (if I can't figure out how to fix the issue).
