Seeming JAX-RS mistake
This can't work right for generic types (like collections), since it doesn't
use java.lang.reflect.Type.
public interface ContextResolver {
/**
* Get a context of type T that is applicable to the
supplied
* type.
* @param type the class of object for which a context is desired
* @return a context for the supplied type or null if a
* context for the supplied type is not available from this provider.
*/
T getContext(Class type);
}
Re: Reliable messaging: Connecting to Oracle
Thanks for the patch, Dan. Your efforts are much appreciated. I've committed the fix just now in r809738. Cheers, Eoghan 2009/8/27 Daniel Kulp > > Please file a JIRA and submit the changes as a patch. This is excellent! > > https://issues.apache.org/jira/browse/CXF > > > Dan > > On Thu August 27 2009 10:17:52 am Dan Ryazansky wrote: > > The current version of CXF uses a Derby database when Reliable messaging > is > > turned on. However, we required use of ORACLE. > > > > I had to make the following changes to to make the code database agnostic > > in RMTxStore: > > > > from > > "CUR_MSG_NO DECIMAL(31, 0) NOT NULL DEFAULT 1, " > > to > > "CUR_MSG_NO DECIMAL(31, 0) DEFAULT 1 NOT NULL, " > > Derby doesn't care about the order of NOT NULL / DEFAULT, Oracle does > > > > from > > "EXPIRY BIGINT, " > > to > > "EXPIRY DECIMAL(31, 0), " > > Oracle doesn't have BIGINT. DECIMAL is the one data type that seems to > work > > across different DBs. > > > > from > > "X0Y32".equals(ex.getSQLState()) > > to > > "X0Y32".equals(ex.getSQLState()) || 955 == ex.getErrorCode() > > When checking for table creation (955 is the Oracle error code if the > table > > already exists). > > > > Is this something that should be committed into the repository? > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: Bigger proposed Aegis change: rename 'Type'
On Mon August 31 2009 10:55:16 am Benson Margulies wrote: > Aegis has a class named 'Type'. This leads to confusing code all over the > place when organizing imports around java.lang.reflect.Type. > > Anyone care to object to changing it to AegisType for 2.3? Nope. Migration guide it it affects people. Though people who are accessing the Aegis Type things are probably few and far between. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
generics and type mapping in Aegis
Sergey's issues with JAX-RS have started me looking at how Aegis maps types. The following temptation now occurs: allow the fundamental aegis type mechanism to map generics. Somene could thus add a mapping from any X -> XML via a custom type. Of course, with type erasure, this only will pay attention to the declared type, not the dynamic type. Somehow, I feel as if this is a slippery slope we don't want to start down. However, the defined APIs for JAX-RS have started us there, with their extra arguments for generic type specs. Apparently, someone thinks that it's so important to be able to write a Collection to the top of JAX-RS to justify adding an asymmetry. Anybody else got a thought here?
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 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.
Re: recent changes
I'm going to revert this change, at least for now until things are fully settled and we get the major stuctural changes in systest pushed back through the fixes. Then, we can probably revisit it on trunk only. The major issue is that those classes are really there to help ANYONE that is using CXF to write unit/system tests for their own work. I know Progress uses it all over the place. Thus, to move it out of rt-core will cause major headaches and not something I want to do on the 2.1/2.2 branches. For trunk, it may make sense, but I'd like to get the rest of the refactoring of the test done first and merged before adding to my misery. :-) Dan On Sun August 30 2009 8:51:51 pm Benson Margulies wrote: > While I was working on splitting the systests, I set out to clean up > some other test-related stuff, perhaps rashly. > > There is some test-only code in rt-core. I moved it from src/main/java > to src/test/java, and changed the POM for rt-core to build a test jar. > Then I 'fixed' the dependencies to have a scope=test dependency on > rt-core with classifier 'tests'. > > For this to work, I had to change the fastinstall profile to use > maven.test.skip.exec instead of plain maven.test.skip. Elsewise, the > tests don't get compiled, and the jar doesn't happen, and the > dependent project refuses to build. > > To really do this cleanly, someone aught to split up rt-core so that > the stuff that the test classes depend on was in one slice and the > other stuff that depends on the test classes was in another, but I > think I've run out of courage for the moment. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: warning: not quite compatible change coming to Aegis in 2.3
On Mon August 31 2009 10:50:42 am Benson Margulies wrote: > Aegis takes a collection of root classes declared as Set>. I plan > to change this to be Set to permit proper generic > analysis. Given how types do and don't work in Java, this will be slightly > incompatible. I actually think this is OK since Class implements Type. In anycase, just add it to:http://cxf.apache.org/23-migration-guide.html -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Bigger proposed Aegis change: rename 'Type'
Aegis has a class named 'Type'. This leads to confusing code all over the place when organizing imports around java.lang.reflect.Type. Anyone care to object to changing it to AegisType for 2.3?
warning: not quite compatible change coming to Aegis in 2.3
Aegis takes a collection of root classes declared as Set>. I plan to change this to be Set to permit proper generic analysis. Given how types do and don't work in Java, this will be slightly incompatible.
Missing OM* classes
Hi all,
I'm having a problems compiling CXF 2.2.3. Very early, when it reaches
"Apache CXF API" it hits errors for missing the AXIOM classes:
[INFO]
[INFO] Building Apache CXF API
[INFO]task-segment: [install]
[INFO]
[INFO] [dependency:unpack {execution: unpack-schemas}]
[INFO] Configured Artifact: org.apache.cxf:cxf-common-schemas:2.2.3:jar
[INFO] Unpacking
D:\.m2\repository\org\apache\cxf\cxf-common-schemas\2.2.3\cxf-common-schemas-2.2.3.jar
to
D:\aiq\jbossws\projects\cxf-2.2.3\api\target\schemas
with includes null and excludes:null
[INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
[INFO] [cxf-common-xsd:xsdtojava {execution: generate-sources}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 15 resources
[INFO] skip non existing resourceDirectory
D:\aiq\jbossws\projects\cxf-2.2.3\api\src\main\resources
[INFO] skip non existing resourceDirectory
D:\aiq\jbossws\projects\cxf-2.2.3\api\src\main\resources-filtered
[INFO] skip non existing resourceDirectory
D:\aiq\jbossws\projects\cxf-2.2.3\api\target\generated\src\main\resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 263 source files to
D:\aiq\jbossws\projects\cxf-2.2.3\api\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
could not parse error message:
org\apache\neethi\PolicyReference.java(org\apache\neethi:PolicyReference.java):35:
package org.apache.axiom.om does not exist
import org.apache.axiom.om.OMElement;
^
could not parse error message:
org\apache\neethi\PolicyReference.java(org\apache\neethi:PolicyReference.java):36:
package org.apache.axiom.om.impl.builder does not exist
import org.apache.axiom.om.impl.builder.StAXOMBuilder;
.GOES ON LIKE THIS
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/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,
RE: Handling collections with Aegis in JAX-RS
Hi Benson
I'll update the javaDocs, now it is the Map, Type> that will be
passed. For example,
List updateList(@PathParam("someParam") FooBean param, List
bars);
In this method a Foo type won't be of interest to Aegis but only
List and List.
So the map containing :
1. updateListMethod.getReturnType() :
updateListMethod.getGenericReturnType()
2. updateListMethod.getParameterTypes()[1] :
updateListMethod.getGenericParameterTypes()[1]
Will be passed to the databinding
So it will provide all the required information. Do you think it will
work for Aegis ? I think it should...
> Aegis has a perfectly
good API for passing in a set of root classes. Why is it better to pass
that
collection through this property map instead of calling setRootClasses?
JAXRS DataBindingProvider is not coded against specific DataBinding
implementations, it is only aware of DataBinding interface, so it should
work with JAXB/Aegis/SDO and XMLBeans. The idea behind introducing this
provider is to let users to use databinding beans as JAXRS provider
instances...
Cheers, Sergey
-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com]
Sent: 31 August 2009 12:59
To: dev@cxf.apache.org
Subject: Re: Handling collections with Aegis in JAX-RS
The more I look at this, the less I understand it. Aegis has a perfectly
good API for passing in a set of root classes. Why is it better to pass
that
collection through this property map instead of calling setRootClasses?
So
that you can get to the other data bindings the same way? It still won't
work for generics.
The problem is this. Aegis has a pre-generic concept of root classes,
because they are *classes*, not reflection types. Classes don't carry
generic information. While Aegis has a default mappings, it won't use it
for
root types. Root types have to be in the root classes or derived from
the
service model. My memory isn't good enough to recall how JAXB deals.
When a
bean has a generic type as a property, the code is using reflection, so
it
can do generic type processing.
So, to get what you want, we'd need to rework your interface to use
java.lang.reflect.Type. I'm willing to look into the Aegis-specific
angle
here for now and see how to add generic roots. I think the new interface
needs more thinks.
On Mon, Aug 24, 2009 at 8:58 AM, Sergey
Beryozkin
wrote:
>
> Hi Benson
>
> Thanks for spending your time on these tests, and fixing CXF 2401. I
was
> also able to add few more tests, including the one which writes/reads
a
> complex Map to/from JSON.
>
> AegisJSONProvider tries its best for users to avoid setting up a
namespace
> map manually, but in cases when it does not guess properly the users
would
> be able to overwrite namespaces and their prefixes as needed. This
isssue
> would likely arise on the read side only, when CXF reads it. JSON is
> namespace-unaware so when reading, one needs to setup a namespace map
for
> Jettison to report values like @ns1.bar to the JAXB reader... (but
only if
> AegisJSONProvider has not guessed how to map prefixes to namespaces)
>
> There's a couple of issues I'd like to discuss. First one is that
> AegisJsonProviderTest.testReadWriteComplexMap does have to setup a
namespace
> for a map root element, but it does not have to do it for
> testWrite/ReadCollection tests. I'm wondering, can it be avoided in
cases
> when Maps are being written/read ? That is, can we modify
> createReader/Writer methods such that QNames for containers like
> Map/Collections and its member types are available ?
>
> Another one is that DataBindingJSONProvider test (aegis tests) still
can
not
> handle collections. I think the problem there is that when
> DataBindingProvider (the one DataBindingJSONProvider extends) is being
> initialized, it uses a workaround which we discussed in the other
thread.
> Namely, it attempts to convert a JAXRS model info into WSDL-like one
and
set
> calls DataBinding.initialize(Service). It's quite limiting for a
number of
> reasons, and one of them is that the generic types are not visible to
data
> bindings
> So we introduced PropertiesAwareDataBinding interface and I've just
updated
> the JAXRS code to call it like this :
>
> Map, Type> allClasses = getAllJAXRSResponseInputTypes();
> Map props = new HashMap();
> props.put(PropertiesAwareDataBinding.TYPES_PROPERTY, allClasses);
> ((PropertiesAwareDataBinding)db).initialize(props);
>
> At the moment no CXF DataBindings implement this newly introduced
interface.
> I think the only way for DataBindingJSONProvider aegis tests which
handle
> collections to start passing is for Aegis DataBinding to implement
> PropertiesAwareDataBinding and initialize itself using the provided
> Map, Type>, as opposed to Service. Would you be open to
updating
> the Aegis databinding ?
>
> thanks, Sergey
>
>
>
>
>
>
>
>
>
>
>
> bimargulies wrote:
>>
>> I have a rather clear memory of working on these, there wasn't enough
>> passing of Generic classes around. I'll go have a look.
>>
>>
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
> 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
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(),
> 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
>
>
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 - .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 e
Re: Handling collections with Aegis in JAX-RS
The more I look at this, the less I understand it. Aegis has a perfectly good API for passing in a set of root classes. Why is it better to pass that collection through this property map instead of calling setRootClasses? So that you can get to the other data bindings the same way? It still won't work for generics. The problem is this. Aegis has a pre-generic concept of root classes, because they are *classes*, not reflection types. Classes don't carry generic information. While Aegis has a default mappings, it won't use it for root types. Root types have to be in the root classes or derived from the service model. My memory isn't good enough to recall how JAXB deals. When a bean has a generic type as a property, the code is using reflection, so it can do generic type processing. So, to get what you want, we'd need to rework your interface to use java.lang.reflect.Type. I'm willing to look into the Aegis-specific angle here for now and see how to add generic roots. I think the new interface needs more thinks. On Mon, Aug 24, 2009 at 8:58 AM, Sergey Beryozkin wrote: > > Hi Benson > > Thanks for spending your time on these tests, and fixing CXF 2401. I was > also able to add few more tests, including the one which writes/reads a > complex Map to/from JSON. > > AegisJSONProvider tries its best for users to avoid setting up a namespace > map manually, but in cases when it does not guess properly the users would > be able to overwrite namespaces and their prefixes as needed. This isssue > would likely arise on the read side only, when CXF reads it. JSON is > namespace-unaware so when reading, one needs to setup a namespace map for > Jettison to report values like @ns1.bar to the JAXB reader... (but only if > AegisJSONProvider has not guessed how to map prefixes to namespaces) > > There's a couple of issues I'd like to discuss. First one is that > AegisJsonProviderTest.testReadWriteComplexMap does have to setup a namespace > for a map root element, but it does not have to do it for > testWrite/ReadCollection tests. I'm wondering, can it be avoided in cases > when Maps are being written/read ? That is, can we modify > createReader/Writer methods such that QNames for containers like > Map/Collections and its member types are available ? > > Another one is that DataBindingJSONProvider test (aegis tests) still can not > handle collections. I think the problem there is that when > DataBindingProvider (the one DataBindingJSONProvider extends) is being > initialized, it uses a workaround which we discussed in the other thread. > Namely, it attempts to convert a JAXRS model info into WSDL-like one and set > calls DataBinding.initialize(Service). It's quite limiting for a number of > reasons, and one of them is that the generic types are not visible to data > bindings > So we introduced PropertiesAwareDataBinding interface and I've just updated > the JAXRS code to call it like this : > > Map, Type> allClasses = getAllJAXRSResponseInputTypes(); > Map props = new HashMap(); > props.put(PropertiesAwareDataBinding.TYPES_PROPERTY, allClasses); > ((PropertiesAwareDataBinding)db).initialize(props); > > At the moment no CXF DataBindings implement this newly introduced interface. > I think the only way for DataBindingJSONProvider aegis tests which handle > collections to start passing is for Aegis DataBinding to implement > PropertiesAwareDataBinding and initialize itself using the provided > Map, Type>, as opposed to Service. Would you be open to updating > the Aegis databinding ? > > thanks, Sergey > > > > > > > > > > > > bimargulies wrote: >> >> I have a rather clear memory of working on these, there wasn't enough >> passing of Generic classes around. I'll go have a look. >> >> >> On Fri, Aug 21, 2009 at 6:38 AM, Sergey >> Beryozkin wrote: >>> >>> Hi Benson >>> >>> if you could look at any of these tests or at least point me in the right >>> direction then it would be great. >>> I know you're busy - so just look at it whenever you get a chance, not >>> urgent... >>> >>> cheers, Sergey >>> >>> >>> Sergey Beryozkin-2 wrote: Hi Benson I can't make the Aegis tests writing/reading collections working in CXF JAX-RS. I've found that AegisProviderTest#testReadWriteComplexMap is still @Ignored, it might've passed for you because it was @Ignored :-) I've also added testWriteCollections() (which writes List) to AegisJSONProviderTest. I also updated DataBindingJSONProviderTest, one of its internal classes to return List. AegisJSONProvider extends AegisElementProvider, DataBindingJSONProvider extends DataBindingProvider which actually (in this case) delegates to Aegis DataBinding. AegisJSONProviderTest fails at the write time, it can't find the mapping for List. DataBindingJSONProviderTest fails early at the Aegis DataBinding initialization time for the same reason. I thought Lists were supported by default ?
Re: Handling collections with Aegis in JAX-RS
Sergey, If you want to me to tackle PADB for Aegis, you have a writing assignment. Please write up a comprehensive explanation in the javadoc. Just calling it an 'alternative' does not give an implementor much to go with. I think the top-level issue with namespaces is going to boil down to the existence, or nonexistence, of 'parts', but I'll report back presently. --benson On Mon, Aug 24, 2009 at 8:58 AM, Sergey Beryozkin wrote: > > Hi Benson > > Thanks for spending your time on these tests, and fixing CXF 2401. I was > also able to add few more tests, including the one which writes/reads a > complex Map to/from JSON. > > AegisJSONProvider tries its best for users to avoid setting up a namespace > map manually, but in cases when it does not guess properly the users would > be able to overwrite namespaces and their prefixes as needed. This isssue > would likely arise on the read side only, when CXF reads it. JSON is > namespace-unaware so when reading, one needs to setup a namespace map for > Jettison to report values like @ns1.bar to the JAXB reader... (but only if > AegisJSONProvider has not guessed how to map prefixes to namespaces) > > There's a couple of issues I'd like to discuss. First one is that > AegisJsonProviderTest.testReadWriteComplexMap does have to setup a namespace > for a map root element, but it does not have to do it for > testWrite/ReadCollection tests. I'm wondering, can it be avoided in cases > when Maps are being written/read ? That is, can we modify > createReader/Writer methods such that QNames for containers like > Map/Collections and its member types are available ? > > Another one is that DataBindingJSONProvider test (aegis tests) still can not > handle collections. I think the problem there is that when > DataBindingProvider (the one DataBindingJSONProvider extends) is being > initialized, it uses a workaround which we discussed in the other thread. > Namely, it attempts to convert a JAXRS model info into WSDL-like one and set > calls DataBinding.initialize(Service). It's quite limiting for a number of > reasons, and one of them is that the generic types are not visible to data > bindings > So we introduced PropertiesAwareDataBinding interface and I've just updated > the JAXRS code to call it like this : > > Map, Type> allClasses = getAllJAXRSResponseInputTypes(); > Map props = new HashMap(); > props.put(PropertiesAwareDataBinding.TYPES_PROPERTY, allClasses); > ((PropertiesAwareDataBinding)db).initialize(props); > > At the moment no CXF DataBindings implement this newly introduced interface. > I think the only way for DataBindingJSONProvider aegis tests which handle > collections to start passing is for Aegis DataBinding to implement > PropertiesAwareDataBinding and initialize itself using the provided > Map, Type>, as opposed to Service. Would you be open to updating > the Aegis databinding ? > > thanks, Sergey > > > > > > > > > > > > bimargulies wrote: >> >> I have a rather clear memory of working on these, there wasn't enough >> passing of Generic classes around. I'll go have a look. >> >> >> On Fri, Aug 21, 2009 at 6:38 AM, Sergey >> Beryozkin wrote: >>> >>> Hi Benson >>> >>> if you could look at any of these tests or at least point me in the right >>> direction then it would be great. >>> I know you're busy - so just look at it whenever you get a chance, not >>> urgent... >>> >>> cheers, Sergey >>> >>> >>> Sergey Beryozkin-2 wrote: Hi Benson I can't make the Aegis tests writing/reading collections working in CXF JAX-RS. I've found that AegisProviderTest#testReadWriteComplexMap is still @Ignored, it might've passed for you because it was @Ignored :-) I've also added testWriteCollections() (which writes List) to AegisJSONProviderTest. I also updated DataBindingJSONProviderTest, one of its internal classes to return List. AegisJSONProvider extends AegisElementProvider, DataBindingJSONProvider extends DataBindingProvider which actually (in this case) delegates to Aegis DataBinding. AegisJSONProviderTest fails at the write time, it can't find the mapping for List. DataBindingJSONProviderTest fails early at the Aegis DataBinding initialization time for the same reason. I thought Lists were supported by default ? I haven't found any exam[le showing how a type mapping for Lists can be created. Can you please, whenever you have a chance, have a look at these tests ? thanks, Sergey >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Handling-collections-with-Aegis-in-JAX-RS-tp24933144p25076146.html >>> Sent from the cxf-dev mailing list archive at Nabble.com. >>> >>> >> >> > > -- > View this message in context: > http://www.nabble.com/Handling-collections-with-Aegis-in-JAX-RS-tp24933144p25115676.html > Sent from the cxf-dev mailing list archive at Nabble.com. > >
RE: New systests subprojetcs are not imported into Eclipse
Works for me now, thanks -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: 31 August 2009 12:15 To: dev@cxf.apache.org Subject: Re: New systests subprojetcs are not imported into Eclipse That works for me. What version of Eclipse have you got? You need to get rid of the .project and .classpath from the systests toplevel. On Mon, Aug 31, 2009 at 6:33 AM, Sergey Beryozkin wrote: > Hi > > > > After running 'mvn -Psetup.eclipse' on the trunk, I can see that all the > related files like .project/etc have been created in > > systests/jaxrs, systests/aegis, systests/uncategorized, but no > projects can be imported from those subfolders. > > Does it work for someone else ? > > > > Cheers, Sergey > > > > > >
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.
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 provi
Re: New systests subprojetcs are not imported into Eclipse
That works for me. What version of Eclipse have you got? You need to get rid of the .project and .classpath from the systests toplevel. On Mon, Aug 31, 2009 at 6:33 AM, Sergey Beryozkin wrote: > Hi > > > > After running 'mvn -Psetup.eclipse' on the trunk, I can see that all the > related files like .project/etc have been created in > > systests/jaxrs, systests/aegis, systests/uncategorized, but no > projects can be imported from those subfolders. > > Does it work for someone else ? > > > > Cheers, Sergey > > > > > >
New systests subprojetcs are not imported into Eclipse
Hi After running 'mvn -Psetup.eclipse' on the trunk, I can see that all the related files like .project/etc have been created in systests/jaxrs, systests/aegis, systests/uncategorized, but no projects can be imported from those subfolders. Does it work for someone else ? Cheers, Sergey
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
> 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,
