geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Client Container seems a little... weird.
Date Wed, 31 Aug 2005 03:24:20 GMT
In the client container, there's a distinction between the "configuration" 
(the client module) and the "client" (the client class itself that you 
ultimately want to run).

You have to provide metadata for both.  The Geronimo plan contains an ID 
and Parent for both the configuration and the client (configId, parentId, 
clientConfigId, clientParentId).

The important thing is that the configuration gets into the server's
config-store.  At that point, the configuration seems to be irrelevant.  
You can stop the configuration, and the client still runs fine.  In fact,
you can even stop the server, and so long as the application client
doesn't try to access an EJB or something, this is totally OK.

Thsat behavior appears to occur because the client container runs its own
kernel pointing at the same config store as the server.  So as long as the
client has been deployed there at some time, the client container is not
really going to care about the server, at least until the client
application tries to log in or access something from the server

This just seems weird to me.  I don't terribly fancy both the client and 
server running kernels in different JVMs but pointing to the same config 
store, manageable attribute store, etc.  Also, it contributes to the 
trouble we have running a client from a different Geronimo install (or on 
a different machine) than the server.  Also, odd things happen if you 
actually start the "client" as you would any other configuration on the 
server side (which I guess means you're running the client container 
literally within the server environment, except the client app is not 
actually executed until you invoke the "main" GBean operation on it).

David J mentioned the possibility of constructing a client container that 
accesses required code from the server via JNLP, for example.  I think 
that would be pretty neat, and a way to avoid these issues.  Basically 
create a standalone client container that downloads things it needs from 
the Geronimo server, and doesn't try to share the server's disk 
environment.  That might also make the configuration/client distinction a 
little more meaningful.

However, in the mean time, I still feel like we have too many
configuration parameters.  As far as configID goes, it's not clear why we
can't produce a name for either the configuration and the client based on
the other, so there's only one name to use regardless of whether you're
trying to redeploy or run the client.  As far as parentID goes, it seems
like you might want to force certain things (such as EJBs) to be running
in the server when the client is runnable (e.g. a parent for the
configuration), but it doesn't seem like you'd ever want to set a parent
on the actual client other than org/apache/geronimo/Client.  So it would
be nice IMHO to stick with the standard configId and parentId, where
configId is used for both configuration and client (well, used for one,
and the other becomes FooClient or whatever), and parentId is used only
for configuration, and "clientConfigId" is always

So I guess I'd like to add two JIRA issues, one to support a remote client 
container, and one to eliminate the clientConfigId and clientParentId.  
Any thoughts would be appreciated.


View raw message