[JBoss JIRA] Assigned: (AS7-1344) JGroups subsystem TimerSchedulerAdapter throws UOE when using timer-executor
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/AS7-1344?page=com.atlassian.jira.plugin.s... ]
Paul Ferraro reassigned AS7-1344:
---------------------------------
Assignee: Paul Ferraro (was: Trustin Lee)
> JGroups subsystem TimerSchedulerAdapter throws UOE when using timer-executor
> ----------------------------------------------------------------------------
>
> Key: AS7-1344
> URL: https://issues.jboss.org/browse/AS7-1344
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.0.0.Final
> Reporter: Michal Linhard
> Assignee: Paul Ferraro
> Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> 07:42:39,535 WARNING [org.jgroups.protocols.UDP] (DiagnosticsHandler,default,perf17-37478) Could not retrieve value of attribute (method) getNumTimerTasks: java.lang.reflect.InvocationTargetException
> [JBoss] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
> [JBoss] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
> [JBoss] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
> [JBoss] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
> [JBoss] at org.jgroups.stack.Protocol.dumpStats(Protocol.java:272) [jgroups-2.12.1.Final.jar:]
> [JBoss] at org.jgroups.stack.ProtocolStack.dumpStats(ProtocolStack.java:310) [jgroups-2.12.1.Final.jar:]
> [JBoss] at org.jgroups.JChannel.dumpStats(JChannel.java:687) [jgroups-2.12.1.Final.jar:]
> [JBoss] at org.jgroups.JChannel$MyProbeHandler.handleProbe(JChannel.java:2099) [jgroups-2.12.1.Final.jar:]
> [JBoss] at org.jgroups.protocols.TP$DiagnosticsHandler.handleDiagnosticProbe(TP.java:2165) [jgroups-2.12.1.Final.jar:]
> [JBoss] at org.jgroups.protocols.TP$DiagnosticsHandler.run(TP.java:2137) [jgroups-2.12.1.Final.jar:]
> [JBoss] at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> [JBoss] Caused by: java.lang.UnsupportedOperationException
> [JBoss] at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.getExecutor(TimerSchedulerAdapter.java:168) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.size(TimerSchedulerAdapter.java:153) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] at org.jgroups.protocols.TP.getNumTimerTasks(TP.java:714) [jgroups-2.12.1.Final.jar:]
> [JBoss] ... 11 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Resolved: (AS7-1344) JGroups subsystem TimerSchedulerAdapter throws UOE when using timer-executor
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/AS7-1344?page=com.atlassian.jira.plugin.s... ]
Paul Ferraro resolved AS7-1344.
-------------------------------
Fix Version/s: 7.0.1.Final
7.1.0.Alpha1
Resolution: Done
> JGroups subsystem TimerSchedulerAdapter throws UOE when using timer-executor
> ----------------------------------------------------------------------------
>
> Key: AS7-1344
> URL: https://issues.jboss.org/browse/AS7-1344
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.0.0.Final
> Reporter: Michal Linhard
> Assignee: Paul Ferraro
> Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> 07:42:39,535 WARNING [org.jgroups.protocols.UDP] (DiagnosticsHandler,default,perf17-37478) Could not retrieve value of attribute (method) getNumTimerTasks: java.lang.reflect.InvocationTargetException
> [JBoss] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
> [JBoss] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
> [JBoss] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
> [JBoss] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
> [JBoss] at org.jgroups.stack.Protocol.dumpStats(Protocol.java:272) [jgroups-2.12.1.Final.jar:]
> [JBoss] at org.jgroups.stack.ProtocolStack.dumpStats(ProtocolStack.java:310) [jgroups-2.12.1.Final.jar:]
> [JBoss] at org.jgroups.JChannel.dumpStats(JChannel.java:687) [jgroups-2.12.1.Final.jar:]
> [JBoss] at org.jgroups.JChannel$MyProbeHandler.handleProbe(JChannel.java:2099) [jgroups-2.12.1.Final.jar:]
> [JBoss] at org.jgroups.protocols.TP$DiagnosticsHandler.handleDiagnosticProbe(TP.java:2165) [jgroups-2.12.1.Final.jar:]
> [JBoss] at org.jgroups.protocols.TP$DiagnosticsHandler.run(TP.java:2137) [jgroups-2.12.1.Final.jar:]
> [JBoss] at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> [JBoss] Caused by: java.lang.UnsupportedOperationException
> [JBoss] at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.getExecutor(TimerSchedulerAdapter.java:168) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.size(TimerSchedulerAdapter.java:153) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] at org.jgroups.protocols.TP.getNumTimerTasks(TP.java:714) [jgroups-2.12.1.Final.jar:]
> [JBoss] ... 11 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBJCA-634) Support query timeout for check-valid-connection-sql
by Takayoshi Kimura (JIRA)
Support query timeout for check-valid-connection-sql
----------------------------------------------------
Key: JBJCA-634
URL: https://issues.jboss.org/browse/JBJCA-634
Project: IronJacamar
Issue Type: Feature Request
Components: JDBC
Affects Versions: 1.0.0.Final
Reporter: Takayoshi Kimura
Assignee: Jesper Pedersen
When network hangs and check-valid-connection-sql is executed, it hangs until socket timeout which is normally 5min or more longer.
We can avoid this long timeout if we have ability to set query timeout for check-valid-connection-sql and the underlying JDBC driver supports query timeout.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (AS7-1322) Provide service for starting/stop a POJO WS endpoint
by Alessio Soldano (JIRA)
Provide service for starting/stop a POJO WS endpoint
----------------------------------------------------
Key: AS7-1322
URL: https://issues.jboss.org/browse/AS7-1322
Project: Application Server 7
Issue Type: Feature Request
Components: Web Services
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: 7.1.0.Alpha1
We need a service for programatically publishing a WS endpoint on JBoss AS 7 HTTP server. There's recently been a mild interest from the community for this and the functionality would be of great use to projects like XTS requiring publishing of endpoints as part of their subsystem boot.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBAS-8786) JBoss unpacks all jars from WEB-INF\lib of war file
by Maxym Pendyshchuk (JIRA)
JBoss unpacks all jars from WEB-INF\lib of war file
---------------------------------------------------
Key: JBAS-8786
URL: https://issues.jboss.org/browse/JBAS-8786
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Environment: Windows XP x32
Reporter: Maxym Pendyshchuk
while starting JBoss AS it unpacks all jar files, which are located in WEB-INF/lib folder of each my war file. It means that in tmp folder mostly I see folder with jar file, and folder with its content. E.g. jackrabbit-server.war contains library asm-3.1.jar, then in tmp folder I see the following folders with files:
asm-3.1.jar-83dc35ead0d41d41/asm-3.1.jar
asm-3.1.jar-2a48f1c13ec7f25d/contents/"unpacked asm-3.1.jar"
actually when I repack jackrabbit-server.war to jackrabbit-server.ear which contains jackrabbit-server.war and moved all its libraries to jackrabbit-server.ear/lib then I still see two folders in tmp:
asm-3.1.jar-215a36131ebb088e/asm-3.1.jar
asm-3.1.jar-14695f157664f00/contents/
but in this case last folder is empty. So it still creates two folders, but does not unpack my library. Also I use exploded deployment so the question is only about jar files, not unpacking ear/war.
the problem is that it slows down application server booting (when I repack all my war files as ear and moved war libraries to ear/lib folder then I save 2+ minutes at JBoss 6 booting...). If it is done deliberately (so it improves some performance at runtime), then would be nice to have a configuration option, so during development I can save time to boot my local JBoss AS
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBRULES-2289) Support JPA Resource Local EntityTransaction based Transactions
by Michael Youngstrom (JIRA)
Support JPA Resource Local EntityTransaction based Transactions
---------------------------------------------------------------
Key: JBRULES-2289
URL: https://jira.jboss.org/jira/browse/JBRULES-2289
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 5.0.1.FINAL
Reporter: Michael Youngstrom
Assignee: Mark Proctor
It would be nice if wherever JPA is used in Drools (drools-flow in particular) there was support for RESOURCE_LOCAL transactions through JPA's EntityTransaction interface as an alternative to JTA.
Support for resource local transactions would reduce the base Drools Flow dependency footprint (no need for bitronix) as well as allow Drools to be used in a containerless or Tomcat like environment without a JTA implementation available. Although embeddable solutions are available they are often either buggy or complex. It would be nice to not have to deal with them if possible.
If the idea is acceptable I'd be willing to put together an initial patch.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months
[JBoss JIRA] Created: (JBAS-9420) JMS Manager is unavailable in JBoss Application Server 6.1.0
by Jarod Rose (JIRA)
JMS Manager is unavailable in JBoss Application Server 6.1.0
------------------------------------------------------------
Key: JBAS-9420
URL: https://issues.jboss.org/browse/JBAS-9420
Project: Legacy JBoss Application Server 6
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS (HornetQ), Web Console
Affects Versions: 6.1.0
Environment: Windows XP SP 3
Reporter: Jarod Rose
Assignee: Clebert Suconic
When accessing the Administration Console in JBoss 6.1.0-SNAPSHOT the JMS Manager is unavailable. When inspecting the log the following stack trace can be found.
2011-07-20 09:21:38,797 INFO [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Scanned [0] servers and found [0] total descendant Resources.
2011-07-20 09:21:38,812 INFO [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Running runtime discovery scan rooted at [platform]
2011-07-20 09:21:38,922 WARN [org.rhq.core.pc.inventory.InventoryManager] (InventoryManager.discovery-1) Failure during discovery for [JMS Manager] Resources - failed after 0 ms.: java.lang.Exception: Discovery component invocation failed.
at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:283) [:3.0.0]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
Caused by: java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'getVersion' on component 'JMSServerMO' with parameters [].
at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:148) [:0.2.2]
at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93) [:0.2.2]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA]
at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99) [:6.1.0-SNAPSHOT]
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967) [:]
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106) [:]
at org.jboss.remoting.Client.invoke(Client.java:2070) [:]
at org.jboss.remoting.Client.invoke(Client.java:879) [:]
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) [:1.0.1.GA]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) [:1.0.1.GA]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) [:1.0.1]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java) [:]
at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63) [:6.1.0-SNAPSHOT]
at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.getVersion(JMSManagerDiscoveryComponent.java:74)
at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.discoverResources(JMSManagerDiscoveryComponent.java:48)
at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) [:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:279) [:3.0.0]
... 5 more
Caused by: java.lang.NullPointerException
at org.jboss.as.integration.hornetq.management.jms.JMSManageMO.getJmsServerControl(JMSManageMO.java:128) [:6.1.0-SNAPSHOT]
at org.jboss.as.integration.hornetq.management.jms.JMSServerMO.getVersion(JMSServerMO.java:47) [:6.1.0-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1]
at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) [jboss-reflect.jar:2.2.1.SP1]
at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305) [jboss-kernel.jar:2.2.0.SP1]
at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:61) [jboss-kernel.jar:2.2.0.SP1]
at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:58) [jboss-kernel.jar:2.2.0.SP1]
at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71) [jboss-kernel.jar:2.2.0.SP1]
at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus.invoke(LifecycleAwareKernelBus.java:57) [jboss-kernel.jar:2.2.0.SP1]
at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:85) [:0.2.2]
at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:135) [:0.2.2]
at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93) [:0.2.2]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA]
at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99) [:6.1.0-SNAPSHOT]
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967) [:]
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106) [:]
at org.jboss.remoting.Client.invoke(Client.java:2070) [:]
at org.jboss.remoting.Client.invoke(Client.java:879) [:]
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) [:1.0.1.GA]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) [:1.0.1.GA]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) [:1.0.1]
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java) [:]
at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63) [:6.1.0-SNAPSHOT]
at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.getVersion(JMSManagerDiscoveryComponent.java:74)
at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.discoverResources(JMSManagerDiscoveryComponent.java:48)
at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) [:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:279) [:3.0.0]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72) [:1.0.1.GA]
... 18 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months