[JBoss JIRA] (WFLY-3912) Upgrade IronJacamar
by David Lloyd (JIRA)
David Lloyd created WFLY-3912:
---------------------------------
Summary: Upgrade IronJacamar
Key: WFLY-3912
URL: https://issues.jboss.org/browse/WFLY-3912
Project: WildFly
Issue Type: Component Upgrade
Components: JCA
Reporter: David Lloyd
Assignee: Jesper Pedersen
Fix For: 9.0.0.CR1
Update to a version of IronJacamar which includes JBJCA-1222.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (JBJCA-1222) org.jboss.jca.adapters.jdbc.WrapperDataSource#getConnection() requires unusual permissions
by David Lloyd (JIRA)
David Lloyd created JBJCA-1222:
----------------------------------
Summary: org.jboss.jca.adapters.jdbc.WrapperDataSource#getConnection() requires unusual permissions
Key: JBJCA-1222
URL: https://issues.jboss.org/browse/JBJCA-1222
Project: IronJacamar
Issue Type: Bug
Reporter: David Lloyd
Assignee: Jesper Pedersen
The WrapperDataSource calls AbstractConnectionManager#allocateConnection() which in turn causes JBossSecuritySubjectFactory#createSubject() to be called. This method requires special/unusual permissions that a user deployment cannot be expected to configure.
The connection manager and/or the wrapper data source should probably check a more pedestrian "get connection" sort of permission, and then do the rest of the work in a privileged context.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (SECURITY-862) Creating a subject requires special permissions
by David Lloyd (JIRA)
David Lloyd created SECURITY-862:
------------------------------------
Summary: Creating a subject requires special permissions
Key: SECURITY-862
URL: https://issues.jboss.org/browse/SECURITY-862
Project: PicketBox
Issue Type: Bug
Reporter: David Lloyd
Assignee: Stefan Guilhen
When a client calls createSubject on a JBossSecuritySubjectFactory, it ultimately causes SecurityConfiguration#getApplicationPolicy() to be called which requires a special permission.
This should probably be done as a privileged block, with a simple createSubject permission of some sort replacing this.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-3911) EJB timer service security manager issue
by David Lloyd (JIRA)
David Lloyd created WFLY-3911:
---------------------------------
Summary: EJB timer service security manager issue
Key: WFLY-3911
URL: https://issues.jboss.org/browse/WFLY-3911
Project: WildFly
Issue Type: Bug
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: 9.0.0.CR1
The file-backed timer service reads files without privileged context, causing security manager failures when loading persisted timers.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-3531) JPA persistence unit services should start completly before sub-deployments reach the next deployment phase
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3531?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3531:
-----------------------------------------------
Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1114726|https://bugzilla.redhat.com/show_bug.cgi?id=1114726] from ON_QA to VERIFIED
> JPA persistence unit services should start completly before sub-deployments reach the next deployment phase
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3531
> URL: https://issues.jboss.org/browse/WFLY-3531
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 9.0.0.Alpha1
>
>
> This is about EAR deployments that contain multiple sub-deployments. Currently, EJB jar sub-deployments may still be starting their JPA persistence units while other sub-deployments move ahead (in parallel) to other deployment phases (which can cause the entity classes to be loaded before the persistence provider has been registered with the class file transformer for the persistence unit).
> Each deployment/sub-deployment should set the NEXT_PHASE_DEP on the persistence unit service (see current phaseContext.addToAttachmentList(Attachments.NEXT_PHASE_DEPS, puServiceName) in PersistenceUnitServiceHandler). For this to work, each deployment/subdeployment should set NEXT_PHASE_DEPS during the FIRST_MODULE_USE phase for each pre-determine persistence unit service name).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months