from:"Thomas Hug"

[jira] [Commented] (DELTASPIKE-1290) Enable EntityGraph in findBy method

2017-09-25 Thread Thomas Hug (JIRA)


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

Thomas Hug commented on DELTASPIKE-1290:


Hi [~hwellmann], could you take this over and check if the EntityGraph API is 
used as intended? Thnx!
I guess we should make this consistently available for all {{findBy}} methods 
on {{EntityRepository}}.

> Enable EntityGraph in findBy method
> ---
>
> Key: DELTASPIKE-1290
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1290
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.0
>Reporter: Marcelo Pio de Castro
> Attachments: findByEntityGraph.patch
>
>
> Hi,
> According to @EntityGraph annotation:
> "Defines an entity graph to be applied to a query. This annotation can be 
> added to any query method of a repository class."
> But it don't work in the findBy(PK) and findOptionalBy(PK) methods
> I made a patch that can solve it.



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

[jira] [Commented] (DELTASPIKE-1098) CriteriaTest#should_create_count_criteria fails on OpenJPA / TomEE7

2016-03-23 Thread Thomas Hug (JIRA)


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

Thomas Hug commented on DELTASPIKE-1098:


[~tandraschko] Thanks Thomas, will try to have a look over the Eastern break. 
For count queries we sometimes have to dig into provider internals to get the 
query string, maybe OpenJPA changed APIs in the latest version.

> CriteriaTest#should_create_count_criteria fails on OpenJPA / TomEE7
> ---
>
> Key: DELTASPIKE-1098
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1098
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.6.0
> Environment: data-impl: mvn clean package -P tomee7-build-managed -D 
> tomee.version=7.0.0-M3
>Reporter: Thomas Andraschko
>Assignee: Thomas Hug
>
> It fails currently only in OpenJPA TomEE7.
> [~thomashug]
> could you please have a look at it? maybe it's just a OpenJPA bug.



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

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

2016-01-22 Thread Thomas Hug (JIRA)


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

Thomas Hug commented on DELTASPIKE-940:
---

So by using {{@Transactional(qualifier = ...)}} the point of each qualifier 
added here is to select exactly one {{EntityManager}} instead of all available 
over @Any. Same thing {{EntityManagerResolver}} is used in the Data module for 
(but as you mentioned we have a different concept of 1 EM per repository, so 
the limiting factor is {{@EntityManagerConfig}} on type level).

I don't have a preference for one or the other, the original CDI Query was 
acutally using qualifiers to select the EM for each repository in case multiple 
existed. As mentioned above the major reason for {{EntityManagerResolver}} was 
a consistent approach with the JSF module. Changing one or the other will break 
existing code so not really sure whether something should be changed at all 
(given we have slightly different concepts). Other preferences?

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



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

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

2016-01-22 Thread Thomas Hug (JIRA)


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

Thomas Hug commented on DELTASPIKE-940:
---

Agree, v2 might be a good opportunity to consolidate the API.

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



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

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

2016-01-21 Thread Thomas Hug (JIRA)


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

Thomas Hug commented on DELTASPIKE-940:
---

The main reason to use a resolver approach in the Data module was that there is 
a similar approach in the JSF module (MessageResolver AFAIR) so to stick to 
this also in the JPA module would be overall consistent. 

Another disadvantage of {{@Transactional(qualifier = ...}} is that a qualifier 
is limited to an annotation type. A "proper" qualifier could also include 
arguments, e.g. {{@MyDB(DbSchema.CUSTOMER)}} which wouldn't work with this 
approach. 

Anything speaking against moving {{EntityManagerResolver}} into the JPA module?

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



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

[jira] [Commented] (DELTASPIKE-1045) Convenience repository classes exposing all EntityManager methods

2015-12-29 Thread Thomas Hug (JIRA)


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

Thomas Hug commented on DELTASPIKE-1045:


Shouldn't "full" also include {{CriteriaSupport}}? Or should the name be more 
specific? ({{EntityManagerRepository}}...)?

> Convenience repository classes exposing all EntityManager methods
> -
>
> Key: DELTASPIKE-1045
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1045
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module
>Affects Versions: 1.5.2
>Reporter: Harald Wellmann
>Assignee: Harald Wellmann
> Fix For: 1.5.3
>
>
> For the benefit of DeltaSpike Data users who frequently use {{EntityManager}} 
> methods not exposed by the {{EntityRepository}} API, provide new API classes 
> which do expose these methods by extending or implementing 
> {{EntityManagerDelegate}}:
> {code}
> public interface FullEntityRepository<E, PK extends Serializable>
> extends EntityRepository<E, PK>, EntityManagerDelegate {
> }
> public abstract class AbstractFullEntityRepository<E, PK extends Serializable>
> extends AbstractEntityRepository<E, PK>
> implements EntityManagerDelegate {
> }
> {code}
> This will enable end users to simply write
> {code}
> public interface CustomerRepository extends FullEntityRepository<Customer, 
> Long> {}
> {code}
> to get access to all {{EntityManager}} methods.



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

[jira] [Resolved] (DELTASPIKE-978) ClassCastException with Native Queries

2015-10-05 Thread Thomas Hug (JIRA)


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

Thomas Hug resolved DELTASPIKE-978.
---
Resolution: Fixed

> ClassCastException with Native Queries
> --
>
> Key: DELTASPIKE-978
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-978
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.5.0
>Reporter: Amita Mehta
>Assignee: Thomas Hug
>Priority: Minor
> Fix For: 1.5.2
>
>
> Native Query does not return a correct result type of entity but returns an 
> object which causes ClassCastException
> details:
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201508.mbox/%3C1438890740891-4661333.post%40n4.nabble.com%3E
> workaround:
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201508.mbox/%3CCAJEn2S5FzMaSOavkOu36fmF8WOGSun%2BRTxDRziSFPvV1eWOGmQ%40mail.gmail.com%3E



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

Re: [DISCUSS] Add persist and merge methods to EntityRepository

2015-08-24 Thread Thomas Hug

EntityRepository is optional, so default hierarchy might be misleading here
;) Similar as EntityRepository or CriteriaSupport, EntityManagerDelegate
was rather something to put on top of a repo, that's primarily why I didn't
extend EntityRepository from it. Also I had the impression that having
save, persist and merge would be confusing - seems like that assumption was
not correct :)

On Sun, Aug 23, 2015 at 7:42 PM, John D. Ament johndam...@apache.org
wrote:

 On Sun, Aug 23, 2015 at 12:39 PM Thomas Andraschko 
 andraschko.tho...@gmail.com wrote:

  Thats not required. You can just extend/implement EntityManagerDelegate
 

 Thanks for pointing that out.  I missed that note in the docs.

 Is there a reason that this isn't the default hierarchy?


 
  2015-08-23 17:37 GMT+02:00 Harald Wellmann hwellmann...@gmail.com:
 
   +1
  
   Regards,
   Harald
  
  
  
   Am 22.08.2015 um 03:23 schrieb John D. Ament:
  
   All,
  
   Based on the findings from Harald, and the general issues being seen
  with
   EntityRepository I'd like to propose that we add merge and persist
  methods
   to the EntityRepository interface.
  
   Both methods would delegate down direct to the underlying
  EntityManager's
   methods of the same signature and have the exact same behavior.  This
  will
   give app developers direct access in cases where they want to
 explicitly
   call one or the other.
  
   John

Re: Issues with EntityRepository.save()

2015-08-14 Thread Thomas Hug

Thanks guys for all the effort in digging into the issue here. From a
pragmatic point of view I guess #2 would be my preferred option and then
think about what we should do with that save thing :) Maybe a strategy
pattern similar to what we have for TX would be the way to go.

The documentation does not put a focus on it, but Data is in no way
exclusively dependent on EntityRepository resp. AbstractEntityRepository -
those are just convenience constructs which I have seen in almost any team
I've worked popping up when it comes to JPA usage. With delegates [1] you
can actually build your own convenience base repositories they way they
should be ;) Also other features like criteria support have been moved to
their own interfaces and can be pulled in on demand.

Hope that helps,
Thomas

[1] http://deltaspike.apache.org/documentation/data.html#QueryDelegates

On Thu, Aug 13, 2015 at 6:21 PM, Marvin Toll marvint...@gtcgroup.com
wrote:

 Am in strong agreement with Harald's statement:

 I never really liked the fact that save() blurs the distinction between
 persist() and merge(), and by its very name it encourages users to always
 call save() after changing an entity state which is usually unnecessary and
 sometimes even wrong - so far, I've seen each and every new user of
 DeltaSpike Data doing that.

 Having used near-native JPA2 for about 3.5 years I'm having an awkward
 time mentally mapping the Data module absraction to native JPA.  Said
 another way, I become a bit confused trying to remember how native JPA2
 works and how the DeltaSpike abstraction works.  However, this potential
 criticism is made without me having adequate time/experience with
 DeltaSpike Data... and may simply be my own transition discomfort.


 A wild idea... would you consider a less intrusive abstraction for a Data2
 module?  One that does not try to mirror Spring (or the Repository Pattern)
 but rather seeks to extend the JPA2 API?


 _Marvin

 -Original Message-
 From: Harald Wellmann [mailto:hwellmann...@gmail.com]
 Sent: Wednesday, August 12, 2015 5:46 PM
 To: dev@deltaspike.apache.org
 Subject: Issues with EntityRepository.save()

 This is a quick summary of the issues around EntityRepository.save() that
 seem to exist since 1.4.2.

 I'll create test cases and JIRA issues as time permits, but I think these
 notes may be helpful at this stage to find out whether or not
 incompatibilities experienced by other users have the same root cause.

 According to Javadoc [1], this is what save() does:

 Persist (new entity) or merge the given entity. The distinction on
 calling either method is done based on the primary key field being null or
 not. If this results in wrong behavior for a specific case, consider using
 the EntityManagerDelegate which offers both persist and merge.

 As far as I can see, the description accurately describes the behaviour in
 1.4.1.

 The behaviour was changed in 1.4.2 in an incompatible way without adapting
 the documentation. Since 1.4.2, if the primary key is not null, DeltaSpike
 also runs a database query to check whether an entity with the given key
 exists. If so, it calls merge(), otherwise persist().

 So there are now quite a few cases when save() calls persist() where it
 would have called merge() in 1.4.1.

 Some use cases:

 Use case 1:

 // assume separate transactions.
 foo = save(foo);
 remove(foo);
 foo = save(foo);

 Result in 1.4.1:
 foo is persistent. The second save() is a merge().

 Result in 1.4.2:
 Exception. The second save() is a persist(), since the key no longer
 exists. But then Hibernate complains it cannot persist a detached entity.

 Use case 2:

 Assume a one-to-many association Blog - Comment, both with auto-generated
 identities of type long.

 public Blog createBlog(ListComment comments) {
  Blog = new Blog();
  blog.setComments(comments);
  blog = blogRepository.save(blog);
  blog.getComments().add(new Comment()); }

 Now someone calls createBlog(Arrays.asList(c1, c2)).

 In 1.4.1 this call succeeds. In 1.4.2, there is an
 UnsupportedOperationException since blog.getComments() is immutable.

 In 1.4.1, the identity member is 0. 0 is not null, so save() performs a
 merge(). merge() creates a new blog instance with a new mutable comments
 list (at least with Hibernate (PersistentBag)).

 In 1.4.2, there is no existing blog entity with identity 0, so save()
 calls persist() and returns the original blog instance. Its comments member
 is the result of Arrays.asList() which is immutable.

 Sometimes it is useful to question the things you think you know, like an
 entity with an identity value of 0 or null cannot be persistent. I
 searched the JPA 2.1 spec and did not find a word about zero identities.
 In fact, Eclipselink has an option to *enable* zero identities
 (eclipselink.allow-zero-id).

 The exception from Hibernate is also misleading. Just because an entity
 passed to persist() has a non-null and non-zero key, it does not have to be

Re: Return type of Repository native query

2015-08-11 Thread Thomas Hug

Pushing this one as soon as the release is out.

On Fri, Aug 7, 2015 at 11:22 PM, Daniel Cunha daniels...@gmail.com wrote:

 Very nice!!! :D

 On Fri, Aug 7, 2015 at 5:45 PM, Thomas Hug thomas@gmail.com wrote:

  Hi Daniel
  Thnx yes I can take this one. It's about time I show up in Git history
  again :-)
 
  On Fri, Aug 7, 2015 at 6:19 PM, Daniel Cunha daniels...@gmail.com
 wrote:
 
   Thomas,
  
   if you don't have time to see it,  I can doing on next week.
   Let me know if you have time to fix it
  
   On Fri, Aug 7, 2015 at 1:07 PM, akm ameh...@ford.com wrote:
  
Thanks Thomas for the response.
   
It works with the workaround.
   
Any idea if the bug will be fixed?
Thanks
   
   
   
   
--
View this message in context:
   
  
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Return-type-of-Repository-native-query-tp4661333p4661337.html
Sent from the Apache DeltaSpike Incubator Discussions mailing list
   archive
at Nabble.com.
   
  
  
  
   --
   Best regard,
   Daniel Cunha (soro)
  
 



 --
 Best regard,
 Daniel Cunha (soro)

Re: Return type of Repository native query

2015-08-07 Thread Thomas Hug

Hi Daniel
Thnx yes I can take this one. It's about time I show up in Git history
again :-)

On Fri, Aug 7, 2015 at 6:19 PM, Daniel Cunha daniels...@gmail.com wrote:

 Thomas,

 if you don't have time to see it,  I can doing on next week.
 Let me know if you have time to fix it

 On Fri, Aug 7, 2015 at 1:07 PM, akm ameh...@ford.com wrote:

  Thanks Thomas for the response.
 
  It works with the workaround.
 
  Any idea if the bug will be fixed?
  Thanks
 
 
 
 
  --
  View this message in context:
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Return-type-of-Repository-native-query-tp4661333p4661337.html
  Sent from the Apache DeltaSpike Incubator Discussions mailing list
 archive
  at Nabble.com.
 



 --
 Best regard,
 Daniel Cunha (soro)

Re: Return type of Repository native query

2015-08-07 Thread Thomas Hug

Hi akm

Given it is stated like that in the documentation, I guess we have a bug
here. The code doesn't call the EM with a result class so there's no
mapping happening.
As a workaround, you might specify a @NamedNativeQuery where you can add a
result class and then reference it in the @Query annotation.

Hope that helps,
Thomas


