Migrated to GitHub Pages

This blog has been migrated to GitHub Pages. See you there:

http://labnotes.decampo.org/

Publishing to the Maven Central Repository

As an exercise in creating a Java library and submitting it to the Central Repository, I created an implementation of the xirr (irregular internal rate of return) function in Java.

If you are interested in what needs to be done to publish to the Maven Central Repository, check out the pom.xml for starters. The distributionManagement section contains configuration for pointing to the Nexus Repository Manager at oss.sonatype.org. This Nexus installation is used as a staging platform for the Central Repository.

Next in the plugins section we include the maven-source-plugin and maven-javadoc-plugin in order to generate the source and javadoc jars for the repository. Your library will not be accepted without these.

Next there is the maven-gpg-plugin for generating signature files for the artifacts. In order to generate the signature files, you will need to have a GPG key and placed the public key on a keyserver. If you don't have this already, google for some GPG tutorials. More about this in a moment.

Finally in the pom.xml we have the nexus-staging-maven-plugin plugin configuration. This plugin overrides the standard deploy plugin to interact with the Nexus Repository Manager.

Both the oss.sonatype.org and the GPG key have authentication credentials which need to be managed as part of the build process. To begin, you need to create a maven master password if you have not already done so. If you are not sure, look for the ~/.m2/settings-security.xml file to see if it has a master element. All the passwords for maven configuration can be encrypted. To generate an encrypted master password, issue the command mvn --encrypt-master-password and then place the result in your ~/.m2/settings-security.xml:

Then you need to encrypt your passwords using mvn --encrypt-password and put them in your ~/.m2/settings.xml:

Note that the first server id corresponds with the id in the distributionManagement section of the pom.xml. The second server id is used by the maven-gpg-plugin by default. Of course that can be changed by configuration, see the documentation of that plugin for details.

Finally, there is a pretty cool implementation of the xirr function in there as well. Not to mention a concise implementation of Newton-Raphson using Java 8 features.

Additional Resources:

• http://central.sonatype.org/pages/apache-maven.html
• https://oss.sonatype.org/

XSLT Utilities

Some XSLT re-usable templates for posterity:

Connect to Microsoft VPN from Fedora 24

New box, new OS, time for another edition of trying to connect to Microsoft's VPN software. This time it is Fedora's turn.

This first part is adapted from my previous editions for Ubuntu and ultimately are sourced from an Ubuntu forums post by user sweisler at http://ubuntuforums.org/showpost.php?p=8261958&postcount=6. Thanks sweisler, wherever you are.

First, there was no need to install any additional packages, apparently everything needed is included by default.

• Open VPN configuration screen:
  • Click on the network icon in the upper right of the desktop
  • Expand the VPN menu
  • Select VPN Settings
  • Select Configure VPN…
• Add a new PPTP connection
• In the Identity section, set the following:
  • Connection name (whatever you want)
  • Gateway (this is the VPN server)
  • User name (for domain-based user accounts, use domain\username or username)
  • Do not set Password; do change the pulldown (hidden in the help icon) to Always Ask
  • Set NT Domain if it is a domain-based account and you feel like it (I tried with User name as plain username and no NT Domain set, with User name as domain\username and no NT Domain and with User name as plain username and NT Domain set and everything worked - a far cry from when I was first trying to connect years ago).
• PPTP Advanced Options (Advanced button from the Identity section)
  • Uncheck all authentication methods except MSCHAPv2
  • Check Use Point-to-Point encryption (MPPE)
  • Leave Security set at All Available (Default)
  • Check Allow stateful inspection
  • Uncheck Allow BSD data compression
  • Uncheck Allow Deflate data compression
  • Uncheck Use TCP header compression
  • Uncheck Send PPP echo packets (this setting works either way, check it for debugging purposes)
  • Leave Use custom unit number unchecked.

Normally at this point we would save and test the connection, but for Fedora there are additional steps. We need to configure the firewall to allow connections on the GRE protocol.

Note that GRE is a protocol like TCP or UDP, not a particular port.

The Fedora firewall demon allows you to make changes in two modes: permanent changes which affect the configuration but not the running instance and temporary changes which affect the running instance but not the configuration. To enable GRE traffic through your firewall, use the following command:

sudo firewall-cmd --add-protocol=gre sudo firewall-cmd --query-protocol=gre

Now test out your VPN connection. If it is working, save the changes to the configuration of the firewall:

sudo firewall-cmd --permanent --add-protocol=gre sudo firewall-cmd --permanent --query-protocol=gre

Note that if you have multiple network connections (e.g. wireless vs wired), it may be necessary to configure the firewall for each one.

Once the VPN connection is working you may want to try to tweak it further as described below.

One problem with the VPN I connect to is that all traffic ends up using the VPN when I am connected. This is less than ideal if you are connecting to servers on the internet while the VPN is connected since the traffic goes through the VPN server before coming to you. The following describes the settings for routing only the proper traffic to the VPN. (Read them all the way through first to make sure you have all the necessary information.)

Start by opening the IPv4 Settings section in the configuration of your VPN.

• Set Additional DNS servers using the IP address of the DNS server for the VPN. (You may need to ask your IT guy for this; there should be a way to discover it when connecting as above but it escapes me.)
• In the Routes section, add a new route:
  • For Address, use the internal IP address of the VPN server applied against the netmask below, e.g. if the VPN server is 10.23.34.89 and the netmask is 255.255.255.0, use 10.23.34.0. Again, this should be the internal IP address for getting to the machine in the intranet, not the external IP address for getting to the machine from the internet.
  • For Netmask, use the netmask of your intranet. (If you are confused, ask your IT guy what to use for both this and the Address.) For most networks this will be 255.255.255.0, but for many it will be different.
  • For Gateway, use 0.0.0.0.
  • Do not set the Metric unless you know what you are doing.
