Using the latest Service Fabric SDK, we would like to replace the restrictive DataContractSerializer with a custom IStateSerializer that uses JSON serialization. We have found the IReliableStateManager.TryAddStateSerializer method, however it is marked as obsolete.
How else can we register a custom IStateSerializer?
There's no alternative way. Using it in this way is supported, but the way it works will change somewhere in the future. You should make the call based on whether you're prepared to deal with that uncertainty.
Related
We would like to extend Wiremocks standard behavior with our own extension that allows for state to be managed across multiple request/response pairs. In particular, we need to aggregate data from a number of requests that is then returned upon invocation of a particular URL. Our question is whether this is even possible with Wiremock and how it could be achieved.
The only idea we have had so far is to introduce custom handlebars that read from/write to global state (e.g., static fields), but is there some other extension mechanism that we are missing? We are aware that this is something you would typically implement with a standard application server, however we have already heavily invested (architecturally speaking) in Wiremock and would prefer to find a compatible solution.
I should add that we are actually using Wiremock Studio rather than plain Wiremock, which may affect what kind of extensions are possible.
After updating to .net core 2.2 we have the following issue:
Autofac.Core.Registration.ComponentNotRegisteredException: 'The
requested service 'Microsoft.AspNetCore.Hosting.Server.IServer' has
not been registered. To avoid this exception, either register a
component to provide the service, check for service registration using
IsRegistered(), or use the ResolveOptional() method to resolve an
optional dependency.'
We are using preBuilder.Populate(services);.
Any ideas?
Thanks for your help
I had the same problem when following Microsoft migration guide for migrating from Core 2.1 to 2.2.
The problem might occur if you are not using WebHost.CreateDefaultBuilder to create the default web host builder, and you change in the CreateWebHostBuilder method of the Program class to call ConfigureKestrel instead of UseKestrel, as suggested in the migration guide.
As far as I understand if you use WebHost.CreateDefaultBuilder to create the default web host builder, it already calls UseKestrel which registers the IServer service. But you might get into some conflicts if also using UseIIS, so to avoid this problems there is a new ConfigureKestrel call that does not register the IServer. So I think that if you are not using WebHost.CreateDefaultBuilder then you still need to call UseKestrel or UseIIS explicitly.
Of course it might be something else that is causing the problems in your case, but I suspect that following the migration guide blindly (as I did) could cause problems for many developers out there.
I have found couple of references to the "TryAddStateSerializer" method but it appears to be deprecated, and the examples provided don't seem to work anyway including this one GitHub Azure content.
How an I supposed to register my Custom serializer?
TryAddStateSerializer is currently the only way to do it. The API may change in the future but it is safe to use today.
I'm doing a Java Backed Webscript to put in Alfresco and call it via REST. This Webscript must do a set of 3 operations (find a path, create a folder and upload a document).
I read about this and found similar examples to do this operations throw the native Alfresco API, with methods like getFileFolderService, getContentService, etc. of Repository or ServiceRegistry classes. All in Java, without javascript.
But I would rather use REST calls instead of Alfresco API inside my Webscript. I think that if already exists Webscripts to do these operacions, is easier call them than use Alfresco API methods to try to do it. And if the API changes in future versions, the REST calls would remain the same. But I'm new here and I don't know if I'm wrong.
In summary: to do these 3 operacions, one after another, in my backed webscript, what is better and why? Use native API methods or use REST calls to existing webscripts?
And if I try to do the second option, is possible to do this? Using HttpClient class and GetMethod/PostMethod for the REST calls inside my Java Webscript may be the best option for Rest calls?. Or this could give me problems? Because I use a Rest call to my backed webscript that do another rest calls to another webscripts.
Thanks a lot!
I think it's bad practice to do it like this. In a lot of Alfresco versions the default services didn't change a bit. Even when they changed they still had deprecated methods.
The rest api changed as well. If you want to make an upgrade proof system I guess it's better to stick with the Webservices (which didn't change since version 2.x) or go with CMIS.
But then it doesn't make sense to have your code within Alfresco, so putting it within an interface is better.
I'd personally just stick with the JavaScript API which didn't change a lot. Yes more functions were enabled within, but the default actions to search & CRUD remained the same.
You could even to a duo: Have your Java Backendscript do whatever fancy stuff and send the result to je JavaScript controller and do the default stuff.
Executing HTTP calls against the process you are already in is a very very bad idea in general. It is slower, much more complex and error-prone, hogs more resources (two threads), and in your case, you will even lose transaction safety. Just imagine the last call fails for some reason. Besides you will most likely have to handle security context propagation yourself. Use the native public API and it will be easy, safe and stable.
We are currently using PostSharp for its standard functionality (logging, caching, transactions, and so on).
We also generate dynamically, at runtime, some custom classes, using Reflection.Emit. This obviously slows startup, and as we need to add more dynamic type generation, I am wondering, since all the information for the dynamic types is known at build time, whether we can use PostSharp to do this.
So, the question itself is, can I use PostSharp to achieve what I can do with Reflection.Emit, but at build time?
Regards
The PostSharp itself is using PostSharp.Sdk to manipulate the binary code, but this API is not publicly documented and supported at the moment. So, it's not future-proof to rely on it in your project.
The closest you can get with the documented API is probably by introducing interfaces, methods and properties: http://doc.postsharp.net/content/code-injections