On Thu, Aug 6, 2015 at 9:52 PM, akm ameh...@ford.com wrote:

 I have a simple native query in my repository

 @Query(value = select * from COUNTRY c where c. COUNTRY_C = ?1, isNative
 =
 true)
 public abstract ListCountry findCountryByCode(String countryCode);

 I execute it by the following line –
   ListCountry countryList =
 this.countryRepository.findCountryByCode(this.countryCode);

 I see the right query being executed –
 [EL Finest]: query: Execute query DataReadQuery(sql=select * from COUNTRY
 c
 where c. COUNTRY_C = ?1)

 And my list contains my expected results, but the problem is when I try to
 do any operation on the entity I get an error
 Caused by: java.lang.ClassCastException: [Ljava.lang.Object; incompatible
 with com.domain.Country

 In this test I am just trying to get the names from the country
   for (Country country : countryList) {
 country.getName();
 }

 Casting the result does not work either.
 Shouldn’t the returned objects be of the Entity type?

 What am I doing wrong? How do I get the Entity type result?
 Thanks.




 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Return-type-of-Repository-native-query-tp4661333.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
 at Nabble.com.

Re: Criteria Query specification support?

2015-06-16 Thread Thomas Hug

Hi,
Currently that's not supported. If you need something similar in your
projects, it should be straight forward to implement this as an extension
[1]. But might be worth looking into it to add it to the core API.
Cheers,
Thomas

[1] http://deltaspike.apache.org/documentation/data.html#Extensions

On Mon, Jun 15, 2015 at 5:51 PM, akm ameh...@ford.com wrote:

 Does DeltaSpike Data Module support criteria Queries with specifications
 like
 Spring Data?
 Link for Spring Data -

 http://docs.spring.io/spring-data/jpa/docs/1.3.0.RELEASE/reference/html/jpa.repositories.html
 
 http://docs.spring.io/spring-data/jpa/docs/1.3.0.RELEASE/reference/html/jpa.repositories.html
 

 It would help to have just one interface for all one use case which would
 contain all the queries required by a single use case.
 Right now if a use case has a criteria query, the use case has to have an
 interface and an abstract class for the criteria query.




 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Criteria-Query-specification-support-tp4660910.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
 at Nabble.com.

Re: DeltaSpike Data Module Repository

2015-06-15 Thread Thomas Hug

Yep looks better to me. I'd be rather careful though putting this into the
API (not in that form as it's not clear what it does). If we see a case
later we can still expose it.

On Sun, Jun 14, 2015 at 8:15 AM, Daniel Cunha daniels...@gmail.com wrote:

 Thomas,

 sounds good:

 https://github.com/danielsoro/deltaspike/commit/ff9a42704547a7373421400960a09b056288ca1c
 ?

 On Fri, Jun 12, 2015 at 5:32 PM, Daniel Cunha daniels...@gmail.com
 wrote:

  +1
 
  On Fri, Jun 12, 2015 at 8:42 AM, Thomas Hug thomas@gmail.com
 wrote:
 
  Oooh I see... I should really find time to code here more often. Looks
  like
  I forgot about a lot of this code :-D
 
  Maybe a little refactoring might help to clean this up. E.g. moving the
  applyRestrictions into the QueryInvocationContext (resp. into a class
  being
  called by the context) so it is simpler to reuse it. Being forced to
  extend
  QueryBuilder seems not right to me. WDYT?
 
 
  On Fri, Jun 12, 2015 at 10:52 AM, Daniel Cunha daniels...@gmail.com
  wrote:
 
   Thomas,
  
   Sure!
  
   MethodQueryBuilder already do it. [1]
   I see for Delegate[2], but.. really, I don't know how to apply it
 here.
  :(
  
   [1]
  
  
 
 https://github.com/danielsoro/deltaspike/blob/applyRestrictions/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/MethodQueryBuilder.java#L48
  
   [2]
  
  
 
 https://github.com/danielsoro/deltaspike/blob/applyRestrictions/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/DelegateQueryBuilder.java
  
   On Fri, Jun 12, 2015 at 4:39 AM, Thomas Hug thomas@gmail.com
  wrote:
  
Thanks Daniel for checking! Different reason it doesn't work than I
  had
   in
memory :-)
I think we should go for a general solution and not just for
EntityRepository methods, @Query metadata should be considered for
 any
method expression. The place to change this is probably somewhere in
Delegate- and MethodQueryBuilder.
   
On Fri, Jun 12, 2015 at 4:19 AM, Daniel Cunha daniels...@gmail.com
 
wrote:
   
 Thomas,

 you're right, not work.
 I changed and works now[1], but I don't know if this is the better
  way
   to
 fix it.



   
  
 
 https://github.com/danielsoro/deltaspike/commit/bb02f14731e9c7fd5d20c255bae2a2033617a9b8

 On Thu, Jun 11, 2015 at 4:11 PM, Thomas Hug thomas@gmail.com
 
wrote:

  Using the @Query(hints...) is the place to set the hints with DS
   Data.
  Unfortunately (hope my memory isn't wrong) this currently
 doesn't
   work
 with
  a method expression. As soon as there's a @Query it's not
  considered
   a
  method expression anymore.
 
  Should not be too difficult to change - and should be changed as
  the
 sample
  from Daniel makes totally sense :-) Will check this tomorrow and
create a
  JIRA issue.
 
 
 
  On Thu, Jun 11, 2015 at 5:42 PM, Daniel Cunha 
  daniels...@gmail.com
  wrote:
 
   Hmm..
  
   so, that's should work:
  
   ```
   @Repository
   public interface SimpleRepository extends
  EntityRepositorySimple,
 Long
   {
  
   @Override
   @Query(hints = {@QueryHint(name =
  javax.persistence.cache.storeMode,
   value = BYPASS)})
   ListSimple findAll();
   }
   ```
  
   On Thu, Jun 11, 2015 at 11:53 AM, akm ameh...@ford.com
 wrote:
  
Thanks for the reply.
   
We are creating a framework that all our enterprise
  applications
will
  be
using; so I am looking for a generic solution that I can add
  in a
   abstract
class that then all entities can use.
Basically looking for something like just adding a hint to
 the
 current
AbstractEntityRepository's findAll.
In the solution you mention all the applications would have
 to
  implement
the
findAll for all the entities.
   
What I have currently is the below solution, but now the
   enterprise
framework would have to implement this for all the find
  methods
  provided
   by
the DeltaSpike repository which leads to maintenance issues
  and
thus
negates
a lot of positives that DeltaSpike would provide us.
   
*Current solution -*
public abstract class MyBaseEntityCrudRepositoryENTITY, PK
   extends
Serializable
extends AbstractEntityRepositoryENTITY, Serializable
  implements
Deactivatable {
   
public ListENTITY findAllFromDatabase() {
   
CriteriaQueryENTITY query = this.criteriaQuery();
RootENTITY root = query.from(entityClass());
query = query.select(root);
TypedQueryENTITY typedQuery =
this.entityManager().createQuery(query);
   
typedQuery.setHint

Re: DeltaSpike Data Module Repository

2015-06-12 Thread Thomas Hug

Oooh I see... I should really find time to code here more often. Looks like
I forgot about a lot of this code :-D

Maybe a little refactoring might help to clean this up. E.g. moving the
applyRestrictions into the QueryInvocationContext (resp. into a class being
called by the context) so it is simpler to reuse it. Being forced to extend
QueryBuilder seems not right to me. WDYT?


On Fri, Jun 12, 2015 at 10:52 AM, Daniel Cunha daniels...@gmail.com wrote:

 Thomas,

 Sure!

 MethodQueryBuilder already do it. [1]
 I see for Delegate[2], but.. really, I don't know how to apply it here. :(

 [1]

 https://github.com/danielsoro/deltaspike/blob/applyRestrictions/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/MethodQueryBuilder.java#L48

 [2]

 https://github.com/danielsoro/deltaspike/blob/applyRestrictions/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/DelegateQueryBuilder.java

 On Fri, Jun 12, 2015 at 4:39 AM, Thomas Hug thomas@gmail.com wrote:

  Thanks Daniel for checking! Different reason it doesn't work than I had
 in
  memory :-)
  I think we should go for a general solution and not just for
  EntityRepository methods, @Query metadata should be considered for any
  method expression. The place to change this is probably somewhere in
  Delegate- and MethodQueryBuilder.
 
  On Fri, Jun 12, 2015 at 4:19 AM, Daniel Cunha daniels...@gmail.com
  wrote:
 
   Thomas,
  
   you're right, not work.
   I changed and works now[1], but I don't know if this is the better way
 to
   fix it.
  
  
  
 
 https://github.com/danielsoro/deltaspike/commit/bb02f14731e9c7fd5d20c255bae2a2033617a9b8
  
   On Thu, Jun 11, 2015 at 4:11 PM, Thomas Hug thomas@gmail.com
  wrote:
  
Using the @Query(hints...) is the place to set the hints with DS
 Data.
Unfortunately (hope my memory isn't wrong) this currently doesn't
 work
   with
a method expression. As soon as there's a @Query it's not considered
 a
method expression anymore.
   
Should not be too difficult to change - and should be changed as the
   sample
from Daniel makes totally sense :-) Will check this tomorrow and
  create a
JIRA issue.
   
   
   
On Thu, Jun 11, 2015 at 5:42 PM, Daniel Cunha daniels...@gmail.com
wrote:
   
 Hmm..

 so, that's should work:

 ```
 @Repository
 public interface SimpleRepository extends EntityRepositorySimple,
   Long
 {

 @Override
 @Query(hints = {@QueryHint(name =
javax.persistence.cache.storeMode,
 value = BYPASS)})
 ListSimple findAll();
 }
 ```

 On Thu, Jun 11, 2015 at 11:53 AM, akm ameh...@ford.com wrote:

  Thanks for the reply.
 
  We are creating a framework that all our enterprise applications
  will
be
  using; so I am looking for a generic solution that I can add in a
 abstract
  class that then all entities can use.
  Basically looking for something like just adding a hint to the
   current
  AbstractEntityRepository's findAll.
  In the solution you mention all the applications would have to
implement
  the
  findAll for all the entities.
 
  What I have currently is the below solution, but now the
 enterprise
  framework would have to implement this for all the find methods
provided
 by
  the DeltaSpike repository which leads to maintenance issues and
  thus
  negates
  a lot of positives that DeltaSpike would provide us.
 
  *Current solution -*
  public abstract class MyBaseEntityCrudRepositoryENTITY, PK
 extends
  Serializable
  extends AbstractEntityRepositoryENTITY, Serializable implements
  Deactivatable {
 
  public ListENTITY findAllFromDatabase() {
 
  CriteriaQueryENTITY query = this.criteriaQuery();
  RootENTITY root = query.from(entityClass());
  query = query.select(root);
  TypedQueryENTITY typedQuery =
  this.entityManager().createQuery(query);
 
  typedQuery.setHint(javax.persistence.cache.retrieveMode,
  CacheRetrieveMode.BYPASS);
 
  return typedQuery.getResultList();
 
  }
 
 
  *I am looking for something easier method to add like -*
  /**
   * @see
  org.apache.deltaspike.data.api.EntityRepository#findAll()
   */
  @Override
  @QueryHint(javax.persistence.cache.storeMode,
  CacheRetrieveMode.BYPASS)
  public ListENTITY findAll() {
   return super.findAll();
  }
 
 
 
 
  --
  View this message in context:
 

   
  
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/DeltaSpike-Data-Module-Repository-tp4660831p4660840.html
  Sent from the Apache DeltaSpike Incubator Discussions mailing
 list
 archive
  at Nabble.com.
 



 --
 Best

[jira] [Commented] (DELTASPIKE-700) Add #tableName() to AbstractEntityRepository

2015-06-11 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581731#comment-14581731
 ] 

Thomas Hug commented on DELTASPIKE-700:
---

Put some comments on the PR, looks good overall!

 Add #tableName() to AbstractEntityRepository
 

 Key: DELTASPIKE-700
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-700
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Data-Module
Reporter: Thomas Andraschko
Assignee: Daniel Cunha (soro)
Priority: Minor

 As table names can easiely be changed via @Table, it would be an typesafe 
 usage to get the native table name for native queries
 e.g.
 @Table(name = tbl_MyEntity)
 public class MyEntity...



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

Re: DeltaSpike Data Module Repository

2015-06-11 Thread Thomas Hug

Using the @Query(hints...) is the place to set the hints with DS Data.
Unfortunately (hope my memory isn't wrong) this currently doesn't work with
a method expression. As soon as there's a @Query it's not considered a
method expression anymore.

Should not be too difficult to change - and should be changed as the sample
from Daniel makes totally sense :-) Will check this tomorrow and create a
JIRA issue.



On Thu, Jun 11, 2015 at 5:42 PM, Daniel Cunha daniels...@gmail.com wrote:

 Hmm..

 so, that's should work:

 ```
 @Repository
 public interface SimpleRepository extends EntityRepositorySimple, Long
 {

 @Override
 @Query(hints = {@QueryHint(name = javax.persistence.cache.storeMode,
 value = BYPASS)})
 ListSimple findAll();
 }
 ```

 On Thu, Jun 11, 2015 at 11:53 AM, akm ameh...@ford.com wrote:

  Thanks for the reply.
 
  We are creating a framework that all our enterprise applications will be
  using; so I am looking for a generic solution that I can add in a
 abstract
  class that then all entities can use.
  Basically looking for something like just adding a hint to the current
  AbstractEntityRepository's findAll.
  In the solution you mention all the applications would have to implement
  the
  findAll for all the entities.
 
  What I have currently is the below solution, but now the enterprise
  framework would have to implement this for all the find methods provided
 by
  the DeltaSpike repository which leads to maintenance issues and thus
  negates
  a lot of positives that DeltaSpike would provide us.
 
  *Current solution -*
  public abstract class MyBaseEntityCrudRepositoryENTITY, PK extends
  Serializable
  extends AbstractEntityRepositoryENTITY, Serializable implements
  Deactivatable {
 
  public ListENTITY findAllFromDatabase() {
 
  CriteriaQueryENTITY query = this.criteriaQuery();
  RootENTITY root = query.from(entityClass());
  query = query.select(root);
  TypedQueryENTITY typedQuery =
  this.entityManager().createQuery(query);
  typedQuery.setHint(javax.persistence.cache.retrieveMode,
  CacheRetrieveMode.BYPASS);
 
  return typedQuery.getResultList();
 
  }
 
 
  *I am looking for something easier method to add like -*
  /**
   * @see org.apache.deltaspike.data.api.EntityRepository#findAll()
   */
  @Override
  @QueryHint(javax.persistence.cache.storeMode,
  CacheRetrieveMode.BYPASS)
  public ListENTITY findAll() {
   return super.findAll();
  }
 
 
 
 
  --
  View this message in context:
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/DeltaSpike-Data-Module-Repository-tp4660831p4660840.html
  Sent from the Apache DeltaSpike Incubator Discussions mailing list
 archive
  at Nabble.com.
 



 --
 Best regard,
 Daniel Cunha (soro)

[jira] [Commented] (DELTASPIKE-894) Trim for CriteriaSupport API

2015-06-08 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577290#comment-14577290
 ] 

Thomas Hug commented on DELTASPIKE-894:
---

Looks good on the API side. For the impl I'd use a single Trim and always trim 
with a Trimspec - use the default BOTH if not specified by the user.

 Trim for CriteriaSupport API
 

 Key: DELTASPIKE-894
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-894
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Data-Module
Reporter: Daniel Cunha (soro)
Assignee: Thomas Hug
Priority: Minor
 Attachments: DELTASPIKE-894.patch






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

[jira] [Commented] (DELTASPIKE-701) Add method in EntityRepository to merge a detached entity and remove it

2015-06-08 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577283#comment-14577283
 ] 

Thomas Hug commented on DELTASPIKE-701:
---

Looks good to me too.

 Add method in EntityRepository to merge a detached entity and remove it
 ---

 Key: DELTASPIKE-701
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-701
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Juliano Marques
Assignee: Thomas Hug
 Attachments: DELTASPIKE-701.patch


 It will be nice if EntityRepository has a method like:
 public void attachAndRemove(Entity entity) {
 if (entityManager.contains(entity)) {
 entityManager.remove(entity);
 } else {
 entityManager.remove(entityManager.merge(entity));
 }
 }
 This method will be useful to handle java.lang.IllegalArgumentException: 
 Removing a detached instance exceptions.
 Workaround: Create a query delegate with this method.
 http://mail-archives.apache.org/mod_mbox/deltaspike-users/201408.mbox/%3CCAAuOd%3DXhb%3D-ssdzU%3DTdxWg8d18XXC15U7EjNiGya9eEgaA%2BUpA%40mail.gmail.com%3E



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

Re: Data Module Changes

2015-06-03 Thread Thomas Hug

Sorry for being the bottleneck here - currently on holidays but will be
back next week.

Cheers,
Thomas

On Thu, May 28, 2015 at 8:53 PM, Daniel Cunha daniels...@gmail.com wrote:

 Hi folks,

 I submitted two patch to change the api in EntityReposity and Critreia.

 https://issues.apache.org/jira/browse/DELTASPIKE-701
 https://issues.apache.org/jira/browse/DELTASPIKE-894

 I have a good support of the Rafael Benevides about this issues, but we
 need to a second  opnion to fix it.

 --
 Best regard,
 Daniel Cunha (soro)

Re: CriteriaSupport API

2015-05-15 Thread Thomas Hug

Wow, thnx for churning out those fixes! :) (and also to Rafael for
reviewing!) Will take some time for me to get to it but will try to do this
asap.
Cheers,
Thomas

On Thu, May 14, 2015 at 10:17 PM, Daniel Cunha daniels...@gmail.com wrote:

 Hi Thomas,

 I've working in some issues and I would like to send my result on work in
 DS.
 I have attached patch for:
 https://issues.apache.org/jira/browse/DELTASPIKE-603
 https://issues.apache.org/jira/browse/DELTASPIKE-894
 https://issues.apache.org/jira/browse/DELTASPIKE-701
 https://issues.apache.org/jira/browse/DELTASPIKE-902

 I had an help of the Rafael Benevides (rbenevides), he reviewed my patchs
 in (DELTASPIKE-894,  DELTASPIKE-701).
 Let me know if the patchs is good or need improvement. I would like to help
 more :)

 I'll start work on DELTASPIKE-901.
 See you. Thank you.

 On Wed, May 13, 2015 at 1:10 PM, Daniel Cunha daniels...@gmail.com
 wrote:

  Hi Thomas,
 
  I'm looking to DELTASPIKE-701 and DELTASPIKE-603
  I'm preparing to start with DELTASPIKE-603. Do you have something for it
  or did something?
  I would like to fix it, if you don't have time to do. :)
 
  On Wed, May 13, 2015 at 1:00 PM, Thomas Hug thomas@gmail.com
 wrote:
 
  Hi Daniel
  I definitely don't have as much time for DS as I'd like to have (right
 now
  close to none ;) so any help is welcome :). Let me know if you have any
  specific issue in mind and we can check what's needed.
  Cheers,
  Thomas
 
  On Wed, May 13, 2015 at 12:13 AM, Daniel Cunha daniels...@gmail.com
  wrote:
 
   Hi Thomas,
  
   I can to see that we have some issues opened and not fixed if you
 want I
   can try help you with this tasks.
   Let me know if you need help to fix another issues in data-module. :)
  
   On Mon, May 11, 2015 at 4:55 AM, Thomas Hug thomas@gmail.com
  wrote:
  
Hi Daniel
   
Thanks for the patch! I should have some bandwidth the next week to
 do
   some
DS coding and take care about it.
There's indeed room for improvement for the criteria API. I was not
   really
sure how useful people find it and started with a simplified
 version,
  but
if it gets more adoption it's definitely worth filling the gaps.
  Feedback
and PRs always welcome :)
   
Cheers,
Thomas
   
On Fri, May 8, 2015 at 10:51 PM, Daniel Cunha daniels...@gmail.com
 
wrote:
   
 Hi folks,

 I started to change something in data-module, I don't know if we
  have
time
 to do it, but, let me know if DELTASPIKE-894 could be apply in
 next
 release.

 We don't support all methods. Do we want support for all methods?
 I can to see that some methods like 'isTrue', 'isFalse', etc.. of
  the
 Criteria not is supported by DS data-module.

 --
 Best regard,
 Daniel Cunha (soro)

   
  
  
  
   --
   Best regard,
   Daniel Cunha (soro)
  
 
 
 
 
  --
  Best regard,
  Daniel Cunha (soro)
 



 --
 Best regard,
 Daniel Cunha (soro)

Re: CriteriaSupport API

2015-05-13 Thread Thomas Hug

Hi Daniel
I definitely don't have as much time for DS as I'd like to have (right now
close to none ;) so any help is welcome :). Let me know if you have any
specific issue in mind and we can check what's needed.
Cheers,
Thomas

On Wed, May 13, 2015 at 12:13 AM, Daniel Cunha daniels...@gmail.com wrote:

 Hi Thomas,

 I can to see that we have some issues opened and not fixed if you want I
 can try help you with this tasks.
 Let me know if you need help to fix another issues in data-module. :)

 On Mon, May 11, 2015 at 4:55 AM, Thomas Hug thomas@gmail.com wrote:

  Hi Daniel
 
  Thanks for the patch! I should have some bandwidth the next week to do
 some
  DS coding and take care about it.
  There's indeed room for improvement for the criteria API. I was not
 really
  sure how useful people find it and started with a simplified version, but
  if it gets more adoption it's definitely worth filling the gaps. Feedback
  and PRs always welcome :)
 
  Cheers,
  Thomas
 
  On Fri, May 8, 2015 at 10:51 PM, Daniel Cunha daniels...@gmail.com
  wrote:
 
   Hi folks,
  
   I started to change something in data-module, I don't know if we have
  time
   to do it, but, let me know if DELTASPIKE-894 could be apply in next
   release.
  
   We don't support all methods. Do we want support for all methods?
   I can to see that some methods like 'isTrue', 'isFalse', etc.. of the
   Criteria not is supported by DS data-module.
  
   --
   Best regard,
   Daniel Cunha (soro)
  
 



 --
 Best regard,
 Daniel Cunha (soro)

Re: CriteriaSupport API

2015-05-11 Thread Thomas Hug

Hi Daniel

Thanks for the patch! I should have some bandwidth the next week to do some
DS coding and take care about it.
There's indeed room for improvement for the criteria API. I was not really
sure how useful people find it and started with a simplified version, but
if it gets more adoption it's definitely worth filling the gaps. Feedback
and PRs always welcome :)

Cheers,
Thomas

On Fri, May 8, 2015 at 10:51 PM, Daniel Cunha daniels...@gmail.com wrote:

 Hi folks,

 I started to change something in data-module, I don't know if we have time
 to do it, but, let me know if DELTASPIKE-894 could be apply in next
 release.

 We don't support all methods. Do we want support for all methods?
 I can to see that some methods like 'isTrue', 'isFalse', etc.. of the
 Criteria not is supported by DS data-module.

 --
 Best regard,
 Daniel Cunha (soro)

[jira] [Resolved] (DELTASPIKE-886) Add ignoreCase() to the criteria API

2015-04-30 Thread Thomas Hug (JIRA)


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

Thomas Hug resolved DELTASPIKE-886.
---
Resolution: Fixed

 Add ignoreCase() to the criteria API
 

 Key: DELTASPIKE-886
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-886
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.3.0
Reporter: Peter Ranegger
Assignee: Thomas Hug

 ignoreCase has recently been added for method expressions but for the
 criteria API it is still missing.



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

