Hi!
Toby Allsopp wrote:
> > For maintenance. It is impractical to package and update a large system
> > as one single EAR.
>
> Ok, so it's the packaging that's impractical, not the description of the
> system? I guess I was envisaging a system so vast and complex that a
> single description of its structure would overwhelm any mere mortal.
> Although I suppose this description could be generated.
Yes. And it should be possible to update it at runtime to add/remove
EAR's.
As I have said, the XML is more of a script, so running several "XML
scripts" should be possible.
> > What would be the potential
> > problems? (Other than namespace problems)
>
> Well, birds crap everywhere, and then there's the pecking and where to
> find all the mice or worms whatever birds eat. Seeds, maybe. I guess the
> namespace could get cluttered, what with them all being called Polly or
> Tweety.
Right. Didn't consider that.
> I think I was trying to make a point about how the behaviour of the
> system (in this case the dependencies between applications) can emerge
> from the behaviour of each component (in this case each application's
> own dependencies). The problem with this in this specific case (the J2EE
> one, not the flocking birds) is a bootstrap one - each application can
> describe its dependencies but, unless you include the URL of the EARs
> that fulfil those dependencies, there isn't any way to find what needs
> to be deployed to fulfil them.
Hm.. yes I guess the dependencies could be figured out by emergent
behaviour by simply checking ejb-ref's. That's true. You still need some
pointer for classloader tree though.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
