Heh, yes, I’m also using direct svn commits to make my changes ;) Afterwards I use the CMS ui to review and publish the changes.
> If that is OK then I can look at the site tomorrow already because I > actually need better owb docs for my day job since we are switching project > after project to it That would be perfect! Feel free to ping me whenever you need help! Re DS-style. Yes, Switching all to asciidoc would be an option as well. I don’t think we have _that_ many stuff into our md. So we could easily go the same route. Just need to transform all to asciidoc. > Regarding the proposed code changes. Anything newbie friendly? :) I think the Session stuff is not that heavy. Probably we could set up pairs and hacking via shared hangout screen to spread the work. LieGrue, strub > Am 19.04.2015 um 23:14 schrieb Karl Kildén <[email protected]>: > > Regarding fixing the site. I know I said I would fix the docs but the cms > holds me back to much because I really dislike it. I was thinking the other > day that it might be a lot easier for me to work with subversion directly > instead and create a patch from it? > > and I explain it over and over anyways. I booked myself > up until lunch tomorrow and I will be on irc trying to get this going > again. I would be really glad if we could have something easier for docs > like github or confluence or something but I understand fully that it's not > so easy. > > Also kind of interested in the deltaspike style... And I am also a bit > interested in merging the CDI based information with the TomEE project a > bit? > > Regarding the proposed code changes. Anything newbie friendly? :) > > cheers > > > On 19 April 2015 at 22:40, Romain Manni-Bucau <[email protected]> wrote: > >> well the good point of FO is that you have a flush at the end so >> potentially a single remote touch. Not sure what's the usage, I know in >> TomEE it is never used. >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> <http://www.tomitribe.com> >> >> 2015-04-19 22:08 GMT+02:00 Mark Struberg <[email protected]>: >> >>> The point is that our default impl will still have a Map backed >>> SessionContext. But that one also doesn’t need any serialisation! >>> >>> The HttpSession will be a part of the webbeans-web module where it fits >>> with the WebContextsService. >>> The headache with the whole FailOver stuff is imo in no relation to the >>> eventual benefits. >>> >>> LieGrue, >>> strub >>> >>>> Am 19.04.2015 um 21:51 schrieb Romain Manni-Bucau < >> [email protected] >>>> : >>>> >>>> 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 >>> >>> >>
