I was looking at TxInterceptor today. It's no wonder it was never
implemented. The metadata constructs are incredibly obfuscated, and tied
to code that is not in CVS (EJX). Furthermore, a lot of the data is
stored in GUI structures (TreeModel - you can't be serious!).
I know we've visited this before on many occasions (and I think
that fact speaks for itself). We need to split the meta data away from
the EJX GUI. It's not enough to lazy load - in the process of looking up
a method's transactions setting, I've had to do 2-3 completely inobvious
casts (is it clear to you that
getMetaData().getBeanContext().getBeanContext() should return an object of
type Jar? What *is* an object of type Jar? It's not a jar file!) and
navigate javax.swing classes and I'm still at the stage of "try something,
observe ClassCastExceptions, refine".
I call do over. If I wanted to deal with "void *" I'd be coding
C. Let's rewrite the metadata to be oriented around fast, convenient,
typesafe access to data, not convenience of display in a GUI. We can wrap
that with classes that perform the desired translations. One suggestion
would be wrapper classes that implement load and save to XML or GUI. To
populate EJX, load XML and save GUI. To save EJX data, load GUI and save
EJX. At runtime, load XML. Or something else. Anything!
But the prerequisite for all of this is to get the EJX code in
the jBoss CVS tree. We need to be able to update it.
Aaron
