RE: struts-faces bug?

[Oliver]

Hi,

I just read:
http://forum.java.sun.com/thread.jsp?forum=427&thread=500294&tstart=30&trang
e=15
New version solved problem!

greetings
Oliver

> -Ursprüngliche Nachricht-
> Von: Oliver [mailto:[EMAIL PROTECTED] 
> Gesendet: Mittwoch, 10. März 2004 19:42
> An: [EMAIL PROTECTED]
> Betreff: struts-faces bug?
> 
> Hi,
> 
> After spending hours with error-searching and reading other 
> forums and mailinglists, I am at a loss.
> I think there is an error in the struts-faces library.
> I am using Tomcat 5.0.19, JSF1.0 reference implementation 
> from Sun and struts-faces.jar from 6.3.04. The JSF examples 
> work trouble free, but as soon as I want to use the 
> struts-faces.jar with my struts app. I get the following Exception:
> 
> 2004-03-10 19:22:32 StandardContext[/myApp]Error configuring 
> application listener of class 
> org.apache.struts.faces.taglib.LifecycleListener
> java.lang.IncompatibleClassChangeError: Implementing class
>   at java.lang.ClassLoader.defineClass0(Native Method)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
>   at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.
> java:123)
>   at
> org.apache.catalina.loader.WebappClassLoader.findClassInternal
> (WebappClassLo
> ader.java:1677)
>   at
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappC
> lassLoader.jav
> a:900)
>   at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappC
> lassLoader.jav
> a:1350)
>   at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappC
> lassLoader.jav
> a:1230)
>   at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
>   at java.lang.Class.getDeclaredConstructors0(Native Method)
>   at 
> java.lang.Class.privateGetDeclaredConstructors(Class.java:1610)
>   at java.lang.Class.getConstructor0(Class.java:1922)
>   at java.lang.Class.newInstance0(Class.java:278)
>   at java.lang.Class.newInstance(Class.java:261)
>   at
> org.apache.catalina.core.StandardContext.listenerStart(Standar
> dContext.java:
> 3722)
>   at
> org.apache.catalina.core.StandardContext.start(StandardContext
> .java:4270)
>   at
> org.apache.catalina.core.ContainerBase.addChildInternal(Contai
> nerBase.java:8
> 66)
>   at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.
> java:850)
>   at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:638)
>   at
> org.apache.catalina.core.StandardHostDeployer.install(Standard
> HostDeployer.j
> ava:320)
>   at
> org.apache.catalina.core.StandardHost.install(StandardHost.java:875)
>   at
> org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:657)
>   at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:476)
>   at
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1008)
>   at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConf
> ig.java:394)
>   at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(L
> ifecycleSuppor
> t.java:166)
>   at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1134)
>   at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:832)
>   at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1126)
>   at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:521)
>   at
> org.apache.catalina.core.StandardService.start(StandardService
> .java:519)
>   at
> org.apache.catalina.core.StandardServer.start(StandardServer.j
> ava:2345)
>   at org.apache.catalina.startup.Catalina.start(Catalina.java:594)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> orImpl.java:39
> )
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> odAccessorImpl
> .java:25)
>   at java.lang.reflect.Method.invoke(Method.java:324)
>   at 
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:297)
>   at 
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:398)
> 
> Thanks for your proposals and help
> Greetings
> Oliver
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts-faces-integration-lib

[Craig R. McClanahan]

Quoting Matthias Wessendorf <[EMAIL PROTECTED]>:

> Hi,
> 
> i noticed, that JSF became final.
> Now i asked myself, when the struts-faces-lib will be shipped? that one,
> that works with 1.0_final... ;-)
> 

Well, it has to work first :-).  I'm finishing up the debugging before I commit
a version that works with the 1.0 final release (without Tiles ... the next
step will be catching up the Tiles integration as well).

My personal goal is to have a production quality version of this code released
before JavaOne.  In order for that to happen, it will need lots of testing
across a variety of existing applications, so we'll probably need some 'early
access' type snapshots in the interim.

> Is main focus now working on struts_1.2?
> or is the integration-lib "independent" of struts-1.2
> because it is in contrib-folder!
> 

So far, I've been doing the integration work against a stock Struts 1.1 install,
so it will be backwards compatible.  I'll test, of course, with Struts 1.2 as
well before we actually release anything.


> Thanks for answer! :-)
> 
> Cheers!
> --
> Matthias Weßendorf
> Aechterhoek 18
> D-48282 Emsdetten
> Email: mailto:[EMAIL PROTECTED]
> URL: http://www.wessendorf.net
> 

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts-faces Roadmap

[Craig R. McClanahan]

Quoting Nadeem Bitar <[EMAIL PROTECTED]>:

