This is a brief note on new the filter support in Scalamodules 2.0. I humbly suggested this functionality to Heiko, and it’s coming in the new version. (It is also on github now, of course.)
What are OSGi filters? Well, they are a subset of LDAP filters, which you most likely aren’t familiar with, unless you’ve dabbled in various black arts of enterprise. They are expressions that can be matched against service registrations in OSGi. Registrations are usually decorated with simple service properties on the familiar name/value form. For instance:
Very familiar, I’m sure. Incidentally, this is represented in OSGi with an old-school Java Dictionary. Don’t worry, non-masochistic Scalamodules users won’t ever see that. Here’s a filter that matches it:
You get the general idea. There is negation and or as well as the and, and the usual set of operators. See the OSGi spec for full details.
OK, so how is the filter represented in OSGi? Answer: It’s a String.
If you silently go “eew” inside now, read on. Again, we feel that Scalamodules users shouldn’t have to see it.
Sure, strings are fine, but this is still something that needs to be a well-formed expression. So why don’t we add programmatic support for it, to ensure both the well-formedness and possibly other constraints? It’s sort of a reverse parser – instead of getting the AST out of an expression, we build the AST and produce the expression as a String when it is to be used.
Here are some ways to build the filter in Scalamodules. First, we import the Filter object:
The below is one of the nicer constructs; it uses Scala-style API pimping to provide implicit conversion to a builder object, which supports the
=== and its peers:
("foo" === "bar") && ("zot" <== 10)
Direct use of the Filter methods instead would be:
and(set("foo", "bar"), lt("zot", 10))
set("foo", "bar") and lt("zot", 10) set("foo", "bar") && lt("zot", 10)
Note that arguments don’t have to be strings, they can be anything that turns into a reasonable string with
toString, including primitives.
set method, which becomes a
(foo=x)-style equality filter, actually takes varargs. Passing no arguments indicates a present filter, which is a convention for asking if the variable is set:
This turns into a
(foo=*) filter, which is interpreted by OSGi as any value. While the following is a multi-value filter:
Filter.set("foo", 5, 6)
This turns into
(foo=[5,6]), which requires that
foo is one of the two values.
So why all this brouhaha? The motivation for all this is simply to make filter construction a more reliable and verifiable process than simply putting together strings, which (at least when I do it) is error-prone and sometimes code-intensive. If it gets bad enough, I usually end up with small string-construction frameworks to do this for me, anyway. And we want to fail fast – detecting and reporting errors as early as possible. Let’s just sayt that not all OSGi implementations produce the best error messages on malformed filters.
But wait! What if you have a filter string? Suppose you got it as an input from somewhere. You don’t want to have to parse it and pick it apart, only to reconstruct it programmatically! The
Filter.literal method handles the case where you get a valid filter from somewhere else, and want to use it verbatim. So if you have a string you’re happy with, you can turn it into a filter and we’ll take your word for its validity. However, it might fail later, when and if it is passed to OSGi and you’ve been less than diligent.
This post is an overview and not a reference manual, we (will) have scaladocs for that. But the above should give and outline of the general idea – I hope.