[JBoss-dev] [ jboss-Bugs-792396 ] Incorrect behavior: transactional Sessions in EJB methods
Bugs item #792396, was opened at 2003-08-21 08:56 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 Category: JBossCX Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Steve Waldman (swaldman) Assigned to: Adrian Brock (ejort) Summary: Incorrect behavior: transactional Sessions in EJB methods Initial Comment: If a QueueSession is created in a business method of an EJB with the transacted argument of createQueueSession() set to true, JBoss fails to send the message unless the user explicitly calls commit() on the session. This is incorrect -- users should be forbidden from calling commit() or rollback(), as jboss is responsible for transaction management. According to Sun (see e.g. JMS tutorial, http://java.sun.com/ products/jms/tutorial/1_3_1-fcs/doc/jmsj2ee.html#1029338) the transacted argument should be ignored in an EJB context. My beans usually set it to true, only to document that message send is intended to be included in the method's transaction. These JMS beans break in jboss. -- Comment By: Adrian Brock (ejort) Date: 2003-08-23 23:40 Message: Logged In: YES user_id=9459 If you want the JMS session to be enlisted in the EJB transaction, you should lookup the ConnectionFactory deployed by the JMS resource adaptor. It is bound into JNDI at java:/JmsXA The value of the transacted flag is irrelevent with this connection factory. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-792396 ] Incorrect behavior: transactional Sessions in EJB methods
Bugs item #792396, was opened at 2003-08-21 03:56 Message generated for change (Comment added) made by swaldman You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 Category: JBossCX Group: v3.2 Status: Open Resolution: Remind Priority: 5 Submitted By: Steve Waldman (swaldman) Assigned to: Adrian Brock (ejort) Summary: Incorrect behavior: transactional Sessions in EJB methods Initial Comment: If a QueueSession is created in a business method of an EJB with the transacted argument of createQueueSession() set to true, JBoss fails to send the message unless the user explicitly calls commit() on the session. This is incorrect -- users should be forbidden from calling commit() or rollback(), as jboss is responsible for transaction management. According to Sun (see e.g. JMS tutorial, http://java.sun.com/ products/jms/tutorial/1_3_1-fcs/doc/jmsj2ee.html#1029338) the transacted argument should be ignored in an EJB context. My beans usually set it to true, only to document that message send is intended to be included in the method's transaction. These JMS beans break in jboss. -- Comment By: Steve Waldman (swaldman) Date: 2003-08-23 18:46 Message: Logged In: YES user_id=175530 Adrian, The value of the transacted flag is irrelevent with this connection factory. It SHOULD be irrelevant, but it is not. Messages are not delivered if transacted is set to true unless a user explicitly commits. This is the incorrect behavior. -- Comment By: Adrian Brock (ejort) Date: 2003-08-23 18:40 Message: Logged In: YES user_id=9459 If you want the JMS session to be enlisted in the EJB transaction, you should lookup the ConnectionFactory deployed by the JMS resource adaptor. It is bound into JNDI at java:/JmsXA The value of the transacted flag is irrelevent with this connection factory. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-791485 ] User roles does not update
Bugs item #791485, was opened at 2003-08-19 13:32 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=791485group_id=22866 Category: JBossSX Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Oscar Chavarria (chavao) Assigned to: Nobody/Anonymous (nobody) Summary: User roles does not update Initial Comment: I am using JBoss and Tomcat. I have a two users: ADMIN and VISIT. Steps: 1: The user VISIT has assigned the ADDR role. 2: The user VISIT is logged in the application and all roles is loaded. 3: The user VISIT use the option LOGOUT. 4: The user ADMIN is logged in the application. 5: The user ADMIN change the roles assigned to the user VISIT: from ADDR to ADDR_1. 6: The user VISIT is logged in the application again. 7: The active role for the user VISIT is ADDR. Why the roles assigned to user VISIT are not actualized in the application? What object class store this information? Best regards Oscar -- Comment By: Scott M Stark (starksm) Date: 2003-08-23 16:48 Message: Logged In: YES user_id=175228 The schema required by the DatabaseServerLoginModule is described in the admin devel guide as well as the quick start guide. Futher authentication info is cached so changed to the underlying database require the authentication cache to be flushed. This is also described in the admin devel guide as the security forum. -- Comment By: Oscar Chavarria (chavao) Date: 2003-08-20 15:22 Message: Logged In: YES user_id=848007 Submit the simplest testcase possible that demonstrates the problem -- Comment By: Oscar Chavarria (chavao) Date: 2003-08-20 15:22 Message: Logged In: YES user_id=848007 I found the solution a my problem, but now, I have another question: which values are assigned to RoleGroup column in the table roles? because by example, it is needed assign to this column the value Roles for to get the correct roles assigned to the user. Best regards -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=791485group_id=22866 --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-792396 ] Incorrect behavior: transactional Sessions in EJB methods
Bugs item #792396, was opened at 2003-08-21 03:56 Message generated for change (Comment added) made by swaldman You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 Category: JBossCX Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Steve Waldman (swaldman) Assigned to: Adrian Brock (ejort) Summary: Incorrect behavior: transactional Sessions in EJB methods Initial Comment: If a QueueSession is created in a business method of an EJB with the transacted argument of createQueueSession() set to true, JBoss fails to send the message unless the user explicitly calls commit() on the session. This is incorrect -- users should be forbidden from calling commit() or rollback(), as jboss is responsible for transaction management. According to Sun (see e.g. JMS tutorial, http://java.sun.com/ products/jms/tutorial/1_3_1-fcs/doc/jmsj2ee.html#1029338) the transacted argument should be ignored in an EJB context. My beans usually set it to true, only to document that message send is intended to be included in the method's transaction. These JMS beans break in jboss. -- Comment By: Steve Waldman (swaldman) Date: 2003-08-23 18:56 Message: Logged In: YES user_id=175530 Adrian, Sorry. I missed something in your response. It's okay. (I missed the part about having to get the XAConnectionFactory for it to be irrelevant... read too fast!) Sorry! -- Comment By: Steve Waldman (swaldman) Date: 2003-08-23 18:46 Message: Logged In: YES user_id=175530 Adrian, The value of the transacted flag is irrelevent with this connection factory. It SHOULD be irrelevant, but it is not. Messages are not delivered if transacted is set to true unless a user explicitly commits. This is the incorrect behavior. -- Comment By: Adrian Brock (ejort) Date: 2003-08-23 18:40 Message: Logged In: YES user_id=9459 If you want the JMS session to be enlisted in the EJB transaction, you should lookup the ConnectionFactory deployed by the JMS resource adaptor. It is bound into JNDI at java:/JmsXA The value of the transacted flag is irrelevent with this connection factory. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-791195 ] PropertyMap disallows changes to JNDI System properties
Bugs item #791195, was opened at 2003-08-19 05:48 Message generated for change (Settings changed) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=791195group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Stanczak (tstanczak) Assigned to: Scott M Stark (starksm) Summary: PropertyMap disallows changes to JNDI System properties Initial Comment: The class org.jboss.util.property.PropertyManager in its static part creates an instance of org.jboss.util.property.PropertyMap and replaces the original System properties using this new instance, after copying its content into the PropertyMap (which descends from Properties). According to the comments in the source of PropertyManager this is done to enable notifications about changes through System.setProperty(). The PropertyMap has yet another feature - it caches all the JNDI related properties in a separate Map to optimize access. A side effect of all this is that JNDI related properties remain read-only for the time after the replacemens of the original System properties. The reason: the getProperty method looks up the internal cache before asking original properties for a value. For all JNDI related properties the values existing in System properties at the time of the replacement are being found in the cache, so the original values are not being looked up. Since setProperty just puts the new value into the System properties but doesn't change the cache Map, any changes to the JNDI properties afterwards (regardless of the reason) remain unseen for all the outside code that uses System.getProperty. Even worse, JNDI properties not existing during the initialisation phase are being cached with null values. A real life example of a problem: Borland's visibroker during its own initialisation reads all the keys, iterates through them and saves alltogether into its own Hashtable. JNDI properties with null values cause it to break, since Hashtable doesn't allow neither null keys nor values. Regardless of the fact if visibroker does it right not checking the values before putting them into a Hashtable, turning JNDI properties into read-only doesn't feel right. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=791195group_id=22866 --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-792396 ] Incorrect behavior: transactional Sessions in EJB methods
Bugs item #792396, was opened at 2003-08-21 03:56 Message generated for change (Comment added) made by swaldman You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 Category: JBossCX Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Steve Waldman (swaldman) Assigned to: Adrian Brock (ejort) Summary: Incorrect behavior: transactional Sessions in EJB methods Initial Comment: If a QueueSession is created in a business method of an EJB with the transacted argument of createQueueSession() set to true, JBoss fails to send the message unless the user explicitly calls commit() on the session. This is incorrect -- users should be forbidden from calling commit() or rollback(), as jboss is responsible for transaction management. According to Sun (see e.g. JMS tutorial, http://java.sun.com/ products/jms/tutorial/1_3_1-fcs/doc/jmsj2ee.html#1029338) the transacted argument should be ignored in an EJB context. My beans usually set it to true, only to document that message send is intended to be included in the method's transaction. These JMS beans break in jboss. -- Comment By: Steve Waldman (swaldman) Date: 2003-08-23 19:19 Message: Logged In: YES user_id=175530 Adrian, Don't know if my last (apologetic) note took. This was totally my error. I was not using the correct ConnectionFactory. Sorry to have wasted your time. And thank you for the quick response! -- Comment By: Adrian Brock (ejort) Date: 2003-08-23 19:14 Message: Logged In: YES user_id=9459 I don't see how that can be unless you changed the resource adaptor to use non-XA connections. These obviously cannot be enlisted in an EJB transaction. If you try to commit() you will get an error because there is actually an XASession behind the scenes. Please post a simple example and confirm you are using java:/JmsXA Regards, Adrian -- Comment By: Steve Waldman (swaldman) Date: 2003-08-23 18:56 Message: Logged In: YES user_id=175530 Adrian, Sorry. I missed something in your response. It's okay. (I missed the part about having to get the XAConnectionFactory for it to be irrelevant... read too fast!) Sorry! -- Comment By: Steve Waldman (swaldman) Date: 2003-08-23 18:46 Message: Logged In: YES user_id=175530 Adrian, The value of the transacted flag is irrelevent with this connection factory. It SHOULD be irrelevant, but it is not. Messages are not delivered if transacted is set to true unless a user explicitly commits. This is the incorrect behavior. -- Comment By: Adrian Brock (ejort) Date: 2003-08-23 18:40 Message: Logged In: YES user_id=9459 If you want the JMS session to be enlisted in the EJB transaction, you should lookup the ConnectionFactory deployed by the JMS resource adaptor. It is bound into JNDI at java:/JmsXA The value of the transacted flag is irrelevent with this connection factory. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-792396 ] Incorrect behavior: transactional Sessions in EJB methods
Bugs item #792396, was opened at 2003-08-21 08:56 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 Category: JBossCX Group: v3.2 Status: Open Resolution: Remind Priority: 5 Submitted By: Steve Waldman (swaldman) Assigned to: Adrian Brock (ejort) Summary: Incorrect behavior: transactional Sessions in EJB methods Initial Comment: If a QueueSession is created in a business method of an EJB with the transacted argument of createQueueSession() set to true, JBoss fails to send the message unless the user explicitly calls commit() on the session. This is incorrect -- users should be forbidden from calling commit() or rollback(), as jboss is responsible for transaction management. According to Sun (see e.g. JMS tutorial, http://java.sun.com/ products/jms/tutorial/1_3_1-fcs/doc/jmsj2ee.html#1029338) the transacted argument should be ignored in an EJB context. My beans usually set it to true, only to document that message send is intended to be included in the method's transaction. These JMS beans break in jboss. -- Comment By: Adrian Brock (ejort) Date: 2003-08-24 00:14 Message: Logged In: YES user_id=9459 I don't see how that can be unless you changed the resource adaptor to use non-XA connections. These obviously cannot be enlisted in an EJB transaction. If you try to commit() you will get an error because there is actually an XASession behind the scenes. Please post a simple example and confirm you are using java:/JmsXA Regards, Adrian -- Comment By: Steve Waldman (swaldman) Date: 2003-08-23 23:56 Message: Logged In: YES user_id=175530 Adrian, Sorry. I missed something in your response. It's okay. (I missed the part about having to get the XAConnectionFactory for it to be irrelevant... read too fast!) Sorry! -- Comment By: Steve Waldman (swaldman) Date: 2003-08-23 23:46 Message: Logged In: YES user_id=175530 Adrian, The value of the transacted flag is irrelevent with this connection factory. It SHOULD be irrelevant, but it is not. Messages are not delivered if transacted is set to true unless a user explicitly commits. This is the incorrect behavior. -- Comment By: Adrian Brock (ejort) Date: 2003-08-23 23:40 Message: Logged In: YES user_id=9459 If you want the JMS session to be enlisted in the EJB transaction, you should lookup the ConnectionFactory deployed by the JMS resource adaptor. It is bound into JNDI at java:/JmsXA The value of the transacted flag is irrelevent with this connection factory. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Job Failed to Complete Successfully
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === === [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/jbossdo-tx.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/security-srp.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/dl10.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/cmp2-commerce.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrcsvc.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/dl11.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/https-service.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrc2.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/circularity.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrc31.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrc32.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrc3.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/security-proxy.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/securitymgr-ejb.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrc4.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/securitymgr-tests.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/jbossdo-query.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/entityref.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/interrupt.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/loadingresource.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/testcopylocaldir.sar [ear] Building ear: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/loadingresource.ear [copy] Copying 7 files to /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/jbossdo-callbacks.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/hloadingresource.ear [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/testcrashinstart.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/cmp2-lob.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/testnullinfo.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/classpath.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/brokendeployer.sar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/testmbeanclassloader.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/jbossdo-mktransient.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/sessiona.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/cmp2-optimisticlock.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/sessionb.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/eardeployment.ear [mkdir] Created dir: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/unpacked/eardeployment.ear/META-INF [copy] Copying 1 file to /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/unpacked/eardeployment.ear/META-INF [unjar] Expanding: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/sessiona.jar into /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/unpacked/eardeployment.ear/sessiona.jar [unjar] Expanding: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/sessionb.jar into /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/unpacked/eardeployment.ear/sessionb.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/abstract.jar [jar] Building jar: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/concrete.jar [ear] Building ear: /home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/cpmanifest.ear [jar] Building jar:
[JBoss-dev] [ jboss-Bugs-792396 ] Incorrect behavior: transactional Sessions in EJB methods
Bugs item #792396, was opened at 2003-08-21 08:56 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 Category: JBossCX Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Steve Waldman (swaldman) Assigned to: Adrian Brock (ejort) Summary: Incorrect behavior: transactional Sessions in EJB methods Initial Comment: If a QueueSession is created in a business method of an EJB with the transacted argument of createQueueSession() set to true, JBoss fails to send the message unless the user explicitly calls commit() on the session. This is incorrect -- users should be forbidden from calling commit() or rollback(), as jboss is responsible for transaction management. According to Sun (see e.g. JMS tutorial, http://java.sun.com/ products/jms/tutorial/1_3_1-fcs/doc/jmsj2ee.html#1029338) the transacted argument should be ignored in an EJB context. My beans usually set it to true, only to document that message send is intended to be included in the method's transaction. These JMS beans break in jboss. -- Comment By: Adrian Brock (ejort) Date: 2003-08-24 00:23 Message: Logged In: YES user_id=9459 I missed your second response, we crossed in the mail ;-) Regards, Adrian -- Comment By: Steve Waldman (swaldman) Date: 2003-08-24 00:19 Message: Logged In: YES user_id=175530 Adrian, Don't know if my last (apologetic) note took. This was totally my error. I was not using the correct ConnectionFactory. Sorry to have wasted your time. And thank you for the quick response! -- Comment By: Adrian Brock (ejort) Date: 2003-08-24 00:14 Message: Logged In: YES user_id=9459 I don't see how that can be unless you changed the resource adaptor to use non-XA connections. These obviously cannot be enlisted in an EJB transaction. If you try to commit() you will get an error because there is actually an XASession behind the scenes. Please post a simple example and confirm you are using java:/JmsXA Regards, Adrian -- Comment By: Steve Waldman (swaldman) Date: 2003-08-23 23:56 Message: Logged In: YES user_id=175530 Adrian, Sorry. I missed something in your response. It's okay. (I missed the part about having to get the XAConnectionFactory for it to be irrelevant... read too fast!) Sorry! -- Comment By: Steve Waldman (swaldman) Date: 2003-08-23 23:46 Message: Logged In: YES user_id=175530 Adrian, The value of the transacted flag is irrelevent with this connection factory. It SHOULD be irrelevant, but it is not. Messages are not delivered if transacted is set to true unless a user explicitly commits. This is the incorrect behavior. -- Comment By: Adrian Brock (ejort) Date: 2003-08-23 23:40 Message: Logged In: YES user_id=9459 If you want the JMS session to be enlisted in the EJB transaction, you should lookup the ConnectionFactory deployed by the JMS resource adaptor. It is bound into JNDI at java:/JmsXA The value of the transacted flag is irrelevent with this connection factory. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=792396group_id=22866 --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Results: 92 % ( 13 / 14 ) - come on - pull your finger out
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 14 Successful tests: 13 Errors:1 Failures: 0 [time of test: 2003-08-24.00-27 GMT] [java.version: 1.4.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_03-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-18.7] See http://jboss1.kimptoc.net/linux1/logtests/testresults/reports/html//. for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: InvocationLogUnitTestCase Test:testClientInvocationLog(org.jboss.test.aop.test.InvocationLogUnitTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - ===Sun Aug 24 01:27:41 BST 2003 ===Linux nog 2.4.20-18.7 #1 Thu May 29 08:32:50 EDT 2003 i686 unknown ===java version 1.4.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02) Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode) --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-783004 ] DistributedStateImpl listContent() NPE for non-String keys
Bugs item #783004, was opened at 2003-08-04 11:44 Message generated for change (Settings changed) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=783004group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sebastian Hauer (hauer) Assigned to: Scott M Stark (starksm) Summary: DistributedStateImpl listContent() NPE for non-String keys Initial Comment: org.jboss.ha.framework.server.DistributedStateImpl's listContent() and listXmlContent() method fail with a NullPointerException when the keys in the distributed list are non-String objects. The reason for this is that the: public Serializable get (String category, String key) is beeing called rather than the more generic: public Serializable get (String category, Serializable key) method to obtain the value of a key. Attached you will find a patch. -- Comment By: Scott M Stark (starksm) Date: 2003-08-23 17:47 Message: Logged In: YES user_id=175228 Fixed for 3.0.9 and 3.2.2RC3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=783004group_id=22866 --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-790843 ] JMX/jndi scoping problem for beans with same jndiName
Bugs item #790843, was opened at 2003-08-18 15:01 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=790843group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Stefan Reich (sreich) Assigned to: Adrian Brock (ejort) Summary: JMX/jndi scoping problem for beans with same jndiName Initial Comment: SUN's petstore components have a couple of beans that appear in several archives, and that have the same jndiName. Although perfectly legal, it causes a problem when the JMX core registers the beans because of the naming scheme it uses. Each bean is registered like this in the jboss.j2ee name space: jboss.j2ee:jndiName=local/ContactInfoEJB,service=EJB Because the record doesn't include the module name, a naming conflict occurs, and result in the deletion and recreation of the bean, but with a different classloader. This finally leads to ClassCastExceptions in arbitrary locations of the application. The test case is SUNs PetStore 1.3.1_02 on top of MySQL, which is most likely to large to attach. I can send it via email, if necessary. Errors at deploy time look like this: 12:59:12,996 ERROR [EjbModule] Initialization failed javax.management.InstanceAlreadyExistsException: jboss.j2ee:jndiName=local/ContactInfoEJB,service=EJB already registered. at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicM BeanRegistry.java:617) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBe an(BasicMBeanRegistry.java:198) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Delegating MethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(Ref lectedMBeanDispatcher.java:284) at org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke( ObjectReferenceInterceptor.java:59) at org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(M BeanAttributeInterceptor.java:43) at org.jboss.mx.interceptor.PersistenceInterceptor2.invoke(Pers istenceInterceptor2.java:93) at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java :76) .. Or 12:59:13,731 DEBUG [EJBModuleFactory] Created module: jboss.management.local: J2EEApplication=supplier.ear,J2EEServer=Local,j2eeType=EJB Module,name=supplierpo-ejb.jar 12:59:13,732 DEBUG [EJBModuleFactory] javax.management.InstanceNotFoundException: jboss.j2ee: jndiName=local/SupplierOrderEJB,service=EJB is not registered. at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicM BeanRegistry.java:354) at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanSe rverImpl.java:446) at org.jboss.management.j2ee.factory.EJBModuleFactory.create EJB(EJBModuleFactory.java:102) at org.jboss.management.j2ee.factory.EJBModuleFactory.create( EJBModuleFactory.java:65) at org.jboss.management.j2ee.LocalJBossServerDomain.handle Notification(LocalJBossServerDomain.java:383) at org.jboss.mx.server.NotificationListenerProxy.handleNotificati on(NotificationListenerProxy.java:71) at javax.management.NotificationBroadcasterSupport.sendNotifi cation(NotificationBroadcasterSupport.java:95) at org.jboss.deployment.SubDeployerSupport.start(SubDeployer Support.java:178) at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java: 558) at org.jboss.deployment.MainDeployer.start(MainDeployer.java: 824) at org.jboss.deployment.MainDeployer.start(MainDeployer.java: 816) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.jav a:632) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.jav a:605) at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Delegating MethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(Ref lectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerI mpl.java:550) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java :177) at $Proxy7.deploy(Unknown Source) -- Comment By: Scott M Stark (starksm) Date: 2003-08-23 17:24 Message: Logged In: YES user_id=175228 You need to specify a unique jndi name using the jboss.xml descriptor: jboss enterprise-beans session ejb-nameENCBean/ejb-name ejb-local-ref ejb-ref-nameejb/bean1/ejb-ref-name local-jndi-nameENCBean1/jndi-name /ejb-ref ... -- Comment By: Adrian Brock (ejort)
[JBoss-dev] [AUTOMATED] JBoss (Branch_3_2/linux1) Testsuite Compilation failed
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS==
===
===
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:77:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:121:
warning: stop() in java.lang.Thread has been deprecated
[javac] t2.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:143:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac] ^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:161:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac] ^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/ExceptionListenerTest.java:63:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac] ^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:111:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:113:
warning: stop() in java.lang.Thread has been deprecated
[javac] t2.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:168:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:170:
warning: stop() in java.lang.Thread has been deprecated
[javac] t2.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:75:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:129:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:133:
warning: stop() in java.lang.Thread has been deprecated
[javac] tf.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:74:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:116:
warning: stop() in java.lang.Thread has been deprecated
[javac] t2.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/marathon/test/BankMarathonTestCase.java:464:
cannot resolve symbol
[javac] symbol : class ApplicationDeadlockException
[javac] location: class
org.jboss.test.marathon.test.BankMarathonTestCase.RegularTeller
[javac] if( lThrowable instanceof ApplicationDeadlockException ) {
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/marathon/test/BankMarathonTestCase.java:470:
cannot resolve symbol
[javac] symbol : class ApplicationDeadlockException
[javac] location: class
org.jboss.test.marathon.test.BankMarathonTestCase.RegularTeller
[javac] if( lTRE.detail instanceof ApplicationDeadlockException ) {
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/marathon/test/BankMarathonTestCase.java:476:
cannot resolve symbol
[javac] symbol : class ApplicationDeadlockException
[javac] location: class
org.jboss.test.marathon.test.BankMarathonTestCase.RegularTeller
[javac]if( lTRE2.detail instanceof ApplicationDeadlockException ) {
[javac]^
[javac]
[JBoss-dev] [AUTOMATED] JBoss (Branch_3_2/linux1) Testsuite Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === === [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/deadlock/bean/StatelessSessionBean.java:88: cannot resolve symbol [javac] symbol : class ApplicationDeadlockException [javac] location: class org.jboss.test.deadlock.bean.StatelessSessionBean [javac] catch (ApplicationDeadlockException ade) [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/deadlock/test/BeanStressTestCase.java:189: cannot resolve symbol [javac] symbol : variable ApplicationDeadlockException [javac] location: class org.jboss.test.deadlock.test.BeanStressTestCase.OrderTest [javac] if (ApplicationDeadlockException.isADE(e) == null) [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/deadlock/test/BeanStressTestCase.java:322: cannot resolve symbol [javac] symbol : variable ApplicationDeadlockException [javac] location: class org.jboss.test.deadlock.test.BeanStressTestCase.CMRTest [javac] if (ApplicationDeadlockException.isADE(e) == null) [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:606: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:641: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:921: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:970: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:1035: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:1085: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/ClientFailTest.java:113: warning: stop() in java.lang.Thread has been deprecated [javac] t.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:77: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:121: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:143: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:161: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/ExceptionListenerTest.java:63: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:111: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:113: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:168: warning: stop() in java.lang.Thread has been deprecated
[JBoss-dev] Fioricet,Somaa,Buspare,Prozacx,and more Prescribed Online and Shipped to Your Door gpchtvvgjd blfani
hamlin Hi, Jboss-development, Mediications Prescribed Online, Get Prescribed VViagra,DietPills and muchmore online!Overnight Shiipping!! No Prescription!! s e e now! plenipotentiary adolphusn o m a i l stream parsimony h aaadm ppaakpixynqabua rw aqwkjhlpq f unpf bimini searchlight ynzgl sx qqoxfsc y hkbs emo yyy
[JBoss-dev] [AUTOMATED] JBoss (Branch_3_2/linux1) Testsuite Compilation failed
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS==
===
===
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:77:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:121:
warning: stop() in java.lang.Thread has been deprecated
[javac] t2.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:143:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac] ^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:161:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac] ^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/ExceptionListenerTest.java:63:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac] ^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:111:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:113:
warning: stop() in java.lang.Thread has been deprecated
[javac] t2.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:168:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:170:
warning: stop() in java.lang.Thread has been deprecated
[javac] t2.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:75:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:129:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:133:
warning: stop() in java.lang.Thread has been deprecated
[javac] tf.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:74:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:116:
warning: stop() in java.lang.Thread has been deprecated
[javac] t2.stop();
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/marathon/test/BankMarathonTestCase.java:464:
cannot resolve symbol
[javac] symbol : class ApplicationDeadlockException
[javac] location: class
org.jboss.test.marathon.test.BankMarathonTestCase.RegularTeller
[javac] if( lThrowable instanceof ApplicationDeadlockException ) {
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/marathon/test/BankMarathonTestCase.java:470:
cannot resolve symbol
[javac] symbol : class ApplicationDeadlockException
[javac] location: class
org.jboss.test.marathon.test.BankMarathonTestCase.RegularTeller
[javac] if( lTRE.detail instanceof ApplicationDeadlockException ) {
[javac]^
[javac]
/home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/marathon/test/BankMarathonTestCase.java:476:
cannot resolve symbol
[javac] symbol : class ApplicationDeadlockException
[javac] location: class
org.jboss.test.marathon.test.BankMarathonTestCase.RegularTeller
[javac]if( lTRE2.detail instanceof ApplicationDeadlockException ) {
[javac]^
[javac]
[JBoss-dev] [AUTOMATED] JBoss (Branch_3_2/linux1) Testsuite Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === === [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/deadlock/bean/StatelessSessionBean.java:88: cannot resolve symbol [javac] symbol : class ApplicationDeadlockException [javac] location: class org.jboss.test.deadlock.bean.StatelessSessionBean [javac] catch (ApplicationDeadlockException ade) [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/deadlock/test/BeanStressTestCase.java:189: cannot resolve symbol [javac] symbol : variable ApplicationDeadlockException [javac] location: class org.jboss.test.deadlock.test.BeanStressTestCase.OrderTest [javac] if (ApplicationDeadlockException.isADE(e) == null) [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/deadlock/test/BeanStressTestCase.java:322: cannot resolve symbol [javac] symbol : variable ApplicationDeadlockException [javac] location: class org.jboss.test.deadlock.test.BeanStressTestCase.CMRTest [javac] if (ApplicationDeadlockException.isADE(e) == null) [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:606: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:641: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:921: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:970: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:1035: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:1085: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/ClientFailTest.java:113: warning: stop() in java.lang.Thread has been deprecated [javac] t.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:77: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:121: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:143: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:161: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/ExceptionListenerTest.java:63: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:111: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:113: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:168: warning: stop() in java.lang.Thread has been deprecated
[JBoss-dev] [ jboss-Bugs-784584 ] Class-Path entry in war manifest ignored
Bugs item #784584, was opened at 2003-08-06 23:08 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=784584group_id=22866 Category: JBossWeb Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Brian Stansberry (bstansberry) Assigned to: Scott M Stark (starksm) Summary: Class-Path entry in war manifest ignored Initial Comment: JBoss 3.2.2RC2, with either Tomcat or Jetty, appears to ignore the Class-Path header in a war's Manifest.mf file. If an EAR includes a library jar that is only referenced via a war's Class-Path header, the jar is not loaded and the war will fail with ClassNotFoundExceptions. It appears the Class-Path header in an EJB jar is handled properly. Attached is a test case that demonstrates this. The attached zip includes an EAR, along with the source and Ant script to build the ear. The ear includes two trivial wars, each of which has a manifest Class-Path header pointing to its respective library jar. Each library jar includes a trivial ServletContextListener implementation that will be invoked when the war is loaded. There is also a trivial EJB. The ejb jar's manifest includes a Class-Path entry pointing to one of the library jar's. The EJB does not actually use the library; I just included the Class-Path entry to test if JBoss loads the jar based on the EJB's manifest. One of the wars has a web.xml reference to the EJB. The EJB is not really used by the war; the web.xml reference is just there to ensure the EJB is loaded before the war. The war associated with the EJB will load properly; the other war will fail with a ClassNotFoundException when the web container attempts to instantiate the ServletContextListener. In 3.2.1, both wars load properly. -- Comment By: Scott M Stark (starksm) Date: 2003-08-24 04:31 Message: Logged In: YES user_id=175228 The patch has been applied and a testcase added for the 3.2.2RC3 release. -- Comment By: Brian Stansberry (bstansberry) Date: 2003-08-11 18:29 Message: Logged In: YES user_id=695688 Patch posted in the SourceForge patch section -- Comment By: Barney Rubble (verilet) Date: 2003-08-11 17:29 Message: Logged In: YES user_id=679243 Yep, have the same problem. An EAR that works on 3.0.X and 3.2.1 and fails on anything with a 3.2.2. Jasper fails to locate beans referenced from the war's JSP pages. -- Comment By: Scott M Stark (starksm) Date: 2003-08-08 20:24 Message: Logged In: YES user_id=175228 I suspected it was the unpackwars feature. If having JarUtils create a manifest actually works that would be the preferred approach. -- Comment By: Brian Stansberry (bstansberry) Date: 2003-08-08 19:34 Message: Logged In: YES user_id=695688 I've traced this problem to the new UnpackWars behavior in AbstractWebContainer, which occurs by default in 3.2.2. The problem is when the war is unpacked, the MANIFEST.MF file is not written. When MainDeployer.parseManifestLibraries looks for any manifest classpath entries, there is no manifest file. The reason the MANIFEST.MF file isn't written is because o.j.util.file.JarUtils.unpackJar() only iterates through the ZipFileEntrys in the jar and writes those. Accessing the manifest requires calling JarInputStream.getManifest() and writing the result. Setting the new UnpackWars attribute to false doesn't seem to be a workaround, as when I tried this the web-console web-app blew up on deploy. I'd be happy to submit a patch for this, but would appreciate some direction from the powers that be on what you'd prefer: 1) Patch AbstractWebContainer so it writes the manifest (which would need to be a fairly ugly hack). 2) Patch JarUtils so it writes the manifest. This would seem cleaner, but has more possibility of impacting other code. Anyone know of any reason why it's not writing the manifest? Scanning a (month old) version of jboss-head, I found this method is invoked in the following places: o.j.persistence.jbossjdo.enhancer.JDOEnhancer.createTempDir () o.j.varia.deployment.FoeDeployer.inflateJar() o.j.web.AbstractWebContainer (as discussed above) o.j.web.catalina.EmbeddedCatalinaServiceSX.performDeploy() Best, Brian -- Comment By: Brian Stansberry (bstansberry) Date: 2003-08-07 00:18 Message: Logged In: YES user_id=695688 To get the zip to upload I had to remove a jar with the javax.ejb and servlet classes in it. So, if you want to rebuild the test you'll have to add those to the build classpath.
[JBoss-dev] [ jboss-Bugs-791195 ] PropertyMap disallows changes to JNDI System properties
Bugs item #791195, was opened at 2003-08-19 05:48 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=791195group_id=22866 Category: JBossServer Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tomasz Stanczak (tstanczak) Assigned to: Scott M Stark (starksm) Summary: PropertyMap disallows changes to JNDI System properties Initial Comment: The class org.jboss.util.property.PropertyManager in its static part creates an instance of org.jboss.util.property.PropertyMap and replaces the original System properties using this new instance, after copying its content into the PropertyMap (which descends from Properties). According to the comments in the source of PropertyManager this is done to enable notifications about changes through System.setProperty(). The PropertyMap has yet another feature - it caches all the JNDI related properties in a separate Map to optimize access. A side effect of all this is that JNDI related properties remain read-only for the time after the replacemens of the original System properties. The reason: the getProperty method looks up the internal cache before asking original properties for a value. For all JNDI related properties the values existing in System properties at the time of the replacement are being found in the cache, so the original values are not being looked up. Since setProperty just puts the new value into the System properties but doesn't change the cache Map, any changes to the JNDI properties afterwards (regardless of the reason) remain unseen for all the outside code that uses System.getProperty. Even worse, JNDI properties not existing during the initialisation phase are being cached with null values. A real life example of a problem: Borland's visibroker during its own initialisation reads all the keys, iterates through them and saves alltogether into its own Hashtable. JNDI properties with null values cause it to break, since Hashtable doesn't allow neither null keys nor values. Regardless of the fact if visibroker does it right not checking the values before putting them into a Hashtable, turning JNDI properties into read-only doesn't feel right. -- Comment By: Scott M Stark (starksm) Date: 2003-08-24 05:12 Message: Logged In: YES user_id=175228 The setProperty override has been updated to allow updates to the JNDI cached properties for the 3.2.2RC3 release. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=791195group_id=22866 --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Undeliverable: Re: Wicked screensaver
Your message To: Sales Subject: Re: Wicked screensaver Sent:Sun, 24 Aug 2003 08:50:19 -0400 did not reach the following recipient(s): Sales on Sun, 24 Aug 2003 14:38:14 -0400 The message reached the recipient's e-mail system, but delivery was refused. Attempt to resend the message. If it still fails, contact your system administrator. atl15ps640010.cypresscorp.net #5.2.1 ---BeginMessage--- Please see the attached file for details. ---End Message---
[JBoss-dev] Your attachment was deleted Re: Wicked screensaver
Cypress Communications mail system do not allow the delivery of this type of attachment. If this is a valid email attachment, contact [EMAIL PROTECTED] IT Support --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(JBoss_3_2_2_RC3 WonderLand) Testsuite Results: 24-August-2003
Automated JBoss(JBoss_3_2_2_RC3 WonderLand) Testsuite Results: 24-August-2003 JBoss daily test results SUMMARY Number of tests run: 1498 Successful tests: 1488 Errors:5 Failures: 5 [time of test: 2003-08-24.20-45 GMT] [java.version: 1.4.2] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.2-b28] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-9smp] Useful resources: - http://jboss.sourceforge.net//junit-results/32/2003-08-24.20-45 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionInTxMarkRollback_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionInTxMarkRollback_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: MissingClassUnitTestCase Test:testDeployServiceWithoutClass Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/home/starksm/JBoss/Releases/3.2.2RC3/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testNameChanges Type:failure Exception: junit.framework.AssertionFailedError Message: name.equals(copy), name=jmx - Suite: WebIntegrationUnitTestCase Test:testUnsecureRunAsServlet Type:failure Exception: junit.framework.AssertionFailedError Message: Expected reply code:200, actual=500 - Suite: SecurityUnitTestCase Test:testSecureHttpInvoker Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: JSR77SpecUnitTestCase Test:testNotificationDeliver Type:failure Exception: junit.framework.AssertionFailedError Message: Not enough notifications received: 0 - Suite: JSR77SpecUnitTestCase Test:testNavigation Type:failure Exception: junit.framework.AssertionFailedError Message: Bad attribute(MessageCache) is not a JSR77 type - --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Question re: JBoss / Log4J / RepositorySelector / Web-apps
At 03:25 PM 8/23/2003 -0400, [EMAIL PROTECTED] wrote:
Hi all, I'm trying to work with JBoss and Log4J, and have run
into a question that I can't seem to find the answer to. In the
course of trying to figure out how to specify per-application
Log4J configuration for web-apps running under JBoss,
I found this reference to the RepositorySelector mechanism:
https://www.qos.ch/logging/sc.html
What I don't know however is:
1. Does JBoss even support this mechanism?
Is JBoss written in Java? Yes, I think it is. Yep, it is
supported. Repository selectors just need some unique characteristic that
can differentiate logger repositories. There are a couple of different
obvious choices to use. One is keying on different classloaders. The
other, under a J2EE environment, is keying on a JNDI namespace. Obviously,
both of these can be used in JBoss since it uses classloaders and is a J2EE
container.
2. If so, how do I utilize it in my client code, to retrieve the app
specific
Log4J instance?
My initial thought, based on a quick perusal of the javadoc gives me the
idea I'd need something like this:
public class ControllerServlet
{
private static Logger logger;
private ServletConfig config;
public void init(ServletConfig config ) throws ServletException
{
this.config = config;
LoggerRepository repos = LogManager.getLoggerRepository();
logger = repos.getLogger( (ControllerServlet.class
).toString());
}
snip
}
is this anything close to correct?
It is actually easier than that. Your logger code doesn't need to change
at all. Just. Once the logger repository selector is used in the
initialization of Log4j, you will be using a unique logger repository.
3. assuming the above (or something similar) is used to retrieve the app
specific instance of Log4J,
is there anything special I need to do to tell Log4J where to find the
app-specific log4j.xml? Or is
simply putting log4j.xml under WEB-INF/classes sufficent? Would I still
need to call DOMConfigurator.configure()?
If you use the default initialization mechanism, you will be logging in the
default logger repository. If you put both log4j.jar and your log4j.xml in
the webapp's WEB-INF/lib and WEB-INF/classes, then you should be able to
use this mechanism since the servlet spec makes it so that the webapp class
loader is checked first for classes and resources. Only after that does it
check parent classloader. Note that this is converse to the normal Java2
class loader hierarchy. If you put log4j.jar in a parent classloader
(outside of WEB-INF/lib), however, you will need to use a repository
selector to keep your logging separated from other apps.
4. is there any configuration at the JBoss level that needs to be done to
support app-specific Log4J
instances? I know about the log4.xml under server/default/conf/ which
specifies the global Log4J
properties for the container itself... it wouldn't need to be touched for
this would it?
Not entirely sure about JBoss specifics, but if you put log4j.jar in
WEB-INF/lib, that jar will be loaded by the webapp rather than the jar
provided by the global JBoss classloader (although I'm not totally sure
about JBoss' single classloader scheme, but it seems that would violate the
servlet spec if they didn't allow for a separate webapp class loader).
However, if you want to use the global log4j.jar and use separate logger
repositories, try the servlet context listener and the custom repository
selectors I wrote in the log4j-sandbox project. Read about that stuff here...
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppContainerLogging
Also, let me apologize in advance for the cross-post. I'm genuinely not
sure which list was the
best choice to post this question too.
Actually, you should send questions like this to log4j-user rather than
log4j-dev since you have a question about Log4j's usage, not a Log4j's
development, but I'll let it slide this time :-)
Jake
Thanks,
Phillip Rhodes
Application Designer
Voice Data Solutions
919-571-4300 x225
[EMAIL PROTECTED]
No citizen shall be denied the right to bear arms, if as a last resort, to
protect themselves from tyranny in Government. - Thomas Jefferson
except crazy Republicans. Thomas Jefferson couldn't have foreseen
their ilk :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
___
JBoss-Development mailing list
[EMAIL PROTECTED]
[JBoss-dev] locking and deadlock detection changes in 3.2.2
I made some significant changes to locking and deadlock detection in 3.2.2. If anybody has time, can you look over my changes? I get nervous about making major changes to maintenance releases like the 3.2 series, so any extra eyes debugging this would be much helpful. Thanks. The EntityReentranceInterceptor now locks an EntityEnterpriseContext for the duration of the method call rather than just throwing an exception on reentrancy. The lock is actually a member variable of EntityEnterpriseContext and is implemented in server/src/main/org/jboss/ejb/plugins/lock/NonReentrantLock. I made this change so that NotSupported methods on Entity Beans would not throw an exception when concurrent access happens on these methods. An exception will still be thrown if The same transaction or thread tries to invoke on method one than once. Since we're doing locking in yet another place, this additional lock also introduces another scenario in which deadlock can happen. This is even worse because there is no transaction timeout that will interrupt the blocked threads. So, what I've done is abstracted out deadlock detection into its own classes under: common/src/main/org/jboss/util/deadlock DeadlockDetector.java Resource.java All locks now implement the Resource interface. The Resource interface has one method: getResourceHolder. The DeadlockDetector keeps a global graph of waiting resources so that it can be traversed to detect deadlock. The Reentrant locks(NonReentrantLock) for method locking in the EntityReentranceInterceptor returns a Thread object if the lock was required outside a transaction context, or it returns a Transaction if the lock was required within a transaction context. Now that we have this DeadlockDetector, we can expand deadlock detection to other locks that are beyond the scope of Entity beans. -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