> Is there a roadmap for the struts and jsf integration library? I am
> particularly interested in an update that would support tiles. I already
> tried the modifications suggested in the developerworks article
> (http://www-106.ibm.com/developerworks/library/j-integrate)
> with partial success, but I would prefer that it was supported directly
> in struts-faces.
> thanks in advance,
> nadeem
> 

The plan is definitely to keep struts-faces up to date with the upcoming beta
and final releases of JavaServer Faces.  Ensuring that Tiles support works is
very high on my agenda; it's a matter of having sufficient time to integrate
and test the solution.

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts-faces

[Craig R. McClanahan]

On Thu, 18 Sep 2003, Ted Husted wrote:

> Date: Thu, 18 Sep 2003 07:05:44 -0400
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: struts-faces
>
> Craig R. McClanahan wrote:
>  > // Return an Action for processing a logon
>  > public Action getLogon() {
>  >   return new Action() {
>  > public String invoke() {
>  >   return logon();
>  > }
>  >   }
>  > }
>  >
>
> Very cool technique =:)
>

Anonymous inner classes have some mind-bending capabilities :-).

> But this has to be the coolest trick yet:
>
>  > // Add an error message
>  > FacesContext.getCurrentInstance().addMessage(...);
>
> Hey, why bother passing around a context when you can get the thread to
> do it? Quite fancy =:)

It's definitely cute, but there's a tradeoff.  The FacesContext
implementation has to use a ThreadLocal variable (or something equivalent)
in order to keep trace of the current FacesContext instance for each
webapp, so there's a (small but real) performance difference between
calling getCurrentInstance() and passing the current context on the stack.
In general, we have tried to pass the context when it was easily
available, but not stressed over using getCurrentInstance() in other
cases.

One might think about applying this design pattern to something like
commons-chain as well (to avoid passing on the Context object).  That
would work if there was only one chain being processed per thread, which
may or may not be practical (it is for JavaServer Faces because there's
only one FacesContext instance per request processing thread).

>
> http://java.sun.com/webservices/docs/1.2/api/javax/faces/context/FacesContext.html
>
> -Ted.

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: struts-faces

[Andrew Hill]

Of course theres an even simpler way to get fresh actions each time - just a
few lines change in your request processor. Have it return a new instance
each time and dont bother with caching it...

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: Thursday, 18 September 2003 18:57
To: Struts Users Mailing List
Subject: Re: struts-faces


Likewise, if anyone really wanted throwaway, non-threadsafe Actions,
there's a nice technique that Maverick uses. A regular singleton Action
is used as a wrapper. When execute is called, the wrapper instantiates a
new instance of the desired type and returns the outcome of its execute.
  But the ActionForm technique Greg describes would be an even better
way to create throwaway Actions.

Gregory Seidman wrote:
> On Wed, Sep 17, 2003 at 01:14:27PM +0200, Adam Hardy wrote:
> } I remember a while ago in one of these architecture- theme emails you
> } discussed the OO nature of struts & it had been said that the
> } action-form class and the action class broke the OO encapsulation
> } principle, by having data in one and functionality in another. You said
> } if you were going to design struts again, you would probably address
this.
> [...]
>
> This is a quibble. If you want to put your functionality into your
> ActionForm class, go ahead. Create an abstract ActionForm subclass that
has
> a takeAction() pure virtual method in it (with appropriate arguments).
> Create an Action class which does nothing more than cast to your
ActionForm
> subclass and call takeAction(). There you go, functionality in the same
> class that holds the data.
>
> } Adam
> --Greg
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

--
Ted Husted,
   Junit in Action  - <http://www.manning.com/massol/>,
   Struts in Action - <http://husted.com/struts/book.html>,
   JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts-faces

[Ted Husted]

Craig R. McClanahan wrote:
> // Return an Action for processing a logon
> public Action getLogon() {
>   return new Action() {
> public String invoke() {
>   return logon();
> }
>   }
> }
>
Very cool technique =:)

But this has to be the coolest trick yet:

> // Add an error message
> FacesContext.getCurrentInstance().addMessage(...);
Hey, why bother passing around a context when you can get the thread to 
do it? Quite fancy =:)

http://java.sun.com/webservices/docs/1.2/api/javax/faces/context/FacesContext.html

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts-faces

[Ted Husted]

Likewise, if anyone really wanted throwaway, non-threadsafe Actions, 
there's a nice technique that Maverick uses. A regular singleton Action 
is used as a wrapper. When execute is called, the wrapper instantiates a 
new instance of the desired type and returns the outcome of its execute. 
 But the ActionForm technique Greg describes would be an even better 
way to create throwaway Actions.

Gregory Seidman wrote:
On Wed, Sep 17, 2003 at 01:14:27PM +0200, Adam Hardy wrote:
} I remember a while ago in one of these architecture- theme emails you 
} discussed the OO nature of struts & it had been said that the 
} action-form class and the action class broke the OO encapsulation 
} principle, by having data in one and functionality in another. You said 
} if you were going to design struts again, you would probably address this.
[...]

This is a quibble. If you want to put your functionality into your
ActionForm class, go ahead. Create an abstract ActionForm subclass that has
a takeAction() pure virtual method in it (with appropriate arguments).
Create an Action class which does nothing more than cast to your ActionForm
subclass and call takeAction(). There you go, functionality in the same
class that holds the data.
} Adam
--Greg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ted Husted,
  Junit in Action  - ,
  Struts in Action - ,
  JSP Site Design  - .


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts-faces

