Skip navigation

Some SASL mechanisms support channel binding to external secure channels like TLS. The name of a SASL mechanism tells us if channel binding is supported. In particular, SASL mechanisms that support the optional use of channel binding have two SASL mechanism names - one name that includes the “-PLUS” suffix, which implies that channel binding is supported, and one name without the “-PLUS” suffix, which implies that channel binding is not supported (e.g., GS2-KRB5 and GS2-KRB5-PLUS, SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, etc.). Whether or not channel binding is used is determined during SASL mechanism negotiation.

 

This blog post is going to show the server and client configuration needed to connect to the JBoss CLI using the SCRAM-SHA-256-PLUS mechanism, one of the SASL PLUS mechanisms provided by Elytron.

 

Prerequisite configuration

 

First, add a management user for the server - this is the user that we’re going to use later on when attempting to connect to the CLI. For this example, we’re going to create a filesystem-based identity store and add a user named “bob” with password “pAssw0rd” using the following CLI commands:

 

/subsystem=elytron/filesystem-realm=exampleRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir)
/subsystem=elytron/filesystem-realm=exampleRealm:add-identity(identity=bob)
/subsystem=elytron/filesystem-realm=exampleRealm:set-password(identity=bob,clear={password=pAssw0rd})

 

Now, we’re going to add the filesystem-realm that we just created to the “ManagementDomain” security domain that is already defined in the default Elytron subsystem configuration and we’re going to make this the default security realm for this security domain:

 

/subsystem=elytron/security-domain=ManagementDomain:list-add(name=realms, value={realm=exampleRealm})
/subsystem=elytron/security-domain=ManagementDomain:write-attribute(name=default-realm, value=exampleRealm)

 

Next, use the following commands to secure the management interface using Elytron:

 

/core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade,value={enabled=true, sasl-authentication-factory=management-sasl-authentication})
/core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory,value=management-http-authentication)
/core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)

 

Finally, generate a server keystore and a client truststore using the keytool command, as shown below. We’re going to use these to enable one-way SSL/TLS for the management interface.

 

Generate the server keystore:

keytool -genkeypair -alias localhost -keyalg RSA -keysize 1024 -validity 365 -keystore server.keystore.jks -dname "CN=localhost" -keypass secret -storepass secret

 

Export the server certificate:

keytool -exportcert  -keystore server.keystore.jks -alias localhost -keypass secret -storepass secret -file server.cer

 

Import the server certificate into the client’s truststore:

keytool -importcert -keystore client.truststore.jks -storepass secret -alias localhost -trustcacerts -file server.cer

 

Now we’re ready to proceed with the server and client configuration needed to use the SCRAM-SHA-256-PLUS mechanism.

 

Configuring the server

 

First, configure a key-store, key-manager, and server-ssl-context in the Elytron subsystem using the server keystore that we just created (the following commands assume the server.keystore.jks file is located in the $WILDFLY_HOME/standalone/configuration directory):

 

/subsystem=elytron/key-store=exampleKS:add(path=server.keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
/subsystem=elytron/key-manager=exampleKM:add(key-store=exampleKS, credential-reference={clear-text=secret})  
/subsystem=elytron/server-ssl-context=exampleSSC:add(key-manager=exampleKM, protocols=["TLSv1.2"])

 

Next, enable HTTPS on the management interface using the newly created server-ssl-context:

 

/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=exampleSSC)
/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)

 

Now, update the “management-sasl-authentication” SASL authentication factory to also offer the SCRAM-SHA-256-PLUS mechanism:

 

/subsystem=elytron/sasl-authentication-factory=management-sasl-authentication:list-add(name=mechanism-configurations, value={mechanism-name=SCRAM-SHA-256-PLUS})

 

Finally, reload the server using the :reload command.

 

Configuring the client

 

We can use a wildfly-config.xml file to provide the information that’s needed to connect to the CLI:

 

<configuration>
    <authentication-client xmlns="urn:elytron:1.0">
        <authentication-rules>
            <rule use-configuration="auth-config"/>
        </authentication-rules>
        <authentication-configurations>
            <configuration name="auth-config">
                <sasl-mechanism-selector selector="SCRAM-SHA-256-PLUS"/>
                <set-user-name name="bob"/>  
                <credentials>  
                    <clear-password password="pAssw0rd"/>  
                </credentials> 
            </configuration>
        </authentication-configurations>
        <key-stores>
            <key-store name="truststore" type="JKS">
                <file name="/path/to/client.truststore.jks" />
                <key-store-clear-password password="secret" />
            </key-store>
        </key-stores>
        <ssl-contexts>
            <ssl-context name="client-cli-context">
                <trust-store key-store-name="truststore" />
            </ssl-context>
        </ssl-contexts>
        <ssl-context-rules>
            <rule use-ssl-context="client-cli-context" />
        </ssl-context-rules>
    </authentication-client>
