RE: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Hi

I've implemented just now on the trunk. I have the unit test only
assuming that the calling BundleContext will be used to load the classes
- can you please verify it?

I'm not sure when exactly the Hudson build at
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi/   

Will start and finish, hopefully soon enough, tomorrow will be ready for
sure.

Alternatively please rebuild dsw/cxf-dsw and then the distribution
(single or multi) that you use...

thanks, Sergey

-Original Message-
From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
Josh Holtzman
Sent: 31 August 2009 10:38
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi

I'm using declarative services to register my endpoints, so it would be
useful for me to specify the provider property using class names rather
than
instances in the service properties.  Perhaps something like this?

  property name=org.apache.cxf.rs.provider
org.whatever.FooXmlReaderWriter,
org.whatever.SomeOtherReaderOrWriter
  /property

Or is there some way to reference an object instance in DS that I'm
unaware
of?

Thanks,
Josh

On Wed, Aug 26, 2009 at 6:45 PM, Sergey Beryozkin
sbery...@progress.comwrote:

 Oh, this is exactly the sort of message I was in need for in the end
of the
 long and difficult day :-)
 Cool. If you could verify (later on today or next week when you're
back)
 that you could do

 Dictionary props = new Hashtable();
 props.put(org.apache.cxf.rs.provider, new Object[]{new
 FooReaderWriter()});
 bundleContext.registerService(YourApplicationService.class.getName,
new
 YourApplicationServiceImpl(), properties);

 This option will allow users to register per-service tuned
 FooReaderWriters, something one can do today with registering
different
 FooReaderWriter instances on a per-endpoint basis with jaxrs:endpoints

 then it would be of help.

 thanks for your help

 Sergey

 - Original Message - From: Josh Holtzman
jholtz...@berkeley.edu
 
 To: dev@cxf.apache.org
 Sent: Wednesday, August 26, 2009 5:37 PM

 Subject: Re: Integrating JAX-RS runtime into DOSGi


  Bah, my isReadable and isWriteable were wrong.  Sorry, false alarm.
This
 works like a charm!

 Thanks,
 Josh

 On Wed, Aug 26, 2009 at 6:16 PM, Sergey Beryozkin
sbery...@progress.com
 wrote:

  Hi Josh

 Thanks, this is exactly how providers are expected to be registered.
 http://hudson.zones.apache.org/hudson/job/CXF-DOSGi

 shows my changes have been picked up so it's a bug then. Have you
tries
 the
 lastest build from snapshots or built the trunk yourself, including
a
 trunk/distributuon ?

 I'll look into it...

 cheers, Sergey

 P.S. was about to ping you on #cxf but somehow I lost the connection
 - Original Message - From: Josh Holtzman 
 jholtz...@berkeley.edu
 
 To: dev@cxf.apache.org
 Sent: Wednesday, August 26, 2009 5:02 PM
 Subject: Re: Integrating JAX-RS runtime into DOSGi



  Great, thanks Sergey.  I just tried this, and wasn't able to
read/write
 an

 arbitrary object.

 I've registered a MessageBodyReader and a MessageBodyWriter
(actually,
 the
 same object) like so:

  FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
  context.registerService(MessageBodyReader.class.getName(),
 fooReaderWriter, null);
  context.registerService(MessageBodyWriter.class.getName(),
 fooReaderWriter, null);

 I see that these services are in fact registered:

 ---
 objectClass = javax.ws.rs.ext.MessageBodyReader
 service.id = 41
 
 objectClass = javax.ws.rs.ext.MessageBodyWriter
 service.id = 42
 

 But when I try to access a Foo via JAX-RS, I get this:

 [9853...@qtp-998044-0 - /inspection/rest/foo] WARN
 org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message
body
 writer found for response class : Foo.

 Please let me know if I misunderstood the recipe for registering
JAX-RS
 providers.  I'll be out of the office until Monday, and will start
 digging
 into the CXF code to see what's going on when I return.

 Many thanks,
 Josh


 On Tue, Aug 25, 2009 at 7:21 PM, Sergey Beryozkin 
 sergey.beryoz...@iona.com

  wrote:



  Hi Josh

 I've updated the JAX-RS layer in DOSGi such that it will now
discover
 JAXRS
 (and CXF specific providers) which have been registered as
(global)
 OSGI
 services. At the moment I've decided not to use a ServiceTracker
and
 instead
 a calling BundleContext is asked to exercise a filter expression
which
 should catch JAXRS MessageBodyReader, MessageBodyWriter,
 ExceptionMapper,
 as
 well as CXF RequestHandler, ResponseHandler  ParameterHandler.
I'll
 attempt
 to optimize it later on

 One can disable such queries for such providers and also insist
that
 only
 those global providers which have identified themselves (through a
 specific
 property) that they will work reliably with CXF can be used.

 Alternatively, one can register an array of service/endpoint
-specific
 providers by using org.apache.cxf.rs.provider property, when

RE: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Missed 'would result in the array value being passed'...

-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com] 
Sent: 31 August 2009 13:10
To: dev@cxf.apache.org
Subject: RE: Integrating JAX-RS runtime into DOSGi

Ok, I didn't know  

property name=org.apache.cxf.rs.provider
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
/property


I'll look more into it...

Thanks, Sergey
 
-Original Message-
From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
Josh Holtzman
Sent: 31 August 2009 13:04
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi

This works when specifying a single property, but not as an array.  In
other
words, this is fine:

  property name=org.apache.cxf.rs.provider
value=org.whatever.MyJaxRsReaderWriter /

but this does not work:

  property name=org.apache.cxf.rs.provider
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
  /property

I seem to recall a general CXF issue with array properties in DS, so
this
may be completely unrelated to the JAX-RS stuff.

Thanks,
Josh


On Mon, Aug 31, 2009 at 1:35 PM, Sergey Beryozkin
sbery...@progress.comwrote:

 Hi

 I've implemented just now on the trunk. I have the unit test only
 assuming that the calling BundleContext will be used to load the
classes
 - can you please verify it?

 I'm not sure when exactly the Hudson build at
 http://hudson.zones.apache.org/hudson/job/CXF-DOSGi/

 Will start and finish, hopefully soon enough, tomorrow will be ready
for
 sure.

 Alternatively please rebuild dsw/cxf-dsw and then the distribution
 (single or multi) that you use...

 thanks, Sergey

 -Original Message-
 From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
 Josh Holtzman
 Sent: 31 August 2009 10:38
 To: dev@cxf.apache.org
 Subject: Re: Integrating JAX-RS runtime into DOSGi

 I'm using declarative services to register my endpoints, so it would
be
 useful for me to specify the provider property using class names
rather
 than
 instances in the service properties.  Perhaps something like this?

  property name=org.apache.cxf.rs.provider
org.whatever.FooXmlReaderWriter,
org.whatever.SomeOtherReaderOrWriter
  /property

 Or is there some way to reference an object instance in DS that I'm
 unaware
 of?

 Thanks,
 Josh

 On Wed, Aug 26, 2009 at 6:45 PM, Sergey Beryozkin
 sbery...@progress.comwrote:

  Oh, this is exactly the sort of message I was in need for in the end
 of the
  long and difficult day :-)
  Cool. If you could verify (later on today or next week when you're
 back)
  that you could do
 
  Dictionary props = new Hashtable();
  props.put(org.apache.cxf.rs.provider, new Object[]{new
  FooReaderWriter()});
  bundleContext.registerService(YourApplicationService.class.getName,
 new
  YourApplicationServiceImpl(), properties);
 
  This option will allow users to register per-service tuned
  FooReaderWriters, something one can do today with registering
 different
  FooReaderWriter instances on a per-endpoint basis with
jaxrs:endpoints
 
  then it would be of help.
 
  thanks for your help
 
  Sergey
 
  - Original Message - From: Josh Holtzman
 jholtz...@berkeley.edu
  
  To: dev@cxf.apache.org
  Sent: Wednesday, August 26, 2009 5:37 PM
 
  Subject: Re: Integrating JAX-RS runtime into DOSGi
 
 
   Bah, my isReadable and isWriteable were wrong.  Sorry, false alarm.
 This
  works like a charm!
 
  Thanks,
  Josh
 
  On Wed, Aug 26, 2009 at 6:16 PM, Sergey Beryozkin
 sbery...@progress.com
  wrote:
 
   Hi Josh
 
  Thanks, this is exactly how providers are expected to be
registered.
  http://hudson.zones.apache.org/hudson/job/CXF-DOSGi
 
  shows my changes have been picked up so it's a bug then. Have you
 tries
  the
  lastest build from snapshots or built the trunk yourself,
including
 a
  trunk/distributuon ?
 
  I'll look into it...
 
  cheers, Sergey
 
  P.S. was about to ping you on #cxf but somehow I lost the
