struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: Is Shale supposed to work in a portlet environment?
Date Sat, 25 Mar 2006 02:07:38 GMT
On 3/24/06, Gary VanMatre <gvanmatre@comcast.net> wrote:
>
> >From: "Marcio E Miranda" <Marcio.E.Miranda@fastsearch.com>
> >
> > That's what I understood from the documentation in the website, but the
> fact is
> > that I get an error (the browser shows an exception) if I don't register
> a
> > managed bean with the same name of the view.
> >
> > And the error has nothing to do with a component backing bean. The same
> > application that works fine without Shale, start to show this error
> message
> > after adding the Shale configurations in the web.xml.
> >


The warning-level message about no view controller that Shale emits should
probably be lowered to debug-level.  It's perfectly reasonable to use Shale
without using ViewControllers -- as would be the case for any existing JSF
app that you were adding Shale to.  For now, just ignore the messages (and
accept my apologies for filling up your log files until we have a chance to
fix it :-).

> Could you please confirm if the following filter is requited by Shale (I'm
> using
> > this in my web.xml):
> >
> >
> ><!-- Shale Application Controller Filter -->
> ><filter>
> >  <filter-name>shale</filter-name>
> >  <filter-class>org.apache.shale.faces.ShaleApplicationFilter
> </filter-class>
> > </filter>
> >
> ><!-- Shale Application Controller Filter Mapping -->
> ><filter-mapping>
> >     <filter-name>shale</filter-name>
> >     <url-pattern>/*</url-pattern>
> >     <dispatcher>REQUEST</dispatcher>
> >     <dispatcher>FORWARD</dispatcher>
> > </filter-mapping>
> >
> >
> > If not, maybe this is the cause of the strange behavior.
> >
>
> This looks correct.  You might check to see that the "<dispatcher>" nodes
> are supported.


The dispatcher option is supported on Servlet 2.4 or later ... but I don't
think you really want it here.  It will cause the filter to be applied
*twice* on every request ... once on the original submit, and once when
RequestDispatcher.forward() is used to forward to the next JSP page.

> Regarding the portlet issue, you mean that Shale adds a requirement to the
> > portlet container? So it means that I might not be able to deploy my
> portlet
> > application in some portal vendor because I use Shale?
> >
>
> I believe that is a true statement but portal talk is outside of my domain
> but from
> what I understand, not all portals support filters.


Since the Portlet spec doesn't say anything about filters, I'd bet the
percentage that do is close to zero :-(.

For Shale, the  application filtering isn't critical to overall processing,
but the initialization that is done when the filter is installed is.  That's
a bug, because it causes problems in a portlet environment (i.e. your
issue).

To make sure this gets tracked, could you please file a bug report about
this in our issue tracking system (http://issues.apache.org/bugzilla)?  If
you wanted, you could also file an RFE about the view controller logging
message too.

> - Marcio



Craig


>
> > -----Original Message-----
> > From: Gary VanMatre [mailto:gvanmatre@comcast.net]
> > Sent: sexta-feira, 24 de março de 2006 12:22
> > To: Struts Users Mailing List
> > Subject: Re: Is Shale supposed to work in a portlet environment?
> >
> > >From: "Marcio E Miranda"
> > >
> > > Hi,
> > >
> > >
> > >
> > > First of all, there is one point in Shale that I didn't understand
> very
> > > well. Why the developer has to register a managed bean for each view?
> >
> >
> > The shale ViewController adds additional lifecycle events to the vanilla
> JSF
> > lifecycle. This is accomplished without hooking into a specific
> implementation
> > of JSF. The solution is loosely coupled and it's not a requirement that
> you
> > associated every page with a ViewController. The mechanism for the extra
> > callback events are on the ViewController. The view controller is a
> managed
> > bean that is associated with a page by it's view id.
> >
> >
> > > When I try to access a page without registering a bean with the same
> > > name of the view in faces-config.xml, I get an error from Shale
> stating
> > > that the expression #{myviewname} could not be evaluated. If I then
> > > register a bean with the same name of the view in faces-config.xml, it
> > > works. There is no such a requirement in a JSF application that
> doesn't
> > > use Shale.
> > >
> >
> > The error that you are seen has to do with binding a component to a
> backing bean
> > using a expression language (EL) binding. You would see this error
> regardless
> > of having Shale in the picture.
> >
> > If you don't have a ViewController associated with a page, you will see
> a
> > *warning* message in the log.
> >
> > WARNING: No ViewController for viewId /usecases.jsp found under name
> usecases
> >
> > Besides the ViewController, the Shale subview component adds a
> "prerender"
> > callback event on the view controller.
> >
> > I really like the new tiger annotations that allow you to register
> managed beans
> > without XML. This makes it easy to register view controllers.
> > You are also able to make a view controller out of any managed bean and
> give
> > your own method signatures to the callback events.
> >
> > For example:
> >
> > /**
> > *
> Sample ViewController
> > * class for /examples/dataList.html.
>
> > */
> > @Bean(name="dataTable", scope=Scope.SESSION)
> > @View public class DataTableBean {
> >
> >
> > @Prerender public void loadPeople() {
> > people = new ArrayList();
> > for (int i = 0; i < 10; i++) {
> > BasicPerson person = new BasicPerson();
> > person.setFirstName("First" + i);
> > person.setLastName("Last" + (10 - i));
> > people.add(person);
> > }
> > }
> >
> > private List people = null;
> > public List getPeople() {
> > return people;
> > }
> >
> > }
> >
> > >
> > >
> > > Now to the portlet issue. I have a portlet application, which uses
> > > Shale, that runs fine in a web container (note that I had to define a
> > > managed bean with the same name of the view for it to work). Then,
> I've
> > > deployed the same application in a portlet container (Liferay). When I
> > > try to access the portlet, I get an error stating that the expression
> > > #{index} could not be evaluated. I checked the stack trace and
> realized
> > > that the exception was raised by the Shale controller (seems to me
> that
> > > this is the same issue described above). What is the workaround? Is
> > > Shale supposed to work in a portlet environment (I'm using the portlet
> > > implementation provided by My Faces)?
> > >
> >
> > Shale requires the portlet container to implement filters.
> >
> >
> > >
> > >
> > > - Marcio.
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message