[jira] [Commented] (NIFI-12055) ListenSyslog: Parse Messages didn't recognize some of the syslogevents
[
https://issues.apache.org/jira/browse/NIFI-12055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766193#comment-17766193
]
Otto Fowler commented on NIFI-12055:
I opened an issue of my upstream library ( that nifi uses an old version of for
5424 processors ): https://github.com/palindromicity/simple-syslog/issues/29
> ListenSyslog: Parse Messages didn't recognize some of the syslogevents
> --
>
> Key: NIFI-12055
> URL: https://issues.apache.org/jira/browse/NIFI-12055
> Project: Apache NiFi
> Issue Type: Task
> Components: Extensions
>Affects Versions: 1.23.2
> Environment: Debian VM
>Reporter: Dirk Mader
>Priority: Major
> Fix For: 1.23.2
>
> Attachments: dump_syslog.tcpd
>
>
> I tested with an OpenBSD Current to send syslog to ListenSyslog.
> But most of the Events are running into "invalid".
> In the attached tcpdump are 4 Events: 3 of them will marked as *invalid* by
> "Parsing Messages" 1 of them is marked as as *success*
> The success message is {{"the last message repeated 2 times"}}
> The only change in properties was the UDP Port to 5140
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi-minifi-cpp] szaszm opened a new pull request, #1660: MINIFICPP-2219 Refactor utils::StringUtils -> utils::string
szaszm opened a new pull request, #1660: URL: https://github.com/apache/nifi-minifi-cpp/pull/1660 - Marked a few implementations as `constexpr` (implies `inline`) or `inline`, where appropriate - Removed a few unused string utilities - Changed a few implementations to use `std::string_view` instead of `const std::string&`. - Rewritten repeat, because this seemed easier than fixing it. - (Resisted the urge to rewrite join_pack with concepts instead of metaprogramming hacks) Thank you for submitting a contribution to Apache NiFi - MiNiFi C++. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically main)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [x] If applicable, have you updated the LICENSE file? - [x] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [x] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MINIFICPP-2219) Refactor utils::StringUtils -> utils::string
[ https://issues.apache.org/jira/browse/MINIFICPP-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz reassigned MINIFICPP-2219: --- Assignee: Marton Szasz > Refactor utils::StringUtils -> utils::string > > > Key: MINIFICPP-2219 > URL: https://issues.apache.org/jira/browse/MINIFICPP-2219 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marton Szasz >Assignee: Marton Szasz >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINIFICPP-2219) Refactor utils::StringUtils -> utils::string
Marton Szasz created MINIFICPP-2219: --- Summary: Refactor utils::StringUtils -> utils::string Key: MINIFICPP-2219 URL: https://issues.apache.org/jira/browse/MINIFICPP-2219 Project: Apache NiFi MiNiFi C++ Issue Type: Improvement Reporter: Marton Szasz -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12075) Deprecate log methods with Object[] + Throwable parameters in ComponentLog
[
https://issues.apache.org/jira/browse/NIFI-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Turcsanyi updated NIFI-12075:
---
Description:
{{ComponentLog}} defines
{code:java}
void error(String msg, Object[] os, Throwable t)
{code}
and similar methods where the caller needs to create the {{Object}} array
explicitly which results in boilerplate and less readable code.
The preferred way has been for a while to use the vararg signature instead:
{code:java}
void error(String msg, Object... os)
{code}
These methods can also handle the last {{Throwable}} argument properly.
The {{Object[]}} methods should be deprecated and the existing usages should be
migrated to use the vararg methods. In 2.0 the deprecated methods can be
removed (NIFI-12076).
was:
{{ComponentLog}} defines
{code:java}
void error(String msg, Object[] os, Throwable t)
{code}
and similar methods where the caller needs to create the {{Object}} array
explicitly which results in boilerplate and less readable code.
The preferred way has been for a while to use the vararg signature instead:
{code:java}
void error(String msg, Object... os)
{code}
These methods can also handle the last {{Throwable}} argument properly.
The {{Object[]}} methods should be deprecated and the existing usages should be
migrated to use the vararg methods. In 2.0 the deprecated methods can be
removed.
> Deprecate log methods with Object[] + Throwable parameters in ComponentLog
> --
>
> Key: NIFI-12075
> URL: https://issues.apache.org/jira/browse/NIFI-12075
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Peter Turcsanyi
>Assignee: Peter Turcsanyi
>Priority: Major
>
> {{ComponentLog}} defines
> {code:java}
> void error(String msg, Object[] os, Throwable t)
> {code}
> and similar methods where the caller needs to create the {{Object}} array
> explicitly which results in boilerplate and less readable code.
> The preferred way has been for a while to use the vararg signature instead:
> {code:java}
> void error(String msg, Object... os)
> {code}
> These methods can also handle the last {{Throwable}} argument properly.
> The {{Object[]}} methods should be deprecated and the existing usages should
> be migrated to use the vararg methods. In 2.0 the deprecated methods can be
> removed (NIFI-12076).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12076) Remove deprecated log methods with Object[] + Throwable parameters in ComponentLog
[
https://issues.apache.org/jira/browse/NIFI-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Turcsanyi updated NIFI-12076:
---
Fix Version/s: 2.latest
> Remove deprecated log methods with Object[] + Throwable parameters in
> ComponentLog
> --
>
> Key: NIFI-12076
> URL: https://issues.apache.org/jira/browse/NIFI-12076
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Peter Turcsanyi
>Assignee: Peter Turcsanyi
>Priority: Major
> Fix For: 2.latest
>
>
> Remove the deprecated {{error(String msg, Object[] os, Throwable t)}} and
> similar methods in ComponentLog. See NIFI-12075.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-12076) Remove deprecated log methods with Object[] + Throwable parameters in ComponentLog
Peter Turcsanyi created NIFI-12076:
--
Summary: Remove deprecated log methods with Object[] + Throwable
parameters in ComponentLog
Key: NIFI-12076
URL: https://issues.apache.org/jira/browse/NIFI-12076
Project: Apache NiFi
Issue Type: Improvement
Reporter: Peter Turcsanyi
Assignee: Peter Turcsanyi
Remove the deprecated {{error(String msg, Object[] os, Throwable t)}} and
similar methods in ComponentLog. See NIFI-12075.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-12075) Deprecate log methods with Object[] + Throwable parameters in ComponentLog
Peter Turcsanyi created NIFI-12075:
--
Summary: Deprecate log methods with Object[] + Throwable
parameters in ComponentLog
Key: NIFI-12075
URL: https://issues.apache.org/jira/browse/NIFI-12075
Project: Apache NiFi
Issue Type: Improvement
Reporter: Peter Turcsanyi
Assignee: Peter Turcsanyi
{{ComponentLog}} defines
{code:java}
void error(String msg, Object[] os, Throwable t)
{code}
and similar methods where the caller needs to create the {{Object}} array
explicitly which results in boilerplate and less readable code.
The preferred way has been for a while to use the vararg signature instead:
{code:java}
void error(String msg, Object... os)
{code}
These methods can also handle the last {{Throwable}} argument properly.
The {{Object[]}} methods should be deprecated and the existing usages should be
migrated to use the vararg methods. In 2.0 the deprecated methods can be
removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-8135) DataTypeUtils conversion methods for Records to java Maps should respect Choice types
[ https://issues.apache.org/jira/browse/NIFI-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Sampson updated NIFI-8135: Status: Patch Available (was: In Progress) > DataTypeUtils conversion methods for Records to java Maps should respect > Choice types > - > > Key: NIFI-8135 > URL: https://issues.apache.org/jira/browse/NIFI-8135 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.11.4 >Reporter: Chris Sampson >Assignee: Chris Sampson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Where a schema field is a Map of Choice, with options of Array (of Strings), > Map (of Strings) or String, Record Readers incorrectly deserialise the data > of the nested Map/Array as Records containing no schema. When converting the > overall Record into a java Map using DataTypeUtils, the nested MapRecord is > not converted into a Map. > This can lead to data loss between readers & writers. > This appears to be related to one/more of: > * missing schema in the nested MapRecord object (even if it's presented with > the data to the Record Reader) - the conversion methods could infer a schema > for such MapRecords rather than effectively skipping them > * Choice types don't appear to be respected for nested fields (e.g. checking > whether the options within a Choice are for Map or Array, not just whether > the field dataType passed to the conversion method is for Map or Array, etc. > ... it's a Choice that should allow for these) > * Array/ Map conversion should not assume all elements within the collection > are of the same type, especially if the field's type is Choice -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] ChrisSamo632 opened a new pull request, #7746: NIFI-8135 allow CHOICE data types in conversion of Records to Java Maps
ChrisSamo632 opened a new pull request, #7746: URL: https://github.com/apache/nifi/pull/7746 # Summary [NIFI-8135](https://issues.apache.org/jira/browse/NIFI-8135) allow CHOICE data types in conversion of Records to Java Maps # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [x] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [x] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [x] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [x] Pull Request based on current revision of the `main` branch - [x] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [x] Build completed using `mvn clean install -P contrib-check` - [x] JDK 17 ### Licensing - ~[ ] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html)~ - ~[ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` files~ ### Documentation - ~[ ] Documentation formatting appears as expected in rendered files~ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (NIFI-12055) ListenSyslog: Parse Messages didn't recognize some of the syslogevents
[
https://issues.apache.org/jira/browse/NIFI-12055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Mader resolved NIFI-12055.
---
Resolution: Resolved
Knowledge transfer successful.
> ListenSyslog: Parse Messages didn't recognize some of the syslogevents
> --
>
> Key: NIFI-12055
> URL: https://issues.apache.org/jira/browse/NIFI-12055
> Project: Apache NiFi
> Issue Type: Task
> Components: Extensions
>Affects Versions: 1.23.2
> Environment: Debian VM
>Reporter: Dirk Mader
>Priority: Major
> Fix For: 1.23.2
>
> Attachments: dump_syslog.tcpd
>
>
> I tested with an OpenBSD Current to send syslog to ListenSyslog.
> But most of the Events are running into "invalid".
> In the attached tcpdump are 4 Events: 3 of them will marked as *invalid* by
> "Parsing Messages" 1 of them is marked as as *success*
> The success message is {{"the last message repeated 2 times"}}
> The only change in properties was the UDP Port to 5140
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12055) ListenSyslog: Parse Messages didn't recognize some of the syslogevents
[
https://issues.apache.org/jira/browse/NIFI-12055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766061#comment-17766061
]
Dirk Mader commented on NIFI-12055:
---
[~otto]
Thank you for all your help, I learned a lot.
And Sorry for my fault… I didn't recognise the <38> as a 8 bit combination of
Facility and Severity, and thought it's part of the human unreadable binary
stuff in front of the message.
Think it will not always possible to configure it on the sender's side,
especially when syslog send by 3rd party software.
But with my new knowledge I think I will able to create proper solutions to
parse invalid messages in nifi or in the splunk endpoint.
> ListenSyslog: Parse Messages didn't recognize some of the syslogevents
> --
>
> Key: NIFI-12055
> URL: https://issues.apache.org/jira/browse/NIFI-12055
> Project: Apache NiFi
> Issue Type: Task
> Components: Extensions
>Affects Versions: 1.23.2
> Environment: Debian VM
>Reporter: Dirk Mader
>Priority: Major
> Fix For: 1.23.2
>
> Attachments: dump_syslog.tcpd
>
>
> I tested with an OpenBSD Current to send syslog to ListenSyslog.
> But most of the Events are running into "invalid".
> In the attached tcpdump are 4 Events: 3 of them will marked as *invalid* by
> "Parsing Messages" 1 of them is marked as as *success*
> The success message is {{"the last message repeated 2 times"}}
> The only change in properties was the UDP Port to 5140
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
