On Aug 6, 2006, at 9:59 AM, Dain Sundstrom wrote:
On Aug 6, 2006, at 12:15 AM, David Jencks wrote:
On Aug 5, 2006, at 5:49 PM, Aaron Mulder wrote:
Currently, the application client plan has both a client-environment
and a server-environment. These can have separate module IDs and
separate classpath modifiers.
The client-environment is used for when you run the application
client
in the application client container (which is essentially a
stripped-down Geronimo runtime).
The server-environment is used to create a JSR-77 GBean representing
the application client, on the server side. That is, the module
ID is
used as part of the GBean name for the JSR-77 GBean, and the class
path is used to run the JSR-77 GBean. There was apparently some
thought that the client might be able to list GBeans that should run
on the server side using that class path and module ID as well, but
that was never implemented.
So here are my claims:
* There's no need to have different module IDs on the client side
and
server side. The JSR-77 GBean and app client container GBeans could
all use the same module ID for GBeans associated with the same app
client.
Thinking about it some more I think the problem is that for a
standalone app client, you would get two modules with the same
module id: one is the server jsr-77 gbean and the other is the
actual app client module. I think we ran into this problem and
that is one reason there is the server-environment.
Thinking back, we introduced the server side app client module
because we were planning on allowing server side resources to be
allocated for an app client program. At first this was just a
server side JNDI, but later we removed this due to it's complexity,
and now I don't think anything uses the server side module. So, if
someone wanted to do the work, we should be able to remove it
completely, and avoid the conflict entirely.
How do we install the required yet idiotic jsr-77 gbean that
represents the app client without a module to put it in?
thanks
david jencks
-dain
