> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
>
> Yes, it is .NET like, but here are the things that I would like to
> have it solve:
>
> 1) Identifying the purpose of the class/interface: component, stage,
> extension, service, listener, etc.
>
> 2) Adding attributes that a particular container can recognize, like
> what Peter D. has been going on about. If a class has been marked
> as "distributable" or "publishable", then the Container
> can publish
> the service in JNDI or expose it via the distribution mechanism.
Agreed. It is basically a way to move the manifest XML into the class
file. Thus, anything that can be described in the XML can be described
in the class file.
What I am weighing is the weight of a two-stage compilation and messing
with bytecode/classloaders versus the need to parse XML.
So far, the XML parsing is relatively light and well-understood, while
the effects of custom classloading isn't. The addition of XML
descriptors
is a relatively low threshold for new users, the addition of custom
bytecode is a relatively high threshold.
In retrospect, I was a bit too harsh when I implied that the method
you propose did not have a problem to solve. What I meant was that there
was no solution it provided that warranted the extra uncertainty
that came with the new approach, as opposed to the well-defined
behavior of an XML manifest.
Trust me, if all this was built-in and standardized in Java, I would
not hesitate a second to choose the approach you propose.
That said, attribute-based programming ***is*** very cool and
***will*** be part of Avalon or basically any language. So when it does
come along, having it in Avalon would be cool. I just don't think
that it should be made Avalon standard without having gone through
some serious testing first. For example, will we be able to use the
custom classloader in all environments?
One question: How flexible is the attributes section? Is it a flat
key = value list or can it have a tree structure, like the XML?
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
