Return-Path: Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: (qmail 98529 invoked from network); 29 Sep 2009 09:47:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Sep 2009 09:47:16 -0000 Received: (qmail 37338 invoked by uid 500); 29 Sep 2009 09:47:15 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 37297 invoked by uid 500); 29 Sep 2009 09:47:15 -0000 Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: user@geronimo.apache.org List-Id: Delivered-To: mailing list user@geronimo.apache.org Received: (qmail 37289 invoked by uid 99); 29 Sep 2009 09:47:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Sep 2009 09:47:15 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.211.184] (HELO mail-yw0-f184.google.com) (209.85.211.184) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Sep 2009 09:47:03 +0000 Received: by ywh14 with SMTP id 14so3467780ywh.26 for ; Tue, 29 Sep 2009 02:46:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.81.12 with SMTP id i12mr4278745anl.151.1254217601196; Tue, 29 Sep 2009 02:46:41 -0700 (PDT) In-Reply-To: <1f3854d50909290231u67da27e9pa4b53f143e50a03a@mail.gmail.com> References: <25632603.post@talk.nabble.com> <25657764.post@talk.nabble.com> <233FD0C9-9065-4B7F-9F9B-3D6F24E1A9AD@yahoo.com> <1f3854d50909290231u67da27e9pa4b53f143e50a03a@mail.gmail.com> From: Quintin Beukes Date: Tue, 29 Sep 2009 11:46:21 +0200 Message-ID: <1f3854d50909290246v5617ae65odd7f9a94fcbb08e3@mail.gmail.com> Subject: Re: How does the Client Container work? To: user@geronimo.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 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 uniqu= e 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 ha= s 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 wr= ote: > There is a book Apache Geronimo Development and Deployment by Aaron Mulde= r > > 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 wr= ote: >> >> On Sep 28, 2009, at 11:45 PM, Juergen Weber wrote: >> >>> >>> OK, thanks, so that is consistent to the way Weblogic server does it, y= ou >>> >>> http://download.oracle.com/docs/cd/E12840_01/wls/docs103/client/thincli= ent.html#wp1079680 >>> start the Weblogic client container =A0which then starts your client >>> application. >>> >>> The Geronimo =A0Wiki 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 the= re >>> 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. =A0I think that you can use the "extract a server" feature to c= reate >> a geronimo assembly that contains your app client plugin and everything >> needed to run it. =A0You could then unpack this on the remote client mac= hine. >> =A0This part should be easy to try out and any problems would most likel= y be >> minor bugs in dependencies in geronimo plugins. =A0This ought to work ri= ght >> now. >> >> However, IIRC the last time I looked there was no obvious way to configu= re >> the app client with the server IP address (or port), so it would really = only >> run on the same machine as the server. =A0I think this would be an easy = thing >> to change, and I think the code would be somewhere in geronimo-client. = =A0I'm >> not sure what a good way to _tell_ the app client where the server is mi= ght >> be. =A0Any ideas? >> >> thanks >> david jencks >> >>> >>> Thanks, >>> Juergen >>> >>> >>> David Blevins wrote: >>>> >>>> >>>> Right. =A0You 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--tp25632603s13= 4p25657764.html >>> Sent from the Apache Geronimo - Users mailing list archive at Nabble.co= m. >>> >> >> >