Winstone Servlet Container v0.8 released

Discussions

News: Winstone Servlet Container v0.8 released

  1. Winstone Servlet Container v0.8 released (18 messages)

    Winstone 0.8, a GPL servlet container focused on size, decomposability and embeddability, has been released. This release focuses on a few key missing features, like name-based virtual hosting and access-logging.

    The container was written primarily as just a servlet container, and had trouble finding a GPL container that did only that or could be stripped down to being purely a servlet container.

    Additional features required for compliance with the specifications have been added, retaining a small distribution size. Winstone has also been designed for ease of deployment. It now passes all the Servlet v2.4 Sun TCK tests for JSR 154 (and JSR 152 JSP kit when deployed with Apache Jasper enabled).

    Since the earliest versions, Winstone has been executable with a simple "java -jar winstone.jar <warfile>". This makes it very apt for quick develop/deploy/test cycles.

    The latest release supports embedding of a warfile inside the Winstone jar itself, so now GPL java webapp projects can distribute an all-in-one container+webapp package that executes with "java -jar package.jar".

    Also in this release:
    • Name based virtual hosting is supported.
    • Apache style access logging options have been added.
    • Lots of bugfixes related to WebDAV. It now works happily with Davenport and Jakarta Slide.
    What do you think of the product?

    Threaded Messages (18)

  2. How is it different from Jetty?[ Go to top ]

    The goals of this project sound (at least to me) a lot like the goals of Jetty: small, embeddable full Servlet container. Except that Jetty has been around for a lot longer and is under an apache license.

    Could the developers of Winstone explain why I might check out Winstone when on the surface it sounds a lot like a more mature product in the same arena? Thanks,

    -Tim Fennell
    Stripes: Because web development should just be easier.
  3. How is it different from Jetty?[ Go to top ]

    The goals of this project sound (at least to me) a lot like the goals of Jetty: small, embeddable full Servlet container. Except that Jetty has been around for a lot longer and is under an apache license.Could the developers of Winstone explain why I might check out Winstone when on the surface it sounds a lot like a more mature product in the same arena? Thanks,-Tim FennellStripes: Because web development should just be easier.
    I agree. What value are you bringing and that too so late in teh game. Will it not be wise to work on somehtng existing and may be improve it. ?
    How many more wheels do we want to reinvent ? can someone make those wheels better instead ?
  4. How is it different from Jetty?[ Go to top ]

    The goals of this project sound (at least to me) a lot like the goals of Jetty: small, embeddable full Servlet container. Except that Jetty has been around for a lot longer and is under an apache license.Could the developers of Winstone explain why I might check out Winstone when on the surface it sounds a lot like a more mature product in the same arena?
    Thanks,
    -Tim FennellStripes: Because web development should just be easier.

    I agree. What value are you bringing and that too so late in teh game. Will it not be wise to work on somehtng existing and may be improve it. ?How many more wheels do we want to reinvent ? can someone make those wheels better instead ?

    I don't agree with that line of thinking. Implementing a specification like servlet spec is a big challenge. If someone wants to get a deep understanding of the servlet spec, implementing it is probably a good way to achieve that goal.

    peter
  5. How is it different from Jetty?[ Go to top ]

    The goals of this project sound (at least to me) a lot like the goals of Jetty: small, embeddable full Servlet container. Except that Jetty has been around for a lot longer and is under an apache license.Could the developers of Winstone explain why I might check out Winstone when on the surface it sounds a lot like a more mature product in the same arena? Thanks,-Tim FennellStripes: Because web development should just be easier.
    I agree. What value are you bringing and that too so late in teh game. Will it not be wise to work on somehtng existing and may be improve it. ?How many more wheels do we want to reinvent ? can someone make those wheels better instead ?
    I don't agree with that line of thinking. Implementing a specification like servlet spec is a big challenge. If someone wants to get a deep understanding of the servlet spec, implementing it is probably a good way to achieve that goal.peter

    You need deep understanding of the servlet so you build a container ? Wow !!! you seem to have a lot of time on hand ...its mostly wasted i guess.
    The source code for all open source servlet containers is available to you. go deep inside it. why build your own.
    anyway - upto you to waste - i wasted some of mine trying to bring you down to earth ( rather bring upto the earth from deep inside servlet spec )
  6. How is it different from Jetty?[ Go to top ]

    The goals of this project sound (at least to me) a lot like the goals of Jetty: small, embeddable full Servlet container. Except that Jetty has been around for a lot longer and is under an apache license.Could the developers of Winstone explain why I might check out Winstone when on the surface it sounds a lot like a more mature product in the same arena? Thanks,-Tim FennellStripes: Because web development should just be easier.

    I agree. What value are you bringing and that too so late in teh game. Will it not be wise to work on somehtng existing and may be improve it. ?How many more wheels do we want to reinvent ? can someone make those wheels better instead ?
    I don't agree with that line of thinking. Implementing a specification like servlet spec is a big challenge. If someone wants to get a deep understanding of the servlet spec, implementing it is probably a good way to achieve that goal.peter

    You need deep understanding of the servlet so you build a container ? Wow !!! you seem to have a lot of time on hand ...its mostly wasted i guess. The source code for all open source servlet containers is available to you. go deep inside it. why build your own. anyway - upto you to waste - i wasted some of mine trying to bring you down to earth ( rather bring upto the earth from deep inside servlet spec )

    I didn't mean to advocate that one "should" implement a full servlet to gain a deeper understanding of the servlet specification. Given tomcat and jetty are both mature containers, one "should" be able to read the source code to get an understanding. Personally, I've read through quite a bit of tomcat 4.x codebase for fun, but not everyone learns from reading code.

    Some people learn through writing software, so even if there's code readily available to learn from, not everyone is going to read the code and get it. Just look at the number of questions on tomcat's developer mailing list. Trying to understand an existing container might not always be the easiest way to learn how servlet containers work. Even people that have worked on tomcat in the past have a challenging time understanding the current codebase. Just reading tomcat or jetty source won't really reveal the intricacies of how and why a servlet container works a certain way.

    peter
  7. How is it different from Jetty?[ Go to top ]

    You need deep understanding of the servlet so you build a container ? Wow !!! you seem to have a lot of time on hand ...its mostly wasted i guess. The source code for all open source servlet containers is available to you. go deep inside it. why build your own. anyway - upto you to waste - i wasted some of mine trying to bring you down to earth ( rather bring upto the earth from deep inside servlet spec )

    My Eclipse projects list is littered with all the fantastic web frameworks I have written from scratch. REST-based, component-based, a view technology that merges the model with pure HTML using Tagsoup and XSLT, one that uses continuations within the controller (that one was particularly fun), etc, etc.

    None could be described as "production-ready". But when I look at any other web framework, I now know better what it is trying to achieve and where is strengths and weaknesses may be than if I had just picked up an existing project and read the docs.

    I don't know how this project started out, but maybe the author wanted to have a go at implementing a servlet container, then found he had a half decent project that others may find useful.

    My guess is, this is how alot of the most popular projects started out.

    Kit
  8. How is it different from Jetty?[ Go to top ]

    My Eclipse projects list is littered with all the fantastic web frameworks I have written from scratch. REST-based, component-based, a view technology that merges the model with pure HTML using Tagsoup and XSLT, one that uses continuations within the controller (that one was particularly fun), etc, etc. None could be described as "production-ready". But when I look at any other web framework, I now know better what it is trying to achieve and where is strengths and weaknesses may be than if I had just picked up an existing project and read the docs. I don't know how this project started out, but maybe the author wanted to have a go at implementing a servlet container, then found he had a half decent project that others may find useful.My guess is, this is how alot of the most popular projects started out.Kit

    Thank you - that's exactly how it started. I was reading an excerpt from a book about Tomcat internals (in an effort to try to strip down Tomcat), and thought "maybe it would be simpler to build only the parts I need". It turned out I was absolutely right when I learned more about the internals.

    I'm so sick of the wheel analogy. How many times do we need to say "because we can make it *rounder* this time". That's what's good about OSS ... things get better through variety and competition.
  9. A better wheel.... ?[ Go to top ]

    ....
    I'm so sick of the wheel analogy. How many times do we need to say "because we can make it *rounder* this time". That's what's good about OSS ... things get better through variety and competition.


    Not to mention all of the people who make that analogy fail to see that we have "re-invented" the wheel many times. I imagine the original wheels were made of stone, not rubber or some synthetic material. You don't have the same wheels on your car you do on your bike do you ? No, because different wheels are better for different purposes.
  10. How is it different from Jetty?[ Go to top ]

    My Eclipse projects list is littered with all the fantastic web frameworks I have written from scratch. REST-based, component-based, a view technology that merges the model with pure HTML using Tagsoup and XSLT, one that uses continuations within the controller (that one was particularly fun), etc, etc. None could be described as "production-ready". But when I look at any other web framework, I now know better what it is trying to achieve and where is strengths and weaknesses may be than if I had just picked up an existing project and read the docs. I don't know how this project started out, but maybe the author wanted to have a go at implementing a servlet container, then found he had a half decent project that others may find useful.My guess is, this is how alot of the most popular projects started out.Kit

    Thank you - that's exactly how it started. I was reading an excerpt from a book about Tomcat internals (in an effort to try to strip down Tomcat), and thought "maybe it would be simpler to build only the parts I need". It turned out I was absolutely right when I learned more about the internals.

    I'm so sick of the wheel analogy. How many times does it need to be repeated: "because we can make it *rounder* this time". That's what's good about OSS ... things get better through variety and competition.
  11. Memory footprint? Speed?[ Go to top ]

    A simple just-servlet container (like the Java Web Server that came bundled with the original servlet API) would be nice. It would be really nice to know any speed or reduced memory footprint advantages it might have.
  12. Memory footprint? Speed?[ Go to top ]

    Carl,

    I tried to answer the speed thing in my last post, but I missed the memory footprint part. I can't give you any hard numbers, just a personal experience example. When I moved one webapp from Tomcat into Winstone, I noticed the java process memory usage (in windows) go from 16MB after startup to 8.5MB after startup.

    Granted, this is no benchmark, but I think just removing the loading of hundreds of extra jars makes the startup faster, and that most rarely used features (eg access logging, JNDI, etc) are turned off by default.
  13. Speed and Memory Footprint[ Go to top ]

    Rick,

    I've test Winstone with a heavy-weight webapp I'm currently developing. Had to tweak it a little bit, but after a few tries everything worked fine.

    Again no benchmark, but the speed seems pretty good, and the memory footprint is amazingly low compared to Tomcat.

    First impression: This little engine rocks!
  14. A couple of replies:

    1) Why duplicate it when jetty sounds similar ?

    Because I guess the devil is in the detail. I always felt that the really crappy thing about containers (as they were) was how even the smallest, Jetty, at that time required a >1MB download, and required property file adjustments etc before even the simplest webapp could be launched. Winstone doesn't need that, just "java -jar winstone.jar <webroot/warfile>".

    Once you use it, it feels quite different to Jetty, especially on deployment. The decomposability and embeddability make it great for junit testing etc as well.

    2) Why not just contribute to an established project ?

    This is the kind of thing only people who have never tried to do it will say. The percentage of OSS projects that will not tell you you're off your rocker if you propose something that's not on their roadmap is very small. Especially if it's something that isn't a feature per-se like size or startup time. Hang around on the *-devel lists of some of the containers, and you'll get what I mean. Some of them are downright hostile, newbies are like targets.

    Then there's the learning curve: in the beginning, you have no idea what the quality of the internal code is like, and how fragile most of it is. You have no way of knowing whether a particularly ugly line of code is required, and if I try to clean it up, will I break something somewhere else. Combine that with the "it's already perfect, nothing to see/do here" attitude that prevails on the dev lists, and writing a container from scratch comes out on top on costs vs benefits.

    3) Size, speed and startup time advantages ?

    My experience for startup is typically 2-300ms plus webapp startup time (once the JVM libs are loaded). To be truthful, I've found the biggest use is as a dev tool, since it's small enough to check into CVS with each project and add a Maven/Ant task to launch it. It's nice to be able to say to new devs on your webapp project "just check out of cvs and run maven clean winstone then open your browser" for a full build/deploy cycle. They can use whatever container they want later, but for quick and dirty it's already there.

    Anyway, if you're unsure please download the jar a try it, it's only 160KB for the lite version. Even dialup can handle that, and it won't take more than 5 minutes.

    Rick
  15. What version of Java is required? I wasn't able to find that on Winstone homepage. I am thinking about getting to run servlet container on PocketPC and only J2ME Personal Profile (mostly Java 1.3 with some packages missing) exists for that platform.
  16. What version of Java is required? I wasn't able to find that on Winstone homepage. I am thinking about getting to run servlet container on PocketPC and only J2ME Personal Profile (mostly Java 1.3 with some packages missing) exists for that platform.

    That's a good point - I'll have to add this to the docs. About 6 months ago I had successfully trialled it running on a JDK1.2 environment, but there have been changes since then, mostly done under 1.4 environments. There isn't anything in the code I can think of that would prevent it, except for the odd bug.

    If it doesn't work on your 1.3 environment please let me know. I'll be happy to bug fix it.
  17. Just a quick post-update. I ran it with Sun JDK1.3.1, and it was using a few classes that were 1.4. I updated it to use only 1.2 classes, and it worked. I've just checked those into CVS, so if you don't mind get the CVS version, it will support 1.3.
  18. GPL[ Go to top ]

    The fact that your project has the GPL license will make almost nobody use it. You say that it's intended to be embeddable, yet you choose a viral license. I strongly recommend to relicense it under another license that is at least friendly towards commercial usage (CDDL being my personal favorite).
  19. GPL[ Go to top ]

    The fact that your project has the GPL license will make almost nobody use it. You say that it's intended to be embeddable, yet you choose a viral license. I strongly recommend to relicense it under another license that is at least friendly towards commercial usage (CDDL being my personal favorite).

    Interesting point. I'd consider changing the license if there was enough positive feedback. My experience has been so far that the license is fine for dev environments (which seems to be the primary use case), and for production environments the people who want a non-GPL license will reject it out of hand anyway for other reasons, like lack of commercial support. Personally I like the ideals of the GPL, but I'm in no way married to it. I'd prefer to use it if there's little cost in doing so.

    If there are people out there who feel a license change is appropriate or not, please comment. This is something I'd like to get bit of feedback on. Maybe trialling a license change for v0.9 or something would be okay ...