Fucema

Google’s awesome, they release some nifty software to the open source community. Here is the link to Google’s Protocol Buffer and more details are available on Google’s Open Source Blog

From what I can tell, it’s a solid format that can replace XML in most scenarios. It’s not as easily human-readable as XML, but then again from experience not many humans are actively reading the XML anyways. The proto format reminds me of a json structure, minus the curly brackets. Also, from skimming the proto java documentation there isn’t support for primitive arrays (at least for java). You should be using List containers instead along with the proto “repeated” scalar.

They include code for data binding source .proto files to C++, Java and Python. This makes it easier to adopt in your next project. I think this is a good data format for internal use, but you’ll probably still have to deal with XML/SOAP and other RPC formats (JSON, etc) on your external interfaces. This would require transforming the internal data format (.proto) into the external format. There is also stub generating code for producing server interfaces that you can drop into your native rpc server implementations. This is pretty cool also.

Hmmm, I see some useful Mule and Camel transformers that could be made to take advantage of this new format. And possibly service adaptors for Mule and Camel too.

I’ve encountered a typo in the JMS package from Oracle while I was debugging a problem with multicast routing under Camel and Oracle AQ. It seems that Oracle may have slipped up and misnamed the “JMSXRcvTimeStamp” property as “JMSXRecvTimeStamp”. I don’t have access to the source code for the ORacle’s implementation of javax.jms.Message (AQjmsMessage), however I poked through the class file with a hexeditor and found instances of the typo.

According to the Java JMS 1.1 specification, this is a property that is set by the jms provider when a message is dequeued. The spelling of the property is listed as “JMSXRcvTimeStamp” on page 39 of the spec pdf. Oracle Streams Advanced Queuing User’s Guide and Reference 10g Release 2 document referencfes the correctly spelled property in section 11.2.2 however elsewhere in the same document it is incorrectly spelled. I’m pretty sure this is a bug in Oracle’s implementation of the Message interface. The document for Release 11g shows the same errors.

Additionally, I get the feeling that either Camel, Oracle or Spring is incorrectly setting null values for several standard JMS headers and properties when they are not assigned or not present. If null values are allowable under the JMS spec, then Oracle’s AQjmsMessage.setJMSReplyTo(Destination) should accept null parameters without exceptions also. Right now passing a null Destination value to method setJMSReplyTo(Destination) results in this exception:

oracle.jms.AQjmsException: JMS-147: Invalid ReplyTo destination type, or use of reserved `JMSReplyTo agent name, or serialization error with AQjmsDestination org.springframework.jms.UncategorizedJms

Here is the post I created in the Camel users forum relating to this issue.

Here is the JIRA issue I created for camel-jms: https://issues.apache.org/activemq/browse/CAMEL-618