• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Inheritance Question (I think)

 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying to implement a class that extends HttpServletRequestWrapper and use it in place of the HttpServletRequest object (interface, whatever) that is being used currently in my application.
Lets say my class is called MyRequestFilter and it extends HttpServletRequestWrapper.

I quickly found out that I could not cast from MyRequestFilter into HttpServletRequest.
So I had MyRequestFilter implement HttpServletRequest and I was able to cast correctly.

The problem is, I had to implement all of the methods defined by HttpServletRequest even though I don't really need them (at least right now). So for now, I just created stub methods that don't do anything but return null for the methods I don't care about.

I thought it would be better to have the stub methods call the super class's methods but they aren't visible for some reason. If HttpServletRequestWrapper has to implement HttpServletRequest's defined methods, why aren't the those methods available to my class that extends HttpServletRequestWrapper? My class is in a different package than HttpServletRequestWrapper but I believe the methods all have public access modifiers.

 
Sheriff
Posts: 14691
16
Eclipse IDE VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I quickly found out that I could not cast from MyRequestFilter into HttpServletRequest.


Why ? HttpServletRequestWrapper already implements HttpServletRequest.
 
Mark Williams
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's exactly what I thought.. I got a class cast exception at runtime until I made my subclass implement HttpServletRequest though...
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mark,

If your class extends HttpServletRequestWrapper and implements HttpServletRequest, the compiler will not force you to implement the methods again, since the base class already implements them. It sounds like something went wrong -- maybe your class wasn't really extending HttpServletRequestWrapper?

 
Mark Williams
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks. Just to confirm, if my super class already implements an interface, my class should automatically implement that interface as well? Now that I know the rules, I will try to figure out what is wrong with my class.
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd also add that calling something a "filter" in servlet-land when it's not actually a filter is a little misleading. Filters are a specific, defined thing--perhaps consider renaming it.
 
Mark Williams
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I figured out my mistake. Even though I am embarrased, I'll give the details in hopes that it might help someone else out in the future... I created my new class in Eclipse and I made a typo in the new class dialog. Instead of extending HttpServletRequestWrapper, I accidentally extended ServletRequestWrapper and I didn't notice in the generated constructor that it was taking ServletRequest as the parameter instead of HttpServletRequest. So once I changed my class to extend the HttpServletRequestWrapper superclass everything worked exactly as we thought it should.

Thanks for the help.
 
Mark Williams
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

David Newton wrote:I'd also add that calling something a "filter" in servlet-land when it's not actually a filter is a little misleading. Filters are a specific, defined thing--perhaps consider renaming it.



I will do that. Thanks.
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mark Williams wrote: I created my new class in Eclipse and I made a typo in the new class dialog. Instead of extending HttpServletRequestWrapper, I accidentally extended ServletRequestWrapper



Cool! Sometimes our tools fail us -- or they are so impolite as to do what we ask for, rather than what we mean. Happens to everybody.
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Over and over, sometimes :/ My favorite is accidentally importing the wrong class, which is the same name as the one you actually want, then wondering why none of its methods autocomplete.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic