About JBoss http://www.h-online.com/open/news/item/JBoss-6-M2-supports-Servlet-3-and-JPA-2-933807.html
On Tue, Jul 27, 2010 at 10:14 PM, Md. Jahid Shohel < [email protected]> wrote: > >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 >> > >> > >> > >
