marc fleury wrote:
> I am thinking "ease of use, ease of use"... can't a deployer see that it is
> a JAR and tell you "kid, thank you for bringing me this (<private>moania!
> why? thank you Rickard!</private>) but I am not the one to deploy it let me
> delegate it for you to the Jar deployer"... you see where I am coming from ?
> this way you don't require that people package an ear structure everytime...
Sure, no problemo.
> |We could probably do a "large application" XML description containing
> |things like:
> |<system>
> | <application>
> | <name>Foo</name>
> | <url>http://.../foo.ear</url>
>
> read my mail to Dr Jung either you specify the URL either you work from the
> class description (ejb-link spec) with a CL service at the class level.
>
> You can then infer that url...
Not sure what you mean.. this is for telling the deployer where the EAR
is in the first place. You can't infer the URL if you aint got it.
> but I am open to that actually specifying the URL will be messy but clear
> and a beginning to this ...
Look, when you call deploy you specify an URL. The above is just a way
to specify that URL.
> | </application>
> | <application>
> | <name>Bar</name>
> | <url>http://.../bar.ear</url>
> | <parent>Foo</parent>
> | </application>
> |</system>
>
> ok, really, why the system tags...
>
> system is system and application is application...
> <system><application/></system> makes no sense to me
A system is a set of applications. The system has no "body" of its own,
but is the set of applications *and the relation between them*.
> Finally does this cover the dependent classes ?
Yes. See the parent notation above. This specifies the parent
classloader delegation tree.
> |Somewhat like the "system" outlined above. Yes, that might be a good
> |idea.
>
> what he is proposing is not really the system idea... see above...
>
> What he is proposing is
>
> <application>
> <module>
> <ear/>
> </module>
> </application>
>
> which is a more powerful way to scope the application and provide
> subparts...
Not following... you only added a layer (instead of system-*ear-*jar you
have application-*module-*ear-*jar). What would be the purpose of the
extra layer?
> Some links are "parent" links (the class loader dependency) some others are
> just "shared classes". I don't think he says so explicitely at this point.
The "shared" classes are specified with Class-Path manifest.
> |> That's meant to be showing that a JBoss application contains many EARs,
> |> each of which contains many modules. In this model we only need to track
> |> dependencies between EARs unless we want to somehow allow redeployment
> |> of part of an EAR.
> |
> |The good thing about the above is that we can probably add a
> |SystemDeployer that is "on top" of the J2EEDeployer even, so we don't
> |mess with the standard stuff.
> |
>
> I don't really follow... the J2EEDeployer needs a rewrite, let's do it...
> what is the "standard" stuff...
"standard" is J2EEDeployer and down. This system notion that binds
several EAR's together is non-standard, so it is good if we can do it
"on top" of the "standard stuff".
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
