[JBoss JIRA] (WFCORE-1226) undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1226?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1226:
-------------------------------------------------
Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1280262|https://bugzilla.redhat.com/show_bug.cgi?id=1280262] from MODIFIED to POST
> undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1226
> URL: https://issues.jboss.org/browse/WFCORE-1226
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.4.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 2.0.6.Final
>
> Attachments: WFCORE-1226-wildflytest.patch, WFCORE-1226.patch
>
>
> {noformat}
> 1. Start EAP 6.4.4 in domain mode and deploy application using following CLI command:
> ~~
> [domain@localhost:9999 /] deploy /Applications/WebApp-1.war --server-groups=main-server-group --name=WebApp-1.war --runtime-name=WebApp-1.war
> ~~~
> 2. Deploy next version of application in "disabled" state with same "runtime-name"
> ~~~
> [domain@localhost:9999 /] deploy /Applications/WebApp-2.war --disabled --name=WebApp-2.war --runtime-name=WebApp-1.war
> ~~~
> 3. Now use replace-deployment command to access latest version of application:
> ~~~
> [domain@localhost:9999 /] /server-group=main-server-group:replace-deployment(name=WebApp-2.war,to-replace=WebApp-1.war)
> ~~~
> its working fine,laest version of application is accessable.
> 4. Now try to undeploy old version of application
> ~~~
> /server-group=main-server-group/deployment=WebApp-1.war:undeploy()
> ~~~
> After undploying older version, we are not able to access(404) latest version of application(WebApp-2.war) as well.To access it we have to redeploy it.
> Same steps are working fine in Standalone mode.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFCORE-1198) CLI does not resolve multiple properties if one property is undefined
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1198?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1198:
-------------------------------------------------
Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1289316|https://bugzilla.redhat.com/show_bug.cgi?id=1289316] from MODIFIED to POST
> CLI does not resolve multiple properties if one property is undefined
> ---------------------------------------------------------------------
>
> Key: WFCORE-1198
> URL: https://issues.jboss.org/browse/WFCORE-1198
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.4.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 2.0.5.Final
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1289316 description:
> {noformat}
> Multiple property substitution is working with EAP 6.4.3+, however, if a variable amongst the multiple variables is empty or has no value, then the subsequent property in the CLI command is not substituted.
> For example :
> cat props.properties
> -----------------------------------------
> PROFILE-NAME=TestProfile
> SERVER-INSTANCE-NUMBER=TestInstance
> APP-VERSION=
> VAR=test
> -----------------------------------------
> cat test.cli :
> ---------------------------------------
> /host=master/server-config=${PROFILE-NAME}${APP-VERSION}${SERVER-INSTANCE-NUMBER}${VAR}:add(auto-start=true, group="${PROFILE-NAME}${APP-VERSION}-server-group")
> ---------------------------------------
> and if I execute "./jboss-cli.sh --connect --file=test.cli --properties=props.properties" then I have the following in the host.xml ":
> ----------
> ...
> <server name="TestProfile${SERVER-INSTANCE-NUMBER}test" group="TestProfile-server-group" auto-start="true"/>
> ...
> -----------
> Note APP-VERSION had no value, and so the subsequent SERVER-INSTANCE-NUMBER was not properly resolved
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFCORE-1257) support query filter implementation in MBeanServerConnection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1257?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1257:
-------------------------------------------------
Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1294010|https://bugzilla.redhat.com/show_bug.cgi?id=1294010] from MODIFIED to POST
> support query filter implementation in MBeanServerConnection
> ------------------------------------------------------------
>
> Key: WFCORE-1257
> URL: https://issues.jboss.org/browse/WFCORE-1257
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
> Assignee: Brian Stansberry
> Fix For: 2.0.8.Final
>
>
> There is no implementation for query filter in MBeanServerConnection, marked as TODO
> {code:title=ModelControllerMBeanHelper.java|borderStyle=solid}
> Set<ObjectName> queryNames(final ObjectName name, final QueryExp query) {
> return new RootResourceIterator<Set<ObjectName>>(accessControlUtil, getRootResourceAndRegistration().getResource(),
> new ObjectNameMatchResourceAction<Set<ObjectName>>(name) {
> Set<ObjectName> set = new HashSet<ObjectName>();
> @Override
> public boolean onResource(ObjectName resourceName) {
> if (name == null || name.apply(resourceName)) {
> //TODO check query
> set.add(resourceName);
> }
> return true;
> }
> @Override
> public Set<ObjectName> getResult() {
> if (set.size() == 1 && set.contains(ModelControllerMBeanHelper.createRootObjectName(domain))) {
> return Collections.emptySet();
> }
> return set;
> }
> }).iterate();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFCORE-1304) WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1304?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1304:
-------------------------------------------------
Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1299189|https://bugzilla.redhat.com/show_bug.cgi?id=1299189] from MODIFIED to POST
> 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
> Fix For: 2.0.8.Final
>
>
> 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)
8 years, 1 month
[JBoss JIRA] (WFCORE-1245) Improve readability of missing dependency logs
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1245?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1245:
-------------------------------------------------
Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1283294|https://bugzilla.redhat.com/show_bug.cgi?id=1283294] from MODIFIED to POST
> Improve readability of missing dependency logs
> ----------------------------------------------
>
> Key: WFCORE-1245
> URL: https://issues.jboss.org/browse/WFCORE-1245
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
> Attachments: after_1.log, after_2.log, before.log, bz1283294-reproducer.zip
>
>
> When deploying an ear using initialize-in-order option, if one of the subdeployments contains an EJB that depends on an EJB from another subdeployment and the dependency subdeployment fails log output makes it hard to understand the root cause.
> Structure of deployment is as follows:
> {noformat}
> reproducer.ear
> |- service-locator.jar
> | |- ServiceLocator (Stateless EJB)
> | |- TestQueue (JNDI Resource)
> |- client.jar
> |- TestEjb (Stateless EJB)
> |- ServiceLocator
> {noformat}
> If the TestQueue JNDI resource cannot be injected in the ServiceLocator, the deployment failure output lists a number of missing services per each EJB in the dependant subdeployment (.ORB, .HandleDelegate, .ValidatorFactory, etc).
> When the dependant subdeployment has a larger number of EJBs the log output very quickly becomes hard to read.
> Example with a single dependant EJB:
> {noformat}
> 14:27:43,092 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "reproducer-1.0-SNAPSHOT.ear"}) - failure description: {
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".batch.environment is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.ValidatorFactory is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.ORB is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.HandleDelegate is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
> "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".deploymentCompleteService is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".deploymentCompleteService]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.InstanceName is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.Validator is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.service-locator.test_ServiceLocator.env.queue.TestQueue is missing [jboss.naming.context.java.jboss.resources.queue.TestQueue]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.InAppClientContainer is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]"
> ],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".INSTALL",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".CLEANUP",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.JndiBindingsService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.START",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".deploymentCompleteService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".jndiDependencyService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".moduleDeploymentRuntimeInformationStart",
> "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".CLEANUP"
> ]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6 addresses in server log
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5242?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5242:
-----------------------------------------------
Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1258298|https://bugzilla.redhat.com/show_bug.cgi?id=1258298] from MODIFIED to POST
> Inconsistent format for IPv6 addresses in server log
> ----------------------------------------------------
>
> Key: WFLY-5242
> URL: https://issues.jboss.org/browse/WFLY-5242
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta2
> Reporter: Lyle Wang
> Assignee: Chao Wang
> Priority: Minor
> Fix For: 10.0.0.CR1
>
>
> Description of problem:
> When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs.
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports)
> 2. Start WildFly and check the log
> Actual results:
> ----------------------------------------
> 2015-08-31 12:51:47,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080
> ......
> 2015-08-31 12:51:48,431 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management
> 2015-08-31 12:51:48,432 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993
> ----------------------------------------
> In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management"
> Expected results:
> Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month