Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Deployment of EJBs on JBoss [$Proxy92 ??]  RSS feed

 
clive jordan
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I am trying to talk to a session bean deployed on jboss 4.0. This is my first stab at EJBs so I may be doing something pretty daft. The whole lot is run from ant on the same machine (Linux 2.4.29 kernel).


I place my jar file in the jboss deploy directory and the console displays this:

16:40:25,644 INFO [EjbModule] Deploying CliveSessionBean
16:40:25,704 INFO [EJBDeployer] Deployed: file:/home/clive/usr/local/jboss-4.0.1/server/default/deploy/cliveSession.jar


So it looks like the bean is being picked up ok by the jboss server.

The jar file looks like this:

jar tvf cliveSession.jar
0 Tue Apr 26 16:40:26 BST 2005 META-INF/
106 Tue Apr 26 16:40:24 BST 2005 META-INF/MANIFEST.MF
947 Tue Apr 26 15:56:34 BST 2005 META-INF/ejb-jar.xml
359 Tue Apr 26 16:40:12 BST 2005 META-INF/jboss.xml
0 Tue Apr 26 15:47:52 BST 2005 com/
0 Tue Apr 26 15:47:52 BST 2005 com/jordan/
0 Tue Apr 26 15:47:52 BST 2005 com/jordan/sessionBean/
1538 Tue Apr 26 16:40:26 BST 2005 com/jordan/sessionBean/CliveSessionBean.class
2315 Tue Apr 26 16:40:26 BST 2005 com/jordan/sessionBean/CliveSessionBeanClient.class
312 Tue Apr 26 16:40:26 BST 2005 com/jordan/sessionBean/CliveSessionHome.class
260 Tue Apr 26 16:40:26 BST 2005 com/jordan/sessionBean/CliveSessionRemote.class


I guess I do not need the client class in there but I also assume it does no harm.

The Two xml files look like this:
ejb-jar.xml:



jboss.xml:



And if I write a small program to dump the contents of the jboss JNDI server I get this (ignore the [java] parts - this is ant output:



Now I see my JNDI entry is:

[java] Name=MyFirstSessionBean: $Proxy92



- Although I am not sure what the $Proxy92 represents - I was expecting the class-name

However, when I try to connect via a client (on the same machine), basic JNDI lookup fails with this:

[java] Naming Exception:null

The client code where the failure occurs is here (apologies for the formatting):




The section that reads the properties file is the same code I use when dumping the directory contents so I believe I have the basic connectivity set up correctly.

So, after all this verbose waffle, it looks to me like the $Proxy92 may be what is causing me issues. I am not putting the real class into the JNDI directory so am not reading it back correctly.

Is there something I am not doing during the deployment process? All I am doing at the moment is packaging the jar file as shown above and dropping it in the ~jboss/server/default/deploy directory. Do I need to set up RMI stubs/skeletons? I can find nothing in the jboss documentation saying I need to do this.

Sorry if this is a really basic question, I just feel I am missing something here and cannot find anything in the documentation to lead me down the right path.

Any help greatly appreciated !

Clive
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,


Is there something I am not doing during the deployment process?

I�m not using jboss, but your packing and your deployment descriptors look fine to me (weblogic dd are almost identical though). Moreover I believe that your bean is deployed correctly as well. In my opinion you did everything right.

Do I need to set up RMI stubs/skeletons?

This I�m pretty sure you don�t need to bother about. Modern containers use dynamic proxies and they will download the stubs for you using the dynamic class loading feature provided by RMI. I�m speaking from my experience with Weblogic but I�m quite sure jobs is similar.

Sorry if this is a really basic question, I just feel I am missing something here and cannot find anything in the documentation to lead me down the right path.

There is only one suggestion I could make: when you run your client, did you add to the classpath the home and remote interfaces? I mean CliveSessionHome.class and CliveSessionRemote.class.
Regards.
 
clive jordan
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Valentin,

Thanks for the reply and the suggestions. Unfortunately I have not had much luck, my original ant target for the client was:


If I remove any of the .jar files from the target I get exceptions thrown so they are needed. I tried explicitly adding the sessionBean jar file as you suggested but to no avail:


At least it's gratifying to know I not doing anything too stupid. I will bang my head against this for a few more hours, revisit the actual sessionBean code and see if anything drops out.

Once again, thanks for the suggestion, it was most appreciated!

Clive
 
rahul bivalkar
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I am trying to run the Tassie Online Book Store
Example. Details are also available on:
http://benmira.free.fr/en/j2ee/sessionEJB.htm#ch29lev1sec4

While I successfully compiled the Search (plus the
other 2), BookDetails( plus the other 2). Finally when
i come to the Cart set of EJBs, I am able to compile
Cart.java, and CartHome.java. But when i try to
compile Cartbean.java compilation fails.

The details are as below:

C:\classes>javac -classpath
C:\jboss\client\jboss-j2ee.jar;. com/brainysoftware/
tassie/ejb/CartBean.java
com/brainysoftware/tassie/ejb/CartBean.java:35: cannot
resolve symbol
symbol : variable cart
location: class com.brainysoftware.tassie.ejb.CartBean
cart.add(row);
^
com/brainysoftware/tassie/ejb/CartBean.java:40: cannot
resolve symbol
symbol : variable cart
location: class com.brainysoftware.tassie.ejb.CartBean
return cart;
^
2 errors

----------------------

All help is gratefully accepted and acknowledged. Thanks in advance.



___________________________
 
clive jordan
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gidday

I have been banging my head against this problem for a while and finally managed to solve it. I thought I'd post my findings to the forum so that it may be useful to others who have the same problem.

There were two issues causing me grief, one caused by ant, one by system setup. The EJB part was ok.

ANT: Use a seperate JVM
I forced ant to create a new JVM when running the client code. I do not know whether this actually helped, but I started getting more meaningful debug messages.


RMI and Security Managers:
It appears that in order to allow the client to automatically download the RMI stub, you need the RMISecurityManager enabled. By default, (on my system), it was not.

So in my client program, I added this:

if ( System.getSecurityManager() == null )
{
System.setSecurityManager( new RMISecurityManager() );
 
clive jordan
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I have been banging my head against this problem for a while and finally managed to solve it. I thought I'd post my findings to the forum so that it may be useful to others who have the same problem.

There were two issues causing me grief, one caused by ant, one by system RMI setup. The EJB part was ok.

ANT: Use a seperate JVM
I forced ant to create a new JVM when running the client code. I do not know whether this actually helped, but I started getting more meaningful debug messages.


RMI and Security Managers:
It appears that in order to allow the client to automatically download the RMI stub, you need the RMISecurityManager enabled. By default, (on my system), it was not.

So in my client program, I added this right at the start of the main() method:

if ( System.getSecurityManager() == null )
{
System.setSecurityManager( new RMISecurityManager() );
}

Running the client again showed that the system could not read my jndi.properties file from the filesystem. I then altered the client code to do away with this and hard-coded the details (bad, but I just wanted to get things going):



Running the client again now indicated that I was being refused permission to open a socket (presumably to JNDI server).

Having had a poke around on my system, there are security policy files. These exist both within the jboss directory tree and also within the J2EE (Sun) tree.

Rather than editing these, I created my own policy file that allowed everything (ie becomes much less secure). This file I called .java.policy and included in my home directory. The content of this file is:



Now it was time to revisit ant and tell it to use my security policy file rather than a system one. The full ant target is here:


I ran the client and (at last!) it worked.

The next steps are to try and revert back to loading JNDI data from a file and then try and screw-down the java.policy file. I suspect this can be done by allowing certain files to be loaded and certain sockets to be opened.

I have a very sore forehead from hitting it on the desk and feel frustrated in that none of the documentation I have read regarding EJB deployment has mentioned anything about RMI security managers. I have a fresh j2EE and jboss installation and not altered them, so it appears the RMISecurityManager is disabled by default (unix).

So, I hope this may be helpful to anyone who has a similar problem !!

Cheers,
Clive
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!