Reconnecting JMS listener to JBossMQ

We have a Java listener that reads text messages off of a queue in JBossMQ. If we have to reboot JBoss, the listener will not reconnect and start reading messages again. We just get messages in the listener’s log file every 2 minutes saying it can’t connect. Is there something we’re not setting in our code or in JBossMQ? I’m new to JMS so any help will be greatly appreciated. Thanks.


You should implement in your client code javax.jms.ExceptionListener. You will need a method called onException. When the client’s connection is lost, you should get a JMSException, and this method will be called automatically. The only thing you have to look out for is if you are intentionally disconnecting from JBossMQ– that will also throw an exception.

Some code might look like this:

    public void onException (JMSException jsme)
        if (!closeRequested)
            this.establishConnection(connectionProps, queueName, uname, pword, clientID, messageSelector);
            //Client requested close so do not try to reconnect

In your “establishConnection” code, you would then implement a while(!initialized) construct that contains a try/catch inside of it. Until you are sure you have connected and subscribed properly, stay inside the while loop catching all JMS/Naming/etc. exceptions.

We’ve used this method for years with JBossMQ and it works great. We have never had a problem with our JMS clients not reconnecting after bouncing JBossMQ or losing our network connection.


Tomcat vs Weblogic JNDI Lookup

The Weblogic servers we are using have been configured to allow JNDI datasource names like “appds”.

