On Wed, Nov 13, 2013 at 2:42 PM, John Sarman <[email protected]> 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.
-igor
