2015-04-19 21:25 GMT+02:00 Mark Struberg <[email protected]>: > Hi folks! > > First I want to say a BIG thanks to all the people wo made OWB-1.5.0 > possible. It was quite a long walk, but we had tons of fun and the project, > the team and the community around it ist still amazing even after so many > years! > > There is an old saying: „After the release is before the release“ > > I guess we will likely get some bugs and feedback pretty soon, so I target > a 1.5.1 release rather soonish ;) > > What do YOU like to address in the next few weeks? > Here is my personal list of tasks: > > * Update our site to reflect CDI-1.1. ANY HELP IS WELCOME :) > > * Get rid of our Map backed SessionContext impl. Instead we should store > our @SessionScoped beans directly in the HttpSession. And only use a Map if > we really need a ’synthetic session’. We also don’t need to care about > sessionId rewrite anymore in that case. > > +0.7. Basically I think it is a super good feature to not depend on the session impl so we need to keep it even if agree it shouldnt be the default. FYI tomee has it https://github.com/apache/tomee/blob/develop/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/cdi/SessionContextBackedByHttpSession.java
> * Store our Conversations in a custom Bean<T> in the SessionContext. That > way it doesn’t matter where the session gets stored. > > +1, also wonder if it makes sense to have ConversationBean request scoped. Makes transient conversation hard to manage and dependent of a scope it shouldnt need IMO. > * Probably get rid of the ConversationManager? It uses the nifty sessionId > heavily :( And technically we don’t need that… > > +1 > * Get rid of all the FailOver stuff. This is not needed anymore if we > really persist into a Session. This will really simplify a big area of our > codebase > > +0.7. Makes sense but also far better than session storage depending the session impl used. > * Split WebBeansConfigurationListener in Begin and End Listeners. We did > this in TomEE already. This is important if to guarantee that OWB gets > started as first in the chain, but stopped/cleaning up as last one in the > Listener chain. > > Also makes harder in servlet apps and not very useful. Can makes sense in tomcat integration but I'd keep an aggregated listener for common cases of OWB user usage. > * Improve our Servlet integration. > > I will create JIRA tickets for all thos ideas. > > Wdyt? Any other things to target in the next release? > > > LieGrue, > strub
