[jira] [Resolved] (DELTASPIKE-1326) Clean up Java 8 support in data module

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1326.
---
Resolution: Fixed

> Clean up Java 8 support in data module
> --
>
> Key: DELTASPIKE-1326
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1326
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Reporter: John D. Ament
>Assignee: John D. Ament
>Priority: Major
> Fix For: 1.9.0
>
>
> Data Module currently uses Java 8 Stream/Optional support.  We can clean up 
> this integration now that we're on Java 8 as a baseline.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (DELTASPIKE-1328) Add a Java 8 base repository

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1328:
-

 Summary: Add a Java 8 base repository
 Key: DELTASPIKE-1328
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1328
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Data-Module
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.9.0


Add a base repository, like {{EntityRepository}} but for Java 8 
{{Optional/Stream}} use cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1177) [Deltaspike Data] Regoznize Entity Type by method returned type if @Repository.forEntity is set to default

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16389866#comment-16389866
 ] 

John D. Ament commented on DELTASPIKE-1177:
---

Hi [~tibor17] basically, the issue is that the entity object is known at the 
repository layer not the method layer 
[https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/meta/RepositoryMetadata.java]

 

For your use case to work, you need to move that entity, or duplicate it, at 
the method level.  

> [Deltaspike Data] Regoznize Entity Type by method returned type if 
> @Repository.forEntity is set to default
> --
>
> Key: DELTASPIKE-1177
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1177
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.7.0
>Reporter: Tibor Digana
>Priority: Major
>
> I want to use Deltaspike Data Repo as a Service because it is simplistic and 
> not DAO.
> Since of service operates over multiple entities I want the extension to 
> recognize the Entity type dynamically by method return type.
> Notice the example does not implement _EntityRepository_ and therefore the 
> only return type should be checked.
> {code}
> @Repository
> public interface Java8Repository {
>   MyEntity findByCourse(@NotNull String courseName);
>   AnotherEntity findByCustomer(@NotNull String customerName);
>   @Query("")
>   Object[] findMultipleEntityTypes(@NotNull String attribute);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DELTASPIKE-1177) [Deltaspike Data] Regoznize Entity Type by method returned type if @Repository.forEntity is set to default

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1177:
--
Fix Version/s: (was: 1.9.0)

> [Deltaspike Data] Regoznize Entity Type by method returned type if 
> @Repository.forEntity is set to default
> --
>
> Key: DELTASPIKE-1177
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1177
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.7.0
>Reporter: Tibor Digana
>Priority: Major
>
> I want to use Deltaspike Data Repo as a Service because it is simplistic and 
> not DAO.
> Since of service operates over multiple entities I want the extension to 
> recognize the Entity type dynamically by method return type.
> Notice the example does not implement _EntityRepository_ and therefore the 
> only return type should be checked.
> {code}
> @Repository
> public interface Java8Repository {
>   MyEntity findByCourse(@NotNull String courseName);
>   AnotherEntity findByCustomer(@NotNull String customerName);
>   @Query("")
>   Object[] findMultipleEntityTypes(@NotNull String attribute);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DELTASPIKE-1177) [Deltaspike Data] Regoznize Entity Type by method returned type if @Repository.forEntity is set to default

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1177:
--
Fix Version/s: 1.9.0

> [Deltaspike Data] Regoznize Entity Type by method returned type if 
> @Repository.forEntity is set to default
> --
>
> Key: DELTASPIKE-1177
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1177
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.7.0
>Reporter: Tibor Digana
>Priority: Major
> Fix For: 1.9.0
>
>
> I want to use Deltaspike Data Repo as a Service because it is simplistic and 
> not DAO.
> Since of service operates over multiple entities I want the extension to 
> recognize the Entity type dynamically by method return type.
> Notice the example does not implement _EntityRepository_ and therefore the 
> only return type should be checked.
> {code}
> @Repository
> public interface Java8Repository {
>   MyEntity findByCourse(@NotNull String courseName);
>   AnotherEntity findByCustomer(@NotNull String customerName);
>   @Query("")
>   Object[] findMultipleEntityTypes(@NotNull String attribute);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (DELTASPIKE-1326) Clean up Java 8 support in data module

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1326:
-

 Summary: Clean up Java 8 support in data module
 Key: DELTASPIKE-1326
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1326
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.9.0


Data Module currently uses Java 8 Stream/Optional support.  We can clean up 
this integration now that we're on Java 8 as a baseline.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DELTASPIKE-1324) @Transactional annotation at method level doesn't override the one at class level any more

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1324:
--
Fix Version/s: 1.9.0

> @Transactional annotation at method level doesn't override the one at class 
> level any more
> --
>
> Key: DELTASPIKE-1324
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1324
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: Jens Berke
>Assignee: John D. Ament
>Priority: Major
> Fix For: 1.9.0
>
>
> Hi. The behaviour of @Transactional has changed with 1.8.1:
> Until version 1.8.0 @Transactional annotations at method level overrode those 
> at the class level. Like this:
> {code:java}
> @Transactional(readOnly = true)
> public class MyClass {
>     public void doSomethingReadOnly()
>     @Transactional
>     public void writeSomething(){code}
> This stopped working with version 1.8.1 because the @Transactional annotation 
> at method level seems to be ignored and the transaction for the method 
> remains read-only. The cause is probably the change introduced with 
> DELTASPIKE-940, where the following method was added to 
> org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper:
> {code:java}
> EntityManagerMetadata createEntityManagerMetadata(InvocationContext context)
> {
>     EntityManagerMetadata metadata = new EntityManagerMetadata();
>     metadata.readFrom(context.getMethod(), beanManager);
>     metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
>     return metadata;
> }{code}
> If first reads the data at method level and then at class level, which seems 
> to be the wrong order. Swapping these lines would restore the correct 
> behaviour:
> {code:java}
> metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
> metadata.readFrom(context.getMethod(), beanManager);{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1324) @Transactional annotation at method level doesn't override the one at class level any more

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16389852#comment-16389852
 ] 

John D. Ament commented on DELTASPIKE-1324:
---

BTW is 1.9.0 an OK place to fix for you?  That release will target Java 8.

> @Transactional annotation at method level doesn't override the one at class 
> level any more
> --
>
> Key: DELTASPIKE-1324
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1324
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: Jens Berke
>Assignee: John D. Ament
>Priority: Major
> Fix For: 1.9.0
>
>
> Hi. The behaviour of @Transactional has changed with 1.8.1:
> Until version 1.8.0 @Transactional annotations at method level overrode those 
> at the class level. Like this:
> {code:java}
> @Transactional(readOnly = true)
> public class MyClass {
>     public void doSomethingReadOnly()
>     @Transactional
>     public void writeSomething(){code}
> This stopped working with version 1.8.1 because the @Transactional annotation 
> at method level seems to be ignored and the transaction for the method 
> remains read-only. The cause is probably the change introduced with 
> DELTASPIKE-940, where the following method was added to 
> org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper:
> {code:java}
> EntityManagerMetadata createEntityManagerMetadata(InvocationContext context)
> {
>     EntityManagerMetadata metadata = new EntityManagerMetadata();
>     metadata.readFrom(context.getMethod(), beanManager);
>     metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
>     return metadata;
> }{code}
> If first reads the data at method level and then at class level, which seems 
> to be the wrong order. Swapping these lines would restore the correct 
> behaviour:
> {code:java}
> metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
> metadata.readFrom(context.getMethod(), beanManager);{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (DELTASPIKE-1324) @Transactional annotation at method level doesn't override the one at class level any more

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-1324:
-

Assignee: John D. Ament

> @Transactional annotation at method level doesn't override the one at class 
> level any more
> --
>
> Key: DELTASPIKE-1324
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1324
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: Jens Berke
>Assignee: John D. Ament
>Priority: Major
>
> Hi. The behaviour of @Transactional has changed with 1.8.1:
> Until version 1.8.0 @Transactional annotations at method level overrode those 
> at the class level. Like this:
> {code:java}
> @Transactional(readOnly = true)
> public class MyClass {
>     public void doSomethingReadOnly()
>     @Transactional
>     public void writeSomething(){code}
> This stopped working with version 1.8.1 because the @Transactional annotation 
> at method level seems to be ignored and the transaction for the method 
> remains read-only. The cause is probably the change introduced with 
> DELTASPIKE-940, where the following method was added to 
> org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper:
> {code:java}
> EntityManagerMetadata createEntityManagerMetadata(InvocationContext context)
> {
>     EntityManagerMetadata metadata = new EntityManagerMetadata();
>     metadata.readFrom(context.getMethod(), beanManager);
>     metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
>     return metadata;
> }{code}
> If first reads the data at method level and then at class level, which seems 
> to be the wrong order. Swapping these lines would restore the correct 
> behaviour:
> {code:java}
> metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
> metadata.readFrom(context.getMethod(), beanManager);{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1324) @Transactional annotation at method level doesn't override the one at class level any more

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16389851#comment-16389851
 ] 

John D. Ament commented on DELTASPIKE-1324:
---

Good catch, will fix.  Sorry about that!

> @Transactional annotation at method level doesn't override the one at class 
> level any more
> --
>
> Key: DELTASPIKE-1324
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1324
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: Jens Berke
>Priority: Major
>
> Hi. The behaviour of @Transactional has changed with 1.8.1:
> Until version 1.8.0 @Transactional annotations at method level overrode those 
> at the class level. Like this:
> {code:java}
> @Transactional(readOnly = true)
> public class MyClass {
>     public void doSomethingReadOnly()
>     @Transactional
>     public void writeSomething(){code}
> This stopped working with version 1.8.1 because the @Transactional annotation 
> at method level seems to be ignored and the transaction for the method 
> remains read-only. The cause is probably the change introduced with 
> DELTASPIKE-940, where the following method was added to 
> org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper:
> {code:java}
> EntityManagerMetadata createEntityManagerMetadata(InvocationContext context)
> {
>     EntityManagerMetadata metadata = new EntityManagerMetadata();
>     metadata.readFrom(context.getMethod(), beanManager);
>     metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
>     return metadata;
> }{code}
> If first reads the data at method level and then at class level, which seems 
> to be the wrong order. Swapping these lines would restore the correct 
> behaviour:
> {code:java}
> metadata.readFrom(context.getMethod().getDeclaringClass(), beanManager);
> metadata.readFrom(context.getMethod(), beanManager);{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1316) add dynamic annotations feature, configurable via config

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362184#comment-16362184
 ] 

John D. Ament commented on DELTASPIKE-1316:
---

Since this is an external code import, don't forget you must submit IP 
Clearance.

> add dynamic annotations feature, configurable via config
> 
>
> Key: DELTASPIKE-1316
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1316
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.8.1
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.8.2
>
>
> A long time ago I created a CDI Extension which can dynamically add 
> annotations to classes identified via a regular expression.
> The Extension is called InterDyn (Interceptor Dynamics) and is hosted at 
> github.
> [https://github.com/struberg/InterDyn]
>  
> I'm the sole originary author, so I have all the IP.
> The project actually consists of two parts: InterDyn for dynamic interceptors 
> and InvoMon, an invocation monitor interceptor. Kind of small man profiler.
> The InterDyn part is actually not restricted to add interceptor annotations, 
> but really could be anything. But adding interceptors obviously makes the 
> most sense. This should go into ds-core-impl. It doesn't even need any api 
> changes.
>  
> The 2nd part (the performance InvocationMonitor. Might become either part of 
> core, or a separate module.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16313288#comment-16313288
 ] 

John D. Ament commented on DELTASPIKE-1311:
---

[~gpetracek] thanks for the reminder.  We already support Deactivatable on 
repositories - 
https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/RepositoryExtension.java#L87

I've got a response I'll share on user list that the person can use immediately.

> Allow Excluded Repositories
> ---
>
> Key: DELTASPIKE-1311
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.2
>
>
> When a repository is discovered, if it has @Exclude on it, then don't include 
> it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16313252#comment-16313252
 ] 

John D. Ament commented on DELTASPIKE-1311:
---

[~romain.manni-bucau] no this is a common use case (the on list reporter 
mentions CDI 2.0).  Vetoed will work, I just worry about not having a solution 
for EE6 use cases.  The problem is that the repository is not an actual bean, 
but we register one, so we want to use {{@Vetoed}} or similar to indicate it 
should not have a repository bean registered.

[~gpetracek] [~tandraschko] what about the idea of also introducing a config 
property, e.g. {{com.mycompany.repository.RepositoryClass.vetoed=true}} to see 
if it should be vetoed?  Considered {{false}} by default.

> Allow Excluded Repositories
> ---
>
> Key: DELTASPIKE-1311
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.2
>
>
> When a repository is discovered, if it has @Exclude on it, then don't include 
> it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16313181#comment-16313181
 ] 

John D. Ament commented on DELTASPIKE-1311:
---

It probably works well as a minimal slice.  We can iterate over it as we gain 
user input on the enhancement.  No reason to boil the ocean.

> Allow Excluded Repositories
> ---
>
> Key: DELTASPIKE-1311
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.2
>
>
> When a repository is discovered, if it has @Exclude on it, then don't include 
> it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (DELTASPIKE-1311) Allow Excluded Repositories

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1311:
-

 Summary: Allow Excluded Repositories
 Key: DELTASPIKE-1311
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.8.1
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.8.2


When a repository is discovered, if it has @Exclude on it, then don't include 
it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1299) Order by items are applied in alphabetic order

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16306996#comment-16306996
 ] 