connection
  - Original Message - From: Josh Holtzman 
  jholtz...@berkeley.edu
  
  To: dev@cxf.apache.org
  Sent: Wednesday, August 26, 2009 5:02 PM
  Subject: Re: Integrating JAX-RS runtime into DOSGi
 
 
 
   Great, thanks Sergey.  I just tried this, and wasn't able to
 read/write
  an
 
  arbitrary object.
 
  I've registered a MessageBodyReader and a MessageBodyWriter
 (actually,
  the
  same object) like so:
 
   FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
   context.registerService(MessageBodyReader.class.getName(),
  fooReaderWriter, null);
   context.registerService(MessageBodyWriter.class.getName(),
  fooReaderWriter, null);
 
  I see that these services are in fact registered:
 
  ---
  objectClass = javax.ws.rs.ext.MessageBodyReader
  service.id = 41
  
  objectClass = javax.ws.rs.ext.MessageBodyWriter
  service.id = 42
  
 
  But when I try to access a Foo via JAX-RS, I get

RE: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Hi Josh

This should be fixed now. I've confirmed it by running the
locally-modified greeter_rest demo on Eclipse Equinox with its DS
service implementation... Unit test has also been there. Now, Equinox DS
passes a Spring[] so at the moment I'm assuming that it has to be String
array, as opposed to Object[].
Given that DS is likely implemented by Equinox only it should work just
fine.

Can you confirm it's working for you (after the build has been done) ?

So we have 3 options now for registering providers :
- registering providers as OSGI services
- providing an array of provider instances as an application service
property
- using declarative services

I'm not sure it is worth investigating the option of class-scanning the
application bundle - it would be more expensive. But may be I will later
on...

Thanks, Sergey 



-Original Message-
From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
Josh Holtzman
Sent: 31 August 2009 13:04
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi

This works when specifying a single property, but not as an array.  In
other
words, this is fine:

  property name=org.apache.cxf.rs.provider
value=org.whatever.MyJaxRsReaderWriter /

but this does not work:

  property name=org.apache.cxf.rs.provider
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
  /property

I seem to recall a general CXF issue with array properties in DS, so
this
may be completely unrelated to the JAX-RS stuff.

Thanks,
Josh


On Mon, Aug 31, 2009 at 1:35 PM, Sergey Beryozkin
sbery...@progress.comwrote:

 Hi

 I've implemented just now on the trunk. I have the unit test only
 assuming that the calling BundleContext will be used to load the
classes
 - can you please verify it?

 I'm not sure when exactly the Hudson build at
 http://hudson.zones.apache.org/hudson/job/CXF-DOSGi/

 Will start and finish, hopefully soon enough, tomorrow will be ready
for
 sure.

 Alternatively please rebuild dsw/cxf-dsw and then the distribution
 (single or multi) that you use...

 thanks, Sergey

 -Original Message-
 From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
 Josh Holtzman
 Sent: 31 August 2009 10:38
 To: dev@cxf.apache.org
 Subject: Re: Integrating JAX-RS runtime into DOSGi

 I'm using declarative services to register my endpoints, so it would
be
 useful for me to specify the provider property using class names
rather
 than
 instances in the service properties.  Perhaps something like this?

  property name=org.apache.cxf.rs.provider
org.whatever.FooXmlReaderWriter,
org.whatever.SomeOtherReaderOrWriter
  /property

 Or is there some way to reference an object instance in DS that I'm
 unaware
 of?

 Thanks,
 Josh

 On Wed, Aug 26, 2009 at 6:45 PM, Sergey Beryozkin
 sbery...@progress.comwrote:

  Oh, this is exactly the sort of message I was in need for in the end
 of the
  long and difficult day :-)
  Cool. If you could verify (later on today or next week when you're
 back)
  that you could do
 
  Dictionary props = new Hashtable();
  props.put(org.apache.cxf.rs.provider, new Object[]{new
  FooReaderWriter()});
  bundleContext.registerService(YourApplicationService.class.getName,
 new
  YourApplicationServiceImpl(), properties);
 
  This option will allow users to register per-service tuned
  FooReaderWriters, something one can do today with registering
 different
  FooReaderWriter instances on a per-endpoint basis with
jaxrs:endpoints
 
  then it would be of help.
 
  thanks for your help
 
  Sergey
 
  - Original Message - From: Josh Holtzman
 jholtz...@berkeley.edu
  
  To: dev@cxf.apache.org
  Sent: Wednesday, August 26, 2009 5:37 PM
 
  Subject: Re: Integrating JAX-RS runtime into DOSGi
 
 
   Bah, my isReadable and isWriteable were wrong.  Sorry, false alarm.
 This
  works like a charm!
 
  Thanks,
  Josh
 
  On Wed, Aug 26, 2009 at 6:16 PM, Sergey Beryozkin
 sbery...@progress.com
  wrote:
 
   Hi Josh
 
  Thanks, this is exactly how providers are expected to be
registered.
  http://hudson.zones.apache.org/hudson/job/CXF-DOSGi
 
  shows my changes have been picked up so it's a bug then. Have you
 tries
  the
  lastest build from snapshots or built the trunk yourself,
including
 a
  trunk/distributuon ?
 
  I'll look into it...
 
  cheers, Sergey
 
  P.S. was about to ping you on #cxf but somehow I lost the
connection
  - Original Message - From: Josh Holtzman 
  jholtz...@berkeley.edu
  
  To: dev@cxf.apache.org
  Sent: Wednesday, August 26, 2009 5:02 PM
  Subject: Re: Integrating JAX-RS runtime into DOSGi
 
 
 
   Great, thanks Sergey.  I just tried this, and wasn't able to
 read/write
  an
 
  arbitrary object.
 
  I've registered a MessageBodyReader and a MessageBodyWriter
 (actually,
  the
  same object) like so:
 
   FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
   context.registerService(MessageBodyReader.class.getName(),
  fooReaderWriter, null

Re: Integrating JAX-RS runtime into DOSGi

[Josh Holtzman]

Great, thanks Sergey.  I just tried this, and wasn't able to read/write an
arbitrary object.

I've registered a MessageBodyReader and a MessageBodyWriter (actually, the
same object) like so:

FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
context.registerService(MessageBodyReader.class.getName(),
fooReaderWriter, null);
context.registerService(MessageBodyWriter.class.getName(),
fooReaderWriter, null);

I see that these services are in fact registered:

---
objectClass = javax.ws.rs.ext.MessageBodyReader
service.id = 41

objectClass = javax.ws.rs.ext.MessageBodyWriter
service.id = 42


But when I try to access a Foo via JAX-RS, I get this:

[9853...@qtp-998044-0 - /inspection/rest/foo] WARN
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body
writer found for response class : Foo.

Please let me know if I misunderstood the recipe for registering JAX-RS
providers.  I'll be out of the office until Monday, and will start digging
into the CXF code to see what's going on when I return.

Many thanks,
Josh


On Tue, Aug 25, 2009 at 7:21 PM, Sergey Beryozkin sergey.beryoz...@iona.com
 wrote:


 Hi Josh

 I've updated the JAX-RS layer in DOSGi such that it will now discover JAXRS
 (and CXF specific providers) which have been registered as (global) OSGI
 services. At the moment I've decided not to use a ServiceTracker and
 instead
 a calling BundleContext is asked to exercise a filter expression which
 should catch JAXRS MessageBodyReader, MessageBodyWriter, ExceptionMapper,
 as
 well as CXF RequestHandler, ResponseHandler  ParameterHandler. I'll
 attempt
 to optimize it later on

 One can disable such queries for such providers and also insist that only
 those global providers which have identified themselves (through a specific
 property) that they will work reliably with CXF can be used.

 Alternatively, one can register an array of service/endpoint -specific
 providers by using org.apache.cxf.rs.provider property, when registering
 an application service.
 Will document it tomorrow

 Give it a try please whenever you get a chance and let me know if it works
 for you

 cheers, Sergey



 Josh Holtzman wrote:
 
  Hi Sergey. Yes, we are using JAXB with both JAX-RS and JAX-WS endpoints.
 
  Josh
 
  On Aug 21, 2009 6:28 PM, Sergey Beryozkin sbery...@progress.com
 wrote:
 
  Hi Josh
 
  Can you please let me know if JAXB is being used for your JAX-RS
 endpoints
  ?
  I've spotted that for HTTP Service based JAX-RS endpoints no
 AegisProvider
  is being set - I'would actually like JAXB being used by default for JAXRS
  endpoints which will be consistent with the expectations of JAX-RS users
  in
  general - but I'd like to confirm first that JAXB is working ok in your
  case...
 
  thanks, Sergey
 
  Sergey,  Thanks again for the detailed documentation you've provided in
  this thread.  I was ab...
 
 

 --
 View this message in context:
 http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp24127832p25138636.html
 Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Hi Josh

Thanks, this is exactly how providers are expected to be registered.
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi

shows my changes have been picked up so it's a bug then. Have you tries the lastest build from snapshots or built the trunk 
yourself, including a trunk/distributuon ?


I'll look into it...

cheers, Sergey

