[jira] [Resolved] (APEXCORE-704) Add supporting of programmatic logger appender

[Vlad Rozov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/APEXCORE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Rozov resolved APEXCORE-704.
-
   Resolution: Implemented
Fix Version/s: 3.7.0

> Add supporting of programmatic logger appender
> --
>
> Key: APEXCORE-704
> URL: https://issues.apache.org/jira/browse/APEXCORE-704
> Project: Apache Apex Core
>  Issue Type: Improvement
>Reporter: Sergey Golovko
>Assignee: Sergey Golovko
> Fix For: 3.7.0
>
>
> Add supporting of a programmatic logger appender that can be added to Apex 
> Application Master and Containers and be configurable programmatically.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (APEXCORE-704) Add supporting of programmatic logger appender

[Vlad Rozov (JIRA)]

[ 
https://issues.apache.org/jira/browse/APEXCORE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011538#comment-16011538
 ] 

Vlad Rozov commented on APEXCORE-704:
-

[~sgolovko] Please document format required to add new appenders in this JIRA.

> Add supporting of programmatic logger appender
> --
>
> Key: APEXCORE-704
> URL: https://issues.apache.org/jira/browse/APEXCORE-704
> Project: Apache Apex Core
>  Issue Type: Improvement
>Reporter: Sergey Golovko
>Assignee: Sergey Golovko
> Fix For: 3.7.0
>
>
> Add supporting of a programmatic logger appender that can be added to Apex 
> Application Master and Containers and be configurable programmatically.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (APEXCORE-704) Add supporting of programmatic logger appender

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/APEXCORE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011533#comment-16011533
 ] 

ASF GitHub Bot commented on APEXCORE-704:
-

Github user asfgit closed the pull request at:

https://github.com/apache/apex-core/pull/515


> Add supporting of programmatic logger appender
> --
>
> Key: APEXCORE-704
> URL: https://issues.apache.org/jira/browse/APEXCORE-704
> Project: Apache Apex Core
>  Issue Type: Improvement
>Reporter: Sergey Golovko
>Assignee: Sergey Golovko
>
> Add supporting of a programmatic logger appender that can be added to Apex 
> Application Master and Containers and be configurable programmatically.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] apex-core pull request #515: APEXCORE-704 Add supporting of programmatic log...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/apex-core/pull/515


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Backward compatibility issue in 3.6.0 release

[Vlad Rozov]

I am slightly in favor of getters and setters approach as well. Likely hotspot 
will optimize extra call anyway.  

Thank you,
Vlad

Отправлено с iPhone

> On May 15, 2017, at 10:51, Bhupesh Chawda  wrote:
> 
> I also suggest going for 1.
> But I think we should make variables private and provide protected getters
> and setters.
> 
> ~ Bhupesh
> 
> 
> On May 15, 2017 23:18, "Bhupesh Chawda"  wrote:
> 
> Actually Ajay discovered this when upgrading the core dependency test.
> One of the tests was failing.
> 
> ~ Bhupesh
> 
> 
> On May 15, 2017 23:15, "Pramod Immaneni"  wrote:
> 
> I would suggest going with 1.
> 
> Bhupesh how did you see this? Did it see it as part of working on an
> operator in Malhar?
> 
>> On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov  wrote:
>> 
>> Hi All,
>> 
>> There is a possible change in operators behavior caused by changes that
>> were introduced in the release 3.6.0 into DefaultInputPort and
>> DefaultOutputPort. Please see https://issues.apache.org/jira
>> /browse/APEXCORE-722. We need to agree how to proceed.
>> 
>> 1. Break semantic versioning for the Default Input and Output Ports in the
>> next release (3.7.0), declare protected variables as private and provide
>> protected access method. Another option is to rename protected variables
> to
>> use less common names (for example __count).
>> 2. Keep protected variables with the risk that the following common
>> operator design pattern will be used accidentally by existing operators
> and
>> newly designed operators:
>> 
>> public Operator extends BaseOperator {
>>  private int count;
>>  public DefaultInputPort in = new DefaultInputPort() {
>>@Override
>>public void process(Object tuple)
>>{
>>   count++;  // updates DefaultInputPort count, not Operator count!
>>}
>>  }
>> }
>> 
>> 
>> Thank you,
>> 
>> Vlad
>> 

Re: Backward compatibility issue in 3.6.0 release

[Amol Kekre]

I agree with Vlad; I would suggest option 1 too, but not a patch release.
Documentation should suffice.

Thks,
Amol


E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Mon, May 15, 2017 at 11:13 AM, Vlad Rozov 
wrote:

