OK, gimme a hint..
I am a JBoss newbie. But, I have figured out by now that
the JBoss naming service (out of the box) does not provide a standard JNDI ENC to all the client programs of an applciation.
Or, it would prefer to do this client-by-client,everybody getting his
own unique JNDI ENC. No recognition (out of the box) that all the clients of an application should see a common JNDI ENC.
The Sun J2EE RI, on the other hand, does provide a standard JNDI ENC to all clients of the same EAR, and
it does this without any fuss.
Running against the Sun J2EE the all the clients can do
and it works fine, returning a ref for myBean to all clients. In JBoss, the preference seems to be that I do a different lookup, a lookup on the EJB's own JNDI name directly. Or, that I do some setup for each client program, individually.
But Sun's looser coupling (through the JNDI ENC) with a common lookup for all cooperating clients is better for portability, it seems to me. The JNDI ENC is a good thing if you don't want to have to change your source code for every server.
It really would be nice if my Sun client programs ran with JBoss as the server. The exact same code all around. I might like to bind in a test EJB in place of the production EJB by hacking the JNDI ENC as we go along. This should be possible without a lot of fuss.
There must be some simple hack to get this to work without having to make separate clients for J2EE and JBoss.
Do I hack the JNP URL, or some other client sysprop or do I hack the jboss.xml that goes with my EJB jar?
The server says this when I do my standard JNDI ENC lookup from the client:
08:00:38,096 ERROR [HAJNDI] lookupLocally failed for comp
javax.naming.NameNotFoundException: comp not bound
at java.lang.reflect.Method.invoke(Native Method)
I am using JBoss 3.0 RC2, although I don't think this makes any difference here. It seems that this is the normal situation for JBoss. What do I do to make the Sun J2EE naming service operation "normal" for JBoss?
Prosoft Technologies, Inc.
won't this work if you include an <ejb-local-ref> declaration in the bean/web client's deployment descriptor?
What you are saying (I think) is that Sun's client-jar file (as built by Sun's "deploytool") is the source of my client-side ENC-like mappings. The J2EE server isn't involved at that stage. It doesn't (and shouldn't) export the ENC(s) of its beans at run-time. so, the server is not involved in mapping client code java:comp/env references to the server resources. The client-side support has to do all this.
Yup, I had not considered this way of doing things, but I think it does work this way, in keeping with the J2EE notion of mappings created at the time of deployment. Deployment mappings are not to be changed at runtime. Unfortunately. This means that in order to change the mapping of client references so that I can put in a subsititute EJB (on the fly) without changing the compiled Java code, then the mappings at each and every client must change (on the fly). Ugh.
Oh well. Someone will fix this someday. So, has anyone succeeded in getting a Sun client-jar and its "runclient" script to run against JBoss-deployed EJBs? Not that this solves anything.
it seems to me that you might want to use some sort of service delegate (like a web service) on the server side to limit your EJBs exposure to the client.
In the sun ri, is the client you are referring to running in a client container? Or is the client in the same vm as the ejbs?
So far no one has bothered to write a jboss client container.
Yes, my client programs do run in (many) separate VMs. This is a distributed application with lots of little clients, like Instant Messenger clients or Jabber clients, one client on each desktop. (Non-web)
Regarding the Sun RI: I guess that one could say that the clients run in a client container (with Sun code). (I had not thought of this as a container before. But why not. And it could do much more about resource management than it currently does.)
The listing below is Sun's "runclient" shell script, which is what launches my mini-clients. The "container" would be the class com.sun.enterprise.appclient.Main
The APPCPATH is there to add the application code, as a special client-jar, to my normal class path. This jar is coughed up by Sun's deploytool when I deploy the EAR to the server. Of course, the EAR contains my client programs and their deployment descriptors, which is what the server/deploytool uses to manufacture the special client-jar. (I once thought that the server "registered" the clients thus packaged, but apparently not.)
When I run the script, I must set VMARGS:
VMARGS="-Dj2eelogin.name=user_name \ -Dj2eelogin.password=user_pw \
The J2EE login properties optional, for convenience during testing.
jms_client.properties are as follows:
#Possible values are SEVERE,WARNING,INFO, FINE, FINER, #FINEST.
And I give the EAR file name and the name of the particular application in this EAR that I want to run. (There may be many client applications in the client-jar, with names in each MANIFEST.MF file).
Note that there is no need to put a bunch of client
jars on my classpath.
The script looks complex, but not having to fumble with a library of client jars is a big boost. I have not yet deconstructed Sun's special client-jar, the one that the server gives me. My guess is that it is a fairly straight-forward repackaging of the client application jars that were in the EAR, with nothing else.
Here is the runner script:
# Copyright 2002 Sun Microsystems, Inc. All rights reserved.
# SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
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=\
$JAVACMD $ACTIVATION $VMARGS -classpath \ "$CPATH:$APPCPATH" \
Is it still true that JBoss 3.0 does not have any form of client container? This is a requirement for J2EE 1.3, so I don't think you can claim full compatibility without this.
What is a "client container" please ?
Could you specify which section for the spec you are talking about ?
Technically, an "application client container". Required by the 1.3 J2EE spec, chapter 9. May be a very lightweight container, but must provide deployment and security services specifed.