[Adam Hardy]

That sounds highly promising. Thanks for the information. You 
architecture gurus have obviously been busy.

Regards
Adam
On 09/17/2003 06:43 PM Craig R. McClanahan wrote:
On Wed, 17 Sep 2003, Adam Hardy wrote:


Date: Wed, 17 Sep 2003 13:14:27 +0200
From: Adam Hardy <[EMAIL PROTECTED]>
Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
To: Struts Users Mailing List <[EMAIL PROTECTED]>
Subject: Re: struts-faces
Hi Craig,
I remember a while ago in one of these architecture- theme emails you
discussed the OO nature of struts & it had been said that the
action-form class and the action class broke the OO encapsulation
principle, by having data in one and functionality in another. You said
if you were going to design struts again, you would probably address this.
Does JSFaces bring these two closer together? Or is this an area where
Faces is not involved? I see you say that in a combination of struts &
Faces, you would still use actions and forms.


JavaServer Faces is designed to give you options to organize things either
way.  Here's one example of a logon form (and associated back-end logic)
that combines the Struts notions of ActionForm and Action into a single
class (corresponds to the syntax in the EA4 release):
JSP PAGE (/logon.jsp):
=
  ...
  


  
  
  
  
  
  

  
  ...
FACES CONFIGURATION FILE (faces-config.xml):
===
  ...
  
logonForm
mypackage.MyLogonForm
request
  
  ...
  
/logon.jsp

  success
  /mainmenu.jsp

  
  ...
BACKING CLASS:
=
  package mypackage;
  public class MyLogonForm { // No required base class or interface
// Property for "username" field
private String username;
public String getUsername() { return username; }
public void setUsername(String username) { this.username = username; }
// Property for "password" field
private String password;
public String getPassword() { return password; }
public void setPassword(String password) { this.password = password; }
// Return an Action for processing a logon
public Action getLogon() {
  return new Action() {
public String invoke() {
  return logon();
}
  }
}
// The actual logon processing logic
private String logon() {
  DAO dao = ...; // Data Access Object for user database
  User user = dao.findUser(this.username);
  if ((user != null) && password.equals(user.getPassword())) {
... record successful logon ...
// Return logical outcome denoting success
return ("success");
  } else {
// Add an error message
FacesContext.getCurrentInstance().addMessage(...);
// Return logical outcome denoting "redisplay this page"
return (null);
  }
}
  }

In this scenario, you can see that the form field values are stored in the
same bean as the processing logic.  Therefore, the processing logic can
just use the field values directly (they are in the instance variables).
However, it's only in the same class because the page author used
"logonForm" at the beginning of the valueRef and actionRef expressions --
they could just as easily have been stored in separate files.
A couple of things not real obvious from this simple example, but
interesting nevertheless:
* The  declaration causes a new instance of the specified
  class to be created in (in this case) request scope, if it is not
  there already, similar to the way that Struts creates form beans for
  you as needed.  However, JavaServer Faces generalizes this to happen
  automatically whenever it evaluates a reference expression and the
  first element does not identify an existing attribute in some scope.
  This can be very handy for instantiating "service" or "processor"
  objects whose precise characteristics are defined in the configuration
  file, rather than being coded in the page.
* JavaServer Faces uses logical outcomes to manage navigation, similar
  to the way that Struts uses the returned ActionForward for this.
  The returned value is matched against a set of navigation rules that
  choose the next page to be displayed based on three criteria:
  - What page am I currently displaying?  (Wildcard rules are allowed)
  - What action was performed? (You can have more than one submit button)
  - What logical outcome is returned?
  If no rule matches, the current page is redisplayed.  I've adopted
  the convention in my code to return null as the logical outcome if
  this is what I want (i.e. the logon failure case here).
* Struts encourages you to use Strings for field values that might
  need conversion, in order to redisplay correctly in case of conversion
  errors.  You don't need to worry about that with JavaServer Faces,
  because the redisplay is handled by

Re: struts-faces

[Craig R. McClanahan]

On Wed, 17 Sep 2003, Adam Hardy wrote:

> Date: Wed, 17 Sep 2003 13:14:27 +0200
> From: Adam Hardy <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: struts-faces
>
> Hi Craig,
> I remember a while ago in one of these architecture- theme emails you
> discussed the OO nature of struts & it had been said that the
> action-form class and the action class broke the OO encapsulation
> principle, by having data in one and functionality in another. You said
> if you were going to design struts again, you would probably address this.
>
> Does JSFaces bring these two closer together? Or is this an area where
> Faces is not involved? I see you say that in a combination of struts &
> Faces, you would still use actions and forms.
>

JavaServer Faces is designed to give you options to organize things either
way.  Here's one example of a logon form (and associated back-end logic)
that combines the Struts notions of ActionForm and Action into a single
class (corresponds to the syntax in the EA4 release):

