> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> 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.
There's one limitation.
What other limitations are there?
That's what I'm asking, rhetorically.
> > 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?)
Will it be compatible with the way you propose for Avalon?
Probably not.
> > 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.
The metainfo for components already requires a tree structure,
if I understand the metainfo package correctly.
This would mean that we'd have attributes *and* XML, which
lowers the utility of the attributes way of doing things.
The problems as I see it are:
+ Future incompatibility with Java standard.
+ Requires own classloader / etc, limiting the scenarios
Avalon can be used in.
+ Still requires XML descriptor.
+ Requires custom compilation process.
So what's the *gain*, versus XML descriptor?
The above is from a "let's make this the Avalon way" perspective.
If you want to try this out in a sandbox or something, then by
all means go ahead. It is cool in the extreme.
But before this can be an Avalon standard, I think you'll have to
solve the problems I listed above. I thought the same thoughts
you did when I saw BCEL (I also considered addition of DBC) - and
after realizing that it just solved 50% of the problem while
introducing new potential pitfalls, I scrapped the idea.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
