I am using bookmark in my code and resuming it from other class which is derived from IWorkflowInstanceExtension . I s there any alternative which i can use of IWorkflowInstanceExtension. what is advantage of using IWorkflowInstanceExtension
The IWorkflowInstanceExtension is typically used for activities that require extensions to be provided, without the workflow host needing to define the extensions. Also, an implementation of IWorkflowInstanceExtension is needed for host types that do not provide the ability to define extensions such as WorkflowInvoker or WorkflowServiceHost.
In your case, you are seeking an alternative for resuming bookmarks without needing to go through implementing the IWorkflowInstanceExtension interface. To do this, you can use the WorkflowApplication type to host your workflow, which has the ResumeBookmark method that you can invoke when you want to.
Related
I have 3 different keys in my key-store but I want to use only one of that to configure ssl in Kafka. Is it possible by using aliases, if is it is what is the property that I should use.
I am using spring boot kafka.
Spring delegates to the kafka-clients library.
I have looked at its SslFactory class and I don't see a mechanism to select which key(s) to use.
According to the answer to this question, that's where I would expect the code to be.
It's up to the application to have a way to select which certificate it wants, using its alias name, but it has to load it explicitly itself.
And the SslFactory doesn't appear to be pluggable.
EDIT
Actually I think the code would be in SslEngineBuilder but there is nothing there either.
Does MOQ give access to Castle's DynamicProxy generation? Or are there configurable static methods or something in the Castle namespace that would allow me to tune MOQ's proxy gen behavior?
Some Background
I am Mocking a WCF Service endpoint (IWhatever). WCF automatically adds Async call back options for methods (e.g. IWhatever.DoWork() is also realized as IWhatever.DoWorkAsync()).
I'm looking to use the Mock<IWhatever> object while self-hosting this service mock'd; basically spoof this external web service to my system. However, when [self-hosted] WCF tries to create a DoWorkAsync() method; it already exists... which ultimately throws errors when opening the self-hosted/mock'd IWhatever endpoint. ((NOTE: I don't have access to original contract to use directly)).
Sooo.. looks like Castle DynamicProxy allows for one to define which methods should be generated (see: http://kozmic.net/2009/01/17/castle-dynamic-proxy-tutorial-part-iii-selecting-which-methods-to/). I was thinking I would use to not intercept calls on methods ending with "[...]Async". However I don't see where I would add this customization rule in the proxy generation within MOQ; hence my question.
I have a small app (Win Forms) where I have two different repositories (SQL Server and Redis) both implementing a interface IFilterRepo.
I also have a service class that depends on the IFilterRepo. The client (the Win Form) call the service to access filter data.
I want the client to have two radio buttons where a user can choose which repo to use. And here comes my dilemma. How should I tell the service which concrete class to instantiate as IFilterRepo? I mean, ALL Unity registrations and references to it shall be done in the composition root. Is that "rule" really possible in this case?
This is a common question, and the answer is generally to use an Abstract Factory.
Here is a good article on the subject (I link this all the time, but I didn't write it):
http://blog.ploeh.dk/2012/03/15/ImplementinganAbstractFactory/
As noted in the article, you can make the factory part of the composition root, so that calling container.Resolve() inside the factory doesn't violate that rule.
Edit
You would register different implementations of the service using a name (string):
http://msdn.microsoft.com/en-us/library/ff648211.aspx
myContainer.RegisterType<IMyService, CustomerService>("Customers");
And then your factory would resolve by that name:
public IFilterRepo Create(string myName)
{
return myContainer.Resolve<IFilterRepo>(myName);
}
Edit 2
The question you asked in your last comment is a bit much to answer here, but in brief: your factory itself would implement an interface, and would be resolved and registered via the container.
As a general matter, I would not recommend accessing a repository directly from the code behind--I would at least look at having a layered architecture (or better, an Onion architecture, which works very well with DI).
Finally, I have not done WinForms development in years, but I don't think it fits perfectly with using a container/Composition Root, since you don't have full control over the lifecycle of your objects (you can't inject services into your form constructors). The same is true of ASP.Net Webforms. So you may have to use property injection for your factory and other services needed in your form, or just resolve the factory directly via calling a static instance of the container (container.Resolve()). This is imperfect, and goes against the idea of having a Composition Root, and more toward service location.
You might google keywords "Unity WinForms" and/or "[OtherDIFramework] Winforms" to get some ideas of how to structure your code.
I will try explaining my confusion through the application I am currently developing.
My application (based on Qt5.1 + Qt Quick Controls) interacts with Facebook API to manage a Facebook Page. I am trying to keep the QML code (for UI) as separate as possible from the C++ core.
Now, an OAuth2 implementation is required to be able to interact with Facebook API. For that, I have a C++ OAuth2 class, the constructor of which has the following signature:
OAuth2::OAuth2(QString appId, QString redirectUrl, QStringList permissions);
Now, as the OAuth process requires a browser, I have also implemented an OAuthBrowser.qml, which uses OAuth2 to complete an authorization.
I have the following options to expose OAuth2 class to OAuth2Browser:
Instantiate OAuth2 and use setContextProperty() to expose the instance to OAuth2Browser. However, this means my C++ code has to deal with the UI code. The more baffling issue is that OAuth2Browser is a secondary window. When a user clicks on a "Authorize" window on the MainWindow, then an
AppController C++ object (connected to MainWindow) will launch the OAuth2Browser window. Thus, the instantiation code of OAuth2Browser would go deep down inside a AppController method. It would have been good if only main.cpp had to deal with the window creation.
Use qmlRegisterType(). In this case, I can't pass parameters to the constructor. So, I will have to implement an init() method that would initialize an OAuth2 object. Then, I would call this init() method in OAuth2Browser's Component.onCompleted() method.However, in this approach, I will have to expose QSettings to the UI code - QML window, so that the required parameters to init() method can be retrieved. I have huge skepticism on whether directly exposing application settings to QML UI is a good idea.
Implicitly use QSettings within the OAuth2 constructor. This way, I won't have to pass any parameters, and I would be able to use qmlRegisterType(). However, this means I am doing some magic stuff "behind the curtains". Instead of explicitly passing QSettings instance, I am using it wherever the hell I want to, thus hiding the initialization detail from public API.
An alternative based on the 3rd option was advised on IRC - use an initFromSettings() type of method to initialize an instance if no parameter is passed to the constructor. That way, the initialization is not hidden, and initFromSettings() can confidently use QSettings within itself. Now, I can happily use qmlRegisterType() to instantiate OAuth2 in QML.
So, what is the better approach?
Also,
Is exposing QSettings directly to QML UI a good idea?
I personally prefer qmlRegisterType() to setContextProperty() - that way, the lifetime of a registered class's instance is maintained solely by QML. However, the former is less likely to be used due to the lack of support of parameterized constructors, unless some form of init() is used
explicitly for initialization. Is that a good design?
I apologise in advance for an excruciatingly long post. But I thought it best to ask here.
It's difficult to fully follow your post since it's so long and information dense. Here are my suggestions for what they might be worth.
You want to know what is a good design but you don't specify your goals. You can't really rate something for how well it achieves goals unless you can enumerate the goals.
You're dealing with facebook's api. My crystal ball says change is something you will need to deal with. Therefore putting all the tools into qml may make you better able to respond to change. You can respond to change by rewriting javascript in a qml file instead of a recompile (hopefully). Use properties and the signal/slot design and it should be flexible enough to get the job done. Performance doesn't seem to be an issue.
I would create a settings object that exposes the stuff you want to store. Perhaps using the model/view architecture Qt provides already. The underlying storage, xml file, database, QSettings registry isn't important. You can offer a grid/list to allow users to update their settings if necessary.
Put together oauth and browser tools as objects that will let you script the behavior of the app in qml.
These tools to expose c++ objects might be something excellent to share with the community as well.
Good luck!
I'd like to create a set of custom activities that do work on a shared resource (like a file). These custom activities will be used in a number of workflows, each of which will have this shared resource in common. My goal is to make creating these workflows as simple as possible since each is just a rearrangement of a few basic activities.
I've managed to use an InArgument and pass this resource to each activity but since this is tedious I was wondering how I might simplify it so that the argument wouldn't be necessary.
Also, would it be possible to initialize this resource in one place so that all workflows could assume it already exists?
You can explore the use of Workflow Extensions if you like. Basically you leverage the "Service Locator" pattern.
Define a class that knows how to access/modify this file that you have. Say this class called ResourceLocator implements a IResourceLocator interface. Then when you create your workflow host do this
class ServiceLocator:IServiceLocator
{
public FileStream GetFile(string path){
}
}
//initiate WF host here
host.Extensions.Add(()=>{new ResourceLocator();});
Then from within your custom activities you can do
context.GetExtension<IResourceLocator>().GetFile(pathToFile);
Basically this Extension becomes your means to share common code between workflows. You can split it out in a different assembly and share it between different workflow projects.