i agree we should restart with the original implementation and incrementally introduce the new features - thats what i proposed in the original pull request.
i am not a big fan of having the application instance managed. what is the value of this? it can be injected using noncontextual just like everything else... -igor On Wed, Nov 13, 2013 at 1:19 PM, Emond Papegaaij <[email protected]> wrote: > Hi all, > > You probably noticed the the flood of emails regarding wicket-cdi these > last few days, which IMHO is good, because it means wicket-cdi is alive. > However, the current status is that the current (old) implementation of > wicket-cdi works badly with CDI 1.1 and the experimental (new) version is > broken in various ways. This is not good, as there is no good > implementation to use for CDI 1.1 users. > > I've reviewed parts of the code in wicket-cdi-1.1 and noticed the following > problems: > - Featuritis: it supports all kinds of usecases nobody is every going to > use, such as: partly managed applications, per-conversation > auto-conversions, per-conversation propagation, package ignores, switched > to enable/disable injection on almost everyting. > - Buggy: auto-conversations are broken for everything but pages, injection > in anonymous classes was broken, probably more. > - Too much state: configuration options are copied all over the place, > objects with different lifecycles share state. > - Too much injection: everything is injected, which makes it almost > impossible to see what's linked to what. > > I've also noticed some very nices features: > - CDI 1.1 support with conversations via the Weld API > - Management of the application and the Wicket-cdi configuration by cdi. > - Better implementation of NonContextual injection, using caches. > - Better testcases > > The experimental code is in such a state that is it almost impossible to > cleanup. On the other hand, I do not want to loose some of the new > features. Therefore, I propose the following: restart the wicket-cdi-1.1 > implementation, starting from the current wicket-cdi implementation and > reintroducing the features one-by-one. Also, I would like to remove some of > the existing features, like most of the toggle-switches, and I would like > to make the new CdiWebApplicationFactory mandatory to always have the > application be managed. All this will still be experimental in wicket 6, > but perhaps it can be made the default in 7. As we at Topicus are currently > starting the migration from JBoss 7.1 to WildFly 8, I can work on this 1 or > 2 days a week. > > Let me know what you think, > Emond