For development (localhost), we might be running Tomcat and when declared in the <context> section of server.xml, Tomcat will hang JNDI datasources on “java:comp/env/jdbc/*” in the JNDI tree.

Problem: in Weblogic, the JNDI lookup is “appds” whilst in Tomcat, it seems that that I must provide the formal “java:comp/env/jdbc/appds”. I’m afraid the Tomcat version is an implicit standard but unfortunately, I can’t change Weblogic’s config … so that means we end up with two different spring config files (we’re using spring 2.5) to facilitate the different environments.

Is there an elegant way to address this. Can I look JNDI names up directly in Tomcat? Can Spring take a name and look in both places? Google searches or suggestions would be great.


JndiLocatorSupport has a property resourceRef. When setting this true, “java:comp/env/” prefix will be prepended automatically. So I believe it would be correct to differentiate this parameter when moving from Tomcat to Weblogic.


String concatenation: concat() vs “+” operator

Assuming String a and b:

a += b
a = a.concat(b)

Under the hood, are they the same thing?

Here is concat decompiled as reference. I’d like to be able to decompile the + operator as well to see what that does.

public String concat(String s) {

    int i = s.length();
    if (i == 0) {
        return this;
    else {
        char ac[] = new char[count + i];
        getChars(0, count, ac, 0);
        s.getChars(0, i, ac, count);
        return new String(0, count + i, ac);


No, not quite.

Firstly, there’s a slight difference in semantics. If a is null, then a.concat(b) throws a NullPointerException but a+=b will treat the original value of a as if it were null. Furthermore, the concat() method only accepts String values while the + operator will silently convert the argument to a String (using the toString() method for objects). So the concat() method is more strict in what it accepts.

To look under the hood, write a simple class with a += b;

public class Concat {
    String cat(String a, String b) {
        a += b;
        return a;

Now disassemble with javap -c (included in the Sun JDK). You should see a listing including:

java.lang.String cat(java.lang.String, java.lang.String);
   0:   new     #2; //class java/lang/StringBuilder
   3:   dup
   4:   invokespecial   #3; //Method java/lang/StringBuilder."<init>":()V
   7:   aload_1
   8:   invokevirtual   #4; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   11:  aload_2
   12:  invokevirtual   #4; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   15:  invokevirtual   #5; //Method java/lang/StringBuilder.toString:()Ljava/lang/    String;
   18:  astore_1
   19:  aload_1
   20:  areturn

So, a += b is the equivalent of

a = new StringBuilder()

The concat method should be faster. However, with more strings the StringBuilder method wins, at least in terms of performance.

The source code of String and StringBuilder (and its package-private base class) is available in of the Sun JDK. You can see that you are building up a char array (resizing as necessary) and then throwing it away when you create the final String. In practice memory allocation is surprisingly fast.

Update: As Pawel Adamski notes, performance has changed in more recent HotSpot. javac still produces exactly the same code, but the bytecode compiler cheats. Simple testing entirely fails because the entire body of code is thrown away. Summing System.identityHashCode (not String.hashCode) shows the StringBuffer code has a slight advantage. Subject to change when the next update is released, or if you use a different JVM. From @lukaseder, a list of HotSpot JVM intrinsics.


Practical Experience using Stripes?

I am coming from an Enterprise Java background which involves a fairly heavyweight software stack, and have recently discovered the
Stripes framework; my initial impression is that this seems to do a good job of minimising the unpleasant parts of building a web application in Java.

Has anyone used Stripes for a project that has gone live? And can you share your experiences from the project? Also, did you consider any other technologies and (if so) why did you chose Stripes?


We’ve been using Stripes for about 4 years now. Our stack is Stripes/EJB3/JPA.

Many use Stripes plus Stripernate as a single, full stack solution. We don’t because we want our business logic within the EJB tier, so we simply rely on JPA Entities as combined Model and DTO.

Stripes does the binding to our Entities/DTO and we shove them back in to the EJB tier for work. For most of our CRUD stuff this is very thing and straightforward, making our 80% use case trivial to work with. Yet we have the flexibility to do whatever we want for the edge cases that always come up with complicate applications.

We have a very large base Action Bean which encapsulates the bulk of our CRUD operations that makes call backs in to the individual subclasses specific to the entities and forms.

We also have a large internal tag file library to manage our pages, security, navigation, tasks, etc. A simple CRUD edit form is little more than a list of field names, and we get all of the chrome and menus and access controls “for free”.

The beauty of this is that we get to keep the HTTP request based metaphor that we like and we get to choose the individual parts of the system rather than use one fat stack. The Stripes layer is lean and mean, and never gets in our way.

We have a bunch of Ajax integrating YUI and JQuery, all working against our Stripes and EJB stack painlessly.

I also ported a lighter version of the stack to GAE for a sample project, basically having to do minor work to our EJB tier. So, the entire stack is very nimble and amicable to change. Stripes is a big factor of that since we let it do the few things that it does, and does very well. Then delegate the rest to other parts of the stack.

As always there are parts folks would rather have different at times, but Stripes would be the last part to go in our stack, frankly. It could be better at supporting the full HTTP verb set, but I’d rather fix Stripes to do that better than switch over to something else.


JUnit for database code

I’ve been trying to implement unit testing and currently have some code that does the following:

  1. query external database, loading
    into a feed table
  2. query a view,
    which is a delta of my feed and data
    tables, updating data table to match
    feed table

my unit testing strategy is this:

I have a testing database that I am free to manipulate.

  1. in setUP(), load some data into my testing db
  2. run my code, using my testing db as the source
  3. inspect the data table, checking for counts and the existence/non existence of certain records
  4. clear testing db, loading in a different set of data
  5. run code again
  6. inspect data table again

Obviously I have the data sets that I load into the source db set up such that I know certain records should be added,deleted,updated, etc.

It seems like this is a bit cumbersome and there should be an easier way? any suggestions?


Is it your intent to test the view which generates the deltas, or to test that your code correctly adds, deletes and updates in response to the view?

If you want to test the view, you could use a tool like DBUnit to populate your feed and data tables with various data whose delta you’ve manually calculated. Then, for each test you would verify that the view returns a matching set.

If you want to test how your code responds to diffs detected by the view, I would try to abstract away database access. I imagine an java method to which you can pass a result set (or list of POJO/DTO’s) and returns a list of parameter Object arrays (again, or POJO’s) to be added. Other methods would parse the diff list for items to be removed and updated. You could then create a mock result set or pojo’s, pass them to your code and verify the correct parameters are returned. All without touching a database.

I think the key is to break your process into parts and test each of those as independently as possible.

Source: stackoverflow
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Privacy Policy, and Copyright Policy. Content is available under CC BY-SA 3.0 unless otherwise noted. The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 © No Copyrights, All Questions are retrived from public domain..