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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev