3 years of WildFly Gource Animation

It is all the rage now at JBoss to generate Gource videos of the source code repositories for our projects giving some very pretty results.

The first was Clebert Suconic, the HornetQ lead: http://www.youtube.com/watch?v=4QI2FuKntpk
Then Tom Jenkinson from the Naranaya (transactions) team: http://jbossts.blogspot.co.uk/2013/10/the-narayana-project-visualized-by.html

Then finally we have WildFly for which all credit goes to Clebert both for running the Gource analysis and providing the cool backing track, showing the three years of WildFly development in about 3 minutes. Enjoy :-)



I expect several more JBoss projects will do the same over the next few weeks. If Clebert is as helpful for others as he has been for us they will show up in his YouTube page.

Simpler Audit Logging Example for WildFly 8.0.0.Alpha4

Tomaz on the WildFly team pointed out that my previous blog post on secure audit logging in WildFly 8.0.0.Alpha4 was a bit too scary :-) So I'd like to point out that that was probably the most complicated setup possible, and to walk through a few simpler examples here while explaining a bit more what goes on. These features are available in WildFly 8.0.0.Alpha4 and later. You can get it from here.

WildFly out of the box comes preconfigured for audit logging to $WILDFLY_HOME/standalone/data/audit-log.log., the only thing you need to do is to enable it. There is a section in $WILDFLY_HOME/standalone/configuration/standalone.xml which contains the configuration for the audit log:

        <audit-log>
            <formatters>
                <json-formatter name="json-formatter">
            </json-formatter></formatters>
            <handlers>
                <file-handler formatter="json-formatter" name="file" path="audit-log.log" relative-to="jboss.server.data.dir">
                </file-handler>
            </handlers>
            <logger enabled="false" log-boot="true" log-read-only="false">
                <handlers>
                    <handler name="file">
                </handler></handlers>
            </logger>
        </audit-log>

This config contains the only audit log formatter we have at the moment, the JSON formatter which formats the audit log records.
It also contains a file-handler called file which points to the file which it should log to.
The file file-handler references the 'json-formatter' which means this handler uses 'json-formatter' to format its log records.
Finally the logger entry references the 'file' handler which means that the 'file' handler will be used for logging audit log records.
The attributes of the logger element mean that we will audit log the operation that happen on boot, that we will not log read-only operations, and that audit logging is not enabled. The not enabled part takes precedence, so we don't log anything at all.

Now if you start up WildFly by running (of course change ~/Downloads/wildfly-8.0.0.Alpha4 to wherever you have installed WildFly)

$cd ~/Downloads/wildfly-8.0.0.Alpha4/bin/
$./standalone.sh

you will see no $WILDFLY_HOME/standalone/data/audit-log.log. file. This is because we need to enable audit logging.

Enable audit logging

In another terminal window go to WildFly's bin directory, start our command-line interface and execute the operation to change the enabled attribute to true:

$cd ~/Downloads/wildfly-8.0.0.Alpha4/bin/

[~/Downloads/wildfly-8.0.0.Alpha4/bin]
$./jboss-cli.sh 
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect 
[standalone@localhost:9990 /] /core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true){"outcome" => "success"}
[standalone@localhost:9990 /] 

If you look in $WILDFLY_HOME/standalone/configuration/standalone.xml again, you will see that the value of the enabled attribute we saw earlier is now true.

Now, if you look, you will see that $WILDFLY_HOME/standalone/data/audit-log.log has been created, and it contains the following:

$more data/audit-log.log
2013-08-14 15:26:16 - {
    "type" : "core",
    "r/o" : false,
    "booting" : false,
    "user" : "$local",
    "domainUUID" : null,
    "access" : "NATIVE",
    "remote-address" : "127.0.0.1/127.0.0.1",
    "success" : true,
    "ops" : [{
        "address" : [
            {
                "core-service" : "management"
            },
            {
                "access" : "audit"
            },
            {
                "logger" : "audit-log"
            }
        ],
        "operation" : "write-attribute",
        "name" : "enabled",
        "value" : true,
        "operation-headers" : {"caller-type" : "user"}
    }]
}