[jira] [Assigned] (DELTASPIKE-886) Add ignoreCase() to the criteria API

2015-04-29 Thread Thomas Hug (JIRA)


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

Thomas Hug reassigned DELTASPIKE-886:
-

Assignee: Thomas Hug

 Add ignoreCase() to the criteria API
 

 Key: DELTASPIKE-886
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-886
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.3.0
Reporter: Peter Ranegger
Assignee: Thomas Hug

 ignoreCase has recently been added for method expressions but for the
 criteria API it is still missing.



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

[jira] [Commented] (DELTASPIKE-871) save() and findByxxx() in same transaction gives constraint violation exception

2015-04-08 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485241#comment-14485241
 ] 

Thomas Hug commented on DELTASPIKE-871:
---

Which transaction strategy do you have configured?

 save() and findByxxx() in same transaction gives constraint violation 
 exception
 ---

 Key: DELTASPIKE-871
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-871
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.2.0
 Environment: Windows-7, Java-8, Netbeans-8.0.2
Reporter: Md Kamaruzzaman
Assignee: Thomas Hug

 It seems like when in the same EJB transaction, save() and findByxxx() is 
 called, then delta-spike inserts the entity twice [once in save() and other 
 time in findByxxx()] and gives a constraint violation exception. 
 After some debuggin, it seems like save() gives a INSERT query in DB and 
 findByxxx() method calls a flush which again gives the same INSERT query in 
 DB [INSERT query from save() is not removed from EntityManager] and gives 
 constraint violation exception.



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

[jira] [Commented] (DELTASPIKE-822) Repository method lookup in super interfaces

2015-03-31 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14388167#comment-14388167
 ] 

Thomas Hug commented on DELTASPIKE-822:
---

Thnx a lot Daniel - I'm currently very short of time but will try to integrate 
it over Eastern holidays.

 Repository method lookup in super interfaces
 

 Key: DELTASPIKE-822
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-822
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.2.1
Reporter: Daniel Heinrich
Assignee: Thomas Hug

 When repository methods are looked up only methods from interfaces which are 
 implemented directly by the repository class or a super class are considered.
 In the case of:
 interface BaseRepositoryT extends EntityRepositoryT,Long
 @Repository
 interface UserRepository extends BaseRepositoryUser
 The UserRepository does not have any default repository methods at runtime.
 NullPointerException at:
 QueryHandler#createContext-CdiQueryInvocationContext()
 this could be fixed at:
 org.apache.deltaspike.data.impl.meta.RepositoryComponent#collectClasses



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

Re: multithreaded repository issues

2015-03-16 Thread Thomas Hug

Thanks! Hope I'll get some time soon to have a detailed look.

RE concurrency: My initial impression is that calling Runnables out of a
@Singleton with a @RequestScoped EM might lead to interesting results ;-)
Probably we have to sort this out first.

On Mon, Mar 16, 2015 at 12:57 PM, hwaastad he...@waastad.org wrote:

 Hi guys,

 made a simple project:

 https://github.com/hwaastad/DeltaDataPerformance.git

 two IT's
 one using em only and the other ds repository.

 Tune number of generated records in abstractContainerTest.

 Please mind that I've not made any timer interceptors for providing time,
 but then again both tests use the same strategy.
 It's just made for proving difference.

 Some details:
 TomEE 1.7.1 as container
 eclipselink 2.5.2
 hsql embedded in tomee as db

 You may choose to use another db by changing datasource in
 container.properties.

 br,
 hw



 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132p4660152.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
 at Nabble.com.

Re: multithreaded repository issues

2015-03-16 Thread Thomas Hug

Static information and validation is indeed computed after bean discovery,
but there are various injections happening during each call. Might also be
interesting to see how different scopes can impact performance (e.g.
AppScoped repositories vs. dependent).

On Sun, Mar 15, 2015 at 10:42 PM, Karl Kildén karl.kil...@gmail.com wrote:

 Hello,

 I have not really noticed any perf issues with deltaspike data but then
 again I did not measure it either. We use it a lot. Would be great to learn
 more about it for sure.

 I always assumed the method name query syntax and the other static stuff
 would be cached etc so I don't really get why it would be any major penalty
 all though I understand each abstraction will have some kind of impact...




 On 15 March 2015 at 21:40, hwaastad he...@waastad.org wrote:

  Hi guys,
  and thanks for answering.
 
  I'll try to get something out on github tomorrow.
 
  Br hw
 
 
 
  --
  View this message in context:
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132p4660145.html
  Sent from the Apache DeltaSpike Incubator Discussions mailing list
 archive
  at Nabble.com.

[jira] [Commented] (DELTASPIKE-420) Transactional repositories

2015-03-09 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14352786#comment-14352786
 ] 

Thomas Hug commented on DELTASPIKE-420:
---

On Wildfly I would have first tried the combination of 
{code}ContainerManagedTransactionStrategy{code} with a 
@javax.transaction.Transactional annotation. Sorry didn't have time yet to look 
at the new partial bean stuff yet.

 Transactional repositories
 --

 Key: DELTASPIKE-420
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-420
 Project: DeltaSpike
  Issue Type: New Feature
  Components: Data-Module
Affects Versions: 0.5
Reporter: Harald Wellmann
Assignee: Jozef Hartinger
 Fix For: 1.3.0

 Attachments: DELTASPIKE-420_spi.patch


 It's nice to get semi-automatic repositories from DeltaSpike Data, but these 
 repositories would be even more fun if they were transactional, not 
 necessarily by default, but at least by simple configuration.
 Possible approaches:
 1) Add @Transactional to an abstract repository class, i.e. 
 javax.transaction.Transactional in Java EE 7, or 
 org.apache.deltaspike.jpa.api.transaction.Transactional otherwise.
 Currently, this does not work due to DELTASPIKE-419.
 2) Make it easy to override the @Repository binding or the query handler, to 
 add transactional behaviour.



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

Re: Unable to enable alternative BeanManagedUserTransactionStrategy

2015-03-02 Thread Thomas Hug

Hi Ove

ActiveEntityManagerHolder gets populated in a Data module repository so the
TXStrategy can use the same EntityManager as the repository. EMs with
qualifiers have to be resolved there slightly different, see
http://deltaspike.apache.org/documentation/data.html#_using_multiple_code_entitymanager_code

Cheers,
Thomas


On Mon, Mar 2, 2015 at 8:54 AM, Ove Ranheim oranh...@gmail.com wrote:

 Hi Gerhard,

 Please have a look at this Gist:
 https://gist.github.com/oranheim/97e65c33ef1ed58fdcac 
 https://gist.github.com/oranheim/97e65c33ef1ed58fdcac

 The reason for the exception below, was due to wrong JNDI lookup in
 BeanManagedUserTransactionStrategy. Now that I’ve fixed that, it turns out
 BeanManagedUserTransactionStrategy#resolveEntityManagerForQualifier is not
 able to resolve my EntityManager.

 I made a simple test to check if ActiveEntityManagerHolder is able to
 resolve my @Inject @PartsRepository EntityManager. When the EM is
 injectedon the test case it works. But not in the
 BeanManagedUserTransactionStrategy#resolveEntityManagerForQualifier,
 because ActiveEntityManagerHolder.get() returns null.

 Is something wrong with my EntityManager producer (see gist)?

 Br, Ove


  On 02 Mar 2015, at 00:05, Gerhard Petracek gerhard.petra...@gmail.com
 wrote:
 
  hi ove,
 
  please provide more details about your setup.
 
  regards,
  gerhard
 
 
 
  2015-03-01 23:47 GMT+01:00 Ove Ranheim oranh...@gmail.com:
 
  Hi,
 
  I’m get an error when I try to enable the
  BeanManagedUserTransactionStrategy in beans.xml.
 
  Any ideas?
 
  Ove
 
  org.jboss.weld.exceptions.DeploymentException: WELD-001422: Enabled
  alternative
 
 classorg.apache.deltaspike.jpa.impl.transaction.BeanManagedUserTransactionStrategy/class
  in
 
 file:/.../parts-backend/persistence/impl/target/test-classes/META-INF/beans.xml@19
  is not an alternative
 at
 
 org.jboss.weld.bootstrap.Validator.validateEnabledAlternativeClasses(Validator.java:725)
 at
 
 org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:483)
 at
  org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:437)
 at
 
 org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
 at org.jboss.weld.environment.se.Weld.initialize(Weld.java:151)
 at
 
 org.apache.deltaspike.cdise.weld.WeldContainerControl.boot(WeldContainerControl.java:65)
 at
 
 org.apache.deltaspike.cdise.weld.WeldContainerControl.boot(WeldContainerControl.java:73)
 at
 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareTestContext.applyBeforeClassConfig(CdiTestRunner.java:462)
 at
 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:365)
 at
 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:392)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
 at
 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.run(CdiTestRunner.java:141)
 at
 
 com.parts.mock.undertow.api.PartsTestRunner.run(PartsTestRunner.java:154)
 at org.junit.runners.Suite.runChild(Suite.java:128)
 at org.junit.runners.Suite.runChild(Suite.java:24)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
 at
 org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
 at
  org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
 at
 org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
 at
 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
 at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
 at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
 at
 
 org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:141)
 at
 
 org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:114)
 at
 
 org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:86)
 at
 
 org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
 at
 
 org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
 at
 
 org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
 at
 
 org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

[jira] [Commented] (DELTASPIKE-836) Support case insensitive LIKE queries with method naming convention

2015-02-24 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334721#comment-14334721
 ] 

Thomas Hug commented on DELTASPIKE-836:
---

Great, thnx! I'll update documentation later this week as well.

 Support case insensitive LIKE queries with method naming convention
 ---

 Key: DELTASPIKE-836
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-836
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.2.1
Reporter: Matti Tahvonen
Assignee: Thomas Hug

 Currently there is no way to create a basic filtering method with naming 
 convention only, because to make decent UI, the filtering should ignore case 
 of the strings some way. Easiest way to solve this would be to support 
 IgnoreCase in the end of the method that would ignore case for all string 
 properties.



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

[jira] [Resolved] (DELTASPIKE-836) Support case insensitive LIKE queries with method naming convention

2015-02-23 Thread Thomas Hug (JIRA)


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

Thomas Hug resolved DELTASPIKE-836.
---
Resolution: Fixed

 Support case insensitive LIKE queries with method naming convention
 ---

 Key: DELTASPIKE-836
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-836
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.2.1
Reporter: Matti Tahvonen
Assignee: Thomas Hug

 Currently there is no way to create a basic filtering method with naming 
 convention only, because to make decent UI, the filtering should ignore case 
 of the strings some way. Easiest way to solve this would be to support 
 IgnoreCase in the end of the method that would ignore case for all string 
 properties.



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

[jira] [Assigned] (DELTASPIKE-836) Support case insensitive LIKE queries with method naming convention

2015-02-23 Thread Thomas Hug (JIRA)


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

Thomas Hug reassigned DELTASPIKE-836:
-

Assignee: Thomas Hug

 Support case insensitive LIKE queries with method naming convention
 ---

 Key: DELTASPIKE-836
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-836
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.2.1
Reporter: Matti Tahvonen
Assignee: Thomas Hug

 Currently there is no way to create a basic filtering method with naming 
 convention only, because to make decent UI, the filtering should ignore case 
 of the strings some way. Easiest way to solve this would be to support 
 IgnoreCase in the end of the method that would ignore case for all string 
 properties.



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

[jira] [Commented] (DELTASPIKE-836) Support case insensitive LIKE queries with method naming convention

2015-02-23 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14333122#comment-14333122
 ] 

Thomas Hug commented on DELTASPIKE-836:
---

IgnoreCase should probably be related to the expression attributes, e.g. 
findByNameIgnoreCaseAndAgeBetween

 Support case insensitive LIKE queries with method naming convention
 ---

 Key: DELTASPIKE-836
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-836
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.2.1
Reporter: Matti Tahvonen
Assignee: Thomas Hug

 Currently there is no way to create a basic filtering method with naming 
 convention only, because to make decent UI, the filtering should ignore case 
 of the strings some way. Easiest way to solve this would be to support 
 IgnoreCase in the end of the method that would ignore case for all string 
 properties.



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

[jira] [Resolved] (DELTASPIKE-683) user criteria() error

2015-01-23 Thread Thomas Hug (JIRA)


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

Thomas Hug resolved DELTASPIKE-683.
---
Resolution: Cannot Reproduce

No feedback here - assuming test has not been run in a Java EE env providing an 
EM.

 user  criteria() error
 --

 Key: DELTASPIKE-683
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-683
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.0.1, 1.0.2
 Environment: ds1.0 jdk1.7 
Reporter: kingli
Assignee: Thomas Hug

 Use the following code, this method throws an exception
 @Test
 public void injectionTest(){
   personRepository.searchAll(king8);
 }
 @Repository(forEntity = Person.class)
 public abstract class PersonRepository extends BaseRepositoryPerson, Long 
 implements IPersonRepository {
   @Override
   public ListPerson searchAll(String v) {
   CriteriaPerson, Person c = criteria();
   c.eq(Person_.name,king);
 return c.getResultList();
 }
 }
 八月 08, 2014 6:00:23 下午 org.apache.deltaspike.data.impl.criteria.QueryCriteria 
 createQuery
 严重: Exception while creating JPA query
 java.lang.NullPointerException
   at 
 org.hibernate.ejb.criteria.path.AbstractPathImpl.get(AbstractPathImpl.java:146)
   at 
 org.apache.deltaspike.data.impl.criteria.predicate.Eq.build(Eq.java:40)
   at 
 org.apache.deltaspike.data.impl.criteria.QueryCriteria.predicates(QueryCriteria.java:283)
   at 
 org.apache.deltaspike.data.impl.criteria.QueryCriteria.createQuery(QueryCriteria.java:147)
   at 
 org.apache.deltaspike.data.impl.criteria.QueryCriteria.getResultList(QueryCriteria.java:106)
   at 
 com.lhl.common.biz.dictionary.repo.PersonRepository.searchAll(PersonRepository.java:19)
   at 
 com.lhl.common.biz.dictionary.repo.PersonRepository_$$_javassist_0._d71searchAll(PersonRepository_$$_javassist_0.java)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.apache.deltaspike.partialbean.impl.PartialBeanAbstractMethodHandler.invoke(PartialBeanAbstractMethodHandler.java:42)
   at 
 org.apache.deltaspike.partialbean.impl.MethodHandlerProxy.invoke(MethodHandlerProxy.java:35)
   at com.sun.proxy.$Proxy72.invoke(Unknown Source)
   at 
 com.lhl.common.biz.dictionary.repo.PersonRepository_$$_javassist_0.searchAll(PersonRepository_$$_javassist_0.java)
   at 
 com.lhl.common.biz.dictionary.repo.PersonTest.injectionTest(PersonTest.java:38)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.invokeMethod(CdiTestRunner.java:335)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.evaluate(CdiTestRunner.java:307)
   at 
 org.apache.deltaspike.testcontrol.impl.transaction.TransactionStatementDecoratorFactory$TransactionAwareRunAfters.evaluate(TransactionStatementDecoratorFactory.java:91)
   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:169)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:67)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$BeforeClassStatement.evaluate(CdiTestRunner.java:361)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$AfterClassStatement.evaluate(CdiTestRunner.java:387

[jira] [Resolved] (DELTASPIKE-714) QueryResult.count not work if jpql have order by

2015-01-23 Thread Thomas Hug (JIRA)


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

Thomas Hug resolved DELTASPIKE-714.
---
Resolution: Fixed

 QueryResult.count not work if  jpql have  order by 
 ---

 Key: DELTASPIKE-714
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-714
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.0.2
Reporter: chunlinyao
Assignee: Thomas Hug

 I have a entity which have a field scannedDate, create a repository with 
 method findByXXX() which return a QueryResult.
 If I call QueryResult.orderAsc(scannedDate).count(), this error will 
 happen. 
 ERROR: column t0.scanneddate must appear in the GROUP BY clause or be used 
 in an aggregate function
 I use openjpa 2.2, We cannot  simply remove the order by, Because if we 
 order by a attribute of associated entity like order by e.foo.bar, JPA engine 
 will generate a inner join, if we simply remove the order by the count 
 result will not correct.
 Maybe this is not a bug, just a limitation.



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

[jira] [Commented] (DELTASPIKE-759) 1.0.3 breaks abstractentityrepositories in ear project

2015-01-07 Thread Thomas Hug (JIRA)

[
https://issues.apache.org/jira/browse/DELTASPIKE-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267472#comment-14267472
]

Thomas Hug commented on DELTASPIKE-759:
---

Tested with v1.2.1 and it seems everything runs fine again. Can you confirm
that?

1.0.3 breaks abstractentityrepositories in ear project
--

Key: DELTASPIKE-759
URL: https://issues.apache.org/jira/browse/DELTASPIKE-759
Project: DeltaSpike
Issue Type: Bug
Components: Data-Module
Affects Versions: 1.0.3
Environment: openjdk 1.7
ubuntu 14.04
tomee 1.7.1
Reporter: Helge Waastad
Assignee: Thomas Hug

In dialog woith Thomas Hug, I've decided to file a bug report.
https://github.com/hwaastad/DeltaspikeEnterprise.git
A simple EAR project having ear,ejb,web and a jpa module.
Using containermanagedtransactionstrategy in beans.xml, jta em producer and
jta in persistence.xml
A simple timerservice is started by a servletcontextlistener in web module.
timer is just persisting a dummy person object using a remote EJB in ejb
module (because my current production environment is a distributed setup)
Before 1.0.3 this has been working smooth as silk, however in 1.0.3 all bad
things happen.
1. parent pom has a deltaspike.version set to 1.0.3
2. compile project
3. in ear module, do mvn tomee:run (fires up a TomEE 1.7.1)
4. Verify repositories are failing
5. set version 1.0.2 and recompile
6. mvn tomee:run and verify its working ok
It is also possible to compile war module using a standalone profile and mvn
tomee:run in wen module will verify its working fine in bothe 1.0.2 AND 1.0.3
I have also made a simple openejb test aswell in another project which I
happily will provide if needed/necessary
br hw

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

[jira] [Commented] (DELTASPIKE-759) 1.0.3 breaks abstractentityrepositories in ear project

2015-01-07 Thread Thomas Hug (JIRA)

[
https://issues.apache.org/jira/browse/DELTASPIKE-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14268041#comment-14268041
]

Thomas Hug commented on DELTASPIKE-759:
---

Don't think something changed on the data module between those releases, but
I'm happy if it works fine ;-) Resolving the issue then.

1.0.3 breaks abstractentityrepositories in ear project
--

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

[jira] [Closed] (DELTASPIKE-759) 1.0.3 breaks abstractentityrepositories in ear project

2015-01-07 Thread Thomas Hug (JIRA)

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

Thomas Hug closed DELTASPIKE-759.
-
Resolution: Fixed
Fix Version/s: 1.2.0

1.0.3 breaks abstractentityrepositories in ear project
--

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

[jira] [Commented] (DELTASPIKE-787) NPE in EntityRepositoryHandler for persistent methods of DTO EntityRepository

2014-11-28 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14228144#comment-14228144
 ] 

