November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-784) local_addr is null when reconnecting.

by Robert Newson (JIRA)

local_addr is null when reconnecting. ------------------------------------- Key: JGRP-784 URL: http://jira.jboss.com/jira/browse/JGRP-784 Project: JGroups Issue Type: Bug Affects Versions: 2.6.2 Reporter: Robert Newson Assigned To: Bela Ban After shunning, a channel never manages to reconnect (with AUTO_RECONNECT) successfully, reporting this endlessly; org.jgroups.ChannelException: local_addr is null at org.jgroups.JChannel.startStack(JChannel.java:1556) at org.jgroups.JChannel.connect(JChannel.java:364) at org.jgroups.JChannel$CloserThread.run(JChannel.java:1908) 2008-06-10 12:04:31,784 FATAL [CloserThread] jgroups.JChannel (JChannel.java:1555) - local_addr is null; cannot connect 2008-06-10 12:04:31,784 ERROR [CloserThread] jgroups.JChannel$CloserThread (JChannel.java:1912) - failure reconnecting to c hannel, retrying -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 9 months

5
8
0 / 0

[JBoss JIRA] Created: (JBAS-4043) Allow webapps for different tomcat services to deployed in the same .ear

by Martin Welss (JIRA)

Allow webapps for different tomcat services to deployed in the same .ear ------------------------------------------------------------------------ Key: JBAS-4043 URL: http://jira.jboss.com/jira/browse/JBAS-4043 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-4.0.5.GA Environment: jboss with embedded tomcat configured with 2 services, like in JBAS-2410 Reporter: Martin Welss Assigned To: Dimitris Andreadis The second tomcat service has its own deployment directory, so the deployment has to be splitted into two separate files. This causes timing problems (NoClassDefFoundError), because our ejb3 application takes amch longer to deploy than our webapp. Maybe a new tag in jbossweb.xml could target the webapp to the respective tomcat-service -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-381) VFSClassLoaderPolicy->getProtectionDomain does not yet handle certificates

by Anil Saldhana (JIRA)

