That sounds fine. Can you show me how the Conversations are broken though? I think the propagation and auto features initially introduced by Igor make sense, after I really understood what was going on. In JSF they can only have auto converations and all propagation. If you google a little you find case after case where they hack around that I added an @Conversational annotation to allow the globals to be overriden to prevent that. But if you can show that it doesn't work as I thought then please show me.
As for Injection, again why is this bad? Makes testing alot simpler. If you dont inject the CdiConfiguration you may have a hard time getting the CDIWicketApplicationFactory to work. Also in the configuration, all those switches are marked deprecated. I didn't want them either, but was maintaining a migration path to cdi-1.1 John On Wed, Nov 13, 2013 at 4:19 PM, Emond Papegaaij <emond.papega...@gmail.com>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 >
