aspose file tools*
The moose likes Servlets and the fly likes using jsp in the background Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "using jsp in the background" Watch "using jsp in the background" New topic
Author

using jsp in the background

joshua k
Greenhorn

Joined: Nov 03, 2000
Posts: 13
i have used jsp for performing background jobs on the weblogic server however my manager is not convinced!! here's the justification.i would like opinions on this please!!!
criticism WELCOME
(I HAVE USED JSP'S TO DELEGATE THE FUNCTIONS OF JNDI LOOKUP TO EJB AND INITIALIZING PRESENTATION JAVA BEAN)
THE USE OF JSP FOR NON VISUAL PURPOSES AND FOR BACKGROUND TASKS ON THE SERVER IS UNCONVENTIONAL AND NOT LIKELY AN IDEA TO BE ACCEPTED EASILY.
AS SUCH THE THUMB RULE FOR CHOOSING BETWEEN A SERVLET OR A JSP IS THAT WHENEVER THERE IS ANY SERVERSIDE COMPUTATIONAL TASK �CHOOSE A SERVLET AND WHENEVER THERE IS PRESENTATION STUFF REQUIRED �CHOOSE A JSP.
THE MOST COMMON SENSE CHOICE FOR A DELEGATE WOULD BE A SERVLET FOR OUR DELEGATE AS SUCH.
I PROPOSE USING JSP�S FOR THE DELEGATE ,ALTHOUGH UNCONVENTIONAL THIS HAS SOME SOUND REASONS MENTIONED BELOW.
KEEP IN MIND THAT JSP TECHNOLOGY IS RELATIVELY NEW
1.WITH REF TO THE PROJECT.
2.AS VS USING A DELEGATE CLASS OR SERVLET
1. SIMPLICITY OF CODING
2. READY MADE TAGS THAT ARE AVAILABELE FOR USE
3. TAGS MOST LIKELY TO BE USED ARE USEBEAN AND THE CORROSPONDING SET/GET TAGS.
4. FORWARD TAG GIVES THE CAPABILTY TO FROWARD THE REQUEST BACK TO THE CONTROLLER SERVLET OR TO A SERVLET/JSP THIS GIVES A LOT OF FLEXIBILTY AND THE TAG IS COMARITIVELY EASIER TO USE THAN CALLING A REQUEST DISPATCHER.
5. NO NEED TO COMPILE!! AS VS A CLASS OR SERVLET.
6. CHANGES CAN BE MADE TO THE CODE AND TESTED STRAIGHTAWAY WITHOUT COMPILING AND REPLACING ETC.
7. CONSIDERABLY EASIER TO CODE AND UNDERSTAND COMPARED TO A SERVLET.
8. INSTANCE OF THE GENERATED SERVLET AVAILABLE VS INSTANTIATING A CLASS FROM THE SERVLET AND CALLING METHODS ON IT.
9. IMPORTANT!!- THERE IS THE POSSIBILTY OF FACTORING OUT COMMON FUNCTIONS AND DEVELOPING CUSTOM TAGS IN THE FUTURE.THIS WOULD BE A SIGNIFICANT IMPROVEMENT VS A CLASS OR SERVLET.
10. VS A CLASS THERE WOULD BE A PERFORMANCE IMPROVEMENT AS AN EXISTING INSTANCE IS AVAILABLE,ALSO THERE IS A CLEAN SEPERATION OF CODE FROM THE CONTROLLER WHO IS RESPONSIBLE FOR ROUTING SERVICES MAINLY.
11. COMPARITIVLY NEW TECHNOLGY AS COMPARED TO SERVLETS AND WHICH IS UNDER ACTIVE DEVELOPMENT.
12. THE PROOF OF CONCEPT PROGRAM HAS BEEN TESTED AND FOUND OK.

------------------
josh
[This message has been edited by joshua k (edited February 06, 2001).]


josh
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12787
    
    5
Hint - all upper case typing is seen as yelling. Most people don't like to be yelled at.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
THE MOST COMMON SENSE CHOICE FOR A DELEGATE WOULD BE A SERVLET FOR OUR DELEGATE AS SUCH.

So far I wouldn't disagree, apart from the yelling that is
I PROPOSE USING JSP�S FOR THE DELEGATE [...]
1. SIMPLICITY OF CODING

If you there is no presentation component, JSPs are generally not simpler to code. That's the whole point, isn't it? This is not a reason, rather a conclusion that should follow from the rest of what you're saying.
2. READY MADE TAGS THAT ARE AVAILABELE FOR USE

Tags like...? Most are tag equivalents of relatively simple Java code. Just some sugar, mostly relevant if you're working in a tag based environment anyway.
3. TAGS MOST LIKELY TO BE USED ARE USEBEAN AND THE CORROSPONDING SET/GET TAGS.

The sugar category: request.getSession().getAttribute("bean") isn't that hard to use, as are method calls. If you're concerned about the effort of instantiating the bean in case it's not been created yet, it will probably take you ten minutes to write a little HttpServlet subclass with a getBean(String id, String className) method, or a private method in your servlet.
4. FORWARD TAG GIVES THE CAPABILTY TO FROWARD THE REQUEST BACK TO THE CONTROLLER SERVLET OR TO A SERVLET/JSP THIS GIVES A LOT OF FLEXIBILTY AND THE TAG IS COMARITIVELY EASIER TO USE THAN CALLING A REQUEST DISPATCHER.

Instead of <jsp:forward page="/page"/> you have to write getServletConfig().getServletContext().getRequestDispatcher("/page").forward(request, response). Hmmm, it's a longer string. But even the search and replace function of my word processor could be able convert the two. If it bothers you, stick it in a little method.
5. NO NEED TO COMPILE!! AS VS A CLASS OR SERVLET.
6. CHANGES CAN BE MADE TO THE CODE AND TESTED STRAIGHTAWAY WITHOUT COMPILING AND REPLACING ETC.

Of course they cannot be tested without compiling. Only, it's the application server does the compiling for you. So what? Your development environment will be happy compile the servlet into the classpath of your server, just as quickly, at the touch of a button. It will also take your editor straight to compiler errors, shortening the debug cycle w.r.t. a jsp. Also a servlet will give you decent runtime error messages, not always the case with jsps.
If you're not using a Java development environment then better tools would be far more helpful than switching to jsps.
7. CONSIDERABLY EASIER TO CODE AND UNDERSTAND COMPARED TO A SERVLET.

I've seen my share of jsps chock full of code and I really, really beg to differ here. In many ways jsps encourage sloppy coding. It doesn't really encourage the use of member functions to manage complexity. All your exceptions are caught for you making harder to create a robust application--I don't know how it is with you but the compiler often saves me from forgetting an error condition.
One vendor whose software I work with have implemented their controllers in JSPs. Bad move. They're now working on moving the whole thing into a servlet that will be several times more flexible, maintainable, and extensible.
8. INSTANCE OF THE GENERATED SERVLET AVAILABLE VS INSTANTIATING A CLASS FROM THE SERVLET AND CALLING METHODS ON IT.

??? It's the jsp where I would encourage you to stuff the real code into a separate Java class.
9. IMPORTANT!!- THERE IS THE POSSIBILTY OF FACTORING OUT COMMON FUNCTIONS AND DEVELOPING CUSTOM TAGS IN THE FUTURE.THIS WOULD BE A SIGNIFICANT IMPROVEMENT VS A CLASS OR SERVLET.

I don't see how tags are an improvement over classes (they're used in different contexts; only in the context of a markup-based jsp is a tag library a Good Thing). And is it any harder to factor your code out of a jsp into a tag than it is to factor it out of a servlet into a tag? The jsp tags you used are likely to make it harder if anything.
10. VS A CLASS THERE WOULD BE A PERFORMANCE IMPROVEMENT AS AN EXISTING INSTANCE IS AVAILABLE,ALSO THERE IS A CLEAN SEPERATION OF CODE FROM THE CONTROLLER WHO IS RESPONSIBLE FOR ROUTING SERVICES MAINLY.

Wrong end of the stick entirely. The performance of a jsp is never, ever, better than that of a servlet. After all, a jsp is a servlet.
The controller argument is a reason why you should not integrate your code with the controller. It is not a reason to choose for either a jsp or a servlet.
11. COMPARITIVLY NEW TECHNOLGY AS COMPARED TO SERVLETS AND WHICH IS UNDER ACTIVE DEVELOPMENT.

Servlets are under active development as well (v2.3 under way). As mentioned above a jsp compiles down to a servlet anyway. This argument is really a non starter.
12. THE PROOF OF CONCEPT PROGRAM HAS BEEN TESTED AND FOUND OK.

That doesn't mean it's the right solution though...
- Peter
joshua k
Greenhorn

Joined: Nov 03, 2000
Posts: 13
thanks peter food for thought!!!
and i aint yellin now.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: using jsp in the background