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 03:19:54 GMT

On Aug 30, 2005, at 8:24 PM, Aaron Mulder wrote:

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

This is partly due to jsr-77.  We need to supply a gbean on the server 
that represents the app client module.  This needs to be in a server 
configuration.  Don't  blame me :-)
> 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.

If you stop the server configuration, jsr-77 won't be able to find that 
all-important app client module gbean with all the important info in it 
(i.e. none :-)
> 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
> environment.

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

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.
> 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
> org/apache/geronimo/Client.

It is sometimes necessary to specify all of these.  The most important 
is clientParentId, now a URI[], which lets you add lots of client 
configurations to your client.  For instance, you can set up a db or 
jms configuration and include it in your app client.  This can be much 
easier than including the config plan in each and every app client 
plan.  The clientConfigId lets you identify the client in the config 
store.  The parentId, as you noted, can be used to get other apps 
running on the server.  The configId needs to be unique and you may 
want to be able to set it.

It is possible to generate defaults for all of these, witness the 
possibility of deploying an app client without a plan.  However, they 
are all useful.
> So I guess I'd like to add two JIRA issues, one to support a remote 
> client
> container,

+1, although I thought there already was such a jira entry
>  and one to eliminate the clientConfigId and clientParentId.
-1, as I attempted to explain above.

david jencks

> Any thoughts would be appreciated.
> Thanks,
> 	Aaron

View raw message