So the first question is, what should the data structure look
like? I see two alternatives:
1) Make it look like the files on disk. Each tag is represented by a
variable, etc. There would be a series of classes so it's not one
gigantic class, but all instance variables would be direct reflections of
an XML tag. This is easy to read/write to disk and GUI, but a harder to
use in jBoss at runtime. It facilitates a modular approach to EJX.
2) Make it look like a bean. There is a class to represent each bean, and
it brings together all the properties. For example, each "method" object
has the access permissions, transaction properties, persistence
information, and so on that apply to that method all in one place. This
is easy to use in jBoss at runtime, but you have to split it all out to
write files to disk, and it's hard to make EJX modular (unless we really
get generic so you can say what metadata is related to methods in your
plug-in, etc.)
I guess if we want to leave EJX as an independent tool usable by
other vendors and so on then we really need to lean toward option 1.
Personally, I would opt for a cleaner interface at runtime and so what if
we have a proprietary deployment tool (after all, everyone does), so I'd
lean toward option 2. But I can see both sides. Thoughts or other
alternatives?
Aaron
On Thu, 29 Jun 2000, Juha Lindfors wrote:
> Yeah Agent Mulder, let's do this.
>
> -- Juha
