Running a non-web client, deployment issues

[vman]

Hi everyone,

I have been developing EJBs on SUNs j2ee server. Needless to say, I want to deploy on something better, thus chose JBoss. I am getting to grips with the deployment descriptors, and where to put files; to check again: I am supposed to put both the EAR and client JAR files into the deploy directories ?
The point is that our application doesn't use web elements. It is Swing/AWT-based. The way we used to test it was to deploy [the EAR file presumably] the app to SUNs server, then call the client JAR with the 'runclient' command.
There are two things I really need clarification on:
1) The runclient command is actually a shell script which appearantly wraps a whole bunch of commands for convenience =>
ACTIVATION=" -Dcom.sun.enterprise.home=$J2EE_HOME -Djms.home=$JMS_HOME -Djms.properties=$J2EE_HOME/config/jms_client.properties -Djava.security.policy=$J2EE_HOME/lib/security/
client.policy -Djava.security.auth.login.config=$J2EE_HOME/lib/security/
clientlogin.config
Is my understanding correct that there are JBoss equivalents for these arguments, so that it will run under JBoss ? I just cannot find the actual java command that runs our Swing client... The only hint is the variable "$JAVACMD" which is embedded in the 'runclient' command.

2) If and when our application runs, where (in which machine's RAM) is the code executed ? Is it done remotely, so that each workstation just gets the stubs and then it all happens on the server, or are the java objects necessary to run the GUI exported to each workstation and then run there, with remote calls only to the beans on the server ? As you can see, my confusion stems largely from the fact that I don't quite understand how runclient works, which in turn prevents me from fully understanding the distributed nature of (non-web) j2ee apps :(
Please help !

Best regards,

Volkmar

[adrian.brock]

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
to System.exit();

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
descriptor.

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.

Regards,
Adrian

[chgrimm]

to deploy a gui client fist of all you need a properties file named jndi.properties with the following content:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=<your_ejb_server>:1099
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

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 )

jboss-j2ee.jar
jboss-client.jar
jnp-client.jar

(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 ;-)

[chgrimm]

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:

grant {
permission java.security.AllPermission;
};

your client must be started with the following option:
-Djava.security.policy=client.policy

if you use java-webstart instead, put the following in your jnlp file


<all-permissions/>


and beware to sign all your jars