Re: [FM3] Dropping support before Servlet 2.5 / JSP 2.1. Or even before 3.0/2.2?
+1 Am 20.01.2017 4:26 nachm. schrieb "Daniel Dekany": > In FM3, I want to get rid of JSP 2.0 support. It needlessly > complicates the build (because we also have to support the new methods > in JSP 2.1). Then our minimum requirement will be still Servet 2.5, > JSP 2.1, which was part of Java EE 5 (May 11, 2006). So I trust that > nobody will want to stop me doing this. > > We might even want to require Servlet 3.0 and JSP 2.2, from Java EE 6 > (December 10, 2009), just to make things easier in the future, though > at the moment we don't utilize that. > > -- > Thanks, > Daniel Dekany > > -- Synesty GmbH Moritz-von-Rohr-Str. 1a 07745 Jena Tel.: +49 3641 559649 Fax.: +49 3641 5596499 Internet: http://synesty.com Geschäftsführer: Christoph Rüger Unternehmenssitz: Jena Handelsregister B beim Amtsgericht: Jena Handelsregister-Nummer: HRB 508766 Ust-IdNr.: DE287564982
Re: [FM3] Dropping support before Servlet 2.5 / JSP 2.1. Or even before 3.0/2.2?
On Jan 20 2017, at 7:26 am, Daniel Dekanywrote: > We might even want to require Servlet 3.0 and JSP 2.2, from Java EE 6 > > (December 10, 2009), just to make things easier in the future, though at the moment we don't utilize that. This seems very reasonable. It goes back quite a few years and is one version back from the current version (JEE 7, Servlet 3.1, JSP 2.3; looks like since June 2013). -David
Re: [FM3] Dropping support before Servlet 2.5 / JSP 2.1. Or even before 3.0/2.2?
I'd vote to start at Servlet 3.0 and JSP 2.2 On Fri, Jan 20, 2017 at 10:26 AM, Daniel Dekanywrote: > In FM3, I want to get rid of JSP 2.0 support. It needlessly > complicates the build (because we also have to support the new methods > in JSP 2.1). Then our minimum requirement will be still Servet 2.5, > JSP 2.1, which was part of Java EE 5 (May 11, 2006). So I trust that > nobody will want to stop me doing this. > > We might even want to require Servlet 3.0 and JSP 2.2, from Java EE 6 > (December 10, 2009), just to make things easier in the future, though > at the moment we don't utilize that. > > -- > Thanks, > Daniel Dekany > >