avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Rationalization (was [RT] Changing Meta Package)
Date Wed, 07 Jan 2004 14:10:33 GMT
I thought my original email had rationalizations and what good I had hoped to
gain by changing the Meta package.  However, it seems that I was not successful
in communicating that yesterday.  A couple of you got hostile and assumed I had
no rationalization simply because I did not have the time to spell it out for
you completely ad nauseum.  That is what this email is for.

What is the primary problem?
----------------------------

The primary problem came from trying to integrate the package into Fortress so
that we can use the same meta info in both Fortress and Merlin.  It became
painfully obvious to me that the certain divisions in the system seemed
artificial and broken.  How many different applications will actually use the
meta info?  Containers and tools.  That's about it.  Yet the model is separated
from the writers and the readers--which both the containers and tools will need
to work with the system.

Secondly, in order to support the Fortress meta info reading the package needs
to be altered because it assumes one file to one component.  In Fortress the
meta info is split between two files--one for component info and one for
dependencies.  There was no simple way to change that.

Thirdly, in order to maintain the ability to automatically assertain which
components were available to Fortress, I would have to have Fortress load the
JAR files and scan them for the meta info.  Fortress was originally designed
to work in situations where the JAR files were already loaded into classloaders.
Reloading the JARs just to scan them would be bad--esp. if you did not know
where those JARs were.

Lastly, the XML panaceia syndrome.  XML is a great tool for certain situations,
but not for all.  In the situation where we are recording meta info for
components, the XML is verbose, and the parsing and generating overhead adds
up.  I suppose one could argue that the serialization solution is one way around
it, but that will run into problems reading meta info generated from one JVM
into another.

The conclusion is that there is no easy way to incorporate the meta package into
anything besides Merlin where it makes all the assumptions that make the package
a decent solution for it.  Quite frankly the number of assumptions in the
package, and the inflexibility of it to do ad hoc attributes of any deliniation
(like @jmx.bean or @instrument name=foo) leads me to the conclusion that it is
a special purpose library for a special purpose solution, and not the general
solution it is touted for.

Why use Leo's Attributes Package?
---------------------------------

Leo's Attributes package is a much easier integration into any system.  It
does not require many different resource files like the Fortress and Merlin
solutions do.  It is neatly contained, and automatically handles any attribute
without question or special coding to make it work.  If I want a model for
new attributes that are no where close to what the Meta package offers, I would
have to make non-trivial code changes with impact on a number of systems.

Do I have specific examples of arbitrary attributes at this time?  Not yet,
but I do have a general idea of where I would want to use them.  The thing is
that inflexibility causes more long term harm than good.  Rather than creating
an environment that is as inflexible as a fascist, creating a system that deals
with change provides better robustness.

My suggestion is not only for the current needs of integrating with Fortress,
but for the future needs that *will* arise.  In fact, it very well may help
make these feature requests from JAMES and company easier to work with.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message