[JBoss JIRA] (WFLY-8732) IIOPNamingTestCase fails with ClassNotFoundException when building with JDK9
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-8732?page=com.atlassian.jira.plugin.... ]
Amos Feng updated WFLY-8732:
----------------------------
Component/s: EJB
> IIOPNamingTestCase fails with ClassNotFoundException when building with JDK9
> ----------------------------------------------------------------------------
>
> Key: WFLY-8732
> URL: https://issues.jboss.org/browse/WFLY-8732
> Project: WildFly
> Issue Type: Bug
> Components: EJB, IIOP
> Reporter: Amos Feng
> Assignee: Tomasz Adamski
>
> {noformat}
> testIIOPNamingInvocation(org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase) Time elapsed: 0.004 sec <<< ERROR!
> javax.naming.NoInitialContextException: Cannot instantiate class: com.sun.jndi.cosnaming.CNCtxFactory [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory]
> at java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:719)
> at java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
> at java.naming/javax.naming.InitialContext.init(InitialContext.java:236)
> at java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208)
> at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:60)
> {noformat}
> I had tried to add "--add-modules=java.corba" in the testsuite/pom.xml. But it is still failed with NPE
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFLY-8732) IIOPNamingTestCase fails with ClassNotFoundException when building with JDK9
by Amos Feng (JIRA)
Amos Feng created WFLY-8732:
-------------------------------
Summary: IIOPNamingTestCase fails with ClassNotFoundException when building with JDK9
Key: WFLY-8732
URL: https://issues.jboss.org/browse/WFLY-8732
Project: WildFly
Issue Type: Bug
Components: IIOP
Reporter: Amos Feng
Assignee: Tomasz Adamski
{noformat}
testIIOPNamingInvocation(org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase) Time elapsed: 0.004 sec <<< ERROR!
javax.naming.NoInitialContextException: Cannot instantiate class: com.sun.jndi.cosnaming.CNCtxFactory [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory]
at java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:719)
at java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
at java.naming/javax.naming.InitialContext.init(InitialContext.java:236)
at java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208)
at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:60)
{noformat}
I had tried to add "--add-modules=java.corba" in the testsuite/pom.xml. But it is still failed with NPE
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[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)
7 years, 8 months
[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)
7 years, 8 months
[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)
7 years, 8 months
[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)
7 years, 8 months
[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)
7 years, 8 months
[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)
7 years, 8 months
[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)
7 years, 8 months
[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)
7 years, 8 months