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. (To
> obtain the firs
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 StandardCon
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 :
>
>
> 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
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 complicat
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 of
> (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 r
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 JNDI is the JNDI tree of
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
2016-03-29 14:32 GMT+02:00 Dimitri :
> 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 co
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
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 ther
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
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 be
14 matches
Mail list logo