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.
> 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
>>
