geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Client Container seems a little... weird.
Date Wed, 31 Aug 2005 04:01:08 GMT
On Tue, 30 Aug 2005, David Jencks wrote:
> I think I'd like to find a classloader that actually lets you use 
> jar:jar: urls, unlike the sun cl, and then just pack a mini-geronimo 
> server with config-store, repo, etc into it and have that be the client 
> jar.  This could be served by jnlp but could also just be copied in 
> place and run.

	But it would have to be dynamic, right?  I mean, if you deploy an 
app client and then immediately run the client container from a remote 
machine, and we expect that remote machine to have your app client and all 
its dependencies in its local config store, then part of the client 
container process needs to be downloading fresh copies of the app client 
and any dependencies into the local config store.  Or if the whole thing's 
going to be in a JAR, then the client continer needs to download a massive
dynamically-generated JAR containing "all the right stuff" in the 
included config-store and so on.

	I think I'd prefer to dispense with the client-side config store
and just have a "lightweight" client environment that starts up, connects
to the server, downloads a dynamically-generated JNLP file describing the
client and its dependencies, sucks down a bunch of JARs, sets up a
ClassLoader, and runs the thing locally.  I'd prefer to avoid running a
Kernel on the client at all, if we can, though I guess that's not very 
realistic since the client can run connectors and stuff in its local 
environment.

	Hmmm...  What if we provided a different implementation of 
ConfigStore for the client?  Perhaps something that can suck things down 
from the server on demand, and read them directly from whatever package 
the server provides?  If we build a CAR export tool, this could work 
hand-in-hand with that.  The only question would be where on the local 
filesystem to store the stuff it downloaded (like a dot dir in your home 
directory, or in the directory you execute the client from, or what?).

	Either way, I'd like to avoid client-only stuff showing up in the 
server's config store.  It's pretty disconcerting to list-modules and see 
stuff there that you're not supposed to use, or to start the client 
container in the server and have it completely alter the Log4J 
configuration of the server, or whatever.  I'm not sure what we can do 
about that.

Aaron

Mime
View raw message