</configuration>

 

Notice that the wildfly-config.xml file specifies that the SCRAM-SHA-256-PLUS mechanism should be used and the username and password that should be used when attempting to connect to the CLI. It also configures an ssl-context using the client truststore that we created earlier.

 

Now, we just need to specify this wildfly-config.xml file when connecting to the CLI. The following command connects to the CLI and executes the :whoami command.

 

$WILDFLY_HOME/jboss-cli.sh -c --controller=remote+https://127.0.0.1:9993 -Dwildfly.config.url=/path/to/wildfly-config.xml :whoami

 

You should see the following output, which indicates that we’ve successfully connected to the CLI using the SCRAM-SHA-256-PLUS mechanism.

 

{
    "outcome" => "success",
    "result" => {"identity" => {"username" => "bob"}}
}

 

Summary

 

This blog post has shown how to set up one-way SSL/TLS for the management interface and how to then use a SASL mechanism that supports channel binding to connect to the CLI.

My previous blog post described how to secure EJBs deployed to WildFly 11 using Elytron and how to invoke them from a standalone remote client. This post describes how to invoke EJBs deployed on a WildFly server instance from another WildFly server instance using Elytron. We’ll refer to the server instance on which the EJBs are deployed as the destination server and we’ll refer to the server instance from which the EJB invocation takes place as the client server.

 

Configuring the client server

As in previous WildFly releases, to be able to invoke EJBs deployed on the destination server, you can add configuration to the Remoting subsystem on the client server to specify the information needed for the outbound connection to the destination server. In WildFly 11, a remote outbound connection can now be specified by two things: an Elytron authentication context and an outbound socket binding.

 

Creating an authentication context

The authentication context provides all of the security information that’s needed to connect to the destination server. For example, if you would like to use a user named “ejbUser” with password “secret” when connecting to the destination server, the following CLI commands can be used to create an appropriate authentication context:

 

/subsystem=elytron/authentication-configuration=ejb-auth-config:add(authentication-name=ejbUser, credential-reference={clear-text="secret"})
/subsystem=elytron/authentication-context=ejb-auth-context:add(match-rules=[{authentication-configuration=ejb-outbound-config}])

 

The above commands result in the following configuration in the Elytron subsystem on the client server:

 

<subsystem xmlns="urn:wildfly:elytron:1.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
...
    <authentication-client>
        <authentication-configuration name="ejb-auth-config" authentication-name="ejbUser">
            <credential-reference clear-text="secret"/>
        </authentication-configuration>
        <authentication-context name="ejb-auth-context">
            <match-rule authentication-configuration="ejb-auth-config"/>
        </authentication-context>
    </authentication-client>
...
</subsystem>

 

Creating an outbound socket binding

As before, the outbound socket binding points to the destination server’s host and port for the connection. For example, if the destination server’s host is 10.20.30.40 and its port is 8080, the following CLI command can be used to create an outbound socket binding:

 

/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-ejb:add(host=10.20.30.40, port=8080)

 

Creating a remote outbound connection

Finally, you can create a remote-outbound-connection that references your newly created authentication context and outbound socket binding as follows:

 

/subsystem=remoting/remote-outbound-connection=remote-ejb-connection:add(authentication-context=ejb-auth-context, outbound-socket-binding-ref=remote-ejb)

 

The above command results in the following configuration in the Remoting subsystem on the client server:

 

<subsystem xmlns="urn:jboss:domain:remoting:4.0">
...
    <outbound-connections>
        <remote-outbound-connection name="remote-ejb-connection" outbound-socket-binding-ref="remote-ejb" authentication-context="ejb-auth-context"/>
    </outbound-connections>
...
</subsystem>

 

Invoking EJBs from a client server

As in my previous post, update any client code that looks up an EJB deployed on the destination server using JNDI to make use of the new Naming Client library. As an example, here’s a simple code snippet that could be used to look up an EJB deployed on the destination server using the new WildFlyInitialContextFactory:

 

Code snippet

// create an InitialContext
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
InitialContext context = new InitialContext(properties);

// look up an EJB and invoke one of its methods
RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
    "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
int sum = statelessRemoteCalculator.add(101, 202);

 

Summary

This blog post has shown how to invoke EJBs deployed on a WildFly server instance from another WildFly server instance using Elytron. If you’d like to see a more advanced example application that shows how to propagate the security identity of an EJB deployed on the client server to an EJB deployed on the destination server, take a look at the ejb-security-context-propagation quickstart.

This blog post describes how to secure EJBs deployed to WildFly 11 using Elytron and how to invoke them from a standalone remote client. If you haven’t already, take a look at the Elytron documentation  on how to create security realms, security domains, and authentication factories. In this post, we’ll make use of a security domain (“ApplicationDomain”) and a SASL authentication factory (“application-sasl-authentication”) that are already defined in the default WildFly configuration file in the Elytron subsystem configuration.

 

To start the server, use the following command:

$WILDFLY_HOME/bin/standalone.sh

 

To connect to the running server to execute CLI commands, use:

$WILDFLY_HOME/bin/jboss-cli.sh --connect

 

Securing EJBs with Elytron

By default, security for EJBs deployed to WildFly 11 will continue to be handled by the legacy security subsystem. To indicate that security for an EJB should be handled by the Elytron subsystem instead, you need to add some configuration to the EJB subsystem to map the security domain name that’s configured for an EJB in a deployment to the Elytron security domain that you would like to use. For example, if “other” is the security domain name that is configured for an EJB (e.g., via a @SecurityDomain annotation or in a jboss-ejb3.xml deployment descriptor) and “ApplicationDomain” is the Elytron security domain that you would like to use, the following CLI command can be used to add the required mapping:

 

/subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain)

 

The above command results in the following configuration in the EJB subsystem:

 

<subsystem xmlns="urn:jboss:domain:ejb3:5.0">
...
    <application-security-domains>
        <application-security-domain name="other" security-domain="ApplicationDomain"/>
    </application-security-domains>
...
</subsystem>

 

Notice that an application-security-domain mapping has two main attributes:

  • name - the name of the security domain as specified in a deployment
  • security-domain - a reference to the Elytron security domain that should be used

 

Next, update the http-remoting-connector in the Remoting subsystem to reference the SASL authentication factory that is backed by your Elytron security domain:

 

/subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=sasl-authentication-factory, value=application-sasl-authentication)
/subsystem=remoting/http-connector=http-remoting-connector:undefine-attribute(name=security-realm)

 

The latter command above just clears the legacy security-realm attribute since it is no longer needed.

 

Finally, reload the server using the :reload command.

 

Invoking EJBs from a standalone remote client

Prior to WildFly 11, many WildFly client libraries used different configuration strategies. WildFly 11 introduces a new wildfly-config.xml file which unifies all client configuration in a single place. EJBs deployed to WildFly 11 can still be invoked using existing standalone remote clients that make use of the legacy naming and EJB client libraries from previous WildFly releases. This section walks through an example of how to migrate a remote client to make use of the new WildFly Naming Client and EJB Client libraries.

 

Consider a legacy client application that has a jboss-ejb-client.properties configuration file and looks up an EJB deployed on a remote server using JNDI, as follows:

 

jboss-ejb-client.properties

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=10.20.30.40
remote.connection.default.port=8080
remote.connection.default.username=bob
remote.connection.default.password=secret

 

Code snippet

// create an InitialContext
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
InitialContext context = new InitialContext(properties);

// look up an EJB and invoke one of its methods
RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
    "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
int sum = statelessRemoteCalculator.add(101, 202);

 

To migrate this example to the new Naming Client and EJB Client libraries, the first thing you can do is remove the jboss-ejb-client.properties file since it is no longer needed. Instead, all of the information that’s needed to connect to the remote server can be specified in a wildfly-config.xml file in the client application’s META-INF directory, as follows:

 

wildfly-config.xml

<configuration>
    <authentication-client xmlns="urn:elytron:1.0">
        <authentication-rules>
            <rule use-configuration="default"/>
        </authentication-rules>
        <authentication-configurations>
            <configuration name="default">
                <set-user-name name="bob"/>
                <credentials>
                    <clear-password password="secret"/>
                </credentials>
            </configuration>
        </authentication-configurations>
    </authentication-client>
    <jboss-ejb-client xmlns="urn:jboss:wildfly-client-ejb:3.0">
        <connections>
            <connection uri="remote+http://10.20.30.40:8080" />
        </connections>
    </jboss-ejb-client>
