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