Changes needed for 7.00.177.00 compatibility

[Mike.Sheen]

Hi everyone,

You can't make an omelette without breaking a few eggs.

Our next release (7.00.177.00 as a development build) has made some changes which will almost certainly cause issues with your code or plugins using our assemblies.

We've outlined the required changes you will need to make in this article: How to convert plugins or code to be compatible with 7.00.177.00 or later.

Fortunately the changes required are fairly simple, and in some cases no changes will be needed at all - but it is very likely you will have to make some changes to your plugins or applications.

We'll be updating the article as needed, so check the article if you are having issues even if you've already read it.

All of our standard plugins that ship with the product will be updated upon upgrade and will be compatible with the changes.

Our next public release which includes these changes will be versioned 7.01.00.00 - this will be when we have fully tested the product, and the REST API is ready for commercial use.

Thanks,

Mike

[Mike.Sheen]

Topic changed to sticky from announcement to allow comments.

One issue reported by forum user SBarnes was relating to problems importing plugins - DEV-5763 - Thanks for the feedback - we're working on a solution.

If any problems are experienced, please report them here or create an issue on the helpdesk.

[Mike.Sheen]

DEV-5878 adds back the singleton Instance property to the JiwaApplication.Manager class to ease migration pain.

The property is marked as obsolete and will be removed in a future version.

Plugins or applications using the JiwaApplication.Manager.Instance property will not function correctly when invoked in the context of the REST API.

[SBarnes]

Hi Mike,

with the new Rest API will it be possible to use other features of ServiceStack such as logging, filters, caching and validation etc, obviously this would be in reference to Custom Routes through a plugin not necessarily for what will come out of box with the API itself?

[Mike.Sheen]

with the new Rest API will it be possible to use other features of ServiceStack such as logging, filters, caching and validation etc, obviously this would be in reference to Custom Routes through a plugin not necessarily for what will come out of box with the API itself?

Logging requests we've already implemented - as can be seen here. This was really simple for us to implement - a 2 minute addition thanks to the flexibility of ServiceStack. We currently just use a request filter to log to rolling CSV files, but any logging provider can be used instead (SQL or event log, for example).

Any feature of ServiceStack can be turned on or off via plugin - logging, filters, caching and validation.

We've recently updated to SS 4.5.8 which includes OpenAPI (Swagger 2.0) - that's yet to be in a dev build but we'll be doing one soon once we've overcome our current obstacle - a memory leak somewhere in our framework in the REST API Plugin - which was uncovered by our unit tests on the REST API. How we do the server side part is exposed as most of it is simply a plugin - every route is in the plugin - our service we provide, or the alternate IIS package is simply a few lines of code to login and invoke plugins implementing the REST API interface.

[SBarnes]

Hi Mike,

All I can say is very cool and looks extremely promising.

The more I look at ServiceStack the more impressed I become with it, originally for another web api project I began looking at it on the theory of why learn two frameworks but the more I look at it in terms of the flexibility and functionality that ServiceStack offers the more impressed I become.

One resource I found useful on ServiceStack as a starting point as it works through a small but simple example that others may find useful can be found here https://www.syncfusion.com/resources/techportal/details/ebooks/servicestack

I had originally liked the improvements Jiwa 7 and plugins offered over what you could do in Jiwa 6 but this will increase the possibilities monumentally in terms of not only the web but also mobile and the cloud in terms of integration.

I have no doubt It will make the "growing pains" of plugin changes worthwhile in the end but thanks for buying time for all of us on this as I know that added to your already busy workload.

[Mike.Sheen]

The more I look at ServiceStack the more impressed I become with it

I was originally exposed to ServiceStack because a customer wanted to integrate with a 3PL which had a REST API built using ServiceStack. After some initial testing using the ServiceStack client to consume the 3PL's SS API, I realised pretty quickly this was a very friction free way to integrate.

The 3PL's ServiceStack API implementation wasn't that great - but I could see the potential and dug deeper into what ServiceStack was all about.

I too, became more and more impressed with ServiceStack and the philosophy behind it over time - so when we were tasked with creating a REST API I revisited ServiceStack and came up with a POC (proof of concept) using that framework. When the ServiceStack POC was compared to our Web API 2 POC it was pretty obvious to me that ServiceStack was the better option.

We - of course - had to make substantial changes to accommodate the ServiceStack philosophy (dependency free DTO's for example) - but that effort is going to pay handsome dividends in the future.

this will increase the possibilities monumentally in terms of not only the web but also mobile and the cloud in terms of integration.

I'm so glad someone else understands this! It's certainly a watershed on the Jiwa development timeline. It's now the basis for a significant part our future development - which is moving to mobile and web.

I have no doubt It will make the "growing pains" of plugin changes worthwhile in the end but thanks for buying time for all of us on this as I know that added to your already busy workload.

You're welcome

[SBarnes]

Hi Mike,

I have a quick general servicestack question, that I am hoping you might be able to help with, I believe you have stuck with using servicestack's bundled orm, ormlite was there any reason for this and did you at all look at using say the Entity Framework or an alternative?

My other question is are you using the T4 templates to generate the classes or is there another way to do it?

Thanks in advance for any help.

[SBarnes]

Hi Mike,

Further to the question above will there be any way to use the razor view features of servicestack with the web API as well?

[Mike.Sheen]

I believe you have stuck with using servicestack's bundled orm, ormlite was there any reason for this and did you at all look at using say the Entity Framework or an alternative?

We use ORMLite purely for convenience as it uses simple conventions to allow filtering, sorting, et cetera. We don't use ORMLite for all operations - the POST, PATCH, DELETE and most GET operations actually use our business logic.

Only when you want to get a list of something with filtering and the like do we use ORMLite to be the mechanism of hitting the tables in the database.

We did look at EF, but given ORMLite is built into the ServiceStack ecosystem so nicely and that with EF you can't have strongly typed client requests for the filtering we decided to stick with ORMLite for the querying aspects.

My other question is are you using the T4 templates to generate the classes or is there another way to do it?

We do use the T4 templates to generate the classes used by ORMLite. The T4 is run against a model database (The JiwaDemo database we ship with) every time our JiwaServiceModel.dll is compiled.

will there be any way to use the razor view features of servicestack with the web API as well?

I'm hoping so - I had a tinker with that and whilst it's not really within the scope of the REST API's purpose, it wouldn't do any harm to have us ship with the ServiceStack Razor plugin. We probably won't initially provide a mechanism to store the pages and support files in the database - but that would be an ideal goal - so initially you'd have to deploy the cshtml/css/js files manually to the folders under the JiwaRESTAPI service, or the IIS web server if you're using that option.