PS: @PostConstruct will force an init and denote the fact the init can be different from the instantiation which means no code triggered before @PostConstruct is called (and app is deployed). Why not using it to also allowing CDI injections (try or skip mode) in resources? we have the web bean context when postconstruct will be called
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-04-14 16:23 GMT+02:00 Romain Manni-Bucau <[email protected]>: > +1 > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2015-04-14 16:21 GMT+02:00 Jonathan Gallimore < > [email protected]>: > >> Hi >> >> Just wanted to give a heads-up that I'm currently working on TOMEE-1547. >> The idea here is that it should be possible to create a resource in an >> application's resources.xml and have the actual class for the resource >> defined within the application itself. This seems to work for WARs but not >> EARs. >> >> Currently, the code >> in >> org.apache.openejb.assembler.classic.Assembler.createResource(ResourceInfo) >> uses Thread.currentThread().getContextClassLoader() which is the TomEE >> system classloader. >> >> I'm currently building on Romain's lazy resource loader to make this >> happen >> slightly later and pick up the correct classpath. I'm also looking at >> calling @PostConstruct and @PreDestroy methods on resources to allow any >> custom logic during resource creation or removal.. >> >> If you have any issues or queries, please let me know. >> Thanks >> >> Jon >> > >
