 Welcome to the final track, final session of the Tomcat Con track. It's aimed as a bit of a wrap up. I'm not going to bother introducing myself. I think you're pretty switch. If anybody here doesn't know who I am, then something's gone wrong this week. First of all, thank you all for attending. I hope it's been useful. Thank you for making it through to the last session. It is nice to see so many of you still here at the last session on the Thursday when normally people are dashing for the aeroplanes. So thank you all very much. I did say on Tuesday that we had some new PMC members that I couldn't announce. I'm pleased to say that both Coty and Huxing are now fully fledged members of the Tomcat PMC. So congratulations to both of you. So with this wrap up session, what I wanted to do was really look forward and think about what I think might be happening in the Tomcat community and things around it over the next year-ish. So obviously the big thing on the horizon is Java EE8. It's June, July, summer-ish. The main thing that we're going to get there is Servlet 4. So that's actually to be two and all the other things that we've talked about this week. In terms of the other specs, I'm not aware that anything has happened on them. So what I'm expecting is what's happened with the JSP spec in the past, which is a few days before the deadline, the maintenance lead will publish an update to the spec that will fix a few typos, maybe add a couple of convenience methods, not really add anything significant, and then push it out there and that'll be what we'll end up implementing. Sort of like half a day's development effort each I'm imagining. So what that means for Tomcat 9 is we're currently releasing milestones. They're going to stay as alphas, milestones, until the specification API is fixed. Once that's, sorry, they're milestones at the minute, they'll be alpha once the spec is fixed. As soon as the implementation is done, we'll switch it to beta. That's going to be a very short period of time unless something truly awful goes wrong in the trailer's implementation. That's about half implemented already, and I only stopped because there wasn't clarity on what the API was going to be. So that's, alpha will happen as soon as the specs go final. Beta will happen very shortly afterwards. Stable is the one that will take a little bit longer. The good thing with all the delays with Java 8 is that Tomcat 9 has been out there for a while. Tomcat 8.5, which is heavily based on it, has been out there for a while. And it's already had a lot of real testing. People are using it actively in production. We've ironed out a lot of the early issues that we'd normally expect to iron out. When will it be production ready? No idea in terms of fixed date. I wouldn't be surprised if it was before the end of this year, assuming that Java 8 delivers when we're expecting it to. So compared to previous releases, that should be fairly quick. There is some work to do around Java 9 modules, but that is still a moving target. And as I've said before this week, I'm not really that keen on spending time working on it when the target's still moving. We've got an idea of what's going to be involved. It's probably not going to be too much, hopefully. So we'll let that settle down. Java 9 and Java 8 aren't tied together at the minute. So we can always treat making it run on Java 9 as just something we fix in a point release. Because I don't think there's going to be anything that's going to massively affect any of the existing APIs. At the other end of things, Tomcat 6, we are now slowly closing down the resources. Bugzilla was closed to new bugs, I think last week. There's something just under 20 open Tomcat 6 bugs. I think it's 18, it might be 17. So we need to review all of those. What I've been doing this time is previously I've just changed the Tomcat version to whatever the latest one is and left them. What I'm trying to do this time is go through them and actually give them a bit more of a review. See if we can actually implement this. Does it look like there's a demand for it? Do we need to mark it as won't fix? And try and actually close them out rather than just punting them again. I expect that someone will end up being punted because it'll be able... Well, it's a nice enough idea. It's just a fair amount of work. So it's not quite an itch I want to scratch, but it makes sense enough that I don't want to just close it as won't fix. So those ones will probably get punted and there'll probably be a couple of them. The other steps, once those are done, we make Bugzilla read only completely for six. We'll remove Tomcat 6 from the downloads page at some point. Once we've done that, we'll remove it from the mirrors and then we'll drop the links to the docs. It's worth remembering that all of the Tomcat 6 versions will still always be available on the archive. The docs will always be available on the website. We're just not linking to them. There will be no more security fixes for six. Well, with the usual caveat that unless three PMC members decide it's a really good idea, get together, do it and vote for it. And if they do, that's fine. The chances of me being one of them is pretty slim. There might be three, it's possible, and it depends what the issue is. And to some extent it depends what those PMC members are still supporting that uses six in their organisations that a release would be helpful for. Personally, I'm trying to avoid doing that. So it's highly unlikely is what we normally say. So yes, the six releases are still on the archives. All the ones back to Tomcat 3.2. The docs will always be available on the website as are the docs all the way back to 3.2. So we just don't link to them. Was that a question over there? So that brings us on to Tomcat 8. And because we want to try and support three versions in parallel, we don't really want to be doing seven, eight, oh, eight, five and nine. So as I said, what we've always wanted is eight, oh, two, eight, five to be seamless, modulos, maybe some simple configuration changes. Eight, oh, has got a slightly slower release cadence. There is no fixed date on when eight, oh, is going to come to an end. And what we heard at the meet-up last night and various people have sort of said in the room or in the corridors is it would actually help if we put a fixed date on that. So I think that's a discussion that we need to have on the mailing list to see well, are we going to put a fixed date on this and if so what is it or is somebody going to step up and volunteer to actually keep it running in parallel with eight, five for at least the next X months and then we'll revisit it maybe. But we'll try and get some more clarity on that because at the minute it's not. So Tomcat 7, that is going to be supported until Java EE9 is close to being released. Now, I've put an idea here on when I think that might be. The question was asked on the mailing list and I think I went through a similar sort of logic and came up with a slightly different set of dates. It's going to be no earlier than end of next year at the absolute earliest and I would be amazed if we end of live Tomcat 7 that early. It all depends on what happens with Java EE9. That's meant to be a year after Java EE8 but I don't see that happening. I think it's going to stretch longer and then there's also then the question of we're not going to end of life Tomcat 7 until we've got a reasonable degree of certainty when Tomcat 10 is actually going to be entering into service because there's always some overlap. We don't want too much, we don't want too little. So yeah, question at the back? Tomcat 8.0 might, but 8.5 will carry on. The plan was always when we created 8.5 was to end of live 8.0 fairly quickly but that's why it's important for us that people can move from 8.0 to 8.5 without hitting anything horrible and if people report it, we'll fix it nice and quickly. So yeah, if Java EE9 says released not next year, let's say it's 6 months late that's end of next year, say we don't have certainty on that until 3 months beforehand so we'd probably shoot then for end of life 12 months after that so that's what end of 2019. So yeah, it's somewhere around 2019 maybe but it's very moveable depending on what happens with Java EE9. It really comes down to there's no fixed rule on what we backport to what. Everything goes into trunk so everything goes into 9. Pretty much everything goes into 8.5 some internal cleanup doesn't. Bug fixes currently are going into trunk 8.5, 8.0 and 7. It's normally what happens is that we will put some bug fixes all the way back to the earlier supported version and it comes down to a judgement call as to how severe the bug is versus what fixing it might do to somebody who thought they were on a nice stable release that wasn't going to change. Everything will get, I think that support will always get security fixes so there's no hard and fast rule and actually it's getting easier to backport stuff. A lot of it depends on whether the code that needs to be backported has gone through a refactoring. If it's in the connectors it's horrible. If it's anywhere else it's now fine. 7 to 6 was potentially horrible in lots of places. That's gone away now. The main area of difficulty is going from 8.5 to 8 around the connectors because of all of the refactoring we had to do. But equally we don't want to backport all the refactoring to 8 because that will create a different set of problems. Yes? It's highly likely not by us. But I imagine that Emmanuel will be backporting stuff from 8.5 to 8. Because 7 is still being supported it might actually be easier to take fixes from 7 than 8.5 depending on the area of the code. We have a Tomcat committer that's plugged into that so that should happen. The reality is that 1, 2 is the one to be their promise to their community. We are not supporting their promise. So if they want to backport our patches to later versions they are free to do so and presumably they will work with us to develop those patches but we won't do it. What we've said is we will always give at least 12 months notice of the end of life of a major version. But we've never made any promise over and above that. And we'll try and do more and we'll try and do better but that's what we've said we will do. How do you know if somebody is just a user that a particular version is production ready? Did you scare you with that because we've been using 8.5 and we considered it production ready? I don't know if you do. If we call it stable that's what we consider production ready. It tends to be my personal yard stick is something along the lines of have we had two or three releases in a row without any bugs that make me go pale? Or any sort of regressions that have caused hassle? It's a sense of actually that we've had those three releases out there and we haven't had the steady trickle of bugs that people have stumbled across that have been in the code base for years and years and years and they just happened to have stumbled across them. If we've still got two or three major bugs being reported on each release and they're related to code that's changed then that's not stable but there's no hard and fast rule. Yes, definitely. And to be honest I'd be close to calling 9 stable if it wasn't the fact that the API wasn't stabilised it would go from milestone to stable very quickly but it needs three PMC members to all consider it stable before it will get A and there needs to be a majority of more people thinking it's stable than beta so it's a PMC decision and we will take feedback from the community as I said before I will quite happily if we have a release that's got 10 PMC votes on user pipes that says hang on this has broken for me that's enough to kill the release. If we stick to the Apache rules we don't have to we could release it anyway but 99 times out of 100 it'll get fine. We'll listen to that. That's valuable feedback. You've gone to the trouble of testing it. We wanted you to test it so now you've told us we're going to listen. Please go at the moment. When Tomcat 7 is end of life I'll go at the moment. If we go back to the other end and Tomcat 10 what do I think might be in that? The servlet spec is fairly easy because that's all the stuff that got punted out of servlet 4 that we decided we didn't have time to do. Request cancellation was mooted. In HTTP2 the container knows if the client has said I don't want that request anymore and potentially we could pass that information onto the app via some form of listener. So there's something there that will be discussed for servlet 4.0 next. Async parameter processing you can process request bodies and write response bodies using async code but you can't actually read form parameters in an async manner. You have to wait for the whole body to turn up so that was discussed as something we could do and overlays goes all the way back to servlet 3 back when people were talking about I forget what the magic phrase was it was something to do with clouds and multi-tenancy and there was some lovely phrase that was all over Java EE and then got forgotten in about six months but here the idea is that if you're deploying the same app multiple times with slight tweaks for different customers different departments whatever then you can have one common app then you have an overlay for each of those customers that had the specific customisations for that particular deployment and then when you wanted to update it you just updated the master copy and the multiple instances all picked up those updates in one go so all you had to do was update one wall, leave the overlays alone and updates in that particular scenario were easier. The good news is all the code we need to do that is implemented ready to go in Tomcat and has been since servlet 3 because I went and implemented it when we thought and literally the week after I had finished implementing it it got dropped from the spec. I wasn't overly happy but it did have some other side of benefits because it forced us to rewrite the resources handling that was getting incredibly spaghetti like so it's a lot better. GSP unified expression and Jaspic I'm not aware of anything that's particularly going to happen so I think there'll just be a maintenance. WebSocket the one big ticket item there is a standard API for WebSocket extensions so at the minute Tomcat has the compression extension, Jetty has a compression extension I think they've also got a multiplexing extension but they're all written to our own internal API so you can't chop and change them it would be nice if there was a standard API for extensions that you could then just plug in to the WebSocket implementation. Having said that it might not be the easiest that API might not be the easiest thing to write because to get those extensions working efficiently you really need to be plugging into some of the low level processing so the right API then potentially depends on how you've actually done the implementation and I just don't know whether we'll be able to get to sort of a common agreed sensible API amongst all of the WebSocket implementers but that's what the expert groups for if it starts up again and if it's agreed that extensions is a way to go then that's what we'd be working on. Jack is the authorization component or how did I do that? That wasn't my plan right Jack is the authorization counterpart to JASPIC so that's the Java authorization contract for containers I think. This has been on my list of things to do to look at for a long time. The main reason for wanting to look at it is if it provides a standard API that apps can then use to do things like add users remove users, update users passwords that would be a useful thing to have I don't know whether it does or not I want to go and have a look we'll see if it does great, if it doesn't then the usefulness of it becomes rather less. Other things for Tomcat 10 this is sort of a theory that I have mooted several times and I must stress this is my personal thinking it is absolutely in no way should be taken as the consensus view of the project so thinking goes the main reason for having API native was that you could use open SSL so TLS was a lot faster well we don't need the API native connector now because we can integrate open SSL with the NIO and NIO2 connectors so potentially we could drop API native all together that would be a nice thing because there are some annoying bugs in API native that are really difficult to track down and when you hit them the JVM crashes it would be nice to just make all of that go away so okay we've got the API native well hey I've started so I might as well carry on do we need NIO and NIO2 there aren't any particular performance differences between the two one isn't particularly easier to integrate than the other if anything NIO2 is a little bit more complicated do we still need could we just have the NIO connector don't know is anything going to happen with HGTP next maybe discussions are happening whether anything will happen in the Tomcat 10 time frame I don't know reactive Rossen talked about that yesterday and we talked about it more at the meet up last night there is definitely interest from people who want to be able to write reactive style apps directly to a reactive API rather than going via the server API because it's a little bit clunky could we put that in SSI is anybody still using server side includes if I drop if we dropped that package would anybody even notice that might be a question for the users list but I suspect it's not that widely used signed code and at the minute we sign all of the windows install and we sign the windows uninstaller so you don't get nasty error messages when you install on windows but nobody's actually noticed or at least they haven't complained the few releases we haven't signed because we're having problems with the code signing service so I'm wondering how much do people actually care about that and taking it going the other way we have the option that we could sign every single jar the only people that the only people I know that have used signed jars have turned around and said that's lovely but it doesn't help us in our particular scenario because every jar we ship has to be signed with the same certificate so we strip out anything they do and redo it ourselves anyway and that's to do with running Java in the browser and it has to work that way so maybe if we talk about more sort of project development type things moving to Git I think is just a matter of time there was general consensus amongst the developers probably about a year ago that yes we want to move to Git it just needs somebody to find the time to run through the process to make sure it works and find some answers to some of our SVN integration questions but I think it's all doable so that I think is going to happen at some point periodically we get asked do we want to move to Maven this came up again over lunch today again this is a personal view I think Maven is unlikely I think that there are always costs associated with that change and I haven't yet seen anybody articulate benefits sufficient to justify the associated costs moving to something that isn't ant that's I could believe would happen if a compelling argument came forth if somebody could come up with a compelling argument for Maven I think we'd move personally I think it's fairly unlikely that that will happen given where the community is at the moment something other than that quite possibly Gradle got mooted at lunchtime I think that could happen maybe Chris I'm done with that yes go on then probably also we talking about TLS 1.3 I'm not sure if that's really a feature it's pretty much going to be in the JVM supports it that we will support it if OpenSSL supports it that we can fair point TLS 1.3 that should be in there I'm also interested maybe not personally doing it but if somebody is motivated to see if they can get connector to building against the OpenSSL Theoretically the APIs are out of the framework but it's going to require some monkeying around with the build that sounds like a job for Rayna to me his area of expertise it's certainly not mine but if there's anybody in the room or you know anybody that's interested in it then yeah happily if there's a patch to do that so we can build with either happily take it so other things that are being talked about possibly some form of community based tomcat training course I've managed to persuade my employer to donate their old tomcat training material it's a bit out of date but it's a possible starting point somebody else has indicated via the wiki that they're in a similar situation they've got some material they might be able to contribute the idea is that we put together an outline of the course on the users list bit like we did for this conference and then put together a bunch of modules that you could then pick and choose from to build a training course and then community members could then give that training course whether it was committers or anybody it would be there and we could potentially do webinars on individual modules there are all sorts of things we could do with it but there would be this community training resource I'd like to try and do some more things with user groups and meetups but these tend to be local things so if this is something that you'd like to see in your area speak up feel free to use the users list to try and organise it feel free to use the users list to try and badger at least one committer to turn up to it if you'd like them to feel free to use the user list to tell the committers to stay the heck away as you wish but getting the community together having those meetups I think is a useful thing to do please take advantage of the community resources if there's anything the foundation can do to help let us know what it is we will do our best other things there's plenty of opportunity to get involved we've just talked about the training course the meetups it isn't just bug fixing the website is desperately in need of an overhaul and has been for a while if you want to help with that please do documentation help just simply cleaning up the code there are lots of areas in the code where just somebody going through and doing a bit of cleanup would actually be a big help so you don't have to fix the big nasty complicated bug we do try and leave the simpler bugs open for a while to give people a chance that want to get involved to pick them up and run with them if you'd like to give it a go and you want to ask for some help where should I start with this what do I need to look at then feel free to ask on the dev list we'll happily give you pointers about what to set up where to look how to go about it yes, because it does support tags so in some ways one of the good things about Tomcat actually causes us problems there because I like to go and close all the open bugs before release then the low hanging fruit doesn't hang around for very long it's almost worth considering leaving the low hanging fruit for longer but then it's a trade off so, yeah it's already a big world so it's a good trade off cool cool and if not we've got enough bugzilla admins on the project to add it so cool ok, so that brings me to the end of what I wanted to talk about any more questions right so um I'm concerned with my release now how much of a problem replacement will 90.5 if you're not considering the circle of course you know, basically a circle of that um almost the only the only differences will be things like Tomcat 9 doesn't send the reason phrase and doesn't give you an option to send the reason phrase the option to have the request line validation be a little more lenient doesn't exist in 9 it forces you to be more spec compliant it's actually still slightly lenient and that might get tightened up further at some point um but otherwise and at times I've gone through and I've actually done diffs between 8.5 and 9 and copied stuff across just to make sure that it's there isn't sink as much as they realistically can be by some underlying refactoring the public API the sort of APIs you'd be using the behavior should be the same no, Java 8 Tomcat 9 will require Java 8 Tomcat 8.5 requires Java 7 7 all later it's always all later it's a minimum Java version so yeah, that'll be fine yes definitely we'll take it we will be more than happy to put translated versions of the docs on the website what historically what we just need to be careful of is obviously we we can't keep them up to date unless we happen to speak the language in question which I certainly don't um so there is an issue of keeping them up to date and keeping them in sync but I think that there are ways around that and part of the website overhaul could perhaps even look at are there ways that we could structure things that would handle that better and the whole lot served through HGPD so in theory we could have it also negotiate and pick the right language based on the user's browser if we've got it if we want it to be really clever about it but certainly as a starting point if it exists and it would be useful on the website then let's get it on there and get it done definitely any more in which case thank you very much and safe travel home everybody