[
https://issues.apache.org/jira/browse/OOZIE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229912#comment-13229912
]
[email protected] commented on OOZIE-674:
-----------------------------------------------------
bq. On 2012-03-15 01:49:40, Angelo K. Huang wrote:
bq. >
trunk/core/src/main/java/org/apache/oozie/command/coord/CoordCommandUtils.java,
line 84
bq. > <https://reviews.apache.org/r/3752/diff/2/?file=88735#file88735line84>
bq. >
bq. > I am not sure why you move these lines out. There is no difference
before and after. You still call this function before you call
getInstanceNumber().
Earlier, resolveInstanceRange was working with input strings which is
coordext:today. This gets passed to getInstanceNumber which evaluates EL for
this input and returns instance number correctly. But the input string is also
passed to getFuncType which doesn't recognize this input.
So, I changed resolveInstanceRange to evaluate the EL input and pass the
evaluation to both getInstanceNumber and getFuncType.
Yes, there is no code difference, but the placement of the code differs.
bq. On 2012-03-15 01:49:40, Angelo K. Huang wrote:
bq. >
trunk/core/src/test/java/org/apache/oozie/command/coord/TestCoordELExtensions.java,
line 20
bq. > <https://reviews.apache.org/r/3752/diff/2/?file=88738#file88738line20>
bq. >
bq. > Please extends from XDataTestCase instead of XTestCase.
will do
bq. On 2012-03-15 01:49:40, Angelo K. Huang wrote:
bq. >
trunk/core/src/test/java/org/apache/oozie/command/coord/TestCoordELExtensions.java,
line 68
bq. > <https://reviews.apache.org/r/3752/diff/2/?file=88738#file88738line68>
bq. >
bq. > There is add coord job method in XDataTestCase.
will do
bq. On 2012-03-15 01:49:40, Angelo K. Huang wrote:
bq. >
trunk/core/src/test/java/org/apache/oozie/command/coord/TestCoordELExtensions.java,
line 85
bq. > <https://reviews.apache.org/r/3752/diff/2/?file=88738#file88738line85>
bq. >
bq. > You can read app xml from file. You can take a look at the example
from XDataTestCase.addRecordToCoordJobTable().
will do
bq. On 2012-03-15 01:49:40, Angelo K. Huang wrote:
bq. > trunk/core/src/test/resources/oozie-site-coordel.xml, line 6
bq. > <https://reviews.apache.org/r/3752/diff/2/?file=88739#file88739line6>
bq. >
bq. > Since the order is currentMonth and today, you should use same order
here.
Does it matter what order its in?
- shwethags
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3752/#review5979
-----------------------------------------------------------
On 2012-03-07 09:43:36, shwethags wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3752/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2012-03-07 09:43:36)
bq.
bq.
bq. Review request for oozie.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. I have an EL extension today(0,0) which maps to start day of nominal time.
This is used to specify startInstance, endInstance and instance in dataIn and
dataOut of coordinator.
bq.
bq. In CoordCommandUtils.resolveInstanceRange(), getInstanceNumber has to
return the instance number with respect to current. So, for
coord-action-create-inst context, I have mapped today to current and hence
getInstanceNumber returns the correct number. But later in
resolveInstanceRange(), getFuncType is called with startInstance value which is
today in this case and it maps to UNEXPECTED and throws up. getFuncType should
be passed the evaluation of coord-action-create-inst context
bq.
bq.
bq. This addresses bug OOZIE-674.
bq. https://issues.apache.org/jira/browse/OOZIE-674
bq.
bq.
bq. Diffs
bq. -----
bq.
bq.
trunk/core/src/main/java/org/apache/oozie/command/coord/CoordCommandUtils.java
1297889
bq. trunk/core/src/main/java/org/apache/oozie/coord/CoordELFunctions.java
1297889
bq.
trunk/core/src/test/java/org/apache/oozie/command/coord/CoordELExtension.java
PRE-CREATION
bq.
trunk/core/src/test/java/org/apache/oozie/command/coord/TestCoordELExtensions.java
PRE-CREATION
bq. trunk/core/src/test/resources/oozie-site-coordel.xml PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/3752/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. UT - TestCoordActionMaterializeCommand
bq. Tested with coord:current instance range and EL extension
bq.
bq.
bq. Thanks,
bq.
bq. shwethags
bq.
bq.
> resolveInstanceRange doesn't work for EL extensions
> ---------------------------------------------------
>
> Key: OOZIE-674
> URL: https://issues.apache.org/jira/browse/OOZIE-674
> Project: Oozie
> Issue Type: Bug
> Reporter: Shwetha G S
> Labels: EL, extension
> Attachments: OOZIE-674.patch
>
>
> I have an EL extension today(0,0) which maps to start day of nominal time.
> This is used to specify startInstance, endInstance and instance in dataIn and
> dataOut of coordinator.
> In CoordCommandUtils.resolveInstanceRange(), getInstanceNumber has to return
> the instance number with respect to current. So, for coord-action-create-inst
> context, I have mapped today to current and hence getInstanceNumber returns
> the correct number. But later in resolveInstanceRange(), getFuncType is
> called with startInstance value which is today in this case and it maps to
> UNEXPECTED and throws up. getFuncType should be passed the evaluation of
> coord-action-create-inst context
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
