[JBoss JIRA] Created: (AS7-1217) Deployment fails when deployment-scanner is pointed to UNC path
by James Livingston (JIRA)
Deployment fails when deployment-scanner is pointed to UNC path
---------------------------------------------------------------
Key: AS7-1217
URL: https://issues.jboss.org/browse/AS7-1217
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.0.0.CR1
Reporter: James Livingston
On JBoss 5, you could add an additional deployment directory located via a UNC path (\\computername\share on Windows). On AS 7.0.0.CR1 it detects that a deployment has been added, but fails deployment because a backslash character gets lost between the host and share parts of the path.
To reproduce:
1) share a directory on a Windows machine, for example "share" on the machine "host"
2) In standalone.xml, add a deployment-scanner with the path "\\host\share\" (or "\\\\host\\share", escaping the backshashes doesn't make a difference)
3) Put a WAR file in that directory
4) start JBoss
It will fail with the error:
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."sample.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."sample.war".STRU
CTURE: Failed to process phase STRUCTURE of deployment "sample.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [:1.6.0_24]
at java.lang.Thread.run(Unknown Source) [:1.6.0_24]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content
at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:82)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
... 5 more
Caused by: java.io.FileNotFoundException: \\hostshare\sample.war (The network path was not found)
at java.io.FileInputStream.open(Native Method) [:1.6.0_24]
at java.io.FileInputStream.<init>(Unknown Source) [:1.6.0_24]
at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:55)
at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:238)
at org.jboss.vfs.VFS.mountZipExpanded(VFS.java:567)
at org.jboss.as.server.deployment.repository.impl.ServerDeploymentRepositoryImpl.mountDeploymentContent(ServerDeploymentRepositoryImpl.java:73)
at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:78)
... 6 more
05:47:04,303 INFO [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployment of "sample.war" was rolled back with failure message {"Failed services" => {"jboss.deployment.unit.\"sample.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"sample.war\".STRUCTURE: Failed to process phase STRUCTURE of deployment \"sample.war\""}}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (JGRP-1432) OutOfMemoryError in GMS
by Peter Nerg (JIRA)
Peter Nerg created JGRP-1432:
--------------------------------
Summary: OutOfMemoryError in GMS
Key: JGRP-1432
URL: https://issues.jboss.org/browse/JGRP-1432
Project: JGroups
Issue Type: Bug
Affects Versions: 2.12.2
Environment: Modified SLES
Reporter: Peter Nerg
Assignee: Bela Ban
When running in a cluster with only two nodes we every now and then see issues that JGroups fails to start a thread due to OOM.
The stack trace always points to the same place hence so it should rule out any other part of the application.
Also taking a heap dump immediately after the OOM yields no obvious cause to the OOM.
It makes we wonder if there is a scenario where JGroups goes wild and starts to create lots of threads.
The stack trace looks like this (often a number of OOM exceptions in a row)
2012-02-21 08:56:52,679 [ OOB-1,null] ERROR [org.jgroups.protocols.TCP] failed handling incoming message
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:640)
at org.jgroups.protocols.pbcast.GMS$ViewHandler.start(GMS.java:1297)
at org.jgroups.protocols.pbcast.GMS$ViewHandler.add(GMS.java:1260)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:801)
at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:170)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:246)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:703)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:101)
at org.jgroups.protocols.FD.up(FD.java:275)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:210)
at org.jgroups.protocols.Discovery.up(Discovery.java:294)
at org.jgroups.stack.Protocol.up(Protocol.java:413)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1109)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1665)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1647)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
The above stack trace is often preceded by the following printout:
2012-02-21 04:39:28,949 [ Timer-2,<ADDR>] WARN [org.jgroups.protocols.FILE_PING] failed reading 9875802e-272a-0bcc-d1db-466d80f188b2.node: removing it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3973) Yet another place where hardcoded IPv4 address scheme is used
by Pavel Janousek (JIRA)
[ https://issues.jboss.org/browse/AS7-3973?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek moved JBPAPP-8299 to AS7-3973:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-3973 (was: JBPAPP-8299)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.1.Final
(was: EAP 6.0.0 ER 2)
Component/s: Test Suite
(was: Testsuite)
Security: (was: JBoss Internal)
Docs QE Status: (was: NEW)
> Yet another place where hardcoded IPv4 address scheme is used
> -------------------------------------------------------------
>
> Key: AS7-3973
> URL: https://issues.jboss.org/browse/AS7-3973
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Blocker
>
> After the last Stuart commit and merge to upstream (on Thursday morning CET time zone), there are still some places where hardcoded IPv4 address scheme is used.
> Wrong TestCases are:
> - org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase
> - org.jboss.as.test.integration.ejb.mdb.containerstart.SendMessagesTestCase
> Both of them use 127.0.0.1 directly even -Dnode0=::1 - it seems to be some other magic inside them because [there|http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-t...] TS passed, but I also reconfigure my machine to avoid IPv4 name address translation like:
> {code}
> #127.0.0.1 localhost.localdomain
> #127.0.0.1 pjanouse.brq.redhat.com localhost
> ::1 localhost6.localdomain6 localhost6 localhost
> ::1 pjanouse.brq.redhat.com localhost
> 127.0.0.2 both
> ::2 both
> 2001:0000:1234:0000:0000:c1c0:abcd:0876 ip6
> {code}
> I've got this result:{code}
> Tests in error:
> org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase: java.net.ConnectException: JBAS012144: Could not connect to remote://127.0.0.1:9999. The connection timed out
> org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase: java.net.ConnectException: JBAS012144: Could not connect to remote://127.0.0.1:9999. The connection timed out
> org.jboss.as.test.integration.ejb.mdb.containerstart.SendMessagesTestCase: java.net.ConnectException: JBAS012144: Could not connect to remote://127.0.0.1:9999. The connection timed out
> org.jboss.as.test.integration.ejb.mdb.containerstart.SendMessagesTestCase: java.net.ConnectException: JBAS012144: Could not connect to remote://127.0.0.1:9999. The connection timed out
> {code}
> It seems there are several other problems in clustering and domain, but I'll report them after deeper investigation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3970) Failure when using queueless-thread-pool as the pool for a web connector
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-3970:
-------------------------------------
Summary: Failure when using queueless-thread-pool as the pool for a web connector
Key: AS7-3970
URL: https://issues.jboss.org/browse/AS7-3970
Project: Application Server 7
Issue Type: Bug
Components: Server, Web
Affects Versions: 7.1.0.Final
Reporter: Brian Stansberry
Assignee: Jason Greene
User is reporting a failure when configuring a queueless-thread-pool as the pool for a web connector.
The report is for a SIGSEGV but I believe that is just because the native connector is being used; if it weren't this would just show up as a normal java exception.
The relevant code in QueuelessExecutor is here:
if (executor != null) {
executor.execute(task);
} else {
throw new RejectedExecutionException();
}
The exception is thrown because 'executor' is null. We'll need configuration information from the user to understand why that is the case.
Here's the user report:
SIGSEGV occurs when specify queueless-thread-pool to executor of connector
This is a piece of log when the error occurs.
10:13:44,590 ERROR [org.apache.tomcat.util.net.AprEndpoint] (ajp-0.0.0.0-0.0.0.0-8009-Poller) Error allocating socket processor: java.util.concurrent.RejectedExecutionException
at org.jboss.threads.QueuelessExecutor.execute(QueuelessExecutor.java:370) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at org.jboss.threads.DelegatingBlockingExecutorService.execute(DelegatingBlockingExecutorService.java:42) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at org.jboss.as.threads.ManagedExecutorService.execute(ManagedExecutorService.java:64) [jboss-as-threads-7.1.0.CR1-redhat-1.jar:7.1.0.CR1-redhat-1]
at org.apache.tomcat.util.net.AprEndpoint.processSocket(AprEndpoint.java:1007) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1819) [jbossweb-7.0.7.Final-redhat-1.jar:]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
10:13:44,581 ERROR [org.apache.coyote.ajp.AjpAprProtocol] (web-threads - 51) Error reading request, ignored: org.apache.tomcat.jni.Error: Socket operation on non-socket
at org.apache.tomcat.jni.Socket.setrbb(Native Method) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:422) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:480) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2510) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at org.jboss.threads.QueuelessExecutor$Worker.run(QueuelessExecutor.java:614) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002aaac0e94a31, pid=29121, tid=1120581952
#
# JRE version: 6.0_20-b20
# Java VM: OpenJDK 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.9.8
# Distribution: CentOS release 5.6 (Final), package rhel-1.22.1.9.8.el5_6-x86_64
# Problematic frame:
# C [libtcnative-1.so+0x17a31] Java_org_apache_tomcat_jni_Socket_destroy+0x11
#
# An error report file with more information is saved as:
# /root/jboss-eap-6.0/bin/hs_err_pid29121.log
10:13:44,588 ERROR [org.apache.tomcat.util.net.AprEndpoint] (ajp-0.0.0.0-0.0.0.0-8009-Acceptor) Error allocating socket processor: java.util.concurrent.RejectedExecutionException
at org.jboss.threads.QueuelessExecutor.execute(QueuelessExecutor.java:370) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at org.jboss.threads.DelegatingBlockingExecutorService.execute(DelegatingBlockingExecutorService.java:42) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at org.jboss.as.threads.ManagedExecutorService.execute(ManagedExecutorService.java:64) [jboss-as-threads-7.1.0.CR1-redhat-1.jar:7.1.0.CR1-redhat-1]
at org.apache.tomcat.util.net.AprEndpoint.processSocketWithOptions(AprEndpoint.java:982) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:1132) [jbossweb-7.0.7.Final-redhat-1.jar:]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
[thread 1115580736 also had an error]
[thread 1115580736 also had an error]
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3971) CLONE - Failure when using queueless-thread-pool as the pool for a web connector
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-3971:
-------------------------------------
Summary: CLONE - Failure when using queueless-thread-pool as the pool for a web connector
Key: AS7-3971
URL: https://issues.jboss.org/browse/AS7-3971
Project: Application Server 7
Issue Type: Bug
Components: Server, Web
Affects Versions: 7.1.0.Final
Reporter: Brian Stansberry
Assignee: Jason Greene
User is reporting a failure when configuring a queueless-thread-pool as the pool for a web connector.
The report is for a SIGSEGV but I believe that is just because the native connector is being used; if it weren't this would just show up as a normal java exception.
The relevant code in QueuelessExecutor is here:
if (executor != null) {
executor.execute(task);
} else {
throw new RejectedExecutionException();
}
The exception is thrown because 'executor' is null. We'll need configuration information from the user to understand why that is the case.
Here's the user report:
SIGSEGV occurs when specify queueless-thread-pool to executor of connector
This is a piece of log when the error occurs.
10:13:44,590 ERROR [org.apache.tomcat.util.net.AprEndpoint] (ajp-0.0.0.0-0.0.0.0-8009-Poller) Error allocating socket processor: java.util.concurrent.RejectedExecutionException
at org.jboss.threads.QueuelessExecutor.execute(QueuelessExecutor.java:370) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at org.jboss.threads.DelegatingBlockingExecutorService.execute(DelegatingBlockingExecutorService.java:42) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at org.jboss.as.threads.ManagedExecutorService.execute(ManagedExecutorService.java:64) [jboss-as-threads-7.1.0.CR1-redhat-1.jar:7.1.0.CR1-redhat-1]
at org.apache.tomcat.util.net.AprEndpoint.processSocket(AprEndpoint.java:1007) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1819) [jbossweb-7.0.7.Final-redhat-1.jar:]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
10:13:44,581 ERROR [org.apache.coyote.ajp.AjpAprProtocol] (web-threads - 51) Error reading request, ignored: org.apache.tomcat.jni.Error: Socket operation on non-socket
at org.apache.tomcat.jni.Socket.setrbb(Native Method) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:422) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:480) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2510) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at org.jboss.threads.QueuelessExecutor$Worker.run(QueuelessExecutor.java:614) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002aaac0e94a31, pid=29121, tid=1120581952
#
# JRE version: 6.0_20-b20
# Java VM: OpenJDK 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.9.8
# Distribution: CentOS release 5.6 (Final), package rhel-1.22.1.9.8.el5_6-x86_64
# Problematic frame:
# C [libtcnative-1.so+0x17a31] Java_org_apache_tomcat_jni_Socket_destroy+0x11
#
# An error report file with more information is saved as:
# /root/jboss-eap-6.0/bin/hs_err_pid29121.log
10:13:44,588 ERROR [org.apache.tomcat.util.net.AprEndpoint] (ajp-0.0.0.0-0.0.0.0-8009-Acceptor) Error allocating socket processor: java.util.concurrent.RejectedExecutionException
at org.jboss.threads.QueuelessExecutor.execute(QueuelessExecutor.java:370) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at org.jboss.threads.DelegatingBlockingExecutorService.execute(DelegatingBlockingExecutorService.java:42) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
at org.jboss.as.threads.ManagedExecutorService.execute(ManagedExecutorService.java:64) [jboss-as-threads-7.1.0.CR1-redhat-1.jar:7.1.0.CR1-redhat-1]
at org.apache.tomcat.util.net.AprEndpoint.processSocketWithOptions(AprEndpoint.java:982) [jbossweb-7.0.7.Final-redhat-1.jar:]
at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:1132) [jbossweb-7.0.7.Final-redhat-1.jar:]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
[thread 1115580736 also had an error]
[thread 1115580736 also had an error]
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (EJBTHREE-2197) Two WARs containing no-local-view EJBs with same name fails to deploy
by Nicklas Karlsson (JIRA)
Two WARs containing no-local-view EJBs with same name fails to deploy
---------------------------------------------------------------------
Key: EJBTHREE-2197
URL: https://jira.jboss.org/browse/EJBTHREE-2197
Project: EJB 3.0
Issue Type: Bug
Reporter: Nicklas Karlsson
Both try to bind to the same JNDI name causing the second WAR to fail deployment:
13:49:05,276 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs:///C:/Java/AS/jboss-6.0.0-SNAPSHOT/server/default/deploy/LTK.war$Kirjautumistoiminnot state=Create: javax.naming.NameAlreadyBoundException: no-interface
at org.jnp.server.NamingServer.bind(NamingServer.java:209) [:5.0.5.Final]
at org.jnp.server.NamingServer.bind(NamingServer.java:167) [:5.0.5.Final]
at org.jnp.interfaces.NamingContext.bind(NamingContext.java:652) [:5.0.5.Final]
at org.jnp.interfaces.NamingContext.bind(NamingContext.java:613) [:5.0.5.Final]
at org.jboss.util.naming.Util.bind(Util.java:105) [jboss-common-core.jar:2.2.17.GA]
at org.jboss.util.naming.Util.bind(Util.java:91) [jboss-common-core.jar:2.2.17.GA]
at org.jboss.ejb3.nointerface.impl.jndi.SessionAwareNoInterfaceViewJNDIBinder.bindNoInterfaceView(SessionAwareNoInterfaceViewJNDIBinder.java:118) [:]
at org.jboss.ejb3.nointerface.impl.jndi.NoInterfaceViewJNDIBinderFacade.onStart(NoInterfaceViewJNDIBinderFacade.java:127) [:]
at sun.reflect.GeneratedMethodAccessor336.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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.Alpha8]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.Alpha8]
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.Alpha8]
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.Alpha8]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha8]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0-SNAPSHOT]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:130) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:59) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:94) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.1.0.Alpha1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_20]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_20]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_20]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_20]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0_20]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [: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]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months