[JBoss JIRA] (ELY-462) DirContext suppliing service to be used in LDAP realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-462?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-462:
---------------------------
Description:
UPDATE: There will be DirContext suppling service, which will be referenced by realm:
* output of service will be ExceptionSupplier<DirContext>, but the returning DirContext will be only delegator, which will call real DirContext and instead of close() it will do returnContext()
was:
-LDAP realm should use JNDI to obtain LdapContext (as JDBC realm use datasource) - configuration of connection should be outside of Elytron configuration.-
(requested by Darran on F2F)
UPDATE: There will be DirContext suppling service, which will be referenced by realm:
* return type ExceptionSupplier<DirContext>
> DirContext suppliing service to be used in LDAP realm
> -----------------------------------------------------
>
> Key: ELY-462
> URL: https://issues.jboss.org/browse/ELY-462
> Project: WildFly Elytron
> Issue Type: Task
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> UPDATE: There will be DirContext suppling service, which will be referenced by realm:
> * output of service will be ExceptionSupplier<DirContext>, but the returning DirContext will be only delegator, which will call real DirContext and instead of close() it will do returnContext()
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6905) Add log error message when Credential Store have set old vault JCEKS
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-6905?page=com.atlassian.jira.plugin.... ]
Hynek Švábek moved JBEAP-5497 to WFLY-6905:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6905 (was: JBEAP-5497)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Target Release: (was: 7.1.0.GA)
Affects Version/s: (was: 7.1.0.DR2)
> Add log error message when Credential Store have set old vault JCEKS
> --------------------------------------------------------------------
>
> Key: WFLY-6905
> URL: https://issues.jboss.org/browse/WFLY-6905
> Project: WildFly
> Issue Type: Enhancement
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> Log error message when user use new Credential Store and configure it to use existing Vault JCEKS.
> It can be nice give him some information about possibility to convert old Vault JCEKS to new Credential Store JCEKS.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1682:
----------------------------------------------
I would vote for reverting fix for WFCORE-1487 and try to find a way to help user dealing with this kind of argument (no completer and no name).
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Petr Kremensky commented on WFCORE-1682:
----------------------------------------
One more issue with completion I didn't notice before is that argument is suggested multiple times
{noformat}
[disconnected /] patch rollback --patch-id=my-custom-patch --p<TAB>
--patch-id --patch-stream= --preserve=
{noformat}
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFBUILD-14) Conflicting feature pack dependency versions should not be allowed
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-14?page=com.atlassian.jira.plugin... ]
Thomas Diesler edited comment on WFBUILD-14 at 8/2/16 7:04 AM:
---------------------------------------------------------------
This condition still seems to be silently ignored both by the feature-pack-build and the server-provisioning plugin.
On server start I see
{code}
12:43:56,173 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.10.Final "Kenny" starting
12:43:56,730 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
Message: Unexpected element '{urn:jboss:domain:4.2}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
... 3 more
12:43:56,734 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
What is supposed to happen here?
The server-provisioning plugin could enforce the exact same version of transitively reachable features packs or use semantic versioning to choose the latest compatible. The former approach would work every time. The latter would likely work in most cases while eliminating the need to rebuild dependent feature packs.
If you like, I could take a look at this.
was (Author: thomas.diesler):
This condition still seems to be silently ignored both by the feature-pack-build and the server-provisioning plugin.
On server start I see
{code}
12:43:56,173 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.10.Final "Kenny" starting
12:43:56,730 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
Message: Unexpected element '{urn:jboss:domain:4.2}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
... 3 more
12:43:56,734 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
> Conflicting feature pack dependency versions should not be allowed
> ------------------------------------------------------------------
>
> Key: WFBUILD-14
> URL: https://issues.jboss.org/browse/WFBUILD-14
> Project: WildFly Build Tools
> Issue Type: Bug
> Reporter: James Netherton
> Assignee: Stuart Douglas
> Fix For: 1.1.7.Final
>
>
> There was a brief discussion about this on the WildFly dev mailing list so I'm capturing the problem here as well.
> Consider the following.
> Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
> </dependencies>
> {code}
> Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
> <artifact name="org.foo:feature-pack-A" />
> </dependencies>
> {code}
> The result is that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions
> At the moment the plugins allow this scenario, which can lead to all sorts of horrors when using the server-provisioning plugin to provision an app server.
> CrossRef: https://github.com/wildfly-extras/fuse-patch/issues/101
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFBUILD-14) Conflicting feature pack dependency versions should not be allowed
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-14?page=com.atlassian.jira.plugin... ]
Thomas Diesler reopened WFBUILD-14:
-----------------------------------
This condition still seems to be silently ignored both by the feature-pack-build and the server-provisioning plugin.
On server start I see
{code}
12:43:56,173 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.10.Final "Kenny" starting
12:43:56,730 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
Message: Unexpected element '{urn:jboss:domain:4.2}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
... 3 more
12:43:56,734 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
> Conflicting feature pack dependency versions should not be allowed
> ------------------------------------------------------------------
>
> Key: WFBUILD-14
> URL: https://issues.jboss.org/browse/WFBUILD-14
> Project: WildFly Build Tools
> Issue Type: Bug
> Reporter: James Netherton
> Assignee: Stuart Douglas
> Fix For: 1.1.7.Final
>
>
> There was a brief discussion about this on the WildFly dev mailing list so I'm capturing the problem here as well.
> Consider the following.
> Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
> </dependencies>
> {code}
> Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
> <artifact name="org.foo:feature-pack-A" />
> </dependencies>
> {code}
> The result is that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions
> At the moment the plugins allow this scenario, which can lead to all sorts of horrors when using the server-provisioning plugin to provision an app server.
> CrossRef: https://github.com/wildfly-extras/fuse-patch/issues/101
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1682:
----------------------------------------------
The side effects of WFCORE-1487 are actually in completion too. There is now a mismatch in the completion logic between indexed and named arguments.
For example: edit-batch-line --line-number=1 :<TAB>
the completer for the line-number (null) is returned instead of the completer for the line.
- The documentation of the commands have not been updated to reflect that the arguments names can be used (look at connect help for example).
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months