[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers
[
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15112287#comment-15112287
]
Gerhard Petracek commented on DELTASPIKE-940:
-
[~thomashug]: imo we shouldn't change it (at least until v2)
> @Transactional and @EntityManagerConfig each use a different method to
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: Thomas Hug
>Priority: Minor
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to
> specify which one(s) should be used. Currently, {{@Transactional}} and
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}}
> ({{@EntityManagerConfig(entityManagerResolver =
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks
> better and should be applied to {{@EntityManagerConfig}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1064) @Secured and stereotypes with custom metadata on class level annotation overwrites method level annotation
[ https://issues.apache.org/jira/browse/DELTASPIKE-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15112203#comment-15112203 ] Gerhard Petracek commented on DELTASPIKE-1064: -- it sounds like DELTASPIKE-1014 [~tvori.kod]: please ensure that you are really using 1.5.2 and not 1.5.1 > @Secured and stereotypes with custom metadata on class level annotation > overwrites method level annotation > -- > > Key: DELTASPIKE-1064 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1064 > Project: DeltaSpike > Issue Type: Bug > Components: Security-Module >Affects Versions: 1.5.2 > Environment: Fedora Linux, Wildfly 8.1, jboss-jsf-api_2.2_spec - 2.2.8 >Reporter: Tvori >Priority: Minor > > When you are using @Secured and stereotypes with custom metadata and you have > annotation on both class and method level the custom metadata is overwrited > by the class level annotation. Will be better that the method level > annotation overwrites the class level annotation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers
[
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15112206#comment-15112206
]
Thomas Hug commented on DELTASPIKE-940:
---
So by using {{@Transactional(qualifier = ...)}} the point of each qualifier
added here is to select exactly one {{EntityManager}} instead of all available
over @Any. Same thing {{EntityManagerResolver}} is used in the Data module for
(but as you mentioned we have a different concept of 1 EM per repository, so
the limiting factor is {{@EntityManagerConfig}} on type level).
I don't have a preference for one or the other, the original CDI Query was
acutally using qualifiers to select the EM for each repository in case multiple
existed. As mentioned above the major reason for {{EntityManagerResolver}} was
a consistent approach with the JSF module. Changing one or the other will break
existing code so not really sure whether something should be changed at all
(given we have slightly different concepts). Other preferences?
> @Transactional and @EntityManagerConfig each use a different method to
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: Thomas Hug
>Priority: Minor
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to
> specify which one(s) should be used. Currently, {{@Transactional}} and
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}}
> ({{@EntityManagerConfig(entityManagerResolver =
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks
> better and should be applied to {{@EntityManagerConfig}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers
[
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15112287#comment-15112287
]
Gerhard Petracek edited comment on DELTASPIKE-940 at 1/22/16 10:46 AM:
---
[~thomashug]: imo we shouldn't change it (at least until v2)
fyi: it isn't about @Any - it's about the injected entity-managers (= default
behavior of @Transactional)
was (Author: gpetracek):
[~thomashug]: imo we shouldn't change it (at least until v2)
> @Transactional and @EntityManagerConfig each use a different method to
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: Thomas Hug
>Priority: Minor
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to
> specify which one(s) should be used. Currently, {{@Transactional}} and
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}}
> ({{@EntityManagerConfig(entityManagerResolver =
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks
> better and should be applied to {{@EntityManagerConfig}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers
[
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15112328#comment-15112328
]
Thomas Hug commented on DELTASPIKE-940:
---
Agree, v2 might be a good opportunity to consolidate the API.
> @Transactional and @EntityManagerConfig each use a different method to
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: Thomas Hug
>Priority: Minor
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to
> specify which one(s) should be used. Currently, {{@Transactional}} and
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}}
> ({{@EntityManagerConfig(entityManagerResolver =
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks
> better and should be applied to {{@EntityManagerConfig}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
RE: [jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers
At the risk of demonstrating a lack of adequate context to contribute to the
discussion...
One preference expressed at our shop is to eliminate the notion of "defaulting"
to an EntityManager. That is, pursue an API that provides explicit readability
as to which EntityManager/persistenceUnitName is being invoked.
In addition, the API should enable multiple alternative EntityManagers during
JUnit testing.
Here is the type of testing use case typical in a large shop:
1. A standard JUnit tests uses H2 as an embedded database.
2. A 'special case' Stored Procedure test uses the application SQL Server
database (DEV instance).
3. A 'special case' View test accesses a legacy DB2 database.
In this scenario items #1 and #2 require at least one alternatve and #3
requires a unique persitenceUnitName. And of course there are additional
scenarios where more than one alternative is required.
So perhaps for some, the idea of an API providing "magic" defaulting is less
attractive than explicit in-line readability.
_Marvin
-Original Message-
From: Thomas Hug (JIRA) [mailto:j...@apache.org]
Sent: Friday, January 22, 2016 6:50 AM
To: deltaspike-...@incubator.apache.org
Subject: [jira] [Commented] (DELTASPIKE-940) @Transactional and
@EntityManagerConfig each use a different method to resolve EntityManagers
> When an application uses multiple {{EntityManager}}'s, there must be a way to
> specify which one(s) should be used
