Roland Häder [Thu, 18 Jul 2019 03:46:01 +0000 (05:46 +0200)]
Please cherry-pick:
- added final modifier because these references shall never be changed
- used interface Context as type (updated signature of inherited method)
Roland Häder [Thu, 26 Apr 2018 20:54:23 +0000 (22:54 +0200)]
Please cherry-pick:
- made more local variables final (possible here) which gives the Java compiler
hints to optimize the binary a bit more
- always invoke super() until you have reach the most-super (highest class)
then there is no need for it as java.lang.Object is then next
Roland Häder [Mon, 17 Jul 2017 09:30:24 +0000 (11:30 +0200)]
Please cherry-pick:
- duplicated files removed
- renamed remaining the proper way as they are user-specific templates
- maybe one day this need more (directory-based) separation to have
smaller directories on server
Roland Häder [Sat, 8 Jul 2017 17:16:55 +0000 (19:16 +0200)]
Please cherry-pick:
- new project 'jfinancials-mailer-ejb' initialized from jfinancials-ejb
- this includes one message-driven bean and a singleton bean
- the message-driven bean accepts "wrapper" objects per JMS from outside EJB
- the singleton bean is then the "backend" which loads templates and delivers
the mail
- this split from general EJB project has the benefit of easier distributing
(cluster) load
- a lot libs were no longer needed
- added velocity engine (from jfinancials-mailer) as library
Roland Häder [Fri, 7 Jul 2017 22:27:02 +0000 (00:27 +0200)]
Please cherry-pick:
- rewrote email delivery as EmailDeliveryWrapper() has now a constructor with all required fields
- also saved one parameter (one lesser = easier code)
Roland Häder [Mon, 26 Jun 2017 22:17:58 +0000 (00:17 +0200)]
Don't cherry-pick:
- need to provide email queues for these EJBs as they will attempt to call
sendEmail() which would then throw a NPE:
----------------------------
Caused by: java.lang.NullPointerException
at org.mxchange.jfinancials.database.BaseFinancialsDatabaseBean.sendEmail(BaseFinancialsDatabaseBean.java:555)
at org.mxchange.jusercore.model.user.register.FinancialsUserRegistrationSessionBean.registerUser(FinancialsUserRegistrationSessionBean.java:208)
----------------------------
However, I will expand sendEmail() a bit to verify that the field session is
really there and not run in such ugly NPE.
Roland Häder [Mon, 26 Jun 2017 21:43:30 +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 [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 [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 [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)
Roland Häder [Tue, 23 Aug 2016 12:13:53 +0000 (14:13 +0200)]
Please cherry-pick:
- implemented business methods for deleting/updating fax/land-line numbers
- better this way: managedBla = em.find(Bla.class, bla.getBlaId()); and then managedBla.setBlaSomeFoo(someFooValue);
Roland Häder [Tue, 23 Aug 2016 09:33:14 +0000 (11:33 +0200)]
Please cherry-pick:
- detachAllContactPhoneEntries() was a bad idea, beter do it the old way.
- The returned instance was a managed instance that have been updated. First find it with find() then you have a managed instanced. Now simply update the fields you want and you are done.