[JBoss JIRA] (DROOLS-1627) Test DynamicRuleLoadTest.testKJarUpgradeWithJavaClass fails on Mac
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1627:
--------------------------------------
Summary: Test DynamicRuleLoadTest.testKJarUpgradeWithJavaClass fails on Mac
Key: DROOLS-1627
URL: https://issues.jboss.org/browse/DROOLS-1627
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Priority: Minor
Attachments: Screen Shot 2017-06-21 at 22.12.12.png
Reportedly, the test DynamicRuleLoadTest.testKJarUpgradeWithJavaClass fails on Mac OSX with HFS+ filesystem with the default of case INsensitive.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2994) Using git for managing configuration history
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2994?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2994:
-------------------------------------
Description:
Currently the configuration is persisted as an XML file and its history is locally stored in a folder. The present feature request is to support using git to manage the persistence of the configuration and its history.
Example use cases this would make possible:
* We could enhance a lot our operations like snapshot which saves a snapshot of the configuration with the user asking for the snapshot and adding a commit as a git message. Even if this is not as precise as the audit log it makes managing the configuration much easier.
* It is a common best practice for administrator to save scripts / configuration in a version control system, with this we give access to all the facilities to the server administrator, making it easy to go back to a previous version (even more since we have the metadata to help). The configuration could be pushed/saved to a remote repository thus making configuration sharing a no pain feature.
* git would allow us to use a central repository for the configuration and we could even directly start from a git repository URL, that way no more copying files between instance. This could help a lot in cloud deployments. We could use a single docker image and pass the git repository URL as a parameter to it so that you would have different server configuration from the same image (as opposed to having to build one image per configuration). You could even imagine a rolling update by just restarting the containers as they would then pick up the latest changes in configuration. _(Note that using this feature in any of these ways in the WildFly/EAP cloud images is not part of this RFE. The intent here is just to illustrate possibilities. There are many other factors that go into deciding how WildFly/EAP should work on the cloud.)_
* We could support branches and use those for domain mode with one branch per host thus you would have your whole domain configuration in a single repository and could manage each host independently.
* With branches administrators could also experiment on a branch and when it is stable use it. And with git history you have all the steps you took to create your configuration.
was:
Currently the configuration is persisted as an XML file and its history is locally stored in a folder. The present feature request is to use git to manage the persistence of the configuration and its history.
* We could enhance a lot our operations like snapshot which saves a snapshot of the configuration with the user asking for the snapshot and adding a commit as a git message. Even if this is not as precise as the audit log it makes managing the configuration much easier.
* it is a common best practice for administrator to save scripts / configuration in a version control system, with this we give access to all the facilities to the server administrator, making it easy to go back to a previous version (even more since we have the metadata to help). The configuration could be pushed/saved to a remote repository thus making configuration sharing a no pain feature.
* git would allow us to use a central repository for the configuration and we could even directly start from a git repository URL, that way no more copying files between instance. This could help a lot in cloud deployments. We could use a single docker image and pass the git repository URL as a parameter to it so that you would have different server configuration from the same image (as opposed to having to build one image per configuration). You could even imagine a rolling update by just restarting the containers as they would then pick up the latest changes in configuration
* We could support branches and use those for domain mode with one branch per host thus you would have your whole domain configuration in a single repository and could manage each host independently.
* With branches we could also experiment on a branch and when it is stable use it. And with git history you have all the steps you took to create your configuration.
> Using git for managing configuration history
> --------------------------------------------
>
> Key: WFCORE-2994
> URL: https://issues.jboss.org/browse/WFCORE-2994
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 3.0.0.Beta26
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> Currently the configuration is persisted as an XML file and its history is locally stored in a folder. The present feature request is to support using git to manage the persistence of the configuration and its history.
> Example use cases this would make possible:
> * We could enhance a lot our operations like snapshot which saves a snapshot of the configuration with the user asking for the snapshot and adding a commit as a git message. Even if this is not as precise as the audit log it makes managing the configuration much easier.
> * It is a common best practice for administrator to save scripts / configuration in a version control system, with this we give access to all the facilities to the server administrator, making it easy to go back to a previous version (even more since we have the metadata to help). The configuration could be pushed/saved to a remote repository thus making configuration sharing a no pain feature.
> * git would allow us to use a central repository for the configuration and we could even directly start from a git repository URL, that way no more copying files between instance. This could help a lot in cloud deployments. We could use a single docker image and pass the git repository URL as a parameter to it so that you would have different server configuration from the same image (as opposed to having to build one image per configuration). You could even imagine a rolling update by just restarting the containers as they would then pick up the latest changes in configuration. _(Note that using this feature in any of these ways in the WildFly/EAP cloud images is not part of this RFE. The intent here is just to illustrate possibilities. There are many other factors that go into deciding how WildFly/EAP should work on the cloud.)_
> * We could support branches and use those for domain mode with one branch per host thus you would have your whole domain configuration in a single repository and could manage each host independently.
> * With branches administrators could also experiment on a branch and when it is stable use it. And with git history you have all the steps you took to create your configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late
by John Ament (JIRA)
[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ]
John Ament commented on WFLY-8488:
----------------------------------
Ok, sorry for the delay missed the response. I can still replicate the issue with ExampleDS on WF 11
{code}
14:12:49,926 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-6) WFLYJCA0019: Stopped Driver service with driver-name = h2
14:12:49,926 WARN [org.jboss.modcluster] (ServerService Thread Pool -- 3) MODCLUSTER000033: Failed to interrupt socket reception.: java.io.IOException: Can't assign requested address
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:693)
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.interruptDatagramReader(AdvertiseListenerImpl.java:209)
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.stop(AdvertiseListenerImpl.java:228)
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.destroy(AdvertiseListenerImpl.java:244)
at org.jboss.modcluster.ModClusterService.shutdown(ModClusterService.java:216)
at org.wildfly.extension.mod_cluster.ContainerEventHandlerService.stop(ContainerEventHandlerService.java:69)
at org.wildfly.clustering.service.AsynchronousServiceBuilder.lambda$stop$7(AsynchronousServiceBuilder.java:124)
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}
> Usage of JGroups JDBC_PING attempts to delete row too late
> ----------------------------------------------------------
>
> Key: WFLY-8488
> URL: https://issues.jboss.org/browse/WFLY-8488
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: John Ament
> Assignee: Paul Ferraro
>
> I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down.
> In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2994) Using git for managing configuration history
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2994?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet commented on WFCORE-2994:
-------------------------------------------
While WFCORE-433 looks the same originally it diverged a lot from the original point.
> Using git for managing configuration history
> --------------------------------------------
>
> Key: WFCORE-2994
> URL: https://issues.jboss.org/browse/WFCORE-2994
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 3.0.0.Beta26
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> Currently the configuration is persisted as an XML file and its history is locally stored in a folder. The present feature request is to use git to manage the persistence of the configuration and its history.
> * We could enhance a lot our operations like snapshot which saves a snapshot of the configuration with the user asking for the snapshot and adding a commit as a git message. Even if this is not as precise as the audit log it makes managing the configuration much easier.
> * it is a common best practice for administrator to save scripts / configuration in a version control system, with this we give access to all the facilities to the server administrator, making it easy to go back to a previous version (even more since we have the metadata to help). The configuration could be pushed/saved to a remote repository thus making configuration sharing a no pain feature.
> * git would allow us to use a central repository for the configuration and we could even directly start from a git repository URL, that way no more copying files between instance. This could help a lot in cloud deployments. We could use a single docker image and pass the git repository URL as a parameter to it so that you would have different server configuration from the same image (as opposed to having to build one image per configuration). You could even imagine a rolling update by just restarting the containers as they would then pick up the latest changes in configuration
> * We could support branches and use those for domain mode with one branch per host thus you would have your whole domain configuration in a single repository and could manage each host independently.
> * With branches we could also experiment on a branch and when it is stable use it. And with git history you have all the steps you took to create your configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2994) Using git for managing configuration history
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-2994:
-----------------------------------------
Summary: Using git for managing configuration history
Key: WFCORE-2994
URL: https://issues.jboss.org/browse/WFCORE-2994
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Affects Versions: 3.0.0.Beta26
Reporter: ehsavoie Hugonnet
Assignee: ehsavoie Hugonnet
Currently the configuration is persisted as an XML file and its history is locally stored in a folder. The present feature request is to use git to manage the persistence of the configuration and its history.
* We could enhance a lot our operations like snapshot which saves a snapshot of the configuration with the user asking for the snapshot and adding a commit as a git message. Even if this is not as precise as the audit log it makes managing the configuration much easier.
* it is a common best practice for administrator to save scripts / configuration in a version control system, with this we give access to all the facilities to the server administrator, making it easy to go back to a previous version (even more since we have the metadata to help). The configuration could be pushed/saved to a remote repository thus making configuration sharing a no pain feature.
* git would allow us to use a central repository for the configuration and we could even directly start from a git repository URL, that way no more copying files between instance. This could help a lot in cloud deployments. We could use a single docker image and pass the git repository URL as a parameter to it so that you would have different server configuration from the same image (as opposed to having to build one image per configuration). You could even imagine a rolling update by just restarting the containers as they would then pick up the latest changes in configuration
* We could support branches and use those for domain mode with one branch per host thus you would have your whole domain configuration in a single repository and could manage each host independently.
* With branches we could also experiment on a branch and when it is stable use it. And with git history you have all the steps you took to create your configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2359) Failure message when an op requires a non-existent capability doesn't list registration points for dynamic caps
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2359?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-2359:
-----------------------------------------
Assignee: ehsavoie Hugonnet
> Failure message when an op requires a non-existent capability doesn't list registration points for dynamic caps
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2359
> URL: https://issues.jboss.org/browse/WFCORE-2359
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
>
> {code}
> [standalone@embedded /] /socket-binding-group=standard-sockets/socket-binding=test:add(interface=bogus,port=12345)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0369: Required capabilities are not available:
> org.wildfly.network.interface.bogus; There are no known registration points which can provide this capability.",
> "rolled-back" => true
> }
> {code}
> The failure message is not fully helpful, since while there are no reg points for org.wildfly.network.interface.bogus there are points for caps whose dynamic part is org.wildfly.network.interface.
> The message is created using the results of CapabilityRegistry.getPossibleProviderPoints(), which just does a map lookup of the passed in capability name.
> Any fix that changes getPossibleProviderPoints() will need to be careful not to break other uses of that method.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years