June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1290) Upgrade Marshalling to 1.4.11.Final

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1290?page=com.atlassian.jira.plugi... ] Tomaz Cerar resolved WFCORE-1290. --------------------------------- Fix Version/s: 2.2.0.CR4 3.0.0.Alpha3 Assignee: Tomaz Cerar (was: David Lloyd) Resolution: Done > Upgrade Marshalling to 1.4.11.Final > ----------------------------------- > > Key: WFCORE-1290 > URL: https://issues.jboss.org/browse/WFCORE-1290 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Radoslav Husar > Assignee: Tomaz Cerar > Fix For: 2.2.0.CR4, 3.0.0.Alpha3 > > > Change log https://issues.jboss.org/projects/JBMAR/versions/12329371 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1349) Upgrate JBoss Marshalling to >= 1.4.11.Final

by Andrea Cosentino (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1349?page=com.atlassian.jira.plugi... ] Andrea Cosentino commented on WFCORE-1349: ------------------------------------------ Ok, no you don't need this PR. > Upgrate JBoss Marshalling to >= 1.4.11.Final > -------------------------------------------- > > Key: WFCORE-1349 > URL: https://issues.jboss.org/browse/WFCORE-1349 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: David Lloyd > Assignee: Andrea Cosentino > Fix For: 3.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1349) Upgrate JBoss Marshalling to >= 1.4.11.Final

by Andrea Cosentino (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1349?page=com.atlassian.jira.plugi... ] Andrea Cosentino commented on WFCORE-1349: ------------------------------------------ Do you want me to change the issue ID in the Pull Request? > Upgrate JBoss Marshalling to >= 1.4.11.Final > -------------------------------------------- > > Key: WFCORE-1349 > URL: https://issues.jboss.org/browse/WFCORE-1349 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: David Lloyd > Assignee: Andrea Cosentino > Fix For: 3.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1349) Upgrate JBoss Marshalling to >= 1.4.11.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1349?page=com.atlassian.jira.plugi... ] Radoslav Husar closed WFCORE-1349. ---------------------------------- Resolution: Duplicate Issue Duplicates WFCORE-1290. > Upgrate JBoss Marshalling to >= 1.4.11.Final > -------------------------------------------- > > Key: WFCORE-1349 > URL: https://issues.jboss.org/browse/WFCORE-1349 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: David Lloyd > Assignee: Andrea Cosentino > Fix For: 3.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1615) Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh (WFCORE-1121)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1615?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-1615: ----------------------------------- Assignee: (was: Tomaz Cerar) > Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh (WFCORE-1121) > -------------------------------------------------------------------------------- > > Key: WFCORE-1615 > URL: https://issues.jboss.org/browse/WFCORE-1615 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Affects Versions: 3.0.0.Alpha2 > Reporter: Jorge Solorzano > Priority: Trivial > > To make both scripts more consistent in terms of functionality, WFCORE-1121 apply changes to wildfly-init-redhat.sh scripts but not to wildfly-init-debian.sh. This jira is to mimic the change back to wildfly-init-debian.sh -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6733) Improve toString() representation of web session cache keys (org.wildfly.clustering.infinispan.spi.distribution.Key subclasses)

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6733?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6733: --------------------------------- Fix Version/s: 11.0.0.Alpha1 > Improve toString() representation of web session cache keys (org.wildfly.clustering.infinispan.spi.distribution.Key subclasses) > ------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6733 > URL: https://issues.jboss.org/browse/WFLY-6733 > Project: WildFly > Issue Type: Enhancement > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 11.0.0.Alpha1 > > > See JBEAP-4757. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1349) Upgrate JBoss Marshalling to >= 1.4.11.Final

by Andrea Cosentino (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1349?page=com.atlassian.jira.plugi... ] Andrea Cosentino reassigned WFCORE-1349: ---------------------------------------- Assignee: Andrea Cosentino > Upgrate JBoss Marshalling to >= 1.4.11.Final > -------------------------------------------- > > Key: WFCORE-1349 > URL: https://issues.jboss.org/browse/WFCORE-1349 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: David Lloyd > Assignee: Andrea Cosentino > Fix For: 3.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6763) Upgrade HAL to 2.8.26.Final

by Vladimir Dosoudil (JIRA)

