[JBoss JIRA] (WFLY-8173) Make build scripts handle default settings.xml correctly
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/WFLY-8173?page=com.atlassian.jira.plugin.... ]
Peter Palaga moved JBEAP-8984 to WFLY-8173:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8173 (was: JBEAP-8984)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Build System
Test Suite
(was: Build System)
(was: Productization)
(was: Test Suite)
Affects Version/s: (was: 7.1.0.DR12)
Affects Testing: (was: Regression)
> Make build scripts handle default settings.xml correctly
> --------------------------------------------------------
>
> Key: WFLY-8173
> URL: https://issues.jboss.org/browse/WFLY-8173
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Test Suite
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Priority: Critical
>
> *Wrong behaviour in EAP 7.1.0.DR12*
> * mvnw, build.sh and integration-tests.sh does't use productized settings.xml by default.
> *Desired behaviour*
> * mvnw, build.sh and integration-tests.sh should use productized settings.xml by default.
> *Workaround for build.sh*
> Productized settings.xml needs to be defined manually by "-s" maven property, example:
> ./build.sh clean -Dmaven.repo.local=$NEW_REPO -DallTests -Djboss.test.mixed.domain.dir=$\{HUDSON_STATIC_ENV\}/eap/archives-repository/mixed-domain -s tools/maven/conf/settings.xml
> *Workaround for integration-tests.sh*
> Absolute path needs to be used (see JBEAP-8947), example: "-s /mnt/hudson_workspace/mkopecky/ts/tools/maven/conf/settings.xml"
> *Additional information:*
> * productized settings.xml is added in [this productization commit|http://git.app.eng.bos.redhat.com/git/wildfly/wildfly.git/commit/t...]
> * "tools/maven/conf/settings.xml" location doesn't make sense, because [download-maven.sh script was removed|https://github.com/jbossas/jboss-eap7/pull/1334/files#diff-d91a6a...]. But I recommend to keep current location because of backward compatibility
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2003) Deliver message batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2003?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2003:
---------------------------
Description:
Currently, message batches are sent up tp the channel, which delivers its messages one-by-one, e.g. by calling the {{Receiver.receive(Message msg)}} callback.
Another callback {{Receiver.receive(MessageBatch batch)}} should be added (also to RpcDispatcher), to deliver a batch of messages at once. The default implementation is to pass messages up one-by-one.
This should result in performance increase, as the application can handle multiple messages at once.
was:
Currently, message batches are sent up tp the channel, which delivers its messages one-by-one, e.g. by calling the {{Receiver.receive(Message msg)}} callback.
Another callback {{Receiver.receive(MessageBatch batch)}} should be added (also to RpcDispatcher), to deliver a batch of messages at once.
This should result in performance increase, as the application can handle multiple messages at once.
> Deliver message batches
> -----------------------
>
> Key: JGRP-2003
> URL: https://issues.jboss.org/browse/JGRP-2003
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, message batches are sent up tp the channel, which delivers its messages one-by-one, e.g. by calling the {{Receiver.receive(Message msg)}} callback.
> Another callback {{Receiver.receive(MessageBatch batch)}} should be added (also to RpcDispatcher), to deliver a batch of messages at once. The default implementation is to pass messages up one-by-one.
> This should result in performance increase, as the application can handle multiple messages at once.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-393) Clone a profile
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-393:
------------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1125143|https://bugzilla.redhat.com/show_bug.cgi?id=1125143] from ASSIGNED to CLOSED
> Clone a profile
> ---------------
>
> Key: WFCORE-393
> URL: https://issues.jboss.org/browse/WFCORE-393
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
> Fix For: 2.0.0.Alpha4
>
>
> Add the ability to clone a profile.
> This could be a new "clone" operation on the existing profile resource, or perhaps a "clone-from" parameter on the existing "add" operation. Probably the former, as that will be more transformation-friendly.
> Implementation will likely involve using the "describe" operation used for configuring managed domain servers and adding steps from the describe results directly on the HC instead of passing them to a server.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2314) Incorrectly closed header results in not helping IllegalArgumentException with null message
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2314?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-8976 to WFCORE-2314:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2314 (was: JBEAP-8976)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
Domain Management
(was: CLI)
(was: Domain Management)
(was: User Experience)
Affects Version/s: (was: 7.1.0.DR11)
> Incorrectly closed header results in not helping IllegalArgumentException with null message
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-2314
> URL: https://issues.jboss.org/browse/WFCORE-2314
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Radim Hatlapatka
> Assignee: Brian Stansberry
> Labels: user_experience
>
> Calling {{/core-service=management/security-realm=bbb:add(){allow-resource-service-restart=true)}} (notice incorrectly closed allow-resource-service-restart with ")" instead of "}" results in
> {noformat}
> [standalone@localhost:9990 /] /core-service=management/security-realm=bbb:add(){allow-resource-service-restart=true)
> {
> "outcome" => "failed",
> "failure-description" => "java.lang.IllegalArgumentException:null"
> }
> {noformat}
> with this message in server.log:
> {noformat}
> 14:20:12,440 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
> "address" => [
> ("core-service" => "management"),
> ("security-realm" => "bbb")
> ],
> "operation" => "add",
> "operation-headers" => {
> "allow-resource-service-restart" => "true)",
> "caller-type" => "user",
> "access-mechanism" => "NATIVE"
> }
> }]: java.lang.IllegalArgumentException
> at org.jboss.dmr.StringModelValue.asBoolean(StringModelValue.java:157)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:346)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:240)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:193)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:240)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:212)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> {noformat}
> The IllegalArgumentException should point in the message what argument is incorrect and what is wrong. Printing only null doesn't help much.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8170) Native interface got left behind in standalone-minimalistic.xml config
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8170:
--------------------------------------
Summary: Native interface got left behind in standalone-minimalistic.xml config
Key: WFLY-8170
URL: https://issues.jboss.org/browse/WFLY-8170
Project: WildFly
Issue Type: Bug
Components: Domain Management
Affects Versions: 10.1.0.Final
Reporter: Alexey Loubyansky
Assignee: Brian Stansberry
Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
These operations are executed when the minimalistic config is loaded:
{code}
/core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
/socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
/core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
/core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
/socket-binding-group=standard-sockets:add(default-interface="public")
{code}
These operations are executed as part of the default core config:
{code}
/core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
/socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
/socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
/core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
/socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months