[JBoss JIRA] (WFCORE-1246) System allows enabling two applications with same runtime-name
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1246?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-1246:
-----------------------------------------
Assignee: ehsavoie Hugonnet
> System allows enabling two applications with same runtime-name
> --------------------------------------------------------------
>
> Key: WFCORE-1246
> URL: https://issues.jboss.org/browse/WFCORE-1246
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: WildFly 10CR4 standalone and domain. Both web management and command line
> Reporter: Guillermo González de Agüero
> Assignee: ehsavoie Hugonnet
> Attachments: clustering-demo1.war, clustering-demo2.war
>
>
> System allows multiple applications with same runtime-name to be enabled at the same time, which shoudl be avoided.
> It correctly prevents the deployment of an enabled second application, but doesn't complain if deploying disabled and enabling after that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1305) LoggingSubsystemRollbackTestCase fails intermittently
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1305?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-1305:
----------------------------------
Description:
*Description of problem:*
LoggingSubsystemRollbackTestCase from wildfly-core fails intermittently.
*How reproducible:*
40% with IBM JDK
*Steps to Reproduce:*
# mvn install -Dmaven.repo.local=$MAVEN_REPO_LOCAL -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dmcast=$MCAST_ADDR -DfailIfNoTests=false -Dts.domain -Dtest=LoggingSubsystemRollbackTestCase
*Stacktrace:*
{noformat}
com.sun.tools.attach.AttachNotSupportedException: target not found
at ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
at org.jboss.byteman.agent.install.Install.attach(Install.java:390)
at org.jboss.byteman.agent.install.Install.install(Install.java:129)
at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:516)
at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:669)
at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:73)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{noformat}
*Standard Output:*
{noformat}
byteman jar is /mnt/hudson_workspace/eap-7x-as-testsuite-test-core-rhel/19de6045/eap-local-maven-repository/org/jboss/byteman/byteman/2.2.1/byteman-2.2.1.jar
{noformat}
*Expected results:*
No errors
*Additional info:*
Jenkins reproducer job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T...
was:
*Description of problem:*
LoggingSubsystemRollbackTestCase from wildfly-core fails intermittently.
*How reproducible:*
40%
*Steps to Reproduce:*
# mvn install -Dmaven.repo.local=$MAVEN_REPO_LOCAL -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dmcast=$MCAST_ADDR -DfailIfNoTests=false -Dts.domain -Dtest=LoggingSubsystemRollbackTestCase
*Stacktrace:*
{noformat}
com.sun.tools.attach.AttachNotSupportedException: target not found
at ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
at org.jboss.byteman.agent.install.Install.attach(Install.java:390)
at org.jboss.byteman.agent.install.Install.install(Install.java:129)
at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:516)
at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:669)
at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:73)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{noformat}
*Standard Output:*
{noformat}
byteman jar is /mnt/hudson_workspace/eap-7x-as-testsuite-test-core-rhel/19de6045/eap-local-maven-repository/org/jboss/byteman/byteman/2.2.1/byteman-2.2.1.jar
{noformat}
*Expected results:*
No errors
*Additional info:*
Jenkins reproducer job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T...
> LoggingSubsystemRollbackTestCase fails intermittently
> -----------------------------------------------------
>
> Key: WFCORE-1305
> URL: https://issues.jboss.org/browse/WFCORE-1305
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.6.Final
> Reporter: Marek Kopecký
> Assignee: James Perkins
>
> *Description of problem:*
> LoggingSubsystemRollbackTestCase from wildfly-core fails intermittently.
> *How reproducible:*
> 40% with IBM JDK
> *Steps to Reproduce:*
> # mvn install -Dmaven.repo.local=$MAVEN_REPO_LOCAL -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dmcast=$MCAST_ADDR -DfailIfNoTests=false -Dts.domain -Dtest=LoggingSubsystemRollbackTestCase
> *Stacktrace:*
> {noformat}
> com.sun.tools.attach.AttachNotSupportedException: target not found
> at ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
> at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
> at org.jboss.byteman.agent.install.Install.attach(Install.java:390)
> at org.jboss.byteman.agent.install.Install.install(Install.java:129)
> at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:516)
> at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:669)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:73)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Standard Output:*
> {noformat}
> byteman jar is /mnt/hudson_workspace/eap-7x-as-testsuite-test-core-rhel/19de6045/eap-local-maven-repository/org/jboss/byteman/byteman/2.2.1/byteman-2.2.1.jar
> {noformat}
> *Expected results:*
> No errors
> *Additional info:*
> Jenkins reproducer job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1305) LoggingSubsystemRollbackTestCase fails intermittently
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1305?page=com.atlassian.jira.plugi... ]
Marek Kopecký moved JBEAP-2835 to WFCORE-1305:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1305 (was: JBEAP-2835)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Test Suite
(was: Test Suite)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.6.Final
(was: 7.0.0.ER4)
Affects Testing: (was: Regression)
> LoggingSubsystemRollbackTestCase fails intermittently
> -----------------------------------------------------
>
> Key: WFCORE-1305
> URL: https://issues.jboss.org/browse/WFCORE-1305
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.6.Final
> Reporter: Marek Kopecký
> Assignee: James Perkins
>
> *Description of problem:*
> LoggingSubsystemRollbackTestCase from wildfly-core fails intermittently.
> *How reproducible:*
> 40%
> *Steps to Reproduce:*
> # mvn install -Dmaven.repo.local=$MAVEN_REPO_LOCAL -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dmcast=$MCAST_ADDR -DfailIfNoTests=false -Dts.domain -Dtest=LoggingSubsystemRollbackTestCase
> *Stacktrace:*
> {noformat}
> com.sun.tools.attach.AttachNotSupportedException: target not found
> at ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
> at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
> at org.jboss.byteman.agent.install.Install.attach(Install.java:390)
> at org.jboss.byteman.agent.install.Install.install(Install.java:129)
> at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:516)
> at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:669)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:73)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Standard Output:*
> {noformat}
> byteman jar is /mnt/hudson_workspace/eap-7x-as-testsuite-test-core-rhel/19de6045/eap-local-maven-repository/org/jboss/byteman/byteman/2.2.1/byteman-2.2.1.jar
> {noformat}
> *Expected results:*
> No errors
> *Additional info:*
> Jenkins reproducer job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1029) Matching expires attribute and accumulate time window makes events expiry infinite
by Thibault Daoulas (JIRA)
Thibault Daoulas created DROOLS-1029:
----------------------------------------
Summary: Matching expires attribute and accumulate time window makes events expiry infinite
Key: DROOLS-1029
URL: https://issues.jboss.org/browse/DROOLS-1029
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Environment: Windows 10, Java 8
Reporter: Thibault Daoulas
Assignee: Mario Fusco
I have declared an event with an attribute @expires 10m.
I have a rule which accumulates these events over window:time(10m).
With this setup, the number of facts keeps growing in WM beyond 10 minutes of corresponding facts.
If I set the the expires to less, say 9 minutes, they do expire after 9 minutes, and if I set the expires to 11 minutes, they do expire after 11 minutes.
So it looks like matching @expires and accumulate time window void any expiry. I couldn't find anything on this in the documentation and please correct if this has been reported already.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6021) Default transaction timeout is not applied for EJB bean when set for second time
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6021?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka reassigned WFLY-6021:
--------------------------------------
Assignee: David Lloyd (was: Tom Jenkinson)
> Default transaction timeout is not applied for EJB bean when set for second time
> --------------------------------------------------------------------------------
>
> Key: WFLY-6021
> URL: https://issues.jboss.org/browse/WFLY-6021
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Ondřej Chaloupka
> Assignee: David Lloyd
>
> It seems that transaction subsystem attribute {{default-timeout}} does not have any effect for EJB if it's redefined. It means if I set the default transaction timeout in transaction subystem for second (and next) time it's not applied for EJB beans. It's used the firstly set value.
> The transaction timeout is not changed for EJB when server is reloaded. When server is restarted it refreshes all settings and EJB starts using the expected value for timeout settings.
> If the value is read from subsystem
> {{/subsystem=transactions:read-attribute(name=default-timeout)}}
> it shows correct value (that one set for second time). But EJB seems not applying it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6021) Default transaction timeout is not applied for EJB bean when set for second time
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created WFLY-6021:
--------------------------------------
Summary: Default transaction timeout is not applied for EJB bean when set for second time
Key: WFLY-6021
URL: https://issues.jboss.org/browse/WFLY-6021
Project: WildFly
Issue Type: Bug
Components: Transactions, EJB
Reporter: Ondřej Chaloupka
Assignee: Tom Jenkinson
It seems that transaction subsystem attribute {{default-timeout}} does not have any effect for EJB if it's redefined. It means if I set the default transaction timeout in transaction subystem for second (and next) time it's not applied for EJB beans. It's used the firstly set value.
The transaction timeout is not changed for EJB when server is reloaded. When server is restarted it refreshes all settings and EJB starts using the expected value for timeout settings.
If the value is read from subsystem
{{/subsystem=transactions:read-attribute(name=default-timeout)}}
it shows correct value (that one set for second time). But EJB seems not applying it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-452) MVEL validates illegal expressions using ":"
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-452?page=com.atlassian.jira.plugin... ]
Petr Široký resolved DROOLS-452.
--------------------------------
Fix Version/s: 6.4.x
Resolution: Done
This has been somehow fixed over the time (without a link to specific commit). Compiler now reports error.
> MVEL validates illegal expressions using ":"
> --------------------------------------------
>
> Key: DROOLS-452
> URL: https://issues.jboss.org/browse/DROOLS-452
> Project: Drools
> Issue Type: Bug
> Reporter: Davide Sottara
> Assignee: Petr Široký
> Priority: Minor
> Fix For: 6.4.x
>
>
> A rule like this
> {code}
> rule "Typo"
> dialect "mvel"
> when
> ...
> then
> // Notice the ":" in place of ";". There is also a \n at the end of the line
> System.out.println( "Hello" ):
> // more statements here
> end
> {code}
> MVEL will validate the RHS at compile time.
> At runtime, the printout (actually any statement ending with ":") will be
> executed, but MVEL will fail silently thereafter. The rest of the conclusion
> will not be evaluated.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1304) WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1304?page=com.atlassian.jira.plugi... ]
Chao Wang moved WFLY-6018 to WFCORE-1304:
-----------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1304 (was: WFLY-6018)
Component/s: Domain Management
(was: Server)
> WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1304
> URL: https://issues.jboss.org/browse/WFCORE-1304
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brad Maxwell
> Assignee: Chao Wang
>
> Mac OS can put .DS_Store files into the content repo directory. This can also be reproduced on Linux by creating a file under the content dir and when clean-obsolete-content() runs it will log this error. It seems it runs every 10 minutes.
> {code}
> 22:59:48,289 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 1) WFLYDR0009: Content /Users/bradley/Desktop/wildfly-10.0.0.CR5/standalone/data/content/9b/.DS_Store is obsolete and will be removed
> 22:59:48,290 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> at java.lang.String.charAt(String.java:658)
> at org.jboss.as.repository.HashUtil.hexStringToByteArray(HashUtil.java:62)
> at org.jboss.as.repository.ContentReference.getHash(ContentReference.java:68)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:365)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.markAsObsolete(ContentRepository.java:427)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:403)
> at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 22:59:48,292 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months