• If necessary, add additional routes. E.g. you might have a DMZ in the 10.0.0.0/24 network in the VPN you are connecting to.
• Check Use this connection only for resources on its network
• In other versions of the NetworkManager configuration tool, there was a field for Additional search domains. This field is missing on Fedora 24 and some experimenting and testing seems to indicate we don't need it.

OK, so now when you connect you should see regular traffic going directly to the internet and intranet traffic directed to the VPN server. You can test this out with traceroute (which you may need to install).

Let me know how these instructions work for you and what type of systems you’ve been able to connect.

Dipping my toes into the Node.js ecosystem

Just to get my feet wet, I published a Node.js module called xirr.

When I was writing the unit tests for the module I had a particular case where the Newton's method implementation was not converging and the library I was using returned false. My son, who has done a bit of coding was shoulder surfing and was asking me what we needed to do to make the the value be true. When I explained that we actually wanted the library to return a number instead his head practically exploded. So I went into the difference between a statically typed and dynamically typed language and he asked "Why don't you just change it to statically typed?"

So, how about EmcsScript committee? Up for making ES7 a statically typed language?

Connect to Microsoft VPN from Ubuntu 16.04 Xenial Xerus

I recently upgraded from Ubuntu 14.04 on my main desktop machine and discovered that my VPN connection to Windows 2008 Server no longer worked. The bugaboo turned out to be the routing table which no longer requires a gateway entry. Here I have rewritten my post originally written for 12.10 to reflect the new configuration.

If you have ever tried to configure a linux machine to connect to a Microsoft-based VPN, you know that it is not as straightforward as it could be. It is more of a voodoo ritual than a science. I figured it would be a good idea to capture the steps for future reference.

This first part is adapted from the Ubuntu Wiki for posterity. You can check out the original at https://wiki.ubuntu.com/VPN under the heading VPN setup in Ubuntu 9.10. Apparently this originates from a Ubuntu forums post by user sweisler at http://ubuntuforums.org/showpost.php?p=8261958&postcount=6. Thanks sweisler, wherever you are.

First, there was no need to install any additional packages, apparently everything needed is included by default.

• Open VPN configuration screen:
  • Click on the network icon in the upper right of the desktop
  • Go to the VPN Connections menu
  • Select Configure VPN…
• Add a new PPTP connection
• On the VPN tab, set the following:
  • Connection name (whatever you want)
  • Gateway (this is the VPN server)
  • User name (for domain-based user accounts, use domain\username)
  • Do not set Password; do change the pulldown to Always Ask
  • Do not set NT Domain
• PPTP Advanced Options (Advanced button from the VPN tab)
  • Uncheck all authentication methods except MSCHAPv2
  • Check Use Point-to-Point encryption (MPPE)
  • Leave Security set at All Available (Default)
  • Check Allow stateful inspection
  • Uncheck Allow BSD data compression
  • Uncheck Allow Deflate data compression
  • Uncheck Use TCP header compression
  • Uncheck Send PPP echo packets (this setting works either way, check it for debugging purposes)

At this point save it and test it. Once the VPN connection is working you may want to try to tweak it further as described below.

One problem with the VPN I connect to is that all traffic ends up using the VPN when I am connected. This is less than ideal if you are connecting to servers on the internet while the VPN is connected since the traffic goes through the VPN server before coming to you. The following describes the settings for routing only the proper traffic to the VPN. (Read them all the way through first to make sure you have all the necessary information.)

• On the IPv4 Settings tab
  • Set Additional DNS servers using the IP address of the DNS server for the VPN. (You may need to ask your IT guy for this; there should be a way to discover it when connecting as above but it escapes me.)
  • Set Additional search domains. Set this to the domain suffix of the machines on the VPN. For example, if the machines are named like dbserver.example.com then set it to example.com.
• Click the Routes button.
  • Check Use this connection only for resources on its network
  • Add a route:
    • For Address, use the internal IP address of the VPN server applied against the netmask below, e.g. if the VPN server is 10.23.34.89 and the netmask is 255.255.255.0, use 10.23.34.0. Again, this should be the internal IP address for getting to the machine in the intranet, not the external IP address for getting to the machine from the internet.
    • For Netmask, use the netmask of your intranet. (If you are confused, ask your IT guy what to use for both this and the Address.) For most networks this will be 255.255.255.0, but for many it will be different.
    • For Gateway, use 0.0.0.0 or simply leave it blank.
    • Do not set the Metric unless you know what you are doing.

OK, so now when you connect you should see regular traffic going directly to the internet and intranet traffic directed to the VPN server. You can test this out with traceroute (which you may need to install). You should also be able to refer to machines on the intranet using their short names (e.g. dbserver instead of dbserver.example.com).

Let me know how these instructions work for you and what type of systems you’ve been able to connect.

Complicated String Joins

So if you have not been under a rock and have used Java 8, you are surely aware of the new String.join() method and the Collectors.joining() method to concatenate arrays or streams of Strings. Sometimes however, a simple concatenation with a delimiter is not quite up to the job.

Consider the following method for example:

Here our plans for a simple invocation of Collectors.joining() is complicated by the intermediate String literals and the particular format desired for the string representation of the entry.

At first blush you might attempt to change this to functional style using something like this:

If you are an old salt at Java however, I'm sure your hair is standing on end considering all those temporary String objects being created. Fortunately, using Stream.of() and Stream.flatMap() there is another way:

If you want to play around with this code, it is available on GitHub at StringJoin.java

Creating a custom Collector

Creating a custom implementation of java.stream.Collector seems daunting at first, but once you give it a try, you'll see that it can actually be pretty easy.

If you are not used to using lambdas and functional concepts, your first look at the Collector interface will be intimidating. From a pre-Java 8 perspective, there are four interfaces to implement to create a custom Collector implementation: java.util.function.BiConsumer, java.util.function.BinaryOperator, java.util.function.Function and java.util.function.Supplier. Fortunately they are all functional interfaces which will allow us to take some shortcuts with lambdas and functional expressions.

The example I chose to implement is a Collector for SetValuedMap from Apache's Common Collections project. We'd like a static method similar to the standard Collectors.toMap() method which will generate a Collector instance yielding a SetValuedMap implementation.

There are a lot of moving parts to the Collector in terms of generics. First, we will have generic parameters for the type in the existing stream <T>, the type of the key in the map <K> and the type of the values in the map <V>. Then we need to identify the three generic parameters to the Collector interface: <T> is the same as before, the type of objects in the stream; <A>, the accumulation type will be SetValuedMap<K,V>; and <R>, the result type, will also be SetValuedMap<K,V>. It is frequently the case with Collectors that <A> and <R> are the same.

Now that we have our generic ducks in a row, we can start figuring out our Collector implementation. For the supplier, we can use a constructor of a SetValuedMap implementation, e.g. HashSetValuedHashMap::new.

The accumulator will be a lambda function taking in a map and a stream object, it will need to put the stream object in the map. For that we will need to pass in functions converting the stream objects to keys and values respectively (just like in Collectors.toMap()).

The combiner will need to accept two maps and return a map containing entries from both. Again this can be specified with a lambda function.

We don't need anything beyond the identity function for the finisher, which means we ready to create our Collector implementation using the Collector.of() factory method:

This method can be used to create a version of Collectors.groupingBy() which eliminates duplicates simply by passing Function.identity for the valueMapper:

If we wanted to get really fancy we could also pass in a Comparator to use with our set, but I will leave that as an exercise for the reader.

See the file MoreCollectorsTest.java for some examples of these methods in action.

JSF EL Implicit Object Reference

Just collecting the implicit objects defined by the JSF 2.2 specification (section 5.6.2.1, table 5-11) which are available in the EL:

application

externalContext.getContext()

applicationScope

externalContext.getApplicationMap()

cookie

externalContext.getRequestCookieMap()

facesContext

the FacesContext for this request

component

the top of the stack of UIComponent instances, as pushed via calls to UIComponent.pushComponentToEL(). See Section 3.1.14 “Lifecycle Management Methods”

flowScope

facesContext.getApplication().getFlowHandler().getCurrentFlowScope()

cc

the current composite component relative to the declaring page in which the expression appears.

flash

externalContext.getFlash()

header

externalContext.getRequestHeaderMap()

headerValues

externalContext.getRequestHeaderValuesMap()

initParam

externalContext.getInitParameterMap()

param

externalContext.getRequestParameterMap()

paramValues

externalContext.getRequestParameterValuesMap()

request

externalContext.getRequest()

requestScope

externalContext.getRequestMap()

resource

facesContext.getApplication().getResourceHandler()

session

externalContext.getSession()

sessionScope

externalContext.getSessionMap()

view

facesContext.getViewRoot()

viewScope

facesContext.getViewRoot().getViewMap()

resource

facesContext.getApplication().getResourceHandler()

jQuery UI Initialization Issues

Every once in a while when using jQuery UI I notice that my widget is not being initialized smoothly. For example, when using the menu widget I might see the list items behind the menu briefly. Then the page jumps around and it is a generally unpleasant experience for the user. Who likes it when your jQuery widgets are jumpy and cause the page to feel like one of those old 'punch the monkey' banner ads?

This usually means I have done something like this:

require(['jquery', 'jquery-ui/menu'], function($, menu) { $("#navmenu").menu(); });

Instead of wrapping the initialization in a function as I should:

require(['jquery', 'jquery-ui/menu'], function($, menu) { $(function() { $("#navmenu").menu(); }); });

JSF: Add Conversation ID to a link or button

To add the conversation ID parameter cid to a h:link or h:button:

<h:button value="Go" outcome="go"> <f:param name="cid" value="#{javax.enterprise.context.conversation.id}" /> </h:button>

Retain sessions in WildFly 8

Add the persistent-sessions element to your WildFly configuration to keep sessions persistent across redeployments and restarts:

<servlet-container name="default"> <jsp-config/> <persistent-sessions /> <websockets/> </servlet-container>

See https://docs.jboss.org/author/display/WFLY8/Undertow+%28web%29+subsystem+configuration for more information.

WildFly 8.2.0 and Java 8 on CentOS 6.6

This post documents how to install and configure WildFly 8.2.0 on CentOS 6.6. We make some changes to move some of the configuration under /etc and also place log files under /var/log and temp files under /tmp just like a well-behaved POSIX application should.

We’ll start by installing Java; download your desired version as an RPM from Oracle and install:

[root@wxyz ~]# rpm -ivh jdk-8u25-linux-x64.rpm

This installs the JDK in /usr/java/jdk1.8.0_25. There is no need to make this the default java used by the system, we'll just configure WildFly to use it.

Next we create a wildfly user on the server to build and run WildFly as:

[root@wxyz ~]# useradd --system \ --comment "WildFly Application Server" \ --create-home --home /opt/wildfly \ --user-group wildfly

I assume you already have the WildFly tarball downloaded and ready to go:

[wildfly@wxyz ~]$ tar zxvf wildfly-8.2.0.Final.tar.gz

Now that we have WildFly on the system, we need to configure CentOS to treat it like a service. WildFly comes with some scripts in the bin/init.d directory that will help with this. I am using the standalone server, but it is not difficult to modify the instructions for the domain server. First up is the /etc/wildfly/wildfly.conf file.

[root@wxyz ~]# cd /etc [root@wxyz etc]# mkdir wildfly [root@wxyz etc]# cd wildfly/ [root@wxyz wildfly]# cp /opt/wildfly/wildfly-8.2.0.Final/bin/init.d/wildfly.conf ./ [root@wxyz wildfly]# # We'll just create an empty properties file for now [root@wxyz wildfly]# touch wildfly.properties

Next edit the file. We need to define a few environment variables, I am only including the ones I've changed:

