>With regard to targeting Servlet 3, I don't think it is supported by >enough application servers.
GlassFish already supports Servlet 3, and the new release of Tomcat 7, which was released 2 weeks back, which supports Servlet 3. On Tue, Jul 27, 2010 at 1:27 PM, Malcolm Edgar <[email protected]>wrote: > With regard to targeting Servlet 3, I don't think it is supported by > enough application servers. > > Personally I have to work with the JBoss 4.x series and the Oracle > WebLogic series of servers and they only support the Servlet 2.5 API. > > regards Malcolm Edgar > > On Tue, Jul 27, 2010 at 5:19 PM, Md. Jahid Shohel > <[email protected]> wrote: > >> The target of Click 3 is Servlet 3.0? > > I think so. > > > >>It would make possible to introduce Click into web applications plugable. > > Yeah pluggability is another issue, that was not possible to bring in on > > current click implementation. While I was implementing the annotation > > support for click on my google code, and later on while I was thinking to > > write extension of click to add modularity support, it appeared that its > > easy to write a new config service instead of extending the existing > > one(which is in the end will bring in lots of maintenance issues). I hope > > there will be some good scope to bring in modularity. Or at least there > > should be scope for people extend the click implementation to add such > > functionalities as their extension projects. And by > modularity/plugability I > > mean dropable jars, but not package level code separation. > > > > > > On Mon, Jul 26, 2010 at 8:40 PM, Naoki Takezoe <[email protected]> > wrote: > >> > >> Hi Malcolm and Bob, > >> > >> The target of Click 3 is Servlet 3.0? > >> > >> It would make possible to introduce Click into web applications > plugable. > >> And also it would make possible to provide file uploading without > >> Commons FileUpload. > >> > >> I think that Click 3 might be a just time to shift to Servlet 3.0. > >> > >> 2010/7/26 Bob Schellink <[email protected]>: > >> > Hi Malcolm, > >> > > >> > Comments inline. > >> > > >> > On 25/07/2010 23:28, Malcolm Edgar wrote: > >> >> > >> >> I want to start a discussion about a potential Apache Click 3 > >> >> development branch. > >> > > >> > > >> > If we are talking about changes to the architecture then I agree it > >> > should be developed in a > >> > separate branch. > >> > > >> > > >> >> The objective of a version 3 would be to: > >> >> * provide a more explicit and consistent programming model > >> > > >> > > >> > Agreed. Over the years I've done more and more maintenance work, as > >> > opposed to pure "developing apps > >> > from scratch". One thing I've come to appreciate is that explicit > >> > programming really helps with > >> > maintenance and is only a slight nuisance to the initial developer. > >> > > >> > Do have something particularly in mind? Except for stateful pages and > >> > autobinding, Click core is > >> > quite explicit. Click-extras, especially the CayenneForm and > >> > HibernateForm, has some implicit > >> > behavior which needs work. I'm not even sure these controls are that > >> > useful as most Java apps uses a > >> > Service/Dao layer anyway. > >> > > >> > > >> >> * target HTML 5 support > >> > > >> > I assume you mean new input attributes? They can already be used > through > >> > setAttribute/getAttribute, > >> > unless you have something else in mind. > >> > > >> >> * introduce new rendering pipeline, to significantly improve > >> >> performance and enable pluggable component renderers > >> > > >> > > >> > Finn did some tests on this which looked quite good. It seemed to be > >> > targeted at Velocity only though. > >> > > >> > > >> >> * remove troublesome parts of the framework, and simplify the > >> >> architecture > >> > > >> > > >> > +1. Over the years we've deprecated a number of API's but never > removed > >> > them. This would be an ideal > >> > time to remove them. > >> > > >> > > >> >> With a change of this nature I don't think we can expect to maintain > >> >> 100% backward compatibility with Apache Click 2.x. Breaking backward > >> >> compatibility is a big deal as you potentially alienate many users > and > >> >> organisations. So any change breaking backward compatibility needs > >> >> have a significant benefit to justify its inclusion. To assist with > >> >> migrating applications from 2 to 3, it would be good to provide some > a > >> >> Ant task to perform refactoring as a head start. > >> >> > >> >> Please note the effort in migrating a v2 to v3 application should not > >> >> be significant. I do not want to see a Tapestry like scenario, where > >> >> people are isolated on older branches. > >> > > >> > > >> > Agreed. As long as there is an upgrade path it shouldn't be too much > of > >> > a deal. > >> > > >> > Kind regards > >> > > >> > Bob > >> > > >> > >> > >> > >> -- > >> Naoki Takezoe > > > > >
