Then it occurred to be: the site was working fine before a recent set of changes, maybe something got broken?

Even better, it had to be some kind of configuration setting that was wrong, incorrect, bad.  Any pure coding/linking error would have been more specific.  I was betting config errors were buried in the oc4j logging somewhere and only the resultant “PERMGEN” showed up.

Turns out a couple of items were off in the config XMLs for the project: missing setters for injections, not including a new hibernate mapping file in the list of mappings.  (I think that was the killer).

Took under 10 minutes to fix these things and everything started working again.

I really don’t like oc4j.

Just trying to save someone else some pain.

A built-in mechanism of EasyMocks is to just “call” the void method in question.  For example a commonly mocked object is the HttpSession:

    expect(request.getSession()).andReturn(session);
    expect(session.getAttribute(name)).andReturn(null);
    session.setAttribute(eq(name), isA(InSession.class));
    replay(session);
    //whatever you are really trying to test
    verify(session);

Could only be easier if the doc told you this clearly.

Adding onclick showed the buttons were working, they just were not calling the actions.

Several misguided google’d references mentioned changing the behavior of the ui callback setting in web.xml. I tried that and it made no difference.

Finally I noticed that I was missing the id attribute on the buttons. Adding different id’s for each of the buttons fixed the problem – the buttons now invoke the methods as expected.

I had thought that icefaces added default id’s where necessary, but there may be a glitch when you have an assortment of fields of the same type.

Looking at the integer values in the table I went through and verified each as correct in the db, mapping, entity and sequence. No luck there.

Poking around the internet though told me the error probably had nothing to do with a LONG mapping and could be ANY size mapping on any field. It’s a generic sizing error.

Luckily the table I created only had a few fields so I was able to narrow done the problem pretty quickly. In my case a VARCHAR2(4000) was attempted to be stored with much more. So, the String in the Java entity had to be controlled to make sure it was small enough.

It’s not much, but thought I would pass the info along and maybe save you some time.

Since then Ihave learned:

- The project is a modern Java web app (they hired 2 junior C (not C++ or GUI) developers from other units)

- There is no architecture, so the developers are doing things like investigating the use of Spring or not.

- The project must be shipped in a few months.  This appears to be a collosal communications screw up: the contract says delivery so many days after signing, the client delayed signed for months, once signed the client assumed the clock had been ticking all along the signing was just a formality.

- The company we work for is strictly waterfall development with very long test cycles.  Given the expected ship date the project needs to go into test phase in a couple of weeks in order to meet their delivery date (per contract) or face penalties.

- Since our company is very concerned with security all 3rd party software used (tomcat, Spring, commons library, etc…) must get approval from lawyer types who go over the specific license agreement for the software involved.  Especially of interest is anything developed by non-US parties.

- There are no written requirements beyond a few paragraphs in the contract.

- There is no UI-design, it is being done by the aforementioned C developers.

- Like everyone else in the world there are constraints on hiring, so it is likely the project will not get a Java developer to help out.

That’s about all I can think of so far.  I am always amazed this kind of silliness still goes on in the world.

Your unit test code is running JUnit4.  At least one test method must have the @Test annotation.  Otherwise this error occurs.

If the class you are testing has @Required setters for Spring injections they must be set otherwise JUnit will mask the missing required exception as a no runnable methods exception.

If you are initializing your mock objects outside of the @Begin method you will get this error.

If you are attempting to mock the same class more than once you will get this error.

org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session…..

This is likely caused by your code doing something like:

session.get()

object.setSomething(value)

session.update()

The session.update() call is attempting to attach an object to the Hibernate session.  This is done by the object id.  If you already have an object with the same id associated with the session (i.e. maintained by Hibernate) you get this error.

You have two choices:

1) Don’t call update on the object.  It is already being maintained by Hibernate.  There is no need to do so.  A later flush() will push any changes recorded in the session to the database.

2) If you can not tell if the object is associated with the session (likely in a long user scenario) call merge() instead.  Merge() takes the instance passed and merges it with any object of the same id associated with the session.  Note, if you plan on using the object again you must use the object returned by the call to merge().  The instance object passed to merge will not be updated.

Per the team lead the developer has lots of experience with Java, JSF, SOA, etc…  All the stuff we need on the team

The guy talks, a lot.  This is just a personality trait that irks me.  So, maybe he’s ok anyway.

Then I overhear the conversations he’s having with other developers (see talks a lot above) and some of the questions he has asked me:

• When a screen (from the functional spec) has multiple checkboxes does that mean the user can select multiple items?
• Similar when a screen has multiple radio buttons does that mean the user can select only one?
• Do I need the JDK installed to compile the application?
• Are all of the user actions affecting the database?

I guess the worst part is I bet he is getting the same hourly rate (or better) than I am.

In this example the Hibernate code would be something like:

Category parent = ...Category child = ...
child.setParent(parent)
dao.create(child);//this does not appear to actually do anything in a self-referencing table
parent.getChildren().add(child);
dao.saveOrUpdate(parent);session.flush();

• Since the reference is in the same table, the above add() to the parent children does nothing.
• The setParent() call is just setting the parent column directly in the Category object – no database action is taking place.
• Calls to getChildren() are doing a simple query unlike other getObject ORM calls in Hibernate
• Calls to getParent() are also doing abnormal ORM calls

All of the above code ‘works’. It just doesn’t work like anything else really in Hibernate.