Hi
If the user still put the <http-conduit> bean in the same configuration
file with the <jaxws:client> we still can't walk around by specifying a
bus in the configuration file.
It is a kind of cycle dependency problem.
Willem.
Daniel Kulp wrote:
Willem,
I guess that's my point... Should his configuration for the ProxyFactory
have a :
<property name="bus" ref="cxf"/>
to get the bus and then also a "depend-on" or similar to make sure the
bus and conduit configs are all set properly first? I think just
adding the bus might do it. Either that, or a depend-on="cxf" type
thing to say it depends on the bus. That may allow the bus to be setup
first and set as the default bus before the proxy is created.
Dan
On Thursday 06 September 2007, Willem Jiang wrote:
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.j
ir 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).
