2:07 p.m.
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).
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".
Some important facts not depicted:
- 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).
- The service naming scheme is not final, especially for JNDI contexts.
- 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.
- 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).
--
- DML
5:20 a.m.
There is a 'soft' dependency between the JNDI Binding and the
Component?2(START).
Can you clarify why we need a binding per entry and a binding per view?
To me the env entries can be expressed as one environment references group.
The views can also be expressed as one unit.
I don't think it really makes a functional difference which way, but I'm
curious.
To me the CompName bit is misleading. It feels like there is a relation
to java:comp. Wouldn't 'Binding' make more sense?
jboss.naming.context.*.CompName
'Lookup Name Binding' and 'JNDI Binding' are the same thing. So we need
to stick to one conceptual name.
I think
'jboss.naming.context.java.comp."foo.ear"."bar.jar".MyComponent.env.myField'
doesn't cover all cases.
There is the 'on behalf of' part:
[<app-name>.].<module-name>.<bean-name> and the env entry name (e.g.
env/
com.example.MyApp/myDatabase). Ah I see it, myField should be
env-entry-name.
Can we get a better visibility on the SPI for resource providers?
At some point (for example) @PersistenceContext needs to be resolved
into something that the EnvEntryBinding service can consume.
Carlo
On 02/06/2011 09:07 PM, David M. Lloyd wrote:
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).
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".
Some important facts not depicted:
- 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).
- The service naming scheme is not final, especially for JNDI contexts.
- 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.
- 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).
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5038
days inactive
5039
days old
1 comments
2 participants
participants (2)
-
Carlo de Wolf -
David M. Lloyd