An important question about the use of STATIC in JSF

[Marcos Silvestri]

Hello folks,

I'd like to know the implications of the use of the following features for the view layer in JSF, to keep sessions alive:

t: - myfaces.tomahawk
a4j: - richfaces

In order to keep my request-scoped beans alive I use <a4j:keepAlive> instead of Tomahawk <t:saveState> due to implementation problems on my JBoss Application Server. However, <a4j:keepAlive> is not flexible enough for maintaining alive only portions of the bean objects, as opposed to <t:saveState> that allows me to define exactly what portions of my bean objects I want to keep alive among requests.

I'm running into the following problem:

When using <a4j:keepAlive>, I must serialize the Managed Bean (implements Serializable). Nevertheless, in my view layer I utilize [[[ binding=#{bean.componente} ]]] and these guys cannot be serialized. Having said that, I'm obliged to initialize my fields with the STATIC keyword, so avoiding any attempt to get them serialized.

Here comes a question about the use of the STATIC keyword:

When I first leaned C language, I learned that variable set to be static are shared among functions, the same values stored in them can be used by different parts of your code in a way that one method changing it will reflect to all other functions. I know that the original idea of the static variable has been kept in the Java language, what would lead me to think of exactly the same behavior. However, let's suppose we have a field in a class that is declared to be static. Initially, I would think of the aforementioned behavior, a variable with shared content between different methods. Despite that, the following question remains: if for each new instance of such a class I've got completely different objects, objects on their own, is it possible to have, let's say, 3 objects from that class and by setting the static field in one single instance, to see it getting replicated to the 3 objects all at once, sharing that content therefore?

That answer is important since we are running a system with a multiple users and their objects must be "isolated" from one another, users of the system must not have access to information that does not pertain to them. The only reason to be using STATIC for the time being is exactly that serialization problem mentioned above.

Thanks in advance!

[Tim Holloway]

This is basic Java.

Static class properties differ from member properties in exactly one way: When you have multiple instances of an object, each instance has its own private member properties that are invisible to not only all other classes (unless scoped for visibility), but all other instances of the same class,

Static properties, on the other hand, occur only once, and the same property value is shared between all instances of the class. And, in fact, if there ARE no instances, the value is still accessible, since it's bound to the class itself and not an instance of that class.

This is one of those times when it's useful to meditate on words of the White Knight in Lewis Carroll's Through the Looking-glass.

The biggest danger of static properties in J2EE/JEE - whether with out without JSF - is that they're not inherently thread-safe. So they're best reserved for immutable values. There are uses for mutable properties as well, but if you want to sleep uninterrupted at night, you will use Java's synchronization mechanisms to ensure that the item in question is handled in a thread-safe manner.