JSP PAGE (/logon.jsp):
=

  ...
  


  
  
  
  
  
  

  
  ...

FACES CONFIGURATION FILE (faces-config.xml):
===

  ...
  
logonForm
mypackage.MyLogonForm
request
  
  ...
  
/logon.jsp

  success
  /mainmenu.jsp

  
  ...

BACKING CLASS:
=

  package mypackage;
  public class MyLogonForm { // No required base class or interface

// Property for "username" field
private String username;
public String getUsername() { return username; }
public void setUsername(String username) { this.username = username; }

// Property for "password" field
private String password;
public String getPassword() { return password; }
public void setPassword(String password) { this.password = password; }

// Return an Action for processing a logon
public Action getLogon() {
  return new Action() {
public String invoke() {
  return logon();
}
  }
}

// The actual logon processing logic
private String logon() {
  DAO dao = ...; // Data Access Object for user database
  User user = dao.findUser(this.username);
  if ((user != null) && password.equals(user.getPassword())) {
... record successful logon ...
// Return logical outcome denoting success
return ("success");
  } else {
// Add an error message
FacesContext.getCurrentInstance().addMessage(...);
// Return logical outcome denoting "redisplay this page"
return (null);
  }
}

  }

In this scenario, you can see that the form field values are stored in the
same bean as the processing logic.  Therefore, the processing logic can
just use the field values directly (they are in the instance variables).
However, it's only in the same class because the page author used
"logonForm" at the beginning of the valueRef and actionRef expressions --
they could just as easily have been stored in separate files.

A couple of things not real obvious from this simple example, but
interesting nevertheless:

* The  declaration causes a new instance of the specified
  class to be created in (in this case) request scope, if it is not
  there already, similar to the way that Struts creates form beans for
  you as needed.  However, JavaServer Faces generalizes this to happen
  automatically whenever it evaluates a reference expression and the
  first element does not identify an existing attribute in some scope.
  This can be very handy for instantiating "service" or "processor"
  objects whose precise characteristics are defined in the configuration
  file, rather than being coded in the page.

* JavaServer Faces uses logical outcomes to manage navigation, similar
  to the way that Struts uses the returned ActionForward for this.
  The returned value is matched against a set of navigation rules that
  choose the next page to be displayed based on three criteria:
  - What page am I currently displaying?  (Wildcard rules are allowed)
  - What action was performed? (You can have more than one submit button)
  - What logical outcome is returned?
  If no rule matches, the current page is redisplayed.  I've adopted
  the convention in my code to return null as the logical outcome if
  this is what I want (i.e. the logon failure case here).

* Struts encourages you to use Strings for field values that might
  need conversion, in order to redisplay correctly in case of conversion
  errors.  You don't need to worry about that with JavaServer Faces,
  because the redisplay is handled by the components themselves.  You
  will generally use the native data types f

Re: struts-faces

[Gregory Seidman]

On Wed, Sep 17, 2003 at 01:14:27PM +0200, Adam Hardy wrote:
} I remember a while ago in one of these architecture- theme emails you 
} discussed the OO nature of struts & it had been said that the 
} action-form class and the action class broke the OO encapsulation 
} principle, by having data in one and functionality in another. You said 
} if you were going to design struts again, you would probably address this.
[...]

This is a quibble. If you want to put your functionality into your
ActionForm class, go ahead. Create an abstract ActionForm subclass that has
a takeAction() pure virtual method in it (with appropriate arguments).
Create an Action class which does nothing more than cast to your ActionForm
subclass and call takeAction(). There you go, functionality in the same
class that holds the data.

} Adam
--Greg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts-faces

[Adam Hardy]

Hi Craig,
I remember a while ago in one of these architecture- theme emails you 
discussed the OO nature of struts & it had been said that the 
action-form class and the action class broke the OO encapsulation 
principle, by having data in one and functionality in another. You said 
if you were going to design struts again, you would probably address this.

Does JSFaces bring these two closer together? Or is this an area where 
Faces is not involved? I see you say that in a combination of struts & 
Faces, you would still use actions and forms.

The reason I ask is that I just had a hard time redesigning a page 
because my initial design failed. The page allows an edit of one parent 
object, while showing a list of its child objects with 
move-to-new-parent / delete controls. I got in a mess initially over 
whether to use the parent or child's form and action for the child 
operations.

Fortunately I solved it nicely by nesting the child objects in the 
parent form, and passing the whole lot to the parent's model, which then 
worked out if it needed to call the child's model for any operations.

Adam

On 09/16/2003 09:30 PM Craig R. McClanahan wrote:
On Tue, 16 Sep 2003, Sasha Borodin wrote:


Date: Tue, 16 Sep 2003 12:35:22 -0500
From: Sasha Borodin <[EMAIL PROTECTED]>
Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
To: Struts Users Mailing List <[EMAIL PROTECTED]>
Subject: Re: struts-faces
Thanks Craig.


