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,
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
Missed 'would result in the array value being passed'...
-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 31 August 2009 13:10
To: dev@cxf.apache.org
Subject: RE: Integrating JAX-RS runtime into DOSGi
Ok, I didn't know
property
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]
Aegis takes a collection of root classes declared as SetClass?. I plan
to change this to be Setjava.lang.reflect.Type 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 SetClass?. I plan
to change this to be Setjava.lang.reflect.Type to permit proper generic
analysis. Given how types do and don't work in Java, this will be slightly
incompatible.
I
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
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
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 Xy,x,q
- XML via a custom type. Of course, with type erasure, this only will pay
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
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 dk...@apache.org
Please file a JIRA and submit the changes as a patch. This is excellent!
https://issues.apache.org/jira/browse/CXF
Dan
On
This can't work right for generic types (like collections), since it doesn't
use java.lang.reflect.Type.
public interface ContextResolverT {
/**
* Get a context of type codeT/code that is applicable to the
supplied
* type.
* @param type the class of object for which a context
14 matches
Mail list logo
