Hi!
Aaron Mulder wrote:
> 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.
I'll add my perspective from the current EJX code.
> 1) Source code in jboss with GPL license
Ok, so if I add the EJX code to CVS under GPL, there's no difference
here.
> 2) Data representation separate from GUI representation, GUI event
> handling, I/O (loading + saving), and logic. We all know about MVC,
> right?
Right. In the current incarnation GUI is separate from data, but I/O is
not. Also, logic is part of the structure which is, IMHO, a good OO
feature: objects are logic and data.
> 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.
The current EJX code uses this kind of mechanism for the container
configurations. Adding aspects to beans in a similar way is trivial.
> 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.
Same with current code if above change is made.
> 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.)
Same with current code if above change is made.
> 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.
Same with current code if above change is made, although I would suggest
using strongly typed properties a la JavaBeans as it is now.
> 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.
Are you saying you would not add a GUI to the new structure? The current
code is easily GUI-fiable due to its reliance on the JavaBeans API.
> 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.
The current code doesn't use reflection AFAIK.
> 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");
These two aren't strictly equal since I'm doing a computation
dynamically which you have done statically. If you feel it is a static
value, then simply compute it and add a strongly typed accessor. The
downside with the "after" approach is that you have to cast it. I would
prefer a JavaBean get/set accessor pair.
As I noted in private email, this is a truly minor issue as it is only
about untyped accessors. Fix by adding strongly typed accessors such as:
public EjbJar getEjbJar()
{
return (EjbJar)getBeanContext();
}
To summarize I personally cannot see that any of the features you
mention cannot be done as easily or better with the current EJX code.
> 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?
Yes, this is something that needs to be fixed, but a very weak point for
introducing a new structure as it only requires strongly typed accessors
to be fixed.
Ok, so now that you have shown me the reasons why you want to introduce
a new structure for metadata my opinion is that these are all very good
features and goals, but none of them aren't feasibly within the current
structure. Sorry, I just don't.
I do sympathize with your pain involved with debugging the structure to
get hold of the information you were looking for, but this is more
documentation issues than design/code issues.
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
