[JBoss JIRA] (WFCORE-919) Allow read-only data/content storage
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-919?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-919:
-----------------------------------------
The content repository is an internal detail, not an end user API. So this is a proposal to change that. Particularly the "deployments are managed via another system (docker, puppet etc)" bit, would be such a big change as to really require a separate issue altogether
Without going to that point, but just sharing the repo, some kind of config setting that lets the user independently specify the location of the content repo would be needed. That itself somewhat exposes the internal detail (i.e. that the content repo is implemented via a FS location.) Any config for this would need to be done in such a way that it can become an alternative to some other approach (e.g. someday we pull content via the internet from Mars.)
If the step of making the repo sharable is worked out, then the "read-only" flag for a given host becomes a small thing.
I don't see a *direct* relationship to WFCORE-310, although it does touch on the same general use cases. The tangential relationship is a host that can is master cannot be configured with a r-o repo, as the master is the one who writes. Being configured with a r-o repo would be an issue with promoting a slave to master (as the config would have to be corrected) but the mechanics of promoting a slave are not the direct concern of 310. 310 deals with the fact that a slave that is ignoring parts of the domain-wide config/content is ineligible for promotion.
> Allow read-only data/content storage
> ------------------------------------
>
> Key: WFCORE-919
> URL: https://issues.jboss.org/browse/WFCORE-919
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: James Livingston
> Assignee: Brian Stansberry
>
> It would be nice to allow the content repository to be read-only, if there was an external guarantee that all content should be there. This would be useful in situations where all HCs (including the DC) share that over NFS, or deployments are managed via another system (docker, puppet etc).
> It could be a ContentRepository implementation which does not make chances, and fails if attempted or content is missing. On read-only HCs the current writeability check would need to be disabled, along with the cleaner task, and the DC (if it could write) would need to ensure content was not removed prior to HCs performing undeployment.
> This would presumably have some interaction with WFCORE-310.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-4255) Allow Arquillian to specify a timeout value for the WildFly clean shutdown mechanism when shutting down a server
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-4255?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-4255:
-------------------------------------------
Rado, any idea what is holding this up?
> Allow Arquillian to specify a timeout value for the WildFly clean shutdown mechanism when shutting down a server
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4255
> URL: https://issues.jboss.org/browse/WFLY-4255
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 9.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Radoslav Husar
>
> WildFly has a clean shutdown mechanism which can be used to shutdown a server from the command line so that requests active at the time of shutdown get a chance to complete:
> {code}
> [standalone@localhost:9990 /] :shutdown(timeout=5)
> {"outcome" => "success"}
> {code}
> Provide access to this feature from an Arquillian test case so that test cases may test with or without clean shutdown enabled.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-846) Some tests throws "Permission check failed" while run with security manager
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-846?page=com.atlassian.jira.plugin... ]
Josef Cacek reassigned WFCORE-846:
----------------------------------
Assignee: Josef Cacek (was: Jan Tymel)
> Some tests throws "Permission check failed" while run with security manager
> ---------------------------------------------------------------------------
>
> Key: WFCORE-846
> URL: https://issues.jboss.org/browse/WFCORE-846
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.0.Alpha11
> Reporter: Petr Kremensky
> Assignee: Josef Cacek
>
> Some tests are failing to deploy an archive when testsuite run with security manager enabled.
> {noformat}
> 08:03:07,171 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service test.deployment.trivial: org.jboss.msc.service.StartException in service test.deployment.trivial: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.trivial.prop" "write")" in code source "(vfs:/content/test-http-deployment.sar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:274)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:176)
> at java.lang.System.setProperty(System.java:792)
> at org.jboss.as.test.deployment.trivial.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:80)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 08:03:07,173 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-5) WFLYCTL0013: Operation ("add") failed - address: ([{"deployment" => "test-http-deployment.sar"}]) - failure description: {"WFLYCTL0080: Failed services" => {"test.deployment.trivial" => "org.jboss.msc.service.StartException in service test.deployment.trivial: Failed to start service
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"test.deployment.trivial.prop\" \"write\")\" in code source \"(vfs:/content/test-http-deployment.sar <no signer certificates>)\" of \"null\")"}}
> 08:03:07,174 ERROR [org.jboss.as.server] (XNIO-1 task-5) WFLYSRV0021: Deploy of deployment "test-http-deployment.sar" was rolled back with the following failure message:
> {"WFLYCTL0080: Failed services" => {"test.deployment.trivial" => "org.jboss.msc.service.StartException in service test.deployment.trivial: Failed to start service
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"test.deployment.trivial.prop\" \"write\")\" in code source \"(vfs:/content/test-http-deployment.sar <no signer certificates>)\" of \"null\")"}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol fatal error on OpenStack Kilo
by Nick Sawadsky (JIRA)
[ https://issues.jboss.org/browse/JGRP-1954?page=com.atlassian.jira.plugin.... ]
Nick Sawadsky commented on JGRP-1954:
-------------------------------------
Great, thanks Bela. One question -- to parse the JSON response, some kind of JSON parser is needed. Would it be alright to introduce a dependency on JSON.simple? Not sure of the best approach here.
> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
> Key: JGRP-1954
> URL: https://issues.jboss.org/browse/JGRP-1954
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123 FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5215) [Migration operation] [Web to Undertow] Scheme attribute of ajp connector is not migrated
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created WFLY-5215:
--------------------------------------
Summary: [Migration operation] [Web to Undertow] Scheme attribute of ajp connector is not migrated
Key: WFLY-5215
URL: https://issues.jboss.org/browse/WFLY-5215
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Radim Hatlapatka
Assignee: Stuart Douglas
Scheme attribute of AJP connector is not migrated.
Web AJP configuration
{noformat}
<connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
{noformat}
should be migrated to
{noformat}
<ajp-listener name="ajp" socket-binding="ajp" scheme="http"/>
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5214) Cannot set initial-pool-size attribute of datasource from web console
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5214?page=com.atlassian.jira.plugin.... ]
Jan Kašík updated WFLY-5214:
----------------------------
Steps to Reproduce:
# Run Wildfly in domain mode
# Navigate to existing datasource, e.g.: Configuration -> Profiles -> full-ha -> Non-XA -> ExampleDS and click on {{View}}
# Switch to {{Pool}} tab
# Click on {{Edit}}
# Set value of {{Initial Pool Size}} labeled field to valid value (e.g. 5)
# Click on {{Save}} button
# Success message appears and everything looks OK, but when I try to read value by CLI command only response which I get is:
{code}
[domain@localhost:9990 /] /profile=full-ha/subsystem=datasources/data-source=ExampleDS:read-attribute(name=initial-pool-size)
{
"outcome" => "success",
"result" => undefined
}
{code}
and it should be:
{code}
{
"outcome" => "success",
"result" => 5
}
{code}
was:
# Run EAP 7 in domain mode
# Navigate to existing datasource, e.g.: Configuration -> Profiles -> full-ha -> Non-XA -> ExampleDS and click on {{View}}
# Switch to {{Pool}} tab
# Click on {{Edit}}
# Set value of {{Initial Pool Size}} labeled field to valid value (e.g. 5)
# Click on {{Save}} button
# Success message appears and everything looks OK, but when I try to read value by CLI command only response which I get is:
{code}
[domain@localhost:9990 /] /profile=full-ha/subsystem=datasources/data-source=ExampleDS:read-attribute(name=initial-pool-size)
{
"outcome" => "success",
"result" => undefined
}
{code}
and it should be:
{code}
{
"outcome" => "success",
"result" => 5
}
{code}
> Cannot set initial-pool-size attribute of datasource from web console
> ---------------------------------------------------------------------
>
> Key: WFLY-5214
> URL: https://issues.jboss.org/browse/WFLY-5214
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 10.0.0.Beta2
> Reporter: Jan Kašík
> Assignee: Heiko Braun
>
> Setting of Initial Pool Size field in datasource pool configuration is not propagated to the server.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5214) Cannot set initial-pool-size attribute of datasource from web console
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5214?page=com.atlassian.jira.plugin.... ]
Jan Kašík moved JBEAP-881 to WFLY-5214:
---------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5214 (was: JBEAP-881)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 10.0.0.Beta2
(was: 7.0.0.DR9)
Component/s: Web Console
(was: Web Console)
Target Release: (was: 7.0.0.GA)
> Cannot set initial-pool-size attribute of datasource from web console
> ---------------------------------------------------------------------
>
> Key: WFLY-5214
> URL: https://issues.jboss.org/browse/WFLY-5214
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 10.0.0.Beta2
> Reporter: Jan Kašík
> Assignee: Heiko Braun
>
> Setting of Initial Pool Size field in datasource pool configuration is not propagated to the server.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-310) Don't copy the contents to all hosts when assigning a deployment to a server-group
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-310?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFCORE-310:
----------------------------------
I think this comes down to changing the default behavior of ignore-unused-configuration to true from false, with the following modifications:
- --backup : rename this to --backup-dc (keep --backup around and warn)?
- --cached-dc : an attempt should be made to contact the DC. If this attempt fails the server should still start and log a warning. Possible issues with long timeouts delaying startup, could mitigate with a timeout (still thinking about this one). This behavior is different from current where the initial connection attempt is not made.
- --backup-dc: ignore-unused-configuration is ignored and all content is copied regardless, as this content will potentially be needed should this instance become DC. Using backup should also attempt to contact the DC and ensure everything is pulled & up to date, if this fails it should log & warn (along with last time DC was actually contacted?) but still start.
-- ignore-unused: add this as a command line option, should override value set in host.xml
Only one of --cached-dc or --backup-dc should be set to true, using both should result in an error.
in host.xml:
<remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="true">
This should allow all of the command line options to be specified:
<remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="false" backup-dc="true" cached-dc="false" >
Do we have use cases for --backup currently where it would be used for anything other than becoming DC? Adding the relevant server groups / using ignore-unused-configuration = false would seem to cover this already.
Also verify a couple of things:
- if a slave is running with --backup, then it is probably only eligible to become master if it is the same (or >=) version as master(?) We should at least warn in the case this is not true.
- more?
> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-310
> URL: https://issues.jboss.org/browse/WFCORE-310
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Assignee: Ken Wills
> Fix For: 2.0.0.CR1
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5213) Injecting external context or its destinations in MDB fails
by Ondřej Kalman (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Ondřej Kalman updated WFLY-5213:
--------------------------------
Summary: Injecting external context or its destinations in MDB fails (was: Injecting external context or it's destinations in MDB fails)
> Injecting external context or its destinations in MDB fails
> -----------------------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months