[JBoss JIRA] Created: (JBAS-4629) Optimized replication of entities and extended persistence context in HttpSessions
by Brian Stansberry (JIRA)
Optimized replication of entities and extended persistence context in HttpSessions
----------------------------------------------------------------------------------
Key: JBAS-4629
URL: http://jira.jboss.com/jira/browse/JBAS-4629
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering, Web (Tomcat) service
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Optimize replication of clustered web sessions that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held as a session attribute and those held by the replicated EntityManager.
Currently object identity is maintained by serializing the entire session as one operation (and thus only works reliably if SESSION granularity is used). The entire EM is serialized, including entities that have been flushed to the db. This is inefficient, since the replication is only done to support failover and in the case of node failover, the flushed entities can be restored from the db or the EM's 2nd level cache.
Intent is to:
1) Use JBoss serialization in order to have the ability to alter the serialized form of entities and XPCs.
1) Have Hibernate's EM impl expose getUnflushedChanges()/setUnflushedChanges() methods to support replication of only the unflushed changes held in the XPC, rather than all data.
2) When writing the attributes in the session, check if the object is a managed entity; if so write it's id to the stream rather than the whole object.
3) Deserialization process needs to ensure that any EntityManager is deserialized before the managed entities.
4) Deserialization of a managed entity would involve reading the id from the stream, identifying the EntityManager and doing a find().
5) Sessions should be lazy-deserialized (i.e. only deserialize if needed to handle failover). This is the way web session clustering already works. This is critical, otherwise the cost of the find() operations would likely outweigh the benefits of reducing the amount of replicated data.
Additionally, intent is to allow registration with the container of an impl, say, "ManagedPersistenceContextSerializer". If registered, implementation of many of the steps above would be delegated. JBoss Seam would intend to register an 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
15 years, 8 months
[JBoss JIRA] Created: (JBAS-4816) FirstAvailable - access and update of electedTarget is not atomic
by Galder Zamarreno (JIRA)
FirstAvailable - access and update of electedTarget is not atomic
-----------------------------------------------------------------
Key: JBAS-4816
URL: http://jira.jboss.com/jira/browse/JBAS-4816
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Trivial
Looking at FirstAvailable load balance policy, electedTarget access/update is not synchronised,
however, the chances of having some issues are very small. First, the proxy needs to be shared
by various threads before the electedTarget has been set, but as electedTarget already elected
randomly, the secondary effects of this lack of safety are none.
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBAS-5253) RetryInterceptor that caches JNDI lookup details per EJB type
by Galder Zamarreno (JIRA)
RetryInterceptor that caches JNDI lookup details per EJB type
-------------------------------------------------------------
Key: JBAS-5253
URL: http://jira.jboss.com/jira/browse/JBAS-5253
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering, Naming
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Configuring a remote EJB client, whether standalone or within AS, to use
RetryInterceptor (RI) when EJBs are deployed across different node/clusters
can be a bit tricky cos jndi details to be used by interceptor are stored statically.
There're several available workarounds which I'll explain in the workaround
section. This JIRA is focused at the feasibility of creating a more intelligent RI
that caches JNDI lookups as per EJB type.
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBAS-5233) Logging synchronous cluster wide RPC calls as DEBUG, thoughts?
by Galder Zamarreno (JIRA)
Logging synchronous cluster wide RPC calls as DEBUG, thoughts?
--------------------------------------------------------------
Key: JBAS-5233
URL: http://jira.jboss.com/jira/browse/JBAS-5233
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
This is not really a bug but was not sure what category to put it under.
When you do a synchronous (GET_ALL) cluster wide RPC call and you
wanna find out which node might not have replied in time (1 min by default),
this is logged at TRACE level in HAPartitionImpl:
if (excludeSelf)
{
if( trace )
{
log.trace("callMethodOnCluster(true), objName="+objName
+", methodName="+methodName+", members="+jgotherMembers);
}
rsp = this.callRemoteMethods(this.jgotherMembers, m, GroupRequest.GET_ALL, methodTimeout);
}
else
{
if( trace )
{
log.trace("callMethodOnCluster(false), objName="+objName
+", methodName="+methodName+", members="+members);
}
rsp = this.callRemoteMethods(null, m, GroupRequest.GET_ALL, methodTimeout);
}
if (rsp != null)
{
for (int i = 0; i < rsp.size(); i++)
{
Object item = rsp.elementAt(i);
if (item instanceof Rsp)
{
Rsp response = (Rsp) item;
// Only include received responses
boolean wasReceived = response.wasReceived();
if( wasReceived == true )
{
item = response.getValue();
if (!(item instanceof NoHandlerForRPC))
rtn.add(item);
}
else if( trace )
log.trace("Ignoring non-received response: "+response);
}
else
{
if (!(item instanceof NoHandlerForRPC))
rtn.add(item);
else if( trace )
log.trace("Ignoring NoHandlerForRPC");
}
}
}
If you ask someone to enable TRACE for HAPartitionImpl (the logger
category would be org.jboss.ha.framework.server.HAPartition), there's the
secondary effect of any HAJNDI lookups that do not find a binding locally
printing a noisy stacktrace that can be ignored:
[org.jboss.ha.framework.interfaces.HAPartition.partition-devl] Handle: HAJNDI.lookupLocally
2008-02-13 16:51:05,684 TRACE [org.jboss.ha.framework.interfaces.HAPartition.partition-devl] rpc call threw exception
javax.naming.NameNotFoundException: hug not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
at org.jnp.server.NamingServer.lookup(NamingServer.java:267)
at org.jnp.server.NamingServer.lookup(NamingServer.java:270)
at org.jboss.ha.jndi.TreeHead.lookupLocally(TreeHead.java:296)
at sun.reflect.GeneratedMethodAccessor453.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:1015)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
at java.lang.Thread.run(Thread.java:595)
So, my suggestion is, what about we log as DEBUG rather than TRACE messages in HAPartitionImpl:
public ArrayList callMethodOnCluster(String objName, String methodName,
Object[] args, Class[] types, boolean excludeSelf, long methodTimeout) throws Exception
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBXB-114) Reusing a model group
by Scott M Stark (JIRA)
Reusing a model group
---------------------
Key: JBXB-114
URL: http://jira.jboss.com/jira/browse/JBXB-114
Project: JBoss XML Binding (JBossXB)
Issue Type: Feature Request
Reporter: Scott M Stark
Fix For: JBossXB-2.0.0.CR5
We have an issue with mapping legacy schemas onto the jboss_5_0.xsd environment model group. The jboss_4_2.dtd specifies elements that are in the environment model group, but there are elements like security-identity interleaved with this:
<!ELEMENT session (ejb-name , jndi-name? , local-jndi-name?, call-by-value?,
exception-on-rollback?, timer-persistence?, configuration-name?, invoker-bindings?,
security-proxy? , ejb-ref* , ejb-local-ref* , service-ref*, security-identity? ,
resource-ref* , resource-env-ref*, message-destination-ref* , clustered? ,
cluster-config?, method-attributes?, depends*,
ior-security-config?, port-component*, ejb-timeout-identity?)>
See the org.jboss.test.metadata.ejb.JBoss42UnitTestCase.testExcludedMethods that parses a conforming jboss_4_2.dtd document, but fails to parse with:
org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/home/svn/JBossHead/projects/metadata/trunk/target/eclipse-classes/org/jboss/test/metadata/ejb/JBoss42_testExcludedMethods.xml@46,34
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:194)
...
Caused by: java.lang.IllegalArgumentException: jndiEnvironmentRefsGroup already set
at org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.setJndiEnvironmentRefsGroup(JBossEnterpriseBeanMetaData.java:265)
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.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108)
at org.jboss.beans.info.plugins.AbstractPropertyInfo.set(AbstractPropertyInfo.java:182)
at org.jboss.xb.spi.AbstractBeanAdapter.set(AbstractBeanAdapter.java:95)
at org.jboss.xb.builder.runtime.PropertyHandler.handle(PropertyHandler.java:61)
... 41 more
--
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
15 years, 8 months
[JBoss JIRA] Created: (EJBTHREE-879) Injection metadata in ejb-jar.xml does not override @EJB annotation
by Justin (JIRA)
Injection metadata in ejb-jar.xml does not override @EJB annotation
-------------------------------------------------------------------
Key: EJBTHREE-879
URL: http://jira.jboss.com/jira/browse/EJBTHREE-879
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC9 - Patch 1
Environment: OS-System: Linux 2.6.16.27-0.6-smp,i386
Java VM: Java HotSpot(TM) Server VM 1.6.0-b105,Sun Microsystems Inc.
JBoss [Zion] 4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)
JBoss EJB 3.0 RC9 Patch 1
Reporter: Justin
I have 2 stateless session EJBs, RecipientServiceBean and InjectedServiceBean.
RecipientService exposes a remote interface. InjectedService exposes only a local interface and is injected into the 'injectedService' field of the RecipientServiceBean
--------------------------------------------------- RecipientServiceBean ---------------------------------------------------
@Stateless(name="RecipientServiceBean")
@Remote(RecipientService.class)
public class RecipientServiceBean implements RecipientService {
@EJB(mappedName="overrideinjection/InjectedServiceBean/local")
private InjectedService injectedService;
public String saySomething() {
return "Hello: " + injectedService.getResponse();
}
}
--------------------------------------------------- InjectedServiceBean ---------------------------------------------------
@Stateless(name="InjectedServiceBean")
@Local(InjectedService.class)
public class InjectedServiceBean implements InjectedService {
public String getResponse() {
return "This is the real service";
}
}
---------------------------------------------------------------------------------------------------------------------------------------------------------
I now want to override the injection specified by the @EJB annotation to inject a stub service. The stub service and ejb-jar.xml included is as follows
--------------------------------------------------- RecipientServiceStubBean ---------------------------------------------------
public class InjectedServiceStubBean implements InjectedService {
public String getResponse() {
return "THIS IS THE STUB";
}
}
--------------------------------------------------- ejb-jar.xml ---------------------------------------------------
<?xml version="1.0" encoding="ISO-8859-1"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
version="3.0">
<enterprise-beans>
<session>
<ejb-name>RecipientServiceBean</ejb-name>
<remote>com.sadalbari.test.overrideinjection.RecipientService</remote>
<ejb-class>com.sadalbari.test.overrideinjection.impl.RecipientServiceBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<ejb-local-ref>
<ejb-ref-name>ejb/InjectedService</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>com.sadalbari.test.overrideinjection.InjectedService</local>
<ejb-link>InjectedServiceStubBean</ejb-link>
<injection-target>
<injection-target-class>com.sadalbari.test.overrideinjection.impl.RecipientServiceBean</injection-target-class>
<injection-target-name>injectedService</injection-target-name>
</injection-target>
</ejb-local-ref>
</session>
<session>
<ejb-name>InjectedServiceStubBean</ejb-name>
<local>com.sadalbari.test.overrideinjection.InjectedService</local>
<ejb-class>com.sadalbari.test.overrideinjection.impl.InjectedServiceStubBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
---------------------------------------------------------------------------------------------------------------------------------------------------------
A dump of my JNDI view at this point
+- overrideinjection (class: org.jnp.interfaces.NamingContext)
| +- RecipientServiceBean (class: org.jnp.interfaces.NamingContext)
| | +- remote (proxy: $Proxy61 implements interface com.sadalbari.test.overrideinjection.RecipientService,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBObject)
| +- InjectedServiceStubBean (class: org.jnp.interfaces.NamingContext)
| | +- local (proxy: $Proxy56 implements interface com.sadalbari.test.overrideinjection.InjectedService,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBLocalObject)
| +- InjectedServiceBean (class: org.jnp.interfaces.NamingContext)
| | +- local (proxy: $Proxy56 implements interface com.sadalbari.test.overrideinjection.InjectedService,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBLocalObject)
---------------------------------------------------------------------------------------------------------------------------------------------------------
The result is that the injection is not overridden and the stub is not used in preference to the 'real service':
Hello: This is the real service
I can work around this issue by removing the @EJB annotation and ALWAYS declaring the injection in the ejb-jar.xml in which case I get:
Hello: THIS IS THE STUB
Thanks
Justin
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBPORTAL-1960) NPE in DefaultPortalCommandFactory
by Prabhat Jha (JIRA)
NPE in DefaultPortalCommandFactory
----------------------------------
Key: JBPORTAL-1960
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1960
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Core
Affects Versions: 2.6.4 Final
Reporter: Prabhat Jha
Assigned To: Julien Viet
Fix For: 2.6.5 Final
Here is what we exchanged in mail.
===============
Julien wrote:
that kind of error is a runtime exception that is a portal programming error, there is not a real way to gracefully handle it at the portal level (since it happens in a command factory), I think the best we can do is to handle it with a request dispatch to a JSP (the ones we use for error handling inside portal).
the following actions should be taken:
1/ determine what is the cause, have the DefaultPortalCommandFactory fixed to handle that kind of situation
2/ have that kind of error reported by a JSP as an internal error
On Mar 21, 2008, at 6:13 PM, Prabhat Jha wrote:
> So here is how you replicate this problem and I agree in advance that using HSQL is not right thing to do in clustering but I still think that the error should be more meaningful than NPE.
>
> 1. Start one node (all configuration) with portal-ha.sar deployed with HSQL as database.
> 2. Access http://IP1:port/portal . It comes up fine.
> 3. Start another node bound to different IP on the same machine. Start up is clean.
> 4. Access http://IP2:port/portal. You get NPE.
>
> I just happened to try this configuration because I got lazy to fire up MySQL.
>
> Regards,
> Prabhat
>
>
> Prabhat Jha wrote:
>> I am getting this NPE when I try to get http://localhost:8080/portal first time . I do not know what's causing this because I don't see any error in server log. This very well could be configuration error on my part but could it be an inherent bug. This is with portal-ha.sar with HSQL. Even if there is some configuration error, should not error be handled gracefully in the method throwing exception?
>>
>> javax.servlet.ServletException: java.lang.NullPointerException
>> org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:276)
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>>
>> *root cause*
>>
>> java.lang.NullPointerException
>> org.jboss.portal.core.model.portal.DefaultPortalCommandFactory.doMapping(DefaultPortalCommandFactory.java:72)
>> org.jboss.portal.core.controller.Controller.handle(Controller.java:208)
>> org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
>> org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
>> org.jboss.portal.core.cms.aspect.IdentityBindingInterceptor.invoke(IdentityBindingInterceptor.java:47)
>> org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>> org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>> org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>> org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>> org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>> org.jboss.portal.core.aspects.server.PortalContextPathInterceptor.invoke(PortalContextPathInterceptor.java:45)
>> org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>> org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>> org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:96)
>> org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>> org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>> org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:246)
>> org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>> org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>> org.jboss.portal.server.aspects.server.SignOutInterceptor.invoke(SignOutInterceptor.java:98)
>> org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>> org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>> org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.invoke(UserEventBridgeTriggerInterceptor.java:65)
>> org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>> org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>> org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
>> org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>> org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>> org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:253)
>> org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>> org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>> org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:262)
>> org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
>> org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
>> org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>> org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>> org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.java:139)
>> org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
>> org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
>> org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:250)
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
--
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
15 years, 8 months
