> 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.)
yo,
well let's give some major credit to the kiddo here. Rickard's EJX classes
with javabean syntax do pretty much that (2) (as you know the XML
serializable implementation in every class, painstakingly done by Rickard).
As you mentioned the problem is in the "non-clean" separation of imports and
classes used and the "UNREADABLE" structure of the javabean syntax stuff (i
made a few nasty comments on that myself). I like the idea of presenting an
interface for the javabean stuff as it will present user with a java
familiar face on the property and configuration management. Right now the
invocation is typed and works on tags in the file.
This is one case where I would put the "readability" of the code before the
compactness of the code just because we need to maintain it in open source.
But again the javabeans syntax done by the kid is close.
Finally I believe that these metadata structures are central in many
aspects. COntainer deployment (both jboss1.0 and jboss2.0 revolve around
the concept of "ContainerMetaData"), and application management derive from
these in memory structure and their changes. What I am trying to steer you
in is that these need to live under JMX at some point. Be it the
application that holds it's metadata or the metadata itself (I would say the
application right now, for lack of more insights). Keep that point in mind.
Application management will be linked here, make sure you expose javabeans
"property change" type thingies (like current EJX does)
marc
>
> 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
>
>
>
