You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by ah...@remainsoftware.com on 2009/07/23 17:35:40 UTC
[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 IRequestService
IComponent c = ( IComponent) requestService.syncRequest();
}
I found you can config your spring beans to be jdk/cglib proxied. I tried
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 this
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 right
solution? Please advise!
Kind regards
Ahmed Aadel
remainsoftware.com
Re: [dOSGI] Proxies and Casting
Posted by ah...@remainsoftware.com.
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 =
Proxy.newProxyInstance(clientFactoryBean.getServiceClass().getClassLoader(),
getImplementingClasses(),
//<-- the list of interfaces for the proxy class to implement !
handler);
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
choice.
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 ( https://issues.apache.org/jira/browse/CXF-2352) can
be solved in the near future?
Many Thanks :)
Best regards
Ahmed Aadel
remainsoftware.com
From:
"Sergey Beryozkin" <sb...@progress.com>
To:
<us...@cxf.apache.org>
Date:
24-07-2009 11:30
Subject:
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: <ah...@remainsoftware.com>
To: <us...@cxf.apache.org>
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
IRequestService
> IComponent c = ( IComponent) requestService.syncRequest();
> }
>
> I found you can config your spring beans to be jdk/cglib proxied. I
tried
> 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
this
> 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
right
> solution? Please advise!
>
> Kind regards
> Ahmed Aadel
> remainsoftware.com
Re: [dOSGI] Proxies and Casting
Posted by Sergey Beryozkin <sb...@progress.com>.
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: <ah...@remainsoftware.com>
To: <us...@cxf.apache.org>
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 IRequestService
> IComponent c = ( IComponent) requestService.syncRequest();
> }
>
> I found you can config your spring beans to be jdk/cglib proxied. I tried
> 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 this
> 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 right
> solution? Please advise!
>
> Kind regards
> Ahmed Aadel
> remainsoftware.com