Leo Sutic wrote:
>
>>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.
Remember that no standard is official without proper testing.
> Trust me, if all this was built-in and standardized in Java, I would
> not hesitate a second to choose the approach you propose.
It *will* be with the Meta Info API changes (JDK 1.5?)
> 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?
Sure. The container will be able to create the classloader necessary.
Would you be able to embed a container in an EJB? No, but you can't
do that now anyway.
> 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?
My guess is that it is as flexible as the Manifest entries. So we are
talking about key=value pairing. For **attributes** that is enough.
In fact, many attributes only need the key portion declaired.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
