We're using ServiceStack within a package that users install onto their Umbraco website. The tricky thing is the users need to be able to add additional methods specific to their implementation.
I'm aware of the ability to pass in multiple assemblies but the issue is we can't leverage global.asax and I believe PreApplicationStartMethod needs to be compiled (so can't be changed).
Can anyone think of a way we can have an overrideable AppHost (or override the default)?
The AppHost needs to be Init, i.e. new AppHost().Init() within the scope of Application_Init event.
As for registering services, apart from scanning the assemblies in the base constructor, you can override what services get registered by overriding AppHost.CreateServiceManager() and returning a ServiceManager configured with only the services you wish to support.
Beyond that you can dynamically register services by using RegisterService either in your AppHost.Configure() or in a IPlugin, e.g:
appHost.RegisterService<RegistrationService>("/AtRestPath");
Related
Short: Is there any way to add a custom ITelemetryInitializer to an AzureFunction application?
Long:
After successfully integrating our AzureFunction application with ApplicationInsights and thoroughly instrumenting our code, it became evident really quickly that we'd need to correlate the various Trace and Request telemetry together. To do this we wanted to reuse a custom property we write to all trace logs called a SessionId.
A quick search yielded this SO post and this Docs article. The problem is that these articles assume I have access to some startup event or to the ApplicationInsights.config file on the server. I could be wrong but I don't believe I have access to either one of these.
So my question is, how do I do this with AzureFunctions?
No, it's not possible to customize that. There is work in progress to allow that, but it's not there yet.
You can see more details on these Github issues
application insights integration - ITelemetryInitializer doesn't have any effects #1416
Unable to access TelemetryConfiguration in DefaultTelemetryClientFactory (App Insights) #1556
EDIT:
It's possible in azure function v2.
There was a question on stackoverflow with problem here:
Custom Application Insight TelemetryInitializer using Azure Function v2
The problem was solved and from version Microsoft.Net.Sdk.Functions 1.0.25 all works fine, more here:
https://github.com/Azure/azure-functions-host/issues/3731#issuecomment-465252591
One abhorrent solution I came up with is to reflect into the ILogger that gets passed to the function to get at the ILogger array it hides inside. Then find the ApplicationInsightsLogger ILogger and reflect harder to pull out the TelemetryClient it uses. Once you get this you can merely set the SessionId property on the client's Context.
This works "great" however not only do I now have reflection in my code I had to downgrade the version of ApplicationInsights package I was using to get the type casting to stick.
Looking forward to better support in the future.
I want to override methods of LayoutImpl in Liferay 7. I tried with service wrapper but there is no option for this class in the Service Name category.
How can I achieve that? Do I need ModelListener for this?
Hint: A service wrapper is used to wrap services. Services in Liferay are usually named ...Service, like LayoutLocalService.
Conclusion: The class LayoutImpl is no service - thats why you can't wrap it with a service wrapper.
You could wrap LayoutLocalService in a service wrapper, wrap the return values in your LayoutWrapper and unwrap the parameters. But that is troublesome and will prevent Liferay upgrades.
If you want to override LayoutImpl for fixing bugs - you should use an Ext Plugin for that.
A ModelListener can only change the content during updates of an article, not the implementation - I don't think that this will help here.
I created service wrapper for UserLocalServiceImpl and declared a new method inside the service wrapper. But when I explicitly call that method using UserLocalServiceUtil the compiler could not resolve this method. So, kindly help me and tell how to override UserLocalServiceImpl so that I can define new methods inside it. Thanx in advance..
This doesn't work. You'd change the interface of Liferay's published API and basically be incompatible with any other plugin that assumes Liferay's API.
While you technically have access to all of Liferay's source code and can build a modified version of Liferay, introducing this change, it would mean that no marketplace plugin (that uses UserLocalService) would be compatible with your customized version. Any OSGi component can hook into Liferay and get into the callstack for the published API, no OSGi plugin can extend a published interface so that the original interface then has more methods than Liferay's published API.
The best thing you can do if you rely on a separate function call: Create your custom service that makes calls to UserLocalService.
Further more, in Liferay 7 you shouldn't use UserLocalServiceUtil any more, rather get the service dependency properly injected through a #Reference annotation. The *LocalServiceUtil classes are there purely for backwards compatibility and to be used only from *.WAR style plugins.
You can do
UserLocalServiceUtil.getService()
and then cast the result to your custom wrapper type. Then you should be able to call the new method.
We want to create general public web services and we create customized APIs.
But how to isolate, version and bind those endpoints as a hyperscaled system?
We want to have:
https://api.domain.tld/v1/..
https://api.domain.tld/v2/..
https://api.domain.tld/latest/..
https://api.domain.tld/bosch/v1/..
or
https://domain.tld/api/v1/..
https://domain.tld/api/v2/..
All endpoints should be isolated. Behind an endpoint like https://domain.tld/api/v2/.. exists at least 3 instances of an ASP.NET WebAPI. We do not want to separate versioning by namespaces inside the WebAPI project and use internal route configurations to resolve this.
We want to have this behavior onpremise and aswell on Azure.
Is there any recommendation or best practise and configuration samples out there?
I could only found one thread here (How to version and configure WebApi with multiple aliases) which is very old and there is no answer.
I always use the version as the api route, like you so:
https://domain.tld/api/v1/..
https://domain.tld/api/v2/..
which has always worked fine, but other use url parameters, which I find to be less explicit:
Visual Studio Team Services - API
I would just not recomend you to go with this pattern:
https://api.domain.tld/latest/..
https://api.domain.tld/bosch/v1/..
It would you make you API look a bit messy, but it could make sense if you use logical services in your API:
https://api.domain.tld/service1/v1
https://api.domain.tld/service1/v2
https://api.domain.tld/service2/v1
I need to implement User lockout in my web application which uses DatabaseServerLoginModule and JBoss5. I am planning to write a custom login module class to achieve this. My next question is: where should I put my custom login module class? After some research I found couple of solutions:
Deploy the login module class in a JAR as a standalone module, independent of the webapp
Deploy the login module class as a part of the webapp in a JAR inside WEB-INF/lib/
My web application will be packaged and shipped to the customer and customers install this package and JBoss separately on a Server. My question is: Where should I put my custom login module class?
Any suggestions will be really helpful.
If I were the data center, I would expect two packages:
One containing the login module
and another one for the real application
Reasons
The data center might have special responsibilities regarding sensitive user data, authentication etc. So in case of a login module, they might even have a special internal review process (this is normally not applied on an ordinary application). In order to avoid this review with each application update, a separate package is preferred. In order to have a quick review, a small package is better.
There might be other applications which use the same login module
A data center must be paranoid: An application which ships with it's own authentication could be abused to install a back door. Again internal or legal requirements may not even allow it.