> I considered proposing 3.6.1 patch release, but rejected it as API changes
> do not qualify for the patch release. Note that this is a compile time
> backward compatibility issue, not a run-time.
>
> Instead of 3.6.1 I would propose to spell out the issue in 3.6.0
> documentation.
>
> Thank you,
> Vlad
>
> Отправлено с iPhone
>
> > On May 15, 2017, at 10:40, Munagala Ramanath
>  wrote:
> >
> > I like proposal 1 too; I also agree with Ajay about doing a 2.6.1 patch
> release.
> > Ram
> >
> >On Monday, May 15, 2017 10:18 AM, AJAY GUPTA 
> wrote:
> >
> >
> > I would vote for 1 and making variables private since it anyways breaks
> > semantic versioning.
> > I think it would it be a good idea to release a 3.6.1 patch release as
> > well.
> >
> >
> > Ajay
> >
> > On Mon, May 15, 2017 at 10:36 PM, Sanjay Pujare 
> > wrote:
> >
> >> I vote for renaming to less common names like __count. The renaming
> breaks
> >> compatibility from 3.6.0 to 3.7.0 but seems to be the best option.
> >>
> >> On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov 
> >> wrote:
> >>
> >>> Hi All,
> >>>
> >>> There is a possible change in operators behavior caused by changes that
> >>> were introduced in the release 3.6.0 into DefaultInputPort and
> >>> DefaultOutputPort. Please see https://issues.apache.org/jira
> >>> /browse/APEXCORE-722. We need to agree how to proceed.
> >>>
> >>> 1. Break semantic versioning for the Default Input and Output Ports in
> >> the
> >>> next release (3.7.0), declare protected variables as private and
> provide
> >>> protected access method. Another option is to rename protected
> variables
> >> to
> >>> use less common names (for example __count).
> >>> 2. Keep protected variables with the risk that the following common
> >>> operator design pattern will be used accidentally by existing operators
> >> and
> >>> newly designed operators:
> >>>
> >>> public Operator extends BaseOperator {
> >>>   private int count;
> >>>   public DefaultInputPort in = new DefaultInputPort() {
> >>> @Override
> >>> public void process(Object tuple)
> >>> {
> >>> count++;  // updates DefaultInputPort count, not Operator
> count!
> >>> }
> >>>   }
> >>> }
> >>>
> >>>
> >>> Thank you,
> >>>
> >>> Vlad
> >>>
> >>
> >
> >
>

Re: Backward compatibility issue in 3.6.0 release

[Vlad Rozov]

I considered proposing 3.6.1 patch release, but rejected it as API changes do 
not qualify for the patch release. Note that this is a compile time backward 
compatibility issue, not a run-time.

Instead of 3.6.1 I would propose to spell out the issue in 3.6.0 documentation.

Thank you,
Vlad

Отправлено с iPhone

> On May 15, 2017, at 10:40, Munagala Ramanath  
> wrote:
> 
> I like proposal 1 too; I also agree with Ajay about doing a 2.6.1 patch 
> release.
> Ram 
> 
>On Monday, May 15, 2017 10:18 AM, AJAY GUPTA  wrote:
> 
> 
> I would vote for 1 and making variables private since it anyways breaks
> semantic versioning.
> I think it would it be a good idea to release a 3.6.1 patch release as
> well.
> 
> 
> Ajay
> 
> On Mon, May 15, 2017 at 10:36 PM, Sanjay Pujare 
> wrote:
> 
>> I vote for renaming to less common names like __count. The renaming breaks
>> compatibility from 3.6.0 to 3.7.0 but seems to be the best option.
>> 
>> On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov 
>> wrote:
>> 
>>> Hi All,
>>> 
>>> There is a possible change in operators behavior caused by changes that
>>> were introduced in the release 3.6.0 into DefaultInputPort and
>>> DefaultOutputPort. Please see https://issues.apache.org/jira
>>> /browse/APEXCORE-722. We need to agree how to proceed.
>>> 
>>> 1. Break semantic versioning for the Default Input and Output Ports in
>> the
>>> next release (3.7.0), declare protected variables as private and provide
>>> protected access method. Another option is to rename protected variables
>> to
>>> use less common names (for example __count).
>>> 2. Keep protected variables with the risk that the following common
>>> operator design pattern will be used accidentally by existing operators
>> and
>>> newly designed operators:
>>> 
>>> public Operator extends BaseOperator {
>>>   private int count;
>>>   public DefaultInputPort in = new DefaultInputPort() {
>>> @Override
>>> public void process(Object tuple)
>>> {
>>> count++;  // updates DefaultInputPort count, not Operator count!
>>> }
>>>   }
>>> }
>>> 
>>> 
>>> Thank you,
>>> 
>>> Vlad
>>> 
>> 
> 
> 