P.S. was about to ping you on #cxf but somehow I lost the connection
- Original Message - 
From: Josh Holtzman jholtz...@berkeley.edu

To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:02 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi



Great, thanks Sergey.  I just tried this, and wasn't able to read/write an
arbitrary object.

I've registered a MessageBodyReader and a MessageBodyWriter (actually, the
same object) like so:

   FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
   context.registerService(MessageBodyReader.class.getName(),
fooReaderWriter, null);
   context.registerService(MessageBodyWriter.class.getName(),
fooReaderWriter, null);

I see that these services are in fact registered:

---
objectClass = javax.ws.rs.ext.MessageBodyReader
service.id = 41

objectClass = javax.ws.rs.ext.MessageBodyWriter
service.id = 42


But when I try to access a Foo via JAX-RS, I get this:

[9853...@qtp-998044-0 - /inspection/rest/foo] WARN
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body
writer found for response class : Foo.

Please let me know if I misunderstood the recipe for registering JAX-RS
providers.  I'll be out of the office until Monday, and will start digging
into the CXF code to see what's going on when I return.

Many thanks,
Josh


On Tue, Aug 25, 2009 at 7:21 PM, Sergey Beryozkin sergey.beryoz...@iona.com

wrote:




Hi Josh

I've updated the JAX-RS layer in DOSGi such that it will now discover JAXRS
(and CXF specific providers) which have been registered as (global) OSGI
services. At the moment I've decided not to use a ServiceTracker and
instead
a calling BundleContext is asked to exercise a filter expression which
should catch JAXRS MessageBodyReader, MessageBodyWriter, ExceptionMapper,
as
well as CXF RequestHandler, ResponseHandler  ParameterHandler. I'll
attempt
to optimize it later on

One can disable such queries for such providers and also insist that only
those global providers which have identified themselves (through a specific
property) that they will work reliably with CXF can be used.

Alternatively, one can register an array of service/endpoint -specific
providers by using org.apache.cxf.rs.provider property, when registering
an application service.
Will document it tomorrow

Give it a try please whenever you get a chance and let me know if it works
for you

cheers, Sergey



Josh Holtzman wrote:

 Hi Sergey. Yes, we are using JAXB with both JAX-RS and JAX-WS endpoints.

 Josh

 On Aug 21, 2009 6:28 PM, Sergey Beryozkin sbery...@progress.com
wrote:

 Hi Josh

 Can you please let me know if JAXB is being used for your JAX-RS
endpoints
 ?
 I've spotted that for HTTP Service based JAX-RS endpoints no
AegisProvider
 is being set - I'would actually like JAXB being used by default for JAXRS
 endpoints which will be consistent with the expectations of JAX-RS users
 in
 general - but I'd like to confirm first that JAXB is working ok in your
 case...

 thanks, Sergey

 Sergey,  Thanks again for the detailed documentation you've provided in
 this thread.  I was ab...



--
View this message in context:
http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp24127832p25138636.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Integrating JAX-RS runtime into DOSGi

[Josh Holtzman]

Bah, my isReadable and isWriteable were wrong.  Sorry, false alarm.  This
works like a charm!

Thanks,
Josh

On Wed, Aug 26, 2009 at 6:16 PM, Sergey Beryozkin sbery...@progress.comwrote:

 Hi Josh

 Thanks, this is exactly how providers are expected to be registered.
 http://hudson.zones.apache.org/hudson/job/CXF-DOSGi

 shows my changes have been picked up so it's a bug then. Have you tries the
 lastest build from snapshots or built the trunk yourself, including a
 trunk/distributuon ?

 I'll look into it...

 cheers, Sergey

 P.S. was about to ping you on #cxf but somehow I lost the connection
 - Original Message - From: Josh Holtzman jholtz...@berkeley.edu
 
 To: dev@cxf.apache.org
 Sent: Wednesday, August 26, 2009 5:02 PM
 Subject: Re: Integrating JAX-RS runtime into DOSGi



  Great, thanks Sergey.  I just tried this, and wasn't able to read/write an
 arbitrary object.

 I've registered a MessageBodyReader and a MessageBodyWriter (actually, the
 same object) like so:

   FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
   context.registerService(MessageBodyReader.class.getName(),
 fooReaderWriter, null);
   context.registerService(MessageBodyWriter.class.getName(),
 fooReaderWriter, null);

 I see that these services are in fact registered:

 ---
 objectClass = javax.ws.rs.ext.MessageBodyReader
 service.id = 41
 
 objectClass = javax.ws.rs.ext.MessageBodyWriter
 service.id = 42
 

 But when I try to access a Foo via JAX-RS, I get this:

 [9853...@qtp-998044-0 - /inspection/rest/foo] WARN
 org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body
 writer found for response class : Foo.

 Please let me know if I misunderstood the recipe for registering JAX-RS
 providers.  I'll be out of the office until Monday, and will start digging
 into the CXF code to see what's going on when I return.

 Many thanks,
 Josh


 On Tue, Aug 25, 2009 at 7:21 PM, Sergey Beryozkin 
 sergey.beryoz...@iona.com

 wrote:



 Hi Josh

 I've updated the JAX-RS layer in DOSGi such that it will now discover
 JAXRS
 (and CXF specific providers) which have been registered as (global) OSGI
 services. At the moment I've decided not to use a ServiceTracker and
 instead
 a calling BundleContext is asked to exercise a filter expression which
 should catch JAXRS MessageBodyReader, MessageBodyWriter, ExceptionMapper,
 as
 well as CXF RequestHandler, ResponseHandler  ParameterHandler. I'll
 attempt
 to optimize it later on

 One can disable such queries for such providers and also insist that only
 those global providers which have identified themselves (through a
 specific
 property) that they will work reliably with CXF can be used.

 Alternatively, one can register an array of service/endpoint -specific
 providers by using org.apache.cxf.rs.provider property, when
 registering
 an application service.
 Will document it tomorrow

 Give it a try please whenever you get a chance and let me know if it
 works
 for you

 cheers, Sergey



 Josh Holtzman wrote:
 
  Hi Sergey. Yes, we are using JAXB with both JAX-RS and JAX-WS
 endpoints.
 
  Josh
 
  On Aug 21, 2009 6:28 PM, Sergey Beryozkin sbery...@progress.com
 wrote:
 
  Hi Josh
 
  Can you please let me know if JAXB is being used for your JAX-RS
 endpoints
  ?
  I've spotted that for HTTP Service based JAX-RS endpoints no
 AegisProvider
  is being set - I'would actually like JAXB being used by default for
 JAXRS
  endpoints which will be consistent with the expectations of JAX-RS
 users
  in
  general - but I'd like to confirm first that JAXB is working ok in your
  case...
 
  thanks, Sergey
 
  Sergey,  Thanks again for the detailed documentation you've provided
 in
  this thread.  I was ab...
 
 

 --
 View this message in context:

 http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp24127832p25138636.html
 Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Oh, this is exactly the sort of message I was in need for in the end of the 
long and difficult day :-)
Cool. If you could verify (later on today or next week when you're back) that 
you could do

Dictionary props = new Hashtable();
props.put(org.apache.cxf.rs.provider, new Object[]{new FooReaderWriter()});
bundleContext.registerService(YourApplicationService.class.getName, new 
YourApplicationServiceImpl(), properties);

This option will allow users to register per-service tuned FooReaderWriters, something one can do today with registering different 
FooReaderWriter instances on a per-endpoint basis with jaxrs:endpoints


then it would be of help.

thanks for your help

Sergey

- Original Message - 
From: Josh Holtzman jholtz...@berkeley.edu

To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:37 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi



Bah, my isReadable and isWriteable were wrong.  Sorry, false alarm.  This
works like a charm!

Thanks,
Josh

On Wed, Aug 26, 2009 at 6:16 PM, Sergey Beryozkin sbery...@progress.comwrote:


Hi Josh

Thanks, this is exactly how providers are expected to be registered.
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi

shows my changes have been picked up so it's a bug then. Have you tries the
lastest build from snapshots or built the trunk yourself, including a
trunk/distributuon ?

I'll look into it...

cheers, Sergey

P.S. was about to ping you on #cxf but somehow I lost the connection
- Original Message - From: Josh Holtzman jholtz...@berkeley.edu

To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:02 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi



 Great, thanks Sergey.  I just tried this, and wasn't able to read/write an

arbitrary object.

I've registered a MessageBodyReader and a MessageBodyWriter (actually, the
same object) like so:

  FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
  context.registerService(MessageBodyReader.class.getName(),
fooReaderWriter, null);
  context.registerService(MessageBodyWriter.class.getName(),
fooReaderWriter, null);

I see that these services are in fact registered:

---
objectClass = javax.ws.rs.ext.MessageBodyReader
service.id = 41

objectClass = javax.ws.rs.ext.MessageBodyWriter
service.id = 42


But when I try to access a Foo via JAX-RS, I get this:

[9853...@qtp-998044-0 - /inspection/rest/foo] WARN
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body
writer found for response class : Foo.

