geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Client Container seems a little... weird.
Date Wed, 31 Aug 2005 04:01:13 GMT

On Aug 30, 2005, at 9:01 PM, Aaron Mulder wrote:

> 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 was thinking the single-jar solution would be "you are responsible 
for getting the correct version of this jar onto all your client 
machines, and starting them with java -jar MyAppClient.jar." no jnlp, 
no nothin.

I've never actually used jnlp so I don't know much about how convenient 
it is to use.
> 	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.

I think the app client kernel is essential.  I think that if someone 
want to run jetty in their app client we should let them.  Also, if 
someone wants to do distributed transactions from the app client and 
use a real tx log, its fine with me.

> 	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?).

I like this idea, although I think a remote repository will be equally 
> 	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.

I don't see it as a problem.  I think it might be useful in fact.  If 
you set the clientParentId to some server configurations, and your "app 
client" has a swing gui, I think you would get a in-vm gui running in 
the server vm if you started the client configuration in the server.

david jencks

> Aaron

View raw message