[GitHub] nifi-minifi-cpp pull request #437: MINIFICPP-558: initial provisioning for C...
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/437#discussion_r233950116
--- Diff: extensions/coap/controllerservice/CoapConnector.cpp ---
@@ -0,0 +1,189 @@
+/**
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "CoapConnector.h"
+#include
+#include
+#include
+#include
+#include
+#include "core/Property.h"
+#include "CoapConnector.h"
+#include "io/validation.h"
+#include "properties/Configure.h"
+
+namespace org {
+namespace apache {
+namespace nifi {
+namespace minifi {
+namespace controllers {
+
+static core::Property RemoteServer;
+static core::Property Port;
+static core::Property MaxQueueSize;
+
+core::Property
CoapConnectorService::RemoteServer(core::PropertyBuilder::createProperty("Remote
Server")->withDescription("Remote CoAP server")->isRequired(true)->build());
+core::Property
CoapConnectorService::Port(core::PropertyBuilder::createProperty("Remote
Port")->withDescription("Remote CoAP server port")->isRequired(true)->build());
+core::Property
CoapConnectorService::MaxQueueSize(core::PropertyBuilder::createProperty("Max
Queue Size")->withDescription("Max queue size for received data
")->isRequired(true)->build());
+
+void CoapConnectorService::initialize() {
+ if (initialized_)
+return;
+
+ callback_pointers ptrs;
+ ptrs.data_received = receiveMessage;
+ ptrs.received_error = receiveError;
+ init_coap_api(this, &ptrs);
+
+ std::lock_guard lock(initialization_mutex_);
+
+ ControllerService::initialize();
+
+ initializeProperties();
+
+ initialized_ = true;
+}
+
+void CoapConnectorService::onEnable() {
+ std::string port_str;
+ if (getProperty(RemoteServer.getName(), host_) && !host_.empty() &&
getProperty(Port.getName(), port_str) && !port_str.empty()) {
+core::Property::StringToInt(port_str, port_);
+ } else {
+// this is the case where we aren't being used in the context of a
single controller service.
+if (configuration_->get("nifi.c2.agent.coap.host", host_) &&
configuration_->get("nifi.c2.agent.coap.port", port_str)) {
+ core::Property::StringToInt(port_str, port_);
+}
+
+ }
+}
+
+CoapConnectorService::CoAPMessage
CoapConnectorService::sendPayload(uint8_t type, const std::string endpoint,
unsigned char *payload, size_t size) {
+ struct coap_context_t* ctx=NULL;
+ struct coap_session_t* session=NULL;
+
+ coap_address_t dst_addr, src_addr;
+ coap_uri_t uri;
+ uri.host.s = reinterpret_cast(const_cast(host_.c_str()));
--- End diff --
Ah thanks for the diligence. This was changed last minute ( from coap to
coap2 ) and I may return back to libcoap where the signature is unsigned char.
I posted this early for someone to take a gander from an integration perspective
---
[jira] [Commented] (NIFI-5822) ControllerServices not available during @OnScheduled
[ https://issues.apache.org/jira/browse/NIFI-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688430#comment-16688430 ] ASF GitHub Bot commented on NIFI-5822: -- Github user bbende commented on the issue: https://github.com/apache/nifi/pull/3171 Reviewing... > ControllerServices not available during @OnScheduled > > > Key: NIFI-5822 > URL: https://issues.apache.org/jira/browse/NIFI-5822 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Peter Wicks >Assignee: Mark Payne >Priority: Blocker > Fix For: 1.9.0 > > > If a processor tries to load a ControllerService during `@OnScheduled`, then > `context.getControllerService` contains a null reference to > `controllerServiceProvider`. I traced this back to > `StandardProcessScheduler.startProcessor`, and the reference to > `controllerServiceProvider` is also `null` here. `ExecuteSQL` acquires it's > connection during `@OnScheduled`. > But once we reach `onTrigger`, everything is fine and you can retrieve a > controller service without issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #3171: NIFI-5822: Ensure that we don't call FlowController.getCon...
Github user bbende commented on the issue: https://github.com/apache/nifi/pull/3171 Reviewing... ---
[jira] [Commented] (MINIFICPP-558) Move PayloadSerializer in preparation for Coap
[
https://issues.apache.org/jira/browse/MINIFICPP-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688416#comment-16688416
]
ASF GitHub Bot commented on MINIFICPP-558:
--
Github user arpadboda commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/437#discussion_r233942801
--- Diff: extensions/coap/controllerservice/CoapConnector.cpp ---
@@ -0,0 +1,189 @@
+/**
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "CoapConnector.h"
+#include
+#include
+#include
+#include
+#include
+#include "core/Property.h"
+#include "CoapConnector.h"
+#include "io/validation.h"
+#include "properties/Configure.h"
+
+namespace org {
+namespace apache {
+namespace nifi {
+namespace minifi {
+namespace controllers {
+
+static core::Property RemoteServer;
+static core::Property Port;
+static core::Property MaxQueueSize;
+
+core::Property
CoapConnectorService::RemoteServer(core::PropertyBuilder::createProperty("Remote
Server")->withDescription("Remote CoAP server")->isRequired(true)->build());
+core::Property
CoapConnectorService::Port(core::PropertyBuilder::createProperty("Remote
Port")->withDescription("Remote CoAP server port")->isRequired(true)->build());
+core::Property
CoapConnectorService::MaxQueueSize(core::PropertyBuilder::createProperty("Max
Queue Size")->withDescription("Max queue size for received data
")->isRequired(true)->build());
+
+void CoapConnectorService::initialize() {
+ if (initialized_)
+return;
+
+ callback_pointers ptrs;
+ ptrs.data_received = receiveMessage;
+ ptrs.received_error = receiveError;
+ init_coap_api(this, &ptrs);
+
+ std::lock_guard lock(initialization_mutex_);
+
+ ControllerService::initialize();
+
+ initializeProperties();
+
+ initialized_ = true;
+}
+
+void CoapConnectorService::onEnable() {
+ std::string port_str;
+ if (getProperty(RemoteServer.getName(), host_) && !host_.empty() &&
getProperty(Port.getName(), port_str) && !port_str.empty()) {
+core::Property::StringToInt(port_str, port_);
+ } else {
+// this is the case where we aren't being used in the context of a
single controller service.
+if (configuration_->get("nifi.c2.agent.coap.host", host_) &&
configuration_->get("nifi.c2.agent.coap.port", port_str)) {
+ core::Property::StringToInt(port_str, port_);
+}
+
+ }
+}
+
+CoapConnectorService::CoAPMessage
CoapConnectorService::sendPayload(uint8_t type, const std::string endpoint,
unsigned char *payload, size_t size) {
+ struct coap_context_t* ctx=NULL;
+ struct coap_session_t* session=NULL;
+
+ coap_address_t dst_addr, src_addr;
+ coap_uri_t uri;
+ uri.host.s = reinterpret_cast(const_cast(host_.c_str()));
--- End diff --
Uri.host is coap_str_const_t, which has "s" as const member, so there is no
need of const cast here, just reinterpret cast to "const unsigned char *".
> Move PayloadSerializer in preparation for Coap
> --
>
> Key: MINIFICPP-558
> URL: https://issues.apache.org/jira/browse/MINIFICPP-558
> Project: NiFi MiNiFi C++
> Issue Type: Bug
>Reporter: Mr TheSegfault
>Assignee: Mr TheSegfault
>Priority: Major
> Fix For: 0.6.0
>
>
> Move PayloadSerializer
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #437: MINIFICPP-558: initial provisioning for C...
Github user arpadboda commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/437#discussion_r233942801
--- Diff: extensions/coap/controllerservice/CoapConnector.cpp ---
@@ -0,0 +1,189 @@
+/**
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "CoapConnector.h"
+#include
+#include
+#include
+#include
+#include
+#include "core/Property.h"
+#include "CoapConnector.h"
+#include "io/validation.h"
+#include "properties/Configure.h"
+
+namespace org {
+namespace apache {
+namespace nifi {
+namespace minifi {
+namespace controllers {
+
+static core::Property RemoteServer;
+static core::Property Port;
+static core::Property MaxQueueSize;
+
+core::Property
CoapConnectorService::RemoteServer(core::PropertyBuilder::createProperty("Remote
Server")->withDescription("Remote CoAP server")->isRequired(true)->build());
+core::Property
CoapConnectorService::Port(core::PropertyBuilder::createProperty("Remote
Port")->withDescription("Remote CoAP server port")->isRequired(true)->build());
+core::Property
CoapConnectorService::MaxQueueSize(core::PropertyBuilder::createProperty("Max
Queue Size")->withDescription("Max queue size for received data
")->isRequired(true)->build());
+
+void CoapConnectorService::initialize() {
+ if (initialized_)
+return;
+
+ callback_pointers ptrs;
+ ptrs.data_received = receiveMessage;
+ ptrs.received_error = receiveError;
+ init_coap_api(this, &ptrs);
+
+ std::lock_guard lock(initialization_mutex_);
+
+ ControllerService::initialize();
+
+ initializeProperties();
+
+ initialized_ = true;
+}
+
+void CoapConnectorService::onEnable() {
+ std::string port_str;
+ if (getProperty(RemoteServer.getName(), host_) && !host_.empty() &&
getProperty(Port.getName(), port_str) && !port_str.empty()) {
+core::Property::StringToInt(port_str, port_);
+ } else {
+// this is the case where we aren't being used in the context of a
single controller service.
+if (configuration_->get("nifi.c2.agent.coap.host", host_) &&
configuration_->get("nifi.c2.agent.coap.port", port_str)) {
+ core::Property::StringToInt(port_str, port_);
+}
+
+ }
+}
+
+CoapConnectorService::CoAPMessage
CoapConnectorService::sendPayload(uint8_t type, const std::string endpoint,
unsigned char *payload, size_t size) {
+ struct coap_context_t* ctx=NULL;
+ struct coap_session_t* session=NULL;
+
+ coap_address_t dst_addr, src_addr;
+ coap_uri_t uri;
+ uri.host.s = reinterpret_cast(const_cast(host_.c_str()));
--- End diff --
Uri.host is coap_str_const_t, which has "s" as const member, so there is no
need of const cast here, just reinterpret cast to "const unsigned char *".
---
[jira] [Commented] (NIFI-5822) ControllerServices not available during @OnScheduled
[ https://issues.apache.org/jira/browse/NIFI-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688412#comment-16688412 ] Joseph Witt commented on NIFI-5822: --- It appears this might be serious enough to warrant an Apache NiFi 1.8.1 release. > ControllerServices not available during @OnScheduled > > > Key: NIFI-5822 > URL: https://issues.apache.org/jira/browse/NIFI-5822 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Peter Wicks >Assignee: Mark Payne >Priority: Blocker > Fix For: 1.9.0 > > > If a processor tries to load a ControllerService during `@OnScheduled`, then > `context.getControllerService` contains a null reference to > `controllerServiceProvider`. I traced this back to > `StandardProcessScheduler.startProcessor`, and the reference to > `controllerServiceProvider` is also `null` here. `ExecuteSQL` acquires it's > connection during `@OnScheduled`. > But once we reach `onTrigger`, everything is fine and you can retrieve a > controller service without issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-558) Move PayloadSerializer in preparation for Coap
[
https://issues.apache.org/jira/browse/MINIFICPP-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688414#comment-16688414
]
ASF GitHub Bot commented on MINIFICPP-558:
--
Github user arpadboda commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/437#discussion_r233941448
--- Diff: extensions/coap/controllerservice/CoapConnector.cpp ---
@@ -0,0 +1,189 @@
+/**
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "CoapConnector.h"
+#include
+#include
+#include
+#include
+#include
+#include "core/Property.h"
+#include "CoapConnector.h"
+#include "io/validation.h"
+#include "properties/Configure.h"
+
+namespace org {
+namespace apache {
+namespace nifi {
+namespace minifi {
+namespace controllers {
+
+static core::Property RemoteServer;
+static core::Property Port;
+static core::Property MaxQueueSize;
+
+core::Property
CoapConnectorService::RemoteServer(core::PropertyBuilder::createProperty("Remote
Server")->withDescription("Remote CoAP server")->isRequired(true)->build());
+core::Property
CoapConnectorService::Port(core::PropertyBuilder::createProperty("Remote
Port")->withDescription("Remote CoAP server port")->isRequired(true)->build());
+core::Property
CoapConnectorService::MaxQueueSize(core::PropertyBuilder::createProperty("Max
Queue Size")->withDescription("Max queue size for received data
")->isRequired(true)->build());
+
+void CoapConnectorService::initialize() {
+ if (initialized_)
+return;
+
+ callback_pointers ptrs;
+ ptrs.data_received = receiveMessage;
+ ptrs.received_error = receiveError;
+ init_coap_api(this, &ptrs);
+
+ std::lock_guard lock(initialization_mutex_);
+
+ ControllerService::initialize();
+
+ initializeProperties();
+
+ initialized_ = true;
+}
+
+void CoapConnectorService::onEnable() {
+ std::string port_str;
+ if (getProperty(RemoteServer.getName(), host_) && !host_.empty() &&
getProperty(Port.getName(), port_str) && !port_str.empty()) {
+core::Property::StringToInt(port_str, port_);
+ } else {
+// this is the case where we aren't being used in the context of a
single controller service.
+if (configuration_->get("nifi.c2.agent.coap.host", host_) &&
configuration_->get("nifi.c2.agent.coap.port", port_str)) {
+ core::Property::StringToInt(port_str, port_);
+}
+
+ }
+}
+
+CoapConnectorService::CoAPMessage
CoapConnectorService::sendPayload(uint8_t type, const std::string endpoint,
unsigned char *payload, size_t size) {
+ struct coap_context_t* ctx=NULL;
+ struct coap_session_t* session=NULL;
+
+ coap_address_t dst_addr, src_addr;
+ coap_uri_t uri;
+ uri.host.s = reinterpret_cast(const_cast(host_.c_str()));
+ uri.host.length = host_.size();
+ uri.path.s = reinterpret_cast(const_cast(endpoint.c_str()));
+ uri.path.length = endpoint.size();
+ uri.port = port_;
+
+ fd_set readfds;
+ coap_pdu_t* request;
+ unsigned char get_method = 1;
+
+ int res = resolve_address(&uri.host, &dst_addr.addr.sa);
+ if (res < 0) {
+return CoAPMessage();
+ }
+
+ dst_addr.size = res;
+ dst_addr.addr.sin.sin_port = htons(uri.port);
+
+ void *addrptr = NULL;
+ char port_str[NI_MAXSERV] = "0";
+ char node_str[NI_MAXHOST] = "";
+ switch (dst_addr.addr.sa.sa_family) {
+case AF_INET:
+ addrptr = &dst_addr.addr.sin.sin_addr;
+
+ /* create context for IPv4 */
+ if (!create_session(&ctx, &session, node_str[0] == 0 ? "0.0.0.0" :
node_str, port_str, &dst_addr)) {
+break;
+ } else {
+return CoAPMessage();
+ }
+case AF_INET6:
+ addrptr = &dst_addr.addr.sin6.sin6_addr;
+
+ /* create context for IPv6 */
+ if (!create_session(
[GitHub] nifi-minifi-cpp pull request #437: MINIFICPP-558: initial provisioning for C...
Github user arpadboda commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/437#discussion_r233941448
--- Diff: extensions/coap/controllerservice/CoapConnector.cpp ---
@@ -0,0 +1,189 @@
+/**
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "CoapConnector.h"
+#include
+#include
+#include
+#include
+#include
+#include "core/Property.h"
+#include "CoapConnector.h"
+#include "io/validation.h"
+#include "properties/Configure.h"
+
+namespace org {
+namespace apache {
+namespace nifi {
+namespace minifi {
+namespace controllers {
+
+static core::Property RemoteServer;
+static core::Property Port;
+static core::Property MaxQueueSize;
+
+core::Property
CoapConnectorService::RemoteServer(core::PropertyBuilder::createProperty("Remote
Server")->withDescription("Remote CoAP server")->isRequired(true)->build());
+core::Property
CoapConnectorService::Port(core::PropertyBuilder::createProperty("Remote
Port")->withDescription("Remote CoAP server port")->isRequired(true)->build());
+core::Property
CoapConnectorService::MaxQueueSize(core::PropertyBuilder::createProperty("Max
Queue Size")->withDescription("Max queue size for received data
")->isRequired(true)->build());
+
+void CoapConnectorService::initialize() {
+ if (initialized_)
+return;
+
+ callback_pointers ptrs;
+ ptrs.data_received = receiveMessage;
+ ptrs.received_error = receiveError;
+ init_coap_api(this, &ptrs);
+
+ std::lock_guard lock(initialization_mutex_);
+
+ ControllerService::initialize();
+
+ initializeProperties();
+
+ initialized_ = true;
+}
+
+void CoapConnectorService::onEnable() {
+ std::string port_str;
+ if (getProperty(RemoteServer.getName(), host_) && !host_.empty() &&
getProperty(Port.getName(), port_str) && !port_str.empty()) {
+core::Property::StringToInt(port_str, port_);
+ } else {
+// this is the case where we aren't being used in the context of a
single controller service.
+if (configuration_->get("nifi.c2.agent.coap.host", host_) &&
configuration_->get("nifi.c2.agent.coap.port", port_str)) {
+ core::Property::StringToInt(port_str, port_);
+}
+
+ }
+}
+
+CoapConnectorService::CoAPMessage
CoapConnectorService::sendPayload(uint8_t type, const std::string endpoint,
unsigned char *payload, size_t size) {
+ struct coap_context_t* ctx=NULL;
+ struct coap_session_t* session=NULL;
+
+ coap_address_t dst_addr, src_addr;
+ coap_uri_t uri;
+ uri.host.s = reinterpret_cast(const_cast(host_.c_str()));
+ uri.host.length = host_.size();
+ uri.path.s = reinterpret_cast(const_cast(endpoint.c_str()));
+ uri.path.length = endpoint.size();
+ uri.port = port_;
+
+ fd_set readfds;
+ coap_pdu_t* request;
+ unsigned char get_method = 1;
+
+ int res = resolve_address(&uri.host, &dst_addr.addr.sa);
+ if (res < 0) {
+return CoAPMessage();
+ }
+
+ dst_addr.size = res;
+ dst_addr.addr.sin.sin_port = htons(uri.port);
+
+ void *addrptr = NULL;
+ char port_str[NI_MAXSERV] = "0";
+ char node_str[NI_MAXHOST] = "";
+ switch (dst_addr.addr.sa.sa_family) {
+case AF_INET:
+ addrptr = &dst_addr.addr.sin.sin_addr;
+
+ /* create context for IPv4 */
+ if (!create_session(&ctx, &session, node_str[0] == 0 ? "0.0.0.0" :
node_str, port_str, &dst_addr)) {
+break;
+ } else {
+return CoAPMessage();
+ }
+case AF_INET6:
+ addrptr = &dst_addr.addr.sin6.sin6_addr;
+
+ /* create context for IPv6 */
+ if (!create_session(&ctx, &session, node_str[0] == 0 ? "::" :
node_str, port_str, &dst_addr)) {
+break;
+ } else {
+return CoAPMessage();
+ }
+default:
+ ;
+ }
+
+ // we want to register handlers in the event tha
[jira] [Commented] (NIFI-5822) ControllerServices not available during @OnScheduled
[ https://issues.apache.org/jira/browse/NIFI-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688398#comment-16688398 ] ASF GitHub Bot commented on NIFI-5822: -- GitHub user markap14 opened a pull request: https://github.com/apache/nifi/pull/3171 NIFI-5822: Ensure that we don't call FlowController.getControllerServ… …iceProvider() before the ControllerServiceProvider has been initialized Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] 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)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/markap14/nifi NIFI-5822 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3171.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3171 commit 6aaf3ed25e17523071b3d4e2dd400a43685f873a Author: Mark Payne Date: 2018-11-15T17:33:03Z NIFI-5822: Ensure that we don't call FlowController.getControllerServiceProvider() before the ControllerServiceProvider has been initialized > ControllerServices not available during @OnScheduled > > > Key: NIFI-5822 > URL: https://issues.apache.org/jira/browse/NIFI-5822 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Peter Wicks >Priority: Blocker > Fix For: 1.9.0 > > > If a processor tries to load a ControllerService during `@OnScheduled`, then > `context.getControllerService` contains a null reference to > `controllerServiceProvider`. I traced this back to > `StandardProcessScheduler.startProcessor`, and the reference to > `controllerServiceProvider` is also `null` here. `ExecuteSQL` acquires it's > connection during `@OnScheduled`. > But once we reach `onTrigger`, everything is fine and you can retrieve a > controller service without issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5822) ControllerServices not available during @OnScheduled
[ https://issues.apache.org/jira/browse/NIFI-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5822: - Assignee: Mark Payne Affects Version/s: 1.8.0 Status: Patch Available (was: Open) > ControllerServices not available during @OnScheduled > > > Key: NIFI-5822 > URL: https://issues.apache.org/jira/browse/NIFI-5822 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Peter Wicks >Assignee: Mark Payne >Priority: Blocker > Fix For: 1.9.0 > > > If a processor tries to load a ControllerService during `@OnScheduled`, then > `context.getControllerService` contains a null reference to > `controllerServiceProvider`. I traced this back to > `StandardProcessScheduler.startProcessor`, and the reference to > `controllerServiceProvider` is also `null` here. `ExecuteSQL` acquires it's > connection during `@OnScheduled`. > But once we reach `onTrigger`, everything is fine and you can retrieve a > controller service without issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #3171: NIFI-5822: Ensure that we don't call FlowController...
GitHub user markap14 opened a pull request: https://github.com/apache/nifi/pull/3171 NIFI-5822: Ensure that we don't call FlowController.getControllerServ⦠â¦iceProvider() before the ControllerServiceProvider has been initialized Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] 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)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/markap14/nifi NIFI-5822 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3171.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3171 commit 6aaf3ed25e17523071b3d4e2dd400a43685f873a Author: Mark Payne Date: 2018-11-15T17:33:03Z NIFI-5822: Ensure that we don't call FlowController.getControllerServiceProvider() before the ControllerServiceProvider has been initialized ---
[jira] [Updated] (NIFI-5822) ControllerServices not available during @OnScheduled
[ https://issues.apache.org/jira/browse/NIFI-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5822: - Fix Version/s: 1.9.0 > ControllerServices not available during @OnScheduled > > > Key: NIFI-5822 > URL: https://issues.apache.org/jira/browse/NIFI-5822 > Project: Apache NiFi > Issue Type: Bug >Reporter: Peter Wicks >Priority: Blocker > Fix For: 1.9.0 > > > If a processor tries to load a ControllerService during `@OnScheduled`, then > `context.getControllerService` contains a null reference to > `controllerServiceProvider`. I traced this back to > `StandardProcessScheduler.startProcessor`, and the reference to > `controllerServiceProvider` is also `null` here. `ExecuteSQL` acquires it's > connection during `@OnScheduled`. > But once we reach `onTrigger`, everything is fine and you can retrieve a > controller service without issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MINIFICPP-644) C API: add support to register terminate handler
[ https://issues.apache.org/jira/browse/MINIFICPP-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpad Boda resolved MINIFICPP-644. -- Resolution: Fixed > C API: add support to register terminate handler > > > Key: MINIFICPP-644 > URL: https://issues.apache.org/jira/browse/MINIFICPP-644 > Project: NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Minor > Fix For: 0.6.0 > > > As MiNiFi is internally based on C++, excetions may occur, those cannot be > handled in C. > It would be useful to provide the possibility to register a callbackback to > execute in such cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5822) ControllerServices not available during @OnScheduled
[ https://issues.apache.org/jira/browse/NIFI-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5822: - Priority: Blocker (was: Major) > ControllerServices not available during @OnScheduled > > > Key: NIFI-5822 > URL: https://issues.apache.org/jira/browse/NIFI-5822 > Project: Apache NiFi > Issue Type: Bug >Reporter: Peter Wicks >Priority: Blocker > Fix For: 1.9.0 > > > If a processor tries to load a ControllerService during `@OnScheduled`, then > `context.getControllerService` contains a null reference to > `controllerServiceProvider`. I traced this back to > `StandardProcessScheduler.startProcessor`, and the reference to > `controllerServiceProvider` is also `null` here. `ExecuteSQL` acquires it's > connection during `@OnScheduled`. > But once we reach `onTrigger`, everything is fine and you can retrieve a > controller service without issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-5822) ControllerServices not available during @OnScheduled
Peter Wicks created NIFI-5822: - Summary: ControllerServices not available during @OnScheduled Key: NIFI-5822 URL: https://issues.apache.org/jira/browse/NIFI-5822 Project: Apache NiFi Issue Type: Bug Reporter: Peter Wicks If a processor tries to load a ControllerService during `@OnScheduled`, then `context.getControllerService` contains a null reference to `controllerServiceProvider`. I traced this back to `StandardProcessScheduler.startProcessor`, and the reference to `controllerServiceProvider` is also `null` here. `ExecuteSQL` acquires it's connection during `@OnScheduled`. But once we reach `onTrigger`, everything is fine and you can retrieve a controller service without issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[ https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688322#comment-16688322 ] ASF GitHub Bot commented on MINIFICPP-667: -- Github user arpadboda commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233919866 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- Okay, fine for me. 👍 Happy to approve as it gets moved. > Create Structural definitions for moving away from C++ classes > -- > > Key: MINIFICPP-667 > URL: https://issues.apache.org/jira/browse/MINIFICPP-667 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: nanofi >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > > Create Structural definitions for moving away from C++ classes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user arpadboda commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233919866 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- Okay, fine for me. ð Happy to approve as it gets moved. ---
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[ https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688321#comment-16688321 ] ASF GitHub Bot commented on MINIFICPP-667: -- Github user phrocker commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233919353 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- sorry CMAKE_SOURCE_DIR. It can go there and should. I think I updated the NOTICE and we direct people to the root source thirdparty, so we can probably just use that. No reason to create levels of thirdparty source dirs yet. > Create Structural definitions for moving away from C++ classes > -- > > Key: MINIFICPP-667 > URL: https://issues.apache.org/jira/browse/MINIFICPP-667 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: nanofi >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > > Create Structural definitions for moving away from C++ classes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user phrocker commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233919353 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- sorry CMAKE_SOURCE_DIR. It can go there and should. I think I updated the NOTICE and we direct people to the root source thirdparty, so we can probably just use that. No reason to create levels of thirdparty source dirs yet. ---
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[ https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688299#comment-16688299 ] ASF GitHub Bot commented on MINIFICPP-667: -- Github user phrocker commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233913016 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- Ah thanks for calling this out. I have a more recent commit with a lot of changes, but didn't move this yet and probably would have forgotten. > Create Structural definitions for moving away from C++ classes > -- > > Key: MINIFICPP-667 > URL: https://issues.apache.org/jira/browse/MINIFICPP-667 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: nanofi >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > > Create Structural definitions for moving away from C++ classes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[
https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688286#comment-16688286
]
ASF GitHub Bot commented on MINIFICPP-667:
--
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233910857
--- Diff: nanofi/include/core/cstructs.h ---
@@ -76,6 +80,12 @@ typedef struct {
* ##
*/
+typedef struct{
+ char *key;
--- End diff --
The example code I took this from had this as char*, not sure we can do
this. I'd have to look at the library.
> Create Structural definitions for moving away from C++ classes
> --
>
> Key: MINIFICPP-667
> URL: https://issues.apache.org/jira/browse/MINIFICPP-667
> Project: NiFi MiNiFi C++
> Issue Type: Improvement
>Affects Versions: nanofi
>Reporter: Mr TheSegfault
>Assignee: Mr TheSegfault
>Priority: Major
> Fix For: 0.6.0
>
>
> Create Structural definitions for moving away from C++ classes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[ https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688302#comment-16688302 ] ASF GitHub Bot commented on MINIFICPP-667: -- Github user arpadboda commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233913935 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- Not yet in nanofi :) Guess this library is not going to be used in the C++ part. > Create Structural definitions for moving away from C++ classes > -- > > Key: MINIFICPP-667 > URL: https://issues.apache.org/jira/browse/MINIFICPP-667 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: nanofi >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > > Create Structural definitions for moving away from C++ classes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user arpadboda commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233913935 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- Not yet in nanofi :) Guess this library is not going to be used in the C++ part. ---
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[ https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688300#comment-16688300 ] ASF GitHub Bot commented on MINIFICPP-667: -- Github user phrocker commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233913139 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- We have a third party dir in the main directory, which is where this should go. > Create Structural definitions for moving away from C++ classes > -- > > Key: MINIFICPP-667 > URL: https://issues.apache.org/jira/browse/MINIFICPP-667 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: nanofi >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > > Create Structural definitions for moving away from C++ classes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user phrocker commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233913139 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- We have a third party dir in the main directory, which is where this should go. ---
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user phrocker commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233913016 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- Ah thanks for calling this out. I have a more recent commit with a lot of changes, but didn't move this yet and probably would have forgotten. ---
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[
https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688292#comment-16688292
]
ASF GitHub Bot commented on MINIFICPP-667:
--
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233911949
--- Diff: nanofi/include/core/cstructs.h ---
@@ -76,6 +80,12 @@ typedef struct {
* ##
*/
+typedef struct{
+ char *key;
--- End diff --
I'll add that I'm not against this, but the code pointer's management was a
little different. Again, I'll take a look at if this makes sense. core will be
things that don't reflect a user experience though. That is code that's not
part of our public API.
> Create Structural definitions for moving away from C++ classes
> --
>
> Key: MINIFICPP-667
> URL: https://issues.apache.org/jira/browse/MINIFICPP-667
> Project: NiFi MiNiFi C++
> Issue Type: Improvement
>Affects Versions: nanofi
>Reporter: Mr TheSegfault
>Assignee: Mr TheSegfault
>Priority: Major
> Fix For: 0.6.0
>
>
> Create Structural definitions for moving away from C++ classes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233911949
--- Diff: nanofi/include/core/cstructs.h ---
@@ -76,6 +80,12 @@ typedef struct {
* ##
*/
+typedef struct{
+ char *key;
--- End diff --
I'll add that I'm not against this, but the code pointer's management was a
little different. Again, I'll take a look at if this makes sense. core will be
things that don't reflect a user experience though. That is code that's not
part of our public API.
---
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[
https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688290#comment-16688290
]
ASF GitHub Bot commented on MINIFICPP-667:
--
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233911441
--- Diff: nanofi/src/api/nanofi.cpp ---
@@ -72,19 +41,17 @@ class DirectoryConfiguration {
* nifi_instance *create_instance(nifi_port const *port) {
*/
nifi_instance *create_instance(const char *url, nifi_port *port) {
- // make sure that we have a thread safe way of initializing the content
directory
- DirectoryConfiguration::initialize();
-
- // need reinterpret cast until we move to C for this module.
- nifi_instance *instance =
reinterpret_cast(malloc(sizeof(nifi_instance)));
+// need reinterpret cast until we move to C for this module.
+ nifi_instance *instance =
(nifi_instance*)(malloc(sizeof(nifi_instance)));
/**
* This API will gradually move away from C++, hence malloc is used for
nifi_instance
* Since minifi::Instance is currently being used, then we need to use
new in that case.
*/
- instance->instance_ptr = new minifi::Instance(url, port->port_id);
+ instance->instance_ptr = create_cxx_instance(url,port);
// may have to translate port ID here in the future
// need reinterpret cast until we move to C for this module.
- instance->port.port_id =
reinterpret_cast(malloc(strlen(port->port_id) + 1));
+ instance->port.port_id = (char*)(malloc(strlen(port->port_id) + 1));
--- End diff --
Yes. We won't be able to use the C++ linter on C files. I haven't pushed
the recent commit, but I'm moving toward renaming this to nanofi.c
> Create Structural definitions for moving away from C++ classes
> --
>
> Key: MINIFICPP-667
> URL: https://issues.apache.org/jira/browse/MINIFICPP-667
> Project: NiFi MiNiFi C++
> Issue Type: Improvement
>Affects Versions: nanofi
>Reporter: Mr TheSegfault
>Assignee: Mr TheSegfault
>Priority: Major
> Fix For: 0.6.0
>
>
> Create Structural definitions for moving away from C++ classes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[
https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688287#comment-16688287
]
ASF GitHub Bot commented on MINIFICPP-667:
--
Github user arpadboda commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233910986
--- Diff: nanofi/src/api/nanofi.cpp ---
@@ -72,19 +41,17 @@ class DirectoryConfiguration {
* nifi_instance *create_instance(nifi_port const *port) {
*/
nifi_instance *create_instance(const char *url, nifi_port *port) {
- // make sure that we have a thread safe way of initializing the content
directory
- DirectoryConfiguration::initialize();
-
- // need reinterpret cast until we move to C for this module.
- nifi_instance *instance =
reinterpret_cast(malloc(sizeof(nifi_instance)));
+// need reinterpret cast until we move to C for this module.
+ nifi_instance *instance =
(nifi_instance*)(malloc(sizeof(nifi_instance)));
/**
* This API will gradually move away from C++, hence malloc is used for
nifi_instance
* Since minifi::Instance is currently being used, then we need to use
new in that case.
*/
- instance->instance_ptr = new minifi::Instance(url, port->port_id);
+ instance->instance_ptr = create_cxx_instance(url,port);
// may have to translate port ID here in the future
// need reinterpret cast until we move to C for this module.
- instance->port.port_id =
reinterpret_cast(malloc(strlen(port->port_id) + 1));
+ instance->port.port_id = (char*)(malloc(strlen(port->port_id) + 1));
--- End diff --
I expect this to fail linter, do we already have nanofi out of range of
that?
> Create Structural definitions for moving away from C++ classes
> --
>
> Key: MINIFICPP-667
> URL: https://issues.apache.org/jira/browse/MINIFICPP-667
> Project: NiFi MiNiFi C++
> Issue Type: Improvement
>Affects Versions: nanofi
>Reporter: Mr TheSegfault
>Assignee: Mr TheSegfault
>Priority: Major
> Fix For: 0.6.0
>
>
> Create Structural definitions for moving away from C++ classes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233911441
--- Diff: nanofi/src/api/nanofi.cpp ---
@@ -72,19 +41,17 @@ class DirectoryConfiguration {
* nifi_instance *create_instance(nifi_port const *port) {
*/
nifi_instance *create_instance(const char *url, nifi_port *port) {
- // make sure that we have a thread safe way of initializing the content
directory
- DirectoryConfiguration::initialize();
-
- // need reinterpret cast until we move to C for this module.
- nifi_instance *instance =
reinterpret_cast(malloc(sizeof(nifi_instance)));
+// need reinterpret cast until we move to C for this module.
+ nifi_instance *instance =
(nifi_instance*)(malloc(sizeof(nifi_instance)));
/**
* This API will gradually move away from C++, hence malloc is used for
nifi_instance
* Since minifi::Instance is currently being used, then we need to use
new in that case.
*/
- instance->instance_ptr = new minifi::Instance(url, port->port_id);
+ instance->instance_ptr = create_cxx_instance(url,port);
// may have to translate port ID here in the future
// need reinterpret cast until we move to C for this module.
- instance->port.port_id =
reinterpret_cast(malloc(strlen(port->port_id) + 1));
+ instance->port.port_id = (char*)(malloc(strlen(port->port_id) + 1));
--- End diff --
Yes. We won't be able to use the C++ linter on C files. I haven't pushed
the recent commit, but I'm moving toward renaming this to nanofi.c
---
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user arpadboda commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233910986
--- Diff: nanofi/src/api/nanofi.cpp ---
@@ -72,19 +41,17 @@ class DirectoryConfiguration {
* nifi_instance *create_instance(nifi_port const *port) {
*/
nifi_instance *create_instance(const char *url, nifi_port *port) {
- // make sure that we have a thread safe way of initializing the content
directory
- DirectoryConfiguration::initialize();
-
- // need reinterpret cast until we move to C for this module.
- nifi_instance *instance =
reinterpret_cast(malloc(sizeof(nifi_instance)));
+// need reinterpret cast until we move to C for this module.
+ nifi_instance *instance =
(nifi_instance*)(malloc(sizeof(nifi_instance)));
/**
* This API will gradually move away from C++, hence malloc is used for
nifi_instance
* Since minifi::Instance is currently being used, then we need to use
new in that case.
*/
- instance->instance_ptr = new minifi::Instance(url, port->port_id);
+ instance->instance_ptr = create_cxx_instance(url,port);
// may have to translate port ID here in the future
// need reinterpret cast until we move to C for this module.
- instance->port.port_id =
reinterpret_cast(malloc(strlen(port->port_id) + 1));
+ instance->port.port_id = (char*)(malloc(strlen(port->port_id) + 1));
--- End diff --
I expect this to fail linter, do we already have nanofi out of range of
that?
---
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233910857
--- Diff: nanofi/include/core/cstructs.h ---
@@ -76,6 +80,12 @@ typedef struct {
* ##
*/
+typedef struct{
+ char *key;
--- End diff --
The example code I took this from had this as char*, not sure we can do
this. I'd have to look at the library.
---
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[
https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688284#comment-16688284
]
ASF GitHub Bot commented on MINIFICPP-667:
--
Github user arpadboda commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233910142
--- Diff: nanofi/include/core/cstructs.h ---
@@ -76,6 +80,12 @@ typedef struct {
* ##
*/
+typedef struct{
+ char *key;
--- End diff --
Can we have this as const char *?
A bit better user experience if you can write something like
```
key_value.key = "some string"
```
> Create Structural definitions for moving away from C++ classes
> --
>
> Key: MINIFICPP-667
> URL: https://issues.apache.org/jira/browse/MINIFICPP-667
> Project: NiFi MiNiFi C++
> Issue Type: Improvement
>Affects Versions: nanofi
>Reporter: Mr TheSegfault
>Assignee: Mr TheSegfault
>Priority: Major
> Fix For: 0.6.0
>
>
> Create Structural definitions for moving away from C++ classes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user arpadboda commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233910142
--- Diff: nanofi/include/core/cstructs.h ---
@@ -76,6 +80,12 @@ typedef struct {
* ##
*/
+typedef struct{
+ char *key;
--- End diff --
Can we have this as const char *?
A bit better user experience if you can write something like
```
key_value.key = "some string"
```
---
[jira] [Commented] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[ https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688282#comment-16688282 ] ASF GitHub Bot commented on MINIFICPP-667: -- Github user arpadboda commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233909297 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- I would prefer to place this file somewhere else, as it's not really part of core, but a 3rd party library we use. Could you add to a folder that implies this? > Create Structural definitions for moving away from C++ classes > -- > > Key: MINIFICPP-667 > URL: https://issues.apache.org/jira/browse/MINIFICPP-667 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: nanofi >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > > Create Structural definitions for moving away from C++ classes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #436: MINIFICPP-667: Add structural definitions...
Github user arpadboda commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/436#discussion_r233909297 --- Diff: nanofi/include/core/utlist.h --- @@ -0,0 +1,1073 @@ +/* --- End diff -- I would prefer to place this file somewhere else, as it's not really part of core, but a 3rd party library we use. Could you add to a folder that implies this? ---
[jira] [Commented] (NIFIREG-211) Add extension bundles as a type of versioned item
[ https://issues.apache.org/jira/browse/NIFIREG-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688258#comment-16688258 ] Otto Fowler commented on NIFIREG-211: - Maybe that stuff would go into the pom then, and the pom info would populate the metadata. > Add extension bundles as a type of versioned item > - > > Key: NIFIREG-211 > URL: https://issues.apache.org/jira/browse/NIFIREG-211 > Project: NiFi Registry > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 0.4.0 > > > This ticket is to capture the work for adding extension bundles to NiFi > Registry. > This work may require several follow on tickets, but at a high-level will > include some of the following: > - Add a new type of item called an extension bundle, where each bundle > can contain one ore extensions or APIs > > - Support bundles for traditional NiFi (aka NARs) and also bundles for > MiNiFi CPP > > - Ability to upload the binary artifact for a bundle and extract the > metadata about the bundle, and metadata about the extensions contained > in the bundle (more on this later) > > - Provide a pluggable storage provider for saving the content of each > extension bundle so that we can have different implementations like > local fileysystem, S3, and other object stores > > - Provide a REST API for listing and retrieving available bundles, > integrate this into the registry Java client and NiFi CLI > - Security considerations such as checksums and cryptographic signatures for > bundles -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-211) Add extension bundles as a type of versioned item
[ https://issues.apache.org/jira/browse/NIFIREG-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688251#comment-16688251 ] Bryan Bende commented on NIFIREG-211: - I think so... I was thinking that there would be a way to create a bundle entity in the registry with a link to the external content, not sure on the terminology yet, but kind of like "managed vs unmanaged" or "internal vs external". The main use cause I was thinking of was when we do apache releases, all of the NARs are already in Maven central, so it might be nice if someone could stand up a registry instance somehow pointing at those NARs. The challenge though is that in order to create that entity, the client would need to supply all of the metadata that is normally extracted directly from the bundle. For example, if someone uploads a NAR we are going to extract all the info from the manifest like group/artifact/version, the dependency group/artifact/version, and a new component descriptor that is going to be added with all the metadata about the components in the bundle... so without having the actual NAR, then we need a way to obtain all of this information. > Add extension bundles as a type of versioned item > - > > Key: NIFIREG-211 > URL: https://issues.apache.org/jira/browse/NIFIREG-211 > Project: NiFi Registry > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 0.4.0 > > > This ticket is to capture the work for adding extension bundles to NiFi > Registry. > This work may require several follow on tickets, but at a high-level will > include some of the following: > - Add a new type of item called an extension bundle, where each bundle > can contain one ore extensions or APIs > > - Support bundles for traditional NiFi (aka NARs) and also bundles for > MiNiFi CPP > > - Ability to upload the binary artifact for a bundle and extract the > metadata about the bundle, and metadata about the extensions contained > in the bundle (more on this later) > > - Provide a pluggable storage provider for saving the content of each > extension bundle so that we can have different implementations like > local fileysystem, S3, and other object stores > > - Provide a REST API for listing and retrieving available bundles, > integrate this into the registry Java client and NiFi CLI > - Security considerations such as checksums and cryptographic signatures for > bundles -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (NIFIREG-211) Add extension bundles as a type of versioned item
[ https://issues.apache.org/jira/browse/NIFIREG-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688251#comment-16688251 ] Bryan Bende edited comment on NIFIREG-211 at 11/15/18 3:50 PM: --- I think so... I was thinking that there would be a way to create a bundle entity in the registry with a link to the external content, not sure on the terminology yet, but kind of like "managed vs unmanaged" or "internal vs external". The main use case I was thinking of was when we do apache releases, all of the NARs are already in Maven central, so it might be nice if someone could stand up a registry instance somehow pointing at those NARs. The challenge though is that in order to create that entity, the client would need to supply all of the metadata that is normally extracted directly from the bundle. For example, if someone uploads a NAR we are going to extract all the info from the manifest like group/artifact/version, the dependency group/artifact/version, and a new component descriptor that is going to be added with all the metadata about the components in the bundle... so without having the actual NAR, then we need a way to obtain all of this information. was (Author: bende): I think so... I was thinking that there would be a way to create a bundle entity in the registry with a link to the external content, not sure on the terminology yet, but kind of like "managed vs unmanaged" or "internal vs external". The main use cause I was thinking of was when we do apache releases, all of the NARs are already in Maven central, so it might be nice if someone could stand up a registry instance somehow pointing at those NARs. The challenge though is that in order to create that entity, the client would need to supply all of the metadata that is normally extracted directly from the bundle. For example, if someone uploads a NAR we are going to extract all the info from the manifest like group/artifact/version, the dependency group/artifact/version, and a new component descriptor that is going to be added with all the metadata about the components in the bundle... so without having the actual NAR, then we need a way to obtain all of this information. > Add extension bundles as a type of versioned item > - > > Key: NIFIREG-211 > URL: https://issues.apache.org/jira/browse/NIFIREG-211 > Project: NiFi Registry > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 0.4.0 > > > This ticket is to capture the work for adding extension bundles to NiFi > Registry. > This work may require several follow on tickets, but at a high-level will > include some of the following: > - Add a new type of item called an extension bundle, where each bundle > can contain one ore extensions or APIs > > - Support bundles for traditional NiFi (aka NARs) and also bundles for > MiNiFi CPP > > - Ability to upload the binary artifact for a bundle and extract the > metadata about the bundle, and metadata about the extensions contained > in the bundle (more on this later) > > - Provide a pluggable storage provider for saving the content of each > extension bundle so that we can have different implementations like > local fileysystem, S3, and other object stores > > - Provide a REST API for listing and retrieving available bundles, > integrate this into the registry Java client and NiFi CLI > - Security considerations such as checksums and cryptographic signatures for > bundles -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5788) Introduce batch size limit in PutDatabaseRecord processor
[ https://issues.apache.org/jira/browse/NIFI-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688248#comment-16688248 ] ASF GitHub Bot commented on NIFI-5788: -- Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/3128 +1 LGTM, tested with various batch sizes and ran unit tests. Thanks for this improvment! Merged to master > Introduce batch size limit in PutDatabaseRecord processor > - > > Key: NIFI-5788 > URL: https://issues.apache.org/jira/browse/NIFI-5788 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework > Environment: Teradata DB >Reporter: Vadim >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > > Certain JDBC drivers do not support unlimited batch size in INSERT/UPDATE > prepared SQL statements. Specifically, Teradata JDBC driver > ([https://downloads.teradata.com/download/connectivity/jdbc-driver)] would > fail SQL statement when the batch overflows the internal limits. > Dividing data into smaller chunks before the PutDatabaseRecord is applied can > work around the issue in certain scenarios, but generally, this solution is > not perfect because the SQL statements would be executed in different > transaction contexts and data integrity would not be preserved. > The solution suggests the following: > * introduce a new optional parameter in *PutDatabaseRecord* processor, > *max_batch_size* which defines the maximum batch size in INSERT/UPDATE > statement; the default value zero (INFINITY) preserves the old behavior > * divide the input into batches of the specified size and invoke > PreparedStatement.executeBatch() for each batch > Pull request: [https://github.com/apache/nifi/pull/3128] > > [EDIT] Changed batch_size to max_batch_size. The default value would be zero > (INFINITY) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5788) Introduce batch size limit in PutDatabaseRecord processor
[ https://issues.apache.org/jira/browse/NIFI-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-5788: --- Fix Version/s: 1.9.0 > Introduce batch size limit in PutDatabaseRecord processor > - > > Key: NIFI-5788 > URL: https://issues.apache.org/jira/browse/NIFI-5788 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework > Environment: Teradata DB >Reporter: Vadim >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > > Certain JDBC drivers do not support unlimited batch size in INSERT/UPDATE > prepared SQL statements. Specifically, Teradata JDBC driver > ([https://downloads.teradata.com/download/connectivity/jdbc-driver)] would > fail SQL statement when the batch overflows the internal limits. > Dividing data into smaller chunks before the PutDatabaseRecord is applied can > work around the issue in certain scenarios, but generally, this solution is > not perfect because the SQL statements would be executed in different > transaction contexts and data integrity would not be preserved. > The solution suggests the following: > * introduce a new optional parameter in *PutDatabaseRecord* processor, > *max_batch_size* which defines the maximum batch size in INSERT/UPDATE > statement; the default value zero (INFINITY) preserves the old behavior > * divide the input into batches of the specified size and invoke > PreparedStatement.executeBatch() for each batch > Pull request: [https://github.com/apache/nifi/pull/3128] > > [EDIT] Changed batch_size to max_batch_size. The default value would be zero > (INFINITY) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5788) Introduce batch size limit in PutDatabaseRecord processor
[ https://issues.apache.org/jira/browse/NIFI-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-5788: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Introduce batch size limit in PutDatabaseRecord processor > - > > Key: NIFI-5788 > URL: https://issues.apache.org/jira/browse/NIFI-5788 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework > Environment: Teradata DB >Reporter: Vadim >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > > Certain JDBC drivers do not support unlimited batch size in INSERT/UPDATE > prepared SQL statements. Specifically, Teradata JDBC driver > ([https://downloads.teradata.com/download/connectivity/jdbc-driver)] would > fail SQL statement when the batch overflows the internal limits. > Dividing data into smaller chunks before the PutDatabaseRecord is applied can > work around the issue in certain scenarios, but generally, this solution is > not perfect because the SQL statements would be executed in different > transaction contexts and data integrity would not be preserved. > The solution suggests the following: > * introduce a new optional parameter in *PutDatabaseRecord* processor, > *max_batch_size* which defines the maximum batch size in INSERT/UPDATE > statement; the default value zero (INFINITY) preserves the old behavior > * divide the input into batches of the specified size and invoke > PreparedStatement.executeBatch() for each batch > Pull request: [https://github.com/apache/nifi/pull/3128] > > [EDIT] Changed batch_size to max_batch_size. The default value would be zero > (INFINITY) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #3128: NIFI-5788: Introduce batch size limit in PutDatabaseRecord...
Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/3128 +1 LGTM, tested with various batch sizes and ran unit tests. Thanks for this improvment! Merged to master ---
[jira] [Commented] (NIFI-5788) Introduce batch size limit in PutDatabaseRecord processor
[ https://issues.apache.org/jira/browse/NIFI-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688240#comment-16688240 ] ASF subversion and git services commented on NIFI-5788: --- Commit d319a3ef2f14317f29a1be5a189bc34f8b3fdbd6 in nifi's branch refs/heads/master from vadimar [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=d319a3e ] NIFI-5788: Introduce batch size limit in PutDatabaseRecord processor NIFI-5788: Introduce batch size limit in PutDatabaseRecord processor Renamed 'batch size' to 'Maximum Batch Size'. Changed default value of max_batch_size to zero (INFINITE) Fixed parameter validation. Added unit tests Signed-off-by: Matthew Burgess This closes #3128 > Introduce batch size limit in PutDatabaseRecord processor > - > > Key: NIFI-5788 > URL: https://issues.apache.org/jira/browse/NIFI-5788 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework > Environment: Teradata DB >Reporter: Vadim >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > > Certain JDBC drivers do not support unlimited batch size in INSERT/UPDATE > prepared SQL statements. Specifically, Teradata JDBC driver > ([https://downloads.teradata.com/download/connectivity/jdbc-driver)] would > fail SQL statement when the batch overflows the internal limits. > Dividing data into smaller chunks before the PutDatabaseRecord is applied can > work around the issue in certain scenarios, but generally, this solution is > not perfect because the SQL statements would be executed in different > transaction contexts and data integrity would not be preserved. > The solution suggests the following: > * introduce a new optional parameter in *PutDatabaseRecord* processor, > *max_batch_size* which defines the maximum batch size in INSERT/UPDATE > statement; the default value zero (INFINITY) preserves the old behavior > * divide the input into batches of the specified size and invoke > PreparedStatement.executeBatch() for each batch > Pull request: [https://github.com/apache/nifi/pull/3128] > > [EDIT] Changed batch_size to max_batch_size. The default value would be zero > (INFINITY) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5788) Introduce batch size limit in PutDatabaseRecord processor
[ https://issues.apache.org/jira/browse/NIFI-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688239#comment-16688239 ] ASF subversion and git services commented on NIFI-5788: --- Commit d319a3ef2f14317f29a1be5a189bc34f8b3fdbd6 in nifi's branch refs/heads/master from vadimar [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=d319a3e ] NIFI-5788: Introduce batch size limit in PutDatabaseRecord processor NIFI-5788: Introduce batch size limit in PutDatabaseRecord processor Renamed 'batch size' to 'Maximum Batch Size'. Changed default value of max_batch_size to zero (INFINITE) Fixed parameter validation. Added unit tests Signed-off-by: Matthew Burgess This closes #3128 > Introduce batch size limit in PutDatabaseRecord processor > - > > Key: NIFI-5788 > URL: https://issues.apache.org/jira/browse/NIFI-5788 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework > Environment: Teradata DB >Reporter: Vadim >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > > Certain JDBC drivers do not support unlimited batch size in INSERT/UPDATE > prepared SQL statements. Specifically, Teradata JDBC driver > ([https://downloads.teradata.com/download/connectivity/jdbc-driver)] would > fail SQL statement when the batch overflows the internal limits. > Dividing data into smaller chunks before the PutDatabaseRecord is applied can > work around the issue in certain scenarios, but generally, this solution is > not perfect because the SQL statements would be executed in different > transaction contexts and data integrity would not be preserved. > The solution suggests the following: > * introduce a new optional parameter in *PutDatabaseRecord* processor, > *max_batch_size* which defines the maximum batch size in INSERT/UPDATE > statement; the default value zero (INFINITY) preserves the old behavior > * divide the input into batches of the specified size and invoke > PreparedStatement.executeBatch() for each batch > Pull request: [https://github.com/apache/nifi/pull/3128] > > [EDIT] Changed batch_size to max_batch_size. The default value would be zero > (INFINITY) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5788) Introduce batch size limit in PutDatabaseRecord processor
[ https://issues.apache.org/jira/browse/NIFI-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688243#comment-16688243 ] ASF GitHub Bot commented on NIFI-5788: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3128 > Introduce batch size limit in PutDatabaseRecord processor > - > > Key: NIFI-5788 > URL: https://issues.apache.org/jira/browse/NIFI-5788 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework > Environment: Teradata DB >Reporter: Vadim >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > > Certain JDBC drivers do not support unlimited batch size in INSERT/UPDATE > prepared SQL statements. Specifically, Teradata JDBC driver > ([https://downloads.teradata.com/download/connectivity/jdbc-driver)] would > fail SQL statement when the batch overflows the internal limits. > Dividing data into smaller chunks before the PutDatabaseRecord is applied can > work around the issue in certain scenarios, but generally, this solution is > not perfect because the SQL statements would be executed in different > transaction contexts and data integrity would not be preserved. > The solution suggests the following: > * introduce a new optional parameter in *PutDatabaseRecord* processor, > *max_batch_size* which defines the maximum batch size in INSERT/UPDATE > statement; the default value zero (INFINITY) preserves the old behavior > * divide the input into batches of the specified size and invoke > PreparedStatement.executeBatch() for each batch > Pull request: [https://github.com/apache/nifi/pull/3128] > > [EDIT] Changed batch_size to max_batch_size. The default value would be zero > (INFINITY) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #3128: NIFI-5788: Introduce batch size limit in PutDatabas...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3128 ---
[jira] [Commented] (NIFIREG-211) Add extension bundles as a type of versioned item
[ https://issues.apache.org/jira/browse/NIFIREG-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688152#comment-16688152 ] Otto Fowler commented on NIFIREG-211: - Would it be possible to have a repository entry for a bundle that was 'only' metadata and a download link? Like a lazy resolvable download? That way a repository could be fully populated, and easily synced, with only the used bundles actually downloaded. > Add extension bundles as a type of versioned item > - > > Key: NIFIREG-211 > URL: https://issues.apache.org/jira/browse/NIFIREG-211 > Project: NiFi Registry > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 0.4.0 > > > This ticket is to capture the work for adding extension bundles to NiFi > Registry. > This work may require several follow on tickets, but at a high-level will > include some of the following: > - Add a new type of item called an extension bundle, where each bundle > can contain one ore extensions or APIs > > - Support bundles for traditional NiFi (aka NARs) and also bundles for > MiNiFi CPP > > - Ability to upload the binary artifact for a bundle and extract the > metadata about the bundle, and metadata about the extensions contained > in the bundle (more on this later) > > - Provide a pluggable storage provider for saving the content of each > extension bundle so that we can have different implementations like > local fileysystem, S3, and other object stores > > - Provide a REST API for listing and retrieving available bundles, > integrate this into the registry Java client and NiFi CLI > - Security considerations such as checksums and cryptographic signatures for > bundles -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-676) Cleanup and fix serializable interface implementation
[ https://issues.apache.org/jira/browse/MINIFICPP-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688124#comment-16688124 ] ASF GitHub Bot commented on MINIFICPP-676: -- Github user arpadboda commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/440 A step forward, there is improvement left (a lot of code duplication exists in stream hierarchy), although this is enough for one PR. > Cleanup and fix serializable interface implementation > - > > Key: MINIFICPP-676 > URL: https://issues.apache.org/jira/browse/MINIFICPP-676 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Minor > > Serializable interface contains a couple of issues: > Type-unsafe template functions > Code duplication > Needless functions > The goal of this ticket is to make the interface cleaner and simpler. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp issue #440: MINIFICPP-676 - Cleanup and fix serializable int...
Github user arpadboda commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/440 A step forward, there is improvement left (a lot of code duplication exists in stream hierarchy), although this is enough for one PR. ---
[jira] [Commented] (MINIFICPP-676) Cleanup and fix serializable interface implementation
[ https://issues.apache.org/jira/browse/MINIFICPP-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688109#comment-16688109 ] ASF GitHub Bot commented on MINIFICPP-676: -- GitHub user arpadboda opened a pull request: https://github.com/apache/nifi-minifi-cpp/pull/440 MINIFICPP-676 - Cleanup and fix serializable interface implementation 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: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] 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)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/arpadboda/nifi-minifi-cpp MINIFICPP-676 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-minifi-cpp/pull/440.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #440 commit cf32a07d7a4b7082a7bc956ea5aa61b343789b81 Author: Arpad Boda Date: 2018-11-14T16:06:17Z MINIFICPP-676 - Cleanup and fix serializable interface implementation > Cleanup and fix serializable interface implementation > - > > Key: MINIFICPP-676 > URL: https://issues.apache.org/jira/browse/MINIFICPP-676 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Minor > > Serializable interface contains a couple of issues: > Type-unsafe template functions > Code duplication > Needless functions > The goal of this ticket is to make the interface cleaner and simpler. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #440: MINIFICPP-676 - Cleanup and fix serializa...
GitHub user arpadboda opened a pull request: https://github.com/apache/nifi-minifi-cpp/pull/440 MINIFICPP-676 - Cleanup and fix serializable interface implementation 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: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] 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)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/arpadboda/nifi-minifi-cpp MINIFICPP-676 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-minifi-cpp/pull/440.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #440 commit cf32a07d7a4b7082a7bc956ea5aa61b343789b81 Author: Arpad Boda Date: 2018-11-14T16:06:17Z MINIFICPP-676 - Cleanup and fix serializable interface implementation ---
[jira] [Commented] (NIFI-4957) Enable JoltTransformJSON to pickup a Jolt Spec file from a file location
[ https://issues.apache.org/jira/browse/NIFI-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688032#comment-16688032 ] Ryan Hendrickson commented on NIFI-4957: Thanks! > Enable JoltTransformJSON to pickup a Jolt Spec file from a file location > > > Key: NIFI-4957 > URL: https://issues.apache.org/jira/browse/NIFI-4957 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Ryan Hendrickson >Assignee: Ryan Hendrickson >Priority: Minor > Attachments: image-2018-03-09-23-56-43-912.png > > > Add a property to allow the Jolt Spec to be read from a file on disk and/or > the classpath. > !image-2018-03-09-23-56-43-912.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (NIFI-4957) Enable JoltTransformJSON to pickup a Jolt Spec file from a file location
[ https://issues.apache.org/jira/browse/NIFI-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Hendrickson reassigned NIFI-4957: -- Assignee: Ryan Hendrickson > Enable JoltTransformJSON to pickup a Jolt Spec file from a file location > > > Key: NIFI-4957 > URL: https://issues.apache.org/jira/browse/NIFI-4957 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Ryan Hendrickson >Assignee: Ryan Hendrickson >Priority: Minor > Attachments: image-2018-03-09-23-56-43-912.png > > > Add a property to allow the Jolt Spec to be read from a file on disk and/or > the classpath. > !image-2018-03-09-23-56-43-912.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5238) Capital "F" in Jolt Transformation moves caret
[ https://issues.apache.org/jira/browse/NIFI-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688030#comment-16688030 ] Ryan Hendrickson commented on NIFI-5238: Agreed - Any idea why? It's an awful strange bug to have. We just found the Caps Lock workaround the other day. > Capital "F" in Jolt Transformation moves caret > -- > > Key: NIFI-5238 > URL: https://issues.apache.org/jira/browse/NIFI-5238 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Anna Vergeles >Priority: Minor > Attachments: nifiFbug.png > > > When Jolt Transformation Component is in Advanced mode in web-UI, it is > impossible to enter capital letter "F" into "Jolt Specification" field – this > results inplacing coursor to the beginning of the text field. > !nifiFbug.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFICPP-676) Cleanup and fix serializable interface implementation
Arpad Boda created MINIFICPP-676: Summary: Cleanup and fix serializable interface implementation Key: MINIFICPP-676 URL: https://issues.apache.org/jira/browse/MINIFICPP-676 Project: NiFi MiNiFi C++ Issue Type: Improvement Reporter: Arpad Boda Assignee: Arpad Boda Serializable interface contains a couple of issues: Type-unsafe template functions Code duplication Needless functions The goal of this ticket is to make the interface cleaner and simpler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-645) Move from new to malloc in CAPI to facilitate eventual change from C++ to C
[
https://issues.apache.org/jira/browse/MINIFICPP-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687923#comment-16687923
]
ASF GitHub Bot commented on MINIFICPP-645:
--
Github user arpadboda commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/439#discussion_r233815698
--- Diff: nanofi/src/api/nanofi.cpp ---
@@ -205,7 +205,7 @@ flow_file_record* create_ff_object(const char *file,
const size_t len, const uin
}
flow_file_record* create_ff_object_na(const char *file, const size_t len,
const uint64_t size) {
- flow_file_record *new_ff = new flow_file_record;
+ flow_file_record *new_ff = (flow_file_record*)
malloc(sizeof(flow_file_record));
--- End diff --
Happy newless year! :)
> Move from new to malloc in CAPI to facilitate eventual change from C++ to C
> ---
>
> Key: MINIFICPP-645
> URL: https://issues.apache.org/jira/browse/MINIFICPP-645
> Project: NiFi MiNiFi C++
> Issue Type: Improvement
>Reporter: Mr TheSegfault
>Assignee: Arpad Boda
>Priority: Blocker
> Labels: CAPI, nanofi
> Fix For: 0.6.0
>
>
> As gradually move to C we should move out of libminifi and remove the linter.
> Nothing that is returned via the API that is not an opaque pointer should use
> new
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (NIFI-1101) Processor support Openstack Swift
[ https://issues.apache.org/jira/browse/NIFI-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686824#comment-16686824 ] Laurenceau Julien edited comment on NIFI-1101 at 11/15/18 12:02 PM: I am confused because there is also a recent ticket on swift Jira that says that it should be compatible (merged in Nov 2018) [https://review.openstack.org/#/c/575838/] [https://review.openstack.org/#/c/571561/] [https://docs.openstack.org/swift/latest/s3_compat.html] I'll try harder and keep you posted. was (Author: julienlau): I am confused because there is also a recent ticket on swift Jira that says that it should be compatible (merged in June 2018) [https://review.openstack.org/#/c/571561/] https://docs.openstack.org/swift/latest/s3_compat.html I'll try harder and keep you posted. > Processor support Openstack Swift > - > > Key: NIFI-1101 > URL: https://issues.apache.org/jira/browse/NIFI-1101 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 0.3.0 >Reporter: robinlin >Priority: Minor > > Hi > I think the current S3 processors are not available for Openstack Swift. > So in order to support Openstack Swift functionalities, the following are > some processors might have to be implemented > 1. GetContainer > 2. PutContainer > 3. DeleteContainer > 4. GetSwiftObject > 5. PutSwiftObject > 6. DeleteSwiftObject -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #439: MINIFICPP-645 - Move from new to malloc i...
Github user arpadboda commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/439#discussion_r233815698
--- Diff: nanofi/src/api/nanofi.cpp ---
@@ -205,7 +205,7 @@ flow_file_record* create_ff_object(const char *file,
const size_t len, const uin
}
flow_file_record* create_ff_object_na(const char *file, const size_t len,
const uint64_t size) {
- flow_file_record *new_ff = new flow_file_record;
+ flow_file_record *new_ff = (flow_file_record*)
malloc(sizeof(flow_file_record));
--- End diff --
Happy newless year! :)
---
[jira] [Commented] (MINIFICPP-645) Move from new to malloc in CAPI to facilitate eventual change from C++ to C
[ https://issues.apache.org/jira/browse/MINIFICPP-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687921#comment-16687921 ] ASF GitHub Bot commented on MINIFICPP-645: -- GitHub user arpadboda opened a pull request: https://github.com/apache/nifi-minifi-cpp/pull/439 MINIFICPP-645 - Move from new to malloc in CAPI to facilitate eventua… …l change from C++ to C 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: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] 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)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/arpadboda/nifi-minifi-cpp MINIFICPP-645 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-minifi-cpp/pull/439.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #439 commit 8b0e39dc8ec0dc79c8b3e58fa1a364e736a1fe38 Author: Arpad Boda Date: 2018-11-15T12:00:07Z MINIFICPP-645 - Move from new to malloc in CAPI to facilitate eventual change from C++ to C > Move from new to malloc in CAPI to facilitate eventual change from C++ to C > --- > > Key: MINIFICPP-645 > URL: https://issues.apache.org/jira/browse/MINIFICPP-645 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Assignee: Arpad Boda >Priority: Blocker > Labels: CAPI, nanofi > Fix For: 0.6.0 > > > As gradually move to C we should move out of libminifi and remove the linter. > Nothing that is returned via the API that is not an opaque pointer should use > new -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #439: MINIFICPP-645 - Move from new to malloc i...
GitHub user arpadboda opened a pull request: https://github.com/apache/nifi-minifi-cpp/pull/439 MINIFICPP-645 - Move from new to malloc in CAPI to facilitate eventua⦠â¦l change from C++ to C 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: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] 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)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/arpadboda/nifi-minifi-cpp MINIFICPP-645 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-minifi-cpp/pull/439.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #439 commit 8b0e39dc8ec0dc79c8b3e58fa1a364e736a1fe38 Author: Arpad Boda Date: 2018-11-15T12:00:07Z MINIFICPP-645 - Move from new to malloc in CAPI to facilitate eventual change from C++ to C ---
[jira] [Assigned] (MINIFICPP-645) Move from new to malloc in CAPI to facilitate eventual change from C++ to C
[ https://issues.apache.org/jira/browse/MINIFICPP-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpad Boda reassigned MINIFICPP-645: Assignee: Arpad Boda > Move from new to malloc in CAPI to facilitate eventual change from C++ to C > --- > > Key: MINIFICPP-645 > URL: https://issues.apache.org/jira/browse/MINIFICPP-645 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Assignee: Arpad Boda >Priority: Blocker > Labels: CAPI, nanofi > Fix For: 0.6.0 > > > As gradually move to C we should move out of libminifi and remove the linter. > Nothing that is returned via the API that is not an opaque pointer should use > new -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-1101) Processor support Openstack Swift
[ https://issues.apache.org/jira/browse/NIFI-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-1101: - Status: Reopened (was: Closed) > Processor support Openstack Swift > - > > Key: NIFI-1101 > URL: https://issues.apache.org/jira/browse/NIFI-1101 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 0.3.0 >Reporter: robinlin >Priority: Minor > > Hi > I think the current S3 processors are not available for Openstack Swift. > So in order to support Openstack Swift functionalities, the following are > some processors might have to be implemented > 1. GetContainer > 2. PutContainer > 3. DeleteContainer > 4. GetSwiftObject > 5. PutSwiftObject > 6. DeleteSwiftObject -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-1101) Processor support Openstack Swift
[ https://issues.apache.org/jira/browse/NIFI-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687780#comment-16687780 ] Pierre Villard commented on NIFI-1101: -- Thanks [~julienlau] - re-opening the JIRA based on your info. Not sure someone will give it a try but who knows. > Processor support Openstack Swift > - > > Key: NIFI-1101 > URL: https://issues.apache.org/jira/browse/NIFI-1101 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 0.3.0 >Reporter: robinlin >Priority: Minor > > Hi > I think the current S3 processors are not available for Openstack Swift. > So in order to support Openstack Swift functionalities, the following are > some processors might have to be implemented > 1. GetContainer > 2. PutContainer > 3. DeleteContainer > 4. GetSwiftObject > 5. PutSwiftObject > 6. DeleteSwiftObject -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-1101) Processor support Openstack Swift
[ https://issues.apache.org/jira/browse/NIFI-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687755#comment-16687755 ] Laurenceau Julien commented on NIFI-1101: - Good question :) ... No I don't. Anyway, I wanted to share the fact that it is not possible to directly manipulate Swift from OVH through Nifi. > Processor support Openstack Swift > - > > Key: NIFI-1101 > URL: https://issues.apache.org/jira/browse/NIFI-1101 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 0.3.0 >Reporter: robinlin >Priority: Minor > > Hi > I think the current S3 processors are not available for Openstack Swift. > So in order to support Openstack Swift functionalities, the following are > some processors might have to be implemented > 1. GetContainer > 2. PutContainer > 3. DeleteContainer > 4. GetSwiftObject > 5. PutSwiftObject > 6. DeleteSwiftObject -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-1101) Processor support Openstack Swift
[ https://issues.apache.org/jira/browse/NIFI-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687681#comment-16687681 ] Pierre Villard commented on NIFI-1101: -- [~julienlau] - do you intend contributing a processor for this feature? > Processor support Openstack Swift > - > > Key: NIFI-1101 > URL: https://issues.apache.org/jira/browse/NIFI-1101 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 0.3.0 >Reporter: robinlin >Priority: Minor > > Hi > I think the current S3 processors are not available for Openstack Swift. > So in order to support Openstack Swift functionalities, the following are > some processors might have to be implemented > 1. GetContainer > 2. PutContainer > 3. DeleteContainer > 4. GetSwiftObject > 5. PutSwiftObject > 6. DeleteSwiftObject -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-1101) Processor support Openstack Swift
[ https://issues.apache.org/jira/browse/NIFI-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687648#comment-16687648 ] Laurenceau Julien commented on NIFI-1101: - Ok after numerous tests I turns out that my cloud provider (OVH) deactivated the S3 access to their openstack swift product... Would it be possible to re-open this ticket, please ? > Processor support Openstack Swift > - > > Key: NIFI-1101 > URL: https://issues.apache.org/jira/browse/NIFI-1101 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 0.3.0 >Reporter: robinlin >Priority: Minor > > Hi > I think the current S3 processors are not available for Openstack Swift. > So in order to support Openstack Swift functionalities, the following are > some processors might have to be implemented > 1. GetContainer > 2. PutContainer > 3. DeleteContainer > 4. GetSwiftObject > 5. PutSwiftObject > 6. DeleteSwiftObject -- This message was sent by Atlassian JIRA (v7.6.3#76005)
