[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 6-December-2002
JBoss daily test results SUMMARY Number of tests run: 1006 Successful tests: 995 Errors:10 Failures: 1 [time of test: 2002-12-06.12-41 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.2] See http://users.jboss.org/~starksm/Branch_3_0/2002-12-06.12-41 for details 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: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testHaInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.CommunicationException Message: Receive timed out - Suite: SimpleUnitTestCase Test:testHaParitionName(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.CommunicationException Message: Receive timed out - Suite: SimpleUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.security.auth.login.LoginException Message: Missing users.properties file. - Suite: SimpleUnitTestCase Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.AuthenticationException Message: Failed to login using protocol=testLoginInitialContext - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - Suite: RollBackUnitTestCase Test: testAsynchQueueReceiveBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: RollBackUnitTestCase Test: testAsynchTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: RollBackUnitTestCase Test: testAsynchDurableTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: CircularityUnitTestCase Test: testPackageProtected(org.jboss.test.classloader.test.CircularityUnitTestCase) Type:error Exception: javax.management.MBeanException Message: Exception in MBean operation 'testPackageProtected()' - --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(JBoss_3_2_0_beta2 WonderLand) Testsuite Results: 6-December-2002
JBoss daily test results SUMMARY Number of tests run: 1035 Successful tests: 1020 Errors:13 Failures: 2 [time of test: 2002-12-07.06-56 GMT] [java.version: 1.3.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_05-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2002-12-07.03-23 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: CircularityUnitTestCase Test: testPackageProtected(org.jboss.test.classloader.test.CircularityUnitTestCase) Type:error Exception: javax.management.MBeanException Message: Exception in MBean operation 'testPackageProtected()' - Suite: InvocationLayerStressTestCase Test: testOILMutliSessionOneConnection(org.jboss.test.jbossmq.perf.InvocationLayerStressTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: RollBackUnitTestCase Test: testAsynchQueueReceiveBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: RollBackUnitTestCase Test: testAsynchTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: RollBackUnitTestCase Test: testAsynchDurableTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: UnackedUnitTestCase Test:testUnackedTopic(org.jboss.test.jbossmq.test.UnackedUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: UnackedUnitTestCase Test:testUnackedDurableTopic(org.jboss.test.jbossmq.test.UnackedUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: XAExceptionUnitTestCase Test: testXAExceptionToTransactionRolledbackLocalExceptionOnServer(org.jboss.test.jca.test.XAExceptionUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Unexpected exception: javax.ejb.EJBException: null; CausedByException is: Unable to commit, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=lamia//11616, BranchQual=] status=STATUS_NO_TRANSACTION - Suite: DeployXMBeanUnitTestCase Test:testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/usr/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute "persistPolicy" with value "Never" must have a value from the list "NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER ".; - nested throwable: (javax.management.NotCompliantMBeanException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute "persistPolicy" with value "Never" must have a value from the list "NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER ".)) - Suite: JarInSarJSR77UnitTestCase Test: testFakeParentCreatedAndRemoved(org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: fakeApp jsr-77 mbean is still present - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/usr/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: JSR77SpecUnitTestCase Test
[JBoss-dev] Automated JBoss(JBoss_3_2_0_beta2 WonderLand) Testsuite Results: 6-December-2002
Number of tests run: 1035 Successful tests: 1020 Errors:13 Failures: 2 [time of test: 2002-12-07.03-23 GMT] [java.version: 1.3.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_05-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2002-12-07.03-23 for the junit report of this test. - http://users.jboss.org/~starksm/Branch_3_2/2002-12-07.03-23/logs/ for the logs for 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. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Interesting Deployment Ordering "Issue"
We actually don't recommend you run the auto deployer in production for this exact type of problem. If you want to hot redeploy or deploy something new, you can always do it manually using the console. If you want to run 24/7/365.25 it is the only way. -dain On Friday, December 6, 2002, at 07:01 PM, Peter Fagerlund wrote: If You aspire to run 24/7/365 it would become a problem in a "real" situation ... Yes - The idee is to be able to change any part of the running system with the "new" desired deploy configuration, at any time also the microkernel when phase'sing a tree phase restart JbossMC:ContainerComponents:Deployments. -- Now in a production scenario striving for 90+ % uptime ... You would typically use a hardware separate box to FW/LB in front to help today ... tomorrow You might just hot-swap any part for another at any time ... "Container wise" ... is/was a goal ... That could theoretically happen today in a clustered scenario ... --- We have just not tested it ... /peter_f lördagen den 7 december 2002 kl 00.25 skrev Hunter Hillegas: I'm happy to file a bug report if y'all actually see this as a bug... Should the deployment mechanism be able to sort out this kind of tampering and redeploy everything correctly? I mean, it would be quite nice but it seems like the case I presented isn't often to occur in any real situation... Hunter From: Peter Fagerlund <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Sat, 7 Dec 2002 00:03:44 +0100 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Interesting Deployment Ordering "Issue" Please file a bug report ! or else i have to ,-) ... yes i found some things not working when it comes to "internal components" redeploying since We tend to mostly focus on application (re)deploy ... a simple ex. run jb -> do a db/ds test -> redeploy db/ds - do a db test : will fail in my tests ... /peter_f fredagen den 6 december 2002 kl 19.47 skrev Hunter Hillegas: Not sure if this is really even an issue, since it sprang up from a very unnatural case... We're testing to find a problem with our app and Jetty... I'm hypothesizing that a script is "touch-ing" all the files under the JBoss tree... When I do a "touch *" under the deploy directory, total chaos ensues. I assume the wildcard orders by name, alpha... Well, this totally fscks everything as things undeploy and redeploy in that order. When the dust settles, basically nothing works. I'm not filing this as a bug since it probably is what you should expect if you are silly enough to do something like "touch *" in deploy... Kind of interesting though... Gotta go kick the guy that wrote the backup script that was doing that. hunter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Interesting Deployment Ordering "Issue"
If You aspire to run 24/7/365 it would become a problem in a "real" situation ... Yes - The idee is to be able to change any part of the running system with the "new" desired deploy configuration, at any time also the microkernel when phase'sing a tree phase restart JbossMC:ContainerComponents:Deployments. -- Now in a production scenario striving for 90+ % uptime ... You would typically use a hardware separate box to FW/LB in front to help today ... tomorrow You might just hot-swap any part for another at any time ... "Container wise" ... is/was a goal ... That could theoretically happen today in a clustered scenario ... --- We have just not tested it ... /peter_f lördagen den 7 december 2002 kl 00.25 skrev Hunter Hillegas: I'm happy to file a bug report if y'all actually see this as a bug... Should the deployment mechanism be able to sort out this kind of tampering and redeploy everything correctly? I mean, it would be quite nice but it seems like the case I presented isn't often to occur in any real situation... Hunter From: Peter Fagerlund <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Sat, 7 Dec 2002 00:03:44 +0100 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Interesting Deployment Ordering "Issue" Please file a bug report ! or else i have to ,-) ... yes i found some things not working when it comes to "internal components" redeploying since We tend to mostly focus on application (re)deploy ... a simple ex. run jb -> do a db/ds test -> redeploy db/ds - do a db test : will fail in my tests ... /peter_f fredagen den 6 december 2002 kl 19.47 skrev Hunter Hillegas: Not sure if this is really even an issue, since it sprang up from a very unnatural case... We're testing to find a problem with our app and Jetty... I'm hypothesizing that a script is "touch-ing" all the files under the JBoss tree... When I do a "touch *" under the deploy directory, total chaos ensues. I assume the wildcard orders by name, alpha... Well, this totally fscks everything as things undeploy and redeploy in that order. When the dust settles, basically nothing works. I'm not filing this as a bug since it probably is what you should expect if you are silly enough to do something like "touch *" in deploy... Kind of interesting though... Gotta go kick the guy that wrote the backup script that was doing that. hunter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Feature Requests-649860 ] Scheduler DateTime format
Feature Requests item #649860, was opened at 2002-12-07 02:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376688&aid=649860&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Rafal Piotrowski (sonofseven) Assigned to: Nobody/Anonymous (nobody) Summary: Scheduler DateTime format Initial Comment: It would be nice to be able to pass datetime format of the initial date argument to the scheduling mbean. This will simplify the "portability" of the mbean. In Windows 2000 (did not test it on Linux) Java takes as default the regional settings to specify the datetime format. This means that each server need to be configured in exactly the same way, which is not always the case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376688&aid=649860&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Interesting Deployment Ordering "Issue"
I'm happy to file a bug report if y'all actually see this as a bug... Should the deployment mechanism be able to sort out this kind of tampering and redeploy everything correctly? I mean, it would be quite nice but it seems like the case I presented isn't often to occur in any real situation... Hunter > From: Peter Fagerlund <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Sat, 7 Dec 2002 00:03:44 +0100 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Interesting Deployment Ordering "Issue" > > Please file a bug report ! or else i have to ,-) ... yes i found some > things not working when it comes to "internal components" redeploying > since We tend to mostly focus on application (re)deploy ... a simple > ex. run jb -> do a db/ds test -> redeploy db/ds - do a db test : will > fail in my tests ... > > /peter_f > > > fredagen den 6 december 2002 kl 19.47 skrev Hunter Hillegas: > >> Not sure if this is really even an issue, since it sprang up from a >> very >> unnatural case... >> >> We're testing to find a problem with our app and Jetty... I'm >> hypothesizing >> that a script is "touch-ing" all the files under the JBoss tree... >> >> When I do a "touch *" under the deploy directory, total chaos ensues. I >> assume the wildcard orders by name, alpha... Well, this totally fscks >> everything as things undeploy and redeploy in that order. When the dust >> settles, basically nothing works. >> >> I'm not filing this as a bug since it probably is what you should >> expect if >> you are silly enough to do something like "touch *" in deploy... Kind >> of >> interesting though... >> >> Gotta go kick the guy that wrote the backup script that was doing that. >> >> hunter >> >> >> >> --- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Interesting Deployment Ordering "Issue"
Please file a bug report ! or else i have to ,-) ... yes i found some things not working when it comes to "internal components" redeploying since We tend to mostly focus on application (re)deploy ... a simple ex. run jb -> do a db/ds test -> redeploy db/ds - do a db test : will fail in my tests ... /peter_f fredagen den 6 december 2002 kl 19.47 skrev Hunter Hillegas: Not sure if this is really even an issue, since it sprang up from a very unnatural case... We're testing to find a problem with our app and Jetty... I'm hypothesizing that a script is "touch-ing" all the files under the JBoss tree... When I do a "touch *" under the deploy directory, total chaos ensues. I assume the wildcard orders by name, alpha... Well, this totally fscks everything as things undeploy and redeploy in that order. When the dust settles, basically nothing works. I'm not filing this as a bug since it probably is what you should expect if you are silly enough to do something like "touch *" in deploy... Kind of interesting though... Gotta go kick the guy that wrote the backup script that was doing that. hunter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-575000 ] Can't disable call by reference
Bugs item #575000, was opened at 2002-06-28 02:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=575000&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: Can't disable call by reference Initial Comment: In the rearchitecting of the invokers we lost the ability to enforce call by value semantics for remote interface invocations. The container invoker Optimized config flag has no effect. -- >Comment By: Scott M Stark (starksm) Date: 2002-12-06 14:18 Message: Logged In: YES user_id=175228 Adrian created a marshall by value interceptor to deal with this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=575000&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-642250 ] CNFE Jdom
Bugs item #642250, was opened at 2002-11-22 04:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=642250&group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Phil Cornelius (smapjb) Assigned to: Scott M Stark (starksm) Summary: CNFE Jdom Initial Comment: I have submitted this ear following the thread on jboss-user included below. The submitted ear works on Jboss-3.0.2 but not on 3.0.4 3.0.4 should work, and does for the jbosstest-web.ear which I updated to include a servlet that accesses a class loaded from a jar referenced by an ejb-jar manifest Class-Path entry. If you have an ear that demonstrates the problem that you can submit to sourceforge open a bug and include the ear. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Phil Cornelius" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 2:35 AM Subject: Re: [JBoss-user] JBoss 3.0.4 w/ Jetty Classloader Attached. I have however solved this by adding a copy of the manifest that is in the ejb jar to the war file (details in thread). So the question I have now is should the servlets have been able to find the jdom classes in 3.0.2? Yours Phil On Fri, 2002-11-15 at 17:19, Scott M Stark wrote: > Show the complete stack trace of the CNFE coming from the servlet. The > indentation of the ear is not coming through in this mail well so run the > attached class on it and send that. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "Phil Cornelius" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, November 15, 2002 1:43 AM > Subject: RE: [JBoss-user] JBoss 3.0.4 w/ Jetty Classloader > > > > Actually now you mention it.. I noticed something too.. > > > > My app is structured thus: > > > > -myear.ear > > -lib/ > > jdom.jar > > junit.jar > > +blah.war > > -blah.jar > > -META-INF/ > > Manifest.mf > > +otherstuff > > +META-INF/ > > > > > > In the manifest of my ejb jar I have > > > > Manifest-Version:1.0 > > Class-Path: ./lib/jdom.jar ./lib/junit.jar > > > > Now in Jboss-3.0.2 everything works fine and my servlets can access the > > jdom classes.. > > > > However in Jboss-3.0.4 I get ClassNotFound org.jdom.Element thrown from > > my servlets. > > > > I had a sniff around.. currently I am happy that it works with 3.0.2.. > > > > Can anyone shed light on this? > > Is there anything that I need to set in my WAR file like a Manifest.mf? > > > > I want to keep my third party libs in one place and I don't want to > > clutter the Jboss dist. so I want to avoid putting a copy in WEB-INF/lib > > > > Yours > > Phil -- >Comment By: Scott M Stark (starksm) Date: 2002-12-06 14:16 Message: Logged In: YES user_id=175228 Ok, the problem was with jdom.jar including a suprious info.xml file in its META-INF directory. This ends up not matching any existing deployer and so the jar does not get deployed. Such jars now are deployed as simple library jars reguardless of what junk is in META-INF. -- Comment By: Phil Cornelius (smapjb) Date: 2002-11-28 02:21 Message: Logged In: YES user_id=559447 Have attached new ear which includes a jar with Classpath entry in manifest pointing to JDOM. Yours Phil -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 09:25 Message: Logged In: YES user_id=175228 Without an ejb jar with a manifest reference to lib/jdom.jar, jboss.jar is not loaded and the NoClassDefFoundError is expected. Add the ejb to complete the example. This should work because the unified loader repository includes the ejb classes and its referenced classes, and it the parent class loader of the web application. -- Comment By: Phil Cornelius (smapjb) Date: 2002-11-25 01:07 Message: Logged In: YES user_id=559447 JDK 1.4.1_01 on W2K. The exeption is thrown when the servlet is invoked.. http://localhost:8080/jdomtest/TestJDom I didn't include an EJB jar with manifest because I was able to reproduce the problem without. I am still unclear: why should it work? i.e. I am happy that I am required to add a classpath directive to the manifest of the war file.. so in a sense I am happy that it does not work in 3.0.4. -- Comment By: Scott M Stark (starksm) Date: 2002-11-23 18:44 Message: Logged In: YES user_id=175228 I have tried deploying the attached ear using both JDK 1.3.1_05 and JDK 1.4.1_01 with jboss-3.0.4 on a WinXP system and both work fin
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 6-December-2002
Number of tests run: 1006 Successful tests: 995 Errors:10 Failures: 1 [time of test: 2002-12-06.12-41 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.2] See http://users.jboss.org/~starksm/Branch_3_0/2002-12-06.12-41 for details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Interesting Deployment Ordering "Issue"
Not sure if this is really even an issue, since it sprang up from a very unnatural case... We're testing to find a problem with our app and Jetty... I'm hypothesizing that a script is "touch-ing" all the files under the JBoss tree... When I do a "touch *" under the deploy directory, total chaos ensues. I assume the wildcard orders by name, alpha... Well, this totally fscks everything as things undeploy and redeploy in that order. When the dust settles, basically nothing works. I'm not filing this as a bug since it probably is what you should expect if you are silly enough to do something like "touch *" in deploy... Kind of interesting though... Gotta go kick the guy that wrote the backup script that was doing that. hunter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Tyrex 2
Hi all, I have changed the tyrex code to solve the problem with the log4j version. The server was started with no problem but now we have problems with naming. I've tried debugging with println's and I've found that Tyrex doesn't find any JNDI name. I need to solve my problem ASAP and because of it I'm here to ask you a big favour!!! If anybody has a version of Tyrex that works well with JBoss 3.0.4, could you please send me? I'd be very grateful! Thank you very much in advance! -- Márcio Emílio Cruz Vono de Azevedo System Specialist Inatel Competence Center http://www.inatel.br --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback)
Hmm, so I am trying to do too many things in my login module. Or maybe I am a bit confused about what role an X509 Certificate really plays in this scenario. The certificate contains information about the principal (the DN) so it appears to perform both the role of principal and credential. Which is it really? Here are my thoughts on the process thus far.: 1) An incoming signed message (that has the required public key information embedded) is passed to the SigVerificationHandler who uses the embedded key information to verify the message. Actually I suppose it is possible that the key information would not be embedded in the message so this guy would have to use a key resolver to acquire the public key information from a keystore or keyserver of some sort. At any rate by the time SigVerificationHandler is finished with the message, we have the public key and the message has been validated. 2) The message is then passed to the SigAuthenticationHandler who's job it is to decide wether or not the key is to be trusted then perform the login. I Suppose this guy's job would be to find the key in a Truststore of some sort, then perform a login. The SigAuthenticationHandler, is where we should decide what or who our principal is prior to performing the login. When dealing with public key information, what is our principal? What is our credential? I kinda assumed the DN would be the principal and the Certificate the credential. (ya, I know that isn't what is currently happening in the code) 3) The message continues along the jboss.net execution path just like none of this weirdness ever happened. Is this really what should be happening to make signature authentication fit into the JBoss security model? Or am I making some very bad assumptions? Thanks for any input. -jason On Thursday, December 5, 2002, at 11:40 AM, Scott M Stark wrote: I don't remeber seeing my reply to this, so maybe a duplicate. The principal for the certificate should be passed in from the layer doing the validation. Login modules do not define the caller principal, they validate them. I need to understand the functions of the SigVerificationHandler and SigAuthenticationHandler in the overall context of a method invocation to really say how they map to JBossSX and whether additional security APIs are needed here. Adding the xmlsig stuff to thirdparty is fine. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Essington To: [EMAIL PROTECTED] Sent: Wednesday, November 27, 2002 2:50 PM Subject: Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback) On Wednesday, November 27, 2002, at 01:01 PM, Scott M Stark wrote: I updated the default CallbackHandler used by the JaasSecurityManager to support ObjectCallbacks and changed the SigAuthenticationHandler to use the isValid() method. Thanks Scott. The use of null as the principal indicates this is not really an authentication so I need to understand what the context of the validation is. Actually the certificate contains the information about the principal we are authenticating ( the CN portion of Distinguished Name for instance ). By the time the SigAuthenticationHandler sees the certificate, the SigVerificationHandler has already validated the certificate, and the messages signature. At this point we are just trying to decide if the certificate should be trusted. Maybe it would be better to not assume the certificate has already been validated? I haven't committed the SigVerificationHandler yet because it requires apache's XML-Security library to compile, and I am not sure if it is o.k. to just go adding things to thirdparty. If you just want to know if the cert should be accepted why not use the KeyStore associated with the security domain to see if the cert is know to the security domain and validate the cert as a X509Certificate? Explain the context some more and if there are cert management functions that should be part of the SecurityDomain interface I'll look into adding them. The CertificateLoginModule checks that the certificate exists (and is trusted) in the keystore. If so it creates a SimplePrincipal (using the certificate's alias as the name) that will be returned by the getIdentity() method. This is admittably a bit of a hack to map certificates to users in the system. I did this rather than using say the CN so that there would be a little bit of control over the user to whom this Certificate gets mapped. I could really use any ideas on a better way to accomplish this? Once the identity has been divined from the certificate, it's a simple matter for getRoleSets() to find the roles this user should assume. Let me know if my thought process is way off here. If it is, is there a better way to accomplish what I am attempting? thanks -jason
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE However, since no packages are imported, xjavadoc has assumed that the referred classes belong to the same package as the referring class. The classes are: org.jboss.mq.il.ServerILJMXService --> ServerILJMXServiceMBean qualified to ServerILJMXServiceMBean org.jboss.mq.il.jvm.JVMServerILService --> JVMServerILServiceMBean qualified to JVMServerILServiceMBean org.jboss.mq.il.oil.OILServerILService --> OILServerILServiceMBean qualified to OILServerILServiceMBean org.jboss.mq.il.oil2.OIL2ServerILService --> OIL2ServerILServiceMBean qualified to OIL2ServerILServiceMBean org.jboss.mq.il.rmi.RMIServerILService --> RMIServerILServiceMBean qualified to RMIServerILServiceMBean org.jboss.mq.il.trunk.TrunkServerILService --> TrunkServerILServiceMBean qualified to TrunkServerILServiceMBean org.jboss.mq.il.uil.UILServerILService --> UILServerILServiceMBean qualified to UILServerILServiceMBean org.jboss.mq.pm.file.CacheStore --> CacheStoreMBean qualified to CacheStoreMBean org.jboss.mq.pm.file.PersistenceManager --> PersistenceManagerMBean qualified to PersistenceManagerMBean org.jboss.mq.server.jmx.DelayInterceptor --> DelayInterceptorMBean qualified to DelayInterceptorMBean org.jboss.mq.server.jmx.DestinationManager --> DestinationManagerMBean qualified to DestinationManagerMBean org.jboss.mq.server.jmx.InterceptorLoader --> InterceptorLoaderMBean qualified to InterceptorLoaderMBean org.jboss.mq.server.jmx.Invoker --> InvokerMBean qualified to InvokerMBean org.jboss.mq.server.jmx.Queue --> QueueMBean qualified to QueueMBean org.jboss.mq.server.jmx.Topic --> TopicMBean qualified to TopicMBean org.jboss.mq.sm.file.DynamicStateManager --> DynamicStateManagerMBean qualified to DynamicStateManagerMBean org.jboss.mq.sm.file.DynamicStateManager --> DurableSubscription qualified to DurableSubscription org.jboss.mq.sm.file.OldStateManager --> OldStateManagerMBean qualified to OldStateManagerMBean compile-parsers: [mkdir] Created dir: /home/jboss/jbossci/jboss-all/messaging/output/gen/classes/org/jboss/mq/selectors [javacc] Java Compiler Compiler Version 2.0 (Parser Generator) [javacc] Copyright (c) 1996-2000 Sun Microsystems, Inc. [javacc] Copyright (c) 1997-2000 Metamata, Inc. [javacc] (type "javacc" with no arguments for help) [javacc] Reading from file /home/jboss/jbossci/jboss-all/messaging/src/main/org/jboss/mq/selectors/SelectorParser.jj . . . [javacc] Warning: Lookahead adequacy checking not being performed since option LOOKAHEAD is more than 1. Set option FORCE_LA_CHECK to true to force checking. [javacc] File "TokenMgrError.java" does not exist. Will create one. [javacc] File "ParseException.java" does not exist. Will create one. [javacc] File "Token.java" does not exist. Will create one. [javacc] File "ASCII_CharStream.java" does not exist. Will create one. [javacc] Parser generated with 0 errors and 1 warnings. _default:compile-classes: [mkdir] Created dir: /home/jboss/jbossci/jboss-all/messaging/output/classes [depend] Deleted 0 out of date files in 0 seconds [javac] Compiling 188 source files to /home/jboss/jbossci/jboss-all/messaging/output/classes /home/jboss/jbossci/jboss-all/messaging/src/main/org/jboss/mq/il/uil/UILServerILService.java:444: cannot resolve symbol symbol : method isBound () location: class java.net.ServerSocket if( serverSocket != null && serverSocket.isBound() ) ^ 1 error BUILD FAILED file:/home/jboss/jbossci/jboss-all/messaging/../tools/etc/buildfragments/targets.ent:45: Compile failed; see the compiler error output for details. Total time: 1 minute 50 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE However, since no packages are imported, xjavadoc has assumed that the referred classes belong to the same package as the referring class. The classes are: org.jboss.mq.il.ServerILJMXService --> ServerILJMXServiceMBean qualified to ServerILJMXServiceMBean org.jboss.mq.il.jvm.JVMServerILService --> JVMServerILServiceMBean qualified to JVMServerILServiceMBean org.jboss.mq.il.oil.OILServerILService --> OILServerILServiceMBean qualified to OILServerILServiceMBean org.jboss.mq.il.oil2.OIL2ServerILService --> OIL2ServerILServiceMBean qualified to OIL2ServerILServiceMBean org.jboss.mq.il.rmi.RMIServerILService --> RMIServerILServiceMBean qualified to RMIServerILServiceMBean org.jboss.mq.il.trunk.TrunkServerILService --> TrunkServerILServiceMBean qualified to TrunkServerILServiceMBean org.jboss.mq.il.uil.UILServerILService --> UILServerILServiceMBean qualified to UILServerILServiceMBean org.jboss.mq.pm.file.CacheStore --> CacheStoreMBean qualified to CacheStoreMBean org.jboss.mq.pm.file.PersistenceManager --> PersistenceManagerMBean qualified to PersistenceManagerMBean org.jboss.mq.server.jmx.DelayInterceptor --> DelayInterceptorMBean qualified to DelayInterceptorMBean org.jboss.mq.server.jmx.DestinationManager --> DestinationManagerMBean qualified to DestinationManagerMBean org.jboss.mq.server.jmx.InterceptorLoader --> InterceptorLoaderMBean qualified to InterceptorLoaderMBean org.jboss.mq.server.jmx.Invoker --> InvokerMBean qualified to InvokerMBean org.jboss.mq.server.jmx.Queue --> QueueMBean qualified to QueueMBean org.jboss.mq.server.jmx.Topic --> TopicMBean qualified to TopicMBean org.jboss.mq.sm.file.DynamicStateManager --> DynamicStateManagerMBean qualified to DynamicStateManagerMBean org.jboss.mq.sm.file.DynamicStateManager --> DurableSubscription qualified to DurableSubscription org.jboss.mq.sm.file.OldStateManager --> OldStateManagerMBean qualified to OldStateManagerMBean compile-parsers: [mkdir] Created dir: /home/jboss/jbossci/jboss-all/messaging/output/gen/classes/org/jboss/mq/selectors [javacc] Java Compiler Compiler Version 2.0 (Parser Generator) [javacc] Copyright (c) 1996-2000 Sun Microsystems, Inc. [javacc] Copyright (c) 1997-2000 Metamata, Inc. [javacc] (type "javacc" with no arguments for help) [javacc] Reading from file /home/jboss/jbossci/jboss-all/messaging/src/main/org/jboss/mq/selectors/SelectorParser.jj . . . [javacc] Warning: Lookahead adequacy checking not being performed since option LOOKAHEAD is more than 1. Set option FORCE_LA_CHECK to true to force checking. [javacc] File "TokenMgrError.java" does not exist. Will create one. [javacc] File "ParseException.java" does not exist. Will create one. [javacc] File "Token.java" does not exist. Will create one. [javacc] File "ASCII_CharStream.java" does not exist. Will create one. [javacc] Parser generated with 0 errors and 1 warnings. _default:compile-classes: [mkdir] Created dir: /home/jboss/jbossci/jboss-all/messaging/output/classes [depend] Deleted 0 out of date files in 0 seconds [javac] Compiling 188 source files to /home/jboss/jbossci/jboss-all/messaging/output/classes /home/jboss/jbossci/jboss-all/messaging/src/main/org/jboss/mq/il/uil/UILServerILService.java:444: cannot resolve symbol symbol : method isBound () location: class java.net.ServerSocket if( serverSocket != null && serverSocket.isBound() ) ^ 1 error BUILD FAILED file:/home/jboss/jbossci/jboss-all/messaging/../tools/etc/buildfragments/targets.ent:45: Compile failed; see the compiler error output for details. Total time: 1 minute 53 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-648111 ] UIL IL does not unbind socket in stop
Bugs item #648111, was opened at 2002-12-04 00:24
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=648111&group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Anatoly Akkerman (azakkerman)
>Assigned to: Christian Riege (lqd)
Summary: UIL IL does not unbind socket in stop
Initial Comment:
This bug was detected on jdk 1.4.1, Win2k, JBoss 3.0.(3|4)
After stopping UIL service and restarting it again ( I
was actually removing the jbossmq-service.xml and
adding it back into deploy) UIL IL MBean throws an
exception that the socket cannot be bound to the
specified address another socket is already bound to it.
Funny, I would have thought that once the UIL MBean is
garbage collected (since I am removing and adding
jbossmq-service.xml I expect that to happen), then the
socket should be GCed and closed, aparently this does
not happen.
The fix is simple, in
org/jboss/mq/il/uil/UILServerILService.java
modify stopService() so it closes the server socket:
public void stopService()
{
try
{
running = false;
unbindJNDIReferences();
// unbind the serverSocket if needed
if (serverSocket != null &&
serverSocket.isBound()) {
serverSocket.close();
}
}
catch (Exception e)
{
e.printStackTrace();
}
}
--
>Comment By: Christian Riege (lqd)
Date: 2002-12-06 10:20
Message:
Logged In: YES
user_id=176671
looks good, will apply your fix. thanks!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=648111&group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-602665 ] Hot Re-Deploy Fails
Bugs item #602665, was opened at 2002-08-31 00:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=602665&group_id=22866 Category: JBossServer Group: None >Status: Deleted Resolution: Invalid Priority: 5 Submitted By: Dorothy Gantenbein (dgantenbein) Assigned to: Nobody/Anonymous (nobody) Summary: Hot Re-Deploy Fails Initial Comment: Hi - This happens with JBoss 3.0.1 and JBoss 3.0.2. My ear contains a sar file. When I deploy this ear for the first time, everything works great. I can hot deploy the ear or have the ear deployed before starting JBoss. Also, the ear successfully undeploys. However all re-deploys of the ear fail with a class loader error [java] org.jboss.deployment.DeploymentException interface org.jboss.system.Service is not visible from class loader; - nested throwable: (java.lang.Illega lArgumentException: interface org.jboss.system.Service is not visible from class loader) [java] at org.jboss.deployment.SARDeployer.create (SARDeployer.java:227) [java] at org.jboss.deployment.MainDeployer.create MainDeployer.java:749) [java] at org.jboss.deployment.MainDeployer.create (MainDeployer.java:741) [java] at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:615) [java] at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:580) [java] at sun.reflect.GeneratedMethodAccessor10.invoke (Unknown Source) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) [java] at java.lang.reflect.Method.invoke(Method.java:324) [java] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) [java] at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) [java] at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) [java] at $Proxy4.deploy(Unknown Source) [java] at org.jboss.deployment.scanner.URLDeploymentScanner. deploy(URLD eploymentScanner.java:427) [java] at org.jboss.deployment.scanner.URLDeploymentScanner. scan(URLDeploymentScanner.java:553) [java] at org.jboss.deployment.scanner.AbstractDeploymentScan ner$ScannerThread.loop (AbstractDeploymentScanner.java:202) [java] at org.jboss.deployment.scanner.AbstractDeploymentScan ner$ScannerThread.run (AbstractDeploymentScanner.java:191) [java] Caused by: java.lang.IllegalArgumentException: interface org.jboss.s ystem.Service is not visible from class loader [java] at java.lang.reflect.Proxy.getProxyClass (Proxy.java:331) [java] at java.lang.reflect.Proxy.newProxyInstance (Proxy.java:552) [java] at org.jboss.system.ServiceController.getServiceProxy (ServiceController.java:740) [java] at org.jboss.system.ServiceController.create (ServiceController.java:276) [java] at org.jboss.system.ServiceController.create (ServiceController.java:242) [java] at sun.reflect.GeneratedMethodAccessor4.invoke (Unknown Source) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) [java] at java.lang.reflect.Method.invoke(Method.java:324) [java] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) [java] at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) [java] at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) [java] at $Proxy3.create(Unknown Source) [java] at org.jboss.deployment.SARDeployer.create (SARDeployer.java:217) [java] ... 15 more Please feel free to contact me if you need more info. Dorothy [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=602665&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
