[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Testsuite Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server - so these results are for yesterdays code. === [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:1035: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:1085: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/ClientFailTest.java:113: warning: stop() in java.lang.Thread has been deprecated [javac] t.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:77: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:121: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:143: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:161: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/ExceptionListenerTest.java:63: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:111: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:113: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:168: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:170: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:75: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:129: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:133: warning: stop() in java.lang.Thread has been deprecated [javac] tf.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:74: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:116: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/security/service/HttpsClient.java:86: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated [javac] if( conn instanceof HttpsURLConnection ) [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/security/service/HttpsClient.java:91: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated [javac] HttpsURLConnection httpsConn
[JBoss-dev] [AUTOMATED] JBoss (HEAD/winxp) Testsuite Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server - so these results are for yesterdays code. === [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest.java:161: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\ExceptionListenerTest.java:63: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:75: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:129: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:133: warning: stop() in java.lang.Thread has been deprecated [javac] tf.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscribers.java:111: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscribers.java:113: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscribers.java:168: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscribers.java:170: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\QueueTest.java:74: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\QueueTest.java:116: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:606: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:641: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:921: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:970: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:1035: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:1085: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\service\HttpsClient.java:86: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated [javac] if( conn instanceof HttpsURLConnection ) [javac] ^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\service\HttpsClient.java:91: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated [javac] HttpsURLConnection httpsConn = (HttpsURLConnection) conn; [javac] ^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\service\HttpsClient.java:91: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated
RE: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
On Tue, 2003-07-08 at 06:54, Jeremy Boynes wrote: I would say the opposite behavior should be the default since if there is an ejb-link it must be resolvable in the scope of the current deployment while a jndi-name cannot in general be resolved since this can refer to an external server that need not even be available during deployment. Therefore, use the ejb-link first, and if none is specified, use the jndi-name. To maintain the current behavior add a flag to the war deployer which treats failures to resolve ejb-links as deployment errors. This would be false by default in which case a failure to resolve an ejb-link triggers fallback to the use of the jndi-name. I disagee with the last bit here. If ejb-link is specified and the target EJB does not exist in the current deployment, then it should definitely be a deployment error as the standard descriptor was mis-assembled. Any flag should be to turn this behaviour off and allow a mis-configured deployment to drop through to the [local-]jndi-name; this should apply to the EJB deployer as well for consistency. If no ejb-link is specified, then a [local-]jndi-name must be specified. If it is not, then it's a deployment error (as it is now for EJBs and should be for WARs) as there is no sensible default (well, maybe the ejb-ref-name less any ejb/). If both exist, we can check they are consistent. A clear error message will help people where it is not. ejb-local-refs are only intended for ejbs in the same deployment so ejb-link should suffice, but the spec is not very explicit. The way jboss works, this won't be a problem. It should not break any existing deployments. Sorry, but I'm not sure what you mean - do you mean that you are or aren't in favour of making the handling consistent, and therefore introducing the ejb-local-ref element? There is no need for an ejb-local-ref in the JBoss specific descriptors as the ejb-link element handles this in the standard descriptor. There is no reason why the metadata needs to be expanded to allow for specifying the local home jndi name. There is, because ejb-link is optional: !ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type, local-home, local, ejb-link?) ^ --| and if it's not there you need to be able to specify the target's local-jndi-name. This would help when porting from weblogic which has a similar descriptor. -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Reply inline. I would say the opposite behavior should be the default since if there is an ejb-link it must be resolvable in the scope of the current deployment while a jndi-name cannot in general be resolved since this can refer to an external server that need not even be available during deployment. Therefore, use the ejb-link first, and if none is specified, use the jndi-name. To maintain the current behavior add a flag to the war deployer which treats failures to resolve ejb-links as deployment errors. This would be false by default in which case a failure to resolve an ejb-link triggers fallback to the use of the jndi-name. I disagee with the last bit here. If ejb-link is specified and the target EJB does not exist in the current deployment, then it should definitely be a deployment error as the standard descriptor was mis-assembled. Any flag should be to turn this behaviour off and allow a mis-configured deployment to drop through to the [local-]jndi-name; this should apply to the EJB deployer as well for consistency. If no ejb-link is specified, then a [local-]jndi-name must be specified. If it is not, then it's a deployment error (as it is now for EJBs and should be for WARs) as there is no sensible default (well, maybe the ejb-ref-name less any ejb/). I agree. I think using the ejb-link first is preferable, because it is part of the standard descriptor. If it is absent, fallback to the [local-]jndi-name. If it is specified but wrong, then use the flag to indicate to use the jndi-name. ejb-local-refs are only intended for ejbs in the same deployment so ejb-link should suffice, but the spec is not very explicit. The way jboss works, this won't be a problem. It should not break any existing deployments. Sorry, but I'm not sure what you mean - do you mean that you are or aren't in favour of making the handling consistent, and therefore introducing the ejb-local-ref element? There is no need for an ejb-local-ref in the JBoss specific descriptors as the ejb-link element handles this in the standard descriptor. There is no reason why the metadata needs to be expanded to allow for specifying the local home jndi name. There is, because ejb-link is optional: !ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type, local-home, local, ejb-link?) ^ --| and if it's not there you need to be able to specify the target's local-jndi-name. Yup, I agree. Jan / * Jan Bartel [EMAIL PROTECTED] * Associate * Core Developers Network LLC * http://www.coredevelopers.net / --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Testsuite Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server - so these results are for yesterdays code. === [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:1035: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/test/SecurityUnitTestCase.java:1085: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/ClientFailTest.java:113: warning: stop() in java.lang.Thread has been deprecated [javac] t.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:77: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:121: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:143: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:161: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/ExceptionListenerTest.java:63: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:111: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:113: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:168: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:170: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:75: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:129: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:133: warning: stop() in java.lang.Thread has been deprecated [javac] tf.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:74: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:116: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/security/service/HttpsClient.java:86: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated [javac] if( conn instanceof HttpsURLConnection ) [javac] ^ [javac] /home/jbossci/jbossci/jboss-head/testsuite/src/main/org/jboss/test/security/service/HttpsClient.java:91: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated [javac] HttpsURLConnection httpsConn
[JBoss-dev] [ jboss-Bugs-767716 ] bad behaviour findByPK with null arg + commit A
Bugs item #767716, was opened at 2003-07-08 14:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=767716group_id=22866
Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Julien Viet (cooperfbi)
Assigned to: Nobody/Anonymous (nobody)
Summary: bad behaviour findByPK with null arg + commit A
Initial Comment:
when using a findByPrimaryKey(null) with commit option
A (meanning cache), the query goes to the instance
cache and it does not like it, throwing a
IllegalStateException instead of having another
behaviour (like ONFE or NPE)
the snippet CMPPersistenceManager#findEntity
if (finderMethod.getName().equals(findByPrimaryKey)
commitOption !=
ConfigurationMetaData.B_COMMIT_OPTION
commitOption !=
ConfigurationMetaData.C_COMMIT_OPTION)
{
Object key = ctx.getCacheKey();
if (key == null)
{
key = ((EntityCache)con.getInstanceCache
()).createCacheKey(args[0]);
}
// the IllegalStateException is thrown when calling
the line after
if (con.getInstanceCache().isActive(key))
{
return key;
}
}
in addition here is a stacktrace excerpt :
java.lang.IllegalArgumentException: Requesting an
object using a null key
at org.jboss.util.LRUCachePolicy.peek
(LRUCachePolicy.java:141)
at
org.jboss.ejb.plugins.AbstractInstanceCache.isActive
(AbstractInstanceCache.java:213)
at
org.jboss.ejb.plugins.CMPPersistenceManager.findEntity
(CMPPersistenceManager.java:305)
at
org.jboss.resource.connectionmanager.CachedConnection
Interceptor.findEntity
(CachedConnectionInterceptor.java:301)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=767716group_id=22866
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] multiple deployment info entries for invoker.war
I see what you are saying about breaking the mirror, the removal of deployers should be controlled by the deployer services. Code already exists in ServerImpl.ShutdownHook.shutdown() to invoke ServiceController.shutdown(), which walks backwards through it's service list to stop, destroy and remove each. From what you say, this could handle undeploying everything. Currently, nothing actually gets undeployed at that point because MainDeployer.shutdown() gets called, and undeploys everything, before ServiceController.shutdown() is called. So, if service shutdown effectively handles undeployment, and preserves the mirror, is there really a need for MainDeployer to undeploy anything at shutdown? Can MainDeployer do all its housekeeping in destroyService()? Then what's left for shutdown() do? Except maybe ask the service controller to stop the deployer services? Rod Burgett Senior Software Engineer webMethods, Inc. 3930 Pender Drive Fairfax, VA 22030 USA Ph: 703.460.5819 (tty only) It's all just 0s 1s - the trick is getting them lined up in the proper order -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 11:35 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] multiple deployment info entries for invoker.war The bigger problem is that the deployment layer does not run a clean state machine. Requests to deploy content should not be allowed when the MainDeployer is being shutdown and therefore the deployment list copy is not needed. Adding a removeDeployer loop in the MainDeployer.shutdown actually breaks the current start/stop mirror behavior since currently all but the bootstrap jar and sar deployers are added/removed in the SubDeployerSupport.startService/stopService methods. What makes more sense to me is to have the MainDeployer.shutdown stop all deployers which will have the side affect of undeploying all content and removing the deployers. What is inconsistent here is that the MainDeployer, JARDeployer and SARDeployer are started as bootstrap services by the ServerImpl, but shutdown does not simply stop and unregister these services in reverse order. -- Scott Stark Chief Technology Officer JBoss Group, LLC Rod Burgett wrote: D-oh! That's embarrassing, I missed the finally block, thinking that 'return' meant return. Thanks for pointing that out. I stumbled onto this duplication while investigating some extra warning messages during shutdown. I'm working on a patch to clean those up. I'll add something to that patch for this up as well. The extra warning messages are from .war files nested inside .sar or .ear files; for example invoker.war inside http-invoker.sar. They both have entries in deploymentList, and undeploying the .sar undeploys the .war, which removes the .war from the deploymentList. But after the .sar undeployment finishes, shutdown() attempts to undeploy the .war, again. Why does it try again when the .war is no longer in deploymentList? Because shutdown is working from a copy of deploymentList. You see the same message with welcome.ear and welcome.war. Also, I think the same sequence occurs with nested .jar files, but the JARDeployer doesn't complain, so it's not noticable. I think the best solution for this is to add a removeDeployer loop to MainDeployer.shutdown(), prior to the 'undeploy everything in sight' loop. That will change the order of undeployment some, but not materially. Basically, this eliminates the duplicate undeployment by splitting it up, so a new deploymentList copy is made for each deployer. Conceptually, this is a cleaner shutdown than the current one, since the current shutdown doesn't go through the removeDeployer processing. A graceful shutdown should mirror startup as much as possible. This isn't a perfect solution, because this removeDeployer loop can't remove the JAR and SAR deployers. There may still be nesting scenarios - maybe an archive nesting an archive of the same type - where the list gets out of synch with it's copy. I'm open to other suggestions. Rod Burgett Senior Software Engineer webMethods, Inc. 3930 Pender Drive Fairfax, VA 22030 USA Ph: 703.460.5819 (tty only) It's all just 0s 1s - the trick is getting them lined up in the proper order --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06 1203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED]
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Jeremy Boynes wrote: Scott Stark wrote: There is no need for an ejb-local-ref in the JBoss specific descriptors as the ejb-link element handles this in the standard descriptor. There is no reason why the metadata needs to be expanded to allow for specifying the local home jndi name. There is, because ejb-link is optional: !ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type, local-home, local, ejb-link?) ^ --| and if it's not there you need to be able to specify the target's local-jndi-name. Jeremy I agree with Scott. Having a element be optional in the DTD doesn't mean it optional for a correct deployment. The intent is that a deployment descriptor may be written by a developer without the ejb-link. The link will be specified later by the deployer or integrator. --Victor
RE: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Victor Langelo wrote: I agree with Scott. Having a element be optional in the DTD doesn't mean it optional for a correct deployment. The intent is that a deployment descriptor may be written by a developer without the ejb-link. The link will be specified later by the deployer or integrator. --Victor The spec makes the usage optional as well: The Application Assembler *can* use the ejb-link element in the deployment descriptor to link an EJB reference to a target enterprise bean. [EJB2.0 pp 418] Note the use of can not must And: *If* an EJB reference declaration includes the ejb-link element, the Deployer *should* bind the enterprise bean reference to the home of the enterprise bean specified as the link's target. [EJB2.0 pp 420] Again note If and should Finally: The Deployer must ensure that all the declared EJB references are bound to the homes of enterprise beans that exist in the operational environment. [EJB2.0 pp 420] So if the target is not there then it is a Deployment error. That seems a little restrictive if checked at deploy time because of boot order dependencies and redeployment, but if the target is not present when used then an error must be raised. Jeremy /* * Jeremy Boynes * Partner * Core Developers Network */ --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (HEAD/winxp) Testsuite Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server - so these results are for yesterdays code. === [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest.java:161: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\ExceptionListenerTest.java:63: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac] ^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:75: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:129: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:133: warning: stop() in java.lang.Thread has been deprecated [javac] tf.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscribers.java:111: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscribers.java:113: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscribers.java:168: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscribers.java:170: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\QueueTest.java:74: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\stress\QueueTest.java:116: warning: stop() in java.lang.Thread has been deprecated [javac] t2.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:606: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:641: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:921: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:970: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:1035: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:1085: warning: stop() in java.lang.Thread has been deprecated [javac] t1.stop(); [javac]^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\service\HttpsClient.java:86: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated [javac] if( conn instanceof HttpsURLConnection ) [javac] ^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\service\HttpsClient.java:91: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated [javac] HttpsURLConnection httpsConn = (HttpsURLConnection) conn; [javac] ^ [javac] F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\service\HttpsClient.java:91: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated
[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 8-July-2003
Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 8-July-2003 JBoss daily test results SUMMARY Number of tests run: 1369 Successful tests: 1352 Errors:10 Failures: 7 [time of test: 2003-07-08.16-17 GMT] [java.version: 1.4.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_02-b06] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-9smp] Useful resources: - http://jboss.sourceforge.net//junit-results/32/2003-07-08.16-17 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: ScopingUnitTestCase Test:testSingletons Type:failure Exception: junit.framework.AssertionFailedError Message: checkVersion(V2) is true - Suite: StatefulSessionUnitTestCase Test:testStrictPooling Type:failure Exception: junit.framework.AssertionFailedError Message: SessionInvoker.runEx != null - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionInTxMarkRollback_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionInTxMarkRollback_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: ConnectionUnitTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: BaseConnectionManagerUnitTestCase Test:testFillToMin Type:failure Exception: junit.framework.AssertionFailedError Message: Wrong number of connections counted: 0 - Suite: JDBCDriverRedeployUnitTestCase Test:testRedeploy Type:failure Exception: junit.framework.AssertionFailedError Message: This test does not work because of class caching in java.sql.DriverManager - Suite: MissingClassUnitTestCase Test:testDeployServiceWithoutClass Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/home/starksm/JBoss/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testHaParitionName Type:error Exception: java.lang.NumberFormatException Message: For input string: DefaultPartition - Suite: SecurityUnitTestCase Test:testSecureHttpInvoker Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: SecurityUnitTestCase Test:testHttpReadonlyLookup Type:failure Exception: junit.framework.AssertionFailedError Message: UndeclaredThrowableException thrown - Suite: SRPUnitTestCase Test:testEchoArgs Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - Suite: XMLLoginModulesUnitTestCase Test:testJCACallerIdentity Type:error Exception: javax.security.auth.login.LoginException Message: Error: no CallbackHandler available to collect authentication information - Suite: HelloClusteredHttpStressTestCase Test:testCNFEObject Type:failure Exception: junit.framework.AssertionFailedError
[JBoss-dev] [ jboss-Bugs-767905 ] Farm re-deployment doesn't work
Bugs item #767905, was opened at 2003-07-08 10:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=767905group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Duffey (kevin-duffey) Assigned to: Nobody/Anonymous (nobody) Summary: Farm re-deployment doesn't work Initial Comment: We are seeing sporadic workings of the clustering/farming redeployment. If we drop a jar in the /farm of one node, it properly gets copied and deployed to other nodes in the same partition. If we drop a new version of the same .jar, it appears that other nodes get some sort of message, but the .jar is not actually copied and redeployed on the other nodes. If we delete a .jar out of the /farm dir of one node, it seems to properly undeploy and delete it out of other nodes as well. Not sure if this last item is a separate bug, but if you bring on a new node, nothing in the /farm dir of any other node seems to get farmed to the newly online node. That is to say, an empty node, one without the .jar in its /farm dir, seems to not get the .jar at all until you delete then drop the .jar in a farm dir again. I do not know if the above occurs if you reboot a node with the jar in the farm or not. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=767905group_id=22866 --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-767905 ] Farm re-deployment doesn't work
Bugs item #767905, was opened at 2003-07-08 10:00 Message generated for change (Settings changed) made by kevin-duffey You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=767905group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Duffey (kevin-duffey) Assigned to: Sacha Labourey (slaboure) Summary: Farm re-deployment doesn't work Initial Comment: We are seeing sporadic workings of the clustering/farming redeployment. If we drop a jar in the /farm of one node, it properly gets copied and deployed to other nodes in the same partition. If we drop a new version of the same .jar, it appears that other nodes get some sort of message, but the .jar is not actually copied and redeployed on the other nodes. If we delete a .jar out of the /farm dir of one node, it seems to properly undeploy and delete it out of other nodes as well. Not sure if this last item is a separate bug, but if you bring on a new node, nothing in the /farm dir of any other node seems to get farmed to the newly online node. That is to say, an empty node, one without the .jar in its /farm dir, seems to not get the .jar at all until you delete then drop the .jar in a farm dir again. I do not know if the above occurs if you reboot a node with the jar in the farm or not. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=767905group_id=22866 --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Ok, then I agree with adding the ejb-local-ref support. -- Scott Stark Chief Technology Officer JBoss Group, LLC Jeremy Boynes wrote: The spec makes the usage optional as well: The Application Assembler *can* use the ejb-link element in the deployment descriptor to link an EJB reference to a target enterprise bean. [EJB2.0 pp 418] Note the use of can not must And: *If* an EJB reference declaration includes the ejb-link element, the Deployer *should* bind the enterprise bean reference to the home of the enterprise bean specified as the link's target. [EJB2.0 pp 420] Again note If and should Finally: The Deployer must ensure that all the declared EJB references are bound to the homes of enterprise beans that exist in the operational environment. [EJB2.0 pp 420] So if the target is not there then it is a Deployment error. That seems a little restrictive if checked at deploy time because of boot order dependencies and redeployment, but if the target is not present when used then an error must be raised. Jeremy /* * Jeremy Boynes * Partner * Core Developers Network */ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] multiple deployment info entries for invoker.war
Theoretically, but a problem with not using the MainDeployer.shutdown is that the deployment shutdown order will change since the MainDeployer.removeDeployer method is not iterating over the deploymentList in reverse order as is the case for MainDeployer.shutdown. If this is corrected then the shutdown method and the ServerImpl*.shutdownDeployments method seem uneccessary and the MainDeployer.shutdown could call the ServiceController.shutdown. -- Scott Stark Chief Technology Officer JBoss Group, LLC Rod Burgett wrote: I see what you are saying about breaking the mirror, the removal of deployers should be controlled by the deployer services. Code already exists in ServerImpl.ShutdownHook.shutdown() to invoke ServiceController.shutdown(), which walks backwards through it's service list to stop, destroy and remove each. From what you say, this could handle undeploying everything. Currently, nothing actually gets undeployed at that point because MainDeployer.shutdown() gets called, and undeploys everything, before ServiceController.shutdown() is called. So, if service shutdown effectively handles undeployment, and preserves the mirror, is there really a need for MainDeployer to undeploy anything at shutdown? Can MainDeployer do all its housekeeping in destroyService()? Then what's left for shutdown() do? Except maybe ask the service controller to stop the deployer services? Rod Burgett Senior Software Engineer webMethods, Inc. 3930 Pender Drive Fairfax, VA 22030 USA Ph: 703.460.5819 (tty only) It's all just 0s 1s - the trick is getting them lined up in the proper order --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Job Failed to Complete Successfully
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === === [junit] Running org.jboss.test.jca.test.DeploymentUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.804 sec [junit] Running org.jboss.test.jca.test.JCA15AdapterUnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 8.901 sec [junit] Running org.jboss.test.jca.test.JDBCStatementTestsConnectionUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 12.189 sec [junit] Running org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase [junit] Tests run: 6, Failures: 0, Errors: 1, Time elapsed: 15.991 sec [junit] TEST org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase FAILED [junit] Running org.jboss.test.jca.test.MessageEndpointUnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 7.084 sec [junit] Running org.jboss.test.jca.test.ReentrantUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11.856 sec [junit] Running org.jboss.test.jca.test.UserTxUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 18.988 sec [junit] Running org.jboss.test.jca.test.WrapperSQLUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.516 sec [junit] Running org.jboss.test.jca.test.XAExceptionUnitTestCase [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 17.553 sec [junit] Running org.jboss.test.jca.test.XAResourceUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 0, Time elapsed: 0.814 sec [junit] Running org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 6.547 sec [junit] Running org.jboss.test.jmsra.test.RaQueueUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 3.966 sec [junit] TEST org.jboss.test.jmsra.test.RaQueueUnitTestCase FAILED [junit] Running org.jboss.test.jmsra.test.RaSyncRecUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 3.852 sec [junit] TEST org.jboss.test.jmsra.test.RaSyncRecUnitTestCase FAILED [junit] Running org.jboss.test.jmsra.test.RaTopicUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 3.738 sec [junit] TEST org.jboss.test.jmsra.test.RaTopicUnitTestCase FAILED [junit] Running org.jboss.test.jmx.test.CPManifestUnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 12.397 sec [junit] Running org.jboss.test.jmx.test.DeployConnectionManagerUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 15.127 sec [junit] TEST org.jboss.test.jmx.test.DeployConnectionManagerUnitTestCase FAILED [junit] Running org.jboss.test.jmx.test.DeployServiceUnitTestCase [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 13.205 sec [junit] Running org.jboss.test.jmx.test.DeployXMBeanUnitTestCase [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 6.813 sec [junit] Running org.jboss.test.jmx.test.EarDeploymentUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 14.195 sec [junit] Running org.jboss.test.jmx.test.EjbDependencyUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 10.372 sec [junit] Running org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 5.636 sec [junit] TEST org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase FAILED [junit] Running org.jboss.test.jmx.test.JavaBeanURIResolverUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.967 sec [junit] Running org.jboss.test.jmx.test.MBeanDependsOnConnectionManagerUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.858 sec [junit] Running org.jboss.test.jmx.test.MBeanDependsOnEJBUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6.111 sec [junit] Running org.jboss.test.jmx.test.MissingClassUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11.182 sec [junit] Running org.jboss.test.jmx.test.ServiceRsrcsUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.771 sec [junit] Running org.jboss.test.jmx.test.UndeployBrokenPackageUnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 21.256 sec [junit] Running org.jboss.test.jmx.test.UnpackedDeploymentUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 20.853 sec [junit] Running org.jboss.test.jrmp.test.CustomSocketsUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 12.285 sec
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Results: % ( / ) - fantastic
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === === head: /home/jbossci/jbossci/logtests/testresults/reports/text/TESTS-TestSuites.txt: No such file or directory ===Wed Jul 9 02:28:45 BST 2003 ===Linux nog 2.4.20-18.7 #1 Thu May 29 08:32:50 EDT 2003 i686 unknown ===java version 1.4.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02) Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode) --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
Hi guys, Over the past two weeks I have started to make a few improvements the current JBossMQ implementation that is in CVS HEAD. I would consider a large porting of what I did refactoring to simplify the current code base to allow future growth without having to sacrifice current features or performance. I just wanted to give provide an update on the development status of the original JBossMQ client-server JMS implementation. Here's a summary of what has changed: - It exclusively uses the remoting subsystem for client server communications. The existing IL subsystem has been removed. The 'async' remoting protocol allows two way communications solely over client sockets (this should allow applet/firewalled clients to connect to the server). Multiple JMS connections made by the client will also share a singe pool of sockets to communicate with the server. - Manually creating JBossMQ ConnectionFactory objects have been simplified since a remoting URI takes care setting up most of the connection options. - The server interceptors have been simplified since they now operate on a typeless invocations (it now matches the style of the other jboss interceptors) - The implementations for the p2p and pub/sub JMS API classes have been consolidated since that is the direction that the JMS 1.1 API is taking (being able to mix the us of p2p and pub/sub with in the same session). - Many (almost all) of the bug fixes/performance enhancements made in the 3.2 branch have been ported forward. - All the PMs except JDBC2 have been removed to make it easier to more quickly make enhancements to the persistence manager interface. I hope a cmp/jdo implementation can be created in the future. - the old org.jboss.mq.xml package that provided a simple xml dom was removed and all code that was using was changed to use dom4j instead. - JNDI Reference object handling was simplified (only StringRefs are used). - The sources were refactored so that the back-end messing server is much less coupled the javax.jms.* classes. The server side is still importing many of the JMSException classes, this can be cleaned up in the future. This might start to lead the way to allow this messaging server to support other messaging APIs (JavaSpaces?) Things to watch out for with this new version: - The jboss API to manually create ConnectionFactory and Destination objects has changed. Most users should not be affected since the JMS spec states that they should be using JNDI to get those objects. - Previous JBossMQ clients will not be able to connect to this new server version (since it is using remoting for communications). Those clients need to upgrade their jbossmq-client.jar. - The message format has changed so the new server will not be able to restore messages saved to persistence storage by the new server. I hope to commit the changes CVS in the next few days. I have 3 jms test cases that I still need to fix and then I still need to run the MDB test cases. Regards, Hiram -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
And what interaction has there been with Nathan who originally responded to the rewrite query? -- Scott Stark Chief Technology Officer JBoss Group, LLC Hiram Chirino wrote: Hi guys, Over the past two weeks I have started to make a few improvements the current JBossMQ implementation that is in CVS HEAD. I would consider a large porting of what I did refactoring to simplify the current code base to allow future growth without having to sacrifice current features or performance. I just wanted to give provide an update on the development status of the original JBossMQ client-server JMS implementation. Here's a summary of what has changed: - It exclusively uses the remoting subsystem for client server communications. The existing IL subsystem has been removed. The 'async' remoting protocol allows two way communications solely over client sockets (this should allow applet/firewalled clients to connect to the server). Multiple JMS connections made by the client will also share a singe pool of sockets to communicate with the server. - Manually creating JBossMQ ConnectionFactory objects have been simplified since a remoting URI takes care setting up most of the connection options. - The server interceptors have been simplified since they now operate on a typeless invocations (it now matches the style of the other jboss interceptors) - The implementations for the p2p and pub/sub JMS API classes have been consolidated since that is the direction that the JMS 1.1 API is taking (being able to mix the us of p2p and pub/sub with in the same session). - Many (almost all) of the bug fixes/performance enhancements made in the 3.2 branch have been ported forward. - All the PMs except JDBC2 have been removed to make it easier to more quickly make enhancements to the persistence manager interface. I hope a cmp/jdo implementation can be created in the future. - the old org.jboss.mq.xml package that provided a simple xml dom was removed and all code that was using was changed to use dom4j instead. - JNDI Reference object handling was simplified (only StringRefs are used). - The sources were refactored so that the back-end messing server is much less coupled the javax.jms.* classes. The server side is still importing many of the JMSException classes, this can be cleaned up in the future. This might start to lead the way to allow this messaging server to support other messaging APIs (JavaSpaces?) Things to watch out for with this new version: - The jboss API to manually create ConnectionFactory and Destination objects has changed. Most users should not be affected since the JMS spec states that they should be using JNDI to get those objects. - Previous JBossMQ clients will not be able to connect to this new server version (since it is using remoting for communications). Those clients need to upgrade their jbossmq-client.jar. - The message format has changed so the new server will not be able to restore messages saved to persistence storage by the new server. I hope to commit the changes CVS in the next few days. I have 3 jms test cases that I still need to fix and then I still need to run the MDB test cases. Regards, Hiram --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
Hiram, As you may know, we are going in a different direction with JMS than the original architecture coded by Norbert Lataille. We are doing a rewrite so patches to the old JBossMQ have a limited lifetime. That means that changes made to the old JBossMQ will most likely not be part of HEAD or the distribution as we move forward. Thanks, Nathan Phelps JMS Lead JBoss Group, L.L.C. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, July 08, 2003 8:41 PM To: [EMAIL PROTECTED] Subject: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite Hi guys, Over the past two weeks I have started to make a few improvements the current JBossMQ implementation that is in CVS HEAD. I would consider a large porting of what I did refactoring to simplify the current code base to allow future growth without having to sacrifice current features or performance. I just wanted to give provide an update on the development status of the original JBossMQ client-server JMS implementation. Here's a summary of what has changed: - It exclusively uses the remoting subsystem for client server communications. The existing IL subsystem has been removed. The 'async' remoting protocol allows two way communications solely over client sockets (this should allow applet/firewalled clients to connect to the server). Multiple JMS connections made by the client will also share a singe pool of sockets to communicate with the server. - Manually creating JBossMQ ConnectionFactory objects have been simplified since a remoting URI takes care setting up most of the connection options. - The server interceptors have been simplified since they now operate on a typeless invocations (it now matches the style of the other jboss interceptors) - The implementations for the p2p and pub/sub JMS API classes have been consolidated since that is the direction that the JMS 1.1 API is taking (being able to mix the us of p2p and pub/sub with in the same session). - Many (almost all) of the bug fixes/performance enhancements made in the 3.2 branch have been ported forward. - All the PMs except JDBC2 have been removed to make it easier to more quickly make enhancements to the persistence manager interface. I hope a cmp/jdo implementation can be created in the future. - the old org.jboss.mq.xml package that provided a simple xml dom was removed and all code that was using was changed to use dom4j instead. - JNDI Reference object handling was simplified (only StringRefs are used). - The sources were refactored so that the back-end messing server is much less coupled the javax.jms.* classes. The server side is still importing many of the JMSException classes, this can be cleaned up in the future. This might start to lead the way to allow this messaging server to support other messaging APIs (JavaSpaces?) Things to watch out for with this new version: - The jboss API to manually create ConnectionFactory and Destination objects has changed. Most users should not be affected since the JMS spec states that they should be using JNDI to get those objects. - Previous JBossMQ clients will not be able to connect to this new server version (since it is using remoting for communications). Those clients need to upgrade their jbossmq-client.jar. - The message format has changed so the new server will not be able to restore messages saved to persistence storage by the new server. I hope to commit the changes CVS in the next few days. I have 3 jms test cases that I still need to fix and then I still need to run the MDB test cases. Regards, Hiram -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
Scott, Why does it matter? Nathan has not expressed interested in growing from the current JMS implementation. I've been waiting for several months for the new general purpose implementation to 'appear' and it has not. So it's time for me to start the engine again and make some needed improvements to the current JBossMQ implementation. Nathan, Your doing great work in the peer based JMS arena. But have you formulated a game plan for the rewrite of general purpose implementation? Right now I'm going down the route of simplifying our current c/s implementation down enough so that we can start taking it apart more easily if required to add the needed features. On Tue, 2003-07-08 at 23:00, Scott M Stark wrote: And what interaction has there been with Nathan who originally responded to the rewrite query? -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
On Tue, 2003-07-08 at 23:41, Nathan Phelps wrote: In line... Hiram, As you may know, we are going in a different direction with JMS than the original architecture coded by Norbert Lataille. We are doing a rewrite I guess I had it good. Norbert made a good start. At least basic pub/sub worked. That's better than starting from scratch. so patches to the old JBossMQ have a limited lifetime. That means that changes made to the old JBossMQ will most likely not be part of HEAD or the distribution as we move forward. You may be right. or wrong. The current JMS will ship until there is a better replacement. Do you plan to replace the current implementation with the peer based implementation you have been working on? Regards, Hiram Thanks, Nathan Phelps JMS Lead JBoss Group, L.L.C. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, July 08, 2003 8:41 PM To: [EMAIL PROTECTED] Subject: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite Hi guys, Over the past two weeks I have started to make a few improvements the current JBossMQ implementation that is in CVS HEAD. I would consider a large porting of what I did refactoring to simplify the current code base to allow future growth without having to sacrifice current features or performance. I just wanted to give provide an update on the development status of the original JBossMQ client-server JMS implementation. Here's a summary of what has changed: - It exclusively uses the remoting subsystem for client server communications. The existing IL subsystem has been removed. The 'async' remoting protocol allows two way communications solely over client sockets (this should allow applet/firewalled clients to connect to the server). Multiple JMS connections made by the client will also share a singe pool of sockets to communicate with the server. - Manually creating JBossMQ ConnectionFactory objects have been simplified since a remoting URI takes care setting up most of the connection options. - The server interceptors have been simplified since they now operate on a typeless invocations (it now matches the style of the other jboss interceptors) - The implementations for the p2p and pub/sub JMS API classes have been consolidated since that is the direction that the JMS 1.1 API is taking (being able to mix the us of p2p and pub/sub with in the same session). - Many (almost all) of the bug fixes/performance enhancements made in the 3.2 branch have been ported forward. - All the PMs except JDBC2 have been removed to make it easier to more quickly make enhancements to the persistence manager interface. I hope a cmp/jdo implementation can be created in the future. - the old org.jboss.mq.xml package that provided a simple xml dom was removed and all code that was using was changed to use dom4j instead. - JNDI Reference object handling was simplified (only StringRefs are used). - The sources were refactored so that the back-end messing server is much less coupled the javax.jms.* classes. The server side is still importing many of the JMSException classes, this can be cleaned up in the future. This might start to lead the way to allow this messaging server to support other messaging APIs (JavaSpaces?) Things to watch out for with this new version: - The jboss API to manually create ConnectionFactory and Destination objects has changed. Most users should not be affected since the JMS spec states that they should be using JNDI to get those objects. - Previous JBossMQ clients will not be able to connect to this new server version (since it is using remoting for communications). Those clients need to upgrade their jbossmq-client.jar. - The message format has changed so the new server will not be able to restore messages saved to persistence storage by the new server. I hope to commit the changes CVS in the next few days. I have 3 jms test cases that I still need to fix and then I still need to run the MDB test cases. Regards, Hiram -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps
