And Todays’s Quote Would Be..

Life begins at the end of your comfort zone.

Neale Donald Walsch

ServletContext.getRealPath Always Return Null on Apache Tomcat 8

I met a very strange error, that somehow works on Tomcat 7, but not working on Tomcat 8. I’m using ServletContext’s class getRealPath method, for getting my application’s absolute file path. Here is my code,

@PostConstruct
    private void init() {
        try {
            // get report location
            String reportLocation = servletContext.getRealPath("WEB-INF");           
        } catch (Exception e) {
            logger.error(e.getMessage(), e);
        }
    }

On this code, i’m trying to get my report’s location and then processing it, by using servletContext.getRealPath. Which works well on my Apache Tomcat 7, but not well enough on Apache Tomcat 8. Somehow it always show null instead of the absolute path of my “WEB-INF” folder.

The workaround is actually quite simple, adding slash in front of “WEB-INF” make the problem disappear.

@PostConstruct
    private void init() {
        try {
            // get report location
            String reportLocation = servletContext.getRealPath("/WEB-INF");           
        } catch (Exception e) {
            logger.error(e.getMessage(), e);
        }
    }
Google+

How to Deploy War File Manually On JBOSS EAP 6.2.0

I usually deploy my war file into JBOSS EAP, using JBOSS’ web console. But i found a very weird condition where i cannot access my web console, so i need to deploy my war file manually from the server’s local disk.

This is how my EAP web console looks like, where i used to deploy my War file.
eap

So basically what i do is i use FTP to transfer my war file from my local disk to the server’s disk, and after that i copy my war file to EAP’s deployment folder. Well in my case, this is my folder location

/usr/share/eap/standalone/deployments

After a while, there will be a file, with the same name as my war file, but with an added extension (.deployed). It means that my war file, has successfully deployed.

eap2

Those new file with extension are called marker files, and they have a different function depends on their extension. Different marker file suffixes have different meanings. And the relevant marker file types are, based on README.txt file,

.dodeploy — Placed by the user to indicate that the given content should be deployed into the runtime (or redeployed if already deployed in the runtime.)

.skipdeploy — Disables auto-deploy of the content for as long as the file is present. Most useful for allowing updates to exploded content without having the scanner initiate redeploy in the middle of the update. Can be used with zipped content as well, although the scanner will detect in-progress changes to zipped content and wait until changes are complete.

.isdeploying — Placed by the deployment scanner service to indicate that it has noticed a .dodeploy file or new or updated auto-deploy mode content and is in the process of deploying the content. This marker file will be deleted when the deployment process completes.

.deployed — Placed by the deployment scanner service to indicate that the given content has been deployed into the runtime. If an end user deletes this file, the content will be undeployed.

.failed — Placed by the deployment scanner service to indicate that the given content failed to deploy into the runtime. The content of the file will include some information about the cause of the failure. Note that with auto-deploy mode, removing this file will make the deployment eligible for deployment again.

.isundeploying — Placed by the deployment scanner service to indicate that it has noticed a .deployed file has been deleted and the content is being undeployed. This marker file will be deleted when the undeployment process completes.

.undeployed — Placed by the deployment scanner service to indicate that the given content has been undeployed from the runtime. If an end user deletes this file, it has no impact.

.pending — Placed by the deployment scanner service to indicate that it has noticed the need to deploy content but has not yet instructed the server to deploy it. This file is created if the scanner detects that some auto-deploy content is still in the process of being copied or if there is some problem that prevents auto-deployment. The scanner will not instruct the server to deploy or undeploy any content (not just the directly affected content) as long as this condition holds.

Google+

How to Create A HTTP Request with Proxy Using Apache HTTP Client

In this tutorial, im trying to simuate a http GET request using apache http client, the version im using is 4.5.1

<!-- http client -->
<dependency>
	<groupId>org.apache.httpcomponents</groupId>
	<artifactId>httpclient</artifactId>
	<version>4.5.1</version>
</dependency>
<dependency>
	<groupId>org.apache.httpcomponents</groupId>
	<artifactId>httpmime</artifactId>
	<version>4.5.1</version>
</dependency>

Usually, my application connects well without proxy. But on production environment, I need to put a proxy configuration. So this is my method for making a proxy request connection.

public String process(String lat, String lon) {
	try {
		HttpClient httpclient = HttpClientBuilder.create().build();
		HttpGet httpGet = new HttpGet("<INPUT YOUR URL HERE>");
		
		HttpHost proxy = new HttpHost("127.0.0.1", 3128, "http");
		RequestConfig config = RequestConfig.custom()
				.setProxy(proxy)
				.build();
		httpGet.setConfig(config);
		
		HttpResponse response = httpclient.execute(httpGet);
		HttpEntity resEntity = response.getEntity();

		String responseText = EntityUtils.toString(resEntity);		
		return responseText;
	} catch (IOException e) {
		logger.error(e, e);
	} catch (Exception e) {
		logger.error(e, e);
	}
	return null;
}
Google+

[Mule] Error 400 Bad Request, Request Header Or Cookie Too Large

I had an error yersterday, when connecting Mule ESB to NGinx. Very weird, because somehow it never shown any errors when fired directly without a reverse proxy. Here is the complete stacktrace

<head><title>400 Request Header Or Cookie Too Large</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>Request Header Or Cookie Too Large</center>
<hr><center>nginx/1.4.4</center>
</body>
</html>
 (javax.xml.ws.soap.SOAPFaultException)
  org.apache.cxf.jaxws.JaxWsClientProxy:156 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/xml/ws/soap/SOAPFaultException.html)
3. Response was of unexpected text/html ContentType.  Incoming portion of HTML stream: <html>
<head><title>400 Request Header Or Cookie Too Large</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>Request Header Or Cookie Too Large</center>
<hr><center>nginx/1.4.4</center>
</body>
</html>

It happens because Mule, by default, send a very large cookies called “X-MULE_SESSION”. After removing it, my ESB runs well again. This is how i remove it,

<http:connector name="NoSessionConnector">
	    <service-overrides sessionHandler="org.mule.session.NullSessionHandler"/>
</http:connector>
Google+

Weird Error on Java Mail, “javax.mail.AuthenticationFailedException: No authentication mechansims supported by both server and client”

I run into a weird error that never happened before, somehow it happened since my user upgrade their Microsoft Mail Exchange’s version. Here is the complete stacktrace,

Caused by: javax.mail.AuthenticationFailedException: 
No authentication mechansims supported by both server and client
    at com.sun.mail.smtp.SMTPTransport.authenticate(SMTPTransport.java:760)
    at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:673)
    at javax.mail.Service.connect(Service.java:317)

I guess there are several reasons why it happens. First of all, it happens because im using starttls = “true” despite im connecting to port 25, first i change it into “false”. And the other thing is that im using username and password for connecting to my email exchange server, so the workaround is quite easy, just setting my mail.smtp.auth parameter into “false” instead of “true”. Or try sending email without setting username and password.

But actually, it’s much easier to fix the error on the mail server’s side, because it’s only a simple checklist configuration :-P

Google+