[JBoss JIRA] Created: (JBAS-8669) StringIndexOutOfBoundsException when deploying applications with 3 characters or less
by Rico Neubauer (JIRA)
StringIndexOutOfBoundsException when deploying applications with 3 characters or less
-------------------------------------------------------------------------------------
Key: JBAS-8669
URL: https://jira.jboss.org/browse/JBAS-8669
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployers
Affects Versions: 6.0.0.CR1
Reporter: Rico Neubauer
Assignee: Ales Justin
Deploy an archive (in my case programmatically using MainDeployer, but should not matter), whose name has 3 characters or less.
org.jboss.as.naming.javaee.NamingJavaEEApplicationInformer tries to truncate the last 4 characters, which results in
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1937)
at org.jboss.as.naming.javaee.NamingJavaEEApplicationInformer.getApplicationName(NamingJavaEEApplicationInformer.java:30)
at org.jboss.reloaded.naming.deployers.AppNamingDeployer.internalDeploy(AppNamingDeployer.java:63)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (JGRP-1265) Member can not join cluster after heavy load
by Victor N (JIRA)
Member can not join cluster after heavy load
--------------------------------------------
Key: JGRP-1265
URL: https://issues.jboss.org/browse/JGRP-1265
Project: JGroups
Issue Type: Bug
Affects Versions: 2.11
Environment: linux, kernel 2.6.18
Reporter: Victor N
Assignee: Bela Ban
In our production system I can see that a node desappers from the cluster if its server was heavily-loaded. It's OK, but the node never comes back to the cluster even after its server is working normally, without load. I can easily reproduce the problem in 2 cases:
1) by taking a memory dump on the node: jmap -dump:format=b,file=dump.hprof <pid>
Since we have 8-16 GB of RAM, this operation takes much time and blocks JVM - so other members exclude this node from View.
2) GC (garbage collection) - if JVM is doing GC constantly (and almost can not work)
In both situations the stuck node never reappears in the cluster (even after 1 h). Below are more details.
We have 12 nodes in our cluster, we problematic node is "gate5".
View on gate5: [gate11.mydomain|869] [gate11.mydomain, gate2.mydomain, gate6.mydomain, gate7.mydomain, gate12.mydomain, gate4.mydomain, gate3.mydomain, gate10.mydomain, gate8.mydomain, gate9.mydomain, gate14.mydomain, gate5.mydomain]
View on gate11 (coordinator): [gate11.mydomain|870] [gate11.mydomain, gate2.mydomain, gate6.mydomain, gate7.mydomain, gate12.mydomain, gate4.mydomain, gate3.mydomain, gate10.mydomain, gate8.mydomain, gate9.mydomain, gate14.mydomain]
The coordinator (gate11) is sending GET_MBRS_REQ periodically - I see them in gate5. But I do NOT see response to this request!
All jgroups threads are alive, not dead (I took stack traces).
Another strange thing is that the problematic gate5 sends messages to other nodes and even receives messages from SOME of them! How is it possible - I double-checked that ALL other nodes have view_id=870 (without gate5)?
The only assumption I have is race-conditions which occurs (as always) under high load.
In normal situations such as temporary network failure everything works perfectly - gate5 joins the cluster.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Updated: (JGRP-1272) FC: all threads are blocked at credits_available.await
by Victor N (JIRA)
[ https://issues.jboss.org/browse/JGRP-1272?page=com.atlassian.jira.plugin.... ]
Victor N updated JGRP-1272:
---------------------------
Attachment: jgroups-tcp.xml
my config
> FC: all threads are blocked at credits_available.await
> ------------------------------------------------------
>
> Key: JGRP-1272
> URL: https://issues.jboss.org/browse/JGRP-1272
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.11
> Environment: ubuntu 10.04.1
> Reporter: Victor N
> Assignee: Bela Ban
> Attachments: jgroups-tcp.xml
>
>
> After several days of working one node can not rejoin because of FC protocol issue. The situation is reproduced once or several times per week.
> The problematic node is called "gate9", its view is outdated:
> [gate10.mydomain|1175] [gate10.mydomain, gate7.mydomain, gate8.mydomain, gate9.mydomain, gate11.mydomain, gate14.mydomain, gate5.mydomain, gate12.mydomain, gate2.mydomain, gate4.mydomain, gate3.mydomain, gate6.mydomain]
> Actual view (seen by all other nodes) is: [gate10.mydomain|1176] [gate10.mydomain, gate7.mydomain, gate8.mydomain, gate11.mydomain, gate14.mydomain, gate5.mydomain, gate12.mydomain, gate2.mydomain, gate4.mydomain, gate3.mydomain, gate6.mydomain]
> In log file at gate9 I can see that it sends CREDIT_REQUEST constantly:
> 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate10.mydomain, src=gate9.mydomain, headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=4308, conn_id=14, TCP: [channel_name=GateCluster]
> 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.BasicTCP.sendUnicast(): dest=192.168.1.10:40001 (94 bytes)
> 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.UNICAST.retransmit(): gate9.mydomain --> XMIT(gate10.mydomain: #2014)
> 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate10.mydomain, src=gate9.mydomain, headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=2014, conn_id=14, TCP: [channel_name=GateCluster]
> 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.BasicTCP.sendUnicast(): dest=192.168.1.10:40001 (94 bytes)
> 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.UNICAST.retransmit(): gate9.mydomain --> XMIT(gate10.mydomain: #1124)
> ...
> At gate10 (the coordinator) I see that it receives the requests and responds:
> 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.passMessageUp(): received [dst: gate10.mydomain, src: gate9.mydomain (3 headers), size=9 bytes], headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=2397, conn_id=14, TCP: [channel_name=GateCluster]
> 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.handleDataReceived(): gate10.mydomain <-- DATA(gate9.mydomain: #2397, conn_id=14)
> 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.sendRequestForFirstSeqno(): gate10.mydomain --> SEND_FIRST_SEQNO(gate9.mydomain)
> 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate9.mydomain, src=gate10.mydomain, headers are UNICAST: SEND_FIRST_SEQNO, seqno=0, TCP: [channel_name=GateCluster]
> 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.passMessageUp(): received [dst: gate10.mydomain, src: gate9.mydomain (3 headers), size=9 bytes], headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=1202, conn_id=14, TCP: [channel_name=GateCluster]
> 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.handleDataReceived(): gate10.mydomain <-- DATA(gate9.mydomain: #1202, conn_id=14)
> 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.sendRequestForFirstSeqno(): gate10.mydomain --> SEND_FIRST_SEQNO(gate9.mydomain)
> 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate9.mydomain, src=gate10.mydomain, headers are UNICAST: SEND_FIRST_SEQNO, seqno=0, TCP: [channel_name=GateCluster]
> ...
> but I do not see any answer to this at gate9.
> My config and stack traces are attached below. I do not know how to reproduce the problem in tests. But it occurs, so I can provide you with any details, just let me know.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (SECURITY-556) Ejb3AuthenticationInterceptorv2 ignores JavaEE 6 (<data-source> in META-INF\application.xml)
by Juergen Zimmermann (JIRA)
Ejb3AuthenticationInterceptorv2 ignores JavaEE 6 (<data-source> in META-INF\application.xml)
--------------------------------------------------------------------------------------------
Key: SECURITY-556
URL: https://issues.jboss.org/browse/SECURITY-556
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Juergen Zimmermann
Assignee: Anil Saldhana
In JBossAS 6 a datasource can be declared in the EAR's META-INF\application.xml:
<application ... version="6">
<initialize-in-order>true</initialize-in-order>
<module>... </module>
...
<data-source>
<description>...</description>
<name>myDS</name>
<class-name>org.postgresql.Driver</class-name>
<url>jdbc:postgresql:jbossdb</url>
...
</data-source>
</application>
This is a standardized alternative to a *-ds.xml file being declared as a service module in the EAR's META-INF\jboss-app.xml.
When I add a <data-source> entry to application.xml and I still have a security-policies-jboss-beans.xml to declare <login-module> based on DatabaseServerLoginModule I get the exception below. BTW, the <data-source> declaration above produces the JNDI name java:internal/myEAR/myEAR/env/myDS.
The stacktrace:
06:51:14,932 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/swe2].[FacesServlet]] Servlet.service() for servlet FacesServlet threw exception: javax.ejb.EJBAccessException: Invalid User
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:161) [:1.7.17]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41) [:1.7.17]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67) [:1.7.17]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.7.17]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86) [:1.7.17]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.ejb3.session.SessionSpecContainer.invoke(SessionSpecContainer.java:323) [:1.7.17]
at org.jboss.ejb3.session.SessionSpecContainer.invoke(SessionSpecContainer.java:156) [:1.7.17]
at org.jboss.ejb3.nointerface.impl.invocationhandler.NoInterfaceViewInvocationHandler.invokeEndpoint(NoInterfaceViewInvocationHandler.java:143) [:6.0.0.Final]
at org.jboss.ejb3.nointerface.impl.invocationhandler.NoInterfaceViewInvocationHandler.access$000(NoInterfaceViewInvocationHandler.java:54) [:6.0.0.Final]
at org.jboss.ejb3.nointerface.impl.invocationhandler.NoInterfaceViewInvocationHandler$1.invoke(NoInterfaceViewInvocationHandler.java:103) [:6.0.0.Final]
at org.jboss.ejb3.sis.reflect.InterceptorInvocationHandler$1.proceed(InterceptorInvocationHandler.java:84) [:1.0.0-alpha-1]
at org.jboss.ejb3.sis.InterceptorAssembly$1.proceed(InterceptorAssembly.java:82) [:1.0.0-alpha-1]
at org.jboss.ejb3.nointerface.impl.async.AsyncClientInterceptor.invoke(AsyncClientInterceptor.java:119) [:6.0.0.Final]
at org.jboss.ejb3.sis.InterceptorAssembly$1.proceed(InterceptorAssembly.java:74) [:1.0.0-alpha-1]
at org.jboss.ejb3.nointerface.impl.invocationhandler.ObjectMethodsInterceptor.invoke(ObjectMethodsInterceptor.java:78) [:6.0.0.Final]
at org.jboss.ejb3.sis.InterceptorAssembly$1.proceed(InterceptorAssembly.java:74) [:1.0.0-alpha-1]
at org.jboss.ejb3.sis.InterceptorAssembly.invoke(InterceptorAssembly.java:90) [:1.0.0-alpha-1]
at org.jboss.ejb3.sis.reflect.InterceptorInvocationHandler.invoke(InterceptorInvocationHandler.java:110) [:1.0.0-alpha-1]
at org.jboss.ejb3.nointerface.impl.invocationhandler.NoInterfaceViewInvocationHandler.invoke(NoInterfaceViewInvocationHandler.java:115) [:6.0.0.Final]
at org.jboss.ejb3.proxy.javassist.JavassistInvocationHandlerAdapter.invoke(JavassistInvocationHandlerAdapter.java:71) [:1.0.0-alpha-1]
at de.swe2.bestellverwaltung.service.Bestellverwaltung_$$_javassist_14.ladenhueter(Bestellverwaltung_$$_javassist_14.java)
at de.swe2.bestellverwaltung.ui.BestellverwaltungController.loadLadenhueter(BestellverwaltungController.java:195) [:]
at de.swe2.bestellverwaltung.ui.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$C:$Software$jboss-6$0$0$server$default$deploy$swe2$ear$swe2Web$war$"-ManagedBean-class_de$swe2$bestellverwaltung$ui$BestellverwaltungController_$$_WeldSubclass.loadLadenhueter(org$jboss$weld$bean-jboss$classloader:id="vfs:$$$C:$Software$jboss-6$0$0$server$default$deploy$swe2$ear$swe2Web$war$"-ManagedBean-class_de$swe2$bestellverwaltung$ui$BestellverwaltungController_$$_WeldSubclass.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_23]
at org.jboss.interceptor.proxy.SimpleInterceptionChain.invokeNextInterceptor(SimpleInterceptionChain.java:114) [:2.0.0.CR1]
at org.jboss.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:143) [:2.0.0.CR1]
at de.swe2.util.RequiredTxInterceptor.workInTransaction(RequiredTxInterceptor.java:34) [:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_23]
at org.jboss.interceptor.proxy.InterceptorInvocation$InterceptorMethodInvocation.invoke(InterceptorInvocation.java:72) [:2.0.0.CR1]
at org.jboss.interceptor.proxy.SimpleInterceptionChain.invokeNextInterceptor(SimpleInterceptionChain.java:82) [:2.0.0.CR1]
at org.jboss.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:143) [:2.0.0.CR1]
at de.swe2.util.LogInterceptor.log(LogInterceptor.java:72) [:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_23]
at org.jboss.interceptor.proxy.InterceptorInvocation$InterceptorMethodInvocation.invoke(InterceptorInvocation.java:72) [:2.0.0.CR1]
at org.jboss.interceptor.proxy.SimpleInterceptionChain.invokeNextInterceptor(SimpleInterceptionChain.java:82) [:2.0.0.CR1]
at org.jboss.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:133) [:2.0.0.CR1]
at org.jboss.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:112) [:2.0.0.CR1]
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:66) [:6.0.0.Final]
at de.swe2.bestellverwaltung.ui.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$C:$Software$jboss-6$0$0$server$default$deploy$swe2$ear$swe2Web$war$"-ManagedBean-class_de$swe2$bestellverwaltung$ui$BestellverwaltungController_$$_WeldSubclass.loadLadenhueter(org$jboss$weld$bean-jboss$classloader:id="vfs:$$$C:$Software$jboss-6$0$0$server$default$deploy$swe2$ear$swe2Web$war$"-ManagedBean-class_de$swe2$bestellverwaltung$ui$BestellverwaltungController_$$_WeldSubclass.java)
at de.swe2.bestellverwaltung.ui.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$C:$Software$jboss-6$0$0$server$default$deploy$swe2$ear$swe2Web$war$"-ManagedBean-class_de$swe2$bestellverwaltung$ui$BestellverwaltungController_$$_WeldClientProxy.loadLadenhueter(org$jboss$weld$bean-jboss$classloader:id="vfs:$$$C:$Software$jboss-6$0$0$server$default$deploy$swe2$ear$swe2Web$war$"-ManagedBean-class_de$swe2$bestellverwaltung$ui$BestellverwaltungController_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_23]
at org.apache.el.parser.AstValue.invoke(AstValue.java:196) [:6.0.0.Final]
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) [:6.0.0.Final]
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:43) [:6.0.0.Final]
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:56) [:6.0.0.Final]
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:43) [:6.0.0.Final]
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:56) [:6.0.0.Final]
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:102) [:2.0.3-]
at com.sun.faces.facelets.tag.jsf.core.DeclarativeSystemEventListener.processEvent(EventHandler.java:124) [:2.0.3-]
at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2378) [:2.0.3-]
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:102) [:2.0.3-]
at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2040) [:2.0.3-]
at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:1988) [:2.0.3-]
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:284) [:2.0.3-]
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:242) [:2.0.3-]
at org.jboss.weld.integration.webtier.jsf.ForwardingApplication.publishEvent(ForwardingApplication.java:336) [:6.0.0.Final]
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:104) [:2.0.3-]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97) [:2.0.3-]
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:135) [:2.0.3-]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:309) [:2.0.3-]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [:6.0.0.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) [:6.0.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final]
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final]
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final]
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final]
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [:6.0.0.Final]
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:600) [:6.0.0.Final]
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2019) [:6.0.0.Final]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months