[JBoss JIRA] (WFLY-2982) refactor two phase persistence unit services (PhaseOnePersistenceUnitServiceImpl + PersistenceUnitServiceImpl) into one service
by Scott Marlow (JIRA)
Scott Marlow created WFLY-2982:
----------------------------------
Summary: refactor two phase persistence unit services (PhaseOnePersistenceUnitServiceImpl + PersistenceUnitServiceImpl) into one service
Key: WFLY-2982
URL: https://issues.jboss.org/browse/WFLY-2982
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JPA / Hibernate
Affects Versions: 8.0.0.Final
Reporter: Scott Marlow
Assignee: Scott Marlow
Fix For: 9.0.0.CR1
Related feedback from https://github.com/wildfly/wildfly/pull/4722:
{quote}
This is asymetrical, so if this service , and phase one are stopped, and then phase 1 is started again, phase 2 will appear started. The side effects seem minor though
{quote}
{quote}
We have a long term goal to somehow verify every service can be stopped and started with the expected effect. Right now many of our services are not restartable which makes potential new features like partial deployment standby hard to achieve. So Im just offering pointers whenever I see lifecycle symmetry issues.
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2981) Add a date format attribute to the list-log-files operation
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-2981?page=com.atlassian.jira.plugin.... ]
Stan Silvert commented on WFLY-2981:
------------------------------------
It wouldn't hurt, but that doesn't help a GUI. The only reason for sort-by at the DMR level would be if you wanted sorting in the plain CLI output. But I don't see that as something important in that case.
It becomes important in a GUI because the user expects to be able to sort a table by any column, ascending or descending. But you wouldn't use a DMR operation to do the sorting for you. You just let the table widget do the sort locally.
> Add a date format attribute to the list-log-files operation
> -----------------------------------------------------------
>
> Key: WFLY-2981
> URL: https://issues.jboss.org/browse/WFLY-2981
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> The {{list-log-files}} operation outputs the last modified date of the available log files. The current date format is {{yyyy-MM-dd'T'HH:mm:ss.SSSZ}}, but it could be useful for the operation to allow any valid {{SimpleDateFormat}} to be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2978) Wildfly ignores jboss-ejb-client.xml
by ofbiz brazil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2978?page=com.atlassian.jira.plugin.... ]
ofbiz brazil updated WFLY-2978:
-------------------------------
Component/s: Naming
> Wildfly ignores jboss-ejb-client.xml
> ------------------------------------
>
> Key: WFLY-2978
> URL: https://issues.jboss.org/browse/WFLY-2978
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Naming, Remoting
> Affects Versions: 8.0.0.Final
> Environment: Spring 4.0.2, EJB
> Reporter: ofbiz brazil
> Assignee: David Lloyd
> Priority: Critical
>
> Hi all,
> I have a project with remote EJB's running in one Wildfly server and the're some war client projects that invoked those EJB's in another Wildfly server. Even adding the descriptor jboss-ejb-client.xml into war client projects Widlfly always says: "No EJB receiver available for handling....". That seems Wildfly is ignoring the descriptor no matter if the file exists in WEB-INF, by the way in JBoss 7.1.1 it works perfectly.
> I added into client war projects the descripor jboss-ejb-client.xml
> --------------------------------------------------------------------------------
> <jboss-ejb-client>
> <client-context>
> <ejb-receivers>
> <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection" />
> </ejb-receivers>
> </client-context>
> </jboss-ejb-client>
> In Wildfly server running EJB's the standalone.xml
> -----------------------------------------------------------
> <security-realm name="ejb-security-realm">
> <server-identities>
> <secret value="c2Fvb3JhY2xlZGV2cGFzcw=="/>
> </server-identities>
> </security-realm>
> <subsystem xmlns="urn:jboss:domain:remoting:2.0">
> <endpoint worker="default"/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> <outbound-connections>
> <remote-outbound-connection name="remote-ejb-connection" outbound-socket-binding-ref="remote-ejb" username="ejbuser" security-realm="ejb-security-realm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> <property name="SASL_POLICY_NOANONYMOUS" value="true"/>
> <property name="SASL_POLICY_NOPLAINTEXT" value="false"/>
> </properties>
> </remote-outbound-connection>
> </outbound-connections>
> </subsystem>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:7029}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:7030}"/>
> <socket-binding name="http" port="${jboss.http.port:7021}"/>
> <socket-binding name="https" port="${jboss.https.port:7022}"/>
> <socket-binding name="txn-recovery-environment" port="7025"/>
> <socket-binding name="txn-status-manager" port="7026"/>
> <outbound-socket-binding name="remote-ejb">
> <remote-destination host="myserver.com" port="7021"/>
> </outbound-socket-binding>
> </socket-binding-group>
> Console exception:
> ------------------------
> 10:41:20,761 INFO [io.undertow.servlet] (MSC service thread 1-9) Initializing Spring root WebApplicationContext
> 10:41:22,540 INFO [org.jboss.ejb.client] (MSC service thread 1-9) JBoss EJB Client version 2.0.0.Final
> 10:41:22,853 INFO [org.wildfly.extension.undertow] (MSC service thread 1-9) JBAS017534: Registered web context: /orca
> 10:41:22,884 INFO [org.jboss.as.server] (ServerService Thread Pool -- 29) JBAS018559: Deployed "SBBORCA.war" (runtime-name : "SBBORCA.war")
> 10:41:22,900 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://0.0.0.0:7029/management
> 10:41:22,900 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://0.0.0.0:7029
> 10:41:22,900 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Final "WildFly" started in 12312ms - Started 413 of 466 services (93 services are lazy, passive or on-demand)
> 10:41:45,533 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /orca/j_spring_cas_security_check: java.lang.RuntimeException: java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:SBBUserAccess, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@19ba64
> at com.sbb.spring.security.CustomUserDetailsService.loadUserByUsername(CustomUserDetailsService.java:63) [utils-1.0.0.jar:]
> at org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper.loadUserDetails(UserDetailsByNameServiceWrapper.java:51) [spring-security-core-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.cas.authentication.CasAuthenticationProvider.loadUserByAssertion(CasAuthenticationProvider.java:185) [spring-security-cas-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.cas.authentication.CasAuthenticationProvider.authenticateNow(CasAuthenticationProvider.java:141) [spring-security-cas-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.cas.authentication.CasAuthenticationProvider.authenticate(CasAuthenticationProvider.java:126) [spring-security-cas-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156) [spring-security-core-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter$AuthenticationManagerDelegator.authenticate(WebSecurityConfigurerAdapter.java:431) [spring-security-config-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.cas.web.CasAuthenticationFilter.attemptAuthentication(CasAuthenticationFilter.java:242) [spring-security-cas-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:211) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:110) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:110) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:50) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:108) [spring-web-4.0.2.RELEASE.jar:4.0.2.RELEASE]
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) [spring-security-web-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344) [spring-web-4.0.2.RELEASE.jar:4.0.2.RELEASE]
> at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261) [spring-web-4.0.2.RELEASE.jar:4.0.2.RELEASE]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:177) [spring-orm-4.0.2.RELEASE.jar:4.0.2.RELEASE]
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:108) [spring-web-4.0.2.RELEASE.jar:4.0.2.RELEASE]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:SBBUserAccess, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@19ba64
> at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:749) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:116) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final]
> at com.sun.proxy.$Proxy89.findByUserProfile(Unknown Source)
> at com.sbb.spring.security.UserProfileGrantedAuthoritiesLoader.loadAuthorities(UserProfileGrantedAuthoritiesLoader.java:44) [utils-1.0.0.jar:]
> at com.sbb.spring.security.CustomUserDetailsService.loadUserByUsername(CustomUserDetailsService.java:55) [utils-1.0.0.jar:]
> ... 52 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2981) Add a date format attribute to the list-log-files operation
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2981?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-2981:
-------------------------------------
Hmm.. ...that might work too. If we're adding attributes, do you see any use to having something like a {{sort-by}} attribute?
> Add a date format attribute to the list-log-files operation
> -----------------------------------------------------------
>
> Key: WFLY-2981
> URL: https://issues.jboss.org/browse/WFLY-2981
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> The {{list-log-files}} operation outputs the last modified date of the available log files. The current date format is {{yyyy-MM-dd'T'HH:mm:ss.SSSZ}}, but it could be useful for the operation to allow any valid {{SimpleDateFormat}} to be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2981) Add a date format attribute to the list-log-files operation
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-2981?page=com.atlassian.jira.plugin.... ]
Stan Silvert commented on WFLY-2981:
------------------------------------
Looking at SimpleDateFormat, I do have the option of parsing the date back out. So I could pass in a format String that includes everything but the kitchen sink, then parse the string that comes back to get a Date object.
But that technique seems error-prone and non-obvious.
Instead of my earlier suggestion to have two fields, why don't we put a flag on the operation called, "format-date", with a default value of true. That way, the default can be human-readable, but if you need the date as a Long then the operation can give it to you that way.
> Add a date format attribute to the list-log-files operation
> -----------------------------------------------------------
>
> Key: WFLY-2981
> URL: https://issues.jboss.org/browse/WFLY-2981
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> The {{list-log-files}} operation outputs the last modified date of the available log files. The current date format is {{yyyy-MM-dd'T'HH:mm:ss.SSSZ}}, but it could be useful for the operation to allow any valid {{SimpleDateFormat}} to be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (SECURITY-801) Modify authentication logic so that exceptions that occur in the role mapping providers do not cause authentication failures
by Derek Horton (JIRA)
[ https://issues.jboss.org/browse/SECURITY-801?page=com.atlassian.jira.plug... ]
Derek Horton updated SECURITY-801:
----------------------------------
Description:
This is an extension of SECURITY-797.
Currently, if the role mapping providers throw an exception then the authentication request fails. It seems like exception should be logged, but failures in role mapping should not cause the authentication request to fail.
<quote from SECURITY-797>
One thing we could do is log exceptions thrown by mapping managers at WARN or ERROR level and let the invocation go through. Authentication will succeed and if authorization fails an admin can check the logs to find out why mapping has failed.
</quote from SECURITY-797>
was:This is an extension of SECURITY-797.
> Modify authentication logic so that exceptions that occur in the role mapping providers do not cause authentication failures
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-801
> URL: https://issues.jboss.org/browse/SECURITY-801
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_20.Final
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
>
> This is an extension of SECURITY-797.
> Currently, if the role mapping providers throw an exception then the authentication request fails. It seems like exception should be logged, but failures in role mapping should not cause the authentication request to fail.
> <quote from SECURITY-797>
> One thing we could do is log exceptions thrown by mapping managers at WARN or ERROR level and let the invocation go through. Authentication will succeed and if authorization fails an admin can check the logs to find out why mapping has failed.
> </quote from SECURITY-797>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (SECURITY-797) Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set
by Derek Horton (JIRA)
[ https://issues.jboss.org/browse/SECURITY-797?page=com.atlassian.jira.plug... ]
Derek Horton resolved SECURITY-797.
-----------------------------------
Resolution: Done
> Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set
> -------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-797
> URL: https://issues.jboss.org/browse/SECURITY-797
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
> Attachments: SECURITY-797.patch
>
>
> If the DatabaseRolesMappingProvider's rolesQuery returns an empty set, then the authentication attempts will fail. Seems like it should not cause the authentication attempt to fail, since this is about mapping/adding roles.
> It looks like the code detects that the result set is empty, but then it tries to get the role from the empty set. This causes an exception which in turn causes the authentication attempt to fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2981) Add a date format attribute to the list-log-files operation
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-2981?page=com.atlassian.jira.plugin.... ]
Stan Silvert edited comment on WFLY-2981 at 2/20/14 12:41 PM:
--------------------------------------------------------------
We do need a human-readable date for CLI, but we also need another attribute that reports this date as a long. Otherwise, it is difficult to display and sort the list in a GUI.
was (Author: ssilvert):
I understand that we need a readable date for CLI, but we also need another attribute that reports this date as a long. Otherwise, it is difficult to display and sort the list in a GUI.
> Add a date format attribute to the list-log-files operation
> -----------------------------------------------------------
>
> Key: WFLY-2981
> URL: https://issues.jboss.org/browse/WFLY-2981
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> The {{list-log-files}} operation outputs the last modified date of the available log files. The current date format is {{yyyy-MM-dd'T'HH:mm:ss.SSSZ}}, but it could be useful for the operation to allow any valid {{SimpleDateFormat}} to be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months