</configuration>

 

To learn more about the contents of the above file, take a look at the Elytron Client documentation.

 

Next, update the client code that sets up the InitialContext to make use of the new WildFlyInitialContextFactory from the new Naming Client library:

 

Code snippet

// create an InitialContext
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
InitialContext context = new InitialContext(properties);

// look up an EJB and invoke one of its methods (this part is the same as before)
RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
    "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
int sum = statelessRemoteCalculator.add(101, 202);

 

Additional client migration examples can also be found here.

 

Summary

This blog post has shown how to secure EJBs deployed to WildFly 11 with Elytron and how to invoke them from a standalone remote client using the new Naming Client and EJB Client libraries. If you’d like to see a complete example application that pulls everything described here together, take a look at the ejb-security quickstart. My next post will cover EJB invocations from a remote server using Elytron.

Since WildFly 10 Final was just released, the OpenShift WildFly cartridge has been updated as well. This post will walk you through getting started on OpenShift and deploying a WildFly quickstart. If you already have an existing WildFly OpenShift app, you'll want to check out these tips for migrating your app to WildFly 10 Final.

 

Creating a new app

There are a few options for creating an app on OpenShift:

  • To use the OpenShift Web Console, just click here.
  • To get started directly from Eclipse, you'll first need to install the OpenShift JBoss Tools package. Then, simply use the New OpenShift Application Wizard to create your app.
  • With JBoss Developer Studio, the OpenShift JBoss Tools package is already installed so you can get started right away with the New OpenShift Application Wizard.
  • To use the CLI, make sure you've got the OpenShift Client Tools installed and then execute the following command:
    rhc app create <WILDFLY_APP_NAME> jboss-wildfly-10

 

WildFly management options

Once you've created your app, it will be available at http://<WILDFLY_APP_NAME>-<NAMESPACE>-rhcloud.com. You can then use the WildFly CLI or Admin Console to manage your server.


To connect to the CLI:

rhc ssh <WILDFLY_APP_NAME> # This command allows you to ssh into your OpenShift app
jboss-cli.sh -c --controller=$OPENSHIFT_WILDFLY_IP:$OPENSHIFT_WILDFLY_MANAGEMENT_HTTP_PORT


When logging into the Admin Console, you can use the credentials for the WildFly management user that's automatically created for you by the WildFly cartridge. To obtain the necessary credentials:

rhc ssh <WILDFLY_APP_NAME>
echo $OPENSHIFT_WILDFLY_USERNAME
echo $OPENSHIFT_WILDFLY_PASSWORD


Then, using port forwarding, you're ready to access the Admin Console from your local machine:

rhc port-forward <WILDFLY_APP_NAME>


Deploying a WildFly quickstart

Getting started with a WildFly quickstart on OpenShift is simple. The following steps will demonstrate how to deploy the kitchensink quickstart, an application that demonstrates a few different Java EE 7 technologies, using the OpenShift Client Tools.


If you created your OpenShift app using the CLI, Eclipse, or JBoss Developer Studio, you should already have a clone of your app's OpenShift git repository on your local machine. If you created your app using the OpenShift Web Console, you'll need to first clone your app's git repository as follows:

rhc git-clone <WILDFLY_APP_NAME>

 

Next, navigate to your app's git repository on your machine and remove the source for the default application that's created by the WildFly cartridge:

git rm -r src pom.xml

 

Now, copy over the source for the kitchensink quickstart:

cp -r QUICKSTART_HOME/kitchensink/src .
cp QUICKSTART_HOME/kitchensink/pom.xml .

 

Next, push your changes:

git add src pom.xml
git commit -m "Deploying the kitchensink quickstart on WildFly 10 on OpenShift!"
git push

 

That's it! The kitchensink quickstart will now be available at your application URL (i.e., http://<WILDFLY_APP_NAME>-<NAMESPACE>-rhcloud.com).


Enjoy!


This post provides some tips on how to migrate an existing OpenShift application to WildFly 10 Final.

 

Migrating from WildFly 10 Alpha/Beta/CR

If you already have an existing WildFly 10 Alpha/Beta/CR app, you can simply create a new WildFly 10 app based on the existing app using the following command:

rhc app create <NEW_WILDFLY_APP> --from-app <OLD_WILDFLY_APP>

 

The result will be a new WildFly 10 Final application that's a clone of your existing one. This means that your new app will have the same git repository, gear size, scaling configuration, environment variables, deployments, etc.

 

