[JBoss-dev] [ jboss-Bugs-676522 ] config files fail DTD verification for two services
Bugs item #676522, was opened at 2003-01-28 18:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=676522&group_id=22866 Category: JBossWeb Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stefan Reich (sreich) Assigned to: Stefan Reich (sreich) Summary: config files fail DTD verification for two services Initial Comment: jbossha-httpsession and jbossweb-ejb.jar fail to deploy with DTD verification enabled. The error messages are: 18:23:10,166 ERROR [XmlFileLoader] XmlFileLoader: File file:/Users/Shared/jboss32/jboss/server/default/tmp/deploy/server/default/deploy/jbossweb-ejb.jar/32.jbossweb-ejb.jar!/META-INF/jboss.xml process error. Line: 38. Error message: The content of element type "container-interceptors" must match "(interceptor)+". 18:23:10,171 ERROR [XmlFileLoader] failed to load jboss.xml. There could be a syntax error. org.jboss.deployment.DeploymentException: Invalid XML: file=file:/Users/Shared/jboss32/jboss/server/default/tmp/deploy/server/default/deploy/jbossweb-ejb.jar/32.jbossweb-ejb.jar!/META-INF/jboss.xml 18:23:05,852 ERROR [XmlFileLoader] XmlFileLoader: File file:/Users/Shared/jboss32/jboss/server/default/tmp/deploy/server/default/deploy/jbossha-httpsession.sar/4.jbossha-httpsession.sar-contents/ClusteredHttpSessionEB.jar!/META-INF/ejb-jar.xml process error. Line: 26. Error message: The content of element type "entity" must match "(description?,display-name?,small-icon?,large-icon?,ejb-name,home?,remote?,local-home?,local?,ejb-class,persistence-type,prim-key-class,reentrant,cmp-version?,abstract-schema-name?,cmp-field*,primkey-field?,env-entry*,ejb-ref*,ejb-local-ref*,security-role-ref*,security-identity?,resource-ref*,resource-env-ref*,query*)". 18:23:05,863 ERROR [MainDeployer] could not create deployment: file:/Users/Shared/jboss32/jboss/server/default/tmp/deploy/server/default/deploy/jbossha-httpsession.sar/4.jbossha-httpsession.sar-contents/ClusteredHttpSessionEB.jar org.jboss.deployment.DeploymentException: Invalid XML: file=file:/Users/Shared/jboss32/jboss/server/default/tmp/deploy/server/default/deploy/jbossha-httpsession.sar/4.jbossha-httpsession.sar-contents/ClusteredHttpSessionEB.jar!/META-INF/ejb-jar.xml -- Comment By: Stefan Reich (sreich) Date: 2003-02-07 13:29 Message: Logged In: YES user_id=429729 The file jetty/src/resources/org.mortbay.j2ee/jboss-container.xml contained a variable that was supposed to substituted somewhere, but wasn't. Commented out the offending line. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=676522&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-681795 ] Bug in message selector evaluation
Bugs item #681795, was opened at 2003-02-06 17:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=681795&group_id=22866 Category: JBossMQ Group: None Status: Open Resolution: None >Priority: 9 Submitted By: Vaughn T. Combs (vaughnt) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in message selector evaluation Initial Comment: I believe that I have found a bug in org.jboss.mq.selectors.Operator. In the methods lt() and le() you are, I believe, erroneously testing the second argument. Rather than != I believe that it should be ==. This truncates the second argument inappropriately when it is a double. I have attached a test run demonstrating the bug and the effect of the patch. Also, obviously, I have attached a patched version of Operator.java. I have checked the source for the most recent distribution v3.0.6 and it seems to be there as well. The interesting lines are 373, 376, 384, 387, 409, 412, 420, and 423 in Operator.java Take Care, Vaughn -- Comment By: Vaughn T. Combs (vaughnt) Date: 2003-02-06 17:35 Message: Logged In: YES user_id=706194 here is the test run that I referred to in my original bug report. vtc -- Comment By: Vaughn T. Combs (vaughnt) Date: 2003-02-06 17:35 Message: Logged In: YES user_id=706194 here is the test run that I referred to in my original bug report. vtc -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=681795&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-682618 ] xDoclet: xmbean generation does not match the DTD
Bugs item #682618, was opened at 2003-02-07 17:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682618&group_id=22866 Category: None Group: v4.0 Status: Open Resolution: None Priority: 7 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: xDoclet: xmbean generation does not match the DTD Initial Comment: I wasn't sure where to submit this-- if this is the wrong place, let me know... The XMBean XML generated by xDoclet does not fit the XMBean DTD. Essentially, the descriptors are written in the wrong order. Here are my xDoclet tags * @jmx.mbean * persistPolicy = "OnUpdate" * persistName = "Resource2-state.xml" * persistLocation = "D:/Matt/apelon/temporary/MBean-Repository" * display-name = "Resource #2 Test MBean" * name = "jboss.jmx.test:name=Resource2" * persistence-manager = "org.jboss.mx.persistence.XMLPersistenceManager" * @jboss.xmbean here's the xml generated by xDoclet and here's the parser error org.xml.sax.SAXParseException: The content of element type "descriptors" must match (persistence?,currencyTimeLimit?,state-action-on-update?,display-name?, default?,value?,persistence-manager?,descriptor*)". - Matt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682618&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-676522 ] config files fail DTD verification for two services
Bugs item #676522, was opened at 2003-01-28 18:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=676522&group_id=22866 Category: JBossWeb Group: v3.2 >Status: Pending >Resolution: Accepted Priority: 5 Submitted By: Stefan Reich (sreich) >Assigned to: Stefan Reich (sreich) Summary: config files fail DTD verification for two services Initial Comment: jbossha-httpsession and jbossweb-ejb.jar fail to deploy with DTD verification enabled. The error messages are: 18:23:10,166 ERROR [XmlFileLoader] XmlFileLoader: File file:/Users/Shared/jboss32/jboss/server/default/tmp/deploy/server/default/deploy/jbossweb-ejb.jar/32.jbossweb-ejb.jar!/META-INF/jboss.xml process error. Line: 38. Error message: The content of element type "container-interceptors" must match "(interceptor)+". 18:23:10,171 ERROR [XmlFileLoader] failed to load jboss.xml. There could be a syntax error. org.jboss.deployment.DeploymentException: Invalid XML: file=file:/Users/Shared/jboss32/jboss/server/default/tmp/deploy/server/default/deploy/jbossweb-ejb.jar/32.jbossweb-ejb.jar!/META-INF/jboss.xml 18:23:05,852 ERROR [XmlFileLoader] XmlFileLoader: File file:/Users/Shared/jboss32/jboss/server/default/tmp/deploy/server/default/deploy/jbossha-httpsession.sar/4.jbossha-httpsession.sar-contents/ClusteredHttpSessionEB.jar!/META-INF/ejb-jar.xml process error. Line: 26. Error message: The content of element type "entity" must match "(description?,display-name?,small-icon?,large-icon?,ejb-name,home?,remote?,local-home?,local?,ejb-class,persistence-type,prim-key-class,reentrant,cmp-version?,abstract-schema-name?,cmp-field*,primkey-field?,env-entry*,ejb-ref*,ejb-local-ref*,security-role-ref*,security-identity?,resource-ref*,resource-env-ref*,query*)". 18:23:05,863 ERROR [MainDeployer] could not create deployment: file:/Users/Shared/jboss32/jboss/server/default/tmp/deploy/server/default/deploy/jbossha-httpsession.sar/4.jbossha-httpsession.sar-contents/ClusteredHttpSessionEB.jar org.jboss.deployment.DeploymentException: Invalid XML: file=file:/Users/Shared/jboss32/jboss/server/default/tmp/deploy/server/default/deploy/jbossha-httpsession.sar/4.jbossha-httpsession.sar-contents/ClusteredHttpSessionEB.jar!/META-INF/ejb-jar.xml -- >Comment By: Stefan Reich (sreich) Date: 2003-02-07 13:29 Message: Logged In: YES user_id=429729 The file jetty/src/resources/org.mortbay.j2ee/jboss-container.xml contained a variable that was supposed to substituted somewhere, but wasn't. Commented out the offending line. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=676522&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 7-February-2003
JBoss daily test results SUMMARY Number of tests run: 1026 Successful tests: 1023 Errors:2 Failures: 1 [time of test: 2003-02-07.12-05 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.3] See http://users.jboss.org/~starksm/Branch_3_0/2003-02-07.12-05 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] unchecked permission bug
I figured out the problem, my bean was calling another bean that didn't have
method permissions, my mistake, the software is working great.
I should never send messages to the dev-list after 10:30 pm.
Tim
On Friday 07 February 2003 12:24 am, Scott M Stark wrote:
> Post a bug with an example attached to sourceforge as it is not clear
> what you are describing here.
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
>
> - Original Message -
> From: "Timothy Barreto" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, February 06, 2003 10:37 PM
> Subject: [JBoss-dev] unchecked permission bug
>
>
> Hi dev-list,
>
> I've been working on this simple ejb that is called from an web container
> unauthenticated. The method I'm calling has an in its
> method-permissions element in the assembly-descriptor. After some debug I
> found that BeanMetaData getMethodPermissions() returned null when
> called from the SecurityInterceptor. This causes the familiar error:
>
> "No method permissions assigned to method="+method
>+ ", interface="+Invocation.getInvocationTypeName(iface);
>
> I then began to inspect the code and found the AnbodyPrincipal class does
> not obey the equals contract. In the following section of code, at least
> on my vm, the calls:
>
> result.clear();
> result.add(AnybodyPrincipal.ANYBODY_PRINCIPAL);
> break;
>
> causes the call result.isEmpty() to return true. This appears to be a bug,
> am I missing something?
>
>while (iterator.hasNext())
> {
> MethodMetaData m = (MethodMetaData) iterator.next();
> if (m.patternMatches(methodName, params, iface))
> {
> /* If this is an unchecked method anyone can access it so
>set the result set to a role that equates to any Principal
> or Principal name and return.
> */
>
> if (m.isUnchecked())
> {
>result.clear();
> result.add(AnybodyPrincipal.ANYBODY_PRINCIPAL);
>break;
> }
> // Else, add all roles
> else
> {
>Iterator rolesIterator = m.getRoles().iterator();
>while (rolesIterator.hasNext())
>{
> String roleName = (String) rolesIterator.next();
> result.add(new SimplePrincipal(roleName));
>}
> }
> }
> }
>
> // If no permissions were assigned to the method return null to
> indicate no access
> if (result.isEmpty()) {
> result = null;
>
> return result;
>
> ---
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See!
> http://www.vasoftware.com
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] XA support in 3.0.4
Hello, I am running JBOSS 3.0.4 and am trying to get an Informix xa driver configured and running. I appear to be able to bind as I do not get any errors during server startup. The problem arises when I try to get a connection to the database. It is unable to get a connection. I've seen comments made on this list and the forums about problems with the Oracle XA stuff but haven't heard about issues with Informix XA and JBOSS 3.0.4. I was under the impression this functionality (at some level) was tested by the JBOSS group because they provided sampe jca configurations for Informix xa (Informix-xa.xml). Are there any development issues on the XA functionality in JBOSS 3.0.4 that would prevent me from getting a connection when it appears to me that the driver is configured correctly? Please advise, J.D. This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the "From:" field.
Re: [JBoss-dev] Remote class loading servlet
There is a dynamic class loading unit test: org.jboss.test.jrmp.test.DynLoadingUnitTestCase Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Dain Sundstrom" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 07, 2003 11:50 AM Subject: Re: [JBoss-dev] Remote class loading servlet > On Friday, February 7, 2003, at 01:28 PM, James Cooley wrote: > > > Dain Sundstrom wrote: > >> Scott, > >> I'm putting the question for you at the top, so you can see it. How > >> do we specify the code base for remote loading? If James writes this > >> he will need to change it to point to the servlet. > >> James, > >> You are way over thinking this. > > > > As I said there isn't a unit test for this so I guess it looked like > > it was doing more than it was doing in reality. > > Good idea. Can you add a unit test for this also? :) > > -dain > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-682529 ] JDK1.4 and CMP hierarchy cause ClassFormatError
Bugs item #682529, was opened at 2003-02-07 14:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682529&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Chris Bono (bonoc) Assigned to: Nobody/Anonymous (nobody) Summary: JDK1.4 and CMP hierarchy cause ClassFormatError Initial Comment: JDK1.4 and CMP hierarchy cause ClassFormatError == We have a somewhat complex inheritance chain of which our entites extend to be realized (see the attached class diagram). When compiled under jdk13 or jdk14 and run under jdk14 the deployment fails due to a ClassFormatError. The complete startup log is attached as well. org.jboss.deployment.DeploymentException: Could not create deployment: file:/C:/DEV/servers/jboss/jboss- 3.0.4/server/default/tmp/deploy/server/default/deploy/zpm _mgmt.ear/61.zpm_mgmt.ear-contents/zpm_mgmt.jar; - nested throwable: (java.lang.ClassFormatError: com/zilliant/zpm/management/model/collector/monitor/M onitorBean$Proxy (Repetitive method name/signature)) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682529&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote class loading servlet
On Friday, February 7, 2003, at 01:28 PM, James Cooley wrote: Dain Sundstrom wrote: Scott, I'm putting the question for you at the top, so you can see it. How do we specify the code base for remote loading? If James writes this he will need to change it to point to the servlet. James, You are way over thinking this. As I said there isn't a unit test for this so I guess it looked like it was doing more than it was doing in reality. Good idea. Can you add a unit test for this also? :) -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote class loading servlet
Dain Sundstrom wrote: Scott, I'm putting the question for you at the top, so you can see it. How do we specify the code base for remote loading? If James writes this he will need to change it to point to the servlet. James, You are way over thinking this. As I said there isn't a unit test for this so I guess it looked like it was doing more than it was doing in reality. I suggest you just start coding. :D Will do. On Friday, February 7, 2003, at 10:40 AM, James Cooley wrote: Scott M Stark wrote: You don't have to worry about the port or interface as these are attributes of the web server context the servlet is deployed to. Okay the default container listens on 8080 from what you're saying there's no need to listen on 8083 anymore. I'm not sure how you'd map the WebServer replacement servlet in the web.xml if the port is not exclusive - perhaps a filter to check each call or something but that's a fair bit of overhead. So what I think is needed here are 2 Tomcat Connectors/Jetty Adapters to one to bind to 8080 and another to bind to 8083 - the 8083 connector/adapter can be setup as part of the servlet containers config. You create a war named say class-loader. Then we set the codebase for remote stubs to be http://whatever:8080/class-loader [the question for Scott above]. Then create a servlet that accepts all requests to the context-root, convert the requested file (under your context-root) into a class name, and return that class from the thread context class loader. Okay. You don't have to worry about class loaders. Just use the thread context class loader. Sorry I wasn't clear on this - WebServer has the following method You're sill trying too hard. All of that code is already handled by the the Jetty or Tomcat web container in which your servlet is running. It is really as simple as Thread().currentThread().getClassLoader().getResourceAsStream(name); Okay, it looked like there was a lot more going on there. Thanks, James --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote class loading servlet
Via the standard java.rmi.server.codebase system property. This is now set by the WebService if it is not already set. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Dain Sundstrom" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 07, 2003 10:59 AM Subject: Re: [JBoss-dev] Remote class loading servlet > Scott, > > I'm putting the question for you at the top, so you can see it. How do > we specify the code base for remote loading? If James writes this he > will need to change it to point to the servlet. > > > > James, > > You are way over thinking this. I suggest you just start coding. :D > > On Friday, February 7, 2003, at 10:40 AM, James Cooley wrote: > > > Scott M Stark wrote: > >> You don't have to worry about the port or interface as these are > >> attributes of the > >> web server context the servlet is deployed to. > > > > Okay the default container listens on 8080 from what you're saying > > there's no need to listen on 8083 anymore. I'm not sure how you'd map > > the WebServer replacement servlet in the web.xml if the port is not > > exclusive - perhaps a filter to check each call or something but > > that's a fair bit of overhead. So what I think is needed here are 2 > > Tomcat Connectors/Jetty Adapters to one to bind to 8080 and another to > > bind to 8083 - the 8083 connector/adapter can be setup as part of the > > servlet containers config. > > You create a war named say class-loader. Then we set the codebase for > remote stubs to be http://whatever:8080/class-loader [the question for > Scott above]. Then create a servlet that accepts all requests to the > context-root, convert the requested file (under your context-root) into > a class name, and return that class from the thread context class > loader. > > >> You don't have to worry about class loaders. Just use the thread > >> context class > >> loader. > > > > Sorry I wasn't clear on this - WebServer has the following method > > You're sill trying too hard. All of that code is already handled by > the the Jetty or Tomcat web container in which your servlet is running. > It is really as simple as > Thread().currentThread().getClassLoader().getResourceAsStream(name); > > -dain > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-682511 ] Client receives RemoteException instead of TransRolledBackEx
Bugs item #682511, was opened at 2003-02-07 19:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682511&group_id=22866 Category: JBossTX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: Nobody/Anonymous (nobody) Summary: Client receives RemoteException instead of TransRolledBackEx Initial Comment: This is Jboss 3_2RC1 >From an EJB, we are doing 2-phase commits. One with Oracle XA and one with Gemstone's JCA Adapter. Gemstone votes rollback, and the client recieves a RemoteException with a nested TransactionRolledBackExcpetion. I was expecting the client to receive the TransactionRolledBackException directly. Here are the stack traces. Stack From Gemstone: 2003-02-07 18:55:55,898 WARN [org.jboss.tm.TransactionImpl] XAException: tx=TransactionImpl:XidImpl [Format Id=257, GlobalId=malt//739691, BranchQual=] errorCode=XA_RBROLLBACK javax.transaction.xa.XAException at com.gemstone.persistence.connection.internal.ContainerXAResource.prepare(ContainerXAResource.java :343) at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1340) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:355) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:361) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:247) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:265) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154 ) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:370) at org.jboss.ejb.Container.invoke(Container.java:680) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvokerHA.invoke(JRMPInvokerHA.java:163) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) Stack From JBoss: 2003-02-07 18:55:55,953 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackException: javax.transaction.TransactionRolledbackException: Unable to commit, tx=TransactionImpl:XidImpl [FormatId=257 , GlobalId=malt//739691, BranchQual=] status=STATUS_NO_TRANSACTION at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:368) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:247) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:265) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154 ) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:370) at org.jboss.ejb.Container.invoke(Container.java:680) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvokerHA.invoke(JRMPInvokerHA.java:163) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) Stack From Client: [java] EJBREMOTEMANAGER RemoteException occured in com.synxis.wizdom.ejbs.SrmsWizcomMsgProcessorRemoteIF: attempt #0 [java] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [java] RemoteException: RemoteException occurred in server thread; nested exception is: [java] javax.transaction.TransactionRolledbackException: Unable to commit, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=malt//735599, BranchQual=] status=STATUS_NO_TRANSACTION [ja
Re: [JBoss-dev] Remote class loading servlet
Scott, I'm putting the question for you at the top, so you can see it. How do we specify the code base for remote loading? If James writes this he will need to change it to point to the servlet. James, You are way over thinking this. I suggest you just start coding. :D On Friday, February 7, 2003, at 10:40 AM, James Cooley wrote: Scott M Stark wrote: You don't have to worry about the port or interface as these are attributes of the web server context the servlet is deployed to. Okay the default container listens on 8080 from what you're saying there's no need to listen on 8083 anymore. I'm not sure how you'd map the WebServer replacement servlet in the web.xml if the port is not exclusive - perhaps a filter to check each call or something but that's a fair bit of overhead. So what I think is needed here are 2 Tomcat Connectors/Jetty Adapters to one to bind to 8080 and another to bind to 8083 - the 8083 connector/adapter can be setup as part of the servlet containers config. You create a war named say class-loader. Then we set the codebase for remote stubs to be http://whatever:8080/class-loader [the question for Scott above]. Then create a servlet that accepts all requests to the context-root, convert the requested file (under your context-root) into a class name, and return that class from the thread context class loader. You don't have to worry about class loaders. Just use the thread context class loader. Sorry I wasn't clear on this - WebServer has the following method You're sill trying too hard. All of that code is already handled by the the Jetty or Tomcat web container in which your servlet is running. It is really as simple as Thread().currentThread().getClassLoader().getResourceAsStream(name); -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MySQL Connector J3.0.5 Gamma with JBoss...
From: "Mark Matthews" <[EMAIL PROTECTED]> To: "Korwin Smith" <[EMAIL PROTECTED]> Subject: Re: bug in mysql-connector-java-3.0.5-gamma? Date: Thu, 6 Feb 2003 08:32:05 -0600 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Virus-Scanned: by AMaViS perl-11 (thematthews.org) This is fixed in what will become 3.0.6. You can test the nightly snapshot from http://mmmysql.sourceforge.net/snapshots/ -Mark - Original Message - From: Korwin Smith To: [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 12:56 AM Subject: bug in mysql-connector-java-3.0.5-gamma? Mark, I am using mysql-connector-java-3.0.5-gamma with mysql 3.23.55 and jboss 3.0.6. When connecting to mysql using a jboss pooled connection I get an error (something to the effect of): "cannot retrieve transaction isolation level from the server" there is a line in Connection.java that goes like this: "SHOW VARIABLES LIKE transaction-isolation'" which seems to be causing the problem, since, at least with my version of mysql, the variable is defined like this: "transaction_isolation" Since this error prohibits the connection pool from working I changed the line to: "SHOW VARIABLES LIKE 'transaction_isolation'" and recompiled, and it works fine. NOTE: This problem does not show up if I call the driver directly using: Class.forName(com.mysql.jdbc.Driver); hopefully this is useful to you, thanks for making your driver available! korwin --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MySQL Connector J3.0.5 Gamma with JBoss...
Hi all,
We've been trying to access a MySQL database by JNDI using
JBoss 3.0.4 with Connector J3.0.5 Gamma as JDBC driver. When I try to get
connection an exception is throwed.Follows the source
code:Context c = new InitialContext ();javax.sql.DataSource
datasource = (javax.sql.DataSource) c.lookup
("java:/AcmeSQL");m_connectionDB = datasource.getConnection (new String
("root"), new String (""));Follows the
exception:javax.ejb.EJBException: ICCProductionEJB: Could not create
connection; - nested throwable: (java.sql.SQLException: Could not retrieve
transaction isolation level from server); - nested throwable:
(org.jboss.resource.ResourceException: Could not create connection; - nested
throwable: (java.sql.SQLException: Could not retrieve transaction isolation
level from server))What do I need to configure to get the connection
properly?Thanks in advance,Márcio
Azevedo.
--Márcio Emílio Cruz Vono de AzevedoEspecialista em
SistemasInatel Competence Centerhttp://www.inatel.br
[JBoss-dev] [ jboss-Bugs-634591 ] netboot failure
Bugs item #634591, was opened at 2002-11-06 11:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=634591&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: ryan sonnek (wireframe6464) Assigned to: Nobody/Anonymous (nobody) Summary: netboot failure Initial Comment: server specs: suse linux 7.3 sun 1.3.1 jdk apache web server 2.x jboss 3.0.2 config files client specs: win2k sun 1.4.0 jdk jboss 3.0.2 netboot files. can view the files correctly through a webbrowser, but when client executes run.bat, no files are pulled down. apache's server log shows the client trying to download crimson.jar. both the server and client are unresponsive, and no error messages are thrown. run.bat -netboot http:// -c custom -- >Comment By: Jeremy Boynes (jboynes) Date: 2003-02-07 08:53 Message: Logged In: YES user_id=378919 In version 3.0 all files needed by the client config must be listed explicitly, or you must configure the server-side helper app. This is covered in the page Sacha referred to. Be aware this has changed significantly in 3.2 - see the change note on SF -- Comment By: ryan sonnek (wireframe6464) Date: 2003-02-07 08:40 Message: Logged In: YES user_id=552776 i've updated to the default installation of jboss 3.0.6 and have continued to try and get this working. i have gotten past the previous errors, but am getting a new error when starting up: 10:28:47,094 INFO [MainDeployer] Starting deployment of package: http://172.16.1.40/jboss/server/local/conf/jboss-service.xml 10:28:47,915 ERROR [Server] start failed org.jboss.deployment.DeploymentException: No wildcard permitted in non-file URL deployment you must specify individual jars at org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:3 75) at org.jboss.deployment.SARDeployer.init(SARDeployer.java:132) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:679) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:615) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:591) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:575) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:222) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:536) org.jboss.deployment.DeploymentException: No wildcard permitted in non-file URL deployment you must specify individual jars at org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:3 75) at org.jboss.deployment.SARDeployer.init(SARDeployer.java:132) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:679) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:615) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:591) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:575) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:222) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:536) 10:28:47,985 INFO [Server] Undeploying all packages if the wildcard can not be used in jboss-service, what can i use to load the required jars? -- Comment By: ryan sonnek (wireframe6464) Date: 2002-11-07 07:23 Message: Logged In: YES user_id=552776 here's the structure of the website: http://172.xxx.xxx.xxx/jboss/server/custom inside the custom directory is pretty much a straight copy of the "def
Re: [JBoss-dev] Remote class loading servlet
Scott M Stark wrote:
You don't have to worry about the port or interface as these are attributes of the
web server context the servlet is deployed to.
Okay the default container listens on 8080 from what you're saying
there's no need to listen on 8083 anymore. I'm not sure how you'd map
the WebServer replacement servlet in the web.xml if the port is not
exclusive - perhaps a filter to check each call or something but that's
a fair bit of overhead. So what I think is needed here are 2 Tomcat
Connectors/Jetty Adapters to one to bind to 8080 and another to bind to
8083 - the 8083 connector/adapter can be setup as part of the servlet
containers config.
You don't have to worry about class loaders. Just use the thread context class
loader.
Sorry I wasn't clear on this - WebServer has the following method
/** Add a class loader to the web server map and return the URL that
should be used as the annotated codebase for classes that are to be
available via RMI dynamic classloading. The codebase URL is formed by
taking the java.rmi.server.codebase system property and adding a subpath
unique for the class loader instance.
@see #getClassLoaderKey(ClassLoader)
@param cl, the ClassLoader instance to begin serving download requests for
@return the annotated codebase to use if java.rmi.server.codebase is set,
null otherwise.
*/
public URL addClassLoader(ClassLoader cl)
And it's called by WebService's
/**
* @jmx:managed-operation
*/
public URL addClassLoader(ClassLoader cl)
{
return server.addClassLoader(cl);
}
Hope this clarifies my original points
James
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "James Cooley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 07, 2003 3:08 AM
Subject: Re: [JBoss-dev] Remote class loading servlet
Hi Dain,
I had a look at the class and it looks like it should be pretty easy
to do this in a servlet but the deployment may be an issue. The API
includes setPort, setBindAddress, etc. Is there an abstract factory to
create a Tomcat Connector/Jetty Adapter (or whatever the container may
be) at runtime? If not is is okay to just default to 8083 and configure
the port in the service xml config file?
The problem is also complicated by the fact that we need to add and
remove ClassLoaders dynamically and WebService will no longer hold the
instance of WebServer (unless there is an abstract factory).
You were looking for a volunteer and you get an essay :)
James
Dain Sundstrom wrote:
We have a small project open for a volunteer. In Jboss 2 and 3 we have
a custom lightweight web server (port 8083) that returns java class
files from the classLoader.getResouceAsStream to RMI clients (this is
how remote class loading happens). I talked to Scott at JBoss Boot Camp
and we think it is a good idea to replace this with a plain old Servlet
for JBoss 4.0 so it can work with regular security, pooling and such.
This is a fairly simple piece of code and shouldn't take longer then a
day or two. If you are interested the code can be found in
jboss-head/server/src/main/org/jboss/web/WebServer.java
-dain
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-634591 ] netboot failure
Bugs item #634591, was opened at 2002-11-06 19:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=634591&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: ryan sonnek (wireframe6464) Assigned to: Nobody/Anonymous (nobody) Summary: netboot failure Initial Comment: server specs: suse linux 7.3 sun 1.3.1 jdk apache web server 2.x jboss 3.0.2 config files client specs: win2k sun 1.4.0 jdk jboss 3.0.2 netboot files. can view the files correctly through a webbrowser, but when client executes run.bat, no files are pulled down. apache's server log shows the client trying to download crimson.jar. both the server and client are unresponsive, and no error messages are thrown. run.bat -netboot http:// -c custom -- >Comment By: ryan sonnek (wireframe6464) Date: 2003-02-07 16:40 Message: Logged In: YES user_id=552776 i've updated to the default installation of jboss 3.0.6 and have continued to try and get this working. i have gotten past the previous errors, but am getting a new error when starting up: 10:28:47,094 INFO [MainDeployer] Starting deployment of package: http://172.16.1.40/jboss/server/local/conf/jboss-service.xml 10:28:47,915 ERROR [Server] start failed org.jboss.deployment.DeploymentException: No wildcard permitted in non-file URL deployment you must specify individual jars at org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:3 75) at org.jboss.deployment.SARDeployer.init(SARDeployer.java:132) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:679) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:615) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:591) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:575) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:222) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:536) org.jboss.deployment.DeploymentException: No wildcard permitted in non-file URL deployment you must specify individual jars at org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:3 75) at org.jboss.deployment.SARDeployer.init(SARDeployer.java:132) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:679) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:615) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:591) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:575) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:222) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:536) 10:28:47,985 INFO [Server] Undeploying all packages if the wildcard can not be used in jboss-service, what can i use to load the required jars? -- Comment By: ryan sonnek (wireframe6464) Date: 2002-11-07 15:23 Message: Logged In: YES user_id=552776 here's the structure of the website: http://172.xxx.xxx.xxx/jboss/server/custom inside the custom directory is pretty much a straight copy of the "default" folder with all of the conf, lib, and deploy folders. i've tried to follow the netboot instructions on the website as much as possible, but it's still not working, and i'm not getting any responses or error messages when i try and run the netboot client. my last post had an incorrect posting of the command i use to startup the client. here's the command i run from my JBOSS_HOME directory: bin/run.bat --netboot http
[JBoss-dev] [ jboss-Bugs-677495 ] JGCacheInvalidationBridge stumbling over itself.
Bugs item #677495, was opened at 2003-01-30 16:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=677495&group_id=22866 Category: Clustering Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mikko Koponen (mtkopone) Assigned to: Sacha Labourey (slaboure) Summary: JGCacheInvalidationBridge stumbling over itself. Initial Comment: Greetings all. We stumbled upon a bug in the JGCacheInvalidationBridge when testing cluster failover. The replicantsChanged() method attempts removal of dead cluster members through the DistributedState interface, while holding on to an iterator to the map being affected. The removal causes a ConcurrentModificationException from ensuing calls to the iterator. Stack trace: 12:51:40,801 ERROR [SaffronTESTBackPartition:ReplicantManager] membershipChanged failedjava.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry (HashMap.java:762) at java.util.HashMap$KeyIterator.next (HashMap.java:798) at org.jboss.cache.invalidation.bridges.JGCacheInvalidation Bridge.replicantsChanged (JGCacheInvalidationBridge.java:123) at org.jboss.ha.framework.server.DistributedReplicantMana gerImpl.notifyKeyListeners (DistributedReplicantManagerImpl.java:662) at org.jboss.ha.framework.server.DistributedReplicantMana gerImpl.purgeDeadMembers (DistributedReplicantManagerImpl.java:774) at org.jboss.ha.framework.server.DistributedReplicantMana gerImpl.membershipChanged (DistributedReplicantManagerImpl.java:296) at org.jboss.ha.framework.server.HAPartitionImpl.viewAcce pted(HAPartitionImpl.java:371) at org.javagroups.blocks.MessageDispatcher$ProtocolAda pter.passUp(MessageDispatcher.java:488) at org.javagroups.blocks.RequestCorrelator.receive (RequestCorrelator.java:294) at org.javagroups.blocks.MessageDispatcher$ProtocolAda pter.up(MessageDispatcher.java:513) at org.javagroups.JChannel.up(JChannel.java:936) at org.javagroups.stack.ProtocolStack.up (ProtocolStack.java:301) at org.javagroups.stack.ProtocolStack.receiveUpEvent (ProtocolStack.java:317) at org.javagroups.stack.Protocol.passUp (Protocol.java:399) at org.javagroups.protocols.pbcast.STATE_TRANSFER.up (STATE_TRANSFER.java:133) at org.javagroups.stack.UpHandler.run (Protocol.java:50) -- Mikko Koponen Krocus Communications, Finland -- >Comment By: Sacha Labourey (slaboure) Date: 2003-02-07 17:18 Message: Logged In: YES user_id=95900 Thank you for the reports. You correctly found the two bugs but only solved one ;) We don't use HAPartition.HAMembershipListener because it doesn't allow for heterogeneous deployments i.e. only two nodes of a 4 nodes cluster running the cache invalidation bridge. Fixed in both Branch_3_2 and HEAD -- Comment By: Mikko Koponen (mtkopone) Date: 2003-02-03 19:26 Message: Logged In: YES user_id=586533 After some more meddling with failover, we now have some new concerns ;) I haven't gone _very_ far into the code, so some of this might be speculation. The replicantsChanged method of JGCacheInvalidationBridge gets called with the values of the serialized objects set in the DRM. These values are passed as the newReplicants list. The bridge apparently expects to find something quite different than a bunch of empty strings in this list, and therefore proceeds to remove everything related to the invalidation cache from the DistributedState. Also, the DRM is apparently only used to find out about dead cluster members. This same sort of functionality is available in the HAPartition.HAMembershipListener interface. I wrote a patch to use the HAMembershipListener instead of the DRM for these events. It has been tested by pulling the plug from different cluster members a couple of times, and checking the content in the DS. Seems to work fine. -- Mikko Koponen Krocus Communications, Finland -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=677495&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-682383 ] files lock(windows)
Bugs item #682383, was opened at 2003-02-07 17:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682383&group_id=22866 Category: JBossServer Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alex Buloichik (alex73) >Assigned to: Alexey Loubyansky (loubyansky) Summary: files lock(windows) Initial Comment: I can't remove application under windows(JBoss-romcat-3.20rc1), because JBoss locl files ejb-jar.xml and web.xml. -- >Comment By: Alexey Loubyansky (loubyansky) Date: 2003-02-07 18:13 Message: Logged In: YES user_id=543482 This should be fixed in JBoss-3.2.0RC2. Please, upgrade and reopen the bug if it is still there. alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682383&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-682390 ] Log4jLoggerPlugin now sends FQCN to Log4J - Correct loc.info
Patches item #682390, was opened at 2003-02-07 07:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376687&aid=682390&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Dag Liodden (daggerrz) Assigned to: Nobody/Anonymous (nobody) Summary: Log4jLoggerPlugin now sends FQCN to Log4J - Correct loc.info Initial Comment: Since the Log4jLoggerPlugin does not send FQCN to Log4j, the LocationInfo is not correct when remotely listening to the logger (e.g with socketappender). All log events seem to originate from Log4jLoggerPlugin itself. This can be illustrated by configuring a socketappender and viewing the logs with a tool like Log4J Chainsaw or equivalent. The problem is solved by sending the FQCN of the Logger class as a parameter to Log4j's logger methods since the Logger class wraps the Log4jLoggerPlugins which then wraps the Log4J logger. This patch is very non-intrusive and could probably be integrated in the 3.0.x branch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376687&aid=682390&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-682384 ] jboss-tomcat runs bad
Bugs item #682384, was opened at 2003-02-07 17:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682384&group_id=22866 Category: JBossWeb Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Alex Buloichik (alex73) Assigned to: Nobody/Anonymous (nobody) Summary: jboss-tomcat runs bad Initial Comment: Whrn I run jboss not from current directory, i.e. C:\jboss\bin\run.bat instead cd \jboss\bin; run.bat, I have many problems with tomcat - it cant see any web-contents. JBoss-tomcat-3.20RC1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682384&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-682383 ] files lock(windows)
Bugs item #682383, was opened at 2003-02-07 17:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682383&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Alex Buloichik (alex73) Assigned to: Nobody/Anonymous (nobody) Summary: files lock(windows) Initial Comment: I can't remove application under windows(JBoss-romcat-3.20rc1), because JBoss locl files ejb-jar.xml and web.xml. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682383&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] AWT plug-in ClassNotFoundException
Anyone run into this problem before? There is a JAR file which is an AWT plug-in (i.e. used by the core system AWT classes), and AWT is throwing a ClassNotFoundException because it can't find the classes in this dependant JAR. We tried putting this JAR in every directory we can think of JRE/lib/ext, the server lib directory, the deploy directory, etc. with no luck. Has anyone dealt with this problem before? Thanks, Nathan --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS Snapshots not being updated?
I was recently noticing that the "last modified" timestamps for files in the CVS snapshots have 4/22/2002 as the last date anything in them was modified, which is consistent with the "last modified" timestamp on the snapshot itself. Are the snapshots not being updated anymore? It's impossible to do a CVS pull here at work as I'm behind the most fascist of firewalls, so a current snapshot's important to me. -- J. Rhett Aultman Business Technology Solutions FCCI Insurance Group --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote class loading servlet
You don't have to worry about the port or interface as these are attributes of the web server context the servlet is deployed to. You don't have to worry about class loaders. Just use the thread context class loader. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "James Cooley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 07, 2003 3:08 AM Subject: Re: [JBoss-dev] Remote class loading servlet > Hi Dain, > > I had a look at the class and it looks like it should be pretty easy > to do this in a servlet but the deployment may be an issue. The API > includes setPort, setBindAddress, etc. Is there an abstract factory to > create a Tomcat Connector/Jetty Adapter (or whatever the container may > be) at runtime? If not is is okay to just default to 8083 and configure > the port in the service xml config file? > > The problem is also complicated by the fact that we need to add and > remove ClassLoaders dynamically and WebService will no longer hold the > instance of WebServer (unless there is an abstract factory). > > You were looking for a volunteer and you get an essay :) > > James > > > Dain Sundstrom wrote: > > We have a small project open for a volunteer. In Jboss 2 and 3 we have > > a custom lightweight web server (port 8083) that returns java class > > files from the classLoader.getResouceAsStream to RMI clients (this is > > how remote class loading happens). I talked to Scott at JBoss Boot Camp > > and we think it is a good idea to replace this with a plain old Servlet > > for JBoss 4.0 so it can work with regular security, pooling and such. > > This is a fairly simple piece of code and shouldn't take longer then a > > day or two. If you are interested the code can be found in > > jboss-head/server/src/main/org/jboss/web/WebServer.java > > > > -dain > > > > > > > > --- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-574501 ] Unable to mix jdk 1.3 and 1.4 on w2k
Bugs item #574501, was opened at 2002-06-27 11:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=574501&group_id=22866 Category: Clustering Group: CVS HEAD >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: Unable to mix jdk 1.3 and 1.4 on w2k Initial Comment: Using jdk 1.3 and jdk 1.4 in the same cluster is not possible under windows 2000 (works with other OS). Issue posted on JavaGroups:analysis in progress (Bela). -- >Comment By: Sacha Labourey (slaboure) Date: 2003-02-07 16:05 Message: Logged In: YES user_id=95900 Does not seem to occur anymore under 3.0.6. Tested on the same w2k host and on distant hosts with JDK 1.3.0_02 and both jdk 1.4.0 and 1.4.1. Something has most probably been fixed in JavaGroups in the meantime. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=574501&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-682352 ] run-jboss target in build.xml doesn't work
Bugs item #682352, was opened at 2003-02-07 14:54
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682352&group_id=22866
Category: Build System
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rod Burgett (rodburgett)
Assigned to: Jason Dillon (user57)
Summary: run-jboss target in build.xml doesn't work
Initial Comment:
The run-jboss target in build.xml (3.2 and 4.0) execs
run.bat/sh. The run scripts work alone, but when using
build.xml the run.bat file complains about not being able
to find .\run.jar. This is because the build target
includes a 'dir="${run.home.dir}"' attribute, but the run.jar
is in run.bin.dir.
After this change, startup still fails. Now run.bat
complains about JAVA_HOME not being set.
JAVA_HOME is clearly set, otherwise ant would have
noticed. But run.bat can't see is because of the
'newenvironment="true"' attribute in the exec tag.
Attached is a diff with these changes.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682352&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-682243 ] 3.0.6 / HAJND: Unable to retrieve remote objects from HAJNDI
Bugs item #682243, was opened at 2003-02-07 11:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682243&group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Halil-C. Gürsoy (che---) >Assigned to: Sacha Labourey (slaboure) Summary: 3.0.6 / HAJND: Unable to retrieve remote objects from HAJNDI Initial Comment: I have a small test applikation for my small two/three machine cluster with a very simple SLSB and an Entity (CMP). The cluster is based on two linux boxes: SuSe 7.2 SUN JDK 1.4.1 JB 3.0.6 (standalone) Catalina 4.1.18 Red Hat HA 6 SUN J.D.K 1.4.1 JB 3.0.6 (standalone) Catalina 4.1.18 The third testing machine is a Win2k but with the same other things. The Web Application has some servlets which access the SB through it's remote interface (i don't use the JB / TC bundle!). All needed JAR's (like the jbossha-client.jar) are packed in the WAR, too. If i connect to JBoss through the local JNDI it functions very nice and i see round robin and fail over functions in the cluster without any problems. But, if i try to connect to the HA JNDI i have allways an exception. I tryied evrything: Autosense while getting in the client the initial context (not set the Context.PROVIDER_URL parameter), set the provider-url to "jnp://localhost:1100" etc. I have set the "loopback" attribute in the cluster settings to true, too, the i tried with on the Win2k machine. It looks like that autosensing functions but during the connection to the HAJNDI there is an error while getting the stub. The Exception is this (see full stack trace in the added file): Failed to look up EmployeeSession from JNDI Context javax.naming.CommunicationException: Failed to retrieve stub from server 192.168.67.65:1100. Root exception is java.io.StreamCorruptedException: unexpected block data at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1288) Thanks and bye Halil -- >Comment By: Sacha Labourey (slaboure) Date: 2003-02-07 15:50 Message: Logged In: YES user_id=95900 You say "I have a small test applikation for my small two/three machine cluster with a very simple SLSB and an Entity (CMP). " I would love to get your test application so that I can debug more efficiently. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682243&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Feature Requests-682345 ] JBossIDE: Integrate Log4j GUI tools
Feature Requests item #682345, was opened at 2003-02-07 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376688&aid=682345&group_id=22866 Category: Other Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: JBossIDE: Integrate Log4j GUI tools Initial Comment: Hans & JBossIDE folks -- This is a great project. Thanks for everything you've done. Here's an idea I had that you may want to use. Currently, the server logs are redirected to the Eclipse console. All of the server logs are log4j logs, AFAICT, so it should be possible to redirect these logs to one of the available log4j GUIs. There are two, I believe, that come bundled with log4j -- LogFactor5, and Chainsaw. I've used both and find them both to be useful. Since we know that the users are using a GUI when they use JBossIDE, it makes sense to use a GUI-based log reporting tool, instead of the console. - Matt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376688&aid=682345&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote class loading servlet
Hi Dain, I had a look at the class and it looks like it should be pretty easy to do this in a servlet but the deployment may be an issue. The API includes setPort, setBindAddress, etc. Is there an abstract factory to create a Tomcat Connector/Jetty Adapter (or whatever the container may be) at runtime? If not is is okay to just default to 8083 and configure the port in the service xml config file? The problem is also complicated by the fact that we need to add and remove ClassLoaders dynamically and WebService will no longer hold the instance of WebServer (unless there is an abstract factory). You were looking for a volunteer and you get an essay :) James Dain Sundstrom wrote: We have a small project open for a volunteer. In Jboss 2 and 3 we have a custom lightweight web server (port 8083) that returns java class files from the classLoader.getResouceAsStream to RMI clients (this is how remote class loading happens). I talked to Scott at JBoss Boot Camp and we think it is a good idea to replace this with a plain old Servlet for JBoss 4.0 so it can work with regular security, pooling and such. This is a fairly simple piece of code and shouldn't take longer then a day or two. If you are interested the code can be found in jboss-head/server/src/main/org/jboss/web/WebServer.java -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-682243 ] 3.0.6 / HAJND: Unable to retrieve remote objects from HAJNDI
Bugs item #682243, was opened at 2003-02-07 11:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682243&group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Halil-C. Gürsoy (che---) Assigned to: Nobody/Anonymous (nobody) Summary: 3.0.6 / HAJND: Unable to retrieve remote objects from HAJNDI Initial Comment: I have a small test applikation for my small two/three machine cluster with a very simple SLSB and an Entity (CMP). The cluster is based on two linux boxes: SuSe 7.2 SUN JDK 1.4.1 JB 3.0.6 (standalone) Catalina 4.1.18 Red Hat HA 6 SUN J.D.K 1.4.1 JB 3.0.6 (standalone) Catalina 4.1.18 The third testing machine is a Win2k but with the same other things. The Web Application has some servlets which access the SB through it's remote interface (i don't use the JB / TC bundle!). All needed JAR's (like the jbossha-client.jar) are packed in the WAR, too. If i connect to JBoss through the local JNDI it functions very nice and i see round robin and fail over functions in the cluster without any problems. But, if i try to connect to the HA JNDI i have allways an exception. I tryied evrything: Autosense while getting in the client the initial context (not set the Context.PROVIDER_URL parameter), set the provider-url to "jnp://localhost:1100" etc. I have set the "loopback" attribute in the cluster settings to true, too, the i tried with on the Win2k machine. It looks like that autosensing functions but during the connection to the HAJNDI there is an error while getting the stub. The Exception is this (see full stack trace in the added file): Failed to look up EmployeeSession from JNDI Context javax.naming.CommunicationException: Failed to retrieve stub from server 192.168.67.65:1100. Root exception is java.io.StreamCorruptedException: unexpected block data at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1288) Thanks and bye Halil -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682243&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNP directory support?
Howdy, I'm considering using the JNP server as a standalone component in a j2se project. For my purposes it would be nice to have directory support, so that I can store/search-on attributes. I noticed that JNP doesn't support this. Having pawed through the code a bit, I believe I could add basic DirContext support without too much trouble. My questions are: Has this been done already? Is this useful to anybody else? Is there something absurd about this endeavor that hasn't occured to me? It seems to me that having a free, standalone JNDI implemenation with directory support would be a good thing. Thanks, Jim --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
