You know, I'm not even going to bother with the point by point.
In the end, I'm sure we're both right - it can probably be made to work
either way.
So where does this leave us? You contend that all of the features
and goals can be achieved by altering the current EJX code. I contend
that they have already been achieved in the new code. I would also point
out that I am not up to the task of altering EJX in the manner you
suggest. So, are you going to commit to making the required changes to
EJX in the immediate future? I cannot make progress (on JAWS and TXs and
the other things I'd like to put into place) with the EJX metadata
structure, and I'd rather not just take a vacation and come back when
everything has been fixed.
So what's it going to be? Would you like to endorse the new code
(and provide constructive input, which seems to already be happening if I
read between the lines) or rewrite the old code? If the latter, when do
you expect to be finished?
Thanks,
Aaron
On Sun, 9 Jul 2000, Rickard [iso-8859-1] �berg wrote:
> 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
>