VFSClassLoaderPolicy->getProtectionDomain does not yet handle certificates -------------------------------------------------------------------------- Key: JBMICROCONT-381 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-381 Project: JBoss Microcontainer Issue Type: Sub-task Reporter: Anil Saldhana Assignee: Adrian Brock http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloadi... =================== @Override protected ProtectionDomain getProtectionDomain(String className, String path) { VirtualFile clazz = findChild(path); if (clazz == null) { log.trace("Unable to determine class file for " + className); return null; } try { VirtualFile root = findRoot(path); URL codeSourceURL = root.toURL(); Certificate[] certs = null; // TODO JBMICROCONT-182 determine certificates CodeSource cs = new CodeSource(codeSourceURL, certs); PermissionCollection permissions = Policy.getPolicy().getPermissions(cs); return new ProtectionDomain(cs, permissions); } catch (Exception e) { throw new Error("Error determining protection domain for " + clazz, e); } } ====================================================== Please move this jira issue to appropriate project and assign appropriate version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

3
9
0 / 0

[JBoss JIRA] Created: (JBCL-24) Circular dependencies

by Adrian Brock (JIRA)

Circular dependencies --------------------- Key: JBCL-24 URL: https://jira.jboss.org/jira/browse/JBCL-24 Project: JBoss ClassLoader Issue Type: Task Components: Dependencies Reporter: Adrian Brock Test and add support for circular dependencies. This basically involves some of kind of hack to pretend the dependency is resolved when we spot the real blockage is a classloader either directly or indirectly depending upon itself with all other dependencies in the classloading space resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBWEB-101) Thread handle leak using Jboss Web native connectors on Windows

by Mike Poindexter (JIRA)

Thread handle leak using Jboss Web native connectors on Windows --------------------------------------------------------------- Key: JBWEB-101 URL: http://jira.jboss.com/jira/browse/JBWEB-101 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBoss Web Server 1.0.1 GA Reporter: Mike Poindexter Assigned To: Mladen Turk When running JBossWeb using the native connectors under Windows XP/Win2k3 I'm seeing a Thread Handles leak. I've traced this with the !htrace feature of CDB (like at http://blogs.technet.com/brad_rutkowski/archive/2007/11/13/got-a-handle-l...). It appears as though this is the behavior reported at https://issues.apache.org/bugzilla/show_bug.cgi?id=42728. The native stack trace from the leaked handles looks like: Handle = 0x00000c64 - OPEN Thread ID = 0x00001014, Process ID = 0x00003e44 0x2c2d624c: libapr_1!apr_os_thread_current+0x0000003c 0x2c339202: LIBEAY32!ERR_remove_state+0x00000062 0x7c9011a7: ntdll!LdrInitializeThunk+0x00000029 0x7c919213: ntdll!LdrShutdownThread+0x000000ed 0x7c80c096: kernel32!ExitThread+0x0000003e 0x7c87545b: kernel32!GetConsoleCharType+0x000002a8 0x7c80b683: kernel32!GetModuleFileNameA+0x000001b4 >From what I can tell, the end result is that one thread handle leaks per JVM thread that terminates. Over the course of a long running server application, this becomes a major leak. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

3
10
0 / 0

[JBoss JIRA] Created: (EJBTHREE-978) Deployer should ignore files that Javassist throws a "non class file" exception for

by Josh Devins (JIRA)

Deployer should ignore files that Javassist throws a "non class file" exception for ----------------------------------------------------------------------------------- Key: EJBTHREE-978 URL: http://jira.jboss.com/jira/browse/EJBTHREE-978 Project: EJB 3.0 Issue Type: Bug Environment: JBoss 4.0.5 GA with EJB3 deployer and IBM DB2 JDBC driver v3.3.54 Reporter: Josh Devins This is a follow-up to a Javassist issue # JASSIST-34. For some reason, the IBM DB2 JDBC jar file contains a class that does not start with the magic code "0xCAFEBABE". When the EJB3 deployer looks at this jar file and scans the classes in it, Javassist is throwing an IOException with message "non class file". This is entirely useless to the end user since there is no information given about what class file or jar file is in error. Javassist should be throwing a more descriptive exception (as per the issue JASSIST-34), and the EJB3 deployer should simply skip that file and output a warning telling the user/developer what jar file and class was in error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3405) Unable to secure JMX Invoker

by amdonov (JIRA)

Unable to secure JMX Invoker ---------------------------- Key: JBAS-3405 URL: http://jira.jboss.com/jira/browse/JBAS-3405 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.3 SP1 Environment: Windows Sun JDK 1.5 Reporter: amdonov I am having the same problem securing the JMX invoker as the user in the referenced forum thread. However, I'm running 4.0.4.GA instead of 4.0.3 SP1. When, performing a clean installation using the installer. I selected the default configuration and elected to secure the invokers. The install completes without error. JBoss has the following error which is unfortunatly only written at the DEBUG level. 2006-07-20 10:40:47,541 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker) at java.lang.Class.getConstructor0(Class.java:2647) at java.lang.Class.getConstructor(Class.java:1629) at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739) at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678) at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400) at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504) at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486) at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350) at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345) at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181) at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171) at org.jboss.system.ServiceController.install(ServiceController.java:226) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.install(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy6.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:464) at java.lang.Thread.run(Thread.java:595) 2006-07-20 10:40:47,551 DEBUG [org.jboss.system.ServiceCreator] Created bean: Access to the adaptors is not restricted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3524) Support Kerberos authentication in CSIv2

by David Robison (JIRA)

Support Kerberos authentication in CSIv2 ---------------------------------------- Key: JBAS-3524 URL: http://jira.jboss.com/jira/browse/JBAS-3524 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: IIOP service Affects Versions: JBossAS-4.0.4.GA Environment: JBoss 4.0.4.GA Reporter: David Robison Assigned To: Francisco Reverbel JacORB supports Kerberos Authentication as part of its SAS implementation. I would be useful for JBoss to support it as part of his JBoss CSIv2 implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-3644) ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster

by anajavi (JIRA)

ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster ---------------------------------------------------------------------------- Key: JBAS-3644 URL: http://jira.jboss.com/jira/browse/JBAS-3644 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: CMP service Affects Versions: JBossAS-4.0.3 SP1 Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0) Reporter: anajavi Assigned To: Alexey Loubyansky Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index. Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query). I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need. I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR). I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help. Example: Original EJBQL: SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2 Generated SQL: SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite FROM rooli t0_o LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa' 10x faster SQL: SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite FROM rooli t0_o INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa' Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-5354) Need to improve error handling around thread pool errors

by Adrian Brock (JIRA)

Need to improve error handling around thread pool errors -------------------------------------------------------- Key: JBAS-5354 URL: http://jira.jboss.com/jira/browse/JBAS-5354 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-4.2.3.GA The related JBCOMMON-47 shows JBossMQ is not gracefully handling thread pool errors in ClientConsumer::queueMessageForSending() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

2
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2008