Despite the fact that EJB inheritance sometimes uses Java inheritance — they’re not always the same. Just as you could read in my previous post, EJB doesn’t have to implement any interface to expose a business interface.
The other way around is also true — just because EJB is implementing some interface or extending other EJB doesn’t mean it exposes all or any of its views.

Let’s say we want to have some basic EJB exposing remote business interface. We then want to extend this EJB and override remote business methods.
Nothing fancy, right? But let’s take a look at some examples.

Continue reading

UPDATE (5.08.2013) – I’ve updated this post to support JBoss EAP 6.1 Final (JBoss AS 7.2). Enjoy

UPDATE (2.09.2013) – Bela Ban pointed to his very interesting post about new ForkChannel feature and easy channel hijacking directly from JBoss AS / Infinispan. Read about it here

JGroups is Bela Ban‘s piece of software for reliable message exchange that is highly configurable and can use either TCP or UDP as a transport protocol. Basically – you run the JGroups on number of clients, they form a cluster and they can send and receive messages within the cluster.

jgroups_logo_450px

JGroups is used internally by JBoss Infinispan. Infinispan, however, unlike JGroups adds the distributed cache semantics (replicated / distributed modes, entries invalidation, transactional behavior, Map access API, etc.) It even allows you to use the cluster as a compute grid.

Infinispan in turn is used to provide JBoss AS 7 clustering functionalities. Therefore, it means that the underlying JGroups subsystem can and is configured using a standard JBoss AS 7 standalone*.xml file. You can access Infinispan cache from your Java EE component (e.g. EJB) without any problems as described here.

However, there are cases when you’d like to use just the underlying JGroups messaging instead of all the cache semantics Infinispan gives you. And here’s the place things are becoming more complicated. You can always use JGroups directly and store the configuration for it as an application-local resources. It might become arguable if this is or isn’t a violation of the Java EE spec which says that an application should not manage low-level connections, spawn threads, open sockets, etc. This is something that is better to be left to the application server – it also allows us to use one configuration file instead of spreading it across multiple places.

So, the question is – how to access the JGroups subsystem from our EJB application? The whole solution involves few steps which will be described below.

Continue reading

When you create a deployment using Arquillian (great test runner for testing your Java EE code in the container of your choice: jBoss, Glassfish, OpenEJB, … either in embedded, managed or remote mode) remember that the name of the deployment archive file is the exact filename that will be executed in the container.

It does make a difference if you use *.war or *.jar for your deployment, so beware the following construct if it’s not exactly what you intended to do:

@Deployment
public static JavaArchive deploy() {
    JavaArchive ar;
    ar = ShrinkWrap.create(JavaArchive.class, "YourTests.war")
                   .addPackage(YourTestClass.class.getPackage());

    return ar;
}

In this case you can end with ClassNotFoundException for YourTestClass.
Just use the archive format you need (in this case I needed a *.jar and not a *.war) as this does make a difference for the application server.