Thomas Hug commented on DELTASPIKE-787:
---

Next minor release is this weekend, which I won't make (better to give it a 
proper look before creating a ThreadLocal mess ;-)) but expect it to be part of 
the next bug fix release. Hope you can life with the workaround for the time 
being.

 NPE in EntityRepositoryHandler for persistent methods of DTO EntityRepository
 -

 Key: DELTASPIKE-787
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-787
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.0.2, 1.0.3, 1.1.0
 Environment: Wildfly 8.1.0.Final/8.2.0.Final, Win7
Reporter: Wojciech Żaboklicki
Assignee: Thomas Hug
Priority: Critical
 Attachments: dto-repository-test.zip


 NPE when trying to save object (or any other persistent operation) using DTO 
 Repository. QueryInvocationContext in EntityRepositoryHandler is not injected.
 Non-persistent operations, like finBy or findAll, work fine. Non-dto entity 
 repository persists data correct.
 Piece of stacktrace:
 Caused by: java.lang.NullPointerException
   at 
 org.apache.deltaspike.data.impl.handler.EntityRepositoryHandler.save(EntityRepositoryHandler.java:66)
  [deltaspike-data-module-impl-1.1.0.jar:1.1.0]
 Debugger shows that entity provided to the method is correct, that means 
 another Repository, used for dto to entity mapping in the same thread, works 
 fine.



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

[jira] [Commented] (DELTASPIKE-787) NPE in EntityRepositoryHandler for persistent methods of DTO EntityRepository

2014-11-27 Thread Thomas Hug (JIRA)

[
https://issues.apache.org/jira/browse/DELTASPIKE-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14228121#comment-14228121
]

Thomas Hug commented on DELTASPIKE-787:
---

Hi Wojtek! Apologies, my explanation was too short. The problem in your sample
is the call to the MouseRepository inside the mapper where you resolve the
Mouse with the findBy. Replace the repository there with an injected
EntityManager and get the Mouse with a entityManager.find(Mouse.class,
mouseId). That will fix the NullPointer.

To give you an insight on the internals, calls to repositories keep a
ThreadLocal for call- and repository contextual data (the
QueryInvocationContext). At the end of each call, this ThreadLocal gets cleaned
up. So if you call ComputerRepository, the implementation will create the
ThreadLocal, call the Mapper which calls again MouseRepository. MouseRepository
cleans up the ThreadLocal and it's missing afterwards in ComputerRepository. We
have to stack this ThreadLocal to get rid of the problem.

NPE in EntityRepositoryHandler for persistent methods of DTO EntityRepository
-

Key: DELTASPIKE-787
URL: https://issues.apache.org/jira/browse/DELTASPIKE-787
Project: DeltaSpike
Issue Type: Bug
Components: Data-Module
Affects Versions: 1.0.2, 1.0.3, 1.1.0
Environment: Wildfly 8.1.0.Final/8.2.0.Final, Win7
Reporter: Wojciech Żaboklicki
Assignee: Thomas Hug
Priority: Critical
Attachments: dto-repository-test.zip

NPE when trying to save object (or any other persistent operation) using DTO
Repository. QueryInvocationContext in EntityRepositoryHandler is not injected.
Non-persistent operations, like finBy or findAll, work fine. Non-dto entity
repository persists data correct.
Piece of stacktrace:
Caused by: java.lang.NullPointerException
at
org.apache.deltaspike.data.impl.handler.EntityRepositoryHandler.save(EntityRepositoryHandler.java:66)
[deltaspike-data-module-impl-1.1.0.jar:1.1.0]
Debugger shows that entity provided to the method is correct, that means
another Repository, used for dto to entity mapping in the same thread, works
fine.

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

Re: ContainerManagedTransactionStrategy issue

2014-10-28 Thread Thomas Hug

Hi Helge,
Not sure what's wrong with the EM producer. Some CDI side effect maybe?
Anyway, if you use an EntityManagerFactory in the producer, the sample goes
green again.

On Tue, Oct 28, 2014 at 9:40 AM, hwaastad he...@waastad.org wrote:

 Hi,
 I need some help understanding how Deltaspike handles entitymanager lookup.
 (I've made this post since the issue I've been struggeling with these last
 couple og days actually are a result on how DS is handling CMT)

 I've made a test project: https://github.com/hwaastad/DeltaDataTest.git
 - JTA in persistence.xml
 - CMT em producer
 - ContainerManagedTransactionStrategy in beans.xml

 This is a simple MDB persisting a dummy entity.

 1. save(entity) will fail
 2. findall() and the save(entity) is working.

 Why is 1. failing?

 br hw



 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/ContainerManagedTransactionStrategy-issue-tp4659285.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
 at Nabble.com.

Re: ContainerManagedTransactionStrategy issue

2014-10-28 Thread Thomas Hug

Hi Helge
Hmmm wouldn't be aware of that. Sounds to me like You can only use JTA
with EJBs in CMT mode? ;-) Have to check the spec.
Anyway, don't think it's a DS issue - if you do the same in the EMResolver,
it works fine. Maybe someone else has a better insight on the CDI side here.

On Tue, Oct 28, 2014 at 11:27 AM, hwaastad he...@waastad.org wrote:

 Hi TH,
 I know it'll work using PersistenceUnit but then again are'nt I using a
 resource_local em?

 I try to read the specs regarding JTA and somewhere I read: You are not
 allowed to use @PersistenceUnit to refer to a unit of type JTA

 I will happily help debugging this issue, but I'm a little bit over my head
 when it comes to debugging DS code.

 If you have any recommendations, I'll start digging further.

 br hw



 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/ContainerManagedTransactionStrategy-issue-tp4659285p4659287.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
 at Nabble.com.

Re: ContainerManagedTransactionStrategy issue

2014-10-28 Thread Thomas Hug

From the Spec (2.0) 7.5 Controlling Transactions: An application-managed
entity manager may be either a JTA entity manager or a resource-local
entity manager.

On Tue, Oct 28, 2014 at 11:46 AM, Thomas Hug thomas@gmail.com wrote:

 Hi Helge
 Hmmm wouldn't be aware of that. Sounds to me like You can only use JTA
 with EJBs in CMT mode? ;-) Have to check the spec.
 Anyway, don't think it's a DS issue - if you do the same in the
 EMResolver, it works fine. Maybe someone else has a better insight on the
 CDI side here.

 On Tue, Oct 28, 2014 at 11:27 AM, hwaastad he...@waastad.org wrote:

 Hi TH,
 I know it'll work using PersistenceUnit but then again are'nt I using a
 resource_local em?

 I try to read the specs regarding JTA and somewhere I read: You are not
 allowed to use @PersistenceUnit to refer to a unit of type JTA

 I will happily help debugging this issue, but I'm a little bit over my
 head
 when it comes to debugging DS code.

 If you have any recommendations, I'll start digging further.

 br hw



 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/ContainerManagedTransactionStrategy-issue-tp4659285p4659287.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list
 archive at Nabble.com.

Re: DS Data and WeldEE causes: URL does not exist: archive:test.war/WEB-INF/classes/META-INF/persistence.xml

2014-10-12 Thread Thomas Hug

Thnx Ove for creating the JIRA issue. We will probably not get fully rid of
the problem as the Arquillian adapter probably also plays a role here, but
my plan is to separate the scanning into a dedicated extension class so it
can be deactivated (impacts only descriptor based JPA scenarios).

Cheers,
Thomas

On Sat, Oct 11, 2014 at 5:48 PM, Ove Ranheim oranh...@gmail.com wrote:

Hi John,

I followed your excellent rest and beyond showcase. Switched to properties
for building my EntityManagerFactory and it works.

Still I hope DELTASPIKE-740 will be fixed. I'm studying the rest and
beyond. It's exactly what I'm after. A lightweight stack using bits of EE.
And Undertow is awesome!!

Cheers
Ove

On 11 Oct 2014, at 16:08, John D. Ament john.d.am...@gmail.com wrote:

Ove,

Please try the same thing I did - don't include persistence.xml in your
JAR
file. Assuming it's in the right spot on your classpath, it should still
get picked up when running embedded.

I was planning to add a failDeploymentIfPersistenceXmlNotReadable to
apache-deltaspike.properties to handle this case. By default you would
get
the current behaviour, but you could turn it off if you so choose. I
simply didn't have time before J1 to fix it. WDYT?

John

On Sat, Oct 11, 2014 at 5:23 AM, Ove Ranheim oranh...@gmail.com wrote:

Hi Thomas

I created this issue:
https://issues.apache.org/jira/browse/DELTASPIKE-740
.

Thanks for point out John's posting.

Best regards
Ove

On 10 Oct 2014, at 09:47, Thomas Hug thomas@gmail.com wrote:

Hi Ove

AFAIR John ran into similar issues recently, see

http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201409.mbox/%3ccaoqetn9hat9yiorqtsafbo5ysmntngaqpet4bnxtw9-czw5...@mail.gmail.com%3E

The reason we look for persistence.xml is to extract the orm.xml files
-
we're mainly interested in those as they define entities, primary keys
etc.
which is cached for later usage. Agree that failing deployments might
be
too aggressive. An option would be to have a dedicated extension for
scanning which can be deactivated (as most use cases will have
annotation
based entities anyway).

On Fri, Oct 10, 2014 at 8:13 AM, Ove Ranheim oranh...@gmail.com
wrote:

Hi,

I have a test case that uses jpa-module and hibernate; using

org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1:1.0.0.CR8.
The persistence.xml and the test case works correctly.

When I add the data-module, it tries to load the persistence.xml over
again and it fails with: URL does not exist:
archive:test.war/WEB-INF/classes/META-INF/persistence.xml

* Is there a way to disable DescriptorReader to load persistence.xml?
* Why does data-module load the persistence.xml?
* Any other way to circumvent this problem?
* Is this a bug?

I read through Mark's blog post:

http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-cdi-based-projects/
,
which indicates that this may be due to a classloading issue. The
links to
Arquillian Wiki is broken (under Embedded style Arquillian tests),
so
I'm
a bit lost.

Regards
Ove

INFO: class: org.apache.deltaspike.data.impl.RepositoryExtension
activated=true
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
-123,542.439 sec FAILURE! - in
org.jboss.weld.WeldTransactionServicesTest
org.jboss.weld.WeldTransactionServicesTest Time elapsed: -123,542.44
sec
ERROR!
org.jboss.weld.exceptions.DefinitionException: Exception List with 1
exceptions:
Exception 0 :
java.lang.IllegalArgumentException: URL does not exist:
archive:test.war/WEB-INF/classes/META-INF/persistence.xml
at

org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
at

org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
at

org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
at

org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
at

org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
at

org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at

org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
at

org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271

Re: DS Data and WeldEE causes: URL does not exist: archive:test.war/WEB-INF/classes/META-INF/persistence.xml

2014-10-10 Thread Thomas Hug

Hi Ove

AFAIR John ran into similar issues recently, see
http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201409.mbox/%3ccaoqetn9hat9yiorqtsafbo5ysmntngaqpet4bnxtw9-czw5...@mail.gmail.com%3E

The reason we look for persistence.xml is to extract the orm.xml files -
we're mainly interested in those as they define entities, primary keys etc.
which is cached for later usage. Agree that failing deployments might be
too aggressive. An option would be to have a dedicated extension for
scanning which can be deactivated (as most use cases will have annotation
based entities anyway).

On Fri, Oct 10, 2014 at 8:13 AM, Ove Ranheim oranh...@gmail.com wrote:

 Hi,

 I have a test case that uses jpa-module and hibernate; using
 org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1:1.0.0.CR8.
 The persistence.xml and the test case works correctly.

 When I add the data-module, it tries to load the persistence.xml over
 again and it fails with: URL does not exist:
 archive:test.war/WEB-INF/classes/META-INF/persistence.xml

 * Is there a way to disable DescriptorReader to load persistence.xml?
 * Why does data-module load the persistence.xml?
 * Any other way to circumvent this problem?
 * Is this a bug?

 I read through Mark's blog post:
 http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-cdi-based-projects/,
 which indicates that this may be due to a  classloading issue. The links to
 Arquillian Wiki is broken (under Embedded style Arquillian tests), so I'm
 a bit lost.

 Regards
 Ove


 INFO: class: org.apache.deltaspike.data.impl.RepositoryExtension
 activated=true
 Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
 -123,542.439 sec  FAILURE! - in
 org.jboss.weld.WeldTransactionServicesTest
 org.jboss.weld.WeldTransactionServicesTest  Time elapsed: -123,542.44 sec
  ERROR!
 org.jboss.weld.exceptions.DefinitionException: Exception List with 1
 exceptions:
 Exception 0 :
 java.lang.IllegalArgumentException: URL does not exist:
 archive:test.war/WEB-INF/classes/META-INF/persistence.xml
 at
 org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
 at
 org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
 at
 org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
 at
 org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
 at
 org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
 at
 org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:74)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:483)
 at
 org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
 at
 org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
 at
 org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
 at
 org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
 at
 org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
 at
 org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:174)
 at
 org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:133)
 at
 org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:107)
 at
 org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54)
 at
 org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
 at
 org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:45)
 at
 org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:385)
 at
 org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
 at
 org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.startContainer(TestContainer.java:273)
 at
 org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:105)
 at
 org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
 at
 org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
 at

Re: ContainerManagedTransactionStrategy

2014-10-06 Thread Thomas Hug

Can you remove the ApplicationScoped on the EMProducer and see if that
helps?

On Sun, Oct 5, 2014 at 4:58 PM, hwaastad he...@waastad.org wrote:

 Hi TH,
 and thanks for answering.

 I'm running JTA datasource and running repository within an EJB
 transaction.

 However, what I found out is that I need the entoitymanagerconfig with
 resolver or else this error occurs.

 I've made a simple test project
 (https://github.com/hwaastad/TomeeDsValidation.git)

 So if you remove the
 @EntityManagerConfig(entityManagerResolver =
 CrmEntityManagerResolver.class,flushMode = FlushModeType.COMMIT)

 Then this error will occure.
 Any idea why?


 br hw



 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/ContainerManagedTransactionStrategy-tp4659084p4659102.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
 at Nabble.com.

Re: ContainerManagedTransactionStrategy

2014-10-05 Thread Thomas Hug

This should be used with a JTA datasource and the call to the repository
typically goes through an EJB starting the transaction.
Do you have some more context to the error?

On Fri, Oct 3, 2014 at 4:58 PM, hwaastad he...@waastad.org wrote:

 Hi,
 i was wondering if there is any doc on the usage of
 ContainerManagedTransactionStrategy?

 I've been trying to add this in beans.xml, but I only get a:

 javax.persistence.PersistenceException: java.lang.NullPointerException
 at

 org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getIdentifier(EntityManagerFactoryDelegate.java:719)
 at

 org.apache.deltaspike.data.impl.handler.CdiQueryInvocationContext.isNew(CdiQueryInvocationContext.java:93)
 .
 .
 .

 Caused by: java.lang.NullPointerException
 at

 org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getIdentifier(EntityManagerFactoryImpl.java:85)
 at

 org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getIdentifier(EntityManagerFactoryDelegate.java:715)

 br hw



 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/ContainerManagedTransactionStrategy-tp4659084.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
 at Nabble.com.

Re: Repository save duplicate key

2014-10-02 Thread Thomas Hug

Hi hw,
currently the way we detect new or updated entities is not perfect :-) -
we're using PersitenceUnitUtil.getIdentifier(entity) != null which gives
not the result you expect in this case. If you want the persist semantics
from JPA, I'd recommend implementing the EntityManagerDelegate.

On Thu, Oct 2, 2014 at 9:17 AM, hwaastad he...@waastad.org wrote:

 Hi,
 Hi,
 just a question regarding save on duplicate primaries.
 I have an entity with @id String id

 eks:
 User
 @id String id
 String name

 User a = new User(id-1,name-1)
 User a2 = new User(id-1,name-2)

 save(a) - OK
 save(a2) - updates entity a

 So, If I want save(a2) to throw an exception on duplicate primary is it
 best
 to use the entitymanagerdelegate or add a contraintvalidator on primary?

 br hw




 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Repository-save-duplicate-key-tp4659067.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
 at Nabble.com.

Re: Repository save duplicate key

2014-10-02 Thread Thomas Hug

I'd not try overriding save - the way the called method is resolved is not
predictable if the method signature is the same. Adding a new method should
do it though.

On Thu, Oct 2, 2014 at 10:12 AM, hwaastad he...@waastad.org wrote:

 Hi,
 and thanks for answering.

 I'm extending the abstractentityrepository so I'll start testing override
 on
 the save method or just adding another method.
 If that does'nt suit my needs, I'll have a closer look at the
 entitymanagerdelegate.

 thanks again,
 br hw



 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Repository-save-duplicate-key-tp4659067p4659069.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
 at Nabble.com.

Re: Repository save duplicate key

2014-10-02 Thread Thomas Hug

Thought about that too, but wouldn't that start to be confusing? We have
save, insert plus EMDelegate with persist and merge?
Alternatively we might add something to override the isNew strategy, or
check whether the ID is a @GeneratedValue. wdyt?

On Thu, Oct 2, 2014 at 11:34 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 @Thomas: we can maybe add it to DS itself: insert?


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau


 2014-10-02 10:58 GMT+02:00 Thomas Hug thomas@gmail.com:
  I'd not try overriding save - the way the called method is resolved is
 not
  predictable if the method signature is the same. Adding a new method
 should
  do it though.
 
  On Thu, Oct 2, 2014 at 10:12 AM, hwaastad he...@waastad.org wrote:
 
  Hi,
  and thanks for answering.
 
  I'm extending the abstractentityrepository so I'll start testing
 override
  on
  the save method or just adding another method.
  If that does'nt suit my needs, I'll have a closer look at the
  entitymanagerdelegate.
 
  thanks again,
  br hw
 
 
 
  --
  View this message in context:
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Repository-save-duplicate-key-tp4659067p4659069.html
  Sent from the Apache DeltaSpike Incubator Discussions mailing list
 archive
  at Nabble.com.

Re: Repository save duplicate key

2014-10-02 Thread Thomas Hug

Agree that it has its uses, but I'm more worried about the naming
(insertOrUpdate vs. insert is far more clear than save vs. insert). Any
good suggestions based on save are welcome :)
SPI sounds good too. We already do provider detection for the query string
extraction.

On Thu, Oct 2, 2014 at 2:30 PM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

well I think EMDelegate isa workaround and shouldn't be visible
(excepted for advanced cases - persist is not ;)).

default as insertOrUpdate is nice but insertOnly is important so it
should be part of the API and this is not directly linked to isNew
IMHO (you can hack isNew to make it working but semantically it is not
the same).

