RE: [JBoss-user] Undeployment problem (still)
> you definately want to go with a single .ear for your application in > production and final testing. That should make for easier management and > will also enable optimized calls (no copying of method parameters). OK, so the option only works for beans within the same .ear? / Jonas ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Undeployment problem (still)
Jonas Bergström wrote: >>Since you have a reference to objects that have a reference to the old >>versions of the classes, the old versions of the classes can't be >>discarded. >> > I don't quite understand. Method invocations through the remote references > goes through the container, right, and I thought the container would handle > things such as ejb-redeployment? You have a good point, but stubs you have in the client have a remote reference to the server-side invoker. What JBoss does on redeploy of a bean is it discards the old invoker stack and creates a new one. This allows any requests that are being processed to complete normally, and subsequent requests pick up the new one. > > >>Have you tried this with a full .ear deployment? (from below I assume >>that you're deploying the servlet and EJBs separately) .ear deployment >>should work. This would be the answer for production. >> > > All my beans are deployed in separate .ear files, and the servlet as well. > Do you mean that I should deploy all ejbs and servlets in the same .ear? > That would really destroy my build process, which only redeploys ejbs and > servlets that have changed. you definately want to go with a single .ear for your application in production and final testing. That should make for easier management and will also enable optimized calls (no copying of method parameters). Yes, for development that might not be best. Perhaps as a work-around, set an environment property to indicate to your servlets that they're in development mode, and in this case don't cache the bean references? -danch ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Undeployment problem (still)
> Since you have a reference to objects that have a reference to the old > versions of the classes, the old versions of the classes can't be > discarded. I don't quite understand. Method invocations through the remote references goes through the container, right, and I thought the container would handle things such as ejb-redeployment? > Have you tried this with a full .ear deployment? (from below I assume > that you're deploying the servlet and EJBs separately) .ear deployment > should work. This would be the answer for production. All my beans are deployed in separate .ear files, and the servlet as well. Do you mean that I should deploy all ejbs and servlets in the same .ear? That would really destroy my build process, which only redeploys ejbs and servlets that have changed. Isn't there another solution? Thanks / Jonas > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of danch (Dan > Christopherson) > Sent: Friday, June 29, 2001 5:48 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Undeployment problem (still) > > > Since you have a reference to objects that have a reference to the old > versions of the classes, the old versions of the classes can't be > discarded. > > Have you tried this with a full .ear deployment? (from below I assume > that you're deploying the servlet and EJBs separately) .ear deployment > should work. This would be the answer for production. > > -danch > > Jonas Bergström wrote: > > > Hi folks, > > > > I posted a message a couple of months ago about hot > undeployment. I reveived > > two answers, neither work, so I'm trying again... > > > > My servlet (Tomcat in-process) has a reference to an EJB. After hot > > undeploying the EJB, the servlet is still able to invoke > methods on the EJB. > > Why? > > > > The tmp-files in /tmp/deploy/Default can't be removed since the JBoss > > process has locked them. > > The EJB class is only visible for the EJB itself, neither JBoss or the > > servlet has it in their classpath's. > > > > This is causing a problem since new versions of the EJB is not > recognized by > > the servlet. It IS recognized if the servlet creates a new > reference on each > > request, but that seems very unefficient. > > > > > > Am running JBoss 2.2.1 and Tomcat 3.2.1 on Windows 2000 Server. > > > > > > Thanks / Jonas > > > > > > ___ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Undeployment problem (still)
Since you have a reference to objects that have a reference to the old versions of the classes, the old versions of the classes can't be discarded. Have you tried this with a full .ear deployment? (from below I assume that you're deploying the servlet and EJBs separately) .ear deployment should work. This would be the answer for production. -danch Jonas Bergström wrote: > Hi folks, > > I posted a message a couple of months ago about hot undeployment. I reveived > two answers, neither work, so I'm trying again... > > My servlet (Tomcat in-process) has a reference to an EJB. After hot > undeploying the EJB, the servlet is still able to invoke methods on the EJB. > Why? > > The tmp-files in /tmp/deploy/Default can't be removed since the JBoss > process has locked them. > The EJB class is only visible for the EJB itself, neither JBoss or the > servlet has it in their classpath's. > > This is causing a problem since new versions of the EJB is not recognized by > the servlet. It IS recognized if the servlet creates a new reference on each > request, but that seems very unefficient. > > > Am running JBoss 2.2.1 and Tomcat 3.2.1 on Windows 2000 Server. > > > Thanks / Jonas > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
