> Another option is I've been tinkering with separating the configurator > system similar to what Trinidad uses in order to put into an Apache > commons project. The code is complete (albeit untested) but the > configurators are a way to duplicate *most* filter logic in a JSF > environment without the use of filters. It works for both portlet and > servlet environements. If you want me to try and get that checked in to > the commons, maybe Orchestra can use it?
yeah, I think that others may benefit from the Trinidad configurator "framework" as well. I think that Orchestra definitely is a valid use case for that. Looks like (from what I remember on old discussions) Tobago also has interest in that. -M > > Scott > > > Simon Kitching wrote: > > BTW, you might try adding these elements to the OrchestraServletFilter > > filter-mapping clause: > > > > <dispatcher>REQUEST</dispatcher> > > <dispatcher>FORWARD</dispatcher> > > <dispatcher>INCLUDE</dispatcher> > > > > Regards, > > Simon > > > > ---- Simon Kitching <[EMAIL PROTECTED]> schrieb: > > > >> Hi Rashmi, > >> > >> Again, exact line numbers from the latest snapshot would be useful. > >> > >> In an email you sent to me directly you said that with the latest snapshot > >> the exception was at line 83 of ConversationManager. But with the latest > >> code, that line is in the middle of a javadoc comment, so perhaps you got > >> the libraries mixed up? > >> > >> The latest snapshot is always here: > >> > >> http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.1-SNAPSHOT/ > >> > >> As the comments in JsfFrameworkAdapter say: > >> This class requires the JsfFrameworkAdapterFilter to > >> be configured to run on every JSF request. > >> > >> And JsfFrameworkAdapterFilter says: > >> Note that the conversation.jsf.OrchestraServletFilter > >> class executes this class as a "subfilter", so defining > >> this filter is not required if that filter is already defined. > >> > >> So as long as you have OrchestraServletFilter defined there is no need to > >> configure anything else. And I certainly hope you have the > >> OrchestraServletFilter defined; that is mandatory. > >> > >> As someone mentioned earlier that filters run at unusual times during > >> portlet processing, that might be the cause of the problem. Neither Mario > >> nor I use portlets so you'll need to look into that yourself although we > >> are both happy to help with advice. > >> > >> I think that getting Orchestra and portlets working together will not be > >> too difficult; it looks like is just the initialisation of basic > >> structures that is not happening in a portlet environment. > >> > >> But getting the correct line at which the NullPointerException is actually > >> happening would be a very good start... > >> > >> Regards, > >> Simon > >> > >> ---- Rashmi <[EMAIL PROTECTED]> schrieb: > >> > >>> Hallo Mario, > >>> > >>> We tried using the latest snapshot of Orchestra. Unfortunately > >>> still > >>> facing the same exception as > >>> before. > >>> > >>> After having tried debugging the application, I see that it fails > >>> in > >>> class SpringConversationScope - > >>> protected Object getBean(String beanName, ObjectFactory > >>> objectFactory) {...} method. It displays > >>> the conversation name correctly, but fails in next step: > >>> > >>> ConversationManager manager = ConversationManager.getInstance(); > >>> > >>> Is it possible through spring IOC I can try instantiating or > >>> something? > >>> > >>> It clearly states in the Orchestra API, that the > >>> BasicFrameworkAdapter > >>> has been implemented for > >>> plain Servlet environment and JsfFrameworkAdapter for JSF > >>> environment. > >>> > >>> In the configuration i.e web.xml I tried explicity setting the > >>> filter > >>> to JsfFrameworkAdapter but again > >>> failed. > >>> > >>> May be we will end up writing a portlet friendly adapter. Please > >>> throw > >>> some light on how to get > >>> started or any other workaround to overcome the problem. > >>> > >>> Regards, > >>> Rashmi > >>> > >>> > >>> Mario Ivankovits wrote: > >>> > >>>> Hi! > >>>> > >>>> > >>>>> currently we're prototyping a portlet application (liferay 4.33) with > >>>>> orchestra , JPA (Hibernate) and myFaces 1.1.5. > >>>>> > >>>> Unhappily I have zero experience with portlets. If you could provide a > >>>> simple webapp to test this thing it would greatly help, though, I know > >>>> how much work it is to setup one. > >>>> However, if possible somehow, please try the latest snapshot of > >>>> Orchestra as we've changed how the FrameworkAdapter will be initialized. > >>>> At least it gives us correct line numbers in the exception. > >>>> > >>>> The FrameworkAdapter brings me to the thing which might be needed to be > >>>> fixed for the portlet environment, not sure though. > >>>> > >>>> If you have a look at the source of this class you'll see that there are > >>>> just a handful of methods which needs to be implement, probably in a > >>>> portlet friendly way. > >>>> > >>>> Could you please check if you have access to a FacesContext close before > >>>> the method raising an exception? > >>>> > >>>> If so, you can stick with the JsfFrameworkAdapter and just need to find > >>>> a way how to initialize it properly. If not, you have to create your own > >>>> portlet friendly FrameworkAdapter wich allows you to get access to the > >>>> session/request stuff required by Orchestra. > >>>> > >>>> > >>>> Ciao, > >>>> Mario > >>>> > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
