2016-03-29 20:53 GMT+02:00 Dimitri <[email protected]>: > 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 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 > > Sounds cool, but how do I obtain an instance to plant? For example, > after parsing a script (at runtime!) I know that it requires a > @PersistenceContext with particular name, as well as some @Resource's > (probably also named), some @EJB's and some @WebServiceRef's. Is there > a "magic" method in OpenEJB that I can call this way: "okay, my newly- > loaded component needs this EE stuff, please instantiate it all for me > (or return reference if already instantiated)"? >
You can rely on deep internals but I wouldn't recommand it. Side note: it breaks by design JavaEE since you have passed the startup which validates as much as possible the application and any runtime change later on can surprisingly break the application (that's why hot reloading is a good bad idea and can break after a restart even if "F5" tests were green ;)). > Of course I could write my own handlers for each annotation type like > this: > - in case of @Resource -> look in JNDI > - in case of @EJB -> the same > - in case of @PersistenceContext/@PersistenceUnit -> instantiate (how > exactly?) there are in global JNDI tree under a name you can find browsing the internal tree (but same note: this is not portable and we can break it without any notice if we need). > - in case of @WebServiceRef -> ??? > This one is easier since it is a plain webservice client, only container config can be missing since it is not on the annotation. > But I would like to avoid it, since all of it is already implemented in > OpenEJB either way. > >> > >> Well babel is trivial to run - at least in version 5: >> https://github.com/rmannibucau/ohmyjs > > Looks really cool - didn't know running Babel on Nashorn would be that > easy! It opens new horizons for me :) In fact, I wouldn't say I'm 100% > happy with ES5. Nashorn was chosen as a first candidate because of its > maturity, performance & support from Oracle; but nothing would prevent > from using any JSR-223 compliant engine. > Nashorn is not that fast to be honest - even if good enough generally. It still interprets a lot of relies on thread locals which can easily breaks any app, in particular starting to use reactive patterns of just EJB @Asynchronous :s - check GlobalContext ;). >> >> 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. > > Neither am I 100% happy with injections-in-comments. I was also > thinking about external (XML/JSON) metadata that would come in pair > with a script. E.g., a script itself could come in foo.js, and its > metadata in foo.{xml|json|etc.} The latter would contain > summary/description, imports, dependencies etc. - all the same, but in > a structured format. > > I was examining ES7 decorators, too. Yes, they could be mapped to Java- > style annotations; the problem is, decorators are applied to JS > classes/methods/properties only. This will force users to > unconditionally wrap their JavaScript code in a class, which seems > reduntant to me. After all, there are a lot of methods to supply script > metadata, with JSDoc-style annotations being just a first try. > >> 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 very similar to what I've tried in the very beginning. Problem > is, in TomEE this works only statically, meaning that MyJsEnv should be > available at application deployment (pre-generated, compiled and > bundled in a WAR). If I generate/load such a class in runtime, EE > injections won't be processed (contrary to WildFly, which in this case > correctly processes both @Inject and @Resource/@EJB/@Persistence* etc). Hmm, maybe not. JSP support injections and are generated at runtime so it needs some glue code but reusing the same principle would work and this API even if internal is more stable (see InstanceManager of tomcat). > >> 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) > > To help me understand better, could you please briefly explain what > OpenEJBScripter is? Are there any examples of scripts for it? Are they > able to access applications' PersistenceUnits/PersistenceContexts, > UserTransactions etc.? Was just a helper class there to allow to access CDI beans from JSR 223 scripts. Next step is to implements Bindings#get and avoid the instantiate() method invocation to get a bean. It is not as good as your impl but allows to wire CDI-script in a smooth fashion since you provide any named CDI beans (very close to JSF xhtml/CDI link). > > Thx! Dimitri >
