March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6619) Management API for Datasources subsystem is missing some properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6619?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6619: ---------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 915288|https://bugzilla.redhat.com/show_bug.cgi?id=915288] from NEW to MODIFIED > Management API for Datasources subsystem is missing some properties > ------------------------------------------------------------------- > > Key: AS7-6619 > URL: https://issues.jboss.org/browse/AS7-6619 > Project: Application Server 7 > Issue Type: Bug > Components: JCA > Affects Versions: 7.2.0.Alpha1 > Reporter: Zbyněk Roubalík > Assignee: Stefano Maestri > > Some properties which were present in previous versions of AS7 are missing in current release: > Parameter driver-name for operation 'get-installed-driver' is no longer available. > These value-type for 'reply-properties' for operation 'get-installed-driver' are no longer available: [jdbc-compliant, module-slot, driver-class-name, driver-module-name] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6580) Do not add transitive dependency to deployments for system dependencies or user dependencies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6580?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6580: ---------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 913321|https://bugzilla.redhat.com/show_bug.cgi?id=913321] from NEW to MODIFIED > Do not add transitive dependency to deployments for system dependencies or user dependencies > -------------------------------------------------------------------------------------------- > > Key: AS7-6580 > URL: https://issues.jboss.org/browse/AS7-6580 > Project: Application Server 7 > Issue Type: Bug > Components: Class Loading > Reporter: James Perkins > Assignee: James Perkins > Fix For: 8.0.0.Alpha1 > > > Currently the {{ModuleSpecProcessor}} adds transitive dependencies to a deployment if the module spec is specified to add them (looks like only RAR's from what I can see). This includes transitive dependencies that are declared in a {{jboss-deployment-structure.xml}} or ones automatically added by the container. > Change to only allow class-path entries to be transitive if the module spec defines they should be. System and user specified dependencies should not be transitive. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6580) Do not add transitive dependency to deployments for system dependencies or user dependencies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6580?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6580: ---------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> made a comment on [bug 913321|https://bugzilla.redhat.com/show_bug.cgi?id=913321] Merged https://github.com/jbossas/jboss-eap/pull/11. > Do not add transitive dependency to deployments for system dependencies or user dependencies > -------------------------------------------------------------------------------------------- > > Key: AS7-6580 > URL: https://issues.jboss.org/browse/AS7-6580 > Project: Application Server 7 > Issue Type: Bug > Components: Class Loading > Reporter: James Perkins > Assignee: James Perkins > Fix For: 8.0.0.Alpha1 > > > Currently the {{ModuleSpecProcessor}} adds transitive dependencies to a deployment if the module spec is specified to add them (looks like only RAR's from what I can see). This includes transitive dependencies that are declared in a {{jboss-deployment-structure.xml}} or ones automatically added by the container. > Change to only allow class-path entries to be transitive if the module spec defines they should be. System and user specified dependencies should not be transitive. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6010) After redeploy an application to a domain the old content is not removed at slave host

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6010?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6010: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > After redeploy an application to a domain the old content is not removed at slave host > -------------------------------------------------------------------------------------- > > Key: AS7-6010 > URL: https://issues.jboss.org/browse/AS7-6010 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.2.0.Alpha1 > Environment: OS Fedora17 > Two instances in domain mode. > DC without server > HC with one server > Reporter: Wolf-Dieter Fink > Assignee: Emanuel Muckenhuber > Labels: deployment, domain, host-controller > Fix For: 8.0.0.Alpha1 > > > If an application deployed on a domain slave HC the content is not removed if a new version of the application is deployed with 'deploy xxx --force' > The logfile looks correct and shows: > JBAS018565: Replaced deployment "appone.ear" with deployment "appone.ear" > JBAS014901: Content removed from location /.../domain/servers/server-one/data/content/5e/c06cd5b58b1b6578188d822b351a14f974804c/content > If the folder is checked the file still exists. > An undeploy remove the files correct with the same log messages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6678) show help usage when determining the host-controller environment fails

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6678?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6678: ---------------------------------------------- emuckenh(a)redhat.com changed the Status of [bug 913581|https://bugzilla.redhat.com/show_bug.cgi?id=913581] from ASSIGNED to POST > show help usage when determining the host-controller environment fails > ---------------------------------------------------------------------- > > Key: AS7-6678 > URL: https://issues.jboss.org/browse/AS7-6678 > Project: Application Server 7 > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 7.1.3.Final (EAP) > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Alpha1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-370) Add Notification support to the domain management API

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/AS7-370?page=com.atlassian.jira.plugin.sy... ] Jeff Mesnil updated AS7-370: ---------------------------- Assignee: Jeff Mesnil (was: Alexey Loubyansky) Fix Version/s: 8.0.0.Alpha1 > Add Notification support to the domain management API > ----------------------------------------------------- > > Key: AS7-370 > URL: https://issues.jboss.org/browse/AS7-370 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Fix For: 7.3.0.Alpha1, 8.0.0.Alpha1 > > > Management resource should be able to emit notifications; clients can register listeners. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-370) Add Notification support to the domain management API

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/AS7-370?page=com.atlassian.jira.plugin.sy... ] Jeff Mesnil commented on AS7-370: --------------------------------- https://community.jboss.org/wiki/AddNotificationSupportToTheDomainManagem... > Add Notification support to the domain management API > ----------------------------------------------------- > > Key: AS7-370 > URL: https://issues.jboss.org/browse/AS7-370 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Alexey Loubyansky > Fix For: 7.3.0.Alpha1 > > > Management resource should be able to emit notifications; clients can register listeners. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on AspectManager

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.... ] Aaron Ogburn edited comment on JBMESSAGING-1941 at 3/5/13 12:49 PM: -------------------------------------------------------------------- Saw another occurrence of this. It's a bit different but fundamentally the same: {noformat} "WorkManager(2)-2" daemon prio=10 tid=0x000000004079b000 nid=0x1f99 waiting for monitor entry [0x00007f2d94a00000] java.lang.Thread.State: BLOCKED (on object monitor) at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728) - waiting to lock <0x000000077039a500> (a org.jboss.aop.AspectManager) at org.jboss.jms.client.delegate.ClientConnectionDelegate.<clinit>(ClientConnectionDelegate.java) <-- native classloader lock grabbed at org.jboss.jms.delegate.CreateConnectionResult.read(CreateConnectionResult.java:106) at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateResponse.read(ConnectionFactoryCreateConnectionDelegateResponse.java:71) at org.jboss.jms.wireformat.JMSWireFormat.read(JMSWireFormat.java:298) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1301) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:907) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:461) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:167) at org.jboss.remoting.Client.invoke(Client.java:2034) at org.jboss.remoting.Client.invoke(Client.java:877) "WorkManager(2)-3" daemon prio=10 tid=0x00007f2d9811d000 nid=0x2003 in Object.wait() [0x00007f2d94125000] java.lang.Thread.State: RUNNABLE at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:296) <-- waiting for that native cl lock - locked <0x000000077039a500> (a org.jboss.aop.AspectManager) at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:170) at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.org$jboss$jms$server$endpoint$advised$ConnectionFactoryAdvised$createConnectionDelegate$aop(ConnectionFactoryAdvised.java:108) at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.createConnectionDelegate(ConnectionFactoryAdvised.java) at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateRequest.serverInvoke(ConnectionFactoryCreateConnectionDelegateRequest.java:91) at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157) {noformat} So we're deadlocked still on the same locks. WorkManager(2)-2 is grabbing the native cl lock then the AspectManager, while WorkManager(2)-3 grabs the AspectManager then the native cl lock. I think the problem is the AspectManager synchronization that was added in JBMESSAGING-797 as a JBM level workaround for JBAOP-360. I think this was fine until synchronization was added in AOP to fix JBAOP-360 as well, and that AOP level fix is in EAP 5 now to conflict with that prior messaging fix. JBAOP-360 resulted in AspectManager.getAdvisor being made a synchronized method and would address the issue without JBMESSAGING-797. JBAOP-360 and JBMESSAGING-797 together though causes the issue as it introduces potential inverse use of the AspectManager and native cl lock. The synchronization in AspectManager has been changed even further beyond JBAOP-360 (by JBAOP-501 & JBAOP-653 for instance), but it seems pretty clear the synchronization we have in place from JBMESSAGING-797 is a relic at this point not necessarily needed any longer with the current AOP branch used on EAP 5. Can we remove the JBMESSAGING-797 changes to address this issue? If any AOP deadlock were to crop back up similar to JBMESSAGING-797, then I think it should be fixed in AOP. was (Author: aogburn): Saw another occurrence of this. It's a bit different but fundamentally the same: {noformat} "WorkManager(2)-2" daemon prio=10 tid=0x000000004079b000 nid=0x1f99 waiting for monitor entry [0x00007f2d94a00000] java.lang.Thread.State: BLOCKED (on object monitor) at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728) - waiting to lock <0x000000077039a500> (a org.jboss.aop.AspectManager) at org.jboss.jms.client.delegate.ClientConnectionDelegate.<clinit>(ClientConnectionDelegate.java) <-- native classloader lock grabbed at org.jboss.jms.delegate.CreateConnectionResult.read(CreateConnectionResult.java:106) at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateResponse.read(ConnectionFactoryCreateConnectionDelegateResponse.java:71) at org.jboss.jms.wireformat.JMSWireFormat.read(JMSWireFormat.java:298) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1301) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:907) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:461) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:167) at org.jboss.remoting.Client.invoke(Client.java:2034) at org.jboss.remoting.Client.invoke(Client.java:877) "WorkManager(2)-3" daemon prio=10 tid=0x00007f2d9811d000 nid=0x2003 in Object.wait() [0x00007f2d94125000] java.lang.Thread.State: RUNNABLE at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:296) <-- waiting for that native cl lock - locked <0x000000077039a500> (a org.jboss.aop.AspectManager) at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:170) at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.org$jboss$jms$server$endpoint$advised$ConnectionFactoryAdvised$createConnectionDelegate$aop(ConnectionFactoryAdvised.java:108) at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.createConnectionDelegate(ConnectionFactoryAdvised.java) at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateRequest.serverInvoke(ConnectionFactoryCreateConnectionDelegateRequest.java:91) at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157) {noformat} So we're deadlocked still on the same locks. WorkManager(2)-2 is grabbing the native cl lock then the AspectManager, while WorkManager(2)-3 grabs the AspectManager then the native cl lock. I think the problem is the AspectManager synchronization that was added in JBMESSAGING-797 as a JBM level workaround for JBAOP-360. I think this was fine until synchronization was added in AOP to fix JBAOP-360 as well, and that AOP level fix is in EAP 5 now to conflict with that prior messaging fix. JBAOP-360 resulted in AspectManager.getAdvisor being made a synchronized method and should address the issue without JBMESSAGING-797. JBAOP-360 and JBMESSAGING-797 together though causes the issue as it introduces potential inverse use of the AspectManager and native cl lock. Can we remove the JBMESSAGING-797 changes to address this issue? > Messaging deadlocks on AspectManager > ------------------------------------ > > Key: JBMESSAGING-1941 > URL: https://issues.jboss.org/browse/JBMESSAGING-1941 > Project: JBoss Messaging > Issue Type: Bug > Affects Versions: 1.4.8.SP9 > Environment: -JBoss Enterprise Application Platform (EAP) 5 > Reporter: Aaron Ogburn > Attachments: 00779442testpatch.diff > > > Messaging can stall JBoss at start up. The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock: > {noformat} > "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728) > - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager) > at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java) > at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273) > - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain) > at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229) > {noformat} > Since the main thread is stalled, so too is start up. This lock is always held by another making a similar call like so: > {noformat} > "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in > Object.wait() [0x00007fe68029a000] > java.lang.Thread.State: RUNNABLE > at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273) > - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager) > at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229) > {noformat} > The code there at line 273 is simple enough and shouldn't cause a long stall: > {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid} > synchronized (AspectManager.instance()) > { > advised = new SessionAdvised(ep); // line 273 > } > {code} > Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses. There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait(). Checking the thread through pstack, we can see the issue. It is waiting in native/JDK level operations required to initialize the SessionAdvised class: > {noformat} > Thread 2 (Thread 0x7fe68029d700 (LWP 13886)): > #0 0x0000003b3e40b43c in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0 > #1 0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so > #2 0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so > #3 0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so > #4 0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so > #5 0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so > #6 0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so > {noformat} > These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time. Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is. But the main thread is still blocked for the AspectManager lock. > So we have a deadlock here. The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock. > The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock. It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager. This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6665) Avoid creation of ConstraintMapping in LazyValidatorFactory

