Adding jars to your OpenShift remote Maven repo

If your OpenShift app has dependencies on other Jars that are not publicly available in the usual maven repos (for example, other Jars from your own projects), you can push them to your remote Maven repo used when your app builds remotely.

Commit the jar in the root of your OpenShift project.

Edit .openshift/action_hooks/pre_build and add the following, updating Jar name etc:

mvn install:install-file --debug -Dfile=../../YourProjectName/runtime/repo/YourJarName.jar
  -DgeneratePom=true -DartifactId=YourArtifactName -Dversion=0.0.1-SNAPSHOT
  -DgroupId=your.group.id -Dpackaging=jar

Commit your changes and push to OpenShift – the jar will get installed to your remote repo, and now you can add a Maven dependency against it in your project’s pom.xml.

Accessing Glassfish server admin when you’ve forgotten your admin password

For my own development I frequently rotate between different app servers and different versions, Tomcat, JBoss AS, Glassfish, trouble is when you work with one for a while and then go back to one of the others, you forget key things, like what your admin password was when you last installed/configured a server.

Whatever the reason, there’s a few different approaches to working around this issue with Glassfish, like creating a new domain and copy files from the old to the new, but this question on superuser.com has the best lifesaver response ever… this file has a backup password that you can use for your admin account, even if you have no idea what your original password was – just copy the value from this file:

glassfish3glassfishdomainsdomain1configlocal_password

Using Spring 3.1 Profiles

Profiles in Spring 3.1+ give you the ability to define conditional bean configurations based on a profile name, where one of your defined profiles is selected at runtime based on a selected profile name.

For example, if you have certain beans that are needed for running in a certain deployment environment but not needed for others (dev, test or prod), or if certain beans need to be configured differently between different environments, Profiles give you the ability to do exactly this.

If you’re using XML configuration, you use the profile=”…” attribute on the
<beans> element. For example:

<beans>
    <beans profile="dev">
        ... bean defs for dev profile here
    </beans>

    <beans profile="prod">
        ... bean defs for prod profile here
    </beans>
</beans>

To select your profile at runtime you’ve got a couple of different options – the easiest approach is to declare a system property, or -D parameter to your JVM at startup:

-Dspring.profiles.active=dev

When you initialize your Application Context, Spring automatically checks for this property and then will initialize only the beans declared for that specific profile. Beans not within a profile will still get initialized, or alternatively a profile with the name ‘default’ will get initialized if no other profile is specified.

Another approach if you need more control over the logic to determine which profile is active on startup, you can programmatically select your profile like this:

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();

if( ... some logic here)
{
    ctx.getEnvironment().setActiveProfiles("example_profile_1");
}
else
{
    ctx.getEnvironment().setActiveProfiles("example_profile_2");
}

ctx.load("classpath:applicationContext.xml");
ctx.refresh();

Notice with this approach, since we’re not using the spring.profiles.active property, we don’t want to load the context xml file until after we’re determined programmatically which profile is active (based on some logic), then we set the profile with setActiveProfiles(), then load the xml, and refresh the context to initialize our beans for the selected profile.

Forge app error “No mime type could be found for file favicon.ico”

Apps generated using JBoss Forge get this error showing up in the server log:

JSF1091: No mime type could be found for file favicon.ico.  To resolve this, add a mime-type mapping to the applications web.xml

This is described in this bug: https://issues.jboss.org/browse/FORGE-657

The quick fix is to add this to your web.xml:

<mime-mapping>
   <extension>ico</extension>
   <mime-type>image/x-icon</mime-type>
</mime-mapping>