I spent a few days in Portugal and took some pictures you might want to see.
If so, please take a look: Porto 2010. Thanks!
2010-05-28
2010-05-14
JBoss: web-app is not bound as a global element
The "Exceptions anyone could have..." series continues with:
Which is a deployment error.
The cause was an erroneous web-app declaration in my web.xml file. Here is the correct one:
I needed 2.4 to enable EL (Expression Language) by default. Versions 2.3 and lower of the Servlet API ignore EL.
web-app is not bound as a global element
Which is a deployment error.
DEPLOYMENTS IN ERROR
The cause was an erroneous web-app declaration in my web.xml file. Here is the correct one:
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <!-- ... --> </webapp>
I needed 2.4 to enable EL (Expression Language) by default. Versions 2.3 and lower of the Servlet API ignore EL.
2010-05-10
JBoss java.io.InvalidClassException: org.jboss.security.auth.callback.SecurityAssociationHandler; class invalid for deserialization
Just in case someone got this error:
I got this when deploying an EJB3 application that uses Hibernate 3 to JBoss Application Server version 5.1.0.GA. It also said:
Semi-useful, if you're in a mood for euphemisms.
JBossSX (which is a security framework) is a dependency coming from my jboss-as-ejb3 dependency (it's a Maven project that I'm creating).
jboss-as-ejb3 mixes up its jbosssx dependencies - it asks for 3 different versions (2.0.2.SP1, 2.0.2.SP2, 2.0.3.SP1). The earlier versions are known to have caused problems.
Therefore I decided to overwrite those Maven dependencies with my own. In other words, in my pom.xml, I added this:
It is explicitly provided by me and overrules the other ones. Fixed!
That's the entire pom.xml file:
I hope this helps if someone is in need.
I am studying Hibernate using this book: Java Persistence with Hibernate
It helps me run this website if you purchase this book using this link. Thanks!
java.io.InvalidClassException: org.jboss.security.auth.callback.SecurityAssociationHandler; org.jboss.security.auth.callback.SecurityAssociationHandler; class invalid for deserialization(Line breaks added for readability).
I got this when deploying an EJB3 application that uses Hibernate 3 to JBoss Application Server version 5.1.0.GA. It also said:
Exception in thread "main" java.lang.RuntimeException: failed on MarshalledValue(Line breaks added for readability).
Semi-useful, if you're in a mood for euphemisms.
The problem
JBossSX (which is a security framework) is a dependency coming from my jboss-as-ejb3 dependency (it's a Maven project that I'm creating).
jboss-as-ejb3 mixes up its jbosssx dependencies - it asks for 3 different versions (2.0.2.SP1, 2.0.2.SP2, 2.0.3.SP1). The earlier versions are known to have caused problems.
The fix
Therefore I decided to overwrite those Maven dependencies with my own. In other words, in my pom.xml, I added this:
<dependency> <groupId>org.jboss.security</groupId> <artifactId>jbosssx</artifactId> <version>2.0.3.SP1</version> </dependency>
It is explicitly provided by me and overrules the other ones. Fixed!
JBoss 5, EJB3 + Hibernate Maven pom.xml
That's the entire pom.xml file:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>nl.novadoc.sample</groupId> <artifactId>ejb</artifactId> <version>0.0.1-SNAPSHOT</version> <name>ejb Maven Webapp</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>javax.persistence</groupId> <artifactId>persistence-api</artifactId> <version>1.0</version> <type>jar</type> <scope>provided</scope> </dependency> <dependency> <groupId>org.jboss.jbossas</groupId> <artifactId>jboss-as-ejb3</artifactId> <version>5.1.0.GA</version> <type>jar</type> <scope>provided</scope> </dependency> <dependency> <groupId>org.jboss.security</groupId> <artifactId>jbosssx</artifactId> <version>2.0.3.SP1</version> </dependency> </dependencies> <build> <finalName>hibejb</finalName> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> </plugins> </build> <repositories> <repository> <id>jboss-maven2</id> <url>http://repository.jboss.com/maven2</url> </repository> </repositories> </project>
I hope this helps if someone is in need.
I am studying Hibernate using this book: Java Persistence with Hibernate
It helps me run this website if you purchase this book using this link. Thanks!
2010-05-06
HSQLDB File mode, shutdown=auto on exception?
I was playing with HSQLDB, which is a pure Java database engine. There is lots of articles on the Internet describing this technology and I don't intend to write another one. Instead, I will point out one of the important features and tell you what problem I got with it...
HSQLDB can run in two different modes:
One thing to mention is that there are several server modes, but that is not so relevant for us, because we are going to focus on the...
In this mode, you simply have a database at your disposal, but you don't have to run it yourself. HSQLDB will do it for you. There are several ways to achieve this.
So, as you can see, you don't have to run the database server, you just tell HSQLDB you want to connect to the database and it will be created and launched for you.
This is how you can specify the connection settings in your hibernate.cfg.xml file:
This is how you can run the Database Manager:
I don't have a persistence.xml example here because I haven't tried it yet.
So what's the difference?
In the Server mode you have a server, of course, which means that you can connect to it from outside with different applications.
In the Listener mode this is impossible, your database is somewhat embedded in your application and it's not accessible from the outside. This approach is also faster (no client-server communication is required).
There are two submodes for the listener mode.
With the Memory option you have no files, everything is in-memory and nothing is stored. This is useful for testing and caching purposes. And this is the JDBC URL you should use to get this effect:
The File option makes it possible to persist the actual results. However, many many people keep running into the same problem - their data is not persisted. This is the solution:
shutdown=true does it. What does it mean? It issues a SHUTDOWN command to the database when all connections are closed. Only that makes sure that your data will be saved. This problem does not occur in the server modes.
But then I realized there might be a problem - and there is a problem indeed.
In short: no. Look at this pseudocode.
Because operation 1 executes in a transaction, you would expect its result to be persisted even though an exception is thrown later on. And this is how it happens with HSQLDB when you are using server mode (and other databases too). However, in HSQLDB with the File mode on, when an exception occurs, nothing is persisted, whether shutdown=true is on or not.
That's wrong and not desired. Perhaps I'm missing something; I posted a question on the Hibernate Forum.
I have only been able to find one workaround. You are able to shutdown the database yourself, programatically.
A definitely better way would be to handle it with AOP (because if you just hardcode this call your application becomes tightly coupled with HSQLDB in the Listener File mode) with, for example, Spring Framework. I will try that some other time; meanwhile, my friend Jeroen has recently published a great intro to AOP.
I am not satisfied by this behavior but I guess I will have to live with that for now. I will use the server mode instead.
HSQLDB can run in two different modes:
- Listener mode
- Server mode
One thing to mention is that there are several server modes, but that is not so relevant for us, because we are going to focus on the...
HSQLDB Listener Mode
In this mode, you simply have a database at your disposal, but you don't have to run it yourself. HSQLDB will do it for you. There are several ways to achieve this.
- Specify the connection settings in your hibernate.cfg.xml file.
- Specify the connection settings in your persistence.xml file.
- Run HSQLDB Database Manager and ask it to connect to an in-memory engine.
- And more...
So, as you can see, you don't have to run the database server, you just tell HSQLDB you want to connect to the database and it will be created and launched for you.
This is how you can specify the connection settings in your hibernate.cfg.xml file:
<hibernate-configuration> <session-factory> <property name="hibernate.connection.driver_class"> org.hsqldb.jdbcDriver </property> <property name="hibernate.connection.url"> jdbc:hsqldb:file:filedb;shutdown=true </property> <property name="hibernate.connection.username"> sa</property> <property name="hibernate.dialect"> org.hibernate.dialect.HSQLDialect </property>(There's more to it, that's not the complete file).
This is how you can run the Database Manager:
java -classpath lib/hsqldb-1.8.0.7.jar org.hsqldb.util.DatabaseManagerSwing(Line break added for readability).
I don't have a persistence.xml example here because I haven't tried it yet.
Listener vs. Server
So what's the difference?
In the Server mode you have a server, of course, which means that you can connect to it from outside with different applications.
In the Listener mode this is impossible, your database is somewhat embedded in your application and it's not accessible from the outside. This approach is also faster (no client-server communication is required).
Listener: Memory vs. File
There are two submodes for the listener mode.
- Memory
- File
With the Memory option you have no files, everything is in-memory and nothing is stored. This is useful for testing and caching purposes. And this is the JDBC URL you should use to get this effect:
jdbc:hsqldb:mem:mymemdb
The File option makes it possible to persist the actual results. However, many many people keep running into the same problem - their data is not persisted. This is the solution:
jdbc:hsqldb:file:db\filedb;shutdown=true
shutdown=true
shutdown=true does it. What does it mean? It issues a SHUTDOWN command to the database when all connections are closed. Only that makes sure that your data will be saved. This problem does not occur in the server modes.
But then I realized there might be a problem - and there is a problem indeed.
Is SHUTDOWN issued when an exception is thrown?
In short: no. Look at this pseudocode.
1. Saving an entity in a transaction. 2. An exception is thrown after the transaction. 3. Application exits.
Because operation 1 executes in a transaction, you would expect its result to be persisted even though an exception is thrown later on. And this is how it happens with HSQLDB when you are using server mode (and other databases too). However, in HSQLDB with the File mode on, when an exception occurs, nothing is persisted, whether shutdown=true is on or not.
That's wrong and not desired. Perhaps I'm missing something; I posted a question on the Hibernate Forum.
Workaround
I have only been able to find one workaround. You are able to shutdown the database yourself, programatically.
org.hsqldb.DatabaseManager.closeDatabases(0);
A definitely better way would be to handle it with AOP (because if you just hardcode this call your application becomes tightly coupled with HSQLDB in the Listener File mode) with, for example, Spring Framework. I will try that some other time; meanwhile, my friend Jeroen has recently published a great intro to AOP.
I am not satisfied by this behavior but I guess I will have to live with that for now. I will use the server mode instead.
Subscribe to:
Posts (Atom)