So what you seem to be saying here is that the code that parses
the XML has a list of classes, and when it sees certain tags is matches
that to a class and turns processing over to that class to continue. I
really don't consider that to be a dynamic plugin architecture. It's just
delegation - you have a big list of stuff and you hand things over to them
according to preset criteria. It's not like I could write a new plugin
and it would be automatically included in your process, or remove an
existing plugin and have your process still work...
Besides, I'm not necessarily convinced that splitting up the
parsing like this is an advantage. It sure makes it harder to debug when
your parsing is split across a number of objects, and there's no clear way
for a particular bit of the parser to access the prior state of the
parsing before everything was handed over to it. This is one of the
"features" I intentionally removed in the new structure - I thought it was
much clearer to handle all the parsing in one place rather than spreading
little bits of it all over, and tying it to a bunch of objects that do a
lot of other things as well.
If every class does a little parsing, a little event handling, a
little data storage, a little GUI modeling, and so on - then where do you
look when something goes wrong? Or where do you look if you want to
extend some bit of functionality? Or where do you go to understand the
*process*? I elected to use a fixed set of specialists rather than a
potentially unbounded number of generalists. I think this is one of the
principal tenets of MVC and similar OO design techniques.
Aaron
On Sun, 9 Jul 2000, Rickard [iso-8859-1] �berg wrote:
> Hi!
>
> Aaron Mulder wrote:
> > Hmmm... I'm not sure I follow you here, Rickard. Besides this,
> > you've said elsewhere that EJX just "knows" what plugins to load, so you
> > don't have to load things manually.
>
> Yes. If you look in the container configuration XML code you will see
> that there are references to Java classes. These are loaded and then
> delegated to.
>
> > However, when I look at the code, the JBossFileManager loads
> > ejb-jar.xml and jboss.xml - and that's hardcoded.
>
> Exactly. These two are always loaded. Notice that part of jboss.xml is
> dynamic content and structure (the container configuration as mentioned
> above). The JAWS settings could be added to the beans in a similar way
> (i.e. contained in jboss.xml).
>
> > Then the
> > JawsFileManager loads ejb-jar.xml and jaws.xml - also hardcoded. The
> > JawsFileManager gets loaded by the JAWSPersistenceManager, which gets
> > loaded since its class is named explicitly in jboss.xml.
>
> Correct.
>
> > This does not seem automatic or "magical" to me - and EJX is not
> > loading things "dynamically".
>
> I was talking about the container configuration kind of doing things.
> This is how it could work for the JAWS settings / bean as well.
>
> > The container code is dynamically loading
> > JAWS based on an entry in another file, but all four files loaded are
> > hardcoded in the FileManager classes. (I won't even ask why ejb-jar.xml
> > is loaded twice!)
>
> Exactly, and this is what has to change to either:
> * Include the dynamic settings in jboss.xml
> * Add ability to add aspects of beans dynamically by loading several XML
> documents into the structure.
>
> > In the EJX GUI, you specifically tell it which plugin to use when
> > you open a file - you have to say "open as type [EJB-JAR | JBoss | JAWS]".
> > So here again, I'm not seeing EJX doing anything dynamic. Can you clarify
> > what you mean when you say EJX just "knows" what plugins to load and
> > "loads the right plugins dynamically"?
>
> Again, I was talking about the container configuration, and the same
> idea could be applied to the bean configuration.
>
> Is it clear now? No magic, but certain decisions on how the structure
> looks like and where to get data from needs to happen at runtime.
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
