Then further, a book written by IBM states:
With WASCE, the following considerations apply:
Unlike other Java EE application servers, WASCE does not
provide a unique
Application Client container. Instead, you must install the full
server package
if you want to run an application client.
This is compliant with the Java EE specification, which does
not require that
you provide a unique installation process for the Application
Client container
(the specification only requires that it exists). Also, because
WASCE has a
very small server footprint of around 150 MB, the net disk space
savings for a
special Application Client container most likely outweighs the
realized benefit
of disk space.
It doesn't say you need to be on the same installation, but it does
say it needs to be deployed on a full installation. I did once
try to
extra the client as a plugin, but failed to then install the
plugin. I
think it's because the client is never really in a "started" state.
Maybe you can deploy the "server side" of the plugin? But on
geronimo
it's 2 separate repo items. and you can't export them as a single
plugin.
Further, I once tried running the appclient from a separate
installation, and all this achieved was port conflicts.
From my struggles, this is what my conclusion was:
I don't think the application client was really meant to be a way
for
remote clients to access the server, but rather for a local
application to gain the benefits of JavaEE. Any "remoting" has to
happen on the server layer, inside EJBs and what not.
So you would develop your thick application client which is
linked to
the EJBs in the server. This is why there are 2 components to the
application client, the server and client component. The client
component runs inside the thick application container, and works
with
the server components to create a JavaEE environment for it. It's
not
meant to directly communicate with remote EJBs as if being a remote
client.
So to summarise (i'm probably repeating myself a lot here - having
difficulty in explaining this - hope you understand). You get 2
types
of JavaEE clients, thin clients and thick clients. Thin clients are
directly connected to the remote server via a remote
InitialContext,
using corba/ejbd. Thick clients run inside a JavaEE environment,
and
is connected to remote clients using traditional JavaEE "remoting"
techniques, such as remote EJBs. This is done inside the EJB layer.
The actual "application client" part is purely for wrapping the
application's parts inside the EE container.
Quintin Beukes
On Tue, Sep 29, 2009 at 11:31 AM, Quintin Beukes <[email protected]
> wrote:
There is a book Apache Geronimo Development and Deployment by
Aaron Mulder
It states:
As of Milestone 4, the client container must run from the same
Geronimo installation as the server,
which also means that it must be run on the same machine, using
the
bin/client.jar file in the
server's Geronimo directory. The command line to start a J2EE
application client looks like this:
java -jar bin/client.jar ConfigName [arg1] [arg2] [arg3] ...
I found the same problems with this, which is why I eventually
ended
up building my own client framework using Spring. It's not as
dynamic,
but I get similar features (ie. dependency injection, security,
etc.).
Quintin Beukes
On Tue, Sep 29, 2009 at 9:17 AM, David Jencks <[email protected]
> wrote:
On Sep 28, 2009, at 11:45 PM, Juergen Weber wrote:
OK, thanks, so that is consistent to the way Weblogic server
does it, you
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/client/thinclient.html#wp1079680
start the Weblogic client container which then starts your
client
application.
The Geronimo Wiki says:
You can run the Application Client with this command:
%GERONIMO_HOME%/bin/client JEE5/EXAMPLEClient/2.1/car
But how do you run the client container from a remote machine
where there
is
no Geronimo installation?
client -h shows no way to argument a Geronimo location.
So far no one has shown enough interest in app client
containers to set this
up well. I think that you can use the "extract a server"
feature to create
a geronimo assembly that contains your app client plugin and
everything
needed to run it. You could then unpack this on the remote
client machine.
This part should be easy to try out and any problems would
most likely be
minor bugs in dependencies in geronimo plugins. This ought to
work right
now.
However, IIRC the last time I looked there was no obvious way
to configure
the app client with the server IP address (or port), so it
would really only
run on the same machine as the server. I think this would be
an easy thing
to change, and I think the code would be somewhere in geronimo-
client. I'm
not sure what a good way to _tell_ the app client where the
server is might
be. Any ideas?
thanks
david jencks
Thanks,
Juergen
David Blevins wrote:
Right. You boot the app client container from the command
line, the
app client container does all the work to setup the
environment,
injects the required things into your main class, then calls
your main
method.
For all intense purposes the app client is really like a mini-
server
with a little Geronimo kernel and everything.
-David
--
View this message in context:
http://www.nabble.com/How-does-the-Client-Container-work--tp25632603s134p25657764.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.
