Websphere problems when setting up Http Connection Pool for RestTemplate - httpclient

I'm working with Spring 4.0.3.RELEASE version. I'm able to make restful calls successfully. However, I learnt that HTTP connections are expensive and thought of using connection pool. I read few articles like this and this. Everything is fine when I include the dependency with Maven3 and compile. The problems arise during runtime.
With this code, I get class not found exception for PoolingHttpClientConnectionManager.
public RestTemplate restTemplate(){
HttpHost host = new HttpHost("localhost", 9081);
PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
// Increase max total connection to 200
cm.setMaxTotal(200);
cm.setDefaultMaxPerRoute(50);
cm.setMaxPerRoute(new HttpRoute(host), 20);
HttpClientBuilder httpClientBuilder = HttpClientBuilder.create().setConnectionManager(cm);
HttpComponentsClientHttpRequestFactory requestFactory = new HttpComponentsClientHttpRequestFactory(
httpClientBuilder.build());
return new RestTemplate(requestFactory);
}
And with this code, I get class not found exception for HttpClients.
public RestTemplate restTemplate(){
RestTemplate restTemplate = new RestTemplate();
HttpComponentsClientHttpRequestFactory requestFactory = new HttpComponentsClientHttpRequestFactory();
requestFactory.setConnectTimeout(20000);
requestFactory.setReadTimeout(20000);
restTemplate.setRequestFactory(requestFactory);
return restTemplate;
}
I'm deploying on Websphere 8.5. And I tried different versions of httpclient from 4.0.1 to 4.5.2 with different scope (provided, compile) with no luck.
Thanks in advance for any hint in the right direction.

So, it's basically a problem with Websphere 8+ versions including httpclient with their jvm library. Luckily, our Enterprise Websphere are all 7.5.x version. So, if we bundle the httpclient with the ear, it does not cause any issue in production or pre-production.
For those, who have to use Websphere 8.x versions, please use the shared isolated library approach as defined here. I used that for my local 8.5 Websphere and it works pretty neat.

you should stop the application and then go to manage module tab in websphere and
and on "Class loader order" combo box choose "parent last" item
and then start application. problem solved...

Related

Using Eureka with Ribbon doesn't send custom header

Current project uses spring-cloud-starter-eureka version 1.0.0.RELEASE.
I am using Ribbon to connect to some other services and require a custom header.
#Autowired
private RestTemplate restTemplate;
. . .
ResponseEntity result = this.restTemplate.exchange("https://FooServices/foos/daily",
HttpMethod.GET,
new HttpEntity(getSpecialHeaders()),
FooView[].class,
new Object[0]);
The code works fine for Spring Cloud version 1.0.0. However, when I move to 1.0.1 or 1.0.2, the custom header is no longer sent.
Is there a security reason this was changed or is this a defect?
It's a bug that has been fixed. It just needs to be released.

gwt-syncproxy can't connect to the address

