Roland Häder [Tue, 17 Oct 2017 20:30:29 +0000 (22:30 +0200)]
Please cherry-pick:
- renamed employee as there will be no other employees
- added administrative country EJB due to remote interface separation
- removed find*ById() as this was causing load on EJB container which can be
prevented by application's JCache
- fixed persistence unit as entities have been moved
Roland Häder [Sat, 14 Oct 2017 13:32:51 +0000 (15:32 +0200)]
Please cherry-pick:
- added createManaged() methods for BranchOffice and HeadquartersData entities
- added helper method setAllOpeningTimesCreated() which sets "created" entity
property of all opening times
- renamed EJB [admin]companyEmployee to only plain [admin]employee (enough),
remember to write the "e" upper-case in adminEmployee
- added EJB for opening times
- added EJB for departments
- updated persistence unit with new entity class' name
Roland Häder [Sun, 24 Sep 2017 13:34:12 +0000 (15:34 +0200)]
Please cherry-pick:
- renamed setAllContactPhoneEntriesCreated() -> setAllPhoneEntriesCreated()
- added similar methods for company basic data and branch offices
- also their phone number's created timestamps must be set prior persisting
Roland Häder [Sat, 9 Sep 2017 12:49:54 +0000 (14:49 +0200)]
Please cherry-pick:
- re-package season has started: now all core project's entity packages do
always have following format: tld.domain.project.model.foo.SomeFoo;
- also fixed persistence unit
Roland Häder [Sat, 9 Sep 2017 12:18:10 +0000 (14:18 +0200)]
Please cherry-pick:
- introduced isSameCompanyNameAdded() which encapsulates checking for if a
company name has already been used. This is, together with the thrown checked
exception a last effort to prevent bad bad SqlException or any other
"low-level" exception as they are more severage than this.
- thumb of a rule: always pre-validate if all conditions are met (return "okay")
prior doing risky things where uncontrolled exceptions may be thrown.
- make company-owner (User), founder (Employee) and contact person (dito)
managed before persisting the whole BasicData instance as this makes sure that
no duplicates will end up in database
Roland Häder [Sat, 9 Sep 2017 11:35:31 +0000 (13:35 +0200)]
Please cherry-pick:
- removed explicit flush() on entity manager as this hurts performance + may
cause trouble when other entities (concurrently) are not "ready to be flushed)
- implemented addBranchOffice() + added missing public constructor
- added private method isBranchOfficeFound() which uses the general EJB for
retrieving whole branch office list
- added protected getManaged() for Contact and Country instances
- renamed companyDataId -> basicDataId
Roland Häder [Tue, 5 Sep 2017 20:03:36 +0000 (22:03 +0200)]
Please cherry-pick:
- added new stateless session beans for administrative and general purposes for
branch office data and implemented business methods
- moved allCompanyBasicData() to general bean as this is a general business method
- also had to switch EJB references (maybe one day lookup="" is required again?)
- added private method isContactFound() to check if contact is already registered
or not there
- this method is now used to throw proper checked exceptions (which in turn your
application must catch)
- implemented business method allCompanyBasicData()
- renamed getAllContacts() -> allContacts() as this is actually no getter
following naming-convention
- renamed getUserNameList() -> allUserNames() for same reason
- in fillUserData() added more checks on parameter 'user' as usual in many
places, including ifUserExists() and throw checked (wanted) exception if not
found in persistence provider
- added 'final' whereever possible, better optimization
- used not NULL when not needed, allowing more 'final' to be set
- updated persistence unit (new namespace for branch office entity)
- relicensed under Affero GPLv3 (no change to e.g. MIT will happen)
- added TODOs
Roland Häder [Sat, 26 Aug 2017 22:02:17 +0000 (00:02 +0200)]
Please cherry-pick/rename:
- added admin/general company employee session bean and implemented all methods
- implemented isCompanyNameUsed() and used dependency injection for injecting
other EJB
Roland Häder [Thu, 27 Jul 2017 21:12:48 +0000 (23:12 +0200)]
Please cherry-pick (when needed):
- duplicated BusinessDataSessionBean as (correctly) AdminBusinessDataSessionBean
- implemented generic business data EJB with first method which returns an
entity for given id number or throws a proper exception if not found
Roland Häder [Sun, 9 Jul 2017 08:35:33 +0000 (10:35 +0200)]
Please cherry-pick:
- returned managed instance so the web controller (backing bean in your web
application) can continue to use it (mostly fire an event)
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. :-)