About isNew: we can introduce a spi by provider and fallback on
current impl if provider is unknown, it would certainly be better if
we still have issues with it.

wdyt?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau

2014-10-02 14:24 GMT+02:00 Thomas Hug thomas@gmail.com:
Thought about that too, but wouldn't that start to be confusing? We have
save, insert plus EMDelegate with persist and merge?
Alternatively we might add something to override the isNew strategy, or
check whether the ID is a @GeneratedValue. wdyt?

On Thu, Oct 2, 2014 at 11:34 AM, Romain Manni-Bucau
rmannibu...@gmail.com
wrote:

@Thomas: we can maybe add it to DS itself: insert?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau

2014-10-02 10:58 GMT+02:00 Thomas Hug thomas@gmail.com:
I'd not try overriding save - the way the called method is resolved is
not
predictable if the method signature is the same. Adding a new method
should
do it though.

On Thu, Oct 2, 2014 at 10:12 AM, hwaastad he...@waastad.org wrote:

Hi,
and thanks for answering.

I'm extending the abstractentityrepository so I'll start testing
override
on
the save method or just adding another method.
If that does'nt suit my needs, I'll have a closer look at the
entitymanagerdelegate.

thanks again,
br hw

--
View this message in context:

http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Repository-save-duplicate-key-tp4659067p4659069.html
Sent from the Apache DeltaSpike Incubator Discussions mailing list
archive
at Nabble.com.

[jira] [Commented] (DELTASPIKE-734) remove() and removeFlush() doesn't seem to perform the operation

2014-09-30 Thread Thomas Hug (JIRA)

[
https://issues.apache.org/jira/browse/DELTASPIKE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14152930#comment-14152930
]

Thomas Hug commented on DELTASPIKE-734:
---

Kinda surprised that the EM producer is not complaining. Can you change the
OciCommerceEntityManagerProducer component request scoped and the persistence
context to not extended? That should fix the problem.

For some details on the extended PC, see
http://stackoverflow.com/questions/2547817/what-is-the-difference-between-transaction-scoped-persistence-context-and-extend

remove() and removeFlush() doesn't seem to perform the operation

Key: DELTASPIKE-734
URL: https://issues.apache.org/jira/browse/DELTASPIKE-734
Project: DeltaSpike
Issue Type: Bug
Components: Data-Module
Affects Versions: 1.0.2
Environment: Windows 7, JBoss EAP 6.3, Deltaspike 1.0.2, intel i5
Reporter: Loïc Prieto Dehennault

We've recently moved the project from a custom-built JPA query
builder/executor to deltaspike Data, using the EntityRepository interface to
perform CRUD operations, and the remove and removeFlush methods of
EntityRepository do not seem to perform the operation. They pass without
error, but nothing is affected.
The transaction context is provided by a Stateless EJB bean, which invokes
the methods of the repositories (that implement the EntityRepository and
CriteriaSupport interfaces).
Update and create operations are performed correctly, only the remove
operation is not completed.
Thats all I can think off the top of my head, if you need any more info,
please ask for it and I will gladly provide.
Thanks,
Loïc Prieto.

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

[jira] [Commented] (DELTASPIKE-734) remove() and removeFlush() doesn't seem to perform the operation

2014-09-29 Thread Thomas Hug (JIRA)

[
https://issues.apache.org/jira/browse/DELTASPIKE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151562#comment-14151562
]

Thomas Hug commented on DELTASPIKE-734:
---

Two questions:
- Which transaction strategy do you have in place? (see
http://deltaspike.apache.org/documentation/jpa#_jta_support)
- What is the Hibernate log output when show_sql is enabled?

remove() and removeFlush() doesn't seem to perform the operation

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

[jira] [Commented] (DELTASPIKE-734) remove() and removeFlush() doesn't seem to perform the operation

2014-09-29 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151566#comment-14151566
 ] 

Thomas Hug commented on DELTASPIKE-734:
---

Actually 3 questions :-)
- Can you confirm the entity is attached to a persistence context before 
calling the remove method?

 remove() and removeFlush() doesn't seem to perform the operation
 

 Key: DELTASPIKE-734
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-734
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.0.2
 Environment: Windows 7, JBoss EAP 6.3, Deltaspike 1.0.2, intel i5
Reporter: Loïc Prieto Dehennault

 We've recently moved the project from a custom-built JPA query 
 builder/executor to deltaspike Data, using the EntityRepository interface to 
 perform CRUD operations, and the remove and removeFlush methods of 
 EntityRepository do not seem to perform the operation. They pass without 
 error, but nothing is affected.
 The transaction context is provided by a Stateless EJB bean, which invokes 
 the methods of the repositories (that implement the EntityRepository and 
 CriteriaSupport interfaces).
 Update and create operations are performed correctly, only the remove 
 operation is not completed.
 Thats all I can think off the top of my head, if you need any more info, 
 please ask for it and I will gladly provide.
 Thanks,
 Loïc Prieto.



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

[jira] [Commented] (DELTASPIKE-734) remove() and removeFlush() doesn't seem to perform the operation

2014-09-29 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151813#comment-14151813
 ] 

Thomas Hug commented on DELTASPIKE-734:
---

Sounds to me like the EM is not attached to the TX - the flush should happen 
when the TX is commited, which is when you should see the Hibernate SQL in the 
log. Just to be sure: the EM configured with a JTA datasource?

You can try injection (with @Inject) your EM and call remove there - it should 
have the same effect (none) as calling it on the repository.

How are you producing the EM?

 remove() and removeFlush() doesn't seem to perform the operation
 

 Key: DELTASPIKE-734
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-734
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.0.2
 Environment: Windows 7, JBoss EAP 6.3, Deltaspike 1.0.2, intel i5
Reporter: Loïc Prieto Dehennault

 We've recently moved the project from a custom-built JPA query 
 builder/executor to deltaspike Data, using the EntityRepository interface to 
 perform CRUD operations, and the remove and removeFlush methods of 
 EntityRepository do not seem to perform the operation. They pass without 
 error, but nothing is affected.
 The transaction context is provided by a Stateless EJB bean, which invokes 
 the methods of the repositories (that implement the EntityRepository and 
 CriteriaSupport interfaces).
 Update and create operations are performed correctly, only the remove 
 operation is not completed.
 Thats all I can think off the top of my head, if you need any more info, 
 please ask for it and I will gladly provide.
 Thanks,
 Loïc Prieto.



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

[jira] [Comment Edited] (DELTASPIKE-734) remove() and removeFlush() doesn't seem to perform the operation

2014-09-29 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151813#comment-14151813
 ] 

Thomas Hug edited comment on DELTASPIKE-734 at 9/29/14 3:45 PM:


Sounds to me like the EM is not attached to the TX - the flush should happen 
when the TX is commited, which is when you should see the Hibernate SQL in the 
log. Just to be sure: the EM is configured with a JTA datasource?

You can try injecting (with @Inject) your EM and call remove there - it should 
have the same effect (none) as calling it on the repository.

How are you producing the EM?


was (Author: thomashug):
Sounds to me like the EM is not attached to the TX - the flush should happen 
when the TX is commited, which is when you should see the Hibernate SQL in the 
log. Just to be sure: the EM configured with a JTA datasource?

You can try injection (with @Inject) your EM and call remove there - it should 
have the same effect (none) as calling it on the repository.

How are you producing the EM?

 remove() and removeFlush() doesn't seem to perform the operation
 

 Key: DELTASPIKE-734
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-734
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.0.2
 Environment: Windows 7, JBoss EAP 6.3, Deltaspike 1.0.2, intel i5
Reporter: Loïc Prieto Dehennault

 We've recently moved the project from a custom-built JPA query 
 builder/executor to deltaspike Data, using the EntityRepository interface to 
 perform CRUD operations, and the remove and removeFlush methods of 
 EntityRepository do not seem to perform the operation. They pass without 
 error, but nothing is affected.
 The transaction context is provided by a Stateless EJB bean, which invokes 
 the methods of the repositories (that implement the EntityRepository and 
 CriteriaSupport interfaces).
 Update and create operations are performed correctly, only the remove 
 operation is not completed.
 Thats all I can think off the top of my head, if you need any more info, 
 please ask for it and I will gladly provide.
 Thanks,
 Loïc Prieto.



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

Re: mocking of abstractentityrepository implementations

2014-09-03 Thread Thomas Hug

If you have a specific question on the persistence extension not covered
here [1] you can always ask on the Arquillian forum, the gentleman
responsible for it is very friendly and helpful ;-) For some code samples
you can take [2] as a starting point (concrete Arquillian deployments are
in subclasses in the subpackage).

[1] https://docs.jboss.org/author/display/ARQ/Persistence
[2]
https://github.com/arquillian/arquillian-extension-persistence/blob/master/int-tests/src/test/java/org/jboss/arquillian/integration/persistence/example/NonDeployableUserPersistenceTest.java


On Tue, Sep 2, 2014 at 11:57 PM, hwaastad he...@waastad.org wrote:

 Hi,
 always looking out for a better way to build my tests :-)

 mocking, well sometimes I just need mock for throwing exceptions and
 anomality.

 Now, I know arquillian is a powerful framework and I guess you can
 dynamically assign alternatives/stereotypes aswell by defining this with a
 addasmanifestresource/beans.xml/stringasset.

 I guess I just got to roll up my sleaves and do a bit more investigation on
 the persistence extension.

 I someone has a link or to I would be most greateful :-)
 I know Romain wrote something about this in his blog,though.

 Well guys,
 thanks a lot for feedback.

 br hw



 --
 View this message in context:
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/mocking-of-abstractentityrepository-implementations-tp4658745p4658766.html
 Sent from the Apache DeltaSpike Incubator Discussions mailing list archive
 at Nabble.com.

Re: Data Module - some issues in SE/Maven Tests

2014-09-02 Thread Thomas Hug

Hi John

First one should - as Romain mentioned - usually not be a problem. Might
still be worth adding the exception check as I've run into problems on WLS
with this particular approach. We lose the ability to deal with entities
defined in orm.xml's but that's probably still better than crashing :-)

The second one comes from creating an uber-jar - the api module doesn't
have a beans.xml. Can't think of a different approach to get rid of this
one...

On Tue, Sep 2, 2014 at 6:54 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

Archive url issue is due to the arquillian adapter (so no problem for data
module)

Can't the other one be fixed using @Typed?
Le 1 sept. 2014 21:41, John D. Ament john.d.am...@gmail.com a écrit :

Hi All!

I've hit a couple of issues with the Data Module and wanted to know if it
was worth fixing.

First, my sample app can be found at [1] (note you'll need JDK8 to run)
and
you can run the test JPATest to see the results, using

mvn -Dtest=JPATest -Ddeltaspike.version=1.0.2

First issue you'll note is that the following output (or something
similar
to it will be given):

java.lang.IllegalArgumentException: URL does not exist:
archive:se-examples.jar/META-INF/persistence.xml

org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)

org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)

org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)

org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)

org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)

org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:73)

(full stack available at [2], test.log). It seems like the
RepositoryExtension is picking up on my persistence.xml and aggressively
trying to parse them (at this point, I don't have any @Repository's
defined
in my app). For some reason it cannot parse this URL but it does seem to
pick up the persistence.xml from target/classes/META-INF so it does
eventually parse it. To work around this, I wrapped
DescriptorReader.readAllFromClassPath's result.add with an exception
check.
I figure if it can't read the descriptor, no reason to make the whole
app
die. What do you think?

Second issue, after fixing this one, was that AbstractEntityRepository
was
being picked up as a @Repository and erroring out saying that there's no
entity for it. This one I wasn't expecting. To fix it, in
RepsitoryComponents, I added an explicit check if it was the base class,
if
it was return null rather than exception and check for null in the add
method. This also fixed things and the tests started running fine. This
fix seems more hacky, and I'm wondering if I'm just doing something wrong
to make this class be picked up.

You can see the summary of changes in the gist's patch.txt.

John

[1]: https://github.com/johnament/restful-and-beyond-tut2184
[2]: https://gist.github.com/johnament/d4a55ce7251062ee0b85

Re: mocking of abstractentityrepository implementations

2014-09-02 Thread Thomas Hug

For this case it's probably also the PartialBeanBindingExtension to
deactivate.

Is this only intended for testing purposes?


On Tue, Sep 2, 2014 at 12:42 PM, John D. Ament john.d.am...@gmail.com
wrote:

 Hi

 Did you deactivate the RepositoryExtension ?


 On Tue, Sep 2, 2014 at 4:50 AM, hwaastad he...@waastad.org wrote:

  Hi,
  I'm trying to mock out abstract repositories in different project stages.
 
  I can extend my repository (in test classes) and use
  alternative/stereotype,
  but excluding does not seem to work then.
  Is this possible?
 
  br hw
 
 
 
 
  --
  View this message in context:
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/mocking-of-abstractentityrepository-implementations-tp4658745.html
  Sent from the Apache DeltaSpike Incubator Discussions mailing list
 archive
  at Nabble.com.

Re: mocking of abstractentityrepository implementations

2014-09-02 Thread Thomas Hug

Maybe also have a look at
https://issues.apache.org/jira/browse/DELTASPIKE-588




On Tue, Sep 2, 2014 at 1:24 PM, Thomas Hug thomas@gmail.com wrote:

 For this case it's probably also the PartialBeanBindingExtension to
 deactivate.

 Is this only intended for testing purposes?


 On Tue, Sep 2, 2014 at 12:42 PM, John D. Ament john.d.am...@gmail.com
 wrote:

 Hi

 Did you deactivate the RepositoryExtension ?


 On Tue, Sep 2, 2014 at 4:50 AM, hwaastad he...@waastad.org wrote:

  Hi,
  I'm trying to mock out abstract repositories in different project
 stages.
 
  I can extend my repository (in test classes) and use
  alternative/stereotype,
  but excluding does not seem to work then.
  Is this possible?
 
  br hw
 
 
 
 
  --
  View this message in context:
 
 http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/mocking-of-abstractentityrepository-implementations-tp4658745.html
  Sent from the Apache DeltaSpike Incubator Discussions mailing list
 archive
  at Nabble.com.

Re: @MappedSuperclass and CriteriaSupport in Data Module

2014-08-27 Thread Thomas Hug

Thnx Radu, I've seen the JIRA issue but am currently tied up with other
stuff. Will give it a closer look hopefully soon.


On Wed, Aug 27, 2014 at 2:35 PM, Radu Creanga rdc...@gmail.com wrote:

 Hi Thomas,

 In case you haven't noticed, I opened
 https://issues.apache.org/jira/browse/DELTASPIKE-699 and submitted a
 patch.
 The patch covers a somewhat larger scope as the issue described here
 affects any method creating QuerySelections. I haven't submitted a ICLA
 yet, as I'm having some trouble with faxing at the moment, but will do that
 soon.

 Regards,
 Radu


 On Tue, Aug 26, 2014 at 12:45 PM, Thomas Hug thomas@gmail.com wrote:

  Hi Radu
  Yes good catch - makes perfectly sense. Do you mind creating a JIRA
 ticket
  for that?
 
 
  On Tue, Aug 26, 2014 at 12:15 PM, Radu Creanga rdc...@gmail.com wrote:
 
   Hi all,
  
   Suppose one has an entity class hierarchy, such as when moving auditing
   fields into a mapped superclass.
  
   @MappedSuperclass
   @EntityListeners(AuditEntityListener.class)
   public abstract class Auditable implements Serializable {
  
 @CreatedOn
 @Temporal(TemporalType.TIMESTAMP)
 private Date created;
  
 @ModifiedOn
 @Temporal(TemporalType.TIMESTAMP)
 private Date modified;
  
 // getters, setters
  
   }
  
   @Entity
   public class Item extends Auditable {
  
 @Id
 private Long id;
 @Basic
 private String name;
  
 // getters, setters
  
   }
  
   Then an metamodel processor would generate the following metamodel
  classes:
  
   @StaticMetamodel(Auditable.class)
   public abstract class Auditable_ {
  
   public static volatile SingularAttributeAuditable, Date created;
public static volatile SingularAttributeAuditable, Date modified;
  
   }
  
   @StaticMetamodel(Item.class)
   public abstract class Item_ extends
   com.mobilabsolutions.nappkin.web.dto.Auditable_ {
  
   public static volatile SingularAttributeItem, Long id;
   public static volatile SingularAttributeItem, String name;
  
   }
  
   For the sake of completeness, here's the repository declaration with
   criteria support:
  
   @Repository
   public interface ItemRepository extends EntityRepositoryItem, Long,
   CriteriaSupportItem {
  
   }
  
   Then, if one wants to do the following:
  
   @Inject
   private ItemRepository itemRepository;
  
   public void someMethod() {
 this.itemRepository.criteria().select(
   this.itemRepository.attribute(Item_.name),
   *this.itemRepository.attribute(Item_.modified)*);
   }
  
   the source won't compile, because the declaration of the attribute()
  method
   in CriteriaSupport:
  
   public interface CriteriaSupportE
   {
   ...
  
   /**
* Create a query selection for an Entity attribute.
* @param attribute Attribute to show up in the result selection
* @return  {@link QuerySelection} part of a {@link
   Criteria#select(Class, QuerySelection...)} call.
*/
   X QuerySelectionE, X attribute(SingularAttributeE, X
  attribute);
  
   ...
  
   }
  
   Wouldn't it make sense (and possible?) to change it to:
  
   X QuerySelectionE, X attribute(SingularAttribute? super E, X
   attribute);
  
   The mapped superclass doesn't have to have anything to do with
 auditing,
   but that's the example that came to mind.
  
   Best regards,
   Radu

Re: DeltaSpike Stickers

2014-08-26 Thread Thomas Hug

There's a courier to Switzerland - if you don't mind a trip to Zürich... ;-)
@John, Bartosz will ping you about it.


On Tue, Aug 26, 2014 at 9:48 AM, Thomas Andraschko 
andraschko.tho...@gmail.com wrote:

 they look really great!

 Can somebody import some of them to germany? :D


 2014-08-26 2:28 GMT+02:00 John D. Ament john.d.am...@gmail.com:

  Hi all,
 
  For JavaOne, I ordered 300 DeltaSpike stickers.  They're 2 vinyl
 stickers,
  good for laptops, etc.  You can see a picture here:
  https://twitter.com/JohnAment/status/504025037817774084
 
  If anyone's going to be at JavaOne, I'll be distributing them.  Help
 spread
  the word!
 
  John

Re: @MappedSuperclass and CriteriaSupport in Data Module

2014-08-26 Thread Thomas Hug

Hi Radu
Yes good catch - makes perfectly sense. Do you mind creating a JIRA ticket
for that?


