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