You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Emond Papegaaij <em...@gmail.com> on 2013/11/13 22:19:49 UTC
Future of wicket-cdi
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
Re: Future of wicket-cdi
Posted by John Sarman <jo...@gmail.com>.
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
<em...@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
>
Re: Future of wicket-cdi
Posted by John Sarman <jo...@gmail.com>.
Alright I throwing my my ultimate defense. My day job I design PCB's do
embedded programming, design 3-D assemblies that my PCB's fit into and tons
of other engineering fun stuff. I use Java because to me it is an
engineers language. I use Wicket because it is flows like an Engineers
mind, well to me at least. I do not have to support users and clients for
web programming, etc. I just used Wicket to make a front end to my own
personal Database to manage my designs. My little ole program allows me to
scrape electronic component vendors for the part number datasheets, etc so
I can be lazy and not manually type in all that important stuff for every
component I use.
Currently it uses SpringBeans and I wanted to transition it to CDI plus
EJBs, and found the cdi-1.0. At the time glassfish 4 was released so I
just dove in head first to get the 1.1 working in Wicket. Ultimately here
we are. I bought your book too, I don't buy CS books typically.
So long story longer, when I ported to CDI-1.1 I had my selfish environment
and goals in mind. Thanks for the intellectual arguments, nice to work
with smart minds.
Comments below
On Wed, Nov 13, 2013 at 7:27 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> On Wed, Nov 13, 2013 at 4:18 PM, John Sarman <jo...@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.
>
ServiceLoader, ok I'll look into it and get that working. Defense to
injection it just worked but you win with the WebApplication accessible for
others argument.
> > 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.
>
BeanManager, could we not have code to look for it. That may be a tall
order to support the different containers, but seems that the jndi string
could just be overridden in web.xml for the pesky containers.
Why not either or. You like config in init, Others may like it in the
web.xml, Support both ways?
>
> >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();
> }
> }
>
I never did have a problem. I just used it after the configure as example.
Just a more than one way to skin a cat approach.
Only loss I see so far is the testing. It may be a little more tricky, it
might not be. Time will tell but I see a consensus brewing.
So here is the open questions I see.
Support for cdi using custom filter (which just overrides the
defaultFactory)? My answer yes.
Support for configuration in init(). My answer yes
Todo on current code
Remove Injection relying on cdi container.
Refactor tests.
John
> -igor
>
>
> >
> >
> > On Wed, Nov 13, 2013 at 6:40 PM, Igor Vaynberg <igor.vaynberg@gmail.com
> >wrote:
> >
> >> On Wed, Nov 13, 2013 at 2:42 PM, John Sarman <jo...@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
> >>
>
Re: Future of wicket-cdi
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Nov 14, 2013 at 2:27 AM, Igor Vaynberg <ig...@gmail.com>wrote:
> On Wed, Nov 13, 2013 at 4:18 PM, John Sarman <jo...@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.vaynberg@gmail.com
> >wrote:
> >
> >> On Wed, Nov 13, 2013 at 2:42 PM, John Sarman <jo...@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
> >>
>
Re: Future of wicket-cdi
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Nov 13, 2013 at 4:18 PM, John Sarman <jo...@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 <ig...@gmail.com>wrote:
>
>> On Wed, Nov 13, 2013 at 2:42 PM, John Sarman <jo...@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
>>
Re: Future of wicket-cdi
Posted by John Sarman <jo...@gmail.com>.
So maybe we should just remove all the scoped classes. Add the code to
automagically find a cdi impl, weld etc. Create custom factory that
CdiConfiguration is set up via parameters in web.xml. Then after
instantiating the App pass it to the NonContextual for injection. 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().
On Wed, Nov 13, 2013 at 6:40 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> On Wed, Nov 13, 2013 at 2:42 PM, John Sarman <jo...@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
>
Re: Future of wicket-cdi
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Nov 13, 2013 at 2:42 PM, John Sarman <jo...@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.
-igor
Re: Future of wicket-cdi
Posted by John Sarman <jo...@gmail.com>.
On Wed, Nov 13, 2013 at 5:21 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> On Wed, Nov 13, 2013 at 1:43 PM, John Sarman <jo...@gmail.com> wrote:
> > So let me filter through injection of App.
> > CdiWicketFilter gets injected factory.
> > @Inject
> > CdiWebApplicationFactory applicationFactory;
> >
> > the Factory get injected the following
> > @Inject
> > @Any
> > Instance<WebApplication> applications;
> > @Inject
> > CdiConfiguration cdiConfiguration;
> >
> > If there is only one application in a war then the web.xml only needs
> > <filter>
> > <filter-name>CdiApplication</filter-name>
> > <filter-class>org.apache.wicket.cdi.CdiWicketFilter</filter-class>
> > </filter>
> > if multiple then additional
> > <init-param>
> > <param-name>applicationName</param-name>
> > <param-value>CdiExample</param-value>
> > </init-param>
> > and @WicketApp("CdiExample") added.
>
> i dont see this as an advantage. specifying a class name is trivial.
>
Yeah I didn't do it as simplification it just organically happened that way.
Initially I used injection to find CDI Impl without needing to write code
to find it.
>
> 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.
> 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.
> >
> > 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).
>
> > Start using CDI.
> >
> > For apps that may want to add CDI they just
> > <filter>
> > <filter-name>CdiApplication</filter-name>
> > <filter-class>org.apache.wicket.cdi.CdiWicketFilter</filter-class>
> > </filter>
> >
> > Start using CDI.
> >
> > So I still defend injection of the Cdi Wicket integration code.
> >
> > Also if it is removed then code will have to be added to differentiate
> > which cdi implementation is being used.
> >
> > Currently CDI does this so long as two different CDI implementation jars
> > aren't add, which would be ambiguous.
>
> this will still work. you can still inject the configuration using
> noncontextual and pull the right instance. or use jdk's ServiceLoader
> to find all implementors.
>
> 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.
> 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.
>
> -igor
>
> > On Wed, Nov 13, 2013 at 4:31 PM, Igor Vaynberg <igor.vaynberg@gmail.com
> >wrote:
> >
> >> i agree we should restart with the original implementation and
> >> incrementally introduce the new features - thats what i proposed in
> >> the original pull request.
> >>
> >> 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...
> >>
> >> -igor
> >>
> >>
> >> On Wed, Nov 13, 2013 at 1:19 PM, Emond Papegaaij
> >> <em...@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
> >>
>
Re: Future of wicket-cdi
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Nov 13, 2013 at 1:43 PM, John Sarman <jo...@gmail.com> wrote:
> So let me filter through injection of App.
> CdiWicketFilter gets injected factory.
> @Inject
> CdiWebApplicationFactory applicationFactory;
>
> the Factory get injected the following
> @Inject
> @Any
> Instance<WebApplication> applications;
> @Inject
> CdiConfiguration cdiConfiguration;
>
> If there is only one application in a war then the web.xml only needs
> <filter>
> <filter-name>CdiApplication</filter-name>
> <filter-class>org.apache.wicket.cdi.CdiWicketFilter</filter-class>
> </filter>
> if multiple then additional
> <init-param>
> <param-name>applicationName</param-name>
> <param-value>CdiExample</param-value>
> </init-param>
> and @WicketApp("CdiExample") added.
i dont see this as an advantage. specifying a class name is trivial.
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
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.
>
> 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.
> Start using CDI.
>
> For apps that may want to add CDI they just
> <filter>
> <filter-name>CdiApplication</filter-name>
> <filter-class>org.apache.wicket.cdi.CdiWicketFilter</filter-class>
> </filter>
>
> Start using CDI.
>
> So I still defend injection of the Cdi Wicket integration code.
>
> Also if it is removed then code will have to be added to differentiate
> which cdi implementation is being used.
>
> Currently CDI does this so long as two different CDI implementation jars
> aren't add, which would be ambiguous.
this will still work. you can still inject the configuration using
noncontextual and pull the right instance. or use jdk's ServiceLoader
to find all implementors.
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.
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.
-igor
> On Wed, Nov 13, 2013 at 4:31 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> i agree we should restart with the original implementation and
>> incrementally introduce the new features - thats what i proposed in
>> the original pull request.
>>
>> 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...
>>
>> -igor
>>
>>
>> On Wed, Nov 13, 2013 at 1:19 PM, Emond Papegaaij
>> <em...@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
>>
Re: Future of wicket-cdi
Posted by John Sarman <jo...@gmail.com>.
So let me filter through injection of App.
CdiWicketFilter gets injected factory.
@Inject
CdiWebApplicationFactory applicationFactory;
the Factory get injected the following
@Inject
@Any
Instance<WebApplication> applications;
@Inject
CdiConfiguration cdiConfiguration;
If there is only one application in a war then the web.xml only needs
<filter>
<filter-name>CdiApplication</filter-name>
<filter-class>org.apache.wicket.cdi.CdiWicketFilter</filter-class>
</filter>
if multiple then additional
<init-param>
<param-name>applicationName</param-name>
<param-value>CdiExample</param-value>
</init-param>
and @WicketApp("CdiExample") added.
No need to start up CDI in init()
Start using CDI.
For apps that may want to add CDI they just
<filter>
<filter-name>CdiApplication</filter-name>
<filter-class>org.apache.wicket.cdi.CdiWicketFilter</filter-class>
</filter>
Start using CDI.
So I still defend injection of the Cdi Wicket integration code.
Also if it is removed then code will have to be added to differentiate
which cdi implementation is being used.
Currently CDI does this so long as two different CDI implementation jars
aren't add, which would be ambiguous.
On Wed, Nov 13, 2013 at 4:31 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> i agree we should restart with the original implementation and
> incrementally introduce the new features - thats what i proposed in
> the original pull request.
>
> 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...
>
> -igor
>
>
> On Wed, Nov 13, 2013 at 1:19 PM, Emond Papegaaij
> <em...@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
>
Re: Future of wicket-cdi
Posted by Igor Vaynberg <ig...@gmail.com>.
i agree we should restart with the original implementation and
incrementally introduce the new features - thats what i proposed in
the original pull request.
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...
-igor
On Wed, Nov 13, 2013 at 1:19 PM, Emond Papegaaij
<em...@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
Re: Future of wicket-cdi
Posted by John Sarman <jo...@gmail.com>.
On Thu, Nov 14, 2013 at 3:36 AM, Emond Papegaaij <emond.papegaaij@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
>
Re: Future of wicket-cdi
Posted by Emond Papegaaij <em...@topicus.nl>.
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.
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.
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.
Best regards,
Emond