> The main issue is that I don't really see how the metadata you submitted
> is a big gain over what is currently available.
>
> Could you enumerate briefly the main features of the new metadata
> structures, and what the main goals are. Thanks.
>
> regards,
> Rickard
Okay, here goes. First, let me say that it sounds like we'll
definitely need to make the change so that the plugins are not handled
statically - which is fine. I'll ponder the best way to achieve that.
Oh, also, I'll be the first to admit that some of these reasons
are more compelling and some are less compelling, but altogether I think a
new structure makes sense.
1) Source code in jboss with GPL license
2) Data representation separate from GUI representation, GUI event
handling, I/O (loading + saving), and logic. We all know about MVC,
right?
3) Uses modular plugins (yes, like EJX), but provides a unified interface
to the properties from all sources - not necessary for a "client" to
distinguish jBoss properties from JAWS properties.
4) When a new plugin is loaded, its metadata can be quickly and easily
added to what is already available - it will never be necessary to load
the same file twice to access the same data in different places.
5) Associates properties clearly with beans, methods, fields, or
containers. The structures around each in jBoss can hald a reference to
their exact level of metadata (that is, an EntityEnterpriseContext can
have a reference directly to the BeanMetaData, a JawsCMPField can have a
reference to a FieldMetaData, etc.)
6) You can ask any object what properties it has, and it will give you a
list. If you're not sure what the name is of the property you're looking
for, and you're not sure which source files to check to find out, you can
find it at runtime relatively easily.
7) Severe changes to new structure will not break the current deployer
GUI. While we could work around this with EJX & a branch, the advantages
of that approach are debatable.
8) It can be easily optimized for speed - the data is coming
straight out of instance variables and the access is handled by
common components across all plugins, so we could easily handle any
slowdowns caused by the current reflection implementation.
9) Code using the new structure is vastly clearer. There are fewer
layers of objects to dig through, and the object names and accessor
methods have obvious names. Many inobvious casts are eliminated
(How many people know what you should cast the result of
getBeanContext().getBeanContext().getBeanContext() into? Hint: it's not
a BeanContext). Compare the following from JawsCMPField:
BEFORE:
String jdbc = ((JawsEjbJar)getBeanContext().getBeanContext()
.getBeanContext()).getTypeMappings().getTypeMapping(
((JawsEjbJar)getBeanContext().getBeanContext()
.getBeanContext()).getTypeMapping())
.getJdbcTypeForJavaType(type.getType(),
(JawsEntity)getBeanContext());
AFTER:
Integer jdbc = (Integer)getFieldMetaData().getProperty("jdbcType");
So, on to the goals. They're pretty well summed up by that last
point. The goal is to make coding against the metadata accessible to more
people.
Finally, the motivation. I spent a significant amount of time
digging through the existing structure to try to implement TxInterceptor.
In the end, I had to simply copy code from elsewhere - it was impossible
to examine the methods or fields of any particular metadata class and
determine how to get what I wanted. There was no way to put in a call to
"show me all the properties you've got" so I could figure out which one
was appropriate. The naming was absurd - we don't have a bean holding a
bean holding a bean, so why do we have a bean context holding a bean
context holding a bean context? The casts are ridiculous - how on earth I
was supposed to know exactly where and what to cast things into? In the
end, I may have gotten close, but I never did figure out how to dig out
the Tx setting I was looking for - the calling code wasn't implemented
yet, so I couldn't copy the critical bits from anywhere else.
Aaron
