<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
There is a 'soft' dependency between the JNDI Binding and the
Componentɸ2(START).<br>
<br>
Can you clarify why we need a binding per entry and a binding per
view?<br>
To me the env entries can be expressed as one environment references
group.<br>
The views can also be expressed as one unit.<br>
I don't think it really makes a functional difference which way, but
I'm curious.<br>
<br>
To me the CompName bit is misleading. It feels like there is a
relation to java:comp. Wouldn't 'Binding' make more sense?<br>
jboss.naming.context.*.CompName<br>
<br>
'Lookup Name Binding' and 'JNDI Binding' are the same thing. So we
need to stick to one conceptual name.<br>
<br>
I think
'jboss.naming.context.java.comp."foo.ear"."bar.jar".MyComponent.env.myField'
doesn't cover all cases.<br>
There is the 'on behalf of' part:
[<app-name>.].<module-name>.<bean-name> and the
env entry name (e.g. env/<br>
com.example.MyApp/myDatabase). Ah I see it, myField should be
env-entry-name.<br>
<br>
Can we get a better visibility on the SPI for resource providers?<br>
At some point (for example) @PersistenceContext needs to be resolved
into something that the EnvEntryBinding service can consume.<br>
<br>
Carlo<br>
<br>
On 02/06/2011 09:07 PM, David M. Lloyd wrote:
<blockquote cite="mid:4D4EFF68.80604@redhat.com" type="cite">I've
been working on getting EE JNDI services organized in a
spec-consistent (and start-order-consistent) manner. The first
part of this effort - dividing the EE component service itself
into two phases - was relatively simple and is now complete;
however it appears that our JNDI services are not entirely
prepared for this organizational change. I've attached a diagram
which illustrates the desired service layout for EE components
which covers injection and start order, and should be cycle-proof
(we'll know for sure once we implement EJB "eager" singletons).
<br>
<br>
Anyway please review the graph and let me know if there are any
questions, especially if I've missed any cases, and in the
meantime I'll be working on getting the deployers straightened
out. The arrow means "depends-on".
<br>
<br>
Some important facts not depicted:
<br>
<br>
- Components (as can be seen from the graph) are bound into JNDI
possibly before they are started; however attempting to create a
new component instance will block until the "START" phase is
complete (note that for some component types, you can acquire a
client proxy without actually causing instantiation to occur).
<br>
<br>
- The service naming scheme is not final, especially for JNDI
contexts.
<br>
<br>
- Note that not all env. entries necessarily imply injection; it
is also possible to specify immediate values in the deployment
descriptor. To achieve this in MSC, the env. entry service should
have an Injector which can be immediate for descriptor-provided
(or defaulted) values or it can be a dependency for lookup values.
<br>
<br>
- Note that all inter-component dependencies are expressed upon
JNDI bindings (jboss.naming.context.* services), not on the actual
components (jboss.deployment.unit.*.component.* services).
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
jboss-as7-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a></pre>
</blockquote>
<br>
</body>
</html>