We Keep Coding

How do I go about Deploying a channel with a connector type of HTTP Sender as a destiantion in Mirth?

I have created a channel with a destiantion of HTTP Sender type in Mirth connect but I cant get the channel to deploy. If fails with a message:
ERROR (com.mirth.connect.server.channel.ErrorTaskHandler:25): java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: javax/activation/DataSource
I have installed Mirth 3.6.1 running on Java 10 in a Mac OS.
There is a solution that might help me and has been suggested but I am so new to Mirth that I do not understand how to implement it.
Suggested Solution

From page 22 of the 3.6 user guide:
Using Java 9 or greater
Currently as per the System Requirements, Mirth Connect version 3.6 supports Java 8 at minimum, and also supports Java 9 and 10. In order to use Java 9 or greater, you'll first need to perform an extra manual step.
In the Installation Directory, there should be a docs folder. Inside, there is a file called mcservice-java9+.vmoptions. This contains some extra JVM options that allow Mirth Connect to run with Java 9 or greater without errors or warnings.
Copy the contents into either the mcserver.vmoptions or mcservice.vmoptions file, depending on whether your
deployment uses mcserver or mcservice. Then restart Mirth Connect. If you're using Java 9 or greater for the
client-side Administrator GUI, make sure also to clear your Java cache and re-launch from the launch page:
Launching the Mirth Connect Administrator

RMI client and server running in different jre versions

I have no RMI experience and have a basic question I seem not to find an answer on the internet.
We want to have RMI calls from a client running jre 6.X to the server running jre 7.X. Is this possible?

Yes it is possible. RMI is highly interoperable.

javax.mail.MessagingException: Could not connect to SMTP host locally via netbeans

I know that there are many questions on this topic, and I have been searching for an answer for the past 4 months. Everyone says check host address, port, and firewall. Well I have done these items, but am still not having any success.
We are running our web application locally using Apache Tomcat 7.0.27 through Netbeans 7.2.1 and are no longer able to connect to the SMTP server to send emails. When running the application on a virtual machine located on the server, there is no issue connecting. We have no problem connecting and sending mail using telnet locally with the same parameters.
We have tried looking at the SMTP logs on the server, and were able to access some logs, but can't find any related to the refused connection. Which SMTP logs would provide more information on this issue? I tend to think that since the connection is refused it may not even trigger any logging, is this a correct assumption? We migrated to IIS7 several months ago and were having trouble accessing IIS 6.0 Manager, so I am not sure that they are even set up correctly.
Does anyone have any ideas of how to further troubleshoot the connection?
Thank you in advance, and please let me know if I can provide any further information.

Almost certainly this is a problem with a firewall or anti-virus program on your local machine. If you can connect from that machine using telnet but can't connect from that same machine using a Java application, there's something on that machine preventing Java applications from connecting.

I recently faced the same problem while running the Mail sending code and what I found is that the code which I had written recently is using the Java version Jre7. But the older codes run in Jre 6 environment, which works perfectly even now also.
So what I had done is I just change the Jre version of my recent code to Jre 6. After that the code works perfectly without any exception.
So try to change your runtime environment to lower Jre and run the code.

"delay" in delivering WebService reply when using sun HttpServer

