Re: Future of wicket-cdi
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
Re: Future of wicket-cdi
On Thu, Nov 14, 2013 at 2:27 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
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,
Re: Future of wicket-cdi
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 emond.papega...@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
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 emond.papega...@gmail.comwrote: 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
So let me filter through injection of App. CdiWicketFilter gets injected factory. @Inject CdiWebApplicationFactory applicationFactory; the Factory get injected the following @Inject @Any InstanceWebApplication applications; @Inject CdiConfiguration cdiConfiguration; If there is only one application in a war then the web.xml only needs filter filter-nameCdiApplication/filter-name filter-classorg.apache.wicket.cdi.CdiWicketFilter/filter-class /filter if multiple then additional init-param param-nameapplicationName/param-name param-valueCdiExample/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-nameCdiApplication/filter-name filter-classorg.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 igor.vaynb...@gmail.comwrote: 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 emond.papega...@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
On Wed, Nov 13, 2013 at 1:43 PM, John Sarman johnsar...@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 InstanceWebApplication applications; @Inject CdiConfiguration cdiConfiguration; If there is only one application in a war then the web.xml only needs filter filter-nameCdiApplication/filter-name filter-classorg.apache.wicket.cdi.CdiWicketFilter/filter-class /filter if multiple then additional init-param param-nameapplicationName/param-name param-valueCdiExample/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-nameCdiApplication/filter-name filter-classorg.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 igor.vaynb...@gmail.comwrote: 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 emond.papega...@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
Re: Future of wicket-cdi
On Wed, Nov 13, 2013 at 5:21 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: On Wed, Nov 13, 2013 at 1:43 PM, John Sarman johnsar...@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 InstanceWebApplication applications; @Inject CdiConfiguration cdiConfiguration; If there is only one application in a war then the web.xml only needs filter filter-nameCdiApplication/filter-name filter-classorg.apache.wicket.cdi.CdiWicketFilter/filter-class /filter if multiple then additional init-param param-nameapplicationName/param-name param-valueCdiExample/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-nameCdiApplication/filter-name filter-classorg.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.vaynb...@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 emond.papega...@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
Re: Future of wicket-cdi
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.
-igor
Re: Future of wicket-cdi
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 igor.vaynb...@gmail.comwrote:
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
Re: Future of wicket-cdi
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.comwrote:
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
Re: Future of wicket-cdi
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 igor.vaynb...@gmail.comwrote:
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.
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.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
