Community
Participate
Working Groups
Build Identifier: 3.0.0.M2 We have currently a need to use existing Riena's server side code to build a JSON server, kind of "single-sourcing". Riena's communication feature is well designed and we are able to build our own "JSON" protocol in addition of Hessian by extending the service publisher. So far everything works well, however currently there is a dependency from the communication.core plugin to the hessian plugin, while in our case this server does not require Hessian to be included. Looking at the code the hessian classes are only used in one spot in the communication.core plugin, which is CallHooksProxy trying to check for Hessian exceptions. It looks like this is not a necessary dependency and this can be moved to somewhere else, leaving a clean communication.core plugin with no dependency to any protocol and easy for developers to extend for other protocols. Reproducible: Always
Its no as easy as it seems. o.e.r.communication.core also has a statement Eclipse-RegisterBuddy: com.caucho.hessian Now registering a Buddy only works if you have a dependency. The reason we put that into the core package is that now model objects or anything that needs to be transferred over the wire can register a dependency to the core package and thats it. publisher.hessian and factory.hessian have a dependency to core PLUS they also register a Buddy at core. removing the dependency of core to hessian means publisher.hessian and factory.hessian need a dependency on the hessian bundly PLUS the register as buddy. (thats ok) it also means that any data objects that needs to go over the wire (that is not from the JDK itself) needs to register a dependency on publisher.hessian and factory.hessian plus they need to register as buddy for each of them. Not so nice. Thats why we choose the current construct.
(In reply to comment #1) Thanks for the explanation. Christian. In that case, can we try to use Eclipse-BuddyPolicy: global for the bundles that needs to load classes from other bundles? Or, shall we make this dependency to Hessian optional? so that when there is no Hessian this bundle still can be started. I think that the way Riena design to separate service publish and protocol invoke is very good and is designed to be extendable to other protocols. I am also happy to share the code when the json protocol for Riena service is implemented and stable. > Its no as easy as it seems. o.e.r.communication.core also has a statement > Eclipse-RegisterBuddy: com.caucho.hessian > > Now registering a Buddy only works if you have a dependency. The reason we put > that into the core package is that now model objects or anything that needs to > be transferred over the wire can register a dependency to the core package and > thats it. > > publisher.hessian and factory.hessian have a dependency to core PLUS they also > register a Buddy at core. > > removing the dependency of core to hessian means > > publisher.hessian and factory.hessian need a dependency on the hessian bundly > PLUS the register as buddy. (thats ok) > > it also means that any data objects that needs to go over the wire (that is not > from the JDK itself) needs to register a dependency on publisher.hessian and > factory.hessian plus they need to register as buddy for each of them. Not so > nice. Thats why we choose the current construct.
I will try the optional flag.....I look forward to your contribution of the json protocol implementation.
