Hi!
> happy that the metadata will be reworked, was a pain having EJX and jBoss
> metadata separed.
> Since me and Andy are working on EJX, can you spend 10 minutes explaining
> the main ideas behind the new model ?
> I'd really appreciate that.
Yes, here's the core of it:
The EJX plugin is now a "EJB" one, instead of a "EJB XML" one. The objects
it contain are logical entities from the XML structure, such as Entity,
Session, CMP-field, etc. But, they do not hold any attributes other than the
"primary key" of the object (for Entity it is ejb-name, for CMP-field it is
field name, etc.). They are there to provide the nodes of a tree. Each node
that we want to attach different "facets" of data to extends FacetHolder
which has addFacet(name, facet) and getFacet(name) methods. For each type of
facet (the types currently being EJB, JBoss, and JAWS) there is a
FacetFactory implementation. FF has a bunch of methods, for example
"entityCreated(Entity newEntity)". Whenever a node object is created the
corresponding method in all FF implementations are called. They can then
call the FacetHolder methods, e.g. newEntity.addFacet("EJB", new
EjbEntity()). This ensures that whenever there is a Entity it will always
have the right facets attached to it. The FF implementation can of course
choose to not attach a facet, for example the JAWS FF does not do anything
on "sessionCreated", since it doesn't care about session EJB's.
During XML load the FacetFactory implementations are called one by one, and
they then load the XML of their own type into the facets it wants. They can
choose to do this any way they want (i.e. do all XML load in the FF, or have
the FF delegate loading to facets through the XmlExternalizable interface as
before), but currently the delegation model is used to simplify things.
Since all FF's are called this means that the same metadata model will after
loading have information about all facet types, so it will hold both EJB,
JBoss, and JAWS metadata.
The XML save works the same way: the FF's are called ("exportXml(URL)") and
they then extract the information they are interested in and store it into
the URL (although the JBoss factory, for example, replaces the file name
part of the URL to "jboss.xml"). In this phase they traverse the EJB
structure and use the getFacet("mytype") for all nodes they find.
The GUI is then adapted to this. When the enterprisebeans tab is selected
(just as before) the beans are shown in a tree view to the left, and
clicking on an bean shows it in the right pane. But, now the right pane is
tabbed too, with one tab for each facet. I.e. you can now edit "EJB",
"JBoss", and "JAWS" info all at the same time. This is a huge timesaver
since you don't have to open the same set of files three times to do
editing. Also, if you change the EJB-name, before you had to go to the other
files (whose information was linked to EJB-name), but now they will
automatically get the right name so there will never be inconsistencies or
lost data due to changed names. Very very cool.
I have also updated the GUI to use the Swing icon collection, which has
icons for J2EE. Looks awesome.
So, how far am I? I have done one vertical slice (enterprisebeans, entity,
environment entries) to test if all of the above worked as it should. Now I
will flesh it out with all of the other types of nodes etc.
Then the last part of the conversion is to update the JBoss to use the new
metadata model. This will probably take some effort, but is mostly a mapping
thing ("go here instead of here").
One thing I am doing is to put the metadata in the EJX CVS module. It made
more sense that way, and was much more practical. However, I am keeping the
JBoss package names, so it is now in "org.jboss.metadata".
This at least outlines the changes I am doing. It is quite clean and not
very difficult when you get used to it. Especially if you are only
interested in adding flags or options it is very simple. If you want to make
another plugin you must understand the above, but you can come a long way
just by copying an existing facet and modify as necessary.
If you have any more questions on this let me know. It will probably take a
couple of days next week to get everything in place. I will not commit right
away but rather make a zip of the new source available, so that developers
can check it out and confirm that it looks ok.
This is a big change, but it will make our life much easier, or at least
that was the idea :-)
regards,
Rickard
