It defines the link only, which means it does the same as your @Resource. Difference is that if you don't have any @Resource then it would still do it if true by default. Then if there is a link and no matching resource then openejb creates one implicitly. This means that false is a good default avoiding to create not needed resources :).
Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn 2017-10-11 10:10 GMT+02:00 Paul Carter-Brown <paul.carter-br...@smilecoms.com>: > 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 >> > > > > -- > > *Paul Carter-Brown* > > *Group Chief Information Officer* > > *Smile Communications Pty (Ltd) * > Smile +234 (0) 702 000 1234 > Mobile +27 (0) 83 4427 179 > Skype PaulC-B > paul.carter-br...@smilecoms.com > www.smilecoms.com > > -- > > > This email is subject to the disclaimer of Smile Communications at > http://www.smilecoms.com/home/email-disclaimer/ > <http://www.smilecoms.com/disclaimer> >
