[wildfly-dev] JNDI and java:comp, slimming the server, and componentless naming contexts

[Eduardo Martins]

Allright, since there is no one else with concerns on the redesign David proposed, I have been thinking on how this may implemented fulfilling his requirements.

So currently we have a design where for each deployment we create a NamingStore for each of the scoped namespaces (java:comp, java:module and java:app), and then resort to deployment processors to bind the shared entries into each of these stores. Then on runtime there is a NamespaceContextSelector thread local design, that is used to select the naming stores related to the EE component in context. The changes I propose are:

	• 3 new “fallback" naming stores are added, one for each scoped namespaces (java:comp, java:module and java:app), and the default namespace context selector points to these, ensuring the “global” binds are accessible through lookups with no component in context
	• modules and extensions, and the naming subsystem management ops as well, bind to the fallback naming stores, instead of using deployment processors to bind into each instance of the scoped namespaces
	• Currently each ServiceBasedNamingStore contains a base MSC service name, which is used to lookup the MSC binder services containing the JNDI values related to the store, and will now (optionally) have an additional fallback base service name. When doing a lookup, if the binder service using the standard and scoped base service name is not found, a lookup using the fallback base service name is then tried
	• on resource injection the dependency are set first to the fallback binder services, but reset if the deployment rebinds any of these

The only issue with these changes is the double lookup of MSC Services, but this only happens when app code tries a JNDI lookup for a global “bind”, and AFAIK the performance penalty is minimal. There could be also an issue if we could have link refs in the fallback naming stores, since we won't "navigate” through these stores, but I don’t see a reason to not forbidden that, after all we don’t even support link ref officially.

Thoughts?

—E

On 04 Feb 2014, at 13:39, David M. Lloyd <david.lloyd at redhat.com> wrote:

> I think we need to look into a small redesign of how we handle 
> java:comp, java:module, and java:app.  The reasoning comes in three parts:
> 
> * Various specs require that certain names be bound globally across all 
> of java:comp.
> * Various other specs implicitly expect to be able to query these 
> globally bound names even if there is no actual component context.
> * Duplicating these bindings uses more resources than are necessary.
> 
> Therefore I think we need to make a small change - we should have a 
> "global" version of the three context-specific namespaces that act as a 
> sort of fallback if there's no (component|module|app)-specific name 
> bound at a location.  This allows us to do a few things:
> 
> * Satisfy the spec issues
> * Reduce resource overhead
> * Allow globally-configured things in the management config to bind to 
> component/module/app-specific namespaces
> 
> Thoughts?
> -- 
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev