Weblogic classes required for remote client to work


EJB programming & troubleshooting: Weblogic classes required for remote client to work

  1. Hi!

    Does anybody know what weblogic classes I need to distribute together with my own java classes which remotely access EJBs deployed to Weblogic6.0? Documentation says I need to have weblogic.jar and weblogic_sp.jar on client machine. First of all, I couldn't find weblogic_sp.jar but that's not a problem. The problem is weblogic.jar which is 15 megabytes. It's not handy to distribute such huge files to my clients (especially if I'm accessing EJBs from an applet). Thanks,

  2. Look at this thread to see how I did it on Weblogic 5.1:


    I think you'll find that the distribution for a remote client for EJB is huge...

    Good luck,

  3. Thanks, Greg.
    I have already seen your posting. Weblogic6 has different jars structure. There is weblogic.jar which is approx. 15MByte. I spent some time trying to extract the necessary classes but gave up when the size of resulting jar exceeded 5M. As long as I understand it's only JNDI part which I need on client side, but I do not understand why it's so huge? You wrote you had managed to get 9M jar needed for client side. Well, it's still too big when my applet will require this file to be dowloaded prior to start of functioning.
  4. You can try to use WebLogic 6.1 - webservices broker creates client.jar which is only ~100k in size.
  5. Thanks, Dima!
    It's quite vital topic and I did not have a chance to have my hands on version 6.1 (and it's still in beta)... Definately worth having look at it bearing in mind what you have said.
  6. An applet should be able to network classload nesessary classes from the WLS (if you have ClassPathServlet enabled).
  7. I do not think it's a good idea to use EJB from applet. Why not to use EJB from servlet and communicate with it via HTTP or RMI (if firewalls are open)?

  8. I know the tie Servlet + EJB works fine, but in my case pretty sophisticated dynamic behaviour is required which cannot be implemented via HTML.