[jboss-as7-dev] EE JNDI services

[Carlo de Wolf]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20110207/c6f46819/attachment.html