Migrating from WildFly 8 or WildFly 9

You can create a new WildFly 10 Final app that's based off your existing app's git repository. There are a couple ways to do this. One option is to first create a new WildFly 10 app and then manually copy over the contents of your old git repo to your new git repo once the new app has been created. Another option is to use the following command:

rhc app create <NEW_WILDFLY_APP> jboss-wildfly-10 --from-code http://url/to/git_repo.git

 

With both of these options, you should first replace the standalone.xml file from your git repo's .openshift/config directory with the WildFly 10 standalone.xml file.

 

Migrating from AS 7

You can create a new WildFly 10 Final app that's based off your existing app's git repository, as described above. However, there are some extra caveats that you should be aware of:

  • If your git repo contains any action hook scripts that end with "_jbossas", these scripts will need to be renamed to end with "_wildfly" instead.
  • If your git repo contains any action hook scripts that reference OpenShift environment variables that start with "OPENSHIFT_JBOSSAS_", these scripts will need to be updated to reference "OPENSHIFT_WILDFLY_" instead.

To see if you have any such scripts, have a look in the .openshift/action_hooks directory in your git repo.


Happy migrating!

Since WildFly 9.0.0.Final was just released, the OpenShift WildFly cartridge has been updated as well. Getting started on OpenShift is simple, the first thing you need to do is pick your favourite tool:

 

Getting started from the Web Console

 

Just click here.

 

Getting started from the command line

 

  1. Follow the instructions here to install the RHC client tools.
  2. Create your WildFly 9 application using the following command:

rhc app create <WILDFLY_APP_NAME> jboss-wildfly-9

 

Getting started from Eclipse

 

  1. Follow the instructions here to install the OpenShift JBoss Tools package from the Eclipse marketplace.
  2. Create your WildFly 9 application directly from Eclipse using the New OpenShift Application Wizard:

Wizard.png

Similarly, you can also create your application using JBoss Developer Studio which comes with the OpenShift plugin installed.

 

Accessing and managing your app

 

Once you've created your application, it will be available at the following URL:

http://{WILDFLY_APP_NAME}-{NAMESPACE}-rhcloud.com

To ssh into your OpenShift instance, the following command can be used:

rhc ssh <WILDFLY_APP_NAME>

You can then use the JBoss CLI to connect to WildFly:

jboss-cli.sh -c --controller=$OPENSHIFT_WILDFLY_IP:$OPENSHIFT_WILDFLY_MANAGEMENT_HTTP_PORT

To access the WildFly Admin Console, you'll need to use port forwarding:

> rhc port-forward <WILDFLY_APP_NAME>

 

Checking available ports ... done
Forwarding ports ...

To connect to a service running on OpenShift, use the Local address

Service Local OpenShift
------- -------------- ---- -------------------
java 127.0.0.1:8080 => 127.13.118.129:8080
java 127.0.0.1:9990 => 127.13.118.129:9990
java 127.0.0.1:9999 => 127.13.118.129:9999

In the example shown above, the Admin Console would then be available on your local machine at http://localhost:9990/console. To log into the Admin Console, you can use the username/password the WildFly cartridge automatically created for you. To find these values, simply ssh into your OpenShift instance and execute the following commands:

echo $OPENSHIFT_WILDFLY_USERNAME

echo $OPENSHIFT_WILDFLY_PASSWORD

 

Tips for migrating an existing OpenShift application to WildFly 9 Final

 

Migrating from WildFly 9 Alpha/Beta/CR

 

If you already have an existing WildFly 9 Alpha/Beta/CR OpenShift app, you can create a new WildFly 9 app based on the existing one using the following command:

rhc app create <NEW_WILDFLY_APP> --from-app <OLD_WILDFLY_APP>

This results in a new WildFly 9 Final application that's a clone of your existing one - same gear size, scaling configuration, environment variables, git repository, deployments, etc.

 

Migrating from WildFly 8 or AS 7

 

If you have an existing WildFly 8 or AS 7 OpenShift app, you can create a new WildFly 9 app using your existing app's git repo, as shown below. You'll want to first replace the standalone.xml file in your git repo's .openshift/config directory with the WildFly 9 standalone.xml file from here.

rhc app create <NEW_WILDFLY_APP> jboss-wildfly-9 --from-code http://url/to/git_repo.git

Alternatively, you can leave off the --from-code option above and manually copy the contents of your old git repo to your new app's git repo once the new app has been created.

 

