RE: [Shale] How to cancel the
Thanks Gary, I created my first submission to the issue tracker. Do I get a jacket or a certificate now that I belong to this exclusive group? -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 3:52 PM To: Struts Users Mailing List Subject: RE: [Shale] How to cancel the >From: "James Reynolds" <[EMAIL PROTECTED]> > > > Hmm, I downloaded the latest Shale libs and the first thing I notice > is that the validator fires for an h:inputText that isn't rendered. > This is what I have on my page: > > > style="font-weight:bold;" > rendered="#{!members$myAccount.editName}"/> > rendered="#{members$myAccount.editName}" > binding="#{members$myAccount.lastNameInput}" > required="true"> >arg="Last name" >server="true" >client="true"/> >errorClass="errorText"/> > > > > The inputText boxes are not rendered unless the user clicks a "Update > Name" button that changes the boolean "editName" property. The problem > is that the Update Name button is triggering the validation on the > un-rendered InputText control. > > I suppose the form's onSubmit event caller assumes the existence of > the Input boxes. > Yeah, that's a bug. The ValidatorScript should not generate javascript for components that are not rendered. Please create an issue tracker for this one - http://issues.apache.org/struts/. As a quick fix, you might try adding the same value binding to the commonValidator client attribute. Gary > > -Original Message- > From: Gary VanMatre [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 23, 2006 12:52 PM > To: Struts Users Mailing List > Subject: Re: [Shale] How to cancel the > > >From: "James Reynolds" > > > > > > I'm coding a cancel button on an update form. I've set its immediate > > attribute to true, but that isn't skipping the client side validation. > > Is there a way to do this, or must I only use server validation in > > this case? > > > > If you are using the JSF runtime commandButton or commandLink component, > the JavaScript, "bCancel=true;", will be injected into the onclick event > when the "immediate" is set to "true". > > http://issues.apache.org/struts/browse/SHALE-37 > > Originally, this worked for all the "javax.faces.Command" family but it > was just limited to the two JSF runtime command components due to a > tomahawk component issue, > http://issues.apache.org/struts/browse/SHALE-68. > > Gary > > > > Thanks > > > > > > - > > 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: [Shale] How to cancel the
Hmm, I downloaded the latest Shale libs and the first thing I notice is that the validator fires for an h:inputText that isn't rendered. This is what I have on my page: The inputText boxes are not rendered unless the user clicks a "Update Name" button that changes the boolean "editName" property. The problem is that the Update Name button is triggering the validation on the un-rendered InputText control. I suppose the form's onSubmit event caller assumes the existence of the Input boxes. -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 12:52 PM To: Struts Users Mailing List Subject: Re: [Shale] How to cancel the >From: "James Reynolds" <[EMAIL PROTECTED]> > > > I'm coding a cancel button on an update form. I've set its immediate > attribute to true, but that isn't skipping the client side validation. > Is there a way to do this, or must I only use server validation in > this case? > If you are using the JSF runtime commandButton or commandLink component, the JavaScript, "bCancel=true;", will be injected into the onclick event when the "immediate" is set to "true". http://issues.apache.org/struts/browse/SHALE-37 Originally, this worked for all the "javax.faces.Command" family but it was just limited to the two JSF runtime command components due to a tomahawk component issue, http://issues.apache.org/struts/browse/SHALE-68. Gary > Thanks > > > - > 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: [Shale] How to cancel the
It was the last announced Alpha update finished around the end of March. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, May 23, 2006 12:44 PM To: Struts Users Mailing List Subject: Re: [Shale] How to cancel the On 5/23/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > > I'm coding a cancel button on an update form. I've set its immediate > attribute to true, but that isn't skipping the client side validation. > Is there a way to do this, or must I only use server validation in > this case? This sounds like an issue that has been reported previously[1], and resolved as fixed. How recent is the version of Shale you are using? Thanks Craig [1] http://issues.apache.org/struts/browse/SHALE-37 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] How to cancel the
I'm coding a cancel button on an update form. I've set its immediate attribute to true, but that isn't skipping the client side validation. Is there a way to do this, or must I only use server validation in this case? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shale: onclick="disabled='true';" not calling Action Method. (stopping double click)
Oh, I totally missed the point. Best of luck. -Original Message- From: Jason Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 1:21 PM To: Struts Users Mailing List Subject: Re: Shale: onclick="disabled='true';" not calling Action Method. (stopping double click) hmmm that isn't going to solve my issue. I don't want the button disabled on reload. I only want it to be disabled from the time the user clicked the button, until the time the server is able to send back a response. Here is an example: On a login form... enter username and pwd and click the submit button. While the server is processing the login form (the IE globe is spinning) the button becomes disabled so that the user can't resubmit the same login form. I'm more curious about how setting a DOM property on a element would change the way it is handled on the server side. Thanks for the try though, Jason On 5/11/06, James Reynolds <[EMAIL PROTECTED]> wrote: > The first thought that occurs to me is, how about binding the button's > JSF 'disabled' attribute to a boolean property on your backing bean? > As part of the button's action method, you could set the boolean to > true, thereby disabling the button when the page reloads. > > > -Original Message- > From: Jason Vincent [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 11, 2006 10:42 AM > To: user@struts.apache.org > Subject: Shale: onclick="disabled='true';" not calling Action Method. > (stopping double click) > > Hi all, > > My project spec is asking me to disable form buttons once they are > clicked. It seemed easy to me, just add onclick="disabled='true'" to > the commandButton. But as anything I've found with JSF, it isn't that > easy. > > When I do this, the action method isn't being called after it passes > validation. If I remove the onclick attribute, the form works fine; > so I know it isn't a logic failure in the ViewController. > > I noticed that JSF inserts some of its own onclick logic to the button > too. So I thought I'd try to disable the button by using the onsubmit > attribute of the form tag. This also had the same behavior. > > What is going on here? Is disabling the button changing the submitted > request parameters? > > Thanks all, > Jason > > - > 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: Shale: onclick="disabled='true';" not calling Action Method. (stopping double click)
The first thought that occurs to me is, how about binding the button's JSF 'disabled' attribute to a boolean property on your backing bean? As part of the button's action method, you could set the boolean to true, thereby disabling the button when the page reloads. -Original Message- From: Jason Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 10:42 AM To: user@struts.apache.org Subject: Shale: onclick="disabled='true';" not calling Action Method. (stopping double click) Hi all, My project spec is asking me to disable form buttons once they are clicked. It seemed easy to me, just add onclick="disabled='true'" to the commandButton. But as anything I've found with JSF, it isn't that easy. When I do this, the action method isn't being called after it passes validation. If I remove the onclick attribute, the form works fine; so I know it isn't a logic failure in the ViewController. I noticed that JSF inserts some of its own onclick logic to the button too. So I thought I'd try to disable the button by using the onsubmit attribute of the form tag. This also had the same behavior. What is going on here? Is disabling the button changing the submitted request parameters? Thanks all, Jason - 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: [Shale/JSF] Frustrating Navigation Quirk
Thanks Gary, I was stuck in ValueChange rut. Switching to a command link fixed the problem and is much simpler. Have a great day! -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Monday, May 08, 2006 12:03 PM To: Struts Users Mailing List Subject: Re: [Shale/JSF] Frustrating Navigation Quirk >From: "James Reynolds" <[EMAIL PROTECTED]> > > > My problem deals with navigation between two pages, a Contract list > page and a Contract detail page. On the list page is a Boolean check > box that filters the list according to a certain criteria with a > ValueChangeListener. When the user click on a contract, the id of that > contract is sent as a parameter to the detail page. That parameter is > used in the init() method of the detail page's backing bean to load a > contract object and place it in session. All this works great. > > The user can go back and forth between the list page and the detail > page > *except* if the booleanCheckBox is clicked. Here is the sequence: The > user is viewing the detail page, then goes back to the list page _via > the back button of the browser_ (I suspect that's a key issue of the > problem), then the user clicks the booleanCheckBox. Instead of > filtering the list (and reloading the list page), the user is returned > to the detail page. > > What I've done so far: My first thought was that the detail page was > still the most recent view because the user employed the browser's > back button to return the list. The ValueChangeListener method, wired > to the list page (and that bean is in session scope), changes a > Boolean property, then calls renderResponse(). That which would reload > the current view - which is the detail page, according to my thought > process. > > To compensate for this, I placed additional code in the > ValueChangeListener that loaded the ViewId. If it didn't match my List > page ViewId, I set up the necessary code to navigate to the correct > ViewId. It didn't make any difference, so I'm not sure if my > hypothesis was correct. > > I'm frankly stumped right now, so any advice would be appreciated. I'm > thinking that this must have something to do with the > ValueChangeListener, which I've listed below. Should I be adding > something else in there? > It seems like you are trying to use the ValueChangeListener for navigation instead of for state management. The action method binding on a command component is where you would want to place the conditional navigation rules. Could you set the boolean flag in the ValueChangeListener that an action method would use to determine the correct navigation path? The action binding would be hooked to the command you are using to submit the page. >From the action, you could look at the boolean value a choose a logical outcome. Something like: public String filterList() { if (wasCheckBoxChanged) return "showList"; else return "showDetail"; } /list.jsp showDetail /detail.jsp showList /list.jsp Gary > > Thanks, > > public void compOnlyChecked(ValueChangeEvent vce) { > compOnly = (Boolean) vce.getNewValue(); > getFacesContext().renderResponse(); > } > > > - > 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]
[Shale/JSF] Frustrating Navigation Quirk
My problem deals with navigation between two pages, a Contract list page and a Contract detail page. On the list page is a Boolean check box that filters the list according to a certain criteria with a ValueChangeListener. When the user click on a contract, the id of that contract is sent as a parameter to the detail page. That parameter is used in the init() method of the detail page's backing bean to load a contract object and place it in session. All this works great. The user can go back and forth between the list page and the detail page *except* if the booleanCheckBox is clicked. Here is the sequence: The user is viewing the detail page, then goes back to the list page _via the back button of the browser_ (I suspect that's a key issue of the problem), then the user clicks the booleanCheckBox. Instead of filtering the list (and reloading the list page), the user is returned to the detail page. What I've done so far: My first thought was that the detail page was still the most recent view because the user employed the browser's back button to return the list. The ValueChangeListener method, wired to the list page (and that bean is in session scope), changes a Boolean property, then calls renderResponse(). That which would reload the current view - which is the detail page, according to my thought process. To compensate for this, I placed additional code in the ValueChangeListener that loaded the ViewId. If it didn't match my List page ViewId, I set up the necessary code to navigate to the correct ViewId. It didn't make any difference, so I'm not sure if my hypothesis was correct. I'm frankly stumped right now, so any advice would be appreciated. I'm thinking that this must have something to do with the ValueChangeListener, which I've listed below. Should I be adding something else in there? Thanks, public void compOnlyChecked(ValueChangeEvent vce) { compOnly = (Boolean) vce.getNewValue(); getFacesContext().renderResponse(); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Starting out with JDBCTemplate
A previous question to this list resulted in many recommendations to use Spring's JDBCTemplate (among other fine alternatives) to connect to my database. It looks like an attractive solution for me so I've been wading through a plethora of material. There are so many tutorials and a wealth of information available, but they all incorporate many many features of Spring that I'm not ready to tackle yet. I'm having trouble discerning which configuration pieces are really necessary just to use JDBCTemplate. I'm asking this group because I'm using JSF/Shale and I'm not sure how my choice of framework will affect the Spring configuration. Could you tell me the minimum pieces I need to assemble to employ JDBCTemplate? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] AbstractViewController for Dummies
I printed your answer and hung it on my cubical wall, where it will continue to help me in the future. 24k gold, Thank you! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, April 24, 2006 4:03 PM To: Struts Users Mailing List Subject: Re: [Shale] AbstractViewController for Dummies On 4/24/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > > My understanding of the JSF lifecycle is a bit tenuous. As a result, > I'm confused about the proper use of init(), preprocess(), and > prerender(). Thus far, I've just been using init() and destroy() to > handle the creation and closing of Connections and other minor duties > because they have just worked for what I needed. Now, I'm moving on > with some more complex pages and I want to be sure that I'm leveraging > the AbstractViewController for all it's worth. > > The documentation does a good job of explaining when and under what > conditions the events are fired, however, my weakness is that I just > don't know what kind of jsf programming events to stuff in each one. > > "If I have a component that uses select items (that don't live in the > application or session scopes), should I build them in init() or > prerender()?" These are the kinds of questions I wrestle with. That's a really useful question to help you understand the differences. The short answer is "either of these will technically work". Some help, huh :-). But there is an important difference in behavior that can help you choose. * The init() method is *always* called if this view controller is ever instantiated. * The prerender() method is *only* called if the corresponding view is actually going to be rendered. If you have navigated to some different page, the prerender() method on *that* page's view controller will be called instead of this one. That can save you from having to do a bunch of expensive database queries that you do not need. So, one way to look at what event method should be used for what kind of application logic is to consider the following two questions: (1) Do I need the results of this computation in order to process a form submit? (2) Do I need the results of this computation in order to render the page? Based on the anaswers, I would suggest sorting things out like this: * Use init() for "(1) and (2)" * Use preprocess() for "(1) only" * Use prerender for "(2) only" And, you can always put any necessary cleanup code in destroy(). So, what's the answer for the use case you just described? It turns out that init() is actually the correct answer -- because when you the form for this view, the UISelectOne or UISelectMany component performs validation on the input value(s) against the set of select items that are defined. If you are not storing the items in session or application scope, then you will need to reload them in order for these validations to not fail. On the other hand, if you *did* have the select items in session or application scope, then you could move the logic to prerender() and only spend the effort to accumulate the items list the first time it is rendered. An actual issue that I'm working through now is this: I have a page that > lists 'Contracts'. If the user clicks one, the plan is to navigate to > a detail page, with the Contract's id number stored in the parameter map. > The detail page's backing bean needs to instantiate a Contract object > based on the id value, but do I do that in the bean constructor, the > init() or the prerender() methods? Does the detail page itself have a form that can be submitted back in again? If so, then init() would be the right place -- by the same logic as above (you need it for both form processing and rendering). If the page just has navigation links, prerender() would work. Any advice would be appreciated. > > Thanks Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] AbstractViewController for Dummies
My understanding of the JSF lifecycle is a bit tenuous. As a result, I'm confused about the proper use of init(), preprocess(), and prerender(). Thus far, I've just been using init() and destroy() to handle the creation and closing of Connections and other minor duties because they have just worked for what I needed. Now, I'm moving on with some more complex pages and I want to be sure that I'm leveraging the AbstractViewController for all it's worth. The documentation does a good job of explaining when and under what conditions the events are fired, however, my weakness is that I just don't know what kind of jsf programming events to stuff in each one. "If I have a component that uses select items (that don't live in the application or session scopes), should I build them in init() or prerender()?" These are the kinds of questions I wrestle with. An actual issue that I'm working through now is this: I have a page that lists 'Contracts'. If the user clicks one, the plan is to navigate to a detail page, with the Contract's id number stored in the parameter map. The detail page's backing bean needs to instantiate a Contract object based on the id value, but do I do that in the bean constructor, the init() or the prerender() methods? Any advice would be appreciated. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale/JSF] Can I redirect/forward in the init() method?
That's doing it. Thank you! -Original Message- From: Richard Wallace [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 3:17 PM To: Struts Users Mailing List Subject: Re: [Shale/JSF] Can I redirect/forward in the init() method? James Reynolds wrote: > I want to test a value in session, then redirect or forward to a > different view based on the result. I tried using > getExternalContext().redirect("/theOtherPage.jsp"); but I received an > exception stating that I cannot redirect after the request is committed. > What's the proper way to do this? > > Try using getExternalContext ().dispatch (viewId); That should forward to the page you want. Rich - 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]
[Shale/JSF] Can I redirect/forward in the init() method?
I want to test a value in session, then redirect or forward to a different view based on the result. I tried using getExternalContext().redirect("/theOtherPage.jsp"); but I received an exception stating that I cannot redirect after the request is committed. What's the proper way to do this? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] When to create a database Connection?
Hi Hermod, Here's my reason I'm under pressure to get this project complete so I'm reluctant to take on learning Hibernate and Spring at this time. There's no question that would be a better way to do it, but (as you can probably tell) I'm not an expert programmer. Maybe my assumption is invalid, how challenging are these technologies for new comers? Thanks -Original Message- From: Hermod Opstvedt [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 29, 2006 11:45 AM To: 'Struts Users Mailing List' Subject: SV: [Shale] When to create a database Connection? Hi Give me one good reason as to why you are doing this. If you let existing tools do the job for you, you are going to relieve your self of a lot of trouble. Have a look at Hibernate or equivalent, combined with Spring. What you are doing here is really is something of the past. Hermod -Opprinnelig melding- Fra: James Reynolds [mailto:[EMAIL PROTECTED] Sendt: 29. mars 2006 19:33 Til: Struts Users Mailing List Emne: [Shale] When to create a database Connection? I'm getting a null pointer error in my backing bean. My grand plan was to create a Connection in the init() method extended from the AbstractViewController, so it can be used by any number of methods and getters in my bean, and then close it in destroy(). In this simple case, the only place this Connection is used is in a getter that returns a Result for a dataTable. However, it doesn't seem to be working as I get a null pointer exception. If I move the getConnection() method out of the init() method and into this getter, then everything works great. Am I miss-using the init() method? Import lots.of.stuff; public class Testimonial extends AbstractViewController { private Connection conn = null; public Testimonial(){ } public void init() { try { conn = DbConnection.getConnection(); System.out.println(); } catch (SQLException e) { e.printStackTrace(); } } public void destroy() { try { if (!conn.isClosed()) { conn.close(); } } catch (SQLException sqle) { log(sqle.getMessage(), sqle); sqle.printStackTrace(); } } public Result getAllTestimonials() { /* ### moving the "conn = DbConnection.getConnection()" here solves the problem ### */ Result result = null; PreparedStatement ps = null; try { ps = conn.prepareStatement(SqlStatements.ALL_TESITIMONIALS); result = ResultSupport.toResult(ps.executeQuery()); } catch (SQLException sqle) { System.out.println("SQL Exception:" + sqle.getMessage()); sqle.printStackTrace(); } catch (Exception e) { System.out.println("Exception:" + e.getMessage()); e.printStackTrace(); } finally { try { if (ps != null) { ps.close(); } } catch (SQLException e) { e.printStackTrace(); } } return result; } } - 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: [Shale] When to create a database Connection?
Never mind, I mis-spelled the bean name in the Faces-Config. Oh the shame :( -Original Message- From: James Reynolds [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 29, 2006 10:33 AM To: Struts Users Mailing List Subject: [Shale] When to create a database Connection? I'm getting a null pointer error in my backing bean. My grand plan was to create a Connection in the init() method extended from the AbstractViewController, so it can be used by any number of methods and getters in my bean, and then close it in destroy(). In this simple case, the only place this Connection is used is in a getter that returns a Result for a dataTable. However, it doesn't seem to be working as I get a null pointer exception. If I move the getConnection() method out of the init() method and into this getter, then everything works great. Am I miss-using the init() method? Import lots.of.stuff; public class Testimonial extends AbstractViewController { private Connection conn = null; public Testimonial(){ } public void init() { try { conn = DbConnection.getConnection(); System.out.println(); } catch (SQLException e) { e.printStackTrace(); } } public void destroy() { try { if (!conn.isClosed()) { conn.close(); } } catch (SQLException sqle) { log(sqle.getMessage(), sqle); sqle.printStackTrace(); } } public Result getAllTestimonials() { /* ### moving the "conn = DbConnection.getConnection()" here solves the problem ### */ Result result = null; PreparedStatement ps = null; try { ps = conn.prepareStatement(SqlStatements.ALL_TESITIMONIALS); result = ResultSupport.toResult(ps.executeQuery()); } catch (SQLException sqle) { System.out.println("SQL Exception:" + sqle.getMessage()); sqle.printStackTrace(); } catch (Exception e) { System.out.println("Exception:" + e.getMessage()); e.printStackTrace(); } finally { try { if (ps != null) { ps.close(); } } catch (SQLException e) { e.printStackTrace(); } } return result; } } - 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]
[Shale] When to create a database Connection?
I'm getting a null pointer error in my backing bean. My grand plan was to create a Connection in the init() method extended from the AbstractViewController, so it can be used by any number of methods and getters in my bean, and then close it in destroy(). In this simple case, the only place this Connection is used is in a getter that returns a Result for a dataTable. However, it doesn't seem to be working as I get a null pointer exception. If I move the getConnection() method out of the init() method and into this getter, then everything works great. Am I miss-using the init() method? Import lots.of.stuff; public class Testimonial extends AbstractViewController { private Connection conn = null; public Testimonial(){ } public void init() { try { conn = DbConnection.getConnection(); System.out.println(); } catch (SQLException e) { e.printStackTrace(); } } public void destroy() { try { if (!conn.isClosed()) { conn.close(); } } catch (SQLException sqle) { log(sqle.getMessage(), sqle); sqle.printStackTrace(); } } public Result getAllTestimonials() { /* ### moving the "conn = DbConnection.getConnection()" here solves the problem ### */ Result result = null; PreparedStatement ps = null; try { ps = conn.prepareStatement(SqlStatements.ALL_TESITIMONIALS); result = ResultSupport.toResult(ps.executeQuery()); } catch (SQLException sqle) { System.out.println("SQL Exception:" + sqle.getMessage()); sqle.printStackTrace(); } catch (Exception e) { System.out.println("Exception:" + e.getMessage()); e.printStackTrace(); } finally { try { if (ps != null) { ps.close(); } } catch (SQLException e) { e.printStackTrace(); } } return result; } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] Getting the JSF Session Started
Oh, OK. Thanks again, I'm going back under the hood :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, March 28, 2006 5:33 PM To: Struts Users Mailing List Subject: Re: [Shale] Getting the JSF Session Started On 3/28/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > Thanks so much for taking the time to do this. Actually, I do have > outputLinks and commandLinks inside the same form to the JSF books> is that bad practice? No, that's fine ... I'm just suggesting that temporarily creating a 10 line JSP page without all the extra stuff might help illuminate where the problems are. Craig -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Craig McClanahan > Sent: Tuesday, March 28, 2006 5:12 PM > To: Struts Users Mailing List > Subject: Re: [Shale] Getting the JSF Session Started > > On 3/28/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > > > (Oh I hope there's nothing stupid here) > > > Nothing obvious stands out (I presume that the "std" thing is loaded > in messages.jspx?). When I run into scenarios like that, I try to get > to the simplest possible case first (say, a form with a command link > and an output link embedded inside) in it, and see that work, before > fleshing it back out again. (Also, of course, check the servlet > container logs for any errors.) > > 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: [Shale] Getting the JSF Session Started
Thanks so much for taking the time to do this. Actually, I do have outputLinks and commandLinks inside the same form is that bad practice? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, March 28, 2006 5:12 PM To: Struts Users Mailing List Subject: Re: [Shale] Getting the JSF Session Started On 3/28/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > (Oh I hope there's nothing stupid here) Nothing obvious stands out (I presume that the "std" thing is loaded in messages.jspx?). When I run into scenarios like that, I try to get to the simplest possible case first (say, a form with a command link and an output link embedded inside) in it, and see that work, before fleshing it back out again. (Also, of course, check the servlet container logs for any errors.) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] Getting the JSF Session Started
(Oh I hope there's nothing stupid here) <%@ taglib prefix="f" uri="http://java.sun.com/jsf/core"; %> <%@ taglib prefix="h" uri="http://java.sun.com/jsf/html"; %> <%@ taglib prefix="t" uri="http://myfaces.apache.org/tomahawk"; %> <%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %> <%@ include file="messages.jspf" %> NPP News http://www.ctconsulting.com/nppsignup.php"; target="_blank" onmouseover="self.status = 'Web Seminars'; return true;" onmouseout="self.status = ''; return true;"> Plus * * * http://www.myplacetolearn.com/"; target="_blank"> mailto:[EMAIL PROTECTED]"> -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, March 28, 2006 4:39 PM To: Struts Users Mailing List Subject: Re: [Shale] Getting the JSF Session Started On 3/28/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > Ah, I was barking up the wrong tree again :) > > Thanks for the suggestion. I do have a messages component on my page > and I'm not seeing any errors. However, I have not implemented a > backing bean for this first page (no real need for it yet) so I am > seeing the corresponding warnings in the console. That wouldn't play > any part would it? You mean the warning about not finding a view controller? No, that's not part of the picture ... indeed, if you pick up tonight's nightly build that log message has been demoted from a warning to a debug message -- it's perfectly legal to not use view controllers. Also, I do have many navigation commandLinks with the immediate > attribute set to true in order to bypass the required fields in the > login section of the page. I've read in some posts that it might be > desirable to set up the navigation as a result of ActionEvent rather > than the action. Is that true, or am I misinterpreting what I've read? I've read the same ... but don't necessarily agree :-). I use immediate for either navigation buttons, or for a cancel button. It'd be helptul to see some code on your JSP page to help figure out what's really going on. Thanks again! Craig -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Craig McClanahan > Sent: Tuesday, March 28, 2006 4:04 PM > To: Struts Users Mailing List > Subject: Re: [Shale] Getting the JSF Session Started > > On 3/28/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > > > > > I'm having to click twice to get a session started. I based my app > > on > > > the Shale-blank code, which includes an index.jsp file which > > contains a tag to "welcome.jsf" to, as I understand > > it, get a session started in the framework. > > > JSF itself doesn't start the session -- in this particular > application, the session is created as a side effect of executing the > index.jsp page ... JSP pages always create a session (if it does not > exist) unless you declare that you do not want one. > > So why the forward in this case? Because some containers do not > correctly support a welcome file name of "welcome.jsf" where there is > no actual resource in the webapp at that location. > > However, I still need to click twice on command buttons or command > links > > to get any action. Should I be using a more thorough method to > > ensure > > > a session begins? > > > Without seeing your code, it's difficult to determine what might be > causing the behavior you are seeing, but it seems unlikely to me that > session existence has an impact. One thing to check, though, is if > your page is triggering a validation error somehow -- unless you have > an or component on your page, to show the > messages when the page gets redisplayed, this can be a bit puzzling to > JSF newcomers. > > Thanks > > > 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: [Shale] Getting the JSF Session Started
Ah, I was barking up the wrong tree again :) Thanks for the suggestion. I do have a messages component on my page and I'm not seeing any errors. However, I have not implemented a backing bean for this first page (no real need for it yet) so I am seeing the corresponding warnings in the console. That wouldn't play any part would it? Also, I do have many navigation commandLinks with the immediate attribute set to true in order to bypass the required fields in the login section of the page. I've read in some posts that it might be desirable to set up the navigation as a result of ActionEvent rather than the action. Is that true, or am I misinterpreting what I've read? Thanks again! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, March 28, 2006 4:04 PM To: Struts Users Mailing List Subject: Re: [Shale] Getting the JSF Session Started On 3/28/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > > I'm having to click twice to get a session started. I based my app on > the Shale-blank code, which includes an index.jsp file which contains > a tag to "welcome.jsf" to, as I understand it, get a > session started in the framework. JSF itself doesn't start the session -- in this particular application, the session is created as a side effect of executing the index.jsp page ... JSP pages always create a session (if it does not exist) unless you declare that you do not want one. So why the forward in this case? Because some containers do not correctly support a welcome file name of "welcome.jsf" where there is no actual resource in the webapp at that location. However, I still need to click twice on command buttons or command links > to get any action. Should I be using a more thorough method to ensure > a session begins? Without seeing your code, it's difficult to determine what might be causing the behavior you are seeing, but it seems unlikely to me that session existence has an impact. One thing to check, though, is if your page is triggering a validation error somehow -- unless you have an or component on your page, to show the messages when the page gets redisplayed, this can be a bit puzzling to JSF newcomers. Thanks 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]
[Shale] Getting the JSF Session Started
I'm having to click twice to get a session started. I based my app on the Shale-blank code, which includes an index.jsp file which contains a tag to "welcome.jsf" to, as I understand it, get a session started in the framework. However, I still need to click twice on command buttons or command links to get any action. Should I be using a more thorough method to ensure a session begins? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] jsp vs. jspx
As part of converting my app from vanilla faces to Shale, I decided to convert my jsp files to jspx for two reasons. First, to prevent someone else from employing scriplets in the future and, second, because I've read that it's a good idea (maybe I've been reading all the wrong stuff). Now I'm running into some newbie problems getting jspx pages to display correctly so I'm starting to second guess myself. Is there any advantage one way or the other as far as Shale is concerned? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [FRIDAY] Re: has struts reached the saturation
Ted, Craig and everyone else, Thanks so much for your dedication and support to these projects. The advice I've received on this list has been a life-saver and has helped me immensely in my career. Your contributions are greatly appreciated. Sincerely, The silent majority - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale]/jsf Referencing a component
Works like a charm! I used the binding method and now I'm off and running. Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Thursday, March 16, 2006 1:42 PM To: Struts Users Mailing List Subject: Re: [Shale]/jsf Referencing a component On 3/16/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > > I'm enjoying the helper methods extended from the > AbstractViewController and I'd like to send a message to a particular component. Good idea :-). For example, > here's the slick error() method. > > protected void error(javax.faces.component.UIComponent component, > java.lang.String summary) > > I'm not sure how to reference the desired component. Can I refer to > the component with its ID? You can't use a component identifier, because the method signature quoted above requires a component *instance*. There are two reasonable approaches to how you can acquire such a component reference. * Use the UIComponent.findComponent() method, perhaps on the root UIViewRoot component, to find the component instance for the specified client id. NOTE -- the "Proposed Final Draft 2" version of the JSF 1.2 spec has added an additional related option here. * Use the "binding" attribute on your JSP tag to attach the component instance into your backing bean. The most common use case I've had for this is when you want to implement pagination on a table component (but the same principle applies to the question you are asking). Consider a component with the following JSP custom tag: In the backing bean class referenced by the managed bean name "mybean", you need to define a property for the component itself, as opposed to its value: private HtmlDataTable table = null; public HtmlDataTable getTable() { return this.table; } public void setTable(HtmlDataTable table) { this.table = table; } Using the latter approach, any event handler method in the same backing bean has direct access to the component instance -- without even having to know its id. The same sort of approach can be used to expose component instances needed for the first parameter to methods like error(). If you think, on the other hand, that we should also support passing a string (the client id) instead of the component instance, please file an RFE in the issue tracking system: http://issues.apache.org/bugzilla/ Under product "Struts" and category "Shale". Thanks Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale]/jsf Referencing a component
I'm enjoying the helper methods extended from the AbstractViewController and I'd like to send a message to a particular component. For example, here's the slick error() method. protected void error(javax.faces.component.UIComponent component, java.lang.String summary) I'm not sure how to reference the desired component. Can I refer to the component with its ID? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] Creating my Managed Bean template
I get it. Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, March 13, 2006 3:30 PM To: Struts Users Mailing List Subject: Re: [Shale] Creating my Managed Bean template On 3/13/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > > I'm about to set up a template file for managed-beans and I was > planning on inserting the methods supported by the ViewController interface. > > My question is, does it hurt to have empty ViewController methods in > the bean if I'm not using them? If, for some reason, I'm not using > the > init() method, should I remove it from the file to avoid confusing > Shale? If your backing bean "implements ViewController" then you are going to be *required* to implement all the methods (even if they are empty) to avoid compile errors. The simplest thing to do is "extends AbstractViewController". Besides the fact that this class implements (as empty methods) all the callbacks, so you only have to override the ones you care about, it also offers you a bunch of useful helper methods too. Thanks Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] Creating my Managed Bean template
I'm about to set up a template file for managed-beans and I was planning on inserting the methods supported by the ViewController interface. My question is, does it hurt to have empty ViewController methods in the bean if I'm not using them? If, for some reason, I'm not using the init() method, should I remove it from the file to avoid confusing Shale? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Shale & Container Managed Security
>There is a subtle but important issue. Container managed security only >operates on the original URL to which a GET or POST was directed ... it does >*not* apply to RequestDispatcher.forward() calls. In JSF terms, that means you can protect the form submit, >but it is up to the application to decide whether or not navigation to a particular page is allowed. > >The RFE being discussed here could do something like a custom navigation handler with a pluggable strategy for >choosing whether or not navigation (according to the navigation rules) is actually going to be permitted or >not. One implementation of this strategy could be based on user roles, but you could also do something more >fine grained or context sensitive (since the strategy implementation would have access to FacesContext, it can >do whatever it needs). > >Craig I think I understand: if I use an action method to forward a user to a different page based on its String name in my Faces-Config.xml, I'm basically employing RequestDispatcher.forward(), which circumvents the container managed security. Did I get it? In theory, couldn't I set a role property for each page in its element and then conditionally render the page, or redirect elsewhere, based on my user's role stored in session? If so, should this evaluation take place in the init() method of every page's bean, or is there a better way to handle it globally? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Shale & Container Managed Security
Now I get it completely (I'm still getting up to speed on a lot of this). Thanks! -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 1:26 PM To: Struts Users Mailing List Subject: RE: [OT] RE: Shale & Container Managed Security >From: "James Reynolds" <[EMAIL PROTECTED]> > > >If you are using J2EE container managed security, why not use the > standard > >declarative security constraint on a url-pattern? You then assign > roles > >to the constraint and to groups and/or users. > > > >Gary > > Thanks Gary, > > Maybe I'm misunderstanding Craig's response (below). Perhaps he is > referring to page-by-page control, while you are referring to a url > pattern that encompasses all contents of a folder (/members_only/*). > Is that the subtle difference here? > Oh, right. I guess you would also have to use "redirects" instead of "forwards" for navigation since the forwards are trusted. viewSalary /secured/viewSalary.faces You could also add programmatic checks in your "action" methods to return outcomes based on security. Gary > > > Shale's filters do indeed intercept whatever requests it is mapped to, > > > but there are two important things to understand with respect to > > container managed security: > > > > * Container managed security is applied *before* any filters > > (including the one that Shale provides). > > > > * Container managed security is applied *only* on the > > initial request, not on RequestDispatcher.forward() calls. > > In JSF (and therefore Shale) apps, that means you can > > protect the incoming form submits (they will be mapped > > to something like "/editCustomer.jsf" if you are using > > extension mapping, and the page being submitted was > > "/editCustomer.jsp"). > > > > The second issue means that it is your application's responsibility to > > > decide whether or not the user should be allowed to navigate to a > > particular page. Container managed security won't help you there. That > > > being said, it might be interesting for Shale to deliver a custom JSF > > navigation handler that would optionally impose that sort of control > > ("only a manager can navigate to the salary details page"). > > > > Craig > > > > -Original Message- > > > From: James Reynolds [mailto:[EMAIL PROTECTED] > > > Sent: Friday, March 03, 2006 3:02 PM > > > To: Struts Users Mailing List > > > Subject: Shale & Container Managed Security > > > > > > > > > I'm a newbie setting up container managed security for a basic > > > Shale-blank application. For my first attempt, I'm trying a simple > > > BASIC authentication but I'm having troubles so I'm trying to rule > out > > > > > the unknowns. > > > > > > My question for this list is, does Shale have an impact on > traditional > > > > > Container Managed Security Methods? > > > > > > Thanks > > > > > > > > > > - > > > 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Shale & Container Managed Security
>If you are using J2EE container managed security, why not use the standard >declarative security constraint on a url-pattern? You then assign roles >to the constraint and to groups and/or users. > >Gary Thanks Gary, Maybe I'm misunderstanding Craig's response (below). Perhaps he is referring to page-by-page control, while you are referring to a url pattern that encompasses all contents of a folder (/members_only/*). Is that the subtle difference here? > Shale's filters do indeed intercept whatever requests it is mapped to, > but there are two important things to understand with respect to > container managed security: > > * Container managed security is applied *before* any filters > (including the one that Shale provides). > > * Container managed security is applied *only* on the > initial request, not on RequestDispatcher.forward() calls. > In JSF (and therefore Shale) apps, that means you can > protect the incoming form submits (they will be mapped > to something like "/editCustomer.jsf" if you are using > extension mapping, and the page being submitted was > "/editCustomer.jsp"). > > The second issue means that it is your application's responsibility to > decide whether or not the user should be allowed to navigate to a > particular page. Container managed security won't help you there. That > being said, it might be interesting for Shale to deliver a custom JSF > navigation handler that would optionally impose that sort of control > ("only a manager can navigate to the salary details page"). > > Craig > > -Original Message- > > From: James Reynolds [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 03, 2006 3:02 PM > > To: Struts Users Mailing List > > Subject: Shale & Container Managed Security > > > > > > I'm a newbie setting up container managed security for a basic > > Shale-blank application. For my first attempt, I'm trying a simple > > BASIC authentication but I'm having troubles so I'm trying to rule out > > > the unknowns. > > > > My question for this list is, does Shale have an impact on traditional > > > Container Managed Security Methods? > > > > Thanks > > > > > > - > > 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]
[OT] RE: Shale & Container Managed Security
Thank you Craig, that's very helpful to understand. There are two things I was hoping to accomplish with Container Managed Security. 1. Ensuring that a user is logged in before serving up protected pages. I believe this is handled easily by using a Servlet Filter to check for a required session object (like username), similar to the example provided by Kito Mann in JSF in Action. 2. Protecting certain parts of the site based on a user's role. This is where I'm having difficulty. Among Shale/JSF programmers, is there a popular/best practice for implementing this requirement? Any advice would be appreciated. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Friday, March 03, 2006 4:52 PM To: Struts Users Mailing List Subject: Re: Shale & Container Managed Security On 3/3/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > Allow me to refine my question. I'm wondering if the Shale filter is > intercepting requests to the container. Do I need to adjust the > filter mapping? Is there an FM somewhere that I should R? Shale's filters do indeed intercept whatever requests it is mapped to, but there are two important things to understand with respect to container managed security: * Container managed security is applied *before* any filters (including the one that Shale provides). * Container managed security is applied *only* on the initial request, not on RequestDispatcher.forward() calls. In JSF (and therefore Shale) apps, that means you can protect the incoming form submits (they will be mapped to something like "/editCustomer.jsf" if you are using extension mapping, and the page being submitted was "/editCustomer.jsp"). The second issue means that it is your application's responsibility to decide whether or not the user should be allowed to navigate to a particular page. Container managed security won't help you there. That being said, it might be interesting for Shale to deliver a custom JSF navigation handler that would optionally impose that sort of control ("only a manager can navigate to the salary details page"). Craig -Original Message- > From: James Reynolds [mailto:[EMAIL PROTECTED] > Sent: Friday, March 03, 2006 3:02 PM > To: Struts Users Mailing List > Subject: Shale & Container Managed Security > > > I'm a newbie setting up container managed security for a basic > Shale-blank application. For my first attempt, I'm trying a simple > BASIC authentication but I'm having troubles so I'm trying to rule out > the unknowns. > > My question for this list is, does Shale have an impact on traditional > Container Managed Security Methods? > > Thanks > > > - > 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: Shale & Container Managed Security
Allow me to refine my question. I'm wondering if the Shale filter is intercepting requests to the container. Do I need to adjust the filter mapping? Is there an FM somewhere that I should R? -Original Message- From: James Reynolds [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 3:02 PM To: Struts Users Mailing List Subject: Shale & Container Managed Security I'm a newbie setting up container managed security for a basic Shale-blank application. For my first attempt, I'm trying a simple BASIC authentication but I'm having troubles so I'm trying to rule out the unknowns. My question for this list is, does Shale have an impact on traditional Container Managed Security Methods? Thanks - 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]
Shale & Container Managed Security
I'm a newbie setting up container managed security for a basic Shale-blank application. For my first attempt, I'm trying a simple BASIC authentication but I'm having troubles so I'm trying to rule out the unknowns. My question for this list is, does Shale have an impact on traditional Container Managed Security Methods? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shale Navigation Error
Never mind. NetBeans is somehow adding the Spring jars back in when I build the project. Manually removing them fixed the problem and it's navigating now. -Original Message- From: James Reynolds [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 9:55 AM To: user@struts.apache.org Subject: Shale Navigation Error I've set up a very basic web app (running on tomcat 5.5.15) based on the Shale-blank.war I downloaded on 3/1/06. It compiles and runs, but if I navigate to a page, it throws the error listed below. I found some messages in the mail archives that described a similar problem that related to Spring integration. I've since removed any jars that appeared to be Spring related, but it still throws the error. Any ideas? Thanks exception javax.servlet.ServletException: No WebApplicationContext found: no ContextLoaderListener registered? javax.faces.webapp.FacesServlet.service(FacesServlet.java:121) org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF ilter.java:285) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(Extensi onsFilter.java:122) root cause java.lang.IllegalStateException: No WebApplicationContext found: no ContextLoaderListener registered? org.springframework.web.jsf.FacesContextUtils.getRequiredWebApplicationC ontext(FacesContextUtils.java:78) org.springframework.web.jsf.DelegatingVariableResolver.getWebApplication Context(DelegatingVariableResolver.java:134) org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(D elegatingVariableResolver.java:112) org.apache.shale.spring.WebApplicationContextVariableResolver.resolveVar iable(WebApplicationContextVariableResolver.java:87) org.apache.shale.view.faces.ViewViewHandler.setupViewController(ViewView Handler.java:233) org.apache.shale.view.faces.ViewViewHandler.createView(ViewViewHandler.j ava:126) org.apache.shale.tiles.TilesViewHandler.createView(TilesViewHandler.java :184) org.apache.myfaces.application.NavigationHandlerImpl.handleNavigation(Na vigationHandlerImpl.java:145) org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(D ialogNavigationHandler.java:193) org.apache.myfaces.application.ActionListenerImpl.processAction(ActionLi stenerImpl.java:84) javax.faces.component.UICommand.broadcast(UICommand.java:106) javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:90) javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:164) org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleIm pl.java:316) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86 ) javax.faces.webapp.FacesServlet.service(FacesServlet.java:106) org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF ilter.java:285) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(Extensi onsFilter.java:122) - 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]
Shale Navigation Error
I've set up a very basic web app (running on tomcat 5.5.15) based on the Shale-blank.war I downloaded on 3/1/06. It compiles and runs, but if I navigate to a page, it throws the error listed below. I found some messages in the mail archives that described a similar problem that related to Spring integration. I've since removed any jars that appeared to be Spring related, but it still throws the error. Any ideas? Thanks exception javax.servlet.ServletException: No WebApplicationContext found: no ContextLoaderListener registered? javax.faces.webapp.FacesServlet.service(FacesServlet.java:121) org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF ilter.java:285) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(Extensi onsFilter.java:122) root cause java.lang.IllegalStateException: No WebApplicationContext found: no ContextLoaderListener registered? org.springframework.web.jsf.FacesContextUtils.getRequiredWebApplicationC ontext(FacesContextUtils.java:78) org.springframework.web.jsf.DelegatingVariableResolver.getWebApplication Context(DelegatingVariableResolver.java:134) org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(D elegatingVariableResolver.java:112) org.apache.shale.spring.WebApplicationContextVariableResolver.resolveVar iable(WebApplicationContextVariableResolver.java:87) org.apache.shale.view.faces.ViewViewHandler.setupViewController(ViewView Handler.java:233) org.apache.shale.view.faces.ViewViewHandler.createView(ViewViewHandler.j ava:126) org.apache.shale.tiles.TilesViewHandler.createView(TilesViewHandler.java :184) org.apache.myfaces.application.NavigationHandlerImpl.handleNavigation(Na vigationHandlerImpl.java:145) org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(D ialogNavigationHandler.java:193) org.apache.myfaces.application.ActionListenerImpl.processAction(ActionLi stenerImpl.java:84) javax.faces.component.UICommand.broadcast(UICommand.java:106) javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:90) javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:164) org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleIm pl.java:316) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86 ) javax.faces.webapp.FacesServlet.service(FacesServlet.java:106) org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF ilter.java:285) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(Extensi onsFilter.java:122) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]