[JBoss JIRA] (WFCORE-2042) Improve query operation for nested child resources
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2042?page=com.atlassian.jira.plugi... ]
Lin Gao commented on WFCORE-2042:
---------------------------------
Please take a look at the proposed requirements document at: https://developer.jboss.org/docs/DOC-56005 :)
> Improve query operation for nested child resources
> --------------------------------------------------
>
> Key: WFCORE-2042
> URL: https://issues.jboss.org/browse/WFCORE-2042
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Lin Gao
> Assignee: Michal Petrov
>
> This is another similar RFE as WFCORE-2041.
> It would be good if the 'query()' operation can filter the resources by specifying value of attributes which are +inside of nested child resources(not only by the first level of child resource)+, so that, for example, the following command can work well as expected:
> {code:}
> [standalone@localhost:9990 /] /subsystem=security:query(select=[security-domain], where={security-domain.authentication.login-modules.code=RealmDirect})
> {
> "outcome" => "success",
> "result" => undefined
> }
> // here the expected output are the security-domain resources which have the loging-module RealmDirect defined.
> {code}
> The {{security-domain.authentication.login-modules.code}} in 'where' parameter is proposed attribute name in enhanced syntax, other options maybe possible.
> The different requirements between this WFCORE-2042 and WFCORE-2041 are:
> * WFCORE-2041 focus on complex attributes in one management resource
> * WFCORE-2042 focus on nested management resources with or without complex attributes
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8920) Adding application-security-domain in EJB subsystem requires server reload
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8920?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas commented on WFLY-8920:
------------------------------------
[~brian.stansberry] I added reproducer to Steps to Reproduce in JBEAP-11450.
> Adding application-security-domain in EJB subsystem requires server reload
> --------------------------------------------------------------------------
>
> Key: WFLY-8920
> URL: https://issues.jboss.org/browse/WFLY-8920
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Ingo Weiss
> Priority: Critical
>
> When application-security-domain is added in EJB subsystem then it is not used until server is reloaded. However CLI command does not set server to {{reload-required}} state, see:
> {code}
> /subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain)
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8927) Review & fix xml persistence of elytron subsystem
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-8927:
---------------------------------
Summary: Review & fix xml persistence of elytron subsystem
Key: WFLY-8927
URL: https://issues.jboss.org/browse/WFLY-8927
Project: WildFly
Issue Type: Task
Components: Domain Management, Security
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
Elytron subsystem uses a mess of parsers and duplicate code in them.
Go trough all parsers and unify attribute persistence with rest of the server.
also get rid as much of custom parser code as possible.
Update XSDs where appropriate to follow common model.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2947) Review & fix xml persistence of elytron subsystem
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-2947:
-----------------------------------
Summary: Review & fix xml persistence of elytron subsystem
Key: WFCORE-2947
URL: https://issues.jboss.org/browse/WFCORE-2947
Project: WildFly Core
Issue Type: Task
Components: Domain Management, Security
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
Elytron subsystem uses a mess of parsers and duplicate code in them.
Go trough all parsers and unify attribute persistence with rest of the server.
also get rid as much of custom parser code as possible.
Update XSDs where appropriate to follow common model.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8926) Review & fix xml persistence of elytron subsystem
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8926?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar moved WFCORE-2947 to WFLY-8926:
-------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-8926 (was: WFCORE-2947)
Component/s: Domain Management
Security
(was: Domain Management)
(was: Security)
> Review & fix xml persistence of elytron subsystem
> -------------------------------------------------
>
> Key: WFLY-8926
> URL: https://issues.jboss.org/browse/WFLY-8926
> Project: WildFly
> Issue Type: Task
> Components: Domain Management, Security
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> Elytron subsystem uses a mess of parsers and duplicate code in them.
> Go trough all parsers and unify attribute persistence with rest of the server.
> also get rid as much of custom parser code as possible.
> Update XSDs where appropriate to follow common model.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2946) Errors publishing a large deployment to a remote server (EAP 7.1 management)
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2946?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet updated WFCORE-2946:
--------------------------------------
Component/s: Domain Management
> Errors publishing a large deployment to a remote server (EAP 7.1 management)
> ----------------------------------------------------------------------------
>
> Key: WFCORE-2946
> URL: https://issues.jboss.org/browse/WFCORE-2946
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Rob Stryker
> Assignee: ehsavoie Hugonnet
>
> I tried to verify EAP 7.1 incremental deployment (JBIDE-23784).
> So I first deployed a simple dynamic web project over management API to a remote EAP 7.1 (on a remote machine). Everything fine so far.
> Then I just copied a big jar (devstudio installer) into the WebContent dir of the project. Then I did a Refresh of the project in Eclipse and I immediately got an error:
> {code}
> Could not publish to the server.
> org.jboss.ide.eclipse.as.management.core.JBoss7ManangerException: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.ide.eclipse.as.internal.management.wf11.DeploymentOperationResult.getStatus(DeploymentOperationResult.java:68)
> at org.jboss.ide.eclipse.as.internal.management.wf11.WildFly11Manager.waitFor(WildFly11Manager.java:231)
> at org.jboss.ide.eclipse.as.internal.management.wf11.WildFly11Manager.incrementalPublish(WildFly11Manager.java:601)
> at org.jboss.ide.eclipse.as.internal.management.wf11.WildFly11ManagerService.incrementalPublish(WildFly11ManagerService.java:201)
> at org.jboss.ide.eclipse.as.management.core.JBoss7ManagerServiceProxy.incrementalPublish(JBoss7ManagerServiceProxy.java:134)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController$IncrementalManagementPublishRunner.incrementalPublish(ManagementPublishController.java:530)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.incrementalPublish(ManagementPublishController.java:474)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.publishModule(ManagementPublishController.java:257)
> at org.jboss.ide.eclipse.as.wtp.core.server.behavior.ControllableServerBehavior.publishModule(ControllableServerBehavior.java:143)
> at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:1091)
> at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:1183)
> at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:987)
> at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:774)
> at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:3182)
> at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:355)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> Caused by: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:281)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:62)
> at org.jboss.as.controller.client.impl.ConvertingDelegatingAsyncFuture.get(ConvertingDelegatingAsyncFuture.java:69)
> at org.jboss.as.controller.client.impl.ConvertingDelegatingAsyncFuture.get(ConvertingDelegatingAsyncFuture.java:41)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:94)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> at org.jboss.ide.eclipse.as.internal.management.wf11.DeploymentOperationResult.getStatus(DeploymentOperationResult.java:65)
> ... 15 more
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3236)
> at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)
> at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
> at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)
> at org.jboss.as.protocol.StreamUtils.copyStream(StreamUtils.java:52)
> at org.jboss.as.controller.client.impl.InputStreamEntry$InMemoryEntry.initialize(InputStreamEntry.java:76)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$ReadAttachmentInputStreamRequestHandler$1.execute(AbstractModelControllerClient.java:220)
> 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)
> {code}
> The server adapter showed [Republish]. So I tried to do a full publish, but that kind of failed. It first showed 19 %, now it's been at 29 % for 5 minutes and nothing seems to be happening. The server adapter says [Started, Publishing...] and the module says [Republish]. And I can't even stop the server, it's stuck.
> I restarted the IDE. Killed the EAP server on the remote host. Started the server again in the IDE. It showed my module is started. The index worked, the jar was not found. So now I did a full publish on the module. I could see that something was being sent over the network. Then the traffic was over and it was at 33 % for a while and finally it finished successfully this time. So at least that. Then I could add another jsp and it redeployed the module without having to send over the big file again. So at least that worked now.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2946) Errors publishing a large deployment to a remote server (EAP 7.1 management)
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2946?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-2946:
-----------------------------------------
Assignee: ehsavoie Hugonnet
> Errors publishing a large deployment to a remote server (EAP 7.1 management)
> ----------------------------------------------------------------------------
>
> Key: WFCORE-2946
> URL: https://issues.jboss.org/browse/WFCORE-2946
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Rob Stryker
> Assignee: ehsavoie Hugonnet
>
> I tried to verify EAP 7.1 incremental deployment (JBIDE-23784).
> So I first deployed a simple dynamic web project over management API to a remote EAP 7.1 (on a remote machine). Everything fine so far.
> Then I just copied a big jar (devstudio installer) into the WebContent dir of the project. Then I did a Refresh of the project in Eclipse and I immediately got an error:
> {code}
> Could not publish to the server.
> org.jboss.ide.eclipse.as.management.core.JBoss7ManangerException: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.ide.eclipse.as.internal.management.wf11.DeploymentOperationResult.getStatus(DeploymentOperationResult.java:68)
> at org.jboss.ide.eclipse.as.internal.management.wf11.WildFly11Manager.waitFor(WildFly11Manager.java:231)
> at org.jboss.ide.eclipse.as.internal.management.wf11.WildFly11Manager.incrementalPublish(WildFly11Manager.java:601)
> at org.jboss.ide.eclipse.as.internal.management.wf11.WildFly11ManagerService.incrementalPublish(WildFly11ManagerService.java:201)
> at org.jboss.ide.eclipse.as.management.core.JBoss7ManagerServiceProxy.incrementalPublish(JBoss7ManagerServiceProxy.java:134)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController$IncrementalManagementPublishRunner.incrementalPublish(ManagementPublishController.java:530)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.incrementalPublish(ManagementPublishController.java:474)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.publishModule(ManagementPublishController.java:257)
> at org.jboss.ide.eclipse.as.wtp.core.server.behavior.ControllableServerBehavior.publishModule(ControllableServerBehavior.java:143)
> at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:1091)
> at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:1183)
> at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:987)
> at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:774)
> at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:3182)
> at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:355)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> Caused by: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:281)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:62)
> at org.jboss.as.controller.client.impl.ConvertingDelegatingAsyncFuture.get(ConvertingDelegatingAsyncFuture.java:69)
> at org.jboss.as.controller.client.impl.ConvertingDelegatingAsyncFuture.get(ConvertingDelegatingAsyncFuture.java:41)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:94)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> at org.jboss.ide.eclipse.as.internal.management.wf11.DeploymentOperationResult.getStatus(DeploymentOperationResult.java:65)
> ... 15 more
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3236)
> at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)
> at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
> at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)
> at org.jboss.as.protocol.StreamUtils.copyStream(StreamUtils.java:52)
> at org.jboss.as.controller.client.impl.InputStreamEntry$InMemoryEntry.initialize(InputStreamEntry.java:76)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$ReadAttachmentInputStreamRequestHandler$1.execute(AbstractModelControllerClient.java:220)
> 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)
> {code}
> The server adapter showed [Republish]. So I tried to do a full publish, but that kind of failed. It first showed 19 %, now it's been at 29 % for 5 minutes and nothing seems to be happening. The server adapter says [Started, Publishing...] and the module says [Republish]. And I can't even stop the server, it's stuck.
> I restarted the IDE. Killed the EAP server on the remote host. Started the server again in the IDE. It showed my module is started. The index worked, the jar was not found. So now I did a full publish on the module. I could see that something was being sent over the network. Then the traffic was over and it was at 33 % for a while and finally it finished successfully this time. So at least that. Then I could add another jsp and it redeployed the module without having to send over the big file again. So at least that worked now.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2946) Errors publishing a large deployment to a remote server (EAP 7.1 management)
by Rob Stryker (JIRA)
Rob Stryker created WFCORE-2946:
-----------------------------------
Summary: Errors publishing a large deployment to a remote server (EAP 7.1 management)
Key: WFCORE-2946
URL: https://issues.jboss.org/browse/WFCORE-2946
Project: WildFly Core
Issue Type: Bug
Reporter: Rob Stryker
I tried to verify EAP 7.1 incremental deployment (JBIDE-23784).
So I first deployed a simple dynamic web project over management API to a remote EAP 7.1 (on a remote machine). Everything fine so far.
Then I just copied a big jar (devstudio installer) into the WebContent dir of the project. Then I did a Refresh of the project in Eclipse and I immediately got an error:
{code}
Could not publish to the server.
org.jboss.ide.eclipse.as.management.core.JBoss7ManangerException: java.util.concurrent.ExecutionException: Operation failed
at org.jboss.ide.eclipse.as.internal.management.wf11.DeploymentOperationResult.getStatus(DeploymentOperationResult.java:68)
at org.jboss.ide.eclipse.as.internal.management.wf11.WildFly11Manager.waitFor(WildFly11Manager.java:231)
at org.jboss.ide.eclipse.as.internal.management.wf11.WildFly11Manager.incrementalPublish(WildFly11Manager.java:601)
at org.jboss.ide.eclipse.as.internal.management.wf11.WildFly11ManagerService.incrementalPublish(WildFly11ManagerService.java:201)
at org.jboss.ide.eclipse.as.management.core.JBoss7ManagerServiceProxy.incrementalPublish(JBoss7ManagerServiceProxy.java:134)
at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController$IncrementalManagementPublishRunner.incrementalPublish(ManagementPublishController.java:530)
at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.incrementalPublish(ManagementPublishController.java:474)
at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.publishModule(ManagementPublishController.java:257)
at org.jboss.ide.eclipse.as.wtp.core.server.behavior.ControllableServerBehavior.publishModule(ControllableServerBehavior.java:143)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:1091)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:1183)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:987)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:774)
at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:3182)
at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:355)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
Caused by: java.util.concurrent.ExecutionException: Operation failed
at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:281)
at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:62)
at org.jboss.as.controller.client.impl.ConvertingDelegatingAsyncFuture.get(ConvertingDelegatingAsyncFuture.java:69)
at org.jboss.as.controller.client.impl.ConvertingDelegatingAsyncFuture.get(ConvertingDelegatingAsyncFuture.java:41)
at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:94)
at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
at org.jboss.ide.eclipse.as.internal.management.wf11.DeploymentOperationResult.getStatus(DeploymentOperationResult.java:65)
... 15 more
Caused by: java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3236)
at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)
at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)
at org.jboss.as.protocol.StreamUtils.copyStream(StreamUtils.java:52)
at org.jboss.as.controller.client.impl.InputStreamEntry$InMemoryEntry.initialize(InputStreamEntry.java:76)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient$ReadAttachmentInputStreamRequestHandler$1.execute(AbstractModelControllerClient.java:220)
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)
{code}
The server adapter showed [Republish]. So I tried to do a full publish, but that kind of failed. It first showed 19 %, now it's been at 29 % for 5 minutes and nothing seems to be happening. The server adapter says [Started, Publishing...] and the module says [Republish]. And I can't even stop the server, it's stuck.
I restarted the IDE. Killed the EAP server on the remote host. Started the server again in the IDE. It showed my module is started. The index worked, the jar was not found. So now I did a full publish on the module. I could see that something was being sent over the network. Then the traffic was over and it was at 33 % for a while and finally it finished successfully this time. So at least that. Then I could add another jsp and it redeployed the module without having to send over the big file again. So at least that worked now.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8925) Mark attribute 'outbound-socket-binding' in a reverse-proxy handler as 'required'
by Romain Pelisse (JIRA)
Romain Pelisse created WFLY-8925:
------------------------------------
Summary: Mark attribute 'outbound-socket-binding' in a reverse-proxy handler as 'required'
Key: WFLY-8925
URL: https://issues.jboss.org/browse/WFLY-8925
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 11.0.0.Alpha1
Reporter: Romain Pelisse
Assignee: Romain Pelisse
Priority: Minor
{{outbound-socket-binding}} attribute in {{/subsystem=undertow/configuration=handler/reverse-proxy=my-rev-proxy/host=some-host}} is not marked as '{{required}}'. Please mark it as required as if {{outbound-socket-binding}} is not specified during 'add' operation, it fails with:
{code}
/subsystem=undertow/configuration=handler/reverse-proxy=my-rev-proxy/host=some-host:add()
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.network.outbound-socket-binding.undefined"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.undertow.reverse-proxy.host.my-rev-proxy.some-host is missing [org.wildfly.network.outbound-socket-binding.undefined]"]
},
"rolled-back" => true
}
{code}
I suppose when this attribute is marked as required, more pleasant failure message is given.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8924) Cache configuration services should start on-demand
by Kabir Khan (JIRA)
Kabir Khan created WFLY-8924:
--------------------------------
Summary: Cache configuration services should start on-demand
Key: WFLY-8924
URL: https://issues.jboss.org/browse/WFLY-8924
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 11.0.0.Alpha1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Most infinispan services are configured to start passively, for a couple reasons:
1. Infinispan requires its cache container to start when the associated JGroups channel is started.
2. Cache configurations should be installed when the cache container starts, so that calls to EmbeddedCacheManager.getCache(...) use the correct configuration.
There's not much we can do about #1, except maybe to allow non-clustered cache containers (i.e. those without a transport) to start on-demand, instead of passively. This is a little tricky currently, since the transport is a separate resource from the cache container, and is typically installed afterwards.
#2 isn't needed anymore, since applications can depend on a specific cache configuration via jndi resource references.
Therefore, cache configuration services (and the individual configuration components services) should start as on-demand. Additionally, many of these services reference a full ConfigurationBuilder object, which is pretty hefty, for the entire lifetime of the service (regardless of state). These can be optimized to create the requisite builders only when the corresponding service is started. This should help reduce WF's startup memory footprint, as cache configurations do not need to be installed on startup.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months