Trouble with Black Screen in Parallels Desktop v9 with Linux Guest OS on Native Partition

jonny Leave a comment

This post is a follow up to Using Parallels Desktop v9 with Linux Guest OS in a Native Partition. After the successful utilization of an existing Linux installation in Parallels Desktop v9 you might want to install the Parallel Tools, in order to have a much nicer integration of the guest system.

But I had the problem, that right after installing the Parallel Tools for Linux AMD 64: The screen went black after the login, when the video driver had been loaded. So I uninstalled the parallel tools again and uninstalled all nvidia drivers which I had installed for dual boot use. Afterwards I reinstalled parallel tools and everything was fine.

Using Parallels Desktop v9 with Linux Guest OS in a Native Partition

jonny Leave a comment

Most of the time you use desktop virtualization, you simply add a virtual hard drive and install a guest operating system (like (K)Ubuntu Linux) in it. But some times – as in my case – you already have another operation system on a partition on your native hard drive. For a mac it’s either via Bootcamp or via something like rEfit enabling you to install a BIOS boot manager like Grub. Since it is kind of uncommon using such an existing partition for desktop virtualization, it is not supported (and documented) so good in the different virtualization solutions.
Read More

Task Queue for Heavy Weight Tasks in JavaSE Applications

jonny 1 Comment

Modern hardware systems have a multi-core architecture. So in contemporary software development concurrency is an even more crucial ingredient than before. But as we will see it is of great importance for single core systems, too. If you have already created a Java Swing application you’ve propably made an acquaintance with the SwingWorker, in order to delegate long running tasks from within Swing events to another thread. But first things first. In Swing the whole painting and event handling of the graphical user interface is executed in one thread the so called event dispatching-thread from AWT the underlying former window toolkit from Java. Therefore most of Swing-based methods are not thread-safe, meaning that you have to prevent race conditions by yourself, but it offers the possibility to dispatch tasks to the event-dispatcher thread. It is highly recommended to do everything, that updates the GUI in the corresponding thread.
Read More

Exception Handling for Injection Interceptor

jonny Leave a comment

Remember my post “Circular Injection of Util Classes in EJB 3.0“? There I offered a some kind of ugly solution to the circular dependency problem for managed classes in Java EE 5. In a preceding post (Circular Dependencies of Session Beans) I grumbled about the exception handling in jBoss-5.1. It lets you alone with a meaningless error message and you have to guess what the problem is. Unfortunately my own code presented in the former post is even worse, since it logs problems but ignores them. It wasn’t mentioned for productive use, but it was annoying to me, so here is a little tune up adding exception handling and readable error messages.
Read More

Inject CDI beans into Tapestry-5.x e.g. in Jboss-7.0.2-Final

jonny Leave a comment

As I explained in “Inject Java EE Beans into Tapestry-5.x“, the AppModule offers a way to configure Tapestry Web Applications directly in Java. In that post, we injected Java EE Beans into Tapestry applications. This time we do the same with Context and Dependency Injection (CDI) Beans. It follows the same procedure. The only difference is the way of looking up a bean. We still use JNDI for a lookup, but this time we retrieve the CDI BeanManager. In a second step we get the bean. For performance reasons we retrieve the bean only once per Thread (see annotation @Scope). It will be cached for subsequent lookups.
Read More

CDI and Transactions e.g. in JBoss-7.0.2

jonny 4 Comments

In Java EE applications you are safe to consider that every method in a session bean has an associated transaction, since there is an implicit declaration of the transaction attribute required. If you like to change this behavior you have to configure this proactively by adding the annotation @TransactionAttribute with another value (see enum TransactionAttributeType). Context and Dependency Injection (CDI) does not have such an implicit declaration and no direct container managed support for transactions. But it has a very nice realization of the interceptor concept. This post shows, how to facilitate an interceptor in order to add a transaction to every (or a selection) method in a CDI bean, if it does not already exist. This is the default behavior of required.
Read More

Circumvent Nested Transaction Issues in Tapestry-5.x

jonny Leave a comment

Ajax component events may be wrapped in a transaction as I pointed out in “Transaction Handling for Ajax Components in Tapestry-5.x“. But on some occasions an Ajax component event is surrounded by a component event. So the code in the ControllerUtil of article “Transaction Handling in Tapestry5” will lead to ‘transaction already active’ problems, since we try to begin a transaction in the nested ajax component event although there is already an active transaction attached to the current thread. We can overcome this situation by checking, whether an active transaction is present and begin/commit/rollback a new transaction iff not. This behavior is similar to the default transaction attribute REQUIRED in Java EE.
Read More

Transaction Handling for Ajax Components in Tapestry-5.x

jonny Leave a comment

In “Transaction Handling in Tapestry5” I described, how to configure transactions wrapping a complete page or component render request. The same is necessary (possible) for Ajax components. Besides having less transactions and sharing the first-level-cache for subsequent calls, this realizes the “Open Session in View Pattern” automatically. So you can access the database lazily via getter from an entity, for example, without running into lazy loading exceptions due to the fact that the transaction has been closed and the entities are detached already.
Read More

Inject Java EE Beans into Tapestry-5.x

jonny Leave a comment

Tapestry uses it’s own Inversion Of Control (IOC) container. Tapestry pages are not Servlets or Servlet Filter (and not another managed class). Therefore they cannot be used for injection of Java EE Beans. But there is the AppModule, which is conceptual some kind of related to Spring Java Config. It allows to configure the Tapestry application directly in Java. Like everything in Tapestry it has an Adaptive API. Hence you have to follow a naming (signature) pattern for your methods and Tapestry finds them. You don’t have to implement an interface.
Read More