Re: JspStateManagerImpl into shared?
On Wed, Apr 2, 2008 at 3:18 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > > Orchestra having its own JspStateManagerImpl sounds "interesting" > > though. Enabling this on Sun Mojarra for example will quite radically > > change the way that a JSF app on Mojarra performs. That's not really > > Orchestra's role. > > > I thought about this like an optional feature one has to configure in > their own faces-config.xml > > > > What is *really* needed is for the StateManager spec to have some > > mechanism to externalise the state, then have Orchestra override just > > that. > +1 But that is not here yet! > > > > Is it not possible to apply the "decorator" pattern to whatever > > StateManager implementation the current JSF implementation provides? > > > No, unfortunately, no! I'd file an spec enhancement request for that, perhaps it will be there in 2.x -M > On the other hand, if you replace the state manager it should work with > any other JSF impl too ... as long as it follows the standard by > dispatching anything through the StateManager, no? > > Ciao, > Mario > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: JspStateManagerImpl into shared?
> Myfaces Core should not be dependent on a > commons library. It has an obligation to the TCK. currently we have dependencies on some apache commons lib, that's fine, I think (we passed the TCK thing). Or did I got you wrong ? > > Unlike everyone else though, I don't like the "base" name. It implies that > other commons projects would be dependent on it. > > Scott > > > > On Apr 2, 2008, at 7:18 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > > > Hi! > > > > > Orchestra having its own JspStateManagerImpl sounds "interesting" > > > though. Enabling this on Sun Mojarra for example will quite radically > > > change the way that a JSF app on Mojarra performs. That's not really > > > Orchestra's role. > > > > > > > > I thought about this like an optional feature one has to configure in > > their own faces-config.xml > > > > > > > What is *really* needed is for the StateManager spec to have some > > > mechanism to externalise the state, then have Orchestra override just > > > that. > > > > > +1 But that is not here yet! > > > > > > > Is it not possible to apply the "decorator" pattern to whatever > > > StateManager implementation the current JSF implementation provides? > > > > > > > > No, unfortunately, no! > > On the other hand, if you replace the state manager it should work with > > any other JSF impl too ... as long as it follows the standard by > > dispatching anything through the StateManager, no? > > > > Ciao, > > Mario > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: JspStateManagerImpl into shared?
I largely agree with Simon here.. Myfaces Core should not be dependent on a commons library. It has an obligation to the TCK. I see no reason, though that if this library has universal appeal, it can't be duplicated in commons. Unlike everyone else though, I don't like the "base" name. It implies that other commons projects would be dependent on it. Scott On Apr 2, 2008, at 7:18 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: Hi! Orchestra having its own JspStateManagerImpl sounds "interesting" though. Enabling this on Sun Mojarra for example will quite radically change the way that a JSF app on Mojarra performs. That's not really Orchestra's role. I thought about this like an optional feature one has to configure in their own faces-config.xml What is *really* needed is for the StateManager spec to have some mechanism to externalise the state, then have Orchestra override just that. +1 But that is not here yet! Is it not possible to apply the "decorator" pattern to whatever StateManager implementation the current JSF implementation provides? No, unfortunately, no! On the other hand, if you replace the state manager it should work with any other JSF impl too ... as long as it follows the standard by dispatching anything through the StateManager, no? Ciao, Mario
Re: shared discuss again [was Re: JspStateManagerImpl into shared?]
> > we already have a very raw starting point in the current commons, > > not yet finished, but it's there ;-) > > The started commons-(converters|validators) are IMHO a other type of commons, > not for use in jsf-impl classes but for application developper. This > is for nice and convenient utils stuff . didn't scott commit something? But even when not, some utils should be placed in commons. -M > > > > > > > > > > > > > > > I think that if we find a good name and define some strict rules we > > > > could move most (or all?) stuff from myfaces-shared to this lib. And > > > > perhaps even get rid of shard in the long run! > > > > > > > One rule can be to allow only stuff which itself directly implements a > > > JSF API but do not provide any functionality on its own, you see, no > > > enum converter or soo. Probably only abstract classes? > > > > > > > Of course, some well-known issues pop up immediately: which JSF-Spec > - > > > > 1.1 and 1.2 or only 1.2? What about JSF 2.0? > > > > > > > I'd like to see one project per version, e.g. myfaces-base11, > > > myfaces-base12, myfaces-base20 (with namespaced package names: > > > org.apache.myfaces.base11, etc) > > > > > > yeah, base11, base12, base20 > > what about a base, for those things that are independent from > > the spec diffs ? > > > > > > > FacesContextWrapper. But there is no need for that, we can't forsee any > > > future change e.g. in JSF 2.0 > > > > > > :-) True, all this is discussed behind closed doors > > > > -M > > > > > > > > Ciao, > > > Mario > > > > > > > > > > > > > > > > -- > > Matthias Wessendorf > > > > further stuff: > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > mail: matzew-at-apache-dot-org > > > > > Regards, > Volker > -- > inexso - information exchange solutions GmbH > Bismarckstraße 13 | 26122 Oldenburg > Tel.: +49 441 4082 356 | > FAX: +49 441 4082 355 | www.inexso.de > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: JspStateManagerImpl into shared?
Hi! > Orchestra having its own JspStateManagerImpl sounds "interesting" > though. Enabling this on Sun Mojarra for example will quite radically > change the way that a JSF app on Mojarra performs. That's not really > Orchestra's role. > I thought about this like an optional feature one has to configure in their own faces-config.xml > What is *really* needed is for the StateManager spec to have some > mechanism to externalise the state, then have Orchestra override just > that. +1 But that is not here yet! > Is it not possible to apply the "decorator" pattern to whatever > StateManager implementation the current JSF implementation provides? > No, unfortunately, no! On the other hand, if you replace the state manager it should work with any other JSF impl too ... as long as it follows the standard by dispatching anything through the StateManager, no? Ciao, Mario
Re: shared discuss again [was Re: JspStateManagerImpl into shared?]
Hi, 2008/4/2, Matthias Wessendorf <[EMAIL PROTECTED]>: > > > Problem here again is the name of such a lib: > > > "myfaces-commons-base"? > > > "myfaces-commons-core"? > > > "myfaces-commons-super"? > > > "myfaces-commons-commons"? ;-) > > > > > I'd opt for myfaces-base, but to say the truth, I do not care about the > > name, whatever name it has will be good for me as long as the goal is > > the same. > > > I'd vote for -base as well. +1 for "-base" for this project > > > > > It is no place where we swiftly drop some > > > nice and convenient utils stuff and the API is nothing to play around > > > with. > > > > > +1 > > > we already have a very raw starting point in the current commons, > not yet finished, but it's there ;-) The started commons-(converters|validators) are IMHO a other type of commons, not for use in jsf-impl classes but for application developper. This is for nice and convenient utils stuff . > > > > > > > I think that if we find a good name and define some strict rules we > > > could move most (or all?) stuff from myfaces-shared to this lib. And > > > perhaps even get rid of shard in the long run! > > > > > One rule can be to allow only stuff which itself directly implements a > > JSF API but do not provide any functionality on its own, you see, no > > enum converter or soo. Probably only abstract classes? > > > > > Of course, some well-known issues pop up immediately: which JSF-Spec - > > > 1.1 and 1.2 or only 1.2? What about JSF 2.0? > > > > > I'd like to see one project per version, e.g. myfaces-base11, > > myfaces-base12, myfaces-base20 (with namespaced package names: > > org.apache.myfaces.base11, etc) > > > yeah, base11, base12, base20 > what about a base, for those things that are independent from > the spec diffs ? > > > > FacesContextWrapper. But there is no need for that, we can't forsee any > > future change e.g. in JSF 2.0 > > > :-) True, all this is discussed behind closed doors > > -M > > > > > Ciao, > > Mario > > > > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > Regards, Volker -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de
Re: Shared module (was Re: JspStateManagerImpl into shared?)
Matthias Wessendorf schrieb: > >> I'm also sceptical that it will be possible to create a "super stable >> API". Just look at what is in shared at the moment! And in addition to >> the API, the *implementation* will also need to be super-stable. For >> example, if a Tomahawk issue (whether bug or new feature) needs changes >> in the "commons" module to resolve, then deploying that commons change >> will immediately impact myfaces-core too. Suddenly people will be >> > +1 that's a side effect > > >> running a version of myfaces-core together with a commons version that >> it was never tested against. I don't like that idea at all. It was >> precisely this issue that the shared repackaging idea was invented for. >> > yup, I guess I now move to your direction, or... > base-tomahawk :-) but... that doesn't fly at all. > I guess what we really want is for servlet engines to explicitly permit OSGi use. Then myfaces-core can depend on version X of the "common" lib, while tomahawk can run in the same webapp using version Y. That would solve my major objection. Package-renaming is just a hack to get a similar effect without having to mess with classloaders. But with this setup, we would still have people complaining that they do not know where to put their breakpoints. In fact, it's even worse. At least with the current stuff, you can clearly see "o.a.m.shared_core.Foo", rather than dealing with two different concurrently-loaded versions of the "o.a.m.Foo" class. How do people interactively debug OSGi apps, I wonder.. Regards, Simon
Re: JspStateManagerImpl into shared?
Mario Ivankovits schrieb: > Hi! > >>>> Does this qualify to move JspStateManagerImpl into shared? Or should I >>>> better copy the source over? >>>> >>>> >>>> >> There are some jira issues and email threads that might be relevant: >> >> > Thanks for the links, for me it seems there is need for this for other > "experiments" too. So, I'd move this class to shared and refactor it a > little bit so that it can be easier subclassed and allow only the bits > changed one is interested in. > > However, I don't want to go to solve the window-problem for MyFaces at > all, but just for Orchestra which seems to be easy due to the already > existent conversationContext parameter. > Ah. The point you were making is that things other than myfaces-core might want a basic JspStateManagerImpl implementation for them to subclass. And that is what "shared" is for. Whether JspStateManagerImpl could be refactored to support alternative strategies is a different issue. Sorry about the red herring. Orchestra having its own JspStateManagerImpl sounds "interesting" though. Enabling this on Sun Mojarra for example will quite radically change the way that a JSF app on Mojarra performs. That's not really Orchestra's role. What is *really* needed is for the StateManager spec to have some mechanism to externalise the state, then have Orchestra override just that. Is it not possible to apply the "decorator" pattern to whatever StateManager implementation the current JSF implementation provides? Regards, Simon
Re: Shared module (was Re: JspStateManagerImpl into shared?)
> Personally, I think the shared concept works fine. fine is a bit to much, right? But, yeah it works > > One problem with a "commons" jar used by core is that Sun Mojarra will > need two jars (jsf-api, jsf-impl) and myfaces will need three (jsf-api, > jsf-impl, commons-whatever.jar). This is rather ugly. true. but since everybody uses maven... that shouldn't be a big deal, IMO but I can see that both approves have their "issues" > I'm also sceptical that it will be possible to create a "super stable > API". Just look at what is in shared at the moment! And in addition to > the API, the *implementation* will also need to be super-stable. For > example, if a Tomahawk issue (whether bug or new feature) needs changes > in the "commons" module to resolve, then deploying that commons change > will immediately impact myfaces-core too. Suddenly people will be +1 that's a side effect > running a version of myfaces-core together with a commons version that > it was never tested against. I don't like that idea at all. It was > precisely this issue that the shared repackaging idea was invented for. yup, I guess I now move to your direction, or... base-tomahawk :-) but... that doesn't fly at all. > We can improve the build process by having a maven plugin that > imports-then-renames, rather than messing with the shared project to > generate the per-user variant. That's really quite simple, and could be > a nice general-purpose plugin. The maven-shade-plugin does something > similar, but at the binary level. > > Earlier releases of myfaces did not include the "shared" source in the > -sources jar which was a major nuisance. But that is now fixed. So for > most users, there is no need to ever deal with the original shared project. +1 -M > > Regards, > Simon > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: shared discuss again [was Re: JspStateManagerImpl into shared?]
> > Problem here again is the name of such a lib: > > "myfaces-commons-base"? > > "myfaces-commons-core"? > > "myfaces-commons-super"? > > "myfaces-commons-commons"? ;-) > > > I'd opt for myfaces-base, but to say the truth, I do not care about the > name, whatever name it has will be good for me as long as the goal is > the same. I'd vote for -base as well. > > It is no place where we swiftly drop some > > nice and convenient utils stuff and the API is nothing to play around > > with. > > > +1 we already have a very raw starting point in the current commons, not yet finished, but it's there ;-) > > > I think that if we find a good name and define some strict rules we > > could move most (or all?) stuff from myfaces-shared to this lib. And > > perhaps even get rid of shard in the long run! > > > One rule can be to allow only stuff which itself directly implements a > JSF API but do not provide any functionality on its own, you see, no > enum converter or soo. Probably only abstract classes? > > > Of course, some well-known issues pop up immediately: which JSF-Spec - > > 1.1 and 1.2 or only 1.2? What about JSF 2.0? > > > I'd like to see one project per version, e.g. myfaces-base11, > myfaces-base12, myfaces-base20 (with namespaced package names: > org.apache.myfaces.base11, etc) yeah, base11, base12, base20 what about a base, for those things that are independent from the spec diffs ? > FacesContextWrapper. But there is no need for that, we can't forsee any > future change e.g. in JSF 2.0 :-) True, all this is discussed behind closed doors -M > > Ciao, > Mario > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Shared module (was Re: JspStateManagerImpl into shared?)
Manfred Geiler schrieb: > Mario, you are not alone in hating the shared concept. ;-) > > This is exactly where the "myfaces-commons-xxx" library comes into > play, I often mentioned before. > What we need is a module, that > 1) has a super stable API > 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces > projects > Personally, I think the shared concept works fine. One problem with a "commons" jar used by core is that Sun Mojarra will need two jars (jsf-api, jsf-impl) and myfaces will need three (jsf-api, jsf-impl, commons-whatever.jar). This is rather ugly. I'm also sceptical that it will be possible to create a "super stable API". Just look at what is in shared at the moment! And in addition to the API, the *implementation* will also need to be super-stable. For example, if a Tomahawk issue (whether bug or new feature) needs changes in the "commons" module to resolve, then deploying that commons change will immediately impact myfaces-core too. Suddenly people will be running a version of myfaces-core together with a commons version that it was never tested against. I don't like that idea at all. It was precisely this issue that the shared repackaging idea was invented for. We can improve the build process by having a maven plugin that imports-then-renames, rather than messing with the shared project to generate the per-user variant. That's really quite simple, and could be a nice general-purpose plugin. The maven-shade-plugin does something similar, but at the binary level. Earlier releases of myfaces did not include the "shared" source in the -sources jar which was a major nuisance. But that is now fixed. So for most users, there is no need to ever deal with the original shared project. Regards, Simon
shared discuss again [was Re: JspStateManagerImpl into shared?]
Hi! > Mario, you are not alone in hating the shared concept. ;-) > Good! > 1) has a super stable API > That is true, that might be the hardest part. > 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces > projects > Sure! > 3) may be used by the experienced JSF app developer who wants to write > his own StateManager or ELResolver or some other pluggable/replaceable > JSF thingy (ie. all the things you can replace via faces-config.xml) > Yepp! > Problem here again is the name of such a lib: > "myfaces-commons-base"? > "myfaces-commons-core"? > "myfaces-commons-super"? > "myfaces-commons-commons"? ;-) > I'd opt for myfaces-base, but to say the truth, I do not care about the name, whatever name it has will be good for me as long as the goal is the same. > It is no place where we swiftly drop some > nice and convenient utils stuff and the API is nothing to play around > with. > +1 > I think that if we find a good name and define some strict rules we > could move most (or all?) stuff from myfaces-shared to this lib. And > perhaps even get rid of shard in the long run! > One rule can be to allow only stuff which itself directly implements a JSF API but do not provide any functionality on its own, you see, no enum converter or soo. Probably only abstract classes? > Of course, some well-known issues pop up immediately: which JSF-Spec - > 1.1 and 1.2 or only 1.2? What about JSF 2.0? > I'd like to see one project per version, e.g. myfaces-base11, myfaces-base12, myfaces-base20 (with namespaced package names: org.apache.myfaces.base11, etc) This might lead to code duplication for every new project, but is the only way I can think of making it possible for this project to succeed. It would not be nice if myfaces-base12 has to deal with backward-compatibility. Parts of myfaces-base12 MIGHT be backward-compatible, e.g. like any FacesContextWrapper. But there is no need for that, we can't forsee any future change e.g. in JSF 2.0 Ciao, Mario
Re: JspStateManagerImpl into shared?
Hi! >>> Does this qualify to move JspStateManagerImpl into shared? Or should I >>> better copy the source over? >>> >>> > > There are some jira issues and email threads that might be relevant: > Thanks for the links, for me it seems there is need for this for other "experiments" too. So, I'd move this class to shared and refactor it a little bit so that it can be easier subclassed and allow only the bits changed one is interested in. However, I don't want to go to solve the window-problem for MyFaces at all, but just for Orchestra which seems to be easy due to the already existent conversationContext parameter. Ciao, Mario
Re: JspStateManagerImpl into shared?
Mario, you are not alone in hating the shared concept. ;-) This is exactly where the "myfaces-commons-xxx" library comes into play, I often mentioned before. What we need is a module, that 1) has a super stable API 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces projects 3) may be used by the experienced JSF app developer who wants to write his own StateManager or ELResolver or some other pluggable/replaceable JSF thingy (ie. all the things you can replace via faces-config.xml) Problem here again is the name of such a lib: "myfaces-commons-base"? "myfaces-commons-core"? "myfaces-commons-super"? "myfaces-commons-commons"? ;-) The name MUST reflect the fact that this jar is a very basic lib all other JSF stuff depends on. It is no place where we swiftly drop some nice and convenient utils stuff and the API is nothing to play around with. I think that if we find a good name and define some strict rules we could move most (or all?) stuff from myfaces-shared to this lib. And perhaps even get rid of shard in the long run! Of course, some well-known issues pop up immediately: which JSF-Spec - 1.1 and 1.2 or only 1.2? What about JSF 2.0? Thoughts? --Manfred On Tue, Apr 1, 2008 at 9:31 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > Just to reiterate: I hate shared! ;-) > > Seriously, it seems that Orchestra has to implement a StateManager which > holds the view state in the conversationContext instead of the session. > At the moment it seems that large portions of JspStateManagerImpl can be > reused, but requires to copy it over into Orchestra. > > With slight refactoring of JspStateManagerImpl it should be possible to > just replace the actual storing/loading stuff. > > Does this qualify to move JspStateManagerImpl into shared? Or should I > better copy the source over? > > Ciao, > Mario > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: JspStateManagerImpl into shared?
Mario Ivankovits schrieb: > Ping! > >> It seems that Orchestra has to implement a StateManager which >> holds the view state in the conversationContext instead of the session. >> At the moment it seems that large portions of JspStateManagerImpl can be >> reused, but requires to copy it over into Orchestra. >> >> With slight refactoring of JspStateManagerImpl it should be possible to >> just replace the actual storing/loading stuff. >> >> Does this qualify to move JspStateManagerImpl into shared? Or should I >> better copy the source over? >> There are some jira issues and email threads that might be relevant: http://issues.apache.org/jira/browse/MYFACES-1791 http://issues.apache.org/jira/browse/TRINIDAD-816 http://www.nabble.com/state-saving-%28StateManager%29-and-multiple-frames-%28HACKATHON-points-4-and-6%29-td13913845.html http://www.nabble.com/RE%3A-Proposal-to-Externalize-the-ViewCache.-td13516998.html Regards, Simon
Re: JspStateManagerImpl into shared?
Ping! > It seems that Orchestra has to implement a StateManager which > holds the view state in the conversationContext instead of the session. > At the moment it seems that large portions of JspStateManagerImpl can be > reused, but requires to copy it over into Orchestra. > > With slight refactoring of JspStateManagerImpl it should be possible to > just replace the actual storing/loading stuff. > > Does this qualify to move JspStateManagerImpl into shared? Or should I > better copy the source over? > Ciao, Mario
JspStateManagerImpl into shared?
Hi! Just to reiterate: I hate shared! ;-) Seriously, it seems that Orchestra has to implement a StateManager which holds the view state in the conversationContext instead of the session. At the moment it seems that large portions of JspStateManagerImpl can be reused, but requires to copy it over into Orchestra. With slight refactoring of JspStateManagerImpl it should be possible to just replace the actual storing/loading stuff. Does this qualify to move JspStateManagerImpl into shared? Or should I better copy the source over? Ciao, Mario