John D. Ament commented on DELTASPIKE-1299:
---

[~tandraschko] I don't know what this ticket has to do with ASM upgrade?

> Order by items are applied in alphabetic order
> --
>
> Key: DELTASPIKE-1299
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1299
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.0
>Reporter: Moritz Becker
> Fix For: 1.8.2
>
>
> DeltaSpike data applies the order bys in parsed methods in alphabetic order 
> which leads to semantically incorrect queries.
> For example, the method {{findAllOrderByNameAscIdDesc}} produces the 
> following query:
> {code:sql}
> select * from ... order by id desc, name asc
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DELTASPIKE-1299) Order by items are applied in alphabetic order

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1299.
---
Resolution: Fixed

Thanks for the patch, applied!

> Order by items are applied in alphabetic order
> --
>
> Key: DELTASPIKE-1299
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1299
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.0
>Reporter: Moritz Becker
> Fix For: 1.8.1
>
>
> DeltaSpike data applies the order bys in parsed methods in alphabetic order 
> which leads to semantically incorrect queries.
> For example, the method {{findAllOrderByNameAscIdDesc}} produces the 
> following query:
> {code:sql}
> select * from ... order by id desc, name asc
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DELTASPIKE-1299) Order by items are applied in alphabetic order

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1299:
--
Fix Version/s: 1.8.1

> Order by items are applied in alphabetic order
> --
>
> Key: DELTASPIKE-1299
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1299
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.0
>Reporter: Moritz Becker
> Fix For: 1.8.1
>
>
> DeltaSpike data applies the order bys in parsed methods in alphabetic order 
> which leads to semantically incorrect queries.
> For example, the method {{findAllOrderByNameAscIdDesc}} produces the 
> following query:
> {code:sql}
> select * from ... order by id desc, name asc
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (DELTASPIKE-1262) Remove CdiContainer control

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reopened DELTASPIKE-1262:
---

[~struberg] This is for a planned 2.0 (who knows when it will happen).  You can 
still accomplish what you're talking about with SeContainer though, but the 
question is why would you?  
https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/se/SeContainerInitializer.java#L259-L268

> Remove CdiContainer control
> ---
>
> Key: DELTASPIKE-1262
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1262
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
> Fix For: 2.0
>
>
> The bootstrap mechanisms for CDI are present in CDI 2.0.  We no longer need 
> this functionality.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16306857#comment-16306857
 ] 

John D. Ament commented on DELTASPIKE-940:
--

Yep, simply forgot to upate JIRA!

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.1
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16274449#comment-16274449
 ] 

John D. Ament commented on DELTASPIKE-940:
--

got it.  The issue looks pretty straight forward, should be a simple fix.

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.1
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265792#comment-16265792
 ] 

John D. Ament commented on DELTASPIKE-1302:
---

I like Romain's idea.  Makes sense.

> ThreadPoolManager: ExecutorService map is always empty
> --
>
> Key: DELTASPIKE-1302
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.8.0
>Reporter: Alonso Gonzalez
>Priority: Minor
>
> ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to 
> an ExecutorService. Unfortunately the map never gets populated. It's always 
> empty.
> I need this because I want to use a specific ExecutorService with @Futureable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1301) java.lang.IllegalStateException,message=Could not find EntityManager with default qualifier.

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257226#comment-16257226
 ] 

John D. Ament commented on DELTASPIKE-1301:
---

You mentioned this in a prior comment:

{code}
 13:13:22,225 ERROR [io.undertow.request] (default task-1) UT005023: Exception 
handling request to /path/: org.jboss.resteasy.spi.UnhandledException: 
javax.persistence.TransactionRequiredException: WFLYJPA0060: Transaction is 
required to perform this operation (either use a transaction or extended 
persistence context)
{code}

Is it in fact that exception? Because that's a different issue.

> java.lang.IllegalStateException,message=Could not find EntityManager with 
> default qualifier.
> 
>
> Key: DELTASPIKE-1301
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1301
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.0
> Environment: Wildfly 10.1.0, Ubuntu 16.04
>Reporter: Nicolas Duminil
>
> Hello,
> I have the following data-module repository:
> {code}
> @Repository
> public interface CustomerManagementRepository extends 
> EntityRepository
> {
>   ...
> }
> {code}
> This repository is called from a stateless session bean, as follows:
> {code}
>   @Inject
>   private CustomerManagementRepository repo;
>   
>   public List findByFirsName(String firstName)
>   {
> return repo.findByFirsName(firstName);
>   }
> {code}
> The following CDI producer is provided as well:
> {code}
> public class EntityManagerProducer
> {
>   @PersistenceContext
>   private EntityManager em;
>   @Produces
>   public EntityManager createEntityManager()
>   {
> return em;
>   }
> }
> {code}
> When calling the staeless bean from a JAX-RS service, as follows:
> {code}
>   @EJB
>   private CustomerManagementFacade facade;
>   @POST
>   @Consumes(MediaType.APPLICATION_JSON)
>   public Response createCustomer(Customer customer)
>   {
> Customer newCustomer = facade.saveAndFlushAndRefresh(customer);
> return Response.created(URI.create("/customers/" + 
> newCustomer.getId())).build();
>   }
> {code}
> the following exception is raised:
> {code}
> 15:48:14,914 ERROR [org.jboss.as.ejb3.invocation] (default task-1) 
> WFLYEJB0034: EJB Invocation failed on component CustomerManagementFacade for 
> method public fr.simplex_software.customer_management.data.Customer 
> fr.simplex_software.customer_management.facade.CustomerManagementFacade.saveAndFlushAndRefresh(fr.simplex_software.customer_management.data.Customer):
>  javax.ejb.EJBException: 
> org.apache.deltaspike.data.api.QueryInvocationException: Exception calling 
> Repository: [Repository=class 
> fr.simplex_software.customer_management.repository.CustomerManagementRepository$$DSPartialBeanProxy,method=saveAndFlushAndRefresh],exception=class
>  java.lang.IllegalStateException,message=Could not find EntityManager with 
> default qualifier.
> {code}
> What seems to happen is that the CDI producer doesn't get called. Do I do 
> anything wrong here ? Please don't send me links to the documentation 'cause 
> I've read it before posting.
> Many thanks in advance,
> Nicolas
> P.S. I have the following in apache-deltaspike.properties:
> {code}
> globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1301) java.lang.IllegalStateException,message=Could not find EntityManager with default qualifier.

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255639#comment-16255639
 ] 

John D. Ament commented on DELTASPIKE-1301:
---

Just wondering, did you try adding {{@Dependent}} to your producer class/field?

> java.lang.IllegalStateException,message=Could not find EntityManager with 
> default qualifier.
> 
>
> Key: DELTASPIKE-1301
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1301
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.8.0
> Environment: Wildfly 10.1.0, Ubuntu 16.04
>Reporter: Nicolas Duminil
>
> Hello,
> I have the following data-module repository:
> {code}
> @Repository
> public interface CustomerManagementRepository extends 
> EntityRepository
> {
>   ...
> }
> {code}
> This repository is called from a stateless session bean, as follows:
> {code}
>   @Inject
>   private CustomerManagementRepository repo;
>   
>   public List findByFirsName(String firstName)
>   {
> return repo.findByFirsName(firstName);
>   }
> {code}
> The following CDI producer is provided as well:
> {code}
> public class EntityManagerProducer
> {
>   @PersistenceContext
>   private EntityManager em;
>   @Produces
>   public EntityManager createEntityManager()
>   {
> return em;
>   }
> }
> {code}
> When calling the staeless bean from a JAX-RS service, as follows:
> {code}
>   @EJB
>   private CustomerManagementFacade facade;
>   @POST
>   @Consumes(MediaType.APPLICATION_JSON)
>   public Response createCustomer(Customer customer)
>   {
> Customer newCustomer = facade.saveAndFlushAndRefresh(customer);
> return Response.created(URI.create("/customers/" + 
> newCustomer.getId())).build();
>   }
> {code}
> the following exception is raised:
> {code}
> 15:48:14,914 ERROR [org.jboss.as.ejb3.invocation] (default task-1) 
> WFLYEJB0034: EJB Invocation failed on component CustomerManagementFacade for 
> method public fr.simplex_software.customer_management.data.Customer 
> fr.simplex_software.customer_management.facade.CustomerManagementFacade.saveAndFlushAndRefresh(fr.simplex_software.customer_management.data.Customer):
>  javax.ejb.EJBException: 
> org.apache.deltaspike.data.api.QueryInvocationException: Exception calling 
> Repository: [Repository=class 
> fr.simplex_software.customer_management.repository.CustomerManagementRepository$$DSPartialBeanProxy,method=saveAndFlushAndRefresh],exception=class
>  java.lang.IllegalStateException,message=Could not find EntityManager with 
> default qualifier.
> {code}
> What seems to happen is that the CDI producer doesn't get called. Do I do 
> anything wrong here ? Please don't send me links to the documentation 'cause 
> I've read it before posting.
> Many thanks in advance,
> Nicolas
> P.S. I have the following in apache-deltaspike.properties:
> {code}
> globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DELTASPIKE-1301) java.lang.IllegalStateException,message=Could not find EntityManager with default qualifier.

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1301:
--
Description: 
Hello,

I have the following data-module repository:

{code}
@Repository
public interface CustomerManagementRepository extends 
EntityRepository
{
  ...
}
{code}

This repository is called from a stateless session bean, as follows:

{code}
  @Inject
  private CustomerManagementRepository repo;
  
  public List findByFirsName(String firstName)
  {
return repo.findByFirsName(firstName);
  }
{code}

The following CDI producer is provided as well:

{code}
public class EntityManagerProducer
{
  @PersistenceContext
  private EntityManager em;

  @Produces
  public EntityManager createEntityManager()
  {
return em;
  }
}
{code}

When calling the staeless bean from a JAX-RS service, as follows:

{code}
  @EJB
  private CustomerManagementFacade facade;

  @POST
  @Consumes(MediaType.APPLICATION_JSON)
  public Response createCustomer(Customer customer)
  {
Customer newCustomer = facade.saveAndFlushAndRefresh(customer);
return Response.created(URI.create("/customers/" + 
newCustomer.getId())).build();
  }
{code}

the following exception is raised:

{code}
15:48:14,914 ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: 
EJB Invocation failed on component CustomerManagementFacade for method public 
fr.simplex_software.customer_management.data.Customer 
fr.simplex_software.customer_management.facade.CustomerManagementFacade.saveAndFlushAndRefresh(fr.simplex_software.customer_management.data.Customer):
 javax.ejb.EJBException: 
