[JBoss JIRA] (WFCORE-2148) --server-config behaves like --read-only-server-config
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2148?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2148:
------------------------------------------
I'm not sure this is meant to work at all, or perhaps it's working somewhat how we intended and the server will only persist to the configuration directory.
> --server-config behaves like --read-only-server-config
> ------------------------------------------------------
>
> Key: WFCORE-2148
> URL: https://issues.jboss.org/browse/WFCORE-2148
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Environment: Java version: 1.8.0_66, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_66.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
> Reporter: Gunther v. Wolffersdorff
> Labels: --server-config
>
> When using command line option *-c* or *--server-config* changes to the management model are not written to the configuration file. Seems to me like the behavior expected for --read-only-server-config option.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-1047) Rollback of undeploy and deployment remove will fail
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1047?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1047:
-------------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1409644|https://bugzilla.redhat.com/show_bug.cgi?id=1409644] from NEW to POST
> Rollback of undeploy and deployment remove will fail
> ----------------------------------------------------
>
> Key: WFCORE-1047
> URL: https://issues.jboss.org/browse/WFCORE-1047
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Final, 2.0.0.CR6
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 2.0.0.CR7
>
>
> This looks like a problem that's been around since Sept 2012.
> The rollback handling in DeploymentHandlerUtil.undeploy and in DeploymentRemoveHandler both try to read the deployment's management name from the deployment resource, but since [1] it hasn't been stored there. So rollback will fail with something like this:
> {code}
> [Server:main-one] 15:58:54,894 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 2) WFLYCTL0190: Step handler org.jboss.as.server.deployment.DeploymentHandlerUtil$5@2a0a9f3f for operation {"operation" => "undeploy","address" => [("deployment" => "broken.jar")],"operation-headers" => {}} at address [("deployment" => "broken.jar")] failed handling operation rollback -- java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child 'name' exists
> [Server:main-one] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:377) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> [Server:main-one] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> [Server:main-one] at org.jboss.dmr.ModelNode.require(ModelNode.java:870) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> [Server:main-one] at org.jboss.as.server.deployment.DeploymentHandlerUtil$5$1.handleResult(DeploymentHandlerUtil.java:331) [wildfly-server-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_45]
> [Server:main-one] at javax.security.auth.Subject.doAs(Subject.java:360) [rt.jar:1.8.0_45]
> [Server:main-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_45]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:364) [wildfly-protocol-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:466) [wildfly-protocol-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45]
> [Server:main-one] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> [Server:main-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> {code}
> [1] https://github.com/wildfly/wildfly-core/commit/f38b37#diff-2dbd1fc9261de7...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-2148) --server-config behaves like --read-only-server-config
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2148?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2148:
----------------------------------------
Assignee: (was: Jason Greene)
> --server-config behaves like --read-only-server-config
> ------------------------------------------------------
>
> Key: WFCORE-2148
> URL: https://issues.jboss.org/browse/WFCORE-2148
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Environment: Java version: 1.8.0_66, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_66.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
> Reporter: Gunther v. Wolffersdorff
> Labels: --server-config
>
> When using command line option *-c* or *--server-config* changes to the management model are not written to the configuration file. Seems to me like the behavior expected for --read-only-server-config option.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-2148) --server-config behaves like --read-only-server-config
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2148?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-7022 to WFCORE-2148:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2148 (was: WFLY-7022)
Component/s: Server
(was: Server)
Affects Version/s: (was: 10.1.0.Final)
> --server-config behaves like --read-only-server-config
> ------------------------------------------------------
>
> Key: WFCORE-2148
> URL: https://issues.jboss.org/browse/WFCORE-2148
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Environment: Java version: 1.8.0_66, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_66.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
> Reporter: Gunther v. Wolffersdorff
> Assignee: Jason Greene
> Labels: --server-config
>
> When using command line option *-c* or *--server-config* changes to the management model are not written to the configuration file. Seems to me like the behavior expected for --read-only-server-config option.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7062) Infinispan query NPE on caches created by EmbeddedCacheManager
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7062?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-7062:
--------------------------------------
Component/s: Clustering
Assignee: Paul Ferraro (was: Jason Greene)
> Infinispan query NPE on caches created by EmbeddedCacheManager
> --------------------------------------------------------------
>
> Key: WFLY-7062
> URL: https://issues.jboss.org/browse/WFLY-7062
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Fedora 24
> openjdk version "1.8.0_102"
> OpenJDK Runtime Environment (build 1.8.0_102-b14)
> OpenJDK 64-Bit Server VM (build 25.102-b14, mixed mode)
> Reporter: Pavol Loffay
> Assignee: Paul Ferraro
> Priority: Blocker
>
> Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final.
> Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine.
> https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
> When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception:
> https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
> Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final).
> Application source code: https://github.com/pavolloffay/infinispan-wildfly10
> Exception when updated to 8.2.4.Final and deployed to Wildfly 10.1.0.Final
> {code:java}
> 15:51:14,692 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /stringContainer: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> 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)
> Caused by: java.lang.NullPointerException
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:42)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:49)
> at sk.loffay.cache.StringCacheContainer.query(StringCacheContainer.java:53)
> at sk.loffay.rest.ContainerHandler.getContainer(ContainerHandler.java:43)
> at sk.loffay.rest.ContainerHandler$Proxy$_$$_WeldClientProxy.getContainer(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
> ... 42 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-2147) Impossible to use environment variables or system properties in permissions.xml
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2147?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-7313 to WFCORE-2147:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2147 (was: WFLY-7313)
Component/s: Security
(was: Security Manager)
Affects Version/s: (was: 10.1.0.Final)
> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2147
> URL: https://issues.jboss.org/browse/WFCORE-2147
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Adrian Boangiu
> Assignee: Jason Greene
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> {noformat}
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> {noformat}
> that were defined in Java policy file in previous verions of JBoss.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-2147) Impossible to use environment variables or system properties in permissions.xml
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2147?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2147:
----------------------------------------
Assignee: Darran Lofthouse (was: Jason Greene)
> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2147
> URL: https://issues.jboss.org/browse/WFCORE-2147
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Adrian Boangiu
> Assignee: Darran Lofthouse
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> {noformat}
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> {noformat}
> that were defined in Java policy file in previous verions of JBoss.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7548) Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7548?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-7548:
--------------------------------------
Component/s: Web (Undertow)
Assignee: Stuart Douglas (was: Jason Greene)
> Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-7548
> URL: https://issues.jboss.org/browse/WFLY-7548
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0.Final
> Reporter: Kálmán Szalai
> Assignee: Stuart Douglas
> Priority: Minor
>
> Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final. I saw WildFly 2.2.0.Final is the Wildfly Core version.
> Additionally the admin interfacde shows:
> Product name: WildFly Full
> Product version: 10.1.0.Final
> Profile: COMMUNITY
> HAL version: 2.8.27.Final
> Core version: 2.8.27.Final
> Wildfly 8 is produced Wildfly 8 version sting on getServerInfo() call.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7558) Replacing a deployment (which uses a different runtime name), starts using the filename as runtime-name
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7558?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-7558:
--------------------------------------
Assignee: Harald Pehl (was: Jason Greene)
I think I've seen another JIRA with a similar report.
> Replacing a deployment (which uses a different runtime name), starts using the filename as runtime-name
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7558
> URL: https://issues.jboss.org/browse/WFLY-7558
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 10.1.0.Final
> Environment: OS X client, wildfly domain is running on CentOS 7
> Reporter: Jeff Scott
> Assignee: Harald Pehl
>
> This is a two step problem. If an ear has been uploaded and configured to use a different runtime name that works and the domain uses the correct runtime name.
> If I replace the ear it doesn't have an input box to choose a new runtime name- yet it defaults the new runtime name to the filename that's being used to replace the deployment.
> I tried to workaround this by renaming my ear to the runtime name and using that to replace the existing deployment but that gives this exception:
> Cannot upload deployment: {"domain-failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"otherName.ear\")]' not found"}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months