On Tue, Aug 26, 2014 at 12:15 PM, Radu Creanga rdc...@gmail.com wrote:

 Hi all,

 Suppose one has an entity class hierarchy, such as when moving auditing
 fields into a mapped superclass.

 @MappedSuperclass
 @EntityListeners(AuditEntityListener.class)
 public abstract class Auditable implements Serializable {

   @CreatedOn
   @Temporal(TemporalType.TIMESTAMP)
   private Date created;

   @ModifiedOn
   @Temporal(TemporalType.TIMESTAMP)
   private Date modified;

   // getters, setters

 }

 @Entity
 public class Item extends Auditable {

   @Id
   private Long id;
   @Basic
   private String name;

   // getters, setters

 }

 Then an metamodel processor would generate the following metamodel classes:

 @StaticMetamodel(Auditable.class)
 public abstract class Auditable_ {

 public static volatile SingularAttributeAuditable, Date created;
  public static volatile SingularAttributeAuditable, Date modified;

 }

 @StaticMetamodel(Item.class)
 public abstract class Item_ extends
 com.mobilabsolutions.nappkin.web.dto.Auditable_ {

 public static volatile SingularAttributeItem, Long id;
 public static volatile SingularAttributeItem, String name;

 }

 For the sake of completeness, here's the repository declaration with
 criteria support:

 @Repository
 public interface ItemRepository extends EntityRepositoryItem, Long,
 CriteriaSupportItem {

 }

 Then, if one wants to do the following:

 @Inject
 private ItemRepository itemRepository;

 public void someMethod() {
   this.itemRepository.criteria().select(
 this.itemRepository.attribute(Item_.name),
 *this.itemRepository.attribute(Item_.modified)*);
 }

 the source won't compile, because the declaration of the attribute() method
 in CriteriaSupport:

 public interface CriteriaSupportE
 {
 ...

 /**
  * Create a query selection for an Entity attribute.
  * @param attribute Attribute to show up in the result selection
  * @return  {@link QuerySelection} part of a {@link
 Criteria#select(Class, QuerySelection...)} call.
  */
 X QuerySelectionE, X attribute(SingularAttributeE, X attribute);

 ...

 }

 Wouldn't it make sense (and possible?) to change it to:

 X QuerySelectionE, X attribute(SingularAttribute? super E, X
 attribute);

 The mapped superclass doesn't have to have anything to do with auditing,
 but that's the example that came to mind.

 Best regards,
 Radu

Re: DeltaSpike Stickers

2014-08-26 Thread Thomas Hug

He will bring beers! :D


On Tue, Aug 26, 2014 at 12:30 PM, John D. Ament john.d.am...@gmail.com
wrote:

 Ha! No way I'm shipping them back w/ Bartosz.  Only Ola.


 On Tue, Aug 26, 2014 at 4:39 AM, Thomas Hug thomas@gmail.com wrote:

  There's a courier to Switzerland - if you don't mind a trip to Zürich...
  ;-)
  @John, Bartosz will ping you about it.
 
 
  On Tue, Aug 26, 2014 at 9:48 AM, Thomas Andraschko 
  andraschko.tho...@gmail.com wrote:
 
   they look really great!
  
   Can somebody import some of them to germany? :D
  
  
   2014-08-26 2:28 GMT+02:00 John D. Ament john.d.am...@gmail.com:
  
Hi all,
   
For JavaOne, I ordered 300 DeltaSpike stickers.  They're 2 vinyl
   stickers,
good for laptops, etc.  You can see a picture here:
https://twitter.com/JohnAment/status/504025037817774084
   
If anyone's going to be at JavaOne, I'll be distributing them.  Help
   spread
the word!
   
John

[jira] [Commented] (DELTASPIKE-683) user criteria() error

2014-08-25 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14109046#comment-14109046
 ] 

Thomas Hug commented on DELTASPIKE-683:
---

Does this only fail in the test or also in the container?

If it's only in the test: Please use Arquillian with your target container for 
testing repositories.

If it also fails in the container: Can you create e.g. a GitHub repository with 
a setup which shows the problem? I've been trying to reproduce the issue but 
couldn't do so.

 user  criteria() error
 --

 Key: DELTASPIKE-683
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-683
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.0.1, 1.0.2
 Environment: ds1.0 jdk1.7 
Reporter: kingli
Assignee: Thomas Hug
 Fix For: 1.0.3


 Use the following code, this method throws an exception
 @Test
 public void injectionTest(){
   personRepository.searchAll(king8);
 }
 @Repository(forEntity = Person.class)
 public abstract class PersonRepository extends BaseRepositoryPerson, Long 
 implements IPersonRepository {
   @Override
   public ListPerson searchAll(String v) {
   CriteriaPerson, Person c = criteria();
   c.eq(Person_.name,king);
 return c.getResultList();
 }
 }
 八月 08, 2014 6:00:23 下午 org.apache.deltaspike.data.impl.criteria.QueryCriteria 
 createQuery
 严重: Exception while creating JPA query
 java.lang.NullPointerException
   at 
 org.hibernate.ejb.criteria.path.AbstractPathImpl.get(AbstractPathImpl.java:146)
   at 
 org.apache.deltaspike.data.impl.criteria.predicate.Eq.build(Eq.java:40)
   at 
 org.apache.deltaspike.data.impl.criteria.QueryCriteria.predicates(QueryCriteria.java:283)
   at 
 org.apache.deltaspike.data.impl.criteria.QueryCriteria.createQuery(QueryCriteria.java:147)
   at 
 org.apache.deltaspike.data.impl.criteria.QueryCriteria.getResultList(QueryCriteria.java:106)
   at 
 com.lhl.common.biz.dictionary.repo.PersonRepository.searchAll(PersonRepository.java:19)
   at 
 com.lhl.common.biz.dictionary.repo.PersonRepository_$$_javassist_0._d71searchAll(PersonRepository_$$_javassist_0.java)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.apache.deltaspike.partialbean.impl.PartialBeanAbstractMethodHandler.invoke(PartialBeanAbstractMethodHandler.java:42)
   at 
 org.apache.deltaspike.partialbean.impl.MethodHandlerProxy.invoke(MethodHandlerProxy.java:35)
   at com.sun.proxy.$Proxy72.invoke(Unknown Source)
   at 
 com.lhl.common.biz.dictionary.repo.PersonRepository_$$_javassist_0.searchAll(PersonRepository_$$_javassist_0.java)
   at 
 com.lhl.common.biz.dictionary.repo.PersonTest.injectionTest(PersonTest.java:38)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.invokeMethod(CdiTestRunner.java:335)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.evaluate(CdiTestRunner.java:307)
   at 
 org.apache.deltaspike.testcontrol.impl.transaction.TransactionStatementDecoratorFactory$TransactionAwareRunAfters.evaluate(TransactionStatementDecoratorFactory.java:91)
   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:169)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:67)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
   at org.junit.runners.ParentRunner$2.evaluate

[jira] [Issue Comment Deleted] (DELTASPIKE-683) user criteria() error

2014-08-25 Thread Thomas Hug (JIRA)


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

Thomas Hug updated DELTASPIKE-683:
--

Comment: was deleted

(was: Does this only fail in the test or also in the container?

If it's only in the test: Please use Arquillian with your target container for 
testing repositories.

If it also fails in the container: Can you create e.g. a GitHub repository with 
a setup which shows the problem? I've been trying to reproduce the issue but 
couldn't do so.)

 user  criteria() error
 --

 Key: DELTASPIKE-683
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-683
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.0.1, 1.0.2
 Environment: ds1.0 jdk1.7 
Reporter: kingli
Assignee: Thomas Hug
 Fix For: 1.0.3


 Use the following code, this method throws an exception
 @Test
 public void injectionTest(){
   personRepository.searchAll(king8);
 }
 @Repository(forEntity = Person.class)
 public abstract class PersonRepository extends BaseRepositoryPerson, Long 
 implements IPersonRepository {
   @Override
   public ListPerson searchAll(String v) {
   CriteriaPerson, Person c = criteria();
   c.eq(Person_.name,king);
 return c.getResultList();
 }
 }
 八月 08, 2014 6:00:23 下午 org.apache.deltaspike.data.impl.criteria.QueryCriteria 
 createQuery
 严重: Exception while creating JPA query
 java.lang.NullPointerException
   at 
 org.hibernate.ejb.criteria.path.AbstractPathImpl.get(AbstractPathImpl.java:146)
   at 
 org.apache.deltaspike.data.impl.criteria.predicate.Eq.build(Eq.java:40)
   at 
 org.apache.deltaspike.data.impl.criteria.QueryCriteria.predicates(QueryCriteria.java:283)
   at 
 org.apache.deltaspike.data.impl.criteria.QueryCriteria.createQuery(QueryCriteria.java:147)
   at 
 org.apache.deltaspike.data.impl.criteria.QueryCriteria.getResultList(QueryCriteria.java:106)
   at 
 com.lhl.common.biz.dictionary.repo.PersonRepository.searchAll(PersonRepository.java:19)
   at 
 com.lhl.common.biz.dictionary.repo.PersonRepository_$$_javassist_0._d71searchAll(PersonRepository_$$_javassist_0.java)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.apache.deltaspike.partialbean.impl.PartialBeanAbstractMethodHandler.invoke(PartialBeanAbstractMethodHandler.java:42)
   at 
 org.apache.deltaspike.partialbean.impl.MethodHandlerProxy.invoke(MethodHandlerProxy.java:35)
   at com.sun.proxy.$Proxy72.invoke(Unknown Source)
   at 
 com.lhl.common.biz.dictionary.repo.PersonRepository_$$_javassist_0.searchAll(PersonRepository_$$_javassist_0.java)
   at 
 com.lhl.common.biz.dictionary.repo.PersonTest.injectionTest(PersonTest.java:38)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.invokeMethod(CdiTestRunner.java:335)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner$ContainerAwareMethodInvoker.evaluate(CdiTestRunner.java:307)
   at 
 org.apache.deltaspike.testcontrol.impl.transaction.TransactionStatementDecoratorFactory$TransactionAwareRunAfters.evaluate(TransactionStatementDecoratorFactory.java:91)
   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:169)
   at 
 org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.runChild(CdiTestRunner.java:67)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222

[jira] [Commented] (DELTASPIKE-687) Let users disable Query Method Expressions

2014-08-18 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100419#comment-14100419
 ] 

Thomas Hug commented on DELTASPIKE-687:
---

Never mind, found your message on the user list 
(http://mail-archives.apache.org/mod_mbox/deltaspike-users/201408.mbox/%3C53EFE6FF.2080104%40gmail.com%3E)

DS Data currently doesn't collect delegates, so the assumtion is that if it's 
not a @Query, not a concrete method and not a method expression, it's a 
delegate. It would be cleaner to actually collect all delegates during startup 
and then get to correct method type instead of disabling method expressions. 
Will give it a look.


 Let users disable Query Method Expressions
 --

 Key: DELTASPIKE-687
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-687
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.0.1
Reporter: Dominik Obermaier
Assignee: Thomas Hug

 While Query Method Expressions are very useful, it would be great to disable 
 this feature globally or on a per-method basis if this automatic 
 implementation is not desired.
 The following approaches could be worth investigating:
 - Disable the Query Method Expressions feature globally with the 
 apache-deltaspike.properties
 - Introduce a new annotation to mark methods for getting ignored by the Query 
 Method Expression Parser



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (DELTASPIKE-687) Let users disable Query Method Expressions

2014-08-18 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100481#comment-14100481
 ] 

Thomas Hug commented on DELTASPIKE-687:
---

You can also go the other way around and change the method expression prefix 
(see http://deltaspike.apache.org/data#method-prefix) instead of your delegate 
prefix. Although this might look weird too.

I was digging already into Data internals with my earlier description. It 
basically drills down to delegates not being recognized in all cases and the 
execution takes the method expression path instead of ending up in the 
delegate. So... Actually it's a bug :-) 

 Let users disable Query Method Expressions
 --

 Key: DELTASPIKE-687
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-687
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.0.1
Reporter: Dominik Obermaier
Assignee: Thomas Hug

 While Query Method Expressions are very useful, it would be great to disable 
 this feature globally or on a per-method basis if this automatic 
 implementation is not desired.
 The following approaches could be worth investigating:
 - Disable the Query Method Expressions feature globally with the 
 apache-deltaspike.properties
 - Introduce a new annotation to mark methods for getting ignored by the Query 
 Method Expression Parser



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (DELTASPIKE-673) CdiQueryInvocationContext#isNew does not work well with OpenJpa and detached entities

2014-07-16 Thread Thomas Hug (JIRA)


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

Thomas Hug reassigned DELTASPIKE-673:
-

Assignee: Thomas Hug

 CdiQueryInvocationContext#isNew does not work well with OpenJpa and detached 
 entities
 -

 Key: DELTASPIKE-673
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-673
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.0.0
Reporter: Philip Herbst
Assignee: Thomas Hug

 I'm trying to use org.apache.deltaspike.data.api.EntityRepository on TomEE 
 1.5.2 with detached entities. Whenever I try to call the save method of 
 EntityRepository I get 
 {code}
 org.apache.openjpa.persistence.EntityExistsException: Attempt to persist 
 detached object
 {code}
 CdiQueryInvocationContex#isNew returns true for my detached entity and and 
 because of that EntityManager#persist is called. 
 see org.apache.deltaspike.data.impl.handler.EntityRepositoryHandler#save
 From OpenJpaPersistenceUtil#getIdentifier(OpenJPAEntityManagerFactory emf,
Object entity)
 {code}
 /**
  * Get the object identifier for a persistent entity managed by one
  * of the entity managers of the specified entity manager factory.
  * @return The identifier of the entity or null if the entity does
  * not have an identifier assigned or is not managed by any of the
  * entity managers of the entity manager factory.
  */
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (DELTASPIKE-673) CdiQueryInvocationContext#isNew does not work well with OpenJpa and detached entities

2014-07-16 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063554#comment-14063554
 ] 

Thomas Hug commented on DELTASPIKE-673:
---

Fully agree. Beside getIdentifier() there's anyway hardly anything else 
portable we can use.

 CdiQueryInvocationContext#isNew does not work well with OpenJpa and detached 
 entities
 -

 Key: DELTASPIKE-673
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-673
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Affects Versions: 1.0.0
Reporter: Philip Herbst
Assignee: Thomas Hug

 I'm trying to use org.apache.deltaspike.data.api.EntityRepository on TomEE 
 1.5.2 with detached entities. Whenever I try to call the save method of 
 EntityRepository I get 
 {code}
 org.apache.openjpa.persistence.EntityExistsException: Attempt to persist 
 detached object
 {code}
 CdiQueryInvocationContex#isNew returns true for my detached entity and and 
 because of that EntityManager#persist is called. 
 see org.apache.deltaspike.data.impl.handler.EntityRepositoryHandler#save
 From OpenJpaPersistenceUtil#getIdentifier(OpenJPAEntityManagerFactory emf,
Object entity)
 {code}
 /**
  * Get the object identifier for a persistent entity managed by one
  * of the entity managers of the specified entity manager factory.
  * @return The identifier of the entity or null if the entity does
  * not have an identifier assigned or is not managed by any of the
  * entity managers of the entity manager factory.
  */
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (DELTASPIKE-647) AppScoped abstract repositories doesn't work

2014-07-12 Thread Thomas Hug (JIRA)


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

Thomas Hug updated DELTASPIKE-647:
--

Attachment: 0001-Failing-PartialBeans-test.patch

 AppScoped abstract repositories doesn't work
 

 Key: DELTASPIKE-647
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Reporter: Thomas Andraschko
Assignee: Thomas Hug
 Attachments: 0001-Failing-PartialBeans-test.patch, DS-647.7z






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (DELTASPIKE-647) AppScoped abstract repositories doesn't work

2014-07-12 Thread Thomas Hug (JIRA)


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

Thomas Hug reassigned DELTASPIKE-647:
-

Assignee: Gerhard Petracek  (was: Thomas Hug)

 AppScoped abstract repositories doesn't work
 

 Key: DELTASPIKE-647
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Reporter: Thomas Andraschko
Assignee: Gerhard Petracek
 Attachments: 0001-Failing-PartialBeans-test.patch, DS-647.7z






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work

2014-07-11 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058697#comment-14058697
 ] 

Thomas Hug commented on DELTASPIKE-647:
---

Wasted too much time trying to make Data work on WebLogic this week, but will 
try to give this one a spin as well. No promises though as last time I looked 
into it I left with no clue about the problem ;-).

What kind of beer? (just for the motivation... :-))

 AppScoped abstract repositories doesn't work
 

 Key: DELTASPIKE-647
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Reporter: Thomas Andraschko
Assignee: Thomas Hug
 Attachments: DS-647.7z






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (DELTASPIKE-649) re-visit wls profile

2014-07-10 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14057417#comment-14057417
 ] 

Thomas Hug commented on DELTASPIKE-649:
---

Anyone experience with context classloaders on WLS? Trying to find all 
META-INF/persistence.xml seems to work fine in other containers but fails on 
WLS. Using a WAR file currently...

 re-visit wls profile
 

 Key: DELTASPIKE-649
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-649
 Project: DeltaSpike
  Issue Type: Task
  Components: Data-Module
Affects Versions: 1.0.0
Reporter: Gerhard Petracek
Assignee: Thomas Hug
 Fix For: 1.0.1


 wls 12.1.3 was just released - we can test again, if all issues are resolved 
 already.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work

2014-06-23 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040561#comment-14040561
 ] 

Thomas Hug commented on DELTASPIKE-647:
---

Seems to crash before reaching any Data module code. Could this be related to 
PartialBeans?

 AppScoped abstract repositories doesn't work
 

 Key: DELTASPIKE-647
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Reporter: Thomas Andraschko
Assignee: Thomas Hug
 Attachments: DS-647.7z






--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [Data] Scope of repositories

2014-06-18 Thread Thomas Hug

