Rajith Attapattu wrote:
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.
XML serialization is better than java serialization - more portable.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
