[JBoss-dev] Fw: jbossha-httpsession.sar location
Why can't the httpsession clustering be conditional on the existence of the distributable web.xml tag so that the jbossha-httpsession.sar can be deployed as part of the all configuration? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Sent: Saturday, August 10, 2002 2:13 AM Subject: RE: jbossha-httpsession.sar location Yes. When you deploy cluster-service.xml in server/all/deploy, beans are not automatically clustered (you need to modify jboss.xml) which is good because people may get strange behaviour if they don't think properly about what they do. But things are different for jbossha-httpsession.sar: if you deploy it, all web-apps httpsessions are automatically clustered, without having to configure anything. this can also be dangerous (and lead to e-mails on jboss-dev) = it is in another place. BUT! I agree that it is not the best place we could imagine. If you think it is wrong, change it: you're the chief. Cheers, Sacha -Message d'origine- De : Scott M Stark [mailto:[EMAIL PROTECTED]] Envoyé : vendredi, 9 août 2002 22:46 À : Sacha Labourey Objet : jbossha-httpsession.sar location Is there a reason jbossha-httpsession.sar was placed into docs/examples/clustering instead of server/all/deploy? --- 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-2.4.8 bug fix release available
A JBoss-2.4.8 bug fix release has been made available. It can be downloaded from SourceForge here: http://sourceforge.net/project/showfiles.php?group_id=22866 The change notes can be found here: http://sourceforge.net/project/shownotes.php?release_id=104449 Scott Stark Chief Technology Officer JBoss Group, LLC --- 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-592346 ] Scoped ears with sars/ejbs fail for multiple versions
Bugs item #592346, was opened at 2002-08-07 15:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=592346group_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: Scoped ears with sars/ejbs fail for multiple versions Initial Comment: The org/jboss/test/cts/test/CtsCmp2UnitTestCase now includes a test of deploying two versions of an ear that contains an ejb and sar. The second sar sees a ClassCastException when it tries to lookup the ejb local home. 15:44:54,140 ERROR [CtsCmpService] Starting failed java.lang.ClassCastException: $Proxy29 at org.jboss.test.cts.service.CtsCmpService.startService (CtsCmpService.j ava:35) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 64) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.inv oke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invok e(ServiceControl ler.java:967) at $Proxy6.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:396) at org.jboss.system.ServiceController.start (ServiceController.java:416) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.inv oke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy26.start(Unknown Source) at org.jboss.ejb.EjbModule.startService (EjbModule.java:430) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 64) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.inv oke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invok e(ServiceControl ler.java:967) at $Proxy6.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:396) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.inv oke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy5.start(Unknown Source) at org.jboss.ejb.EJBDeployer.start (EJBDeployer.java:394) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:796) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:788) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:616) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:580) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.inv oke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner .deploy(URLDeploymen tScanner.java:427) at org.jboss.deployment.scanner.URLDeploymentScanner .scanDirectory(URLDe ploymentScanner.java:648) at org.jboss.deployment.scanner.URLDeploymentScanner .scan(URLDeploymentS canner.java:499) at org.jboss.deployment.scanner.AbstractDeploymentSca nner$ScannerThread. loop(AbstractDeploymentScanner.java:202) at org.jboss.deployment.scanner.AbstractDeploymentSca nner$ScannerThread. run(AbstractDeploymentScanner.java:191) -- Comment By: Scott M Stark (starksm) Date: 2002-08-10 09:06 Message: Logged In: YES user_id=175228 The JMX BasicMBeanRegistry was adding and removing MBeans that happen to be ClassLoaders to the default LoaderRepository instance. This would reset the repository of the class loader of the service MBean to a non-scoped version and undo the ear specified loader repository. This code has been removed from the BasicMBeanRegistry as its not its job to manage class loaders. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=592346group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___
Re: [JBoss-dev] BasicMBeanRegistry and class loader MBeans
Hi Scott, This is the specs/RIs mechanism for maintaining the LoaderRepository, although it is only implicitly mentioned in the javadoc for the DefaultLoaderRepository: Keeps the list of Class Loaders registered in the MBean Server. It provides the necessary methods to load classes using the registered Class Loaders. The unified repositories are externally managed and hierarchical, so this behaviour is conflicting. I see you have already removed this code. This probably breaks the MLet processing. But then I think it was already broken, MLets are URLClassLoaders not UCLs. I'll take a look at fixing this without breaking bug #592346 Regards, Adrian From: Scott M Stark [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [JBoss-dev] BasicMBeanRegistry and class loader MBeans Date: Fri, 9 Aug 2002 12:11:41 -0700 When one registers an MBean that is a ClassLoader the BasicMBeanRegistry adds it to the the default LoaderRepository. This breaks scoped class loading of services, and it really seems to be out of the scope of functionality that the BasicMBeanRegistry should assume. Really I don't see why the BasicMBeanRegistry should have any interaction with the LoaderRepository as all it is doing is adding and removing class loaders. Scott Stark Chief Technology Officer JBoss Group, LLC --- 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 _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx --- 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] BasicMBeanRegistry and class loader MBeans
Look at fixing it in head as there the BasicMBeanRegistry has been restored, but the default has been changed to JBossMBeanRegistry. The design of our JMX implementation class loading layer has to be geared toward JBoss functionality and requirements. Accommodating whatever is required by the JMX spec is necessary, but if one or the other requires a non-trivial configuration, it is the JMX spec behavior that should incur this burden, not the default JBoss behavior. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Adrian Brock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 10, 2002 11:44 AM Subject: Re: [JBoss-dev] BasicMBeanRegistry and class loader MBeans Hi Scott, This is the specs/RIs mechanism for maintaining the LoaderRepository, although it is only implicitly mentioned in the javadoc for the DefaultLoaderRepository: Keeps the list of Class Loaders registered in the MBean Server. It provides the necessary methods to load classes using the registered Class Loaders. The unified repositories are externally managed and hierarchical, so this behaviour is conflicting. I see you have already removed this code. This probably breaks the MLet processing. But then I think it was already broken, MLets are URLClassLoaders not UCLs. I'll take a look at fixing this without breaking bug #592346 Regards, Adrian From: Scott M Stark [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [JBoss-dev] BasicMBeanRegistry and class loader MBeans Date: Fri, 9 Aug 2002 12:11:41 -0700 When one registers an MBean that is a ClassLoader the BasicMBeanRegistry adds it to the the default LoaderRepository. This breaks scoped class loading of services, and it really seems to be out of the scope of functionality that the BasicMBeanRegistry should assume. Really I don't see why the BasicMBeanRegistry should have any interaction with the LoaderRepository as all it is doing is adding and removing class loaders. --- 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] BasicMBeanRegistry and class loader MBeans
On Sat, 10 Aug 2002, Scott M Stark wrote: This probably breaks the MLet processing. But then I think it was already broken, MLets are URLClassLoaders not UCLs. actually we detect ULR in the mlet code and register one UCL per URL in case ULR is used... -- Juha --- 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(Branch_3_0) Testsuite Results: 10-August-2002
Number of tests run: 897
Successful tests: 892
Errors:1
Failures: 4
[time of test: 10 August 2002 12:39 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
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] BasicMBeanRegistry and class loader MBeans
I agree we are beyond the spec here. Queue Marc's dance :-) I think we should still support MLets. I need to figure out a mechanism for registering URLClassLoaders in a Unified repository, probably some form of delegation. The rest is easy. We reserve add/removeClassLoader() for use by the MBeanServer/registry which noops for a UnifiedClassLoader. Then use add/removeUnifiedClassLoader() for the external management. Regards, Adrian From: Scott M Stark [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] BasicMBeanRegistry and class loader MBeans Date: Sat, 10 Aug 2002 12:22:25 -0700 Look at fixing it in head as there the BasicMBeanRegistry has been restored, but the default has been changed to JBossMBeanRegistry. The design of our JMX implementation class loading layer has to be geared toward JBoss functionality and requirements. Accommodating whatever is required by the JMX spec is necessary, but if one or the other requires a non-trivial configuration, it is the JMX spec behavior that should incur this burden, not the default JBoss behavior. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Adrian Brock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 10, 2002 11:44 AM Subject: Re: [JBoss-dev] BasicMBeanRegistry and class loader MBeans Hi Scott, This is the specs/RIs mechanism for maintaining the LoaderRepository, although it is only implicitly mentioned in the javadoc for the DefaultLoaderRepository: Keeps the list of Class Loaders registered in the MBean Server. It provides the necessary methods to load classes using the registered Class Loaders. The unified repositories are externally managed and hierarchical, so this behaviour is conflicting. I see you have already removed this code. This probably breaks the MLet processing. But then I think it was already broken, MLets are URLClassLoaders not UCLs. I'll take a look at fixing this without breaking bug #592346 Regards, Adrian From: Scott M Stark [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [JBoss-dev] BasicMBeanRegistry and class loader MBeans Date: Fri, 9 Aug 2002 12:11:41 -0700 When one registers an MBean that is a ClassLoader the BasicMBeanRegistry adds it to the the default LoaderRepository. This breaks scoped class loading of services, and it really seems to be out of the scope of functionality that the BasicMBeanRegistry should assume. Really I don't see why the BasicMBeanRegistry should have any interaction with the LoaderRepository as all it is doing is adding and removing class loaders. --- 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 _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com --- 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] BasicMBeanRegistry and class loader MBeans
Ok, But I'm seeing failures in the MLet tests (before Scotts modificaiton). I'll investigate... Regards, Adrian From: Juha-P Lindfors [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] BasicMBeanRegistry and class loader MBeans Date: Sat, 10 Aug 2002 22:28:56 +0300 (EET DST) On Sat, 10 Aug 2002, Scott M Stark wrote: This probably breaks the MLet processing. But then I think it was already broken, MLets are URLClassLoaders not UCLs. actually we detect ULR in the mlet code and register one UCL per URL in case ULR is used... -- Juha --- 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 _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com --- 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] BasicMBeanRegistry and class loader MBeans
The Mlet had not been converted to the UnifiedLoaderRepository2. Regards, Adrian From: Adrian Brock [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] BasicMBeanRegistry and class loader MBeans Date: Sat, 10 Aug 2002 21:16:06 +0100 Ok, But I'm seeing failures in the MLet tests (before Scotts modificaiton). I'll investigate... Regards, Adrian From: Juha-P Lindfors [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] BasicMBeanRegistry and class loader MBeans Date: Sat, 10 Aug 2002 22:28:56 +0300 (EET DST) On Sat, 10 Aug 2002, Scott M Stark wrote: This probably breaks the MLet processing. But then I think it was already broken, MLets are URLClassLoaders not UCLs. actually we detect ULR in the mlet code and register one UCL per URL in case ULR is used... -- Juha --- 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 _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com --- 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 _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx --- 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(HEAD Matrix2) Testsuite Results: 11-August-2002
Number of tests run: 906 Successful tests: 883 Errors:17 Failures: 6 [time of test: 11 August 2002 2:40 GMT] [java.version: 1.3.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_03-b03] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/sun_jdk131_03 for the junit report of this test. - http://lubega.com/testarchive/sun_jdk131_03/logs/ for the logs for this test. - http://lubega.com for general test information. 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