org.apache.deltaspike.data.api.QueryInvocationException: Exception calling 
Repository: [Repository=class 
fr.simplex_software.customer_management.repository.CustomerManagementRepository$$DSPartialBeanProxy,method=saveAndFlushAndRefresh],exception=class
 java.lang.IllegalStateException,message=Could not find EntityManager with 
default qualifier.
{code}

What seems to happen is that the CDI producer doesn't get called. Do I do 
anything wrong here ? Please don't send me links to the documentation 'cause 
I've read it before posting.

Many thanks in advance,

Nicolas

P.S. I have the following in apache-deltaspike.properties:

{code}
globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy
{code}

  was:
Hello,

I have the following data-module repository:

@Repository
public interface CustomerManagementRepository extends 
EntityRepository
{
  ...
}

This repository is called from a stateless session bean, as follows:

  @Inject
  private CustomerManagementRepository repo;
  
  public List findByFirsName(String firstName)
  {
return repo.findByFirsName(firstName);
  }

The following CDI producer is provided as well:

public class EntityManagerProducer
{
  @PersistenceContext
  private EntityManager em;

  @Produces
  public EntityManager createEntityManager()
  {
return em;
  }
}

When calling the staeless bean from a JAX-RS service, as follows:

  @EJB
  private CustomerManagementFacade facade;

  @POST
  @Consumes(MediaType.APPLICATION_JSON)
  public Response createCustomer(Customer customer)
  {
Customer newCustomer = facade.saveAndFlushAndRefresh(customer);
return Response.created(URI.create("/customers/" + 
newCustomer.getId())).build();
  }

the following exception is raised:

15:48:14,914 ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: 
EJB Invocation failed on component CustomerManagementFacade for method public 
fr.simplex_software.customer_management.data.Customer 
fr.simplex_software.customer_management.facade.CustomerManagementFacade.saveAndFlushAndRefresh(fr.simplex_software.customer_management.data.Customer):
 javax.ejb.EJBException: 
org.apache.deltaspike.data.api.QueryInvocationException: Exception calling 
Repository: [Repository=class 
fr.simplex_software.customer_management.repository.CustomerManagementRepository$$DSPartialBeanProxy,method=saveAndFlushAndRefresh],exception=class
 java.lang.IllegalStateException,message=Could not find EntityManager with 
default qualifier.

What seems to happen is that the CDI producer doesn't get called. Do I do 
anything wrong here ? Please don't send me links to the documentation 'cause 
I've read it before posting.

Many thanks in advance,

Nicolas

P.S. I have the following in apache-deltaspike.properties:

globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy



> java.lang.IllegalStateException,message=Could not find EntityManager with 
> default qualifier.
> 
>
> Key: DELTASPIKE-1301
>  

[jira] [Resolved] (DELTASPIKE-1292) deltaspike distribution BOM has wrong parent - rendering it useless

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1292.
---
Resolution: Duplicate

Marking as a duplicate.

> deltaspike distribution BOM has wrong parent - rendering it useless
> ---
>
> Key: DELTASPIKE-1292
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1292
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.8.0
>Reporter: Jörg Sesterhenn
>Assignee: John D. Ament
>  Labels: maven
>
> In Version 1.8.0 of the deltaspike distribution bom the parent was changed to
> {code}
> org.apache.deltaspike.distribution
> distributions-project
> 1.8.0
> {code}
> This change leads to several unwanted dependency management entries (for 
> libraries not concerning deltaspike) in our projects after importing your bom.
> Please revert this change and verify that importing your BOM only sets 
> versions for deltaspike artifacts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DELTASPIKE-1278) PropertyFileConfig does not respect optional on external resources

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1278.
---
   Resolution: Fixed
 Assignee: John D. Ament
Fix Version/s: 1.8.1

Thanks for the contribution, merged!

> PropertyFileConfig does not respect optional on external resources
> --
>
> Key: DELTASPIKE-1278
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1278
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Dennis Rippinger
>Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> Adding a property file from an external location (e.g. local file system) 
> marked as optional is not respected by {{PropertyFileUtils}}. It creates a 
> list of possible resource URLs, but does not check for their existence in all 
> branches of its logic. This results in a list of possible nonexistent 
> resources which could be optional, leading to an IllegalStateException.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124726#comment-16124726
 ] 

John D. Ament commented on DELTASPIKE-940:
--

[~tandraschko] sorry thought I had already responded.  The problem with pulling 
it out is that it has to be in two places, since this annotation can control 
both transactions and repository.  Having it in a common place makes more sense.

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.1
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DELTASPIKE-1281) Deltaspike does not pass BeanManager to persistenf factory config using "javax.persistence.bean.manager"

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1281.
---
Resolution: Fixed

Done.

> Deltaspike does not pass BeanManager to persistenf factory config using 
> "javax.persistence.bean.manager"
> 
>
> Key: DELTASPIKE-1281
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1281
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.8.0
> Environment: Deltaspike 1.8, Weld 3.0, Java 8 (JSE) JPA with 
> HIbernate 5.2.10
>Reporter: Alex Roytman
>Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> As the result no injections were working in JPA listeners.
> Per specs Persistence UnitFactory expects BeanManager in 
> javax.persistence.bean.manager property passed when instantiate it but 
> org.apache.deltaspike.jpa.impl.entitymanager.PersistenceConfigurationProviderImpl
>  does not pass it
> this simple override took care of it but I should not need to do it:
> {code:java}
> @ApplicationScoped
> @Alternative
> @Priority(Interceptor.Priority.APPLICATION + 10)
> public class CdiAwarePersistenceConfigurationProviderImpl extends 
> PersistenceConfigurationProviderImpl implements 
> PersistenceConfigurationProvider {
>   @Inject BeanManager beanManager;
>   @Override public Properties getEntityManagerFactoryConfiguration(String 
> persistenceUnitName) {
> final Properties conf = 
> super.getEntityManagerFactoryConfiguration(persistenceUnitName);
> conf.put("javax.persistence.bean.manager", beanManager);
> return conf;
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (DELTASPIKE-1281) Deltaspike does not pass BeanManager to persistenf factory config using "javax.persistence.bean.manager"

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-1281:
-

Assignee: John D. Ament

> Deltaspike does not pass BeanManager to persistenf factory config using 
> "javax.persistence.bean.manager"
> 
>
> Key: DELTASPIKE-1281
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1281
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.8.0
> Environment: Deltaspike 1.8, Weld 3.0, Java 8 (JSE) JPA with 
> HIbernate 5.2.10
>Reporter: Alex Roytman
>Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> As the result no injections were working in JPA listeners.
> Per specs Persistence UnitFactory expects BeanManager in 
> javax.persistence.bean.manager property passed when instantiate it but 
> org.apache.deltaspike.jpa.impl.entitymanager.PersistenceConfigurationProviderImpl
>  does not pass it
> this simple override took care of it but I should not need to do it:
> {code:java}
> @ApplicationScoped
> @Alternative
> @Priority(Interceptor.Priority.APPLICATION + 10)
> public class CdiAwarePersistenceConfigurationProviderImpl extends 
> PersistenceConfigurationProviderImpl implements 
> PersistenceConfigurationProvider {
>   @Inject BeanManager beanManager;
>   @Override public Properties getEntityManagerFactoryConfiguration(String 
> persistenceUnitName) {
> final Properties conf = 
> super.getEntityManagerFactoryConfiguration(persistenceUnitName);
> conf.put("javax.persistence.bean.manager", beanManager);
> return conf;
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DELTASPIKE-1281) Deltaspike does not pass BeanManager to persistenf factory config using "javax.persistence.bean.manager"

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1281:
--
Fix Version/s: 1.8.1

> Deltaspike does not pass BeanManager to persistenf factory config using 
> "javax.persistence.bean.manager"
> 
>
> Key: DELTASPIKE-1281
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1281
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.8.0
> Environment: Deltaspike 1.8, Weld 3.0, Java 8 (JSE) JPA with 
> HIbernate 5.2.10
>Reporter: Alex Roytman
> Fix For: 1.8.1
>
>
> As the result no injections were working in JPA listeners.
> Per specs Persistence UnitFactory expects BeanManager in 
> javax.persistence.bean.manager property passed when instantiate it but 
> org.apache.deltaspike.jpa.impl.entitymanager.PersistenceConfigurationProviderImpl
>  does not pass it
> this simple override took care of it but I should not need to do it:
> {code:java}
> @ApplicationScoped
> @Alternative
> @Priority(Interceptor.Priority.APPLICATION + 10)
> public class CdiAwarePersistenceConfigurationProviderImpl extends 
> PersistenceConfigurationProviderImpl implements 
> PersistenceConfigurationProvider {
>   @Inject BeanManager beanManager;
>   @Override public Properties getEntityManagerFactoryConfiguration(String 
> persistenceUnitName) {
> final Properties conf = 
> super.getEntityManagerFactoryConfiguration(persistenceUnitName);
> conf.put("javax.persistence.bean.manager", beanManager);
> return conf;
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1275) Build fails on Linux because Testclass filenames are to long

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063499#comment-16063499
 ] 

John D. Ament commented on DELTASPIKE-1275:
---

what distro?

> Build fails on Linux because Testclass filenames are to long
> 
>
> Key: DELTASPIKE-1275
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1275
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JPA-Module
>Affects Versions: 1.8.0
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 1.8.1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DELTASPIKE-1252) data-documentation missing Optional return value

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1252.
---
Resolution: Fixed

> data-documentation missing Optional return value
> 
>
> Key: DELTASPIKE-1252
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1252
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Affects Versions: 1.7.2
>Reporter: Jan Matèrne
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.1
>
>
> http://deltaspike.apache.org/documentation/data.html lists the format for 
> methods:
> (Entity|List) (prefix)(Property[Comparator]){Operator Property 
> [Comparator]}
> Here java.util.Optional is missing:
> "(Entity|Optional|List) 
> (prefix)(Property[Comparator]){Operator Property [Comparator]}
>  
> Or in more concrete words:
> • The query method must either return an entity or an java.util.Optional 
> or a list of entities.
> • It must start with the findBy prefix ..."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (DELTASPIKE-1273) Test against OWB 2

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1273:
-

 Summary: Test against OWB 2
 Key: DELTASPIKE-1273
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1273
 Project: DeltaSpike
  Issue Type: Test
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.8.1


Add tests against OWB 2.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (DELTASPIKE-1264) Remove portions of BeanProvider/BeanManagerProvider

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1264:
-

 Summary: Remove portions of BeanProvider/BeanManagerProvider
 Key: DELTASPIKE-1264
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1264
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
 Fix For: 2.0


These internal utilities may not be needed based on CDI.current() from CDI 1.1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DELTASPIKE-1263) Remove BeanBuilder

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1263:
-

 Summary: Remove BeanBuilder
 Key: DELTASPIKE-1263
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1263
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
 Fix For: 2.0


CDI 2.0 introduces bean configurators, which handle the use cases of 
BeanBuilder.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DELTASPIKE-1260) Remove Servlet Module

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1260:
-

 Summary: Remove Servlet Module
 Key: DELTASPIKE-1260
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1260
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
 Fix For: 2.0


The Servlet module is fully supported by features of Java EE 7+, and is no 
longer useful.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DELTASPIKE-1261) Remove BeanVal Module

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1261:
-

 Summary: Remove BeanVal Module
 Key: DELTASPIKE-1261
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1261
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
 Fix For: 2.0


The Bean Validation module is fully supposed by Java EE 7+ and can be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DELTASPIKE-1257) Research why BOM isn't working right in a release

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1257:
-

 Summary: Research why BOM isn't working right in a release
 Key: DELTASPIKE-1257
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1257
 Project: DeltaSpike
  Issue Type: Task
Reporter: John D. Ament
Assignee: John D. Ament


