[JBoss JIRA] (WFLY-13476) MP FT QS: Missing supported shared-docs sections
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13476?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFLY-13476:
---------------------------------------
While at it, I have found a couple of English language issues, opened WFLY-13479 to fix along with this.
> MP FT QS: Missing supported shared-docs sections
> ------------------------------------------------
>
> Key: WFLY-13476
> URL: https://issues.redhat.com/browse/WFLY-13476
> Project: WildFly
> Issue Type: Bug
> Components: MP Fault Tolerance, Quickstarts
> Affects Versions: 19.1.0.Final
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 20.0.0.Beta1
>
>
> Consider adding standard sections - see other QS
> * Use of the EAP_HOME and QUICKSTART_HOME Variables
> * Start the JBoss EAP XP Standalone Server
> * Build and Deploy the Quickstart
> * Access the Application
> * Undeploy the Quickstart
> * Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13459) Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/WFLY-13459?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated WFLY-13459:
--------------------------------
Attachment: client.sh
> Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13459
> URL: https://issues.redhat.com/browse/WFLY-13459
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 19.1.0.Final
> Reporter: Brad Maxwell
> Assignee: Sudeshna Sur
> Priority: Minor
> Attachments: Client.java, client.sh, server.log.gz
>
>
> The Remote Naming (JNDI) is Read-Only, remote clients cannot bind or rebind objects into it. Only applications running in the same JVM can bind values into JNDI.
> It looks like the server side logs the warning, but the client does not get an exception thrown back, bind and rebind should throw some javax.naming.NamingException since the bind/rebind operations are failing.
> {code}
> public static void main(String[] args) throws Exception {
> Context ctx = getInitialContext("localhost", 8080, "admin", "redhat1!");
> ctx.bind("java:/reproducer", "reproducer");
> ctx.rebind("java:/reproducer", "reproducer");
> }
> public static Context getInitialContext(String host, Integer port, String username, String password) throws NamingException {
> Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> props.put(Context.PROVIDER_URL, String.format("%s://%s:%d", "remote+http", host, port));
> if(username != null && password != null) {
> props.put(Context.SECURITY_PRINCIPAL, username);
> props.put(Context.SECURITY_CREDENTIALS, password);
> }
> return new InitialContext(props);
> }
> {code}
> {code}
> 13:20:22,804 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:66)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:262)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:289)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:238)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:126)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> 13:20:22,813 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:108)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:301)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:309)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:236)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:129)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13459) Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/WFLY-13459?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated WFLY-13459:
--------------------------------
Steps to Reproduce:
Add a user: ./bin/add-user.sh -a -u admin -p redhat1!
Start JBoss ./bin/standalone.sh
javac Client.java
java -cp $JBOSS_HOME/bin/client/jboss-cli-client.jar:$JBOSS_HOME/bin/client/jboss-client.jar:. Client
It will test remoting and http. -Dtest=http or -Dtest=remoting to just run a single test
java -cp $JBOSS_HOME/bin/client/jboss-cli-client.jar:$JBOSS_HOME/bin/client/jboss-client.jar:. -Dtest=http Client
-Dpass=null will set the user/pass to null so that it will not be set inside of the InitialContext.
-Dhost= , -Dport , -Duser, -Dpass can all be passed to use a different value from the default localhost , 8080, admin , redhat1!
Will log:
{code}
Starting test: Remote Naming / Remoting
==================
Failed to catch exception for method bind
Failed to catch exception for method rebind
Failed to catch exception for method unbind
Failed to catch exception for method rename
Failed to catch exception for method createSubcontext
Failed to catch exception for method destroySubcontext
Failed to catch exception for method destroySubcontext
Finished test: Remote Naming / Remoting
==================
Starting test: Remote Http Naming
==================
Success catch exception javax.naming.NamingException for method bind
Success catch exception javax.naming.NamingException for method rebind
Success catch exception javax.naming.CommunicationException for method unbind
Success catch exception javax.naming.CommunicationException for method rename
Success catch exception javax.naming.CommunicationException for method createSubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Finished test: Remote Http Naming
==================
{code}
Expected result is success where the client is catching a NamingException (which ever is most specific to the method).
The implementation down in the org.wildfly.naming.client.WildFlyInitialContextFactory for these methods must just not be throwing the exception back, since the server side is logging a warning
was:
Add a user: ./bin/add-user.sh -a -u admin -p redhat1!
Start JBoss ./bin/standalone.sh
javac Client.java
java -cp $JBOSS_HOME/bin/client/jboss-cli-client.jar:$JBOSS_HOME/bin/client/jboss-client.jar:. Client
It will test remoting and http. -Dtest=http or -Dtest=remoting to just run a single test
java -cp /tmp/jboss-eap-7.3/bin/client/jboss-cli-client.jar:/tmp/jboss-eap-7.3/bin/client/jboss-client.jar:. -Dtest=http Client
-Dpass=null will set the user/pass to null so that it will not be set inside of the InitialContext.
-Dhost= , -Dport , -Duser, -Dpass can all be passed to use a different value from the default localhost , 8080, admin , redhat1!
Will log:
{code}
Starting test: Remote Naming / Remoting
==================
Failed to catch exception for method bind
Failed to catch exception for method rebind
Failed to catch exception for method unbind
Failed to catch exception for method rename
Failed to catch exception for method createSubcontext
Failed to catch exception for method destroySubcontext
Failed to catch exception for method destroySubcontext
Finished test: Remote Naming / Remoting
==================
Starting test: Remote Http Naming
==================
Success catch exception javax.naming.NamingException for method bind
Success catch exception javax.naming.NamingException for method rebind
Success catch exception javax.naming.CommunicationException for method unbind
Success catch exception javax.naming.CommunicationException for method rename
Success catch exception javax.naming.CommunicationException for method createSubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Finished test: Remote Http Naming
==================
{code}
Expected result is success where the client is catching a NamingException (which ever is most specific to the method).
The implementation down in the org.wildfly.naming.client.WildFlyInitialContextFactory for these methods must just not be throwing the exception back, since the server side is logging a warning
> Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13459
> URL: https://issues.redhat.com/browse/WFLY-13459
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 19.1.0.Final
> Reporter: Brad Maxwell
> Assignee: Sudeshna Sur
> Priority: Minor
> Attachments: Client.java, server.log.gz
>
>
> The Remote Naming (JNDI) is Read-Only, remote clients cannot bind or rebind objects into it. Only applications running in the same JVM can bind values into JNDI.
> It looks like the server side logs the warning, but the client does not get an exception thrown back, bind and rebind should throw some javax.naming.NamingException since the bind/rebind operations are failing.
> {code}
> public static void main(String[] args) throws Exception {
> Context ctx = getInitialContext("localhost", 8080, "admin", "redhat1!");
> ctx.bind("java:/reproducer", "reproducer");
> ctx.rebind("java:/reproducer", "reproducer");
> }
> public static Context getInitialContext(String host, Integer port, String username, String password) throws NamingException {
> Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> props.put(Context.PROVIDER_URL, String.format("%s://%s:%d", "remote+http", host, port));
> if(username != null && password != null) {
> props.put(Context.SECURITY_PRINCIPAL, username);
> props.put(Context.SECURITY_CREDENTIALS, password);
> }
> return new InitialContext(props);
> }
> {code}
> {code}
> 13:20:22,804 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:66)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:262)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:289)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:238)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:126)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> 13:20:22,813 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:108)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:301)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:309)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:236)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:129)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13476) MP FT QS: Missing supported shared-docs sections
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13476?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13476:
----------------------------------
Summary: MP FT QS: Missing supported shared-docs sections (was: MP FT Quickstart: Missing supported shared-docs sections)
> MP FT QS: Missing supported shared-docs sections
> ------------------------------------------------
>
> Key: WFLY-13476
> URL: https://issues.redhat.com/browse/WFLY-13476
> Project: WildFly
> Issue Type: Bug
> Components: MP Fault Tolerance, Quickstarts
> Affects Versions: 19.1.0.Final
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
>
> Consider adding standard sections - see other QS
> * Use of the EAP_HOME and QUICKSTART_HOME Variables
> * Start the JBoss EAP XP Standalone Server
> * Build and Deploy the Quickstart
> * Access the Application
> * Undeploy the Quickstart
> * Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13459) Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/WFLY-13459?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated WFLY-13459:
--------------------------------
Steps to Reproduce:
Add a user: ./bin/add-user.sh -a -u admin -p redhat1!
Start JBoss ./bin/standalone.sh
javac Client.java
java -cp $JBOSS_HOME/bin/client/jboss-cli-client.jar:$JBOSS_HOME/bin/client/jboss-client.jar:. Client
It will test remoting and http. -Dtest=http or -Dtest=remoting to just run a single test
java -cp /tmp/jboss-eap-7.3/bin/client/jboss-cli-client.jar:/tmp/jboss-eap-7.3/bin/client/jboss-client.jar:. -Dtest=http Client
-Dpass=null will set the user/pass to null so that it will not be set inside of the InitialContext.
-Dhost= , -Dport , -Duser, -Dpass can all be passed to use a different value from the default localhost , 8080, admin , redhat1!
Will log:
{code}
Starting test: Remote Naming / Remoting
==================
Failed to catch exception for method bind
Failed to catch exception for method rebind
Failed to catch exception for method unbind
Failed to catch exception for method rename
Failed to catch exception for method createSubcontext
Failed to catch exception for method destroySubcontext
Failed to catch exception for method destroySubcontext
Finished test: Remote Naming / Remoting
==================
Starting test: Remote Http Naming
==================
Success catch exception javax.naming.NamingException for method bind
Success catch exception javax.naming.NamingException for method rebind
Success catch exception javax.naming.CommunicationException for method unbind
Success catch exception javax.naming.CommunicationException for method rename
Success catch exception javax.naming.CommunicationException for method createSubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Finished test: Remote Http Naming
==================
{code}
Expected result is success where the client is catching a NamingException (which ever is most specific to the method).
The implementation down in the org.wildfly.naming.client.WildFlyInitialContextFactory for these methods must just not be throwing the exception back, since the server side is logging a warning
was:
Add a user: ./bin/add-user.sh -a -u admin -p redhat1!
Start JBoss ./bin/standalone.sh
javac Client.java
java -cp $JBOSS_HOME/bin/client/jboss-cli-client.jar:$JBOSS_HOME/bin/client/jboss-client.jar Client
It will test remoting and http. -Dtest=http or -Dtest=remoting to just run a single test
java -cp /tmp/jboss-eap-7.3/bin/client/jboss-cli-client.jar:/tmp/jboss-eap-7.3/bin/client/jboss-client.jar:. -Dtest=http Client
-Dpass=null will set the user/pass to null so that it will not be set inside of the InitialContext.
-Dhost= , -Dport , -Duser, -Dpass can all be passed to use a different value from the default localhost , 8080, admin , redhat1!
Will log:
{code}
Starting test: Remote Naming / Remoting
==================
Failed to catch exception for method bind
Failed to catch exception for method rebind
Failed to catch exception for method unbind
Failed to catch exception for method rename
Failed to catch exception for method createSubcontext
Failed to catch exception for method destroySubcontext
Failed to catch exception for method destroySubcontext
Finished test: Remote Naming / Remoting
==================
Starting test: Remote Http Naming
==================
Success catch exception javax.naming.NamingException for method bind
Success catch exception javax.naming.NamingException for method rebind
Success catch exception javax.naming.CommunicationException for method unbind
Success catch exception javax.naming.CommunicationException for method rename
Success catch exception javax.naming.CommunicationException for method createSubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Finished test: Remote Http Naming
==================
{code}
Expected result is success where the client is catching a NamingException (which ever is most specific to the method).
The implementation down in the org.wildfly.naming.client.WildFlyInitialContextFactory for these methods must just not be throwing the exception back, since the server side is logging a warning
> Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13459
> URL: https://issues.redhat.com/browse/WFLY-13459
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 19.1.0.Final
> Reporter: Brad Maxwell
> Assignee: Sudeshna Sur
> Priority: Minor
> Attachments: Client.java, server.log.gz
>
>
> The Remote Naming (JNDI) is Read-Only, remote clients cannot bind or rebind objects into it. Only applications running in the same JVM can bind values into JNDI.
> It looks like the server side logs the warning, but the client does not get an exception thrown back, bind and rebind should throw some javax.naming.NamingException since the bind/rebind operations are failing.
> {code}
> public static void main(String[] args) throws Exception {
> Context ctx = getInitialContext("localhost", 8080, "admin", "redhat1!");
> ctx.bind("java:/reproducer", "reproducer");
> ctx.rebind("java:/reproducer", "reproducer");
> }
> public static Context getInitialContext(String host, Integer port, String username, String password) throws NamingException {
> Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> props.put(Context.PROVIDER_URL, String.format("%s://%s:%d", "remote+http", host, port));
> if(username != null && password != null) {
> props.put(Context.SECURITY_PRINCIPAL, username);
> props.put(Context.SECURITY_CREDENTIALS, password);
> }
> return new InitialContext(props);
> }
> {code}
> {code}
> 13:20:22,804 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:66)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:262)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:289)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:238)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:126)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> 13:20:22,813 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:108)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:301)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:309)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:236)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:129)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1440?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-1440:
----------------------------------
Fix Version/s: 1.12.0.CR4
(was: 1.12.0.CR3)
> FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.
> ----------------------------------------------------------------------------------------------
>
> Key: ELY-1440
> URL: https://issues.redhat.com/browse/ELY-1440
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI
> Reporter: Darran Lofthouse
> Priority: Major
> Fix For: 1.12.0.CR4
>
>
> This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event.
> Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance.
> At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months