[JBoss JIRA] (WFLY-7976) Logging the elytron version once is sufficient
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-7976:
--------------------------------------
Summary: Logging the elytron version once is sufficient
Key: WFLY-7976
URL: https://issues.jboss.org/browse/WFLY-7976
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Brian Stansberry
Assignee: Darran Lofthouse
Priority: Minor
Pick one or the other please:
{code}
19:05:58,886 INFO [org.wildfly.security] (ServerService Thread Pool -- 7) ELY00001: WildFly Elytron version 1.1.0.Beta21
19:05:58,890 INFO [org.wildfly.extension.elytron] (ServerService Thread Pool -- 7) WFLYELY00001: Activating Elytron Subsystem Elytron Version=1.1.0.Beta21, Subsystem Version=1.0.0.Beta2
{code}
I couldn't care less about the Subsystem Version. Besides the extension code MUST get integrated into WildFly (Core) proper.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7975) Print RESTEasy version during boot
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7975?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7975:
----------------------------------------
Ugh. I vote instead we remove all the other component version logging during boot. :)
Well, I don't think David Lloyd is going to remove his logging and he logs about 10 libs now, so I guess there's no good justification for not adding one more.
> Print RESTEasy version during boot
> ----------------------------------
>
> Key: WFLY-7975
> URL: https://issues.jboss.org/browse/WFLY-7975
> Project: WildFly
> Issue Type: Enhancement
> Components: REST
> Reporter: Alessio Soldano
> Assignee: Alessio Soldano
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> It would be good to have the current RESTEasy version printed out during boot.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7975) Print RESTEasy version during boot
by Alessio Soldano (JIRA)
Alessio Soldano created WFLY-7975:
-------------------------------------
Summary: Print RESTEasy version during boot
Key: WFLY-7975
URL: https://issues.jboss.org/browse/WFLY-7975
Project: WildFly
Issue Type: Enhancement
Components: REST
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Priority: Minor
Fix For: 11.0.0.Alpha1
It would be good to have the current RESTEasy version printed out during boot.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2234) Introduce srcdeps
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2234?page=com.atlassian.jira.plugi... ]
Peter Palaga commented on WFCORE-2234:
--------------------------------------
bq. This needs a discussion on wildfly-dev.
Initialized :)
> Introduce srcdeps
> -----------------
>
> Key: WFCORE-2234
> URL: https://issues.jboss.org/browse/WFCORE-2234
> Project: WildFly Core
> Issue Type: Task
> Reporter: Peter Palaga
> Assignee: Peter Palaga
>
> Srcdeps is a tool to build Maven dependencies from their sources. With srcdeps, wildfly-core can depend on a specific commit of, e.g., undertow:
> {code}
> <version.io.undertow>1.4.8.Final-SRC-revision-aabbccd</version.io.undertow>
> {code}
> where {{aabbccd}} is the git commit id to build when any undertow artifact is requested during the build of wildfly-core.
> The main advantage of srcdeps is that changes in components can be integrated and tested in wildfly-core immediately after they are committed to a public component branch. There is no need to wait for the component release.
> [1] https://github.com/srcdeps/srcdeps-maven#srcdeps-maven
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7483) Credential store has configuration in "uri" attribute.
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-7483?page=com.atlassian.jira.plugin.... ]
Brad Maxwell commented on WFLY-7483:
------------------------------------
It seems like if any or all of these configurations (cr-store-path, store.password,create.storage) are common and will be set for every credential store, then it would make more sense that they be separate parameters and then for any generic properties handled like a list of key value pairs. Similar to like datasource subsystem, this URI form reminds me of a datasource string with everything listed in it, where we split those up in the datasource subsystem instead of using 1 string
> Credential store has configuration in "uri" attribute.
> ------------------------------------------------------
>
> Key: WFLY-7483
> URL: https://issues.jboss.org/browse/WFLY-7483
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Critical
>
> Credential store has configuration in "uri" attribute. All parameters are in one string. It can be confusing and there is risk of typo (e.g. delimiter typo)
> In my opinion the main intention for it is to have general solution for custom implementation.
> *Current state*
> {code}
> /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/keystore.jceks?store.password=pass123;create.storage=true")
> {code}
> *Suggestion for improvement:*
> Better solution to achieve this could be use a map.
> e.g. some like that:
> {code}
> /subsystem=elytron/credential-store=credStore:add(cs-map={store.password=pass123, create.storage=true, store.file=path/to/cred/file})
> {code}
> Now credential store name is in URI too, it can be get from resource name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7974) Listener resource's redirect-socket does not validate or support tab completion
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7974?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved JBEAP-8515 to WFLY-7974:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7974 (was: JBEAP-8515)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
> Listener resource's redirect-socket does not validate or support tab completion
> -------------------------------------------------------------------------------
>
> Key: WFLY-7974
> URL: https://issues.jboss.org/browse/WFLY-7974
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The redirect-socket should be a capability reference to a socket-binding capability in order to benefit from model validation and tab completion.
> See WFLY-7957 for a case of a user misconfiguring this and not understanding why it doesn't work.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2235) Intermittent module loading failure in InterdependentDeploymentTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2235:
-------------------------------------
Attachment: WFCORE-2235svcdump.txt
> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
> Key: WFCORE-2235
> URL: https://issues.jboss.org/browse/WFCORE-2235
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 3.0.0.Alpha22
> Reporter: Brian Stansberry
> Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore...
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
> at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
> 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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
> at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
> at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
> at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
> ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2235) Intermittent module loading failure in InterdependentDeploymentTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2235:
------------------------------------------
Service details from the test failure that I mentioned in the description are attached.
> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
> Key: WFCORE-2235
> URL: https://issues.jboss.org/browse/WFCORE-2235
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 3.0.0.Alpha22
> Reporter: Brian Stansberry
> Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore...
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
> at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
> 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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
> at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
> at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
> at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
> ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2235) Intermittent module loading failure in InterdependentDeploymentTestCase
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2235:
----------------------------------------
Summary: Intermittent module loading failure in InterdependentDeploymentTestCase
Key: WFCORE-2235
URL: https://issues.jboss.org/browse/WFCORE-2235
Project: WildFly Core
Issue Type: Bug
Components: Modules, Server
Affects Versions: 3.0.0.Alpha22
Reporter: Brian Stansberry
InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore...
The most notable bit of info in the log is:
{code}
17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
... 6 more
{code}
The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months