[jboss-jira] [JBoss JIRA] (WFLY-7113) Naming subsystem does not expose a proper capability contract

Thu Nov 3 16:39:00 EDT 2016

    [ https://issues.jboss.org/browse/WFLY-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13317180#comment-13317180 ] 

Paul Ferraro commented on WFLY-7113:
------------------------------------

Pasting comments from HipChat discussion w/Brian:

[3:51 PM] Brian Stansberry: @PaulFerraro got a sec to talk naming?
[3:51 PM] Paul Ferraro: Sure
[3:51 PM] Paul Ferraro: what's up?
[3:51 PM] Paul Ferraro: naming subsystem?
[3:52 PM] Brian Stansberry: there are a lot of uses of org.jboss.as.naming classes outside of naming subsystem besides NamingStore, but...
[3:52 PM] Brian Stansberry: some of them at least seem to be non-capability API
[3:52 PM] Brian Stansberry: like "BinderService" etc
[3:53 PM] Paul Ferraro: BindInfo
[3:53 PM] Brian Stansberry: so I'm curious how much you dug into all those; i.e. is NamingStore the only cap from that subsystem, or is that just the one you needed to deal with
[3:54 PM] Brian Stansberry: @PaulFerraro what about BindInfo? another cap?
[3:54 PM] Paul Ferraro: well - the naming subsystem doesn't have a proper spi module
[3:54 PM] Paul Ferraro: which would be ideal
[3:55 PM] Paul Ferraro: so, every subsystem that wants to create a jndi binding needs
[3:55 PM] Paul Ferraro: to use BindInfo, BinderService, etc
[3:55 PM] Brian Stansberry: yeah
[3:55 PM] Paul Ferraro: Ideally, these classes would reside in a separate module
[3:56 PM] Paul Ferraro: and the exposed capability would be a BindInfoFactory
[3:56 PM] Paul Ferraro: or something
[3:56 PM] Paul Ferraro: it gets complicated because of the way the different namespaces are handled
[3:56 PM] Paul Ferraro: so - I did the least amount of work to be able to make the existence of the extension optional
[3:57 PM] Paul Ferraro: e.g. if you remove the naming subsystem, you can still use the jgroups subsystem
[3:58 PM] Brian Stansberry: would a later addition of a cap for BindInfoFactory make your cap name of "org.wildfly.naming" for the NamingStore a bad choice?
[3:59 PM] Brian Stansberry: that kind of issue is often the danger of doing things piecemeal
[4:00 PM] Paul Ferraro: I don't think so - this is the base naming store
[4:00 PM] Paul Ferraro: there are naming stores for each namespace that a built on top of this
[4:01 PM] Brian Stansberry: ok
[4:01 PM] Brian Stansberry: here's another one:
[4:01 PM] Brian Stansberry: https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java/org/wildfly/iiop/openjdk/I...
[4:01 PM] Brian Stansberry: those calls in that block there are kind of a "runtime API" type thing
[4:02 PM] Brian Stansberry: not sure where those fit. Could be exposed by org.wildfly.naming
[4:02 PM] Paul Ferraro: agreed
[4:02 PM] Brian Stansberry: which wouldn't be a conflict with what you did if it's a runtime API impl and not a Service
[4:02 PM] Brian Stansberry: and could be added later
[4:03 PM] Paul Ferraro: but your question about the name is valid, maybe "org.wildfly.naming.store" is better?
[4:05 PM] Brian Stansberry: @PaulFerraro yeah, my instincts say yes, so long as your better informed instincts agree ;)
[4:05 PM] Paul Ferraro: ok - let me give it another look
[4:15 PM] Paul Ferraro: @BrianStansberry so I kinda based the capability name on the legacy service name:
[4:15 PM] Paul Ferraro: https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/jboss/as/naming/deployment/C...
[4:15 PM] Paul Ferraro: where the base naming store used ServiceName.JBOSS.append("naming")
[4:17 PM] Brian Stansberry: OT to your last post -- https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/jboss/as/naming/WritableServ... is another bit of "capability runtime API"
[4:22 PM] Brian Stansberry: @PaulFerraro so AIUI your BindInfoFactory thing would basically be to encapsulate those ContextNames.bindInfoFor(...) calls?
[4:22 PM] Paul Ferraro: yeah
[4:23 PM] Brian Stansberry: looking at the uses of those, that doesn't sound like a service either, more like another aspect of "capability runtime API"
[4:23 PM] Brian Stansberry: you know what I mean by "capability runtime API" ?
[4:24 PM] Paul Ferraro: yes - RuntimeCapability<T>
[4:24 PM] Brian Stansberry: k
[4:25 PM] Brian Stansberry: it seems like we are talking about 3 different aspects of a RuntimeCapability<T>
[4:25 PM] Brian Stansberry: and so far I haven't seen any other Service<T> type
[4:26 PM] Brian Stansberry: i.e. the service type is still only NamingStore, so that's more evidence your org.wildfly.naming name is ok
[4:27 PM] Brian Stansberry: 3 different runtime API aspects being static methods now in ContextNames, InitialContext and WritableServiceBasedNamingStore
[4:27 PM] Paul Ferraro: well - the purpose of the BindInfo is to be able to resolve a ServiceBasedNamingStore service dependency
[4:28 PM] Paul Ferraro: so that's definitely a non-runtime API use case
[4:28 PM] Paul Ferraro: but, I'm not entirely sure of the best way to encapsulate that
[4:29 PM] Paul Ferraro: since the service for the parent context is effectively parsed from the jndi name
[4:29 PM] Brian Stansberry: ah, i just happened to randomly look up https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/concurrent/service/E...
[4:30 PM] Brian Stansberry: where it's more a factory for the name param for the BinderService
[4:30 PM] Paul Ferraro: otherwise, I would normally expect to use a dynamic capability where the dynamic name corresponds to the namespace
[4:31 PM] Brian Stansberry: yeah
[4:31 PM] Paul Ferraro: the crux of that logic is here: https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/jboss/as/naming/deployment/C...
[4:32 PM] Paul Ferraro: which is why I figured it was probably sufficient to expose a capability for the base store
[4:33 PM] Brian Stansberry: ok
[4:33 PM] Brian Stansberry: well, so far I haven't heard anything that makes me think anything you've done is wrong, including your name choice
[4:34 PM] Brian Stansberry: so I propose to just paste ^^^ as a comment in the JIRA to help anyone who presses forward, and then ack the PR
[4:35 PM] Brian Stansberry: unless you want to change the name
[4:36 PM] Brian Stansberry: @PaulFerraro but I think your PR shouldn't resolve the JIRAs as there's more to do

> Naming subsystem does not expose a proper capability contract
> -------------------------------------------------------------
>
>                 Key: WFLY-7113
>                 URL: https://issues.jboss.org/browse/WFLY-7113
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> Subsystems that currently use JNDI bindings require that the naming subsystem be present.  The naming subsystem should expose capabilities for which other subsystems can test for the presence, so they can function in the absence of the naming subsystem.

--
This message was sent by Atlassian JIRA
(v7.2.3#72005)