You can scope partial beans just like any other bean (@Gerhard, correct me
if I'm wrong) - e.g. like this example here in the JDF [1].

For the serialization issue I'd have to check. The partial bean
InvocationHandler is a Serializable [2]. Can you paste a stacktrace
somewhere?

[1]
https://github.com/jboss-developer/jboss-wfk-quickstarts/blob/7eed438476290e5a9db2e82cb3032d5479402b6d/deltaspike-partialbean-advanced/src/main/java/org/jboss/as/quickstart/deltaspike/partialbeanadvanced/queryservice/PersonQueryService.java
[2]
https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/handler/QueryHandler.java


On Wed, Jun 18, 2014 at 1:13 PM, Karl Kildén karl.kil...@gmail.com wrote:

 Feels like it should default to @ApplicationScoped? I see no reason why not
 at least


 On 18 June 2014 13:12, Thomas Andraschko andraschko.tho...@gmail.com
 wrote:

  or: @Repository(scope = ApplicationScoped.class)
 
 
  2014-06-18 12:25 GMT+02:00 Thomas Andraschko 
 andraschko.tho...@gmail.com
  :
 
   Hi Thomas,
  
   my problem is that when i inject it in a ViewScoped bean, it tries to
   serialize it but it isn't serializable.
   Could we make it configurable? Maybe we could declerate the scope on
 the
   repo:
  
   @Repository
   @ApplicationScoped
   public abstract class MyRepository extends
   AbstractEntityRepositoryMitarbeiter, Long
  
   Regards,
   Thomas
  
  
   2014-06-18 12:20 GMT+02:00 Thomas Hug thomas@gmail.com:
  
   Hi Thomas
   We made some efforts to get rid of scope-related parts in the impl,
 but
  I
   don't think there's anything speakin' against a @NormalScoped repo -
   PartialBeans do support that.
   Cheers,
   Thomas
  
  
   On Wed, Jun 18, 2014 at 11:37 AM, Thomas Andraschko 
   andraschko.tho...@gmail.com wrote:
  
Hi,
   
AFAICS repositories are non-scoped, right?
Isn't it possible to make them appscoped?
   
Regards,
Thomas

Re: [data] dto and isNew

2014-06-17 Thread Thomas Hug

 at all, but something like it
 would
   work
 well
  together with the default strategy for determine save or
 merge...
  But
my
  main wish now is to override the save logic actually.
 
 
 
 
 
 
 
 
 
 
 
  On 16 June 2014 09:48, Thomas Hug thomas@gmail.com wrote:
 
   Thanks Karl for the clarification!
   If you assign a new group, I'd first make sure you have this
 one
  persisted
   as well (or we do too much in the mapper IMO). Then save the
   userDto
 with
   something like
  
   User toEntity(User user, UserDto dto) {
   ...
   user.setGroup(groupMapper.toEntity(dto.getGroup()); // or
  check
  before
   if ID changed
   }
  
   I guess that would even work if the group is not persisted if
 you
adapt
   cascading.
  
   Makes sense?
  
   On Fri, Jun 13, 2014 at 5:56 PM, Karl Kildén 
   karl.kil...@gmail.com
   wrote:
  
Not sure I get myself ;)
   
Lets walk through how I see it:
   
1. User foo is created and is assigned to the preexisting
  group
   Admin.
   
It goes like this in the flow: user = new UserDTO() -
*user*.setGroupDTO(selectedGroup)
- save
   
Some logic must make sure that we don't get
  EntityExistsException
  trying
   to
save that group.
   
   
2. Many sessions later user foo is edited. Flow:
*user*.setGroupDTO(newGroup)
- save
   
The variable *user *is a random object that happens to be
 the
latest
version of that user that also has a new group set.
   
So  *PK, user.getGroup()*
*should lazyload the group - right? *This will result in the
previous
   group
being loaded unless I am missing something. While it is
   technically
   correct
since the new group relationship has not been persisted yet
 it
  is
   actually
impossible to ever update group with this flow
   
   
   
   
   
   
   
On 13 June 2014 17:09, Thomas Hug thomas@gmail.com
  wrote:
   
 Hi Karl
 Sorry not sure if I get you right. Why would
 user.getGroup()
  be
  stale?
   As
 in the update case user has just been fetched by the PK,
   user.getGroup()
 should lazyload the group - right?


 On Fri, Jun 13, 2014 at 2:51 PM, Karl Kildén 
 karl.kil...@gmail.com
 wrote:

  Hi and hrmmm,
 
  What if user group was changed?
groupMapper.toEntity(user.getGroup(),
  userDto.getGroup()); This would then operate on stale
 data
unless
  you
 fetch
  and send in correct group. And managing new groups is
 easy
   for
 me I
 think,
  I would call the method using groupMapper.toEntity(new
   Group(),
  userDto.getGroup());
 
 
  I would much prefer all three methods to be non
 protected.
Then I
   could
  create my helper something along the lines of this:
 
  I did not test this very well but unless I thought wrong
 completely
   it
  would be a one time thing to implement. But using
 mappers
   from
   mappers
 are
  hard because if the relationship is declared in both
 ways
  you
can
  get
  circular references. Anyways here's my helper I
  theorycrafted
   together:
 
 
  Group g = fetch (new Group(), user.getGroup(),
  groupMapper);
 
  public Entity, Dto Entity fetch(Entity entity, Dto
  dto,
  SimpleQueryInOutMapperBaseEntity, Dto entityMapper){
  Object pk = entityMapper.getPrimaryKey(dto);
  Entity foundEntity = (Entity)
 entityManager.find(entity.getClass(),
  pk);
 
  if (foundEntity == null) {
  foundEntity = entity;
  }
  return entityMapper.toEntity(foundEntity, dto);
  }
 
 
 
  One could always create their own base class overriding
 the
  protected
  methods and adding that fetch helper I guess...
 
  cheers
 
 
 
 
 
 
 
 
  On 13 June 2014 12:54, Thomas Hug thomas@gmail.com
 
wrote:
 
   Hey Karl
  
   Sorry missed your mail indeed - it's probably time I
subscribe
 to
   the
  user
   mailing list too :-)
  
   You can still chain those mappers together, but I
 agree
  the
  casting
and
   wiring is clunky. As options I see:
   - we add a public E toEntity(Dto dto) back which

Re: [data] dto and isNew

2014-06-16 Thread Thomas Hug

Thanks Karl for the clarification!
If you assign a new group, I'd first make sure you have this one persisted
as well (or we do too much in the mapper IMO). Then save the userDto with
something like

User toEntity(User user, UserDto dto) {
...
user.setGroup(groupMapper.toEntity(dto.getGroup()); // or check before
if ID changed
}

I guess that would even work if the group is not persisted if you adapt
cascading.

Makes sense?

On Fri, Jun 13, 2014 at 5:56 PM, Karl Kildén karl.kil...@gmail.com wrote:

 Not sure I get myself ;)

 Lets walk through how I see it:

 1. User foo is created and is assigned to the preexisting group Admin.

 It goes like this in the flow: user = new UserDTO() -
 *user*.setGroupDTO(selectedGroup)
 - save

 Some logic must make sure that we don't get EntityExistsException trying to
 save that group.


 2. Many sessions later user foo is edited. Flow:
 *user*.setGroupDTO(newGroup)
 - save

 The variable *user *is a random object that happens to be the latest
 version of that user that also has a new group set.

 So  *PK, user.getGroup()*
 *should lazyload the group - right? *This will result in the previous group
 being loaded unless I am missing something. While it is technically correct
 since the new group relationship has not been persisted yet it is actually
 impossible to ever update group with this flow







 On 13 June 2014 17:09, Thomas Hug thomas@gmail.com wrote:

  Hi Karl
  Sorry not sure if I get you right. Why would user.getGroup() be stale? As
  in the update case user has just been fetched by the PK, user.getGroup()
  should lazyload the group - right?
 
 
  On Fri, Jun 13, 2014 at 2:51 PM, Karl Kildén karl.kil...@gmail.com
  wrote:
 
   Hi and hrmmm,
  
   What if user group was changed?  groupMapper.toEntity(user.getGroup(),
   userDto.getGroup()); This would then operate on stale data unless you
  fetch
   and send in correct group. And managing new groups is easy for me I
  think,
   I would call the method using groupMapper.toEntity(new Group(),
   userDto.getGroup());
  
  
   I would much prefer all three methods to be non protected. Then I could
   create my helper something along the lines of this:
  
   I did not test this very well but unless I thought wrong completely it
   would be a one time thing to implement. But using mappers from mappers
  are
   hard because if the relationship is declared in both ways you can get
   circular references. Anyways here's my helper I theorycrafted together:
  
  
   Group g = fetch (new Group(), user.getGroup(), groupMapper);
  
   public Entity, Dto Entity fetch(Entity entity, Dto dto,
   SimpleQueryInOutMapperBaseEntity, Dto entityMapper){
   Object pk = entityMapper.getPrimaryKey(dto);
   Entity foundEntity = (Entity)
  entityManager.find(entity.getClass(),
   pk);
  
   if (foundEntity == null) {
   foundEntity = entity;
   }
   return entityMapper.toEntity(foundEntity, dto);
   }
  
  
  
   One could always create their own base class overriding the protected
   methods and adding that fetch helper I guess...
  
   cheers
  
  
  
  
  
  
  
  
   On 13 June 2014 12:54, Thomas Hug thomas@gmail.com wrote:
  
Hey Karl
   
Sorry missed your mail indeed - it's probably time I subscribe to the
   user
mailing list too :-)
   
You can still chain those mappers together, but I agree the casting
 and
wiring is clunky. As options I see:
- we add a public E toEntity(Dto dto) back which basically does the
  same
   as
mapParameter now (just hides the casting) for new entities
- we make the E toEntity(Entity e, Dto dto) public as well, so it's
  quite
easy to chain mapper calls for updates
   
groupMapper.toEntity(user.getGroup(), userDto.getGroup());
   
You will still have to have some conditionals to see which one to
 call,
also depends on your data model (required relations, lazy or eager
   fetch).
How does that look? Better ideas?
   
   
   
On Fri, Jun 13, 2014 at 8:42 AM, Karl Kildén karl.kil...@gmail.com
wrote:
   
 I wrote a response to the users list but not sure it came through.
 It
kinda
 belongs in this thread so here it goes.


 So I ran into issues with the DTO mapper api and voiced my concerns
  in
irc.
 I saw this discussion and now I am trying the solution present in
 the
 current SNAPSHOT. However I have one comment / question:

 What if my Entity has a relationship to another Entity?

 Like this:

 public class User extends BaseAuditEntity {

 @Column
 private String name;

 @Column
 @ManyToOne
 @JoinColumn(name=group_id)
 private Group group;

 This means my userDTO may come with a GroupDTO and how do I map
 that
 relationship? Or to explain by code please fill in the question
 marks
below
 ;) or if you feel my implementation

Re: [data] dto and isNew

2014-06-13 Thread Thomas Hug

Hey Karl

Sorry missed your mail indeed - it's probably time I subscribe to the user
mailing list too :-)

You can still chain those mappers together, but I agree the casting and
wiring is clunky. As options I see:
- we add a public E toEntity(Dto dto) back which basically does the same as
mapParameter now (just hides the casting) for new entities
- we make the E toEntity(Entity e, Dto dto) public as well, so it's quite
easy to chain mapper calls for updates

groupMapper.toEntity(user.getGroup(), userDto.getGroup());

You will still have to have some conditionals to see which one to call,
also depends on your data model (required relations, lazy or eager fetch).
How does that look? Better ideas?



On Fri, Jun 13, 2014 at 8:42 AM, Karl Kildén karl.kil...@gmail.com wrote:

 I wrote a response to the users list but not sure it came through. It kinda
 belongs in this thread so here it goes.


 So I ran into issues with the DTO mapper api and voiced my concerns in irc.
 I saw this discussion and now I am trying the solution present in the
 current SNAPSHOT. However I have one comment / question:

 What if my Entity has a relationship to another Entity?

 Like this:

 public class User extends BaseAuditEntity {

 @Column
 private String name;

 @Column
 @ManyToOne
 @JoinColumn(name=group_id)
 private Group group;

 This means my userDTO may come with a GroupDTO and how do I map that
 relationship? Or to explain by code please fill in the question marks below
 ;) or if you feel my implementation is weird then I would gladly accept
 comments on that too. But the way I see it I need to @Inject the
 GroupMapper, use the EntityManager to find the Group then call
 groupMapper.toEntity and then I think to myself that the API is worse now
 because before I could call groupMapper.toEntity with only a dto argument.
 At that point you had to use the entitymanager anyways to find yourself
 and that feels clean compared to find your entities you form relationships
 with.

 @Override
 protected User toEntity(final User user, final UserDTO userDTO) {
 MapperUtil.toAuditEntity(user, userDTO);
 user.setName(userDTO.getName());
 user.setEmail(userDTO.getEmail());
 user.setLocale(userDTO.getLocale());
 user.setGroup(*?*);
 return user;
 }

 Cheers / Karl


 On 17 May 2014 16:40, Romain Manni-Bucau rmannibu...@gmail.com wrote:

  Yep, missed it.
 
  Works for me. Maybe the name should be closer to other methods,
  mapKey? But whatever you choose as name this solution works :).
 
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
  2014-05-17 15:54 GMT+02:00 Thomas Hug thomas@gmail.com:
   It's the PK, not the Entity ;) In SimpleQueryInOutMapperBase, it could
 be
   something like
  
   @Inject
   private QueryInvocationContext context;
  
   protected abstract Object getPrimaryKey(Dto dto);
  
   protected E findEntity(Object pk)
   {
   return (E)
 context.getEntityManager().find(context.getEntityClass(),
   pk);
   }
  
   @Override
   public Object mapParameter(final Object parameter)
   {
   Object pk = getPrimaryKey((Dto) parameter);
   if (pk != null)
   {
   E entity = findEntity(pk);
   return toEntity(entity, (Dto) parameter);
   }
   return toEntity(newEntity(), (Dto) parameter);
   }
  
  
   On Sat, May 17, 2014 at 1:57 PM, Romain Manni-Bucau
   rmannibu...@gmail.comwrote:
  
   would work while return is E and not Object ;)
  
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
   2014-05-17 11:47 GMT+02:00 Thomas Hug thomas@gmail.com:
Or a protected abstract Object getPrimaryKey(Dto dto). We can get
 the
  EM
over an injected QueryInvocationContext.
   
   
On Thu, May 15, 2014 at 9:06 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
   
I think a protected findEntity(id) in the mapper can be enough.
   
   
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
   
   
2014-05-07 22:29 GMT+02:00 Thomas Hug thomas@gmail.com:
 Hi Romain,
 See your point. But if we only get the DTO - with what would we
  call
   the
 find? Could even be that the PK is a DTO or encoded / encrypted
 and
   needs
 to go through the mapper first. Maybe we can provide some
  convenience
 methods in the base mapper?


 On Tue, May 6, 2014 at 7:41 PM, Romain Manni-Bucau 
rmannibu...@gmail.comwrote:

 Hi guys,

 DTO feature is awesome but doesn't work in update mode since
 isNew
 doesn't use a managed entity.

 When

Re: [data] dto and isNew

2014-06-13 Thread Thomas Hug

Hi Karl
Sorry not sure if I get you right. Why would user.getGroup() be stale? As
in the update case user has just been fetched by the PK, user.getGroup()
should lazyload the group - right?


On Fri, Jun 13, 2014 at 2:51 PM, Karl Kildén karl.kil...@gmail.com wrote:

 Hi and hrmmm,

 What if user group was changed?  groupMapper.toEntity(user.getGroup(),
 userDto.getGroup()); This would then operate on stale data unless you fetch
 and send in correct group. And managing new groups is easy for me I think,
 I would call the method using groupMapper.toEntity(new Group(),
 userDto.getGroup());


 I would much prefer all three methods to be non protected. Then I could
 create my helper something along the lines of this:

 I did not test this very well but unless I thought wrong completely it
 would be a one time thing to implement. But using mappers from mappers are
 hard because if the relationship is declared in both ways you can get
 circular references. Anyways here's my helper I theorycrafted together:


 Group g = fetch (new Group(), user.getGroup(), groupMapper);

 public Entity, Dto Entity fetch(Entity entity, Dto dto,
 SimpleQueryInOutMapperBaseEntity, Dto entityMapper){
 Object pk = entityMapper.getPrimaryKey(dto);
 Entity foundEntity = (Entity) entityManager.find(entity.getClass(),
 pk);

 if (foundEntity == null) {
 foundEntity = entity;
 }
 return entityMapper.toEntity(foundEntity, dto);
 }



 One could always create their own base class overriding the protected
 methods and adding that fetch helper I guess...

 cheers








 On 13 June 2014 12:54, Thomas Hug thomas@gmail.com wrote:

  Hey Karl
 
  Sorry missed your mail indeed - it's probably time I subscribe to the
 user
  mailing list too :-)
 
  You can still chain those mappers together, but I agree the casting and
  wiring is clunky. As options I see:
  - we add a public E toEntity(Dto dto) back which basically does the same
 as
  mapParameter now (just hides the casting) for new entities
  - we make the E toEntity(Entity e, Dto dto) public as well, so it's quite
  easy to chain mapper calls for updates
 
  groupMapper.toEntity(user.getGroup(), userDto.getGroup());
 
  You will still have to have some conditionals to see which one to call,
  also depends on your data model (required relations, lazy or eager
 fetch).
  How does that look? Better ideas?
 
 
 
  On Fri, Jun 13, 2014 at 8:42 AM, Karl Kildén karl.kil...@gmail.com
  wrote:
 
   I wrote a response to the users list but not sure it came through. It
  kinda
   belongs in this thread so here it goes.
  
  
   So I ran into issues with the DTO mapper api and voiced my concerns in
  irc.
   I saw this discussion and now I am trying the solution present in the
   current SNAPSHOT. However I have one comment / question:
  
   What if my Entity has a relationship to another Entity?
  
   Like this:
  
   public class User extends BaseAuditEntity {
  
   @Column
   private String name;
  
   @Column
   @ManyToOne
   @JoinColumn(name=group_id)
   private Group group;
  
   This means my userDTO may come with a GroupDTO and how do I map that
   relationship? Or to explain by code please fill in the question marks
  below
   ;) or if you feel my implementation is weird then I would gladly accept
   comments on that too. But the way I see it I need to @Inject the
   GroupMapper, use the EntityManager to find the Group then call
   groupMapper.toEntity and then I think to myself that the API is worse
 now
   because before I could call groupMapper.toEntity with only a dto
  argument.
   At that point you had to use the entitymanager anyways to find
 yourself
   and that feels clean compared to find your entities you form
  relationships
   with.
  
   @Override
   protected User toEntity(final User user, final UserDTO userDTO) {
   MapperUtil.toAuditEntity(user, userDTO);
   user.setName(userDTO.getName());
   user.setEmail(userDTO.getEmail());
   user.setLocale(userDTO.getLocale());
   user.setGroup(*?*);
   return user;
   }
  
   Cheers / Karl
  
  
   On 17 May 2014 16:40, Romain Manni-Bucau rmannibu...@gmail.com
 wrote:
  
Yep, missed it.
   
Works for me. Maybe the name should be closer to other methods,
mapKey? But whatever you choose as name this solution works :).
   
   
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
   
   
2014-05-17 15:54 GMT+02:00 Thomas Hug thomas@gmail.com:
 It's the PK, not the Entity ;) In SimpleQueryInOutMapperBase, it
  could
   be
 something like

 @Inject
 private QueryInvocationContext context;

 protected abstract Object getPrimaryKey(Dto dto);

 protected E findEntity(Object pk)
 {
 return (E

Re: [VOTE] logo-shape

2014-06-12 Thread Thomas Hug

+1 on #3 and #12


On Thu, Jun 12, 2014 at 7:34 AM, Nicklas Karlsson nicka...@gmail.com
wrote:

 #12, #2 (most options look a bit like aiming for the letter A and #13
 reminds a bit of the german SS-logo) ;-)


 On Thu, Jun 12, 2014 at 5:11 AM, Shane Bryzak sbry...@redhat.com wrote:

  +1 for #1
 
 
  On 06/12/2014 12:51 AM, Gerhard Petracek wrote:
 
  hi @ all,
 
  this first vote is just about the basic shape/style and not the color.
 
  i've uploaded the candidates provided by jim at [1].
  please send a +1 for one (or two) logo shape/s.
  (there will be a 2nd vote about the color afterwards.)
 
  regards,
  gerhard
 
  [1] http://s.apache.org/DS_LOGO1_VOTE1
 
 
 


 --
 Nicklas Karlsson, +358 40 5062266
 Vaakunatie 10 as 7, 20780 Kaarina