You can, but the integration library lets you use Struts Actions on the
back end, creates form beans automatically, and so on.
Reading through Sun's Web Services Tutorial section on JSF, things are
starting to come into focus:  JSF provides functionality that overlaps that
of Struts (my misconception was that JSF was strictly a UI component tag
library).


Yep ... there's quite a bit of overlap, and JavaServer Faces is FAR more
than "a component tag library".

.: Anyone know of a resource that summarizes/contrasts solutions provided by
both frameworks?


I'll throw in a few short comments below, but caution you that this is
based on the EA4 release of JavaServer Faces.  Things are still evolving
rapidly.  (My comments ought to have at least a *little* relevance,
because I'm both the original author of Struts and the co-spec-lead for
JavaServer Faces :-).

i.e.:
   -UI Components


Struts doesn't really have any notion of components at all (the closest
thing is properties of a form bean), while JavaServer Faces has a fairly
rich component model that is accessible at both the Java and JSP levels
(JSP is not required), supports a separate rendering model (so you can
render something like a "select one" control as either a set of radio
buttons or a  element with one simple change) and is not tied to
HTML -- although the default render kit included will be HTML specific.
Out of the box, you'll get complex components like a grid and an editable
table, and there are already demonstration components for things like
trees and menus that (in a Struts world) require additional add-on tag
libraries.
For people who have existing Struts expertise and/or applications, this is
the key value add of integrating JavaServer Faces -- you can use the fancy
UI component model without having to change your back-end form beans or
actions.

   -controller components


This is where Struts shines, and I assume you're familiar with that.
JavaServer Faces uses a somewhat different abstraction for navigation, and
defers the decision of what page to display next to a NavigationHandler
that is configured with a set of rules -- the next page is determined by
matching rules for:
* The page that is currently being displayed
* Which Action was invoked (for example, you can have
  multiple submit buttons on the page that do different things)
* Which logical "outcome" was returned by the Action that
  was invoked -- sort of like how Struts actions return an
  ActionForward.
JavaServer Faces is more flexible in how you organize your processing
logic -- you can maintain a Struts-like model of separate "form beans" and
"action classes", or you can combine them together (somewhat like how
code-behind pages work in ASP.Net).
Struts has a couple of framework features (Tiles and the Validator
Framework) that are beyond the current scope of JavaServer Faces -- but
one advantage of the integration library is that you'll be able to use
these sorts of technologies together.

   -model components


Being presentation frameworks, both technologies are mostly focused on the
view and controller.  The important part becomes how the presentation tier
and model tier object communicate values:
* With Struts, you can use property expressions to navigate
  down a bean hierarchy -- something like:


* With JavaServer Faces, this is done with "value reference
  expressions" that use the same syntax as JSTL 

Re: struts-faces

[Craig R. McClanahan]

On Tue, 16 Sep 2003, Sasha Borodin wrote:

> Date: Tue, 16 Sep 2003 12:35:22 -0500
> From: Sasha Borodin <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: struts-faces
>
> Thanks Craig.
>
> > You can, but the integration library lets you use Struts Actions on the
> > back end, creates form beans automatically, and so on.
>
> Reading through Sun's Web Services Tutorial section on JSF, things are
> starting to come into focus:  JSF provides functionality that overlaps that
> of Struts (my misconception was that JSF was strictly a UI component tag
> library).
>

Yep ... there's quite a bit of overlap, and JavaServer Faces is FAR more
than "a component tag library".

> .: Anyone know of a resource that summarizes/contrasts solutions provided by
> both frameworks?
>

I'll throw in a few short comments below, but caution you that this is
based on the EA4 release of JavaServer Faces.  Things are still evolving
rapidly.  (My comments ought to have at least a *little* relevance,
because I'm both the original author of Struts and the co-spec-lead for
JavaServer Faces :-).

> i.e.:
> -UI Components

Struts doesn't really have any notion of components at all (the closest
thing is properties of a form bean), while JavaServer Faces has a fairly
rich component model that is accessible at both the Java and JSP levels
(JSP is not required), supports a separate rendering model (so you can
render something like a "select one" control as either a set of radio
buttons or a  element with one simple change) and is not tied to
HTML -- although the default render kit included will be HTML specific.
Out of the box, you'll get complex components like a grid and an editable
table, and there are already demonstration components for things like
trees and menus that (in a Struts world) require additional add-on tag
libraries.

For people who have existing Struts expertise and/or applications, this is
the key value add of integrating JavaServer Faces -- you can use the fancy
UI component model without having to change your back-end form beans or
actions.

> -controller components

This is where Struts shines, and I assume you're familiar with that.
JavaServer Faces uses a somewhat different abstraction for navigation, and
defers the decision of what page to display next to a NavigationHandler
that is configured with a set of rules -- the next page is determined by
matching rules for:
* The page that is currently being displayed
* Which Action was invoked (for example, you can have
  multiple submit buttons on the page that do different things)
* Which logical "outcome" was returned by the Action that
  was invoked -- sort of like how Struts actions return an
  ActionForward.

JavaServer Faces is more flexible in how you organize your processing
logic -- you can maintain a Struts-like model of separate "form beans" and
"action classes", or you can combine them together (somewhat like how
code-behind pages work in ASP.Net).

Struts has a couple of framework features (Tiles and the Validator
Framework) that are beyond the current scope of JavaServer Faces -- but
one advantage of the integration library is that you'll be able to use
these sorts of technologies together.

> -model components

Being presentation frameworks, both technologies are mostly focused on the
view and controller.  The important part becomes how the presentation tier
and model tier object communicate values:

* With Struts, you can use property expressions to navigate
  down a bean hierarchy -- something like:



* With JavaServer Faces, this is done with "value reference
  expressions" that use the same syntax as JSTL EL expressions.
  The equivalent tag to output a bean property would be:

:

* In both technologies, it's possible to evaluate expressions
  like this programmatically in your Java code -- with Struts,
  you use the commons-beanutils package; with JavaServer Faces,
  you use the ValueBinding API.

* With Struts, the framework will automatically create form bean
  instances for you if you want.  If you're using DynaActionForms,
  you can also preconfigure the properties of the created form bean
  using the "initial" attribute.

* With JavaServer Faces, this concept is extended to support creation
  of *any* model tier bean (in any scope), complete with configuring
  the initial properties, using the Managed Bean Creation facility.
  In the example above, I can configure things such that if the "customer"
  object does not already exist, a new instance of a configured class
  will automatically be created, and have its property values also
  configured based on settings in faces-config.xml.

> -Page Flow

Neither t

Re: struts-faces

[Sasha Borodin]

Great website, thanks James!

-Sasha

