Hi ,
I am relatively new to nifi .I have a requirment where i have to push some
messages to JMS (HornetQ).
When i push the message with below configuration in putJMS of nifi i am
getting the below error.
2019-06-13 09:30:31,701 ERROR [Timer-Driven Process Thread-7]
o.apache.nifi.processors.stan
Hi,
I am having difficulty adding an advanced button based on the information
provided in the nifi developer guide. Before I elaborate, I wanted to make
sure I am even 'doing the right thing' in reaching out to this email
address (mailing list?).
Thanks,
P
Philip
This is a perfectly fine place to bring this to.
These links may help
http://apache-nifi.1125220.n5.nabble.com/Custom-UI-for-Processor-td12150.html
https://nifi.apache.org/docs/nifi-docs/html/developer-guide.html#ui-extensions
Thanks
On Thu, Jun 13, 2019 at 11:10 AM Philip Wofford
wro
For our organization the server certificate is considered sensitive and not
available to the users who need to deploy to NiFi. Actual authentication to
NiFi is handled through Knox and our SSO Service so the end user never deals
with SSL or has access to a certificate. Originally I started down
I see a couple choices here:
1. Use the CA to generate and sign a new certificate for deployments. This
certificate would not be as sensitive as the server certificate, as you can put
stricter permissions on that identity within the NiFi access controls, and the
cert would be issued for a DN th
Is there a way to pass 2 currently? Because you can get the token via curl like
I’m currently doing?
Thanks
Shawn
Sent from my iPhone
> On Jun 13, 2019, at 12:21 PM, Andy LoPresto wrote:
>
> I see a couple choices here:
>
> 1. Use the CA to generate and sign a new certificate for deployments
You’ll probably have to write (minimal) code to expose the ClientBuilder
constructor/factory methods to the part that parses command-line arguments.
Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Jun 13, 201
Just to further elaborate, within the CLI there are commands that work
against registry and commands that work against NiFi. For registry
commands, they use the Java client that is provided by registry [1].
For NiFi commands, there is mini client developed as need with in the
CLI [2].
None of thes
Ok, I was thinking the CLI used the Rest API exclusively and that's what I was
missing. Unfortunately I don't have the option to use self-signed certificate
due to organizational security policies and we don't have a way to get SSL
Certificates issued to individuals only servers.
Thanks
Shawn
I'm not sure if I confused things... the clients that I mentioned are
wrappers for the REST API implemented with Jersey client, so the CLI
does exclusively use the REST API.
I was just drawing attention to the clients to say that part of the
work is outside of the CLI in nifi-registry-client to al
Got it, I've been trying to read some of this on my phone and missed something.
Currently it looks like the NiFi Client JerseyNiFiClient.java was setup to
support token(JWT) based requests but from what I can tell those methods are
never called anywhere. NiFi Registry Client only implemented the
Ah thanks for pointing that out, I completely forgot that apparently I
was thinking ahead in the JerseyNiFiClient of how we could support
tokens :)
You would need to make the same changes in the
JerseyNiFiRegistryClient, and then build a new toolkit based on a new
version of nifi-registry-client.
Completely agree on username and password but I'll probably still do something
somewhat generic around access tokens vs 2 way ssl as in the future there might
be something else. On a related note is it possible to get a JWT with 2 way
ssl? If so we could use the same auth method for everything.
No, client cert authentication bypasses the JWT behavior completely. Because a
client cert is automatically sent on every request, it makes no sense to
delegate the credential to a token in that case.
Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6
It would be a little bit weird because you'd still need the client
cert for the initial request to get the JWT, so then in that case why
not just keep using the client cert.
Registry does things a little bit different than NiFi and has a few
variations of the token end-point:
/access/token/login
Got it, for now I'm just going to work on implementing a Kerberos solution that
either allows you to configure a keytab and principal or pulls from the current
subject if your already logged in.
I created NIFI-6378 and NIFIREG-281. Can one of you assign the registry one to
me as I'm not a contr
Assigned you that Jira and added you to the contributors role so you can do the
same in the future. Thanks.
Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Jun 13, 2019, at 12:11 PM, Shawn Weeks wrote:
>
>
Hello,
PutJMS is deprecated, PublishJMS is recommended instead.
PublishJMS uses JMSConnectionFactoryProvider Controller Service, in
which you can specify "MQ ConnectionFactory Implementation" and "MQ
Client Libraries path (i.e., /usr/jms/lib)".
You will need to download HornetQ from here, extract
Hi,
There is another NiFi JMS connection ControllerService, that is
JndiJmsConnectionFactoryProvider.
With PublishJMS and JndiJmsConnectionFactoryProvider, I was able to
send message to a HornetQ queue.
JndiJmsConnectionFactoryProvider config example:
- Initial Naming Factory Class: org.jnp.inter
19 matches
Mail list logo
