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 <[email protected]>wrote: > On Wed, Nov 13, 2013 at 4:18 PM, John Sarman <[email protected]> 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 <[email protected] > >wrote: > > > >> On Wed, Nov 13, 2013 at 2:42 PM, John Sarman <[email protected]> > wrote: > >> > >> <snip> > >> > >> >> further you are assuming i am running inside a container that has its > >> >> filter's managed by cdi, this is not always the case so using your > cdi > >> >> filter would fail. one would have to fall back on wicket-filter and > >> >> > >> > > >> > I am 100% assuming that since you just included wicket-weld in the > build. > >> > Therefore you do have a managed container at that point. > >> > >> we deploy in tomcat. we include weld as a war-dependency, not as > >> tomcat dependency, therefore in our deployments filters are not > >> injected. i assume this is how most people deploying to tomcat or > >> jetty have it set up. are we dropping support for those people? > > > > > >> >> specify the cdi application factory that you provide, but that class > >> >> itself assumes it is managed by cdi, so it wont work either. so you > >> >> did not leave an escape hatch for people using simple containers. > >> >> > >> >> my original code may not be "cdi-pretty" but it works for all > >> >> containers out there - cdi managed or not. > >> > > >> > I couldn't have got anywhere without your code. I was pretty to me > >> m_BLAH > >> > m_BLAT is ugly. > >> > I'm an ole school constructor versus setter myself, Object is ready at > >> > Construction. But with CDI I get that guarantee with the no arg, > easier > >> to > >> > Mock. > >> > >> unfortunately WebApplication instances are not ready at construction, > >> that is the problem. > > > > > >> >> > No need to start up CDI in init() > >> >> > >> >> we do not start up cdi in init, we configure how it interacts with > the > >> >> wicket application. settings such things as conversation propagation > >> >> mode, etc. > >> >> > >> > > >> > Yeah but that starts it otherwise the Injectors are not set up and it > >> > wouldn't work(inject). > >> > >> in our deployment we have a servlet listener that bootstraps cdi so > >> its available to other servlets, not just wicket. in > >> application.init() you simply configure wicket to use cdi by giving it > >> the bean manager. this approach also works in environments with no > >> JNDI where you cannot simply pull a bean manager out of some store but > >> have to use a custom mechanism to retrieve it. imagine an application > >> with an embedded servlet container. > > > > > >> <snip> > >> > >> >> my problem with this is that there is a specific lifecycle to the > >> >> application that is not managed by cdi. it is not safe to use the > >> >> application instance after it has been created, you have to wait > until > >> >> wicket calls certain methods on it. > >> >> > >> > > >> > Yeah, I do wait. That's why I used the Factory. Only thing that is > done > >> is > >> > some member variables are populated. I did not override Wicket > >> management, > >> > just injected some dependencies. > >> > >> you wait, but the users may not. now that application instance is > >> managed by cdi why cant i do something like this: > >> > >> class WebConfigurator { > >> @Inject WebApplication application; > >> > >> private void configure(@Observes ContainerStartEvent) { > >> application.getMarkupSettings().setFoo(bar); > >> } > >> } > >> > > after all, this would be the CDI-way of configuring the web > >> application instance. but this does not work because webapplication > >> instance is managed by wicket and not by cdi. so if this code runs > >> before the filter my settings would be overwritten by internalInit() > >> call. > >> > >> this is the impedance mismatch i do not like. artifacts whose > >> lifecycle is managed by wicket should not also be managed by cdi, or > >> if they are there should be a provider that creates instances and > >> knows how to correctly configure it. > >> > >> so in the case above when my configurator is called the provider > >> should bootstrap the wicket application, call internalinit(), and have > >> it all ready for my code. > >> > >> >> by making it managed you are giving the impression that it is safe to > >> >> inject the instance and use it in various places. it is not, not > until > >> >> it has been properly configured. i do not want to debug cases where > my > >> >> configuration changes to the application disappear because my code > got > >> >> that injected the application and configured it got called before > >> >> internalInit(). either create a subcpass with @PostConstruct that > >> >> configures the application - which wont work - people dont like using > >> >> subclasses - or create a provider. > >> >> > >> > > >> > Like I said Cdi injects some members, the Factory returns the > application > >> > to WicketFilter and the same lifecycle commences. > >> > >> see point above, by making it managed you are making it available for > >> other code to consume as injectable. > >> > > > > John > > > > > > > >> -igor > >> >
