[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-433:
---------------------------
Description:
LDAP realm should be able to authenticate user using user certificate.
This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP.
was:
This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP.
> Support verification of a users certificate against an LDAP Server
> ------------------------------------------------------------------
>
> Key: ELY-433
> URL: https://issues.jboss.org/browse/ELY-433
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms, SSL
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta10
>
>
> LDAP realm should be able to authenticate user using user certificate.
> This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7024) show-resources operation of jaxrs subsystem must provide more information about end-point
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-7024?page=com.atlassian.jira.plugin.... ]
Lin Gao updated WFLY-7024:
--------------------------
Description:
show-resources operation of jaxrs subsystem must provide more informations about end-point. Information about parameters and returned value should be provided.
Example:
{code:java}
@GET
@Path("entity/get")
@Produces(MediaType.APPLICATION_JSON)
public Person post3(@QueryParam("boolean") @DefaultValue("false") boolean v) {
Person per = new Person();
per.setName("per");
per.setFamily("son");
return per;
}
{code}
Actual return value of {{/deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources}}:
{noformat}
{
"resource-class" => "org.resteasy.simple.deployment.AdvancedService",
"resource-path" => "/sample/entity/get",
"resource-methods" => ["GET /jaxrs-eap/a/sample/entity/get - org.resteasy.simple.deployment.AdvancedService.post3(...)"]
},
{noformat}
There should be information about "boolean v" parameter and about returned type (Person).
---
-jax-rs subsystem should be able to collect some statistics about invocation of end-points (count of invocations, execution time, etc.)-
-Some statistics could be be activated and printed, only if end-point is also EJB bean, example:-
-/subsystem=ejb3:write-attribute(name=enable-statistics,value=true)-
-/deployment=cdiexp-1.0-SNAPSHOT.jar/subsystem=ejb3/stateless-session-bean=Servicer:read-resource(include-runtime=true)-
was:
show-resources operation of jaxrs subsystem must provide more informations about end-point. Information about parameters and returned value should be provided.
Example:
{code:java}
@GET
@Path("entity/get")
@Produces(MediaType.APPLICATION_JSON)
public Person post3(@QueryParam("boolean") @DefaultValue("false") boolean v) {
Person per = new Person();
per.setName("per");
per.setFamily("son");
return per;
}
{code}
Actual return value of {{/deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources}}:
{noformat}
{
"resource-class" => "org.resteasy.simple.deployment.AdvancedService",
"resource-path" => "/sample/entity/get",
"resource-methods" => ["GET /jaxrs-eap/a/sample/entity/get - org.resteasy.simple.deployment.AdvancedService.post3(...)"]
},
{noformat}
There should be information about "boolean v" parameter and about returned type (Person).
---
jax-rs subsystem should be able to collect some statistics about invocation of end-points (count of invocations, execution time, etc.)
Some statistics could be be activated and printed, only if end-point is also EJB bean, example:
{noformat}
/subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
/deployment=cdiexp-1.0-SNAPSHOT.jar/subsystem=ejb3/stateless-session-bean=Servicer:read-resource(include-runtime=true)
{noformat}
> show-resources operation of jaxrs subsystem must provide more information about end-point
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-7024
> URL: https://issues.jboss.org/browse/WFLY-7024
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Critical
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> show-resources operation of jaxrs subsystem must provide more informations about end-point. Information about parameters and returned value should be provided.
> Example:
> {code:java}
> @GET
> @Path("entity/get")
> @Produces(MediaType.APPLICATION_JSON)
> public Person post3(@QueryParam("boolean") @DefaultValue("false") boolean v) {
> Person per = new Person();
> per.setName("per");
> per.setFamily("son");
> return per;
> }
> {code}
> Actual return value of {{/deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources}}:
> {noformat}
> {
> "resource-class" => "org.resteasy.simple.deployment.AdvancedService",
> "resource-path" => "/sample/entity/get",
> "resource-methods" => ["GET /jaxrs-eap/a/sample/entity/get - org.resteasy.simple.deployment.AdvancedService.post3(...)"]
> },
> {noformat}
> There should be information about "boolean v" parameter and about returned type (Person).
> ---
> -jax-rs subsystem should be able to collect some statistics about invocation of end-points (count of invocations, execution time, etc.)-
> -Some statistics could be be activated and printed, only if end-point is also EJB bean, example:-
> -/subsystem=ejb3:write-attribute(name=enable-statistics,value=true)-
> -/deployment=cdiexp-1.0-SNAPSHOT.jar/subsystem=ejb3/stateless-session-bean=Servicer:read-resource(include-runtime=true)-
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7024) show-resources operation of jaxrs subsystem must provide more information about end-point
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-7024?page=com.atlassian.jira.plugin.... ]
Lin Gao updated WFLY-7024:
--------------------------
Summary: show-resources operation of jaxrs subsystem must provide more information about end-point (was: show-resources operation of jaxrs subsystem must provide more informations and statistics about end-point)
> show-resources operation of jaxrs subsystem must provide more information about end-point
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-7024
> URL: https://issues.jboss.org/browse/WFLY-7024
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Critical
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> show-resources operation of jaxrs subsystem must provide more informations about end-point. Information about parameters and returned value should be provided.
> Example:
> {code:java}
> @GET
> @Path("entity/get")
> @Produces(MediaType.APPLICATION_JSON)
> public Person post3(@QueryParam("boolean") @DefaultValue("false") boolean v) {
> Person per = new Person();
> per.setName("per");
> per.setFamily("son");
> return per;
> }
> {code}
> Actual return value of {{/deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources}}:
> {noformat}
> {
> "resource-class" => "org.resteasy.simple.deployment.AdvancedService",
> "resource-path" => "/sample/entity/get",
> "resource-methods" => ["GET /jaxrs-eap/a/sample/entity/get - org.resteasy.simple.deployment.AdvancedService.post3(...)"]
> },
> {noformat}
> There should be information about "boolean v" parameter and about returned type (Person).
> ---
> jax-rs subsystem should be able to collect some statistics about invocation of end-points (count of invocations, execution time, etc.)
> Some statistics could be be activated and printed, only if end-point is also EJB bean, example:
> {noformat}
> /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> /deployment=cdiexp-1.0-SNAPSHOT.jar/subsystem=ejb3/stateless-session-bean=Servicer:read-resource(include-runtime=true)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1807) CLI config (jboss-cli.xml) is trimming vault-options when it should pass them on as is
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1807?page=com.atlassian.jira.plugi... ]
Chao Wang moved JBEAP-6057 to WFCORE-1807:
------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1807 (was: JBEAP-6057)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: 3.0.0.Alpha8
(was: 7.0.1.GA)
> CLI config (jboss-cli.xml) is trimming vault-options when it should pass them on as is
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1807
> URL: https://issues.jboss.org/browse/WFCORE-1807
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha8
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Vault option is calling trim which is causing issues with custom vault implementation.
> The implementation of the vault config parser in the normal EAP config (i.e. in standalone.xml) does not do this.
> To provide more details why this is an issue, the custom impl is prepending a string to an executable command. By trimming the command is being mangled:
> <vault code="com.example.CommandVault" module="com.example">
> <vault-option name="prependToValue" value="perform_encryption.sh -value "/>
> <vault-option name="allowEmptyPassword" value="false"/>
> </vault>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich updated WFLY-7075:
-----------------------------------------
Attachment: Screenshot_10.png
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> [WFLY-7108] is now the tracking jira for the fix.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich edited comment on WFLY-7075 at 9/19/16 12:00 AM:
------------------------------------------------------------------------
Sorry for long delay.
I have tried to apply suggested solution for our project.
And we have next trouble:
We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized)
We have only one EntityManager with non-default configuration (Extended, Unsynchronized)
If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project.
If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only.
I can see Persistence.xml property from EntityManagerFactory:
!Screenshot_10.png|thumbnail! and !Screenshot_7.png|thumbnail!
But i have only target property from annotation in other places:
!Screenshot_8.png|thumbnail! and !Screenshot_9.png|thumbnail!
was (Author: veselroger):
Sorry for long delay.
I have tried to apply suggested solution for our project.
And we have next trouble:
We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized)
We have only one EntityManager with non-default configuration (Extended, Unsynchronized)
If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project.
If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only.
I can see Persistence.xml property from EntityManagerFactory:
!Screenshot_7.png|thumbnail!
But i have only target property from annotation in other places:
!Screenshot_8.png|thumbnail! and !Screenshot_9.png|thumbnail!
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> [WFLY-7108] is now the tracking jira for the fix.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich edited comment on WFLY-7075 at 9/18/16 11:56 PM:
------------------------------------------------------------------------
Sorry for long delay.
I have tried to apply suggested solution for our project.
And we have next trouble:
We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized)
We have only one EntityManager with non-default configuration (Extended, Unsynchronized)
If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project.
If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only.
I can see Persistence.xml property from EntityManagerFactory:
!Screenshot_7.png|thumbnail!
But i have only target property from annotation in other places:
!Screenshot_8.png|thumbnail! and !Screenshot_9.png|thumbnail!
was (Author: veselroger):
Sorry for long delay.
I have tried to apply suggested solution for our project.
And we have next trouble:
We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized)
We have only one EntityManager with non-default configuration (Extended, Unsynchronized)
If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project.
If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only.
I can see this property from EntityManagerFactory:
!Screenshot_7.png|thumbnail!
But i have only target property from annotation:
!Screenshot_8.png|thumbnail! and !Screenshot_9.png|thumbnail!
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> [WFLY-7108] is now the tracking jira for the fix.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months