by Gunnar Morling (JIRA)

[ https://issues.jboss.org/browse/AS7-6665?page=com.atlassian.jira.plugin.s... ] Gunnar Morling commented on AS7-6665: ------------------------------------- We also need to implement the new method {{ValidatorFactory#getParameterNameProvider()}}. > Avoid creation of ConstraintMapping in LazyValidatorFactory > ----------------------------------------------------------- > > Key: AS7-6665 > URL: https://issues.jboss.org/browse/AS7-6665 > Project: Application Server 7 > Issue Type: Task > Components: JPA / Hibernate > Affects Versions: 7.1.3.Final (EAP) > Reporter: Gunnar Morling > Assignee: Scott Marlow > > As discussed with @smarlow, the call to {{new ConstraintMapping()}} in [LazyValidatorFactory|https://github.com/jbossas/jboss-as/blob/master/ee/s...] needs to be removed as it makes it impossible to use Hibernate Validator 5 with AS. > I'm going to create a pull request for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6580) Do not add transitive dependency to deployments for system dependencies or user dependencies

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6580?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6580: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 (was: 7.3.0.Alpha1) > Do not add transitive dependency to deployments for system dependencies or user dependencies > -------------------------------------------------------------------------------------------- > > Key: AS7-6580 > URL: https://issues.jboss.org/browse/AS7-6580 > Project: Application Server 7 > Issue Type: Bug > Components: Class Loading > Reporter: James Perkins > Assignee: James Perkins > Fix For: 8.0.0.Alpha1 > > > Currently the {{ModuleSpecProcessor}} adds transitive dependencies to a deployment if the module spec is specified to add them (looks like only RAR's from what I can see). This includes transitive dependencies that are declared in a {{jboss-deployment-structure.xml}} or ones automatically added by the container. > Change to only allow class-path entries to be transitive if the module spec defines they should be. System and user specified dependencies should not be transitive. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
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 March 2013