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
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
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 li
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, h
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 ge
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
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
w
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: de
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 comp
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.a
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.getRet
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.MyJaxRsReaderWrite
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]
[INF
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.
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?
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 O
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
usin
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 t
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
attenti
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 p
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 Augus
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
22 matches
Mail list logo