# General configuration for the init.d scripts, # not necessarily for JBoss AS itself. # default location: /etc/default/wildfly ## Location of JDK JAVA_HOME=/usr/java/jdk1.8.0_25 ## Location of WildFly JBOSS_HOME=/opt/wildfly/wildfly-8.2.0.Final ## The username who should own the process. JBOSS_USER=wildfly ## Configuration for standalone mode JBOSS_CONFIG=standalone-full.xml ## Location to keep the console log JBOSS_CONSOLE_LOG="/var/log/wildfly/console.log" # Need to modify the init script to account for JBOSS_OPTS # Allows us to pass system properties to WildFly JBOSS_OPTS="--properties=/etc/wildfly/wildfly.properties"

Next up we will deposit the init script in /etc/init.d and set the server to start on boot:

[root@wxyz wildfly]# cd /etc/ini t.d/ [root@wxyz init.d]# cp /opt/wildfly/wildfly-8.2.0.Final/bin/init.d/wildfly-init-redhat.sh ./wildfly [root@wxyz init.d]# chkconfig --add wildfly [root@wxyz init.d]# chkconfig --level 345 wildfly on [root@wxyz init.d]# chkconfig --list wildfly wildfly 0:off 1:off 2:off 3:on 4:on 5:on 6:off

You will need to edit the wildfly script in two places; first, to change the default location of the wildfly.conf file from /etc/default/wildfly.conf, starting at line 19:

# Load JBoss AS init.d configuration. if [ -z "$JBOSS_CONF" ]; then JBOSS_CONF="/etc/wildfly/wildfly.conf" fi

As-is the scripts do not allow passing any additional options to the WildFly process, so we need to edit the /etc/init.d/wildfly script to add the $JBOSS_OPTS variable whenever WildFly is starting. Here is the edited snippet for the standalone configuration (I’ve added some line breaks for readability) starting from line 104:

if [ ! -z "$JBOSS_USER" ]; then if [ "$JBOSS_MODE" = "standalone" ]; then if [ -r /etc/rc.d/init.d/functions ]; then daemon --user $JBOSS_USER LAUNCH_JBOSS_IN_BACKGROUND=1 \ JBOSS_PIDFILE=$JBOSS_PIDFILE $JBOSS_SCRIPT -c $JBOSS_CONFIG \ $JBOSS_OPTS 2>&1 > $JBOSS_CONSOLE_LOG & else su - $JBOSS_USER -c "LAUNCH_JBOSS_IN_BACKGROUND=1 \ JBOSS_PIDFILE=$JBOSS_PIDFILE $JBOSS_SCRIPT -c $JBOSS_CONFIG \ $JBOSS_OPTS" 2>&1 > $JBOSS_CONSOLE_LOG & fi else

Next up we create the log directories and redirect the JBoss log directory to /var/log/wildfly and the tmp directory to /tmp/wildfly

[root@wxyz ~]# mkdir /var/log/wildfly [root@wxyz ~]# chown wildfly:wildfly /var/log/wildfly/

To get WildFly to use these directories, we set the system properties for them in /etc/wildfly/wildfly.properties:

# System properties for wildfly jboss.server.log.dir=/var/log/wildfly jboss.server.temp.dir=/tmp/wildfly

At this point you can start the server using the command service wildfly start. You won’t be able to do much however, unless you like browsing via wget since the server is bound to the localhost interface only (and we are working on a headless server, i.e. no GUI web browser). So we’ll need to bind WildFly to all interfaces and open up the CentOS firewall to allow browsing to WildFly and the management console. Keep in mind that this may not be exactly what you want in a production environment or in environment where unknown users might access your server (like shared hosting).

First we’ll edit the /etc/wildfly/wildfly.properties file:

# System properties for wildfly jboss.bind.address=0.0.0.0 jboss.bind.address.management=0.0.0.0 jboss.server.log.dir=/var/log/wildfly jboss.server.temp.dir=/tmp/wildfly

Depending on how your local network is setup you may need further configuration for WildFly to be completely happy binding to all interfaces. If your DNS recognizes the name of the CentOS server you are working on, congratulations, you are all set. On the other hand, if DNS is not configured for the server, you will need to add an entry to the /etc/hosts file pointing the name of the server to the external IP.

Next we need to open the firewall for ports 8080 (regular WildFly) and 9990 (the management console). Be careful when adjusting the firewall. The commands below use hard-coded line numbers that may not be appropriate for whatever system you are using. If you think you have screwed up your firewall use service iptables restart to reset it. Of course, this won’t work after you issue service iptables save so be extra sure before you save the rules. You will also need to replace 10.0.0.0 with your subnet below.

[root@wxyz ~]# # 8080 for WildFly applications [root@wxyz ~]# iptables --insert INPUT 5 \ --match state \ --state NEW \ --protocol tcp \ --destination-port 8080 \ --source 10.0.0.0/24 \ --jump ACCEPT [root@wxyz ~]# # 9990 for WildFly management [root@wxyz ~]# iptables --insert INPUT 6 \ --match state \ --state NEW \ --protocol tcp \ --destination-port 9990 \ --source 10.0.0.0/24 \ --jump ACCEPT [root@wxyz ~]# # Verify the state of the firewall [root@wxyz ~]# iptables -L --line-numbers [root@wxyz ~]# # Go and test it out before doing the following [root@wxyz ~]# service iptables save

At this point you should be ready to go. Start up WildFly and try accessing it from your desktop.

Network issues with CentOS 6.x under Hyper-V

I had a number of CentOS instances running under Hyper-V using the standard virtual network interface via integration services. Post CentOS 6.3 integration services are included in the install and that has been my experience. However at some point after updating to 6.6, something causes the integration services to no longer work with the virtual network interface.

To fix, remove the Network Adapter from the Hyper-V configuration and replace it with a Legacy Network Adapter.

Now you need to boot the virtual machine and access it from the Hyper-V console in order to log in. Backup the file /etc/udev/rules/70.persisent-net.rules and remove it from the /etc/udev/rules directory. This file tells CentOS to look for the old network interface and assign it to eth0.

Second, backup the /etc/sysconfig/network-scripts/ifcfg-eth0 file. Edit the file and remove any reference to UUID or HWADDR.

JSF 2.2 Welcome File

