CloudFlare & Liferay

This blog entry will cover my recent experience with CloudFlare and Liferay 6.2 CE.  On my last project (wordpress) my customer had an excrutiating 30 second page-load time from South Africa.  Albeit, from the same browser CNN took 12 seconds and its my assumption that people that live far away from the datacenter will simply learn to expect latency.  The latency was caused by the word press designer's extensive use of wordpress plugins which never seem to use the same javascript file twice.  This resulted in 160 distinct trips to the server to get all of the images, styles, javascript and eventually content. 

Why CloudFlare?  The main reason is that CloudFlare acted as a proxy to the wordpress site - bringing cached content forward onto CloudFlare's servers around the world (including Africa).  Implementation of CloudFlare didn't require me to optimize the already complex/spaghetti mix of plugins and custom theme overrides.  CloudFlare acts at the DNS level routing users to the cached content nearest to them.  It also gave me the option to use https at no additional charge.  Annually, my customer will spend $240 to reach their customers quickly and securely via CloudFlare via the $20 per month plan.

How does this apply to Liferay?  I was curious how I could also apply the CDN, proxy, https benefits of cloudflare to my Liferay driven sites.  Yes, its possible - here is the write up:

Property Changes:

    # Set the application server's protocol. Lucene will use it to load the
    # index from the cluster when the hostname and port are not detected on the
    # first request. Note that this property refers to the application server's
    # protocol, and not the web server's as specified in the property
    # "web.server.protocol".
    # this tells liferay that in fact JBoss is serving the content and to bypass the 
    # apache AJP proxied server moves content between 8080 and 80.
    # Set the preferred protocol.

    # Set the HTTP and HTTPs ports when running the portal in a J2EE server that
    # is sitting behind another web server like Apache. Set the values to -1 if
    # the portal is not running behind another web server like Apache.

Note: the above change requires a servlet container restart to reload the properties.

CloudFlare settings:

When adding or editing content on the page, you want to be sure to bypass the CloudFlare cache to load content and scripts as Liferay expects it.   The setting I update was: 

CloudFlare > > Caching > Caching Level > No Query String
This resulted in the ability to drag and drop content using Liferay's Javscript tools.

CloudFlare > > Crypto > SSL > full
This resulted in https functioning between the browser and cloudflare and cloudflare and my host.

CloudFlare > > Page Rules > forward http://** to always use https
This resulted in all requests being translated to https.

Oracle's Plan for JAVA Obsolescence

I'm an avid LinkedIn reader.  That means I see who in my contacts connects with whomever.  Especially if its a former employer trying to fill my desk. I'm curious - like a guy that used to date a girl and wants to know if she really "could" do better.  Of course, thats a metaphor and not a 1:1 comparison - but you get the idea.

Today, on LinkedIn, I read an article about the "secret email" about planned obsolescence of JAVA, which is dear to my livelihood: (insider-oracle-lost-interest-in-java).  Obsolescence will happen. I guess that is a narcissistic to write, sorry to those who just learned it.  In 1999 we were all talking about how long could JAVA last - whether it was a good technology to invest your time in...  Times have changed.  Hello, server side JAVAscript...?

Yes, Larry Ellison's company bought Sun Microsystems 6-years ago for the server business and got JAVA as a bonus.  Yes, the capitalists at Oracle might not be so huggy at open source conferences...   But, what are they going to do - take the future development away?  Probably not, as taking it away would mean they intend to continue to make it better and not share [for free].  I'm a capitalist, is that so bad? I work and don't want to share unless I'm paid...

