Caveat, I have never used runclient.
Unfortunatly JBoss doesn't have an equivalent of
runclient. Also called Application Client in the J2EE
spec. It is an optional and under-specfied part of J2EE.
Basically an Application Client is a jar that can
run in a mini Application Server and talk to the
main Application Server(s). The spec
requires all J2EE apis to be available, but the
only required services are JNDI and Security.
The client code has no restrictions
on the operations it can perform, e.g. it is legal
The bit that is missing from JBoss is the parsing
of the client deployment descriptor on both the
client and server.
Since JBoss is highly modularised you can construct the
equivalent of an Application Client yourself.
The minimal config included with JBoss3 would be a start,
it is just JNDI and JMX.
You could add as many or as few other services as you
like, e.g. managed connections.
The only downside is that it won't be portable to other
App Servers if it isn't based on the client deployment
I did see a post once that somebody had done just this
(it might even have parsed the client descriptor?)
But it wasn't contributed back to the JBoss codebase :-(
The answer to your specific questions are that the
client code runs locally, but it has remote
access to the Application Server(s) through the normal
jndi lookups and a java:comp namespace.
to deploy a gui client fist of all you need a properties file named jndi.properties with the following content:
add this file to your application jar
to load the context, do the following
Properties jndiProperties = new Properties();
jndiProperties.load( getClass().getResourceAsStream("/jndi.properties") );
InitialContext ctx = new InitialContext( jndiProperties );
then you need to add some jar files to your classpath:
( and also to include them in the client distribution )
(if there are others needed for a basic client someone could pls. corrrect )
to start a client you can use three different ways:
a) create a script file that sets your classpath and starts your gui main class
b) in your application jar file use the manifest to set the classpath and the main class and execute the jar directly ( in M$-OS you can even link the jar extension to java so one only needs to click on the jar file )
c) use java-webstart to launch your gui. beware that if your gui need's to access restricted resources, you have to sign all the jar files mentioned above.
btw. i thing the main problem with the sun ri is that it makes people think they know about j2ee when they have sucessfully clicked the right buttons.
the advantage of jboss is, that you have to read and understand the j2ee specs at least to some part to write the descriptors ;-)
i forgot one issue:
jboss does not use stubs generated in advance and ditributed with the client, but so called dynamic proxies.
these are downloaded to the client at runtime by the RMIClassloader
therefor you have to create a policy file like client.policy
with at least this minimal content:
your client must be started with the following option:
if you use java-webstart instead, put the following in your jnlp file
and beware to sign all your jars