The actual contents of the fields is explained in the documentation but a few things worth pointing out is that access=NATIVE means it came from the native management interface, and ops contains the operation that we executed to enable audit logging.

Enable syslog logging

First you need a syslog server which can accept connections via UDP or TCP/IP. I am on OS X, so I enabled my local syslog server to accept UDP connections on port 514 by following these tips. If you are on linux you probably have rsyslog installed, so you would typically modify /etc/rsyslog.conf to include the following directives

...
$ModLoad imudp.so
$UDPServerRun 514
...

Then restart the syslog service. I think the OS X link shows you how to do that, and for linux you need to restart the rsyslogd service. In the worst case reboot, and start up wildfly and the command-line interface again ;-)

Then in the command-line interface window, execute these following commands to add a syslog handler called mysyslog:

[standalone@localhost:9990 /] batch 
[standalone@localhost:9990 / #] /core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
#1 /core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
[standalone@localhost:9990 / #] /core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
#2 /core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
[standalone@localhost:9990 / #] run-batch 
The batch executed successfully

Then add a reference to mysyslog to the logger:

[standalone@localhost:9990 /] /core-service=management/access=audit/logger=audit-log/handler=mysyslog:add
{"outcome" => "success"}

You should now see the executed commands logged in $WILDFLY_HOME/standalone/data/audit-log.log., e.g.:

2013-08-14 15:55:20 - {
    "type" : "core",
    "r/o" : false,
    "booting" : false,
    "user" : "$local",
    "domainUUID" : null,
    "access" : "NATIVE",
    "remote-address" : "127.0.0.1/127.0.0.1",
    "success" : true,
    "ops" : [{
        "operation" : "composite",
        "address" : [],
        "steps" : [
            {
                "address" : [
                    {
                        "core-service" : "management"
                    },
                    {
                        "access" : "audit"
                    },
                    {
                        "syslog-handler" : "mysyslog"
                    }
                ],
                "operation" : "add",
                "formatter" : "json-formatter",
                "operation-headers" : {"caller-type" : "user"},
                "max-length" : null,
                "syslog-format" : null,
                "truncate" : null,
                "max-failure-count" : null
            },
            {
                "address" : [
                    {
                        "core-service" : "management"
                    },
                    {
                        "access" : "audit"
                    },
                    {
                        "syslog-handler" : "mysyslog"
                    },
                    {
                        "protocol" : "udp"
                    }
                ],
                "operation" : "add",
                "port" : 514,
                "host" : "localhost",
                "operation-headers" : {"caller-type" : "user"}
            }
        ],
        "operation-headers" : {"caller-type" : "user"}
    }]
}
2013-08-14 15:56:34 - {
    "type" : "core",
    "r/o" : false,
    "booting" : false,
    "user" : "$local",
    "domainUUID" : null,
    "access" : "NATIVE",
    "remote-address" : "127.0.0.1/127.0.0.1",
    "success" : true,
    "ops" : [{
        "address" : [
            {
                "core-service" : "management"
            },
            {
                "access" : "audit"
            },
            {
                "logger" : "audit-log"
            },
            {
                "handler" : "mysyslog"
            }
        ],
        "operation" : "add",
        "operation-headers" : {"caller-type" : "user"}
    }]
}

And if you look at syslog,

• On OS X, open the Console.app and go to 'All Messages'
  
On Linux, look in /var/log/messages

In any case you should see the logger handler reference add in syslog

14/08/2013 15:56:35.000 2013-08-14T15: 56:35.529+01:00 localhost WildFly 2348 - - 2013-08-14 15:56:34 - {
    "type" : "core",
    "r/o" : false,
    "booting" : false,
    "user" : "$local",
    "domainUUID" : null,
    "access" : "NATIVE",
    "remote-address" : "127.0.0.1/127.0.0.1",
    "success" : true,
    "ops" : [{
        "address" : [
            {
                "core-service" : "management"
            },
            {
                "access" : "audit"
            },
            {
                "logger" : "audit-log"
            },
            {
                "handler" : "mysyslog"
            }
        ],
        "operation" : "add",
        "operation-headers" : {"caller-type" : "user"}
    }]

(The reason you did not see the add of the handler is that the audit log subsystem does not actually start using it until the logger handler reference is added). If you execute the following command in the command-line interface

[standalone@localhost:9990 /] /system-property=test123:add(value=testing)
{"outcome" => "success"}

You should see the operation get logged in both syslog and the file.

Finally, if you look at $WILDFLY_HOME/standalone/configuration/standalone.xml again you will see that the syslog handler and reference have been persisted:

        <audit-log>
            <formatters>
                <json-formatter name="json-formatter"/>
            </formatters>
            <handlers>
                <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
                <syslog-handler name="mysyslog" formatter="json-formatter">
                    <udp host="localhost" port="514"/>
                </syslog-handler>
            </handlers>
            <logger log-boot="true" log-read-only="false" enabled="true">
                <handlers>
                    <handler name="file"/>
                    <handler name="mysyslog"/>
                </handlers>
            </logger>
        </audit-log>

Setting up Secure Audit Logging to a Remote Rsyslog Instance in WildFly 8.0.0.Alpha4

WildFly is the new name for JBoss Application Server. It builds on the same architecture as JBoss Application Server 7. WildFly is the upstream for JBoss Enterprise Application Platform 6, which is our supported middleware offering at Red Hat. Some of our larger customers have asked for additional security features when it comes to managing their installations, and one of the pieces for this is to implement audit logging of the management layer. The initial implementation of audit logging will be part of the WildFly 8.0.0.Alpha4 release, which was released today.

Note that this is a pretty advanced topic, for a simpler overview of audit logging see my follow-up post.

The WildFly Admin Guide covers the reference for the configuration of audit logging framework, but I thought it would be a good idea to show step by step how to configure WildFly to log to a remote syslog server over TLS. I will also throw client certificate authentication into the mix. I have used rsyslog for my experiments since that comes with nice documentation for how to set it up to use TLS. You need to install the rsyslog-gnutls package for the following to work.

I do my main work on OS X but have a linux server with rsyslog installed so I will use that as the syslog server. It's address is kabirlinux. Wherever you see the name kabirlinux you should replace it with the host name of your machine running rsyslog.

Generating the server certificates

First I ssh into kabirlinux and generate the keys we need to set up rsyslog to accept remote connections over TLS (taken from http://www.rsyslog.com/tag/tls/ and http://www.rsyslog.com/doc/rsyslog_tls.html). The first thing we need to do is to generate the ca certificate that will be used for signing the other certificates. Please note that wherever I have used sudo, it is very important that you do so too, otherwise rsyslog might not recognise your keys.

$ssh kabirlinux
Last login: Mon Aug 12 16:15:28 2013 from 192.168.1.102

[kabirlinux ~]
$mkdir tmp

[kabirlinux ~]
$cd tmp

[kabirlinux ~/tmp]
$sudo certtool --generate-privkey --outfile ca-key.pem
[sudo] password for kabir: 
Generating a 2560 bit RSA private key...

Then we generate the ca certificate using the private key:

[kabirlinux ~]
$sudo certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem
Generating a self signed certificate...
Please enter the details of the certificate's distinguished name. Just press enter to ignore a field.
Country name (2 chars): UK
Organization name: Red Hat
Organizational unit name: JBoss
Locality name: London
State or province name: London
Common name: kabirlinux
UID: 
This field should not be used in new certificates.
E-mail: me@redhat.com
Enter the certificate's serial number in decimal (default: 1376387226): 


Activation/Expiration time.
The certificate will expire in (days): 3650


Extensions.
Does the certificate belong to an authority? (y/N): y
Path length constraint (decimal, -1 for no constraint): 
Is this a TLS web client certificate? (y/N): 
Will the certificate be used for IPsec IKE operations? (y/N): 
Is this also a TLS web server certificate? (y/N): 
Enter the e-mail of the subject of the certificate:    
Will the certificate be used to sign other certificates? (y/N): y
Will the certificate be used to sign CRLs? (y/N): 
Will the certificate be used to sign code? (y/N): 
Will the certificate be used to sign OCSP requests? (y/N): 
Will the certificate be used for time stamping? (y/N): 
Enter the URI of the CRL distribution point: 
X.509 Certificate Information:
 Version: 3
.........

Is the above information ok? (y/N): y


Signing certificate...

Next we generate a certificate request, and the server certificate that will be used to secure TLS.

[kabirlinux ~/tmp]
$sudo certtool  --generate-privkey --outfile server-key.pem --bits 2048
** Note: Please use the --sec-param instead of --bits
Generating a 2048 bit RSA private key...

[kabirlinux ~/tmp]
$sudo certtool --generate-request --load-privkey server-key.pem --outfile request.pem
Generating a PKCS #10 certificate request...
Country name (2 chars): UK
Organization name: Red Hat
Organizational unit name: JBoss
Locality name: London
State or province name: London
Common name: kabirlinux
UID: 
Enter a dnsName of the subject of the certificate: kabirlinux
Enter a dnsName of the subject of the certificate: 
Enter the IP address of the subject of the certificate: 
Enter the e-mail of the subject of the certificate: me@redhat.com
Enter a challenge password: 
Does the certificate belong to an authority? (y/N): 
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (y/N): 
Will the certificate be used for encryption (RSA ciphersuites)? (y/N): 
Is this a TLS web client certificate? (y/N): y
Is this also a TLS web server certificate? (y/N): y

[kabirlinux ~/tmp]
$sudo certtool --generate-certificate --load-request request.pem --outfile server-cert.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem
Generating a signed certificate...
Enter the certificate's serial number in decimal (default: 1376387546): 


Activation/Expiration time.
The certificate will expire in (days): 3650


Extensions.
Do you want to honour the extensions from the request? (y/N): 
Does the certificate belong to an authority? (y/N): 
Is this a TLS web client certificate? (y/N): y
Will the certificate be used for IPsec IKE operations? (y/N): 
Is this also a TLS web server certificate? (y/N): y
Enter a dnsName of the subject of the certificate: kabirlinux
Enter a dnsName of the subject of the certificate: 
Enter the IP address of the subject of the certificate: 
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (y/N): 
Will the certificate be used for encryption (RSA ciphersuites)? (y/N): 
X.509 Certificate Information:
 Version: 3

.....

Is the above information ok? (y/N): y


Signing certificate...

[kabirlinux ~/tmp]
$rm request.pem 

We then need to protect the ca private key

[kabirlinux ~/tmp]
$sudo chmod 400 ca-key.pem

Now move the generated files across to /etc/pki/rsyslog, keeping a copy of the server certificate in the tmp directory:

[kabirlinux ~/tmp]
$sudo mv ca-key.pem ca.pem server-cert.pem server-key.pem /etc/pki/rsyslog/

[kabirlinux ~/tmp]
$sudo cp /etc/pki/rsyslog/server-cert.pem .

Then modify the rsyslog configuration file at /etc/rsyslog.conf to allow TLS. In a vanilla installation this is just after the initial ModLoad directives.

....
#### MODULES ####
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)
#$ModLoad immark  # provides --MARK-- message capability

# Provides TLS syslog reception
$ModLoad imtcp #Load tcp driver
$DefaultNetstreamDriver gtls # Sets the gtls driver as the default
# Certificates
$DefaultNetstreamDriverCAFile /etc/pki/rsyslog/ca.pem
$DefaultNetstreamDriverCertFile /etc/pki/rsyslog/server-cert.pem
$DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/server-key.pem
# run driver in TLS-only mode
$InputTCPServerStreamDriverMode 1
$InputTCPServerStreamDriverAuthMode anon 
$InputTCPServerRun 514 # start up listener at port 514
....

Make sure the syslog server's firewall is open to TCP requests on port 514. A simple way to get rid of all rules is to run this when ssh'ed into the syslog server (you will of course want to set this up properly once done experimenting):

[kabirlinux ~]
$sudo iptables -F

Then restart the rsyslog daemon:

[kabirlinux ~]
$sudo service rsyslog restart
[sudo] password for kabir: 
Redirecting to /bin/systemctl restart  rsyslog.service

In the syslog you should then see messages indicating that the service has been restarted

[kabirlinux ~]
$sudo tail -f /var/log/messages
.....
Aug 12 16:50:32 kabir systemd[1]: Stopping System Logging Service...
Aug 12 16:50:32 kabir systemd[1]: Starting System Logging Service...
Aug 12 16:50:32 kabir systemd[1]: Started System Logging Service.

Importing the server certificate into a Java truststore

Since the server certificate is not signed by a trusted certificate authorization authority, in my local machine where I will be running WildFly, I need to import the server certificate into a truststore. First I copy it down to my local machine:

[~]
$mkdir test

[~]
$cd test

[~/test]
$sftp kabirlinux
Connected to kabirlinux.
sftp> cd tmp
sftp> ls
server-cert.pem
sftp> get server-cert.pem
Fetching /home/kabir/tmp/server-cert.pem to server-cert.pem
/home/kabir/tmp/server-cert.pem                                                    100% 1529     1.5KB/s   00:00    
sftp> exit

[~/test]

Then I import the certificate into a trustore file using the keytool command, and 'test123' as the password:

[~/test]
$keytool -import -trustcacerts -file server-cert.pem -alias CA_ALIAS -keystore truststore
Enter keystore password:  
Re-enter new password: 
...

Trust this certificate? [no]:  yes
Certificate was added to keystore

Set up WildFly to use syslog with TLS for audit logging

Make sure you are using WildFly 8.0.0.Alpha4 or later! Out of the box wildfly's audit log configuration in its standalone/configuration/standalone.xml will look like this

<audit-log>
            <formatters>
                <json-formatter name="json-formatter"/>
            </formatters>
            <handlers>
                <file-handler name="file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
            </handlers>
            <logger log-boot="true" log-read-only="false" enabled="false">
                <handlers>
                    <handler name="file"/>
                </handlers>
            </logger>
        </audit-log>

Change this to

<audit-log>
            <formatters>
                <json-formatter name="json-formatter"/>
            </formatters>
            <handlers>
                <syslog-handler name="syslog-tls" formatter="json-formatter" syslog-format="RFC5424">
                    <tls host="kabirlinux" port="514" message-transfer="NON_TRANSPARENT_FRAMING">
                        <truststore path="/Users/kabir/test/truststore" keystore-password="test123"/>
                    </tls>
                </syslog-handler>
            </handlers>
            <logger log-boot="true" log-read-only="true" enabled="true">
                <handlers>
                    <handler name="syslog-tls"/>
                </handlers>
            </logger>
        </audit-log>

If having the keystore password hard wired in the xml worries you, please take a look at how to use our vault for sensitive information like that. Now if you stop and start WildFly and look in /var/log/messages on the server running rsyslog, you should see audit logged messages on bootup. Also, when executing operations, for example from the CLI you should see those added to the syslog.

Client certificate authentication

Rsyslog supports full blown client certificate authentication, however I have not tried setting that up. However, it also has a slightly more permissive mode which simply checks that the client has a certificate signed by the server's ca. So first we generate the client certificate, I do this on my syslog server:

[~/test]
$ssh kabirlinux
Last login: Mon Aug 12 18:02:25 2013 from 192.168.1.102

[kabirlinux ~]
$cd tmp/

[kabirlinux ~/tmp]
$certtool --generate-privkey --outfile client-key.pem
Generating a 2560 bit RSA private key...

[kabirlinux ~/tmp]
$certtool --generate-request --load-privkey client-key.pem --outfile client-request.pem
Generating a PKCS #10 certificate request...
Country name (2 chars): UK
Organization name: Red Hat
Organizational unit name: JBoss
Locality name: London
State or province name: London
Common name: client    
UID: 
Enter a dnsName of the subject of the certificate: kabirlinux
Enter a dnsName of the subject of the certificate: 
Enter the IP address of the subject of the certificate: 
Enter the e-mail of the subject of the certificate: me@redhat.com
Enter a challenge password: 
Does the certificate belong to an authority? (y/N): N
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (y/N): 
Will the certificate be used for encryption (RSA ciphersuites)? (y/N): 
Is this a TLS web client certificate? (y/N): y
Is this also a TLS web server certificate? (y/N): y

[kabirlinux ~/tmp]
$sudo certtool  --generate-certificate --load-request client-request.pem --outfile client-cert.pem  --load-ca-certificate /etc/pki/rsyslog/ca.pem --load-ca-privkey /etc/pki/rsyslog/ca-key.pem
[sudo] password for kabir: 
Generating a signed certificate...
Enter the certificate's serial number in decimal (default: 1376327802): 


Activation/Expiration time.
The certificate will expire in (days): 3650


Extensions.
Do you want to honour the extensions from the request? (y/N): 
Does the certificate belong to an authority? (y/N): 
Is this a TLS web client certificate? (y/N): y
Will the certificate be used for IPsec IKE operations? (y/N): 
Is this also a TLS web server certificate? (y/N): y
Enter a dnsName of the subject of the certificate: kabirlinux
Enter a dnsName of the subject of the certificate: 
Enter the IP address of the subject of the certificate: 
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (y/N): 
Will the certificate be used for encryption (RSA ciphersuites)? (y/N): 
X.509 Certificate Information:
...

Is the above information ok? (y/N): y

We then need to combine the client certificate and key to pkcs12 format to copy across to the client, using 'test123' as the export password

[kabirlinux ~/tmp]
$openssl pkcs12  -export -in client-cert.pem -inkey client-key.pem -out client.p12 -name "Whatever"
Enter Export Password:
Verifying - Enter Export Password:

[kabirlinux ~/tmp]
$rm -rf client*.pem

Now on my Mac I get the client.p12 file and import it into a jks keystore

[~/test]
$sftp kabirlinux
Connected to kabirlinux.
sftp> cd tmp 
sftp> get client.p12
Fetching /home/kabir/tmp/client.p12 to client.p12
/home/kabir/tmp/client.p12                                                                                                                                               100% 3094     3.0KB/s   00:00    
sftp> exit

[~/test]
$keytool -v -importkeystore -srckeystore client.p12 -srcstoretype PKCS12 -destkeystore client.jks -deststoretype JKS
Enter destination keystore password:  
Re-enter new password: 
Enter source keystore password:  
Entry for alias whatever successfully imported.
Import command completed:  1 entries successfully imported, 0 entries failed or cancelled
[Storing client.jks]

Again, I use 'test123' as the keystore password. Then on the rsyslog server we change /etc/rsyslog.conf to use 'x509/certvalid' instead of 'anon' for the InputTCPServerStreamDriverAuthMode directive, e.g:

$InputTCPServerStreamDriverAuthMode x509/certvalid

Next we add the client-certificate-store information to the syslog handler in the audit logging section of standalone/configuration/standalone.xml in the WildFly installation so it looks like:

<audit-log>
            <formatters>
                <json-formatter name="json-formatter"/>
            </formatters>
            <handlers>
                <syslog-handler name="syslog-tls" formatter="json-formatter" syslog-format="RFC5424">
                    <tls host="kabirlinux" port="514" message-transfer="NON_TRANSPARENT_FRAMING">
                        <truststore path="/Users/kabir/test/truststore" keystore-password="test123"/>
                        <client-certificate-store path="/Users/kabir/test/client.jks" keystore-password="test123"/>
                    </tls>
                </syslog-handler>
            </handlers>
            <logger log-boot="true" log-read-only="true" enabled="true">
                <handlers>
                    <handler name="syslog-tls"/>
                </handlers>
            </logger>
        </audit-log>

Now if you restart the rsyslog daemon and WildFly you should see the log messages come through again. So this means that you can host rsyslog on a machine not accessible by the people who have access to your WildFly installation. Communication between the WildFly installation and rsyslog is encrypted since it goes over TLS, and only users who have the correct certificate are able to send data to rsyslog.

Transylvania Java User Group Roundup

I just got back from the presenting JBoss Application Server 7 at the Transylvania User Group last night. I didn't know much about Romania before I went, but I was impressed by the friendly people and enthusiastic crowd at the event, and was taken very well care of by Gabriel Pop, the organiser, and the other locals. Everything was great apart from that the only direct flights between Cluj and London mean getting up at 4am both going there and coming back :-) The centre of Cluj was pretty, and the restaurants I got taken to were excellent.

We covered why JBoss AS 7 is so fast and had a demo introducing Java EE 6. A majority of the crowd were Spring users but the feedback I got indicated that they were impressed by the simplified programming model introduced in Java EE 6. I got a few chuckles when I complained that the initial start of the application server during the demo was slow, since it started in 2 seconds. Restarting it it started in the 1.3s I am used to on my laptop.

I then went on to explain and demo the JBoss 7 management model, and then revisited the original EE 6 demo and tested it using Arquillian before adding JAX-RS features to it and deploying it to OpenShift using a mobile HTML 5 client to interact with the server via JAX-RS.

The feedback was very good after the event, I had lots of people using JBoss AS 5.x, WebLogic, WebSphere etc. coming up to me saying they now wanted to move to AS 7. And thanks to the people who hung around for dinner afterwards, it was fun - and yes I did manage to get up for my flight after 3 hours of sleep!

JBoss AS 7 at Transylvania JUG

I'll be going to Transylvania to present at the Transylvania Java User Group on 13 March.

I'll be talking about the recently released JBoss AS 7. I'll cover the road to Java EE 6 certification, how we did the performance improvements and our brand new management layer. There will be plenty of demos taking a basic EE application, testing it and getting it working in the cloud with a HTML 5 client.

Hope to see you there!

JBoss AS 7 at Devoxx

I just got back from my first ever Devoxx, and it is a really great conference - I was very pleasantly surprised! The auditoriums for the main talks were amazing.

Dimitris, Pete, Carlo, Dan, Lincoln, Aslak, Andrew, Max and I (apologies if I forgot anybody, there were quite a few of us) did a BOF on JBoss AS 7 with good attendance and some great questions from the audience. In hindsight I wish I'd prepared some demos for anticipated questions though.

It was a very nice experience to hang around the JBoss booth and finally meet some real AS 7 users after having worked on AS 7 the past year and a half. Users of older versions of the application server seemed to be impressed by the much improved configuration and domain management of AS 7. From the chats I had that seemed to be the thing people were most impressed by/disliked the most in previous versions.

Then there were numerous other talks by the usual JBoss suspects, all of which were great and packed. Since I'm biased and work on AS 7 I loved Andrew Rubinger and Dan Allen's talk on AS 7, and of course Pete Muir's talk on OpenShift. There will be more blogs from the rest of the team on our jboss.org events page.

Getting started with JBoss Application Server 7.0.0 CR1 in minutes

JBoss Application Server 7.0.0 CR1 was released this morning (GMT). I'm sure Jason Greene, the AS 7 lead will post more details in the next day or two. In the meantime, I'd like to give you a very quick overview of how to get this up and running in a few minutes.

The most time-consuming step is to grab it from http://download.jboss.org/jbossas/7.0/jboss-7.0.0.CR1/jboss-7.0.0.CR1.zip (later releases will be accessible from the main download page http://www.jboss.org/jbossas/downloads).

Now go to your download directory and unzip it to somewhere, and then go to the jboss-7.0.0.CR1/bin folder:

[kabir ~/Downloads]
$unzip -q jboss-7.0.0.CR1.zip -d ~/AS7

[kabir ~/Downloads]
$cd ~/AS7/jboss-7.0.0.CR1/bin/



Now that the slow part is done, let's start it up in single server mode:


[kabir ~/AS7/jboss-7.0.0.CR1/bin]
$./standalone.sh
=========================================================================

JBoss Bootstrap Environment

JBOSS_HOME: /Users/kabir/AS7/jboss-7.0.0.CR1

JAVA: /Library/Java/Home//bin/java

JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman

=========================================================================

11:55:25,759 INFO [org.jboss.modules] JBoss Modules version 1.0.0.CR4
11:55:26,009 INFO [org.jboss.msc] JBoss MSC version 1.0.0.CR2
11:55:26,077 INFO [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
11:55:26,955 INFO [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
11:55:26,965 INFO [org.jboss.as.logging] Removing bootstrap log handlers
11:55:26,997 INFO [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
11:55:27,101 INFO [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
11:55:27,157 INFO [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
11:55:27,188 INFO [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
11:55:27,208 INFO [org.jboss.as.naming] (MSC service thread 1-4) Starting Naming Service
11:55:27,215 INFO [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 3.2.0.Beta2
11:55:27,229 INFO [org.xnio] (MSC service thread 1-3) XNIO Version 3.0.0.Beta3
11:55:27,248 INFO [org.xnio.nio] (MSC service thread 1-3) XNIO NIO Implementation Version 3.0.0.Beta3
11:55:27,518 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-2) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
11:55:27,539 INFO [org.jboss.as.remoting] (MSC service thread 1-3) Listening on /127.0.0.1:9999
11:55:27,575 WARN [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-2) Unable to set the URLStreamHandlerFactory
11:55:27,576 WARN [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-2) Unable to set the ContentHandlerFactory
11:55:27,590 INFO [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
11:55:27,593 INFO [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-4) Starting remote JMX connector
11:55:27,604 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
11:55:27,732 INFO [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
11:55:27,855 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) Bound data source [java:jboss/datasources/ExampleDS]
11:55:28,255 INFO [org.jboss.as.deployment] (MSC service thread 1-1) Started FileSystemDeploymentService for directory /Users/kabir/AS7/jboss-7.0.0.CR1/standalone/deployments
11:55:28,267 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 2750ms - Started 91 of 146 services (55 services are passive or on-demand)!

And that's it! JBoss Application Server 7.0.0 started in 2750ms. Leave it running for now.

Go to http://localhost:8080/ for the welcome page which contains links to our admin console and documentation. Our documentation is being created online at https://docs.jboss.org/author/display/AS7/Documentation and there is a fair bit of content already, but make sure you check in regularly since for our next release we will be focussing 100% on our documentation. The docs include a more extensive quick start guide than this.

To deploy applications one way to do it is to copy them to the jboss-7.0.0.CR1/standalone/deployments folder. Since this is not a Java EE tutorial, let's use the first example war I could find online:



[kabir ~/AS7]
$curl http://gwt-examples.googlecode.com/files/Calendar.war > Calendar.war
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 529k 100 529k 0 0 312k 0 0:00:01 0:00:01 --:--:-- 356k

[kabir ~/AS7]
$cp Calendar.war jboss-7.0.0.CR1/standalone/deployments/



Now in the terminal window where you started AS 7 you should see that the application has been deployed:


11:55:28,267 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 2750ms - Started 91 of 146 services (55 services are passive or on-demand)
12:05:13,713 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "Calendar.war"
12:05:14,262 INFO [org.jboss.web] (MSC service thread 1-3) registering web context: /Calendar
12:05:14,290 INFO [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "Calendar.war"


If you go to http://localhost:8080/Calendar you should see the deployed web app.

See the docs for more information about how to make JBoss AS 7 work for you!

And please report any issues at our users forum.