On 17/01/12 19:00, gaygeek wrote:
I tried out the DOSGI change and it will work very well
great
--the only thing
missing is the ability to specify in.fault and out.fault interceptors to
cover all interceptor lifecycles. Also, I have a suggestion on the
implementation--in ClassUtils, I think
I tried out the DOSGI change and it will work very well--the only thing
missing is the ability to specify in.fault and out.fault interceptors to
cover all interceptor lifecycles. Also, I have a suggestion on the
implementation--in ClassUtils, I think the loadProviderClasses should also
check the se
Great--I see on the trunk code you have added the below for in and out
interceptors, but how about in.fault and out.fault interceptors? I'll be
trying this out today--thanks again for looking into this issue so quickly.
-Jeff
On Tue, Jan 17, 2012 at 7:55 AM, Sergey Beryozkin-5 [via CXF] <
ml-nod
Hi
On 17/01/12 13:47, gaygeek wrote:
Sergey-
Can you explain how this will work for already-instantiated interceptors
from DOSGi? I realized that there are some interceptors where I may want to
inject spring beans, so the annotation approach won't work for those. Will
there be a way to reference
Thanks Freeman for the idea of another approach... I have not worked with
osgi fragments, so was not aware how they work. This sounds like an
approach that could work in many situations where other osgi classloader
issues arise in 3rd-party libraries.
-Jeff
On Mon, Jan 16, 2012 at 8:46 PM, Freema
Sergey-
Can you explain how this will work for already-instantiated interceptors
from DOSGi? I realized that there are some interceptors where I may want to
inject spring beans, so the annotation approach won't work for those. Will
there be a way to reference a spring-instantiated bean as the inte
Hi,
Another general solution to workaround this class.forname issue in
OSGi world is create your customer bundle as a fragment bundle, and
attach it to the cxf bundle(cxf bundle play the role as a host
bundle), so that all fragment bundle resource is available for host
bundle.
We usually
Dan and Sergey-
Thanks for your responses. I locally modified the cxf 2.5.2-SNAPSHOT
AnnotationInterceptors class and the interceptor annotations to allow class
objects to be set in the annotations as Dan suggested and that will work
very well. Instead of needing the classloader to find the classe
Dan, thanks for the fix/enhancement, I also updated DOSGi
to check for custom interceptors & features passed along during the
registration/lookup, possibly already instantiated, and also from
Declarative Services...for WS & RS
Just stopped short of also starting the trackers, may be later :-)
On Monday, January 16, 2012 7:33:45 AM gaygeek wrote:
> Yes--as you said, the export is there in my custom bundle, but the cxf
> bundle has no way to import it to create the interceptor instance.
>
> Are you saying there is currently a way to do this, or that DOSGi will need
> to be modified to al
Yes--as you said, the export is there in my custom bundle, but the cxf
bundle has no way to import it to create the interceptor instance.
Are you saying there is currently a way to do this, or that DOSGi will need
to be modified to allow custom interceptors? I think you are saying it is
not availa
Ignore that please, keeping forgetting the cxf bundle does not import
custom classes/
I think in DOSGi case, a new property would have to be introduced in
time for custom CXF interceptors be picked up
Cheers, Sergey
On 16/01/12 12:25, Sergey Beryozkin wrote:
Does the custom bundle export "c
Does the custom bundle export "com.uhg.upm.webservice.interceptor" ?
Sergey
On 13/01/12 22:36, gaygeek wrote:
I am trying to configure a custom interceptor for a web service I'm exposing
with DOSGi. However, it seems that the interceptor cannot be initialized via
annotation, as the org.apache.c
13 matches
Mail list logo