> From: "James Holmes" <[EMAIL PROTECTED]>
> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Date: Tue, 16 Sep 2003 15:10:36 -0400
> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> Subject: RE: struts-faces
> 
> Hi Sasha,
> 
> I don't have a specific resource in mind for you to look at, but I have
> compiled the most comprehensive listing of Java Server Faces resources
> on my website.
> 
> http://www.jamesholmes.com/JavaServerFaces/
> 
> Hope that helps,
> 
> -James
> 
> -Original Message-
> From: Sasha Borodin [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 16, 2003 12:35 PM
> To: Struts Users Mailing List
> Subject: Re: struts-faces
> 
> Thanks Craig.
> 
>> You can, but the integration library lets you use Struts Actions on
> the
>> back end, creates form beans automatically, and so on.
> 
> Reading through Sun's Web Services Tutorial section on JSF, things are
> starting to come into focus:  JSF provides functionality that overlaps
> that
> of Struts (my misconception was that JSF was strictly a UI component tag
> library).
> 
> .: Anyone know of a resource that summarizes/contrasts solutions
> provided by
> both frameworks?
> 
> i.e.:
>   -UI Components
>   -controller components
>   -model components
>   -Page Flow
>   -etc.
> 
> Thanks,
> 
> -Sasha
> 
> 
>> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>> Date: Tue, 16 Sep 2003 10:16:22 -0700 (PDT)
>> To: Struts Users Mailing List <[EMAIL PROTECTED]>
>> Subject: Re: struts-faces
>> 
>> On Tue, 16 Sep 2003, Sasha Borodin wrote:
>> 
>>> Date: Tue, 16 Sep 2003 11:30:40 -0500
>>> From: Sasha Borodin <[EMAIL PROTECTED]>
>>> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>> To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>> Subject: struts-faces
>>> 
>>> Can someone tell me why I'd need a "struts integration" version of
> the JSF
>>> implementation?  Why can't one just add the RI JAR files, TLD
> documents,
>>> config files and just starting using the tags?
>>> 
>> 
>> You can, but the integration library lets you use Struts Actions on
> the
>> back end, creates form beans automatically, and so on.
>> 
>>> Thanks,
>>> 
>>> -Sasha
>>> 
>> 
>> Craig
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: struts-faces

[James Holmes]

Hi Sasha,

I don't have a specific resource in mind for you to look at, but I have
compiled the most comprehensive listing of Java Server Faces resources
on my website.

http://www.jamesholmes.com/JavaServerFaces/

Hope that helps,

-James

-Original Message-
From: Sasha Borodin [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 16, 2003 12:35 PM
To: Struts Users Mailing List
Subject: Re: struts-faces

Thanks Craig.

> You can, but the integration library lets you use Struts Actions on
the
> back end, creates form beans automatically, and so on.

Reading through Sun's Web Services Tutorial section on JSF, things are
starting to come into focus:  JSF provides functionality that overlaps
that
of Struts (my misconception was that JSF was strictly a UI component tag
library).

.: Anyone know of a resource that summarizes/contrasts solutions
provided by
both frameworks?

i.e.:
-UI Components
-controller components
-model components
-Page Flow
-etc.

Thanks,

-Sasha


> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Date: Tue, 16 Sep 2003 10:16:22 -0700 (PDT)
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: struts-faces
> 
> On Tue, 16 Sep 2003, Sasha Borodin wrote:
> 
>> Date: Tue, 16 Sep 2003 11:30:40 -0500
>> From: Sasha Borodin <[EMAIL PROTECTED]>
>> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>> To: Struts Users Mailing List <[EMAIL PROTECTED]>
>> Subject: struts-faces
>> 
>> Can someone tell me why I'd need a "struts integration" version of
the JSF
>> implementation?  Why can't one just add the RI JAR files, TLD
documents,
>> config files and just starting using the tags?
>> 
> 
> You can, but the integration library lets you use Struts Actions on
the
> back end, creates form beans automatically, and so on.
> 
>> Thanks,
>> 
>> -Sasha
>> 
> 
> Craig
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts-faces

[Sasha Borodin]

Thanks Craig.

> You can, but the integration library lets you use Struts Actions on the
> back end, creates form beans automatically, and so on.

Reading through Sun's Web Services Tutorial section on JSF, things are
starting to come into focus:  JSF provides functionality that overlaps that
of Struts (my misconception was that JSF was strictly a UI component tag
library).

.: Anyone know of a resource that summarizes/contrasts solutions provided by
both frameworks?

i.e.:
-UI Components
-controller components
-model components
-Page Flow
-etc.

Thanks,

-Sasha


> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Date: Tue, 16 Sep 2003 10:16:22 -0700 (PDT)
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: struts-faces
> 
> On Tue, 16 Sep 2003, Sasha Borodin wrote:
> 
>> Date: Tue, 16 Sep 2003 11:30:40 -0500
>> From: Sasha Borodin <[EMAIL PROTECTED]>
>> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>> To: Struts Users Mailing List <[EMAIL PROTECTED]>
>> Subject: struts-faces
>> 
>> Can someone tell me why I'd need a "struts integration" version of the JSF
>> implementation?  Why can't one just add the RI JAR files, TLD documents,
>> config files and just starting using the tags?
>> 
> 
> You can, but the integration library lets you use Struts Actions on the
> back end, creates form beans automatically, and so on.
> 
>> Thanks,
>> 
>> -Sasha
>> 
> 
> Craig
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts-faces

[Craig R. McClanahan]

On Tue, 16 Sep 2003, Sasha Borodin wrote:

> Date: Tue, 16 Sep 2003 11:30:40 -0500
> From: Sasha Borodin <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: struts-faces
>
> Can someone tell me why I'd need a "struts integration" version of the JSF
> implementation?  Why can't one just add the RI JAR files, TLD documents,
> config files and just starting using the tags?
>

You can, but the integration library lets you use Struts Actions on the
back end, creates form beans automatically, and so on.

> Thanks,
>
> -Sasha
>

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts Faces ea validation XML error [SOLVED]

[PILGRIM, Peter, FM]

> -Original Message-
> From: PILGRIM, Peter, FM 
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> > 
> > On Mon, 10 Mar 2003, PILGRIM, Peter, FM wrote:
> > 
> > > Date: Mon, 10 Mar 2003 17:18:25 -
> > > From: "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>
> > > Reply-To: Struts Users Mailing List 
> <[EMAIL PROTECTED]>
> > > To: "Struts Users Mailing List (E-mail)" 
> > <[EMAIL PROTECTED]>
> > > Subject: Struts Faces ea validation XML error
> > >
> > > After copying all three JSF JAR to struts-faces/WEB-INF,
> > > and copying commons-logging-1.0.2.jar over WEB-INF/lib
> > > I got a validation error in the Struts Faces download.
> > >
> > > Is the validation XML correct?
> > >
> > 
> > I only get errors like this when I forget to include
> > "/WEB-INF/validation.xml" in my webapps -- can you make sure 
> > that is still
> > present?
> > 
> > Craig
> 
> It is very weird because I have both `/WEB-INF/validation.xml'
> and `/WEB-INF/validation-rules.xml' in the right place,
> I also checked the `/WEB-INF/struts-config.xml' to make
> sure that validator plugin is correctly set. This is 
> how I downloaded the struts-faces.jar ``as is'
> 
> Something is wrong here.

I copied the new validation.xml and validation-rules.xml from
the original Struts example in 1.1 beta 3 release over to the
Struts-Faces web app. Lo and behold, it works!

> > > org.apache.jasper.JasperException: Depends string "email" 
> > was not found in
> > > validator-rules.xml.
> > >   void
> > > 
----
> 
> ----

Mr. Brownstone, Appetite for Destruction, G & R

--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923




  Visit our Internet site at http://www.rbsmarkets.com

This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
 Regulated by the Financial Services Authority


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts Faces ea validation XML error

[PILGRIM, Peter, FM]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> 
> On Mon, 10 Mar 2003, PILGRIM, Peter, FM wrote:
> 
> > Date: Mon, 10 Mar 2003 17:18:25 -
> > From: "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: "Struts Users Mailing List (E-mail)" 
> <[EMAIL PROTECTED]>
> > Subject: Struts Faces ea validation XML error
> >
> > After copying all three JSF JAR to struts-faces/WEB-INF,
> > and copying commons-logging-1.0.2.jar over WEB-INF/lib
> > I got a validation error in the Struts Faces download.
> >
> > Is the validation XML correct?
> >
> 
> I only get errors like this when I forget to include
> "/WEB-INF/validation.xml" in my webapps -- can you make sure 
> that is still
> present?
> 
> Craig

It is very weird because I have both `/WEB-INF/validation.xml'
and `/WEB-INF/validation-rules.xml' in the right place,
I also checked the `/WEB-INF/struts-config.xml' to make
sure that validator plugin is correctly set. This is 
how I downloaded the struts-faces.jar ``as is'

Something is wrong here.

> > org.apache.jasper.JasperException: Depends string "email" 
> was not found in
> > validator-rules.xml.
> > void
> > 
> org.apache.jasper.servlet.JspServletWrapper.service(javax.serv
> let.http.HttpS
> > ervletRequest, javax.servlet.http.HttpServletResponse, boolean)
> > JspServletWrapper.java:248
> > void
> > 
> org.apache.jasper.servlet.JspServlet.serviceJspFile(javax.serv
> let.http.HttpS
> > ervletRequest, javax.servlet.http.HttpServletResponse, 
> java.lang.String,
> > java.lang.Throwable, boolean)
> > JspServlet.java:295
> > void
> > 
> org.apache.jasper.servlet.JspServlet.service(javax.servlet.htt
> p.HttpServletR
> > equest, javax.servlet.http.HttpServletResponse)
> > JspServlet.java:241
> >
> > ----
> >

----

--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923



  Visit our Internet site at http://www.rbsmarkets.com

This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
 Regulated by the Financial Services Authority


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts Faces ea validation XML error

[Craig R. McClanahan]

On Mon, 10 Mar 2003, PILGRIM, Peter, FM wrote:

> Date: Mon, 10 Mar 2003 17:18:25 -
> From: "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List (E-mail)" <[EMAIL PROTECTED]>
> Subject: Struts Faces ea validation XML error
>
> After copying all three JSF JAR to struts-faces/WEB-INF,
> and copying commons-logging-1.0.2.jar over WEB-INF/lib
> I got a validation error in the Struts Faces download.
>
> Is the validation XML correct?
>

I only get errors like this when I forget to include
"/WEB-INF/validation.xml" in my webapps -- can you make sure that is still
present?

Craig

> org.apache.jasper.JasperException: Depends string "email" was not found in
> validator-rules.xml.
>   void
> org.apache.jasper.servlet.JspServletWrapper.service(javax.servlet.http.HttpS
> ervletRequest, javax.servlet.http.HttpServletResponse, boolean)
>   JspServletWrapper.java:248
>   void
> org.apache.jasper.servlet.JspServlet.serviceJspFile(javax.servlet.http.HttpS
> ervletRequest, javax.servlet.http.HttpServletResponse, java.lang.String,
> java.lang.Throwable, boolean)
>   JspServlet.java:295
>   void
> org.apache.jasper.servlet.JspServlet.service(javax.servlet.http.HttpServletR
> equest, javax.servlet.http.HttpServletResponse)
>   JspServlet.java:241
>
> ----
>
> --
> Peter Pilgrim,
> Struts/J2EE Consultant, RBoS FM, Risk IT
> Tel: +44 (0)207-375-4923
>
>
> ***
>   Visit our Internet site at http://www.rbsmarkets.com
>
> This e-mail is intended only for the addressee named above.
> As this e-mail may contain confidential or privileged information,
> if you are not the named addressee, you are not authorised to
> retain, read, copy or disseminate this message or any part of it.
> The Royal Bank of Scotland plc is registered in Scotland No 90312
> Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
> Regulated by the Financial Services Authority
> ***
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts-Faces

[Dom]

Found : I replaced commons-logging.jar with the commons-logging-1.0.2 one in
WEB-INF/lib

Now, I try to run one of my struts app using jakarta-struts-faces-0.3.
A very simple jsp. I've added all the required jars, updated web.xml by
including the JavaServer Faces Servlet Configuration and the required Tags :

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core"; %>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html"; %>
<%@ taglib prefix="s" uri="http://jakarta.apache.org/struts/tags-faces"; %>









When running this jsp, I get :

2003-03-09 19:33:36 StandardWrapperValve[jsp]: "Servlet.service()" pour la
servlet jsp a généré une exception
org.apache.jasper.JasperException: Cannot find FacesContext
 at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2
54)
 at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:256)
 at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
 at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
 at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
 at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
 at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
 at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
 at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:171)
 at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172
)
 at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
 at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
 at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
 at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
 at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
 at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
 at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
 at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
 at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
 at java.lang.Thread.run(Thread.java:536)
- Root Cause -
javax.servlet.ServletException: Cannot find FacesContext
 at
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImp
l.java:533)
 at
org.apache.jsp.customerFindAll_jsp._jspService(customerFindAll_jsp.java:76)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
 at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2
10)
 at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:256)
 at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
 at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
 at
org.apache