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 wrote: 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 supported by the JAX
Re: HTTP transport -- no exception on server side when client has reset TCP connection
2009/6/24 Daniel Kulp : > 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: > > > > > > > > > > > > > > > > > > > > > > > > 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]: > >> >> type="tns:JMSGreeterPortType"> >> transport="http://www.w3.org/2008/07/soap/bindings/JMS/"/> > >> > >> PERSISTENT > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ... > >> > >> > >> If I add the extension schema like this[2]: > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> But I can't get the extension in the wsdl. > >> If I change the wsdl like this[3]: > >> >> type="tns:JMSGreeterPortType"> >> transport="http://www.w3.org/2008/07/soap/bindings/JMS/"/> > >> > >> PERSISTENT >>Mod e> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ... > >> > >> > >> 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: HTTP transport -- no exception on server side when client has reset TCP connection
Unfortunately, circumstances conspire against me... Our network guys said it would take a couple of days to open another port to test this with Jetty, meanwhile the guy at the remote site who wrote the client is leaving today, which I only just found out. So I'll have to simulate it here in order to reproduce it. Possibly do-able with a debugger -- dig down to find the Socket object and call setLinger() and close() on it -- hard to say if it's a realistic reproduction though :-( Andrew. 2009/6/25 Andrew Clegg : > 2009/6/24 Daniel Kulp : > >> 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/ :: > -- :: http://biotext.org.uk/ ::
Re: Whiteboard pattern for JAX-RS services
Hi Josh
I'd like to ask your opinion about providing JAXRS providers through this
pattern.
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 ?
Oh, and sorry to hijack the thread, but I've been using the jax-rs frontend
for DOSGi and I'm very happy with it... thanks for all of your work in this
area. Job well done!
thanks a million for experimenting and providing the feedback
cheers, Sergey
Thanks,
Josh
Re: Whiteboard pattern for JAX-RS services
On Thu, Jun 25, 2009 at 8:46 AM, Sergey Beryozkin wrote:
> Hi Josh
>
>
> I'd like to ask your opinion about providing JAXRS providers through this
>>> pattern.
>>>
>>
>
>>
>>>
> 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.
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
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.
