You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Guillaume Nodet <gn...@gmail.com> on 2006/11/20 22:19:43 UTC
CXF and ServiceMix
I'm looking at CXF to enhance the soap support in ServiceMix and run
in several problems. First, let me state how I'd like to use CXF.
I'd like to reuse CXF to perform Soap processing (and WS-* stuff) on the
binding component side to send a JBI exchange which would conform to
the WSDL 1.1 / WSDL 2.0 abstract description of the service. For services
that use WSDL 1.1, there can be multiple parts in the message, so JBI
defines a wrapper to wrap these parts and soap headers that are part of
the message (this is not needed in WSDL 2.0).
On the binding side, I need to be able to override the SoapBindingFactory
with another implementation, because no marshaling phase should occur
at this point. Unfortunately, this is not easy because I'd like to reuse
some of the existing soap interceptors, and the existing SoapBindingFactory
is registered automatically and I found no way to override it without rewriting
the full bus configuration using spring.
Another point (and I guess this is a bug) is that I need an asynchronous
service invocation because the response will be send back by JBI at a later
time and being synchronous is unnecessary here. The problem is that the
current interceptor chain has been designed only around synchronous service
invocation. I said this is a bug, because the jaxws spec requires the
implementation
to be able to accept an Executor for service invocations, and given the code,
I doubt it will work if the default SimpleExecutor (which executes in
the same thread
in a blocking manner) is overriden.
The second step is to reuse CXF JAX-WS support in a soap agnostic way.
Writing a new binding may be the easiest way to go, maybe with an annotation
like @JBIBinding and all the needed stuff.
On the service side, I think we could write a SE which would support jax-ws
with a JBI binding which would unwrap the jbi wrapper and unmarshal the xml,
invoke the service and marshal the response back to xml.
What do you think of writing this new JBIBinding and allow the tooling to use
it. I'd like to be able to leverage the java2wsdl and wsdl2java to only support
the abstract wsdl definition for that (I don't think this is currently
possible, but I
haven't looked at it yet).
Thoughts ?
--
Cheers,
Guillaume Nodet
Re: JettyServerEngine patch
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
Sorry, please see the Jira issue :
http://issues.apache.org/jira/browse/CXF-278
Thanks, Sergey
> Hi Sergey,
>
> I think your attached patch had been removed by cxf-dev mail list. :(
> Could you please create JIRA task [1] and upload the patch to it.
>
> [1] http://issues.apache.org/jira/browse/CXF
>
> Cheers,
>
> Willem.
>
> Sergey Beryozkin wrote:
>
>> Hi
>>
>> I'd like to ask for the attached patch be applied. This patch ensures
>> that the configuration can be applied at the server engine level for a
>> given port, for example :
>>
>> <bean
>> name="org.apache.cxf.transport.http.JettyHTTPServerEngine.${http.port}"
>> abstract="true"/>
>>
>> org.apache.cxf.transport.http.JettyHTTPServerEngine is the bean name
>> of the engine, ${http.port} is the specific port. This is useful when
>> there're multiple types of providers listening on the same port and
>> one wants to apply, say, sslServer properties to all providers. This
>> functionality was available in Celtix, the bean name was different though.
>>
>> Test is also attached.
>>
>> Thanks, Sergey Beryozkin
>>
>>
>>
>>
>>
>
Re: JettyServerEngine patch
Posted by Willem Jiang <ni...@iona.com>.
Hi Sergey,
I think your attached patch had been removed by cxf-dev mail list. :(
Could you please create JIRA task [1] and upload the patch to it.
[1] http://issues.apache.org/jira/browse/CXF
Cheers,
Willem.
Sergey Beryozkin wrote:
> Hi
>
> I'd like to ask for the attached patch be applied. This patch ensures
> that the configuration can be applied at the server engine level for a
> given port, for example :
>
> <bean
> name="org.apache.cxf.transport.http.JettyHTTPServerEngine.${http.port}"
> abstract="true"/>
>
> org.apache.cxf.transport.http.JettyHTTPServerEngine is the bean name
> of the engine, ${http.port} is the specific port. This is useful when
> there're multiple types of providers listening on the same port and
> one wants to apply, say, sslServer properties to all providers. This
> functionality was available in Celtix, the bean name was different though.
>
> Test is also attached.
>
> Thanks, Sergey Beryozkin
>
>
>
>
>
Re: JettyServerEngine patch
Posted by Bozhong Lin <bl...@iona.com>.
Just a quick note, contributors are always encouraged to create JIRA
task and upload any patch to that JIRA task. This will not only track
your contributions for later committership vote purpose, but also a
requirement for legal purpose. (when you upload patch at JIRA system, it
will ask you to grant any contributions to Apache).
Regards,
Bo
Willem Jiang wrote:
> Hi Sergey,
>
> I think your attached patch had been removed by cxf-dev mail list. :(
> Could you please create JIRA task [1] and upload the patch to it.
>
> [1] http://issues.apache.org/jira/browse/CXF
>
> Cheers,
>
> Willem.
>
> Sergey Beryozkin wrote:
>
>> Hi
>>
>> I'd like to ask for the attached patch be applied. This patch ensures
>> that the configuration can be applied at the server engine level for
>> a given port, for example :
>>
>> <bean
>> name="org.apache.cxf.transport.http.JettyHTTPServerEngine.${http.port}"
>> abstract="true"/>
>>
>> org.apache.cxf.transport.http.JettyHTTPServerEngine is the bean name
>> of the engine, ${http.port} is the specific port. This is useful when
>> there're multiple types of providers listening on the same port and
>> one wants to apply, say, sslServer properties to all providers. This
>> functionality was available in Celtix, the bean name was different
>> though.
>>
>> Test is also attached.
>>
>> Thanks, Sergey Beryozkin
>>
>>
>>
>>
>>
>
Re: JettyServerEngine patch
Posted by Willem Jiang <ni...@iona.com>.
Hi Sergey,
I think your attached patch had been removed by cxf-dev mail list. :(
Could you please create JIRA task [1] and upload the patch to it.
[1] http://issues.apache.org/jira/browse/CXF
Cheers,
Willem.
Sergey Beryozkin wrote:
> Hi
>
> I'd like to ask for the attached patch be applied. This patch ensures
> that the configuration can be applied at the server engine level for a
> given port, for example :
>
> <bean
> name="org.apache.cxf.transport.http.JettyHTTPServerEngine.${http.port}"
> abstract="true"/>
>
> org.apache.cxf.transport.http.JettyHTTPServerEngine is the bean name
> of the engine, ${http.port} is the specific port. This is useful when
> there're multiple types of providers listening on the same port and
> one wants to apply, say, sslServer properties to all providers. This
> functionality was available in Celtix, the bean name was different though.
>
> Test is also attached.
>
> Thanks, Sergey Beryozkin
>
>
>
>
>
JettyServerEngine patch
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
I'd like to ask for the attached patch be applied. This patch ensures that the configuration can be applied at the server engine level for a given port, for example :
<bean name="org.apache.cxf.transport.http.JettyHTTPServerEngine.${http.port}" abstract="true"/>
org.apache.cxf.transport.http.JettyHTTPServerEngine is the bean name of the engine, ${http.port} is the specific port. This is useful when there're multiple types of providers listening on the same port and one wants to apply, say, sslServer properties to all providers. This functionality was available in Celtix, the bean name was different though.
Test is also attached.
Thanks, Sergey Beryozkin
SSL Server configuration
Posted by Sergey Beryozkin <se...@iona.com>.
Hi there
In our CXF-based server we want to configure SSL props and I'm trying to do it like this (this fragmnet is incomplete, 'sec' prefix
is declared earlier, xmlns:sec="http://cxf.apache.org/configuration/security") :
<bean id="ModelProviderPort.http-destination" class="org.apache.cxf.transport.http.destination.HTTPDestinationConfigBean">
<property name="sslServer">
<value>
<sec:sslServer>
<sec:Keystore>src/demo/hw_https/resources/celtix.p12</sec:Keystore>
<!-- more settings here -->
<sec:sslServer>
</bean>
And I get the error message (please see below). Now if I change the above bean setting to this one :
<bean id="ModelProviderPort.http-destination" abstract="true"> then the server starts ok, but it appears that the sslServer config
is not picked up as I can successfully access our server using plain http...
Any advice on how we can make the CXF notice that sslServer is in teh config will be appreciated...Should we use abstract="true" or
not ? Is it a matter of adding of updating our server's pom to bring some extra CXF jar dependency ? Can it be that due sslServer
settings are ignored with abstract="true" because at the moment these settings in our case are simply not correct yet, for ex, a
keystore location can not be resolved ?
Thanks, Sergey
WARNING: Failed to create application context.
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ModelProviderPort.http-destination' defined
in class path resource [cxf.xml]: Error setting property values; nested exception is
org.springframework.beans.PropertyBatchUpdateException; nested PropertyAccessExceptions (1) are:
PropertyAccessException 1: org.springframework.beans.TypeMismatchException: Failed to convert property value of type
[org.apache.xerces.dom.DeferredElementNSImpl] to required type [org.apache.cxf.configuration.security.SSLServerPolicy] for property
'sslServer'; nested exception is java.lang.IllegalArgumentException: No matching editors or conversion strategy found
Caused by: org.springframework.beans.PropertyBatchUpdateException; nested PropertyAccessException details (1) are:
PropertyAccessException 1:
org.springframework.beans.TypeMismatchException: Failed to convert property value of type
[org.apache.xerces.dom.DeferredElementNSImpl] to required type [org.apache.cxf.configuration.security.SSLServerPolicy] for property
'sslServer'; nested exception is java.lang.IllegalArgumentException: No matching editors or conversion strategy found
Caused by: java.lang.IllegalArgumentException: No matching editors or conversion strategy found
at org.springframework.beans.TypeConverterDelegate.convertIfNecessary(TypeConverterDelegate.java:212)
P.S. Is it really a user question so that we should send questions like this to a users group ?