[JBoss JIRA] (WFLY-9072) @RunAs role authorization from the first invoker of @Singleton bean is propagated through the @PostConstruct method of @Singleton bean with Elytron
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9072?page=com.atlassian.jira.plugin.... ]
David Lloyd moved JBEAP-12062 to WFLY-9072:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9072 (was: JBEAP-12062)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
Security
(was: EJB)
(was: Security)
Affects Version/s: (was: 7.1.0.DR19)
(was: 7.1.0.ER1)
> @RunAs role authorization from the first invoker of @Singleton bean is propagated through the @PostConstruct method of @Singleton bean with Elytron
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9072
> URL: https://issues.jboss.org/browse/WFLY-9072
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Michal Jurc
> Assignee: David Lloyd
> Priority: Critical
>
> Suppose an environment with a chain of three bean invocations:
> {code:java|title=Bean1.java}
> @Stateless
> @Remote(WhoAmI.class)
> @RunAs("Admin")
> @SecurityDomain("other")
> public class Bean1 implements WhoAmI {
> @EJB(beanName = "Bean2")
> private WhoAmI singleton;
> public String getCallerPrincipal() {
> return singleton.getCallerPrincipal();
> }
> }{code}
> {code:java|title=Bean2.java}@Singleton
> @Remote(WhoAmI.class)
> @SecurityDomain("other")
> public class Bean2 implements WhoAmI {
> @EJB(beanName = "Bean3")
> private WhoAmI bean3;
> private String principal;
> @PostConstruct
> public void init() {
> principal = bean3.getCallerPrincipal();
> }
> public String getCallerPrincipal() {
> return principal;
> }
> }
> {code}
> {code:java|title=Bean3.java}@Stateless
> @Local(WhoAmI.class)
> @RolesAllowed("Admin")
> @SecurityDomain("other")
> public class Bean3 implements WhoAmI {
> @Resource
> private SessionContext ctx;
> public String getCallerPrincipal() {
> return ctx.getCallerPrincipal().getName();
> }
> }{code}
> The {{@RunAs("Admin")}} is propagated from {{Bean1}} through {{Bean2.init()}} to {{Bean3}} with Elytron. The EJB3.1 specification does not specify security context of {{@PostConstruct}} method for {{@Singleton}} beans, however with this approach the {{@RunAs}} authorization of initialization of any {{@Singleton}} bean will be determined by its first invoker with Elytron. With legacy security, the {{@RunAs}} authorization of {{@PostConstruct}} method for {{@Singleton}} beans was undefined.
> This is covered by {{org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testSingletonPostconstructSecurityNotPropagating}} in WildFly Integration/Basic Test Suite module.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8997) @RunAsIdentity should cause authentication part to be skipped
by Jörg Bäsner (JIRA)
[ https://issues.jboss.org/browse/WFLY-8997?page=com.atlassian.jira.plugin.... ]
Jörg Bäsner reassigned WFLY-8997:
---------------------------------
Assignee: Stefan Guilhen
> @RunAsIdentity should cause authentication part to be skipped
> -------------------------------------------------------------
>
> Key: WFLY-8997
> URL: https://issues.jboss.org/browse/WFLY-8997
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jörg Bäsner
> Assignee: Stefan Guilhen
>
> The issue [WFLY-140|https://issues.jboss.org/browse/WFLY-140] introduced a change in behavior.
> Before this change, the SecurityContextInterceptor would just invoke the push() method on SimpleSecurityManager and that method would internally create a new security context and authenticate the incoming principal if needed. In that implementation the presence of a RunAsIdentity would cause authentication part to be skipped.
> With the changes in the above issue, the security context establishment and the authentication parts were separated and while push() still checks for a RunAsIdentity, the authenticate() implementation does not, which ends up triggering the authentication process even if a RunAsIdentity is available. There is another check in place to avoid authentication if a valid authenticated subject already exists and the security domains match but this should also be the case if the security domains do not match.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8928) JMS broker does not allow the use of a transacted session in a Servlet
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8928?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reopened WFLY-8928:
-------------------------------
Assignee: Jeff Mesnil (was: Andy Taylor)
The attribute is not taken into account in the pooled-connection-factory resource (but it does in the @JMSConnectionFactoryDefinition annotation).
> JMS broker does not allow the use of a transacted session in a Servlet
> ----------------------------------------------------------------------
>
> Key: WFLY-8928
> URL: https://issues.jboss.org/browse/WFLY-8928
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Alpha1
> Environment: JBoss-EAP-7.0.0
> ActiveMQ Artemis 1.1.0.SP16
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 11.0.0.Beta1
>
>
> The JMS broker does not allow the creation of a transacted session inside a Servlet. It is essential for a Servlet to use a transacted session at the absence of JTA support.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-1280) Regression against ER1, Elytron kerberos for remoting does not work with IBM java
by Martin Choma (JIRA)
Martin Choma created ELY-1280:
---------------------------------
Summary: Regression against ER1, Elytron kerberos for remoting does not work with IBM java
Key: ELY-1280
URL: https://issues.jboss.org/browse/ELY-1280
Project: WildFly Elytron
Issue Type: Bug
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
In ER2 kerberos authentication in remoting does not work with IBM java. I see same error in 2 scenarios:
* Elytron kerberos authentication for management interface - CLI
* Elytron kerberos authenticaiton for EJB
This issue (reproducer/description)is based on CLI case. As it seems to me it is caused by same error.
{code}
13:15:25,038 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) Command:[/home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/../tests/target/dist/jboss-eap/bin/jboss-cli.sh, -Djboss.cli.config=/home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/../tests/target/dist/jboss-eap/bin/jboss-cli.xml, -c, --controller=remote+http://localhost.localdomain:9990, --timeout=60000, -Djavax.security.auth.useSubjectCredsOnly=false, -Djava.security.krb5.conf=/home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb5-4030706113084817464.conf, -Dsun.security.krb5.debug=true, -Dcom.ibm.security.jgss.debug=all, -Dcom.ibm.security.krb5.Krb5Debug=all, -Djavax.net.ssl.trustStore=/home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/KerberosCLITestCase/localhost.keystore, :whoami]
13:15:26,352 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Initialized connection from /127.0.0.1:41690 to /127.0.0.1:9990 with options {org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL=>remote}
13:15:26,352 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Accepted connection from /127.0.0.1:41690 to localhost.localdomain/127.0.0.1:9990
13:15:26,353 TRACE [org.jboss.remoting.remote] (management I/O-1) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@6a1d77d9
13:15:26,353 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Sent 28 bytes
13:15:26,353 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Flushed channel
13:15:26,375 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) No buffers in queue for message header
13:15:26,375 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Allocated fresh buffers
13:15:26,375 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received 56 bytes
13:15:26,375 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
13:15:26,375 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Received java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capabilities request
13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: version 1
13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: remote endpoint name "cli-client"
13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: message close protocol supported
13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: remote version is "5.0.0.CR4-redhat-1"
13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: remote channels in is "40"
13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: remote channels out is "40"
13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: authentication service
13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) No EXTERNAL mechanism due to lack of SSL
13:15:26,380 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Added mechanism GSSAPI
13:15:26,381 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Added mechanism PLAIN
13:15:26,381 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Sent 81 bytes
13:15:26,381 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Flushed channel
13:15:27,194 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) No buffers in queue for message header
13:15:27,194 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Allocated fresh buffers
13:15:27,194 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received 583 bytes
13:15:27,194 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=579 cap=8192]
13:15:27,194 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Received java.nio.HeapByteBuffer[pos=0 lim=579 cap=8192]
13:15:27,194 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received authentication request
13:15:27,194 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback type='SASL' name='GSSAPI' host-name='localhost.localdomain' protocol='remote'
13:15:27,194 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback type='SASL' name='GSSAPI' host-name='localhost.localdomain' protocol='remote'
13:15:27,197 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-1) configuredMaxReceiveBuffer=16777215
13:15:27,197 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-1) relaxComplianceChecks=false
13:15:27,197 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-1) QOP={AUTH}
13:15:27,197 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-1) Obtaining GSSCredential for the service from callback handler...
13:15:27,197 TRACE [org.wildfly.security] (management I/O-1) No valid cached credential, obtaining new one...
13:15:27,198 TRACE [org.wildfly.security] (management I/O-1) Logging in using LoginContext and subject [Subject:
]
13:15:27,218 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: debug=true
13:15:27,218 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: principal=remote/localhost.localdomain(a)JBOSS.ORG
13:15:27,218 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: credsType=accept only
13:15:27,218 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 config: useDefaultCcache=false (default)
13:15:27,219 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 config: useCcache=null
13:15:27,219 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 config: useDefaultKeytab=false
13:15:27,220 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 config: useKeytab=/home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb.4304838673032362747.keytab
13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: forwardable=false (default)
13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: renewable=false (default)
13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: proxiable=false (default)
13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: tryFirstPass=false (default)
13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: useFirstPass=false (default)
13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: moduleBanner=false (default)
13:15:27,225 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: interactive login? no
13:15:27,225 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 Try keytab for principal=remote/localhost.localdomain(a)JBOSS.ORG
13:15:27,327 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 No Kerberos creds in keytab for principal remote/localhost.localdomain(a)JBOSS.ORG
13:15:27,327 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 Login successful
13:15:27,327 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 kprincipal : remote/localhost.localdomain(a)JBOSS.ORG
13:15:27,327 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 remote/localhost.localdomain(a)JBOSS.ORG added to Subject
13:15:27,327 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 KeyTab added to Subject
13:15:27,328 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 No keys to add to Subject for remote/localhost.localdomain(a)JBOSS.ORG
13:15:27,328 TRACE [org.wildfly.security] (management I/O-1) Logging in using LoginContext and subject [Subject:
Principal: remote/localhost.localdomain(a)JBOSS.ORG
Private Credential: /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb.4304838673032362747.keytab for remote/localhost.localdomain(a)JBOSS.ORG
] succeed
13:15:27,329 TRACE [org.wildfly.security] (management I/O-1) Creating GSSName for Principal 'remote/localhost.localdomain(a)JBOSS.ORG'
13:15:27,337 TRACE [org.wildfly.security] (management I/O-1) Obtained GSSCredentialCredential [org.wildfly.security.credential.GSSKerberosCredential@b7cba9ed]
13:15:27,337 TRACE [org.wildfly.security] (management I/O-1) Handling ServerCredentialCallback: successfully obtained credential type type=class org.wildfly.security.credential.GSSKerberosCredential, algorithm=null, params=null
13:15:27,339 TRACE [org.wildfly.security] (management I/O-1) Created SaslServer for mechanism GSSAPI and protocol remote
13:15:27,339 TRACE [org.wildfly.security] (management I/O-1) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@7e6923d] for mechanism [GSSAPI]
13:15:27,339 TRACE [org.jboss.remoting.endpoint] (management I/O-1) Allocated tick to 9 of endpoint "localhost:MANAGEMENT" <43fd3bb3> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@48dbe42)
13:15:27,599 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-6) Negotiated mechanism 1.2.840.113554.1.2.2
13:15:27,599 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-6) No response so triggering next state immediately.
13:15:27,599 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-6) Not offering a security layer so zero length.
13:15:27,601 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-6) Transitioning to receive chosen security layer from client
13:15:27,601 TRACE [org.jboss.remoting.remote.server] (management task-6) Server sending authentication challenge
13:15:27,601 TRACE [org.jboss.remoting.remote] (management task-6) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Authentication@aa1379f
13:15:27,601 TRACE [org.jboss.remoting.endpoint] (management task-6) Resource closed count 00000008 of endpoint "localhost:MANAGEMENT" <43fd3bb3> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@48dbe42)
13:15:27,601 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Sent 37 bytes
13:15:27,601 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Flushed channel
13:15:27,608 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) No buffers in queue for message header
13:15:27,608 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Allocated fresh buffers
13:15:27,608 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received 37 bytes
13:15:27,608 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=33 cap=8192]
13:15:27,608 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Received java.nio.HeapByteBuffer[pos=0 lim=33 cap=8192]
13:15:27,608 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received authentication response
13:15:27,608 TRACE [org.jboss.remoting.endpoint] (management I/O-1) Allocated tick to 9 of endpoint "localhost:MANAGEMENT" <43fd3bb3> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@48dbe42)
13:15:27,609 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-7) Client selected security layer AUTH, with maxBuffer of 0
13:15:27,610 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-7) Authentication ID=jdukec4c36a8b-173f-41e7-af5b-7492f91a404c(a)JBOSS.ORG, Authorization ID=jdukec4c36a8b-173f-41e7-af5b-7492f91a404c(a)JBOSS.ORG
13:15:27,610 TRACE [org.wildfly.security] (management task-7) Principal assigning: [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c(a)JBOSS.ORG], pre-realm rewritten: [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c], realm name: [fileSystemRealm], post-realm rewritten: [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c], realm rewritten: [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c]
13:15:27,611 TRACE [org.wildfly.security] (management task-7) Role mapping: principal [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles []
13:15:27,611 TRACE [org.wildfly.security] (management task-7) Authorizing principal jdukec4c36a8b-173f-41e7-af5b-7492f91a404c.
13:15:27,611 TRACE [org.wildfly.security] (management task-7) Authorizing against the following attributes: [] => []
13:15:27,611 TRACE [org.wildfly.security] (management task-7) Permission mapping: identity [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c] with roles [] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
13:15:27,611 TRACE [org.wildfly.security] (management task-7) Authorization succeed
13:15:27,611 TRACE [org.wildfly.security] (management task-7) RunAs authorization succeed - the same identity
13:15:27,611 TRACE [org.wildfly.security] (management task-7) Handling AuthorizeCallback: authenticationID = jdukec4c36a8b-173f-41e7-af5b-7492f91a404c(a)JBOSS.ORG authorizationID = jdukec4c36a8b-173f-41e7-af5b-7492f91a404c(a)JBOSS.ORG authorized = true
13:15:27,613 TRACE [org.jboss.remoting.remote.server] (management task-7) Server sending authentication rejected: java.lang.IllegalArgumentException: Parameter 'gssCredential' may not be null
at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:70)
at org.wildfly.common.Assert.checkNotNullParam(Assert.java:48)
at org.wildfly.security.credential.GSSKerberosCredential.<init>(GSSKerberosCredential.java:53)
at org.wildfly.security.credential.GSSKerberosCredential.<init>(GSSKerberosCredential.java:43)
at org.wildfly.security.sasl.gssapi.GssapiServer.evaluateMessage(GssapiServer.java:284)
at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
at org.wildfly.security.sasl.gssapi.GssapiServer.evaluateResponse(GssapiServer.java:122)
at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57)
at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:468)
at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:898)
at org.jboss.remoting3.EndpointImpl$TrackingExecutor$$Lambda$905.00000000201F9C40.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:785)
13:15:27,614 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-7) dispose
13:15:27,614 TRACE [org.wildfly.security] (management task-7) Handling AuthenticationCompleteCallback: fail
13:15:27,614 TRACE [org.jboss.remoting.remote] (management task-7) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@18fce815
13:15:27,614 TRACE [org.jboss.remoting.endpoint] (management task-7) Resource closed count 00000008 of endpoint "localhost:MANAGEMENT" <43fd3bb3> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@48dbe42)
13:15:27,614 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Sent 5 bytes
13:15:27,614 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Flushed channel
13:15:27,615 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) No buffers in queue for message header
13:15:27,615 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Alloca
{code}
Test pass just fine on Oracle/OpenJDK JDK
In stacktrace there is involved code introduced by https://github.com/wildfly-security/wildfly-elytron/commit/faf1aff340c3a2... .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8933) Description of path attributes in messaging subsystem contains HTML tags
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8933?page=com.atlassian.jira.plugin.... ]
Romain Pelisse reopened WFLY-8933:
----------------------------------
Reopening upstream issue, as downstream was reopend.
> Description of path attributes in messaging subsystem contains HTML tags
> ------------------------------------------------------------------------
>
> Key: WFLY-8933
> URL: https://issues.jboss.org/browse/WFLY-8933
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
> Fix For: 11.0.0.Beta1
>
>
> Description of attributes {{path}} and {{relative-to}} shown in CLI contains HTML tags.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/path=paging-directory:read-resource-description
> {noformat}
> {panel}
> "paging-directory" => {
> "path" => {
> "description" => "The actual filesystem path. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path. {color:#d04437}<p>{color}If treated as an absolute path, the actual runtime pathname specified by the value of this attribute will be determined as follows: {color:#d04437}</p>{color}If this value is already absolute, then the value is directly used. Otherwise the runtime pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.",
> },
> "relative-to" => {
> "description" => "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute. The standard paths provided by the system include:{color:#d04437}<ul><li>{color}jboss.home - the root directory of the JBoss AS distribution{color:#d04437}</li>{color}<li>user.home - user's home directory{color:#d04437}</li><li>{color}user.dir - user's current working directory</li><li>java.home - java installation directory{color:#d04437}</li><li>{color}jboss.server.base.dir - root directory for an individual server instance{color:#d04437}</li><li>{color}jboss.server.data.dir - directory the server will use for persistent data file storage{color:#d04437}</li><li>{color}jboss.server.log.dir - directory the server will use for log file storage{color:#d04437}</li><li>{color}jboss.server.tmp.dir - directory the server will use for temporary file storage{color:#d04437}</li><li>{color}jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances{color:#d04437}</li></ul>{color}"
> },
> }
> {panel}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8933) Description of path attributes in messaging subsystem contains HTML tags
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8933?page=com.atlassian.jira.plugin.... ]
Romain Pelisse updated WFLY-8933:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/10194, https://github.com/wildfly/wildfly/pull/10299 (was: https://github.com/wildfly/wildfly/pull/10194)
> Description of path attributes in messaging subsystem contains HTML tags
> ------------------------------------------------------------------------
>
> Key: WFLY-8933
> URL: https://issues.jboss.org/browse/WFLY-8933
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
> Fix For: 11.0.0.Beta1
>
>
> Description of attributes {{path}} and {{relative-to}} shown in CLI contains HTML tags.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/path=paging-directory:read-resource-description
> {noformat}
> {panel}
> "paging-directory" => {
> "path" => {
> "description" => "The actual filesystem path. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path. {color:#d04437}<p>{color}If treated as an absolute path, the actual runtime pathname specified by the value of this attribute will be determined as follows: {color:#d04437}</p>{color}If this value is already absolute, then the value is directly used. Otherwise the runtime pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.",
> },
> "relative-to" => {
> "description" => "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute. The standard paths provided by the system include:{color:#d04437}<ul><li>{color}jboss.home - the root directory of the JBoss AS distribution{color:#d04437}</li>{color}<li>user.home - user's home directory{color:#d04437}</li><li>{color}user.dir - user's current working directory</li><li>java.home - java installation directory{color:#d04437}</li><li>{color}jboss.server.base.dir - root directory for an individual server instance{color:#d04437}</li><li>{color}jboss.server.data.dir - directory the server will use for persistent data file storage{color:#d04437}</li><li>{color}jboss.server.log.dir - directory the server will use for log file storage{color:#d04437}</li><li>{color}jboss.server.tmp.dir - directory the server will use for temporary file storage{color:#d04437}</li><li>{color}jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances{color:#d04437}</li></ul>{color}"
> },
> }
> {panel}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months