I am trying to send an ActiveMQ StreamMessage from a C++ (CMS) client to a Java (JMS) client. However, the Java client is unable to correctly read the values from the incoming message - most fields are extracted as null, and the fields that do have values associated with them just seem to contain garbage.
I can send BytesMessages and TextMessages from our C++ client to our Java client just fine, so the BytesMessage is our fallback for now.
However, the misbehaving StreamMessage is making us suspect something is wrong/incompatible between our two clients.
We are using ActiveMQ 5.4.2 on the Java side, and activemq-cpp 3.0.1 on the C++ side.
Are there any known incompatibilities between the JMS and CMS implementations, or are there any other obvious pitfalls I should look for?
I think there were some issues that I fixed somewhere between 3.0.1 and the latest 3.2.4 that fixed some issues with stream message. I'd really recommend that you update to v3.2.4 of CMS as there's been a large number of bugs fixed, along with some great new features.
The CMS issue tracker is here if you want to review to issues fixed since the version you are using:
Edit: Found the issue that fixed it, its here.
-Tim
www.fusesource.com
Related
I am working on my graduate thesis about RESTful web services in Spark micro framework and I want to talk a little about HTTP 1.1 protocol specifically HTTP methods. Problem is I am a bit confused with the reference documentation cause till now in my graduate thesis I've used HTTP 1.1 RFC2616 as my reference documentation but I see that there is a lot of new updated versions like RFC7230 and I am confused which one is the current one that is used. I am currently using jetty-9.4.4.v20170414 as my server and I can see that the server uses HTTP 1.1 but I am not sure if I am describing the right version of HTTP used in my jetty server?
2616 has been obsolete since June 2014, when they released 723x. Each of 7230-7235 have a section at the end that describes what changes there are since 2616. I can't speak to what's being used in Jetty, but there are not many substantiative changes between the documents, so if that version of Jetty is relatively recent, I'd expect it conforms to the new specs. Have you tried asking the Jetty authors?
So I've been searching for 1 hour on Google and this website if I can generate reports using Jasper reports in Dart.
Anyone know if it is possible?
Is there any plug-in?
Thanks in advance
You can make a request from the browser (might be Dart) to the server (probably in Dart according to your question) and the server has to forward the request to a service running in Java or an application built in Java which generates the PDF file and returns the file (or the path to the file) to the Dart server which itself serves it to the browser.
You can make a Java service that accepts HTTP requests directly and skip the Dart server. The Browser can then directly access the Java service that generates the PDF and receive it from there.
It all depends how your infrastructure looks like.
(I don't know Jasper Reports, it might offer some functionality that makes this easier. This is just a generic answer).
You might take a look at this site
http://community.jaspersoft.com/questions/818313/which-best-way-use-jasperreport-php-application
I suppose this will apply mostly to Dart as well.
I found that Jasper Reports offers a standalone server which allows both above described scenarios
http://community.jaspersoft.com/project/jasperreports-server
There seems not to be a dedicated Dart client available (like this one for PHP) but Dart is quite capable of accessing a REST API. It's just a bit more manual labor to access the server than with customized a client library.
Is there any good library which supports WebSockets and is compatible with GWT? Ideally, the library would support WebSockets as well as a fallback for browsers which don't support WebSocket, e.g. a comet-like approach or polling.
I'm currently using GWT-Comet to push data from my server to my GWT web application. However, this library is a bit broken in some aspects and it seems it's not maintained actively anymore. Thus, I'm searching for an alternative.
I found Atmosphere, which suits the needs stated in the question pretty good. It supports GWT, and also Websockets. Also, it supports many different application Servers, like Tomcat and Jetty.
We are developing an application that has an iPhone client, and a Rails server. We have released a first version, and are now starting to work on 1.1 version.
We were wondering if there are any tools (external or provided by hostingrails) to address those two basic requirements:
- development / production versions of a Rails application
- simultaneous live versions of the application (versioned APIs) for example to keep supporting older versions of the client application iPhone.
A first approach we are thinking of right now would be to duplicate the application for each version of the API we want to have, each of them being referenced by a specific URL for example: myapp.com/v1 , myapp.com/v2 ...
This entire stack would itself be duplicated in order to have a live/production version, and a development one. Once tested, the development version would be switched with the production version.
What do you think of this approach ? Are there any tools that allow to manage the lifecycle of the application ?
Does Rails has built-in features facilitating this ?
Thanks
The simplest thing would just be to keep your API backward-compatible, thus obviating the need to maintain two versions of the API, and if you must evolve it in a way that breaks backwards compatibility, deprecate the old API and give it a real termination date so that you don't support it ad infinitum.
If you absolutely have to go down this road, read Fowler's blog post on the topic first (http://martinfowler.com/bliki/TolerantReader.html) and then look at namespacing your API routes. In Rails you could accomplish this using namespaced routes and controllers, so you might have your original api at /application/endpoint and your new version at /application/v2/endpoint (I'm assuming that you can't change your endpoints for old clients easily)
I'm not aware of any tools that explicitly claim to solve the problems you're saying you want to solve, but I think that has more to do with developers working hard not to need them than the idea that they're not solvable in Rails.
Did you consider using Subdomains?: http://railscasts.com/episodes/221-subdomains-in-rails-3
I have tried several Java frameworks, but I only found out that Axis 1 supports these messages, but Axis 1 is old and not developed anymore. So I would like to know if there are any Java frameworks that support RPC/Encoded messages and are still supported and developed.
It looks like Axis1.4 is the only option as RPC/encoded SOAP should be old - old and no longer developed framework shoudln't be a problem
http://ws.apache.org/axis/java/user-guide.html#ServiceStylesRPCDocumentWrappedAndMessage