I'm writing a standalone application that implements a Web Service, for which the Endpoint is published using the embedded Sun HttpServer. I have an odd issue with this, where in a specific deployment situation, there is an apparent delay between the server processing /sending the reply and the client receiving the reply.
Let me give a few scenarios:
Case 1) Working: server is running inside Eclipse, which uses OpenJDK 1.6.0_23 as runtime. Client is implemented with axis (not axis2!) and is running on Solaris x86 inside JBoss (must admit I don't know the exact Java version used, but I suspect a Java 5 version).
Case 2) Working: server is running on Solaris x86 with java 1.6.0_26, client is running inside Eclipse with OpenJDK 1.6.0_23.
Case 3) Not working: server is running on Solaris x86 with java 1.6.0_26, client is on Solaris x86 with axis on Solaris x86 (again, suspect it's Java 5, not 6).
I'm wondering if I could be suffering from the following Java bug, which is fixed in 1.6.0_30 (assuming that OpenJDK 1.6.0_xx does not suffer the same bug)?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068416
But if that's the case, then why would case 2 work? Can the client somehow control the TCP_NODELAY on the server side?
On the exact delays that i have observed: I have 2 web services, published on different contexts. Eg 2 different WSDLs. The client has (obviously) separate (axis 1) bindings for each service. For one service, I see a consistent delay of exactly 150 seconds, for the other service the delay is consistently 300 seconds. Do these values ring a bell to anybody?
Maarten
Edit
I am now leaning towards the cause and solution in Eclipse Generated Web Service Client Extremely Slow. Can't test at the moment as I'm sitting in a hotel room without access to the system.

OK, managed to solve this, by telling Axis to use the CommonsHttpSender instead of the default HttpSender. Since the relevant application already had the prerequisite jars for that inside its WEB-INF/lib directory, that wasn't such a big deal.
To make Axis (1.4) use the CommonsHttpSender, create a "client-config.wsdd" file in the following location (note: this was the non-obvious part that caused me quite a few headaches):
MY.ear/MY.war/WEB-INF/classes/org/apache/axis/client/client-config.wsdd
with the following contents:
<?xml version="1.0" encoding="UTF-8"?>
<deployment
name="commonsHTTPConfig"
xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<!-- use CommonsHTTPSender instead of the default HTTPSender -->
<transport name="http" pivot="java:org.apache.axis.transport.http.CommonsHTTPSender" />
<transport name="local" pivot = "java:org.apache.axis.transport.local.LocalSender" />
<transport name="java" pivot="java:org.apache.axis.transport.java.JavaSender" />
</deployment>
Restart your application. After this change, Axis will use HTTP/1.1 to make web service calls, which seems to be all that was needed to correct this annoying delay. Seems that there is something in the HTTP protocol specs (or perhaps Axis' implementation) that doesn't like a HTTP/1.1 response to a HTTP/1.0 request.
Maarten

Server binding mode to connect Websphere MQ7 without WAS installed on the same server

I've being trying to setup my java application that connects to a local queue manager in MQ7 without a WebSphere Application Server installed on my machine in binding mode. Without specifying the host in the .bindings file, running my application will throw an java exception somewhere along the lines of:
com.ibm.msg.client.jms.DetailedIllegalStateException: JMSWMQ0018:
Failed to connect to queue manager 'TBUKKKNN' with connection mode
'Client' and host name ''. Check the queue manager is started and if
running in client mode, check there is a listener running. Please see
the linked exception for more information.
Although documentation for WebSphere MQ has explicitly denied possibility of connecting to MQ7 without WAS installed on same machine, my colleagues are very confident that there are workarounds for this.
Much appreciated if anyone could help me with this issue. Or let me know if more clarification on my question is required.

I wrote an article a while back that explains how to do this so I'm a little puzzled about any documentation stating that it can't be done. Not only is there a "workaround" but it is officially supported and the sample programs that come with the WMQ Client install media include several that use Java and JMS but do not use a Java EE server. If for some reason you just grabbed the jar files instead of installing the vendor distribution, you can download it for free to get the samples. The v7.0 client is here and the v7.1 client is here. Also, make sure to use the version of the docs that matches your client version. The v7.0 Infocenter is here and the v7.1 Infocenter is here. Any client version can connect to a v7.0 QMgr, by the way.
Anyway, your error message indicates that your Connection Factory transport type is still set to Client. You'll need to change it to BIND. The properties are described here. The landing page with the list of all the properties of all the administered objects is here.

Change to cf.setTransportType(MQCNO_STANDARD_BINDING); ...that should work

cf.setTransportType(WMQConstants.WMQ_CM_BINDINGS);
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_BINDINGS);