Skip to main content

Welcome to Geoff Hayward's Weblog

Commenting on Java, JavaFX, Java EE, Joomla, and IoT.

Serving a static files with Bloomreach (formally known as Hippo CMS), such as BingVerify.xml, is not as simple as dropping it in the webapp folder. However, with a little extra configuration Bloomreach CMS will serve the file.

First add the static file in webapp. In my case example site/src/main/webapp/BingSiteAuth.xml. Then update hts:default in sitemap.ymal akin to the following.

/hst:hst/hst:configurations/hst:default/hst:sitemap:
 /BingSiteAuth.xml:
   hst:authenticated: false
   hst:containerresource: true
   jcr:primaryType: hst:sitemapitem

After rebuilding the project, the static file BingSiteAuth.xml will be served by Bloomreach CMS.



Read

The first push of a new Git branch, when given as git push will remind you to set the upstream.

The following command will capture that reminder and then run it.

$(git push 2>&1 | grep "git push")

Tags: GitGREP

Read

I'm excited to announce that I will be answering SEO (search engine optimisation) questions on behalf of NHS Digital at The Search Conference in February 2019.

A banner that has a photo of Geoffrey Hayward next to details of The Search Conference in London on the 13th Febuary 2019

If you are interested in SEO from a Software Developer's point of view, I hope to see you there.



Read

This post is a note on using Maven's 'maven-antrun-plugin' to replace a variable version number in a Dockerfile with the Maven project's version.

The following code replaces this line ADD ./target/[email protected]{version}.jar application.jar in a Dockerfile with something like ADD ./target/application-1.2.0-SNAPSHOT.jar application.jar. The processed Dockerfile is then saved in the target folder alongside any other artefacts created by Maven.

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.8</version>
    <executions>
        <execution>
            <phase>package</phase>
            <configuration>
                <target>
                    <copy file="Dockerfile" todir="${project.build.directory}"/>
                    <replace file="${project.build.directory}/Dockerfile" >
                        <replacefilter token="@{version}" value="${project.version}" />
                    </replace>
                </target>
            </configuration>
            <goals>
                <goal>run</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Once the Dockerfile has been processed a tool such as the Maven 'maven-assembly-plugin' can then package the Dockerfile and other artefacts into a shippable form.

For completeness, here is an example configuration that creates a shippable ZIP ready for AWS's Elastic Beanstalk.

<plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <version>3.0.0</version>
    <executions>
        <execution>
            <id>make-zip</id>
            <phase>package</phase>
            <goals>
                <goal>single</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <appendAssemblyId>false</appendAssemblyId>
        <descriptors>
            <descriptor>assembly.xml</descriptor>
        </descriptors>
    </configuration>
</plugin>

And here is the corresponding example of the 'filesSets' element from an assembly.xml.

<fileSets>
    <fileSet>
        <directory>${project.build.directory}</directory>
        <includes>
            <include>${project.build.finalName}.jar</include>
        </includes>
        <outputDirectory>target</outputDirectory>
    </fileSet>
    <fileSet>
        <directory>${project.build.directory}</directory>
        <includes>
            <include>Dockerfile</include>
        </includes>
        <outputDirectory>.</outputDirectory>
    </fileSet>
    <fileSet>
        <directory>${basedir}</directory>
        <includes>
            <-- other stuff from the base directory -->
        </includes>
        <outputDirectory>.</outputDirectory>
    </fileSet>
</fileSets>

I hope this helps you.



Read

There are several ways to embed the root of a deployed application into a JSP page for JavaScript to phone home with. However in some server environments some methods work better than others. This short post explains the problem that load balancing can course to the Request object and gives a simple workaround for finding the application's root from its JavaScript.

The most common suggestion for embedding an application's seems to be the following. However, the following does not work when a load balancer forwards HTTPS request to the application's server via HTTP (a.k.a. SSL Off Loading).

function root() { // Bad example
       return "${pageContext.request.scheme}://${pageContext.request.serverName}:${pageContext.request.serverPort}${pageContext.request.contextPath}";}";
}

When the application server receives a proxied request via HTTP the JSP will embed the HTTP scheme along with the application server's configured HTTP port.

The simple workaround is to ask JavaScript for its origin and append only the context path from the JSP. Here is a working example:

function root() { // Good example
       return window.location.origin + "${pageContext.request.contextPath}";
}

Hope this helps.


Tags: AjaxHTTPSJSP

Read

Mailing List


Responsive Media

With the ResponsiveMedia plugin for Joomla it is easy to add 3rd party content from YouTube, Vimeo, and Instagram right in to any Joomla! article.

ResponsiveMedia