i'm trying to set up some code that needs access the PerRequest lifestyle. this lifestyle can't be access from within the AppStart of the global.asax.
How can i effectively run initialization code on a wcf service outside of appstart?
this is so that i can configure what documents are versioned in my RavenDb - to do this i have to specify the perrequest ifestyle - doing this in app start throws an exception.
Code that use the PerRequest lifestyle runs by definition per request.
You could split your initialisation code in two parts
What is not dependant on the per request lifecycle runs in Application_start
What is dependant on per request lifecycle runs as the first code in each request
Typically the binding of your ioc containers should be in application_start
Related
I have Integration Tests failing when run at once, but pass if run separately.
The tests are for Service 1 which initializes dependent Service 2. Service 2 receives HttpClientHandler through DI where it sets default behavior (AllowAutoRedirect property).
Due to a test scenario I have to use HttpClientHandler to create the HttpClient in Service 2. (To be specific the call through HttpClientHandler is intercepted in the Integration tests where response content is changed. There is no way to do this through HttpWebRequest and HttpClientFactory. Hence the default behaviour for HttpClientHandler is in Service 2's constructor).
Why am I getting this error when tests are run at once? What is happening twice? The tests work fine separately which is honestly baffling.
System.InvalidOperationException : This instance has already started one or more requests. Properties can only be modified before sending the first request.
Stack Trace:
SocketsHttpHandler.CheckDisposedOrStarted()
HttpClientHandler.set_AllowAutoRedirect(Boolean value)
Have I made a design sin somewhere?
So, I am creating an application which will be using flowable.
We can say that once my application starts, it's gonna start a particular process deployed on flowable, proceed ahead accordingly.
So, in a way there will be lot of talking between flowable and other application, but for now suppose I just want to call flowable applications from POSTMAN (outside FLOWABLE).
I have used 3 modules: flowable-idm, flowable-modeler, flowable-task in my application.
Everything works fine when I am starting my deployed process from UI of flowable task, problems come when I want to start the processInstance using REST endpoint.
In flowable-task application, there is already a REST endpoint to start the process deployed: http://localhost:8080/flowable-task/app/rest/process-instances.
Now, if I call this from Swagger of flowable-task application, it works fine.
But it doesn't work when I try to call it from another application or POSTMAN for now (once POSTMAN call works, I can make the same arrangement in code), where I'm doing a basic auth and providing what's required in body.
Also, there is no error or exception displayed on console, I believe that is because of something catching that error or exception and not displaying anything.
However, to overcome the problem of starting process from POSTMAN, I can use REST endpoint http://localhost:9999/flowable-task/process-api/runtime/process-instances, but this is just a workaround, in future if I create new endpoints I would have to figure out a way to call those endpoints.
I saw this post and I guess this guy was also trying to achieve something similar but for flowable-modeler.
It's been suggested to make changes in SecurityConfiguration.java of flowable-task-conf module for my case, but I haven't done such changes before so not exactly sure where to start and how to proceed.
So, my question is how to talk to flowable-applications from outside flowable applications.
Edit:
Forum post about getting exception when imported flowable-rest module in workspace
The flowable-task UI Application is an example application that exposes non public REST API for the UI. However, the application also exposes the full REST API of Flowable.
There is also the flowable-rest application that has the Swagger doc and exposes the full REST API without a UI.
You would want to communicate with those REST endpoints.
The endpoints are under the following contexts:
process-api for the Process Engine
cmmn-api for the CMMN Engine
dmn-api for the DMN Engine
idm-api for the IDM Engine
form-api for the Form Engine
content-api for the Content Engine
For your example you would need to use POST to /process-api/runtime/process-instances for Starting a Process Instance
In previous ASP.NET versions I was used to create a BaseController inherited from the other controllers and there intercepting the general error and logging each error with a simple logging method and passing the ExceptionContext filterContext.
Should I do the same in ASP.NET 5?
I see in file Startup.cs that there is a if/else statement that basically separate the debug/live condition, with line
app.UseErrorHandler("/Home/Error");
for a production application.
How am I supposed to hook in the process and log the errors?
Handling and logging errors in ASP.NET 5 involves a few elements.
To handle the error in a production scenario and show an error page, the app.UseExceptionHandler() method is the way to go. The Diagnostics repository on the ASP.NET GitHub organisation includes a sample that shows this. For development-time scenarios where you want to see a full stack trace and other diagnostic information, use app.UseDeveloperExceptionPage() as seen in this sample.
If the application is using ASP.NET MVC 6, then there is an MVC-specific way of handling errors, much as there was in earlier versions of ASP.NET MVC. In ASP.NET MVC 6, a filter (or the Controller itself, which is also a filter) can handle/override the OnActionExecuted method and inspect the ActionExecutedContext parameter to attempt to handle the error.
When it comes to logging, there's a new logging infrastructure in ASP.NET 5 that reports a great deal of information to any registered ILogger. The default project templates in Visual Studio 2015 register some loggers that log errors (and other data) to the console and the Visual Studio debug output window. However, when running in IIS or IIS Express there is no console window (yet!). But if you run from the command line (using dnx web) then you'll see the error. Or, of course, you can register a different logger that writes to a log file or database and see the logs there.
To register a custom ILogger in a web app:
Write a logger that implements the ILogger interface. See the DNX implementations for how to do this.
Add a parameter of type ILoggerFactory to your app's Startup class's Configure method.
In the Configure method call loggerFactory.AddProvider(<some provider>) and pass in an instance of your logger.
I know all about the AspNetCacheProfileAttribute. But is there any way to hook into the cache programmatically? I've tried using Response.Cache in global.asax which seems to set the correct client-side headers but the response is never cached on the server.
I don't think you can do it unless you build your own solution. I just checked implementation of AspNetCahceProfileAttribute which only add internal CachingParameterInspector to the operation dispatcher. This has two problems:
Parameter inspector is assigned when the service host starts = during first request and until that it cannot be changed
Parameter inspector is initialized in its cosntructor by reading cache configuration from the web.config file based on the profile name passed to AspNetCacheProfileAttribute
There is no API available to modify already assigned and configured parameter inspector
I created WCF web service, deployed it, and debugged it. I wrote a console app, referenced the web service, and everything works.
Now, I'm attempting to consume the web service in a silverlight 3 application. I added the following code to a click event.
TagServiceClient client = new TagServiceClient();
Tag[] tags = client.GetTags();
client.Close();
VS is telling me it can't find the GetTags() and Close() methods. But VS has no problem with these methods in the console app.
I added a using statement for the service reference to the top of my file.
I placed a clientaccesspolicy.xml file in the root domain and in the folder containing the web service. Doesn't seem to change anything regardless where it is.
What's going on? Any suggestions? This is my first time consuming a web service in Silverlight so I may just be missing something.
You will need to generate a new client proxy to use in the Silverlight app - IOW, from the Silverlight app, add a new service reference, and point it to the service.
You will then see that things are a little different - you will find that there are async methods in the proxy, not the synchronous ones you will have seen in the proxy generated for the console app. So in the silverlight app, your code will end up looking something like this:
client.GetTagsCompleted += [my event handler];
client.GetTagsAsync();
and in your event handler:
if (e.Error == null)
if (!e.Cancelled)
List<Tag> tags = new List<Tag>(e.result);
When you add a the service reference to the silverlight app, make sure you have a poke around the advanced settings, because you can change what sort of collection the items are returned in, etc (the default return collection is an ObservableCollection<T>).
If you want to avoid this sort of thing (different proxies for different apps or modules), then consider using svcutil to generate your proxy instead of allowing VS to do it (VS doesn't use svcutil).