Hi Paul,
You might like to consider investigating the @Asynchronous annotation.
It could solve a few of your headaches, without requiring the
ManagedExecutorService.
Here is a simple example - But it can do a lot more:
http://tomee.apache.org/examples-trunk/async-methods/ - It's basically
like a free and managed ManagedExecutorService without the overhead if
you get my drift?
Andy.
On 11/10/17 01:10, Paul Carter-Brown wrote:
Thanks Romain/Andy,
openejb.environment.default = true fixed it
Does this property merely indicate that the resources should be bound into
the JNDI tree or does it control whether they are created or not by the
container?
I found it interesting that this works fine even with that property set to
false:
@Resource
private ManagedExecutorService mes;
~~~
In terms of why I need the executor:
The systems we build almost always do a lot in the background in addition
to servicing incoming requests over HTTP and other protocols. Background
threads are needed to do things like service discovery, service monitoring,
rating, event processing, polling external systems etc etc. I bootstrap
this "background" functionality via a servlet with loadOnStartup and an
init function that would kick everything off. I was experimenting with
moving all this background code to be loaded and managed by CDI. As the
initial servlet init function is within a managed context I could inject
from there on into the code base to boot everything up. I was thinking of
using @Singleton/@ApplicationScope managed beans as a way of neatly
starting these background objects with @PostConstruct once and only once so
they could do their thing with executors in the background. My recent
issues with controlling @Singleton/@ApplicationScope objects in
circumstances with multiple skinny wars in a EAR lead me to rethink using
CDI and rather use good old Singletons where I can fully control the
lifecycle of the instance and be sure its background processing is only
started once. Instead of creating my own threads I'd prefer to use
ManagedExecutorService and ManagedScheduledExecutorService. It was easy to
get these when I could inject them but now with singletons and classes that
are being created outside of the managed context (i.e. with
Foo.getInstance() as opposed to @Inject Foo) I need to get them from JNDI
and this is where I hit this particular issue.
Paul
On 11 October 2017 at 01:46, agumbrecht <agumbre...@tomitribe.com> wrote:
Properties are somewhat documented here:
http://tomee.apache.org/admin/configuration/server.html - It's not totally
obvious in your case that the property named here does what Romain
describes, but please feel free to create a ticket on the jira here:
https://issues.apache.org/jira/browse/TOMEE if you would like a better
description.
The managed executor is a way to start threads that the server will attempt
to stop on a shutdown. The app server is already multithreaded, so there
might be a better way to do what you are intending?
Andy.
-----
--
Andy Gumbrecht
http://www.tomitribe.com
agumbre...@tomitribe.com
https://twitter.com/AndyGeeDe
TomEE treibt Tomitribe ! | http://tomee.apache.org
--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-
f979441.html
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io