cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [dOSGI] Proxies and Casting
Date Fri, 24 Jul 2009 11:58:45 GMT
Hi Sergey,
Thank you so much.

 I was kind of divide- and- conquering  our issue :) as, we actually are 
dealing with interfaces chains deeper  than the prototype I gave. I don't 
know exactly how cxf is dealing with proxies, but  at bottom line cxf is 
using java.lang.reflect.Proxy as well, which allows determining the list 
of interfaces (e.g. IComponent, IPeristable) the proxy class is 
implementing. I know It would be extremely inefficient traversing the type 
hierarchy  upward when we don't know beforehand the widest type of the 
proxy we're dealing with. But in  cxf case,  dealing, IMHO, mostly with 
services, we can be a bit more deterministic, going from the concrete 
implementation being proxied  up to type of its interface being published. 
In our simple case, the proxied class is Component with its list of 
interfaces { IComponent,IPeristable}. But having a quick look at cxf code, 
at least how client proxies are created in 
org.apache.cxf.frontend.ClientProxyFactoryBean,  I notice that only the 
published interface is being taken into consideration:

  public Object create() {
/// omitted code
 Object obj = 

//<-- the list of interfaces for the proxy class to implement !
        return obj;

  protected Class[] getImplementingClasses() {
        Class cls = clientFactoryBean.getServiceClass(); 
        return new Class[] {cls};

I don't have that knowledge about cxf,  neither am I that good at proxying 
paradigms, so it might  be some very right arguments behind this design 

Anyway, I thankfully keep waiting for any cxf  solution/approach of my 
original problem/issue.

Sergey, I've yet two questions  if you don't mind:
1- is DOSGi zookeeper-based discovery OSGi fully compatible (follows osgi 
RFC119  specs )?  
2- Any chance jira ( can 
be solved  in the near future?

Many Thanks :)

Best regards
Ahmed Aadel

"Sergey Beryozkin" <>
24-07-2009 11:30
Re: [dOSGI] Proxies and Casting

Hi Ahmed

Sorry for a late reply - to be honest I just don't know the answer may be 
others can comment more.

I didn't know DOSGi can handle requests like

IPersistable ip = requestService.syncRequest();

which return interface instances (it probably works with the help 
WS-Addressing under the hood ?)
But even it works, I don't think you can do

IComponent component = (IComponent)ip;

this is really out of DOSGI's control, because it's really controlling the 
publication/lookups of IRequestService only. IPersistable 
instances are CXF proxies as far as I know...If so then it's down to CXF 
to ensure a given proxy implements IPersistable & 
IComponent  and it can't do it as far as I know - unless Dan knows how it 
can be done

cheers, Sergey

----- Original Message ----- 
From: <>
To: <>
Sent: Thursday, July 23, 2009 4:35 PM
Subject: [dOSGI] Proxies and Casting

> Hi
> I have a blocking problem dealing with downcasting proxied types under
> dOSGI, and of course any help from this lovely community is very
> appreciated.
> //given an interface
> interface  IComponent extends IPersistable
> //its implementation
> class Component implements IComponent
> //service contract
> interface IRequestService{
> IPersistable syncRequest();
> }
> // its implementation
> class RequestService implements IRequestService{
> IPersistable syncRequest(){
> //in this arbitrary case return IComponent object
> return new Component();
> }
> An exception such as:  "java.lang.ClassCastException: $Proxy39 cannot be
> cast to ... "
> is thrown  when the  remote consumer is trying to down cast from
> IPersistable to IComponent via proxy:
> class SomeConsumer{
> IRequestService requestService= ..;//some remote proxy to 
> IComponent c = ( IComponent) requestService.syncRequest();
> }
> I found you can config your spring beans to be jdk/cglib  proxied. I 
> adding some aop elements "like":
> <aop:config proxy-target-class="true" /> to my spring/context.xml hoping
> for some springful magic :).
> Back to earth, the problem is that neither our objects (Component in 
> case) were intended to be managed by Spring, nor are we
> intercepting/advising in our osgi app, in first place.
> Is going for some aop stuff (somehow overkill!) for such issues the 
> solution?  Please advise!
> Kind regards
> Ahmed Aadel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message