This post is a little bit infantile, since it does present a really, really simple thing, but I wrote the shell code yesterday for a backup script and it seems as I will not need it. So I write it down here so either I do not forget it (who knows when it will come in handy?) or perhaps someone else says: “Hey my script could be much easier using this”. In the next days I will post the code that replaces the code shown in this post, so stay tuned.
Read More
Author: jonny
Standalone Tomcat with jBoss (2nd Edition)
This tutorial desribes, how to install and configure a standalone Tomcat, so that a deployed webapp can connect to a jBoss and use the authentication of the application server. This method is decoupled from the login module or authentication type (LDAP, Database, …), respectively. It differs from the approach described in Standalone Tomcat with jBoss plus authentication against LDAP, in that it allows for parallel logged in users and it does not need to authenticate to LDAP/Database on both sides, but on the jBoss only.
Generate HTML from Colored Terminal for Sharing Diffs
The version control system git has the nice feature git diff --color-words which shows on a word by word basis the changes, coloring new words green and deleted ones red. The script ansi2html.sh converts a colored xterm output to html. This way you are able to share your diffs with others: hello world example. For $latex \LaTeX$ you may use latexdiff, which highlights the changes in the generated PDF/DVI-output.
The Cartesian Product Read Issue
Building up a project with a JPA persistence layer requires some design decisions from you. Although the abstraction layer is meant to relieve you from the pain working with a relational database, you have to keep in mind that everything you do with your entities has somehow to be translated to the underlying resource and is subject to its constraints. Often the abstraction layer even adds constraints, since the OR-Mapper has to be independent from the concrete implementation of your resource and therefore can only use the intersection of the different sets of functions. Furthermore there are general solutions to many common problems that might be a lot of slower than a specialized implementation in some cases. In the last posts I tried to give some hints and advices, how a persistence provider — especially hibernate — can be configured, in order to overcome many of this problems. Still, you have to decide beside plenty others, when to use lazy- and eager-fetching.
Read More
Unit Test Your Persistence Layer
This post is an addition to the post Unit Test Your DB Schema and Named Queries. It shows how to use the TestNG Annotations in order to simulate a lightweight EJB container enabling you to test your persistence layer (DAO, entity classes and similar). If you are using JBoss 6 you may use the embedded EB container. EJB3Unit supports testing Enterprise Beans, too. But I couldn’t get the latter to run smoothly and I do not use the former, yet. So if you are still tied to the old Java EE 5 world you might benefit form this solution.
Read More
Script Your Remote Session Beans with Groovy
A JavaEE application with a multi-tier application generally has a presentation layer running in a servlet engine, a business logic layer running in a EJB container and a persistence layer facilitating JPA. During the development often there are occasions where a new functionality in the business logic (called backend from now on), which has no corresponding code in the presentation layer (let’s name it frontend), yet. So, what you need is a way to try out your code. This post shows you how to use the groovy shell to connect via JNDI to your remote session beans and call them in order to test your application fast. You may use it for a fast monitoring or maintenance API to your system, too. The groovy code of your efforts to test your code (monitor your application) may even be read from the history of the groovy shell and compiled into byte code. This code may be called from a test case or in a monitoring software (like nagios).
Read More
Unit Testing of DB Schema and Named Queries
It is essential to software development, that bugs or misconfiguration are detected as early as possible. Therefore, tests being run during the build process can help to detect problems before your software is applied in a productive environment. In a EJB 3.0 application you may validate your DB-Schema and your named queries in a unit test, by starting up the EntityManagerFactory. It is one of the fine new features of JPA 1.0 (related to CMP in EJB 2.x) that you are able to use it without a container in a normal Java application. For your test you need a jndi.properties in your classpath:
Read More
Cache Named Queries with Hibernate
In the last post (see organize your named queries) a nice way to organize named queries has been proposed. The advantages of using named queries in the first place is discussed in the mentioned post, too. Hibernate offers a nice way removing a big disadvantage of named queries or to be more precise of JPQL queries in general, as compared with associations of an entity. Query results are not cached by default, neither in the first level nor in the second level cache. But you may add a query hint in order to advise hibernate to cache the results. Fortunately, like for associations, the query cache does store the ids for resulting entities, so the first and second level cache is requested for the respective objects. If the values are not present in the cache they are retrieved from the underlying resource.
Read More
Organize Your Named JPQL Queries
Named queries have some nice properties. They are precompiled and therefore faster than their “normal” counterparts, encourage to use named parameters, make your code easier to read and avoid messing up your code with string concatenated queries. A nice addon is, that named queries are validated during the creation of the persistence unit. If you have a unit test (see unit test db schema and named queries), checking whether the entities represent a valid DB Schema, the named queries are validated, too. So, there will be syntactical as well as some static analysis (e.g. “exist all referenced entities?”) during the test phase, before your application is even packaged.
Read More
EAGER Fetch of Multiple Associations
Associations are fetched lazily by default. You may change this behavior by setting the parameter fetch=FetchType.EAGER of the annotation @OneToMany for example. This has the disadvantage, that the association is eagerly fetched each time the respective entity is retrieved from the underlying database. This leads to the so called cartesian product read issue since the respective association is retrieved with the query of the owning entity via LEFT OUTER JOIN (see JPQL and joins). So, a lot of redundant data might be retrieved from the database, since the OR-Mapper has no interception point where he can prevent to retrieve data cached already. Another way is to overwrite the lazy fetch type in a jpql query (see override fetch type). So the cartesian product read issue does still exist, but you can control when to eagerly fetch an assoctiation and when not.
Read More