i'm writing a java project in GWT in eclipse of a car rental agency .
I need to trade info between 2 agencies(server), like the lists of the cars available for rent , and i got suggested to use the gwt-syncproxy .
Description from the site:
GWT SyncProxy provides synchronous RPC between Java client and RemoteService servlet. By using SyncProxy, we can invoke the GWT RemoteService methods from pure Java (no JSNI) code.
I've followed the official guide(also the only one on the net)
https://code.google.com/p/gwt-syncproxy/
but it doesn't work: a message in the browser says:
Plugin failed to connect to Development Mode server at 127.0.0.1:9997 Follow the underlying troubleshooting instructions
(the address i've specified in java client code) project.java
//create new proxy instance for the service interface:
private static GreetingService rpcService =
SyncProxy.newProxyInstance(GreetingService.class,
"http://127.0.0.1:9997", "greet");
//invoke the RPC method:
String result = rpcService.greetServer("SyncProxy");
This is GreetingService.java:
#RemoteServiceRelativePath("greet")
public interface GreetingService extends RemoteService {
String greetServer(String name);
}
and the service implementation GreetingServiceImpl.java:
public class GreetingServiceImpl extends RemoteServiceServlet
implements GreetingService {
public String greetServer(String name) {
return "Hello, " + name;
}
}
What am i doing wrong? Is there a better way to get to do RPC in lan between different servers?
(i got no error in the log file and eclipse console)
Disclaimer: I'm a developer for the Sync-Proxy Android library.
The error you are receiving is not actually from the gwt-syncproxy library. It is from the GWT development system that is indicating that the browser isn't able to contact the dev mode system (being hosted by Eclipse). A couple things to verify:
Is the Development Mode host running in eclipse (Checkout the Development Mode view available in Eclipse) without error?
Are there any errors being thrown by the compiling front-end (check the Console view)
Try clearing your browser cache (brief google search on that error yielded some random occurences preventing the dev mode system from latching on properly)
Try browsing to the hosting url without dev mode support (IE without navigate in the browser to 127.0.0.1:8888 or wherever eclipse says it's hosting your app) and verify that your page is loading properly. If not, I recommend creating a clean start GWT-project and verifying that is working to make sure there isn't another service on your computer that is blocking)
As a follow-up, I'm a little confused by your setup. Are you developing a GWT front-end client or a Java desktop client? Sync-proxy was developed so that regular clients (outside of the GWT framework) could work with GWT designed backended RPC's. Specifically, the server-based RemoteService servlet's need to be utliizing the GWT RPC system, as opposed to just regular RemoteService servlets. If you are developing a GWT front-end client, you should have no need for syncproxy because the regular GWT framework can communicate to the RPC backends. Now, if I understand your purposes of multi-server communication, the question then becomes are you trying to do this communication from your web-frontend (the GWT client) or is this being done from a Java servlet on your backend?
If this is being done in the front-end, I'm afraid I have no instructions available for you to utilize on that because you would have to get past the cross-site scripting issue and syncproxy is not designed to work inside a GWT frontend client (that I've tested anyway). If this is your intention, then as a start, you'll need to use the Asynchronous method call to newProxyInstance:
private static GreetingServiceAsync rpcServiceAsync =
SyncProxy.newProxyInstance(GreetingServiceAsync.class,
"127.0.0.1:8888", "greet");
Specifically, you would end up calling this method twice in order to get to targets, where each URL would represent a different rental agency server. Now, hosting that on your dev machine so that it works properly is a bit outside the scope of this answer, but you'll need to take that into consideration as well
If you are doing this on the back-end, syncproxy may (untested) be able to perform your needs, but you'll need to manage for timeout scenarios since the call you are making will not be asynchronous. On top of that, you'll again have to setup different hosting servers in your dev environment to test a scenario where that might be possible. If this is a big need, put in an issue request for the gwt-syncproxy project and I might be able to test out that scenario and provide instructions somwhere down the line.

Is embeddable container working with JBoss 7?

Some time ago, I tried out the embeddable container API of EJB 3.1 with GlassFish.
Now I tried to do the same thing with JBoss 7.1, but could not make it work. I spent some time researching the problem, but only found others having this problems and no answers or examples to it.
I do know of Arquillian, which more or less eliminates the need of an embeddable container for testing EJBs, but still am interested in a working solution.
So, here's the code which works with GlassFish:
Map<String, Object> params = new HashMap<String, Object>();
//param is needed due to GlassFish bug http://java.net/jira/browse/GLASSFISH-16285
params.put(EJBContainer.APP_NAME, "MyAppName");
EJBContainer container = EJBContainer.createEJBContainer(params);
MyBean instance = (MyBean) container.getContext().lookup("java:global/MyAppName/classes/MyBean");
instance.doSomething("data");
container.close();

Several REST and EJB problems

