On Thu, Nov 14, 2013 at 3:36 AM, Emond Papegaaij <emond.papega...@topicus.nl > wrote:
> I'll reply to several mails at once. > > On Wednesday 13 November 2013 13:31:39 Igor Vaynberg wrote: > > 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... > > Having the application and its configuration managed allows you to obtain > the instances via injection. Using the qualifier with the application name > on > both the application and its configuration provides a strong binding > between the two, while still making it possible to centralize the > configuration or override it in a testcase. I agree that the application > should be ready to use. This can be achieved with a producer method that > initializes the application. > > A simple usecase: our selenium tests, which live in a different servlet > filter, > require access to the wicket application. At the moment I have to do all > kind of magic to make sure I get a fully initialized application. It would > be > much easier to just inject it. > It will be easier but not just as simple as @Inject because the Application is an @Dependent. Simple Inject will just get you an new instance. In current form you would have to maintain the reference that is injected in the WebApplicationFactory, and add a method to retrieve that instance. More than likely it is much simpler that your current technique, but still requires a little extra work (other strategies would suffice as well). > > On Wednesday 13 November 2013 15:40:10 Igor Vaynberg wrote: > > we deploy in tomcat. we include weld as a war-dependency, not as > > tomcat dependency, therefore in our deployments filters are not > > injected. i assume this is how most people deploying to tomcat or > > jetty have it set up. are we dropping support for those people? > > That should not be a problem. Weld allows you to bootstrap from a servlet > listener, which also makes the BeanManager available through JNDI (if > done correctly). Simply follow the manual. The filters will not be > injected in > all cases, so we should not depend on that, but we can depend on CDI > being available. There's no need use ServiceLoader. CDI 1.1 has > CDI.current(), which is portable. Also, the BeanManager is available > through JNDI in most cases. > > Current WicketExamples have that code in place. Others reading can see that if interested. The ServiceLoader was proposed as alternate solution to autolookup the cdi container impl, such as Weld. Martin stated that this would break OSGI so that may be a gotcha. > The start, at this moment, should be to revert wicket-cdi-1.1 to the old > implementation and start migrating some of the most important parts: > - The NonContextual implementation > - The split in modules, with cdi-core and cdi-weld > - The testcases > I hope to get to this later today. After that, we can start working on > making > the application managed and using cdi to provide the configuration. > > Don't forget the real most important part which is the ConversationPropagator. That class is most important if we want Conversations. After ripping my hair out understanding why Igor implemented the way it is, it finally became clear. Without that class Conversations simply will not work. > Best regards, > Emond >
