Oooh, neat idea Salvatore. +1 to creativity. Really interesting.
Adam
On Mon, Nov 16, 2015 at 6:25 AM, Salvatore Papa
wrote:
> If you're on a linux system, a alternative i've used in the past is to
> create another directory, full of symlinks pointing to the
Per NiFi-1165: a discussion is occurring on the ticket:
https://issues.apache.org/jira/browse/NIFI-1165
Overall, most of the issues are identified and pending a fix from Mark, Oleg
and I. The issues were encountered on two different windows 8 machines by me
and on windows 2012 R2 by Mark.
Github user naveenmadhire commented on the pull request:
https://github.com/apache/nifi/pull/125#issuecomment-157086151
Closing the pull request. As I've messed up with the commits. I will open a
new one soon. Sorry for the trouble.
---
If your project is set up for it, you can
Github user naveenmadhire closed the pull request at:
https://github.com/apache/nifi/pull/125
---
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
Github user olegz commented on the pull request:
https://github.com/apache/nifi/pull/123#issuecomment-157029989
@trkurc @joewitt @apiri
Guys, please see the latest commit. Didn't squash it, so its easier to read
and see what's been addressed. In summary:
1. Since based on the
GitHub user olegz opened a pull request:
https://github.com/apache/nifi/pull/126
NIFI-1164 decreased the chances of race condition
Removed checks for 'if (getState() != ControllerServiceState.DISABLED)â
from StandardControllerServiceNode.verifyCanEnable(..) operations based on
Github user markap14 commented on the pull request:
https://github.com/apache/nifi/pull/125#issuecomment-157140757
@naveenmadhire no trouble at all :) Looking forward to the new pull request.
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user jskora commented on a diff in the pull request:
https://github.com/apache/nifi/pull/121#discussion_r44967382
--- Diff:
nifi-nar-bundles/nifi-aws-bundle/nifi-aws-processors/src/main/java/org/apache/nifi/processors/aws/s3/PutS3ObjectMultipart.java
---
@@ -0,0 +1,550 @@
GitHub user naveenmadhire opened a pull request:
https://github.com/apache/nifi/pull/127
NIFI-1146 Allow GetKafka to be configured with auto.offset.reset to
"largest" or "smallest"
Pull request with changes.
@markap14 I removed the writeAttributes ones, since there is no need
Github user asfgit closed the pull request at:
https://github.com/apache/nifi/pull/127
---
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
Github user markap14 commented on the pull request:
https://github.com/apache/nifi/pull/127#issuecomment-157179517
@naveenmadhire - code looks good. Builds without problem, and testing on my
Kafka instance shows the expected results. Nice work! And thanks for the
contribution. On
Github user markap14 commented on the pull request:
https://github.com/apache/nifi/pull/123#issuecomment-157182575
@trkurc Personally, I have exactly 0 qualms about changing it to package
private. If I choose to take some random util class from a release of Apache
Tomcat, for
Github user olegz closed the pull request at:
https://github.com/apache/nifi/pull/126
---
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
Github user olegz commented on the pull request:
https://github.com/apache/nifi/pull/126#issuecomment-157173562
Pulling back, see comments in JIRA
---
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
The documentation is a little unclear and light. Made a ticket [1] to
clarify how these properties are interpreted.
Thanks!
[1] https://issues.apache.org/jira/browse/NIFI-1177
On Mon, Nov 16, 2015 at 3:52 PM, Sumanth Chinthagunta
wrote:
> Thanks Aldrin.
> it works after I
Github user trkurc commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157213254
@jskora what would you expect the following unit tests to do?
```
@Test
public void testInvalidRegex() {
final TestRunner runner =
Github user trkurc commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157218572
I think what I'm getting at is that I think having a property that requires
the expression to evaluate to a valid regex might mean it is time for a failure
relationship
Taking liberties - so let me throw few example. I am sure you’d agree that
Thread creation and management is an expensive and hard and error prone, hence
new java.util.concurrent and all the goodies in it.
- There is a patch currently in the queue where there is a creation of new
Thread() and
Github user jskora commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157265254
Interesting. Before I enabled EL support, it had a
REGULAR_EXPRESSION_VALIDATOR which would have caught those. Is there a way to
validate a property that supports
Github user apiri commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157265218
@trkurc I am onboard with what you are driving toward. I had created an
issue around the same thought process.
https://issues.apache.org/jira/browse/NIFI-813
The
Github user trkurc commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157266419
@jskora as @apiri pointed out, i think that we may have to live with the
problem until NIFI-813 is resolved. I tried wrapping my head around a validator
that handled the
Github user trkurc commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157266895
@apiri you have some history with this - what is a greater evil, no el
support or possibly breaking? this is already a processor that appears to have
a "beware of el" sign
So back in the day...
Here is the thought process behind how it works today at a high level
and taking some generalities. Developers of extensions, and that
primarily means processors, begin process sessions. In a process
session a processor can access, create, destroy zero or more flow
files
Github user jskora commented on the pull request:
https://github.com/apache/nifi/pull/116#issuecomment-157272302
@trkurc, this is not a problem fix but an enhancement based on discussion
that occurred on [NIFI-641|https://issues.apache.org/jira/browse/NIFI-641]. It
seemed easy
If you're on a linux system, a alternative i've used in the past is to
create another directory, full of symlinks pointing to the original
directory.
As an example, assuming you have a directory: /data/input_files/ full of
files, create a directory /data/input_links/, and from that new directory,
25 matches
Mail list logo