You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Quintin Beukes <qu...@last.za.net> on 2009/10/20 16:47:58 UTC
Dev Question re. Injections on newly created beans
Hey,
I am trying to get @Singleton working in Geronimo. I've been sitting
the whole day tracking/changing and was hoping someone could please
save me some time tomorrow.
So far I can get it deployed, loaded, able to call locally and
remotely, I've gotten the @Startup and @PostConstruct to execute,
fixed 2 deadlocks (rather, never satisfied .wait() calls in the
Geronimo-OpenEJB integration code). Only thing that looks like it's
not working is the injections. When the bean loads it curses the
following: 2009-10-20 15:10:55,257 WARN [OpenEJB] Injection data not
found in enc: jndiName='net.kunye.platform.init.KMSPlatformEjbStartupBean/em',
target=class net.kunye.platform.init.KMSPlatformEjbStartupBean/em
It does this for all types of injections. I checked the JndiEnc
object, and those injections are one hundred percent definitely being
added to it. It also looks like it's being bound to the context,
though I can't say for sure if it's done correctly.
Could someone please give me a general idea as to how this work so I
don't have to trace it tomorrow. I'm sort of tired of having to
restart geronimo and wait 2 minutes just to redeploy the app and
restart the stepping process (there are MANY deadlocks related to
failed EJBs - I stopped caring about those that happen after a failed
deploy, since they will probably not be there if the app runs fine -
so it's a care for another day).
Quintin Beukes
Re: Dev Question re. Injections on newly created beans
Posted by David Blevins <da...@visi.com>.
On Oct 20, 2009, at 8:06 AM, Quintin Beukes wrote:
> What I have need to find out now is where does it go from here, and
> how is it still involved in the injection lookups?
If it helps Singleton instances are created with:
SingletonInstanceManager.createInstance
Lookups are done downstream of that method.
-David
Re: Dev Question re. Injections on newly created beans
Posted by Quintin Beukes <qu...@last.za.net>.
Just to update a bit on where I am now tracing the injections:
In JndiEncBuilder.java, the following executes and DOES add all the
fields to be injected, where reference name equals the name reported
in the error for jdniName.
public Map<String, Object> buildMap() throws OpenEJBException
{
...
for (EjbReferenceInfo referenceInfo : jndiEnc.ejbLocalReferences) {
....
bindings.put(normalize(referenceInfo.referenceName), reference);
}
...
}
Then, back in build()
the jdnifactory is executes, and the WritableContext is created,
passing in a valid bindings object (with all the bindings listed in
it, as proven by the debugger's variables view). A sample bindings
entry (key=>value):
String "java:comp/env/net.kunye.platform.init.KMSPlatformEjbStartupBean/em"
=> JndiUrlReference org.apache.openejb.core.ivm.naming.JndiUrlReference@1d9c8a5
The resulting WriteableContext contains entries like:
java:comp/env/net.kunye.platform.init.KMSPlatformEjbStartupBean/site=org.apache.openejb.core.ivm.naming.IntraVmJndiReference@1d8efd1
This is returned back to the EnterpriseBeanBuilder, and passed into
DeploymentContext.
What I have need to find out now is where does it go from here, and
how is it still involved in the injection lookups?
Quintin Beukes
On Tue, Oct 20, 2009 at 4:47 PM, Quintin Beukes <qu...@last.za.net> wrote:
> Hey,
>
> I am trying to get @Singleton working in Geronimo. I've been sitting
> the whole day tracking/changing and was hoping someone could please
> save me some time tomorrow.
>
> So far I can get it deployed, loaded, able to call locally and
> remotely, I've gotten the @Startup and @PostConstruct to execute,
> fixed 2 deadlocks (rather, never satisfied .wait() calls in the
> Geronimo-OpenEJB integration code). Only thing that looks like it's
> not working is the injections. When the bean loads it curses the
> following: 2009-10-20 15:10:55,257 WARN [OpenEJB] Injection data not
> found in enc: jndiName='net.kunye.platform.init.KMSPlatformEjbStartupBean/em',
> target=class net.kunye.platform.init.KMSPlatformEjbStartupBean/em
>
> It does this for all types of injections. I checked the JndiEnc
> object, and those injections are one hundred percent definitely being
> added to it. It also looks like it's being bound to the context,
> though I can't say for sure if it's done correctly.
>
> Could someone please give me a general idea as to how this work so I
> don't have to trace it tomorrow. I'm sort of tired of having to
> restart geronimo and wait 2 minutes just to redeploy the app and
> restart the stepping process (there are MANY deadlocks related to
> failed EJBs - I stopped caring about those that happen after a failed
> deploy, since they will probably not be there if the app runs fine -
> so it's a care for another day).
>
> Quintin Beukes
>
Re: Dev Question re. Injections on newly created beans
Posted by Quintin Beukes <qu...@skywalk.co.za>.
> synchronized (deploymentInfo) {
> if (deploymentInfo.get(EjbDeployment.class) == null) {
> if (!deploymentInfo.isDestroyed()) {
> try {
> deploymentInfo.wait();
> } catch (InterruptedException e) {
> log.warn("Wait on deploymentInfo interrupted
> unexpectedly");
> }
> }
> }
> }
> }
>
I actually found it's ALL related to this EjbDeployment.class. Any
idea why it would not be set, or whet it get's set?
Because the ThreadContext doesn't run, when the injections are bound,
they are bound to comp/env isntead of comp/geronimo/env or
geronimo/env (can't recall which). This mod is done only when
deploymentInfo.get(EjbDeployment.class) returns non-null.
Q
Re: Dev Question re. Injections on newly created beans
Posted by Quintin Beukes <qu...@skywalk.co.za>.
> I assume you're not referring to the bean code created deadlock you reported
> on the user list.
No, lol.
The deadlocks are related to failed code. Because one thread raises an
exception another stays unsatisfied. Or another case where failed code
causes a ReadWriteLock to have null values. That's why I figured it's
not that important. If the code is made to work all is well and it
shouldn't happen. So it's like saying incomplete code is broken? It's
not broken... it's incomplete. There's a difference. :>
The only deadlock that does seem serious is in
GeronimoThreadContextListener.contextEntered()
I tried to look for this notify but can't find it. I know it has to be
somewhere, but since isDestroyed() is false at @Startup, it always
enters and waits forever. I made a temporary quick fix until I can
research it a bit more. The fix was basically to add an "isStarting()"
to get it to fail that fix. I figure the correct fix would be to have
the EjbDeployment.class object added to the properties of
deploymentInfo, though that's left till I can at least get Singletons
to work and have development of our product continue. Then I can start
looking at cleaning up the implementation.
synchronized (deploymentInfo) {
if (deploymentInfo.get(EjbDeployment.class) == null) {
if (!deploymentInfo.isDestroyed()) {
try {
deploymentInfo.wait();
} catch (InterruptedException e) {
log.warn("Wait on deploymentInfo interrupted
unexpectedly");
}
}
}
}
}
Beyond this I'm learning a lot about OpenEJB/Geronimo.
Re: Dev Question re. Injections on newly created beans
Posted by David Blevins <da...@visi.com>.
On Oct 20, 2009, at 7:47 AM, Quintin Beukes wrote:
> So far I can get it deployed, loaded, able to call locally and
> remotely, I've gotten the @Startup and @PostConstruct to execute,
> fixed 2 deadlocks (rather, never satisfied .wait() calls in the
> Geronimo-OpenEJB integration code).
There shouldn't be any deadlocks in the integration code. Do you have
details?
I assume you're not referring to the bean code created deadlock you
reported on the user list.
-David