>>>At the time OWB picks up the extension, we will try to add the javax.faces.bean.ViewScoped.class and the corresponding Context to the BeanManager >>>-> kawumms, because the ViewScoped.class is not available in JSF-1.2 Maybe I did not explain it better, but OWB uses JSF2 not JSF 1.2. Look at "trunk/pom.xml" and "webbeans-jsf/pom.xml". So, there is no such a think that "it uses JSF2 but OWB does not support it". OWB uses JSF2 API not JSF 1.2 or earlier. But we can still support OWB with JSF 1.2 runtimes. For example, we can add some property to "openwebbeans.properties" like
use.JSF2.extensions = true/false (default true) If developer wants to use OWB with JSF 1.2, it defines openwebbeans.properties file with "use.JSF2.extensions=false", so we can disable JSF2 extensions in JSF 1.2 environments. >>>What about introducing an own 'extensions' module for parts which are not OWB specific but would also work on other containers? +1, but this can be delayed. And it requires a bit thinking :) >>>webbeans-extensions >>> +- cdi-jsf2 >>>> | +- cdi-jsf2-api (contains e.g. a new @FlashScoped annotation) >>> | +- cdi-jsf2-impl (contains extensions for @ViewScoped + @FlashScoped) >>> +- cdi-another I really hate this! We are not implementing JSF2 specs, APIs etc. This is provided by the JSF2 implementations. Therefore my comment on JSF extensions is that; * Write JSF extensions in webbeans-jsf package for the time being. Use properties scenario (I explained) to disable this extension in JSF 1.2 environments. Thanks; --Gurkan 2010/1/12 Mark Struberg <strub...@yahoo.de> > in theory yes, in praxis no ;) > > At the time OWB picks up the extension, we will try to add the > javax.faces.bean.ViewScoped.class and the corresponding Context to the > BeanManager -> kawumms, because the ViewScoped.class is not available in > JSF-1.2 > > Thus, I really hesitate to check it in :( > > I also already thought about adding a webbeans-extensions module (copying > over from my currently composing mail): > > What about introducing an own 'extensions' module for parts which are not > OWB specific but would also work on other containers? > > I have the following structure in mind: > > webbeans-extensions > +- cdi-jsf2 > | +- cdi-jsf2-api (contains e.g. a new @FlashScoped annotation) > | +- cdi-jsf2-impl (contains extensions for @ViewScoped + @FlashScoped) > +- cdi-another > > Otoh, this interferes with seam3 which will also contain such an extension. > And there is currently no way to disable 'parts' of an extension. The way to > go is imho to introduce some properties to 'disable' parts of the > functionality of an extension manually. > > After talking with Nik and Pete on IRC, I'm pretty sure that we need to do > this extensions, because Seam3 is still LGPL and so we wouldn't be able to > provide this functionality for Geronimo or MyFaces if needed some days. > And supporting @ViewScoped via CDI may be part of the next JSF spec?... > > LieGrue, > strub > > --- On Tue, 1/12/10, Gurkan Erdogdu <cgurkanerdo...@gmail.com> wrote: > > > From: Gurkan Erdogdu <cgurkanerdo...@gmail.com> > > Subject: Re: fully going JSF2? > > To: dev@openwebbeans.apache.org > > Date: Tuesday, January 12, 2010, 12:46 PM > > >>>This also has the side > > effect that we now for the first time really use > > JSF2 functionality, and thus it would not be possible to > > use OWB with JSF-1 > > >>>applications anymore > > > > Actually this is not correct observation. OWB does not > > depend on any JSF > > specific implementations. And you know that core OWB does > > not require any > > JSF library (Plugin model). You can use OWB with/without > > JSF. > > > > From JSF Perspective > > ---------------------------------------- > > Currently we are providing CDI Conversation Context via our > > "webbeans-jsf" > > module. This module has a dependency on "MyFaces > > 2.0.0-alpha API" as an > > optional because JSF libraries are provided at runtime via > > containers/developers. As you see, even webbeans-jsf module > > does not depend > > on any JSF implementation or specific JSF 1.2/2.0 API etc. > > Therefore we can > > put any JSF 1.2/2.0 related code here, because this module > > uses 2.0 API and > > 2.0 API is backward compatible with 1.2 API (Means that 1.2 > > APIs are > > contained in 2.0 API). If anyone would like to use our JSF > > 2.0 functionality > > (like ViewScoped), then he requires to add JSF 2.0 > > implementation libraries > > into his application class path. > > > > In summary, OWB is not related with JSF implementations. It > > uses JSF2 API, > > that is all. If anyone wants to use our JSF2 funtions, he > > has to provide > > runtime JSF2 libraries. > > > > For example, some JSF samples are currently run with JSF > > 2.0 libraries while > > some of them uses JSF 1.2 libraries. Both of them uses > > webbeans-impl and > > webbeans-jsf modules. > > > > From Extensions Perspective > > ------------------------------------------- > > But, it is reasonable for me that we can define > > "webbeans-extensions" module > > that is independent from CDI implementations. But I am not > > sure, whether ot > > not this module depend on any OWB specific code! > > > > > > Thanks; > > > > --Gurkan > > > > > > > > 2010/1/12 Mark Struberg <strub...@yahoo.de> > > > > > Hi! > > > > > > I have coded the javax.faces.bean.ViewScoped handling > > and it turned out > > > that I do not need anything OWB special. So this i a > > completely CDI > > > independent portable implementation, and as such I'm > > in favour to _not_ add > > > it to openwebbeans-jsf but to a new 'extensions' > > module. > > > > > > This also has the side effect that we now for the > > first time really use > > > JSF2 functionality, and thus it would not be possible > > to use OWB with JSF-1 > > > applications anymore! But since I consider OWB + JSF-1 > > a very important > > > scenario (for making migration easier and due to the > > fact that there is > > > still no JSF-2 component taglib on the market!), I > > don't like to add this to > > > openwebbeans-jsf. > > > > > > This opens the general question on how we cope with > > JSF-1 vs JSF-2 in the > > > future. > > > > > > LieGrue, > > > strub > > > > > > > > > > > > > > > > > > -- > > Gurkan Erdogdu > > http://gurkanerdogdu.blogspot.com > > > > > > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
