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 >> > > > >> > > >> > >> > >