https://lists.apache.org/thread.html/655162d82786d1201c2b33a20d82db8a36a642d0d9afc20042584b0d@%3Cdev.deltaspike.apache.org%3E

Something causes the release to work incorrectly with the BOM not inheriting 
from DS parent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-1257) Research why BOM isn't working right in a release

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1257:
--
Fix Version/s: 1.8.1

> Research why BOM isn't working right in a release
> -
>
> Key: DELTASPIKE-1257
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1257
> Project: DeltaSpike
>  Issue Type: Task
>Affects Versions: 1.8.0
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> https://lists.apache.org/thread.html/655162d82786d1201c2b33a20d82db8a36a642d0d9afc20042584b0d@%3Cdev.deltaspike.apache.org%3E
> Something causes the release to work incorrectly with the BOM not inheriting 
> from DS parent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-1257) Research why BOM isn't working right in a release

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1257:
--
Affects Version/s: 1.8.0

> Research why BOM isn't working right in a release
> -
>
> Key: DELTASPIKE-1257
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1257
> Project: DeltaSpike
>  Issue Type: Task
>Affects Versions: 1.8.0
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> https://lists.apache.org/thread.html/655162d82786d1201c2b33a20d82db8a36a642d0d9afc20042584b0d@%3Cdev.deltaspike.apache.org%3E
> Something causes the release to work incorrectly with the BOM not inheriting 
> from DS parent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-1212) Introduce a ConfigResolver.resolveAllProperties method

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-1212:
-

Assignee: John D. Ament

> Introduce a ConfigResolver.resolveAllProperties method
> --
>
> Key: DELTASPIKE-1212
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1212
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.0
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.1
>
>
> Invoking ConfigResolver.getAllProperties does not expand out any inlined 
> variables.  In addition, assume the following properties file and project 
> stage = Development
> {code}
> some-service-url=${edge-server-url}/some-service
> edge-server-url=undefined
> edge-server-url.Development=http://development:8081
> edge-server-url.Staging=http://staging:8081
> edge-server-url.Production=http://prod:8081
> {code}
> calling {{getAllProperties}} returns the raw output of this file.  
> Introducing a new {{resolveAllProperties}} method would only return back the 
> active values.  The expected result would be
> {code}
> some-service-url=http://development:8081/some-service
> edge-server-url=http://development:8081
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1212) Introduce a ConfigResolver.resolveAllProperties method

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013120#comment-16013120
 ] 

John D. Ament commented on DELTASPIKE-1212:
---

I disagree with closing hard to implement things as won't fix.  We'll come up 
with a way to solve this, even if its expensive.

> Introduce a ConfigResolver.resolveAllProperties method
> --
>
> Key: DELTASPIKE-1212
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1212
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.0
>Reporter: John D. Ament
> Fix For: 1.8.1
>
>
> Invoking ConfigResolver.getAllProperties does not expand out any inlined 
> variables.  In addition, assume the following properties file and project 
> stage = Development
> {code}
> some-service-url=${edge-server-url}/some-service
> edge-server-url=undefined
> edge-server-url.Development=http://development:8081
> edge-server-url.Staging=http://staging:8081
> edge-server-url.Production=http://prod:8081
> {code}
> calling {{getAllProperties}} returns the raw output of this file.  
> Introducing a new {{resolveAllProperties}} method would only return back the 
> active values.  The expected result would be
> {code}
> some-service-url=http://development:8081/some-service
> edge-server-url=http://development:8081
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-940:
-
Fix Version/s: (was: 2.0)
   1.8.0

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-940:
-
Attachment: ds940.patch

This is basically what I had in mind for the first pass.  Deprecate the 
existing behavior, and let that be baked in.

To support the existing, we can create a qualifier based implementation in SPI, 
especially since it doesn't support qualifiers with parameters in them.

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 2.0
>
> Attachments: ds940.patch
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002558#comment-16002558
 ] 

John D. Ament commented on DELTASPIKE-940:
--

While we shouldn't remove the old behavior pre-DS 2.0, it would be good to 
provide similar capabilities in both.

As a result, I think it makes sense to include qualifier in the look up while 
still allowing class based resolution.

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-940:
-
Fix Version/s: 1.8.0

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-940) @Transactional and @EntityManagerConfig each use a different method to resolve EntityManagers

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-940:


Assignee: John D. Ament  (was: Thomas Hug)

> @Transactional and @EntityManagerConfig each use a different method to 
> resolve EntityManagers
> -
>
> Key: DELTASPIKE-940
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-940
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module, JPA-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
>
> When an application uses multiple {{EntityManager}}'s, there must be a way to 
> specify which one(s) should be used. Currently, {{@Transactional}} and 
> {{@EntityManagerConfig}} use different approaches:
> - {{@Transactional}} can take one or more qualifiers directly in its 
> {{qualifier()}} member ({{@Transactional(qualifier = MyDB.class)}})
> - While {{@EntityManagerConfig}} must define an {{EntityManagerResolver}} 
> ({{@EntityManagerConfig(entityManagerResolver = 
> MyDBEntityManagerResolver.class}})
> I think both should be unified and use a single way to specify which 
> {{EntityManager}} to use. IMHO, the {{@Transactional}} way of doing looks 
> better and should be applied to {{@EntityManagerConfig}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-1193) Repository methods should consider Boolean and boolean the same

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-1193:
-

Assignee: John D. Ament

> Repository methods should consider Boolean and boolean the same
> ---
>
> Key: DELTASPIKE-1193
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1193
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/property/MethodPropertyImpl.java#L79
> In this case, we're treating boolean as valid for is methods, the same is not 
> applied to Boolean types.  This means your entities can't have Boolean 
> methods.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-1225) deltaspike.testcontrol.stop_container should stop the container after all tests executed

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-1225:
-

Assignee: John D. Ament

> deltaspike.testcontrol.stop_container should stop the container after all 
> tests executed
> 
>
> Key: DELTASPIKE-1225
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1225
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: TestControl
>Affects Versions: 1.7.2
>Reporter: Remo
>Assignee: John D. Ament
>Priority: Minor
>
> deltaspike.testcontrol.stop_container is very useful to speed up test cases. 
> However, it results that the container does not getting shutdown at all. This 
> should still be done after ALL the tests have been executed.
> With Gradle the current behavior is quite a problem. The Gradle Wrappers keep 
> by default the VM running. And as such, test cases must properly cleanup and 
> free resources. Otherwise the Gradle wrapper consumes more and more memory 
> and dies at some point.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-1229) Allow the use of @Alternative to implement a custom TimestampsProvider

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-1229:
-

Assignee: John D. Ament

> Allow the use of @Alternative to implement a custom TimestampsProvider
> --
>
> Key: DELTASPIKE-1229
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1229
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module, JPA-Module
>Affects Versions: 1.7.2
> Environment: Deltaspike 1.7.2. CDI 1.1 Wildfly AS 9.0.2.Final
>Reporter: Nico Schlebusch
>Assignee: John D. Ament
>
> I'm using the JPA {{@EntityListeners(AuditEntityListener.class)}} and the 
> audit functionality of Deltaspike Data ({{@CreatedOn}}, {{@ModifiedOn}} and 
> {{@ModifiedBy}} annotations) on an entity bean with the difference that I 
> have a custom implementation of {{java.time.ChronoLocalDateTime}} which 
> converts any {{LocalDateTime}} + {{ZoneOffset}} OR a {{ZonedDateTime}} to be 
> the UTC date & time.
> Is there a way to implement my own 
> {{org.apache.deltaspike.data.impl.audit.PrePersistAuditListener}} and 
> {{org.apache.deltaspike.data.impl.audit.PreUpdateAuditListener}} and use them 
> to create the instance of {{UTCDateTime}} required by he fields marked with 
> {{@InsertedOn}} and {{@ModiefiedOn}}?
> See this [SO 
> Question|http://stackoverflow.com/questions/41057116/deltaspike-data-cdi-jpa-custom-prepersistauditlistener-and-preupdateauditlis]
>  and the discussion on this [mail 
> thread|https://lists.apache.org/thread.html/c47a6187d03fc8f665c6b3c7ab760e80084db3b8d4f83fe9d34015d8@%3Cusers.deltaspike.apache.org%3E]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (DELTASPIKE-1236) unit testing a servlet that uses injection

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1236.
-
Resolution: Won't Fix

> unit testing a servlet that uses injection
> --
>
> Key: DELTASPIKE-1236
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1236
> Project: DeltaSpike
>  Issue Type: Improvement
>Affects Versions: 1.7.2
> Environment: Tomcat
>Reporter: Stephen More
>
> I have been using org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner 
> to test JSF backing beans and everything seems to be working well.
> At this point I am struggling how to test a plain old servlet that uses 
> injection, are there any examples anywhere ?
> The current - non working test code can be found here: 
> https://github.com/mores/maven-examples/tree/master/prime-deltaspike
> Servlet works as expected when deployed - output is survey says: 3.96 
> (https://github.com/mores/maven-examples/blob/master/prime-deltaspike/src/main/java/org/test/MyServlet.java)
> But when trying to run the test, windowContext appears to be null. ( 
> https://github.com/mores/maven-examples/blob/master/prime-deltaspike/src/test/java/org/test/MyServletTest.java
>  )



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1240) [Config] add List support

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002541#comment-16002541
 ] 

John D. Ament commented on DELTASPIKE-1240:
---

FYI, while there's documentation committed in this ticket it was never 
published.  I'm about to publish the docs.

> [Config] add List support
> -
>
> Key: DELTASPIKE-1240
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1240
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> Currently there is no built-in way to configure lists of values. This is 
> useful if you think about e.g. something like
> {code}
> mycompany.myproj.batch.error.email=someone@mycomp,else@mycomp,ops@mycomp
> {code}
> Any ',' character inside the payload might get escaped via '\,' and a single 
> backslash '\' itself with double-backslash '\\'



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (DELTASPIKE-1252) data-documentation missing Optional return value

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1252.
---
Resolution: Fixed

> data-documentation missing Optional return value
> 
>
> Key: DELTASPIKE-1252
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1252
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Affects Versions: 1.7.2
>Reporter: Jan Matèrne
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
>
> http://deltaspike.apache.org/documentation/data.html lists the format for 
> methods:
> (Entity|List) (prefix)(Property[Comparator]){Operator Property 
> [Comparator]}
> Here java.util.Optional is missing:
> "(Entity|Optional|List) 
> (prefix)(Property[Comparator]){Operator Property [Comparator]}
>  
> Or in more concrete words:
> • The query method must either return an entity or an java.util.Optional 
> or a list of entities.
> • It must start with the findBy prefix ..."



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1252) data-documentation missing Optional return value

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002531#comment-16002531
 ] 

John D. Ament commented on DELTASPIKE-1252:
---

Fair point... stream is missing there as well.

> data-documentation missing Optional return value
> 
>
> Key: DELTASPIKE-1252
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1252
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Affects Versions: 1.7.2
>Reporter: Jan Matèrne
>Priority: Minor
> Fix For: 1.8.0
>
>
> http://deltaspike.apache.org/documentation/data.html lists the format for 
> methods:
> (Entity|List) (prefix)(Property[Comparator]){Operator Property 
> [Comparator]}
> Here java.util.Optional is missing:
> "(Entity|Optional|List) 
> (prefix)(Property[Comparator]){Operator Property [Comparator]}
>  
> Or in more concrete words:
> • The query method must either return an entity or an java.util.Optional 
> or a list of entities.
> • It must start with the findBy prefix ..."



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-1252) data-documentation missing Optional return value

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1252:
--
Fix Version/s: 1.8.0

> data-documentation missing Optional return value
> 
>
> Key: DELTASPIKE-1252
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1252
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Affects Versions: 1.7.2
>Reporter: Jan Matèrne
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
>
> http://deltaspike.apache.org/documentation/data.html lists the format for 
> methods:
> (Entity|List) (prefix)(Property[Comparator]){Operator Property 
> [Comparator]}
> Here java.util.Optional is missing:
> "(Entity|Optional|List) 
> (prefix)(Property[Comparator]){Operator Property [Comparator]}
>  
> Or in more concrete words:
> • The query method must either return an entity or an java.util.Optional 
> or a list of entities.
> • It must start with the findBy prefix ..."



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (DELTASPIKE-1252) data-documentation missing Optional return value

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-1252:
-

Assignee: John D. Ament

> data-documentation missing Optional return value
> 
>
> Key: DELTASPIKE-1252
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1252
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Affects Versions: 1.7.2
>Reporter: Jan Matèrne
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.8.0
>
>
> http://deltaspike.apache.org/documentation/data.html lists the format for 
> methods:
> (Entity|List) (prefix)(Property[Comparator]){Operator Property 
> [Comparator]}
> Here java.util.Optional is missing:
> "(Entity|Optional|List) 
> (prefix)(Property[Comparator]){Operator Property [Comparator]}
>  
> Or in more concrete words:
> • The query method must either return an entity or an java.util.Optional 
> or a list of entities.
> • It must start with the findBy prefix ..."



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-1238) Create a better default TransactionStrategy

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1238:
--
Description: Create a better default TransactionStrategy that handles more 
use cases out of the box.  (was: Make EnvironmentAwareTransactionStrategy the 
default transaction strategy, since it properly looks up container managed, 
resource local without requiring the user to do anything.)

> Create a better default TransactionStrategy
> ---
>
> Key: DELTASPIKE-1238
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1238
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Create a better default TransactionStrategy that handles more use cases out 
> of the box.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (DELTASPIKE-1238) Create a better default TransactionStrategy

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1238:
--
Summary: Create a better default TransactionStrategy  (was: Make 
EnvironmentAwareTransactionStrategy the default)

> Create a better default TransactionStrategy
> ---
>
> Key: DELTASPIKE-1238
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1238
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Make EnvironmentAwareTransactionStrategy the default transaction strategy, 
> since it properly looks up container managed, resource local without 
> requiring the user to do anything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (DELTASPIKE-1238) Make EnvironmentAwareTransactionStrategy the default

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reopened DELTASPIKE-1238:
---

Hey, I disagree. We can talk through it more, but it isn't a top priority for 
me right now.

> Make EnvironmentAwareTransactionStrategy the default
> 
>
> Key: DELTASPIKE-1238
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1238
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Make EnvironmentAwareTransactionStrategy the default transaction strategy, 
> since it properly looks up container managed, resource local without 
> requiring the user to do anything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (DELTASPIKE-1195) Servlet module forces application to use distributed sessions

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1195.
---
Resolution: Won't Fix

Wasn't me, but the user mentioned that issue is not ours, so I think we're good.

> Servlet module forces application to use distributed sessions
> -
>
> Key: DELTASPIKE-1195
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1195
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Servlet-Module
>Affects Versions: 1.7.1
>Reporter: Klaasjan Brand
>Assignee: John D. Ament
>Priority: Minor
>
> The deltaspike-servlet-module-impl jar contains a web-fragment.xml file 
> containing a  tag. This forces every web application 
> including this jar file to support distributed sessions.
> I know it's possible to disable the parsing of fragments, but we use 
> fragments for other libraries. Besides, I don't think it's the responsibility 
> of deltaspike to decide if web application sessions are distributable.
> Could you consider removing this line?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1238) Make EnvironmentAwareTransactionStrategy the default

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897654#comment-15897654
 ] 

John D. Ament commented on DELTASPIKE-1238:
---

Those are things that can be fixed.  We have direct feedback on the user's list 
that the default doesn't work for most use cases out of the box, which is true.

> Make EnvironmentAwareTransactionStrategy the default
> 
>
> Key: DELTASPIKE-1238
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1238
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Make EnvironmentAwareTransactionStrategy the default transaction strategy, 
> since it properly looks up container managed, resource local without 
> requiring the user to do anything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DELTASPIKE-1238) Make EnvironmentAwareTransactionStrategy the default

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1238:
-

 Summary: Make EnvironmentAwareTransactionStrategy the default
 Key: DELTASPIKE-1238
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1238
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: John D. Ament
Assignee: John D. Ament


Make EnvironmentAwareTransactionStrategy the default transaction strategy, 
since it properly looks up container managed, resource local without requiring 
the user to do anything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1236) unit testing a servlet that uses injection

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15891479#comment-15891479
 ] 

John D. Ament commented on DELTASPIKE-1236:
---

[~mores] not sure if you saw my messages on the mailing list, so anyways I'll 
post a complete response.  The problem is that you're mixing mockito and 
deltaspike.  When I change your test class to be:

{code:java}
@RunWith(CdiTestRunner.class)
public class MyServletTest {

@Inject
private org.apache.deltaspike.core.spi.scope.window.WindowContext 
windowContext;

@Inject
private org.apache.deltaspike.cdise.api.ContextControl contextControl;

@Inject
private MyServlet myServlet;

@After
public void teardown() {
contextControl

.stopContext(javax.enterprise.context.ConversationScoped.class);
}

@Before
public void init() {
contextControl

.startContext(javax.enterprise.context.ConversationScoped.class);
windowContext.activateWindow("testWindow");
}

@Test
public void testServlet() throws Exception {
javax.servlet.http.HttpServletRequest request = 
org.mockito.Mockito

.mock(javax.servlet.http.HttpServletRequest.class);
javax.servlet.http.HttpServletResponse response = 
org.mockito.Mockito

.mock(javax.servlet.http.HttpServletResponse.class);

// org.mockito.Mockito.when( request.getServletPath() 
).thenReturn(
// "/this/path" );
// org.mockito.Mockito.when( request.getParameter( "ID" ) 
).thenReturn(
// "1234" );
// org.mockito.Mockito.when( request.getParameter( "format" )
// ).thenReturn( "PDF" );

myServlet.doGet(request, response);
}
}
{code}

It passes fine.  But note, you can't mix the two.  If you need to do mocking, 
you would use our MockManager so that its still handled as a CDI injection 
point - 
http://deltaspike.apache.org/documentation/test-control.html#MockFrameworks

Using the mocks for request/response should be perfectly fine for your use 
case, but you can't expect @Inject and mockito to work together.

> unit testing a servlet that uses injection
> --
>
> Key: DELTASPIKE-1236
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1236
> Project: DeltaSpike
>  Issue Type: Improvement
>Affects Versions: 1.7.2
> Environment: Tomcat
>Reporter: Stephen More
>
> I have been using org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner 
> to test JSF backing beans and everything seems to be working well.
> At this point I am struggling how to test a plain old servlet that uses 
> injection, are there any examples anywhere ?
> The current - non working test code can be found here: 
> https://github.com/mores/maven-examples/tree/master/prime-deltaspike
> Servlet works as expected when deployed - output is survey says: 3.96 
> (https://github.com/mores/maven-examples/blob/master/prime-deltaspike/src/main/java/org/test/MyServlet.java)
> But when trying to run the test, windowContext appears to be null. ( 
> https://github.com/mores/maven-examples/blob/master/prime-deltaspike/src/test/java/org/test/MyServletTest.java
>  )



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DELTASPIKE-1237) Fetch definitions for queries

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1237:
-

 Summary: Fetch definitions for queries
 Key: DELTASPIKE-1237
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1237
 Project: DeltaSpike
  Issue Type: New Feature
Reporter: John D. Ament


In JPQL you can define a query such as {{select e from Entity e join fetch 
e.someChild}}.  You can't do this with method expressions.  It would also be a 
bit too verbose to include all of the fetches.

We should introduce some ways to define the fetches for a query, as well as 
whether its outer or inner join ( see notes from 
http://docs.oracle.com/html/E13946_04/ejb3_langref.html#ejb3_langref_Joins 
where its either "[INNER] JOIN" or "LEFT [OUTER] JOIN"



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1222) Allow query by example method expression wtih @Query annotation

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862602#comment-15862602
 ] 

John D. Ament commented on DELTASPIKE-1222:
---

[~richardjusko]  i'm having a hard time understanding the relationship between 
the parameter's you're passing in, and how they're using in the query.  How 
does "paramE" fit in?

> Allow query by example method expression wtih @Query annotation
> ---
>
> Key: DELTASPIKE-1222
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1222
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module
>Reporter: Richard Juso
>  Labels: features
> Fix For: 1.8.0, 2.0
>
>
> ability to either override findBy/findAll methods with @Query annotation 
> (without using params or using params, but also allowing the E example 
> pattern)  or add support for custom method expression that could be used for 
> this purpose.  the E example would only appy to the main Entity restrictions, 
> the additional params could apply to nested entities based on param index
> ie. @Query(value = "select r from Range r where r.customId IN (select 
> e.customId from EbsUserStub e)")
>   public abstract List findBy(Range paramE, 
> SingularAttribute paramArrayOfSingularAttribute);
> or 
> @Query(value = "select r from Range r where r.customId IN (select e.customId 
> from EbsUserStub e)")
>   public abstract List findUsing(Range paramE, 
> SingularAttribute paramArrayOfSingularAttribute);
> or 
> @Query(value = "select r from Range r where r.customId IN (select e.customId 
> from EbsUserStub e where e.miscField = ?2)")
>   public abstract List findByMiscField(Range paramE, 
> SingularAttribute paramArrayOfSingularAttribute, String miscField);
> method expression could either be custom ie. findUsing,  findByEntityName, 
> findByMiscField or some other marker.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (DELTASPIKE-1217) Use a README file in the repo to provide more info

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1217.
---
Resolution: Fixed

There is a readme file.

> Use a README file in the repo to provide more info
> --
>
> Key: DELTASPIKE-1217
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1217
> Project: DeltaSpike
>  Issue Type: Improvement
>Affects Versions: 1.7.2
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.0
>
>
> Currently when you browse deltaspike, from github for instance, there is no 
> README and it makes the repo look bare.  Add a README to provide more info to 
> users, or developers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1235) DS 2: check if we can remove our ContextControl

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862594#comment-15862594
 ] 

John D. Ament commented on DELTASPIKE-1235:
---

Basically, no we cannot.  ContainerControl can be removed, however the only 
context that supports activation is request.  Other contexts are not supported 
yet.  However, it would only really impact session context.

> DS 2: check if we can remove our ContextControl
> ---
>
> Key: DELTASPIKE-1235
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1235
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 2.0
>Reporter: Thomas Andraschko
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1234) DS 2: check if we can remove our proxy module

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862593#comment-15862593
 ] 

John D. Ament commented on DELTASPIKE-1234:
---

We can definitely make improvements based on how InterceptionFactory works.  
However, it doesn't do proxy handler type support.

> DS 2: check if we can remove our proxy module
> -
>
> Key: DELTASPIKE-1234
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1234
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Proxy-Module
>Affects Versions: 2.0
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 2.0
>
>
> in favor of the InterceptionFactory
> This will likely not work because we also support abstract classes



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1232) Weld 3.0.0.CR1 package changes causing build failures

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15834719#comment-15834719
 ] 

John D. Ament commented on DELTASPIKE-1232:
---

AFAIK, Weld 1.1.5 is still supported.

> Weld 3.0.0.CR1 package changes causing build failures
> -
>
> Key: DELTASPIKE-1232
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1232
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.7.2
>Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.0
>
>
> Using Weld 3.0.0.CR1, Weld-container control module fails to build.
> The reason is the package change introduced as a part of Weld's JDK 9 early 
> adaptation (see [WELD-2305|https://issues.jboss.org/browse/WELD-2305]). This 
> was done to eliminate future package-clash problems.
> It should be investigated whether DS can depend on Weld API instead of 
> internals to handle container control as depending on internals is a bad 
> practice anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1231) Update the Weld3 Profile for DS 1.8

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1231.
---
   Resolution: Fixed
Fix Version/s: 1.8.0

Added new build job, committed changes.

https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike_Weld_3/

> Update the Weld3 Profile for DS 1.8
> ---
>
> Key: DELTASPIKE-1231
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1231
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Build
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.0
>
>
> Presently, DeltaSpike does not compile with CDI 2 on the classpath.  When you 
> compile w/ CDI 2.0 the default methods on interfaces are not leverages.
> For DS 1.8, the Weld 3 profile should get updated to:
> - Point to latest beta
> - Point to java compiler 1.8 (e.g. this build should fail on Java 7 and below)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1231) Update the Weld3 Profile for DS 1.8

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1231:
-

 Summary: Update the Weld3 Profile for DS 1.8
 Key: DELTASPIKE-1231
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1231
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Build
Reporter: John D. Ament
Assignee: John D. Ament


Presently, DeltaSpike does not compile with CDI 2 on the classpath.  When you 
compile w/ CDI 2.0 the default methods on interfaces are not leverages.

For DS 1.8, the Weld 3 profile should get updated to:

- Point to latest beta
- Point to java compiler 1.8 (e.g. this build should fail on Java 7 and below)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1228) ContextControl does not work in Websphere AS

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15798563#comment-15798563
 ] 

John D. Ament commented on DELTASPIKE-1228:
---

Newer versions of websphere ship with Weld, not OpenWebBeans.  The version 
you're using should be using Weld.

> ContextControl does not work in Websphere AS
> 
>
> Key: DELTASPIKE-1228
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1228
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.7.1
> Environment: Websphere 8.5.5.9
>Reporter: Matthias Wronka
>
> I´m getting an Exception in Websphere Application Server 8.5.5.9 when I try 
> to start the SessionScope like this using ContextControl:
> {code:java}
> @Inject
> private ContextControl contextControl
> private void doSth() {
> contextControl.startContext(SessionScoped.class);
> }
> {code}
> The exception is:
> {code}
> java.lang.NoClassDefFoundError: org/apache/webbeans/config/WebBeansContext at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContextControl.getContextsService(OpenWebBeansContextControl.java:242)
>  at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContextControl.startSessionScope(OpenWebBeansContextControl.java:154)
>  at 
> org.apache.deltaspike.cdise.owb.OpenWebBeansContextControl.startContext(OpenWebBeansContextControl.java:80)
>  
> {code}
> I think this is because of a rather old owb-implementations, that Websphere 
> uses. I found the missing class in another package: 
> org/apache/webbeans/*context*/WebBeansContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1226) NPE in DeltaSpikeLifecycleWrapper with OmniFaces 2.5 FullAjaxExceptionHandler

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15730441#comment-15730441
 ] 

John D. Ament commented on DELTASPIKE-1226:
---

Hi, I'm fine with leaving this open.  If they need us to fix something, we can 
fix it.  However, it seems like their implementation isn't correct.

If its OK with you, I can create a ticket in their github issues and see if 
they respond.

> NPE in DeltaSpikeLifecycleWrapper with OmniFaces 2.5 FullAjaxExceptionHandler
> -
>
> Key: DELTASPIKE-1226
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1226
> Project: DeltaSpike
>  Issue Type: Wish
>  Components: JSF-Module
>Affects Versions: 1.7.2
> Environment: JBoss EAP 7.0.3.GA; DeltaSpike 1.7.2; OmniFaces 2.5.1; 
> PrimeFaces 6.0.7
>Reporter: Gerald Turner
>Priority: Minor
>
> I have a JSF application with web.xml declaring an error page, and I am using 
> [OmniFaces 
> FullAjaxExceptionHandler|http://showcase.omnifaces.org/exceptionhandlers/FullAjaxExceptionHandler]
>  to render failed AJAX requests with the error page.
> Since upgrading to OmniFaces 2.5.1 the application has been having 
> NullPointerExceptions in DeltaSpikeLifecycleWrapper when 
> FullAjaxExceptionHandler performs it's error page rendering. Triggering the 
> so-called "Error in error page itself" condition.
> I believe [OmniFaces commit 
> 59459007|https://github.com/omnifaces/omnifaces/commit/5945900731da60f609d7dd36f0fe28ce3f26edbf]
>  is the culprit.
> I've breakpointed at the NullPointerException thrown in 
> DeltaSpikeLifecycleWrapper#render and found that none of the fields like 
> _contextExtension_ have been initialized.
> Downgrading to OmniFaces 2.4 works around the issue.
> Stacktrace:
> {noformat}
> 2016-12-07 14:26:25,581 SEVERE 
> [org.omnifaces.exceptionhandler.FullAjaxExceptionHandler] (default task-100) 
> FullAjaxExceptionHandler: Well, another exception occurred during rendering 
> error page '/csst/error.jsf'. Trying to render a hardcoded error page now.: 
> java.lang.NullPointerException
>   at 
> org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.render(DeltaSpikeLifecycleWrapper.java:115)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at 
> javax.faces.lifecycle.LifecycleWrapper.render(LifecycleWrapper.java:92) 
> [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> org.apache.deltaspike.jsf.impl.listener.request.JsfClientWindowAwareLifecycleWrapper.render(JsfClientWindowAwareLifecycleWrapper.java:160)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at 
> org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.renderErrorPageView(FullAjaxExceptionHandler.java:536)
>  [omnifaces-2.5.1.jar:2.5.1]
>   at 
> org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handleAjaxException(FullAjaxExceptionHandler.java:411)
>  [omnifaces-2.5.1.jar:2.5.1]
>   at 
> org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handle(FullAjaxExceptionHandler.java:364)
>  [omnifaces-2.5.1.jar:2.5.1]
>   at 
> javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:100)
>  [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> org.apache.deltaspike.jsf.impl.exception.control.BridgeExceptionHandlerWrapper.handle(BridgeExceptionHandlerWrapper.java:109)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) 
> [jsf-impl-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) 
> [jsf-impl-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at 
> javax.faces.lifecycle.LifecycleWrapper.execute(LifecycleWrapper.java:77) 
> [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658) 
> [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>  [undertow-servlet-1.3.25.Final-redhat-1.jar:1.3.25.Final-redhat-1]
>   at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>  [undertow-servlet-1.3.25.Final-redhat-1.jar:1.3.25.Final-redhat-1]
>   at 
> net.xoint.csst.common.util.SlowRequestFilter.doFilter(SlowRequestFilter.java:113)
>  [CSST-war-common-2.12-SNAPSHOT.jar:2.12-SNAPSHOT (local)]
>   at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) 
> 

[jira] [Commented] (DELTASPIKE-1226) NPE in DeltaSpikeLifecycleWrapper with OmniFaces 2.5 FullAjaxExceptionHandler

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15730284#comment-15730284
 ] 

John D. Ament commented on DELTASPIKE-1226:
---

Gerald, did you also file an issue w/ the omnifaces team?  The problem is that 
they're manually looking up a lifecycle but not triggering the event for that 
lifecycle, which never calls execute.  The way they're manually setting the 
phase ID means the event doesn't get published.

> NPE in DeltaSpikeLifecycleWrapper with OmniFaces 2.5 FullAjaxExceptionHandler
> -
>
> Key: DELTASPIKE-1226
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1226
> Project: DeltaSpike
>  Issue Type: Wish
>  Components: JSF-Module
>Affects Versions: 1.7.2
> Environment: JBoss EAP 7.0.3.GA; DeltaSpike 1.7.2; OmniFaces 2.5.1; 
> PrimeFaces 6.0.7
>Reporter: Gerald Turner
>Priority: Minor
>
> I have a JSF application with web.xml declaring an error page, and I am using 
> [OmniFaces 
> FullAjaxExceptionHandler|http://showcase.omnifaces.org/exceptionhandlers/FullAjaxExceptionHandler]
>  to render failed AJAX requests with the error page.
> Since upgrading to OmniFaces 2.5.1 the application has been having 
> NullPointerExceptions in DeltaSpikeLifecycleWrapper when 
> FullAjaxExceptionHandler performs it's error page rendering. Triggering the 
> so-called "Error in error page itself" condition.
> I believe [OmniFaces commit 
> 59459007|https://github.com/omnifaces/omnifaces/commit/5945900731da60f609d7dd36f0fe28ce3f26edbf]
>  is the culprit.
> I've breakpointed at the NullPointerException thrown in 
> DeltaSpikeLifecycleWrapper#render and found that none of the fields like 
> _contextExtension_ have been initialized.
> Downgrading to OmniFaces 2.4 works around the issue.
> Stacktrace:
> {noformat}
> 2016-12-07 14:26:25,581 SEVERE 
> [org.omnifaces.exceptionhandler.FullAjaxExceptionHandler] (default task-100) 
> FullAjaxExceptionHandler: Well, another exception occurred during rendering 
> error page '/csst/error.jsf'. Trying to render a hardcoded error page now.: 
> java.lang.NullPointerException
>   at 
> org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.render(DeltaSpikeLifecycleWrapper.java:115)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at 
> javax.faces.lifecycle.LifecycleWrapper.render(LifecycleWrapper.java:92) 
> [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> org.apache.deltaspike.jsf.impl.listener.request.JsfClientWindowAwareLifecycleWrapper.render(JsfClientWindowAwareLifecycleWrapper.java:160)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at 
> org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.renderErrorPageView(FullAjaxExceptionHandler.java:536)
>  [omnifaces-2.5.1.jar:2.5.1]
>   at 
> org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handleAjaxException(FullAjaxExceptionHandler.java:411)
>  [omnifaces-2.5.1.jar:2.5.1]
>   at 
> org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handle(FullAjaxExceptionHandler.java:364)
>  [omnifaces-2.5.1.jar:2.5.1]
>   at 
> javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:100)
>  [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> org.apache.deltaspike.jsf.impl.exception.control.BridgeExceptionHandlerWrapper.handle(BridgeExceptionHandlerWrapper.java:109)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) 
> [jsf-impl-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) 
> [jsf-impl-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at 
> javax.faces.lifecycle.LifecycleWrapper.execute(LifecycleWrapper.java:77) 
> [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658) 
> [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>  [undertow-servlet-1.3.25.Final-redhat-1.jar:1.3.25.Final-redhat-1]
>   at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>  [undertow-servlet-1.3.25.Final-redhat-1.jar:1.3.25.Final-redhat-1]
>   at 
> net.xoint.csst.common.util.SlowRequestFilter.doFilter(SlowRequestFilter.java:113)
>  [CSST-war-common-2.12-SNAPSHOT.jar:2.12-SNAPSHOT (local)]
>   at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) 
> 

[jira] [Commented] (DELTASPIKE-1226) NPE in DeltaSpikeLifecycleWrapper with OmniFaces 2.5 FullAjaxExceptionHandler

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15730235#comment-15730235
 ] 

John D. Ament commented on DELTASPIKE-1226:
---

Hi Gerald

Do you see the {{execute}} method being invoked in this case? 
https://github.com/apache/deltaspike/blob/master/deltaspike/modules/jsf/impl/src/main/java/org/apache/deltaspike/jsf/impl/listener/request/DeltaSpikeLifecycleWrapper.java#L67

> NPE in DeltaSpikeLifecycleWrapper with OmniFaces 2.5 FullAjaxExceptionHandler
> -
>
> Key: DELTASPIKE-1226
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1226
> Project: DeltaSpike
>  Issue Type: Wish
>  Components: JSF-Module
>Affects Versions: 1.7.2
> Environment: JBoss EAP 7.0.3.GA; DeltaSpike 1.7.2; OmniFaces 2.5.1; 
> PrimeFaces 6.0.7
>Reporter: Gerald Turner
>Priority: Minor
>
> I have a JSF application with web.xml declaring an error page, and I am using 
> [OmniFaces 
> FullAjaxExceptionHandler|http://showcase.omnifaces.org/exceptionhandlers/FullAjaxExceptionHandler]
>  to render failed AJAX requests with the error page.
> Since upgrading to OmniFaces 2.5.1 the application has been having 
> NullPointerExceptions in DeltaSpikeLifecycleWrapper when 
> FullAjaxExceptionHandler performs it's error page rendering. Triggering the 
> so-called "Error in error page itself" condition.
> I believe [OmniFaces commit 
> 59459007|https://github.com/omnifaces/omnifaces/commit/5945900731da60f609d7dd36f0fe28ce3f26edbf]
>  is the culprit.
> I've breakpointed at the NullPointerException thrown in 
> DeltaSpikeLifecycleWrapper#render and found that none of the fields like 
> _contextExtension_ have been initialized.
> Downgrading to OmniFaces 2.4 works around the issue.
> Stacktrace:
> {noformat}
> 2016-12-07 14:26:25,581 SEVERE 
> [org.omnifaces.exceptionhandler.FullAjaxExceptionHandler] (default task-100) 
> FullAjaxExceptionHandler: Well, another exception occurred during rendering 
> error page '/csst/error.jsf'. Trying to render a hardcoded error page now.: 
> java.lang.NullPointerException
>   at 
> org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.render(DeltaSpikeLifecycleWrapper.java:115)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at 
> javax.faces.lifecycle.LifecycleWrapper.render(LifecycleWrapper.java:92) 
> [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> org.apache.deltaspike.jsf.impl.listener.request.JsfClientWindowAwareLifecycleWrapper.render(JsfClientWindowAwareLifecycleWrapper.java:160)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at 
> org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.renderErrorPageView(FullAjaxExceptionHandler.java:536)
>  [omnifaces-2.5.1.jar:2.5.1]
>   at 
> org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handleAjaxException(FullAjaxExceptionHandler.java:411)
>  [omnifaces-2.5.1.jar:2.5.1]
>   at 
> org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handle(FullAjaxExceptionHandler.java:364)
>  [omnifaces-2.5.1.jar:2.5.1]
>   at 
> javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:100)
>  [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> org.apache.deltaspike.jsf.impl.exception.control.BridgeExceptionHandlerWrapper.handle(BridgeExceptionHandlerWrapper.java:109)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) 
> [jsf-impl-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) 
> [jsf-impl-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89)
>  [deltaspike-jsf-module-impl-1.7.2.jar:1.7.2]
>   at 
> javax.faces.lifecycle.LifecycleWrapper.execute(LifecycleWrapper.java:77) 
> [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658) 
> [jboss-jsf-api_2.2_spec-2.2.12.redhat-1.jar:2.2.12.redhat-1]
>   at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>  [undertow-servlet-1.3.25.Final-redhat-1.jar:1.3.25.Final-redhat-1]
>   at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>  [undertow-servlet-1.3.25.Final-redhat-1.jar:1.3.25.Final-redhat-1]
>   at 
> net.xoint.csst.common.util.SlowRequestFilter.doFilter(SlowRequestFilter.java:113)
>  [CSST-war-common-2.12-SNAPSHOT.jar:2.12-SNAPSHOT (local)]
>   at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) 
> 

[jira] [Resolved] (DELTASPIKE-1224) Use newer release version of Apache RAT / release audit tool

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1224.
---
Resolution: Fixed
  Assignee: John D. Ament

Merged, thanks!

> Use newer release version of Apache RAT / release audit tool
> 
>
> Key: DELTASPIKE-1224
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1224
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.7.2
> Environment: HEAD
>Reporter: Philipp Ottlinger
>Assignee: John D. Ament
> Fix For: 1.8.0
>
> Attachments: DELTASPIKE-1224_useNewerRAT.diff
>
>
> Currently v0.8 is used, while the latest release is 0.12.
> {code}
> diff --git a/deltaspike/pom.xml b/deltaspike/pom.xml
> index 1460bb0..dd6835f 100644
> --- a/deltaspike/pom.xml
> +++ b/deltaspike/pom.xml
> @@ -83,7 +83,7 @@
>  
>  org.apache.rat
>  apache-rat-plugin
> -0.8
> +0.12
>  
>  
>  .idea/**/*
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1224) Use newer release version of Apache RAT / release audit tool

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1224:
--
Component/s: Build

> Use newer release version of Apache RAT / release audit tool
> 
>
> Key: DELTASPIKE-1224
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1224
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.7.2
> Environment: HEAD
>Reporter: Philipp Ottlinger
> Fix For: 1.8.0
>
> Attachments: DELTASPIKE-1224_useNewerRAT.diff
>
>
> Currently v0.8 is used, while the latest release is 0.12.
> {code}
> diff --git a/deltaspike/pom.xml b/deltaspike/pom.xml
> index 1460bb0..dd6835f 100644
> --- a/deltaspike/pom.xml
> +++ b/deltaspike/pom.xml
> @@ -83,7 +83,7 @@
>  
>  org.apache.rat
>  apache-rat-plugin
> -0.8
> +0.12
>  
>  
>  .idea/**/*
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1224) Use newer release version of Apache RAT / release audit tool

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15693749#comment-15693749
 ] 

John D. Ament commented on DELTASPIKE-1224:
---

Did you want to raise a PR for this Phil? Or should we just commit the patch?

> Use newer release version of Apache RAT / release audit tool
> 
>
> Key: DELTASPIKE-1224
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1224
> Project: DeltaSpike
>  Issue Type: Improvement
>Affects Versions: 1.8.0
> Environment: HEAD
>Reporter: Philipp Ottlinger
> Attachments: DELTASPIKE-1224_useNewerRAT.diff
>
>
> Currently v0.8 is used, while the latest release is 0.12.
> {code}
> diff --git a/deltaspike/pom.xml b/deltaspike/pom.xml
> index 1460bb0..dd6835f 100644
> --- a/deltaspike/pom.xml
> +++ b/deltaspike/pom.xml
> @@ -83,7 +83,7 @@
>  
>  org.apache.rat
>  apache-rat-plugin
> -0.8
> +0.12
>  
>  
>  .idea/**/*
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1218) Backport CDI 2.0 Request Context Controller

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1218:
-

 Summary: Backport CDI 2.0 Request Context Controller
 Key: DELTASPIKE-1218
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1218
 Project: DeltaSpike
  Issue Type: New Feature
  Components: CdiControl
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.8.0


Backport the new features of context control to enable users to leverage the 
functionality now.

{{@ActivateRequestContext}}
{{RequestContextController}}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DELTASPIKE-1216) AbstractFullEntityRepository should implement FullEntityRepository

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-1216:
-

Assignee: John D. Ament

> AbstractFullEntityRepository should implement FullEntityRepository
> --
>
> Key: DELTASPIKE-1216
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1216
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.7.1
>Reporter: Anthony Vanelverdinghe
>Assignee: John D. Ament
>Priority: Minor
>
> In practice, AbstractFullEntityRepository implements the FullEntityRepository 
> interface, but it's not specified to do so in its implements clause.
> Because of this:
> - it's not immediately obvious from AbstractFullEntityRepository's Javadoc 
> that it actually implements FullEntityRepository
> - and, analog, FullEntityRepository's Javadoc doesn't have an "All Known 
> Implementing Classes:" clause which lists AbstractFullEntityRepository



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1199) Problems with ContextControl and Weld ContainerInitialized, ContainerShutdown event.

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1199.
-

>  Problems with ContextControl and Weld ContainerInitialized, 
> ContainerShutdown event.
> -
>
> Key: DELTASPIKE-1199
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1199
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: CdiControl
>Affects Versions: 1.7.1
>Reporter: Seto
>Assignee: Matej Novotny
> Fix For: 1.7.2
>
>
> No replies in user mail list. So I submit an issue here. And I think it's a 
> bug as well.
> I have an @ApplicationScoped bean. It observes ContainerInitialized and 
> ContainerShutdown event. 
> {code:title=Kernel.java|borderStyle=solid}
> public Kernel(){
> System.out.println("Kernel constructed");
> }
> public void onContainerInitialized(@Observes ContainerInitialized event, 
> @Parameters List parameters) {
> System.out.println("container initialized");
> }
> public void onContainerShutdown(@Observes ContainerShutdown event){
> System.out.println("container shutdown");
> }
> {code}
> Then the kernel is constructed twice with the code below, one after boot, one 
> after shutdown.
> {code:title=Test.java|borderStyle=solid}
> public class Test {
> public static void main(String[] args) {
> CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer();
> cdiContainer.boot();
> // Starting the application-context enables use of @ApplicationScoped 
> beans
> ContextControl contextControl = cdiContainer.getContextControl();
> contextControl.startContext(ApplicationScoped.class);
> // You can use CDI here
> contextControl.stopContext(ApplicationScoped.class);
> cdiContainer.shutdown();
> }
> }
> {code}
> If I remove the ContextControl related code. Then it is constructed only once 
> after boot.
> If I keep the ContextControl related code and remove the observation of 
> ContainerInitialized. Then it is constructed only after shutdown.
> If I keep the ContextControl related code and remove the observation of 
> ContainerShutdown. Then it is constructed only after boot.
> What I expect is it is constructed only once after boot even I keep the 
> ContextControl related code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1208) deltaspike configuration: Variable Replacement in Configured Values is NOT fully stage aware

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1208.
-

> deltaspike configuration: Variable Replacement in Configured Values is NOT 
> fully stage aware
> 
>
> Key: DELTASPIKE-1208
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1208
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.7.1
>Reporter: Valentin Maechler
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.7.2
>
> Attachments: DELTASPIKE-1208.patch
>
>
> using the following apache-deltaspike.properties 
> {code}
> some-service-url=${edge-server-url}/some-service
> edge-server-url=undefined
> edge-server-url.Development=http://development:8081
> edge-server-url.Staging=http://staging:8081
> edge-server-url.Production=http://prod:8081
> {code}
> and executing the following code:
> {code}
> System.out.println("some-service-url="+ConfigResolver.getProjectStageAwarePropertyValue("some-service-url"));
> {code}
> having the following java VM arg set:
> {code}
> -Dorg.apache.deltaspike.ProjectStage=Staging
> {code}
> should result in the output: 
> some-service-url=http://staging:8081/some-service
> I have already contributed a bug fix for DELTASPIKE-1167 - unfortunately that 
> didn't fully solve the issue.
> -I plan to provide a fix for this soon.- [UPDATE] patch added



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1209) Textual fixes for documentation of Data Module

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1209.
-

> Textual fixes for documentation of Data Module
> --
>
> Key: DELTASPIKE-1209
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1209
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module, Documentation
>Reporter: Anthony Vanelverdinghe
>Assignee: John D. Ament
>Priority: Trivial
>  Labels: documentation
> Fix For: 1.7.2
>
>
> * cenertalization -> centralization
> * are outlines -> are outlined
> * simples way -> simplest way
> * of your query DeltaSpike expects -> of your query. DeltaSpike expects
> * While repositories defines several base interfaces -> While several base 
> interfaces are defined for repositories
> * mapResultList(List -> mapResultList(List
> * override two methods -> override three methods
> * Beside keeping track -> Besides keeping track
> * Transactions code example -> add DelegateQueryHandler



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1189) Migrate index.html into git

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1189.
-

> Migrate index.html into git
> ---
>
> Key: DELTASPIKE-1189
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1189
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Documentation
>Reporter: John D. Ament
>Assignee: Andrea Cosentino
> Fix For: 1.7.2
>
> Attachments: index_adoc_reformatting.patch
>
>
> Our index.html is still managed in subversion.  We should move this into git. 
>  Source file can be found at 
> http://svn.apache.org/repos/asf/deltaspike/site/trunk/content/index.html
> It should end up in the site module of the build.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1188) Improve contributor guide

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1188.
-

> Improve contributor guide
> -
>
> Key: DELTASPIKE-1188
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1188
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Documentation
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.7.2
>
>
> Create an improved contributor guide that goes over the github PR process



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1187) Document entity graph support

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1187.
-

> Document entity graph support
> -
>
> Key: DELTASPIKE-1187
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1187
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Documentation
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.7.2
>
>
> Add documentation for the Entity Graph features - 
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/api/src/main/java/org/apache/deltaspike/data/api/EntityGraph.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1194) Distribution not including binary artifacts

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1194.
-

