So - bearing in mind that I was not involved (except very slightly) in the development of this component, the general reason to throw an exception rather than to ignore is in case the application programmer has made a typo, or is expecting some behaviour by setting the option... and the fact that no action will be taken (because of a typo, or because the option has no effect in the context) will be a surprise to them.
So, if - for example - you were using an SSL connection, but had supplied the option verfyHost=false (i.e. you had accidentally omitted the i in verify) then it seems appropriate to throw the exception. Ideally a better error message could be generated to differentiate between completely unknown (and thus likely typos) options, and options that are not valid on this transport (e.g. verifyHost on a non TLS connection), but overall I think the decision to throw an exception is reasonable. -- Rob On 1 February 2017 at 11:57, Adel Boutros <[email protected]> wrote: > So for me there are 2 possible solutions: > > 1) Throw exception > > 2 ) Ignore the useless parameters > > > So for my general knowledge, why do you think the first one (Which is > implemented in the JMS client) is the appropriate one? > > > Regards, > > Adel > > ________________________________ > From: Robbie Gemmell <[email protected]> > Sent: Wednesday, February 1, 2017 11:47:00 AM > To: [email protected] > Subject: Re: [Qpid Java Broker 6.0.4][Qpid JMS 0.11.1] Setting SSL options > to AMQP non secured port triggers exception in JMS > > Yep, the client is reporting that a given transport option was not > able to be applied, in this case because its still using the 'tcp > transport' and the verifyHost option only applies with the 'ssl > transport'. As you thought, this occurs before it even attempts to > make a connection. > > Robbie > > On 1 February 2017 at 10:35, Rob Godfrey <[email protected]> wrote: > > I'm not an expert on the JMS client, but I'm not sure that the > "verifyHost" > > option would make any sense on a non-TLS connection (since by definition > > you can only verify the host when you receive the TLS certificate). > > > > I think the use of the Java Broker here is not important, as I assume > this > > fails before it even tries to make a connection, > > > > -- Rob > > > > On 1 February 2017 at 11:31, Adel Boutros <[email protected]> wrote: > > > >> Hello, > >> > >> > >> I was playing around SSL/SASL with the Java Broker and noticed that some > >> of the options which I can pass to the JMS client do not work. > >> > >> > >> For example, if I set the following url for the JMS Connection Factory, > I > >> will get the below exception. Is this expected behavior? > >> > >> > >> JmsConnectionFactory jmsConnectionFactory = new > >> JmsConnectionFactory("amqp://localhost:5672?transport. > verifyHost=false"); > >> jmsConnectionFactory.createConnection(); > >> > >> > >> Caused by: java.lang.IllegalArgumentException: Not all transport > options > >> could be set on the TCP Transport. Check the options are spelled > correctly. > >> Unused parameters=[{verifyHost=false}]. This provider instance cannot > be > >> started. > >> at org.apache.qpid.jms.transports.TransportFactory.createTransport( > >> TransportFactory.java:64) > >> at org.apache.qpid.jms.transports.TransportFactory. > >> create(TransportFactory.java:120) > >> at org.apache.qpid.jms.provider.amqp.AmqpProvider.connect( > >> AmqpProvider.java:160) > >> > >> > >> Regards, > >> > >> Adel > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
