[jira] [Updated] (DELTASPIKE-968) ClientWindowMode shows white loading page for button navigation
[ https://issues.apache.org/jira/browse/DELTASPIKE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-968: Fix Version/s: (was: 1.5.0) 1.5.1 ClientWindowMode shows white loading page for button navigation --- Key: DELTASPIKE-968 URL: https://issues.apache.org/jira/browse/DELTASPIKE-968 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 1.4.2 Environment: Google Chrome 44 Reporter: Markus Lachat Assignee: Thomas Andraschko Fix For: 1.5.1 Screen flickers when navigating with buttons. The action method of a command button uses a bean method and there a viewNavigationHandler with a viewConfig class. This behavior occurs on Chrome and the jsf-playground application of DS running on maven plugin bundled tomee or glassfish http://localhost:8080/ds/views/windowhandling/clientwindow/test.xhtml https://github.com/mlachat/deltaspike/tree/ds-1.4.2-WindowHandling -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-848) EntityManagerFactory is not closed on disposal
[
https://issues.apache.org/jira/browse/DELTASPIKE-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-848.
-
Resolution: Won't Fix
this topic continues at DELTASPIKE-976
EntityManagerFactory is not closed on disposal
--
Key: DELTASPIKE-848
URL: https://issues.apache.org/jira/browse/DELTASPIKE-848
Project: DeltaSpike
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: Sven Linstaedt
{{org.apache.deltaspike.jpa.impl.entitymanager.EntityManagerFactoryProducer}}
does produces EntityManagerFactory, but it does not implement a disposal
method, which closes the factory on destruction, causing any underlying
SesionFactories to leak.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-853) Use @Stereotype for interface/enum/implicit bean discovery
[ https://issues.apache.org/jira/browse/DELTASPIKE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-853: Fix Version/s: 1.5.0 Use @Stereotype for interface/enum/implicit bean discovery -- Key: DELTASPIKE-853 URL: https://issues.apache.org/jira/browse/DELTASPIKE-853 Project: DeltaSpike Issue Type: Improvement Reporter: Jozef Hartinger Assignee: Daniel Cunha (soro) Fix For: 1.5.0 In several places DeltaSpike uses ProcessAnnotatedType to discover interfaces/enum provided by the application. These interfaces/enums are usually annotated with a marker annotation, e.g.: * @MessageBundle * @View/@Folder * @Repository * most likely others This works fine in explicit bean archives, where PAT is fired for each and every interface/enum within the archive. In CDI 1.1+ implicit bean archives, this won't work however as PAT is only fired for classes with a bean defining annotation. One option to make these extensions work in CDI 1.2 environment is to add @Stereotype to the marker annotations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (DELTASPIKE-974) support other pk than long
[
https://issues.apache.org/jira/browse/DELTASPIKE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek reopened DELTASPIKE-974:
-
support other pk than long
--
Key: DELTASPIKE-974
URL: https://issues.apache.org/jira/browse/DELTASPIKE-974
Project: DeltaSpike
Issue Type: Improvement
Components: Data-Module
Affects Versions: 1.4.2
Reporter: Gerhard Petracek
currently it's possible to use e.g.:
@Repository
public interface MyRepository extends EntityRepositoryMyEntry, Long {
MyEntry findByProperty(String property);
}
the same fails once the pk is e.g. a string.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DELTASPIKE-967) Ability to start transaction scope manually
[ https://issues.apache.org/jira/browse/DELTASPIKE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek closed DELTASPIKE-967. --- Ability to start transaction scope manually --- Key: DELTASPIKE-967 URL: https://issues.apache.org/jira/browse/DELTASPIKE-967 Project: DeltaSpike Issue Type: New Feature Affects Versions: 1.4.2 Reporter: John D. Ament Currently, the CDI Context controller class defines methods to manually start the CDI 1.0 provided scopes - Request, Session, Application and ConversationScoped. There's presently no way in the DS codebase to manually start a TransactionScope using the controllers See here https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-weld/src/main/java/org/apache/deltaspike/cdise/weld/WeldContextControl.java#L76 https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-owb/src/main/java/org/apache/deltaspike/cdise/owb/OpenWebBeansContextControl.java#L72 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-967) Ability to start transaction scope manually
[ https://issues.apache.org/jira/browse/DELTASPIKE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-967. - Resolution: Won't Fix this topic continues at DELTASPIKE-977 Ability to start transaction scope manually --- Key: DELTASPIKE-967 URL: https://issues.apache.org/jira/browse/DELTASPIKE-967 Project: DeltaSpike Issue Type: New Feature Affects Versions: 1.4.2 Reporter: John D. Ament Currently, the CDI Context controller class defines methods to manually start the CDI 1.0 provided scopes - Request, Session, Application and ConversationScoped. There's presently no way in the DS codebase to manually start a TransactionScope using the controllers See here https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-weld/src/main/java/org/apache/deltaspike/cdise/weld/WeldContextControl.java#L76 https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-owb/src/main/java/org/apache/deltaspike/cdise/owb/OpenWebBeansContextControl.java#L72 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-977) discuss handling of custom scope-annotations
Gerhard Petracek created DELTASPIKE-977: --- Summary: discuss handling of custom scope-annotations Key: DELTASPIKE-977 URL: https://issues.apache.org/jira/browse/DELTASPIKE-977 Project: DeltaSpike Issue Type: Task Components: CdiControl Affects Versions: 1.5.0 Reporter: Gerhard Petracek Assignee: Mark Struberg e.g. we could introduce a deactivatable validator for the scope-annotations passed to ContextControl#startContext and ContextControl#stopContext (similar to what we have in the test-control module) to avoid wrong usages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-974) support other pk than long
[
https://issues.apache.org/jira/browse/DELTASPIKE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-974.
-
Resolution: Duplicate
support other pk than long
--
Key: DELTASPIKE-974
URL: https://issues.apache.org/jira/browse/DELTASPIKE-974
Project: DeltaSpike
Issue Type: Improvement
Components: Data-Module
Affects Versions: 1.4.2
Reporter: Gerhard Petracek
currently it's possible to use e.g.:
@Repository
public interface MyRepository extends EntityRepositoryMyEntry, Long {
MyEntry findByProperty(String property);
}
the same fails once the pk is e.g. a string.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-974) support other pk than long
[
https://issues.apache.org/jira/browse/DELTASPIKE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-974.
-
Resolution: Won't Fix
Assignee: (was: Daniel Cunha (soro))
it turned out that the issue is caused by a dependent-scoped
EntityManagerResolver.
support other pk than long
--
Key: DELTASPIKE-974
URL: https://issues.apache.org/jira/browse/DELTASPIKE-974
Project: DeltaSpike
Issue Type: Improvement
Components: Data-Module
Affects Versions: 1.4.2
Reporter: Gerhard Petracek
currently it's possible to use e.g.:
@Repository
public interface MyRepository extends EntityRepositoryMyEntry, Long {
MyEntry findByProperty(String property);
}
the same fails once the pk is e.g. a string.
-
@Repository
public interface MyRepository extends EntityRepositoryMyEntry, String {
MyEntry findByProperty(String property);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-975) dependent-scoped EntityManagerResolver get destroyed too early
Gerhard Petracek created DELTASPIKE-975: --- Summary: dependent-scoped EntityManagerResolver get destroyed too early Key: DELTASPIKE-975 URL: https://issues.apache.org/jira/browse/DELTASPIKE-975 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Affects Versions: 1.4.2 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.3 if a dependent-scoped EntityManagerResolver creates an unmanaged dependent-scoped entity-manager, there is no possibility to close it. reason: the dependent-scoped EntityManagerResolver gets destroyed too early (directly after the lookup of the entity-manager). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-975) dependent-scoped EntityManagerResolver get destroyed too early
[ https://issues.apache.org/jira/browse/DELTASPIKE-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-975. - Resolution: Fixed dependent-scoped EntityManagerResolver get destroyed too early -- Key: DELTASPIKE-975 URL: https://issues.apache.org/jira/browse/DELTASPIKE-975 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Affects Versions: 1.4.2 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.3 if a dependent-scoped EntityManagerResolver creates an unmanaged dependent-scoped entity-manager, there is no possibility to close it. reason: the dependent-scoped EntityManagerResolver gets destroyed too early (directly after the lookup of the entity-manager). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-967) Ability to start transaction scope manually
[ https://issues.apache.org/jira/browse/DELTASPIKE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658577#comment-14658577 ] Gerhard Petracek commented on DELTASPIKE-967: - it sounded like you are talking about org.apache.deltaspike.jpa.api.transaction.TransactionScoped. however, in both cases, it needs to be managed by the container itself, because such beans depend on an active transaction - everything else doesn't make a lot of sense imo... Ability to start transaction scope manually --- Key: DELTASPIKE-967 URL: https://issues.apache.org/jira/browse/DELTASPIKE-967 Project: DeltaSpike Issue Type: New Feature Affects Versions: 1.4.2 Reporter: John D. Ament Currently, the CDI Context controller class defines methods to manually start the CDI 1.0 provided scopes - Request, Session, Application and ConversationScoped. There's presently no way in the DS codebase to manually start a TransactionScope using the controllers See here https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-weld/src/main/java/org/apache/deltaspike/cdise/weld/WeldContextControl.java#L76 https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-owb/src/main/java/org/apache/deltaspike/cdise/owb/OpenWebBeansContextControl.java#L72 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DELTASPIKE-967) Ability to start transaction scope manually
[ https://issues.apache.org/jira/browse/DELTASPIKE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14658577#comment-14658577 ] Gerhard Petracek edited comment on DELTASPIKE-967 at 8/5/15 5:57 PM: - it sounded like you are talking about org.apache.deltaspike.jpa.api.transaction.TransactionScoped. however, javax.transaction.TransactionScoped isn't part of the cdi-specification itself. in both cases it needs to be managed automatically, because such beans depend on an active transaction - everything else doesn't make a lot of sense imo... was (Author: gpetracek): it sounded like you are talking about org.apache.deltaspike.jpa.api.transaction.TransactionScoped. however, in both cases, it needs to be managed by the container itself, because such beans depend on an active transaction - everything else doesn't make a lot of sense imo... Ability to start transaction scope manually --- Key: DELTASPIKE-967 URL: https://issues.apache.org/jira/browse/DELTASPIKE-967 Project: DeltaSpike Issue Type: New Feature Affects Versions: 1.4.2 Reporter: John D. Ament Currently, the CDI Context controller class defines methods to manually start the CDI 1.0 provided scopes - Request, Session, Application and ConversationScoped. There's presently no way in the DS codebase to manually start a TransactionScope using the controllers See here https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-weld/src/main/java/org/apache/deltaspike/cdise/weld/WeldContextControl.java#L76 https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-owb/src/main/java/org/apache/deltaspike/cdise/owb/OpenWebBeansContextControl.java#L72 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-974) support other pk than long
[
https://issues.apache.org/jira/browse/DELTASPIKE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-974:
Description:
currently it's possible to use e.g.:
@Repository
public interface MyRepository extends EntityRepositoryMyEntry, Long {
MyEntry findByProperty(String property);
}
the same fails once the pk is e.g. a string.
was:
currently it's possible to use e.g.:
@Repository
public interface MyRepository extends EntityRepositoryMyEntry, Long {
MyEntry findByProperty(String property);
}
the same fails once the pk is e.g. a string.
-
@Repository
public interface MyRepository extends EntityRepositoryMyEntry, String {
MyEntry findByProperty(String property);
}
support other pk than long
--
Key: DELTASPIKE-974
URL: https://issues.apache.org/jira/browse/DELTASPIKE-974
Project: DeltaSpike
Issue Type: Improvement
Components: Data-Module
Affects Versions: 1.4.2
Reporter: Gerhard Petracek
currently it's possible to use e.g.:
@Repository
public interface MyRepository extends EntityRepositoryMyEntry, Long {
MyEntry findByProperty(String property);
}
the same fails once the pk is e.g. a string.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-853) Use @Stereotype for interface/enum/implicit bean discovery
[ https://issues.apache.org/jira/browse/DELTASPIKE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-853: Issue Type: Improvement (was: Task) Use @Stereotype for interface/enum/implicit bean discovery -- Key: DELTASPIKE-853 URL: https://issues.apache.org/jira/browse/DELTASPIKE-853 Project: DeltaSpike Issue Type: Improvement Reporter: Jozef Hartinger Assignee: Daniel Cunha (soro) In several places DeltaSpike uses ProcessAnnotatedType to discover interfaces/enum provided by the application. These interfaces/enums are usually annotated with a marker annotation, e.g.: * @MessageBundle * @View/@Folder * @Repository * most likely others This works fine in explicit bean archives, where PAT is fired for each and every interface/enum within the archive. In CDI 1.1+ implicit bean archives, this won't work however as PAT is only fired for classes with a bean defining annotation. One option to make these extensions work in CDI 1.2 environment is to add @Stereotype to the marker annotations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-968) ClientWindowMode shows white loading page for button navigation
[ https://issues.apache.org/jira/browse/DELTASPIKE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-968: Assignee: Thomas Andraschko ClientWindowMode shows white loading page for button navigation --- Key: DELTASPIKE-968 URL: https://issues.apache.org/jira/browse/DELTASPIKE-968 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 1.4.2 Environment: Google Chrome 44 Reporter: Markus Lachat Assignee: Thomas Andraschko Fix For: 1.4.3 Screen flickers when navigating with buttons. The action method of a command button uses a bean method and there a viewNavigationHandler with a viewConfig class. This behavior occurs on Chrome and the jsf-playground application of DS running on maven plugin bundled tomee or glassfish http://localhost:8080/ds/views/windowhandling/clientwindow/test.xhtml https://github.com/mlachat/deltaspike/tree/ds-1.4.2-WindowHandling -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-968) ClientWindowMode shows white loading page for button navigation
[ https://issues.apache.org/jira/browse/DELTASPIKE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-968: Fix Version/s: 1.4.3 ClientWindowMode shows white loading page for button navigation --- Key: DELTASPIKE-968 URL: https://issues.apache.org/jira/browse/DELTASPIKE-968 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 1.4.2 Environment: Google Chrome 44 Reporter: Markus Lachat Fix For: 1.4.3 Screen flickers when navigating with buttons. The action method of a command button uses a bean method and there a viewNavigationHandler with a viewConfig class. This behavior occurs on Chrome and the jsf-playground application of DS running on maven plugin bundled tomee or glassfish http://localhost:8080/ds/views/windowhandling/clientwindow/test.xhtml https://github.com/mlachat/deltaspike/tree/ds-1.4.2-WindowHandling -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-967) Ability to start transaction scope manually
[ https://issues.apache.org/jira/browse/DELTASPIKE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648161#comment-14648161 ] Gerhard Petracek commented on DELTASPIKE-967: - i agree with mark - imo we don't need this ticket. Ability to start transaction scope manually --- Key: DELTASPIKE-967 URL: https://issues.apache.org/jira/browse/DELTASPIKE-967 Project: DeltaSpike Issue Type: New Feature Affects Versions: 1.4.2 Reporter: John D. Ament Assignee: Mark Struberg Currently, the CDI Context controller class defines methods to manually start the CDI 1.0 provided scopes - Request, Session, Application and ConversationScoped. There's presently no way in the DS codebase to manually start a TransactionScope using the controllers See here https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-weld/src/main/java/org/apache/deltaspike/cdise/weld/WeldContextControl.java#L76 https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-owb/src/main/java/org/apache/deltaspike/cdise/owb/OpenWebBeansContextControl.java#L72 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-680) Lazy init should not rely on BeanManagerProvider
[
https://issues.apache.org/jira/browse/DELTASPIKE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-680:
Fix Version/s: (was: 1.4.3)
1.5.0
Lazy init should not rely on BeanManagerProvider
Key: DELTASPIKE-680
URL: https://issues.apache.org/jira/browse/DELTASPIKE-680
Project: DeltaSpike
Issue Type: Improvement
Components: Data-Module
Affects Versions: 1.0.1
Reporter: Harald Wellmann
Assignee: Harald Wellmann
Fix For: 1.5.0
Trying to work with DeltaSpike Data in OSGi (with on-the-fly OSGification,
see DELTASPIKE-660), I found that things break when the TCCL is not set to
the classloader of the current repository.
This is caused by lazy initialization of {{RepositoryComponent}} using
{{BeanManagerProvider}}.
Now the current strategies of {{BeanManagerProvider}} to locate the current
{{BeanManager}} do not work in OSGi where each bundle may have its own
BeanManager and there is no obvious interpretation of current, and the TCCL
is not by default set to anything useful for this problem.
However, in the context of DeltaSpike Data, is it easy to avoid the
{{BeanManagerProvider}} even with lazy initialization. The correct
{{BeanManager}} is known when a {{RepositoryComponent}} is instantiated, so
its sufficient to keep a reference to this {{BeanManager}} to perform lazy
initialization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-853) Use @Stereotype for interface/enum/implicit bean discovery
[ https://issues.apache.org/jira/browse/DELTASPIKE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-853: Summary: Use @Stereotype for interface/enum/implicit bean discovery (was: Use @Stereotype for interface/enum discovery) Use @Stereotype for interface/enum/implicit bean discovery -- Key: DELTASPIKE-853 URL: https://issues.apache.org/jira/browse/DELTASPIKE-853 Project: DeltaSpike Issue Type: Task Reporter: Jozef Hartinger Assignee: Daniel Cunha (soro) In several places DeltaSpike uses ProcessAnnotatedType to discover interfaces/enum provided by the application. These interfaces/enums are usually annotated with a marker annotation, e.g.: * @MessageBundle * @View/@Folder * @Repository * most likely others This works fine in explicit bean archives, where PAT is fired for each and every interface/enum within the archive. In CDI 1.1+ implicit bean archives, this won't work however as PAT is only fired for classes with a bean defining annotation. One option to make these extensions work in CDI 1.2 environment is to add @Stereotype to the marker annotations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-743) audit of code/javadoc for warnings and other minor improvements
[ https://issues.apache.org/jira/browse/DELTASPIKE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-743: Assignee: Rafael Benevides (was: Matt Benson) audit of code/javadoc for warnings and other minor improvements --- Key: DELTASPIKE-743 URL: https://issues.apache.org/jira/browse/DELTASPIKE-743 Project: DeltaSpike Issue Type: Improvement Affects Versions: 1.1.0 Reporter: Matt Benson Assignee: Rafael Benevides Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-897) discuss configuration of a ClassDeactivator
[ https://issues.apache.org/jira/browse/DELTASPIKE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-897: Fix Version/s: (was: 1.5.0) 1.4.3 discuss configuration of a ClassDeactivator --- Key: DELTASPIKE-897 URL: https://issues.apache.org/jira/browse/DELTASPIKE-897 Project: DeltaSpike Issue Type: Task Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.3 currently it's needed to configure a custom ClassDeactivator via apache-deltaspike.properties, but not via META-INF/services/org.apache.deltaspike.core.spi.activation.ClassDeactivator this limitation was required, because it isn't possible to deactivate/overrule a ClassDeactivator configured via the std. spi-config, but via config-sources and ordinals it's possible to overrule it. that's basically fine, but not that intuitive esp. because it's a spi for a low-level functionality - users expect a std. spi-config. therefore we should combine both or provide a corresponding hint/warning. #1 usually there is just one configured ClassDeactivator and therefore we can support both config formats easily. once there is at least one ClassDeactivator configured in apache-deltaspike.properties, we can ignore all implementations of ClassDeactivator configured via the std. spi-config. that allows to deactivate/overrule such a configuration. currently we just support one ClassDeactivator at runtime. that's limited by the config-format itself. since a std. spi-config allows multiple config-entries, we would need to use an internal instance which aggregates instances of the configured classes. #2 we just check if there is an active spi-config for 1-n implementations of ClassDeactivator and in such cases we log a warning that they are ignored and how to configure a ClassDeactivator correctly (and that only one active implementation is supported). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-853) Use @Stereotype for interface/enum discovery
[ https://issues.apache.org/jira/browse/DELTASPIKE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644129#comment-14644129 ] Gerhard Petracek commented on DELTASPIKE-853: - @daniel: please commit it for @Repository (+ test it manually - since it's just a type-safe hint for the cdi-container covered by the spec/tck, we don't need autom. tests) Use @Stereotype for interface/enum discovery Key: DELTASPIKE-853 URL: https://issues.apache.org/jira/browse/DELTASPIKE-853 Project: DeltaSpike Issue Type: Task Reporter: Jozef Hartinger Assignee: Daniel Cunha (soro) In several places DeltaSpike uses ProcessAnnotatedType to discover interfaces/enum provided by the application. These interfaces/enums are usually annotated with a marker annotation, e.g.: * @MessageBundle * @View/@Folder * @Repository * most likely others This works fine in explicit bean archives, where PAT is fired for each and every interface/enum within the archive. In CDI 1.1+ implicit bean archives, this won't work however as PAT is only fired for classes with a bean defining annotation. One option to make these extensions work in CDI 1.2 environment is to add @Stereotype to the marker annotations. -- 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: Fix Version/s: 1.4.3 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 Fix For: 1.4.3 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-853) Use @Stereotype for interface/enum discovery
[ https://issues.apache.org/jira/browse/DELTASPIKE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-853: Assignee: Daniel Cunha (soro) Use @Stereotype for interface/enum discovery Key: DELTASPIKE-853 URL: https://issues.apache.org/jira/browse/DELTASPIKE-853 Project: DeltaSpike Issue Type: Task Reporter: Jozef Hartinger Assignee: Daniel Cunha (soro) In several places DeltaSpike uses ProcessAnnotatedType to discover interfaces/enum provided by the application. These interfaces/enums are usually annotated with a marker annotation, e.g.: * @MessageBundle * @View/@Folder * @Repository * most likely others This works fine in explicit bean archives, where PAT is fired for each and every interface/enum within the archive. In CDI 1.1+ implicit bean archives, this won't work however as PAT is only fired for classes with a bean defining annotation. One option to make these extensions work in CDI 1.2 environment is to add @Stereotype to the marker annotations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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 resolved DELTASPIKE-817. - Resolution: Fixed 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 Fix For: 1.4.3 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-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: Issue Type: Improvement (was: Bug) 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: Improvement Components: Core Affects Versions: 1.2.0 Reporter: Martin Kouba Assignee: Mark Struberg Priority: Minor Fix For: 1.4.3 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-853) Use @Stereotype for interface/enum discovery
[ https://issues.apache.org/jira/browse/DELTASPIKE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-853: Assignee: Daniel Cunha (soro) (was: Gerhard Petracek) Use @Stereotype for interface/enum discovery Key: DELTASPIKE-853 URL: https://issues.apache.org/jira/browse/DELTASPIKE-853 Project: DeltaSpike Issue Type: Task Reporter: Jozef Hartinger Assignee: Daniel Cunha (soro) In several places DeltaSpike uses ProcessAnnotatedType to discover interfaces/enum provided by the application. These interfaces/enums are usually annotated with a marker annotation, e.g.: * @MessageBundle * @View/@Folder * @Repository * most likely others This works fine in explicit bean archives, where PAT is fired for each and every interface/enum within the archive. In CDI 1.1+ implicit bean archives, this won't work however as PAT is only fired for classes with a bean defining annotation. One option to make these extensions work in CDI 1.2 environment is to add @Stereotype to the marker annotations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DELTASPIKE-853) Use @Stereotype for interface/enum discovery
[ https://issues.apache.org/jira/browse/DELTASPIKE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reassigned DELTASPIKE-853: --- Assignee: Gerhard Petracek (was: Daniel Cunha (soro)) Use @Stereotype for interface/enum discovery Key: DELTASPIKE-853 URL: https://issues.apache.org/jira/browse/DELTASPIKE-853 Project: DeltaSpike Issue Type: Task Reporter: Jozef Hartinger Assignee: Gerhard Petracek In several places DeltaSpike uses ProcessAnnotatedType to discover interfaces/enum provided by the application. These interfaces/enums are usually annotated with a marker annotation, e.g.: * @MessageBundle * @View/@Folder * @Repository * most likely others This works fine in explicit bean archives, where PAT is fired for each and every interface/enum within the archive. In CDI 1.1+ implicit bean archives, this won't work however as PAT is only fired for classes with a bean defining annotation. One option to make these extensions work in CDI 1.2 environment is to add @Stereotype to the marker annotations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-966) Document ClientWindow configuration
[ https://issues.apache.org/jira/browse/DELTASPIKE-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-966: Fix Version/s: 1.4.3 Document ClientWindow configuration --- Key: DELTASPIKE-966 URL: https://issues.apache.org/jira/browse/DELTASPIKE-966 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module, JSF22-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 1.4.3 like isClientWindowStoreWindowTreeEnabled / isClientWindowTokenizedRedirectEnabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-680) Lazy init should not rely on BeanManagerProvider
[
https://issues.apache.org/jira/browse/DELTASPIKE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-680:
Fix Version/s: 1.4.3
Lazy init should not rely on BeanManagerProvider
Key: DELTASPIKE-680
URL: https://issues.apache.org/jira/browse/DELTASPIKE-680
Project: DeltaSpike
Issue Type: Improvement
Components: Data-Module
Affects Versions: 1.0.1
Reporter: Harald Wellmann
Assignee: Harald Wellmann
Fix For: 1.4.3
Trying to work with DeltaSpike Data in OSGi (with on-the-fly OSGification,
see DELTASPIKE-660), I found that things break when the TCCL is not set to
the classloader of the current repository.
This is caused by lazy initialization of {{RepositoryComponent}} using
{{BeanManagerProvider}}.
Now the current strategies of {{BeanManagerProvider}} to locate the current
{{BeanManager}} do not work in OSGi where each bundle may have its own
BeanManager and there is no obvious interpretation of current, and the TCCL
is not by default set to anything useful for this problem.
However, in the context of DeltaSpike Data, is it easy to avoid the
{{BeanManagerProvider}} even with lazy initialization. The correct
{{BeanManager}} is known when a {{RepositoryComponent}} is instantiated, so
its sufficient to keep a reference to this {{BeanManager}} to perform lazy
initialization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-680) Lazy init should not rely on BeanManagerProvider
[
https://issues.apache.org/jira/browse/DELTASPIKE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644029#comment-14644029
]
Gerhard Petracek commented on DELTASPIKE-680:
-
@harald:
please push your pull requests like that one.
Lazy init should not rely on BeanManagerProvider
Key: DELTASPIKE-680
URL: https://issues.apache.org/jira/browse/DELTASPIKE-680
Project: DeltaSpike
Issue Type: Improvement
Components: Data-Module
Affects Versions: 1.0.1
Reporter: Harald Wellmann
Assignee: Harald Wellmann
Fix For: 1.4.3
Trying to work with DeltaSpike Data in OSGi (with on-the-fly OSGification,
see DELTASPIKE-660), I found that things break when the TCCL is not set to
the classloader of the current repository.
This is caused by lazy initialization of {{RepositoryComponent}} using
{{BeanManagerProvider}}.
Now the current strategies of {{BeanManagerProvider}} to locate the current
{{BeanManager}} do not work in OSGi where each bundle may have its own
BeanManager and there is no obvious interpretation of current, and the TCCL
is not by default set to anything useful for this problem.
However, in the context of DeltaSpike Data, is it easy to avoid the
{{BeanManagerProvider}} even with lazy initialization. The correct
{{BeanManager}} is known when a {{RepositoryComponent}} is instantiated, so
its sufficient to keep a reference to this {{BeanManager}} to perform lazy
initialization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-462) BeanManagedUserTransactionStrategy closes transaction even if it is called within EJB
[ https://issues.apache.org/jira/browse/DELTASPIKE-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-462. - Resolution: Cannot Reproduce BeanManagedUserTransactionStrategy closes transaction even if it is called within EJB - Key: DELTASPIKE-462 URL: https://issues.apache.org/jira/browse/DELTASPIKE-462 Project: DeltaSpike Issue Type: Bug Components: JPA-Module Affects Versions: 0.5 Reporter: Mark Struberg Assignee: Mark Struberg Happens if BeanManagedUserTransactionStrategy is used. If a @Stateless EJB invokes a @Transactional CDI bean then the UserTransaction is already open. In this case our TransactionStrategy must not commit the EntityTransaction but leave it to the outer EJB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-605) discuss manual interceptor implementation
[ https://issues.apache.org/jira/browse/DELTASPIKE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644038#comment-14644038 ] Gerhard Petracek commented on DELTASPIKE-605: - it isn't possible to add e.g. mocked beans which use interceptors. some months ago mark thought about a new feature which would require interceptors for manually added BeanT instances as well. with partial-beans we support the most important use-case, however, interceptor-support for (custom) BeanT would be great for (advanced) users. 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 BeanT, InjectionTargetT and ProducerT, we should think about a manual interceptor implementation for them. with that we could support interceptors e.g. for BeanT 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-813) improve basic core documentation
[ https://issues.apache.org/jira/browse/DELTASPIKE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-813: Assignee: Rafael Benevides (was: Ron Smeral) improve basic core documentation Key: DELTASPIKE-813 URL: https://issues.apache.org/jira/browse/DELTASPIKE-813 Project: DeltaSpike Issue Type: Task Components: Documentation Affects Versions: 1.2.1 Reporter: Gerhard Petracek Assignee: Rafael Benevides Fix For: 1.5.0 in this first step we should improve everything which is marked red or yellow in the documentation column and green or yellow in the importance for average users column ( see https://cwiki.apache.org/confluence/display/DeltaSpike/DS-Core+Overview ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-688) OSGi Support for DeltaSpike JSF and its dependencies
[ https://issues.apache.org/jira/browse/DELTASPIKE-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-688: Assignee: Harald Wellmann (was: Charles Moulliard) OSGi Support for DeltaSpike JSF and its dependencies Key: DELTASPIKE-688 URL: https://issues.apache.org/jira/browse/DELTASPIKE-688 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module, Security-Module Affects Versions: 1.0.1 Reporter: Harald Wellmann Assignee: Harald Wellmann Goal: Users can work with DeltaSpike JSF in OSGi applications, using Pax CDI. This includes adding OSGi support to DeltaSpike Security, a runtime dependency of DeltaSpike JSF. (Actually, I think this indicates the JSF module is not modular enough, but that's a different story. JSF should not depend on security at all.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-645) review sonar findings
[ https://issues.apache.org/jira/browse/DELTASPIKE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-645: Assignee: Rafael Benevides (was: Matt Benson) review sonar findings - Key: DELTASPIKE-645 URL: https://issues.apache.org/jira/browse/DELTASPIKE-645 Project: DeltaSpike Issue Type: Task Affects Versions: 1.0.0 Reporter: Gerhard Petracek Assignee: Rafael Benevides Fix For: 1.5.0 a lot of the sonar findings are wrong, because sonar isn't aware of cdi and there are still some old rules in there. however, we should review the findings on a regular basis. see http://deltaspike.apache.org/build.html#sonar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-897) check configuration of a ClassDeactivator
[ https://issues.apache.org/jira/browse/DELTASPIKE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-897: Summary: check configuration of a ClassDeactivator (was: discuss configuration of a ClassDeactivator) check configuration of a ClassDeactivator - Key: DELTASPIKE-897 URL: https://issues.apache.org/jira/browse/DELTASPIKE-897 Project: DeltaSpike Issue Type: Task Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.3 currently it's needed to configure a custom ClassDeactivator via apache-deltaspike.properties, but not via META-INF/services/org.apache.deltaspike.core.spi.activation.ClassDeactivator this limitation was required, because it isn't possible to deactivate/overrule a ClassDeactivator configured via the std. spi-config, but via config-sources and ordinals it's possible to overrule it. that's basically fine, but not that intuitive esp. because it's a spi for a low-level functionality - users expect a std. spi-config. therefore we should combine both or provide a corresponding hint/warning. #1 usually there is just one configured ClassDeactivator and therefore we can support both config formats easily. once there is at least one ClassDeactivator configured in apache-deltaspike.properties, we can ignore all implementations of ClassDeactivator configured via the std. spi-config. that allows to deactivate/overrule such a configuration. currently we just support one ClassDeactivator at runtime. that's limited by the config-format itself. since a std. spi-config allows multiple config-entries, we would need to use an internal instance which aggregates instances of the configured classes. #2 we just check if there is an active spi-config for 1-n implementations of ClassDeactivator and in such cases we log a warning that they are ignored and how to configure a ClassDeactivator correctly (and that only one active implementation is supported). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-942) DeltaSpike fails to start with corrupted persistence.xml file.
[
https://issues.apache.org/jira/browse/DELTASPIKE-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-942:
Issue Type: Improvement (was: Bug)
DeltaSpike fails to start with corrupted persistence.xml file.
--
Key: DELTASPIKE-942
URL: https://issues.apache.org/jira/browse/DELTASPIKE-942
Project: DeltaSpike
Issue Type: Improvement
Components: Data-Module
Affects Versions: 1.4.1
Environment: * Java version: 1.8.0_40, vendor: Oracle Corporation
* Windows 7 Enterprise
* Apache Maven 3.2.3
Reporter: Grzegorz Demecki
Assignee: Daniel Cunha (soro)
Labels: easyfix
Attachments: DELTASPIKE-942-bug-showcase.zip
h4. Details
Please see attached sample web application and run it via:
{code} mvn clean compile jetty:run {code}
At startup we can see huge stack trace that tells literally nothing.
{code:java}
2015-07-01 16:38:50.076:WARN:oeja.ServletContainerInitializersStarter:main:
org.jboss.weld.exceptions.DefinitionException: Exception List with 1
exceptions:|Exception 0 :|java.lang.RuntimeException: Failed initializing
mapping files
at
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.extractMappings(PersistenceUnitReader.java:82)
at
org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.lookupUnits(PersistenceUnitReader.java:54)
...
{code}
Whereas the exception should look like:
{code:java}
javax.servlet.ServletException: Caused by:
javax.persistence.PersistenceException: [PersistenceUnit: netadminPU] Unable
to resolve named mapping-file [META-INF/jpql/named-queries.xml]
{code}
_Because corruption is about pointing out to a not-existing mapping file
named {{named-queries.xml}}_
h4. Known workarounds
# Of course we can fix the corrupted {{persistence.xml}} file, by removing
line:
{{mapping-fileMETA-INF/jpql/named-queries.xml/mapping-file}}
# We can also remove dependency to deltaspike-data from {{pom.xml}} as it
solves the issue
Because then we got perfectly clear and correct message that tells us what
is wrong with {{persistene.xml}}.
For further details, please see file *README.md* inside attached application.
BTW: Why does the DeltaSpike parse persistence.xml at application startup?
Shouldn't this file be parsed with a lazy manner, at first usage of the
EntityManagerFactory?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-897) check configuration of a ClassDeactivator
[ https://issues.apache.org/jira/browse/DELTASPIKE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-897: Issue Type: Improvement (was: Task) check configuration of a ClassDeactivator - Key: DELTASPIKE-897 URL: https://issues.apache.org/jira/browse/DELTASPIKE-897 Project: DeltaSpike Issue Type: Improvement Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.3 currently it's needed to configure a custom ClassDeactivator via apache-deltaspike.properties, but not via META-INF/services/org.apache.deltaspike.core.spi.activation.ClassDeactivator this limitation was required, because it isn't possible to deactivate/overrule a ClassDeactivator configured via the std. spi-config, but via config-sources and ordinals it's possible to overrule it. that's basically fine, but not that intuitive esp. because it's a spi for a low-level functionality - users expect a std. spi-config. therefore we should combine both or provide a corresponding hint/warning. #1 usually there is just one configured ClassDeactivator and therefore we can support both config formats easily. once there is at least one ClassDeactivator configured in apache-deltaspike.properties, we can ignore all implementations of ClassDeactivator configured via the std. spi-config. that allows to deactivate/overrule such a configuration. currently we just support one ClassDeactivator at runtime. that's limited by the config-format itself. since a std. spi-config allows multiple config-entries, we would need to use an internal instance which aggregates instances of the configured classes. #2 we just check if there is an active spi-config for 1-n implementations of ClassDeactivator and in such cases we log a warning that they are ignored and how to configure a ClassDeactivator correctly (and that only one active implementation is supported). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (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 closed DELTASPIKE-943. --- 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-897) check configuration of a ClassDeactivator
[ https://issues.apache.org/jira/browse/DELTASPIKE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-897. - Resolution: Fixed check configuration of a ClassDeactivator - Key: DELTASPIKE-897 URL: https://issues.apache.org/jira/browse/DELTASPIKE-897 Project: DeltaSpike Issue Type: Task Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.3 currently it's needed to configure a custom ClassDeactivator via apache-deltaspike.properties, but not via META-INF/services/org.apache.deltaspike.core.spi.activation.ClassDeactivator this limitation was required, because it isn't possible to deactivate/overrule a ClassDeactivator configured via the std. spi-config, but via config-sources and ordinals it's possible to overrule it. that's basically fine, but not that intuitive esp. because it's a spi for a low-level functionality - users expect a std. spi-config. therefore we should combine both or provide a corresponding hint/warning. #1 usually there is just one configured ClassDeactivator and therefore we can support both config formats easily. once there is at least one ClassDeactivator configured in apache-deltaspike.properties, we can ignore all implementations of ClassDeactivator configured via the std. spi-config. that allows to deactivate/overrule such a configuration. currently we just support one ClassDeactivator at runtime. that's limited by the config-format itself. since a std. spi-config allows multiple config-entries, we would need to use an internal instance which aggregates instances of the configured classes. #2 we just check if there is an active spi-config for 1-n implementations of ClassDeactivator and in such cases we log a warning that they are ignored and how to configure a ClassDeactivator correctly (and that only one active implementation is supported). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-965) EntityRepository.save() is broken for entities with String ID
[
https://issues.apache.org/jira/browse/DELTASPIKE-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643078#comment-14643078
]
Gerhard Petracek commented on DELTASPIKE-965:
-
@harald:
as a ds-committer you don't need to use pull-requests.
commit it directly or if you aren't sure about it, push it to your own fork -
just provide the link (and you can skip the pull-request itself).
EntityRepository.save() is broken for entities with String ID
-
Key: DELTASPIKE-965
URL: https://issues.apache.org/jira/browse/DELTASPIKE-965
Project: DeltaSpike
Issue Type: Bug
Components: Data-Module
Affects Versions: 1.4.2
Reporter: Harald Wellmann
Assignee: Daniel Cunha (soro)
Priority: Blocker
Fix For: 1.4.3
EntityRepository.save() generates illegal SQL when the entity identity is of
String type.
This is a regression introduced in 1.4.2 with
{{org.apache.deltaspike.data.impl.handler.CdiQueryInvocationContext.countCheck(Object)}}.
--
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] [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] [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-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-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) MapClassLoader, PersistenceInfo which also looks up the parent ClassLodaer chain. -- 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 BeanT, InjectionTargetT and ProducerT, we should think about a manual interceptor implementation for them. with that we could support interceptors e.g. for BeanT 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-960) WindowIdHtmlRenderer needs to use maxWindowIdCount for window-id cookies
[ https://issues.apache.org/jira/browse/DELTASPIKE-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-960: Reporter: Ortwin Escher (was: Gerhard Petracek) WindowIdHtmlRenderer needs to use maxWindowIdCount for window-id cookies Key: DELTASPIKE-960 URL: https://issues.apache.org/jira/browse/DELTASPIKE-960 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 1.4.1 Reporter: Ortwin Escher Fix For: 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-960) WindowIdHtmlRenderer needs to use maxWindowIdCount for window-id cookies
Gerhard Petracek created DELTASPIKE-960: --- Summary: WindowIdHtmlRenderer needs to use maxWindowIdCount for window-id cookies Key: DELTASPIKE-960 URL: https://issues.apache.org/jira/browse/DELTASPIKE-960 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 1.4.1 Reporter: Gerhard Petracek Fix For: 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-951) validate the content of TestControl#startScopes
[ https://issues.apache.org/jira/browse/DELTASPIKE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-951: Fix Version/s: (was: 1.5.0) 1.4.2 validate the content of TestControl#startScopes --- Key: DELTASPIKE-951 URL: https://issues.apache.org/jira/browse/DELTASPIKE-951 Project: DeltaSpike Issue Type: Improvement Components: TestControl Affects Versions: 1.4.2 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.2 a lot of users use it the wrong way - we should validate it and fail fast in case of a wrong usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DELTASPIKE-957) Improve how TransactionStrategies are looked up
[ https://issues.apache.org/jira/browse/DELTASPIKE-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek closed DELTASPIKE-957. --- Improve how TransactionStrategies are looked up --- Key: DELTASPIKE-957 URL: https://issues.apache.org/jira/browse/DELTASPIKE-957 Project: DeltaSpike Issue Type: New Feature Components: Data-Module, Documentation, JPA-Module Affects Versions: 1.4.1 Reporter: John D. Ament Currently transaction strategies are implemented as alternatives. I created a WAR for WildFly 9, and ran into a lot of issues getting it to work. My WAR has many JARs in it, all with beans.xml files. I tried to enable the alternative in various spots, but no luck, even went through all 30 beans.xml files in my project and enabled it. Still went with the default transaction strategy. In order to fix, I had to enable a global alternative with the strategy. This seems to go against our docs, which indicate it should be a regular alternative. I'd recommend a few things to think about. - Expect a concrete producer. - Use a class look up in apache-deltaspike.properties -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-951) validate the content of TestControl#startScopes
[ https://issues.apache.org/jira/browse/DELTASPIKE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-951. - Resolution: Fixed validate the content of TestControl#startScopes --- Key: DELTASPIKE-951 URL: https://issues.apache.org/jira/browse/DELTASPIKE-951 Project: DeltaSpike Issue Type: Improvement Components: TestControl Affects Versions: 1.4.2 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.2 a lot of users use it the wrong way - we should validate it and fail fast in case of a wrong usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-960) WindowIdHtmlRenderer needs to use maxWindowIdCount for window-id cookies
[ https://issues.apache.org/jira/browse/DELTASPIKE-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-960. - Resolution: Fixed WindowIdHtmlRenderer needs to use maxWindowIdCount for window-id cookies Key: DELTASPIKE-960 URL: https://issues.apache.org/jira/browse/DELTASPIKE-960 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 1.4.1 Reporter: Gerhard Petracek Fix For: 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-933) Upgrade to Arquillian 1.1.8.Final
[ https://issues.apache.org/jira/browse/DELTASPIKE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-933: Component/s: Build Upgrade to Arquillian 1.1.8.Final - Key: DELTASPIKE-933 URL: https://issues.apache.org/jira/browse/DELTASPIKE-933 Project: DeltaSpike Issue Type: Improvement Components: Build Affects Versions: 1.4.0 Reporter: Harald Wellmann Assignee: Harald Wellmann Fix For: 1.4.2 This upgrade should make tests with broken deployments fail. With 1.1.4, tests from broken deployments silently do not get run, without failing the build. See DELTASPIKE-929. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-958) remove outdated information
[ https://issues.apache.org/jira/browse/DELTASPIKE-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-958: Component/s: Documentation Build remove outdated information --- Key: DELTASPIKE-958 URL: https://issues.apache.org/jira/browse/DELTASPIKE-958 Project: DeltaSpike Issue Type: Bug Components: Build, Documentation Affects Versions: 1.4.1 Reporter: Gerhard Petracek Priority: Minor Fix For: 1.4.2 we are still adding e.g. the incubator-disclaimer -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-934) @Query metadata should be considered for any method expression
[ https://issues.apache.org/jira/browse/DELTASPIKE-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632910#comment-14632910 ] Gerhard Petracek commented on DELTASPIKE-934: - @john: see https://git1-us-west.apache.org/repos/asf?p=deltaspike.git;a=commit;h=687e57e8 @Query metadata should be considered for any method expression -- Key: DELTASPIKE-934 URL: https://issues.apache.org/jira/browse/DELTASPIKE-934 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Affects Versions: 1.4.0 Reporter: Daniel Cunha (soro) Assignee: Daniel Cunha (soro) Fix For: 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-936) OSGi capability cleanup
[
https://issues.apache.org/jira/browse/DELTASPIKE-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-936:
Fix Version/s: (was: 1.4.2)
1.4.3
OSGi capability cleanup
---
Key: DELTASPIKE-936
URL: https://issues.apache.org/jira/browse/DELTASPIKE-936
Project: DeltaSpike
Issue Type: Improvement
Affects Versions: 1.4.1
Reporter: Harald Wellmann
Assignee: Harald Wellmann
Fix For: 1.4.3
OSGi capabilities and requirements are somewhat inconsistent at the moment.
{noformat}
osgi.extender; filter:=(osgi.extender=pax.cdi)
{noformat}
must be required by all modules providing CDI beans.
{noformat}
org.ops4j.pax.cdi.extension; filter:=(extension=pax-cdi-extension)
{noformat}
is not required, since DeltaSpike modules do not provide or consume OSGi
services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-961) prepare v1.4.2
[ https://issues.apache.org/jira/browse/DELTASPIKE-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-961. - Resolution: Fixed prepare v1.4.2 -- Key: DELTASPIKE-961 URL: https://issues.apache.org/jira/browse/DELTASPIKE-961 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-929) Weld test profile is broken
[
https://issues.apache.org/jira/browse/DELTASPIKE-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-929:
Component/s: Build
Weld test profile is broken
---
Key: DELTASPIKE-929
URL: https://issues.apache.org/jira/browse/DELTASPIKE-929
Project: DeltaSpike
Issue Type: Bug
Components: Build
Affects Versions: 1.4.0
Reporter: Harald Wellmann
Assignee: Harald Wellmann
Fix For: 1.4.2
The Weld test profile is broken, see e.g.
https://builds.apache.org/view/All/job/DeltaSpike%20Weld%201.1.28/4/consoleFull
The following exception causes most tests to be skipped without being
reported as failure:
{noformat}
Caused by: java.lang.ClassNotFoundException:
org.jboss.weld.manager.api.WeldManager
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 47 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-931) Integration tests fail when dependencies are class folders, not JARs
[
https://issues.apache.org/jira/browse/DELTASPIKE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-931:
Component/s: Tests
Integration tests fail when dependencies are class folders, not JARs
Key: DELTASPIKE-931
URL: https://issues.apache.org/jira/browse/DELTASPIKE-931
Project: DeltaSpike
Issue Type: Bug
Components: Tests
Affects Versions: 1.4.0
Reporter: Harald Wellmann
Assignee: Harald Wellmann
Fix For: 1.4.2
Arquillian-based tests fail when run from Eclipse, e.g.
{{org.apache.deltaspike.test.core.api.alternative.global.GlobalAlternativeTest}}
{noformat}
java.lang.IllegalStateException: Could not find beans for Type=class
org.apache.deltaspike.core.impl.scope.window.WindowBeanHolder and
qualifiers:[]
at
org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:153)
at
org.apache.deltaspike.core.impl.scope.DeltaSpikeContextExtension.initializeDeltaSpikeContexts(DeltaSpikeContextExtension.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:266)
at
org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:482)
at
org.apache.webbeans.container.BeanManagerImpl.fireEvent(BeanManagerImpl.java:446)
at
org.apache.webbeans.container.BeanManagerImpl.fireLifecycleEvent(BeanManagerImpl.java:436)
at
org.apache.webbeans.config.BeansDeployer.fireAfterDeploymentValidationEvent(BeansDeployer.java:374)
at
org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:205)
at
org.apache.webbeans.lifecycle.AbstractLifeCycle.bootstrapApplication(AbstractLifeCycle.java:141)
at
org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:107)
at
org.apache.webbeans.arquillian.standalone.OwbStandaloneContainer.deploy(OwbStandaloneContainer.java:122)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
[jira] [Updated] (DELTASPIKE-887) ds:windowId should initialize the windowhandler script
[ https://issues.apache.org/jira/browse/DELTASPIKE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-887: Component/s: JSF-Module ds:windowId should initialize the windowhandler script -- Key: DELTASPIKE-887 URL: https://issues.apache.org/jira/browse/DELTASPIKE-887 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 1.3.0 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 1.4.2 Currently the windowhandler will be initialized with window.onload but if the user defined an onload attribute on the body, the js version will be ignored. This requires an bigger refactoring on the client side, therefore i will fix in the future when developing the new mixed mode between LAZY/CLIENT_WINDOW. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-921) OSGi support for Servlet Module
[ https://issues.apache.org/jira/browse/DELTASPIKE-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-921: Fix Version/s: (was: 1.4.2) 1.4.3 OSGi support for Servlet Module --- Key: DELTASPIKE-921 URL: https://issues.apache.org/jira/browse/DELTASPIKE-921 Project: DeltaSpike Issue Type: New Feature Components: Servlet-Module Affects Versions: 1.4.0 Reporter: Harald Wellmann Assignee: Harald Wellmann Fix For: 1.4.3 Goal: Users can work with DeltaSpike Servlet in OSGi applications, using Pax CDI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-897) discuss configuration of a ClassDeactivator
[ https://issues.apache.org/jira/browse/DELTASPIKE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-897: Fix Version/s: (was: 1.4.2) 1.5.0 discuss configuration of a ClassDeactivator --- Key: DELTASPIKE-897 URL: https://issues.apache.org/jira/browse/DELTASPIKE-897 Project: DeltaSpike Issue Type: Task Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.5.0 currently it's needed to configure a custom ClassDeactivator via apache-deltaspike.properties, but not via META-INF/services/org.apache.deltaspike.core.spi.activation.ClassDeactivator this limitation was required, because it isn't possible to deactivate/overrule a ClassDeactivator configured via the std. spi-config, but via config-sources and ordinals it's possible to overrule it. that's basically fine, but not that intuitive esp. because it's a spi for a low-level functionality - users expect a std. spi-config. therefore we should combine both or provide a corresponding hint/warning. #1 usually there is just one configured ClassDeactivator and therefore we can support both config formats easily. once there is at least one ClassDeactivator configured in apache-deltaspike.properties, we can ignore all implementations of ClassDeactivator configured via the std. spi-config. that allows to deactivate/overrule such a configuration. currently we just support one ClassDeactivator at runtime. that's limited by the config-format itself. since a std. spi-config allows multiple config-entries, we would need to use an internal instance which aggregates instances of the configured classes. #2 we just check if there is an active spi-config for 1-n implementations of ClassDeactivator and in such cases we log a warning that they are ignored and how to configure a ClassDeactivator correctly (and that only one active implementation is supported). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-645) review sonar findings
[ https://issues.apache.org/jira/browse/DELTASPIKE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-645: Fix Version/s: (was: 1.4.2) 1.5.0 review sonar findings - Key: DELTASPIKE-645 URL: https://issues.apache.org/jira/browse/DELTASPIKE-645 Project: DeltaSpike Issue Type: Task Affects Versions: 1.0.0 Reporter: Gerhard Petracek Assignee: Matt Benson Fix For: 1.5.0 a lot of the sonar findings are wrong, because sonar isn't aware of cdi and there are still some old rules in there. however, we should review the findings on a regular basis. see http://deltaspike.apache.org/build.html#sonar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-724) upgrade version of the tomee-arquillian adapter
[ https://issues.apache.org/jira/browse/DELTASPIKE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-724: Fix Version/s: (was: 1.4.2) 1.5.0 upgrade version of the tomee-arquillian adapter --- Key: DELTASPIKE-724 URL: https://issues.apache.org/jira/browse/DELTASPIKE-724 Project: DeltaSpike Issue Type: Task Components: Build, Tests Reporter: Gerhard Petracek Assignee: Romain Manni-Bucau Fix For: 1.5.0 to test against tomee 1.7.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-440) discuss helper for adding deployment-problems
[ https://issues.apache.org/jira/browse/DELTASPIKE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-440: Fix Version/s: (was: 1.4.2) 1.5.0 discuss helper for adding deployment-problems - Key: DELTASPIKE-440 URL: https://issues.apache.org/jira/browse/DELTASPIKE-440 Project: DeltaSpike Issue Type: Task Components: Core Reporter: Gerhard Petracek Assignee: Rafael Benevides Fix For: 1.5.0 in many cases it's possible to detect deployment-problems before AfterDeploymentValidation. it's possible to throw an exception at any time, however, it might be useful to unify it. e.g. collecting problems via a helper which adds all issues via AfterDeploymentValidation#addDeploymentProblem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-872) Support mocking on proxied beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-872: Fix Version/s: (was: 1.4.2) 1.5.0 Support mocking on proxied beans Key: DELTASPIKE-872 URL: https://issues.apache.org/jira/browse/DELTASPIKE-872 Project: DeltaSpike Issue Type: Improvement Components: TestControl Affects Versions: 1.3.0 Reporter: Rafael Assignee: Thomas Andraschko Fix For: 1.5.0 Currently test control mock feature is not supported on proxies (e.g: beans with interceptors), a sample test which fails because of this limitation can be found here: https://github.com/rmpestano/ee6-ds-demo/blob/master/src/test/java/org/os890/demo/ee6/test/MockTest.java . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-813) improve basic core documentation
[ https://issues.apache.org/jira/browse/DELTASPIKE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-813: Fix Version/s: (was: 1.4.2) 1.5.0 improve basic core documentation Key: DELTASPIKE-813 URL: https://issues.apache.org/jira/browse/DELTASPIKE-813 Project: DeltaSpike Issue Type: Task Components: Documentation Affects Versions: 1.2.1 Reporter: Gerhard Petracek Assignee: Ron Smeral Fix For: 1.5.0 in this first step we should improve everything which is marked red or yellow in the documentation column and green or yellow in the importance for average users column ( see https://cwiki.apache.org/confluence/display/DeltaSpike/DS-Core+Overview ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-957) Improve how TransactionStrategies are looked up
[ https://issues.apache.org/jira/browse/DELTASPIKE-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-957. - Resolution: Not A Problem @john: if you don't agree with the arguments we provided (for keeping it as it is), please start a [discuss]-thread on the mailing-list (before we open this ticket again). if you think that the documentation isn't clear enough about this topic, you are very welcome to improve the documentation. Improve how TransactionStrategies are looked up --- Key: DELTASPIKE-957 URL: https://issues.apache.org/jira/browse/DELTASPIKE-957 Project: DeltaSpike Issue Type: New Feature Components: Data-Module, Documentation, JPA-Module Affects Versions: 1.4.1 Reporter: John D. Ament Currently transaction strategies are implemented as alternatives. I created a WAR for WildFly 9, and ran into a lot of issues getting it to work. My WAR has many JARs in it, all with beans.xml files. I tried to enable the alternative in various spots, but no luck, even went through all 30 beans.xml files in my project and enabled it. Still went with the default transaction strategy. In order to fix, I had to enable a global alternative with the strategy. This seems to go against our docs, which indicate it should be a regular alternative. I'd recommend a few things to think about. - Expect a concrete producer. - Use a class look up in apache-deltaspike.properties -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-957) Improve how TransactionStrategies are looked up
[ https://issues.apache.org/jira/browse/DELTASPIKE-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-957. - Resolution: Not A Problem i just tested it with globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.EnvironmentAwareTransactionStrategy on as7, wf8 and wf9. it worked with all of them. Improve how TransactionStrategies are looked up --- Key: DELTASPIKE-957 URL: https://issues.apache.org/jira/browse/DELTASPIKE-957 Project: DeltaSpike Issue Type: New Feature Components: Data-Module, Documentation, JPA-Module Affects Versions: 1.4.1 Reporter: John D. Ament Currently transaction strategies are implemented as alternatives. I created a WAR for WildFly 9, and ran into a lot of issues getting it to work. My WAR has many JARs in it, all with beans.xml files. I tried to enable the alternative in various spots, but no luck, even went through all 30 beans.xml files in my project and enabled it. Still went with the default transaction strategy. In order to fix, I had to enable a global alternative with the strategy. This seems to go against our docs, which indicate it should be a regular alternative. I'd recommend a few things to think about. - Expect a concrete producer. - Use a class look up in apache-deltaspike.properties -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-957) Improve how TransactionStrategies are looked up
[ https://issues.apache.org/jira/browse/DELTASPIKE-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14627744#comment-14627744 ] Gerhard Petracek commented on DELTASPIKE-957: - please try it with our global alternative feature (as documented). the bda-rule-interpretation in weld based servers was the only reason for that feature. Improve how TransactionStrategies are looked up --- Key: DELTASPIKE-957 URL: https://issues.apache.org/jira/browse/DELTASPIKE-957 Project: DeltaSpike Issue Type: New Feature Components: Data-Module, Documentation, JPA-Module Affects Versions: 1.4.1 Reporter: John D. Ament Currently transaction strategies are implemented as alternatives. I created a WAR for WildFly 9, and ran into a lot of issues getting it to work. My WAR has many JARs in it, all with beans.xml files. I tried to enable the alternative in various spots, but no luck, even went through all 30 beans.xml files in my project and enabled it. Still went with the default transaction strategy. In order to fix, I had to enable a global alternative with the strategy. This seems to go against our docs, which indicate it should be a regular alternative. I'd recommend a few things to think about. - Expect a concrete producer. - Use a class look up in apache-deltaspike.properties -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-958) remove outdated information
[ https://issues.apache.org/jira/browse/DELTASPIKE-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-958. - Resolution: Fixed remove outdated information --- Key: DELTASPIKE-958 URL: https://issues.apache.org/jira/browse/DELTASPIKE-958 Project: DeltaSpike Issue Type: Bug Affects Versions: 1.4.1 Reporter: Gerhard Petracek Priority: Minor Fix For: 1.4.2 we are still adding e.g. the incubator-disclaimer -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (DELTASPIKE-830) Now active ViewAccessScoped context during restore view phase
[ https://issues.apache.org/jira/browse/DELTASPIKE-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reopened DELTASPIKE-830: - Now active ViewAccessScoped context during restore view phase - Key: DELTASPIKE-830 URL: https://issues.apache.org/jira/browse/DELTASPIKE-830 Project: DeltaSpike Issue Type: Bug Components: JSF-Module Affects Versions: 1.2.1 Environment: Glassfish 3.1.2.2 and Weblogic 12.1.2.2 Reporter: Nuno G. de M Assignee: Thomas Andraschko Fix For: 1.4.2 While testing delta-spike in clientview mode, coming from CODI, we have one view that is giving problems trying to access ViewAccessScoped beans during the restored view phase. Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.ViewAccessScoped Namely the exception we get in our page is the following: Caused By: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.ViewAccessScoped at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:590) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79) at com.corp.whatever.component.ui.web.CR100Bean$Proxy$_$$_WeldClientProxy.getPageIds(CR100Bean$Proxy$_$$_WeldClientProxy.java) at sun.reflect.GeneratedMethodAccessor1663.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at javax.el.BeanELResolver.getValue(BeanELResolver.java:305) at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) at com.sun.el.parser.AstValue.getValue(AstValue.java:138) at com.sun.el.parser.AstValue.getValue(AstValue.java:183) at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:99) at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) at com.sun.faces.facelets.tag.jstl.core.SetHandler.apply(SetHandler.java:163) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:187) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95) at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:188) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93) at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:320) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:379) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:358) at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199) at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:155) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93) at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:320) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:379) at
[jira] [Created] (DELTASPIKE-958) remove outdated information
Gerhard Petracek created DELTASPIKE-958: --- Summary: remove outdated information Key: DELTASPIKE-958 URL: https://issues.apache.org/jira/browse/DELTASPIKE-958 Project: DeltaSpike Issue Type: Bug Affects Versions: 1.4.1 Reporter: Gerhard Petracek Priority: Minor Fix For: 1.4.2 we are still adding e.g. the incubator-disclaimer -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-957) Improve how TransactionStrategies are looked up
[ https://issues.apache.org/jira/browse/DELTASPIKE-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628193#comment-14628193 ] Gerhard Petracek commented on DELTASPIKE-957: - container managed EMs aren't the default in ds and you end up in almost the same with a producer. if you have the config-entry globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.EnvironmentAwareTransactionStrategy or org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.EnvironmentAwareTransactionStrategy is in the end the same for users. *you need to read the docs* - add a config-entry if you like to change the default handling. the way we handle it is around for a long time (in ds and even before - since codi did the same). Improve how TransactionStrategies are looked up --- Key: DELTASPIKE-957 URL: https://issues.apache.org/jira/browse/DELTASPIKE-957 Project: DeltaSpike Issue Type: New Feature Components: Data-Module, Documentation, JPA-Module Affects Versions: 1.4.1 Reporter: John D. Ament Currently transaction strategies are implemented as alternatives. I created a WAR for WildFly 9, and ran into a lot of issues getting it to work. My WAR has many JARs in it, all with beans.xml files. I tried to enable the alternative in various spots, but no luck, even went through all 30 beans.xml files in my project and enabled it. Still went with the default transaction strategy. In order to fix, I had to enable a global alternative with the strategy. This seems to go against our docs, which indicate it should be a regular alternative. I'd recommend a few things to think about. - Expect a concrete producer. - Use a class look up in apache-deltaspike.properties -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-951) validate the content of TestControl#startScopes
Gerhard Petracek created DELTASPIKE-951: --- Summary: validate the content of TestControl#startScopes Key: DELTASPIKE-951 URL: https://issues.apache.org/jira/browse/DELTASPIKE-951 Project: DeltaSpike Issue Type: Improvement Components: TestControl Affects Versions: 1.4.2 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.5.0 a lot of users use it the wrong way - we should validate it and fail fast in case of a wrong usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DELTASPIKE-935) ds:disableClientWindow should also disable JSF 2.2 rendering mode
[ https://issues.apache.org/jira/browse/DELTASPIKE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14614725#comment-14614725 ] Gerhard Petracek edited comment on DELTASPIKE-935 at 7/6/15 2:05 PM: - we need to re-visit if the refactored code for this ticket breaks deltaspike-jsf-module-impl-ee6 was (Author: gpetracek): the refactored code for this ticket breaks deltaspike-jsf-module-impl-ee6 ds:disableClientWindow should also disable JSF 2.2 rendering mode - Key: DELTASPIKE-935 URL: https://issues.apache.org/jira/browse/DELTASPIKE-935 Project: DeltaSpike Issue Type: Bug Components: JSF-Module, JSF22-Module Affects Versions: 1.4.1 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 1.4.2 to prevent jfwid on URLs with Mojarra -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DELTASPIKE-871) save() and findByxxx() in same transaction gives constraint violation exception
[ https://issues.apache.org/jira/browse/DELTASPIKE-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek closed DELTASPIKE-871. --- save() and findByxxx() in same transaction gives constraint violation exception --- Key: DELTASPIKE-871 URL: https://issues.apache.org/jira/browse/DELTASPIKE-871 Project: DeltaSpike Issue Type: Bug Components: Data-Module Affects Versions: 1.2.0 Environment: Windows-7, Java-8, Netbeans-8.0.2 Reporter: Md Kamaruzzaman Assignee: Daniel Cunha (soro) It seems like when in the same EJB transaction, save() and findByxxx() is called, then delta-spike inserts the entity twice [once in save() and other time in findByxxx()] and gives a constraint violation exception. After some debuggin, it seems like save() gives a INSERT query in DB and findByxxx() method calls a flush which again gives the same INSERT query in DB [INSERT query from save() is not removed from EntityManager] and gives constraint violation exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DELTASPIKE-938) Enable the use of slf4j for logging without jul2slf4j-bridge
[ https://issues.apache.org/jira/browse/DELTASPIKE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek closed DELTASPIKE-938. --- Enable the use of slf4j for logging without jul2slf4j-bridge Key: DELTASPIKE-938 URL: https://issues.apache.org/jira/browse/DELTASPIKE-938 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 1.4.1 Reporter: Jörg Sesterhenn As a developer i want to use slf4j in my application to be able to choose an loggingimplementation at a later point in time. deltaspike should suport this without having me use the jul2slf4j brigde wich has performance warnings attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (DELTASPIKE-883) Create a new module for proxy
[ https://issues.apache.org/jira/browse/DELTASPIKE-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reopened DELTASPIKE-883: - Create a new module for proxy - Key: DELTASPIKE-883 URL: https://issues.apache.org/jira/browse/DELTASPIKE-883 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 1.3.0, 1.4.0 Reporter: Rafael Benevides Assignee: Rafael Benevides Priority: Blocker Fix For: 1.4.1 We are now using asm to create our own proxies - with 1.3.0 that was added to the partial bean module - now We replace the optional proxies created in the JSF module for converters/validators with the same approach - the proxy code was moved to ds-core. that works but isn't nice and not that flexible - the goal is an own module side by side with core and all modules which need proxy stuff have core and that new proxy module as dep. (currently the partial-bean and JSF module).It allows to support different versions of asm once it's needed... (e.g. for diff. versions of java if the latest version drops e.g. backward compat. to and old version...) It's already discussed and agreed on the dev list so you can just create a ticket and just move the code + update the release poms so that the new module is part of the release as well... The new module should be called proxy-utils. GAV: org.apache.deltaspike.modules:deltaspike-proxy-module-api *don't* move org.apache.deltaspike.core.util.ProxyUtils - because it doesn't depend on asm and is valid for any proxy (weld-proxy, owb-proxy, javassist-proxy,...) We support at all + it's needed a lot in ds-core. If you would move it ds-core would depend on the proxy-module (which shouldn't be the case). The goal is really that the proxy-module is just needed once you need the partial-bean module and/or the optional proxies in the JSF module so the proxy-module needs to be an optional dep. of the JSF module... but in case of the partial-bean module the proxy-api module is a compile dep. since it's required anyway That's currently the release blocker, because now ds-core has a dependency to a fixed version of asm and so far Core didn't introduce a 3rd party dep. So We need to move to the new module before the next release... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DELTASPIKE-883) Create a new module for proxy
[ https://issues.apache.org/jira/browse/DELTASPIKE-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek closed DELTASPIKE-883. --- Resolution: Duplicate Create a new module for proxy - Key: DELTASPIKE-883 URL: https://issues.apache.org/jira/browse/DELTASPIKE-883 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 1.3.0, 1.4.0 Reporter: Rafael Benevides Assignee: Rafael Benevides Priority: Blocker We are now using asm to create our own proxies - with 1.3.0 that was added to the partial bean module - now We replace the optional proxies created in the JSF module for converters/validators with the same approach - the proxy code was moved to ds-core. that works but isn't nice and not that flexible - the goal is an own module side by side with core and all modules which need proxy stuff have core and that new proxy module as dep. (currently the partial-bean and JSF module).It allows to support different versions of asm once it's needed... (e.g. for diff. versions of java if the latest version drops e.g. backward compat. to and old version...) It's already discussed and agreed on the dev list so you can just create a ticket and just move the code + update the release poms so that the new module is part of the release as well... The new module should be called proxy-utils. GAV: org.apache.deltaspike.modules:deltaspike-proxy-module-api *don't* move org.apache.deltaspike.core.util.ProxyUtils - because it doesn't depend on asm and is valid for any proxy (weld-proxy, owb-proxy, javassist-proxy,...) We support at all + it's needed a lot in ds-core. If you would move it ds-core would depend on the proxy-module (which shouldn't be the case). The goal is really that the proxy-module is just needed once you need the partial-bean module and/or the optional proxies in the JSF module so the proxy-module needs to be an optional dep. of the JSF module... but in case of the partial-bean module the proxy-api module is a compile dep. since it's required anyway That's currently the release blocker, because now ds-core has a dependency to a fixed version of asm and so far Core didn't introduce a 3rd party dep. So We need to move to the new module before the next release... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-883) Create a new module for proxy
[ https://issues.apache.org/jira/browse/DELTASPIKE-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-883: Fix Version/s: (was: 1.4.1) Create a new module for proxy - Key: DELTASPIKE-883 URL: https://issues.apache.org/jira/browse/DELTASPIKE-883 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 1.3.0, 1.4.0 Reporter: Rafael Benevides Assignee: Rafael Benevides Priority: Blocker We are now using asm to create our own proxies - with 1.3.0 that was added to the partial bean module - now We replace the optional proxies created in the JSF module for converters/validators with the same approach - the proxy code was moved to ds-core. that works but isn't nice and not that flexible - the goal is an own module side by side with core and all modules which need proxy stuff have core and that new proxy module as dep. (currently the partial-bean and JSF module).It allows to support different versions of asm once it's needed... (e.g. for diff. versions of java if the latest version drops e.g. backward compat. to and old version...) It's already discussed and agreed on the dev list so you can just create a ticket and just move the code + update the release poms so that the new module is part of the release as well... The new module should be called proxy-utils. GAV: org.apache.deltaspike.modules:deltaspike-proxy-module-api *don't* move org.apache.deltaspike.core.util.ProxyUtils - because it doesn't depend on asm and is valid for any proxy (weld-proxy, owb-proxy, javassist-proxy,...) We support at all + it's needed a lot in ds-core. If you would move it ds-core would depend on the proxy-module (which shouldn't be the case). The goal is really that the proxy-module is just needed once you need the partial-bean module and/or the optional proxies in the JSF module so the proxy-module needs to be an optional dep. of the JSF module... but in case of the partial-bean module the proxy-api module is a compile dep. since it's required anyway That's currently the release blocker, because now ds-core has a dependency to a fixed version of asm and so far Core didn't introduce a 3rd party dep. So We need to move to the new module before the next release... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-924) Adjust The AbstractEntityRepository Class section.
[ https://issues.apache.org/jira/browse/DELTASPIKE-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-924: Summary: Adjust The AbstractEntityRepository Class section. (was: Adjust The AbstractEntityRepository Class secion.) Adjust The AbstractEntityRepository Class section. -- Key: DELTASPIKE-924 URL: https://issues.apache.org/jira/browse/DELTASPIKE-924 Project: DeltaSpike Issue Type: Improvement Components: Documentation Reporter: Daniel Cunha (soro) Assignee: Daniel Cunha (soro) Priority: Minor Fix For: 1.4.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-909) Site/Docs/Javadoc Release procedures for DS 1.4
[ https://issues.apache.org/jira/browse/DELTASPIKE-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-909: Fix Version/s: (was: 1.4.0) 1.4.1 Site/Docs/Javadoc Release procedures for DS 1.4 --- Key: DELTASPIKE-909 URL: https://issues.apache.org/jira/browse/DELTASPIKE-909 Project: DeltaSpike Issue Type: Task Components: Documentation Affects Versions: 1.4.0 Reporter: Rafael Benevides Assignee: Rafael Benevides Fix For: 1.4.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-925) prepare v1.4.1
Gerhard Petracek created DELTASPIKE-925: --- Summary: prepare v1.4.1 Key: DELTASPIKE-925 URL: https://issues.apache.org/jira/browse/DELTASPIKE-925 Project: DeltaSpike Issue Type: Task Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-813) improve basic core documentation
[ https://issues.apache.org/jira/browse/DELTASPIKE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-813: Fix Version/s: (was: 1.4.1) 1.4.2 improve basic core documentation Key: DELTASPIKE-813 URL: https://issues.apache.org/jira/browse/DELTASPIKE-813 Project: DeltaSpike Issue Type: Task Components: Documentation Affects Versions: 1.2.1 Reporter: Gerhard Petracek Assignee: Ron Smeral Fix For: 1.4.2 in this first step we should improve everything which is marked red or yellow in the documentation column and green or yellow in the importance for average users column ( see https://cwiki.apache.org/confluence/display/DeltaSpike/DS-Core+Overview ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-724) upgrade version of the tomee-arquillian adapter
[ https://issues.apache.org/jira/browse/DELTASPIKE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-724: Fix Version/s: (was: 1.4.1) 1.4.2 upgrade version of the tomee-arquillian adapter --- Key: DELTASPIKE-724 URL: https://issues.apache.org/jira/browse/DELTASPIKE-724 Project: DeltaSpike Issue Type: Task Components: Build, Tests Reporter: Gerhard Petracek Assignee: Romain Manni-Bucau Fix For: 1.4.2 to test against tomee 1.7.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-872) Support mocking on proxied beans
[ https://issues.apache.org/jira/browse/DELTASPIKE-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-872: Fix Version/s: (was: 1.4.1) 1.4.2 Support mocking on proxied beans Key: DELTASPIKE-872 URL: https://issues.apache.org/jira/browse/DELTASPIKE-872 Project: DeltaSpike Issue Type: Improvement Components: TestControl Affects Versions: 1.3.0 Reporter: Rafael Assignee: Thomas Andraschko Fix For: 1.4.2 Currently test control mock feature is not supported on proxies (e.g: beans with interceptors), a sample test which fails because of this limitation can be found here: https://github.com/rmpestano/ee6-ds-demo/blob/master/src/test/java/org/os890/demo/ee6/test/MockTest.java . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-894) Trim for CriteriaSupport API
[ https://issues.apache.org/jira/browse/DELTASPIKE-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-894: Fix Version/s: 1.4.1 Trim for CriteriaSupport API Key: DELTASPIKE-894 URL: https://issues.apache.org/jira/browse/DELTASPIKE-894 Project: DeltaSpike Issue Type: New Feature Components: Data-Module Reporter: Daniel Cunha (soro) Assignee: Daniel Cunha (soro) Priority: Minor Fix For: 1.4.1 Attachments: DELTASPIKE-894.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-911) Criteria API - Add support for accept multiple columns in orderBy
[ https://issues.apache.org/jira/browse/DELTASPIKE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-911: Fix Version/s: 1.4.1 Criteria API - Add support for accept multiple columns in orderBy - Key: DELTASPIKE-911 URL: https://issues.apache.org/jira/browse/DELTASPIKE-911 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Affects Versions: 1.4.0 Reporter: Daniel Cunha (soro) Assignee: Daniel Cunha (soro) Fix For: 1.4.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-603) removeBy* - similiar to findBy*
[ https://issues.apache.org/jira/browse/DELTASPIKE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-603: Fix Version/s: 1.4.1 removeBy* - similiar to findBy* --- Key: DELTASPIKE-603 URL: https://issues.apache.org/jira/browse/DELTASPIKE-603 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Reporter: Thomas Andraschko Assignee: Thomas Hug Fix For: 1.4.1 It would be great to allow a removeBy* - simliar to findBy* e.g. void removeByBrandId(String brandId); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DELTASPIKE-919) higher priority for dynamic navigation-parameters
Gerhard Petracek created DELTASPIKE-919: --- Summary: higher priority for dynamic navigation-parameters Key: DELTASPIKE-919 URL: https://issues.apache.org/jira/browse/DELTASPIKE-919 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 1.4.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.1 navigation parameters added manually via NavigationParameterContext#addPageParameter shouldn't get overruled by navigation parameters (with the same name) provided via @NavigationParameter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DELTASPIKE-919) higher priority for dynamic navigation-parameters
[ https://issues.apache.org/jira/browse/DELTASPIKE-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-919. - Resolution: Fixed higher priority for dynamic navigation-parameters - Key: DELTASPIKE-919 URL: https://issues.apache.org/jira/browse/DELTASPIKE-919 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 1.4.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.4.1 navigation parameters added manually via NavigationParameterContext#addPageParameter shouldn't get overruled by navigation parameters (with the same name) provided via @NavigationParameter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-680) Lazy init should not rely on BeanManagerProvider
[
https://issues.apache.org/jira/browse/DELTASPIKE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-680:
Assignee: Harald Wellmann (was: Thomas Hug)
Lazy init should not rely on BeanManagerProvider
Key: DELTASPIKE-680
URL: https://issues.apache.org/jira/browse/DELTASPIKE-680
Project: DeltaSpike
Issue Type: Improvement
Components: Data-Module
Affects Versions: 1.0.1
Reporter: Harald Wellmann
Assignee: Harald Wellmann
Trying to work with DeltaSpike Data in OSGi (with on-the-fly OSGification,
see DELTASPIKE-660), I found that things break when the TCCL is not set to
the classloader of the current repository.
This is caused by lazy initialization of {{RepositoryComponent}} using
{{BeanManagerProvider}}.
Now the current strategies of {{BeanManagerProvider}} to locate the current
{{BeanManager}} do not work in OSGi where each bundle may have its own
BeanManager and there is no obvious interpretation of current, and the TCCL
is not by default set to anything useful for this problem.
However, in the context of DeltaSpike Data, is it easy to avoid the
{{BeanManagerProvider}} even with lazy initialization. The correct
{{BeanManager}} is known when a {{RepositoryComponent}} is instantiated, so
its sufficient to keep a reference to this {{BeanManager}} to perform lazy
initialization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-448) Review exception handling in Data module
[ https://issues.apache.org/jira/browse/DELTASPIKE-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-448: Assignee: Daniel Cunha (soro) (was: Thomas Hug) Review exception handling in Data module Key: DELTASPIKE-448 URL: https://issues.apache.org/jira/browse/DELTASPIKE-448 Project: DeltaSpike Issue Type: Improvement Components: Data-Module Reporter: Thomas Hug Assignee: Daniel Cunha (soro) For the exception handling: - javax.persistence.PersistenceException should be re-thrown to the caller - Other exceptions should be wrapped in a QueryInvocationException. The exception should be available in the API module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-594) Memory leak in RepositoryComponents singleton
[
https://issues.apache.org/jira/browse/DELTASPIKE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-594:
Assignee: Harald Wellmann (was: Thomas Hug)
Memory leak in RepositoryComponents singleton
-
Key: DELTASPIKE-594
URL: https://issues.apache.org/jira/browse/DELTASPIKE-594
Project: DeltaSpike
Issue Type: Bug
Components: Data-Module
Affects Versions: 0.7
Reporter: Harald Wellmann
Assignee: Harald Wellmann
{{RepositoryComponentsFactory}} has a static singleton member of type
{{RepositoryComponents}}.
Repository classes are added to this singleton, but are never deleted.
This will cause a classloader leak when the DeltaSpike modules live longer
than application modules, e.g. in OSGi when each DeltaSpike module is a
separate bundle, or in WildFly when DeltaSpike is installed as a JBoss module.
--
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: Ron Smeral (was: Thomas Hug)
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: Ron Smeral
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)