I'm trying to deploy a Java EE web application with RESTful web services and an EJB connexion to another Java EE application.
I'm experiencing several problems and I fail to write down every specific question, so I have no choice but tell you all in a row.
1) First, I am using Tomcat to run the app and I cannot get EJB connexion to work. No matter what, I get a JNDI error : NamingContextFactory class not found. Why ?
My JNDI connexion is as follows :
String hostname = "localhost";
String port = "1099";
String url = "jnp://" + hostname + ":" + port + "/";
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
h.put(Context.PROVIDER_URL, url);
h.put(Context.URL_PKG_PREFIXES, "org.jboss.naming.client");
initialContext = new InitialContext(h);
2) Therefore, as the server used is not relevant, and as the app I'm trying to connect to is using JBoss (4.4.2.GA), I tried to deploy my app under the same JBoss. I cannot get it to deploy, I have a REST problem: ClassNotFoundException: javax.ws.rs.core.ApplicationConfig at deploy time.
2.1) I am compiling with Netbeans and the ApplicationConfig.class is not part of the 1.1 version of the JAX-RS api jsr311-api-1.1.jar I'm using at compile time. The implementation of the library was changed since 0.8 version, which I was using before, but I had to upgrade the jar because it didn't include #FormParam. Until now, I had found a workaround using com.sun.jersey.api.representation.FormParam instead but Jersey is not compatible with JBoss as far as I understand.
Why is the server looking for ApplicationConfig while it's not used in the war?
2.2) I understood I had to use RESTEasy, and JBoss 4 does not include it, so have to install it manually. But the RESTEasy doc suggest that I thoroughly modify my project my adding a lot of jars, servlets etc. From my point of view, I simply need a RESTful implementation on the server libs to which my JAX-RS API, which is only an interface, will refer once the app is deployed. I may have some serious misconceptions about how Java EE libraries linking work. Please help.
So I know there are several different problems here but I couldn't manage to separate them. I have lost so much time on this that I'm worried for my project. Thanks in advance.

JMS without JNDI?

We are running portlets in WebSphere 6.01, using Java 1.4. We want to send JMS messages to a JBoss 5 queue, running Java 5 (or maybe 6, but it's certainly newer than 1.4). Trying to connect using JNDI is not working, since we have to include the JBoss client jars in the classpath of the portlet, and they are Java 1.5. So I get an unsupported major/minor error when I try to create the InitialContext.
Can we connect straight to JBoss without using JNDI? Or is there some way to get around this issue I can't think of?
Even if you were able to connect to JMS without going through JBoss's JNDI, you would still need to include the JBoss client JAR in order to use JMS. Both JNDI and JMS are APIs, and you need the server's implementation of that client API in order to talk to the server.
If it's just your JNDI classes that prereq Java 5 and not the JBoss classes then you can do this. But you would have to set all of the properties of the objects and that is provider-specific. The WebSphere MQ JMS samples show how to do this with WMQ and you would need to know the property and value names for JBoss to make the equivalent code. Here is a code snippet from the WMQ JmsProducer.java sample:
JmsFactoryFactory ff = JmsFactoryFactory.getInstance(WMQConstants.WMQ_PROVIDER);
JmsConnectionFactory cf = ff.createConnectionFactory();
// Set the properties
cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, host);
cf.setIntProperty(WMQConstants.WMQ_PORT, port);
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, channel);
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT);
cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, queueManagerName);
// Create JMS objects
connection = cf.createConnection();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
if (isTopic) {
destination = session.createTopic(destinationName);
}
else {
destination = session.createQueue(destinationName);
}
producer = session.createProducer(destination);
On the other hand, if your JBoss classes prereq Java 1.5 then you need to run Java 1.5 or better.
Depending on the JBoss version you can directly instantiate all the JMS objects.
One particular version:
see http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta1/html/using-jms.html
(Section 5.5. Directly instantiating JMS Resources without using JNDI)
I think JNDI is the only way that you can create JMS connection factories and destinations (queue or topic), and these are your means of communication.
In fact using JNDI is a way to be independant of the JMS provider, because you can easly change it.
But if you've got no problem with that most provider offer facilities to create a connection factory and destinations
It sounds like the problem isn't with JNDI but with the conflicting classnames between the environments.
You could try doing the classloading yourself when you try to instantiate the JBOSS client classes. That way you get a separate classloader from the one that loaded the Portlet. Just make sure you understand whether you need Parent-first or Parent-last behavior. Also on that page is debugging classloading which can show you how to set the Classpath for the classloader so you can isolate the JBOSS libraries and avoid classname collisions. It is a good resource for understanding even advanced classloading issues.