Re: Data Module - Criteria Support

2014-06-12 Thread Thomas Hug

Hi Radu,

Thanks for paying attention! You're right, doesn't really make sense.
Additionally, the result type can also be narrowed down to a
QuerySelectionE, Long.
I'll create a JIRA ticket for it.

Cheers,
Thomas



On Thu, Jun 12, 2014 at 4:53 PM, Radu Creanga rdc...@gmail.com wrote:

 Hi @all,

 I am just trying out the data module and it seems that the
 CriteriaSupport#count() method is too restrictive on the attribute
 parameter type. The current declaration is:

 N extends Number QuerySelectionE, N count(SingularAttributeE, N
 attribute);

 while it should probably be:

 N extends Number QuerySelectionE, N count(SingularAttributeE, ?
 attribute);

 That's because when using the Criteria API alone, there is no such
 restriction to the attribute type. Could this be an oversight?

 Best regards,
 Radu

[jira] [Resolved] (DELTASPIKE-639) Fix Criteria API count methods signatures

2014-06-12 Thread Thomas Hug (JIRA)


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

Thomas Hug resolved DELTASPIKE-639.
---

Resolution: Fixed

API updated.

 Fix Criteria API count methods signatures
 -

 Key: DELTASPIKE-639
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-639
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 0.7
Reporter: Thomas Hug
Assignee: Thomas Hug
 Fix For: 1.0.0


 The method signatures for the count should:
 - Return a QuerySelectionE, Long
 - Take a SingularAttributeE, ? as parameter



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (DELTASPIKE-627) Distinguish saves and updates

2014-06-12 Thread Thomas Hug (JIRA)


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

Thomas Hug resolved DELTASPIKE-627.
---

Resolution: Fixed

Javadoc of save updated. The distinction can be made using 
EntityManagerDelegate.

 Distinguish saves and updates
 -

 Key: DELTASPIKE-627
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-627
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 0.7
Reporter: Harald Wellmann
Assignee: Thomas Hug

 JPA {{EntityManager}} has distinct {{persist()}} and {{merge()}} methods, and 
 there's a reason for that.
 DeltaSpike {{EntityRepository}} hides both behind a {{save()}} method which 
 loses information and does not always do the right thing.
 Example:
 Take an entity with a user-defined ID of type String, e.g.
 {code}
 @Entity
 public class Language {
 @Id
 private String id;
 private String name;
 }
 {code}
 Using {{EntityManager.persist()}}, we get an {{EntityExistsException}}:
 {code}
 em.persist(new Language(de, Deutsch));
 em.persist(new Language(de, Doitsch));
 {code}
 Using {{EntityRepository.save()}}, the first entity is silently overwritten 
 by the second one.
 {code}
 repository.save(new Language(de, Deutsch));
 repository.save(new Language(de, Doitsch));
 {code}
 Goals:
 * Clarify semantics of save() in the Javadoc.
 * Add a create() method with persist() semantics.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (DELTASPIKE-627) Distinguish saves and updates

2014-06-06 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019761#comment-14019761
 ] 

Thomas Hug commented on DELTASPIKE-627:
---

The upcoming release allows to call persist / merge explicitly, see 
http://deltaspike.apache.org/data.html#other-entitymanager-methods


 Distinguish saves and updates
 -

 Key: DELTASPIKE-627
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-627
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 0.7
Reporter: Harald Wellmann
Assignee: Thomas Hug

 JPA {{EntityManager}} has distinct {{persist()}} and {{merge()}} methods, and 
 there's a reason for that.
 DeltaSpike {{EntityRepository}} hides both behind a {{save()}} method which 
 loses information and does not always do the right thing.
 Example:
 Take an entity with a user-defined ID of type String, e.g.
 {code}
 @Entity
 public class Language {
 @Id
 private String id;
 private String name;
 }
 {code}
 Using {{EntityManager.persist()}}, we get an {{EntityExistsException}}:
 {code}
 em.persist(new Language(de, Deutsch));
 em.persist(new Language(de, Doitsch));
 {code}
 Using {{EntityRepository.save()}}, the first entity is silently overwritten 
 by the second one.
 {code}
 repository.save(new Language(de, Deutsch));
 repository.save(new Language(de, Doitsch));
 {code}
 Goals:
 * Clarify semantics of save() in the Javadoc.
 * Add a create() method with persist() semantics.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (DELTASPIKE-617) Utility Method for TypedQuery in AbstractEntityRepository

2014-05-27 Thread Thomas Hug (JIRA)


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

Thomas Hug resolved DELTASPIKE-617.
---

Resolution: Fixed

 Utility Method for TypedQuery in AbstractEntityRepository
 -

 Key: DELTASPIKE-617
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-617
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Thomas Hug
Assignee: Thomas Hug
 Fix For: 0.8


 As there is also a criteriaQuery(). Should encourage users to rather use a 
 TypedQuery than a JPA 1 Query, conflicting with the repository @Query.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (DELTASPIKE-606) Simplified DTO mapping for Entity updates

2014-05-26 Thread Thomas Hug (JIRA)


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

Thomas Hug resolved DELTASPIKE-606.
---

Resolution: Fixed

 Simplified DTO mapping for Entity updates
 -

 Key: DELTASPIKE-606
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-606
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Thomas Hug
Assignee: Thomas Hug
 Fix For: 0.8


 Updating a DTO currently still requires custom code in a mapper. This should 
 be reduced to a minimum in the mapper base class.
 SimpleQueryInOutMapperBase:
 {code:java}
 @Inject
 private QueryInvocationContext context;
 protected abstract Object getPrimaryKey(Dto dto);
 protected E findEntity(Object pk)
 {
 return (E) context.getEntityManager().find(context.getEntityClass(), pk);
 } 
 @Override
 public Object mapParameter(final Object parameter)
 {
 Object pk = getPrimaryKey((Dto) parameter);
 if (pk != null)
 {
 E entity = findEntity(pk);
 return toEntity(entity, (Dto) parameter);
 }
 return toEntity(newEntity(), (Dto) parameter);
 }
 {code}
 Note that this is an API breaking change (toEntity).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: @Query naming conflict with javax.persistence.Query. Rename?

2014-05-26 Thread Thomas Hug

At least for me, it's typically when the findByExample doesn't work anymore
(date range searches etc).


On Mon, May 26, 2014 at 5:21 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 well, honestly more abstract repo are promoted less they seem useful.
 interfaces are where the real added value is then some interceptors (for
 audit for instance) are nice but no more. Abstract repo are technically
 interesting but for app code they seem just a debt, no? What would be the
 real use case then?



 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau


 2014-05-26 16:56 GMT+02:00 Thomas Hug thomas@gmail.com:

  Thought about this too as it pops up also in some impl classes, but
  couldn't think of a better concise name :-)
  What about adding something like a
 
  TypedQueryE createTypedQuery(...)  // eventually rename createQuery
  for the CriteriaQuery result?
 
  to AbstractEntityRepository? Might make the workaround more obvious.
 
 
 
  On Mon, May 26, 2014 at 4:38 PM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
   You will not get it using TypedQuery ;).
  
   @Query is the smoother default IMO
  
  
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
   2014-05-26 16:22 GMT+02:00 Thomas Andraschko 
  andraschko.tho...@gmail.com
   :
  
Hi,
   
i currently start to use the Data Module and one thing isn't really
  nice.
   
If you have an abstract Repository, you likely have an import of
javax.persistence.Query and maybe @Query.
   
What do you think about renaming @Query to resolve the naming
 conflict?
   
Regards,
Thomas

[jira] [Created] (DELTASPIKE-606) Simplified DTO mapping for Entity updates

2014-05-25 Thread Thomas Hug (JIRA)

Thomas Hug created DELTASPIKE-606:
-

 Summary: Simplified DTO mapping for Entity updates
 Key: DELTASPIKE-606
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-606
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Thomas Hug
Assignee: Thomas Hug
 Fix For: 0.8


Updating a DTO currently still requires custom code in a mapper. This should be 
reduced to a minimum in the mapper base class.

SimpleQueryInOutMapperBase:

{code:java}
@Inject
private QueryInvocationContext context;

protected abstract Object getPrimaryKey(Dto dto);

protected E findEntity(Object pk)
{
return (E) context.getEntityManager().find(context.getEntityClass(), pk);
} 

@Override
public Object mapParameter(final Object parameter)
{
Object pk = getPrimaryKey((Dto) parameter);
if (pk != null)
{
E entity = findEntity(pk);
return toEntity(entity, (Dto) parameter);
}
return toEntity(newEntity(), (Dto) parameter);
}
{code}

Note that this is an API breaking change (toEntity).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (DELTASPIKE-607) Add EntityManagerDelegateE interface to API

2014-05-25 Thread Thomas Hug (JIRA)

Thomas Hug created DELTASPIKE-607:
-

 Summary: Add EntityManagerDelegateE interface to API
 Key: DELTASPIKE-607
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-607
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Thomas Hug
Assignee: Thomas Hug
 Fix For: 0.8


Gives access to all EntityManager methods. Simplifies the EM interfaces 
slightly by being parameterized, and allows dealing with different version of 
JPA. Repositories can simply extend / implement the interface.

Fixes DELTASPIKE-604.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (DELTASPIKE-604) Add #merge to EntityRepository

2014-05-23 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14006954#comment-14006954
 ] 

Thomas Hug commented on DELTASPIKE-604:
---

Is #save not working for you? Calls either persist or merge depending on the 
entity state.

 Add #merge to EntityRepository
 --

 Key: DELTASPIKE-604
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-604
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Thomas Andraschko





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (DELTASPIKE-604) Add #merge to EntityRepository

2014-05-23 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14006968#comment-14006968
 ] 

Thomas Hug commented on DELTASPIKE-604:
---

Ok I see. My preference would actually be to allow repositories to extend / 
implement EntityManager (or we keep repeating the exercise for all kind of EM 
methods ;-)) but that probably requires some more control on the PartialBean 
bean types.

 Add #merge to EntityRepository
 --

 Key: DELTASPIKE-604
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-604
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Thomas Andraschko





--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Data Module - Provide an abstract base entity class?

2014-05-20 Thread Thomas Hug

+0 Seen this in several places already, so people seem to like it ;) Agree
with Romain that it will be hard to come up with a reasonable impl (also
considering optimistic locking, timestamps, ...) - main reason auditing in
the data module is annotation- and not type-based.


On Tue, May 20, 2014 at 1:12 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 well the class only implements equals/hashcode which are pretty simpler
 without abstraction, that's why I asked. BTW we could add what spring-data
 has with the Persistable hierarchy but then we should agree on the default
 impl (and pretty sure we'll not: UUID, generated value as in spring-data
 etc...).

 PS: the hierarchy can be seen

 http://grepcode.com/file/repo1.maven.org/maven2/org.springframework.data/spring-data-jpa/1.0.3.RELEASE/org/springframework/data/jpa/domain/AbstractAuditable.java?av=h#AbstractAuditable



 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau


 2014-05-20 13:07 GMT+02:00 Karl Kildén karl.kil...@gmail.com:

  Hi,
 
  The gain is that the collective behind the data module are pretty much
 the
  people I would hire to write my base class if I could ;)
 
  It also unifies how stuff is done etc...
 
 
  On 20 May 2014 13:03, Romain Manni-Bucau rmannibu...@gmail.com wrote:
 
   Hi
  
   +-0 nothing particular against but not sure the real gain is
  
  
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
   2014-05-20 12:57 GMT+02:00 Thomas Andraschko 
  andraschko.tho...@gmail.com
   :
  
Hi,
   
WDYT about providing an abstract base entity?
I always copy this from project to project...
   
Here is a example:
https://gist.github.com/tandraschko/a5a79c4edb3e742fc75b
   
Regards,
Thomas

Re: [data] dto and isNew

2014-05-17 Thread Thomas Hug

Or a protected abstract Object getPrimaryKey(Dto dto). We can get the EM
over an injected QueryInvocationContext.


On Thu, May 15, 2014 at 9:06 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 I think a protected findEntity(id) in the mapper can be enough.


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau


 2014-05-07 22:29 GMT+02:00 Thomas Hug thomas@gmail.com:
  Hi Romain,
  See your point. But if we only get the DTO - with what would we call the
  find? Could even be that the PK is a DTO or encoded / encrypted and needs
  to go through the mapper first. Maybe we can provide some convenience
  methods in the base mapper?
 
 
  On Tue, May 6, 2014 at 7:41 PM, Romain Manni-Bucau 
 rmannibu...@gmail.comwrote:
 
  Hi guys,
 
  DTO feature is awesome but doesn't work in update mode since isNew
  doesn't use a managed entity.
 
  When using a mapper we should call find and pass it to the mapper (or
  create a new unmanaged entity if not found). So mapper signature
  should be Entity toEntity(Entity, DTO) no?
 
  Otherwise users need to do the find in the mapper...almost eveytime.
 
  wdyt?
 
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau

Re: [data] dto and isNew

2014-05-17 Thread Thomas Hug

It's the PK, not the Entity ;) In SimpleQueryInOutMapperBase, it could be
something like

@Inject
private QueryInvocationContext context;

protected abstract Object getPrimaryKey(Dto dto);

protected E findEntity(Object pk)
{
return (E) context.getEntityManager().find(context.getEntityClass(),
pk);
}

@Override
public Object mapParameter(final Object parameter)
{
Object pk = getPrimaryKey((Dto) parameter);
if (pk != null)
{
E entity = findEntity(pk);
return toEntity(entity, (Dto) parameter);
}
return toEntity(newEntity(), (Dto) parameter);
}


On Sat, May 17, 2014 at 1:57 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 would work while return is E and not Object ;)


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau


 2014-05-17 11:47 GMT+02:00 Thomas Hug thomas@gmail.com:
  Or a protected abstract Object getPrimaryKey(Dto dto). We can get the EM
  over an injected QueryInvocationContext.
 
 
  On Thu, May 15, 2014 at 9:06 PM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
  I think a protected findEntity(id) in the mapper can be enough.
 
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
  2014-05-07 22:29 GMT+02:00 Thomas Hug thomas@gmail.com:
   Hi Romain,
   See your point. But if we only get the DTO - with what would we call
 the
   find? Could even be that the PK is a DTO or encoded / encrypted and
 needs
   to go through the mapper first. Maybe we can provide some convenience
   methods in the base mapper?
  
  
   On Tue, May 6, 2014 at 7:41 PM, Romain Manni-Bucau 
  rmannibu...@gmail.comwrote:
  
   Hi guys,
  
   DTO feature is awesome but doesn't work in update mode since isNew
   doesn't use a managed entity.
  
   When using a mapper we should call find and pass it to the mapper (or
   create a new unmanaged entity if not found). So mapper signature
   should be Entity toEntity(Entity, DTO) no?
  
   Otherwise users need to do the find in the mapper...almost eveytime.
  
   wdyt?
  
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau

[jira] [Commented] (DELTASPIKE-589) Support WLS Profile in Data Module

2014-05-10 Thread Thomas Hug (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13993475#comment-13993475
 ] 

Thomas Hug commented on DELTASPIKE-589:
---

Anyone seen this problem while running tests on WLS?

Simple Deployment:

{code:java}
@Deployment
public static Archive? deployment()
{
WebArchive archive = ShrinkWrap
.create(WebArchive.class, test.war)
.addAsWebInfResource(EmptyAsset.INSTANCE, 
ArchivePaths.create(beans.xml))
.addAsLibraries(
Maven.resolver().loadPomFromFile(pom.xml)
.resolve(

org.apache.deltaspike.core:deltaspike-core-api,

org.apache.deltaspike.core:deltaspike-core-impl)
.withTransitivity()
.asFile()
);
return archive;
}
{code}

Fails to deploy with

{code}
weblogic.management.DeploymentException: 
org.jboss.weld.exceptions.DeploymentException: Exception List with 4 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied 
dependencies for type [MBeanExtension] with qualifiers [@Default] at injection 
point [[field] @Inject private 
org.apache.deltaspike.core.impl.jmx.BroadcasterProducer.extension]
at 
org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
...
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied 
dependencies for type [ExceptionControlExtension] with qualifiers [@Default] at 
injection point [[field] @Inject private 
org.apache.deltaspike.core.impl.exception.control.HandlerMethodStorageProducer.exceptionControlExtension]
at 
org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
...
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied 
dependencies for type [DeltaSpikeContextExtension] with qualifiers [@Default] 
at injection point [[field] @Inject private 
org.apache.deltaspike.core.impl.scope.conversation.GroupedConversationArtifactProducer.deltaSpikeContextExtension]
at 
org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
...
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied 
dependencies for type [DeltaSpikeContextExtension] with qualifiers [@Default] 
at injection point [[field] @Inject private 
org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.deltaSpikeContextExtension]
at 
org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
...
{code}

 Support WLS Profile in Data Module
 --

 Key: DELTASPIKE-589
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-589
 Project: DeltaSpike
  Issue Type: Task
  Components: Build, Data-Module
Affects Versions: 0.7
Reporter: Thomas Hug
Assignee: Thomas Hug
 Fix For: 0.8


 Add a WLS-specific test-persistence.xml included by the WLS profiles.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (DELTASPIKE-589) Support WLS Profile in Data Module

2014-05-05 Thread Thomas Hug (JIRA)

Thomas Hug created DELTASPIKE-589:
-

 Summary: Support WLS Profile in Data Module
 Key: DELTASPIKE-589
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-589
 Project: DeltaSpike
  Issue Type: Task
  Components: Build, Data-Module
Reporter: Thomas Hug
Assignee: Thomas Hug


Add a WLS-specific test-persistence.xml included by the WLS profiles.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (DELTASPIKE-578) org.apache.deltaspike.data.impl.meta.RepositoryComponent is not thread safe

2014-04-30 Thread Thomas Hug (JIRA)


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

Thomas Hug resolved DELTASPIKE-578.
---

Resolution: Fixed

 org.apache.deltaspike.data.impl.meta.RepositoryComponent is not thread safe
 ---

 Key: DELTASPIKE-578
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-578
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 0.6
Reporter: Stuart Douglas
Assignee: Thomas Hug
 Fix For: 0.7

 Attachments: DELTASPIKE-578.patch


 The lazy init process is not thread safe. In particular the code checks if 
 entityManagerResolverIsNormalScope is null to determine if the entity is 
 initialised, however this is set before the initialisation is actually 
 completed, meaning a thread can get an uninitialized component, which then 
 causes problems. 
 The initialize() call should be moved up to before 
 entityManagerResolverIsNormalScope is set.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

1 2 >

1 - 100 of 135 matches

Mail list logo