Just a quick post in case you are trying to use a JSF page as a welcome file. This is what you'll need in your web.xml:

<servlet> <servlet-name>Faces Servlet</servlet-name> <servlet-class> javax.faces.webapp.FacesServlet </servlet-class> </servlet> <servlet-mapping> <servlet-name>Faces Servlet</servlet-name> <url-pattern>*.xhtml</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.xhtml</welcome-file> </welcome-file-list>

Could not find backup for factory javax.faces.context.FacesContextFactory

Recently I was porting a JEE application’s development environment from an outdated version of IDEA to Maven and NetBeans. After some effort I got the two builds to yeild pretty much the same EAR files.

The next step was to connect JBoss (version 7.1.1.Final in this case) to the project and begin development. However when I deployed the EAR to JBoss using NetBeans. I got the following error:

13:32:42,744 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/sc]] (MSC service thread 1-14) 
  StandardWrapper.Throwable: java.lang.IllegalStateException: Could not find backup for factory javax.faces.context.FacesContextFactory.
        at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1008) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
        at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:343) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
        at javax.faces.webapp.FacesServlet.init(FacesServlet.java:302) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
        at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.13.Final.jar:]
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102) [jbossweb-7.0.13.Final.jar:]
        at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655) [jbossweb-7.0.13.Final.jar:]
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873) [jbossweb-7.0.13.Final.jar:]
        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]

Needless to say, that was unexpected. Now the common answer from Google on this error is that there are multiple copies of JSF confusing the issue. That did not jibe with my situation as I do not pack JSF with this application.

The first thing I tried was to make sure the entire tool chain was using JDK 7. NetBeans had been compiling with JDK 8 so it seemed possible this was causing a class loading conflict. But this failed to alleviate the issue.

The next thing I tried was taking the exploded EAR file from the Maven target directory and deploying it by hand. No problems when deploying that way.

Some more investigation revealed that NetBeans was deploying the EAR archive, not the exploded directory. When I deployed the archive manually, I reproduced the error. At least I had eliminated NetBeans as a potential source of blame.

When investigating the differences between the exploded EAR directory and the EAR archive I discovered that what you see is not what you get with Maven. I think the issue is that the various Maven plugins for WAR and EAR building are not applied when creating the exploded directories.

So to eliminate these differences I took the Maven EAR archive and extracted it in the JBoss deployments directory and deployed it by hand. To my surprise there was no error.

So there seemed to be a difference between deploying the application as an EAR archive vs an EAR directory. I had one final arrow left in my quiver: I would try deploying the EAR archive as produced by the previous build process.

That EAR archive worked like a champ. Now I needed to figure out the difference between the two archives. The contents were essentially the same but one difference stood out: the WAR and EJB jar files in the working archive were archives themselves, whereas they were exploded in the broken EAR archive.

That was easy enough to fix: just remove the <unpack> directives from the POM for the EAR. Now a I had deployments working from within NetBeans.

TL;DR: Don’t use exploded WARs inside of an unexploded EAR archive.

SELinux and ssh

I've had this one as a draft post for a while and I just ran into the it again, so it's time to to publish it.

I had a Linux server setup that I was getting a new developer to connect to. Whatever we tried, we could not get him logged in via ssh using keys. I verified the home directory permissions (at most 755), the .ssh directory permissions (700), the permissions of the files in the .ssh directory (600). Other users could connect to the server using keys. The developer could use the same client to connect to other ssh servers using keys.

Finally it occurred to me to check the SELinux context on the .ssh directory; it was missing the ssh_home_t context. The repair is simple: restorecon -r -vv .ssh

If you don't trust restorecon or you are just looking for an alternate fix, you can delete the .ssh directory and have the user connect to another ssh server from the target machine. This will build the .ssh directory on the target server when the known_hosts file is created.

Reusing JavaScript Modules in Liferay 6.2

Liferay is a JSR-286 compliant portal server that runs on a variety of different application servers. Previously I have explained how to get Liferay working with JBoss 7.2.0.

Today I would like to focus on getting an example portlet working with Liferay which uses a custom JavaScript module, similar to what we did with the GateIn portal server earlier. Since developing that example I have learned that ninjas are not always well-behaved, so we will stick to some home-grown JavaScript. We will use JavaScript to place a quote on the screen when the user clicks on a certain area of the portlet.

First things first: Liferay does a fair amount of caching for performance reasons. We will need to deactivate the caching otherwise there will be a great deal of pulling of hair and gnashing of teeth while you wonder why your newly deployed JavaScript changes have not made it to the browser. Fortunately Liferay makes this easy by allowing you to pass the flag -Dexternal-properties=portal-developer.properties to the application server on start-up. This incorporates the properties in the /WEB-INF/classes/portal-developer.properties file from the Liferay WAR into the Liferay system properties. If, for whatever reason you require more fine-grained control, you can manipulate the same properties by placing them in your portal-ext.properties file in your Liferay home directory (typically one directory above your application server home directory).

Now that we have an environment conducive to peaceful code development, we can begin. Liferay incorporates the AlloyUI JavaScript library, which is based on the YUI library from Yahoo (specifically the 3.x series sometimes referred to as YUI3, particularly when using a search engine). AlloyUI inherits the module model from YUI and that gives us a nice scaffold to organize our JavaScript.

Unlike GateIn however, Liferay is not "module-aware". That is, we cannot declare our modules and then declare which modules a particular portlet is dependent on. So we’ll need to work around that by placing our modules in a Liferay hooks. Hooks allow us to extend or override core features of Liferay without needing to change Liferay’s source. In our case we will simply use the hook functionality to include our module’s JavaScript in the portal template.