JAVA is already, still... here, and good, eh?  The libraries available to make it better come from great open source foundations (Apache), code repositories (GIT, Codehaus),  and companies "Google".  Its getting better with or without the JCP being involved [the article reported that Oracle doesn't want to be involved as much with the JCP.  Further, evangelists typically always have another job - to evanglise another product]. 

As the article goes on, there is the implied potential of fewer public upgrades...  These are cash cows for consultants, sys admins, developers and testers. But seriously, I wouldn't complain if they came out every third year.  Then companies could focus on their product, not their infrastructure.

Here you have it, my opinion on the topic: 

Dear Oracle, make BEA Weblogic better and you will make JAVA guys happy.  Dump support for Glassfish [check, already done]- you made this guy happy.  Make Weblogic open, you lose money.  Keep the standard against JBoss, WebSphere - nobody complains too much.  Oracle will not win in public opinion - no matter what they do.  My guess, they sell JAVA to Google, Redhat, IBM [who sell openness and innovation as a brand] with java.lang.Strings attached with how open it should be for a seriously undisclosed price...



Server Side JavaScript

Its become clear to me a while ago that a full understanding of how server-side javascript works is part of being an effective JAVA developer, especially a web application developer using Enterprise JAVA. This is especially true if you have been developing with Struts, Tapestry, JSF and the other frameworks that have come along since 2002. These web application frameworks were designed to shield applications from custom javascript. It was dangerous, remember? Javascript was dangerous and expensive to maintain. Not anymore. Not anymore than the web applications that were written in the past.

I remember being proud of getting my Sun JAVA Programmer Certification in 2001. It meant to me that I would be considered "more" of software engineer than a web designer.  This meant I wouldn't be required to sit in meetings with non-engineers who would debate colors, photos, and fonts. I wanted the other side of that equation – not to be there. Remember, these were the days where recruiters lined up to talk to JAVA/J2EE developers at JavaOne?

To make my point even more painfully clear, as a JSF specialist, I see a dwindling amount of jobs for one of my specialities since 2008.  People want the actual javascript - not the wrapper around it. I'm not complaining – its just a fact that if you check – you see the number of positions available and can compare with how things were in previous years – fewer JSF jobs.

Ok, enough of how things were...

What do to?  Fend for yourselves (and your families at this point). My plan has been to do the same thing I did when JSP/EJB was new.  Dive in anew! Stay up late, learn, build apps and go to the market with your new skills.  I've been in my deep dive since the beginning of this year.  Vocabulary that seemed foreign to me including npm, brew, bower, gulp and many more are now references to server side javascript installations that will make a developers life “easy”. Its either this or understand that your skillset is a widely available commodity.  There will still be projects/jobs, but they won't pay like they did 10-years ago. 

This strategic path diverges from the standard strategy of 2005 - gain experience with vendor's stack and your marketability is safe. I would say, pick a horse and make your bet. If you bet on “orion application server” you'd have lost, for instance.  I picked IBM WebSphere back then. It worked until the financial crisis of 2008. Its still relevant.  Yes, many are still relevant - but they don't get you the kind of job that they used to.  And you can't leave your vendor stack for a few years and expect to get back on it.

So, I leave it there – no answers or recommendations except to learn more about these emerging technologies. Resting on ANT, IVY and Struts is no longer an option – you must see what the market wants and adapt.


Now Available: Terms Of Use Administration for Liferay Portal

Yesterday, I recieved a notification from Liferay that my plugin "termsofuse-portlet" has passed their QA process.  Its now in the Liferay Marketplace.  This portlet permits administative users to activate terms of use; change the Localized Terms of Use web content; and reset terms of use acceptance by group, role or company.

I'm actively working on the second revision of the plugin to provide Terms of Use auditing including: tracking changes to Terms of Use and tracking user acceptance to Terms of Use.  So far, based upon Liferay Marketplace QA timing - this version should be available at end of August.

Feel free to contact me with suggestions or additional features that you need.

ben {at} javablog {dot} com


Liferay CE & JBoss EAP 6.4 Built and Deployed from sources

I found a great project to build jboss-eap from its sources.  Its not clear if that makes permits a person to run JBoss EAP 6.4.0 for instance on a production server; or permits the person to provide services related to JBoss products.  Anyway - the project is in GIT here:

I followed the readme instructions and was able to take my development EAP configurations into production within 30 minutes of downloading.  This introduces an interesting combination serving this blog: Unsupported JBoss EAP from Sources and Unsupported Liferay CE from Sources with zero licensing costs.

Liferay 6.2 CE GA4 on Wildfly 8.2


Today I configured this blog to run on JBoss Wildfly 8.2.0 Final and Liferay 6.2 ga4.  The tricky part for me was to configure https in UnderTow.  This is what I did:

In the JBOSS_HOME/standalone/configuration/standalone.xml file I did the following.

Define Security Realm for Https:

<management> <security-realms>

<security-realm name="HttpsRealm">

<server-identities> <ssl> <keystore path="tomcat.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="tomcat" key-password="password" /> </ssl> </server-identities> <authentication>

<truststore path="tomcat.keystore" relative-to="jboss.server.config.dir" keystore-password="password" /> <local default-user="$local"/>

<properties path="" relative-to="jboss.server.config.dir"/> </authentication>



Define Undertow Values for Liferay:

<subsystem xmlns="urn:jboss:domain:undertow:1.2">

  <buffer-cache name="default"/>

  <server name="default-server">

   <http-listener name="default" socket-binding="http"/>
   <https-listener name="https" socket-binding="https" security-realm="HttpsRealm" verify-client="REQUESTED" record-request-start-time="true" max-buffered-request-size="50000" resolve-peer-address="true"/>
    <host name="default-host" alias="localhost,," default-web-module="liferay.war">
     <location name="/" handler="welcome-content"/>
     <filter-ref name="server-header"/>
     <filter-ref name="x-powered-by-header"/>


<servlet-container name="default">

<filters> <response-header name="server-header" header-name="Server" header-value="WildFly/8"/> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/> </filters>

<handlers><file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/> </handlers>



— 20 Items per Page
Showing 6 results.