Hello again, Bernhard.
First, the footprint of the app client container is much larger than
we would like. It requires more JARs of larger size than we want. In
most cases the app client container needs only some of the classes in
each of those JARs, but because of the way GlassFish packaging has
evolved over the years the JAR containing such classes also contain
classes which are not needed on the client side, yet we are stuck with
them.
Second, something that will provide a little relief (but, sadly, only
a little) is the package-appclient command. This command creates a
zip file containing the GlassFish system files (JARs, config files,
etc.) that the app client container will need on a remote system. You
can then copy that zip to other systems and unzip it to create an
environment where you can run app clients. The footprint of this will
be some smaller than a full GlassFish installation, but again not as
much smaller as we would like. This zip contains all the GlassFish
files that any app client might need to access EJBs, web services, JMS
queues and topics. etc.
Note that package-appclient and the resulting zip do not include your
application's files.
We are trying to take steps to reduce the footprint, but I understand
that this does not help you now.
- Tim
On Jan 17, 2012, at 4:16 PM, Bernhard Thalmayr wrote:
> Thanks again for the info Tim,
>
> I see f.e.
>
> ../lib/install/applications/__ds_jdbc_ra/__ds_jdbc_ra.jar ../lib/
> install/applications
> /__cp_jdbc_ra/__cp_jdbc_ra.jar ../lib/install/applications/__xa_jdbc_
> ra/__xa_jdbc_ra.jar ../lib/install/applications/__dm_jdbc_ra/__dm_jdb
> c_ra.jar ../../javadb/lib/derby.jar ../../javadb/lib/derbyclient.jar
> ../../javadb/lib/derbynet.jar ../../javadb/lib/derbytools.jar
>
> I can not believe these can be used from an app client.
>
> My real issue is how to distribute a 'remote client' to hundreds of
> workstations and servers without installing a local GlassFish?
>
> From the (windows) workstation interactive applications are run as
> well as batch jobs, from the servers batch jobs are run which use
> the EJBs remotely.
>
> Within GlassFish instance applications (some 3rd party ones, closed
> source) are deployed which include EJBs version 2.1, 3.0 and 3.1.
>
> For the (Linux) servers the 'remote client' is distributed as an
> RPM ....
>
> -Bernhard
>
> On Tue, Jan 17, 2012 at 5:26 PM, Tim Quinn <tim.quinn_at_oracle.com>
> wrote:
>
> On Jan 17, 2012, at 10:04 AM, Bernhard Thalmayr wrote:
>
> Thanks for the information Cheng.
>
> Do you know why nearly every jar of GF installation has been
> configured as dependency in gf-client.jar?
>
> Wouldn't it be a good idea to specify only the jars which are really
> needed?
>
> The Class-Path list in gf-client.jar supports all of the
> technologies that might be used from an app client: EJBs, web
> services, JMS, etc. That's why the list is longer than the EJB-only
> list Cheng refers to.
>
> - Tim
>
>
> Regards,
> Bernhard
>
> On 1/17/12, Cheng Fang <cheng.fang_at_oracle.com> wrote:
> Hi Bernhard,
>
> Which GlassFish jars are required on the client side depends on your
> application and there is no one-size-fit-all minimum set of jar files.
> For a simple remote EJB invocation, there are about 31 individual
> GlassFish jar files that need to be present in client classpath. This
> can change from release to release. One way to find out is to start
> the
> client with -verbose:class option.
>
> -Cheng
>
> On 1/16/12 10:41 AM, Bernhard Thalmayr wrote:
> Hi experts,
> according to the EJB FAQ 'gf-client.jar' has to be used to connect to
> remote EJBs.
>
> However gf-client.jar references nearly all JARs provided with
> GlassFish installation.
>
> I'm pretty sure this is not needed ... is it?
>
> How can I create a minimalisitc set of JARs/dependencies to connect to
> remote EJBs?
>
> TIA,
> Bernhard
>
>
>
>
> --
> IT-Consulting Bernhard Thalmayr
> - Painstaking Minds -
> 83620 Vagen (Munich area)
> Germany
>
>
>
>
> --
> IT-Consulting Bernhard Thalmayr
> - Painstaking Minds -
> 83620 Vagen (Munich area)
> Germany