Couple more steps when migrating from AS 7

 

When migrating from AS 7, there are a few more things to keep in mind:

  1. Any action hook scripts in your app's git repo (i.e., in .openshift/action_hooks) that end with "_jbossas" will need to be renamed to end with "_wildfly".
  2. Any action hook scripts with references to OpenShift environment variables that start with "OPENSHIFT_JBOSSAS_" will need to be updated to reference "OPENSHIFT_WILDFLY_" instead.

 

Fire up an OpenShift instance!

 

Getting WildFly 9 running on OpenShift is easy, try it out now, it only takes a few minutes. For more information about the WildFly cartridge, check out the documentation.

Since WildFly 8.2.0.Final was just released, the OpenShift WildFly cartridge has been updated as well. The WildFly cartridge is now a registered cartridge on OpenShift, which means it's easier than ever to create new apps from the command line! If you don't already have the OpenShift command line tools, follow the quick instructions here to install them. Then, simply use the following command to create a new WildFly 8.2.0.Final app:

rhc app create <APP> jboss-wildfly-8

That's it, no need to reference a long URL anymore in the creation command!

 

For more information on how to access your application, take a look at the cartridge documentation. Enjoy!

Since WildFly 8.1.0.Final was just released, the OpenShift WildFly cartridge has been updated as well and now includes support for Java 8! The WildFly cartridge now installs JDK 8 during instance creation since JDK 8 isn't available on OpenShift yet. All new WildFly applications on OpenShift will default to using Java 8. If you want to switch back to Java 7, simply rename the marker file in your application's git repo as follows:

 

git mv .openshift/markers/java8 .openshift/markers/java7
git commit -a -m "Switching to Java 7"
git push






















 

 

If you create a WildFly application based on an existing WildFly 8.0.0.Final or 8.1.0.CR1 OpenShift application using the --from-app command, your new WildFly 8.1.0.Final application will remain on Java 7. You can manually switch to Java 8 as follows:

 

1. In the pom.xml file in your application's git repo:

 

Change the maven.compiler.source and maven.compiler.target properties to:

 

<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>






















Add the following two properties:

 

<maven.compiler.executable>${env.OPENSHIFT_WILDFLY_DIR}usr/lib/jvm/jdk1.8.0_05/bin/javac</maven.compiler.executable>
<maven.compiler.fork>true</maven.compiler.fork>





















 

 

2. Now rename the marker file and push your changes:

 

git mv .openshift/markers/java7 .openshift/markers/java8
git commit -a -m "Switching to Java 8"
git push





















 

 

For more information on how to get started with the WildFly cartridge, take a look at the cartridge documentation. As always, feedback is welcome on the WildFly community forums. Enjoy!

Since WildFly 8.1.0.CR1 was released last week, the OpenShift WildFly cartridge has been updated as well.

 

Create a new WildFly 8.1.0.CR1 app

 

To create a new WildFly 8.1.0.CR1 application on OpenShift, you can either use the OpenShift Web Console or the following RHC command:

rhc app create <NEW_WILDFLY_APP> https://cartreflect-claytondev.rhcloud.com/reflect?github=openshift-cartridges/openshift-wildfly-cartridge

 

Create a new WildFly 8.1.0.CR1 app based on an existing app (takes a bit longer)

 

If you already have an existing WildFly 8.0.0.Final OpenShift application, you can try out a brand new RHC command that creates an application based on an existing one:


1. Upgrade to the latest version of the OpenShift command line tools:

gem update rhc

 

2. Create your WildFly 8.1.0.CR1 application using the new --from-app command:

rhc app create <NEW_WILDFLY_APP> --from-app <OLD_WILDFLY_APP>

 

This creates an application that's a clone of your existing one (i.e., same gear size, scaling configuration, environment variables, git repository, etc.). This means that your new WildFly 8.1.0.CR1 application will have the same configuration and deployment(s) as your existing application. However, because the --from-app command relies on an application snapshot, it will take some time to complete (be patient!). This should improve going forward since snapshot exclusions have now been added to the WildFly cartridge to reduce its snapshot footprint.


Be sure to check out the cartridge documentation for more information about the cartridge. Please try it out and provide feedback. Enjoy!

Since WildFly 8.0.0.Final was released this week, the OpenShift WildFly cartridge has been updated as well! There are a couple ways to get started quickly on OpenShift. To use the OpenShift Web Console to create your WildFly 8 application, simply click on "Deploy Now" here. If you'd like to use the OpenShift command line tools instead, just follow these steps:

 

