Re: Performing Java EE resource injections dynamically

Do you use a custome classloader? If so try to override equals/hascode to simulate webapp one Le 31 mars 2016 06:43, "Dimitri" a écrit : > Hi, > > In Tomee 7.0.0-M3, I've tried to use JavaeeInstanceManager and > DefaultInstanceManager to instantiate dynamically loaded class.

Re: Performing Java EE resource injections dynamically

Hi, In Tomee 7.0.0-M3, I've tried to use JavaeeInstanceManager and DefaultInstanceManager to instantiate dynamically loaded class. (To obtain the first, I used InstanceManagerFactory; for the second I've copied the code from your recent commit and used ContainerServlet to obtain parent

Re: Performing Java EE resource injections dynamically

True, we are based on a static analysis at startup so we likely miss JSP - means if you use it somewhere else it should work. Fixed in https://issues.apache.org/jira/browse/TOMEE-1764 Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-30 1:52 GMT+02:00 Dimitri

Re: Performing Java EE resource injections dynamically

> In the case of resources.xml-defined entry, I didn't manage to > resolve it even through JNDI manually. Sorry, I was wrong, it is resolvable as "openejb:Resource/XXX" in JNDI. But still no way to use @Resource annotation. Dimitri

Re: Performing Java EE resource injections dynamically

Quick followup. I tried similar JSP in Tomcat 8.0.27, and wow! @Resource injection into JSP worked like a charm! context.xml: JSP: <%! @Resource(name = "foo") private Integer foo; %> foo = <%= foo %> This successfully rendered foo = 42. Things were much more

Re: Performing Java EE resource injections dynamically

jspInit() sounds better than PostConstruct. UserTransaction can use @Inject by spec if Im not mistaken so issues are for entity manager and resources. Here no portable solution but easy to generate at build tume producers for them. A simpe Mojo/Ant task/gradle plugin would enable it in few lines

Re: Performing Java EE resource injections dynamically

> (that's > why hot reloading is a good bad idea and can break after a restart > even if "F5" tests were green ;)). Oh yeah, I've got obscure errors after hot reloading hundreds of times. Most of them were JNDI-related, by the way ;) > Hmm, maybe not. JSP support injections and are generated at

Re: Performing Java EE resource injections dynamically

2016-03-29 20:53 GMT+02:00 Dimitri : > Hi, > >> > Does it mean that if I somehow manage to (dynamically) plant the >> > necessary entries to a JNDI tree, everything would work like in >> > WildFly? (InjectionTarget is what's used under the hood in >> > Unmanaged) >> > >> if

Re: Performing Java EE resource injections dynamically

Hi Dimitri CDI injections are created - more validated actually - at startup and dont rely on JNDI at all. EE injections rely on JNDI and are linked to CDI through a particular bean (Comp) representing the whole webapp JNDI tree. In term of code an InjectionTarget should work but needs to be

Re: Performing Java EE resource injections dynamically

Sorry for broken links. Shouldn't have used line wrapping in my mail client. Project write-up: https://gist.github.com/dteleguin/c93fe4a4c666234729d8 StackOverflow thread: http://stackoverflow.com/questions/36239250/injecting-java-ee-resources-into-dynamically-loaded-classes

Performing Java EE resource injections dynamically

Hi all, I'm working on a project that is meant to bring CDI injections to server-side JavaScript. There are similarities with Undertow.js [1], but the project I'm working on has more generic nature, wider scope and vendor-neutral character. From the very inception it was clear that TomEE should