Hi Jim, Thank you very much for the feedback I really appreciate it. Please see my comments inline marked with [RA]
On 9/26/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Hi Rajith, Thanks for the patch. I had a couple of quick questions, mostly related to things that could be done to evolve the code (It's before I have had enough coffee so bear with me ;-) ):
[RA] I really appreciate this. 1. Some of the exception handling does printStackTrace() and
exceptions derive directly from things like RuntimeException (I realize this is probably just for expediency). Eventually these should probably be converted into descendants of TuscanyException and TuscanyRuntimeException. We did a write-up of this at http:// incubator.apache.org/tuscany/codeguidelines.html which may be useful.
[RA] Yes this was done for expediency. But thats not an excuse :-) Before the code is moved to trunk I want to do proper error handling. The exceptions should be meaningful and consistent with the existing error handling framework. I will address this with the next patch for sure. 2. Could you explain what you have in mind w.r.t. data binding? I
noticed Axiom is used to parse the configuration and then SDO is used to deserialize the payload. I was thinking the StAX APIs could be used for configuration processing and the binding itself could be configured to support a variety of serialization strategies, including non-textual ones? This would break the dependence on Axiom and SDO.
[RA] This was a very primitive attempt at doing databinding. I modeled it on the axis2 binding. Raymond has refactored the code since then to remove the dependency on SDO. I will do the same in the next patch. what I had in mind was to serialize the objects to XML and send as Text messages in JMS. The other end would deserialize it into the format expected by the component. I am hoping to leverage the interceptor chain in the data binding framework The non-textual angel is interesting too. Are u sugesting java serialization and send that as a Bytes message in JMS?? That is something that I had in mind too. But I settled for the XML serialization as the first attempt. 3. There are a couple of places classes are reflectively newed and
they can probably be replaced with system services, e.g. SimpleJMSResourceFactory.
[RA] The JMS binding spec describes that OperationSelectors can be specified as part of the binding. Therefore this will be specified as a fully qualified class name. So we need to support user defined OperationSelectors which is only known at runtime and can only be loaded via reflection. In the absence of that I just do new DefaultOperationSelector(). The same thinking goes behind the JMSResourceFactory as well. I hope I explained my point. If u have further questions please feel free to discuss them. Once again thank you very much for taking the time to review and comment on the patch. Thanks,
Jim On Sep 25, 2006, at 3:29 PM, Rajith Attapattu (JIRA) wrote: > [ http://issues.apache.org/jira/browse/TUSCANY-753?page=all ] > > Rajith Attapattu updated TUSCANY-753: > ------------------------------------- > > Attachment: jmsbinding_jira753_25sep06.patch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