Getting started from the command line

 

  1. Follow the instructions in the OpenShift Getting Started guide to install the OpenShift command line tools.
  2. Create your WildFly 8 OpenShift application using the following command:

rhc app create <APP> https://cartreflect-claytondev.rhcloud.com/reflect?github=openshift-cartridges/openshift-wildfly-cartridge

 

You're all set now!

 

Accessing your application

 

You can access your application via this url:

http://{APP}-{NAMESPACE}-rhcloud.com

 

To connect to your WildFly instance using the JBoss CLI tool, use the following commands:

  1. ssh into your application: rhc ssh <APP>
  2. jboss-cli.sh -c --controller=$OPENSHIFT_WILDFLY_IP:$OPENSHIFT_WILDFLY_MANAGEMENT_HTTP_PORT

 

To access the WildFly Admin Console, port forwarding can be used:

> rhc port-forward <APP>

 

Checking available ports ... done
Forwarding ports ...

To connect to a service running on OpenShift, use the Local address

Service Local OpenShift
------- -------------- ---- -------------------
java 127.0.0.1:8080 => 127.13.118.129:8080
java 127.0.0.1:9990 => 127.13.118.129:9990

In the above example, the Admin Console can be accessed using http://localhost:9990.

 

For more information about the cartridge, take a look at the cartridge documentation.

 

Try it out!

 

It only takes a few minutes to get WildFly 8 up and running on OpenShift! We encourage you to try it out and provide feedback. Enjoy!

The AeroGear team is happy to announce the first community release of the AeroGear Push Server downloadable OpenShift cartridge. This cartridge handles the necessary installation and configuration for getting both the AeroGear UnifiedPush Server and the AeroGear SimplePush Server deployed to OpenShift in minutes. In particular, the cartridge provides:

 

  • the AeroGear UnifiedPush Server deployed to JBoss Application Server 7 on OpenShift
  • the AeroGear SimplePush Server embedded within the same JBoss Application Server 7 instance
  • MySQL datasources for persistence for both the AeroGear UnifiedPush Server and the AeroGear SimplePush Server

 

Getting started on OpenShift

 

Want to try out the downloadable cartridge? It's easy! Just follow these two simple steps:

 

  1. Create an OpenShift account and follow the instructions in the Getting Started guide to install the OpenShift command line tools.
  2. Create your AeroGear Push Server OpenShift application using the following command (notice that this command also adds the MySQL OpenShift cartridge to your application):
rhc app create <APP> https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push mysql-5.1

 

That's it! Now:

 

  • You can access the AeroGear UnifiedPush Server Administration Console via the following URL. Temporarily, there is an "admin:123" user. You will need to change this password when you first log in. Check out the Administration Console user guide for more information about the console.
http://{APP}-{NAMESPACE}-rhcloud.com
  • Client applications can establish secured connections to the AeroGear SimplePush Server via

https://{APP}-{NAMESPACE}-rhcloud.com:8443/simplepush

  • The AeroGear UnifiedPush Server and the AeroGear SimplePush Server persist all data to the MySQL database that's been added to your application's gear.

 

For more information about the downloadable cartridge, check out the cartridge documentation.

 

What's next?

 

The AeroGear Push Server OpenShift cartridge will soon be available directly from OpenShift Online. Stay tuned for that! In the meantime, we encourage you to provide feedback on the downloadable cartridge via our mailing list.

Minification is often considered to be a best practice for improving the performance of web applications since it helps to reduce page loading time. The wro4j plugin is one tool that can be used to minify JavaScript and CSS files at build-time or at run-time.

Manually configuring minification using wro4j

If you want to set up JavaScript and CSS minification at build-time for a web application that will be deployed on JBoss AS 7 or EAP 6 on OpenShift, you can do the following:

 

  1. Add a "minify" profile that configures the wro4j plugin to your pom.xml.
  2. Add a wro.properties file to src/main/webapp/WEB-INF/.
  3. Add a wro.xml file to src/main/webapp/WEB-INF/.
  4. Make sure the minified versions of your JavaScript and CSS files are referenced in your web application code.
  5. Override OpenShift's default maven arguments by setting MAVEN_ARGS in .openshift/action_hooks/pre_build_{jbossas-7,jbosseap} as follows:
MAVEN_ARGS="clean package -Popenshift,minify -DskipTests"

 

