struts.xml

...
 <constant name="myVal" value="9" />
 <bean name="myService" type="prac.MyService" class="prac.MyServiceImpl" />
...

MyServiceImpl.java

...
 @Inject("myVal")
 public void setMyVal(String myVal) {
 this.myVal = Integer.parseInt(myVal);
 }
...

MyAction.java

...
 @Inject("myService")
 public void setMyService(MyService myService) {
 this.myService = myService;
 }
...

This will create a single instance of MyService with myVal injected into it.
And on every invocation of MyAction, that MyService instance will be injected into it.
Sweet!

Of course, this is part of Struts internals, so these can change at any time. It is probably not a good idea to use it on a real world system.

A few years later, I revisited equals() ( and hashcode() ) when reading Joshua Bloch’s Effective Java. Chapter 3, “Methods Common to All Objects” shows how to, and why you should, properly implement equals() method. This must be required reading for every Java programmer, even if you ever only write CRUD applications in Struts, and are never going to use any of it.

Recently, I read Angelika Langer‘s article on this subject. If, like me, you have read the Effective Java book, and think that you know all that you need to about Object equality, think again!

Angelika Langer and Klaus Kreft disect various approaches to implementing equals() – Secrets of equals().

The gist of it is that although implementing equals() for a final class, or a class with a final equals() method is reasonably straightforward, there is no one correct way of doing that with mixed-type comparisons allowed between objects of different types in the same class hierarchy.
The second thing to keep in mind is that if you are overriding a class that implements equals(), and you override the equals() method you have to pay particular attention to whether the superclass’s equals() method allows mixed-type comparisons or not -

If the designer of such a non-final class decides in favor of implementing equals() using instanceof , then no subclass can ever add fields and override equals() without violating the transitivity requirement of the equals() contract.
If the designer decides in favor of implementing equals() using getClass() , then no subclass object will ever be comparable to a superclass object and trivial extensions may not make a lot of sense.

There is a follow up article showing one way of Implementing equals() To Allow Mixed-Type Comparison.