2016-03-29 14:32 GMT+02:00 Dimitri <[email protected]>: > Hi Romain, > >> 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 there at >> startup. > > 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 JNDI is the JNDI tree of Comp bean (a kinf of EJB with its own JNDI tree which is a merge of all trees to make it simple) yes >> That said: why not using es6 and or purescript/typescript to get real >> imports and potentially annotations/decorators and just convert it to java > > Did you mean "to JavaScript"? That would involve heavy-weight machinery > like Babel/Traceur that requires Node.js, and running Node code in > Nashorn is a non-trivial task (though I know the guy who currently > works on that). It's an interesting challenge, but I think I'd better > start with a simpler (ad-hoc) prototype. > Well babel is trivial to run - at least in version 5: https://github.com/rmannibucau/ohmyjs Now I thought to that cause that's what give a language a java developer will not reject immediately I think. es5 is still not tempting for a java developer cause of the scope plus adding injections in comments is another reason to not accept this I think. That said it is your choice and I can be totally wrong on that, no issue ;). >> and then wire it through websocket? Sounds like a simple and safe impl to >> me to do that. > > Sorry, can't understand how it would solve a problem of dynamic EE > injections. Could you please elaborate? Here is the (lazy?) workflow I would have implemented if I would have had it to do: 1. convert the js to java - just in term of EE contract ex: /** @import org.apache.commons.configuration.Configuration @import java.util.logging.Level @Startup(order = 1) @Inject Configuration config */ $LOG.log(Level.INFO, "Starting MyApplication {0} b{1}", [ config.getString("myapp.version"), config.getString("myapp.build") ]); would be public class MyJsEnv { @Inject Configuration config; // all injections even @Resource, @PersistenceContext etc } 2. I would have impl-ed a websocket endpoint getting MyJsEnv injected and mapping client operations to server operations This is actually pretty close to angularbeans: http://bessemhmidi.github.io/AngularBeans/ but without the need to recreate a server side API This is for remoting - maybe not what you want to achieve. A common alternative for 100% server usage is to simply name beans and use them as bindings in the script engine. With the BeanManager it is pretty easy to implement a Binding to do so (something like https://github.com/apache/tomee/blob/120a33c7b4de07ae01c17978ea37d88a911ea860/container/openejb-core/src/main/java/org/apache/openejb/util/OpenEJBScripter.java#L104 but more integrate to JSR 223) > > Thx! Dimitri > >> Le 29 mars 2016 01:48, "Dimitri" <[email protected]> a écrit : >> >> > >> > 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 >> >