After completing these steps, the next time you use the OpenShift infrastructure to build your web application (e.g., after a git push), wro4j will be used to minify your files. Want to see an example? Take a look at the kitchensink-html5-mobile quickstart for an example of how to configure the wro4j plugin in pom.xml and for a sample wro.properties file and a sample wro.xml file.

Automatic wro4j configuration?

Although the minification configuration described above isn't too painful, it has to be repeated for each web application that's created. Since it's generally considered good practice to use minification, there could be value in having the OpenShift AS 7/EAP 6 cartridges do some of this configuration automatically. It's one way to make it easier for users to optimize their web applications. Note that when an application is created using the AS 7 or EAP 6 OpenShift cartridge, a default pom.xml file and a default maven src structure are created. The cartridge could potentially configure wro4j for the user by doing some or all of the following:

 

  • Adding a "minify" profile to the default pom.xml.
  • Adding a sample wro.properties and a sample wro.xml file to the default src/main/webapp/WEB-INF directory.
  • Adding the "minify" profile to the default maven arguments used to build the application. Alternatively, instead of enabling minification by default, a user could be required to specify that they want to use the "minify" profile by overriding OpenShift's default maven arguments via the pre_build_{jbossas-7,jbosseap} action hook.

 

Any thoughts on this?

It's hard to believe it's already been a year since I started working at Red Hat! Time really does fly when you're having fun! I recently finished working on a domain controller discovery system for JBoss AS 8 and thought I'd give an overview of this new feature.

What is it?

When setting up a managed domain, each host controller must be configured with information that's needed to contact the master domain controller. In AS 7, this information is provided by statically configuring the master domain controller's host and port. The domain controller discovery system for AS 8 provides support for a brand new form of discovery and also allows a host controller to be configured with multiple options for contacting the master domain controller.

A new form of discovery

In addition to static discovery, a host controller can now dynamically discover a master domain controller via Amazon S3. In particular, host controllers and the master domain controller can now be configured with information needed to access an S3 bucket (sample configuration is below). When a master domain controller is started, it will write its IP address and port to an S3 file in the given bucket. Then, whenever a slave host controller needs to contact the master domain controller, it will get its IP address and port from that S3 file. If the master domain controller's IP address changes (e.g., this is common when stopping and starting an EC2 instance), the host controllers won't need to be reconfigured. They'll be able to get the new address from the S3 file.

 

Slave host controller configuration:

<domain-controller>
    <remote security-realm="ManagementRealm">
      <discovery-options>
          <discovery-option name="s3-discovery" code="org.jboss.as.host.controller.discovery.S3Discovery" module="org.jboss.as.host-controller">
            <property name="access-key" value="s3_access_key"/>
            <property name="secret-access-key" value="s3_secret_access_key"/>
            <property name="location" value="s3_bucket_name"/>
          </discovery-option>
      </discovery-options>
    </remote>
</domain-controller>

 

Master domain controller configuration:

<domain-controller>
    <local>
        <discovery-options>
            <discovery-option name="s3-discovery" code="org.jboss.as.host.controller.discovery.S3Discovery" module="org.jboss.as.host-controller">
              <property name="access-key" value="s3_access_key"/>
              <property name="secret-access-key" value="s3_secret_access_key"/>
              <property name="location" value="s3_bucket_name"/>
          </discovery-option>
      </discovery-options>
    </local>
</domain-controller>


Support for multiple discovery options

A host controller can now be configured with multiple options for contacting a master domain controller (sample configuration is below). Currently, any number of static discovery or S3 discovery options are supported. Whenever a host controller needs to contact the master domain controller, it will now loop through the provided options, in order. The first option provided should be the one that's expected to succeed. The remaining discovery options can be used in failover situations. For example, if the primary domain controller fails, a backup can be brought online as the new domain controller and the host controllers will be able to connect to it without requiring any configuration changes!

 

<discovery-options>
    <discovery-option name="option-one" code="org.jboss.as.host.controller.discovery.S3Discovery" module="org.jboss.as.host-controller">
        <property name="access-key" value="s3_access_key"/>
        <property name="secret-access-key" value="s3_secret_access_key"/>
        <property name="location" value="s3_bucket_name"/>
    </discovery-option>
    <static-discovery name="option-two" host="172.16.81.100" port="9999"/>
    <static-discovery name="option-three" host="172.16.81.101" port="9999"/>
</discovery-options>

 

You can try out this new feature by using the latest AS 8 snapshot. Enjoy!