Re: Backward compatibility issue in 3.6.0 release

[Bhupesh Chawda]

I also suggest going for 1.
But I think we should make variables private and provide protected getters
and setters.

~ Bhupesh


On May 15, 2017 23:18, "Bhupesh Chawda"  wrote:

Actually Ajay discovered this when upgrading the core dependency test.
One of the tests was failing.

~ Bhupesh


On May 15, 2017 23:15, "Pramod Immaneni"  wrote:

I would suggest going with 1.

Bhupesh how did you see this? Did it see it as part of working on an
operator in Malhar?

On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov  wrote:

> Hi All,
>
> There is a possible change in operators behavior caused by changes that
> were introduced in the release 3.6.0 into DefaultInputPort and
> DefaultOutputPort. Please see https://issues.apache.org/jira
> /browse/APEXCORE-722. We need to agree how to proceed.
>
> 1. Break semantic versioning for the Default Input and Output Ports in the
> next release (3.7.0), declare protected variables as private and provide
> protected access method. Another option is to rename protected variables
to
> use less common names (for example __count).
> 2. Keep protected variables with the risk that the following common
> operator design pattern will be used accidentally by existing operators
and
> newly designed operators:
>
> public Operator extends BaseOperator {
>   private int count;
>   public DefaultInputPort in = new DefaultInputPort() {
> @Override
> public void process(Object tuple)
> {
>count++;  // updates DefaultInputPort count, not Operator count!
> }
>   }
> }
>
>
> Thank you,
>
> Vlad
>

Re: Backward compatibility issue in 3.6.0 release

[Bhupesh Chawda]

Actually Ajay discovered this when upgrading the core dependency test.
One of the tests was failing.

~ Bhupesh

On May 15, 2017 23:15, "Pramod Immaneni"  wrote:

I would suggest going with 1.

Bhupesh how did you see this? Did it see it as part of working on an
operator in Malhar?

On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov  wrote:

> Hi All,
>
> There is a possible change in operators behavior caused by changes that
> were introduced in the release 3.6.0 into DefaultInputPort and
> DefaultOutputPort. Please see https://issues.apache.org/jira
> /browse/APEXCORE-722. We need to agree how to proceed.
>
> 1. Break semantic versioning for the Default Input and Output Ports in the
> next release (3.7.0), declare protected variables as private and provide
> protected access method. Another option is to rename protected variables
to
> use less common names (for example __count).
> 2. Keep protected variables with the risk that the following common
> operator design pattern will be used accidentally by existing operators
and
> newly designed operators:
>
> public Operator extends BaseOperator {
>   private int count;
>   public DefaultInputPort in = new DefaultInputPort() {
> @Override
> public void process(Object tuple)
> {
>count++;  // updates DefaultInputPort count, not Operator count!
> }
>   }
> }
>
>
> Thank you,
>
> Vlad
>

Re: Backward compatibility issue in 3.6.0 release

[Pramod Immaneni]

I would suggest going with 1.

Bhupesh how did you see this? Did it see it as part of working on an
operator in Malhar?

On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov  wrote:

> Hi All,
>
> There is a possible change in operators behavior caused by changes that
> were introduced in the release 3.6.0 into DefaultInputPort and
> DefaultOutputPort. Please see https://issues.apache.org/jira
> /browse/APEXCORE-722. We need to agree how to proceed.
>
> 1. Break semantic versioning for the Default Input and Output Ports in the
> next release (3.7.0), declare protected variables as private and provide
> protected access method. Another option is to rename protected variables to
> use less common names (for example __count).
> 2. Keep protected variables with the risk that the following common
> operator design pattern will be used accidentally by existing operators and
> newly designed operators:
>
> public Operator extends BaseOperator {
>   private int count;
>   public DefaultInputPort in = new DefaultInputPort() {
> @Override
> public void process(Object tuple)
> {
>count++;  // updates DefaultInputPort count, not Operator count!
> }
>   }
> }
>
>
> Thank you,
>
> Vlad
>

Re: Backward compatibility issue in 3.6.0 release

[Munagala Ramanath]

I like proposal 1 too; I also agree with Ajay about doing a 2.6.1 patch release.
Ram 

On Monday, May 15, 2017 10:18 AM, AJAY GUPTA  wrote:
 

 I would vote for 1 and making variables private since it anyways breaks
semantic versioning.
I think it would it be a good idea to release a 3.6.1 patch release as
well.


Ajay

On Mon, May 15, 2017 at 10:36 PM, Sanjay Pujare 
wrote:

