ejb 3.0 - How @EJB annotation is processed in EJB container 3.x from the moment when we deploy ejb components? -

questions ejb session bean behavior when used injected bean instances. i'm not 100% sure how works. guess practice , reading documents on subject. want know how @ejb annotation processed container in detail.

session bean have interfaces, impl class, deployment descriptor. package them in ejb jar.

1. what putted in global jndi container? static references business interfaces ?
2. how , when global jndi read ?
3. when component jndi enc populated ejb reference ?
4. is reference in jndi enc (java:comp/env/beanb) reference session bean component interface, session bean instance proxy or session bean instance ? there difference slsb , sfsb ?
5. with @ejb annotation on field every new ejb session bean instance new instance of injected ejb in annotated field or ejb instances share same injected ejb session bean instance ?
6. does ejb injection lookup (on session context) provide new injected ejb instance, example: calling ctx.lookup(ejbreference) in loop ?

1. in ejb 3.0, jndi names vendor-specific (if available @ all; in theory, container support ejb references only), vendors typically return ejb reference/proxy. in ejb 3.1, specification requires ejb container make specific java:global, java:app, , java:module names available, , object returned these lookups must ejb reference/proxy.
2. the global jndi accessed when perform jndi lookup. container might access global jndi names in other cases (e.g., when resolving @ejb(lookup="java:app/...")).
3. it's undefined when container populates java:, contents must available before lifecycle callback or business methods invoked on component instance.
4. @ejb/<ejb-ref>/<ejb-local-ref> ensure lookups return ejb reference/proxy , never actual bean instance. proxy ensures container services performed (security, transaction, remoting, etc.) before invoking actual bean instance. slsb, arbitrary bean instance invoked, , same or different actual instance might invoked depending on thread, concurrency, timing, vendor-specific configuration, etc. sfsb, bean instance specific identity invoked; same bean instance, might not if ejb container has passivated actual bean instance, reactivation should result in instance equivalent state. singleton session bean in ejb 3.1, guaranteed singleton bean instance invoked.
5. it's undefined whether same proxy instance. slsb , singleton beans, injection or lookup return single proxy delegates actual bean instance mentioned above. sfsb, proxy required separate instance per injection or lookup since proxy must store state identity can invoke specific actual bean instance.
6. it's undefined container does, injection typically implemented containers using context.lookup followed field.set (or method.invoke setter method injection). regardless, instance handling described above.