Please let me know if I misunderstood the recipe for registering JAX-RS
providers.  I'll be out of the office until Monday, and will start digging
into the CXF code to see what's going on when I return.

Many thanks,
Josh


On Tue, Aug 25, 2009 at 7:21 PM, Sergey Beryozkin 
sergey.beryoz...@iona.com


wrote:





Hi Josh

I've updated the JAX-RS layer in DOSGi such that it will now discover
JAXRS
(and CXF specific providers) which have been registered as (global) OSGI
services. At the moment I've decided not to use a ServiceTracker and
instead
a calling BundleContext is asked to exercise a filter expression which
should catch JAXRS MessageBodyReader, MessageBodyWriter, ExceptionMapper,
as
well as CXF RequestHandler, ResponseHandler  ParameterHandler. I'll
attempt
to optimize it later on

One can disable such queries for such providers and also insist that only
those global providers which have identified themselves (through a
specific
property) that they will work reliably with CXF can be used.

Alternatively, one can register an array of service/endpoint -specific
providers by using org.apache.cxf.rs.provider property, when
registering
an application service.
Will document it tomorrow

Give it a try please whenever you get a chance and let me know if it
works
for you

cheers, Sergey



Josh Holtzman wrote:

 Hi Sergey. Yes, we are using JAXB with both JAX-RS and JAX-WS
endpoints.

 Josh

 On Aug 21, 2009 6:28 PM, Sergey Beryozkin sbery...@progress.com
wrote:

 Hi Josh

 Can you please let me know if JAXB is being used for your JAX-RS
endpoints
 ?
 I've spotted that for HTTP Service based JAX-RS endpoints no
AegisProvider
 is being set - I'would actually like JAXB being used by default for
JAXRS
 endpoints which will be consistent with the expectations of JAX-RS
users
 in
 general - but I'd like to confirm first that JAXB is working ok in your
 case...

 thanks, Sergey

 Sergey,  Thanks again for the detailed documentation you've provided
in
 this thread.  I was ab...



--
View this message in context:

http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp24127832p25138636.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Integrating JAX-RS runtime into DOSGi

[Demetris]

After looking at the project I mentioned - here is the article here on 
their web site:

(http://www.dosgi.com/distributed-osgi-webservices-articles-list/39-distributed-osgi-webservices-articles-category/55-initial-idea-distributed-osgi-through-web-services.html)
it seems that the similarities between that MS thesis and this project 
are a few. In the
article they mention that *Apache CFX .. *This is the closest one with 
this thesis project,
yet some significant differences maybe found as we go through deep to 
compare but they

don't really mention these diffs. So these are two separate projects.

Apache CXF DOSGi is the RFC 119 implementation. I remember reading about 
that RFC -

can someone tell me when the implementation in CXF begun?

Thanks


Sergey Beryozkin wrote:

Hi

Have a look here please 


http://cxf.apache.org/distributed-osgi.html

cheers, Sergey



Demetris G wrote:
  

Hey Sergei and Josh

Is the DOSGi you are referring in the essay of an email below the  
Masters thesis I read once (and it became an open source branch of an  
apache project) or is this a separate design?
We worked on a design calked p2pSOA the connected distributed OSGi  
containers over p2p technologies while exposing the endpt bundles as  
web services. So I am fairly interested in your discussion - I just  
want a quick clarification so I can position your work in my mind.  
Thanks


On Aug 21, 2009, at 12:28 PM, Sergey Beryozkin  
sbery...@progress.com wrote:




Hi Josh

Can you please let me know if JAXB is being used for your JAX-RS  
endpoints ?
I've spotted that for HTTP Service based JAX-RS endpoints no  
AegisProvider is being set - I'would actually like JAXB being used  
by default for JAXRS endpoints which will be consistent with the  
expectations of JAX-RS users in general - but I'd like to confirm  
first that JAXB is working ok in your case...


thanks, Sergey

  

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.

I agree that the jaxrs.resource property is no longer needed, as  
you can

simply register jaxrs resources as a dosgi services.

Josh

On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin
sbery...@progress.com 


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
  



  

Re: Integrating JAX-RS runtime into DOSGi

[Demetris]

Ok - for whoever will actually read this email - sorry it's late so my 
previous email

may be a bit confusing.
The project I mentioned (included the link) and the Apache CXF 
Distributed OSGi seem to
share similarities but the person who is working on that MS thesis is 
not really making
a strong case for his work to differentiate it from RFC 119 and its 
implementation. That's
why I was asking whether these are two different projects and apparently 
they are.


My other two questions were clear:
Apache CXF DOSGi is the RFC 119 implementation. I remember reading about 
that RFC
and its early draft release last August - can someone tell me when the 
implementation in CXF

(release 1) began?

Thanks - I need sleep.

Demetris wrote:


After looking at the project I mentioned - here is the article here on 
their web site:
(http://www.dosgi.com/distributed-osgi-webservices-articles-list/39-distributed-osgi-webservices-articles-category/55-initial-idea-distributed-osgi-through-web-services.html) 

it seems that the similarities between that MS thesis and this project 
are a few. In the
article they mention that *Apache CFX .. *This is the closest one 
with this thesis project,
yet some significant differences maybe found as we go through deep to 
compare but they

don't really mention these diffs. So these are two separate projects.

Apache CXF DOSGi is the RFC 119 implementation. I remember reading 
about that RFC -

can someone tell me when the implementation in CXF begun?

Thanks


Sergey Beryozkin wrote:

Hi

Have a look here please
http://cxf.apache.org/distributed-osgi.html

cheers, Sergey



Demetris G wrote:
 

Hey Sergei and Josh

Is the DOSGi you are referring in the essay of an email below the  
Masters thesis I read once (and it became an open source branch of 
an  apache project) or is this a separate design?
We worked on a design calked p2pSOA the connected distributed OSGi  
containers over p2p technologies while exposing the endpt bundles 
as  web services. So I am fairly interested in your discussion - I 
just  want a quick clarification so I can position your work in my 
mind.  Thanks


On Aug 21, 2009, at 12:28 PM, Sergey Beryozkin  
sbery...@progress.com wrote:


   

Hi Josh

Can you please let me know if JAXB is being used for your JAX-RS  
endpoints ?
I've spotted that for HTTP Service based JAX-RS endpoints no  
AegisProvider is being set - I'would actually like JAXB being used  
by default for JAXRS endpoints which will be consistent with the  
expectations of JAX-RS users in general - but I'd like to confirm  
first that JAXB is working ok in your case...


thanks, Sergey

 

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.

I agree that the jaxrs.resource property is no longer needed, as  
you can

simply register jaxrs resources as a dosgi services.

Josh

On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin
sbery...@progress.com

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
  



  

Re: Integrating JAX-RS runtime into DOSGi

[Josh Holtzman]

Hi Sergey. Yes, we are using JAXB with both JAX-RS and JAX-WS endpoints.

Josh

On Aug 21, 2009 6:28 PM, Sergey Beryozkin sbery...@progress.com wrote:

Hi Josh

Can you please let me know if JAXB is being used for your JAX-RS endpoints ?
I've spotted that for HTTP Service based JAX-RS endpoints no AegisProvider
is being set - I'would actually like JAXB being used by default for JAXRS
endpoints which will be consistent with the expectations of JAX-RS users in
general - but I'd like to confirm first that JAXB is working ok in your
case...

thanks, Sergey

 Sergey,  Thanks again for the detailed documentation you've provided in
this thread.  I was ab...

Re: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Hi

Have a look here please 

http://cxf.apache.org/distributed-osgi.html

cheers, Sergey



Demetris G wrote:
 
 Hey Sergei and Josh
 
 Is the DOSGi you are referring in the essay of an email below the  
 Masters thesis I read once (and it became an open source branch of an  
 apache project) or is this a separate design?
 We worked on a design calked p2pSOA the connected distributed OSGi  
 containers over p2p technologies while exposing the endpt bundles as  
 web services. So I am fairly interested in your discussion - I just  
 want a quick clarification so I can position your work in my mind.  
 Thanks
 
 On Aug 21, 2009, at 12:28 PM, Sergey Beryozkin  
 sbery...@progress.com wrote:
 
 Hi Josh

 Can you please let me know if JAXB is being used for your JAX-RS  
 endpoints ?
 I've spotted that for HTTP Service based JAX-RS endpoints no  
 AegisProvider is being set - I'would actually like JAXB being used  
 by default for JAXRS endpoints which will be consistent with the  
 expectations of JAX-RS users in general - but I'd like to confirm  
 first that JAXB is working ok in your case...

 thanks, Sergey

 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.

 I agree that the jaxrs.resource property is no longer needed, as  
 you can
 simply register jaxrs resources as a dosgi services.

 Josh

 On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin
 sbery...@progress.com 
 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
 
 

-- 
View this message in context: 
http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp24127832p25086130.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Integrating JAX-RS runtime into DOSGi

[David Bosschaert]

Hi all,

2009/6/20 Sergey Beryozkin sbery...@progress.com:
 Hi,
  ... snip/ ...
 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.

Just to let you know that an initial version of this is now on trunk.
You can find some documentation about it here: http://tr.im/qKlc

If you find this useful, let me know!

Cheers,

David

Re: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

 but will be
supported by the JAX-RS runtime, a model file in OSGI-INF/cxf/jaxrs
resource folder in the greeter-rest/interface bundle enables it. Note
that in this case the model enables the interface only so all the
implementation objects will be supported as the result. The
GreeterService2Impl registration code in the greeter-rest/impl Activator
is commented at the moment as the cxf 2.2.3-SNAPSHOT needs another
build.

The only issue I haven't solved yet is that the restful client proxies
are created only in case of single-distribution, I could not figure out
why it was not working in case of the multibundle one. Will fix in due
course.

So that is it for now - please try the latest trunk (though I'll ping
you once I can confirm the 2.2.3-SNAPSHOT has been built or please build
it locally). Please let us know what you think - comments/objections/etc
and we'll to sort out all the issues.

I'm going to prioritize now on the mainline jaxrs work around supporting
the metadata plus some various urgent enhancements but will be able to
reply to all your dosgi jaxrs related queries

Cheers, Sergey




-Original Message-
From: Sergey Beryozkin
Sent: 12 June 2009 14:43
To: 'dev@cxf.apache.org'
Subject: RE: Integrating JAX-RS runtime into DOSGi

Fantastic, thanks a million. I might not be able to apply it today as
I'd like to finish some initial WADL work but I will start working with
it on Monday

Cheers, Sergey

-Original Message-
From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
Josh Holtzman
Sent: 12 June 2009 14:20
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi

I've attached the jaxws/jaxrs/databinding patch to
https://issues.apache.org/jira/browse/CXF-2252

Thanks,
Josh

On Fri, Jun 12, 2009 at 3:19 AM, Sergey Beryozkin
sbery...@progress.comwrote:

 Hi,

 I agree, putting the jaxrs-specific resources into OSGI-INF/cxf/jaxrs
 makes sense.
 I'll wait for Josh to submit his patch and then I'll add a simple demo
 and also tests if needed. Josh has already kindly shown all the code
in
 his code review page, but I'd rather him collecting another major
patch
 point than me just copying his code.

 Cheers, Sergey

 -Original Message-
 From: Eoghan Glynn [mailto:eogl...@gmail.com]
 Sent: 12 June 2009 09:58
 To: dev@cxf.apache.org
 Subject: Re: Integrating JAX-RS runtime into DOSGi

 2009/6/12 David Bosschaert david.bosscha...@gmail.com:
 
  2009/6/11 Sergey Beryozkin sbery...@progress.com:
  ...
  The only question I have is where this model info should reside, in
  META-INF/cxf-dosgi ? I'll check with Favid/Eoghan
 
  We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific
intents
  files, so maybe somewhere in the OSGI-INF/cxf area?
 

 Yeah, makes sense to gather all the CXF-specific elements under
 OSGI-INF/cxf.

 Maybe scope it further with OSGI-INF/cxf/jaxrs/resources or somesuch.

 Cheers,
 Eoghan

Re: Integrating JAX-RS runtime into DOSGi

[David Bosschaert]

Hi Sergey,

2009/6/11 Sergey Beryozkin sbery...@progress.com:
...
 The only question I have is where this model info should reside, in
 META-INF/cxf-dosgi ? I'll check with Favid/Eoghan
...
 thanks, Sergey

We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific intents
files, so maybe somewhere in the OSGI-INF/cxf area?

Cheers,

David

RE: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Fantastic, thanks a million. I might not be able to apply it today as
I'd like to finish some initial WADL work but I will start working with
it on Monday 

Cheers, Sergey

-Original Message-
From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
Josh Holtzman
Sent: 12 June 2009 14:20
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi

I've attached the jaxws/jaxrs/databinding patch to
https://issues.apache.org/jira/browse/CXF-2252

Thanks,
Josh

On Fri, Jun 12, 2009 at 3:19 AM, Sergey Beryozkin
sbery...@progress.comwrote:

 Hi,

 I agree, putting the jaxrs-specific resources into OSGI-INF/cxf/jaxrs
 makes sense.
 I'll wait for Josh to submit his patch and then I'll add a simple demo
 and also tests if needed. Josh has already kindly shown all the code
in
 his code review page, but I'd rather him collecting another major
patch
 point than me just copying his code.

 Cheers, Sergey

 -Original Message-
 From: Eoghan Glynn [mailto:eogl...@gmail.com]
 Sent: 12 June 2009 09:58
 To: dev@cxf.apache.org
 Subject: Re: Integrating JAX-RS runtime into DOSGi

 2009/6/12 David Bosschaert david.bosscha...@gmail.com:
 
  2009/6/11 Sergey Beryozkin sbery...@progress.com:
  ...
  The only question I have is where this model info should reside, in
  META-INF/cxf-dosgi ? I'll check with Favid/Eoghan
 
  We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific
intents
  files, so maybe somewhere in the OSGI-INF/cxf area?
 

 Yeah, makes sense to gather all the CXF-specific elements under
 OSGI-INF/cxf.

 Maybe scope it further with OSGI-INF/cxf/jaxrs/resources or somesuch.

 Cheers,
 Eoghan

Re: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Hi Josh

This is super, thanks for starting the actual integration project.


 I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.


It is embedded inside cxf-minimal-bundle (2,3-SNAPSHOT) so there's no need to 
update single or multi bundle distributions.
Yesterday I updated them so that a jaxrs1.0-api specs bundle is pulled in so 
everything should be set in this regard.

I think this code :

http://codereview.appspot.com/71041/patch/3002/3009

should work as is really, thanks.
A couple of comments :

Server :
The only code which may need to be update is the one which checks a 
DataBinding. At the moment it can be considered as redundant as
the JAX-RS frontend does not allow yet for plugging in yet CXF DataBindings. Instead, it relies on JAX-RS MessageBodyProviders which 
are essentially can be seen as data bindings too.


JAX-RS mandates that JAXB is supported out of the box thus, in our case, we don't need to do anything if a jaxb property is set, 
we only need to add an Aegis provider (which actually depends on Aegis databinding) if no jaxb is set, you can register an 
AegisProvider like this :


bean.setProviders(Collections.singletonList(new AegisProvider()));

Client.

If needed, you can also work with JAXRSCleintFactoryBean. JAXRSClientFactory 
just delegates to it through its utility methods.
One of these methods also accepts a list of providers, so if no jaxb is set then that method needs to be used to register an Aegis 
provider


So I think it's nearly there. I'd also consider checking if some model info is available and use it if yes, such that client 
application bundles won't have to import jaxrs* packages if it is something they don't want to do... But it can be done later on


thanks for your help, Sergey


I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.
The work I've done so far [1] will tie the DSW software to the JAX-RS
implementation.  Since cxf-rt-frontend-jaxrs isn't an osgi bundle, I'd have
to embed the jar within DSW to satisfy the dependency.  This doesn't seem
like a good idea to me.  Any suggestions?

Thanks,
Josh

[1] http://codereview.appspot.com/71041

On Wed, Jun 10, 2009 at 5:18 AM, David Bosschaert 
david.bosscha...@gmail.com wrote:


 I've just updated a cxf-minimal bundle to include a jaxrs frontend and I
 updated the cxf.version in dosgi/parent to 2.3.0-SNAPHOT

 (David, Eoghan - we can downgrade it easily to 2.2.2 fixes tag if DOSGi
will
 need to be released sooner than 2.3 does which is in about 3 months or so
I
 believe, with fixes branch likely be easiler tp release earlier).

Yeah - going to 2.2.2.fixes might be good. I expect that a DOSGi
release will be done earlier than in 3 months, especially since the
property names that are used will change in the real OSGi spec, which
is currently being finalized.
I am planning to update the properties in the DOSGi implementation to
reflect the latest in the spec draft either later this week or early
next week.

BTW we now also have Discovery in CXF/DOSGi, so it would be nice to
include that in a release fairly soon too.

Thanks,

David

Re: Integrating JAX-RS runtime into DOSGi

[Josh Holtzman]

Great, I'm glad this is helpful.  And thanks for explaining the redundancy
regarding databindings... that makes sense.

I'd seen your comments about model info earlier in this or a related
thread, but I don't know what model info is.  Perhaps this is a good time
to hand over the reigns to you?

Thanks,
Josh

On Thu, Jun 11, 2009 at 3:34 AM, Sergey Beryozkin sbery...@progress.comwrote:

 Hi Josh

 This is super, thanks for starting the actual integration project.

   I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.


 It is embedded inside cxf-minimal-bundle (2,3-SNAPSHOT) so there's no need
 to update single or multi bundle distributions.
 Yesterday I updated them so that a jaxrs1.0-api specs bundle is pulled in
 so everything should be set in this regard.

 I think this code :

 http://codereview.appspot.com/71041/patch/3002/3009

 should work as is really, thanks.
 A couple of comments :

 Server :
 The only code which may need to be update is the one which checks a
 DataBinding. At the moment it can be considered as redundant as
 the JAX-RS frontend does not allow yet for plugging in yet CXF
 DataBindings. Instead, it relies on JAX-RS MessageBodyProviders which are
 essentially can be seen as data bindings too.

 JAX-RS mandates that JAXB is supported out of the box thus, in our case, we
 don't need to do anything if a jaxb property is set, we only need to add
 an Aegis provider (which actually depends on Aegis databinding) if no jaxb
 is set, you can register an AegisProvider like this :

 bean.setProviders(Collections.singletonList(new AegisProvider()));

 Client.

 If needed, you can also work with JAXRSCleintFactoryBean.
 JAXRSClientFactory just delegates to it through its utility methods.
 One of these methods also accepts a list of providers, so if no jaxb is set
 then that method needs to be used to register an Aegis provider

 So I think it's nearly there. I'd also consider checking if some model info
 is available and use it if yes, such that client application bundles won't
 have to import jaxrs* packages if it is something they don't want to do...
 But it can be done later on

 thanks for your help, Sergey


  I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.
 The work I've done so far [1] will tie the DSW software to the JAX-RS
 implementation.  Since cxf-rt-frontend-jaxrs isn't an osgi bundle, I'd
 have
 to embed the jar within DSW to satisfy the dependency.  This doesn't seem
 like a good idea to me.  Any suggestions?

 Thanks,
 Josh

 [1] http://codereview.appspot.com/71041

 On Wed, Jun 10, 2009 at 5:18 AM, David Bosschaert 
 david.bosscha...@gmail.com wrote:

   I've just updated a cxf-minimal bundle to include a jaxrs frontend and
 I
  updated the cxf.version in dosgi/parent to 2.3.0-SNAPHOT
 
  (David, Eoghan - we can downgrade it easily to 2.2.2 fixes tag if DOSGi
 will
  need to be released sooner than 2.3 does which is in about 3 months or
 so
 I
  believe, with fixes branch likely be easiler tp release earlier).

 Yeah - going to 2.2.2.fixes might be good. I expect that a DOSGi
 release will be done earlier than in 3 months, especially since the
 property names that are used will change in the real OSGi spec, which
 is currently being finalized.
 I am planning to update the properties in the DOSGi implementation to
 reflect the latest in the spec draft either later this week or early
 next week.

 BTW we now also have Discovery in CXF/DOSGi, so it would be nice to
 include that in a release fairly soon too.

 Thanks,

 David

Re: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Hi Josh


Great, I'm glad this is helpful.  And thanks for explaining the redundancy
regarding databindings... that makes sense.

I'd seen your comments about model info earlier in this or a related
thread, but I don't know what model info is.


It is just the alternative way to tell the JAX-RS runtime how a given service 
class has to be exposed as a RESTful service.
I only blogged about it : 
http://sberyozkin.blogspot.com/2009/05/annotation-free-services-with-cxf-jax.html
but I will document it and will also enhance it as well. In the scope of DOSGi it can make quite a bit of sense for some 
deployments, otherwise the client application bundles will need to be explicitly aware of say JAX-RS annotations which will kind of 
'leak' the DSW's internal details into a client bundle, though may be it's not a big deal if such imports are made optional.


The only question I have is where this model info should reside, in 
META-INF/cxf-dosgi ? I'll check with Favid/Eoghan


Perhaps this is a good time to hand over the reigns to you?


Can you please create a new patch with the changes you did to the factory and the newly introduced JaxRs handler ? Or may be just 
update your original pathc to do with the JAXWS support ? I will apply it and proceed from there - will just add some simple demo...


thanks, Sergey



Thanks,
Josh

On Thu, Jun 11, 2009 at 3:34 AM, Sergey Beryozkin sbery...@progress.comwrote:


Hi Josh

This is super, thanks for starting the actual integration project.

  I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.




It is embedded inside cxf-minimal-bundle (2,3-SNAPSHOT) so there's no need
to update single or multi bundle distributions.
Yesterday I updated them so that a jaxrs1.0-api specs bundle is pulled in
so everything should be set in this regard.

I think this code :

http://codereview.appspot.com/71041/patch/3002/3009

should work as is really, thanks.
A couple of comments :

Server :
The only code which may need to be update is the one which checks a
DataBinding. At the moment it can be considered as redundant as
the JAX-RS frontend does not allow yet for plugging in yet CXF
DataBindings. Instead, it relies on JAX-RS MessageBodyProviders which are
essentially can be seen as data bindings too.

JAX-RS mandates that JAXB is supported out of the box thus, in our case, we
don't need to do anything if a jaxb property is set, we only need to add
an Aegis provider (which actually depends on Aegis databinding) if no jaxb
is set, you can register an AegisProvider like this :

bean.setProviders(Collections.singletonList(new AegisProvider()));

Client.

If needed, you can also work with JAXRSCleintFactoryBean.
JAXRSClientFactory just delegates to it through its utility methods.
One of these methods also accepts a list of providers, so if no jaxb is set
then that method needs to be used to register an Aegis provider

So I think it's nearly there. I'd also consider checking if some model info
is available and use it if yes, such that client application bundles won't
have to import jaxrs* packages if it is something they don't want to do...
But it can be done later on

thanks for your help, Sergey


 I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.

The work I've done so far [1] will tie the DSW software to the JAX-RS
implementation.  Since cxf-rt-frontend-jaxrs isn't an osgi bundle, I'd
have
to embed the jar within DSW to satisfy the dependency.  This doesn't seem
like a good idea to me.  Any suggestions?

Thanks,
Josh

[1] http://codereview.appspot.com/71041

On Wed, Jun 10, 2009 at 5:18 AM, David Bosschaert 
david.bosscha...@gmail.com wrote:

  I've just updated a cxf-minimal bundle to include a jaxrs frontend and

I
 updated the cxf.version in dosgi/parent to 2.3.0-SNAPHOT

 (David, Eoghan - we can downgrade it easily to 2.2.2 fixes tag if DOSGi
will
 need to be released sooner than 2.3 does which is in about 3 months or
so
I
 believe, with fixes branch likely be easiler tp release earlier).

Yeah - going to 2.2.2.fixes might be good. I expect that a DOSGi
release will be done earlier than in 3 months, especially since the
property names that are used will change in the real OSGi spec, which
is currently being finalized.
I am planning to update the properties in the DOSGi implementation to
reflect the latest in the spec draft either later this week or early
next week.

BTW we now also have Discovery in CXF/DOSGi, so it would be nice to
include that in a release fairly soon too.

Thanks,

David

Re: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

There's some uinfortunate typo in my last message, hope David won't notice it 
:-)

- Original Message - 
From: Sergey Beryozkin sbery...@progress.com

To: dev@cxf.apache.org
Sent: Thursday, June 11, 2009 5:11 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi



Hi Josh


Great, I'm glad this is helpful.  And thanks for explaining the redundancy
regarding databindings... that makes sense.

I'd seen your comments about model info earlier in this or a related
thread, but I don't know what model info is.


It is just the alternative way to tell the JAX-RS runtime how a given service 
class has to be exposed as a RESTful service.
I only blogged about it : 
http://sberyozkin.blogspot.com/2009/05/annotation-free-services-with-cxf-jax.html
but I will document it and will also enhance it as well. In the scope of DOSGi it can make quite a bit of sense for some 
deployments, otherwise the client application bundles will need to be explicitly aware of say JAX-RS annotations which will kind 
of 'leak' the DSW's internal details into a client bundle, though may be it's not a big deal if such imports are made optional.


The only question I have is where this model info should reside, in 
META-INF/cxf-dosgi ? I'll check with Favid/Eoghan


Perhaps this is a good time to hand over the reigns to you?


Can you please create a new patch with the changes you did to the factory and the newly introduced JaxRs handler ? Or may be just 
update your original pathc to do with the JAXWS support ? I will apply it and proceed from there - will just add some simple 
demo...


thanks, Sergey



Thanks,
Josh

On Thu, Jun 11, 2009 at 3:34 AM, Sergey Beryozkin sbery...@progress.comwrote:


Hi Josh

This is super, thanks for starting the actual integration project.

  I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.




It is embedded inside cxf-minimal-bundle (2,3-SNAPSHOT) so there's no need
to update single or multi bundle distributions.
Yesterday I updated them so that a jaxrs1.0-api specs bundle is pulled in
so everything should be set in this regard.

I think this code :

http://codereview.appspot.com/71041/patch/3002/3009

should work as is really, thanks.
A couple of comments :

Server :
The only code which may need to be update is the one which checks a
DataBinding. At the moment it can be considered as redundant as
the JAX-RS frontend does not allow yet for plugging in yet CXF
DataBindings. Instead, it relies on JAX-RS MessageBodyProviders which are
essentially can be seen as data bindings too.

JAX-RS mandates that JAXB is supported out of the box thus, in our case, we
don't need to do anything if a jaxb property is set, we only need to add
an Aegis provider (which actually depends on Aegis databinding) if no jaxb
is set, you can register an AegisProvider like this :

bean.setProviders(Collections.singletonList(new AegisProvider()));

Client.

If needed, you can also work with JAXRSCleintFactoryBean.
JAXRSClientFactory just delegates to it through its utility methods.
One of these methods also accepts a list of providers, so if no jaxb is set
then that method needs to be used to register an Aegis provider

So I think it's nearly there. I'd also consider checking if some model info
is available and use it if yes, such that client application bundles won't
have to import jaxrs* packages if it is something they don't want to do...
But it can be done later on

thanks for your help, Sergey


 I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.

The work I've done so far [1] will tie the DSW software to the JAX-RS
implementation.  Since cxf-rt-frontend-jaxrs isn't an osgi bundle, I'd
have
to embed the jar within DSW to satisfy the dependency.  This doesn't seem
like a good idea to me.  Any suggestions?

Thanks,
Josh

[1] http://codereview.appspot.com/71041

On Wed, Jun 10, 2009 at 5:18 AM, David Bosschaert 
david.bosscha...@gmail.com wrote:

  I've just updated a cxf-minimal bundle to include a jaxrs frontend and

I
 updated the cxf.version in dosgi/parent to 2.3.0-SNAPHOT

 (David, Eoghan - we can downgrade it easily to 2.2.2 fixes tag if DOSGi
will
 need to be released sooner than 2.3 does which is in about 3 months or
so
I
 believe, with fixes branch likely be easiler tp release earlier).

Yeah - going to 2.2.2.fixes might be good. I expect that a DOSGi
release will be done earlier than in 3 months, especially since the
property names that are used will change in the real OSGi spec, which
is currently being finalized.
I am planning to update the properties in the DOSGi implementation to
reflect the latest in the spec draft either later this week or early
next week.

BTW we now also have Discovery in CXF/DOSGi, so it would be nice to
include that in a release fairly soon too.

Thanks,

David

Re: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Hi Josh



What do you think about this idea. The factory which returns handlers
can check first if a given service intents include HTTP but no SOAP
and a frontend.jaxrs property is set, and if yes then it returns
JaxRSPojoConfigurationTypeHandler which will do what
PojoConfigurationTypeHandler but use JAXRS factories instead. The common
code, if any, can be refactored away into OSGIUtils.

I agree it would be great if a common interface was there but may be we
will be able to get to it at some later stage and collapse handlers into
a single one...

Thanks, Sergey


I can't seem to find JaxRSPojoConfigurationTypeHandler anywhere in the
source.  I thought this was something that had been written and
committed already.  Should I be looking in a branch for this?


Sorry, it was just an idea, there's no such handler in the source code yet.
I've just updated a cxf-minimal bundle to include a jaxrs frontend and I 
updated the cxf.version in dosgi/parent to 2.3.0-SNAPHOT

(David, Eoghan - we can downgrade it easily to 2.2.2 fixes tag if DOSGi will need to be released sooner than 2.3 does which is in 
about 3 months or so I believe, with fixes branch likely be easiler tp release earlier).


I haven't gone yet into the DOSGi code, it's been awhile since I last time worked with it. So the idea is to basically copypaste 
the existing PojoConfigurationHandler into JaxRSPojoConfigurationHandler and return it from a factory if certain conditions are met 
(namely HTTP content is set, no SOAP and the the jaxrs property is also set). And then, as the next step, see what may be refactored 
from both JaxRSPojoConfigurationHandler  PojoConfigurationHandler into OSGIUtils.


so the code for the server should be along these lines :

JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();

sf.setResourceClasses(serviceClass);

sf.setResourceProvider(serviceClass, new 
SingletonResourceProvider(serviceObject));

// only if aegis is needed, otherwise jaxb will be supported otb

sf.setProviders(Collections.singletonList(new AegisProvider()));

return sf.create()

for the client it should be something like

JAXRSClientFactory.create(serviceClass, Collections.singletonList(new 
AegisProvider()));

I'd also like to suggest that we check first if a model info is available, say 
in META-INF/{classname}.model, and if yes then use

JAXRSClientFactory.createFromModel(serviceClass, Collections.singletonList(new 
AegisProvider()), modelRef);

and

JAXRSServerFactoryBean.setModelRef(modelRef)

so that users who'd like to avoid pulling in JAX-RS annotations can avail of 
this featuer - but this can be done later on

Let me know please if you'd like me to prototype some code there.


thanks, Sergey


Thanks,
Josh

--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtz...@berkeley.edu
510.529.9225

Re: Integrating JAX-RS runtime into DOSGi

[Josh Holtzman]

I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.
The work I've done so far [1] will tie the DSW software to the JAX-RS
implementation.  Since cxf-rt-frontend-jaxrs isn't an osgi bundle, I'd have
to embed the jar within DSW to satisfy the dependency.  This doesn't seem
like a good idea to me.  Any suggestions?

Thanks,
Josh

[1] http://codereview.appspot.com/71041

On Wed, Jun 10, 2009 at 5:18 AM, David Bosschaert 
david.bosscha...@gmail.com wrote:

  I've just updated a cxf-minimal bundle to include a jaxrs frontend and I
  updated the cxf.version in dosgi/parent to 2.3.0-SNAPHOT
 
  (David, Eoghan - we can downgrade it easily to 2.2.2 fixes tag if DOSGi
 will
  need to be released sooner than 2.3 does which is in about 3 months or so
 I
  believe, with fixes branch likely be easiler tp release earlier).

 Yeah - going to 2.2.2.fixes might be good. I expect that a DOSGi
 release will be done earlier than in 3 months, especially since the
 property names that are used will change in the real OSGi spec, which
 is currently being finalized.
 I am planning to update the properties in the DOSGi implementation to
 reflect the latest in the spec draft either later this week or early
 next week.

 BTW we now also have Discovery in CXF/DOSGi, so it would be nice to
 include that in a release fairly soon too.

 Thanks,

 David

Re: Integrating JAX-RS runtime into DOSGi

[Josh Holtzman]

Sergey Beryozkin wrote:

This means that

AbstractPojoConfigurationTypeHandler.createClientProxyFactoryBean() 
won't be able to return a JAXRSClientFactoryBean.


What do you think about this idea. The factory which returns handlers
can check first if a given service intents include HTTP but no SOAP
and a frontend.jaxrs property is set, and if yes then it returns
JaxRSPojoConfigurationTypeHandler which will do what
PojoConfigurationTypeHandler but use JAXRS factories instead. The common
code, if any, can be refactored away into OSGIUtils. 


I agree it would be great if a common interface was there but may be we
will be able to get to it at some later stage and collapse handlers into
a single one...
  
Thanks, Sergey
  
I can't seem to find JaxRSPojoConfigurationTypeHandler anywhere in the 
source.  I thought this was something that had been written and 
committed already.  Should I be looking in a branch for this?


Thanks,
Josh

--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtz...@berkeley.edu
510.529.9225

Re: Integrating JAX-RS runtime into DOSGi

[David Bosschaert]

Brilliant! Can't wait to see Distributed OSGi over JAX-RS / REST!

David

2009/6/7 Sergey Beryozkin sbery...@progress.com:
 Hi Josh

 Yes, I would like to work on integrating your JAX-RS work with the
 JAX-WS patch I put together.

 It sounds great :-) Lets chat about all the issues in this thread,
 hopefully we will do it without too many difficulties.

 I took a quick look at JAXRSClientFactory and JAXRSClientFactoryBean.

 It looks like these don't share a common interface or superclass with
 ClientProxyFactoryBean or JaxWsProxyFactoryBean.

 When working on the client api support I looked at the possibility of
 reusing the common interface but I thought it was not possible due to
 some abstractions on the existing interfaces being quite specific and
 not very applicable to the interface which would represent restful
 clients.

 This means that
 AbstractPojoConfigurationTypeHandler.createClientProxyFactoryBean()
 won't be able to return a JAXRSClientFactoryBean.

 What do you think about this idea. The factory which returns handlers
 can check first if a given service intents include HTTP but no SOAP
 and a frontend.jaxrs property is set, and if yes then it returns
 JaxRSPojoConfigurationTypeHandler which will do what
 PojoConfigurationTypeHandler but use JAXRS factories instead. The common
 code, if any, can be refactored away into OSGIUtils.

 I agree it would be great if a common interface was there but may be we
 will be able to get to it at some later stage and collapse handlers into
 a single one...

 Thanks, Sergey

 -Original Message-
 From: Josh Holtzman [mailto:jholtz...@berkeley.edu]
 Sent: 06 June 2009 00:47
 To: dev@cxf.apache.org
 Subject: Re: Integrating JAX-RS runtime into DOSGi

 Hi Sergey,
 Yes, I would like to work on integrating your JAX-RS work with the
 JAX-WS patch I put together.  I'm still very inexperienced with CXF
 internals, so I may need a little hand holding.

 I took a quick look at JAXRSClientFactory and JAXRSClientFactoryBean.
 It looks like these don't share a common interface or superclass with
 ClientProxyFactoryBean or JaxWsProxyFactoryBean.  This means that
 AbstractPojoConfigurationTypeHandler.createClientProxyFactoryBean()
 won't be able to return a JAXRSClientFactoryBean.

 Should all of these client-side proxy factories implement a common
 interface?  I'll admit to being a little lost here, as I still can't
 figure out the difference between JaxWsClientFactoryBean and
 JaxWsProxyFactoryBean :(

 Thanks,
 Josh

 Sergey Beryozkin wrote:

 Hi



 I'm planning to integrate the JAX-RS runtime into DOSGi.

 Both JAXRS endpoints and client proxies can be created either from
 Spring or programmatically and they can work with JAXB, Aegis,
 XmlBeans.



 First CXF minimal bundle needs to be updated to include
 cxf-frontend-jaxrs and depend on jaxrs-1.0 api. This should affect the

 overall bundle size too much.



 Next, as far as DOSGi RI is concerned :

 If HTTP intent is available and org.apache.cxf.dosgi.frontend.jaxrs is

 there then JAXRS gets involved, either on the server or the client
 sides.



 I think that should be enough for a start.



 Next we can ensure that no JAX-RS annotations are required for JAXRS
 runtime to operate in DOSGi case as we now support provisioning of the

 metadata out of band but it can be done later on..



 Josh, if you're interested then we can work on integrating JAX-RS into

 DOSGi together, given that you've provided a JAXWS patch..



 Cheers, Sergey


 --
 Josh Holtzman
 Educational Technology Services, UC Berkeley
 jholtz...@berkeley.edu
 510.529.9225

Re: Integrating JAX-RS runtime into DOSGi

[Josh Holtzman]

Sergey Beryozkin wrote:



This means that

AbstractPojoConfigurationTypeHandler.createClientProxyFactoryBean() 
won't be able to return a JAXRSClientFactoryBean.


What do you think about this idea. The factory which returns handlers
can check first if a given service intents include HTTP but no SOAP
and a frontend.jaxrs property is set, and if yes then it returns
JaxRSPojoConfigurationTypeHandler which will do what
PojoConfigurationTypeHandler but use JAXRS factories instead. The common
code, if any, can be refactored away into OSGIUtils. 


I agree it would be great if a common interface was there but may be we
will be able to get to it at some later stage and collapse handlers into
a single one...
  
Thanks, Sergey
Sounds like a reasonable approach to me.  I will start digging into this 
code tomorrow and let you know what I find.


Thanks,
Josh


--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtz...@berkeley.edu
510.529.9225

RE: Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Hi Josh

 Yes, I would like to work on integrating your JAX-RS work with the 
JAX-WS patch I put together.

It sounds great :-) Lets chat about all the issues in this thread,
hopefully we will do it without too many difficulties. 

 I took a quick look at JAXRSClientFactory and JAXRSClientFactoryBean.