Vladimir Dosoudil created WFLY-6763: --------------------------------------- Summary: Upgrade HAL to 2.8.26.Final Key: WFLY-6763 URL: https://issues.jboss.org/browse/WFLY-6763 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Vladimir Dosoudil Assignee: Harald Pehl -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1212) Input stream finalized or forced closed during server startup

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1212?page=com.atlassian.jira.plugi... ] Petr Široký reassigned DROOLS-1212: ----------------------------------- Assignee: Petr Široký (was: Mario Fusco) > Input stream finalized or forced closed during server startup > ------------------------------------------------------------- > > Key: DROOLS-1212 > URL: https://issues.jboss.org/browse/DROOLS-1212 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: Glassfish 4.1.1 > Reporter: Fernando Machado > Assignee: Petr Široký > > I'm getting some exceptions during GF4 startup related with _"Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace"_ and it seems similar to DROOLS-812. > org.drools.template.parser.DefaultTemplateRuleBase.readKnowledgeBase(String) > {code} > private InternalKnowledgeBase readKnowledgeBase(String drl) { > try { > // logger.info(drl); > // read in the source > Reader source = new StringReader(drl); > KnowledgeBuilderImpl builder = new KnowledgeBuilderImpl(); > builder.addPackageFromDrl(source); > InternalKnowledgePackage pkg = builder.getPackage(); > // add the package to a rulebase (deploy the rule package). > InternalKnowledgeBase kBase = (InternalKnowledgeBase) KnowledgeBaseFactory.newKnowledgeBase(); > kBase.addPackage(pkg); > return kBase; > } catch (Exception e) { > throw new RuntimeException(e); > } > } > {code} > Is related with: > {noformat} > [#|2016-06-15T13:51:07.671+0200|WARNING|glassfish 4.1|javax.enterprise.system.util|_ThreadID=74442;_ThreadName=RunLevelControllerThread-1465991462855;_TimeMillis=1465991467671;_LevelValue=900;_MessageID=NCLS-COMUTIL-00023;|Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace > java.lang.Throwable > at org.drools.template.parser.DefaultTemplateRuleBase.readKnowledgeBase(DefaultTemplateRuleBase.java:133) > at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:56) > at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74) > at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:50) > at org.drools.template.ObjectDataCompiler.compile(ObjectDataCompiler.java:57) > at com.mycompany.mypackage.MyClass.init(MyClass.java:xxx) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1035) > at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72) > at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) > at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986) > at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72) > at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205) > at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163) > at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986) > at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72) > at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:412) > at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375) > at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:2014) > at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:468) > at com.sun.ejb.containers.AbstractSingletonContainer.access$000(AbstractSingletonContainer.java:74) > at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:647) > at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:389) > at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:219) > at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:180) > at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:158) > ... > {noformat} > There is another class that is also throwing the same exception: > {noformat} > [#|2016-06-14T11:08:19.953+0200|WARNING|glassfish 4.1|javax.enterprise.system.util|_ThreadID=68093;_ThreadName=RunLevelControllerThread-1465895294550;_TimeMillis=1465895299953;_LevelValue=900;_MessageID=NCLS-COMUTIL-00023;|Input stream has been finalized or forced closed without being explicitly closed; > stream instantiation reported in following stack trace > java.lang.Throwable > at com.sun.enterprise.loader.ASURLClassLoader$SentinelInputStream.<init>(ASURLClassLoader.java:1278) > at com.sun.enterprise.loader.ASURLClassLoader$InternalJarURLConnection.getInputStream(ASURLClassLoader.java:1386) > at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:238) > at com.sun.enterprise.loader.ASURLClassLoader.getResourceAsStream(ASURLClassLoader.java:930) > at java.lang.Class.getResourceAsStream(Class.java:2223) > at org.eclipse.jdt.internal.compiler.parser.Parser.readReadableNameTable(Parser.java:719) > at org.eclipse.jdt.internal.compiler.parser.Parser.initTables(Parser.java:615) > at org.eclipse.jdt.internal.compiler.parser.Parser.<clinit>(Parser.java:124) > at org.eclipse.jdt.internal.compiler.Compiler.initializeParser(Compiler.java:687) > at org.eclipse.jdt.internal.compiler.Compiler.<init>(Compiler.java:285) > at org.eclipse.jdt.internal.compiler.Compiler.<init>(Compiler.java:206) > at org.drools.compiler.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:416) > at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49) > at org.drools.compiler.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:417) > at org.drools.compiler.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:61) > at org.drools.compiler.compiler.PackageRegistry.compileAll(PackageRegistry.java:138) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAll(KnowledgeBuilderImpl.java:1314) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:953) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackage(KnowledgeBuilderImpl.java:944) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:363) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addPackageFromDrl(KnowledgeBuilderImpl.java:339) > at org.drools.template.parser.DefaultTemplateRuleBase.readKnowledgeBase(DefaultTemplateRuleBase.java:133) > at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:56) > at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74) > at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:50) > at org.drools.template.ObjectDataCompiler.compile(ObjectDataCompiler.java:57) > at com.mycompany.mypackage.MyClass.init(MyClass.java:xxx) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1035) > at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72) > at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) > at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986) > at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72) > at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205) > at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163) > at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986) > at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72) > at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:412) > at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375) > at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:2014) > at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:468) > at com.sun.ejb.containers.AbstractSingletonContainer.access$000(AbstractSingletonContainer.java:74) > at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:647) > at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:389) > at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:219) > at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:180) > at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:158) > at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:166) > ... > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6762) Is Network Disabling on a Node, a valid test scenario for testing Cluster Failover

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-6762?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla updated WFLY-6762: ----------------------------------- Description: In your mail related to WFLY-6749 you has said the below :- *The default stack contains the following failure detection protocols: FD_SOCK FD_ALL These protocols are described here: http://www.jgroups.org/manual/index.html#FailureDetection I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property. e.g. <protocol type="FD_ALL" ><property name="timeout">60000</property></protocol> * Thanks for the quick response on WFLY-6749. Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster. The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster. However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node. Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster. Thanks, Preeta > Is Network Disabling on a Node, a valid test scenario for testing Cluster Failover > ---------------------------------------------------------------------------------- > > Key: WFLY-6762 > URL: https://issues.jboss.org/browse/WFLY-6762 > Project: WildFly > Issue Type: CTS Challenge > Components: Clustering > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Paul Ferraro > Priority: Critical > > In your mail related to WFLY-6749 you has said the below :- > *The default stack contains the following failure detection protocols: > FD_SOCK > FD_ALL > These protocols are described here: > http://www.jgroups.org/manual/index.html#FailureDetection > I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property. > e.g. > <protocol type="FD_ALL" ><property name="timeout">60000</property></protocol> > * > Thanks for the quick response on WFLY-6749. > Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster. > The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster. > However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node. > Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster. > Thanks, > Preeta -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016