[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=15110440#comment-15110440
]
Xavier Dury commented on DELTASPIKE-940:
Now I realize that there is an advantage using {{EntityManagerResolver}}
instead of qualifiers: with qualifiers, you need to {{@Produces}} the entity
manager which can cause trouble if it belongs to a passivation-capable scope
(see {{SerializableEntityManager}}). The problem does not exist with
{{EntityManagerResolver}} which does not produce anything but keeps the entity
manager reference for on-demand resolving. So maybe, it is the
{{@Transactional}} annotation which should have an {{entityManagerResolver}}
attribute.
> @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=15110810#comment-15110810
]
Thomas Hug commented on DELTASPIKE-940:
---
The main reason to use a resolver approach in the Data module was that there is
a similar approach in the JSF module (MessageResolver AFAIR) so to stick to
this also in the JPA module would be overall consistent.
Another disadvantage of {{@Transactional(qualifier = ...}} is that a qualifier
is limited to an annotation type. A "proper" qualifier could also include
arguments, e.g. {{@MyDB(DbSchema.CUSTOMER)}} which wouldn't work with this
approach.
Anything speaking against moving {{EntityManagerResolver}} into the JPA module?
> @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=15110905#comment-15110905
]
Gerhard Petracek commented on DELTASPIKE-940:
-
[~thomashug]:
that isn't the whole story. @Transactional#qualifier is not intended to be used
for the main use-case. it's just in place for an optimization.
with @Transactional#qualifier you can limit the transactions to start.
without it all injected entity-managers will be used (for each entity-manager a
transaction will get started).
for those entity-managers there is no qualifier limitation in theory (currently
it's limited to qualifier-types to improve the performance, but it's just an
implementation detail of EntityManagerEntry and not a limitation of the api).
it's the other way round: EntityManagerResolver is limited, because there can
be only one active entity-manager.
> @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] [Created] (DELTASPIKE-1064) @Secured and stereotypes with custom metadata on class level annotation overwrites method level annotation
Tvori created DELTASPIKE-1064: - Summary: @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] [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=15110905#comment-15110905
]
Gerhard Petracek edited comment on DELTASPIKE-940 at 1/21/16 5:03 PM:
--
[~thomashug] and [~kalgon] :
that isn't the whole story. @Transactional#qualifier is not intended to be used
for the main use-case. it's just in place for an optimization.
with @Transactional#qualifier you can limit the transactions to start.
without it all injected entity-managers will be used (for each entity-manager a
transaction will get started).
for those entity-managers there is no qualifier limitation in theory (currently
it's limited to qualifier-types to improve the performance, but it's just an
implementation detail of EntityManagerEntry and not a limitation of the api).
it's the other way round: EntityManagerResolver is limited, because there can
be only one active entity-manager (in case of the data module it's just a minor
limitation due to the overall concept).
was (Author: gpetracek):
[~thomashug]:
that isn't the whole story. @Transactional#qualifier is not intended to be used
for the main use-case. it's just in place for an optimization.
with @Transactional#qualifier you can limit the transactions to start.
without it all injected entity-managers will be used (for each entity-manager a
transaction will get started).
for those entity-managers there is no qualifier limitation in theory (currently
it's limited to qualifier-types to improve the performance, but it's just an
implementation detail of EntityManagerEntry and not a limitation of the api).
it's the other way round: EntityManagerResolver is limited, because there can
be only one active entity-manager (in case of the data module it's just a minor
limitation due to the overall concept).
> @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=15110991#comment-15110991 ] Gerhard Petracek commented on DELTASPIKE-1064: -- it sounds like DELTASPIKE-1014 > @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)
