• Post Reply Bookmark Topic Watch Topic
  • New Topic

Can you get rid of servlets and only use filters?

 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here we have an web app which only uses filters and jsp's, but no servlets.
I was wondering if this is a proper way to do this. Or their performance issues or other drawbacks
by using only filters.

For example i read that the servlet container only instantiates one filter instance per filtermapping/url.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No problem there.

Of course, you are using Servlets - you've just written them using JSP markup.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is rather weird. I see no advantage of doing things that way either except to make it confusing and, well, just weird.
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:It is rather weird. I see no advantage of doing things that way either except to make it confusing and, well, just weird.

All the authentication, xslt processing etc is done in filters and then forwarded to jsp's.

Weird? I thought the same, but I couldn't find any valid reason why the developer shouldn't have done this. That's why I'm asking it here.

Are there any disadvantages for example because of the fact that only one filter instance is instantiated?
 
Paul Clapham
Sheriff
Posts: 21872
36
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Apart from the filter aspect, there are a lot of people who use only JSPs and no servlets. This usually corresponds to a mess of scriptlets jammed into JSP code. I've never understood why you would want to do this, debugging those things is like trying to drive while wearing boxing gloves.
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:Apart from the filter aspect, there are a lot of people who use only JSPs and no servlets. This usually corresponds to a mess of scriptlets jammed into JSP code. I've never understood why you would want to do this, debugging those things is like trying to drive while wearing boxing gloves.


I agree with this. Though i won't say that the code is a mess only the endpoint of the request is not a servlet but a filter.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The mess comes on the JSP side: what do the JSP's look like? Are they filled with scriptlets?

Filters were designed specifically to wrap requests--like AOP for requests. They're not intended to be used for generic business logic normally encapsulated in services and used by servlets (or equivalent). I guess they *could* be, but that would be somewhat counter to the intent, IMO.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am in agreement with David. Filters are intended to be used for cross-request purposes that are orthogonal to the purpose of the requests themselves (authentication, AOP, compression, etc)

You can use the back of stapler to drive tacks, but it's not the purpose for which the tool was intended.
 
Kerry Wilson
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dennis Zandvliet wrote:
Bear Bibeault wrote:It is rather weird. I see no advantage of doing things that way either except to make it confusing and, well, just weird.

All the authentication, xslt processing etc is done in filters and then forwarded to jsp's.

Weird? I thought the same, but I couldn't find any valid reason why the developer shouldn't have done this. That's why I'm asking it here.

Are there any disadvantages for example because of the fact that only one filter instance is instantiated?


Only one servlet is instantiated. Personally, I wouldn't dismiss it as architecturally flawed. It's an interesting approach though.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Without a deeper understanding of what the OP is actually referring to it's hard to say. If filters are being used *as* servlets then I guess I *would* consider it "architecturally flawed," by definition.

I just can't come up with any compelling reason to ignore the existing mechanism, duplicate some servlet functionality in a class that doesn't already have it, and so on. I'm happy to be shown why it's a good idea, however.
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kerry Wilson wrote:
Personally, I wouldn't dismiss it as architecturally flawed.


But that's the problem with this. When i discussed this with the developer, i couldn't come with any other reason then "it's architecturally flawed".
That's why i posted this question here because i would have expected stronger arguments.. :-)


Bear Bibeault wrote:
You can use the back of stapler to drive tacks, but it's not the purpose for which the tool was intended.

Although I do understand you're point i don't agree with you're comparison, because it's obvious that a stapler will do bad job in driving tacks, but until now it's not obvious for me that servlets will do a better job in this case?
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you describe the system more or provide a skeleton example?

i would have expected stronger arguments

Can't argue something that's been presented with essentially no details.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!