> Distribution not including binary artifacts
> ---
>
> Key: DELTASPIKE-1194
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1194
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.7.0, 1.7.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.7.2
>
>
> The distributions no longer include binary artifacts.  The following output 
> can be seen when building
> {code}
> [WARNING] Cannot include project artifact: 
> org.apache.deltaspike.distribution:distribution-full:pom:1.7.2-SNAPSHOT; it 
> doesn't have an associated file or directory.
> [WARNING] The following patterns were never triggered in this artifact 
> inclusion filter:
> o  'org.apache.deltaspike.modules:*'
> [WARNING] Cannot include project artifact: 
> org.apache.deltaspike.distribution:distribution-full:pom:1.7.2-SNAPSHOT; it 
> doesn't have an associated file or directory.
> [WARNING] The following patterns were never triggered in this artifact 
> inclusion filter:
> o  'org.apache.deltaspike.core:*'
> [WARNING] Cannot include project artifact: 
> org.apache.deltaspike.distribution:distribution-full:pom:1.7.2-SNAPSHOT; it 
> doesn't have an associated file or directory.
> [WARNING] The following patterns were never triggered in this artifact 
> inclusion filter:
> o  'org.apache.deltaspike.cdictrl:*'
> [INFO] Building zip: 
> /Users/spartan/src/deltaspike/deltaspike/dist/full/target/deltaspike-full-1.7.2-SNAPSHOT.zip
> [WARNING] Cannot include project artifact: 
> org.apache.deltaspike.distribution:distribution-full:pom:1.7.2-SNAPSHOT; it 
> doesn't have an associated file or directory.
> [WARNING] The following patterns were never triggered in this artifact 
> inclusion filter:
> o  'org.apache.deltaspike.modules:*'
> [WARNING] Cannot include project artifact: 
> org.apache.deltaspike.distribution:distribution-full:pom:1.7.2-SNAPSHOT; it 
> doesn't have an associated file or directory.
> [WARNING] The following patterns were never triggered in this artifact 
> inclusion filter:
> o  'org.apache.deltaspike.core:*'
> [WARNING] Cannot include project artifact: 
> org.apache.deltaspike.distribution:distribution-full:pom:1.7.2-SNAPSHOT; it 
> doesn't have an associated file or directory.
> [WARNING] The following patterns were never triggered in this artifact 
> inclusion filter:
> o  'org.apache.deltaspike.cdictrl:*'
> [INFO] Building tar: 
> /Users/spartan/src/deltaspike/deltaspike/dist/full/target/deltaspike-full-1.7.2-SNAPSHOT.tar.gz
> [INFO] 
> [INFO] --- maven-checkstyle-plugin:2.9.1:check (verify-style) @ 
> distribution-full ---
> [INFO] Starting audit...
> Audit done.
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1192) Fix increase in warning messages with DeltaSpike Data and Weld

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1192.
-

> Fix increase in warning messages with DeltaSpike Data and Weld
> --
>
> Key: DELTASPIKE-1192
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1192
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Data-Module
>Affects Versions: 1.7.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.7.2
>
>
> https://lists.apache.org/thread.html/8edcc676c2dbede50f7e75cc56c4d78d260357df527347a1ff155402@%3Cusers.deltaspike.apache.org%3E
> Moving from 1.6.x to 1.7.0 and up of DeltaSpike results in an increase in 
> warning logs.  We should identify why, and if needed make fixes to DS to 
> address.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1210) DelegateQueryHandler has missing Javadoc

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1210.
-

> DelegateQueryHandler has missing Javadoc
> 
>
> Key: DELTASPIKE-1210
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1210
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.7.1
>Reporter: Anthony Vanelverdinghe
>Assignee: John D. Ament
>Priority: Trivial
> Fix For: 1.7.2
>
>
> The 
> [Javadoc|https://deltaspike.apache.org/javadoc/1.7.1/org/apache/deltaspike/data/spi/DelegateQueryHandler.html]
>  of DelegateQueryHandler says:
> {quote}
> The extension is now usable with:
> {quote}
> without giving an actual example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1204) Wildfly managed profiles blow up

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1204.
-

> Wildfly managed profiles blow up
> 
>
> Key: DELTASPIKE-1204
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1204
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.7.1
> Environment: Wildfly managed (or build managed)
> Weld 2/3
>Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.7.2
>
>
> Using a Wildfly profile with Weld causes things to blow up when executed with 
> the following command {{mvn clean verify -Pwildfly-managed 
> -Dweld.version=3.0.0.Alpha17 
> -Dmaven.repo.local=/home/manovotn/anotherMvnRepo}}.
> There are two problems I detected so far:
>  # Compilation error (with clean Mvn repo)
>  * CDI control module - weld impl - is based on Weld version passed as 
> parameter
>  * However, currently there is hardcoded cdi-api version in the [wildfly 
> profile|https://github.com/apache/deltaspike/blob/master/deltaspike/parent/code/pom.xml#L1074]
>  * Granted, it is {{provided}}, therefore the tests run fine on the Wildfly 
> server, but the compilation of CDI control module will blow up as it now uses 
> Weld 3.x and CDI 1.1 API
>  # At the moment, the CDI control module uses maven dependency plugin to 
> unpack tck tests as test classes no matter the profile
>  * as can be seen 
> [here|https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-weld/pom.xml#L83]
>  * this makes no sense when running wildfly profile
>  * not to mention you do not have dependency on arq-weld-container so you 
> cannot even execute it
> Proposed solution:
> # A dependency on cdi-api needs to be added to this profile
>  * it cannot be hardcoded (weld 2 used CDI 1.2, but weld 3 keeps up with 
> latest CDI 2 EDR releases)
>  * We can either add a new build property like {{cdi.version}}
>  ** this is all the more error prone
>  ** if you don't pass this in, things get really weird
>  * We can fetch it in by declaring a dep. on a weld artifact, which has it
>  ** e.g. adding a dependency on {{weld-core-impl}} which uses already defined 
> {{weld.version}} will fetch in the required cdi-api as well
>  # Simply extend the Weld1/2/3 profiles and copy the build step into them
>  * it makes no sense to add these sources when running different profiles
> Current draft of what I have in mind can be seen [on top of my 
> branch|https://github.com/manovotn/deltaspike/tree/wflyManagedFix].
> **Comments are welcome as I am not sure what I suggested above is a good 
> way.**
> Note that this should effect builds with Weld 2 and Weld 3 as they both use 
> the very same profile for wildfly. Even  though I currently tested this with 
> Weld 3 only (getting to Weld 2 atm).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1181) Implement tests for Payara

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-1181.
-

> Implement tests for Payara
> --
>
> Key: DELTASPIKE-1181
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1181
> Project: DeltaSpike
>  Issue Type: Task
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.7.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1215) Java8Test failing with EAP 6.4

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1215:
--
Affects Version/s: 1.7.0
Fix Version/s: (was: 1.7.2)
   1.7.3

> Java8Test failing with EAP 6.4
> --
>
> Key: DELTASPIKE-1215
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1215
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Tests
>Affects Versions: 1.7.0, 1.7.1
> Environment: EAP 6.4 (yes, it support Java 8)
> Weld 1.1.33.Final
>Reporter: Matej Novotny
>Assignee: Matej Novotny
>Priority: Minor
> Fix For: 1.7.3
>
>
> EAP 6.4 is executed with {{jbossas-managed-7}} profile which is missing 
> {{persistence.xml}} for this to work.
> Furthermore the test needs to explicitly {{flush()}} the EM, otherwise there 
> is a failure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1214) 1.7.2 Release Tasks

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1214:
-

 Summary: 1.7.2 Release Tasks
 Key: DELTASPIKE-1214
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1214
 Project: DeltaSpike
  Issue Type: Task
  Components: Build
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.7.3






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1052) Support JPA 2.1 EntityGraphs

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1052:
--
Fix Version/s: 1.5.2

> Support JPA 2.1 EntityGraphs
> 
>
> Key: DELTASPIKE-1052
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1052
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module
>Reporter: Harald Wellmann
>Assignee: Harald Wellmann
> Fix For: 1.5.2
>
>
> Support EntityGraphs when running in a JPA 2.1 environment. There shall be no 
> compile-time dependency on JPA 2.1.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1191) Update Test-Control gradle docs

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1191.
---
Resolution: Fixed

Updated docs.

> Update Test-Control gradle docs
> ---
>
> Key: DELTASPIKE-1191
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1191
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Remo
>Assignee: John D. Ament
> Fix For: 1.7.2
>
>
> The suggested solution for gradle/test-control in 
> https://deltaspike.apache.org/documentation/test-control.html results in 
> duplicate class files in the assembled jars, this should be used instead:
> {code}
> // merge resources and classes dir since we are doing JEE/CDI
> sourceSets {
> main {
> output.resourcesDir = 'build/classes/main'
> output.classesDir   = 'build/classes/main'
> }
> test {
> output.resourcesDir = 'build/classes/test'
> output.classesDir   = 'build/classes/test'
> }
> }
> // exclude duplicates since we merge classes and resources dir
> jar {
> duplicatesStrategy = DuplicatesStrategy.EXCLUDE
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1191) Update Test-Control gradle docs

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1191:
--
Fix Version/s: 1.7.2

> Update Test-Control gradle docs
> ---
>
> Key: DELTASPIKE-1191
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1191
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Remo
>Assignee: John D. Ament
> Fix For: 1.7.2
>
>
> The suggested solution for gradle/test-control in 
> https://deltaspike.apache.org/documentation/test-control.html results in 
> duplicate class files in the assembled jars, this should be used instead:
> {code}
> // merge resources and classes dir since we are doing JEE/CDI
> sourceSets {
> main {
> output.resourcesDir = 'build/classes/main'
> output.classesDir   = 'build/classes/main'
> }
> test {
> output.resourcesDir = 'build/classes/test'
> output.classesDir   = 'build/classes/test'
> }
> }
> // exclude duplicates since we merge classes and resources dir
> jar {
> duplicatesStrategy = DuplicatesStrategy.EXCLUDE
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1213) LockedTest fails on OWB 1.1.x

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1213.
---
Resolution: Fixed

Test fixed.

> LockedTest fails on OWB 1.1.x
> -
>
> Key: DELTASPIKE-1213
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1213
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.7.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.7.2
>
>
> Run {{mvn clean install -POWB -Dowb.version=1.1.8 -Dopenejb.owb.version=1.2.6 
> -Dtest=LockedTest}} from the core/impl directory.  See that the JVM just 
> hangs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DELTASPIKE-1213) LockedTest fails on OWB 1.1.x

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-1213:
-

Assignee: John D. Ament

> LockedTest fails on OWB 1.1.x
> -
>
> Key: DELTASPIKE-1213
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1213
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.7.1
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Run {{mvn clean install -POWB -Dowb.version=1.1.8 -Dopenejb.owb.version=1.2.6 
> -Dtest=LockedTest}} from the core/impl directory.  See that the JVM just 
> hangs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DELTASPIKE-1211) SingleResultType.OPTIONAL refers to nonexistent constant SINGLE

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament resolved DELTASPIKE-1211.
---
   Resolution: Fixed
 Assignee: John D. Ament
Fix Version/s: 1.7.2

Merges, thanks for the contrib!

> SingleResultType.OPTIONAL refers to nonexistent constant SINGLE
> ---
>
> Key: DELTASPIKE-1211
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1211
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.7.1
>Reporter: Anthony Vanelverdinghe
>Assignee: John D. Ament
>Priority: Trivial
> Fix For: 1.7.2
>
>
> The 
> [Javadoc|https://deltaspike.apache.org/javadoc/1.7.1/org/apache/deltaspike/data/api/SingleResultType.html#OPTIONAL]
>  of SingleResultType.OPTIONAL refers to the nonexistent constant SINGLE, 
> instead of the intended constant JPA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)