It looks like these don't share a common interface or superclass with 
ClientProxyFactoryBean or JaxWsProxyFactoryBean.

When working on the client api support I looked at the possibility of
reusing the common interface but I thought it was not possible due to
some abstractions on the existing interfaces being quite specific and
not very applicable to the interface which would represent restful
clients. 
 
 This means that
AbstractPojoConfigurationTypeHandler.createClientProxyFactoryBean() 
won't be able to return a JAXRSClientFactoryBean.

What do you think about this idea. The factory which returns handlers
can check first if a given service intents include HTTP but no SOAP
and a frontend.jaxrs property is set, and if yes then it returns
JaxRSPojoConfigurationTypeHandler which will do what
PojoConfigurationTypeHandler but use JAXRS factories instead. The common
code, if any, can be refactored away into OSGIUtils. 

I agree it would be great if a common interface was there but may be we
will be able to get to it at some later stage and collapse handlers into
a single one...
  
Thanks, Sergey

-Original Message-
From: Josh Holtzman [mailto:jholtz...@berkeley.edu] 
Sent: 06 June 2009 00:47
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi

Hi Sergey,
Yes, I would like to work on integrating your JAX-RS work with the 
JAX-WS patch I put together.  I'm still very inexperienced with CXF 
internals, so I may need a little hand holding.

