Re: Integrating JAX-RS runtime into DOSGi
Hi Josh Sergey, Thanks again for the detailed documentation you've provided in this thread. I was able to easily convert from JAX-WS to JAX-RS, which (I think) will make our lives even easier. Once we've got the ability to expose a single service with both of these frontends, I'll make use of that as well. Thanks for experimenting with this initial effort. We'll add the ability to combine frontends soon, I was nearly ready to do it but I was not sure at a time how consuming bundles would indicate their preferences - perhaps should be some sort of intersection happening there. Likewise, it is not clear what to do when one of the frontends fails to start - is it a total failure or just a warning (plus removing a given failing frontend from the property to be published...) So we need to think what to do in such cases and then add the actual support. I agree that the jaxrs.resource property is no longer needed, as you can simply register jaxrs resources as a dosgi services. OK. 'jaxrs.resource' still appeals to me a bit so if we can see the opportunity for providing a portable JAX-RS publication feature not strictly bound to DOSGi then I'll be happy to add the support for it (while still using DOSGi under the hood)... thanks, Sergey Josh On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin sbery...@progress.comwrote: Hi, I've applied your patch and I've completed the initial integration of JAX-RS into DOSGi RI. As it often happens I underestimated a bit how long it would take me to do it :-) but I'm quite happy now with what has been done so far. I haven't got a chance to write JAX-WS system tests yet - I was a bit constrained in time but judging from the code you did JAXWS/databindings should be working nicely now - please feel free to add a system test, or either of us will do it asap. Now, the property names have actually changed and differ from those you provided in the patch. As David noted, it was recommended that DOSGI providers would use reverse domain names as prefixes to their custom configuration types, such as 'pojo' in case of DOSGI RI. Furthermore, 'pojo' was a bit constraining in that it did not reflect the fact that say SOAP or RS services were supported. Additionally, the DOSGI way is to associate additional properties qualifying a given config type with the config type property, for ex, if it's 'pojo' then it really should be 'pojo.frontend', etc. What David changed on the trunk was that he introduced new properties, while still maintaining the old ones for now. So, 'org.apache.cxf.ws' is equivalent to old 'pojo' soap-based services, while 'org.apache.cxf.rs' identifies a handler capable of exposing pojos as RESTful services. Now, frontends and databindings for SOAP services can be selected by the following properties : 'org.apache.cxf.ws.frontend' 'org.apache.cxf.ws.databinding'. For JAX-RS (org.apache.cxf.rs) services there's no need to configure frontends though databindings can be configured too. Address servlet context properties have also changed, with either org.apache.cxf.ws/rs replacing 'pojo'. Please check the DOSGi docs - David will also provide more feedback. It may be that global databinding and some other properties can still be introduced for them be shared between soap jaxrs services. Lets discuss it more and see what can be done. David has also updated the trunk so that multiple config types can be applied to a given service registration. There's a minor update still needs to be done (something like AggregatePojoConfigurationHandler needs to be added) but it's really nearly there. So for now please register your bean twice to make them work with JAXWS JAXRS, but it will be fixed soon. I think the new properties will also let us do pretty advanced combinations (like jaxb for soap but atom and aegis for jaxrs), etc. There's something else David is thinking of doing shortly, possibly next week or so. At the moment one has to configure DOSGI properties on the individual service basis, either from the code or from the xml. David is thinking of introducing wildcards such that for ex a given set of (dosgi) properties can apply to a potentially unlimited number of services - that will scale in terms of configuration dramatically. David is traveling but he will clarify as soon as he can. For now I did not add the support for a jaxrs.resource property Aaron and yourself talked about - this would be a non-standard property anyway and may be you can live for now with using the DOSGI props. You'll be abale to move all the dosgi properties away from your Activators once David finishes his work on supporting wildcards. Now, as far as the JAX-RS integration is concerned. It works both ways, on the client and on the server. Have a look please at samples/greeter_rest, it's basically identical to greeter demo, except that its GreeterService has JAX-RS annotations and it also introduces GreeterService2 interface which has no JAX-RS annotations but will be
Re: HTTP transport -- no exception on server side when client has reset TCP connection
2009/6/24 Daniel Kulp dk...@apache.org: Any chance you could try with Jetty? Maybe Jetty does something different. Sure, I'll need to install a few things on the server first -- I'll set it up today hopefully and let you know what happens. Andrew. -- :: http://biotext.org.uk/ ::
Re: How to add wsdl extension for SOAP/JMS.
On Thu June 25 2009 1:39:34 am liucong wrote: Hi, Dan, Thank you very much for your advice. By some experiments for the WSDL extension. I think it is right that this WSDL extension needs some changes to CXF wsdl processing. And the CXF wsdl processing will supoort the entension in SOAP/JMS. I think this kind of extension is necessary for CXF wsdl processing. The best place to look is in the cxf trunk/common/xjc/ts project. That project is an XJC plugin that adds toString methods to all the generated types. For MOST cases, you would need make the superclass be TExtensibilityElementImpl instead of Object. In other cases, it's a bit more complex: 1) For stuff that sublasses JAXBElement, you would need to make it implement ExtensibilityElement and add those methods and field. 2) For Enums - I think the stuff from (1) applies as well, not really sure though. Technically, it PROBABLY just needs to apply to root elements. (Stuff with @XmlRootElement annotations). Dan Are there any documents which help me finish this kind of extension? thank you! :-) Liu Daniel Kulp wrote: Hmm... I'm not really sure. I don't think there IS a schema that would work properly for this. My gut feeling was something like: xs:complexType name=deliveryModeType xs:simpleContent xs:restriction base=wsdl:tExtensibilityElement xs:enumeration value=PERSISTENT / xs:enumeration value=NON_PERSISTENT / /xs:restriction /xs:simpleContent /xs:complexType but I know that doesn't work. This will probably need some changes to CXF wsdl processing to really get this to work well. Actually, this could provide a good opportunity to cleanup the JAXB WSDL extension mechanism to NOT require that the schema extends the wsdl:tExtensibilityElement type. I'm actually thinking a xjc plugin that would make all the generated types automatically implement the wsdl4j ExtensibiltyElement interface and add the methods/fields for that. That can significantly cleanup the CXF schemas for all the extensors. It would be completely automatic. Dan On Tue June 23 2009 11:51:43 am liucong wrote: Hi, I want to add wsdl extension for SOAP/JMS according to http://www.w3.org/TR/2008/WD-soapjms-20081121/#wsdl-extensions. For example, I want add wsdl extension for DeliveryMode property. I edit the wsdl file like[1]: wsdl:binding name=JMSGreeterPortBinding type=tns:JMSGreeterPortType soap:binding style=document transport=http://www.w3.org/2008/07/soap/bindings/JMS// soapjms:deliveryModePERSISTENT/soapjms:deliveryMode wsdl:operation name=greetMe soap:operation soapAction=test style=document/ wsdl:input name=greetMeRequest soap:body use=literal/ /wsdl:input wsdl:output name=greetMeResponse soap:body use=literal/ /wsdl:output /wsdl:operation ... /wsdl:binding If I add the extension schema like this[2]: xs:element name=deliveryMode type=soapjms:deliveryModeType / xs:complexType name=deliveryModeType xs:complexContent xs:extension base=wsdl:tExtensibilityElement xs:sequence xs:element name=deliveryMode xs:simpleType xs:restriction base=xs:string xs:enumeration value=PERSISTENT / xs:enumeration value=NON_PERSISTENT / /xs:restriction /xs:simpleType /xs:element /xs:sequence /xs:extension /xs:complexContent /xs:complexType But I can't get the extension in the wsdl. If I change the wsdl like this[3]: wsdl:binding name=JMSGreeterPortBinding type=tns:JMSGreeterPortType soap:binding style=document transport=http://www.w3.org/2008/07/soap/bindings/JMS// soapjms:deliveryModesoapjms:deliveryModePERSISTENT/soapjms:delivery Mod e/soapjms:deliveryMode wsdl:operation name=greetMe soap:operation soapAction=test style=document/ wsdl:input name=greetMeRequest soap:body use=literal/ /wsdl:input wsdl:output name=greetMeResponse soap:body use=literal/ /wsdl:output /wsdl:operation ... /wsdl:binding I'll get the result of deliveryMode extension. I think the wsdl extension just can add attributes, element to a extension element in CXF. But I can't get the extension element's value. Is it right? My question is: how to get the extension information in [1]. What does the extension schema look like? thanks. Liu -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Whiteboard pattern for JAX-RS services
On Thu, Jun 25, 2009 at 8:46 AM, Sergey Beryozkin sbery...@progress.comwrote:
Hi Josh
I'd like to ask your opinion about providing JAXRS providers through this
pattern.
snip/
I'm not sure how CXF keeps track of these providers now, but I assume
there's a registry of some kind. Are the providers tied to specific
jax-rs
resources, or are they global? If it's a global registry, it should be
trivial to add a service tracker that watches for new services that are
registered with the osgi container under the MessageBodyReader,
MessageBodyWriter, or ExceptionMapper interfaces. The service tracker
would
add or remove the providers from the internal CXF provider registry.
That's
what I did with the resteasy spi, but I am not as familiar with how CXF
keeps track of providers.
CXF JAX-RS has a global registry which provides providers supporting
formats/features as requested by the spec (for ex JAXB support, etc). These
providers are shared. In addition, every endpoint gets the opportunity to
register per-endpoint unique providers. Some endpoints may or may not share
the same instances but it's up to the app developer. So say the same JAXB
provider may be configured to suit a particular endpoint's needs
Thus, given that the endpoint or client is created by DOSGI, I was thinking
about the user bundles providing a list of additional providers using a
service property :
Dictionary props = ...
props.put(org.apache.cxf.rs.providers, new Object[]{provider1,
provider2});
and then publish or attempt to bind...
and DOSGI will use them at the point of creating the endpoint/client
I'm wondering, would this approach work for you ?
Yes, partially. Since there are multiple scopes, I think there should be
multiple mechanisms for registering providers. A developer should be able
to register a global provider by simply publishing it as an OSGi service,
and should be able to register per-endpoint providers in the manner you
describe above.
If global provider registration is not a priority for others, I'd be happy
to work on a patch. Just let me know when things settle down in this area,
so we don't wind up with a difficult-to-merge patch :)
Thanks,
Josh
Re: Whiteboard pattern for JAX-RS services
Hi
Please see my comments with prefixed with S.B.
I'm not sure how CXF keeps track of these providers now, but I assume
there's a registry of some kind. Are the providers tied to specific
jax-rs
resources, or are they global? If it's a global registry, it should be
trivial to add a service tracker that watches for new services that are
registered with the osgi container under the MessageBodyReader,
MessageBodyWriter, or ExceptionMapper interfaces. The service tracker
would
add or remove the providers from the internal CXF provider registry.
That's
what I did with the resteasy spi, but I am not as familiar with how CXF
keeps track of providers.
CXF JAX-RS has a global registry which provides providers supporting
formats/features as requested by the spec (for ex JAXB support, etc).
These
providers are shared. In addition, every endpoint gets the opportunity to
register per-endpoint unique providers. Some endpoints may or may not
share
the same instances but it's up to the app developer. So say the same JAXB
provider may be configured to suit a particular endpoint's needs
Thus, given that the endpoint or client is created by DOSGI, I was
thinking
about the user bundles providing a list of additional providers using a
service property :
Dictionary props = ...
props.put(org.apache.cxf.rs.providers, new Object[]{provider1,
provider2});
and then publish or attempt to bind...
and DOSGI will use them at the point of creating the endpoint/client
I'm wondering, would this approach work for you ?
Yes, partially. Since there are multiple scopes, I think there should be
multiple mechanisms for registering providers. A developer should be able
to register a global provider by simply publishing it as an OSGi service,
and should be able to register per-endpoint providers in the manner you
describe above.
S.B Yeah, registering a global provider this way sounds like a good idea.
Not sure yet how to handle it
in DOSGi. According to the spec, custom providers should be chosen instead
of any matching default providers, for ex, if one registers a provider
capable of handling WebApplicationExceptions then it should be chosen
instead of the default one. If we add such 'overlapping' providers to the
global registry then it could be tricky to meet the specs requirements.
May be in CXF JAX-RS we need to introduce another ProviderFactory instance
for keeping the shared custom handlers. So first the endpoint-specific
providers will be checked, next shared custom providers will be checked and
finally the default ones will be checked. This new ProviderFactory instance
is kind of redundant in most other cases as without OSGI users can easily
inject the same instance into endpoint-specific factories, but in OSGi it
can be handy.
Perhaps for a start, a ServiceTracker launched in DOSGI can keep this shared
custom providers state locally and provide it to individual JAX-RS config
handlers.
Endpoint specific providers would be much simpler to deal with, they'll just
have to be passed to the endpoint factory code, but a providers property
will likely need to be excluded from the service properties available for
the publication
/S.B
If global provider registration is not a priority for others, I'd be happy
to work on a patch. Just let me know when things settle down in this area,
so we don't wind up with a difficult-to-merge patch :)
S.B : Patch would be welcome :-) Give it a try please whenever you get a
chance/some time. We will fix the merge issues if any...Thanks
Thanks,
Josh
--
View this message in context:
http://www.nabble.com/Whiteboard-pattern-for-JAX-RS-services-tp23999480p24207585.html
Sent from the cxf-dev mailing list archive at Nabble.com.
