[GLASSFISH-1083] Thin client-side JAR for remoting Created: 05/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: standalone_client
Affects Version/s: 9.0peur1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: cowwoc Assignee: Tim Quinn
Resolution: Unresolved Votes: 12
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 1,083


I am looking for a Glassfish equivilent of hibernate-client.jar offered by JBoss
which allows EJBs to return entity beans to a remote client and if/when lazy
collections are accessed, the client initializes them automatically over the wire.

Hibernate has this going in around 250k, Glassfish's appserv-rt.jar is a
whopping 16MB and (I think) it won't even handle remote lazy initialization of

This sort of feature is a P2 or P1 in my mind (because I really need it) but
I'll leave it up to you guys to prioritize it in a more fair manner. I think the
potential of this would be huge for desktop applications or handheld devices.

Comment by vchet [ 05/Sep/06 ]
      • Issue 1083 has been confirmed by votes. ***
Comment by cowwoc [ 09/Sep/06 ]

Please check out http://www.jboss.com/developers/projects/jboss/IIOP

JBoss managed to get stubless EJBs working for RMI-IIOP by adding the stubs to
the CodeServer. I don't understand the technical details, but couldn't Glassfish
do the same? It would be great if we could just use CosNaming JNDI provider
against Glassfish for EJB3 instead of the custom JNDI provider it currently
requires. Please comment on this approach.

Comment by cowwoc [ 11/Sep/06 ]

Seems JBoss doesn't have this working (yet) either:

but I see no reason why you couldn't get CosNaming working with EJB3 RMI-IIOP.
It should be technically possible right?

Comment by ksak [ 14/Sep/06 ]

Posting snippet from related forum thread : http://forums.java.net/jive/thread.jspa?

> I don't understand why I need static RMI-IIOP stubs
> if I use the CosNaming JNDI provider.

The default naming provider in SUN's implementation already
has full RMI-IIOP support, so we have focused on that rather
than on the naming provider in Java SE. For historical reasons
the orb implementation is different between Java SE and Java EE.
Merging them is something we'd like to do but it's a large
effort and has lower priority.

> I mean, since
> JDK5 RMI no longer requires static stubs,

That's the RMI-JRMP implementation, not RMI-IIOP.

>they are
> sent over the wire to the client dynamically. Why
> then can't RMI-IIOP do the same? Surely there has to
> be a better way?

We've moved away from the entire notion of static
RMI-IIOP stubs other than legacy support for clients
coded to CosNaming. Rather than spend time improving
the experience with static RMI-IIOP stubs we've focused
on getting rid of them altogether. One tradeoff is the
need for more of our system code in the client JVM, but
the benefit is full interoperable RMI-IIOP support, no
static RMI-IIOP stubs, and support for the no-arg
InitialContext() constructor.

Comment by cowwoc [ 14/Sep/06 ]

>That's the RMI-JRMP implementation, not RMI-IIOP.

RMI-JRMP makes the stubs available from the code-servers. Isn't there a way to
port that mechanism over to RMI-IIOP somehow?

My problem with the current situation is that we're coding against a specific
RMI-IIOP implementation against some sort of interface. I am expecting to be
able to swap out different RMI-IIOP clients and be able to use them against
different RMI-IIOP servers. So in theory, GlassFish and JBoss should work
together. Can you please comment on what needs to be done to achieve this?

Unless you can reduce the client-side JAR from 16MB to say 500k I don't think
it will be realistic for use with standalone clients such as desktop
applications (which is what I'm aiming for). I understand there is a lot of
complexity going on on the server-end but what does the client-end need to do
beyond parsing for annotations and communicating over the wire using RMI-IIOP
without stubs? Sounds like this should be fairly light...? The rest (RMI) is
built into the JRE and comes for free.

Comment by Hong Zhang [ 08/Nov/07 ]

assign to tim for further evaluation.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.

Generated at Thu Mar 30 12:46:10 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.