I took a quick look at JAXRSClientFactory and JAXRSClientFactoryBean.  
It looks like these don't share a common interface or superclass with 
ClientProxyFactoryBean or JaxWsProxyFactoryBean.  This means that 
AbstractPojoConfigurationTypeHandler.createClientProxyFactoryBean() 
won't be able to return a JAXRSClientFactoryBean.

Should all of these client-side proxy factories implement a common 
interface?  I'll admit to being a little lost here, as I still can't 
figure out the difference between JaxWsClientFactoryBean and 
JaxWsProxyFactoryBean :(

Thanks,
Josh

Sergey Beryozkin wrote:

 Hi

  

 I'm planning to integrate the JAX-RS runtime into DOSGi.

 Both JAXRS endpoints and client proxies can be created either from 
 Spring or programmatically and they can work with JAXB, Aegis,
XmlBeans.

  

 First CXF minimal bundle needs to be updated to include 
 cxf-frontend-jaxrs and depend on jaxrs-1.0 api. This should affect the

 overall bundle size too much.

  

 Next, as far as DOSGi RI is concerned :

 If HTTP intent is available and org.apache.cxf.dosgi.frontend.jaxrs is

 there then JAXRS gets involved, either on the server or the client
sides.

  

 I think that should be enough for a start.

  

 Next we can ensure that no JAX-RS annotations are required for JAXRS 
 runtime to operate in DOSGi case as we now support provisioning of the

 metadata out of band but it can be done later on..

  

 Josh, if you're interested then we can work on integrating JAX-RS into

 DOSGi together, given that you've provided a JAXWS patch..

  

 Cheers, Sergey


-- 
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtz...@berkeley.edu
510.529.9225

Integrating JAX-RS runtime into DOSGi

[Sergey Beryozkin]

Hi

 

I'm planning to integrate the JAX-RS runtime into DOSGi.

Both JAXRS endpoints and client proxies can be created either from
Spring or programmatically and they can work with JAXB, Aegis, XmlBeans.


 

First CXF minimal bundle needs to be updated to include
cxf-frontend-jaxrs and depend on jaxrs-1.0 api. This should affect the
overall bundle size too much. 

 

Next, as far as DOSGi RI is concerned :

If HTTP intent is available and org.apache.cxf.dosgi.frontend.jaxrs is
there then JAXRS gets involved, either on the server or the client
sides.

 

I think that should be enough for a start.

 

Next we can ensure that no JAX-RS annotations are required for JAXRS
runtime to operate in DOSGi case as we now support provisioning of the
metadata out of band but it can be done later on..

 

Josh, if you're interested then we can work on integrating JAX-RS into
DOSGi together, given that you've provided a JAXWS patch..

 

Cheers, Sergey

Re: Integrating JAX-RS runtime into DOSGi

[Josh Holtzman]

Hi Sergey,
Yes, I would like to work on integrating your JAX-RS work with the 
JAX-WS patch I put together.  I'm still very inexperienced with CXF 
internals, so I may need a little hand holding.


I took a quick look at JAXRSClientFactory and JAXRSClientFactoryBean.  
It looks like these don't share a common interface or superclass with 
ClientProxyFactoryBean or JaxWsProxyFactoryBean.  This means that 
AbstractPojoConfigurationTypeHandler.createClientProxyFactoryBean() 
won't be able to return a JAXRSClientFactoryBean.


Should all of these client-side proxy factories implement a common 
interface?  I'll admit to being a little lost here, as I still can't 
figure out the difference between JaxWsClientFactoryBean and 
JaxWsProxyFactoryBean :(


Thanks,
Josh

Sergey Beryozkin wrote:


Hi

 


I'm planning to integrate the JAX-RS runtime into DOSGi.

Both JAXRS endpoints and client proxies can be created either from 
Spring or programmatically and they can work with JAXB, Aegis, XmlBeans.


 

First CXF minimal bundle needs to be updated to include 
cxf-frontend-jaxrs and depend on jaxrs-1.0 api. This should affect the 
overall bundle size too much.


 


Next, as far as DOSGi RI is concerned :

If HTTP intent is available and org.apache.cxf.dosgi.frontend.jaxrs is 
there then JAXRS gets involved, either on the server or the client sides.


 


I think that should be enough for a start.

 

Next we can ensure that no JAX-RS annotations are required for JAXRS 
runtime to operate in DOSGi case as we now support provisioning of the 
metadata out of band but it can be done later on..


 

Josh, if you're interested then we can work on integrating JAX-RS into 
DOSGi together, given that you've provided a JAXWS patch..


 


Cheers, Sergey



--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtz...@berkeley.edu
510.529.9225