> I vote for renaming to less common names like __count. The renaming breaks
> compatibility from 3.6.0 to 3.7.0 but seems to be the best option.
>
> On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov 
> wrote:
>
> > Hi All,
> >
> > There is a possible change in operators behavior caused by changes that
> > were introduced in the release 3.6.0 into DefaultInputPort and
> > DefaultOutputPort. Please see https://issues.apache.org/jira
> > /browse/APEXCORE-722. We need to agree how to proceed.
> >
> > 1. Break semantic versioning for the Default Input and Output Ports in
> the
> > next release (3.7.0), declare protected variables as private and provide
> > protected access method. Another option is to rename protected variables
> to
> > use less common names (for example __count).
> > 2. Keep protected variables with the risk that the following common
> > operator design pattern will be used accidentally by existing operators
> and
> > newly designed operators:
> >
> > public Operator extends BaseOperator {
> >  private int count;
> >  public DefaultInputPort in = new DefaultInputPort() {
> >    @Override
> >    public void process(Object tuple)
> >    {
> >        count++;  // updates DefaultInputPort count, not Operator count!
> >    }
> >  }
> > }
> >
> >
> > Thank you,
> >
> > Vlad
> >
>


   

Re: Backward compatibility issue in 3.6.0 release

[AJAY GUPTA]

I would vote for 1 and making variables private since it anyways breaks
semantic versioning.
I think it would it be a good idea to release a 3.6.1 patch release as
well.


Ajay

On Mon, May 15, 2017 at 10:36 PM, Sanjay Pujare 
wrote:

> I vote for renaming to less common names like __count. The renaming breaks
> compatibility from 3.6.0 to 3.7.0 but seems to be the best option.
>
> On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov 
> wrote:
>
> > Hi All,
> >
> > There is a possible change in operators behavior caused by changes that
> > were introduced in the release 3.6.0 into DefaultInputPort and
> > DefaultOutputPort. Please see https://issues.apache.org/jira
> > /browse/APEXCORE-722. We need to agree how to proceed.
> >
> > 1. Break semantic versioning for the Default Input and Output Ports in
> the
> > next release (3.7.0), declare protected variables as private and provide
> > protected access method. Another option is to rename protected variables
> to
> > use less common names (for example __count).
> > 2. Keep protected variables with the risk that the following common
> > operator design pattern will be used accidentally by existing operators
> and
> > newly designed operators:
> >
> > public Operator extends BaseOperator {
> >   private int count;
> >   public DefaultInputPort in = new DefaultInputPort() {
> > @Override
> > public void process(Object tuple)
> > {
> >count++;  // updates DefaultInputPort count, not Operator count!
> > }
> >   }
> > }
> >
> >
> > Thank you,
> >
> > Vlad
> >
>

Re: Backward compatibility issue in 3.6.0 release

[Sanjay Pujare]

I vote for renaming to less common names like __count. The renaming breaks
compatibility from 3.6.0 to 3.7.0 but seems to be the best option.

On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov  wrote:

> Hi All,
>
> There is a possible change in operators behavior caused by changes that
> were introduced in the release 3.6.0 into DefaultInputPort and
> DefaultOutputPort. Please see https://issues.apache.org/jira
> /browse/APEXCORE-722. We need to agree how to proceed.
>
> 1. Break semantic versioning for the Default Input and Output Ports in the
> next release (3.7.0), declare protected variables as private and provide
> protected access method. Another option is to rename protected variables to
> use less common names (for example __count).
> 2. Keep protected variables with the risk that the following common
> operator design pattern will be used accidentally by existing operators and
> newly designed operators:
>
> public Operator extends BaseOperator {
>   private int count;
>   public DefaultInputPort in = new DefaultInputPort() {
> @Override
> public void process(Object tuple)
> {
>count++;  // updates DefaultInputPort count, not Operator count!
> }
>   }
> }
>
>
> Thank you,
>
> Vlad
>

Re: Backward compatibility issue in 3.6.0 release

[Thomas Weise]

I would prefer 1. - treat it as bug and add exception to semver check to
fix the issue (in both master and release branch).

In light of recent discussions, I think it is necessary to up the review
due diligence for changes to the API and those classes in core that are
covered by backward compatibility.

Thanks,
Thomas



On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov  wrote:

> Hi All,
>
> There is a possible change in operators behavior caused by changes that
> were introduced in the release 3.6.0 into DefaultInputPort and
> DefaultOutputPort. Please see https://issues.apache.org/jira
> /browse/APEXCORE-722. We need to agree how to proceed.
>
> 1. Break semantic versioning for the Default Input and Output Ports in the
> next release (3.7.0), declare protected variables as private and provide
> protected access method. Another option is to rename protected variables to
> use less common names (for example __count).
> 2. Keep protected variables with the risk that the following common
> operator design pattern will be used accidentally by existing operators and
> newly designed operators:
>
> public Operator extends BaseOperator {
>   private int count;
>   public DefaultInputPort in = new DefaultInputPort() {
> @Override
> public void process(Object tuple)
> {
>count++;  // updates DefaultInputPort count, not Operator count!
> }
>   }
> }
>
>
> Thank you,
>
> Vlad
>

Backward compatibility issue in 3.6.0 release

[Vlad Rozov]

Hi All,

There is a possible change in operators behavior caused by changes that 
were introduced in the release 3.6.0 into DefaultInputPort and 
DefaultOutputPort. Please see 
https://issues.apache.org/jira/browse/APEXCORE-722. We need to agree how 
to proceed.


1. Break semantic versioning for the Default Input and Output Ports in 
the next release (3.7.0), declare protected variables as private and 
provide protected access method. Another option is to rename protected 
variables to use less common names (for example __count).
2. Keep protected variables with the risk that the following common 
operator design pattern will be used accidentally by existing operators 
and newly designed operators:


public Operator extends BaseOperator {
  private int count;
  public DefaultInputPort in = new DefaultInputPort() {
@Override
public void process(Object tuple)
{
   count++;  // updates DefaultInputPort count, not Operator count!
}
  }
}


Thank you,

Vlad

[jira] [Updated] (APEXCORE-722) Protected data members in DefaultInputPort and DefaultOutputPort may interfere with user code

[Vlad Rozov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/APEXCORE-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Rozov updated APEXCORE-722:

Affects Version/s: 3.6.0

> Protected data members in DefaultInputPort and DefaultOutputPort may 
> interfere with user code
> -
>
> Key: APEXCORE-722
> URL: https://issues.apache.org/jira/browse/APEXCORE-722
> Project: Apache Apex Core
>  Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Bhupesh Chawda
>Assignee: Bhupesh Chawda
>
> Following code in DefaultInputPort may interfere with user defined variables 
> with the same names.
> {code}
>   protected int count;
>   protected boolean connected = false;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (APEXMALHAR-2447) No indication from AbstractFileInputOperator when directory is empty

[Priyanka Gugale (JIRA)]

 [ 
https://issues.apache.org/jira/browse/APEXMALHAR-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Priyanka Gugale resolved APEXMALHAR-2447.
-
   Resolution: Fixed
Fix Version/s: 3.8.0

> No indication from AbstractFileInputOperator when directory is empty
> 
>
> Key: APEXMALHAR-2447
> URL: https://issues.apache.org/jira/browse/APEXMALHAR-2447
> Project: Apache Apex Malhar
>  Issue Type: Improvement
>Reporter: Velineni Lakshmi Prasanna
>Assignee: Velineni Lakshmi Prasanna
>Priority: Minor
> Fix For: 3.8.0
>
>
> AbstractFileInputOperator scans a directory for files and outputs the file 
> contents. However, when the directory is empty nothing is sent. A downstream 
> operator may want some basic information that the input directory is scanned, 
> so for example, it can create an output folder. Add a notification to the 
> operator when the directory is scanned for the first time. An implementation, 
> for example, can use this notification to send a control tuple with the 
> directory path notifying the downstream that the directory has been visited.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (APEXMALHAR-2447) No indication from AbstractFileInputOperator when directory is empty

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/APEXMALHAR-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16010054#comment-16010054
 ] 

ASF GitHub Bot commented on APEXMALHAR-2447:


Github user asfgit closed the pull request at:

https://github.com/apache/apex-malhar/pull/619


> No indication from AbstractFileInputOperator when directory is empty
> 
>
> Key: APEXMALHAR-2447
> URL: https://issues.apache.org/jira/browse/APEXMALHAR-2447
> Project: Apache Apex Malhar
>  Issue Type: Improvement
>Reporter: Velineni Lakshmi Prasanna
>Assignee: Velineni Lakshmi Prasanna
>Priority: Minor
>
> AbstractFileInputOperator scans a directory for files and outputs the file 
> contents. However, when the directory is empty nothing is sent. A downstream 
> operator may want some basic information that the input directory is scanned, 
> so for example, it can create an output folder. Add a notification to the 
> operator when the directory is scanned for the first time. An implementation, 
> for example, can use this notification to send a control tuple with the 
> directory path notifying the downstream that the directory has been visited.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] apex-malhar pull request #619: APEXMALHAR-2447 Notification from AbstractFil...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/apex-malhar/pull/619


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---