RE: Integrating JAX-RS runtime into DOSGi
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:
but this does not work:
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
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
wrote:
> 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?
>
>
>org.whatever.FooXmlReaderWriter,
>org.whatever.SomeOtherReaderOrWriter
>
>
> 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
> wrote:
>
> > 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"
> > >
> > To:
> > 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
> >> >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 th
RE: Integrating JAX-RS runtime into DOSGi
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
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
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:
but this does not work:
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
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
wrote:
> 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?
>
>
>org.whatever.FooXmlReaderWriter,
>org.whatever.SomeOtherReaderOrWriter
>
>
> 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
> wrote:
>
> > 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"
> > >
> > To:
> > 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
> >> >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:
> >>> 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/w
RE: Integrating JAX-RS runtime into DOSGi
Ok, I didn't know
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
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:
but this does not work:
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
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
wrote:
> 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?
>
>
>org.whatever.FooXmlReaderWriter,
>org.whatever.SomeOtherReaderOrWriter
>
>
> 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
> wrote:
>
> > 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"
> > >
> > To:
> > 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
> >> >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:
> >>> 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
> >>>&
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:
but this does not work:
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
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 wrote:
> 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?
>
>
>org.whatever.FooXmlReaderWriter,
>org.whatever.SomeOtherReaderOrWriter
>
>
> 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
> wrote:
>
> > 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"
> > >
> > To:
> > 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
> >> >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:
> >>> 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(),
> >>
RE: Integrating JAX-RS runtime into DOSGi
It's finished, so please try a single-bundle distribution :
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi/org.apache.cxf.dosgi
$cxf-dosgi-ri-singlebundle-distribution/
Sergey
-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 31 August 2009 12:36
To: dev@cxf.apache.org
Subject: RE: Integrating JAX-RS runtime into DOSGi
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?
org.whatever.FooXmlReaderWriter,
org.whatever.SomeOtherReaderOrWriter
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
wrote:
> 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"
>
> To:
> 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
> >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:
>>> 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 - .N
RE: Integrating JAX-RS runtime into DOSGi
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?
org.whatever.FooXmlReaderWriter,
org.whatever.SomeOtherReaderOrWriter
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
wrote:
> 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"
>
> To:
> 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
> >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:
>>> 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.
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?
org.whatever.FooXmlReaderWriter,
org.whatever.SomeOtherReaderOrWriter
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 wrote:
> 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" >
> To:
> 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 > >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:
>>> 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
Re: Integrating JAX-RS runtime into DOSGi
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"
To:
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 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"
To:
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"
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
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 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" > > To: > 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" >>> 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
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" To: 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 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" 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
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 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" > 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
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" 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
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" 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
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" 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 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
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" 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 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
Ok so that's it - perfect thanks Sergey On Aug 21, 2009, at 3:40 PM, 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" 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 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
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" > 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 >>> >> >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
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" 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 >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
s 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 wrote: > 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 : > > > > 2009/6/11 Sergey Beryozkin : > > ... > >> 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
Hi all, 2009/6/20 Sergey Beryozkin : > Hi, > ... ... > 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
x27;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-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 wrote: > 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 : > > > > 2009/6/11 Sergey Beryozkin : > > ... > >> 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
eter-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 > wrote: > > > 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 : > > > > > > 2009/6/11 Sergey Beryozkin : > > > ... > > >> 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
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-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
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 wrote: > 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 : > > > > 2009/6/11 Sergey Beryozkin : > > ... > >> 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
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 wrote: > 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 : > > > > 2009/6/11 Sergey Beryozkin : > > ... > >> 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
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 : > > 2009/6/11 Sergey Beryozkin : > ... >> 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
2009/6/12 David Bosschaert : > > 2009/6/11 Sergey Beryozkin : > ... >> 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
Hi Sergey, 2009/6/11 Sergey Beryozkin : ... > 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
There's some uinfortunate typo in my last message, hope David won't notice it :-) - Original Message - From: "Sergey Beryozkin" To: 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 wrote: 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
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 wrote: 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
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 wrote: > 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
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
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
> 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
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 copy&paste
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
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
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
Brilliant! Can't wait to see Distributed OSGi over JAX-RS / REST! David 2009/6/7 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 > >
RE: Integrating JAX-RS runtime into DOSGi
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
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
