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

[ https://issues.jboss.org/browse/WFLY-7113?page=com.atlassian.jira.plugin.... ] 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.... [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/j.... [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/j.... 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.... [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/j.... [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 -- This message was sent by Atlassian JIRA (v7.2.3#72005)