Sumit, That all looks good. Could you point me to where you added object support to the config injector stuff. I was very happy that you were able to incorporate that and I just missed where you made that enhancement in my review. Kevin.
On 2/20/15, 12:37 PM, "Sumit Gupta (JIRA)" <[email protected]> wrote: > > [ >https://issues.apache.org/jira/browse/KNOX-481?page=com.atlassian.jira.plu >gin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329230#comme >nt-14329230 ] > >Sumit Gupta commented on KNOX-481: >---------------------------------- > >I took care of most of the comments above. Here are answers to some >things that didn't go in a commit. > >*gateway-test/src/test/java/org/apache/hadoop/gateway/deploy/DeploymnetFac >toryFuncTest.java >testSimpleTopology() >**Are there any implications to the change of the role name for webhdfs >dispatch from hdfs to webhdfs? >**Just want to make sure there wasn't any special code in HdfsDisptach >since the tests indicates GatewayDispatchFilter is now used. >{quote} >This seems to not effect anything. Especially now that the contributor is >gone, this just becomes the filter's name in gateway.xml, which now >matches the service name. >{quote} > >*gateway-provider-ha/src/main/java/org/pache/hadoop/gateway/ha/provider/Ha >ServletContextListener.java >What motivated the change of the PROVIDER_ATTRIBUTE_NAME? Just curious. >* >gateway-service-webhdfs/src/main/java/org/apache/hadoop/gateway/hdfs/dispa >tch/WebHdfsHaHttpClientDispatch.java >Did you have to do something special to get @Configure setHaProvider to >work? I thought the config injector stuff only worked with things that >could be coerced to/from strings. > >{quote} >Both these questions are related. I changed the config injector to work >with objects and that's how the HaProvider instance can get injected. >{quote} > >*gateway-spi/src/amin/java/org/apache/hadoop/gateway/topology/Topology.jav >a >**Is there ever a case where you ned to find a service by just role and >name and not version? >*gateway-spi/src/test/java/org/apache/hadoop/gateway/topology/xml/Topology >RulesModuleTests.java >**Same question as above since you don't test for this. >I added tests for this. This was a good catch although, other than test >code, no one uses this method yet. The caveat in the current >implementation is that the service *must* be looked up exactly as it has >been defined in the topology i.e. if it has name, role and version, you >must provide all. I don't know if this is a bad thing yet. > >*gateway-server/src/main/java/org/apache/hadoop/gateway/deploy/impl/Servic >eDefinitionDeploymentContributor.java >addDispatchFilterForClass >**The special case for Hive being applied to all dispatches isn't great. > >{quote} I have added a todo in the code for this. I agree this is not >great. I was thinking of adding params to the service def or some other >way to provide config to dispatch. We should discuss this and I can >create another JIRA for enhancing this functionality. >{quote} > >* >gateway-server/src/main/java/org/apche/hadoop/gateway/topology/builder/pro >perty/interpreter/ServicePropertyInterpreter.java >**Does the TODO:sumit need to be resolved before commit? > >{quote} I left this in on purpose. I don't think we use the Ambari >format. If we need to, then we need to update this class appropriately. >{quote} > > >> Support configuration driven REST API integration (aka Stacks) >> -------------------------------------------------------------- >> >> Key: KNOX-481 >> URL: https://issues.apache.org/jira/browse/KNOX-481 >> Project: Apache Knox >> Issue Type: New Feature >> Components: Server >> Affects Versions: 0.6.0 >> Reporter: Sumit Gupta >> Assignee: Sumit Gupta >> Fix For: 0.6.0 >> >> >> The gateway server has a framework that allows for plugging in new >>'services'. The framework requires code to be written for every new >>service that is added in. We need a way to make adding new services easy >>and make it possible to add a new service without writing any code >>(using configuration instead) while leaving open the flexibility of >>being able to write code if necessary. > > > >-- >This message was sent by Atlassian JIRA >(v6.3.4#6332)
