After upgrading from Azure SDK 1.7 => 1.8, we're noticing that there are two classes of essentially the same thing:
Microsoft.WindowsAzure.Storage.CloudStorageAccount (v1.7)
Microsoft.WindowsAzure.CloudStorageAccount (v1.8)
Before we migrate over to 1.8 in code (we can still reference Azure SDK 1.7 and compile), does anyone know what the newer benefits are and if there is some sample code to use it? This is from the perspective of Azure Diagnostics, so start and stop On-Demand transfers.
Microsoft.WindowsAzure.Storage namespace is introduced with Storage Client Library 2.0, which comes with Azure SDK 1.8. But the Storage Client Library 1.7 also exists in SDK 1.8 for backward compatibility reasons. For more information on Storage Client Library 2.0, please refer to this blog post.
Related
Our team would like to use an Infinispan client in an ASP.NET core DOCKER environment. The last version seems to be an 8.3.0-Alpha1 version on Nuget.org, which is almost 2 years old. Are there any plans to get this into a release version and make it current?
I've assembled two new .nupkg Hotrod clients for Fedora31 and Windows10-VS14.
They're based on the 8.3.1.Final version released on the Infinispan web site.
Packages contain native libraries, please consider to build it by yourself following the readme if you need a different build for your specific platform.
For more info, meet the Infinispan Team at infinispan.zulipchat.com
I have a few apps in data pipeline which use kafka as a queuing system.
If a producer app on java7 using kryo 2.22 produces to a kafka (java7) then would a consumer app on java8 using kryo 4.0 be able do deserialize the data ?
I short data serialization/deserialization compatible across different kryo versions ?
Well, after certain testing and looking up kryo's github docs i found that data serialization/deserialization is NOT compatible across major version changes of kayo library
https://github.com/EsotericSoftware/kryo :: Section Versioning Semantics, Upgrading
we increase the major version if serialization compatibility is broken (data serialized with the previous version cannot be deserialized with the new version)
We have a requirement to connect SAP ERP. As per Mule documentation, to connect SAP( Jco jars) it says 3.0.11 ( Latest) is not supported by the connector.
[http://www.mulesoft.org/documentation/display/current/SAP+Connector][1]
We have reached SAP - they says like only Latest version ( 3.0.11) should be downloaded from Marker place.They were not supporting the SAP old version jars since latest is released( with bug fixed) .
Please suggest, how do we get older version of jars ( 3.0.9 or 3.0.6). It will be very helpful. We are looking for options.
Thanks in advance.
SAP do not release older versions of the SAPJCO or SAPIDOC libraries as the latest versions are fully backward compatible.
The difference between 3.0.9 and 3.0.11 are very minor bug fixes, so its surprising to hear that 3.0.11 does not work. MuleSoft should liaise directly with SAP as they are an SAP Certified Integration Partner and their software should always run on the latest versions of the various SAP connectors.
As a certified partner MuleSoft will be abundantly aware that customers only have access to the most recent versions of the SAPJCO/IDOC libraries, and that SAP do not release older versions.
You would also think that MuleSoft would have access to older versions of the libraries from engagements with existing/previous SAP customers.
I would advise you to go back to MuleSoft and have them speak directly with SAP. This is not a problem for the customer.
Third-party libraries are often included by the appliation server you are deploying to and class with the ones included by your application. So far I have dealt with this in the simplest and hackiest way possible: removing the libraries on the app server.
In our case it is ok, noone is relying on the app server to provide them with any libraries. But if I were running my app along with lots of other peoples app, which again might depend on the libraries included by the application server, this would not be a solution.
How is this supposed to be solved (cleanly)? How are you doing it?
An example of a problem might be this:
you build an jax-rs application using cxf, hibernate and jackson, and deploy to glassfish 2.1.1. glassfish supplies the asm 3.1 library, but this causes clashes with hibernate using an incompatible 1.5 version. similarly the application needs jackson 1.8.2 (due to a bug fix), but glassfish 2.1.1 ships with version 0.9. BOOM. Any way of fixing this other than simply removing offending libraries?
consider using :
asadmin deploy --libraries ...
I'm working on a cross-platform solution currently. The solution uses XmlMtomReader and XmlMtomWriter from .NET framework 3.0.
Now i need to know if these two classes (and all the nessasary infrastructure around them) are fully supported in Mono project from the porting-it-to-linux point of view. :)
You can check it on the mono status:
http://go-mono.com/status/
You can also check your code using the mono migration analyser
http://www.mono-project.com/MoMA
I checked they are currently not implemented
The APIs are available on the current Mono 2.6 preview, but they are not available on the 2.4 release (the current official release).