Leo Sutic wrote:
>>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>>
<snip/>
>>
>>Using BCEL to add and read attributes will make our lives
>>easier, although it is entirely possible to have something
>>that will scan the class file without BCEL (to limit the
>>number of runtime dependencies).
>
>
> Neat idea, very .NET-like, but it seems like a cumbersome way to me.
>
> + Compatibility: Having our own classloader is fine, but is this
> something that will work in most/all environments?
>
> + What is the gain, really? We get a two-stage, highly avalon-specific
> compilation process, and the only thing we get rid of is the
> XML descriptor. (Agreed, we do not need an XML parser anymore,
> but...)
>
> + As I understand it, from a developer POV, what you get with
> instrumented
> bytecode is identical to what you get with your JAR scanner - a way
> to
> obtain Avalon-specific metainfo about a class.
>
> That said, it is an extremely cool thing.
>
> Now if we could only find a problem for it to solve.
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.
These things *can* be done with the Manifest, though. It's a thought.
--
"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]>
