The Pull Request is applied and Wicket-Examples CDI example is updated to CDI 1.1 with Weld.
Next step I think is to add some unit tests. Igor suggested to take a look at http://jglue.org/cdi-unit/ On Wed, Jun 26, 2013 at 8:12 PM, John Sarman <[email protected]> wrote: > I just sent a pull request for the refactor Martin described. Also updated > the example code https://github.com/jsarman/WicketCdiExample > > Code is setup to work with tomcat 7. > > > > > On Wed, Jun 26, 2013 at 8:20 AM, John Sarman <[email protected]> wrote: > > > INFO: > > > validateJarFile(WicketCdiExample-2.0-SNAPSHOT\WEB-INF\lib\el-api-2.2.jar) - > > jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: > > javax/el/Expression.class > > More precisely cdi-1.1 has a transitive dependency with el-api-2.2.jar > and > > it does not get loaded. The app works fine just line noise. Actually > > weld-servlet-2.0.1.Final also accidentally included the javax.el package > > and the listener will not load if you use that version. That causes the > > app to fail. > > > > In either case the app developer will always have to include some weld > > impl code for non ee7 app servers. > > So we have a few options. > > > > 1. compile scope cdi and weld-api > > Still need weld-servlet in app pom > > > > 2. compile scope cdi and add weld-servlet as compile scope. > > This works cleanly for jetty and tomcat, user still has to edit > > context.xml and web.xml to bring up beanmanager. > > For jboss gf4 it justs adds bloat to war file and potential class > > loading issues. > > To overcome this the app dev will just add exclusions to the > > dependency > > > > 3. provided scope for cdi and weld-api > > This forces tomcat jetty user to include weld-servlet. > > Works seamless for ee7 app servers. > > > > Tomcat and Jetty users will always have to do additional work to init the > > beanmanager see > > > http://docs.jboss.org/weld/reference/2.0.0.Final/en-US/html_single/#d0e5324 > > > > John > > > > > > > > > > On Wed, Jun 26, 2013 at 7:55 AM, Martin Grigorov <[email protected] > >wrote: > > > >> On Wed, Jun 26, 2013 at 2:49 PM, John Sarman <[email protected]> > >> wrote: > >> > >> > I am currently working on splitting the codebase as you suggested > >> similar > >> > to the websocket structure. However the way the app pom will be is > >> similar > >> > to Atmosphere's requirement of adding the stubs at app level. > >> > The reason for this is because the cdi ref impl may or may not already > >> be > >> > in the app. Also cdi-1.1 contains javax.el package which will cause an > >> > invalid jar file see servlet 2.3 spec error in Tomcat. > >> > > >> > >> What is the error ? > >> AFAIK the servlet container complains when the app brings > servlet-api.jar > >> in WEB-INF/lib/. But I'm not aware of other limitations for javax.** > >> classes. > >> > >> > >> > So the core package will set the cdi-1.1 dependencies scope to > provided. > >> > The weld package will have the weld-2.0-api dependencies scope set to > >> > provided. > >> > > >> > >> Scope "provided" is OK. I understand why it has to be like this. > >> > >> > >> > If you are deploying to tomcat the pom will contain the following > >> > > >> > <dependency> > >> > <groupId>org.apache.wicket</groupId> > >> > <artifactId>wicket-cdi-1.1-weld</artifactId> > >> > <version>${wicket.version}</version> > >> > </dependency> > >> > > >> > <dependency> > >> > <groupId>org.jboss.weld.servlet</groupId> > >> > <artifactId>weld-servlet</artifactId> > >> > <version>2.0.0.SP1</version> > >> > </dependency> > >> > > >> > Plus some code in web.xml and context.xml to initialize the cdi > >> container. > >> > > >> > >> If wicket-cdi-1.1 will be only in Wicket 7.x then we can use > >> web-fragment.xml or annotations. Wicket 7.x requires Servlet 3.0. > >> > >> > >> > > >> > In this case weld-servlet.jar contains all classes needed for weld cdi > >> RI. > >> > > >> > For glassfish4 you would include just > >> > <dependency> > >> > <groupId>org.apache.wicket</groupId> > >> > <artifactId>wicket-cdi-1.1-weld</artifactId> > >> > <version>${wicket.version}</version> > >> > </dependency> > >> > > >> > because gf4 already integrates the weld codebase. > >> > > >> > If we didn't set to provided the app developer would have alot of > >> > exclusions in the pom, which would be counter productive in this > >> instance. > >> > > >> > John > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > On Wed, Jun 26, 2013 at 7:34 AM, Martin Grigorov < > [email protected] > >> > >wrote: > >> > > >> > > Hi, > >> > > > >> > > > >> > > On Wed, Jun 26, 2013 at 1:31 PM, John Sarman <[email protected]> > >> > wrote: > >> > > > >> > > > First, > >> > > > I was able to integrate Weld-api-2.0 with only a few changes to > the > >> > > cdi-1.0 > >> > > > base code which was branched into cdi-1.1 around march. > >> > > > > >> > > > That being said Martin suggests that the final design be split > into > >> > > > wicket-cdi-1.1-core. Wicket-cdi-1.1-weld, and in the future > >> > > > wicket-cd1-1.1-owb, once owb has support for cdi-1.1. > >> > > > > >> > > > >> > > Yes. Initially I thought that CDI 1.1 will provide the APIs for > >> managing > >> > > the conversations but it seems this is not the case. > >> > > We will still need to use implementation specific classes to support > >> > them. > >> > > https://issues.apache.org/jira/browse/WICKET-4951 is about support > >> > > OpenWebBeans. > >> > > http://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-cdi11/is > >> > > about > >> > > CDI 1.1 but I have no idea how complete it is. > >> > > > >> > > Wicket Native WebSocket uses the approach of -core, -jetty, -jetty9, > >> > > -tomcat, -glassfish to integrate with the respective servlet > >> container. > >> > > When using them in Jetty 7/8 all one need is to add dependency on > >> > > wicket-native-websocket-jetty.jar (-core.jar will come as transitive > >> > > dependency). > >> > > With the WebSocket spec this may be improved but I haven't played > >> with it > >> > > yet. > >> > > > >> > > Atmosphere does this differently - to be transparent it requires to > >> add > >> > > some jars with stub classes. E.g. when running in Jetty the > >> application > >> > > should provide atmosphere-tomcat.jar, atmosphere-jboss.jar, > >> > > atmosphere-glassfish.jar (see > >> > > > >> > > > >> > > >> > https://github.com/Atmosphere/atmosphere/wiki/Structure-of-an-Atmosphere's-Application > >> > > for > >> > > details). I personally find it more confusing. > >> > > > >> > > I've CC'd Mark Struberg from OWB team because he offered help > several > >> > > months ago. > >> > > > >> > > > >> > > > > >> > > > I just wanted to start a discussion to gather opinions and best > way > >> to > >> > > move > >> > > > forward. > >> > > > > >> > > > To see it in action you can pull from > >> > > > > >> > > > git pull https://github.com/jsarman/wicket cdi-1.1 > >> > > > > >> > > > > >> > > > Also I ported Igor's cdi example and placed it here > >> > > > > >> > > > https://github.com/jsarman/WicketCdiExample > >> > > > > >> > > > The example currently is setup to work on tomcat 7. > >> > > > > >> > > > John Sarman > >> > > > > >> > > > >> > > >> > > > > >
