Ignoring JPA Annotations in Vaadin Forms?

Hello everyone,

So far I’m really impressed with Vaadin! The visual appeal of the controls is fabulous; the client side awareness of things like communications difficulties & timeouts is brilliant, and there is a wealth of information available in these forums.

I have been working with Vaadin as a possibe GUI for an application for a little while now, but I’ve come up against a few problems and cannot find a way around on my own.

The Server App:

The server Application is an EJB3 app, running on a Glassfish server. The Vaaadin GUI app connects via a remote SLSB; and that remote session bean is the only interface between the 2 apps.

The required entity beans have been extracted into a client side JAR, which is part of the library for the client app.
NB: All the Annotations are intact in the client side JAR. They are literally the same beans from the server app.

All data changes are managed from the server app; the front end is truly just the GUI. I have a different AJAX front end working, but Vaadin is so compelling that I am very keen to complete a proof of concept and move to full blown implementation!

Data binding has always been an issue in AJAX frameworks ( I had to implement my own with the previous framework I was using. Nasty!) so I really want to see that functionality in action with my system.

As a trial I have been working on a form to display & update Person information. I have successfully implemented the login process from the Vaadin client to the glassfish back-end, and also successfully retrieved a person into a form.

I have also retrieved a few of the lookup table contents into some Combo boxes (via IndexedContainers as per several examples), which as part of the form. In the database, these lookup tables are FK relations for the Person table: Gender, Language, Title, etc.

And the results are visually beautiful!

My problem is that when I commit the changes a whole slew of hibernate errors are being generated! The annotations are being read and attempts are being made to action them. I most definitely do not want this to happen - all the data and persistence are handled back in the appication server.

It’s got me stuck - I’ve seen a few different posts that are broadly similar in nature, but not quite the same concerns.

So my questions are:

  1. Do I have to remove the JPA annotations from my entities in order to use them as POJOs in Vaadin? (There are about 50!)

  2. Can I programmatically disregard/ignore the annotations & just use my entity beans as ‘pure’ POJOs ?

  3. Should I be using specific classes or interfaces that are not annotation/relationship aware?

  4. (Not the same topic but I’m on a roll!) If I want the application to reset if anyone refreshes the browser screen - what do I do? Is this a config setting or an application startup process/parameter that I must deal with?

I realise that this is a lot different to the other reuests I’ve read (usually asking you to increase the JPA/Hibernate support!) but it would be so much help I can’t being to explain.

Many thanks,

Chris.

Chris, do you mean hibernate trying to process annotations on a client side, like validate them, etc ? Or some code inside Vaadin gets confused from annotations ? Actually, annotation needs to be processed by some other code, so just annotated class in another JVM should work as usual.

We’re using almost the same environment and do not see such problems. The only downside is that you had to have hibernate / jpa jars when compiling your web application even it does not use hibernate/jpa - because of annotated beans.

As for questions #1,#2 and #3 - In our experience there are still some problems with the JPA entities excessively used outside the container (lazy things, mass updates, etc) so we’re looking to continue use TO’s for remote interfaces and facades. But this does not relates to your problem, however. So would you please describe what exactly happens in your webapp layer. Could it be you left the PU xml descriptor in your webapp and glassfish is trying to run the persistence and process annotations ?

And as for #4 - Vaadin is a server side framework and all state is also stored on the server. So browser refreshes does not break the applicaiton. You may, however, play with the session lifetime and cookies - if session cookie will expire on a refresh - an application state will be lost and reset. As another solution (better to my mind) is to have a refresh/reset button in your application UI to perform the desired operation. May I ask you a question - for what reason do you need to reset application state on a browser refresh, maybe there are other better ways to achieve your goal ?

Dmitri

Hi Chris,

My instant reaction to 1,2 and 3 is that Vaadin (as it stands) knows nothing at all about Hibernate or JPA annotations (unless you are using some custom containers that do); where are the hibernate errors being generated from? If you are not deploying hibernate in your webapp, they can’t be coming from hibernate!

Is it possible that the errors are actually happening in the App server, but it appears like they are appearing in the Vaadin webapp?

Can’t help on 4), as I’ve not had to do this yet (intercept refresh)

Cheers,

Charles.

As others already answered for 1, 2 and 3, Vaadin itself ignores these annotations

Most Hibernate objects can be used as simple, detached POJOs. However, what I suspect is happening is that you are using Hibernate lazy fetching from the database in your entities. In this case, your fields may contain Hibernate proxy objects (instead of the real objects) that load data only when it is accessed. When you pass such an object from one server to another, the object will be in a “detached” state in which these proxies do not work.

Where are the errors triggered? Are you taking any special actions in your commit? Are you using the default Items from IndexedContainer or some custom Item/Container classes?

The HbnContainer incubator project does use Hibernate, but I understand you are not using it.

As for 4: one simple option that does not guarantee this to happen but is easy to implement: start the application with the URL parameter “?restartApplication”. Whenever such a URL is reloaded, the application is restarted.

If you really need to take the control out of the hands of the client (browser), you might need to close the application yourself when reloading the page, which is a little more tricky. There might be examples on that elsewhere on the forum, or maybe someone remembers how to do this.

Hi Dmitri,

Yes, I was thinking that the results appear as if hibernate is trying to persist my changes as soon as I call commit on a form - when all I wanted to do was pump the changes back into my Person bean for shipping back to the app server etc etc.

I was hoping that Vaadin was not trying to interpret any JPA annotations. Now I know it’s all my fault :slight_smile:

It’s entirely possible that I’ve left the PU details hanging around.

I’ll gather some more info & error messages etc and post tomorrow night (getting too late here in Brisbane)

My thought was to invalidate sessions etc on a refresh simply for security if someone walks away form the computer without logging out & someone else sits down…but I suppose a short session time would achieve the same result. Perhaps a timing task to listen for no activity for 5 mins…then logout for you… Anyway, something like that.

Thanks for the pointers & I will send some more info about the errors. You’ve got me thinking now.

Chris.

Chris, yes, logs may help. As also Henri said, this could be a lazy field initialization problem as well. So let’s look at the error traces.

Regarding the session invalidation if someone walks out - just set the appropriate http session lifetime - so if anyone walk out for, say, more than 10 minutes from a computer - session will expire and any other movement in UI (not only refresh) will result in session expired error.

And you can put all your resources invalidation code into your application’s close() method (simply override it) - it will be called by Vaadin when a session is expired, so you may cleanup any connections, ejb’s, resources, etc there.