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
