Had a interesting need to do validation on two fields and ensure one or the other had (valid) input.

Here’s what the code looks like:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20

class Resource {
    String url
    String data

    static hasMany = [views:View]

    static constraints = {
        url(nullable: true, url: true, validator: { val, obj ->
            if (obj.url == null && obj.data == null) return ['url OR data required.']
        })
        data(nullable: true, maxSize:5000, validator: { val, obj ->
            if (obj.data == null && obj.url == null) return ['url OR data required.']
        })

    }

    String toString() {
        this.id
    }
}

Nothing spectacular…just simple.

I had to do a bit of Java magic to get to the “right” classpath when trying to use the AutoActivator.AUTO_START_PROP to load external OSGi bundles. It took a bit, and I finally found the solution hidden in the depths of the Felix mailing list.

I’m actually starting Felix from inside Grail’s BootStrap.groovy file, so here’s the snip of code:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28

def configMap = new StringMap(false)

        configMap.put(FelixConstants.EMBEDDED_EXECUTION_PROP, "true")

        configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES,
            "org.osgi.util.tracker; version=1.3.2," +
            "org.apache.felix.shell; version=1.0.2," +
            "javax.swing.border;," +
            "javax.swing.event;," +
            "javax.swing.table;," +
            "javax.swing.tree;," +
            "javax.naming;," +
            "javax.naming.spi;," +
            "javax.net;," +
            "javax.net.ssl;," +
            "javax.sql;," +
            "javax.swing;," +
            "org.osgi.framework; version=1.4.0," +
            "org.osgi.service.packageadmin; version=1.2.0," +
            "org.osgi.service.startlevel; version=1.1.0," +
            "org.osgi.service.url; version=1.0.0,");

            def bundles = 
            this.getClass().getClassLoader().getResource("WAR-INF/lib/com.springsource.org.hsqldb-1.8.0.9.jar").toString() + " " +
            this.getClass().getClassLoader().getResource("WAR-INF/lib/org.apache.felix.shell-1.0.2.jar").toString() + " " +
            this.getClass().getClassLoader().getResource("WAR-INF/lib/org.apache.felix.shell.remote-1.0.2.jar").toString()

            configMap.put(AutoActivator.AUTO_START_PROP + ".1", bundles)

“The memo will also confirm that it is acceptable for an agency to contribute source code back into a public open source project. It is acceptable, Risacher qualified, assuming the agency has the rights to the code, that releasing the code is in the government’s interest and that sharing the code does not violate any other government restrictions, such as the International Traffic in Arms Regulations (ITAR). Risacher also cautioned that government employees may not copyright any work that they do, so any contributions will be in the public domain.”

Taken from:

This great article

Now, all we need is an nice “incentive” for contractors to produce OSS. Hello, Mr. CIO. Might I suggest some leverage…

The saga continues. In my quest to integrate my business logic inside OSGi modules/bundles I’ve had to “rig” up a few interfaces. In a previous post I looked at launching Felix from Grails. More importantly I discovered how to query for OSGi-based services, and subsequently get access to the Java interfaces.

Now, the tricky part. Getting the results back to Grails’ ORM, GORM. I knew that was going to be tough, and based on the lack of information…decided that it wasn’t worth the effort. So, I started thinking Hibernate access to the HSQLDB setup underneath GORM. Well, with Hibernate being Hibernate ultimately decided that it wasn’t worth the effort just to process a few SQL commands. That leaves me with generic JDBC access to the HSQLDB. Not a problem…as long as there is only one connection. Grails’ development environment works in an in-memory DB configuration which prevented me from even trying to get to it from the OSGi framework bundles.

Here we go. Grails, is a web application framework built with Groovy on top of Spring, Hibernate and a other gooey stuff. Felix, is an OSGi (rev. 4) implementation under the Apache umbrella.

I need a sophisticated infrastructure of modular components to home some complex business logic (algorithms). I also need a service-oriented front-end that can easily support HTTP, WS and JMS. ReST is a byproduct that will gladly take with Grails’ convention. The ORM layer in Grails, GORM, is another nice benefit – because working with (read against) Hibernate sucks. The questions start. How do I get Grails (specifically the controllers) to talk to services registered inside the OSGi framework? Then, how do I get my OSGi service to interact with Grails’ ORM/database? Well, I’ve figured out the first part…and, honestly I’m sure others have as well. I owe a beer or two to a few of the guys working at my home office for answering a few of my “sub” questions, without even knowing it [you know who you are]. And, Cheers to James Lorenzen for the late night pointer to Grails Services.

Just teasing. Hehe.

No seriously, for whatever reason there are those few things that come around (technically) every once and a while that just make me giddy. It was embedded systems, then it QNX, then it was Integrity, then is was ActiveMQ/ServiceMix, throw Ruby in there some where – and now it is OSGi (again).

I have a couple of cool project spinning these days – and totally divergent. One is in the “enterprisy” space and the other is in pervasive devices/ubiquitous computing. The common denominator is OSGi, and there’s no irony here. Unfortunately, I can’t talk at all about the latter project – but the former probably can leak a few details here and there. One of the things that is really interesting about this project is that its current form is seriously broken. Not just broken functionally, but from a developmental perspective too (code, compile, test, deply, test, code, blah, blah). It is just too damn hard to build in modularity where it is needed, and integrate external and internal interfaces, while maintaining simplicity. The needs are not great, nor complex. But, the implementation dwarfs the needs, and the complexity went through the roof. And we are just now considering persistence. Soooo.

Enter the need for an off-the-shelf framework. Grails? Yes, because we are a predominantly customer-driven, and agile environment; the customer prescribes Java. Grails affords us the potential support many different external interfaces including ReST (default), WS/SOAP, and JMS. Nevermind the beauty of GORM’s abstraction to Hibernate.

Behind Grails comes OSGi. Not beneath, or around – but behind. We need a service infrastructure to house extensible algorithms. Sure we could go the strange world of ESBs (and we do have the JBI expertise in house). But, we don’t need that overhead. OSGi allows us to provide a nice package around a simple API pushing the extensibility with absolute modularity and scalability (with cool stuff like hot-deploy).

Both Grails and OSGi are well-blogged topics and I don’t intend to rave and praise them. Over the next couple of days I’ll drop a bit more, in detail, about how I’m going about integrating the too. I suppose I should state that I have given zero thought to getting Grails OSGI bundle-ized. That’s just not something at this point that I really want to think about. But, is an interesting notion – and does make sense because it would afford us a bit of independence from any one OSGi framework. We are using Felix, really just because it is an Apache project and it is a little less coupled to any major project like Equinox is to Eclipse.

More to come…