[JBoss-dev] [ jboss-Feature Requests-531255 ] SSL support for all sockets
Feature Requests item #531255, was opened at 2002-03-18 03:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376688aid=531255group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Priority: 5 Submitted By: Alarik Myrin (alarik) Assigned to: Nobody/Anonymous (nobody) Summary: SSL support for all sockets Initial Comment: From a security perspective, having SSL support for all services that use sockets would really improve matters. For example, JMS messages may well contain confidential and sensitive data, and it should be possible to encrypt their tranmission with SSL. SSL has another benefit: (I believe) it is a fairly simple matter to configure the use of a proxy server to proxy SSL sockets. Many proxies are already configured to proxy SSL on port 443, and thus it is possible to allow real app-server access over the internet from behind proxies that you do not control. I don't know how difficult all of this is (perhaps it is already possible, and I just don't know how to configure it, in which case I apologize for wasting everyone's time and would appreciate any direction anyone wanted to send my way...) I currently work on a software project that uses SSL to connect to Weblogic over the internet from behind any number of firewalls and proxies, allowing everything from creation of InitialContexts, JMS messaging, and EJB calls. I actually may work on implementing this request for a local build of JBoss with or without encouragement, but certainly welcome feedback/direction/criticism/advice/etc. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376688aid=531255group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource ConnectionFactoryLoader.java
User: cazzius
Date: 02/03/18 00:44:29
Modified:src/main/org/jboss/resource ConnectionFactoryLoader.java
Log:
Use J2EEManagerObject.TYPE, JMSResource.J2EE_TYPE and JDBCDataSource.J2EE_TYPE when
checking if a JSR-77 object exists
Revision ChangesPath
1.24 +19 -6 jbosscx/src/main/org/jboss/resource/ConnectionFactoryLoader.java
Index: ConnectionFactoryLoader.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/ConnectionFactoryLoader.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ConnectionFactoryLoader.java 6 Mar 2002 01:07:45 - 1.23
+++ ConnectionFactoryLoader.java 18 Mar 2002 08:44:29 - 1.24
@@ -50,6 +50,7 @@
import org.jboss.resource.security.PrincipalMapping;
import org.jboss.system.ServiceMBeanSupport;
+import org.jboss.management.j2ee.J2EEManagedObject;
import org.jboss.management.j2ee.JDBCDataSource;
import org.jboss.management.j2ee.JMSResource;
import org.jboss.deployment.DeploymentException;
@@ -68,7 +69,7 @@
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
* @seeRARDeployer
- * @version$Revision: 1.23 $ p
+ * @version$Revision: 1.24 $ p
*
* bRevisions:/b
*
@@ -393,7 +394,10 @@
try {
java.util.Set lNames = getServer().queryNames(
- new ObjectName( *:type=JDBCDataSource,name= + jndiName + ,* ),
+ new ObjectName( *: +
+J2EEManagedObject.TYPE + = + JDBCDataSource.J2EE_TYPE
+
+,name= + jndiName +
+,* ),
null
);
if( lNames.iterator().hasNext() ) {
@@ -410,11 +414,14 @@
try {
java.util.Set lNames = getServer().queryNames(
- new ObjectName( *:type=JMSResource,name= + jndiName + ,* ),
+ new ObjectName( *: +
+J2EEManagedObject.TYPE + = + JMSResource.J2EE_TYPE +
+,name= + jndiName +
+,* ),
null
);
if( lNames.iterator().hasNext() ) {
- // Destroy JSR-77 JDBCDataSource
+ // Destroy JSR-77 JMSResource
JMSResource.destroy(
getServer(),
jndiName
@@ -795,7 +802,10 @@
{
try {
java.util.Set lNames = getServer().queryNames(
- new ObjectName( *:type=JDBCDataSource,name= + jndiName + ,* ),
+ new ObjectName( *: +
+J2EEManagedObject.TYPE + = + JDBCDataSource.J2EE_TYPE
+
+,name= + jndiName +
+,* ),
null
);
if( lNames.iterator().hasNext() ) {
@@ -818,7 +828,10 @@
{
try {
java.util.Set lNames = getServer().queryNames(
- new ObjectName( *:type=JMSResource,name= + jndiName + ,* ),
+ new ObjectName( *: +
+J2EEManagedObject.TYPE + = + JMSResource.J2EE_TYPE +
+,name= + jndiName +
+,* ),
null
);
if( lNames.iterator().hasNext() ) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Ordering part 2 :-)
Hi alls! I think we have a little bug in MainDeployer. I'll try to explain the problem in my bad English :-( When I deploy redeploy an ear I have an JSR-77 exception (javax.management.InstanceNotFound) because: deploy init init current deployer invoked init subdeployers invoked create create subdeployers invoked create current deployer invoked start start subdeployers invoked start current deployer invoked undeploy stop stop current deployer invoked stop subdeployers invoked destroy destroy current deployer invoked destroy subdeployers invoked I think the right order is: deploy init (ok) init current init subdeployers create create current create subdeployers start start current start subdeployers undeploy stop stop subdeployers stop current destroy destroy subdeployers destroy current When I have modified the MainDeployer with this new order the exception has not been take place. If Marc is of agreement can apply the patch or I can post it. Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Ordering part 2 :-)
What exactly is the problem you are having? Can you post a small detailed example? As I understand your proposal you want to deploy from the outside in rather than the inside out. I think this won't work for most packages: for instance I don't think we can put our sar packages inside ejb-jars so they could get deployed after the ejb-jar, whereas you can put an ejb-jar inside a sar to get it deployed before the sar. Please explain further. david jencks On 2002.03.18 04:19:56 -0500 Vesco Claudio wrote: Hi alls! I think we have a little bug in MainDeployer. I'll try to explain the problem in my bad English :-( When I deploy redeploy an ear I have an JSR-77 exception (javax.management.InstanceNotFound) because: deploy init init current deployer invoked init subdeployers invoked create create subdeployers invoked create current deployer invoked start start subdeployers invoked start current deployer invoked undeploy stop stop current deployer invoked stop subdeployers invoked destroy destroy current deployer invoked destroy subdeployers invoked I think the right order is: deploy init (ok) init current init subdeployers create create current create subdeployers start start current start subdeployers undeploy stop stop subdeployers stop current destroy destroy subdeployers destroy current When I have modified the MainDeployer with this new order the exception has not been take place. If Marc is of agreement can apply the patch or I can post it. Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Ordering part 2 :-)
If you try to make the deploy of a ear, then you make the undeploy and therefore you make the deploy of the same one ear, comes written in log one exception. In this moment, I don't have the possibility to give you a better example, but I think you can reproduce the exception with the above operations. I think that the problem is that in the management of the resources jsr77 it does not come created the resource before father but tries to create the dependent resources. With the changed order, the exception does not happen. The proposed resolution does not resolve the problem discussed in the maillist, but resolves an other problem. Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 1:51 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Ordering part 2 :-) What exactly is the problem you are having? Can you post a small detailed example? As I understand your proposal you want to deploy from the outside in rather than the inside out. I think this won't work for most packages: for instance I don't think we can put our sar packages inside ejb-jars so they could get deployed after the ejb-jar, whereas you can put an ejb-jar inside a sar to get it deployed before the sar. Please explain further. david jencks On 2002.03.18 04:19:56 -0500 Vesco Claudio wrote: Hi alls! I think we have a little bug in MainDeployer. I'll try to explain the problem in my bad English :-( When I deploy redeploy an ear I have an JSR-77 exception (javax.management.InstanceNotFound) because: deploy init init current deployer invoked init subdeployers invoked create create subdeployers invoked create current deployer invoked start start subdeployers invoked start current deployer invoked undeploy stop stop current deployer invoked stop subdeployers invoked destroy destroy current deployer invoked destroy subdeployers invoked I think the right order is: deploy init (ok) init current init subdeployers create create current create subdeployers start start current start subdeployers undeploy stop stop subdeployers stop current destroy destroy subdeployers destroy current When I have modified the MainDeployer with this new order the exception has not been take place. If Marc is of agreement can apply the patch or I can post it. Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: HTTP loadbalancing
So has anybody actually tried the load balancer? Or is it not such a needed feature after all :-) cheers -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Ordering part 2 :-)
Could you please show the exception you are seeing in the log. This will help me 1. understand without having to reproduce the problem what you are writing about. 2. If I do attempt to reproduce the problem, indicate to me that I have found the same problem you are working with. Have you seen this problem with any .ears from the testsuite? Thanks david jencks On 2002.03.18 08:35:57 -0500 Vesco Claudio wrote: If you try to make the deploy of a ear, then you make the undeploy and therefore you make the deploy of the same one ear, comes written in log one exception. In this moment, I don't have the possibility to give you a better example, but I think you can reproduce the exception with the above operations. I think that the problem is that in the management of the resources jsr77 it does not come created the resource before father but tries to create the dependent resources. With the changed order, the exception does not happen. The proposed resolution does not resolve the problem discussed in the maillist, but resolves an other problem. Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 1:51 PM To: [EMAIL PROTECTED] Subject:Re: [JBoss-dev] Ordering part 2 :-) What exactly is the problem you are having? Can you post a small detailed example? As I understand your proposal you want to deploy from the outside in rather than the inside out. I think this won't work for most packages: for instance I don't think we can put our sar packages inside ejb-jars so they could get deployed after the ejb-jar, whereas you can put an ejb-jar inside a sar to get it deployed before the sar. Please explain further. david jencks On 2002.03.18 04:19:56 -0500 Vesco Claudio wrote: Hi alls! I think we have a little bug in MainDeployer. I'll try to explain the problem in my bad English :-( When I deploy redeploy an ear I have an JSR-77 exception (javax.management.InstanceNotFound) because: deploy init init current deployer invoked init subdeployers invoked create create subdeployers invoked create current deployer invoked start start subdeployers invoked start current deployer invoked undeploy stop stop current deployer invoked stop subdeployers invoked destroy destroy current deployer invoked destroy subdeployers invoked I think the right order is: deploy init (ok) init current init subdeployers create create current create subdeployers start start current start subdeployers undeploy stop stop subdeployers stop current destroy destroy subdeployers destroy current When I have modified the MainDeployer with this new order the exception has not been take place. If Marc is of agreement can apply the patch or I can post it. Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] when does website get rebuilt?
Is it done automatically? Or do you have to ping somebody to do it? Thanks, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Ordering part 2 :-)
It does not stop deploy/redeploy, only produce an exception in log. I test the testsuite now :-) Per quanto riguarda la discussione che avvenuta a riguardi dell'ordinamento, penso che le dipendenze tra risorse debbano essere indicate in un jboss-application.xml Concerning the recently discussion, I think that the dependecies between resources must be included in application-jboss.xml. The order proposed in MainDeployer I think is this correct KISS :-) If I have a ear containing sar containing ear etc etc etc, it does not standard (j2ee compliant) and so - application-jboss.xml :-) Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 5:22 PM To: Vesco Claudio Subject: Re: [JBoss-dev] Ordering part 2 :-) Does this actually stop undeployment/redeployment or only produce an ugly log? Previously Andy indicated (I think) that the jsr-77 stuff should not impede redeployment, no matter how many errors it put in the log. I am _very_ worried about reversing the order of subdeployment nesting without a more complete dependency mechanism. If this is not stopping redeployment I would prefer to leave it till I can think about it more carefully. Have you seen what happens with your change with 1. the testsuite and 2. more complicated packaging such as ear containing sar containing ear containing rar? Thanks david jencks On 2002.03.18 09:48:08 -0500 Vesco Claudio wrote: Only for you :-) I have deployed bench.ear from testsuite and when I undeploy it I have this exception, ehm zipped :-) With call reordering I don't have exception :-) Claudio undeploy-exception.zip Patch.zip -Original Message- From: Vesco Claudio [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:27 PM To: 'David Jencks'; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Ordering part 2 :-) I'll retest jboss without my patchs :-) please wait a moment :-) -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:24 PM To: [EMAIL PROTECTED] Subject:Re: [JBoss-dev] Ordering part 2 :-) Could you please show the exception you are seeing in the log. This will help me 1. understand without having to reproduce the problem what you are writing about. 2. If I do attempt to reproduce the problem, indicate to me that I have found the same problem you are working with. Have you seen this problem with any .ears from the testsuite? Thanks david jencks On 2002.03.18 08:35:57 -0500 Vesco Claudio wrote: If you try to make the deploy of a ear, then you make the undeploy and therefore you make the deploy of the same one ear, comes written in log one exception. In this moment, I don't have the possibility to give you a better example, but I think you can reproduce the exception with the above operations. I think that the problem is that in the management of the resources jsr77 it does not come created the resource before father but tries to create the dependent resources. With the changed order, the exception does not happen. The proposed resolution does not resolve the problem discussed in the maillist, but resolves an other problem. Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 1:51 PM To: [EMAIL PROTECTED] Subject:Re: [JBoss-dev] Ordering part 2 :-) What exactly is the problem you are having? Can you post a small detailed example? As I understand your proposal you want to deploy from the outside in rather than the inside out. I think this won't work for most packages: for instance I don't think we can put our sar packages inside ejb-jars so they could get deployed after the ejb-jar, whereas you can put an ejb-jar inside a sar to get it deployed before the sar. Please explain further. david jencks On 2002.03.18 04:19:56 -0500 Vesco Claudio wrote: Hi alls! I think we have a little bug in MainDeployer. I'll try to explain the problem in my bad English :-( When I deploy redeploy an ear I have an JSR-77 exception (javax.management.InstanceNotFound) because: deploy init init current deployer invoked init subdeployers invoked create create subdeployers invoked create current deployer invoked start start subdeployers invoked
Re: [JBoss-dev] Ordering part 2 :-)
On 2002.03.18 11:46:32 -0500 Vesco Claudio wrote: It does not stop deploy/redeploy, only produce an exception in log. I test the testsuite now :-) Thanks Per quanto riguarda la discussione che avvenuta a riguardi dell'ordinamento, penso che le dipendenze tra risorse debbano essere indicate in un jboss-application.xml Concerning the recently discussion, I think that the dependecies between resources must be included in application-jboss.xml. The order proposed in MainDeployer I think is this correct KISS :-) I think there are arguments in favor of both orders. If I have a ear containing sar containing ear etc etc etc, it does not standard (j2ee compliant) and so - application-jboss.xml :-) True, but some nesting is allowed by j2ee, and needs to be handled without any jboss-application.xml needed. I think that most of these problems will go away when we can represent most dependencies as (automatically generated) mbean dependencies. I think we will be able to deploy just about anything packaged in just about any nesting without needing explicit deployment instructions. btw, I think two possible fixes I would be happier with are 1. jsr 77 mbeans destroy all their children when they are destroyed. 2. create, and start steps remain ordered from inside to outside, stop step remains ordered from outside to inside, destroy step is reversed to from inside to outside. Thanks david jencks Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 5:22 PM To: Vesco Claudio Subject:Re: [JBoss-dev] Ordering part 2 :-) Does this actually stop undeployment/redeployment or only produce an ugly log? Previously Andy indicated (I think) that the jsr-77 stuff should not impede redeployment, no matter how many errors it put in the log. I am _very_ worried about reversing the order of subdeployment nesting without a more complete dependency mechanism. If this is not stopping redeployment I would prefer to leave it till I can think about it more carefully. Have you seen what happens with your change with 1. the testsuite and 2. more complicated packaging such as ear containing sar containing ear containing rar? Thanks david jencks On 2002.03.18 09:48:08 -0500 Vesco Claudio wrote: Only for you :-) I have deployed bench.ear from testsuite and when I undeploy it I have this exception, ehm zipped :-) With call reordering I don't have exception :-) Claudio undeploy-exception.zip Patch.zip -Original Message- From: Vesco Claudio [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:27 PM To: 'David Jencks'; [EMAIL PROTECTED] Subject:RE: [JBoss-dev] Ordering part 2 :-) I'll retest jboss without my patchs :-) please wait a moment :-) -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:24 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Ordering part 2 :-) Could you please show the exception you are seeing in the log. This will help me 1. understand without having to reproduce the problem what you are writing about. 2. If I do attempt to reproduce the problem, indicate to me that I have found the same problem you are working with. Have you seen this problem with any .ears from the testsuite? Thanks david jencks On 2002.03.18 08:35:57 -0500 Vesco Claudio wrote: If you try to make the deploy of a ear, then you make the undeploy and therefore you make the deploy of the same one ear, comes written in log one exception. In this moment, I don't have the possibility to give you a better example, but I think you can reproduce the exception with the above operations. I think that the problem is that in the management of the resources jsr77 it does not come created the resource before father but tries to create the dependent resources. With the changed order, the exception does not happen. The proposed resolution does not resolve the problem discussed in the maillist, but resolves an other problem. Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 1:51 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Ordering part 2 :-) What exactly is the problem you are having? Can you post a small detailed example? As I understand your proposal you want to deploy from the outside in rather than the inside out. I think this won't work for most packages:
[JBoss-dev] [ jboss-Bugs-531445 ] Entity remove() not removing from cache
Bugs item #531445, was opened at 2002-03-18 12:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=531445group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Nobody/Anonymous (nobody) Summary: Entity remove() not removing from cache Initial Comment: - Create an entity object using CMP. - Remove the new entity object. - Attempt to create another entity with the same primary key. - The second create fails. Client side stacktrace: test-all: [junit] Running ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] Testsuite: ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] [junit] Testcase: testCacheClearing took 0.401 sec [junit] Caused an ERROR [junit] RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) [junit] at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) [junit] at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) [junit] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invok e(Unknown Source) [junit] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.i nvoke(JRMPInvokerProxy.java:128) [junit] at org.jboss.invocation.InvokerInterceptor.invoke (InvokerInterceptor.java:108) [junit] at org.jboss.proxy.TransactionInterceptor.invoke (TransactionInterceptor.java:73) [junit] at org.jboss.proxy.SecurityInterceptor.invoke (SecurityInterceptor.java:76) [junit] at org.jboss.proxy.ejb.HomeInterceptor.invoke (HomeInterceptor.java:185) [junit] at org.jboss.proxy.ClientContainer.invoke (ClientContainer.java:96) [junit] at $Proxy0.create(Unknown Source) [junit] at ejbtest.TestEntity.testCacheClearing (TestEntity.java:28) [junit] at java.lang.reflect.Method.invoke (Native Method) [junit] at junit.framework.TestCase.runTest (TestCase.java:166) [junit] at junit.framework.TestCase.runBare (TestCase.java:140) [junit] at junit.framework.TestResult$1.protect (TestResult.java:106) [junit] at junit.framework.TestResult.runProtected (TestResult.java:124) [junit] at junit.framework.TestResult.run (TestResult.java:109) [junit] at junit.framework.TestCase.run (TestCase.java:131) [junit] at junit.framework.TestSuite.runTest (TestSuite.java:173) [junit] at junit.framework.TestSuite.run (TestSuite.java:168) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.main(JUnitTestRunner.java:409) [junit] [junit] TEST ejbtest.TestEntity FAILED Server stack trace: javax.ejb.EJBException: Error getting application tx data map. Embedded Exception Already marked for rollback at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.getAppl icationTxDataMap(JDBCStoreManager.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.synchro nizeRelationData(JDBCStoreManager.java:434) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEn tity(JDBCStoreManager.java:430) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity (CMPPersistenceManager.java:436) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:676) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:177) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanu p.beforeCompletion(GlobalTxEntityMap.java:315) at org.jboss.tm.TxCapsule.doBeforeCompletion (TxCapsule.java:1317) at org.jboss.tm.TxCapsule.rollback (TxCapsule.java:430) at org.jboss.tm.TransactionImpl.rollback (TransactionImpl.java:88) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:180) at
RE: [JBoss-dev] Ordering part 2 :-)
I have run the testsuite. I have confronted the result with http://www.lubega.com/testarchive/reports-20020318-0547/ I have errors in org.jboss.test.jmx.test, = lubega. I have *no* errors in org.jboss.test.management.test, = lubega I have errors in org.jboss.test.readahead.test.ReadAheadUnitTestCase != lubega entity already found remainder = lubega :-) I think is better to create/start an outer container before an inner container - an inner container *is* contained in the outer container. I think this is not only better for jsr 77 but better for deploying/classloading etc etc etc, but I don't know everything in jboss :-))) Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 6:05 PM To: Vesco Claudio Cc: Jboss Dev Subject: Re: [JBoss-dev] Ordering part 2 :-) On 2002.03.18 11:46:32 -0500 Vesco Claudio wrote: It does not stop deploy/redeploy, only produce an exception in log. I test the testsuite now :-) Thanks Per quanto riguarda la discussione che avvenuta a riguardi dell'ordinamento, penso che le dipendenze tra risorse debbano essere indicate in un jboss-application.xml Concerning the recently discussion, I think that the dependecies between resources must be included in application-jboss.xml. The order proposed in MainDeployer I think is this correct KISS :-) I think there are arguments in favor of both orders. If I have a ear containing sar containing ear etc etc etc, it does not standard (j2ee compliant) and so - application-jboss.xml :-) True, but some nesting is allowed by j2ee, and needs to be handled without any jboss-application.xml needed. I think that most of these problems will go away when we can represent most dependencies as (automatically generated) mbean dependencies. I think we will be able to deploy just about anything packaged in just about any nesting without needing explicit deployment instructions. btw, I think two possible fixes I would be happier with are 1. jsr 77 mbeans destroy all their children when they are destroyed. 2. create, and start steps remain ordered from inside to outside, stop step remains ordered from outside to inside, destroy step is reversed to from inside to outside. Thanks david jencks Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 5:22 PM To: Vesco Claudio Subject: Re: [JBoss-dev] Ordering part 2 :-) Does this actually stop undeployment/redeployment or only produce an ugly log? Previously Andy indicated (I think) that the jsr-77 stuff should not impede redeployment, no matter how many errors it put in the log. I am _very_ worried about reversing the order of subdeployment nesting without a more complete dependency mechanism. If this is not stopping redeployment I would prefer to leave it till I can think about it more carefully. Have you seen what happens with your change with 1. the testsuite and 2. more complicated packaging such as ear containing sar containing ear containing rar? Thanks david jencks On 2002.03.18 09:48:08 -0500 Vesco Claudio wrote: Only for you :-) I have deployed bench.ear from testsuite and when I undeploy it I have this exception, ehm zipped :-) With call reordering I don't have exception :-) Claudio undeploy-exception.zip Patch.zip -Original Message- From: Vesco Claudio [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:27 PM To: 'David Jencks'; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Ordering part 2 :-) I'll retest jboss without my patchs :-) please wait a moment :-) -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:24 PM To: [EMAIL PROTECTED] Subject:Re: [JBoss-dev] Ordering part 2 :-) Could you please show the exception you are seeing in the log. This will help me 1. understand without having to reproduce the problem what you are writing about. 2. If I do attempt to reproduce the problem, indicate to me that I have found the same problem you are working with. Have you seen this problem with any .ears from the testsuite? Thanks david jencks On 2002.03.18 08:35:57 -0500 Vesco Claudio wrote: If you try to make the deploy of a ear, then you make the undeploy and therefore you make the deploy of the same one ear, comes written in log one exception. In this moment, I don't have the possibility to give you a better example, but I think you can reproduce
[JBoss-dev] [ jboss-Bugs-531445 ] Entity remove() not removing from cache
Bugs item #531445, was opened at 2002-03-18 12:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=531445group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Bill Burke (patriot1burke) Summary: Entity remove() not removing from cache Initial Comment: - Create an entity object using CMP. - Remove the new entity object. - Attempt to create another entity with the same primary key. - The second create fails. Client side stacktrace: test-all: [junit] Running ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] Testsuite: ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] [junit] Testcase: testCacheClearing took 0.401 sec [junit] Caused an ERROR [junit] RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) [junit] at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) [junit] at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) [junit] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invok e(Unknown Source) [junit] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.i nvoke(JRMPInvokerProxy.java:128) [junit] at org.jboss.invocation.InvokerInterceptor.invoke (InvokerInterceptor.java:108) [junit] at org.jboss.proxy.TransactionInterceptor.invoke (TransactionInterceptor.java:73) [junit] at org.jboss.proxy.SecurityInterceptor.invoke (SecurityInterceptor.java:76) [junit] at org.jboss.proxy.ejb.HomeInterceptor.invoke (HomeInterceptor.java:185) [junit] at org.jboss.proxy.ClientContainer.invoke (ClientContainer.java:96) [junit] at $Proxy0.create(Unknown Source) [junit] at ejbtest.TestEntity.testCacheClearing (TestEntity.java:28) [junit] at java.lang.reflect.Method.invoke (Native Method) [junit] at junit.framework.TestCase.runTest (TestCase.java:166) [junit] at junit.framework.TestCase.runBare (TestCase.java:140) [junit] at junit.framework.TestResult$1.protect (TestResult.java:106) [junit] at junit.framework.TestResult.runProtected (TestResult.java:124) [junit] at junit.framework.TestResult.run (TestResult.java:109) [junit] at junit.framework.TestCase.run (TestCase.java:131) [junit] at junit.framework.TestSuite.runTest (TestSuite.java:173) [junit] at junit.framework.TestSuite.run (TestSuite.java:168) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.main(JUnitTestRunner.java:409) [junit] [junit] TEST ejbtest.TestEntity FAILED Server stack trace: javax.ejb.EJBException: Error getting application tx data map. Embedded Exception Already marked for rollback at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.getAppl icationTxDataMap(JDBCStoreManager.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.synchro nizeRelationData(JDBCStoreManager.java:434) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEn tity(JDBCStoreManager.java:430) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity (CMPPersistenceManager.java:436) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:676) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:177) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanu p.beforeCompletion(GlobalTxEntityMap.java:315) at org.jboss.tm.TxCapsule.doBeforeCompletion (TxCapsule.java:1317) at org.jboss.tm.TxCapsule.rollback (TxCapsule.java:430) at org.jboss.tm.TransactionImpl.rollback (TransactionImpl.java:88) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:180) at
[JBoss-dev] [ jboss-Bugs-531445 ] Entity remove() not removing from cache
Bugs item #531445, was opened at 2002-03-18 12:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=531445group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Nobody/Anonymous (nobody) Summary: Entity remove() not removing from cache Initial Comment: - Create an entity object using CMP. - Remove the new entity object. - Attempt to create another entity with the same primary key. - The second create fails. Client side stacktrace: test-all: [junit] Running ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] Testsuite: ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] [junit] Testcase: testCacheClearing took 0.401 sec [junit] Caused an ERROR [junit] RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) [junit] at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) [junit] at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) [junit] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invok e(Unknown Source) [junit] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.i nvoke(JRMPInvokerProxy.java:128) [junit] at org.jboss.invocation.InvokerInterceptor.invoke (InvokerInterceptor.java:108) [junit] at org.jboss.proxy.TransactionInterceptor.invoke (TransactionInterceptor.java:73) [junit] at org.jboss.proxy.SecurityInterceptor.invoke (SecurityInterceptor.java:76) [junit] at org.jboss.proxy.ejb.HomeInterceptor.invoke (HomeInterceptor.java:185) [junit] at org.jboss.proxy.ClientContainer.invoke (ClientContainer.java:96) [junit] at $Proxy0.create(Unknown Source) [junit] at ejbtest.TestEntity.testCacheClearing (TestEntity.java:28) [junit] at java.lang.reflect.Method.invoke (Native Method) [junit] at junit.framework.TestCase.runTest (TestCase.java:166) [junit] at junit.framework.TestCase.runBare (TestCase.java:140) [junit] at junit.framework.TestResult$1.protect (TestResult.java:106) [junit] at junit.framework.TestResult.runProtected (TestResult.java:124) [junit] at junit.framework.TestResult.run (TestResult.java:109) [junit] at junit.framework.TestCase.run (TestCase.java:131) [junit] at junit.framework.TestSuite.runTest (TestSuite.java:173) [junit] at junit.framework.TestSuite.run (TestSuite.java:168) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.main(JUnitTestRunner.java:409) [junit] [junit] TEST ejbtest.TestEntity FAILED Server stack trace: javax.ejb.EJBException: Error getting application tx data map. Embedded Exception Already marked for rollback at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.getAppl icationTxDataMap(JDBCStoreManager.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.synchro nizeRelationData(JDBCStoreManager.java:434) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEn tity(JDBCStoreManager.java:430) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity (CMPPersistenceManager.java:436) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:676) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:177) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanu p.beforeCompletion(GlobalTxEntityMap.java:315) at org.jboss.tm.TxCapsule.doBeforeCompletion (TxCapsule.java:1317) at org.jboss.tm.TxCapsule.rollback (TxCapsule.java:430) at org.jboss.tm.TransactionImpl.rollback (TransactionImpl.java:88) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:180) at
[JBoss-dev] [ jboss-Bugs-531445 ] Entity remove() not removing from cache
Bugs item #531445, was opened at 2002-03-18 12:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=531445group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Nobody/Anonymous (nobody) Summary: Entity remove() not removing from cache Initial Comment: - Create an entity object using CMP. - Remove the new entity object. - Attempt to create another entity with the same primary key. - The second create fails. Client side stacktrace: test-all: [junit] Running ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] Testsuite: ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] [junit] Testcase: testCacheClearing took 0.401 sec [junit] Caused an ERROR [junit] RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) [junit] at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) [junit] at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) [junit] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invok e(Unknown Source) [junit] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.i nvoke(JRMPInvokerProxy.java:128) [junit] at org.jboss.invocation.InvokerInterceptor.invoke (InvokerInterceptor.java:108) [junit] at org.jboss.proxy.TransactionInterceptor.invoke (TransactionInterceptor.java:73) [junit] at org.jboss.proxy.SecurityInterceptor.invoke (SecurityInterceptor.java:76) [junit] at org.jboss.proxy.ejb.HomeInterceptor.invoke (HomeInterceptor.java:185) [junit] at org.jboss.proxy.ClientContainer.invoke (ClientContainer.java:96) [junit] at $Proxy0.create(Unknown Source) [junit] at ejbtest.TestEntity.testCacheClearing (TestEntity.java:28) [junit] at java.lang.reflect.Method.invoke (Native Method) [junit] at junit.framework.TestCase.runTest (TestCase.java:166) [junit] at junit.framework.TestCase.runBare (TestCase.java:140) [junit] at junit.framework.TestResult$1.protect (TestResult.java:106) [junit] at junit.framework.TestResult.runProtected (TestResult.java:124) [junit] at junit.framework.TestResult.run (TestResult.java:109) [junit] at junit.framework.TestCase.run (TestCase.java:131) [junit] at junit.framework.TestSuite.runTest (TestSuite.java:173) [junit] at junit.framework.TestSuite.run (TestSuite.java:168) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.main(JUnitTestRunner.java:409) [junit] [junit] TEST ejbtest.TestEntity FAILED Server stack trace: javax.ejb.EJBException: Error getting application tx data map. Embedded Exception Already marked for rollback at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.getAppl icationTxDataMap(JDBCStoreManager.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.synchro nizeRelationData(JDBCStoreManager.java:434) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEn tity(JDBCStoreManager.java:430) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity (CMPPersistenceManager.java:436) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:676) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:177) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanu p.beforeCompletion(GlobalTxEntityMap.java:315) at org.jboss.tm.TxCapsule.doBeforeCompletion (TxCapsule.java:1317) at org.jboss.tm.TxCapsule.rollback (TxCapsule.java:430) at org.jboss.tm.TransactionImpl.rollback (TransactionImpl.java:88) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:180) at
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmx/test JarInSarJSR77UnitTestCase.java
User: cazzius
Date: 02/03/18 11:19:07
Modified:src/main/org/jboss/test/jmx/test
JarInSarJSR77UnitTestCase.java
Log:
ported to last jsr 77 spec
Revision ChangesPath
1.2 +3 -3
jbosstest/src/main/org/jboss/test/jmx/test/JarInSarJSR77UnitTestCase.java
Index: JarInSarJSR77UnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jmx/test/JarInSarJSR77UnitTestCase.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JarInSarJSR77UnitTestCase.java3 Mar 2002 05:24:21 - 1.1
+++ JarInSarJSR77UnitTestCase.java18 Mar 2002 19:19:02 - 1.2
@@ -47,9 +47,9 @@
{
String testUrl = jarinsar.sar;
getLog().debug(testUrl is : + testUrl);
- ObjectName fakeApp = new
ObjectName(jboss.management.single:J2EEDomain=Manager,J2EEServer=Single,name=jarinsar.sar,type=J2EEApplication);
- ObjectName ejbModule = new
ObjectName(jboss.management.single:J2EEDomain=Manager,name=jarinsar.jar,J2EEServer=Single,J2EEApplication=jarinsar.sar,type=EjbModule);
- ObjectName bean = new
ObjectName(jboss.management.single:J2EEDomain=Manager,J2EEServer=Single,name=TestDataSource,J2EEApplication=jarinsar.sar,EjbModule=jarinsar.jar,type=StatelessSessionBean);
+ ObjectName fakeApp = new
ObjectName(jboss.management.single:J2EEServer=Single,name=jarinsar.sar,j2eeType=J2EEApplication);
+ ObjectName ejbModule = new
ObjectName(jboss.management.single:name=jarinsar.jar,J2EEServer=Single,J2EEApplication=jarinsar.sar,j2eeType=EJBModule);
+ ObjectName bean = new
ObjectName(jboss.management.single:J2EEServer=Single,name=TestDataSource,J2EEApplication=jarinsar.sar,EJBModule=jarinsar.jar,j2eeType=StatelessSessionBean);
//deploy the test package.
deploy(testUrl);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-531445 ] Entity remove() not removing from cache
Bugs item #531445, was opened at 2002-03-18 12:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=531445group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Bill Burke (patriot1burke) Summary: Entity remove() not removing from cache Initial Comment: - Create an entity object using CMP. - Remove the new entity object. - Attempt to create another entity with the same primary key. - The second create fails. Client side stacktrace: test-all: [junit] Running ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] Testsuite: ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] [junit] Testcase: testCacheClearing took 0.401 sec [junit] Caused an ERROR [junit] RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) [junit] at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) [junit] at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) [junit] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invok e(Unknown Source) [junit] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.i nvoke(JRMPInvokerProxy.java:128) [junit] at org.jboss.invocation.InvokerInterceptor.invoke (InvokerInterceptor.java:108) [junit] at org.jboss.proxy.TransactionInterceptor.invoke (TransactionInterceptor.java:73) [junit] at org.jboss.proxy.SecurityInterceptor.invoke (SecurityInterceptor.java:76) [junit] at org.jboss.proxy.ejb.HomeInterceptor.invoke (HomeInterceptor.java:185) [junit] at org.jboss.proxy.ClientContainer.invoke (ClientContainer.java:96) [junit] at $Proxy0.create(Unknown Source) [junit] at ejbtest.TestEntity.testCacheClearing (TestEntity.java:28) [junit] at java.lang.reflect.Method.invoke (Native Method) [junit] at junit.framework.TestCase.runTest (TestCase.java:166) [junit] at junit.framework.TestCase.runBare (TestCase.java:140) [junit] at junit.framework.TestResult$1.protect (TestResult.java:106) [junit] at junit.framework.TestResult.runProtected (TestResult.java:124) [junit] at junit.framework.TestResult.run (TestResult.java:109) [junit] at junit.framework.TestCase.run (TestCase.java:131) [junit] at junit.framework.TestSuite.runTest (TestSuite.java:173) [junit] at junit.framework.TestSuite.run (TestSuite.java:168) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.main(JUnitTestRunner.java:409) [junit] [junit] TEST ejbtest.TestEntity FAILED Server stack trace: javax.ejb.EJBException: Error getting application tx data map. Embedded Exception Already marked for rollback at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.getAppl icationTxDataMap(JDBCStoreManager.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.synchro nizeRelationData(JDBCStoreManager.java:434) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEn tity(JDBCStoreManager.java:430) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity (CMPPersistenceManager.java:436) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:676) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:177) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanu p.beforeCompletion(GlobalTxEntityMap.java:315) at org.jboss.tm.TxCapsule.doBeforeCompletion (TxCapsule.java:1317) at org.jboss.tm.TxCapsule.rollback (TxCapsule.java:430) at org.jboss.tm.TransactionImpl.rollback (TransactionImpl.java:88) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:180) at
[JBoss-dev] [ jboss-Bugs-531445 ] Entity remove() not removing from cache
Bugs item #531445, was opened at 2002-03-18 12:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=531445group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Nobody/Anonymous (nobody) Summary: Entity remove() not removing from cache Initial Comment: - Create an entity object using CMP. - Remove the new entity object. - Attempt to create another entity with the same primary key. - The second create fails. Client side stacktrace: test-all: [junit] Running ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] Testsuite: ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] [junit] Testcase: testCacheClearing took 0.401 sec [junit] Caused an ERROR [junit] RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) [junit] at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) [junit] at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) [junit] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invok e(Unknown Source) [junit] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.i nvoke(JRMPInvokerProxy.java:128) [junit] at org.jboss.invocation.InvokerInterceptor.invoke (InvokerInterceptor.java:108) [junit] at org.jboss.proxy.TransactionInterceptor.invoke (TransactionInterceptor.java:73) [junit] at org.jboss.proxy.SecurityInterceptor.invoke (SecurityInterceptor.java:76) [junit] at org.jboss.proxy.ejb.HomeInterceptor.invoke (HomeInterceptor.java:185) [junit] at org.jboss.proxy.ClientContainer.invoke (ClientContainer.java:96) [junit] at $Proxy0.create(Unknown Source) [junit] at ejbtest.TestEntity.testCacheClearing (TestEntity.java:28) [junit] at java.lang.reflect.Method.invoke (Native Method) [junit] at junit.framework.TestCase.runTest (TestCase.java:166) [junit] at junit.framework.TestCase.runBare (TestCase.java:140) [junit] at junit.framework.TestResult$1.protect (TestResult.java:106) [junit] at junit.framework.TestResult.runProtected (TestResult.java:124) [junit] at junit.framework.TestResult.run (TestResult.java:109) [junit] at junit.framework.TestCase.run (TestCase.java:131) [junit] at junit.framework.TestSuite.runTest (TestSuite.java:173) [junit] at junit.framework.TestSuite.run (TestSuite.java:168) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.main(JUnitTestRunner.java:409) [junit] [junit] TEST ejbtest.TestEntity FAILED Server stack trace: javax.ejb.EJBException: Error getting application tx data map. Embedded Exception Already marked for rollback at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.getAppl icationTxDataMap(JDBCStoreManager.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.synchro nizeRelationData(JDBCStoreManager.java:434) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEn tity(JDBCStoreManager.java:430) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity (CMPPersistenceManager.java:436) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:676) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:177) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanu p.beforeCompletion(GlobalTxEntityMap.java:315) at org.jboss.tm.TxCapsule.doBeforeCompletion (TxCapsule.java:1317) at org.jboss.tm.TxCapsule.rollback (TxCapsule.java:430) at org.jboss.tm.TransactionImpl.rollback (TransactionImpl.java:88) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:180) at
[JBoss-dev] [ jboss-Bugs-531445 ] Entity remove() not removing from cache
Bugs item #531445, was opened at 2002-03-18 12:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=531445group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Nobody/Anonymous (nobody) Summary: Entity remove() not removing from cache Initial Comment: - Create an entity object using CMP. - Remove the new entity object. - Attempt to create another entity with the same primary key. - The second create fails. Client side stacktrace: test-all: [junit] Running ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] Testsuite: ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] [junit] Testcase: testCacheClearing took 0.401 sec [junit] Caused an ERROR [junit] RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) [junit] at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) [junit] at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) [junit] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invok e(Unknown Source) [junit] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.i nvoke(JRMPInvokerProxy.java:128) [junit] at org.jboss.invocation.InvokerInterceptor.invoke (InvokerInterceptor.java:108) [junit] at org.jboss.proxy.TransactionInterceptor.invoke (TransactionInterceptor.java:73) [junit] at org.jboss.proxy.SecurityInterceptor.invoke (SecurityInterceptor.java:76) [junit] at org.jboss.proxy.ejb.HomeInterceptor.invoke (HomeInterceptor.java:185) [junit] at org.jboss.proxy.ClientContainer.invoke (ClientContainer.java:96) [junit] at $Proxy0.create(Unknown Source) [junit] at ejbtest.TestEntity.testCacheClearing (TestEntity.java:28) [junit] at java.lang.reflect.Method.invoke (Native Method) [junit] at junit.framework.TestCase.runTest (TestCase.java:166) [junit] at junit.framework.TestCase.runBare (TestCase.java:140) [junit] at junit.framework.TestResult$1.protect (TestResult.java:106) [junit] at junit.framework.TestResult.runProtected (TestResult.java:124) [junit] at junit.framework.TestResult.run (TestResult.java:109) [junit] at junit.framework.TestCase.run (TestCase.java:131) [junit] at junit.framework.TestSuite.runTest (TestSuite.java:173) [junit] at junit.framework.TestSuite.run (TestSuite.java:168) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.main(JUnitTestRunner.java:409) [junit] [junit] TEST ejbtest.TestEntity FAILED Server stack trace: javax.ejb.EJBException: Error getting application tx data map. Embedded Exception Already marked for rollback at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.getAppl icationTxDataMap(JDBCStoreManager.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.synchro nizeRelationData(JDBCStoreManager.java:434) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEn tity(JDBCStoreManager.java:430) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity (CMPPersistenceManager.java:436) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:676) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:177) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanu p.beforeCompletion(GlobalTxEntityMap.java:315) at org.jboss.tm.TxCapsule.doBeforeCompletion (TxCapsule.java:1317) at org.jboss.tm.TxCapsule.rollback (TxCapsule.java:430) at org.jboss.tm.TransactionImpl.rollback (TransactionImpl.java:88) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:180) at
Re: [JBoss-dev] Ordering part 2 :-)
On 2002.03.18 12:47:11 -0500 Vesco Claudio wrote: I have run the testsuite. I have confronted the result with http://www.lubega.com/testarchive/reports-20020318-0547/ I have errors in org.jboss.test.jmx.test, = lubega. I have *no* errors in org.jboss.test.management.test, = lubega I have errors in org.jboss.test.readahead.test.ReadAheadUnitTestCase != lubega entity already found remainder = lubega :-) I think is better to create/start an outer container before an inner container - an inner container *is* contained in the outer container. I think this is not only better for jsr 77 but better for deploying/classloading etc etc etc, but I don't know everything in jboss :-))) Claudio Well, my thinking so far is that it makes little sense to say that say an application is started before its ejb modules are started, or after they are stopped. Outside in start order says this, IMO. I think a package depends on its subpackages, which requires the current ordering unless a package handles the deployment of its subpackages, in which case it could do whatever it likes. david jencks snip ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-531524 ] Error in passivation of bean with JMS
Bugs item #531524, was opened at 2002-03-18 21:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=531524group_id=22866 Category: JBossMQ Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Marius Kotsbak (mkotsbak) Assigned to: Nobody/Anonymous (nobody) Summary: Error in passivation of bean with JMS Initial Comment: I get this exception when using JMS as managed resource: java.rmi.ServerException: Could not passivate; nested exception is: java.io.NotSerializableException: org.jboss.resource.adapter.jms.JmsManagedConnectionFactory java.io.NotSerializableException: org.jboss.resource.adapter.jms.JmsManagedConnectionFactory at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1161) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code)) at java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java(Compiled Code)) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:486) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1227) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code)) at java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java(Compiled Code)) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:486) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1227) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code)) at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:287) at org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(StatefulSessionInstanceCache.java:65) at org.jboss.ejb.plugins.AbstractInstanceCache$1.execute(AbstractInstanceCache.java:737) at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:206) at java.lang.Thread.run(Thread.java:498) Is this a bug (the class should be serializable for example), or have I done something wrong (then it is a bg too, because the errormessage should be better!) Marius K -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=531524group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-531571 ] performance tuning for selector LIKE
Patches item #531571, was opened at 2002-03-18 13:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=531571group_id=22866 Category: JBossMQ Group: v3.0 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Loren Rosen (lorenrosen) Assigned to: Nobody/Anonymous (nobody) Summary: performance tuning for selector LIKE Initial Comment: It was taking about 60 ms to scan a 1000 messages with a selector containing a regular expression (with JDK 1.3.1... it was far worse with earlier JVMs). It turns out the code was recompiling the RE on every message tested. In addition to adding time overhead this probably produces lots of garbage. The patch changes the Operator class to retain the results of the RE compilation done the first time the selector is evaluated. (It might be more logical to compile the RE when the selector is parsed, but that change would be a bit more complicated to make). The RE wrapper code (which wraps the gnu regexp code) was moved into a separate class for clarity. Some other small changes were made to improve performance and clarity. End result is a 2X speed-up (from 60ms/1000msg to 30/1000) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=531571group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Ordering part 2 :-)
Hi Geeks I just read your thread. I think one of the problems is that JSR-77 is still ALPHA. Also it does not know anything about SAR and how you can nest deployment units in there. 1) I will create a JBoss specific SARModule (like EJBModule) 2) I will create a JBoss specific Service (like EJB or Servlet) 3) Look why the stopping of the components fails ATTENTION: JSR-77 exceptions are reported for testing purposes. All the JSR-77 components should reflect JBoss and NOT direct the development of JBoss in any way. So whatever is correct for JBoss the JSR-77 components will adapt. Have fun - Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-531445 ] Entity remove() not removing from cache
Bugs item #531445, was opened at 2002-03-18 12:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=531445group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Invalid Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Nobody/Anonymous (nobody) Summary: Entity remove() not removing from cache Initial Comment: - Create an entity object using CMP. - Remove the new entity object. - Attempt to create another entity with the same primary key. - The second create fails. Client side stacktrace: test-all: [junit] Running ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] Testsuite: ejbtest.TestEntity [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.401 sec [junit] [junit] Testcase: testCacheClearing took 0.401 sec [junit] Caused an ERROR [junit] RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.]; nested exception is: [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.0.] [junit] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) [junit] at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) [junit] at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) [junit] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invok e(Unknown Source) [junit] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.i nvoke(JRMPInvokerProxy.java:128) [junit] at org.jboss.invocation.InvokerInterceptor.invoke (InvokerInterceptor.java:108) [junit] at org.jboss.proxy.TransactionInterceptor.invoke (TransactionInterceptor.java:73) [junit] at org.jboss.proxy.SecurityInterceptor.invoke (SecurityInterceptor.java:76) [junit] at org.jboss.proxy.ejb.HomeInterceptor.invoke (HomeInterceptor.java:185) [junit] at org.jboss.proxy.ClientContainer.invoke (ClientContainer.java:96) [junit] at $Proxy0.create(Unknown Source) [junit] at ejbtest.TestEntity.testCacheClearing (TestEntity.java:28) [junit] at java.lang.reflect.Method.invoke (Native Method) [junit] at junit.framework.TestCase.runTest (TestCase.java:166) [junit] at junit.framework.TestCase.runBare (TestCase.java:140) [junit] at junit.framework.TestResult$1.protect (TestResult.java:106) [junit] at junit.framework.TestResult.runProtected (TestResult.java:124) [junit] at junit.framework.TestResult.run (TestResult.java:109) [junit] at junit.framework.TestCase.run (TestCase.java:131) [junit] at junit.framework.TestSuite.runTest (TestSuite.java:173) [junit] at junit.framework.TestSuite.run (TestSuite.java:168) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestR unner.main(JUnitTestRunner.java:409) [junit] [junit] TEST ejbtest.TestEntity FAILED Server stack trace: javax.ejb.EJBException: Error getting application tx data map. Embedded Exception Already marked for rollback at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.getAppl icationTxDataMap(JDBCStoreManager.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.synchro nizeRelationData(JDBCStoreManager.java:434) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEn tity(JDBCStoreManager.java:430) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity (CMPPersistenceManager.java:436) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:676) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:177) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanu p.beforeCompletion(GlobalTxEntityMap.java:315) at org.jboss.tm.TxCapsule.doBeforeCompletion (TxCapsule.java:1317) at org.jboss.tm.TxCapsule.rollback (TxCapsule.java:430) at org.jboss.tm.TransactionImpl.rollback (TransactionImpl.java:88) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:180) at
[JBoss-dev] CVS update: jbossmx/src/etc farm-service.xml
User: schaefera Date: 02/03/18 14:34:02 Modified:src/etc farm-service.xml Log: Fixed the broken Farm Member Service. Now the Main Deployer is emitting JMX notification when an object is deployed / undeployed and the Farm Member Service is listening for. Also the Farm Member Service is self-contained meaning that you only have to adjust the farm-service.xml and deployed it (no further adjustments necessary even the creation of the farm directory). Also fixed a problem with URL Deployment Scanner which fails when a new directory is added (through addURL()) during startup by another MBean because list is changed without recreation of the iterator. Now the iterator is replaced by a generated array which does not change when the list changes. Revision ChangesPath 1.6 +11 -20jbossmx/src/etc/farm-service.xml Index: farm-service.xml === RCS file: /cvsroot/jboss/jbossmx/src/etc/farm-service.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- farm-service.xml 24 Feb 2002 10:24:29 - 1.5 +++ farm-service.xml 18 Mar 2002 22:34:01 - 1.6 @@ -7,36 +7,27 @@ !-- = -- server - + classpath codebase=lib archives=jbossha.jar/ - + !--these depends tags no longer do anything dependsjboss:service=Naming/depends dependsjboss.system:service=ServiceDeployer/depends dependsjboss:service=DefaultPartition/depends -- - + !-- -- !-- Cluster Partition: defines cluster -- !-- -- - + + !-- +Farm Deploy Directory and Scanner Name must not be set here because this +are the default values but when you want to change them do it here. + -- mbean code=org.jboss.ha.framework.server.FarmMemberService name=jboss:service=FarmMember,partition=DefaultPartition attribute name=PartitionNameDefaultPartition/attribute + attribute name=FarmDeployDirectory./deploy/farm/attribute + attribute name=ScannerNamejboss.deployment:type=DeploymentScanner,flavor=URL/attribute /mbean - - mbean code=org.jboss.deployment.AutoDeployer name=jboss:service=FarmAutoDeployer - attribute name=Deployers - jboss:service=FarmMember,partition=DefaultPartition - /attribute - attribute name=URLs - ../deploy/farm - /attribute - attribute name=Timeout - 3000 - /attribute - attribute name=WithInitialRun - false - /attribute - /mbean - + /server ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment MainDeployer.java
User: schaefera
Date: 02/03/18 14:34:03
Modified:src/main/org/jboss/deployment MainDeployer.java
Log:
Fixed the broken Farm Member Service. Now the Main Deployer is emitting JMX
notification when an object is deployed / undeployed and the Farm Member
Service is listening for.
Also the Farm Member Service is self-contained meaning that you only have
to adjust the farm-service.xml and deployed it (no further adjustments
necessary even the creation of the farm directory).
Also fixed a problem with URL Deployment Scanner which fails when a new
directory is added (through addURL()) during startup by another MBean
because list is changed without recreation of the iterator. Now the
iterator is replaced by a generated array which does not change when the
list changes.
Revision ChangesPath
1.19 +19 -1 jboss-system/src/main/org/jboss/deployment/MainDeployer.java
Index: MainDeployer.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/MainDeployer.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- MainDeployer.java 9 Mar 2002 05:22:38 - 1.18
+++ MainDeployer.java 18 Mar 2002 22:34:03 - 1.19
@@ -42,6 +42,7 @@
import java.util.jar.Manifest;
import javax.management.MBeanServer;
import javax.management.MalformedObjectNameException;
+import javax.management.Notification;
import javax.management.ObjectName;
import org.jboss.system.ServiceMBeanSupport;
import org.jboss.system.server.ServerConfig;
@@ -58,7 +59,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.18 $
+ * @version $Revision: 1.19 $
* @jmx:mbean name=jboss.system:service=MainDeployer
*extends=org.jboss.system.ServiceMBean
*/
@@ -322,6 +323,14 @@
log.info(Undeploying +di.url);
stop(di);
destroy(di);
+ //AS Test if JMX Notifications can be used to trigger the FarmMemberService
+ Notification lNotification = new Notification(
+ Undeployment,
+ this,
+ 0L
+ );
+ lNotification.setUserData( di.url );
+ sendNotification( lNotification );
}
/**
@@ -478,6 +487,15 @@
log.info(Starting deployment of package: + deployment.url);
if (init(deployment))
{
+ //AS Test if JMX Notifications can be used to trigger the FarmMemberService
+ Notification lNotification = new Notification(
+Deployment,
+this,
+0L
+ );
+ lNotification.setUserData( deployment.url );
+ sendNotification( lNotification );
+
create(deployment);
start(deployment);
log.info(Successfully completed deployment of package: +
deployment.url);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server FarmMemberService.java FarmMemberServiceMBean.java
User: schaefera
Date: 02/03/18 14:34:02
Modified:src/main/org/jboss/ha/framework/server
FarmMemberService.java FarmMemberServiceMBean.java
Log:
Fixed the broken Farm Member Service. Now the Main Deployer is emitting JMX
notification when an object is deployed / undeployed and the Farm Member
Service is listening for.
Also the Farm Member Service is self-contained meaning that you only have
to adjust the farm-service.xml and deployed it (no further adjustments
necessary even the creation of the farm directory).
Also fixed a problem with URL Deployment Scanner which fails when a new
directory is added (through addURL()) during startup by another MBean
because list is changed without recreation of the iterator. Now the
iterator is replaced by a generated array which does not change when the
list changes.
Revision ChangesPath
1.8 +218 -141
jbossmx/src/main/org/jboss/ha/framework/server/FarmMemberService.java
Index: FarmMemberService.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/FarmMemberService.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- FarmMemberService.java22 Feb 2002 04:24:54 - 1.7
+++ FarmMemberService.java18 Mar 2002 22:34:02 - 1.8
@@ -17,16 +17,27 @@
import java.net.URL;
import java.net.MalformedURLException;
import java.util.Date;
+import java.util.Hashtable;
import javax.management.ObjectName;
import javax.management.JMException;
+import javax.management.MBeanServer;
+import javax.management.Notification;
+import javax.management.NotificationFilterSupport;
+import javax.management.NotificationListener;
import org.jboss.deployment.DeploymentInfo;
import org.jboss.deployment.DeploymentException;
+import org.jboss.deployment.MainDeployerMBean;
+import org.jboss.deployment.DeployerMBean;
import org.jboss.ha.framework.server.FarmMemberServiceMBean.FileContent;
import org.jboss.ha.framework.interfaces.HAPartition;
+import org.jboss.system.ServiceMBeanSupport;
+import org.jboss.system.server.ServerConfig;
+import org.jboss.system.server.ServerConfigLocator;
+
/**
* This class indicates that this JBoss instance is a member of a farm
* builded by all the classes connecting to each other.
@@ -43,7 +54,7 @@
* /ul
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
- * @version $Revision: 1.7 $ p
+ * @version $Revision: 1.8 $ p
*
* bRevisions:/b p
*
@@ -51,27 +62,44 @@
* ul
* liInitial import
* /ul
+ * pb20020316 andreas schaefer:/b
+ * ul
+ * liAdjusted to new Deployer Implementation
+ * /ul
+ *
+ * @todo AS add the MBean interface generation through XDoclet
+ * @--jmx:mbean extends=org.jboss.system.ServiceMBean
**/
-public class FarmMemberService extends org.jboss.system.ServiceMBeanSupport
implements FarmMemberServiceMBean, javax.management.MBeanRegistration
+public class FarmMemberService
+ extends ServiceMBeanSupport
+ implements FarmMemberServiceMBean
{
-
+
+ // Constants -
+
+ private static final String DEFAULT_DEPLOY_DIRECTORY = ./deploy/farm;
+ private static final String DEFAULT_SCANNER_NAME =
jboss.deployment:type=DeploymentScanner,flavor=URL;
+
// Attributes
-
-
- protected ObjectName sFarmMemberService = null;
- protected ObjectName sDeployerService = null;
- protected ObjectName sClusterPartitionService = null;
- protected String backgroundPartition = DefaultPartition;
+
+ protected ObjectName mFarmMemberName = null;
+ protected ObjectName mClusterPartitionName = null;
+ protected String mBackgroundPartition = DefaultPartition;
protected final static String SERVICE_NAME = FarmMemberService;
/** A callback to the JMX Agent **/
- private javax.management.MBeanServer mServer;
-
- private java.util.Hashtable mDeployedServices = new java.util.Hashtable();
+ private MBeanServer mServer;
+
+ private Hashtable mDeployedServices = new java.util.Hashtable();
+ private File mTempDirectory;
+ private String mFarmDeployDirectory = DEFAULT_DEPLOY_DIRECTORY;
+ private String mScannerName = DEFAULT_SCANNER_NAME;
+ private File mDeployDirectory;
+ private NotificationListener mListener = new Listener();
// Static
-
+
// Constructors --
/**
@@ -83,67 +111,18 @@
}
// Public
- /**
-* FIXME FOR COMPILATION ONLY
-*/
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment/scanner URLDeploymentScanner.java
User: schaefera
Date: 02/03/18 14:34:03
Modified:src/main/org/jboss/deployment/scanner
URLDeploymentScanner.java
Log:
Fixed the broken Farm Member Service. Now the Main Deployer is emitting JMX
notification when an object is deployed / undeployed and the Farm Member
Service is listening for.
Also the Farm Member Service is self-contained meaning that you only have
to adjust the farm-service.xml and deployed it (no further adjustments
necessary even the creation of the farm directory).
Also fixed a problem with URL Deployment Scanner which fails when a new
directory is added (through addURL()) during startup by another MBean
because list is changed without recreation of the iterator. Now the
iterator is replaced by a generated array which does not change when the
list changes.
Revision ChangesPath
1.6 +19 -1
jboss-system/src/main/org/jboss/deployment/scanner/URLDeploymentScanner.java
Index: URLDeploymentScanner.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/scanner/URLDeploymentScanner.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- URLDeploymentScanner.java 16 Mar 2002 08:40:44 - 1.5
+++ URLDeploymentScanner.java 18 Mar 2002 22:34:03 - 1.6
@@ -38,7 +38,7 @@
* A URL-based deployment scanner. Supports local directory
* scanning for file-based urls.
*
- * @version tt$Revision: 1.5 $/tt
+ * @version tt$Revision: 1.6 $/tt
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
*/
public class URLDeploymentScanner
@@ -351,6 +351,9 @@
}
synchronized (urlList) {
+ //AS Run into some problems when adding a new deployment
+ //AS directory through another MBean
+ /*
for (Iterator iter = urlList.iterator(); iter.hasNext();)
{
URL url = (URL)iter.next();
@@ -363,6 +366,21 @@
else {
// just deploy, not a file url and not yet deployed
deploy(new DeployedURL(url));
+ }
+}
+ }
+ */
+ URL[] urls = (URL[]) urlList.toArray( new URL[] {} );
+ for( int i = 0; i urls.length; i++ )
+ {
+if (!isDeployed(urls[i])) {
+ if (urls[i].getProtocol().equals(file)) {
+ // it is a file url which gets special handling
+ scanDirectory(urls[i]);
+ }
+ else {
+ // just deploy, not a file url and not yet deployed
+ deploy(new DeployedURL(urls[i]));
}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] New Farm Member Service
Hi Geeks I just uploaded the new version of the Farm Member Service. The current implementation is listening for Notifications sent by the Main Deployer (Jason: can be changed later but I thought the Main Deployer is a good start). Also the farm-service.xml is self-contained thus you only adjust this file and deploy it. The Farm Member Service will created the necessary directory and add it as new deployment directory to scan for in the Deployment Scanner. Have fun x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-management/src/main/org/jboss/management/j2ee EJB.java J2EEManagedObject.java
User: schaefera
Date: 02/03/18 14:34:02
Modified:src/main/org/jboss/management/j2ee EJB.java
J2EEManagedObject.java
Log:
Fixed the broken Farm Member Service. Now the Main Deployer is emitting JMX
notification when an object is deployed / undeployed and the Farm Member
Service is listening for.
Also the Farm Member Service is self-contained meaning that you only have
to adjust the farm-service.xml and deployed it (no further adjustments
necessary even the creation of the farm directory).
Also fixed a problem with URL Deployment Scanner which fails when a new
directory is added (through addURL()) during startup by another MBean
because list is changed without recreation of the iterator. Now the
iterator is replaced by a generated array which does not change when the
list changes.
Revision ChangesPath
1.3 +1 -2 jboss-management/src/main/org/jboss/management/j2ee/EJB.java
Index: EJB.java
===
RCS file:
/cvsroot/jboss/jboss-management/src/main/org/jboss/management/j2ee/EJB.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- EJB.java 16 Mar 2002 06:44:56 - 1.2
+++ EJB.java 18 Mar 2002 22:34:02 - 1.3
@@ -19,7 +19,7 @@
* {@link javax.management.j2ee.EJB EJB}.
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*
* pbRevisions:/b
*
@@ -121,7 +121,6 @@
// the name by the J2EE-Server type
lReturn.put( J2EEApplication.J2EE_TYPE, lProperties.get(
J2EEApplication.J2EE_TYPE ) );
lReturn.put( J2EEServer.J2EE_TYPE, lProperties.get( J2EEServer.J2EE_TYPE ) );
- System.out.println( -- EJB.getParentKeys(),
return: + lReturn );
return lReturn;
}
1.3 +1 -2
jboss-management/src/main/org/jboss/management/j2ee/J2EEManagedObject.java
Index: J2EEManagedObject.java
===
RCS file:
/cvsroot/jboss/jboss-management/src/main/org/jboss/management/j2ee/J2EEManagedObject.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- J2EEManagedObject.java16 Mar 2002 06:44:56 - 1.2
+++ J2EEManagedObject.java18 Mar 2002 22:34:02 - 1.3
@@ -23,7 +23,7 @@
* {@link javax.management.j2ee.J2EEManagedObject J2EEManagedObject}.
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*
* pbRevisions:/b
*
@@ -290,7 +290,6 @@
* @return An empty hashtable
**/
protected Hashtable getParentKeys( ObjectName pParent ) {
- System.out.println( -- J2EEManagedObject return
empty hashtable );
return new Hashtable();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbossmx/src/etc farm-service.xml
Good work Andreas! Thanks mucho -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andreas Schaefer Sent: Monday, March 18, 2002 5:34 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] CVS update: jbossmx/src/etc farm-service.xml User: schaefera Date: 02/03/18 14:34:02 Modified:src/etc farm-service.xml Log: Fixed the broken Farm Member Service. Now the Main Deployer is emitting JMX notification when an object is deployed / undeployed and the Farm Member Service is listening for. Also the Farm Member Service is self-contained meaning that you only have to adjust the farm-service.xml and deployed it (no further adjustments necessary even the creation of the farm directory). Also fixed a problem with URL Deployment Scanner which fails when a new directory is added (through addURL()) during startup by another MBean because list is changed without recreation of the iterator. Now the iterator is replaced by a generated array which does not change when the list changes. Revision ChangesPath 1.6 +11 -20jbossmx/src/etc/farm-service.xml Index: farm-service.xml === RCS file: /cvsroot/jboss/jbossmx/src/etc/farm-service.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- farm-service.xml24 Feb 2002 10:24:29 - 1.5 +++ farm-service.xml18 Mar 2002 22:34:01 - 1.6 @@ -7,36 +7,27 @@ !-- = -- server - + classpath codebase=lib archives=jbossha.jar/ - + !--these depends tags no longer do anything dependsjboss:service=Naming/depends dependsjboss.system:service=ServiceDeployer/depends dependsjboss:service=DefaultPartition/depends -- - + !-- -- !-- Cluster Partition: defines cluster -- !-- -- - + + !-- +Farm Deploy Directory and Scanner Name must not be set here because this +are the default values but when you want to change them do it here. + -- mbean code=org.jboss.ha.framework.server.FarmMemberService name=jboss:service=FarmMember,partition=DefaultPartition attribute name=PartitionNameDefaultPartition/attribute + attribute name=FarmDeployDirectory./deploy/farm/attribute + attribute name=ScannerNamejboss.deployment:type=DeploymentScanner,flavor= URL/attribute /mbean - - mbean code=org.jboss.deployment.AutoDeployer name=jboss:service=FarmAutoDeployer - attribute name=Deployers - jboss:service=FarmMember,partition=DefaultPartition - /attribute - attribute name=URLs - ../deploy/farm - /attribute - attribute name=Timeout - 3000 - /attribute - attribute name=WithInitialRun - false - /attribute - /mbean - + /server ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: [JBoss-user] JBOSS 3.x FINAL
|obviously has to have customers, and those customers deserve respect. Customers pay, My comments stand marcf | |Sincerely, | |Brian Sondergaard | |P.S. I'll buy you a pitcher (or two) next week in SF. | |- Original Message - |From: marc fleury [EMAIL PROTECTED] |To: Trawick, James [EMAIL PROTECTED]; |Jboss-Development@Lists. Sourceforge. Net |[EMAIL PROTECTED]; Jboss-User@Lists. Sourceforge. |Net [EMAIL PROTECTED] |Sent: Thursday, March 14, 2002 10:22 PM |Subject: RE: [JBoss-dev] RE: [JBoss-user] JBOSS 3.x FINAL | | | mr trawick james, | | suck my dick | | marcf | | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED]]On Behalf Of | |Trawick, James | |Sent: Thursday, March 14, 2002 12:33 PM | |To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. | |Sourceforge. Net | |Subject: RE: [JBoss-dev] RE: [JBoss-user] JBOSS 3.x FINAL | | | | | |Not unfounded, personally proven. | | | |In any case there needs to be some sort of kickstart and executive |summary | |for the new JBoss features. If it means that I'll finally get the |answers | |I'm looking for without holding for three hours and/or putting up with |the | |hellfire here, I'll be more than happy to help produce that. | | | |I was not aware that the docs for sale were actually available. My | |experience has been the exact opposite. On three separate |occaisons over | |the past couple of months I've attempted to purchase the clustering | |documentation. Each time I received a message saying that there was a | |problem with their side of the transaction and a support rep would be in | |contact with me. Despite multiple attempts to open communications about | |these cases with Flashline, they have failed to do so. Emails |apparently | |went to the bit bucket and their phone support reps have proven to be | |anywhere from rude to utterly incompetant. So for my purposes, the docs | |aren't real because for whatever reason I can't get to them despite my | |willingness to pay the mere $10 for quality documentation. At |least they | |didn't charge me for it. | | | |chris | | | |-Original Message- | |From: Bill Burke [mailto:[EMAIL PROTECTED]] | |Sent: Thursday, March 14, 2002 3:10 PM | |To: Trawick, James | |Cc: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. | |Sourceforge. Net | |Subject: RE: [JBoss-dev] RE: [JBoss-user] JBOSS 3.x FINAL | | | | | |Clustering docs are available for purchase. | | | |http://www.flashline.com/components/productsbyvendor.jsp?vendorid= | |1376affi | |liateid=260343 | | | |I've also written an article on clustering JBoss 2.4.x | | | |http://www.onjava.com/pub/a/onjava/2001/09/18/jboss.html | | | |Clustering features in JBoss beta: | |HA-JNDI, HA-RMI, EJBs(EB, SLSB, SFSB) Failover and load-balancing | | | |The code for HTTP Session Failover is in CVS, but is a work in progress. | |Ask Sacha and Julian how it's going. I don't work on this stuff. HTTP | |Session Failover will probably only be available for Jetty. | | | |I don't know what you're talking about when you say docs for sale aren't | |real, because we've already sold at least a 100 copies of the clustering | |docs. Sacha and I have gotten good feedback on these docs so your | |complaints are unfounded. | | | | -Original Message- | | From: [EMAIL PROTECTED] | | [mailto:[EMAIL PROTECTED]]On Behalf Of | | Trawick, James | | Sent: Thursday, March 14, 2002 2:28 PM | | To: 'David Ward' | | Cc: 'marc fleury'; Jboss-Development@Lists. Sourceforge. Net; | | Jboss-User@Lists. Sourceforge. Net | | Subject: [JBoss-dev] RE: [JBoss-user] JBOSS 3.x FINAL | | | | | | What I'm really interested in is the more corporate questions | |(we're still | | battling for JBoss over Weblogic, and clustering is a real sore | | point). How | | does JBoss 3 clustering interact with web container clustering? | | If they're | | completely separate (which I'm pretty sure is the case, as it was | | last time | | I walked through the code), how can I put together a full clustered |J2EE | | stack with JBoss and (for example) Tomcat/Catalina? To what |level does | | JBoss provide high-availability? What are some failover scenarios? |How | | does one initiate a graceful failover for server maintenance? How | | flexible/controllable is JBoss clustering in reality? | | | | | |Failover scenarios? | |- failed network card | |- server crash | |- application crash | |- What else? | | | |Initiate graceful failover for Server maintainance? | |Just gracefully shutdown jboss. The Cluster dynamically figures out | |topology. Topology information is piggy-backed over invocation | |responses to | |client proxies when it changes. | | | |How flexible/controllable? | |We wanted to keep things as simple as possible for the initial |release to | |reduce code complexity and make sure we get the core things | |correct. If you | |want to know how flexible, buy the docs. It's only $10.00. | | | |Bill | | |
RE: [JBoss-dev] Ordering part 2 :-)
please remove the exceptions on 77, if you try a service and redeploy we get a nasty instance found ... I say it because I saw it in london, please take care of the redeploy problems with the 77 stuff, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Andreas Schaefer |Sent: Monday, March 18, 2002 1:57 PM |To: David Jencks; [EMAIL PROTECTED]; |[EMAIL PROTECTED] |Cc: Scott McLaughlin |Subject: Re: [JBoss-dev] Ordering part 2 :-) | | |Hi Geeks | |I just read your thread. I think one of the problems is that |JSR-77 is still ALPHA. Also it does not know anything |about SAR and how you can nest deployment units in there. | |1) I will create a JBoss specific SARModule (like EJBModule) |2) I will create a JBoss specific Service (like EJB or Servlet) |3) Look why the stopping of the components fails | |ATTENTION: JSR-77 exceptions are reported for testing |purposes. All the JSR-77 components should reflect JBoss |and NOT direct the development of JBoss in any way. |So whatever is correct for JBoss the JSR-77 components |will adapt. | |Have fun - Andy | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Ordering part 2 :-)
This is a 77 problem as far as I can tell, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Vesco |Claudio |Sent: Monday, March 18, 2002 1:20 AM |To: Jboss Dev (Posta elettronica) |Subject: [JBoss-dev] Ordering part 2 :-) | | |Hi alls! | |I think we have a little bug in MainDeployer. | |I'll try to explain the problem in my bad English :-( | |When I deploy redeploy an ear I have an JSR-77 exception |(javax.management.InstanceNotFound) because: | |deploy | init | init current deployer invoked | init subdeployers invoked | | create | create subdeployers invoked | create current deployer invoked | | start | start subdeployers invoked | start current deployer invoked | |undeploy | stop | stop current deployer invoked | stop subdeployers invoked | | destroy | destroy current deployer invoked | destroy subdeployers invoked | |I think the right order is: | |deploy | init (ok) | init current | init subdeployers | | create | create current | create subdeployers | | start | start current | start subdeployers | |undeploy | stop | stop subdeployers | stop current | | destroy | destroy subdeployers | destroy current | | |When I have modified the MainDeployer with this new order the exception |has not been take place. | |If Marc is of agreement can apply the patch or I can post it. | | Claudio | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Sun unofficially recommending JBoss as an Open-Source alternative
Guys, I thought you might find this amusing: couple of days ago I went to a Sun corporate presentation to my company, and got myself exposed to two long hours of Sun slideware. However, one of the presenters caught my ear with open-source alternatives. In a series of slides demonstrating why the SunONE initiative would be better than .NET, they have this slide containing in the left side a list of open-source products representing the full J2EE stack; on the other, iPlanet. The left side went on like this: Web Server: Apache, Servlet Runner: Tomcat; App. Server: JBOSS. Now that sure was cute. Regards, HJP ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Sun unofficially recommending JBoss as an Open-Source alternative
They will come around to it, we are making sure they get the message from us, we want to collaborate and make sure there is a credible alternative. And no, it doesn't include Apache/Jakarta and all that non-sense, all born right, free... marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Hugo |José Pinto |Sent: Monday, March 18, 2002 3:50 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] Sun unofficially recommending JBoss as an |Open-Source alternative | | |Guys, | |I thought you might find this amusing: couple of days ago I went to a Sun |corporate presentation to my company, and got myself exposed to two long |hours of Sun slideware. | |However, one of the presenters caught my ear with open-source |alternatives. In a series of slides demonstrating why the SunONE |initiative |would be better than .NET, they have this slide containing in the left side |a list of open-source products representing the full J2EE stack; on the |other, iPlanet. | |The left side went on like this: Web Server: Apache, Servlet |Runner: Tomcat; |App. Server: JBOSS. Now that sure was cute. | |Regards, | |HJP | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Feature Requests-531649 ] SOAP and Web Services
Feature Requests item #531649, was opened at 2002-03-18 16:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376688aid=531649group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: SOAP and Web Services Initial Comment: Support for Web Services and SOAP is now a key selling point for EJB server products from SUN, BEA and IBM. Addressing this need in JBoss would help it to climb the ladder faster. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376688aid=531649group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] WebIntegration TestSuite, JSPs and ClassLoaders....
I am trying to crush the two JSP compile errors in this testsuite. The classpath for Jasper is being built by walking up the classloader hierarchy from the WebApp to the top, passing each classloader to AbstractWebContainer.getClassLoaderURLs(ClassLoader). My problem is that the javax.servlet.jar does not seem to have been loaded by an immediate parent of my webapp's classloader. You will want a fixed width font to view this. sun.misc.Launcher$ExtClassLoader@7d8483 | | sun.misc.Launcher$AppClassLoader@7fdcde | | java.net.URLClassLoader@6930e2 | ---. | | org.jboss.system.UnifiedClassLoader@76949770 org.jboss.system.UnifiedClassLoader@806b8bd7 (JAVAX.SERVLET.JAR) | | java.net.FactoryURLClassLoader@5ef658 | | org.mortbay.http.ContextLoader (MY WEBAPP) Consequently the servlet jar does not get onto the classpath and JSP compilation fails. So what should happen here ? Should a UnifiedClassLoader return all it's siblings URLs as well - they are all loaded into a flat scope and are available to each other, are they not? Thanks for your time, Jules
[JBoss-dev] Automated JBoss Testsuite Results: 19-March-2002
JBoss daily test results SUMMARY Number of tests run: 537 Successful tests: 518 Errors:12 Failures: 7 [time of test: 19 March 2002 0:54 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-management/src/main/org/jboss/management/j2ee EJB.java EJBModule.java J2EEApplication.java J2EEManagedObject.java JCAConnectionFactory.java JCAManagedConnectionFactory.java JCAResource.java JDBCDataSource.java JDBCResource.java JMSResource.java JNDIResource.java JTAResource.java JavaMailResource.java RMI_IIOPResource.java ResourceAdapter.java ResourceAdapterModule.java URLResource.java
User: schaefera
Date: 02/03/18 17:09:19
Modified:src/main/org/jboss/management/j2ee EJB.java EJBModule.java
J2EEApplication.java J2EEManagedObject.java
JCAConnectionFactory.java
JCAManagedConnectionFactory.java JCAResource.java
JDBCDataSource.java JDBCResource.java
JMSResource.java JNDIResource.java JTAResource.java
JavaMailResource.java RMI_IIOPResource.java
ResourceAdapter.java ResourceAdapterModule.java
URLResource.java
Log:
Take out some of the exceptions reported:
- whenever a JSR-77 objects is not found for destruction ignore the exception
- whenever a Notification Listener cannot be removed because its source is
already destroyed then ignore it
Revision ChangesPath
1.4 +2 -1 jboss-management/src/main/org/jboss/management/j2ee/EJB.java
Index: EJB.java
===
RCS file:
/cvsroot/jboss/jboss-management/src/main/org/jboss/management/j2ee/EJB.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- EJB.java 18 Mar 2002 22:34:02 - 1.3
+++ EJB.java 19 Mar 2002 01:09:19 - 1.4
@@ -19,7 +19,7 @@
* {@link javax.management.j2ee.EJB EJB}.
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*
* pbRevisions:/b
*
@@ -81,6 +81,7 @@
// Now remove the EJB
pServer.unregisterMBean( new ObjectName( pEJBName ) );
}
+ catch( javax.management.InstanceNotFoundException infe ) {}
catch( Exception e ) {
lLog.error( Could not destory JSR-77 EJB: + pEJBName, e );
}
1.5 +3 -5
jboss-management/src/main/org/jboss/management/j2ee/EJBModule.java
Index: EJBModule.java
===
RCS file:
/cvsroot/jboss/jboss-management/src/main/org/jboss/management/j2ee/EJBModule.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- EJBModule.java16 Mar 2002 06:44:56 - 1.4
+++ EJBModule.java19 Mar 2002 01:09:19 - 1.5
@@ -31,7 +31,7 @@
* {@link javax.management.j2ee.EJBModule EJBModule}.
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*
* pbRevisions:/b
*
@@ -177,8 +177,8 @@
J2EEApplication.destroy( pServer, lParent.toString() );
} // end of if ()
-
}
+ catch( javax.management.InstanceNotFoundException infe ) {}
catch( Exception e ) {
lLog.error( Could not destory JSR-77 EJBModule: + pModuleName, e );
}
@@ -288,9 +288,7 @@
getServer().removeNotificationListener( mService, mState );
}
catch( JMException jme ) {
- //AS ToDo: later on we have to define what happens when service is null or
- //AS ToDo: not found.
- jme.printStackTrace();
+ // When the service is not available anymore then just ignore the exception
}
}
1.4 +7 -12
jboss-management/src/main/org/jboss/management/j2ee/J2EEApplication.java
Index: J2EEApplication.java
===
RCS file:
/cvsroot/jboss/jboss-management/src/main/org/jboss/management/j2ee/J2EEApplication.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- J2EEApplication.java 16 Mar 2002 06:44:56 - 1.3
+++ J2EEApplication.java 19 Mar 2002 01:09:19 - 1.4
@@ -24,7 +24,7 @@
* {@link javax.management.j2ee.J2EEApplication J2EEApplication}.
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*
* pbRevisions:/b
*
@@ -104,22 +104,17 @@
try {
ObjectName lApplication;
if( pName.indexOf( J2EEManagedObject.TYPE + = +
J2EEApplication.J2EE_TYPE ) = 0 ) {
-lApplication = new ObjectName( pName );
+pServer.unregisterMBean( new ObjectName( pName ) );
} else {
-// Find the Object to be destroyed
-ObjectName lSearch = new ObjectName(
+J2EEManagedObject.removeObject(
+ pServer,
J2EEManagedObject.getDomainName() + : +
- J2EEManagedObject.TYPE + = + J2EE_TYPE + ,name= + pName + , +
- *
+ J2EEManagedObject.TYPE + = + J2EE_TYPE + ,name= + pName + ,
+
+ *
);
-lApplication =
Re: [JBoss-dev] Ordering part 2 :-)
Hi Claudio The unnecessary exceptions previously reported by JSR-77 is ingored now. Please can you check your example to see if this solves your problem and if not please can you provide me with your log-file, thanx. Have a nice day - Andy - Original Message - From: marc fleury [EMAIL PROTECTED] To: Andreas Schaefer [EMAIL PROTECTED]; David Jencks [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Scott McLaughlin [EMAIL PROTECTED] Sent: Monday, March 18, 2002 3:22 PM Subject: RE: [JBoss-dev] Ordering part 2 :-) please remove the exceptions on 77, if you try a service and redeploy we get a nasty instance found ... I say it because I saw it in london, please take care of the redeploy problems with the 77 stuff, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] when does website get rebuilt?
This is a marc thing... --jason Bill Burke wrote: Is it done automatically? Or do you have to ping somebody to do it? Thanks, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 19-March-2002
JBoss daily test results SUMMARY Number of tests run: 544 Successful tests: 526 Errors:10 Failures: 8 [time of test: 19 March 2002 1:40 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20020124 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] WebIntegration TestSuite, JSPs and ClassLoaders....
Jules, I can see the javax.servlet.jar on the JSP classpath returned from AbstractWebContainer.getClassLoaderURLs - what jboss version are you using? Caveat: I haven't refreshed my tree in the last 3 days or so, so maybe there has been a recent change ... Jan Jules Gosnell wrote: I am trying to crush the two JSP compile errors in this testsuite. The classpath for Jasper is being built by walking up the classloader hierarchy from the WebApp to the top, passing each classloader to AbstractWebContainer.getClassLoaderURLs(ClassLoader). My problem is that the javax.servlet.jar does not seem to have been loaded by an immediate parent of my webapp's classloader. You will want a fixed width font to view this. sun.misc.Launcher$ExtClassLoader@7d8483 | | sun.misc.Launcher$AppClassLoader@7fdcde | | java.net.URLClassLoader@6930e2 | ---. | | org.jboss.system.UnifiedClassLoader@76949770 org.jboss.system.UnifiedClassLoader@806b8bd7 (JAVAX.SERVLET.JAR) | | java.net.FactoryURLClassLoader@5ef658 | | org.mortbay.http.ContextLoader (MY WEBAPP) Consequently the servlet jar does not get onto the classpath and JSP compilation fails. So what should happen here ? Should a UnifiedClassLoader return all it's siblings URLs as well - they are all loaded into a flat scope and are available to each other, are they not? Thanks for your time, Jules ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] WebIntegration TestSuite, JSPs and ClassLoaders....
Jules, Furthermore, if you are intending using the URLs returned by the AbstractWebContainer.getClassLoaderURLs(), then you are going to run into the njar problem (ie jars within sars etc are not unpacked, so there is no URL to a disk location), which is how we got into this whole issue in the first place. Or have I misunderstood where your question comes from ? Jan Jan Bartel wrote: Jules, I can see the javax.servlet.jar on the JSP classpath returned from AbstractWebContainer.getClassLoaderURLs - what jboss version are you using? Caveat: I haven't refreshed my tree in the last 3 days or so, so maybe there has been a recent change ... Jan Jules Gosnell wrote: I am trying to crush the two JSP compile errors in this testsuite. The classpath for Jasper is being built by walking up the classloader hierarchy from the WebApp to the top, passing each classloader to AbstractWebContainer.getClassLoaderURLs(ClassLoader). My problem is that the javax.servlet.jar does not seem to have been loaded by an immediate parent of my webapp's classloader. You will want a fixed width font to view this. sun.misc.Launcher$ExtClassLoader@7d8483 | | sun.misc.Launcher$AppClassLoader@7fdcde | | java.net.URLClassLoader@6930e2 | ---. | | org.jboss.system.UnifiedClassLoader@76949770 org.jboss.system.UnifiedClassLoader@806b8bd7 (JAVAX.SERVLET.JAR) | | java.net.FactoryURLClassLoader@5ef658 | | org.mortbay.http.ContextLoader (MY WEBAPP) Consequently the servlet jar does not get onto the classpath and JSP compilation fails. So what should happen here ? Should a UnifiedClassLoader return all it's siblings URLs as well - they are all loaded into a flat scope and are available to each other, are they not? Thanks for your time, Jules ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 19-March-2002
JBoss daily test results SUMMARY Number of tests run: 544 Successful tests: 528 Errors:10 Failures: 6 [time of test: 19 March 2002 2:24 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1_02a-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jboss/Catalina and ports bug?
About a month ago I downloaded Tomcat and MySQL and have been running them on Mac OS X (FreeBSD). I've created a site using servlets and jsps and everything's working fine (http://www.gaddzeit.com). So I'm now preparing to start into EJBs. On Friday I downloaded: JBoss-2.4.4_Tomcat-4.0.1.zip, bought the manual, studied the documentation plus several other net tutorials that I've come across. Here's the process I'm following: 1. I've shut down my standalone version of tomcat. 2. I'm running the script /jboss/bin/run_with_catalina.sh which launches both jboss and catalina without errors. 3. The jboss.jcml file shows port configuration as: mbean code=org.jboss.web.WebService name=DefaultDomain:service=Webserver attribute name=Port8083/attribute !-- Should resources and non-EJB classes be downloadable -- attribute name=DownloadServerClassestrue/attribute /mbean 4. During startup, two ports are reported on as follows: [INFO,WebService] Starting [INFO,WebService] Started webserver with address: null port: 8083 [INFO,WebService] Codebase set to: http://localhost:8083/ [INFO,WebService] Started and [INFO,EmbeddedCatalinaServiceSX] HttpConnector Opening server socket on all host IP addresses [INFO,EmbeddedCatalinaServiceSX] HttpConnector[8080] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080][0] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080][1] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080][2] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080][3] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080][4] Starting background thread [INFO,EmbeddedCatalinaServiceSX] OK [INFO,EmbeddedCatalinaServiceSX] Started 5. When I launch a browser and enter http://localhost:8083/ into the browser, I am returned a page with 0 characters. 6. When I enter http://localhost:8080/, I get: HTTP Status 500 - No Context configured to process this request 6. Now, according to page 319 of the manual: The MBean used to embed the Tomcat-4.x series of web containers is the org.jboss.web.catalina.EmbeddedCatalinaServiceSX service. It is a subclass of the AbstractWebContainer class. Its configurable attributes include etc etc etc MY QUESTIONS 1. Shouldn't either 8083 or 8080 on a clean install of JBoss-2.4.4_Tomcat-4.0.1 give me some kind of default page? 2. If not, and I have to configurethe EmbeddedCatalinaServiceSX class first, where is it located? The path under src is org/jboss/web/ - there is no subfolder catalina. 3. I wanted to search the archives for an answer but the search engine at the top of this page: http://www.geocrawler.com/lists/3/SourceForge/10766/0/ doesn't seem to find messages from the jboss list very effectively. I've limited my search to sourceforge.net in the dropdown, but I'm still getting all kinds of downloads and other stuff--how do I simply search JUST the jboss archive? Thanks for the help from a newbie, David Gadd http://www.gaddzeit.com -- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-management/src/main/org/jboss/management/j2ee J2EEManagedObject.java
User: schaefera
Date: 02/03/18 18:50:18
Modified:src/main/org/jboss/management/j2ee J2EEManagedObject.java
Log:
Removed another unecessary exception stack trace.
Revision ChangesPath
1.5 +13 -8
jboss-management/src/main/org/jboss/management/j2ee/J2EEManagedObject.java
Index: J2EEManagedObject.java
===
RCS file:
/cvsroot/jboss/jboss-management/src/main/org/jboss/management/j2ee/J2EEManagedObject.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- J2EEManagedObject.java19 Mar 2002 01:09:19 - 1.4
+++ J2EEManagedObject.java19 Mar 2002 02:50:18 - 1.5
@@ -11,6 +11,7 @@
import java.util.Hashtable;
import java.util.Set;
+import javax.management.InstanceNotFoundException;
import javax.management.JMException;
import javax.management.MalformedObjectNameException;
import javax.management.MBeanServer;
@@ -24,7 +25,7 @@
* {@link javax.management.j2ee.J2EEManagedObject J2EEManagedObject}.
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*
* pbRevisions:/b
*
@@ -261,13 +262,17 @@
try {
// Only remove child if it is a child (root has not parent)
if( mParent != null ) {
-// Notify the parent about its new child
-getServer().invoke(
- mParent,
- removeChild,
- new Object[] { mName },
- new String [] { ObjectName.class.getName() }
-);
+try {
+ // Notify the parent about its new child
+ getServer().invoke(
+ mParent,
+ removeChild,
+ new Object[] { mName },
+ new String [] { ObjectName.class.getName() }
+ );
+}
+catch( InstanceNotFoundException infe ) {
+}
}
// Let the subclass handle pre destruction steps
preDestruction();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss/Catalina and ports bug?
8083 is used to serve classes, not web pages. There is no default application with embedded Tomcat, you have to supply something yourself to see a page on 8080. david jencks On 2002.03.18 21:46:26 -0500 David Gadd wrote: About a month ago I downloaded Tomcat and MySQL and have been running them on Mac OS X (FreeBSD). I've created a site using servlets and jsps and everything's working fine (http://www.gaddzeit.com). So I'm now preparing to start into EJBs. On Friday I downloaded: JBoss-2.4.4_Tomcat-4.0.1.zip, bought the manual, studied the documentation plus several other net tutorials that I've come across. Here's the process I'm following: 1. I've shut down my standalone version of tomcat. 2. I'm running the script /jboss/bin/run_with_catalina.sh which launches both jboss and catalina without errors. 3. The jboss.jcml file shows port configuration as: mbean code=org.jboss.web.WebService name=DefaultDomain:service=Webserver attribute name=Port8083/attribute !-- Should resources and non-EJB classes be downloadable -- attribute name=DownloadServerClassestrue/attribute /mbean 4. During startup, two ports are reported on as follows: [INFO,WebService] Starting [INFO,WebService] Started webserver with address: null port: 8083 [INFO,WebService] Codebase set to: http://localhost:8083/ [INFO,WebService] Started and [INFO,EmbeddedCatalinaServiceSX] HttpConnector Opening server socket on all host IP addresses [INFO,EmbeddedCatalinaServiceSX] HttpConnector[8080] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080][0] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080][1] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080][2] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080][3] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080][4] Starting background thread [INFO,EmbeddedCatalinaServiceSX] OK [INFO,EmbeddedCatalinaServiceSX] Started 5. When I launch a browser and enter http://localhost:8083/ into the browser, I am returned a page with 0 characters. 6. When I enter http://localhost:8080/, I get: HTTP Status 500 - No Context configured to process this request 6. Now, according to page 319 of the manual: The MBean used to embed the Tomcat-4.x series of web containers is the org.jboss.web.catalina.EmbeddedCatalinaServiceSX service. It is a subclass of the AbstractWebContainer class. Its configurable attributes include etc etc etc MY QUESTIONS 1. Shouldn't either 8083 or 8080 on a clean install of JBoss-2.4.4_Tomcat-4.0.1 give me some kind of default page? 2. If not, and I have to configurethe EmbeddedCatalinaServiceSX class first, where is it located? The path under src is org/jboss/web/ - there is no subfolder catalina. 3. I wanted to search the archives for an answer but the search engine at the top of this page: http://www.geocrawler.com/lists/3/SourceForge/10766/0/ doesn't seem to find messages from the jboss list very effectively. I've limited my search to sourceforge.net in the dropdown, but I'm still getting all kinds of downloads and other stuff--how do I simply search JUST the jboss archive? Thanks for the help from a newbie, David Gadd http://www.gaddzeit.com -- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss/Catalina and ports bug?
3. I wanted to search the archives for an answer but the search engine at the top of this page: http://www.geocrawler.com/lists/3/SourceForge/10766/0/ doesn't seem to find messages from the jboss list very effectively. I've limited my search to sourceforge.net in the dropdown, but I'm still getting all kinds of downloads and other stuff--how do I simply search JUST the jboss archive? http://www.mail-archive.com is a pretty reasonable source of arhives (not just for JBoss - http://www.mail-archive.com/jboss-user%40lists.sourceforge.net/). hth dim ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 19-March-2002
JBoss daily test results SUMMARY Number of tests run: 544 Successful tests: 527 Errors:10 Failures: 7 [time of test: 19 March 2002 3:35 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-02a-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 19-March-2002
JBoss daily test results SUMMARY Number of tests run: 544 Successful tests: 528 Errors:10 Failures: 6 [time of test: 19 March 2002 4:41 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] test
Test Jason Uithol Data Technologist DatacodeX Pty Ltd [EMAIL PROTECTED] http://www.datacodex.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-530627 ] ejbStore invoked after ejbRemove on BMP
Bugs item #530627, was opened at 2002-03-16 00:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=530627group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Mac (macearl) Assigned to: Nobody/Anonymous (nobody) Summary: ejbStore invoked after ejbRemove on BMP Initial Comment: Win2000 JDK 1.3.1_01 I'm doing a BMP test - I'd sumbit the source, but it's not mine to give :( - I invoked the remove on the EJBObject.remove() method on a bean, and after the bean is successfully removed the ejbStore operation is performed, which causes an exception since the object is no longer available in the database. It kind of goes without saying that this is a spec compliance issue as well (since ejbStore should not be invoked after an ejbRemove operation). The whole think appears to happen in the same transaction context, because the when I review the hypersonic database script my removed entity is still there. I'm presuming that the entity is removed and then the failed store operation throws an EJBException, which causes the transaction to be rolled back. I'm using the default database configuration. I was able to put this all together by logging the invocation of logging methods to System.out. Note the error message Invalid update rowcount on customer. That's my custom message saying that the store operation did not effect exactly 1 row in the database. Here's the relevant portion of the trace. 2002-03-15 23:55:34,334 INFO [STDOUT] EJBStore executing 2002-03-15 23:55:34,334 INFO [STDOUT] ejbStore completed successfully. 2002-03-15 23:55:34,354 INFO [STDOUT] getting first name 2002-03-15 23:55:34,354 INFO [STDOUT] EJBStore executing 2002-03-15 23:55:34,354 INFO [STDOUT] ejbStore completed successfully. 2002-03-15 23:55:34,384 INFO [STDOUT] EJBStore executing 2002-03-15 23:55:34,384 INFO [STDOUT] ejbStore completed successfully. 2002-03-15 23:55:34,394 INFO [STDOUT] EJBStore executing 2002-03-15 23:55:34,404 INFO [STDOUT] ejbStore completed successfully. 2002-03-15 23:55:34,414 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.AccountH olderEJB.findByIdentity] Executing SQL: SELECT t0_owner.clientId, t0_owner.createDate FROM AccountHolderEJB t0_owner WHERE t0_owner.username = ? AND t0_owner.password = ? 2002-03-15 23:55:34,434 INFO [STDOUT] EJBRemove executing. 2002-03-15 23:55:34,434 INFO [STDOUT] EJBRemove completed successfully. 2002-03-15 23:55:34,444 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCFindByPrimaryKeyQue ry.AccountEJB.findByPrimaryKey] Executing SQL: SELECT accountId, createDate FROM AccountEJB WHERE accountId=? AND createDate=? 2002-03-15 23:55:34,444 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.A ccountHolderEJB] Executing SQL: SELECT firstName, lastName, emailAddress, username, password, address FROM AccountHolderEJB WHERE (clientId=? AND createDate=?) 2002-03-15 23:55:34,454 INFO [STDOUT] EJBStore executing 2002-03-15 23:55:34,514 ERROR [org.jboss.ejb.GlobalTxEntityMap] Store failed on entity: com.sextanttech.entities.interfaces.AccountHolderKey@4c 1dbbf7 javax.ejb.EJBException: Invalid update row count on customer. at com.sextanttech.entities.implementations.AccountHolderB MPBean.ejbStore(AccountHolderBMPBean.java:150) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.plugins.BMPPersistenceManager.storeEntity (BMPPersistenceManager.java:455) at org.jboss.ejb.EntityContainer.storeEntity (EntityContainer.java:676) at org.jboss.ejb.GlobalTxEntityMap.syncEntities (GlobalTxEntityMap.java:177) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanu p.beforeCompletion(GlobalTxEntityMap.java:315) at org.jboss.tm.TxCapsule.doBeforeCompletion (TxCapsule.java:1317) at org.jboss.tm.TxCapsule.rollback (TxCapsule.java:430) at org.jboss.tm.TransactionImpl.rollback (TransactionImpl.java:88) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:180) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:127) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:166) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:474) at org.jboss.ejb.Container.invoke (Container.java:681) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:1003) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1555) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke (JRMPInvoker.java:364) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:241)
[JBoss-dev] Automated JBoss Testsuite Results: 19-March-2002
JBoss daily test results SUMMARY Number of tests run: 542 Successful tests: 525 Errors:11 Failures: 6 [time of test: 19 March 2002 5:57 GMT] [java.version: 1.3.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_02-b02] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] WebIntegration TestSuite, JSPs and ClassLoaders....
Title: Nachricht
Hi
Jules,
-Ursprüngliche Nachricht-Von:
Jules Gosnell [mailto:[EMAIL PROTECTED]]Gesendet: Dienstag, 19. März 2002
01:39An:
[EMAIL PROTECTED]Betreff:
[JBoss-dev] WebIntegration TestSuite, JSPs and
ClassLoaders
Should a UnifiedClassLoader return all
it's siblings URLs as well - they are all loaded into a flat scope and are
available to each other, are they not?Hmm, ideally
yes, since the siblings contain indeed classes that may possibly be needed to
run the web application (not only javax.servlet.jar, could only contain EJB
interface classes etc.) andhencealso tocompilea
JSP.
If
that becomes too verbose, we would need some kind of precompilation step
thatrules out the possible dependencies (using source/byte-code
analysis? starting from the JSP-code imports and then doing
loadClass("bla").getClassLoader()? Just a silly idea. Maybe tt-bytecode can
help with that, I´m just about to check that in anyway) ...
Best,
CGJ
Re: [JBoss-dev] WebIntegration TestSuite, JSPs and ClassLoaders....
No, i know about the njar problem - that was the next on the list. I'm not sure whether a public accessor has been added to allow you to convert njar-file (all the nested jars are unpacked into tmp and an index maintained), but there were plans afoot. Jules Jan Bartel wrote: Jules, Furthermore, if you are intending using the URLs returned by the AbstractWebContainer.getClassLoaderURLs(), then you are going to run into the njar problem (ie jars within sars etc are not unpacked, so there is no URL to a disk location), which is how we got into this whole issue in the first place. Or have I misunderstood where your question comes from ? Jan Jan Bartel wrote: Jules, I can see the javax.servlet.jar on the JSP classpath returned from AbstractWebContainer.getClassLoaderURLs - what jboss version are you using? Caveat: I haven't refreshed my tree in the last 3 days or so, so maybe there has been a recent change ... Jan Jules Gosnell wrote: I am trying to crush the two JSP compile errors in this testsuite. The classpath for Jasper is being built by walking up the classloader hierarchy from the WebApp to the top, passing each classloader to AbstractWebContainer.getClassLoaderURLs(ClassLoader). My problem is that the javax.servlet.jar does not seem to have been loaded by an immediate parent of my webapp's classloader. You will want a fixed width font to view this. sun.misc.Launcher$ExtClassLoader@7d8483 | | sun.misc.Launcher$AppClassLoader@7fdcde | | java.net.URLClassLoader@6930e2 | ---. | | org.jboss.system.UnifiedClassLoader@76949770 org.jboss.system.UnifiedClassLoader@806b8bd7 (JAVAX.SERVLET.JAR) | | java.net.FactoryURLClassLoader@5ef658 | | org.mortbay.http.ContextLoader (MY WEBAPP) Consequently the servlet jar does not get onto the classpath and JSP compilation fails. So what should happen here ? Should a UnifiedClassLoader return all it's siblings URLs as well - they are all loaded into a flat scope and are available to each other, are they not? Thanks for your time, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
