A patch from Pierre Smits for "ListEmplPositionFulfillments links to wrong profile of employee" at https://issues.apache.org/jira/browse/OFBIZ-5708

Instead it should link to EmployeeProfile of the employee.


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617229 13f79535-47bb-0310-9956-ffa450edef68
Some optimization for service event handler to prevent unnecessary operations at every service invocation.


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617473 13f79535-47bb-0310-9956-ffa450edef68
Fix for a typo and an important optimization: enabled cache lookup for the retrieval of SystemProperty records.


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617480 13f79535-47bb-0310-9956-ffa450edef68
Better French label

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617496 13f79535-47bb-0310-9956-ffa450edef68
Really better French label

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617498 13f79535-47bb-0310-9956-ffa450edef68
Add a helper method for auto adjusting the threadCount.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617808 13f79535-47bb-0310-9956-ffa450edef68
Add a global fork-join thread pool, and switch a bunch of stuff over to
it.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617809 13f79535-47bb-0310-9956-ffa450edef68
Add a GLOBAL_BATCH thread pool.  This is different than GLOBAL_EXECUTOR,
in that:

* BATCH does not block when all the coreThreads are busy, as would
  happen with EXECUTOR.  When all coreThreads are busy, new threads will
  be spawned.
* Scheduled jobs can *not* be submitted.

You can simulate the first problem, by modifying ExecutionPool, and
force-setting the threadCount to 1.  Then, submit something to the pool,
that will then itself submit more items into the pool.  Dead-lock will
occur.

BATCH should be used when it might be posslbe that more items could be
submitted by code you are calling.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617810 13f79535-47bb-0310-9956-ffa450edef68
Add a simple Future implementation, that returns a constant,
non-changing value.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617811 13f79535-47bb-0310-9956-ffa450edef68
Initialize the eca handler's DispatchContext asynchronously.  This means
the eca handler will be available sooner, but might briefly pause the
first time it is used, while it waits for the DispatchContext to finish
initializing.

This patch is needed to prevent a deadlock when the eca handler itself
is initialized asynchronously in the delegator; see the next commit.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617812 13f79535-47bb-0310-9956-ffa450edef68
Initialize the eca handler in asycnhronously.  This requires the previous
patch, that initializes the eca handlers DispatchContext asynchronously.
With it, when the eca attempts to initialize, the DelegatorContext will
also initialize at the same time; this will end up calling back into the
same delegator, and a deadlock will occur.

When both are asynchronous, then the eca initialization will return
quickly, and upon first access, the DispatchContext future will be
waited for.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617813 13f79535-47bb-0310-9956-ffa450edef68
Initialize the DistributedCacheClear handler in a thread pool.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617814 13f79535-47bb-0310-9956-ffa450edef68
Use the BATCH thread pool for the helper initialization.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617815 13f79535-47bb-0310-9956-ffa450edef68
Now that the thread-pool startup dead-locks are fixed, we can configure
the entirety of the delegator in a thread pool.  This will become a big
win very shortly, when multiple delegators are created at startup.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617816 13f79535-47bb-0310-9956-ffa450edef68
We now have a real delegator container, that can be used to auto-start
many delegator instances.  Just specify the ones to load, separated by
commas or spaces.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617817 13f79535-47bb-0310-9956-ffa450edef68
Remove creation of any delegator instance when a catalina container
starts; nothing was ever using the saved delegator instance anyways.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617818 13f79535-47bb-0310-9956-ffa450edef68
Fixed a bug in Start.java reported by Justen Walker (https://issues.apache.org/jira/browse/OFBIZ-5710):

The singleton pattern was broken by adding Commons Daemon support code to the class - resulting in multiple instances when using Commons Daemon.

I extracted the Commons Daemon code to a separate class - which delegates to the singleton Start instance. Users of Commons Daemon will need to update their scripts/etc to point to the new class instead of Start.

I also added a comment describing the design of Start.java, so hopefully this will help others maintain the code without breaking it.


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617936 13f79535-47bb-0310-9956-ffa450edef68
Small fixup for my last commit.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617938 13f79535-47bb-0310-9956-ffa450edef68
No functional changes, only blocks moves and formatting

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1617971 13f79535-47bb-0310-9956-ffa450edef68
[OFBIZ-3428] Now order entry process buttons are visible. Thanks Erwan de FERRIERES for the report and ofbiz.us team for the fix.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1618311 13f79535-47bb-0310-9956-ffa450edef68