Roland Häder [Mon, 26 Jun 2017 21:43:25 +0000 (23:43 +0200)]
Rewrite continued:
- Now all project-specific abstract web beans (controllers) inherit from BaseFacesBean to have these nice showFacesMessage() methods.
- Also all project-specific abstract EJBs inherit now only BaseDataBean (one was missing in an old project)
- So, if you have a WAR project, inherit from BaseFacesBean, if you have an EJB project, inherit from BaseDatabaseBean
Roland Häder [Mon, 26 Jun 2017 19:26:23 +0000 (21:26 +0200)]
Please cherry-pick:
- had moved copyAll() to new utility classes which is a much better place for
them. Per EJB standards, no "complex" methods in POJOs/entity classes which
makes sense. :-)
Roland Häder [Fri, 23 Jun 2017 18:23:39 +0000 (20:23 +0200)]
Please cherry-pick:
- rewrote to new copyAll() methods as having them in POJOs is no good idea
anyway as you should keep those objects as simple as possible.
Roland Häder [Thu, 22 Jun 2017 20:55:38 +0000 (22:55 +0200)]
Please cherry-pick:
- moved EJBs to proper package as they are user-related beans
- handled over randomPassword parameter to sendEmail()
- or null if not possible/wanted
Roland Häder [Sat, 3 Jun 2017 16:24:32 +0000 (18:24 +0200)]
Continued a bit:
- remote interface for resending confirmation link is now genweric in juser-lib
- updated method as checked exceptions are thrown
- updated copyright
- updated jar(s)
Roland Häder [Sat, 15 Apr 2017 21:57:41 +0000 (23:57 +0200)]
Continued and discontinued:
- jshop-ejb and jshop-receipt-ejb had persistence unit files which would make
it impossible to have two shops at the same system. Well, mostly not what you
want because you want performance, but who knows?
Roland Häder [Sat, 15 Apr 2017 19:10:57 +0000 (21:10 +0200)]
Continued:
- pizzaservice-core/mailer are now referenced as projects as they are
application-specific projects and not libraries (like e.g. juser-core is)
- updated jar(s)
Roland Häder [Thu, 1 Sep 2016 15:34:20 +0000 (17:34 +0200)]
Continued a bit:
- close internal TODO as the user-actiity-log can be used for this
- for this making easily to work, 2 new business methods have been added
- fetchAllUsersActivityLogByType() for a single type per user
- fetchAllUsersActivityLogByMultipleType() for multiple types per user
Roland Häder [Wed, 31 Aug 2016 14:45:52 +0000 (16:45 +0200)]
Please cherry-pick:
- the user instance needs to be merged into current persience context, else some of its child entities will be persisted (inserted) again
Roland Häder [Wed, 31 Aug 2016 13:32:16 +0000 (15:32 +0200)]
Please cherry-pick:
- renamed updatedUser -> managedUser
- better set all data in EJB to avoid managedUser become detached (as the scope is not EJB anymore)
Roland Häder [Thu, 25 Aug 2016 12:23:11 +0000 (14:23 +0200)]
Please cherry-pick:
- first the user instance must become managed, then persist log entry ...
- better check for Long, and not != null test (very lazy)
Roland Häder [Thu, 25 Aug 2016 10:34:53 +0000 (12:34 +0200)]
Please cherry-pick: (be careful with project-specific names!)
- <Project>UserActivitySessionBean should better extend BaseDatabaseBean as no mail is being sent from this type of EJB
- added activity JMS queue
- implemented it in message-driven bean
- this whole thing may be shortened to only the EJB but then it is synchronous and people then will experience a slow down on heavy load
Roland Häder [Thu, 25 Aug 2016 09:44:37 +0000 (11:44 +0200)]
Please cherry-pick:
- added message-driven bean (unfinished) for adding user activity log
- this is asynchronous and won't cause application freezes if inserting takes some time
Roland Häder [Wed, 24 Aug 2016 11:09:01 +0000 (13:09 +0200)]
Please cherry-pick:
- sadly all getReference() + merge() was based on wrong assumption, now find() returns a managed entity where all setter calls leads to an update
- used getManaged() of repeating code (DRY)
Roland Häder [Tue, 23 Aug 2016 15:50:42 +0000 (17:50 +0200)]
Please cherry-pick:
- if you don't want to have redundant entries (=objects aka. entities) in database of referenced entities, first you need to merge it as it is detached
- then you have a managed instance which you can set in the referencing entity back
- if you don't do this, the entity manager will "think" it is a new instance and persists + relinks it
- maybe some implementations don't do this, but the JPA standard (generic) seems to want to have this way
- do never implement for only one JPA implementation! Do always follow the generic JPA way
Roland Häder [Tue, 23 Aug 2016 13:03:00 +0000 (15:03 +0200)]
Please cherry-pick:
- copy all data from detached to managed instance before updating it
- this needs to be done before the updated timestamp is being set to make sure it is not overwritten by old value (as copyAll() may do it)