Mike Smithson

Greenhorn
+ Follow
since Sep 15, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Mike Smithson

I'm having a problem with an include, where the content in the include seems to be functioning as if it is not within the "including" template's <ice:form>

Each time a user clicks a command link in the "included" content, they get the JavaScript error below (two times):

Internet explorer:
Exception thrown and not caught, line 19, char 4054.
Firefox:
Uncaught exception: couldn’t find container for property:bridge.

My understanding from some searching is that this is commonly a missing <form> tag. But the include seems to be properly wrapped by an <ice:form> tag.


searchScreen.jspx is the "including file", it has the <ice: form>, and the included "searchWorkArea.jspx" has the command buttons that throw the JavaScript errors.




The command links inside searchWorkArea.jspx that are causing JavaScript errors look like the following:



All of the links function properly after the 2 JavaScript alerts, it's basically an annoyance but I really want to understand and fix this problem. Is there something wrong with how these are constructed?



12 years ago
JSF

Paul Clapham wrote:I have no idea. You said that JSP includes a lot of other JSPs. Perhaps you are making an incorrect assumption about the order in which the compiled code will be executed. I don't know whether you are or not, and I don't really care to know anyway because I wouldn't write code where it mattered. And if I were brought in to fix that problem in your code I would just refactor it as per my earlier post.



The logout.jsp doesn't include any other .jsps. The rest of the site's pages have included jsps (left nav, header, footer, normal stuff like that). The logout .jsp is accessed directly via a link. It executes some code that looks at session values to determine which site the user is logging out of (different sites for different regions of the country), and then does the session.invalidate method. It then redirects the user to a logout landing page (which is actually just a .html document)...

13 years ago

Bear Bibeault wrote:Paul is spot on, it would be best to remove all this code from the JSP. In fact, in 2011, there should never be Java code of any kind in a JSP -- that's a poor practice that has been discredited for almost 10 years now.



I wouldn't be surprised to find that this .jsp is about that old.. :-) Seriously, it's on a site with several million subscribers, so it gets a lot of use. The problem is, this behavior seems to have just started somewhat recently though.

A re-write could be justified, but it would be hugely helpful if I understood exactly what is happening and why so I can justify the rewrite. The hope was that I could put a "try/catch" in logout.jsp, but the problem is that, frequently, the string of null pointers in other jsps begins somewhere other than logout.jsp.

You all have given me more to look at, thanks!!
13 years ago

Paul Clapham wrote:My theory was that the processing went in two steps:

(1) Invalidate the session

(2) Try to use data from the session

I'm pretty sure that both of these steps are in the code somewhere, and I'm pretty sure people have asked this already, but do you try to do (2) after (1)? Even after all these posts I can't figure out the answer to that question.




I just added a little code after the session.invalidate(), and it does throw an illegal state exception:



But in the actual logout.jsp itself, the invalidate() method is essentially the last thing in the JSP. So what is confusing to me still is, why a bunch of other .jsp's throw null pointers as if the jvm/actionservlet is trying to create them or access them??


13 years ago

Bear Bibeault wrote:Why would the JVM not try to "do things" after a session invalidation?



That is probably poorly phrased on my part. :-)

I meant, it seems like it is trying to "do things" with the session/client that was invalidated. For example, after logout.jsp, I will see a huge thread dump with null pointers in a string of jsps, then finally one or more Response Already Committed exceptions. Here is an example, these .jsps would all be "on the page" (ie, they are includes) before logout, but after logout has exectued and you are redirected to the "logout landing page", none of these jsp's would exist.

• /portal/common/blocks/postPromotion4.jsp,
• /portal/common/blocks/postPromotion5.jsp, then
• /portal/common/navigation/footer.jsp,
• /portal/common/template/LeftnavPortalTemplate.jsp,
• /portal/member/postPwdCategory.jsp,
• Exception in AppActionServletjavax.servlet.ServletException,
• Uncaught exception thrown in one of the service methods of the servlet: action. Exception thrown : java.lang.IllegalStateException: Cannot forward. Response already committed.
• java.lang.IllegalStateException: Cannot forward. Response already committed.
13 years ago
There is some code in between there that would be relevant, along with some stuff that I don't think is.. Here is the relevant:



I am seeing tons of those response already committed in the full stack trace, not just the one on the cookie.

It's almost like the jvm is trying to do things after the session has been invalidated, which is why a bunch of null pointers in .jsps (as well as the response already committed) are occuring. I can't figure out what would cause this though...

