You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by John Sarman <jo...@gmail.com> on 2013/06/26 12:31:28 UTC
Starting discussion about cdi-1.1 integration.
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.
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
Re: Starting discussion about cdi-1.1 integration.
Posted by Martin Grigorov <mg...@apache.org>.
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 <jo...@gmail.com> 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 <jo...@gmail.com> 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 <mgrigorov@apache.org
> >wrote:
> >
> >> On Wed, Jun 26, 2013 at 2:49 PM, John Sarman <jo...@gmail.com>
> >> 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 <
> mgrigorov@apache.org
> >> > >wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > >
> >> > > On Wed, Jun 26, 2013 at 1:31 PM, John Sarman <jo...@gmail.com>
> >> > 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
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: Starting discussion about cdi-1.1 integration.
Posted by John Sarman <jo...@gmail.com>.
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 <jo...@gmail.com> 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 <mg...@apache.org>wrote:
>
>> On Wed, Jun 26, 2013 at 2:49 PM, John Sarman <jo...@gmail.com>
>> 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 <mgrigorov@apache.org
>> > >wrote:
>> >
>> > > Hi,
>> > >
>> > >
>> > > On Wed, Jun 26, 2013 at 1:31 PM, John Sarman <jo...@gmail.com>
>> > 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
>> > > >
>> > >
>> >
>>
>
>
Re: Starting discussion about cdi-1.1 integration.
Posted by John Sarman <jo...@gmail.com>.
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 <mg...@apache.org>wrote:
> On Wed, Jun 26, 2013 at 2:49 PM, John Sarman <jo...@gmail.com> 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 <mgrigorov@apache.org
> > >wrote:
> >
> > > Hi,
> > >
> > >
> > > On Wed, Jun 26, 2013 at 1:31 PM, John Sarman <jo...@gmail.com>
> > 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
> > > >
> > >
> >
>
Re: Starting discussion about cdi-1.1 integration.
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Jun 26, 2013 at 2:49 PM, John Sarman <jo...@gmail.com> 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 <mgrigorov@apache.org
> >wrote:
>
> > Hi,
> >
> >
> > On Wed, Jun 26, 2013 at 1:31 PM, John Sarman <jo...@gmail.com>
> 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
> > >
> >
>
Re: Starting discussion about cdi-1.1 integration.
Posted by John Sarman <jo...@gmail.com>.
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 <mg...@apache.org>wrote:
> Hi,
>
>
> On Wed, Jun 26, 2013 at 1:31 PM, John Sarman <jo...@gmail.com> 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
> >
>
Re: Starting discussion about cdi-1.1 integration.
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Wed, Jun 26, 2013 at 1:31 PM, John Sarman <jo...@gmail.com> 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
>