Recently I started with Corda and am a bit confused about this point.
I have a state which needs to initialize a party with some default values.
How can I do that?
Actually I have a state which accepts a party as an argument. And I
want user to give the option to choose the party. so to define the
state's constructor I need to set it to some default value. Correct me
if I am wrong. I am new to Corda
I am answering this on based of your above comment.
Look into this example: https://github.com/corda/cordapp-example/blob/release-V3/java-source/src/main/java/com/example/state/IOUState.java
It's also storing Party in State and there is no default Party defined. It's accepting Party as constructer and assigning it to the class variable.
Take a look at the definition of Party.kt in Corda and you'll see that a Party is constructed from an X509Certificate.
Could you elaborate on why you need to initialize a party with a default value? Parties should already be defined on the network and you can find obtain a reference to them by querying the networkMapCache.
In addition, you can fetch your own Party identity within flows by calling ourIdentity or using the serviceHub.
Related
I am using the NamedScoped Ninject extension in an attempt to create object graphs that are constructed everytime a command handler is constructed by the container. In other words, I want a fresh object graph for every command that might get processed by its corresponding handler.
I have used the .DefinesNamedScope("TopLevelOrhcestrator") binding when registering my "command handlers" as they are the top level for command processing.
A type in this named scope needs to be injected with the result of a method call on a type already registered in this named scope. I thought the best way to do this would be with a ninject provider.
Inside the provider I attempt to resolve the type in hopes I can call a method on it to pass into another object I am creating within this named scope. The problem I'm having is that when I ask the IContext for the instance inside the customer provider I get an exception that says "No matching scopes are available, and the type is declared InNamedScope(TopLevelOrchestrator).
context.Kernel.Get<TypeAlreadyRegisteredInScope>().MethodThatGetsAnotherDependency()
Is it possible to get types from the container inside a Ninject provider when they are registered inside a named scope?
EDIT
I apologize if the use case seems a bit odd, I am experimenting with some ideas about how to manage my units of work and other services/managers that may need a handle to the uow to complete a business usecase. I know its common for the unit of work to be "started" and then passed into all dependencies that may need to take part in a larger process. I was thinking I'd rather let my orchestrator take a unit of work factory so that it could deterministically destroy the UOW and it would be clear who the owner of a usecase is. What would get supplied to the managers/services would be a proxy to the unit of work that would be null until a real unit of work was started by the orchestrator. That's why I was attempting to link the proxy from the already registered type in my provider. This is all very experimental at this point and was testing some ideas.
I'd be happy to hear any further thoughts.
For MethodThatGetsAnotherDependency() to be able to .Get<>() an instance that is bound .InNamedScope(...) you will need to add the Context Preservation Extension.
This is because NamedScope is adding a parameter to the request context of the binding that has .DefinesNamedScope(...). As soon as that request is over, that context and it's parameters are forgotten. Now with the ContextPreservation extension the context is kept and reused for late / factory creations (Func<>, interface factory with .ToFactory() binding...). It think it should also work with providers.
If not, just switch to a factory instead of a provider.
However i have to admit that i don't fully understand why/what you are trying to achieve. There might be simpler ways.
I'm in charge of a WCF service. Our client has requested an override feature: If a call is resubmitted, allow the operation to proceed despite warnings. I need a way to persist data from recent calls so I can detect a resubmission. I thought making the service durable, part of WF3, would resolve the problem; however, my service uses .NET 4.5 which marks WF3 as obsolete. I've been trying to find the WF4 equivalent, but nothing's clicked for me. All the examples presume a workflow which I lack.
What is the best solution for my needs?
Edit:
According to this question, a static variable should meet my needs, but I haven't been able to get one to persist between calls.
A static variable did meet my needs.
I used a property to interact with my static variable, and in the getter I would remove some of the old data. For some reason, having that call in the getter prevented the static variable from persisting. I relocated the clean up code (incidentally I didn't need the property anymore), and the static variable persisted.
I am building an open source library to interact with a public API. The API validates all data passed to it and on failure properly returns a non-200 status code and usually a failure message causing my library to throw an Exception.
Some of my methods do check for required parameters, but mostly I have decided not to validate the data before passing it to the API.
Should a library for an API also be validating the data? If so, to what extent? Should it attempt to fully validate all data or just verify that required parameters are present/not empty?
The rule has two parts: on input, be an accepting loving grandmother: take what the caller gives you and don't be a stickler about the interface convention in places where it makes little difference; or where you can supply reasonable defaults. On output, follow the convention to the letter: be a strict pedant, a martinet.
So, in my opinion, the answer is yes, you should check your caller's input and give the API the best data you can. But this does not necessarily mean you should duplicate validations that the API is going to do anyway.
You have to use your head and think about what makes sense.
I have a WCF service that supports about 10 contracts, we have been supporting a client with all the business rules specific to this client now we have another client who will be using the exact same contracts (so we cannot change that) they will be calling the service exactly the same way the previous client called now the only way we can differentiate between the two clients is by one of the input parameters. Based on this input parameter we have to use a slightly different business logic – the logic for both the Client will be same 50% of the time the remainder will have different logic (across Business / DAL layers) . I don’t want to use if else statement in each of contract implementation to differentiate and reroute the logic also what if another client comes in. Is there a clean way of handling a situation like this. I am using framework 3.5. Like I said I cannot change any of the contracts (service / data contract ) or the current service calling infrastructure for the new client. Thanks
Can you possibly host the services twice and have the clients connect to the right one? Apart from that, you have to use some kind of if-else, I guess.
I can't say whether this is applicable to you, but we have solved a similar problem along this path:
We add a Header information to the message that states in which context some logic is called.
This information ends up in a RequestContext class.
We delegate responsibility of instantiating the implementation of the contract to a DI Container (in our case StructureMap)
We have defined a strategy how certain components are to be provided by the container:
There is a default for a component of some kind.
Attributes can be placed on specializations that denote for which type of request context this specialization should be used.
This is registered into the container through available mechanisms
We make a call to the Container by stating ObjectFactory.With(requestcontext).getInstance<CONTRACT>()
Dependencies of the service implementations are now resolved in a way that the described process is applied. That is, specializations are provided based ultimately on a request information placed in the header.
This is an example how this may be solvable.
If I have an object that holds the parameters for my method. I need to change the Object to have an additional property. I have full control over the server, but not over all of the clients. Will this change make those clients break?
I am using a self-hosted service with a binary endpoint.
I am new to WCF so my apologies if this is a silly question.
I guess you are asking about a class that represents your DataContract.
Learn about DataContract versioning and how various changes in your DataContract affect the compatibility in MSDN
In short the answer is No, it will not break the client code. The serialized graph of the data contract will deserialize to the available data members matching by their names and assigned through the property setter method. Obviously in this case, your newly added data member will not have value. Since you have full control on the server side code, you just have to make sure this newly added member need to be dealt in such a way that it is meaningful in the new implementation and allow for default/unassigned value.