Thursday, February 26, 2009

Hibernate: QueryException: could not instantiate: (updated)

I was doing some queries today in EJB-QL on JBossAS (which uses Hibernate as persistence provider).
And for a query that was nicely working in the Jopr Gui, I got errors in the test suite:


javax.ejb.EJBTransactionRolledbackException: java.lang.IllegalArgumentException: org.hibernate.QueryException: could not instantiate: com.acme.Foo
at ...... ( a lot ) ....
Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: could not instantiate: com.acme.Foo


Ok nice - Hibernate can not instantiate my class because it can not instantiate my class. So what?

After looking some time at this and debugging around I found out that the issue was the following. But before I show you the code, let me assure that IntelliJ flagged it as valid and it did work in the UI.

But now the code:


SELECT new com.acme.FOO(res.name, res.id, ... , parent.name, parent.id)

FROM Resource res

LEFT OUTER JOIN res.parentResource parent

...

WHERE ...


The constructor of com.acme.Foo looked like this:


Foo(String res.name, int res.id, ... , String parentName, int parentId) {}


This is all valid,

but:

It can happen for Resources at the root of the hierarchy to not have a parent (when they are roots). And in this case, parent is null and Hibernate is looking for a constructor to pass NULL in as last argument, which does not fit for 'int'. Thus the failure to instantiate the class.

The correct constrctor looks like this:

Foo(String res.name, int res.id, ... , String parentName, Integer parentId) {}

(of course you need to update the respective property within Foo too).

Conclusion:
Just to get it straight: Hibernate is doing the right thing - it's only not easy to find out what is going wrong.




Tuesday, February 24, 2009

Cups error on Leopard: "Missing filter"

Today I was trying to print some files over the printer attached to my mac mini. All I got were pages with errors


ERROR: undefined
OFFENDING COMMAND: csq
I thought first the word processor is sending crap, but after some investigation I found out that the issue is that the generic postscript printer driver is used and not the Laserjet one. Ok, went to preferences and changed the printer to use the Laserjet driver. But still no avail - now the printer even showed up as "not ready" :-(

Looking at /var/log/cups/error_log showed the following:

E [24/Feb/2009:11:02:59 +0100] Unable to execute /Library/Printers/hp/filter/hpPostProcessing.bundle/Contents/MacOS/hpPostProcessing: Operation not permitted
E [24/Feb/2009:11:02:59 +0100] [Job 50] Unable to start filter "/Library/Printers/hp/filter/hpPostProcessing.bundle/Contents/MacOS/hpPostProcessing" - Operation not permitted.

Looking at the two files showed that the x-Bit was missing from them. chmod +x solved this and now the printer is up and running nicely :-)


Thursday, February 19, 2009

Postgres/Hibernate sql fun - NOT

This probably isn't really a postgres, but a more general issue, but then ...

I was writing some stuff in EJB-QL and all I got from Postgres was

ERROR: could not identify an ordering operator for type record
SQLState:42883

This sucks of course :)
After some trial and error I found the following in my query:

group by resource4_.NAME , ... , (measuremen1_.TIME, measuremen1_.ID)

Removing the parens ('(',')') finally made the query run successfully.

Now you may ask, what was the input that led to this? Well, here is is:

SELECT new Foo(a.id, b.id, ..., bla.id, bla.time)
FROM .... , org.acme.Bla bla
GROUP by a.id, b.id, bla

So the query translated the bla in the GROUP BY to (bla,id, bla.time) - including the parens. Explicitly listing bla.id, bla.time in the GROUP BY clause solved this.
This is no fun, as the EJB-QL Query got correctly translated and postgres does not give any hint, what part of this longish SQL it does not like.


MacDeveloper

Are you interested in testing Mac software? You can do so at MacDeveloper.net. I met this site when reporting issues with Trailrunner and the TR autor pointed me to this site, where he has just opened an account.
Meanwhile MD is getting traction and new projects are popping up every week.

And - your time is honored: when you find an issue that is accepted by the developer, you will get points for this. If you have enough points, you will get a rebate on the license or even a license for free -- this depends on the developers and each individual project.


Tuesday, February 03, 2009

Upcoming speaking engagements in March '09

I have been invited by two German Java user groups to talk about RHQ, Jopr and JBoss ON. The talks will be as following:



Both talks are special to me: As I studied in Karlsruhe, I will be talking in the same lecture auditorium in which I used to sit and listen to Professors talks some years ago. The user group in Düsseldorf will record the session and make it available on the web later on.

I am looking forward meeting as many as possible of you.

Monday, February 02, 2009

New OOB subsystem in RHQ

RHQ had since its inception the concept of Out-of-bounds (OOB) metrics. Consider the following diagram:

oob_example


Here we have measurement values denoted by the green and red vertical bars (actually those are aggregates over several values as e.g. seen in the 1h tables). In addition to the values we have a band of 'good' or 'allowed' values (e.g. the typical variation of disk space used).

The measurement values marked in red have outliers outside of the band and thus trigger OOB conditions.

In previous RHQ versions, we were computing the OOB violations against the live data coming into the system, which was expensive on large scale systems. And if you had a violation every minute, the counter was showing you 3600 violations a day - but it did not tell you if those were severe conditions or just tiny little ones.

For the upcoming version of RHQ (or in svn HEAD) we revamped the system in a way that it calculates the OOB conditions from the hourly data table, that already has an aggregation of data from the last hour. Instead of recording the count of OOBs, we are now computing a factor. This is just a number that tells you how severe the violations are. A higher number means more severe. This could come from a one time big violation or from many smaller ones.

The new subsystem view will show you a table about the known OOB violators sorted by severity. You can then go to the individual metrics big charts and if you want also manually set a larger band. Resetting the band will automatically clean out the now obsolete OOBs, as will the automatic recalculation of baselines.

If you want to know more, have a look at the design page and the documentation jira entry.