I want no monuments

These days I’m working with Spring Security 3

SS3 added the Spring Expression Language, a nice way of script boolean conditions into “access” attributes of your URLs and into @PostFilter annotations

The hidden part is that you could have used them even with the security:authorize tag in your JSPs IF they had added the element <expression-handler> as a child of the element <http>
That’s the only missing part since the code to handle it is already there.
So what? I took the spring-security-3.0.xsd, edit it to add the missing element, modified the schemaLocation of my security xml file and voilà: SpEL is alive and kicking even on JSPs

I’ve opened a ticket for that: the answer was that they deliberately turned it off for version 3 but no target version is set.

In the meanwhile I’ve also found a problem on the JMX lib of Jetty, and opened a ticket as well. Hope they could fix it asap.

UPDATE: indeed they fixed it! Thx to Michael Gorovoy

I don’t know either if I’m stupid or if the Pentaho developers are lacking of effort in helping poor conference speakers like me.

If you want to show someone the features of something, you have to set up a demo. And half the times these demos require data. And if you are setting up a demo for a business intelligence tool, data is essential!

Pentaho provides you with a dataset to use in demos and as a playground (thank you), but it’s quite difficult to set it up. An early adopter may judge this as project immatureness, while Mondrian is all but immature!

That’s what you need to set up the FoodMart database on PostgreSQL before demoing Mondrian (don’t try that with MySQL: it will take hours!)

First, locate a copy of these dependencies: log4j, eigenbase-xom, eigenbase-properties, eigenbase-resgen, commons-logging and postgresql-8.4-701.jdbc4.jar (or a suitable postgres jdbc driver): let’s say you have them in folder “mondrian/lib” and that you are in folder “mondrian”

Then write in a console:

java -cp .:lib/mondrian.jar:lib/log4j.jar:lib/eigenbase-xom.jar:lib/eigenbase-properties.jar:lib/eigenbase-resgen.jar:lib/commons-logging.jar:lib/postgresql-8.4-701.jdbc4.jar
mondrian.test.loader.MondrianFoodMartLoader
-verbose -tables -data
-jdbcDrivers=org.postgresql.Driver
-outputJdbcURL='jdbc:postgresql://localhost/mondrian?user=postgres&password=postgres'
-inputFile=demo/FoodMartCreateData.sql

Then wait for a minute.

Bah, maybe it’s just me, too comfy sat on ant and maven.

Tomorrow I’ll attend the first Italian Java Application Server Day, organized by Genova JUG.

See you there folks!

UPDATE: an unexpected problem prevented me from attending :( Hope to find the slides online, at least.

JRecordBind 2 is the JAXB of fixed-length files: using XML Schema to describe their structure, it’s able to both produce and consume them, letting the developer focus on the real task, that’s what to do with the data.

This is the final release, ready for production use.

I’ve asked the java.net admins to graduate the project, and I’m waiting for their reply.

Anyway the URL won’t change, so it’s safe to bookmark:
https://jrecordbind.dev.java.net/

The current stable version on JRecordBind (rev 58) is deprecated: the new version is on its way to stable status!

JRecordBind-2 will be based on JAXB: forget the .properties file and start describing the hierarchy of your fixed length file with XML Schema!

For what I want it to do now, it’s feature complete. It needs a refactoring, since the code is the ugliest I’ve ever written. Once done, I’ll update the documentation, announce the final release and ask java.net admins to get me out of the incubator.

Stay tuned!

I’ve just received the approval email for my latest java tool: JRecordBind.

If you are familiar with JAXB, JRecordBind is just the same (from a functional point of view) but it targets host files, a.k.a. “fixed length text files“.

If you are not familiar with (un)marshalling tools, let me present you JRecordBind.

When you need to import some fixed length file, you usually have an extensive documentation about which field is where. Something like

• from char 1 to 20 there are name and surname, filled with spaces
• from 21 to 28 the birthdate in the format YYYYMMDD

and so on.

Speaking XML, this is the XSD, the definition of the structure of the data file, with the types of each field.

JRecordBind needs you to write this definition into a “.properties” file.
The RecordBeanGenerator will then create a java bean suitable for storing each line of the data file.
The Marshaller object will transform this bean into a text line: that’s useful when you need to export data.
The Unmarshaller will do the contrary, that’s transforming every single line into a bean: useful when you need to import data.

JRecordBind allows the developer to focus of the varying part of such import procedures: how to spread imported data into a database. JRecordBind will care about reading/parsing/validating.

JRecordBind is still in the incubator since I plan to add multiline support (beans defined in multiple lines) and multibean support (different types of beans defined in different lines)

Nonetheless, it’s quite fast: on my pentium-m, unit tests have unmashalled 100.000 lines in 5 seconds.

If you want to blame me for this tiny little piece of code, drop me an email at federico _Oo_ fissore.org

A final note

I must admit that JRecordBind is currently compiled with Java 6. But it could be easily ported to Java 1.4. Do you think I should? My ego says “Noo! Java 1.4 is dead. Long live Java 1.4!” but since host files are old, maybe old 1.4 software could benefit of this tool.
Uhmm, I’m at a crossroad.

Today we host Vaclav Pech, JetBrains evangelist, that will show us the functionalities of IDEA, the famous IDE.

IDEA has always been one step ahead when talking about refactoring: it will be great to have Vaclav himself speaking to us about his product.

So: don’t miss it!

Despite my deficiencies as a meeting organizer, the January meeting (the very first one this year) has just been closed and it was a good one.

I finally managed to study SoapUI and to briefly show its functionalities in the quickie, while Bruno showed us the new features of Java SE 6: scripting could be real fun… I have to look deeper into it, especially considering my previous post.

As always, all the bits (slides and code) showed and used during the meeting will be available on the JUG wiki page in the coming days.

Now come nearer the monitor, because I prefer to whisper this: next meeting we’ll probably have a new location! Sshhhh!!! Don’t tell anybody!

Today I’ve had the pleasure to read InfoQ^[0] and its comments about Ola Bini’s^[1] opinion about the coming or not of a Next Big Language.

I share Ola’s opinion: no big language for your future, forget it.

Newer apps will be built with a mix of different languages, because each tool is born to solve one or few problems, and usually they are very good at it. Increasing software complexity will lead to a finer grained choice about which language best fits the problem to solve.

Question is: how do these languages communicate? Ola thinks they are all going to live on top of a JVM. That’s probably what will happen. Because that will make things easier.

That leads to the next question: will Java die? No. If we are going to stay in the JVM (and there is already evidence of it: JRuby, Groovy, Scala, Jython…) then we will gently move to these new worlds while keeping on using, developing, improving and investing on our solid code base.

I think no one can really predict the death of a language. We could only throw thoughts about what could change.

Language interoperability and polyglot programming could be good guesses.

Very good week, very good talks, very nice venue, wonderful croissants, very nice people, ugly photos! (photographer’s fault)

One nice note: a good number of talks was related to agile and there were always quite a crowd of people attending.