you don't have to deploy the classes into the 'lib' directory. everything can be deployed into the 'deploy' directory.
the only time you can't hot-deploy in this situation is if the ejb interface changes. if all you do is change business logic inside the ejb, then you can hot deploy the ear w/o issue. if you change the interfaces, then you need to restart the server in order for the changes to be picked up. what you should end up having is the following: - a jar w/ all the ejb interfaces in addition to any additional classes that interface needs to operate (ie, if one of your methods returns an object of class type Foo, then Foo.class needs to be packaged in the same jar as the ejb interfaces). - EAR1 w/ all necessary classes it needs to operate minus those contained in the jar - EAR2 w/ all the necessary classes minus those included in the jar. provided the ejb interface does not change (or any of the other classes contained inside the jar) you can hot deploy EAR1 and/or EAR2 w/o problem. if the classes inside the jar do change, then you need the server restart. i highly recommend spending the 10 bux (if you haven't done so already) and getting the jboss admin book. chapter 2 talks all about this (see the classloader section). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3837421#3837421 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3837421 ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user