Re: [JBoss-dev] Web integration (clustering) updates
Scott M Stark wrote: This has been fixed by only unregistering the deployment UCL if the deployment actually created the UCL as opposed to inherit the UCL from its containing deployment. The current NPE behavior is an artifact of class loading that is ocurring now, not any specific behavior changes. Cool :) Should I remove the nested deployment for the root webapp in the TC 5 SAR, and move the .war to deploy ? -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Web integration (clustering) updates
The problem is due to how the ROOT.war is deployed. Instead of being deployed as a unique war with its own UCL, it is being associated as a nested deployment of the jbossweb-tomcat50.sar, and uses the sar UCL as the war URL: 2004-01-19 14:55:04,085 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] Added url: file:/C:/cvs/JBoss3.2/jboss-3.2/build/output/jboss-3.2.4RC1/server/tomcat5/de ploy/jbossweb-tomcat50.sar/ROOT.war/, to ucl: org.jboss.mx.loading.UnifiedClassL [EMAIL PROTECTED] url=file:/C:/cvs/JBoss3.2/jboss-3.2/build/output/jboss-3.2.4RC1/s erver/tomcat5/deploy/jbossweb-tomcat50.sar/ ,addedOrder=5} When the shutdown occurs, all wars are undeployed, and then the jbossweb-tomcat50.sar. The stopService method of the jbossweb-tomcat50.sar is called after the ROOT.war has been undeployed and the jbossweb-tomcat50.sar UCL removed from its repository. A sar which is a deployer with a nested deployment is not going to shutdown cleanly. I'm still looking at why the NPE was not seen before, but this shutdown behavior is not new. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Thursday, January 08, 2004 12:06 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Web integration (clustering) updates I am able to reproduce the problem, but after spending a good bit of time trying to find the bug, I am at a loss. Here is what I have found so far (Scott maybe you would be able to figure it out based on this info?). The LoaderRepository variable, repository, within UnifiedClassLoader is null when loadClassImpl() is called. Best I can tell, this probably happens because UnifiedClassLoader::setRepository() is called with a null value or UnifiedClassLoader::unregister() is called (am guessing it is the later). The MainDeployer does call the unregister() method on the UnifiedClassLoader, but not until after it calls stop(), which is where the NPE occurs (so has not gotten to the unregister() call yet). My best guess is that the problem stems from destroying one of the sub deployments (which happens before the NPE and will call unregister(), but not familiar enough with classloader/deployment stuff to know if would be using same UnifiedClassLoader instance). I did notice an exception in the log before the NPE (am attaching snippet of the log). I also checked the MainDeployer, UnifiedClassLoader, and UnifiedClassLoader3 for recent code changes. The MainDeployer had only one change related to using a HashSet for the waitingForClasses collection. The UnifiedClassLoader3 did not have any changes. The UnifiedClassLoader had a lot of changes, but don't seem related to this (but could be missing something). Remy Maucherat wrote: 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 Host name=localhost by Host name=localhost autoDeploy=false deployOnStartup=false (that way, Tomcat will do a Class.forName during its shutdown, but before AbstractWebContainer.stopService is called) Rémy --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Web integration (clustering) updates
Tom Elrod wrote: I am able to reproduce the problem, but after spending a good bit of time trying to find the bug, I am at a loss. Here is what I have found so far (Scott maybe you would be able to figure it out based on this info?). The LoaderRepository variable, repository, within UnifiedClassLoader is null when loadClassImpl() is called. Best I can tell, this probably happens because UnifiedClassLoader::setRepository() is called with a null value or UnifiedClassLoader::unregister() is called (am guessing it is the later). The MainDeployer does call the unregister() method on the UnifiedClassLoader, but not until after it calls stop(), which is where the NPE occurs (so has not gotten to the unregister() call yet). My best guess is that the problem stems from destroying one of the sub deployments (which happens before the NPE and will call unregister(), but not familiar enough with classloader/deployment stuff to know if would be using same UnifiedClassLoader instance). I did notice an exception in the log before the NPE (am attaching snippet of the log). I also checked the MainDeployer, UnifiedClassLoader, and UnifiedClassLoader3 for recent code changes. The MainDeployer had only one change related to using a HashSet for the waitingForClasses collection. The UnifiedClassLoader3 did not have any changes. The UnifiedClassLoader had a lot of changes, but don't seem related to this (but could be missing something). I ended up giving up, and modifying Tomcat a little to do the needed classloading on startup instead. This could possibly cause regressions with other services, although this is unlikely, since doing explicit classloading on shutdown is at best unusual ;-) I put the 5.0.18 binaries in the CVS, and they have the fix. So update your repository, and there shouldn't be a problem now. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Web integration (clustering) updates
I just tried to reproduce this with the current cvs snapshot and cannot, I guess because the behavior is changed. I'll try with the previous binaries as I do want to see what the source of the problem is. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Remy Maucherat Sent: Sunday, January 18, 2004 9:36 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Web integration (clustering) updates I ended up giving up, and modifying Tomcat a little to do the needed classloading on startup instead. This could possibly cause regressions with other services, although this is unlikely, since doing explicit classloading on shutdown is at best unusual ;-) I put the 5.0.18 binaries in the CVS, and they have the fix. So update your repository, and there shouldn't be a problem now. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Web integration (clustering) updates
I went back to a snapshot from 2004-01-10 and I'm still not seeing the NPE on shutdown using a jbossweb-tomcat50.sar/server.xml config with: Engine name=jboss.web defaultHost=localhost autoDeploy=false deployOnStartup=false What else does it take to produce this error? Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Thursday, January 08, 2004 12:06 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Web integration (clustering) updates I am able to reproduce the problem, but after spending a good bit of time trying to find the bug, I am at a loss. Here is what I have found so far (Scott maybe you would be able to figure it out based on this info?). The LoaderRepository variable, repository, within UnifiedClassLoader is null when loadClassImpl() is called. Best I can tell, this probably happens because UnifiedClassLoader::setRepository() is called with a null value or UnifiedClassLoader::unregister() is called (am guessing it is the later). The MainDeployer does call the unregister() method on the UnifiedClassLoader, but not until after it calls stop(), which is where the NPE occurs (so has not gotten to the unregister() call yet). My best guess is that the problem stems from destroying one of the sub deployments (which happens before the NPE and will call unregister(), but not familiar enough with classloader/deployment stuff to know if would be using same UnifiedClassLoader instance). I did notice an exception in the log before the NPE (am attaching snippet of the log). I also checked the MainDeployer, UnifiedClassLoader, and UnifiedClassLoader3 for recent code changes. The MainDeployer had only one change related to using a HashSet for the waitingForClasses collection. The UnifiedClassLoader3 did not have any changes. The UnifiedClassLoader had a lot of changes, but don't seem related to this (but could be missing something). --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ 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. We need to get the web integration tests running before tc5 can be considered for the default config. The web integration tests now work. Clustering is still untested, though. -- 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 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=1278alloc_id=3371op=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_id78alloc_id371op=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=1278alloc_id=3371op=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=1278alloc_id=3371op=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=1278alloc_id=3371op=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=1278alloc_id=3371op=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=1278alloc_id=3371op=click ___ 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=1278alloc_id=3371op=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=1278alloc_id=3371op=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 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=1278alloc_id=3371op=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] 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: - Host name=localhost autoDeploy=false deployOnStartup=false + Host name=localhost -- 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 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: - Host name=localhost autoDeploy=false deployOnStartup=false + Host name=localhost -- 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
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 Host name=localhost by Host name=localhost autoDeploy=false deployOnStartup=false (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
