Grails: use a session scoped bean in a singleton bean

In my project, I had to change the scope of two of my services from the default scope (singleton) to as session scope. With grails, this is fairly easy, for a service, you simply have to add the following line in you service class:
static scope = 'session'

Now there's a problem if you use this service in a singleton scoped bean like a filter or a taglib for example. The problem is that spring will try to instantiate the singleton bean on startup, then it will try to create the service to inject it in the singleton, but as this does not occur in a session, spring cannot create the service and fails with a BeanCreationException. Anyway, even if the singleton was created within a session, the same service would be used for all sessions as the singleton wouldn't be re-injected for each session.

Fortunately, spring comes with the handy ScopedProxyFactoryBean. As its name implies, it is a proxy factory bean for scoped object. To use it, you first have to declare the service in grails-app/conf/spring/resources.groovy for an application or in the doWithSpring method of the plugin descriptor for a plugin:
sessionScopedService(SessionScopedService) { bean ->
bean.scope = 'session'
}

At the same place, declare the proxy factory bean:
sessionScopeProxy(org.springframework.aop.scope.ScopedProxyFactoryBean) {
targetBean = 'sessionScopedService'
proxyTargetClass = true
}

You can now use the sessionScopeProxy instead of the sessionScopedService in you singleton bean. It will transparently proxy to a session scoped SessionScopeService bean.

Grails: externalize configuration with jndi

Grails provides a very handy way to set configuration with Config.groovy file.

When developing internal applications, this solution is perfect especially with per-environment configuration.

For packaged third-party applications or complex multi-environment sites, it's harder to get a maintainable solution. Grails provides the grails.config.locations setting to load configuration from files possibly out of the application war file. The problem with this solution is to get a flexible cross-appserver cross-platform way to provide the custom config file to the application.

The solution presented here is to use jndi.

Let's say you want to provide a web service URL to an application, it will be made available to the application by the application server.

We will store the web service URL at the jndi name java:comp/env/wsUrl.

To access the value in the grails application, we will use a bit of spring magic by declaring a bean in grails-app/conf/spring/resources.groovy:

beans = {
wsUrl(org.springframework.jndi.JndiObjectFactoryBean){
jndiName = 'java:comp/env/wsUrl'
}
}

This will make the bean available with the value read from jndi, to use it, simply declare a variable named wsUrl in an injected object (controller, service...):
def wsUrl

For the development environment, if you use jetty, the value can be set by creating the web-app/WEB-INF/jetty-env.xml file with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<configure class="org.mortbay.jetty.webapp.WebAppContext">
<new id="wsUrl" class="org.mortbay.jetty.plus.naming.EnvEntry">
<arg>wsUrl</arg>
<arg>http://www.example.com/dev-ws/</arg>
<arg type="boolean">true</arg>
</new>
</configure>


If you deploy to a tomcat environment, you can set the value by creating a file conf/Catalina/localhost/<context-name>.xml in your tomcat installation containing:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Environment name="wsUrl" value="http://www.example.com/prod-ws/"
type="java.lang.String" override="true"/>
</Context>
If the parameter has to be set in multiple applications in the same tomcat instance, it can be declared in conf/server.xml file and referenced in each application .xml file with the ResourceLink tag.

BAF: soon something to show

It has been a long time since I last blogged. I was working hard on my new project: BAF.

BAF stands for Business Application Framework. As the name implies, it is a framework for building business applications. Of course it is built on top of grails.

People working with legacy 5250 application are used to have single sign-on, security management, modular applications. BAF is about bringing that (and more in the future) to web applications.

BAF is still in development, but you can already look at the git repository.

For more information, check the BAF page.

Deploying on Websphere Application Server 6.1 for i5/OS

The IBM official alternative to IBM Integrated Web application server for i is websphere application server.

By default, WAS uses the classic JVM, the problem is that, since version 1.0, grails doesn't work with the classic JVM. So to deploy a grails application on WAS, the instance must run with the IBM technology for java VM.

To switch an instance to the IBM technology for java VM, run the following command under qshell:

/QIBM/ProdData/Websphere/AppServer/V61/edition/bin/enableJvm -jvm std32 -profile profile

Where edition is the WAS edition you use.

To switch all instances, you can omit the -profile profile parameter.

Once the instance is switched, you can start it and deploy your app.

The rest is WAS administration

Deploying on IBM Integrated Web Application Server for i

