Hallo,
can myfaces portlet bridge can be used in someway to overcome the
porblem?
Regards,
Rashmi
Scott O'Bryan wrote:
>
> Ok. I'll need to add a few utilities to the common utilities and add a
> common configurator jar to the project. But it should be easy enough to
> do in my copious amounts of free time. I'm currently in the middle of
> restructuring the bridge projects (which is almost done as well) so let
> me get that done and I'll check in the configurators so people can take
> a look at possibly using them.
>
> Scott
>
> Matthias Wessendorf wrote:
>>> 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
>>>>>>>
>>>>>>>
>>>>
>>>
>>
>>
>>
>>
>
>
>
--
View this message in context:
http://www.nabble.com/Portlet-Environment-and-Orchestra-tp15270215p15306534.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
