You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by Rohini Palaniswamy <ro...@gmail.com> on 2016/01/18 06:31:16 UTC
Re: Review Request 36123: OOZIE-2259 : Callback Action Executor
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36123/#review114940
-----------------------------------------------------------
client/src/main/resources/callback-action-0.1.xsd (lines 28 - 31)
<https://reviews.apache.org/r/36123/#comment175769>
Would suggest two additions - type and configuration.
url
type
method
configuration
arg
capture-output
- type can be http or jms. This can be used to abstract the diffent options supported in different classes and instantiated via factory making it more clean and extensible. With type, method can then just be GET, PUT and POST.
- Use configuration instead of arg if it is property with name and value.
- Can still keep arg to pass arguments like in pig/hive/spark actions and use Options parser to parse the arguments if needed.
core/src/main/java/org/apache/oozie/action/callback/CallbackActionExecutor.java (line 98)
<https://reviews.apache.org/r/36123/#comment175772>
Move all HTTP code to HTTPCallBack and JMS code to JMSCallback classes and just call sendNotification on them
interface CallBack
sendNotification(Context, URI, List<String> args, Configuration, boolean capture-output)
core/src/main/java/org/apache/oozie/service/CallbackActionService.java (lines 28 - 30)
<https://reviews.apache.org/r/36123/#comment175776>
Remove invalid comment.
core/src/main/resources/oozie-default.xml (line 2577)
<https://reviews.apache.org/r/36123/#comment175778>
Can you keep this setting similar to oozie.jms.producer.connection.properties? It will allow specifying more properties if needed.
docs/src/site/twiki/DG_CallbackActionExtension.twiki (lines 64 - 66)
<https://reviews.apache.org/r/36123/#comment175786>
Currently it only seems to be contents of body of MapMessage. In future, if support for Message properties has to be added how is that supposed to be done? Or if different type of Message - says TextMessage has to be supported.
In case of http get, it seems to be query params and with post it seems to be form params (application/x-www-form-urlencoded). What if application/octet-stream needs to be supported in the future?
I think we need to define and document all this clearly and also make sure it is not difficult to enhance in future. As I see it, the current form of definition makes it hard to support additional features of HTTP or JMS in future without hacking around how arguments are defined as we are assuming now by default there is only one way of doing it.
- Rohini Palaniswamy
On Nov. 30, 2015, 8:02 p.m., Jaydeep Vishwakarma wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36123/
> -----------------------------------------------------------
>
> (Updated Nov. 30, 2015, 8:02 p.m.)
>
>
> Review request for oozie.
>
>
> Bugs: OOZIE-2259
> https://issues.apache.org/jira/browse/OOZIE-2259
>
>
> Repository: oozie-git
>
>
> Description
> -------
>
> Adding callback as an action, It have support for HTTP and JMS server. Not covering Excecutor level queue, I will create a separate jira for it.
>
>
> Diffs
> -----
>
> client/src/main/java/org/apache/oozie/cli/OozieCLI.java 48bac7d
> client/src/main/resources/callback-action-0.1.xsd PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallbackActionExecutor.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSNotification.java PRE-CREATION
> core/src/main/java/org/apache/oozie/service/CallbackActionService.java PRE-CREATION
> core/src/main/resources/oozie-default.xml 0a7e250
> core/src/test/java/org/apache/oozie/action/callback/TestCallbackActionExecutor.java PRE-CREATION
> docs/src/site/twiki/DG_CallbackActionExtension.twiki PRE-CREATION
> docs/src/site/twiki/DG_CommandLineTool.twiki 1823247
> docs/src/site/twiki/index.twiki 8591530
>
> Diff: https://reviews.apache.org/r/36123/diff/
>
>
> Testing
> -------
>
> Done,
> Will add more test cases.
>
>
> Thanks,
>
> Jaydeep Vishwakarma
>
>
Re: Review Request 36123: OOZIE-2259 : Callback Action Executor
Posted by Rohini Palaniswamy <ro...@gmail.com>.
> On Jan. 18, 2016, 5:31 a.m., Rohini Palaniswamy wrote:
> > client/src/main/resources/callback-action-0.1.xsd, lines 28-31
> > <https://reviews.apache.org/r/36123/diff/8/?file=1148596#file1148596line28>
> >
> > Would suggest two additions - type and configuration.
> >
> > url
> > type
> > method
> > configuration
> > arg
> > capture-output
> >
> > - type can be http or jms. This can be used to abstract the diffent options supported in different classes and instantiated via factory making it more clean and extensible. With type, method can then just be GET, PUT and POST.
> > - Use configuration instead of arg if it is property with name and value.
> > - Can still keep arg to pass arguments like in pig/hive/spark actions and use Options parser to parse the arguments if needed.
>
> Jaydeep Vishwakarma wrote:
> In future we can have some other way of sending notification. GET, PUT and POST cannot be generic, As these terminology are only meaningful for http calls.
> It does not belongs to configuration category according to it characterstics.
> I always felt to have more cleaner way for pig/hive/spark action as well. The current format making it more cleaner.
> Please let me know if you have diffrent thought.
> In future we can have some other way of sending notification. GET, PUT and POST cannot be generic, As these terminology are only meaningful for http calls.
Yes. For that very reason, you definitely need type. When type is defined as HTTP, method values will be GET, PUT and POST. That is more clean instead of adding multiple different kinds of methods like HTTP_GET, HTTP_PUT, QUEUE_PUBLISH and some XXX in future without any relation between them.
> I always felt to have more cleaner way for pig/hive/spark action as well.
Pig/hive/spark/distcp are clean. They have configuration which means actual configuration used while running and arg to mean the command line arguments they take. It is easy for a commandline user to relate to as there is direct correlation. I agree with you configuration does not make sense in this case as it is actual data that you are passing there and not configuration. But arg does not make sense either as it is not arguments. In traditional sense, arguments should be based on commandline options like (-key1 val1 -key2 val2) or atleast positional (first argument is is value for key1, second argument is value for key2, etc). You can go probably go with params instead.
> On Jan. 18, 2016, 5:31 a.m., Rohini Palaniswamy wrote:
> > docs/src/site/twiki/DG_CallbackActionExtension.twiki, lines 64-66
> > <https://reviews.apache.org/r/36123/diff/8/?file=1148602#file1148602line64>
> >
> > Currently it only seems to be contents of body of MapMessage. In future, if support for Message properties has to be added how is that supposed to be done? Or if different type of Message - says TextMessage has to be supported.
> >
> > In case of http get, it seems to be query params and with post it seems to be form params (application/x-www-form-urlencoded). What if application/octet-stream needs to be supported in the future?
> >
> > I think we need to define and document all this clearly and also make sure it is not difficult to enhance in future. As I see it, the current form of definition makes it hard to support additional features of HTTP or JMS in future without hacking around how arguments are defined as we are assuming now by default there is only one way of doing it.
>
> Jaydeep Vishwakarma wrote:
> I agree, I will detail out all the details in doc.
> I have created a jira OOZIE-2403 for custom method. I will take care the future enchancement part there.
I am not asking about adding those future enhancements. The current xsd and argument/data passing interface is not clean enough to extend in future. That needs to be fixed here taking future enhancements into account. Even current usage is not even clear from documentation. I had to look into code to understand what kind of data and parameters are constructed for all methods and what needs to be actually passed in the arg section by the user for them to be used.
> On Jan. 18, 2016, 5:31 a.m., Rohini Palaniswamy wrote:
> > core/src/main/resources/oozie-default.xml, line 2577
> > <https://reviews.apache.org/r/36123/diff/8/?file=1148600#file1148600line2577>
> >
> > Can you keep this setting similar to oozie.jms.producer.connection.properties? It will allow specifying more properties if needed.
>
> Jaydeep Vishwakarma wrote:
> oozie.jms.producer.connection.properties have # and ; to separate multiple properties which is not looking clean from my view. Currently I am not seeing the use of multiple values to provide in jms callback.
Sounds good
- Rohini
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36123/#review114940
-----------------------------------------------------------
On Jan. 18, 2016, 1:28 p.m., Jaydeep Vishwakarma wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36123/
> -----------------------------------------------------------
>
> (Updated Jan. 18, 2016, 1:28 p.m.)
>
>
> Review request for oozie.
>
>
> Bugs: OOZIE-2259
> https://issues.apache.org/jira/browse/OOZIE-2259
>
>
> Repository: oozie-git
>
>
> Description
> -------
>
> Adding callback as an action, It have support for HTTP and JMS server. Not covering Excecutor level queue, I will create a separate jira for it.
>
>
> Diffs
> -----
>
> client/src/main/java/org/apache/oozie/cli/OozieCLI.java 48bac7d
> client/src/main/resources/callback-action-0.1.xsd PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallbackActionExecutor.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/HTTPCallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSCallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSNotification.java PRE-CREATION
> core/src/main/java/org/apache/oozie/service/CallbackActionService.java PRE-CREATION
> core/src/main/resources/oozie-default.xml 0a7e250
> core/src/test/java/org/apache/oozie/action/callback/TestCallbackActionExecutor.java PRE-CREATION
> docs/src/site/twiki/DG_CallbackActionExtension.twiki PRE-CREATION
> docs/src/site/twiki/DG_CommandLineTool.twiki 1823247
> docs/src/site/twiki/index.twiki 8591530
>
> Diff: https://reviews.apache.org/r/36123/diff/
>
>
> Testing
> -------
>
> Done,
> Will add more test cases.
>
>
> Thanks,
>
> Jaydeep Vishwakarma
>
>
Re: Review Request 36123: OOZIE-2259 : Callback Action Executor
Posted by Jaydeep Vishwakarma <ja...@gmail.com>.
> On Jan. 18, 2016, 5:31 a.m., Rohini Palaniswamy wrote:
> > core/src/main/resources/oozie-default.xml, line 2577
> > <https://reviews.apache.org/r/36123/diff/8/?file=1148600#file1148600line2577>
> >
> > Can you keep this setting similar to oozie.jms.producer.connection.properties? It will allow specifying more properties if needed.
oozie.jms.producer.connection.properties have # and ; to separate multiple properties which is not looking clean from my view. Currently I am not seeing the use of multiple values to provide in jms callback.
> On Jan. 18, 2016, 5:31 a.m., Rohini Palaniswamy wrote:
> > client/src/main/resources/callback-action-0.1.xsd, lines 28-31
> > <https://reviews.apache.org/r/36123/diff/8/?file=1148596#file1148596line28>
> >
> > Would suggest two additions - type and configuration.
> >
> > url
> > type
> > method
> > configuration
> > arg
> > capture-output
> >
> > - type can be http or jms. This can be used to abstract the diffent options supported in different classes and instantiated via factory making it more clean and extensible. With type, method can then just be GET, PUT and POST.
> > - Use configuration instead of arg if it is property with name and value.
> > - Can still keep arg to pass arguments like in pig/hive/spark actions and use Options parser to parse the arguments if needed.
In future we can have some other way of sending notification. GET, PUT and POST cannot be generic, As these terminology are only meaningful for http calls.
It does not belongs to configuration category according to it characterstics.
I always felt to have more cleaner way for pig/hive/spark action as well. The current format making it more cleaner.
Please let me know if you have diffrent thought.
> On Jan. 18, 2016, 5:31 a.m., Rohini Palaniswamy wrote:
> > docs/src/site/twiki/DG_CallbackActionExtension.twiki, lines 64-66
> > <https://reviews.apache.org/r/36123/diff/8/?file=1148602#file1148602line64>
> >
> > Currently it only seems to be contents of body of MapMessage. In future, if support for Message properties has to be added how is that supposed to be done? Or if different type of Message - says TextMessage has to be supported.
> >
> > In case of http get, it seems to be query params and with post it seems to be form params (application/x-www-form-urlencoded). What if application/octet-stream needs to be supported in the future?
> >
> > I think we need to define and document all this clearly and also make sure it is not difficult to enhance in future. As I see it, the current form of definition makes it hard to support additional features of HTTP or JMS in future without hacking around how arguments are defined as we are assuming now by default there is only one way of doing it.
I agree, I will detail out all the details in doc.
I have created a jira OOZIE-2403 for custom method. I will take care the future enchancement part there.
- Jaydeep
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36123/#review114940
-----------------------------------------------------------
On Jan. 18, 2016, 1:28 p.m., Jaydeep Vishwakarma wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36123/
> -----------------------------------------------------------
>
> (Updated Jan. 18, 2016, 1:28 p.m.)
>
>
> Review request for oozie.
>
>
> Bugs: OOZIE-2259
> https://issues.apache.org/jira/browse/OOZIE-2259
>
>
> Repository: oozie-git
>
>
> Description
> -------
>
> Adding callback as an action, It have support for HTTP and JMS server. Not covering Excecutor level queue, I will create a separate jira for it.
>
>
> Diffs
> -----
>
> client/src/main/java/org/apache/oozie/cli/OozieCLI.java 48bac7d
> client/src/main/resources/callback-action-0.1.xsd PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallbackActionExecutor.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/HTTPCallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSCallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSNotification.java PRE-CREATION
> core/src/main/java/org/apache/oozie/service/CallbackActionService.java PRE-CREATION
> core/src/main/resources/oozie-default.xml 0a7e250
> core/src/test/java/org/apache/oozie/action/callback/TestCallbackActionExecutor.java PRE-CREATION
> docs/src/site/twiki/DG_CallbackActionExtension.twiki PRE-CREATION
> docs/src/site/twiki/DG_CommandLineTool.twiki 1823247
> docs/src/site/twiki/index.twiki 8591530
>
> Diff: https://reviews.apache.org/r/36123/diff/
>
>
> Testing
> -------
>
> Done,
> Will add more test cases.
>
>
> Thanks,
>
> Jaydeep Vishwakarma
>
>
Re: Review Request 36123: OOZIE-2259 : Callback Action Executor
Posted by Srikanth Sundarrajan <sr...@hotmail.com>.
> On Jan. 18, 2016, 5:31 a.m., Rohini Palaniswamy wrote:
> > client/src/main/resources/callback-action-0.1.xsd, lines 28-31
> > <https://reviews.apache.org/r/36123/diff/8/?file=1148596#file1148596line28>
> >
> > Would suggest two additions - type and configuration.
> >
> > url
> > type
> > method
> > configuration
> > arg
> > capture-output
> >
> > - type can be http or jms. This can be used to abstract the diffent options supported in different classes and instantiated via factory making it more clean and extensible. With type, method can then just be GET, PUT and POST.
> > - Use configuration instead of arg if it is property with name and value.
> > - Can still keep arg to pass arguments like in pig/hive/spark actions and use Options parser to parse the arguments if needed.
>
> Jaydeep Vishwakarma wrote:
> In future we can have some other way of sending notification. GET, PUT and POST cannot be generic, As these terminology are only meaningful for http calls.
> It does not belongs to configuration category according to it characterstics.
> I always felt to have more cleaner way for pig/hive/spark action as well. The current format making it more cleaner.
> Please let me know if you have diffrent thought.
>
> Rohini Palaniswamy wrote:
> > In future we can have some other way of sending notification. GET, PUT and POST cannot be generic, As these terminology are only meaningful for http calls.
>
> Yes. For that very reason, you definitely need type. When type is defined as HTTP, method values will be GET, PUT and POST. That is more clean instead of adding multiple different kinds of methods like HTTP_GET, HTTP_PUT, QUEUE_PUBLISH and some XXX in future without any relation between them.
>
> > I always felt to have more cleaner way for pig/hive/spark action as well.
>
> Pig/hive/spark/distcp are clean. They have configuration which means actual configuration used while running and arg to mean the command line arguments they take. It is easy for a commandline user to relate to as there is direct correlation. I agree with you configuration does not make sense in this case as it is actual data that you are passing there and not configuration. But arg does not make sense either as it is not arguments. In traditional sense, arguments should be based on commandline options like (-key1 val1 -key2 val2) or atleast positional (first argument is is value for key1, second argument is value for key2, etc). You can go probably go with params instead.
>
> Robert Kanter wrote:
> This is a good point. I agree with Rohini that we should revisit the user-facing aspects of the action and make sure it's right and generic enough. (For example, users still find it confusing to enter the RM address in the <job-tracker> field when using Hadoop 2)
My 2 cents on inclusion of type & relating to customization of headers/payload (covered in a subsequent comment):
The feature request was to provide a simple callback /notification mechanism with the ability to customize the callback with properties from the workflow / coordinator or both (as covered in the initial exchanges in the jira). Also another important ask was to allow for this callback to be lightweight and be performed from within the oozie server without adopting the general scheme of executing action through a MR-launcher. This wasn't intended to be a general http client, which might then require support for overriding headers or to provide a stream entity in the post/put body (doing so from within the oozie server might be a bad idea, as the payload can be fairly unbounded). The way to look at the callback action definition is that there is a flattened method which descibes the implementation of the callback and the arguments which were meant to a general purpose KV map to be shared. How the KV map need to be marshalled is left to the implementation of the callback. For ex. An HTTP
_GET would send them as a query param, while JMS_PUBLISH would send them as a MapMessage. Or in other words, the contract is simply, "how to notify/callback" - method and the "what parameters to send during notification" - args/config, thus keeping it both simple and very pointed towards the callback use case.
Since the callback parameters are KV pairs, use of configuration instead of args may be more appropriate.
- Srikanth
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36123/#review114940
-----------------------------------------------------------
On Jan. 18, 2016, 1:28 p.m., Jaydeep Vishwakarma wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36123/
> -----------------------------------------------------------
>
> (Updated Jan. 18, 2016, 1:28 p.m.)
>
>
> Review request for oozie.
>
>
> Bugs: OOZIE-2259
> https://issues.apache.org/jira/browse/OOZIE-2259
>
>
> Repository: oozie-git
>
>
> Description
> -------
>
> Adding callback as an action, It have support for HTTP and JMS server. Not covering Excecutor level queue, I will create a separate jira for it.
>
>
> Diffs
> -----
>
> client/src/main/java/org/apache/oozie/cli/OozieCLI.java 48bac7d
> client/src/main/resources/callback-action-0.1.xsd PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallbackActionExecutor.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/HTTPCallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSCallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSNotification.java PRE-CREATION
> core/src/main/java/org/apache/oozie/service/CallbackActionService.java PRE-CREATION
> core/src/main/resources/oozie-default.xml 0a7e250
> core/src/test/java/org/apache/oozie/action/callback/TestCallbackActionExecutor.java PRE-CREATION
> docs/src/site/twiki/DG_CallbackActionExtension.twiki PRE-CREATION
> docs/src/site/twiki/DG_CommandLineTool.twiki 1823247
> docs/src/site/twiki/index.twiki 8591530
>
> Diff: https://reviews.apache.org/r/36123/diff/
>
>
> Testing
> -------
>
> Done,
> Will add more test cases.
>
>
> Thanks,
>
> Jaydeep Vishwakarma
>
>
Re: Review Request 36123: OOZIE-2259 : Callback Action Executor
Posted by Robert Kanter <rk...@cloudera.com>.
> On Jan. 18, 2016, 5:31 a.m., Rohini Palaniswamy wrote:
> > client/src/main/resources/callback-action-0.1.xsd, lines 28-31
> > <https://reviews.apache.org/r/36123/diff/8/?file=1148596#file1148596line28>
> >
> > Would suggest two additions - type and configuration.
> >
> > url
> > type
> > method
> > configuration
> > arg
> > capture-output
> >
> > - type can be http or jms. This can be used to abstract the diffent options supported in different classes and instantiated via factory making it more clean and extensible. With type, method can then just be GET, PUT and POST.
> > - Use configuration instead of arg if it is property with name and value.
> > - Can still keep arg to pass arguments like in pig/hive/spark actions and use Options parser to parse the arguments if needed.
>
> Jaydeep Vishwakarma wrote:
> In future we can have some other way of sending notification. GET, PUT and POST cannot be generic, As these terminology are only meaningful for http calls.
> It does not belongs to configuration category according to it characterstics.
> I always felt to have more cleaner way for pig/hive/spark action as well. The current format making it more cleaner.
> Please let me know if you have diffrent thought.
>
> Rohini Palaniswamy wrote:
> > In future we can have some other way of sending notification. GET, PUT and POST cannot be generic, As these terminology are only meaningful for http calls.
>
> Yes. For that very reason, you definitely need type. When type is defined as HTTP, method values will be GET, PUT and POST. That is more clean instead of adding multiple different kinds of methods like HTTP_GET, HTTP_PUT, QUEUE_PUBLISH and some XXX in future without any relation between them.
>
> > I always felt to have more cleaner way for pig/hive/spark action as well.
>
> Pig/hive/spark/distcp are clean. They have configuration which means actual configuration used while running and arg to mean the command line arguments they take. It is easy for a commandline user to relate to as there is direct correlation. I agree with you configuration does not make sense in this case as it is actual data that you are passing there and not configuration. But arg does not make sense either as it is not arguments. In traditional sense, arguments should be based on commandline options like (-key1 val1 -key2 val2) or atleast positional (first argument is is value for key1, second argument is value for key2, etc). You can go probably go with params instead.
This is a good point. I agree with Rohini that we should revisit the user-facing aspects of the action and make sure it's right and generic enough. (For example, users still find it confusing to enter the RM address in the <job-tracker> field when using Hadoop 2)
- Robert
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36123/#review114940
-----------------------------------------------------------
On Jan. 18, 2016, 1:28 p.m., Jaydeep Vishwakarma wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36123/
> -----------------------------------------------------------
>
> (Updated Jan. 18, 2016, 1:28 p.m.)
>
>
> Review request for oozie.
>
>
> Bugs: OOZIE-2259
> https://issues.apache.org/jira/browse/OOZIE-2259
>
>
> Repository: oozie-git
>
>
> Description
> -------
>
> Adding callback as an action, It have support for HTTP and JMS server. Not covering Excecutor level queue, I will create a separate jira for it.
>
>
> Diffs
> -----
>
> client/src/main/java/org/apache/oozie/cli/OozieCLI.java 48bac7d
> client/src/main/resources/callback-action-0.1.xsd PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallbackActionExecutor.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/HTTPCallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSCallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSNotification.java PRE-CREATION
> core/src/main/java/org/apache/oozie/service/CallbackActionService.java PRE-CREATION
> core/src/main/resources/oozie-default.xml 0a7e250
> core/src/test/java/org/apache/oozie/action/callback/TestCallbackActionExecutor.java PRE-CREATION
> docs/src/site/twiki/DG_CallbackActionExtension.twiki PRE-CREATION
> docs/src/site/twiki/DG_CommandLineTool.twiki 1823247
> docs/src/site/twiki/index.twiki 8591530
>
> Diff: https://reviews.apache.org/r/36123/diff/
>
>
> Testing
> -------
>
> Done,
> Will add more test cases.
>
>
> Thanks,
>
> Jaydeep Vishwakarma
>
>
Re: Review Request 36123: OOZIE-2259 : Callback Action Executor
Posted by Rohini Palaniswamy <ro...@gmail.com>.
> On Jan. 18, 2016, 5:31 a.m., Rohini Palaniswamy wrote:
> > docs/src/site/twiki/DG_CallbackActionExtension.twiki, lines 64-66
> > <https://reviews.apache.org/r/36123/diff/8/?file=1148602#file1148602line64>
> >
> > Currently it only seems to be contents of body of MapMessage. In future, if support for Message properties has to be added how is that supposed to be done? Or if different type of Message - says TextMessage has to be supported.
> >
> > In case of http get, it seems to be query params and with post it seems to be form params (application/x-www-form-urlencoded). What if application/octet-stream needs to be supported in the future?
> >
> > I think we need to define and document all this clearly and also make sure it is not difficult to enhance in future. As I see it, the current form of definition makes it hard to support additional features of HTTP or JMS in future without hacking around how arguments are defined as we are assuming now by default there is only one way of doing it.
>
> Jaydeep Vishwakarma wrote:
> I agree, I will detail out all the details in doc.
> I have created a jira OOZIE-2403 for custom method. I will take care the future enchancement part there.
>
> Rohini Palaniswamy wrote:
> I am not asking about adding those future enhancements. The current xsd and argument/data passing interface is not clean enough to extend in future. That needs to be fixed here taking future enhancements into account. Even current usage is not even clear from documentation. I had to look into code to understand what kind of data and parameters are constructed for all methods and what needs to be actually passed in the arg section by the user for them to be used.
One more thing I missed mentioning is HTTP headers (to specify content type, etc). Basically what I am asking is to go back and revisit all options/features associated with HTTP and JMS and come up with a generic way for user to easily and intuitively represent them in xml without confusion. Code/implementation can be easily changed anytime later but not the interface we expose to the user. We can have schema revisioning to support more enhancements. But with current schema, it will be a lot of behavior change next time if something has to be added which will not be good.
- Rohini
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36123/#review114940
-----------------------------------------------------------
On Jan. 18, 2016, 1:28 p.m., Jaydeep Vishwakarma wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36123/
> -----------------------------------------------------------
>
> (Updated Jan. 18, 2016, 1:28 p.m.)
>
>
> Review request for oozie.
>
>
> Bugs: OOZIE-2259
> https://issues.apache.org/jira/browse/OOZIE-2259
>
>
> Repository: oozie-git
>
>
> Description
> -------
>
> Adding callback as an action, It have support for HTTP and JMS server. Not covering Excecutor level queue, I will create a separate jira for it.
>
>
> Diffs
> -----
>
> client/src/main/java/org/apache/oozie/cli/OozieCLI.java 48bac7d
> client/src/main/resources/callback-action-0.1.xsd PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/CallbackActionExecutor.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/HTTPCallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSCallBack.java PRE-CREATION
> core/src/main/java/org/apache/oozie/action/callback/JMSNotification.java PRE-CREATION
> core/src/main/java/org/apache/oozie/service/CallbackActionService.java PRE-CREATION
> core/src/main/resources/oozie-default.xml 0a7e250
> core/src/test/java/org/apache/oozie/action/callback/TestCallbackActionExecutor.java PRE-CREATION
> docs/src/site/twiki/DG_CallbackActionExtension.twiki PRE-CREATION
> docs/src/site/twiki/DG_CommandLineTool.twiki 1823247
> docs/src/site/twiki/index.twiki 8591530
>
> Diff: https://reviews.apache.org/r/36123/diff/
>
>
> Testing
> -------
>
> Done,
> Will add more test cases.
>
>
> Thanks,
>
> Jaydeep Vishwakarma
>
>