[jira] [Updated] (DELTASPIKE-943) Provide add() methods instead of save() methods in EntityRepository
[ https://issues.apache.org/jira/browse/DELTASPIKE-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Cunha (soro) updated DELTASPIKE-943: --- Issue Type: Improvement (was: Bug) > Provide add() methods instead of save() methods in EntityRepository > --- > > Key: DELTASPIKE-943 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-943 > Project: DeltaSpike > Issue Type: Improvement > Components: JPA-Module >Affects Versions: 1.4.1 > Environment: JPA >Reporter: Robin Roos >Assignee: Daniel Cunha (soro) >Priority: Minor > > The semantics of Repository is to model a Collection of persistent objects. > There is no need to add() an object to a Collection if it is already in that > Collection. > By providing save() methods you lead developers to invoke save() on objects > which they got from the Repository. This is (usually) inappropriate. > Please provide add() methods to parallel the save() method signatures. > Ideally the save() methods would be deprecated. > Even if the save() methods remain, IDE inspections can then be configured to > forbid their invocation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-964) Publish Javadoc 1.4.2 and 1.4.3-SNAPSHOT
[ https://issues.apache.org/jira/browse/DELTASPIKE-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Benevides resolved DELTASPIKE-964. - Resolution: Fixed Javadocs published > Publish Javadoc 1.4.2 and 1.4.3-SNAPSHOT > > > Key: DELTASPIKE-964 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-964 > Project: DeltaSpike > Issue Type: Task > Components: Documentation >Affects Versions: 1.4.2 >Reporter: Rafael Benevides >Assignee: Rafael Benevides > Fix For: 1.4.3 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-605) discuss manual interceptor implementation
[ https://issues.apache.org/jira/browse/DELTASPIKE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-605: Assignee: Thomas Andraschko > discuss manual interceptor implementation > - > > Key: DELTASPIKE-605 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-605 > Project: DeltaSpike > Issue Type: Task > Components: Core >Affects Versions: 0.7 >Reporter: Gerhard Petracek >Assignee: Thomas Andraschko > > due to a major restriction concerning interceptors for custom Bean, > InjectionTarget and Producer, we should think about a manual > interceptor implementation for them. with that we could support interceptors > e.g. for Bean created via BeanBuilder, partial-beans as well as mocked > beans. (as we have seen) esp. several use-cases for partial-beans and mocked > beans need interceptors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-406) PersistenceUnits#instance sinngleton does not work in EAR scenarios
[ https://issues.apache.org/jira/browse/DELTASPIKE-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-406: Assignee: Mark Struberg (was: Thomas Hug) > PersistenceUnits#instance sinngleton does not work in EAR scenarios > > > Key: DELTASPIKE-406 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-406 > Project: DeltaSpike > Issue Type: Bug > Components: Data-Module >Affects Versions: 0.5 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Minor > > Currently the info regarding the various persistence.xml files on the > classpath only gets scanned once and stored in the static > PersistenceUnits#instance. > This does not work in EAR scenarios if one of the persistence.xml is in a > webapp or if the deltaspike-data-impl is on any other shared ClassLoader. > We should at least document this restriction it until it's properly fixed. > A possible fix would be to have a (weak) Map > which also looks up the parent ClassLodaer chain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-817) API and Core contain types recognized as managed beans but declaring an illegal bean type
[ https://issues.apache.org/jira/browse/DELTASPIKE-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-817: Assignee: Mark Struberg > API and Core contain types recognized as managed beans but declaring an > illegal bean type > - > > Key: DELTASPIKE-817 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-817 > Project: DeltaSpike > Issue Type: Bug > Components: Core >Affects Versions: 1.2.0 >Reporter: Martin Kouba >Assignee: Mark Struberg >Priority: Minor > > API and Core artifacts contain some types which are recognized as managed > beans but in the same time they declare an illegal bean type, namely a > parameterized type that contains a wildcard type parameter: > * org.apache.deltaspike.core.util.Annotateds$AnnotatedCallableComparator > * org.apache.deltaspike.core.util.Annotateds$AnnotatedConstructorComparator > * org.apache.deltaspike.core.util.Annotateds$AnnotatedFieldComparator > * org.apache.deltaspike.core.util.Annotateds$AnnotatedMethodComparator > * org.apache.deltaspike.core.impl.exception.control.ExceptionHandlerComparator > The spec is not clear what should happen in this case (although it would make > sense to just ignore the type and log some warning), see also the > corresponding issue: > https://issues.jboss.org/browse/CDI-495 > I believe these beans should either be completely excluded from scanning > (vetoed, etc.) or should have their set of bean types restricted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-839) Data module test deployments pack individual classes instead of JARs
[
https://issues.apache.org/jira/browse/DELTASPIKE-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-839:
Assignee: Daniel Cunha (soro) (was: Ron Smeral)
> Data module test deployments pack individual classes instead of JARs
>
>
> Key: DELTASPIKE-839
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-839
> Project: DeltaSpike
> Issue Type: Bug
> Components: Data-Module, Tests
>Affects Versions: 1.2.1
>Reporter: Ron Smeral
>Assignee: Daniel Cunha (soro)
>Priority: Minor
>
> Tests of all other modules pack dependencies using ShrinkWrap's
> {{addLibrary}}, but data module tests add api and impl classes individually
> using {{addClass}}. This reduces the fidelity of the tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DELTASPIKE-920) AnnotationUtils must work with AnnotatedType, not with raw annotations
[
https://issues.apache.org/jira/browse/DELTASPIKE-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek closed DELTASPIKE-920.
---
> AnnotationUtils must work with AnnotatedType, not with raw annotations
> --
>
> Key: DELTASPIKE-920
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-920
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.4.0
>Reporter: Harald Wellmann
>
> {{AnnotationUtils}} uses reflection to find annotations on methods or
> classes.
> This approach does not consider the {{AnnotatedType}} abstraction layer
> defined in the [CDI
> spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#alternative_metadata_sources].
> Any "logical annotation" added via a {{ProcessAnnotatedType}} observer is
> currently ignored by {{AnnotationUtils}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-920) AnnotationUtils must work with AnnotatedType, not with raw annotations
[
https://issues.apache.org/jira/browse/DELTASPIKE-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-920.
-
Resolution: Not A Problem
that isn't the goal of the existing method.
currently it's just used to get @Transactional and the base information comes
from InvocationContext -> we can't use AnnotatedType here.
however, with a custom TransactionStrategyHelper it's possible to change it to
a different approach (if needed).
if you need it for your custom code, you are welcome to reopen this ticket +
provide a patch which adds a new method (which needs to support qualifiers as
well).
> AnnotationUtils must work with AnnotatedType, not with raw annotations
> --
>
> Key: DELTASPIKE-920
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-920
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.4.0
>Reporter: Harald Wellmann
>
> {{AnnotationUtils}} uses reflection to find annotations on methods or
> classes.
> This approach does not consider the {{AnnotatedType}} abstraction layer
> defined in the [CDI
> spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#alternative_metadata_sources].
> Any "logical annotation" added via a {{ProcessAnnotatedType}} observer is
> currently ignored by {{AnnotationUtils}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (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:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-940:
Assignee: Thomas Hug
> @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] [Updated] (DELTASPIKE-943) Provide add() methods instead of save() methods in EntityRepository
[ https://issues.apache.org/jira/browse/DELTASPIKE-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-943: Assignee: Daniel Cunha (soro) > Provide add() methods instead of save() methods in EntityRepository > --- > > Key: DELTASPIKE-943 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-943 > Project: DeltaSpike > Issue Type: Bug > Components: JPA-Module >Affects Versions: 1.4.1 > Environment: JPA >Reporter: Robin Roos >Assignee: Daniel Cunha (soro) >Priority: Minor > > The semantics of Repository is to model a Collection of persistent objects. > There is no need to add() an object to a Collection if it is already in that > Collection. > By providing save() methods you lead developers to invoke save() on objects > which they got from the Repository. This is (usually) inappropriate. > Please provide add() methods to parallel the save() method signatures. > Ideally the save() methods would be deprecated. > Even if the save() methods remain, IDE inspections can then be configured to > forbid their invocation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (DELTASPIKE-928) Allow to disable storeWindowTree() on ClientWindow mode
[ https://issues.apache.org/jira/browse/DELTASPIKE-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reopened DELTASPIKE-928: - > Allow to disable storeWindowTree() on ClientWindow mode > --- > > Key: DELTASPIKE-928 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-928 > Project: DeltaSpike > Issue Type: Improvement > Components: JSF-Module >Affects Versions: 1.4.0 > Environment: JSF with clientWindow >Reporter: Janario >Assignee: Thomas Andraschko > Fix For: 1.4.3 > > Attachments: DELTASPIKE-928.patch > > > If I change the default windowhandler.html, I may not want to reuse the > client data storage and this leave some object there forever. > > It would be nice if I could disable that > windowhandler.js (storeWindowTree()) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-928) Allow to disable storeWindowTree() on ClientWindow mode
[ https://issues.apache.org/jira/browse/DELTASPIKE-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-928. - Resolution: Fixed > Allow to disable storeWindowTree() on ClientWindow mode > --- > > Key: DELTASPIKE-928 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-928 > Project: DeltaSpike > Issue Type: Improvement > Components: JSF-Module >Affects Versions: 1.4.0 > Environment: JSF with clientWindow >Reporter: Janario >Assignee: Thomas Andraschko > Fix For: 1.4.3 > > Attachments: DELTASPIKE-928.patch > > > If I change the default windowhandler.html, I may not want to reuse the > client data storage and this leave some object there forever. > > It would be nice if I could disable that > windowhandler.js (storeWindowTree()) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-963) Header injection due to unescaped key in JsfUtils
[ https://issues.apache.org/jira/browse/DELTASPIKE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638440#comment-14638440 ] Ortwin Escher commented on DELTASPIKE-963: -- The fix works, thank you! > Header injection due to unescaped key in JsfUtils > - > > Key: DELTASPIKE-963 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-963 > Project: DeltaSpike > Issue Type: Bug >Affects Versions: 1.4.1 >Reporter: Ortwin Escher >Assignee: Thomas Andraschko > Fix For: 1.4.3 > > > The JsfUtils used in DeltaSpike URLEncode the values but not the keys. This > allows header injection (see > https://www.owasp.org/index.php/HTTP_Response_Splitting for more info on this > attack type). As an example if I open a page without window ID and thus have > a redirect by DefaultClientWindow.getOrCreateWindowId() in it: > /somepage.xhtml?%0aSet-Cookie:%20newcookie%3Dinjectme%0a > will cause the key side to be an unescaped part of the redirect URL and thus > cause the cookie to be set. the encodeValues parameter should also cause the > keys to be encoded as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