The easy way to get started with a Liferay hook is to use the Liferay IDE, a set of extensions for Eclipse. But I have never been a big fan of Eclipse and I am a big fan of doing things manually at least once for better understanding. So I’ll explain how to do the "hard" way (which really isn’t all that bad anyway.

Create a WAR project (using your favorite method) to hold the hook. Add a /WEB-INF/web.xml file with an empty <web-app> tag:

<?xml version="1.0" encoding="UTF-8"?> <web-app version="3.0" metadata-complete="true" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"> </web-app>

Next we’ll need a /WEB-INF/liferay-hook.xml file telling Liferay where to find our JSP extensions. Liferay has documentation for this file and their other XML configuration files at http://docs.liferay.com/portal/6.2/definitions/. Here is the content of our /WEB-INF/liferay-hook.xml file:

<?xml version="1.0"?> <!DOCTYPE hook PUBLIC "-//Liferay//DTD Hook 6.2.0//EN" "http://www.liferay.com/dtd/liferay-hook_6_2_0.dtd"> <hook> <custom-jsp-dir>/WEB-INF/jsp</custom-jsp-dir> </hook>

Now we need to create the JSP extension file which Liferay will append to the standard JSP. Create /WEB-INF/jsp/html/common/themes/top_js-ext.jspf:

<script type="text/javascript" src="/js/quotify.js"></script> <script type="text/javascript" src="https://www.google.com/jsapi"></script>

The first line is for a JavaScript file we will include in the WAR we created. The second line is an example of including a third-party JavaScript library which is hosted elsewhere.

Finally we will add our YUI JavaScript module source in /WEB-INF/jsp/js/quotify.js:

YUI().add('com.example.quotify', function(Y) { Y.namespace('com.example'); Y.com.example.quotify = { quotes : [ "If at first you don't succeed... so much for sky-diving. -Henny Youngman", "I intend to live forever. So far, so good. -Steven Wright", "A day without sunshine is like, you know, night. -Steve Martin", "Get your facts first, then you can distort them as you please. -Mark Twain"], fontSizes: ['300%', '400%', '400%', '600%'], colors: ['black', 'black', 'blue', 'darkblue', 'darkgreen', 'darkred'], fontStyles: [ 'normal', 'italic', 'normal', 'oblique' ], fontVariants: [ 'normal', 'normal', 'normal', 'small-caps' ], fontWeights: [ 'normal', 'bold', 'bold', 'bolder', 'bolder' ], fonts: [ 'serif', 'sans-serif', 'cursive', 'monospace' ], random : function(array) { return array[Math.floor(Math.random()*array.length)]; }, add : function(x, y) { var quote = this.random(this.quotes); var style = "position:absolute; left:50px; top:" + (y-50) + "px;" + "line-height:1.1em; background-color:rgba(128,128,128,.35);" + "z-index:9999; width:75%; border-radius:.3em; padding: 20px;"; var div = Y.Node.create('<div style="' + style + '"></div>'); div.setStyle('fontSize', this.random(this.fontSizes)); var bodyNode = Y.one(document.body); bodyNode.append(div); var me = this; var data = { words: quote.split(' ').reverse(), append: function() { var span = Y.Node.create("<span>" + Y.Escape.html(this.words.pop()) + " </span>"); span.setStyle('color', me.random(me.colors)); span.setStyle('fontFamily', me.random(me.fonts)); span.setStyle('fontVariant', me.random(me.fontVariants)); span.setStyle('fontWeight', me.random(me.fontWeights)); div.append(span); // Let's try to give the quote presentation the cadence of Capt. Kirk var f = [Math.floor(2*Math.random()), Math.floor(2*Math.random())]; var r = [300*Math.random(), 200*Math.random(), 1000]; var when = Math.floor(r[0] + f[0]*(r[1] + f[1]*r[2])); if (this.words.length > 0) { Y.later(when, this, 'append'); } } }; data.append(); Y.later(30*1000, this, function(){bodyNode.removeChild(div)}); }, quotesOnClick : function (node) { var quotify = this; node.on('click', function(e) { quotify.add(e.pageX, e.pageY); e.preventDefault(); // Stop the event's default behavior e.stopPropagation(); // Stop the event from bubbling up }); } }; }, '1.0', { requires: ['node', 'escape', 'yui-later', 'event'] });

A quick primer in case you are not familiar with YUI module system: the module is defined using the YUI.add() function (an instance of YUI is obtained via the global YUI() function). The first argument gives the module name, here we have used com.example.quotify. The second argument is a function that will only be invoked when the module is required. The next argument is an unused version number for the module, then finally an array of modules the new module depends on. Within the module definition function, you are expected to set a property on the passed YUI instance containing your module. Since we are using a multilevel namespace, we use the YUI.namespace() function to ensure it exists. Then we can set the Y.com.example.quotify property. We will get to using the module soon.

That is everything we need for the Liferay hook. Of course, hooks in Liferay provide a great deal more functionality then what we have used here, but this post is going to be long enough as it is. Package your WAR and place it in the Liferay deploy directory.

Now we are ready to create our portlet. Start a new WAR project. Let’s begin with the JavaScript for the portlet which will give a chance to see how to use YUI modules. Create a file named js/portlet.js:

YUI().use(['com.example.quotify', 'node', 'event'], function(Y) { Y.on('domready', function() { Y.all('.quoteme').each(function(node, index, list) { Y.com.example.quotify.quotesOnClick(node); }); }); });

In order to use a YUI module, we invoke the YUI.use() function. The first argument is an array of module names we would like to use. The second argument is a function accepting a YUI instance. The YUI system will pass a YUI instance that has had the requested modules initialized. This instance will be distinct to this YUI.use() invocation; if YUI.use() is used a second time to utilize the module that use will get a distinct instance of Y.com.example.quotify. (The word use now has no meaning to me after that paragraph. I’ll try not to u— include it again.)

Next we tell Liferay to insert a reference to our JavaScript file in the header for any page containing our portlet. This is done in the /WEB-INF/liferay-portlet.xml file:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE liferay-portlet-app PUBLIC "-//Liferay//DTD Portlet Application 6.2.0//EN" "http://www.liferay.com/dtd/liferay-portlet-app_6_2_0.dtd"> <liferay-portlet-app> <portlet> <!-- TODO: Use the name of your portlet from the portlet.xml here --> <portlet-name>name of your portlet from portlet.xml</portlet-name> <instanceable>true</instanceable> <header-portlet-javascript>/js/portlet.js</header-portlet-javascript> </portlet> </liferay-portlet-app>

Here we reference our JavaScript file in the <header-portlet-javascript> tag. The <instanceable> tag indicates to Liferay whether the portlet may be included on the page once (false) or many times (true). You may need to adjust it depending on whatever portlet you decided to turn into Frankenstein’s monster by sewing my quotify module onto it.

Next make sure that your portlet output has some <span> or <div> tags with the quoteme class defined, e.g. <span class="quoteme">I’m just some innocent text</span>. The Y.on(domready,…) idiom executes the function body when the DOM is available; at that point onclick handlers are added to every DOM element with the quoteme class defined.

In summary, Liferay’s support for JavaScript modules, while not as integrated as GateIn’s, is quite serviceable. Liferay supports multiple hooks on a single server, so you can have a separate hook for each JavaScript module if you want and you can easily distribute your modules to third parties as well.

One advantage of GateIn’s approach over the approach above is that GateIn can dynamically include the necessary JavaScript files on the page on demand and omit the unnecessary. However, given the extensibility of the Liferay portal, it is not hard to imagine implementing hooks or extensions it to handle modules the same way. One would need to hook into the deployment event to scan and register the modules and then include the right <script> tags on render.

Liferay 6.2 Portal on JBoss 7.2.0

Liferay is a JSR-286 (also known as Portal 2.0) compliant portal (and a whole lot more). Since I am in the market for a portal server for an upcoming project, I figured I needed to check Liferay out. The folks at Liferay have bundled version 6.2 with a number of different open-source application servers, including JBoss 7.1.1, but what fun would it be to simply download a bundle? Liferay is also available as a war download for deployment on existing (and closed-source) application servers. So let’s see if we can get Liferay running on the JBoss 7.2.0 server we built previously.

We will need the Liferay war (liferay-portal-6.2.0-ce-ga1-20131101192857659.war) and the Liferay dependencies package (liferay-portal-dependencies-6.2.0-ce-ga1-20131101192857659.zip) available from the Additional Files tab on the Liferay download page. I will be using a PostgreSQL database as well, so I’ll need the PostgreSQL JDBC driver (postgresql-9.3-1100.jdbc4.jar) as well. Feel free to substitute the driver for your favorite DBMS.

First, Liferay will be using the directory above the JBoss installation as a installation directory, so let’s create that directory and extract JBoss:

$ mkdir liferay $ cd liferay $ unzip -q ../jboss-as-7.2.0.Final.zip

Liferay requires that you install the dependencies at the application server level; for JBoss that means creating a module for Liferay. The Liferay installation instructions bundle the JDBC driver with the Liferay module. That feels wrong to me, so we’ll create a separate module for the JDBC driver. In this case I am using PostgreSQL, but this can easily be adapted for any driver.

$ cd jboss-as-7.2.0.Final/modules $ mkdir -p org/postgresql/main $ cp ../../../postgresql-9.3-1100.jdbc4.jar org/postgresql/main/ $ mkdir -p com/liferay/portal/main $ cd com/liferay/portal/main $ unzip -q \ ../../../../../../../liferay-portal-dependencies-6.2.0-ce-ga1-20131101192857659.zip $ mv liferay-portal-dependencies-6.2.0-ce-ga1/* ./ $ rmdir liferay-portal-dependencies-6.2.0-ce-ga1 $ cd ../../../../../..

Next you’ll need to create the two module.xml files. First, for PostgreSQL create the file jboss-as-7.2.0.Final/modules/org/postgresql/main/module.xml with contents:

<?xml version="1.0"?> <module xmlns="urn:jboss:module:1.0" name="org.postgresql"> <resources> <resource-root path="postgresql-9.3-1100.jdbc4.jar" /> </resources> <dependencies> <module name="javax.api" /> <module name="javax.transaction.api" /> </dependencies> </module>

Next for the Liferay module, note that we will be adding a dependency on the PostgreSQL module. The file is jboss-as-7.2.0.Final/modules/com/liferay/portal/main/module.xml:

<?xml version="1.0"?> <module xmlns="urn:jboss:module:1.0" name="com.liferay.portal"> <resources> <resource-root path="hsql.jar" /> <resource-root path="portal-service.jar" /> <resource-root path="portlet.jar" /> </resources> <dependencies> <module name="javax.api" /> <module name="javax.mail.api" /> <module name="javax.servlet.api" /> <module name="javax.servlet.jsp.api" /> <module name="javax.transaction.api" /> <module name="org.postgresql" /> </dependencies> </module>

While we are mucking around with the modules, it seems like a good time to make the Liferay-recommended changes to the system modules of JBoss. Open up jboss-as-7.2.0.Final/modules/system/layers/base/sun/jdk/main/module.xml and add the following <path> tags under the existing <paths> tag:

<path name="com/sun/crypto" /> <path name="com/sun/org/apache/xml/internal/resolver" /> <path name="com/sun/org/apache/xml/internal/resolver/tools" />

The Liferay documentation at this point indicates there are some steps to do to work around JBPAPP6-932. However, that bug only affects environments using the IBM JDK, which I am not planning on doing. Further, I am using JBoss 7.2.0 and the patch is for 7.1.x; it is not clear if the bug exists in 7.2.0 or if the patch is appropriate for 7.2.0. The upshot is I am skipping that step but you may want to consider if you need it.

Next up are some edits to the JBoss configuration file, standalone-full.xml. (I typically configure my servers to use standalone-full.xml instead of just standalone.xml, YMMV.) We’ll start by adding some system properties following the <extensions> tag:

<system-properties> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/> </system-properties>

We also need a to set a timeout for the deployment scanner by adding the deployment-timeout attribute to the existing deployment-scanner tag:

<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1"> <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" deployment-timeout="240"/> </subsystem>

Next we need to configure the Liferay login system. Add a <security-domain> tag to the existing <security-domains> tag in the existing <subsystem xmlns="urn:jboss:domain:security:1.2"> tag

<security-domain name="PortalRealm"> <authentication> <login-module code="com.liferay.portal.security.jaas.PortalLoginModule" flag="required"/> </authentication> </security-domain>

We will be replacing the standard JBoss welcome application with Liferay later, so we need to set the enable-welcome-root attribute to false on the existing <virtual-server> tag. We will also set the JSP mode to development by adding <configuration> and <jsp-configuration> tags in the web <subsystem>:

<subsystem xmlns="urn:jboss:domain:web:1.4" default-virtual-server="default-host" native="false"> <configuration> <jsp-configuration development="true"/> </configuration> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> <virtual-server name="default-host" enable-welcome-root="false"> <alias name="localhost"/> <alias name="example.com"/> </virtual-server> </subsystem>

While we are here, let’s create a mail session for Liferay to use by modifying the existing <mail-session> tag in the <subsystem xmlns="urn:jboss:domain:mail:1.0"> tag:

<subsystem xmlns="urn:jboss:domain:mail:1.0"> <mail-session jndi-name="java:/mail/MailSession" from="MAIL_ADDRESS"> <smtp-server outbound-socket-binding-ref="mail-smtp"> <login name="MAIL_USER" password="MAIL_PASSWORD"/> </smtp-server> </mail-session> </subsystem>

We also need to tell JBoss that the socket binding mail-smtp should talk to the right mail server. Change the host attribute of the existing <remote-destination> tag for the mail-smtp socket binding:

<outbound-socket-binding name="mail-smtp"> <remote-destination host="MAIL_HOST" port="25"/> </outbound-socket-binding>

Of course, replace the MAIL_ADDRESS, MAIL_HOST, MAIL_USER and MAIL_PASSWORD tokens in the above with the proper values for your environment.

Finally we create a JDBC data source for Liferay to use in two steps. First, add a <datasource> tag to the existing <datasources> in the <subsystem xmlns="urn:jboss:domain:datasources:1.1"> subsystem:

<datasource jta="true" jndi-name="java:/jdbc/LiferayPool" pool-name="LiferayPool" enabled="true" use-java-context="true" use-ccm="true"> <connection-url>jdbc:postgresql://DB_SERVER:5432/DB_DATABASE</connection-url> <driver>postgresql</driver> <pool> <min-pool-size>1</min-pool-size> <max-pool-size>20</max-pool-size> <prefill>true</prefill> </pool> <security> <user-name>DB_USERNAME</user-name> <password>DB_PASSWORD</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> <validate-on-match>false</validate-on-match> <background-validation>false</background-validation> </validation> <statement> <prepared-statement-cache-size>16</prepared-statement-cache-size> <share-prepared-statements>true</share-prepared-statements> </statement> </datasource>

Then add a <driver> tag to the existing <drivers> tag within the <datasources> tag:

<driver name="postgresql" module="org.postgresql"> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> </driver>

Again, replace the DB_SERVER, DB_DATABASE, DB_USERNAME and DB_PASSWORD tokens with the correct values for your environment. If you are using a different database server, you’ll have to change the <connection-url>, the class-name for the <validation-connection-checker> and the <xa-datasource-class> as well, but you knew that already. For the database, use an empty schema and Liferay will populate it when it first starts.

Liferay requires certain system properties to be set when JBoss is started. Use your favorite mechanism to ensure the following values are set:

-Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true -Djava.security.manager -Djava.security.policy=$JBOSS_HOME\bin\server.policy -Djboss.home.dir=$JBOSS_HOME

If you are developing on Windows, use the standalone/standalone.conf.bat file. If you have set up JBoss on CentOS per my instructions, you can use the /etc/jboss-as/jboss-as.properties file (drop the -D prefixes of course).

Don’t forget to set the set the -Xmx and -XX:MaxPermSize options while you are editing files in the bin directory. Liferay recommends -Xmx1024m -XX:MaxPermSize=256m.

The Liferay documentation suggests setting the user.timezone property to GMT as well. I encountered problems with that setting when deploying JSP changes. The Liferay deployer left the JSP timestamped with GMT time value on the file system; since these were always in the past for me the JSPs always looked older than their last compile time from JBoss’s point of view. So they did not get recompiled. So I have skipped that setting.

While we are fooling around with the JBoss start-up mechanism, it seems like a good time to create the server.policy file in jboss-as-7.2.0.Final/bin:

grant { permission java.security.AllPermission; };

Next we need to define the portal-ext.properties file in the liferay directory. We tell Liferay where in the JNDI to find our data source and mail session. We also disable the mechanism where it tries to launch a browser every time it starts.

jdbc.default.jndi.name=java:/jdbc/LiferayPool mail.session.jndi.name=java:/mail/MailSession browser.launcher.url=

Something to note here is that the Liferay documentation omits the first slash in the JNDI names which causes issues on JBoss 7.2.0. Include the slash and make sure your names are consistent between the portal-ext.properties and standalone-full.xml files.

OK, we are to install Liferay itself. We extract the contents of the Liferay war download into a new directory under deployments. Then we need to delete the eclipselink.jar from the lib directory. Finally we create a .dodeploy file to trigger the deployment:

$ cd jboss-as-7.2.0.Final/standalone/deployments/ $ mkdir liferay-portal.war $ cd liferay-portal.war $ jar xf ../../../../../liferay-portal-6.2.0-ce-ga1-20131101192857659.war $ rm WEB-INF/lib/eclipselink.jar $ cd .. $ touch liferay-portal.war.dodeploy

Note that we are differing from the Liferay instructions again, mainly because JBoss 7.2.0 does not have a ROOT.war deployment to clear out. Instead we use the much clearer name liferay-portal.war.

At this point you are ready to go. Fire up JBoss and enjoy your Liferay portal at http://localhost:8080/. Don’t forget that we used the standalone-full.xml file, not the default standalone.xml file when you start your application server.