Rashmi,
I don't know where you are getting this code you show in the example below. It
corresponds to no version of the Orchestra code that I know of.
Method FrameworkAdapter.getInstance does not exist in either the 1.0 release or
the current trunk. In both of these it is called
FrameworkAdapter.getCurrentInstance(). Are you perhaps typing this in from
memory? If so, cut-and-paste would better in order to avoid confusion.
The code that most resembles what you show below is the 1.0 tag. It really
would be best if you could test against the latest code, as that is of course
what I have set up on my machine. The svn trunk is quite stable.
It is not surprising that FrameworkAdapter.getCurrentInstance is returning null
in a portlet environment. This class uses a filter to set a thread-local
variable which getCurrentInstance later reads. As was pointed out earlier by
Scott, both of these actions are problematic in a portlet environment.
If you can find a way to:
1) ensure that logic equivalent to JsfFrameworkAdapterFilter gets invoked early
on during a request cycle (ie before any beans are accessed and any
PhaseListeners run), and
2) store that adapter object somewhere so that it is accessable from backing
beans that are processing that same request
then we will happily add that functionality to Orchestra.
However as I have no Portlet experience, I have no idea how (1) and (2) can be
achieved in that environment.
Alternatively, if you can provide a simple demo Portlet app that we can easily
install and run then Mario or I *may* find time to work on this (no promises
though).
Regards,
Simon
---- Rashmi <[EMAIL PROTECTED]> schrieb:
>
> Hello Simon,
>
> I tried with the latest snapshot. The exception occurs in
> ConversationManager class:
>
> public static ConversationManager getInstance(boolean create)
> {
> ConversationManager conversationManager = (ConversationManager)
>
> FrameworkAdapter.getInstance().getSessionAttribute(CONVERSATION_MANAGER_KEY);
> ....
> }
>
> The FrameworkAdapter.getInstance() is null. The instance is not
> getting set.
>
> web.xml config: I only have orchestra filter configured
> <filter>
> <filter-name>Orchestra Filter</filter-name>
>
> <filter-class>org.apache.myfaces.orchestra.conversation.jsf.filter.OrchestraServletFilter</filter-class>
> <init-param>
> <param-name>serializeRequests</param-name>
> <param-value>true</param-value>
> </init-param>
> </filter>
>
> <filter-mapping>
> <filter-name>Orchestra Filter</filter-name>
> <servlet-name>Faces Servlet</servlet-name>
> </filter-mapping>
>
> spring-config:
> <import
> resource="classpath:*/META-INF/spring-orchestra-init.xml" />
>
> <bean
> class="org.springframework.beans.factory.config.CustomScopeConfigurer">
> <property name="scopes">
> <map>
> <entry key="conversation">
> <bean
> class="org.apache.myfaces.orchestra.conversation.spring.SpringConversationScope">
> </bean>
> </entry>
> </map>
> </property>
> </bean>
>
> <!-- Managed Beans -->
> <bean id="mitarbeiterlist"
> class="de.seat.mitarbeiterinfo.view.mitarbeiterlist"
> scope="conversation"
> orchestra:conversationName="mitarbeiterConv"
> autowire="byName">
> <property name="mitarbeiterService" ref="MitarbeiterService" />
> <property name="mitarbeiterDTO" ref="MitarbeiterDTO" />
> <aop:scoped-proxy />
> </bean>
>
>
> Regards,
> Rashmi
>
>
>
>
> Simon Kitching-4 wrote:
> >
> > 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
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Portlet-Environment-and-Orchestra-tp15270215p15289160.html
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