Starting with i5/OS V5R4, you can get the Integrated Web Application Server v7.1. It is meant as a partial replacement for Tomcat which isn't available from IBM for IBM i V6R1 and up. The Integrated Web Application Server is a small footprint J2EE web server. For small CPUs (pre-power4 or partial power5 520s) or systems very low in RAM (less than 2GB) it can be very useful.

There are a few limitations to know about:

* You can have only one DataSource, its jndi name is jdbc/ProxyDS. But you can simulate multiple DataSource (more on this below)

* The DataSource pooling is done by Apache commons pool which is considered as quite slow

* You can only access DB2 for i (local or remote)

The server creation and administration is pretty straightforward via IBM Web Administration for i5/OS.

The default memory limit is very low, so complex webapp won't run out of the box, you're likely to get StackOverflowError. To increase memory limit, edit the /www/appserver/lwi/conf/overrides/i5javaopts.javaopt file and add a line with -Xmx1024m or more.

You can create several "Database connections" which will be made available to all application through the jdbc/ProxyDS DataSource. You assign each connection a "connection ID", one can be *DEFAULT. To get a *DEFAULT connection, you simply use getConnection() on the DataSource. To get a non *DEFAULT connection, you use getConnection(connectionID,null) on the DataSource. I will make further investigation to check if GORM is able to use a non *DEFAULT connection.

Don't forget to apply the latest HTTP PTF group.

Practical example: jtopen and webservice

At my job we are currently prototyping a monitoring solution. We use a packaged solution to monitor our Unix and Windows servers, our telecom equipments and our AS/400s.

For the AS/400, we want to check verify that our scheduler is up. The way to determine if it's running is to see if a given data area is locked. If it is locked, the scheduler is running. The question was: how to check this from the monitoring box? The first solution was to create a telnet script that would connect to the AS/400, and check if the data area is locked. Of course, this is not the good way to go, this should be considered as a last resort. The second solution was to create a java program on the monitoring package that would use jtopen (the library, not the plugin) to try to lock the data area. This would work but we would be tied between the monitoring solution program and the scheduler (think about updates...). The third solution was to use a web service. The monitoring solution is able to call a web service and take action depending on the result. With grails, creating the web service is so simple a monkey could do it (even I did it!).

The first step is to create a new grails application:

grails create-app monitor

Then we install the jtopen plugin:

grails install-plugin jtopen

For web service, there are several plugins available. I decided to go with xfire plugin, it is the simplest for me:

grails install-plugin xfire

We then create a new service:

grails create-service scheduler

We then instruct xfire to expose the service:

static expose = ['xfire']

We define an ibmI object that will be injected:

def ibmI

We then define the service method:

boolean isSchedulerActive(){

def cr = ibmI.execute("ALCOBJ OBJ((DTAARA *DTAARA *SHRRD)) WAIT(0)")

if(cr.success){

ibmI.execute("DLCOBJ OBJ((DTAARA *DTAARA *SHRRD))")

false

} else {

if(cr.messageList[0].ID == "CPF1002"){

true

} else {

throw new RuntimeException("Unexpected message "+cr.messageList[0].toString())

}

}

}

And that's it!

Let's give a closer look at the method:

def cr = ibmI.execute("ALCOBJ OBJ((DTAARA *DTAARA *SHRRD)) WAIT(0)")

This will try to allocate the data area, returning immediately if the lock can't be locked.

if(cr.success){

ibmI.execute("DLCOBJ OBJ((DTAARA *DTAARA *SHRRD))")

false

}

If the command ran successfully, it means that the data area was not locked. We immediately unlock the data area to avoid being bugged by a ghost lock and return false.

else {

if(cr.messageList[0].ID == "CPF1002"){

true

} else {

throw new RuntimeException("Unexpected message "+cr.messageList[0].toString())

}

}

If the command did not run successfully, we check the message ID returned by the command processor. If the message is a CPF1002, it means that the data area was already locked, meaning the scheduler is active, so we return true. If we have another message, then something went wrong and we throw an exception.

We just have to specify the as/400 host name, user and password in Config.groovy and that's it.

You can take your favorite soap client (I use Mac SOAP Client) and point it to the wsdl which is created by the xfire plugin at: http://localhost:8080/monitor/services/scheduler?wsdl and test the isSchedulerActive method.

And that's all. No boiler plate code, no infinite xml file to write, just strait to the code.

In a next post, I will talk about deployement.

Grails jtopen plugin 0.3 is out: user profile authentication

Release 0.3 of the grails jtopen plugin is out.

This new release features user profile authentication.

More information about how to use it in a future post.

http://grails.org/plugin/jtopen