13 years ago
Here is the start of the .jsp, right after the page imports. Don't think anything is really proprietary here.. Is this what you are looking for?

13 years ago
nope, the first references to the session are getAttribute methods.
13 years ago
session.invalidate(); is located in logout.jsp, which is a link at bottom of the page (link is directly to the jsp, that is). Code is at the end of logout.jsp:

if (abandonSession) { // which is deterimined from a session attribute above...
session.invalidate();
System.out.println ("Mike: session has been abandoned!");


I don't see any direct defining of the session, there are numeros session.getAttribute methods on the .jsp before the invalidate method is called on it. I just assumed the session was already available.


I'm new to this area, still trying to figure out some of the session stuff on the web side.. Please let me know if I'm looking at something from wrong perspective.


Thanks!!
13 years ago
We are seeing a variety of errors show up in our logs and monitoring tools during our logout process. I'm struggling to narrow down the cause.

Our logout jsp has a session.invalidate(); statement. That statement is executing, but frequently right after it executes, a whole string of null pointers in various jsps occurs, as well as illegal state exceptions (response already committed).

I can duplicate this on my local server, but because it doesn't have a common "starting point", I have never been able to successfully catch it.

This thread dump is from right when session.invalidate() executes, until the first couple of errors (a long string of jsp null pointers would then follow).

Does anyone have any suggestions as to what to try? It seems like SessionListener.java is creating a new session for some reason?

Please let me know if this is the wrong forum, I can't decide if it is servlet related (ActionServlet specifically) or something else..

13 years ago

Campbell Ritchie wrote:Class casts are nasty evil things. They are error-prone and should be avoided as much as possible.
I pointed it out because I have had so many myself

You need to decide what is being returned, and what you want.

  • How do you get eUser?
  • Does its class implement the IMember interface? (By the way, it looks more like C# coding conventions than Java™, starting interface names with I.)
  • What is the return type of the method you get eUser from?
  • What methods are there in the IMember interface?
  • Do you need any more methods?


  • eUser is passed to the method:



    I have no idea where the coding convention in play came from.. it's code from part of a very large enterprise site's login process, over which i have little control.. Essentially what is happening is that this particular code is getting hit for all different login user roles, and the class cast exception happens whenever it's not a "Member" role.. I think I know how to fix, but really want to understand it all both from perspective of my fix code and also my general knowledge, in that i hate feeling like I don't fully understand something! lol.. plus i know i have to understand it for SCJP of course...


    IMember actually extends IEUser, as do our other user roles...

    I have to figure out what eUser is when it comes in, if not a member, don't do the cast (and skip the few lines of Member-specific code directly below).. seems simple enough, it just bugs me that I didn't fully understand it all.
    13 years ago

    Campbell Ritchie wrote:

    Jesper de Jong wrote: . . . The only thing that a cast does, is tell the compiler "look, I have this object here, and I want you to treat it as if it is of type IMember". . . .

    . . . with the complication that at Runtime, you may be mistaken about its being an IMember, in which case you see one of these




    Campbell - funny you should point that out, as that is exactly what is happening in our code! :-) I basically know WHY the ClassCastException is happening, I was just struggling with the code where it happens.. Lots of good information above that I'm digesting still, thanks guys!

    FYI, this is for a production issue I'm looking at for my day job, not for a course or my SCJP prep work (using Sierra/Bates primarily for that)... but obviously i am also interested in learning for SCJP as well!
    13 years ago
    Campbell, thanks for the welcome!

    I'm still trying to wrap my head around Paul's response. It is kind of a mind warp for me, I'd drilled into my head that you can't create an instance of an interface, but I sort of understand what he's saying.

    I'm going to try to trace back to getThisInfo()'s implementation as I need to understand something about the data that's being returned.

    Thanks again!
    13 years ago
    My first post!

    I am an intermediate-level programmer at best (passed SCJA and studying for SCJP)... I am looking at some code at work that is confusing the heck out of me, it appears that it is creating an instance of an interface and then calling interface methods (that i can't find the implementation for).

    This is the line that is confusing me:


    eUser is argument to the method as an interface type as well (iEuser eUser).

    So it appears to me that eMember is being created via a cast of an IUser interface to an IMember interface.

    But a few lines later, methods are being called that are defined in the IMember interface (via eMember.getThisInfo() references [example syntax]).

    I can't figure out where the implementation for getThisInfo() is, I can see the abstract method declaration in the interface but how is it getting implemented?

    Any hints as to what I'm not reading right??

    13 years ago