On Thu, Nov 14, 2013 at 2:27 AM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote:
> On Wed, Nov 13, 2013 at 4:18 PM, John Sarman <johnsar...@gmail.com> wrote:
> > So maybe we should just remove all the scoped classes. Add the code to
> > automagically find a cdi impl, weld etc.
>
> yeah, we can use jdk's ServiceLoader to see whats on the classpath.
>
Using ServiceLoader will break in OSGi environments.
>
> > Create custom factory that
> > CdiConfiguration is set up via parameters in web.xml.
>
> im not sure this is necessary, it will make it more difficult for
> deployments where its hard to find the bean manager (ie its not in a
> well known place in jndi). the only part this saves is calling new
> CdiConfiguration()....configure(this) in application init, right? i
> actually like that part because it makes it clear what options i set -
> propagation, etc.
>
> >Then after
> > instantiating the App pass it to the NonContextual for injection.
>
> see below
>
> > Rewrite
> > the tests to work with new technique. This allows app injection with
> Wicket
> > in charge, before init. And everything works the same. That may be a
> > better roadmap for the rewrite. Also that does eliminate the need for
> the
> > weld listener.
> >
> > Time to start planning on a rewrite, I am not married to the Injection,
> > just like to add @Resource(mailSessionJNDI) to my Application and use it
> in
> > init().
>
> the application is already injected, thats why i dont understand why
> you had a problem with the original way of doing things...
>
> public class MyApplication extends WebApplication {
> @Resource resource;
>
> public void init() {
> // do some configuration
>
> new CdiConfiguration().configure(this);
>
> // after the line above the application is injected and resource
> is now available. by default injectApplication bit in CdiConfiguration
> is set to true and it passes the instance through NonContextual.
>
> resource.doSomething();
> }
> }
>
> -igor
>
>
> >
> >
> > On Wed, Nov 13, 2013 at 6:40 PM, Igor Vaynberg <igor.vaynb...@gmail.com
> >wrote:
> >
> >> On Wed, Nov 13, 2013 at 2:42 PM, John Sarman <johnsar...@gmail.com>
> wrote:
> >>
> >> <snip>
> >>
> >> >> further you are assuming i am running inside a container that has its
> >> >> filter's managed by cdi, this is not always the case so using your
> cdi
> >> >> filter would fail. one would have to fall back on wicket-filter and
> >> >>
> >> >
> >> > I am 100% assuming that since you just included wicket-weld in the
> build.
> >> > Therefore you do have a managed container at that point.
> >>
> >> 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?
> >
> >
> >> >> specify the cdi application factory that you provide, but that class
> >> >> itself assumes it is managed by cdi, so it wont work either. so you
> >> >> did not leave an escape hatch for people using simple containers.
> >> >>
> >> >> my original code may not be "cdi-pretty" but it works for all
> >> >> containers out there - cdi managed or not.
> >> >
> >> > I couldn't have got anywhere without your code. I was pretty to me
> >> m_BLAH
> >> > m_BLAT is ugly.
> >> > I'm an ole school constructor versus setter myself, Object is ready at
> >> > Construction. But with CDI I get that guarantee with the no arg,
> easier
> >> to
> >> > Mock.
> >>
> >> unfortunately WebApplication instances are not ready at construction,
> >> that is the problem.
> >
> >
> >> >> > No need to start up CDI in init()
> >> >>
> >> >> we do not start up cdi in init, we configure how it interacts with
> the
> >> >> wicket application. settings such things as conversation propagation
> >> >> mode, etc.
> >> >>
> >> >
> >> > Yeah but that starts it otherwise the Injectors are not set up and it
> >> > wouldn't work(inject).
> >>
> >> in our deployment we have a servlet listener that bootstraps cdi so
> >> its available to other servlets, not just wicket. in
> >> application.init() you simply configure wicket to use cdi by giving it
> >> the bean manager. this approach also works in environments with no
> >> JNDI where you cannot simply pull a bean manager out of some store but
> >> have to use a custom mechanism to retrieve it. imagine an application
> >> with an embedded servlet container.
> >
> >
> >> <snip>
> >>
> >> >> my problem with this is that there is a specific lifecycle to the
> >> >> application that is not managed by cdi. it is not safe to use the
> >> >> application instance after it has been created, you have to wait
> until
> >> >> wicket calls certain methods on it.
> >> >>
> >> >
> >> > Yeah, I do wait. That's why I used the Factory. Only thing that is
> done
> >> is
> >> > some member variables are populated. I did not override Wicket
> >> management,
> >> > just injected some dependencies.
> >>
> >> you wait, but the users may not. now that application instance is
> >> managed by cdi why cant i do something like this:
> >>
> >> class WebConfigurator {
> >> @Inject WebApplication application;
> >>
> >> private void configure(@Observes ContainerStartEvent) {
> >> application.getMarkupSettings().setFoo(bar);
> >> }
> >> }
> >>
> > after all, this would be the CDI-way of configuring the web
> >> application instance. but this does not work because webapplication
> >> instance is managed by wicket and not by cdi. so if this code runs
> >> before the filter my settings would be overwritten by internalInit()
> >> call.
> >>
> >> this is the impedance mismatch i do not like. artifacts whose
> >> lifecycle is managed by wicket should not also be managed by cdi, or
> >> if they are there should be a provider that creates instances and
> >> knows how to correctly configure it.
> >>
> >> so in the case above when my configurator is called the provider
> >> should bootstrap the wicket application, call internalinit(), and have
> >> it all ready for my code.
> >>
> >> >> by making it managed you are giving the impression that it is safe to
> >> >> inject the instance and use it in various places. it is not, not
> until
> >> >> it has been properly configured. i do not want to debug cases where
> my
> >> >> configuration changes to the application disappear because my code
> got
> >> >> that injected the application and configured it got called before
> >> >> internalInit(). either create a subcpass with @PostConstruct that
> >> >> configures the application - which wont work - people dont like using
> >> >> subclasses - or create a provider.
> >> >>
> >> >
> >> > Like I said Cdi injects some members, the Factory returns the
> application
> >> > to WicketFilter and the same lifecycle commences.
> >>
> >> see point above, by making it managed you are making it available for
> >> other code to consume as injectable.
> >>
> >
> > John
> >
> >
> >
> >> -igor
> >>
>
