RE: [JBoss-dev] pluggable tx retry handlers
Ok, will do once Alexey has his code in. Scott Stark Chief Technology Officer JBoss Group, LLC From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Wed 1/7/2004 3:37 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] pluggable tx retry handlers Well, I'll put it in 4.0 and you can pull it out whenever a new metamodel is created. -- Bill Burke Chief Architect JBoss Group LLC. <>
[JBoss-dev] SNMP alert notifications
It makes sense to plug in SNMP to the alert monitoring I did. Does anybody know how I can go about this? I saw some stuff in the SNMP adapter about converting JMX NOtifications into SNMP messages. Can somebody look into creating an SNMP listener for my alert monitoring stuff or give me pointers (links, urls) on how to create an SNMP message sent through our SNMP adaptor? Thanks, Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Tx retry pluggability committed
You can now plug in retry handlers that are able to retry transactions based on an exception. This is useful for Oracle deadlock SQLExceptions and also MySQL cluster failure exceptions that can be retried. It is configured on a per container configuration basis. You expand on the declaration of the TxInterceptorCMT XML definition org.jboss.ejb.plugins.TxInterceptorCMT org.mysql.SomeExceptionHandler The handler class must implement org.jboss.ejb.plugins.TxRetryExceptionHandler which has one method boolean retry(Exception ex) -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] xml configuration server interceptors
added ability to be able to define server interceptors as org.jboss.metadata.XmlLoadable so that you can define extra child XML elements within the XML definition in a server configuration -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] pluggable tx retry handlers
Well, I'll put it in 4.0 and you can pull it out whenever a new metamodel is created. Scott M Stark wrote: That's ok with me for now, but its yet another expansion of the xml parser usage into a context it does not belong. We should not be doing this in 4.0. Scott Stark Chief Technology Officer JBoss Group, LLC From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Wed 1/7/2004 2:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] pluggable tx retry handlers Scott M Stark wrote: > This is really not a container level configuration, rather its > configuration info for > the tx interceptor, but we don't support that capability well. I just added support to allow you to define an interceptor as XmlLoadable (haven't committed) this is how I did the tx retry stuff. The mbean > approach > with an attribute on the tx interceptor that references the mbean > approximates > this. There has to be some pluggibility as I doubt every deployed > application > wants the same retry logic. > Ok, then I can keep it as I've implemented it though. You would do org.jboss.ejb.plugins.TxInterceptorCMT com.stuff.myhandler Bill -- Bill Burke Chief Architect JBoss Group LLC. -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] pluggable tx retry handlers
That's ok with me for now, but its yet another expansion of the xml parser usage into a context it does not belong. We should not be doing this in 4.0. Scott Stark Chief Technology Officer JBoss Group, LLC From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Wed 1/7/2004 2:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] pluggable tx retry handlers Scott M Stark wrote: > This is really not a container level configuration, rather its > configuration info for > the tx interceptor, but we don't support that capability well. I just added support to allow you to define an interceptor as XmlLoadable (haven't committed) this is how I did the tx retry stuff. The mbean > approach > with an attribute on the tx interceptor that references the mbean > approximates > this. There has to be some pluggibility as I doubt every deployed > application > wants the same retry logic. > Ok, then I can keep it as I've implemented it though. You would do org.jboss.ejb.plugins.TxInterceptorCMT com.stuff.myhandler Bill -- Bill Burke Chief Architect JBoss Group LLC. <>
Re: [JBoss-dev] pluggable tx retry handlers
Scott M Stark wrote: This is really not a container level configuration, rather its configuration info for the tx interceptor, but we don't support that capability well. I just added support to allow you to define an interceptor as XmlLoadable (haven't committed) this is how I did the tx retry stuff. The mbean approach with an attribute on the tx interceptor that references the mbean approximates this. There has to be some pluggibility as I doubt every deployed application wants the same retry logic. Ok, then I can keep it as I've implemented it though. You would do org.jboss.ejb.plugins.TxInterceptorCMT com.stuff.myhandler Bill Scott Stark Chief Technology Officer JBoss Group, LLC From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Wed 1/7/2004 1:58 PM To: Jboss-Dev Subject: [JBoss-dev] pluggable tx retry handlers I'm currently writing pluggable TX retry handlers so that you can configure JBoss to automatically retry transactions for other exceptions other than ApplicationDeadlockException i.e. Oracle deadlock, MySQL cluster failure, etc. The question is, should this be pluggable per entity container and thus have to define the handlers per container? This is what I have implemented currently and thought that it might be overally complicated as you would have to define it for every container. The other approach would be to just define this thing for the entire app server in an MBean. Thoughts? Thanks Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] pluggable tx retry handlers
No, but it should. On Wed, 7 Jan 2004, Bill Burke wrote: > Sorry, not per entity container, per container. > > standardjboss.xml doesn't have does it? > > Bill > > Juha Lindfors wrote: > > > On Wed, 7 Jan 2004, Bill Burke wrote: > > > >>The question is, should this be pluggable per entity container and thus > >>have to define the handlers per container? > > > > > > Why is this specific to entities? Per container-config and add a > > element to standardjboss.xml (like std-jbosscmp) that is used > > for all configs unless explicitly overridden. > > > > -- Juha > > > > > > > > > > --- > > This SF.net email is sponsored by: Perforce Software. > > Perforce is the Fast Software Configuration Management System offering > > advanced branching capabilities and atomic changes on 50+ platforms. > > Free Eval! http://www.perforce.com/perforce/loadprog.html > > ___ > > JBoss-Development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > -- > > Bill Burke > Chief Architect > JBoss Group LLC. > > > > > > --- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] pluggable tx retry handlers
Sorry, not per entity container, per container. standardjboss.xml doesn't have does it? Bill Juha Lindfors wrote: On Wed, 7 Jan 2004, Bill Burke wrote: The question is, should this be pluggable per entity container and thus have to define the handlers per container? Why is this specific to entities? Per container-config and add a element to standardjboss.xml (like std-jbosscmp) that is used for all configs unless explicitly overridden. -- Juha --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] pluggable tx retry handlers
This is really not a container level configuration, rather its configuration info for the tx interceptor, but we don't support that capability well. The mbean approach with an attribute on the tx interceptor that references the mbean approximates this. There has to be some pluggibility as I doubt every deployed application wants the same retry logic. Scott Stark Chief Technology Officer JBoss Group, LLC From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Wed 1/7/2004 1:58 PM To: Jboss-Dev Subject: [JBoss-dev] pluggable tx retry handlers I'm currently writing pluggable TX retry handlers so that you can configure JBoss to automatically retry transactions for other exceptions other than ApplicationDeadlockException i.e. Oracle deadlock, MySQL cluster failure, etc. The question is, should this be pluggable per entity container and thus have to define the handlers per container? This is what I have implemented currently and thought that it might be overally complicated as you would have to define it for every container. The other approach would be to just define this thing for the entire app server in an MBean. Thoughts? Thanks Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development <>
Re: [JBoss-dev] pluggable tx retry handlers
On Wed, 7 Jan 2004, Bill Burke wrote: > The question is, should this be pluggable per entity container and thus > have to define the handlers per container? Why is this specific to entities? Per container-config and add a element to standardjboss.xml (like std-jbosscmp) that is used for all configs unless explicitly overridden. -- Juha --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] pluggable tx retry handlers
I'm currently writing pluggable TX retry handlers so that you can configure JBoss to automatically retry transactions for other exceptions other than ApplicationDeadlockException i.e. Oracle deadlock, MySQL cluster failure, etc. The question is, should this be pluggable per entity container and thus have to define the handlers per container? This is what I have implemented currently and thought that it might be overally complicated as you would have to define it for every container. The other approach would be to just define this thing for the entire app server in an MBean. Thoughts? Thanks Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Web integration (clustering) updates
Tom Elrod wrote: So is this still an issue? If so, how do I reproduce (will look at it tonight)? The value of looking into this is that it could possibly be a regression. Otherwise, the workaround is good enough :) - Use the TC 5 SAR instead of the TC 4.1 SAR - In the server.xml of the SAR, replace by (that way, Tomcat will do a Class.forName during its shutdown, but before AbstractWebContainer.stopService is called) Rémy -- x Rémy Maucherat Senior Developer & Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Web integration (clustering) updates
So is this still an issue? If so, how do I reproduce (will look at it tonight)? Scott M Stark wrote: So with the current 3.2 branch code what do I do to produce the class loader problem? Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Remy Maucherat Sent: Wednesday, January 07, 2004 8:39 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Web integration (clustering) updates Scott M Stark wrote: The class loading is the same, the bigger recent change was a refactoring No, your refactoring didn't break anything, as I did test it earlier. of the embedded web service into the web container service and a deployer. I would this is the source of the behavior change. What use case produces the problem so I can look at it? For a variety of reasons, I needed to get a new class on shutdown of the service (a webapp deployer, to shutdown all the webapps). This is mostly to be consistent with Tomcat standalone, and it would actually be useful if using external contexts. So to fix it, I changed the setting so that a (useless) Host deployer would be created on startup: - + -- x Rémy Maucherat Senior Developer & Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] WINNING NOTIFICATION
PLATINIUM INTERNATIONAL LOTTERY.THE NEDERLANDS
FROM:THE DESK OF THE PRESIDENT
PLATINIUM INTERNATIONAL LOTTERY/PRIZE AWARD DEPT
Ref. Number:HFR/55217/CRZ
Batch Number:88/55312/997JH
ATTENTION.
Sir/ Ma/ Miss,
We are pleased to inform you of the result of the
winners of the Platinium International Lottery
programs held on the 30th DECEMBER,2003.Your e-mail
address attached to ticket number 768---9084217--776
with serial number 1143--22 drew lucky numbers 9-7
2-55-69-44-88 which consequently won in the
category A.You have therefore been approved for a lump
sum pay of US $1.200,000.00(one million two hundred
thousand United States Dollars)in cash credited to
file Ref. Number:HFR/55217/CRZ.This is from a total
cash prize of US $16.800,000.00usd
international winners in this category.
CONGRATULATIONS!!!
Due to mix up of some numbers and names we ask that
you keep your winning information confidential until
your claims has been processed and your money remitted
to you.This is part of our security protocol to avoid
double claiming and unwarranted abuse of this program
by some participants.
All participants were selected through a computer
ballot system drawn from over 20,000 company and
30,000,000 individual email addresses and names from
all over the world.This promotional program takes
place every three years in different developed
countries,the lottery was promoted and sponsored by the president of the world largest
softwares
to increase the awareness of microsoft software
packages.We hope with part of your winning you will
take part in our next USD 40 million
international lottery.
To file for your claim please contact our financial
agent NESTER MICHEAL, Foreign Operations Manager of the
Prudent Trust Security Services Holland{netherlands}with a
photocopy of your ID for age verification,
telephone and fax numbers.8.00 am to18.00 gmt
TEL:+31-612-932-685
FAX:+31-645-234-412
Email:[EMAIL PROTECTED]
Remember all winning must be claimed not later than
15 th JANUARY, 2004. After this date all unclaimed
funds will be included in the next stake. Please note
in order to avoid unnecessary delays and complications
please remember to quote your reference number and
batch numbers in all correspondence. Furthermore,
should there be any change of address do inform our
agent as soon as possible.
Congratulations once more
and thank you for being part of our promotional
program.
Note:Anybody under the age of 18 is automatically
disqualified.
Sincerely yours,
KARYN van KIFF
[JBoss-dev] Is JBossAopXDocletTestCase in head expected to fail
I'm taking a snapshot of the aop unit tests in head before migrating the 3.2 changes to the Transator/Translatable to head and I see the JBossAopXDocletTestCase is failing. Is this expected currently? [EMAIL PROTECTED] testsuite]$ ant -Dtest=aop junit_opts="-Djunit.timeout=180 -Dnojars=t" test [mkdir] Created dir: /cvs/JBossHead/jboss-head/testsuite/output/reports [junit] Running org.jboss.test.aop.test.AOPUnitTestCase [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 38.791 sec [junit] Running org.jboss.test.aop.test.RemotingUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 37.438 sec [junit] Running org.jboss.test.aop.test.SecurityUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 39.013 sec [junit] Running org.jboss.test.aop.test.SimpleBeanUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.02 sec [junit] Running org.jboss.test.aop.test.TxLockUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 42.033 sec [junit] Running org.jboss.test.aop.test.TxUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 40.211 sec [junit] Running org.jboss.test.aop.test.VersionedObjectUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 38.946 sec [junit] Running org.jboss.test.aop.xdoclet.JBossAopXDocletTestCase [junit] Tests run: 10, Failures: 0, Errors: 9, Time elapsed: 0.137 sec [junit] TEST org.jboss.test.aop.xdoclet.JBossAopXDocletTestCase FAILED Scott StarkChief Technology OfficerJBoss Group, LLC
RE: [JBoss-dev] Moving out the core hard-coded serviceconfiguration
One is a composite mbean service definition/dependency and configuration defaults file, the other a specific implementation of a ModelMBean metadata store. They have some overlap, but are largely completely seperate things. Scott Stark Chief Technology Officer JBoss Group, LLC From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Wed 1/7/2004 11:06 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Moving out the core hard-coded serviceconfiguration Why do we have a separate -service.xml file and XMBean configuration file anyways? They're both proprietary. Just asking Bill -- Bill Burke Chief Architect JBoss Group LLC. <>
[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 7-January-2004
Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 7-January-2004 JBoss daily test results SUMMARY Number of tests run: 1644 Successful tests: 1625 Errors:8 Failures: 11 [time of test: 2004-01-07.18-38 GMT] [java.version: 1.4.2_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.2_03-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-9smp] Useful resources: - http://jboss.sourceforge.net//junit-results/32/2004-01-07.18-38 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: org.jboss.test.cache.test.local.ConcurrentUnitTestCase Test:testConcurrentAccessWithRWLock Type:failure Exception: junit.framework.AssertionFailedError Message: expected:<1001> but was:<1000> - Suite: org.jboss.test.cache.test.local.TxConcurrentUnitTestCase Test:testConcurrentAccess Type:failure Exception: junit.framework.AssertionFailedError Message: expected:<768> but was:<1000> - Suite: org.jboss.test.cts.test.StatefulSessionUnitTestCase Test:testStrictPooling Type:failure Exception: junit.framework.AssertionFailedError Message: SessionInvoker.runEx != null - Suite: org.jboss.test.exception.EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionInTxMarkRollback_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: org.jboss.test.exception.EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: org.jboss.test.exception.EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionInTxMarkRollback_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: org.jboss.test.exception.EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: org.jboss.test.jmx.test.DeployXMBeanUnitTestCase Test:testUserXMBeanPersistentValues Type:failure Exception: junit.framework.AssertionFailedError Message: value == UpdatedAttr1Value, value=Att1InitialValue - Suite: org.jboss.test.naming.test.SimpleUnitTestCase Test:testNameChanges Type:failure Exception: junit.framework.AssertionFailedError Message: name.equals(copy), name=jmx - Suite: org.jboss.test.webservice.external.ExternalUnitTestCase Test:testFederated Type:error Exception: org.apache.axis.AxisFault Message: Our connection to the Altavista BabelFish site has been cut. This service will remain down indefinitely until an alternate translation engine can be found. We apologize for any inconvenience. - Suite: org.jboss.test.naming.test.SecurityUnitTestCase Test:testSecureHttpInvoker Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: org.jboss.test.security.test.HttpsUnitTestCase Test:testHttpsURL Type:error Exception: java.io.IOException Message: Failed to readURL, ex=null - Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFail Type:failure Exception: junit.framework.AssertionFailedError Message: Unexpected exception - Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFailReentrant Type:failure Exception: junit.framework.AssertionFailedError Message: Unexpected exception - Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFailNotSupportedReent
Re: [JBoss-dev] Moving out the core hard-coded serviceconfiguration
Why do we have a separate -service.xml file and XMBean configuration file anyways? They're both proprietary. Just asking Bill Scott M Stark wrote: I don't see a chicken/egg problem for the JBoss services which is what I want to address now. Trying to do the same for the embedded JMX services is a second step. I was just thinking of using a system property to specify the xmbean resource location in the same manner in which the conf/jboss-service.xml descriptor is used, and would default to a conf/xmbeans directory (the current conf/xmdesc would be renamed). Scott Stark Chief Technology Officer JBoss Group, LLC From: [EMAIL PROTECTED] on behalf of Adrian Brock Sent: Wed 1/7/2004 10:28 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Moving out the core hard-coded serviceconfiguration On Wed, 2004-01-07 at 18:04, Scott M Stark wrote: > A long standing issue I have with the jmx microkernel of services > that are hard-coded (ServerImpl, MainDeployer, SARDeployer, > ServiceController, ...) > is that there is no way to configure these services let alone replace > them. > > So, I want to externalize these as XMBeans. Comments? > Couldn't we just use an xml (xmbean) description of these services in jboss-system.jar Then use Classloader.getResource() to load it. If somebody wants to override the xml they can use the patch parameter (or add it JBOSS_CLASSPATH) to insert an alternate xml file before jboss-system.jar in the kernel's classloader. The same could be done for the hard-wired modelmbean descriptions in MBeanServerImpl. Depending upon how far you want to go, we could also provide a file that contains a list of mbeans descriptors to instantiate that forms the kernel. In principal this could all be handled by the mbean server. i.e. When creating the MBeanServer it looks in a certain location for the initial mbeans to load. Bootstrapping the server would just be to setup the classloader then create an MBeanServer. I imagine there are a number of "chicken/egg" problems to solve. Regards, Adrian -- Adrian Brock Director of Support Back Office JBoss Group, LLC -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Moving out the core hard-coded serviceconfiguration
I don't see a chicken/egg problem for the JBoss services which is what I want to address now. Trying to do the same for the embedded JMX services is a second step. I was just thinking of using a system property to specify the xmbean resource location in the same manner in which the conf/jboss-service.xml descriptor is used, and would default to a conf/xmbeans directory (the current conf/xmdesc would be renamed). Scott Stark Chief Technology Officer JBoss Group, LLC From: [EMAIL PROTECTED] on behalf of Adrian Brock Sent: Wed 1/7/2004 10:28 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Moving out the core hard-coded serviceconfiguration On Wed, 2004-01-07 at 18:04, Scott M Stark wrote: > A long standing issue I have with the jmx microkernel of services > that are hard-coded (ServerImpl, MainDeployer, SARDeployer, > ServiceController, ...) > is that there is no way to configure these services let alone replace > them. > > So, I want to externalize these as XMBeans. Comments? > Couldn't we just use an xml (xmbean) description of these services in jboss-system.jar Then use Classloader.getResource() to load it. If somebody wants to override the xml they can use the patch parameter (or add it JBOSS_CLASSPATH) to insert an alternate xml file before jboss-system.jar in the kernel's classloader. The same could be done for the hard-wired modelmbean descriptions in MBeanServerImpl. Depending upon how far you want to go, we could also provide a file that contains a list of mbeans descriptors to instantiate that forms the kernel. In principal this could all be handled by the mbean server. i.e. When creating the MBeanServer it looks in a certain location for the initial mbeans to load. Bootstrapping the server would just be to setup the classloader then create an MBeanServer. I imagine there are a number of "chicken/egg" problems to solve. Regards, Adrian -- Adrian Brock Director of Support Back Office JBoss Group, LLC <>
[JBoss-dev] default head configuration will not startup without errors
The default configuration in head is not starting up without errors due to the inclusion of the HAILSingletonController and related. There are not clustering services in the default config, so don't put services needing them in the default config. 11:03:27,743 INFO [MainDeployer] Deployed package: file:/cvs/JBossHead/jboss-head/build/output/jboss-4.0.0DR3/server/default/deploy/management/web-console.war11:03:27,744 ERROR [URLDeploymentScanner] MBeanException: Incomplete Deployment listing:Packages waiting for a deployer: Incompletely deployed packages: MBeans waiting for classes: MBeans waiting for other MBeans:[ObjectName: jboss.mq:service=HAILSharedState state: CONFIGURED I Depend On: jboss:service=DefaultPartition Depends On Me: jboss.mq:service=InvocationLayer,type=HAIL, ObjectName: jboss.mq:service=InvocationLayer,type=HAIL state: CONFIGURED I Depend On: jboss.mq:service=InvocationLayer,type=UIL2 jboss.mq:service=HAILSharedState Depends On Me: jboss.mq:service=HAILSingletonController, ObjectName: jboss.mq:service=HAILSingletonController state: CONFIGURED I Depend On: jboss:service=DefaultPartition jboss.mq:service=InvocationLayer,type=HAIL Depends On Me: ]Cause: Incomplete Deployment listing:Packages waiting for a deployer: Incompletely deployed packages: MBeans waiting for classes: MBeans waiting for other MBeans:[ObjectName: jboss.mq:service=HAILSharedState state: CONFIGURED I Depend On: jboss:service=DefaultPartition Depends On Me: jboss.mq:service=InvocationLayer,type=HAIL, ObjectName: jboss.mq:service=InvocationLayer,type=HAIL state: CONFIGURED I Depend On: jboss.mq:service=InvocationLayer,type=UIL2 jboss.mq:service=HAILSharedState Depends On Me: jboss.mq:service=HAILSingletonController, ObjectName: jboss.mq:service=HAILSingletonController state: CONFIGURED I Depend On: jboss:service=DefaultPartition jboss.mq:service=InvocationLayer,type=HAIL Depends On Me: ]11:03:27,745 INFO [URLDeploymentScanner] Started jboss.deployment:type=DeploymentScanner,flavor=URL Scott StarkChief Technology OfficerJBoss Group, LLC
Re: [JBoss-dev] Moving out the core hard-coded service configuration
On Wed, 2004-01-07 at 18:04, Scott M Stark wrote: > A long standing issue I have with the jmx microkernel of services > that are hard-coded (ServerImpl, MainDeployer, SARDeployer, > ServiceController, ...) > is that there is no way to configure these services let alone replace > them. > > So, I want to externalize these as XMBeans. Comments? > Couldn't we just use an xml (xmbean) description of these services in jboss-system.jar Then use Classloader.getResource() to load it. If somebody wants to override the xml they can use the patch parameter (or add it JBOSS_CLASSPATH) to insert an alternate xml file before jboss-system.jar in the kernel's classloader. The same could be done for the hard-wired modelmbean descriptions in MBeanServerImpl. Depending upon how far you want to go, we could also provide a file that contains a list of mbeans descriptors to instantiate that forms the kernel. In principal this could all be handled by the mbean server. i.e. When creating the MBeanServer it looks in a certain location for the initial mbeans to load. Bootstrapping the server would just be to setup the classloader then create an MBeanServer. I imagine there are a number of "chicken/egg" problems to solve. Regards, Adrian > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > --- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Moving out the core hard-coded service configuration
A long standing issue I have with the jmx microkernel of services that are hard-coded (ServerImpl, MainDeployer, SARDeployer, ServiceController, ...) is that there is no way to configure these services let alone replace them. So, I want to externalize these as XMBeans. Comments? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Web integration (clustering) updates
So with the current 3.2 branch code what do I do to produce the class loader problem? Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Remy Maucherat Sent: Wednesday, January 07, 2004 8:39 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Web integration (clustering) updates Scott M Stark wrote: > The class loading is the same, the bigger recent change was a > refactoring No, your refactoring didn't break anything, as I did test it earlier. > of the embedded web service into the web container service and a deployer. > I would this is the source of the behavior change. What use case > produces the problem so I can look at it? For a variety of reasons, I needed to get a new class on shutdown of the service (a webapp deployer, to shutdown all the webapps). This is mostly to be consistent with Tomcat standalone, and it would actually be useful if using external contexts. So to fix it, I changed the setting so that a (useless) Host deployer would be created on startup: - + -- x Rémy Maucherat Senior Developer & Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Web integration (clustering) updates
Scott M Stark wrote: The class loading is the same, the bigger recent change was a refactoring No, your refactoring didn't break anything, as I did test it earlier. of the embedded web service into the web container service and a deployer. I would this is the source of the behavior change. What use case produces the problem so I can look at it? For a variety of reasons, I needed to get a new class on shutdown of the service (a webapp deployer, to shutdown all the webapps). This is mostly to be consistent with Tomcat standalone, and it would actually be useful if using external contexts. So to fix it, I changed the setting so that a (useless) Host deployer would be created on startup: - + -- x Rémy Maucherat Senior Developer & Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Web integration (clustering) updates
The class loading is the same, the bigger recent change was a refactoring of the embedded web service into the web container service and a deployer. I would this is the source of the behavior change. What use case produces the problem so I can look at it? Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Remy Maucherat Sent: Wednesday, January 07, 2004 12:38 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Web integration (clustering) updates Scott M Stark wrote: > The class loading failure is due the associated deployment being > destroyed and the class loader removed from the repository. The class > loader reference is invalid, so look into why the class loader is > being used after its deployment is destroyed. This was working before the JMX 1.2 backport. Also, the CL occurs in the stopService method, not after. I think the CL should still be valid at that point (it can be marked invalid after returning from that call). I don't think I can change that in Tomcat, so I think I'll have to rely on my workaround. -- x Rémy Maucherat Senior Developer & Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ModelMBean persistence appears broken
I have a vague recollection of writing a test or two, but that may just be wishful thinking ;) I stopped working on this quite a while ago as someone (can't remember who) came forward with AOP persistence or somesuch that made what I was doing irrelevant... - Matt -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 7:53 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ModelMBean persistence appears broken Its his persistence implementation that cannot work with the duplication of descriptors as this is what I modified and used for the 3.2.3 and earlier persistence tests. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Monday, January 05, 2004 4:51 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ModelMBean persistence appears broken If there are no unit tests for the persistence in the HEAD test suite then it hasn't. I can't remember if Matt Munz added any tests for his persistence implementation or not. -- Juha --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&opÕick ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Web integration (clustering) updates
Was my fault for not giving more notice. I e-mailed a few people directly before the commit, but should have notified the list before hand. Will be working on the classloader problem later today (sorry for negative impact on you Remy). Hope to have it fixed by end of day. -Tom Sacha Labourey wrote: I would qualify JMX 1.2 as a major addition, so maybe it would be a good idea to change the numbering scheme (3.2.3 was a minor update, 3.2.2 wasn't, and 3.2.4 isn't going to be one either). I agree, I didn't expected the JMX 1.2 migration, that was quite a big move, I was impressed by so much courage :) Cheers, sahca --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Remoting and NAT traversal, advanced network]
> And, no Marc, this isn't relegated to just JMX as Bill > demonstrates with AOP Remoting. This should be used for JMS, > EJB and all the other subsystem layers. ;) That is great, the AOP remoting part is the future. But the best of this will come as the invoker layer for proxies of EJB (which do use the JMX invokers). Replace the EJB invokers with the functionality pointed out by Scott and you got massive usage of this. Marcf --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Web integration (clustering) updates
Hello! Am Mit, den 07.01.2004 schrieb Remy Maucherat um 07:01: > IMO, the TC 5 code which I ported should be kept in sync (it's in > src/main/org/jboss/web/tomcat/tc5/session). Also, would it be possible > to test it so that the TC 5 integration has the same features as TC 4.1 > ? I don't quite have the right setup myself. I am looking into this tomorrow. > Would it be possible to switch to TC 5 for JB 3.2.4 (assuming there's > someone to test and bugfix the clustering code) ? I did add the JSR 77 > stats, so the web console works and has the same stats as with TC 4.1 now. +1 from me. CU Thomas --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Web integration (clustering) updates
> I would qualify JMX 1.2 as a major addition, so maybe it > would be a good > idea to change the numbering scheme (3.2.3 was a minor update, 3.2.2 > wasn't, and 3.2.4 isn't going to be one either). I agree, I didn't expected the JMX 1.2 migration, that was quite a big move, I was impressed by so much courage :) Cheers, sahca --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Web integration (clustering) updates
Sacha Labourey wrote: Hello Rémy, Would it be possible to switch to TC 5 for JB 3.2.4 (assuming there's someone to test and bugfix the clustering code) ? I did add the JSR 77 stats, so the web console works and has the same stats as with TC 4.1 now. It is not my decision but in a recent e-mail (virtual hosting) you said that it needed some more testing, do you think it is really safe to do the change now (remember these are stable minor releases)? I would qualify JMX 1.2 as a major addition, so maybe it would be a good idea to change the numbering scheme (3.2.3 was a minor update, 3.2.2 wasn't, and 3.2.4 isn't going to be one either). As for testing, that's what betas are for. One more month in beta should be enough :) -- x Rémy Maucherat Senior Developer & Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Can't update from cvs Branch_3_2 or HEAD
You need to do a fresh checkout. -- Juha On Wed, 7 Jan 2004, Dimitris Andreadis wrote: > > Something wrong with /cvsroot/jboss/build/jboss/etc/root ??? > > cvs update -P -d (in directory X:\jboss\jboss-3.2\) > cvs server: Updating . > cvs server: cannot open directory /cvsroot/jboss/build/jboss/etc/root: No > such file or directory > cvs server: skipping directory > > *CVS exited normally with code 0* > > --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Can't update from cvs Branch_3_2 or HEAD
Something wrong with /cvsroot/jboss/build/jboss/etc/root ??? cvs update -P -d (in directory X:\jboss\jboss-3.2\) cvs server: Updating . cvs server: cannot open directory /cvsroot/jboss/build/jboss/etc/root: No such file or directory cvs server: skipping directory *CVS exited normally with code 0* --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Web integration (clustering) updates
Scott M Stark wrote: The class loading failure is due the associated deployment being destroyed and the class loader removed from the repository. The class loader reference is invalid, so look into why the class loader is being used after its deployment is destroyed. This was working before the JMX 1.2 backport. Also, the CL occurs in the stopService method, not after. I think the CL should still be valid at that point (it can be marked invalid after returning from that call). I don't think I can change that in Tomcat, so I think I'll have to rely on my workaround. -- x Rémy Maucherat Senior Developer & Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Webconsole Snapshot Recording of JMX attributes
Yes, I remember exactly: - I know Java - I don't know DHTML :) If you want to reimplement it in DTHML and check on the server side if the browser supports it and send the appropriate version of the tree, fine! Cheers, sacha - Original Message - From: "Ivelin Ivanov" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 07, 2004 7:41 AM Subject: Re: [JBoss-dev] Webconsole Snapshot Recording of JMX attributes > > Sacha, do you remember what drove your decision to use > Swing for the management tree in the web console? > > The reason why I am asking is because we (in our > company) had to go through a long and painful round of > experiments and prototypes comparing the feasibility > of DHTML vs Swing for a big project. One of the > prototypes showed how to efficiently implement dynamic > tree that updates some of its nodes over time. > > At the end, DHTML came ahead because of its better > cross-browser, cross-platform availability, compared > to java plug-ins. Although it is much less pleasent to > code to. > > > Ivelin > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > The web-console framework is Sacha's baby. I've > > just added shit. > > > > Ivelin Ivanov wrote: > > > > > Cool. > > > I assume this is a feature of the web console, not > > the > > > jmx console? > > > > > > BTW, how did you make the decision to use a java > > > applet in the web console vs. dhtml? > > > > > > Ivelin > > > > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > >>Hi all, > > >> > > >>I just committed the ability to do snapshot > > >>recordings of any JMX > > >>attribute within the web-console. > > >> > > >>To use it, you right-click a JMX attribute and > > >>choose the "create > > >>snapshot" item. > > >> > > >> From there you can start/stop snapshotting. > > Review > > >>the dataset and > > >>Graph the dataset. > > >> > > >>This is currently only available in Branch_3_2 and > > >>will be released with > > >>3.2.4 (or the next RC of 3.2.4) > > >> > > >>Regards, > > >> > > >> > > >>Bill > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > --- > > > > > >>This SF.net email is sponsored by: IBM Linux > > >>Tutorials. > > >>Become an expert in LINUX or just sharpen your > > >>skills. Sign up for IBM's > > >>Free Linux Tutorials. Learn everything from the > > >>bash shell to sys admin. > > >>Click now! > > >> > > > > > > > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > > > >>___ > > >>JBoss-Development mailing list > > >>[EMAIL PROTECTED] > > >> > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > --- > > > This SF.net email is sponsored by: IBM Linux > > Tutorials. > > > Become an expert in LINUX or just sharpen your > > skills. Sign up for IBM's > > > Free Linux Tutorials. Learn everything from the > > bash shell to sys admin. > > > Click now! > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > ___ > > > JBoss-Development mailing list > > > [EMAIL PROTECTED] > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > -- > > > > Bill Burke > > Chief Architect > > JBoss Group LLC. > > > > > > > > > > > > > --- > > This SF.net email is sponsored by: IBM Linux > > Tutorials. > > Become an expert in LINUX or just sharpen your > > skills. Sign up for IBM's > > Free Linux Tutorials. Learn everything from the > > bash shell to sys admin. > > Click now! > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > ___ > > JBoss-Development mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Web integration (clustering) updates
Hello Rémy, > Would it be possible to switch to TC 5 for JB 3.2.4 (assuming there's > someone to test and bugfix the clustering code) ? I did add the JSR 77 > stats, so the web console works and has the same stats as with TC 4.1 now. It is not my decision but in a recent e-mail (virtual hosting) you said that it needed some more testing, do you think it is really safe to do the change now (remember these are stable minor releases)? --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] If JSR-77 stats were mbeans...
Just have the JSR77 mbeans expose a flattened version of a
subset of the stats as an mbean. The JSR77 stats interfaces
will not map to usable mbean attributes because they are aggregate
objects like:
javax.management.j2ee.statistics.RangeStatistic extends Statistic
{
public String getName();
public String getUnit();
public String getDescription();
public long getStartTime();
public long getLastSampleTime();
public long getHighWaterMark();
public long getLowWaterMark();
public long getCurrent();
}
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Tuesday, January 06, 2004 2:52 PM
To: Jboss-Dev
Subject: [JBoss-dev] If JSR-77 stats were mbeans...
If JSR-77 stats were mbeans then we could use all the monitoring,
snapshotting and graphing features. Is it feasible to make current
MBeans that manage EJBs, JMS, etc... implement the JSR-77 interfaces and
expose these stats as JMX attributes? Just a thought and I haven't put
any research at all to see whether this was feasible or not. Just
thought I would throw it out.
Bill
--
Bill Burke
Chief Architect
JBoss Group LLC.
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Web integration (clustering) updates
The class loading failure is due the associated deployment being destroyed and the class loader removed from the repository. The class loader reference is invalid, so look into why the class loader is being used after its deployment is destroyed. We need to get the web integration tests running before tc5 can be considered for the default config. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Remy Maucherat Sent: Tuesday, January 06, 2004 10:02 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Web integration (clustering) updates Hi, I saw some updates here to the web clustering code from Thomas: User: tpeuss Date: 04/01/04 03:54:01 Modified:src/main/org/jboss/web/tomcat/session Tag: Branch_3_2 ClusterManager.java ClusteredSession.java Log: Change for bug #863113. This patch adds a new configuration option (UseLocalCache) to the clustering code. Setting this option to false forces the clustering code to look into the distributed store on every access and to replicate the session on every access. This is useful in a non-sticky session environment but costs performance. By default this option is true. IMO, the TC 5 code which I ported should be kept in sync (it's in src/main/org/jboss/web/tomcat/tc5/session). Also, would it be possible to test it so that the TC 5 integration has the same features as TC 4.1 ? I don't quite have the right setup myself. Would it be possible to switch to TC 5 for JB 3.2.4 (assuming there's someone to test and bugfix the clustering code) ? I did add the JSR 77 stats, so the web console works and has the same stats as with TC 4.1 now. BTW, what about the classloading failure I posted two days ago ? I did find a workaround for it but it's not very clean. -- x Rémy Maucherat Senior Developer & Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-jmx-remoting 3.2 branch module
I have added a new module called jboss-jmx-remoting32 to CVS in order to make it a little easier to work on jmx, remoting and jmx-remoting (without having to get and build the whole jboss tree). This is only for the 3.2 branch, so will have to use the following for checkout: cvs checkout -r Branch_3_2 jboss-jmx-remoting32 for it to get any code. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
