Yes we can start that way. But having 2 modules would have the benefit that we can define the corresponding dependencies and thus make sure that we do not use 'newer' features at compile time.
LieGrue, strub --- Gurkan Erdogdu <[email protected]> schrieb am Do, 17.12.2009: > Von: Gurkan Erdogdu <[email protected]> > Betreff: Re: Integration of JSF2 specific API calls > An: [email protected] > Datum: Donnerstag, 17. Dezember 2009, 10:49 > >>>I think we will start > hacking on the feature and if we hit the point of > no return we should create an own module. > We could definitely create a new package for unique JSF2 > features if we will > have under webbeans-jsf project. So management and > configuration are much > more easy with having one JSF module. > > > 2009/12/17 Gurkan Erdogdu <[email protected]> > > > What I mean is that, > > > > Our code base has nothing regarding to JSF 1.2 like > other JSF > > Frameworks/Tools etc. do. > > > > We have just implemented 2 class for conversation > service > > > > 1* WebBeansPhase Listener --> For restore > conversations > > 2* Custom View Handler > --> For adding cid to view handler > > > > Both of them work on any JSF1.2 or JSF2 > implementation. > > > > Therefore it is not rational to define new jsf2 > project from my point of > > view. If we were implementing lots of code unique to > JSF 1.2 then it will be > > reasonable to define new JSF2 project but we did not. > Actually it is > > meaningless for me to separate JSF 1.2 and JSF 2. > > > > We must not think of such a backward compatibility > with JSF 1.2 etc because > > we have been implementing Java EE 6 defined JSR-299 > specification. > > > > > > --Gurkan > > > > 2009/12/17 Mark Struberg <[email protected]> > > > >> Gurkan, > >> > >> I was not talking about special products, I also > meant the API and I > >> mentioned RichFaces-3.3.2 only as an example. You > can google for the > >> incompatibility problems. > >> > >> Matter of fact: > >> .) EE6 WebProfile defines JSF-2, so from this > point I'm with you > >> > >> But: > >> .) there is no full stack for JSF-2 on the market > currently (the component > >> libraries are missing, since they are mostly > incompatible) > >> Plus, there will be lot old projects which still > use JSF-1.2 but may like > >> to use OWB for new extensions. > >> > >> and as such: > >> .) providing an easy migration path to EE6 by > allowing to use JSF-1.2 + > >> OWB would imho be a pretty nice goodie. > >> > >> I don't think it will confuse users if they have a > choice between a > >> JSF-1.2 and a JSF-2 plugin if we explain the > differences in the > >> documentation. > >> I think we will start hacking on the feature and > if we hit the point of no > >> return we should create an own module. > >> > >> > >> wdyt? > >> > >> LieGrue, > >> strub > >> > >> --- Gurkan Erdogdu <[email protected]> > schrieb am Do, 17.12.2009: > >> > >> > Von: Gurkan Erdogdu <[email protected]> > >> > Betreff: Re: Integration of JSF2 specific API > calls > >> > An: [email protected] > >> > Datum: Donnerstag, 17. Dezember 2009, 10:03 > >> > Hey Mark, > >> > > >> > >>E.g. try running RichFaces-3.3.2 on a > JSF-2 > >> > container ;) > >> > Java EE standards do not depend on any > special product! > >> > Standards talk about > >> > API. > >> > > >> > >>In JSF-1.2 there was no standardised > ajax handling, > >> > so we would have no > >> > chance to use those features in a portable > fashion. > >> > JSR-299 is contained in Java EE 6. Java EE 6 > defines JSF2 > >> > and when we talk > >> > about JSF functionality, it means JSF2 not > JSF1.2 or > >> > earlier. > >> > We wrote a little JSF code for conversations > and at that > >> > time there was no > >> > offical MyFaces JSF2 API to use. Now there is > one and we > >> > will update our pom > >> > to use MyFaces JSF2 and we will go ahead with > it. In fact, > >> > our codes in > >> > webbeans-jsf must work within JSF2. Moreover, > JSF2 is > >> > compatible with JSF1.2 > >> > as written in Java EE 6 specification. > >> > > >> > So all functionality must go into package > webbeans-jsf. > >> > There is no need to > >> > create extra project modules that confuses > developers > >> > minds. > >> > > >> > Thnks; > >> > > >> > --Gurkan > >> > > >> > 2009/12/17 Mark Struberg <[email protected]> > >> > > >> > > > JSF2 is backward compatible > >> > > > >> > > Not when it comes to the details! > >> > > E.g. try running RichFaces-3.3.2 on a > JSF-2 container > >> > ;) > >> > > > >> > > There have been a few changes which > allows us to > >> > create better support for > >> > > JSF2, mostly in the AJAX area. In > JSF-1.2 there was no > >> > standardised ajax > >> > > handling, so we would have no chance to > use those > >> > features in a portable > >> > > fashion. > >> > > > >> > > LieGrue, > >> > > strub > >> > > > >> > > --- Gurkan Erdogdu <[email protected]> > >> > schrieb am Do, 17.12.2009: > >> > > > >> > > > Von: Gurkan Erdogdu <[email protected]> > >> > > > Betreff: Re: Integration of JSF2 > specific API > >> > calls > >> > > > An: [email protected] > >> > > > Datum: Donnerstag, 17. Dezember > 2009, 9:50 > >> > > > >>>Id favour a > >> > > > webbeans-jsf2, I think that's more > future proof. > >> > > > I think that there is no need to > define extra > >> > jsf > >> > > > module/project. There is > >> > > > no such a thing that "You could use > it in JSF > >> > 1.2 but > >> > > > not JSF2 or vice > >> > > > versa". We support JSF2 and JSF2 is > backward > >> > compatible. > >> > > > But, if we really > >> > > > emphasize that the code is related > with "JSF2", > >> > we can > >> > > > create a package with > >> > > > named "jsf2" in webbeans-jsf > project. > >> > > > > >> > > > Thanks; > >> > > > > >> > > > --Gurkan > >> > > > > >> > > > 2009/12/17 Mark Struberg <[email protected]> > >> > > > > >> > > > > cool! > >> > > > > > >> > > > > Id favour a webbeans-jsf2, I > think that's > >> > more future > >> > > > proof. > >> > > > > > >> > > > > And as Gurkan already said: > please attach > >> > the patch as > >> > > > owb-171-patch.rfc in > >> > > > > Jira. > >> > > > > > >> > > > > txs and LieGrue, > >> > > > > strub > >> > > > > > >> > > > > --- Sven Linstaedt <[email protected]> > >> > > > schrieb am Do, > >> > > > > 17.12.2009: > >> > > > > > >> > > > > > Von: Sven Linstaedt > <[email protected]> > >> > > > > > Betreff: Integration of > JSF2 specific > >> > API calls > >> > > > > > An: [email protected] > >> > > > > > Datum: Donnerstag, 17. > Dezember 2009, > >> > 2:24 > >> > > > > > Back in business. > >> > > > > > > >> > > > > > I am currently working on > a patch for > >> > OWB-171. > >> > > > Besides some > >> > > > > > cleanups I have > refactored the code: > >> > > > > > > >> > > > > > Conversation is request > scoped and > >> > solely created > >> > > > or > >> > > > > > restored by > ConversationBean which > >> > delegates the > >> > > > later one > >> > > > > > to the > ConversationManager. > >> > WebBeansPhaseListener > >> > > > is only > >> > > > > > responsible for > retrieving and handling > >> > the > >> > > > > > ConversationContext. > Conversation is > >> > only > >> > > > restored using the > >> > > > > > "cid" request parameter > and not the > >> > > > > > UIViewRoot's attributes, > because the > >> > view is > >> > > > only > >> > > > > > accessible after restore > view phase. > >> > The > >> > > > restored > >> > > > > > conversation (and it's > context of > >> > course) must > >> > > > actually > >> > > > > > exist for restoring the > view. This > >> > chicken or egg > >> > > > problem > >> > > > > > was the reason not to > store the the cid > >> > in the > >> > > > view's > >> > > > > > attributes, because > restoring these > >> > attributes > >> > > > actually > >> > > > > > needs restoring the > conversation > >> > beforehand. > >> > > > > > > >> > > > > > > >> > > > > > There is still an issue > with the > >> > jsf2-example: In > >> > > > case of > >> > > > > > ajax requests which start > a long > >> > running > >> > > > conversation, all > >> > > > > > form's action attributes > needs to be > >> > updated to > >> > > > reflect > >> > > > > > the current active > conversation for > >> > following > >> > > > request. This > >> > > > > > could be done using JSF2 > specific API > >> > features. > >> > > > At the > >> > > > > > moment webbeans-impl is > purely compiled > >> > against > >> > > > the JSF 1.2 > >> > > > > > API. Without the > necessary abstraction > >> > there is > >> > > > no chance to > >> > > > > > get the JSF2 specific > ajax > >> > functionality working > >> > > > again. > >> > > > > > > >> > > > > > > >> > > > > > I have attached the patch > to this mail > >> > and not to > >> > > > the > >> > > > > > issue, because the patch > is not meant > >> > for > >> > > > inclusion yet, but > >> > > > > > for testing purposes. > Integration it > >> > and > >> > > > rerunning the > >> > > > > > jsf2-example points out > my problem. If > >> > you > >> > > > disable ajax by > >> > > > > > disabling javascript in > your browser > >> > e.g. the > >> > > > conversation > >> > > > > > example is working, > because in this > >> > case the full > >> > > > page with > >> > > > > > updated form's action > urls is rendered > >> > during > >> > > > each > >> > > > > > action invocation. > >> > > > > > > >> > > > > > > >> > > > > > Last but not least: Do > you guys have a > >> > glue how > >> > > > JSF2 > >> > > > > > specific extension for > conversation > >> > handling > >> > > > should be > >> > > > > > integrated? I supose > either adding > >> > another > >> > > > project > >> > > > > > (webbeans-jsf2 e.g.) or > updating the > >> > JSF API (not > >> > > > impl) > >> > > > > > version to 2.x and making > sure, we are > >> > loading > >> > > > JSF2 specific > >> > > > > > classes only for this > ajax purpose. > >> > > > > > > >> > > > > > > >> > > > > > good night, Sven > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > __________________________________________________ > >> > > > > Do You Yahoo!? > >> > > > > Sie sind Spam leid? Yahoo! > Mail verfügt > >> > über einen > >> > > > herausragenden Schutz > >> > > > > gegen Massenmails. > >> > > > > http://mail.yahoo.com > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Gurkan Erdogdu > >> > > > http://gurkanerdogdu.blogspot.com > >> > > > > >> > > > >> > > > __________________________________________________ > >> > > Do You Yahoo!? > >> > > Sie sind Spam leid? Yahoo! Mail verfügt > über einen > >> > herausragenden Schutz > >> > > gegen Massenmails. > >> > > http://mail.yahoo.com > >> > > > >> > > >> > > >> > > >> > -- > >> > Gurkan Erdogdu > >> > http://gurkanerdogdu.blogspot.com > >> > > >> > >> > __________________________________________________ > >> Do You Yahoo!? > >> Sie sind Spam leid? Yahoo! Mail verfügt über > einen herausragenden Schutz > >> gegen Massenmails. > >> http://mail.yahoo.com > >> > > > > > > > > -- > > Gurkan Erdogdu > > http://gurkanerdogdu.blogspot.com > > > > > > -- > Gurkan Erdogdu > http://gurkanerdogdu.blogspot.com > __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
