Servoy tech webinar series 12: The art of WAR deployment

The broadcast is now starting all attendees are in listen only mode. Hello and welcome to yet another 30 minutes with your boy. I am Stephen Portanoi. Yawn is on a business trip. Just happens to be in Hawaii. So I’m filling in as moderator. Let’s see. I think. Sean, are you showing your screen? I’m having an issue. It’s not letting me. I think it was maybe started the poll. Let me close the poll right now. Yeah. Yeah. So we’re going to try something today’s webinar is about board deployment. Before I get too much into that, let’s talk about Servoy world. Servoy world is approaching fast may 17th to the 20th in Amsterdam at the beautiful hotel. We’re running out of space very quickly. So if you haven’t yet signed up, please go to Servoy.com and follow the links and get signed up. It’s going to be a really, really great Servoy world this year. We have a lot of good stuff already on the schedule. If you go to the next slide, there you go. A couple of pre and post classes and training. For all kinds of things that are really, really exciting stuff. So with that said, like I was saying earlier, today our webinar is about word deployment, the art of war deployment with Sean Sue. And we’re going to do a poll. I started the poll, which you some of you already saw. I think what we’ll do is in the last few minutes, because apparently the poll pre-empts, the slides, we’ll put it up again and get some ideas of who’s done the word deployment and who is only tried it and who has yet to try it. So we’ll do that at the end. And right now I will hand it things over to Sean. Okay. Thank you, Steve. So today we’re discussing word deployment. This is the 12th webinar in our biweekly tech series. Number 12. And we’re trying to keep it mixed of topics. Some that are relevant only to web components. Some about just new open source modules that come out. Some are around best practices. So today we are finding ourselves on word deployment because we’ve had some feedback about about this subject. Maybe it’s not as intuitive as it should be or easy to get going. So we’re trying to help with that. Again, this is like a best practices webinar. Not really meant to be a training, mostly meant to show you what’s possible and where to find more information. That said, we might go a little bit over our usual 25 to 30 minute mark because it is a bit of a bigger topic. And on the agenda, I want to do a quick overview. I’ll just do a few hundred slides. And then, and then, and then, and then, and then, and then, and then, and then, we’re going to do a demo. And for this demo, I actually want to go through not only deploying a War file, but actually installing a Java app server and configuring it before we do the word deployment because I think that’s where a lot of the sticking points happen. But during the demo, we’ll go over the installation, the configuration, we’re export and deployment and some troubleshooting and odds and ends. But quickly, let’s just talk about word deployment in general for those who are completely new to the subject. War stands for Web Archive, and it’s a way of packaging a whole web application and deploying it to any standard Java enterprise container or app server. So you may have heard of some of the, these servers before Apache Tomcat, you probably know because that’s, that’s the web server that, that all prior versions of Servoy have deployed on a modified version of that Apache Tomcat, Jetty, Glassfish, J-Boss, any of those qualify as a standard Java container. So which, which one should you choose? Well, if you’re new to the subject, I recommend Tomcat or Jetty, because those are just the web server portion. The Java, the JEE spec encompasses a lot more stuff. So if you’re already using J-Boss or one of, you know, WebSphere or something, you can go ahead and deploy a server application on those. Otherwise, I would say skip, you know, some of those because they’re, they’re bigger, they have a bigger footprint, they’re more complicated configured and they’re meant for, to also include things like enterprise Java beans and, and such. So Tomcat and Jetty are the way to go. So again, when you’re choosing one of those, one of those containers, for the NG client, it’s important that, that they support web sockets. So you just want to pick a version that is later than 743 from Tomcat or Jetty, 91. So you get the web socket support. So quickly, what’s the difference between a dot war file and a dot Servoy file for those of you who have experienced just exporting an application in Servoy, you get that dot Servoy file and you import it to a running Servoy application server. The difference with the war files that it includes everything else, all of the dependencies from your application and the configurations. So normally you do this manually in Servoy, you actually install, or sorry, in dot Servoy deployment, you actually install the Servoy application server, you upload, drivers, beans, whatever dependencies you might have, and then you do the, you do the export after you’ve, after you’ve managed everything else. So what’s in a war file is, first of all, the most important thing is Servoy itself. The, the Servoy application server is not the same as, as the Java application server. So now you can package Servoy and deploy it on, on any server. So all the Servoy lives, any plugins, beans, drivers, sort of Java dependencies that you have there, any server properties that you might want to configure. For example, database connection, configurations, a server plug-in configuration, etc. You can, you can package that up in, in the word deployment. Web components, ng services for ng client, additional res, web resources like CSS and image media, etc. So why would you want to pick a word deployment? First of all, if you want to run the ng client, you kind of have to. But even if you’re not using the ng client, there’s some advantages to it. One is that there’s zero Servoy installation or upgrade. It’s part of the war file. So you don’t start off by installing Servoy. You just have a generic Java container and the war file contains Servoy. So that’s, that’s easy. You pretty much remove the manual step to manage all of the dependencies. You can package that up in the war file. So it’s very convenient that way if you want to update a plug in or a bean or some other dependency. Another thing is that you can run multiple separate applications on one container. So you can have two different versions say of the same, the same application running on at two different, they’re called context, two different web context. And I think it’s important to point out that that the Java app server and the war, the web archive spec are very standard based. So this allows you to now deploy Servoy applications on a really standard space environment. So you can integrate with, you know, the rest of the enterprise or cloud infrastructure. Say you’re using something like Amazon, a bean stock, for example, to, to scale out web applications. It’s going to be able to just handle your war file and scale that for you. A couple of things to note, server downtime. So if you’re doing dot Servoy deployment where you have the, the Servoy application server already running, you may, well, maybe you never noticed, but you just took it for a little bit. You just took it for granted. You don’t actually have to turn the server off to, to do the, to upgrade your, your Servoy application. Well, with word deployment, the, the war, the web archive itself is read only. So you actually have to take the application offline, not the full Tomcat server, just the application offline momentarily. Well, you, well, you update the war file. A couple other things that are gone for the same reason is the upload library. So you may remember this from, from the web admin page for the Servoy app server. That’s gone because now it’s all managed through the war file. And again, a running web archive is read only. So you have to redeploy to manage those dependencies. Also, no web dev. This is for editing web client templates on the classic web client. That is also not supported again because the running archive is, is read only. Okay, so let’s get to the demo. I’d like to start with actually downloading and installing, we’re going to work with Tomcat for, for this one. So to save some steps, I already downloaded, but I’m just sort of showing the web page with where you would find the latest version of Tomcat. Tomcat’s on, on nine, but I’m using the eight five one here. I think nine requires Java eight and higher, which I have installed, but I didn’t want people to assume that they should go and get nine because maybe they’re running a bit older version of Java. So, so I start with a five here. I’m running windows and I want to install Tomcat as a Windows service. So there’s a lot of options here for what you can download. And this, this demo is going to be focused mainly on on a Windows service set up. We do have additional documentation that my colleague has prepared about, say, doing Ubuntu Linux, but this will just be focused on Windows. So, so I recommend that you get the, the 32 bit slash 64 bit service installer. So this will identify correctly the, the bit depth of your operating system and install the right version for you. So once you download that, you can run it and I have. You’re already in my downloads directory. My Apache Tomcat installer. So I’m going to take you through the installation right now and point out a few things along the way. Yeah, we get through all the server, the license agreement here. So right off the bat, you have to make some choices about what to install. So I’m going to take turn off documentation here because I don’t really need it. If you’re running a sort of a test server, maybe you want to leave that on there because it does include hyperlinks to documentation right on, right on your, your web application. So you could leave that up. For production server, I would, I would take that off. I am going to leave manager on there because that’s, that’s an actual web application to manage Tomcat. So that’s nice to have to have open. I wouldn’t install the examples for production server also. It will slow down startup time. So now we can do some of the configuration. The very first thing that that I want to, that I want to handle is the port number. The default port as you probably have learned from the past because we already used Tomcat for all prior versions of Servoythe default port is 8080. I want to change that right here because I want to run Servoydeveloper on the same machine, which is already running 8080 so I don’t want that port conflict. I’m going to set it to 8085. We can do this right here on the initial installation, but at any time you can configure this. So I’ll show you how to do that in a little bit. Also, we want to credentials for the Tomcat manager web application. Also, just the regular administrator login. So I’m going to go ahead and give it username and password here. The roles here manager GUI, that’s important because that allows you to also access the manager application. Again, you can set this up one time here, but I’ll show you where you could reconfigure it later. The path where we’re going to install, sorry, the path where it’s going to find the JRE if I have multiple run times installed. It will give me a choice. This is where I’m going to install it at and so now it’s running. Okay, when it’s done, I can actually run Apache Tomcat and what this does is it starts the Windows service. Okay, so now it’s running. How do I find out if it’s working successfully? Pretty simple. I come into my browser and I want local host 8085. Okay, so it worked. If you see this page, it means you installed it successfully. This is the main root application. You also see that there’s a link here to the manager app. So when we get into deployments, I can do that. So that that’s installation. It’s pretty easy. Let’s talk a bit about configuring the service. If I want to configure the service, there is a startup I can menu. You can see recently added configure Tomcat because I did choose the start menu options when I installed. So it brings up this configuration wizard. If I didn’t include that, it’s pretty easy to find. I’m going to go into my Tomcat installation into the bin directory where all the executables are. And it’s this Tomcat 8W exe file. So that’s just a shortcut to year. So if I double click that, I get the same thing. All the executables are in the bin directory of Tomcat 8.5. So let’s look at some of these options. First of all, I may want to change the startup type from manual to automatic. So now it actually would start every time the server machine starts. So if I was running this in a production environment, I would probably set that up. The log on, this is the same as when you’re configuring a regular window service. And you can choose what account you want to use. So right now the default is the local system account. I’m going to leave that there. But quite commonly on production environments, people have a dedicated user account that runs a that runs their Tomcat and maybe other services. So you could go in here and specialize or specify a different account. I also want to make note of the logging. So by default, it’s going to go under the Tomcat logs directory. You could change this so that it logs somewhere else. Also, you could you could change this to a log to a location where the actual service user has right access. Sometimes you see problems with Tomcat installations because the windows service user account doesn’t actually have right access to some of the file locations of the installation. Usually people saw that by just granting permission, but sometimes they actually go and move stuff around. So this is where you could do that. You could also change the log level here. So if you want to run the service for a little while and put it down to a debug level for the Tomcat logs, not the Servoy logs, then you could do that here. So there’s a couple of things here that we would want to work with. First of all is memory. You can see that the initial mem size and the maximum size are not that big. If I was really running a production environment, I probably want to put this up. If you’re running 32 bit windows, keep in mind that you have that two gig limit. If you’re running 64 bit windows, you can go above that. If you get up, I think above the four gig limit, I think it is. Then you probably want to put in some options for using a different garbage collector. And there’s documentation on our wiki about that. But for right now, I’m just going to leave it the way it is, but if you wanted to change, change your memory settings you do it here. Also keep in mind those memory settings are for the entire Tomcat installation, which may be running multiple web applications. So maybe not just your Servoy applications even. So this is not the same as the Servoy memory settings, which happened within the same Java virtual machine as this. Another thing to note is these Java options. So here you can pass in parameters to the Java runtime as it’s starting the Java virtual machine that runs Tomcat. And there’s one option in here that’s worth pointing out that I’m actually going to set. and it’s the it’s the Servoy, it’s the Servoy user directory. This is you can find this on the wiki page, but I’ve copied it and pasted it here. It’s this D Servoy user home. And I’m going to copy and paste that into. Into my properties here. By default it’s going to it’s going to find the the home directory of the of the user that’s running Tomcat. In this case, it’s a local system account. So it actually puts it in a weird spot in like the windows 32 directory probably where you’ll never find it. So I’m going to go ahead and set this up front. This is kind of an important step. So that I can easily find where this stuff goes. If you don’t remember to do this, it’s okay, you can always go back and change it also when you’re running Servoy now in the on the admin page. It shows you where the the Servoy user home directory is and that’s where your properties get stored and some of your logging goes. So that’s why we’re pointing this out. So I’m going to click apply so that that saves my settings back to general. I could actually stop. And and start the service and that will that will put everything into effect because I won’t get that that logging or the sorry that user home directory changed until I restarted the service. All right, so. Now let’s talk about the war export itself. For this we go into Servoy developer. I’ve created a little hello world application. It’s pretty simple. It has a label on there that says hello world. And I want to generate the war export. Right click the active solution export solution right below the classic dot Servoy export. You’ll see the dot war export. And I’m going to browse and pick hello world dot war. Save that. First thing when you name the war file. That will also be the name of your context which is Tom cat speak or Java app server speak for your web application. So that’s important because that will actually be the URL. In the URL when you when you deploy this so this will be at you know slash hello world slash you know and then all the Servoy stuff. So you probably want to pick something that you want to keep and you want to keep it consistent once you go into production. You can also name this the same as the root context so that you don’t have that it just starts right at wherever the path to the app server is right from there. So that’s that’s probably the most common thing to do in production and I’ll show you how to do that at the end. So everything that’s here is is the same as the dot Servoy export all of the the options. So I’m not going to spend time going through those I want to point out there are a few extra that you want to keep in mind. First one is include the active solution. Why would you ever do an export without the active solution and its modules. Well that goes back to what a war file is and how it’s different from a dot Servoy file keep in mind that the war file is all of the Servoy libraries all of your dependencies etc. If you just want to install and set up your Servoy environment without actually exporting the solution with it you can do that just don’t check that box and then you can still send up all of the libraries and build the Servoy app server. In this case we do want it so i’m going to check it. The next the next thing worth pointing out is the automatically upgrade repository if needed option. This is important because again you’re doing things all on one step with a war file so if your repository is not built or if it’s built to a lower version and now you’ve upgraded your solution you can upgrade the repository in this step. Personally i always check this i don’t see much of a reason not to unless you don’t want to accidentally upgrade your repository because you went to the wrong. The wrong endpoint or something. And then the next option down is also new and it’s it’s totally just related to tomcat. It says create tomcat medit if context XML what the heck is that every web application has its own configuration XML file in tomcat. And so here you can actually push some properties to configure this application specifically. And so you can enable this and then you get these check boxes enabled. I won’t go into too much detail about these. I would just say the first one anti resource locking that comes up more frequently than the other ones because sometimes a war file can’t be undiployed because some of the resources get locked. So if you check this it’ll allow it to. It’ll allow it to undiploy things more easily so if you ever get warnings in your your tomcat logs then you can go in and have a look at it sometimes I see it with drivers drivers can’t be undiployed. So this can do that anyway any of this stuff could it could be configured manually to. On tomcat so you don’t have to do it here but you can push those up if you need to from here. I’m going to uncheck that one and finally there’s the minimize JavaScript and CSS so. Of course it makes sense to make your code based smaller by minimizing JavaScript and CSS and. So if you’re going to use that for you. I’ll do that in the export for you. Unless you’ve already you’re already working with say a web component that has minified resources then then it doesn’t make much sense. But ideally you do this you can run off. Unminimized JavaScript and CSS in developer because it’s easier to debug in the browser. But when you go to a production environment. You can you can export minimize stuff. So that’s the next the next step so remember I said the plugins beans all that stuff can go up with it. So here you could choose any of the plugins that are in your development environment and include them. For my hello world example I’m not using anything so I’ll uncheck that same with the beans directory. I have a bunch of stuff in there but I don’t need it for this example. Look and feels looking field files are for Java swing stuff so that is the smart client. You can include those as well. Database drivers you need to have the HSQL. Excuse me that’s required so that you can’t uncheck. I’m going to deploy to a postgres database so I’m including that. Okay web components. One thing that’s really nice about the exporter is that it’s going to look at your solution. And it’s going to recognize the dependencies you have on web components and it should put them over in the exported column automatically. I’m not using any web components. Other than the Servoy default ones and also some of the Servoy core stuff gets included. You always want to include that the Servoy core stuff. So anything that you have installed that’s referenced will get picked up automatically. Usually you can just click next through this unless there’s some extra stuff you feel like you need to add. Same with the ng services. Okay so this is the default admin user for the the Servoy admin page. So you can set this up so you can actually log in and configure Servoy itself. All right. The remember that when you deploy Servoy application there is that Servoy properties file that you manage on the server. This allows you to pick browse to a Servoy.properties file that you can set up in advance to push up with your deployment. This can have everything that you need in a database connections server plug-in settings. Smart client memory settings, network settings, whatever it might be are included in that properties file. If you don’t, if you don’t do this then a default one will get generated and then you can still manage your server from the admin server page. But this will this will push up initial configurations that you want. I’m going to leave this blank and go through the next steps which will walk me through building database server connections. Of course if you want to run the smart client you can set up the ROMI registry. If you’re not doing any smart client stuff I recommend you uncheck this. You don’t need to. Licensing, we’re going to skip that. All right so here it’s recognizing that I have referenced to two databases. We’re really one database example data but just like in traditional deployment you still have to connect to a repository database. So that’s required. So now that I’ve selected my database servers it’s going to walk me through the configuration of those. So again this is not the connection to the development database. This is now the connection to my production database or wherever it’s going to be relative to the app server machine. So it might not always be local host, it might be an internal IP address or a host name. In this case it is local host but you’ll notice that I’m running 5433 which is not the default postgres port. If you look at my database connections inside Servoydeveloper they be on a different port. So I’m actually running two instances of postgres one being my simulated production database and that’s at port 5433. So I set up the configuration for my databases here. So it’s already filled in is because I did this once to practice for the webinar. So it conveniently remembers the last values that you put in so it’s very easy to just kind of cruise through this and if nothing’s changed. So we do the example data the repository database and click finish and now it’s starting to build the war file. So now the war file has been written. It’s really just a big zip file that has everything in it and now I just need to put it up on a patchy tomcat and it will be deployed. There’s two ways to do that one is manually by copying it and pasting it there and the other one is through the manager. I’m going to go ahead and take you through the manager version first and then we’ll look at how to do it manually as well. So this is the tomcat manager app you can see that it’s listing the current applications that are running which are the root and the tomcat manager web application. What I want to do is is add mine to that list. So I’m going to go down to the word employment section. I’m going to find my hello world dot war file and I’m going to click deploy now this is going to fail. And I’m set it up this way on purpose so that we can troubleshoot it rather than it succeed and then so I give you a real world example because this is the most common problem that I see. So we click deploy. It’s taking a minute while it uploads the file. Now you can see that it did deploy it. But it’s not running and this confuses people a lot that hey I deployed it but then when I go to the URL that should be my solution I just get a 404 not found or I try to start this and it doesn’t start. So what do I do how do I troubleshoot this and this goes back to where that log file is stored and this is the most the reason I did it this way is it’s the most common problem that I see. So let’s go ahead and troubleshoot this. More than 90% of the time I think in word deployments when there’s a problem it’s because of connection with the repository database that’s required to run and I forgot. Well I didn’t really forget but I’m pretending I forgot to set up my databases. Maybe it was at a different location or something. So here’s my postgres I database I haven’t created a repository or the example database yet. So how would I figure this out? Remember when we configured the extra Java option where the home directory is going to be. I set that to be in the Tomcat 8.5 directory a directory called Servoy. So there’s no from not normally a Servoy directory inside Tomcat I put it there. You could really put it anywhere. So if I look in here there’s a dot Servoy directory and then there’s a server folder and then there’s going to be one folder for every contact to every web application that you’ve deployed. So there’s my hello world. So it did deploy my hello world application it just doesn’t start. So when it tried to start it it wrote to the log file in this directory and now I can go in and look at this and say, oh, can’t start repository error checking repository. Servoy doesn’t start any database and farther down I should see something. Servoy repository does not exist. Oops I forgot to set up my repository. I found that out by looking at the Servoy log file. So that’s that’s the easiest place to go and look for it. If for some reason your application doesn’t deploy. So you don’t even get this directory is written. You don’t even see in Tomcat manager that it’s listed here. It would just say it failed. Well then there’s no Servoy log file. That’s the next most common error that I see is that it didn’t even deploy the war file. So there’s no application. So then you have to go into the Tomcat logs and that’s in a different location. That’s in Tomcat logs convenient. Remember that was also a configuration option at the beginning. I didn’t change that I used the default. And the Catalina log is like the core Tomcat log. And so that’s where you would look and you’d come in here and you would see something about why your. Why your application failed to deploy. So. So. So let’s fix this. I’m going to come into Postgres. I’m going to make a new database. One is example. The other one is. Servoite underscore repository. And what I’m simply going to do is come back to. Well I said I would show you an example of the manual version of the deployment. So I’m not going to do this through the manager. Let’s say you don’t have access to Tomcat manager. For whatever reason you want to do it manually. All you have to do is go to. The web apps directory. And this is a special directory inside your app server. That has all of your web applications. Each one will have its own folder. Excuse me. And you can also see the war file that got deployed there. Tomcat monitors this directory. And if it sees that a war file is added or a war file is overwritten. It will basically delete the directory and unpack that war file which is really just a zip file. Into into the web apps directory again essentially redeploying it. So what I could do is I could go to. The version of this that I. That I had and go back to Tomcat. Now I could paste this here and overwrite it and I think it will detect that. And. There you can see the timestamp changed on my hello world directory. So what it did is it took this war file and it unpacked this into this directory which has. Again it’s just a web application now it has all of the. The past all of the resources all of my components and. My my dependencies are all there. So let’s try it out. If we go back to Tomcat manager. And I list applications. You can see that hello world is there again. And if I look under the running column it’s true. So that means that it’s actually running. So if I click this link. It should take me there. So that is the root of Servoyof course. If we wanted to see it we would go to the. For the ng client we go to solutions hello world index dot html. And there it is that’s that’s all it is. It says hello world. So. So that’s kind of the basic deployment you can upload it through the Tomcat manager. Or you can manually paste that that war file into that directory and it will automatically detect it. And unpack it and deploy it. And so you can see that if there’s a problem you go to. First you look for that Servoylog file and that Servoyhome directory. Underneath where you can see the. And if you don’t find anything there then you would troubleshoot. The Tomcat the Catalina logs in the Tomcat logs directory. Let’s talk a bit where over time I predicted this would go a little bit long. Let’s just do a few odds and heads though and talk about. Some of the some of the configuration and and settings for both the Tomcat server and and the Servoy app server. One thing that I want to point out is back in that. Servoyfolder that I set up for this the Servoyuser home. There is a properties file. Now if I edit this it’s empty. Sorry if I edit this right now it’s empty because I just I did the generator and generated the properties. If I had set some. If I loaded a properties file from the the outset or I started setting things from the. From the admin console which I could access here. Sorry set that up real quick. This is normally protected but I have a cookie that seemed to work so I have to come in and. It would have asked me to log in and then still I’d have to create the user. So if I were to come in here and say start tweaking the networking settings or whatever. Then that gets written remember that the running web archive is not. It’s read only so if we want to save the setting somewhere. Then it actually writes that Servoyhome directory. Now. One problem that I’ve seen is that. Let’s say I go and I upload a new war file. It’s not going to overwrite any of the keys that are back in that properties file. Located in sorry I keep bouncing around. Located in my. Properties file here in my Servoyuser home directory. So that can cause a bit of confusion it’s it’s it’s intentional so that you don’t. Always overwrite some configuration that you set. up with every with every export if it was written here then it then it it trumps the. The incoming property if it the key does exist here. So only new stuff gets gets gets. So that can be a source of confusion so if you ever get and I saw this recently where. The properties for sorry one of the database connections themselves. Was. A mysteriously not working like in the export it was set and then in the properties file here it was still looking at local host and the database had been moved. Then we had to go in here to figure out what what does it really think it’s at and then you clear out that property or set it there. And then and then everything’s back to normal so you do want to peek in here if you’re troubleshooting something like a property that doesn’t seem to want to stick. You could look for it in here. Also a little bit about Tomcat configuration. We did some stuff at the at the outset when we were installing but let’s say I wanted to to change some some things so. There’s a comp directory and Tomcat and this is where all the configurations are there’s really a few key XML files here that you could go in and manually edit. The first one being server XML you may have experience with this just running. Old versions of server because we’ve always used Tomcat if you want to change the port number for example I have it set to 8085 if I want to move this to a different port all I have to do is change this save it and. And then restart the service and it will start up on the new port so. SSL and all that stuff you can set up here and server XML. You may have also remembered that I set up a user so that when I log into the Tomcat manager. And I had a cookie so unfortunately didn’t show the login but it would have asked me to log in the very first time. That is in the Tomcat users and so you could see that admin admin. Well, now you can see my password it’s not encrypted that I had set up there with the role for manager gooey which gives me access to the manager. That was that was written here but if I wanted to add another user or come in and you know change my password or something I could do it in here in this in this file so all of the configuration stuff for Tomcat is in this com directory. Web XML has to do with particular server let’s in Tomcat but if you wanted it for example change the the upload file size limit that’s there’s a limit in Tomcat. And if you want to override that you can come in here and edit that XML file so you have to read a bit of documentation and get into those XML files but it’s pretty easy to do. Well we’re pretty far over our limit. You know most of the rest of the topics really get into you know specific stuff with Tomcat or if you use another container so maybe I should stop here and ask you Steve do we have any questions. Yes there is one question I did forget to mention at the beginning that there’s a questions panel of but one on funnios and town of Medina has a question which is when using multiple contexts do does bread data broadcasting work as usual between all the contexts. Does data so the question is does data broadcasts work as usual across context didn’t know that the context is the serve way app server and the solutions in it so data broadcasting. Doesn’t work between app servers that you would just upload those you there essentially separate totally separate web applications. Okay. That is the only question that we had. We did do a poll at the very beginning and a few of you answered it I closed the poll so that Sean could show his screen. I think what I’ll do right now is I have a share results which I think now it just takes the screen away. And those were the results from the 60% of people who were here at the time of who is used or deployment and who’s not tried it. I’m not sure if there’s a way that we can do it again. Let’s see Sean you may have to either create another poll or. Start it out of it’s not a big deal not a big deal just nice to know that it’s so we have 25% yes 58% have not tried it. 17% have tried it. So and with 60% of the people voting so a little more than half the people that answered and we get a majority of them have either not tried it or. They have tried it but they’re not a fool yes like they do word employment so. That’s good that means that the topic is at least relevant. So one I forgot to mention is. That you can always find that home directory right here on the at the admin page of Servoyif you forget for some reason where it is or. You’ve never set it up in that configuration and to begin with and then you go looking for it which I’ve done personally because it sticks it in a weird place sometimes you can find it right here. So I just want to point that out. That appears to be it for questions. Sean if you want to put up the links to the forum topic and. Just the last couple of slides there. So any. So lots of documentation on the wiki about this so if you have additional questions. You can go to that first link. Again, the recording of this webinar will be uploaded to the thread in the forum. And any other issue or questions that you may have or resources access the forum demo dot server. So void.com and also GitHub for any sample files and things that we have there. Our next webinar will be in two weeks on May 3rd. The topic is to be determined. We’re probably going to do probably going to do like an open source update. Some of the open source projects and just an update on what’s what’s new there. But we haven’t decided what will be in that update yet. And then I think two weeks from that is Servoy world. So we may be dark for that week. I’m not sure what the what the plan is or we maybe. Yeah, there won’t be a webinar that week because it it coincides exactly with Servoy world. So come to Servoy world instead. There you go. All right. Well, thank you everybody for attending and we will see you all in two weeks. Thanks guys.

Close