[JBoss-dev] [ jboss-Bugs-880191 ] 3.2.3prod, jboss.xml depends breaks undeployment
Bugs item #880191, was opened at 2004-01-19 22:48 Message generated for change (Comment added) made by cazzius You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880191group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Ivan Parra (ioparra) Assigned to: Claudio Vesco (cazzius) Summary: 3.2.3prod, jboss.xml depends breaks undeployment Initial Comment: I had this problem when migrating to JBoss3.2.3 (prod). I then recreated from CVS tag JBoss_3_2_3. Here is how to set up the scenario: 1) compile JBoss_3_2_3 2) compile testsuite 3) modify the unpacked/eardeployment.ear/sessionb.jar/META- INF/jboss.xml Note: that sessiona.jar deploys Session B a) add dependsjboss.j2ee:jndiName=eardeployment/Sessi onB,service=EJB/depends to the SessionA. 4) deploy the application You can either 5) undeploy the application and look at the JMX-Console a)after undeployment, the mbean for sessionA will still exist OR 5) redeploy and get an InstanceAlreadyExistsException from the JMX layer. This did work in JBoss3.2.1. I also noticed from the MainDeployer.listDeployed()(via JMXConsole) that not all jars are in the STARTED state. Some are in START_DEPLOYER state. Check this first before testing. I saw random things in this state(jms-ds.xml, hsqldb-ds.xml, jbossmq- service.xml, etc.) Is that intentional? When I added mbean dependencies for the session, I noticed the status changes from STARTED to START_DEPLOYER. That may be the reason. If I find anything else out, I'll post. Good Luck! -Ivan -- Comment By: Claudio Vesco (cazzius) Date: 2004-01-20 08:23 Message: Logged In: YES user_id=211618 Can you try this test with current 3.2 Branch? I think that the current 3.2 branch does not have this problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880191group_id=22866 --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-880191 ] 3.2.3prod, jboss.xml depends breaks undeployment
Bugs item #880191, was opened at 2004-01-19 14:48 Message generated for change (Comment added) made by ioparra You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880191group_id=22866 Category: JBossMX Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ivan Parra (ioparra) Assigned to: Claudio Vesco (cazzius) Summary: 3.2.3prod, jboss.xml depends breaks undeployment Initial Comment: I had this problem when migrating to JBoss3.2.3 (prod). I then recreated from CVS tag JBoss_3_2_3. Here is how to set up the scenario: 1) compile JBoss_3_2_3 2) compile testsuite 3) modify the unpacked/eardeployment.ear/sessionb.jar/META- INF/jboss.xml Note: that sessiona.jar deploys Session B a) add dependsjboss.j2ee:jndiName=eardeployment/Sessi onB,service=EJB/depends to the SessionA. 4) deploy the application You can either 5) undeploy the application and look at the JMX-Console a)after undeployment, the mbean for sessionA will still exist OR 5) redeploy and get an InstanceAlreadyExistsException from the JMX layer. This did work in JBoss3.2.1. I also noticed from the MainDeployer.listDeployed()(via JMXConsole) that not all jars are in the STARTED state. Some are in START_DEPLOYER state. Check this first before testing. I saw random things in this state(jms-ds.xml, hsqldb-ds.xml, jbossmq- service.xml, etc.) Is that intentional? When I added mbean dependencies for the session, I noticed the status changes from STARTED to START_DEPLOYER. That may be the reason. If I find anything else out, I'll post. Good Luck! -Ivan -- Comment By: Ivan Parra (ioparra) Date: 2004-01-20 12:02 Message: Logged In: YES user_id=812998 Tested with Branch3_2 head. Had a few problems compiling the testsuite, but figured it shouldn't matter. It's not like I'm actually RUNNING the code, I'm just deploying it. Sure enough, this issue doesn't exist on the Branch. Good to close. I still noticed that STARTED - START_DEPLOYER after adding dependency. Is this on purpose? -- Comment By: Claudio Vesco (cazzius) Date: 2004-01-20 00:23 Message: Logged In: YES user_id=211618 Can you try this test with current 3.2 Branch? I think that the current 3.2 branch does not have this problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880191group_id=22866 --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-880191 ] 3.2.3prod, jboss.xml depends breaks undeployment
Bugs item #880191, was opened at 2004-01-19 14:48 Message generated for change (Settings changed) made by ioparra You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880191group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Ivan Parra (ioparra) Assigned to: Nobody/Anonymous (nobody) Summary: 3.2.3prod, jboss.xml depends breaks undeployment Initial Comment: I had this problem when migrating to JBoss3.2.3 (prod). I then recreated from CVS tag JBoss_3_2_3. Here is how to set up the scenario: 1) compile JBoss_3_2_3 2) compile testsuite 3) modify the unpacked/eardeployment.ear/sessionb.jar/META- INF/jboss.xml Note: that sessiona.jar deploys Session B a) add dependsjboss.j2ee:jndiName=eardeployment/Sessi onB,service=EJB/depends to the SessionA. 4) deploy the application You can either 5) undeploy the application and look at the JMX-Console a)after undeployment, the mbean for sessionA will still exist OR 5) redeploy and get an InstanceAlreadyExistsException from the JMX layer. This did work in JBoss3.2.1. I also noticed from the MainDeployer.listDeployed()(via JMXConsole) that not all jars are in the STARTED state. Some are in START_DEPLOYER state. Check this first before testing. I saw random things in this state(jms-ds.xml, hsqldb-ds.xml, jbossmq- service.xml, etc.) Is that intentional? When I added mbean dependencies for the session, I noticed the status changes from STARTED to START_DEPLOYER. That may be the reason. If I find anything else out, I'll post. Good Luck! -Ivan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880191group_id=22866 --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
