[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ]
Jan Kalina commented on WFCORE-2691:
------------------------------------
ehm, true, as the *credential-store* can be any key-store based, creating WFCORE-2777 for it.
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: WFCORE-2691
> URL: https://issues.jboss.org/browse/WFCORE-2691
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta15
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2777) Elytron credential-store should offer operations instead of alias resource
by Jan Kalina (JIRA)
Jan Kalina created WFCORE-2777:
----------------------------------
Summary: Elytron credential-store should offer operations instead of alias resource
Key: WFCORE-2777
URL: https://issues.jboss.org/browse/WFCORE-2777
Project: WildFly Core
Issue Type: Bug
Components: Security
Affects Versions: 3.0.0.Beta18
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Blocker
Elytron credential-store resources should offer operations instead of alias resource, as for key-stores, as it can be based on any key-store too.
The reason is more described in WFCORE-2691 or related mailing thread on wildfly-dev.
Setting priority to blocker by WFCORE-2691 and WFCORE-2737.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JGRP-2168) JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2168?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2168 at 5/9/17 2:18 AM:
--------------------------------------------------------
System properties override *any value*, whether set as default value in the code, via XML or programmatically. If you want to overwrite a value programmatically, you have to do this after channel creation.
It would be quite an effort to change this, because we'd have to introduce an additional phase where the attributes are set from the config and system properties, then programmatic configuration happens and only _then_ the channel is created and init() is called in all protocols.
was (Author: belaban):
System properties override *any value*, whether set as default value in the code, via XML or programmatically. If you want to overwrite a value programmatically, you have to do this after channel creation. It would be quite an effort to change this...
> JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2168
> URL: https://issues.jboss.org/browse/JGRP-2168
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.13, 4.0.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> WildFly 11 recently started using the new JChannel(Protocol...) constructor for creating channels. This has resulted in the inability to configure certain protocol properties, most notably, initial_hosts for TCPPING.
> Because this constructor calls resolveAndAssignFields(...) with an empty map, if a property was explicitly set, and its associated system property does not exist, and that property uses a non-default converter, then it will have its value undefined (or, more specifically, set to whatever the converter does with a null value).
> Additionally, if the assocated system property did exist, it would take precedence over an explicitly set value. I don't think that's a good idea.
> Consider the following:
> {code:java}
> TCP transport = new TCP();
> transport.setBindAddress(InetAddress.getLocalHost());
> transport.setBindPort(9600);
> TCPPING ping = new TCPPING();
> ping.setInitialHosts(Collections.singletonList(new IpAddress(transport.getBindAddress(), transport.getBindPort())));
> JChannel channel = new JChannel(transport, ping);
> assert !ping.getInitialHosts().isEmpty() : "No initial hosts!";
> {code}
> Side note: new JChannel(Collection<Protocol>) should really be new JChannel(List<Protocol>), since the collection should be ordered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JGRP-2168) JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2168?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2168:
--------------------------------
System properties override *any value*, whether set as default value in the code, via XML or programmatically. If you want to overwrite a value programmatically, you have to do this after channel creation. It would be quite an effort to change this...
> JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2168
> URL: https://issues.jboss.org/browse/JGRP-2168
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.13, 4.0.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> WildFly 11 recently started using the new JChannel(Protocol...) constructor for creating channels. This has resulted in the inability to configure certain protocol properties, most notably, initial_hosts for TCPPING.
> Because this constructor calls resolveAndAssignFields(...) with an empty map, if a property was explicitly set, and its associated system property does not exist, and that property uses a non-default converter, then it will have its value undefined (or, more specifically, set to whatever the converter does with a null value).
> Additionally, if the assocated system property did exist, it would take precedence over an explicitly set value. I don't think that's a good idea.
> Consider the following:
> {code:java}
> TCP transport = new TCP();
> transport.setBindAddress(InetAddress.getLocalHost());
> transport.setBindPort(9600);
> TCPPING ping = new TCPPING();
> ping.setInitialHosts(Collections.singletonList(new IpAddress(transport.getBindAddress(), transport.getBindPort())));
> JChannel channel = new JChannel(transport, ping);
> assert !ping.getInitialHosts().isEmpty() : "No initial hosts!";
> {code}
> Side note: new JChannel(Collection<Protocol>) should really be new JChannel(List<Protocol>), since the collection should be ordered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1107) Wildfly Elytron Tool, Summary CLI command for adding new credential store contains duplicity for "create" and "location" attribute, "modification" attr is wrongly placed..
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1107?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek updated ELY-1107:
------------------------------
Summary: Wildfly Elytron Tool, Summary CLI command for adding new credential store contains duplicity for "create" and "location" attribute, "modification" attr is wrongly placed.. (was: Wildfly Elytron Tool, Summary CLI command for adding new credential store contain duplicity for "create" and "location" attribute, "modification" attr is wrongly placed..)
> Wildfly Elytron Tool, Summary CLI command for adding new credential store contains duplicity for "create" and "location" attribute, "modification" attr is wrongly placed..
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1107
> URL: https://issues.jboss.org/browse/ELY-1107
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Yeray Borges
>
> Summary CLI command for adding new credential store contains duplicity for "create" and "location" attribute, "modification" attr is wrongly placed..
> Create, location and modifiable attributes cannot be included in implementation-properties. "modifiable" attribute should be present in same way as "create" and "location" in its own attribute.
> *How to reproduce*
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --add secret_alias --password pass123 --create -x secret_password -l store.jceks --summary
> {code}
> {code}
> /subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="store.jceks",create=true,implementation-properties={"keyStoreType"=>"JCEKS","create"=>"true","location"=>"store.jceks","modifiable"=>"true"},credential-reference={clear-text="pass123"})
> {code}
> *It is expected some like this*
> {code}
> /subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="store.jceks",create=true, modifiable=true,implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="pass123"})
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1107) Wildfly Elytron Tool, Summary CLI command for adding new credential store contain duplicity for "create" and "location" attribute, "modification" attr is wrongly placed..
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1107?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek updated ELY-1107:
------------------------------
Description:
Summary CLI command for adding new credential store contains duplicity for "create" and "location" attribute, "modification" attr is wrongly placed..
Create, location and modifiable attributes cannot be included in implementation-properties. "modifiable" attribute should be present in same way as "create" and "location" in its own attribute.
*How to reproduce*
{code}
java -jar wildfly-elytron-tool.jar credential-store --add secret_alias --password pass123 --create -x secret_password -l store.jceks --summary
{code}
{code}
/subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="store.jceks",create=true,implementation-properties={"keyStoreType"=>"JCEKS","create"=>"true","location"=>"store.jceks","modifiable"=>"true"},credential-reference={clear-text="pass123"})
{code}
*It is expected some like this*
{code}
/subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="store.jceks",create=true, modifiable=true,implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="pass123"})
{code}
was:
Summary CLI command for adding new credential store contain duplicity for "create" and "location" attribute, "modification" attr is wrongly placed..
Create, location and modifiable attributes cannot be included in implementation-properties. "modifiable" attribute should be present in same way as "create" and "location" in its own attribute.
*How to reproduce*
{code}
java -jar wildfly-elytron-tool.jar credential-store --add secret_alias --password pass123 --create -x secret_password -l store.jceks --summary
{code}
{code}
/subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="store.jceks",create=true,implementation-properties={"keyStoreType"=>"JCEKS","create"=>"true","location"=>"store.jceks","modifiable"=>"true"},credential-reference={clear-text="pass123"})
{code}
*It is expected some like this*
{code}
/subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="store.jceks",create=true, modifiable=true,implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="pass123"})
{code}
> Wildfly Elytron Tool, Summary CLI command for adding new credential store contain duplicity for "create" and "location" attribute, "modification" attr is wrongly placed..
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1107
> URL: https://issues.jboss.org/browse/ELY-1107
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Yeray Borges
>
> Summary CLI command for adding new credential store contains duplicity for "create" and "location" attribute, "modification" attr is wrongly placed..
> Create, location and modifiable attributes cannot be included in implementation-properties. "modifiable" attribute should be present in same way as "create" and "location" in its own attribute.
> *How to reproduce*
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --add secret_alias --password pass123 --create -x secret_password -l store.jceks --summary
> {code}
> {code}
> /subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="store.jceks",create=true,implementation-properties={"keyStoreType"=>"JCEKS","create"=>"true","location"=>"store.jceks","modifiable"=>"true"},credential-reference={clear-text="pass123"})
> {code}
> *It is expected some like this*
> {code}
> /subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="store.jceks",create=true, modifiable=true,implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="pass123"})
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JGRP-2168) JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2168?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2168:
--------------------------------
First off: I cannot change the Collection to a List as this would be an API change. I did change the InitialHosts converter to return a null value, which won't overwrite the value set programmatically.
Which other converters do cause issues?
> JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2168
> URL: https://issues.jboss.org/browse/JGRP-2168
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.13, 4.0.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> WildFly 11 recently started using the new JChannel(Protocol...) constructor for creating channels. This has resulted in the inability to configure certain protocol properties, most notably, initial_hosts for TCPPING.
> Because this constructor calls resolveAndAssignFields(...) with an empty map, if a property was explicitly set, and its associated system property does not exist, and that property uses a non-default converter, then it will have its value undefined (or, more specifically, set to whatever the converter does with a null value).
> Additionally, if the assocated system property did exist, it would take precedence over an explicitly set value. I don't think that's a good idea.
> Consider the following:
> {code:java}
> TCP transport = new TCP();
> transport.setBindAddress(InetAddress.getLocalHost());
> transport.setBindPort(9600);
> TCPPING ping = new TCPPING();
> ping.setInitialHosts(Collections.singletonList(new IpAddress(transport.getBindAddress(), transport.getBindPort())));
> JChannel channel = new JChannel(transport, ping);
> assert !ping.getInitialHosts().isEmpty() : "No initial hosts!";
> {code}
> Side note: new JChannel(Collection<Protocol>) should really be new JChannel(List<Protocol>), since the collection should be ordered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JGRP-2168) JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2168?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2168:
--------------------------------
Unit test is TCPPING_Test
> JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2168
> URL: https://issues.jboss.org/browse/JGRP-2168
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.13, 4.0.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> WildFly 11 recently started using the new JChannel(Protocol...) constructor for creating channels. This has resulted in the inability to configure certain protocol properties, most notably, initial_hosts for TCPPING.
> Because this constructor calls resolveAndAssignFields(...) with an empty map, if a property was explicitly set, and its associated system property does not exist, and that property uses a non-default converter, then it will have its value undefined (or, more specifically, set to whatever the converter does with a null value).
> Additionally, if the assocated system property did exist, it would take precedence over an explicitly set value. I don't think that's a good idea.
> Consider the following:
> {code:java}
> TCP transport = new TCP();
> transport.setBindAddress(InetAddress.getLocalHost());
> transport.setBindPort(9600);
> TCPPING ping = new TCPPING();
> ping.setInitialHosts(Collections.singletonList(new IpAddress(transport.getBindAddress(), transport.getBindPort())));
> JChannel channel = new JChannel(transport, ping);
> assert !ping.getInitialHosts().isEmpty() : "No initial hosts!";
> {code}
> Side note: new JChannel(Collection<Protocol>) should really be new JChannel(List<Protocol>), since the collection should be ordered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JGRP-2169) PDC.java can NPE when calling deleteFile
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2169?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2169.
----------------------------
Resolution: Done
Fixed by removing the before trace statement
> PDC.java can NPE when calling deleteFile
> ----------------------------------------
>
> Key: JGRP-2169
> URL: https://issues.jboss.org/browse/JGRP-2169
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Elias Ross
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> As seen in my logs:
> {noformat}
> [thread=jgroups-4,pv36d01ls-geo02042101-26405] [level=ERROR] [logger=unknown.jul.logger] - JGRP000027: failed passing message up
> java.lang.NullPointerException: null
> at org.jgroups.protocols.PDC.deleteFile(PDC.java:271) ~[org.jgroups-jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.PDC.writeNodeToDisk(PDC.java:208) ~[org.jgroups-jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.PDC.down(PDC.java:89) ~[org.jgroups-jgroups-4.0.1.Final.jar:4.0.1.Final]
> {noformat}
> It seems that there are code paths where deleteFile can be called with a null parameter. For example:
> {code:java}
> protected File writeToTempFile(File dir, Address logical_addr, Address physical_addr, String logical_name) throws Exception {
> DataOutputStream out=null;
> File file=null;
> String filename=null;
> try {
> file=File.createTempFile("temp", null, dir);
> ^^ If this fails, then file is null and delete is called with null
> filename=file.getName();
> ...
> }
> catch(Exception e) {
> Util.close(out);
> log.error(Util.getMessage("FailedToWriteTemporaryFile") + filename, e);
> deleteFile(file);
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8731) Unable to inject EJBs into web resources
by Archimedes Trajano (JIRA)
Archimedes Trajano created WFLY-8731:
----------------------------------------
Summary: Unable to inject EJBs into web resources
Key: WFLY-8731
URL: https://issues.jboss.org/browse/WFLY-8731
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, EJB, Web (Undertow)
Affects Versions: 10.0.0.Final
Environment: WildFly 10.0 on Windows 10
Reporter: Archimedes Trajano
Assignee: Stuart Douglas
There's an old bug on https://issues.jboss.org/browse/JBAS-8818 that talks about this issue on JBoss, but it still applies on WildFly up until now.
Their comment was based on just WebListener, but I found it applied to the following as well
* WebServlet
* WebService (code first and contract first)
* JAX-RS paths.
One other thing to note, converting to @EJB from @Inject created another problem, but I'd rather get @Inject working first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month