Does anyone know if its possible to re-configure CometD to use the WebSphere Application Server instead of using Jetty? If so, is there much effort involved in porting it over if I've already got CometD running with Jetty?
CometD runs in any Servlet 2.5 or later Servlet Container, see here.
You did not specify the WebSphere version, but I assume it's a recent enough one.
The only CometD feature that will not work in WebSphere is the WebSocket transport, which is Jetty specific due to lack of standard WebSocket API (now filled by JSR 356 and supported soon in CometD 3).
Your CometD application should deploy and run with no changes in WebSphere, unless you tied yourself explicitly to Jetty APIs.
Related
I have application working on Jboss eap 6.3 and Hornetq queue for jms. I have to change queue from hornetq to OracleAQ. Is there any ready resource-adapter to connect it or I have to write new one for my own? I will be gratefull for any tips how can i achieve that. Thanks in advance.
As far as I know, Oracle AQ's administered JMS objects (e.g. connection factories and destinations) must be looked up via a database connection (or perhaps LDAP) rather than JNDI. Nothing shipped with JBoss EAP can do this.
I propose to check with Oracle for information regarding a JCA resource adapter that they might provide for integration with other Java EE application servers like JBoss EAP.
I'm evaluating options for my team's middleware. We really have a frankenstein'd setup. We're using Apache ServiceMix(Karaf/ActiveMQ/CXF), Websphere 8.5, ActiveMQ where we don't really need it, and all of our applications are not really coded to failover to another node if the primary goes down. We realized the issues of our setup and now want to improve.
We currently host bundles (not sure if they're all OSGI compliant) in a Karaf Container, which are used via ActiveMQ after being sent JMS messages via Apache Camel from Websphere.
My current idea is to kill off ActiveMQ, make all the camel routes towards HTTP (instead of JMS queues), and convert our data bundles/services to serve via HTTP through Apache CXF (replacing websphere for some things) and not ActiveMQ Queues/JMS. However, we have Websphere licenses, and I do know that it supports bundles in some way, I'm just not as familiar as to how it does (same nature as karaf)?
The main question is in the title, and I hope it's not too generic.
WebSphere 8.5 is a full OSGi container supporting Blueprint just as Karaf does.
You can, in theory, run your camel bundles or whatnot just as fine in WAS8.5. However, Apache Karaf is a lot more aligned towards running ActiveMQ/CXF/Camel stuff than WebSphere will ever be. Installation in Karaf is a few commands, where installation and configuration struggle in WAS85 for the Camel feauters and basic camel routes is .. well, a headace when I tried it last time. Others seems to have the same struggle.
I have rather good experience of running Camel apps inside WebSphere Application Server, but that was by embedding Camel in a standard WebApp, not using the OSGi stuff. So, embedded web apps is my recommendation for running Camel inside WebSphere.
For the "replace AMQ/JMS with HTTP" part. You are aware of that you are replacing pears with apples, right? JMS has a lot of features HTTP does not have (and some overhead compared to HTTP). For the sake of completeness, WebSphere also has a JMS provider built in. So if you have a large HA secured WebSphere infrastructure, the WebSphere (SIBus) provider might be a good choice. Otherwise, ActiveMQ rocks :-)
We are working on an IBM WebSphere MQ application, and we use JMS API to operate the message. But we have a problem that the connection takes too much time, and we want to pool the JMS connection, for it's a standalone application, we have no application container to provide JNDI or pooling service. So is there a solution to resolve this? For JDBC we can use DBCP or c3p0 to archive pooling datasource, in JMS, is there any similar project that can pool JMS connections?
It used to be that the JMS MQConnectionFactory had pooling built in, but it seems that in version 7, it has been removed.
Set the use of ConnectionPooling in earlier versions of the WebSphere
MQ classes for JMS. This method is retained for compatibility with
older MQJMS applications, but, because this Connection Pooling
functionality has been removed from version 7, setting this property
will have no effect.
In the absence of anything else, you can use Apache Commons Pool. Same idea as DBCP (which uses Pool) but for non JDBC objects.
Spring's CachingConnectionFactory works well for this use case.
This answer in https://stackoverflow.com/a/31119435/1765341 explains how to do this in Tomcat, but the code there can easily be adapted for Java standalone applications. This should be much easier (and less error prone) than writing an Apache Commons Pool implementation.
We're looking at the choice between implementing an enterprise integration solution in either:
Spring/Spring Integration/JMS/Spring Web MVC
Websphere Application Server/MDB/Spring
What are the pros/cons?
Especially interested in what WAS/MDB solution is functionally better at.
Cheers
Paul
If the only thing you need in your entire project from the Java EE Specification is to get messages from a JMS provider, I suggest you to not use WebSphere App Server. Go with Tomcat+Basic Spring JMS Template. Simple, free, lightweight.
Websphere will bring a level of complexity you don't need. Stay away from heavy weight app server. But if you need more fancy Transaction management ( XA between JMS and a DB) then get a real Java EE App Server.
Anybody knows about a performance comparison for Tomcat vs Websphere app server's web container?
www.webperformanceinc.com provides such a comparison but it's very outdated, somebody knows if there is a newer one, say with Websphere v6.1 or v7?
Websphere uses Tomcat under the hood. It only adds some more Java EE capabilities (EJB and so on) and of course the IBM sausage over it, so I wouldn't expect Websphere to be much faster than Tomcat.