After updating pod to AFNetworking 4.0, I noticed that AFOAuth2Manager and AFNetworkActivityLogger are not available with this release.
I am using authenticateUsingOAuthWithURLString() method to perform a login task in my application.
Also, AFNetworkActivityLogger is being used as AFNetworkActivityLogger.shared().startLogging().
Can anyone please suggest a way to use AFOAuth2Manager and AFNetworkActivityLogger with an updated AFNetworking framework.
OR
Please let me know an alternative to handle this scenario.
Related
I have an application, which needs to be tested using in-house developed python automation. Originally, the application was developed using Swagger 2.x spec. Now it is migrated to use Open API 3.x
When it was on Swagger 2.x spec, I used to use swagger-codegen-cli-2.4.21.jar to generate the python client libraries, which we eventually consumed to write our automation. With the 2.4.21 jar we could disable the client side validation (configuration.py)
But after moving to OpenAPI 3.x, I am not able to use 2.4.21 jar because its not supported. So I used 3.0.36 jar to generate the python client libraries. But this doesn't have the option to disable the client side validation (in configuration.py). This is actually creating lot of problems because we are getting ValueErrors during GET calls.
I see that there are some discussions happened on the same, but none of them are conclusive enough that it is actually fixed in 3.x
https://github.com/OpenAPITools/openapi-generator/pull/4137
https://github.com/swagger-api/swagger-codegen/issues/5530
https://github.com/swagger-api/swagger-codegen/pull/9717
So I need help to understand whether this is still a open issue (or) it is fixed in some 3.x release..? If its not fixed yet, is there a workaround to overcome this issue..?
As of now, we are commenting all the ValueErrors to get around the issue, but this is not recommended because we lose the validation capability during POST calls.
On python-nextgen (latest Python generator) it is not implemented (you can indicate which type of validation can be skipped using disabled_client_side_validations when creating the configuration object, maybe works for you?).
The configuration object also includes a property client_side_validation which seems to be intended for this purpose but at the moment there is no implementation.
The only option at the moment is to keep it or remove it for all operations.
I moved to Bolt 4 (from Bolt 3.7) and would like to implement front-end user to give them access to private contents of the website. Previously, I used the extension BoltAuth/Auth, which worked like a charm.
Now in Bolt 4, there is no easy way like in Bolt 3.x to install an extension from the back-end page. I found out I could use composer to do so, but I run in the following problem:
> composer require "boltauth/auth:3.0.1"
[InvalidArgumentException]
Could not find a matching version of package boltauth/auth. Check the package
spelling, your version constraint and that the package is available in a stability
which matches your minimum-stability (stable).
Either I do something wrong, or the extension is not compatible with Bolt 4.1.
Could someone tell me if there is a way to make this extension work? Or alternatives for front-end user management?
EDIT: I'm now using the bolt/users extension as it can be used to add a ROLE_MEMBERS and let users login for the frontend.
Yes, unfortunately the architecture for plugins (mainly driven by the move from Silex to Symfony) changed completely between 3.x and 4.x and it's not really feasible to release new 4.x compatible versions.
So for now there won't likely be updates to BoltAuth. It may be worth joining the Slack community and seeing if any other developers are working on 4.x compatible solutions to the client login scenarios.
I've used CTL in ExecuteGroovyScript processor to connect to database which is selected by database.name due to this problem DBCPConnectionPoolLookup problem in ExecuteGroovyScript. after upgrading NiFi to new version (1.10.0), the processors show this error:
and this is my processor configuration:
Please let me know the problem.
I started testing version 1.10.0 myself recently and that was one of the things I ran in to as well. Try using SQL.* (ex: SQL.db) for your property name as that is used specifically for DBCP services. If you need to access other services that still can be done by looking up the service by name in your Groovy script as a workaround but based on Jira activity, I see this bug is already being worked on and hopefully will be fixed in next release. I hope this helps.
I am trying to change the compile engine of worklight from rhino to nodejs by following the steps mentioned in this URL
It was specifically mentioned that the above method doesn't work for 6.2 version. I am using 6.2v and tried it once but with no luck...., is there any other way to achieve this?
Thanks!!
There is currently no way to use nods.js-based adapters in Worklight 6.2, as you have already mentioned. That is still valid.
You can submit a feature request here: http://www.ibm.com/developerworks/rfe/
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.