Tag Archives: wildfly

Jenkins – How to Deploy an Artifact Into a Custom Directory

It takes me some time to figure out the right way to deploy an artifact with Jenkins. After a successful build, I wanted to deploy the generated EAR file into a custom directory of my server. After trying several plugins the Artifact Deployer Plugin  seems to me the best solution.

jenkins-01

With this plugin installed you can add a ‘Post-Build-Action’ to your project. The Artefact location can be specified using the wildcards “**/*.war” or “**/*.ear”.  In case of a Maven Project it’s not necessary to add a Base Dir location like it was in earlier releases. The ‘Remote File Location’ is just your target directory. You have also an option to disable the deployment in case the build failed.

So that’s it. If you know other solutions (especially for Wilfly) let me know.

Wildfly – Debugging JPA / Eclipselink

It take me some time to figure out how to debug the JPA / EclipseLink implementation running on Wildfly. My goal was to log the SQL statements generated by EclipseLink.

It’s not necessary to modify the persistance.xml file. Just add into the standalone.xml file the following additional logger categories:

 <logger category="org.eclipse.persistence.sql">
 <level name="DEBUG"/>
 </logger>
 <logger category="org.jboss.as.jpa">
 <level name="DEBUG"/>
 </logger>

And change the log level from the console-handler from ‘INFO’ to ‘DEBUG’

<console-handler name="CONSOLE">
 <level name="INFO"/>
 <formatter>
 <named-formatter name="COLOR-PATTERN"/>
 </formatter>
 </console-handler>

Restart wildfly which is now logging all JPA information.

WildFly – Reverse Proxy via SSL

In many web architectures it is common to access a Java EE Application through a reverse proxy server. A reverse proxy can be used for example as a dispatcher to redirect users to different servers or switch to a standby server in a failover scenario. Another typical use case is to run a dispatcher as the SSL Endpoint for a Java EE application. Squid for example is a common tool to provide such a functionality. If you are running Wildfly behind such a reverse proxy server for SSL Endpoints you need to take care about some configuration issues.

Enable HTTPS on WildFly

To access an application running on Wildfly through a reverse proxy per SSL it is necessary to enable also HTTPS connections in Wildfly. Per default the WildFly server is only allowing HTTP connections. To enable HTTPS you need first to create a certificate and add this into the standalone.xml. Here are the steps to go:

(1) Create a Certificate 

(1.1) Self-signed Certificate:

Using the linux keytool you can easily create your own private certificate and store it into the  / configuration/ directory in Wildfly:

cd /opt/wildfly/standalone/configuration/
keytool -genkey -alias local-wildfly-cert -keyalg RSA -sigalg MD5withRSA -keystore local-wildfly-cert.jks -storepass adminadmin  -keypass adminadmin -validity 9999 -dname "CN=Server Administrator,O=MyOrg,OU=com,C=DE"

Replace the password and organisation name with appropriate values.

(1.2) CA-Certificate

Only in case that you already have an existing CA-Certificate and you want to use it for wildfly directly you can create the keystore file for wildfly with the openssl command line tool:

openssl pkcs12 -export -in yourdomain.com.crt -inkey yourdomain.com.key -out yourdomain.com.p12 -name local-wildfly-cert -CAfile your_provider_bundle.crt -caname root -chain

You need to define a password for the generated cert file. The pk12 file can now be imported into the keystore with the following command

keytool -importkeystore -deststorepass <secret password> -destkeypass <secret password> -destkeystore yourdomain.com.jks -srckeystore yourdomain.com.p12 -srcstoretype PKCS12 -srcstorepass <secret password used in csr> -alias local-wildfly-cert

The password again is needed for the configuration in wildfly.

(2) Configure a security realm

After you have generated the .jks file you can now add a new SecurityRealm with the name “UndertowRealm” in the standalone.xml file. This security realm is used to established https connections for wildfly/undertow later.  Add the following entry into the section “security-realms” of the standalone.xml file:

..... 
  <security-realm name="UndertowRealm">
      <server-identities>
         <ssl>
           <keystore path="local-wildfly-cert.jks" relative-to="jboss.server.config.dir" keystore-password="adminadmin" alias="local-wildfly-cert" key-password="adminadmin"/>
         </ssl>
      </server-identities>
  </security-realm>
</security-realms>

The new realm is using the local SSL certificate created before.
Note: Take care about the location of your key files.

(3) Setup the HTTPS Listener

Finally you need to update the http and https-listeners for undertow in the standalone.xml. Edit the server section ‘default-server’ in the following way:

.......
<server name="default-server">
 <http-listener name="default" socket-binding="http" proxy-address-forwarding="true"/>
 <https-listener name="https" socket-binding="https" security-realm="UndertowRealm"/>
   ....
.....

Note: Be careful about changing both listener settings – http and https! The default setting redirect-socket=https from the http-listener must be changed in proxy-address-forwarding=true.

The default port for https in wildfly/undertow is 8443. So you can test your https setup now with a direct https request:

https://myserver:8443/myapplication

proxy-address-forwarding

Finally you need to do some configuration on the dispatcher side. This is because Wildfly is not aware of the proxy and so in cases when your application sends a HTTP redirect (302) an already established SSL connection will be lost. This redirect scenario is typical for JSF applications where a navigation rule can issue such a situation.  To avoid the loss of SSL connections inside your WildFly application you need to add the HTTP header parameter into the HTTP listener of your dispatcher. Sending an X-Forwarded-Proto https header along with your proxy will do the trick:

proxy-address-forwarding="true"

For squid you can add the corresponding config option:

request_header_add X-Forwarded-Proto https

For WildFly 10 another option is to use the new added option “secure=true|false” for http-listener. This option tells wildfly that all requests that come in are “secure” even when they come over http. See also the discussion here.

 

Wildfly – Logging

To activate logging for a specific category (path/class) from a deployed application follow these steps:

  1. Open the Wildfly Admin Console
  2. Switch to “Configuration -> Subsystem :Logging”
  3. Change the Console Loglevel to ‘FINE’ (or higher in case you need finer log levels) – default is ‘INFO’
  4. Add a new Log Category (Tab: Log Categories) with the following settings:
    • Category = package or class
    • Level = FINE (or higher in case you need finer log levels)
    • Use parent handler=true

WildFly Undertow – How to Configure a Request Dump

If you need to debug the request headers send to Wildfly application server you can configure a Request-Dumper. There for change the standalone.xml file and add a filter-ref and filter configuration into the subsystem section of undertow. See the following example:

... 
<subsystem xmlns="urn:jboss:domain:undertow:2.0">
....
 <server name="default-server">
       ...
      <host name="default-host" alias="localhost">
          .....
          <filter-ref name="request-dumper"/>
      </host>
 </server>
....
<filters>
    .....
    <filter name="request-dumper" class-name="io.undertow.server.handlers.RequestDumpingHandler" module="io.undertow.core" />
</filters

This will print out all the request information send by a browser.

Wildfly and MVC 1.0 Ozark

I just started to build a new Java EE Web Application based on the new MVC 1.0 Framework which will become part of Java EE8. I tried to run the application on Wildfly 9.0.2.

Setup a Maven Project

To setup a MVC 1.0 Web Application with maven seems to be quite simple. I Just added the following dependencies into my pom.xm :

 <!-- MVC 1.0 dependencies -->
 <dependency>
   <groupId>org.glassfish.ozark</groupId>
   <artifactId>ozark</artifactId>
   <version>1.0.0-m02</version>
   <scope>compile</scope>
 </dependency>
 <dependency>
   <groupId>org.glassfish.jersey.containers</groupId>
   <artifactId>jersey-container-servlet</artifactId>
   <version>2.22</version>
 </dependency>

As ozark is based on jersey we need the jersey-container-servlet. As ozark is based on Java 8 it is also necessary to start Wildfly with JDK 8. Otherwise the war file can not be deployed.

The application class

Next I added an application class with a resurce mapping /api/

@ApplicationPath("api")
public class MyApplication extends Application {
}

This class is necessary to call the application URL like

/myapp/api/hello?name=xx

Here is my controller class:

@Path("hello")
public class HelloController {
 @Inject 
 private Greeting greeting; 
 private static Logger logger = Logger.getLogger(HelloController.class.getName());

 @GET
 @Controller
 @View("/pages/hello.xhtml")
 public void hello(@QueryParam("name") String name) {
 logger.info("set new message: "+name);
 greeting.setMessage("Hello "+name);
 }
}

On the first look the conroller is triggered. But currently I am not able to return the target page (in my example /pages/hello.xhtml)

The reason seems to be that the jersey servlet container will not replace the resteasy implementation for the application.

Maybe someone knows how to solve this problem?

Wildfly – HeapSize

The default memory setting for Wildfly are not very high and can be to less for deployed applications. The default VM settings are typically:

  • -Xms64m
  • -Xmx512m
  • -XX:MaxPermSize=256m

For production mode this can be increased by editing the “bin/standalone.conf” file. To increase the memory size from 512MB to 2GB change the following line from:

JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true"

into

JAVA_OPTS="-Xms2048m -Xmx2048m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true"

The settings depend on the applications deployed on wildfly.

Debug an application in WildFly with Eclipse

You can debug a deployed applications running in WildFly with the Eclipse Debugging feature.

First you need to start WildFly in debug mode with the following command:

standalone.sh --debug --server-config=standalone.xml

Now WildFly starts in the debug mode and listens to the port 8787.

To enable debugging in your Eclipse IDE you now can add a new Debug Configuration:

wildfly_debug_eclipse

This will connect Eclipse to the WildFly Debug port.

Connection refused!

It may happen that – even if you have started glassfish in debug mode and configured all well – you got the following eclipse error message:

Failed to connect to remote VM. Connection refused.

eclipse-debug-02

In this case – it maybe can help if you add a project to the debug configuration. In the screen example above I have let the field ‘Project’ empty. It may help in some cases that you select a project there