You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Daniel Kulp (JIRA)" <ji...@apache.org> on 2007/09/06 03:37:33 UTC
[jira] Commented: (CXF-955) Implicit dependency from jaxws:endpoint
on httpj:engine-factory is not encoded in Spring
[ https://issues.apache.org/jira/browse/CXF-955?page=com.atlassian.jira.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).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (CXF-955) Implicit dependency from jaxws:endpoint
on httpj:engine-factory is not encoded in Spring
Posted by Willem Jiang <ni...@iona.com>.
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).
>>>>
>
>
>
>
Hainan? (Was RE: [Review] Implement JSR-311 in CXF)
Posted by Glen Mazza <gl...@verizon.net>.
BTW, I think since Sun's JAX-RS representation is named after an island,
it might be a neat idea if CXF did the same.
Regards,
Glen
Am Freitag, den 07.09.2007, 03:13 -0400 schrieb Liu, Jervis:
> Hi Glen,
>
> Thanks for the input. We probably need to dig into CXF architectures and APIs deeper in order to understand what can be shared between “Web service CXF” and “REST CXF”. BTW I would use the phrase Web service CXF instead of SOAP CXF as CXF offered much more than just SOAP. Below are some initial thoughts on what CXF APIs can be reused by JAX-RS:
>
> 1.Reuse CXF front end APIs in JAX-RS: This looks good in my experimental implementation. Using following code snippet to start a service should appear familiar to any CXF users. Also it’s easy to integrate with Spring in this way.
>
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(BookStore.class);
> sf.setBindingId(JAXRSBindingFactory.JAXRS_BINDING_ID);
> sf.setAddress(" <http://localhost:9080/xml/> http://localhost:9080/xml/");
> sf.create();
>
> Whether or not JAXRSServerFactoryBean/JAXRSServiceFactoryBean are extended from some common CXF frontend base classes is a matter of implementation details.
>
> 2.Reuse CXF DataBinding API in JAX-RS: Ideally we would like to reuse CXF DataBindings in JAX-RS, such as JAXB, Aegis (as well as the XMLBean and JBIX that hopefully will come out soon). Take our JAXB data binding implementation as an example, we did extend Sun’s JAXB to some extent in order to handle some cases that JAXB can not handle properly, such as Array, List and hexBinary. Reusing JAXB data binding in JAX-RS definitely sounds a saving on both sides. However, I haven’t figured out how to do this yet. The CXF data binding is WSDL-centric, it depends on the schema info from the service model to do the marshal/unmarshal. We could though, in JAX-RS, build up schema info from resource classes, then feed schema info into data bindings. Internally in JAX-RS EntityProvider we can make calls to databinding to do the read/write.
>
> 3.Reuse CXF Binding: I don’t find any concepts in JSR-311 that are equivalent to CXF Binding. I would say we wont need Binding stuff in JAX-RS.
>
> Jervis
>
>
> > -----Original Message-----
> > From: Glen Mazza [ mailto:glen.mazza@verizon.net]
> > Sent: 2007年9月7日 12:55
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: [Review] Implement JSR-311 in CXF
> >
> >
> > The folks over at Sun have kept Jersey[1] separate from
> > Metro--they have
> > different codebases. This allows both Jersey and Metro to be tightly
> > fitting to the respective specifications they need to implement.
> >
> > Indeed, my past experience on Apache FOP is that the closer
> > you keep the
> > coding to the specification, the more developers you will
> > attract to the
> > project--always a good thing.
> >
> > So my feeling is that it would be good for REST CXF to be
> > coded from the
> > beginning, as if SOAP CXF did not exist, *but* for any commonality
> > between SOAP CXF and REST CXF to be factored out and shared
> > between the
> > two systems--perhaps in a commons project. Just my $0.02.
> >
> > Regards,
> > Glen
> >
> > [1] https://jersey.dev.java.net/source/browse/jersey/
> >
> >
> > Am Donnerstag, den 06.09.2007, 23:15 -0400 schrieb Liu, Jervis:
> > > Hi, I recently spent some time on implementing JSR-311 (JAX-RS: Java
> > > API for RESTful Web Services [1]) in CXF. The prototype code can be
> > > checked out from branch
> > >
> > https://svn.apache.org/repos/asf/incubator/cxf/branches/jliu. As this
> > > is still in a prototype phase, please don’t mind uncleared
> > warnings,
> > > funny hacked methods etc. Any comments or feedbacks will be highly
> > > appreciated.
> > >
> > > When I first started looking into the implementation, I
> > actually have
> > > three different design choices:
> > >
> > > The first approach is to implement JAX-RS in CXF similar to Jersey
> > > [2], using the JAX-WS Provider API as a proxy to direct request from
> > > CXF runtime to JAX-RS runtime. This might be the least intrusive
> > > approach as from the CXF runtime’s point of view, the
> > JAX-RS runtime
> > > is really just an application sitting on top of CXF. On the other
> > > hand, less intrusion means less control. Taking this approach, for
> > > example, the only information CXF runtime knows about the JAX-RS
> > > service is that it has a method exposed as invoke(T). This may gives
> > > us difficulties later on when we bring in management capabilities or
> > > introduce a service description language like WADL. Another
> > problem is
> > > a potential performance penalty. Depends on the specific JAX-WS
> > > implementation, there is always an extra time spent on transforming
> > > input stream to the T in the Provider.invoke(T).
> > >
> > > The second and the third approach are both implementing
> > JAX-RS in CXF
> > > core. What distinguished them from each other is whether or not to
> > > implement JAX-RS based on existing CXF API models. The CXF
> > API models
> > > I referred to are frontend APIs such as
> > > serviceFactoryBean/serverFactoryBean/Endpoint/EndpointInfo, Binding
> > > APIs, DataBinding APIs, Transport APIs and service model etc. As I
> > > mentioned early, the major problem with these CXF APIs is they are
> > > very WSDL-centric. To get around this, we can either
> > refactor CXF APIs
> > > so that at least the top abstract layer is suitable for both
> > > WSDL-based services and non-WSDL-based services. Or we can
> > start off a
> > > new set of APIs for non-WSDL-based services and built JAX-RS
> > > implementation on top of them. My prototype implementation
> > takes the
> > > former approach, can be briefed as below:
> > >
> > > 1. Refactored CXF APIs, so that AbstractServiceFactoryBean and
> > > AbstractEndpointFactory become the base classes that are neutral to
> > > both WSDL-based services and non-WSDL-based services. Also refactor
> > > Service interface so that it can represent both WSDL
> > service model and
> > > non-WSDL service model. The service model for JAX-RS is
> > pretty simple,
> > > it consists of resource classes and each resource class
> > consists of a
> > > set of resource methods.
> > >
> > > 2. JAXRSServiceFactoryBean extended from AbstractServiceFactoryBean,
> > > is responsible for the creation of service model, data binding etc.
> > >
> > > 3. JAXRSServerFactoryBean extended from AbstractEndpointFactory, is
> > > responsible for creating EndpointInfo, Endpoint, BindingFactory,
> > > ServerImpl etc.
> > >
> > > 4. Start a JAX-RS service would look very similar to Simple
> > or JAX-WS
> > > frontend:
> > >
> > > JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> > > sf.setResourceClasses(BookStore.class);
> > > sf.setBindingId(JAXRSBindingFactory.JAXRS_BINDING_ID);
> > > sf.setAddress(" http://localhost:9080/xml/");
> > >
> > > sf.create();
> > >
> > > I have created a simple bookstore sample, which is located under
> > > \systests\src\test\java\org\apache\cxf\systest\jaxrs. At the moment,
> > > the JAX-RS implementation does not support sub-resource
> > locators yet,
> > > thus this service can only serve services for the following URLs:
> > >
> > > http://localhost:9080/xml/bookstore return all books
> > > http://localhost:9080/xml/bookstore/123 return book 123
> > >
> > >
> > > [1]. JSR-311 Spec: https://jsr311.dev.java.net/
> > > [2]. Jersey: https://jersey.dev.java.net/
> > >
> > > Cheers,
> > > Jervis
> > >
> > >
> > >
> > >
> > > ----------------------------
> > > IONA Technologies PLC (registered in Ireland)
> > > Registered Number: 171387
> > > Registered Address: The IONA Building, Shelbourne Road,
> > Dublin 4, Ireland
> >
>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: [Review] Implement JSR-311 in CXF
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi Glen,
Thanks for the input. We probably need to dig into CXF architectures and APIs deeper in order to understand what can be shared between “Web service CXF” and “REST CXF”. BTW I would use the phrase Web service CXF instead of SOAP CXF as CXF offered much more than just SOAP. Below are some initial thoughts on what CXF APIs can be reused by JAX-RS:
1.Reuse CXF front end APIs in JAX-RS: This looks good in my experimental implementation. Using following code snippet to start a service should appear familiar to any CXF users. Also it’s easy to integrate with Spring in this way.
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setResourceClasses(BookStore.class);
sf.setBindingId(JAXRSBindingFactory.JAXRS_BINDING_ID);
sf.setAddress(" <http://localhost:9080/xml/> http://localhost:9080/xml/");
sf.create();
Whether or not JAXRSServerFactoryBean/JAXRSServiceFactoryBean are extended from some common CXF frontend base classes is a matter of implementation details.
2.Reuse CXF DataBinding API in JAX-RS: Ideally we would like to reuse CXF DataBindings in JAX-RS, such as JAXB, Aegis (as well as the XMLBean and JBIX that hopefully will come out soon). Take our JAXB data binding implementation as an example, we did extend Sun’s JAXB to some extent in order to handle some cases that JAXB can not handle properly, such as Array, List and hexBinary. Reusing JAXB data binding in JAX-RS definitely sounds a saving on both sides. However, I haven’t figured out how to do this yet. The CXF data binding is WSDL-centric, it depends on the schema info from the service model to do the marshal/unmarshal. We could though, in JAX-RS, build up schema info from resource classes, then feed schema info into data bindings. Internally in JAX-RS EntityProvider we can make calls to databinding to do the read/write.
3.Reuse CXF Binding: I don’t find any concepts in JSR-311 that are equivalent to CXF Binding. I would say we wont need Binding stuff in JAX-RS.
Jervis
> -----Original Message-----
> From: Glen Mazza [ mailto:glen.mazza@verizon.net]
> Sent: 2007年9月7日 12:55
> To: cxf-dev@incubator.apache.org
> Subject: Re: [Review] Implement JSR-311 in CXF
>
>
> The folks over at Sun have kept Jersey[1] separate from
> Metro--they have
> different codebases. This allows both Jersey and Metro to be tightly
> fitting to the respective specifications they need to implement.
>
> Indeed, my past experience on Apache FOP is that the closer
> you keep the
> coding to the specification, the more developers you will
> attract to the
> project--always a good thing.
>
> So my feeling is that it would be good for REST CXF to be
> coded from the
> beginning, as if SOAP CXF did not exist, *but* for any commonality
> between SOAP CXF and REST CXF to be factored out and shared
> between the
> two systems--perhaps in a commons project. Just my $0.02.
>
> Regards,
> Glen
>
> [1] https://jersey.dev.java.net/source/browse/jersey/
>
>
> Am Donnerstag, den 06.09.2007, 23:15 -0400 schrieb Liu, Jervis:
> > Hi, I recently spent some time on implementing JSR-311 (JAX-RS: Java
> > API for RESTful Web Services [1]) in CXF. The prototype code can be
> > checked out from branch
> >
> https://svn.apache.org/repos/asf/incubator/cxf/branches/jliu. As this
> > is still in a prototype phase, please don’t mind uncleared
> warnings,
> > funny hacked methods etc. Any comments or feedbacks will be highly
> > appreciated.
> >
> > When I first started looking into the implementation, I
> actually have
> > three different design choices:
> >
> > The first approach is to implement JAX-RS in CXF similar to Jersey
> > [2], using the JAX-WS Provider API as a proxy to direct request from
> > CXF runtime to JAX-RS runtime. This might be the least intrusive
> > approach as from the CXF runtime’s point of view, the
> JAX-RS runtime
> > is really just an application sitting on top of CXF. On the other
> > hand, less intrusion means less control. Taking this approach, for
> > example, the only information CXF runtime knows about the JAX-RS
> > service is that it has a method exposed as invoke(T). This may gives
> > us difficulties later on when we bring in management capabilities or
> > introduce a service description language like WADL. Another
> problem is
> > a potential performance penalty. Depends on the specific JAX-WS
> > implementation, there is always an extra time spent on transforming
> > input stream to the T in the Provider.invoke(T).
> >
> > The second and the third approach are both implementing
> JAX-RS in CXF
> > core. What distinguished them from each other is whether or not to
> > implement JAX-RS based on existing CXF API models. The CXF
> API models
> > I referred to are frontend APIs such as
> > serviceFactoryBean/serverFactoryBean/Endpoint/EndpointInfo, Binding
> > APIs, DataBinding APIs, Transport APIs and service model etc. As I
> > mentioned early, the major problem with these CXF APIs is they are
> > very WSDL-centric. To get around this, we can either
> refactor CXF APIs
> > so that at least the top abstract layer is suitable for both
> > WSDL-based services and non-WSDL-based services. Or we can
> start off a
> > new set of APIs for non-WSDL-based services and built JAX-RS
> > implementation on top of them. My prototype implementation
> takes the
> > former approach, can be briefed as below:
> >
> > 1. Refactored CXF APIs, so that AbstractServiceFactoryBean and
> > AbstractEndpointFactory become the base classes that are neutral to
> > both WSDL-based services and non-WSDL-based services. Also refactor
> > Service interface so that it can represent both WSDL
> service model and
> > non-WSDL service model. The service model for JAX-RS is
> pretty simple,
> > it consists of resource classes and each resource class
> consists of a
> > set of resource methods.
> >
> > 2. JAXRSServiceFactoryBean extended from AbstractServiceFactoryBean,
> > is responsible for the creation of service model, data binding etc.
> >
> > 3. JAXRSServerFactoryBean extended from AbstractEndpointFactory, is
> > responsible for creating EndpointInfo, Endpoint, BindingFactory,
> > ServerImpl etc.
> >
> > 4. Start a JAX-RS service would look very similar to Simple
> or JAX-WS
> > frontend:
> >
> > JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> > sf.setResourceClasses(BookStore.class);
> > sf.setBindingId(JAXRSBindingFactory.JAXRS_BINDING_ID);
> > sf.setAddress(" http://localhost:9080/xml/");
> >
> > sf.create();
> >
> > I have created a simple bookstore sample, which is located under
> > \systests\src\test\java\org\apache\cxf\systest\jaxrs. At the moment,
> > the JAX-RS implementation does not support sub-resource
> locators yet,
> > thus this service can only serve services for the following URLs:
> >
> > http://localhost:9080/xml/bookstore return all books
> > http://localhost:9080/xml/bookstore/123 return book 123
> >
> >
> > [1]. JSR-311 Spec: https://jsr311.dev.java.net/
> > [2]. Jersey: https://jersey.dev.java.net/
> >
> > Cheers,
> > Jervis
> >
> >
> >
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road,
> Dublin 4, Ireland
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [Review] Implement JSR-311 in CXF
Posted by Glen Mazza <gl...@verizon.net>.
The folks over at Sun have kept Jersey[1] separate from Metro--they have
different codebases. This allows both Jersey and Metro to be tightly
fitting to the respective specifications they need to implement.
Indeed, my past experience on Apache FOP is that the closer you keep the
coding to the specification, the more developers you will attract to the
project--always a good thing.
So my feeling is that it would be good for REST CXF to be coded from the
beginning, as if SOAP CXF did not exist, *but* for any commonality
between SOAP CXF and REST CXF to be factored out and shared between the
two systems--perhaps in a commons project. Just my $0.02.
Regards,
Glen
[1] https://jersey.dev.java.net/source/browse/jersey/
Am Donnerstag, den 06.09.2007, 23:15 -0400 schrieb Liu, Jervis:
> Hi, I recently spent some time on implementing JSR-311 (JAX-RS: Java
> API for RESTful Web Services [1]) in CXF. The prototype code can be
> checked out from branch
> https://svn.apache.org/repos/asf/incubator/cxf/branches/jliu. As this
> is still in a prototype phase, please don’t mind uncleared warnings,
> funny hacked methods etc. Any comments or feedbacks will be highly
> appreciated.
>
> When I first started looking into the implementation, I actually have
> three different design choices:
>
> The first approach is to implement JAX-RS in CXF similar to Jersey
> [2], using the JAX-WS Provider API as a proxy to direct request from
> CXF runtime to JAX-RS runtime. This might be the least intrusive
> approach as from the CXF runtime’s point of view, the JAX-RS runtime
> is really just an application sitting on top of CXF. On the other
> hand, less intrusion means less control. Taking this approach, for
> example, the only information CXF runtime knows about the JAX-RS
> service is that it has a method exposed as invoke(T). This may gives
> us difficulties later on when we bring in management capabilities or
> introduce a service description language like WADL. Another problem is
> a potential performance penalty. Depends on the specific JAX-WS
> implementation, there is always an extra time spent on transforming
> input stream to the T in the Provider.invoke(T).
>
> The second and the third approach are both implementing JAX-RS in CXF
> core. What distinguished them from each other is whether or not to
> implement JAX-RS based on existing CXF API models. The CXF API models
> I referred to are frontend APIs such as
> serviceFactoryBean/serverFactoryBean/Endpoint/EndpointInfo, Binding
> APIs, DataBinding APIs, Transport APIs and service model etc. As I
> mentioned early, the major problem with these CXF APIs is they are
> very WSDL-centric. To get around this, we can either refactor CXF APIs
> so that at least the top abstract layer is suitable for both
> WSDL-based services and non-WSDL-based services. Or we can start off a
> new set of APIs for non-WSDL-based services and built JAX-RS
> implementation on top of them. My prototype implementation takes the
> former approach, can be briefed as below:
>
> 1. Refactored CXF APIs, so that AbstractServiceFactoryBean and
> AbstractEndpointFactory become the base classes that are neutral to
> both WSDL-based services and non-WSDL-based services. Also refactor
> Service interface so that it can represent both WSDL service model and
> non-WSDL service model. The service model for JAX-RS is pretty simple,
> it consists of resource classes and each resource class consists of a
> set of resource methods.
>
> 2. JAXRSServiceFactoryBean extended from AbstractServiceFactoryBean,
> is responsible for the creation of service model, data binding etc.
>
> 3. JAXRSServerFactoryBean extended from AbstractEndpointFactory, is
> responsible for creating EndpointInfo, Endpoint, BindingFactory,
> ServerImpl etc.
>
> 4. Start a JAX-RS service would look very similar to Simple or JAX-WS
> frontend:
>
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(BookStore.class);
> sf.setBindingId(JAXRSBindingFactory.JAXRS_BINDING_ID);
> sf.setAddress("http://localhost:9080/xml/");
>
> sf.create();
>
> I have created a simple bookstore sample, which is located under
> \systests\src\test\java\org\apache\cxf\systest\jaxrs. At the moment,
> the JAX-RS implementation does not support sub-resource locators yet,
> thus this service can only serve services for the following URLs:
>
> http://localhost:9080/xml/bookstore return all books
> http://localhost:9080/xml/bookstore/123 return book 123
>
>
> [1]. JSR-311 Spec: https://jsr311.dev.java.net/
> [2]. Jersey: https://jersey.dev.java.net/
>
> Cheers,
> Jervis
>
>
>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
[Review] Implement JSR-311 in CXF
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi, I recently spent some time on implementing JSR-311 (JAX-RS: Java API for RESTful Web Services [1]) in CXF. The prototype code can be checked out from branch https://svn.apache.org/repos/asf/incubator/cxf/branches/jliu. As this is still in a prototype phase, please don’t mind uncleared warnings, funny hacked methods etc. Any comments or feedbacks will be highly appreciated.
When I first started looking into the implementation, I actually have three different design choices:
The first approach is to implement JAX-RS in CXF similar to Jersey [2], using the JAX-WS Provider API as a proxy to direct request from CXF runtime to JAX-RS runtime. This might be the least intrusive approach as from the CXF runtime’s point of view, the JAX-RS runtime is really just an application sitting on top of CXF. On the other hand, less intrusion means less control. Taking this approach, for example, the only information CXF runtime knows about the JAX-RS service is that it has a method exposed as invoke(T). This may gives us difficulties later on when we bring in management capabilities or introduce a service description language like WADL. Another problem is a potential performance penalty. Depends on the specific JAX-WS implementation, there is always an extra time spent on transforming input stream to the T in the Provider.invoke(T).
The second and the third approach are both implementing JAX-RS in CXF core. What distinguished them from each other is whether or not to implement JAX-RS based on existing CXF API models. The CXF API models I referred to are frontend APIs such as serviceFactoryBean/serverFactoryBean/Endpoint/EndpointInfo, Binding APIs, DataBinding APIs, Transport APIs and service model etc. As I mentioned early, the major problem with these CXF APIs is they are very WSDL-centric. To get around this, we can either refactor CXF APIs so that at least the top abstract layer is suitable for both WSDL-based services and non-WSDL-based services. Or we can start off a new set of APIs for non-WSDL-based services and built JAX-RS implementation on top of them. My prototype implementation takes the former approach, can be briefed as below:
1. Refactored CXF APIs, so that AbstractServiceFactoryBean and AbstractEndpointFactory become the base classes that are neutral to both WSDL-based services and non-WSDL-based services. Also refactor Service interface so that it can represent both WSDL service model and non-WSDL service model. The service model for JAX-RS is pretty simple, it consists of resource classes and each resource class consists of a set of resource methods.
2. JAXRSServiceFactoryBean extended from AbstractServiceFactoryBean, is responsible for the creation of service model, data binding etc.
3. JAXRSServerFactoryBean extended from AbstractEndpointFactory, is responsible for creating EndpointInfo, Endpoint, BindingFactory, ServerImpl etc.
4. Start a JAX-RS service would look very similar to Simple or JAX-WS frontend:
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setResourceClasses(BookStore.class);
sf.setBindingId(JAXRSBindingFactory.JAXRS_BINDING_ID);
sf.setAddress("http://localhost:9080/xml/");
sf.create();
I have created a simple bookstore sample, which is located under \systests\src\test\java\org\apache\cxf\systest\jaxrs. At the moment, the JAX-RS implementation does not support sub-resource locators yet, thus this service can only serve services for the following URLs:
http://localhost:9080/xml/bookstore return all books
http://localhost:9080/xml/bookstore/123 return book 123
[1]. JSR-311 Spec: https://jsr311.dev.java.net/
[2]. Jersey: https://jersey.dev.java.net/
Cheers,
Jervis
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [jira] Commented: (CXF-955) Implicit dependency from jaxws:endpoint
on httpj:engine-factory is not encoded in Spring
Posted by Willem Jiang <ni...@iona.com>.
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).
>>>>>>
>
>
>
>
Re: [jira] Commented: (CXF-955) Implicit dependency from jaxws:endpoint on httpj:engine-factory is not encoded in Spring
Posted by Daniel Kulp <dk...@apache.org>.
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).
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: [jira] Commented: (CXF-955) Implicit dependency from jaxws:endpoint
on httpj:engine-factory is not encoded in Spring
Posted by Willem Jiang <ni...@iona.com>.
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.jira.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).
>>
>
>