Hi, This is a problem for me too. jBoss 3.0.1RC1, Sun JDK1.4 on windows...
Torsten > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Eric Kaplan > Sent: 2. juli 2002 21:20 > To: Sullivan, Sean C - MLG > Cc: Jboss-User > Subject: RE: [JBoss-user] is coding a bean truly independent from > deployment? > > > Yes. If you re-deploy an ear file you get a classcastexception on the > server when trying to lookup a bean that was looked up fine before the > deploy. Here's an excerpt of mail on this in which Burkhard confirmed the > problem. If this is not a problem, please tell me, because I'd like to be > able to hot re-deploy my ear. > > Eric > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Burkhard > Vogel > Sent: Friday, June 14, 2002 12:08 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] 3.0 a moving target? > > > Hi, > JDBC-access has changed, see the provided examples. As for > "portableremoteobject.narrow": if you are on JDK 1.4, this is a known sun > bug. > Regards, > Burkhard > ----- Original Message ----- > From: "Eric Kaplan" <[EMAIL PROTECTED]> > To: "Jboss-User" <[EMAIL PROTECTED]> > Sent: Friday, June 14, 2002 10:22 AM > Subject: [JBoss-user] 3.0 a moving target? > > > > I was happily using jboss3.0.0RC1_tomcat-4.0.3. However, I stumbled > across > > a problem with hot re-deploy in which it seemed that after i hot > re-deployed > > by .ear i got a classcastexception on the server when trying to lookup a > > bean that had worked before. It was almost as if the jndi > mapping for one > > bean somehow got configured with another and when I cast the > > portableremoteobject.narrow the exception occured. > > > > I thought maybe this might have been addressed with the latest > version of > > jboss, so i downloaded jboss3.0.0_tomcat-4.0.3. Now my problem > is worse. > I > > put my changed oracle-service.xml in server/default/conf (as i had done > > before), but now i get that my jdbc resource is not bound (even though > this > > worked before!). what has changed from rc1 that would cause this? > > > > Eric Kaplan > > Armanta, Inc. > > 55 Madison Ave. > > Morristown, NJ 07960 > > Phone: (973) 326-9600 > > -----Original Message----- > From: Sullivan, Sean C - MLG [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 02, 2002 3:06 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-user] is coding a bean truly independent from > deployment? > > > > > Really? Can you provide details? > > > -----Original Message----- > > From: Eric Kaplan [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, July 02, 2002 11:43 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-user] is coding a bean truly independent from > > deployment? > > > > although the hot deploy currently does not work properly under > jdk 1.4 ... > > :( > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Burkhard > > Vogel > > Sent: Monday, July 01, 2002 4:20 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-user] is coding a bean truly independent from > > deployment? > > > > > > Hi, > > AFAIK there is no such thing as a bean deployer as a person > with decisions > > to make. You on your own decide witch transactions etc you want by > > generating the ejb-jar.xml. The only deployer I know is a software tool > > for > > lame app-servers without a nifty super-easy drag'n'drop hotdeploy > > easeofuse > > feature like JBoss. > > Regards, > > Burkhard > > ----- Original Message ----- > > From: "Eric Kaplan" <[EMAIL PROTECTED]> > > To: "Jboss-User" <[EMAIL PROTECTED]> > > Sent: Monday, July 01, 2002 1:24 PM > > Subject: [JBoss-user] is coding a bean truly independent from > deployment? > > > > > > > The theory certainly seems to suggest that there is the ejb coder and > > the > > > ejb deployer, and that neither one should have to do much with the > > other. > > > If bean A calls bean B, a deployer can choose to have bean B > be Required > > or > > > RequiresNew at deployment time. However, in reality, the choice has a > > lot > > > to do with how bean A is coded, doesn't it? In other words, bean B > > throws > > > EJBException on error, causing the transaction to roll back. If the > > > deployer has set B to Required and A continues merrily it's a problem, > > since > > > the transaction that A was in is now rolled back. If the > deployer sets > > B > > to > > > RequiresNew and A continues merrily, no problem. If this is true, > > what's > > a > > > bean coder to do if he doesn't know the intended transaction semantics > > ahead > > > of time? Conversely, if he does know the intended transaction > > semantics, > > > what's a bean deployer to do? Am I thinking about this wrong? I've > > been > > > grappling with this issue for a while. > > > > > > Thanks > > > > > > Eric Kaplan > > > Armanta, Inc. > > > 55 Madison Ave. > > > Morristown, NJ 07960 > > > Phone: (973) 326-9600 > > > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
