[JBoss JIRA] (WFLY-485) Review SecurityContext associations
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-485?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-485:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Review SecurityContext associations
> ------------------------------------
>
> Key: WFLY-485
> URL: https://issues.jboss.org/browse/WFLY-485
> Project: WildFly
> Issue Type: Sub-task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: David Lloyd
> Labels: Security_SPI
> Fix For: 8.0.0.CR1
>
>
> We should re-review the approach we take for security context association within AS7 containers.
> Back at the time of AS 3 it fairly reliable to assume a 1:1 mapping of thread and client with the incoming connection being allocated it's own thread, this is no longer automatically the case and different containers can use different threading models e.g. using Executors to handle asynchronous requests.
> The problem with using a ThreadLocal approach is that every time a container diverges from the 1:1 mapping of thread and client that container needs to work around the issue of an invalid SecurityContext association.
> One possibility is to pass responsibility for managing the context to the container although this then introduces the question of how it is passed from container to container. This issue needs to consider this further.
> Also need to review further how the security context can be created at all entry points to the server and how it can be manually switched now that we use SASL on entry for remote calls we do now have the opportunity for equivalent behaviour at the entry point for both web and ejb type calls - in the past we only had this opportunity for web based calls and would only create a security context on entering the interceptors for the EJB calls.
--
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
11 years, 3 months
[JBoss JIRA] (WFLY-479) Ability to rollback AS version updates
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-479?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-479:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Ability to rollback AS version updates
> --------------------------------------
>
> Key: WFLY-479
> URL: https://issues.jboss.org/browse/WFLY-479
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 8.0.0.CR1
>
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> >> A fixpack installer that handles version rollbacks would be fantastic.
> >> Of course it needs to remain flexible to work with JBoss installs that
> >> have been manually modified.
> Note that this may be out of scope for community AS 7; e.g. it may be a JON function. However, the AS 7 design of things like how we lay down content on the filesystem should take this use case into account.
--
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
11 years, 3 months
[JBoss JIRA] (WFLY-674) NPE in thread "vfs-shutdown"
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-674?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-674:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> NPE in thread "vfs-shutdown"
> -----------------------------
>
> Key: WFLY-674
> URL: https://issues.jboss.org/browse/WFLY-674
> Project: WildFly
> Issue Type: Bug
> Components: VFS
> Environment: 7.1.0.Alpha1 Jenkins build 1402
> Reporter: Juergen Zimmermann
> Assignee: David Lloyd
> Fix For: 8.0.0.CR1
>
>
> When I shutdown a standalone server I'm getting a NPE. The shutdown command is:
> jboss-admin.bat --connect command=:shutdown
> Console log:
> ...
> 18:24:55,990 INFO [org.jboss.as.logging] Restored bootstrap log handlers
> 18:24:55,990 INFO [org.jboss.as.jmx.JMXConnectorService] JMX remote connector stopped
> 18:24:56,075 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-as-osgi-configadmin:7.1.0.Alpha1-SNAPSHOT
> 18:24:56,125 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.log:1.0.0
> 18:24:56,230 INFO [org.apache.catalina.core.StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
> 18:24:56,286 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.configadmin:1.2.8
> 18:24:56,323 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-osgi-logging:1.0.0
> 18:24:56,330 INFO [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
> 18:24:56,331 INFO [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
> 18:24:56,368 ERROR [stderr] Exception in thread "vfs-shutdown" java.lang.NullPointerException
> 18:24:56,368 ERROR [stderr] at org.jboss.vfs.TempFileProvider$DeleteTask.run(TempFileProvider.java:151)
> 18:24:56,368 ERROR [stderr] at org.jboss.vfs.TempFileProvider.close(TempFileProvider.java:132)
> 18:24:56,368 ERROR [stderr] at org.jboss.osgi.vfs30.VirtualFileAdaptor30$2.run(VirtualFileAdaptor30.java:94)
--
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
11 years, 3 months