After upgrading the com.hazelcast group to 5.2.1 version, not able to configure the ManagementCentre url. Not able to see the following method itself, do I need to any other alternate config api for this?
ManagementCenterConfig managementCenterConfig = new ManagementCenterConfig();
managementCenterConfig.setUrl(hazelCastConfiguration.getManCenterUrl());
able to config mancenter url in lower version.
Related
I'm trying to run Heat Clinic 6.0.1 locally following getting started tutorial: https://www.broadleafcommerce.com/docs/core/current/getting-started/running-locally
I managed to run admin and site but not the API project. The application starts without problems but when I go to http://localhost:8082/api/v1/swagger-ui.html I get a 404. In the log I see this exception:
javax.servlet.ServletException: Circular view path [error]: would dispatch back to the current handler URL [/error] again. Check your ViewResolver setup! (Hint: This may be the result of an unspecified view, due to default view name generation.)
Also trying to log in directly in the API with user broadleafapi and password gives 404.
My environment: Windows 10, jdk 8, maven 3.6
What's wrong? Can you help me? Thank you
Thanks for the report. I reproduced this and it looks like that with the update to Spring Boot 2.0, we did not appropriately override the updated property that specifies the servlet location to embedded Tomcat. Thus, when you went to /api/v1/swagger-ui.html, the application treats it exactly like that URL which is what gave the 404.
Setting the server.servlet.contextPath=/api/v1 property appropriately stripped off this path as part of the servlet context and resolved the 404.
I tested around a bit and was able to 'Authorize' the app (button at the top right of the Swagger page) with the credentials information that get spit out in the logs:
Basic auth configured with user broadleafapi and password: <<generated>>
then I was able to hit the API endpoints.
The changes you will need to make locally in your project to consume the fix are at https://github.com/BroadleafCommerce/DemoSite/commit/422d1cdc37f847afd8bec0be477ab784cbad2e9d#diff-991c59b6dbb0f619b8570d8f8779eaddR11. You will notice that I moved the original definition in default.properties over to common.properties and I recommend that you do the same. To be clear, follow these steps:
Delete the server.servlet.contextPath entry in `api/src/main/resources/runtime-properties/default.properties
Change server.servletPath in api/src/main/resources/runtime-properties/common.properties to server.servlet.contextPath
Thanks for trying out Broadleaf and the report, sorry for the rough early start!
Is there a way to set the default application version in azure batch account using java sdk?
The sample script that they have in the git does not show how to set the default version(https://github.com/Azure-Samples/batch-java-manage-batch-accounts/blob/master/src/main/java/com/microsoft/azure/management/batch/samples/ManageBatchAccount.java).
Also I was trying to dig in the interface(https://github.com/Azure/azure-libraries-for-java/blob/master/azure-mgmt-batch/src/main/java/com/microsoft/azure/management/batch/Application.java) to get some clues but couldn't see anything that supports updating the default version.
UPDATE:
I was able to get the version update working following #brklein suggestion:
BatchApplication batchApplication = batchAccount.applications().get(applicationName)
ApplicationTokenCredentials credentials = new ApplicationTokenCredentials(applicationId, tenantId, appSecret, AzureEnvironment.AZURE)
BatchManager batchManager = BatchManager.authenticate(credentials, subscriptionId)
ApplicationsInner applicationsInner = batchManager.inner().applications()
ApplicationUpdateParameters parameters = new ApplicationUpdateParameters(defaultVersion: DEFAULT_APP_VERSION)
applicationsInner.update(resourceGroupName, batchAccountName, batchApplication.id(), parameters)
It does not appear that default version is being surface at the client layer of the SDK.
To get around this you should be able to call the implementation methods manually, which have the full functionality of the REST API (as they are auto-generated).
To do this create either CreateApplicationParameters or ApplicationUpdateParameters and set the defaultVersion property. Then you can call the implementations create or update methods manually (https://github.com/Azure/azure-libraries-for-java/blob/78e8ff2940eba34bc63f8e7be6807a377500f5c7/azure-mgmt-batch/src/main/java/com/microsoft/azure/management/batch/implementation/ApplicationsInner.java#L474).
I have enabled versioning for Azure API Management (APIM). The versioning is based on querystring parameters (e.g. ?api-version=1.0). The intent for using a querystring is so that if the user doesn't provide the parameter, it'll default to the latest version. So:
/api/operation?api-version=1.0 <- Goes to 1.0
/api/operation?api-version=1.1 <- Goes to 1.1
/api/operation <- Goes to 1.1 (assuming that is latest)
However, it appears as though APIM uses that parameter as an indexer and if it's not provided, APIM doesn't know which version to use. Is there a way to tell APIM that, if the parameter is missing, automatically go to a specific version?
Not possible in Azure APIM. API version is required to be passed for every request.
Once you opt into API versioning, all API routes are explicitly versioned. This means a client cannot request a resource without explicitly providing an API version.
In order to make your scenario work, you need to allow match a default API version when a client doesn't specify anything. You could set up like below:
service.AddApiVersioning( options => options.AssumeDefaultVersionWhenUnspecified = true );
The AssumeDefaultVersionWhenUnspecified option enables support for clients to make requests with implicit API versioning. This option is disabled by default, which means that all clients must send requests with an explicit API version.
Services will respond to client requests that do not specify an API version with either HTTP status code 400 (Bad Request) or HTTP status code 404 (Not Found), depending whether the requested route exists.
Also, you could use DefaultApiVersion option which defines what the default ApiVersion will be for a service without explicit API version information. The default configured value is 1.0.
services.AddApiVersioning(
o => o.DefaultApiVersion =
new ApiVersion( new DateTime( 2016, 7, 1 ) );
For more details, you could refer to this article.
I am writing some C# code that uses the Azure Resource Manager APIs and my CloudBlobClient needs to use a web proxy. According to the documentation for OperationContext.UserHeaders property at https://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storage.operationcontext.userheaders.aspx, UserHeaders can be used to specify a proxy. Can you please share how this should be done properly?
Edited after Gaurav Mantri's comment.
The Azure clients below allow you to specify a proxy to be used via the httpClientHandler but the CloudBlobClient does not respect the proxy information from StorageManagementClient and there doesn't seem to be a way to pass the proxy information to the CloudBlobClient. Our users may want to specify different proxies for multiple connections and it doesn't seem the current architecture will easily allow this.
//Example code that instantiates clients with proxy information inside the httpClientHandler
armCompute = new ComputeManagementClient(tokenCredentials, httpClientHandler)
armStorage = new StorageManagementClient(tokenCredentials, httpClientHandler)
armNetwork = new NetworkManagementClient(tokenCredentials, httpClientHandler)
armResource = new ResourceManagementClient(tokenCredentials, httpClientHandler)
armSubscription = new SubscriptionClient(tokenCredentials, httpClientHandler)
I believe you're understanding it incorrectly. The documentation states:
Gets or sets additional headers on the request, for example, for proxy
or logging information.
From what I understand you use this to get or set the headers for your proxy to understand and not specify proxy configuration settings.
In order to specify proxy settings, you would need to specify those in your application configuration file (web.config or app.config).
I'm behind a firewall and lazybones can't reach its repository without a proxy.
I've searched the source and can't seem to find any reference to a proxy that seems to be relevant.
Support was officially added in version 0.8.1 of Lazybones, albeit via a general mechanism to add arbitrary system properties to the application in its configuration file, ~/.lazybones/config.groovy.
You can read about the details in the project README, but in essence, simply add the following to your config.groovy file:
systemProp {
http {
proxyHost = "localhost"
proxyPort = 8181
}
https {
proxyHost = "localhost"
proxyPort = 8181
}
}
You can use the systemProp. prefix to add any system properties to Lazybones, similar to the way it works in Gradle.
Is that what You're looking for? Basically You need to add some properties to gradle.properties file.
I am using Cygwin on Windows and I have modified the last line of
~/.gvm/lazybones/current/bin/lazybones
to say
exec "$JAVACMD" "${JVM_OPTS[#]}" -classpath "$CLASSPATH" "-Dhttp.proxyHost=127.0.0.1" "-Dhttp.proxyPort=8888" "-Dhttp.nonProxyHosts=localhost|127.0.0.1" uk.co.cacoethes.lazybones.LazybonesMain "$#"
Please note the quotes around the options. It works very well with my local Fiddler installation.
I have found no better way to enable proxy support due to the way the script is using eval. Maybe a more experienced shell script programmer can come up with a more elegant solution.
I was able to get out through the proxy setting the environment settings of
Picked up JAVA_TOOL_OPTIONS: -Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=8080
-Dhttp.nonProxyHosts="lmig.com" -Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=8080
unfortunately my environment requires authentication so I couldn't provide the complete proxy this way. I first ran "OWASP Zed Attach Proxy (ZAP)" which allowed me to run a proxy on my own machine (at port 8080) which then provided the complete authentication required.
This was able to then run the complete "lazybones list" command which retrieved the contents of the respositories.
Unfortunately I was not able to create an application from those templates becuase bintray required a login (though an anonymous login would do) and couldn't seem to get an additional level of authentication (I received "Unauthorized" from bintray)