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" <[email protected]>
To:
<[email protected]>
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: <[email protected]>
To: <[email protected]>
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
