logins and sessions
can someone please give me some examples of code for jsp login page.
thanks in advance.
[228 byte] By [snabi] at [2007-11-15 21:32:17] 
what is the best way to implement a login page in jsp ? i want to use sessions but can this be done without using a bean ?
can someone please give me some examples of code for jsp login page.
thanks in advance.
# 1 Re: logins and sessions
You can use the Session object in your JSP without using beans, but what do you want to use it for? You won't get very far with JSP without using beans...Dave
To email me remove '_spamjam' from my email address
dlorde at 2007-11-10 2:43:25 >
# 2 Re: logins and sessions
Sure you will :)Jsp-Beans are pretty useless things. In a purely Java environment (ie only Java developers) then they're a bit of a waste. The developers can create a much better system.
In an environment with lots of web designers, then custom taglibs are very tempting. They hide things better than beans, which are just data-containers. Equally, the jsp-bean is like a custom taglib, it's just fairly simple.
Beans are a nice way of hiding objects in the session without explicitly pushing and pulling.
Though I suspect the questioner is trying to focus on sessions before focusing on beans.
Bayard
bayard@generationjava.com
http://www.generationjava.com
Brainbench MVP for Java
http://www.brainbench.com
bayard at 2007-11-10 2:44:36 >
# 3 Re: logins and sessions
The best way would be to hook up to some form of standard UserManager code. I'd imagine this would be coded as a Servlet controller.
For the simplest jsp login page, have a simple html form which submits to a jsp. Said jsp looks at the request.getParameter("password") and rr.
Check against a hardcoded user/password and then if it's true,
session.setAttribute("user",request.getParameter("user)) and redirect to one page,
else redirect back to the login form page.
Admittedly that's very simplistic. Next steps are to think about where the user data comes from, ie) DB. authentication/security. Having a central servlet so that when people try to hit a 'secure' page, and they don't have a "user" in their session, then you throw them back out. Putting a real User object in the session rather than a string username.
Bayard
bayard@generationjava.com
http://www.generationjava.com
Brainbench MVP for Java
http://www.brainbench.com
bayard at 2007-11-10 2:45:32 >
# 4 Re: logins and sessions
You can certainly develop a trivial JSP application without using beans, but I really don't see how you can sensibly avoid them in a non-trivial application. How will you pass session data around? How will your business logic be managed? how will you manage your database access? Are you going to avoid using beans in your custom tag libraries?I remain totally unconvinced ;-)
ISTM beans, in particular Javabeans & EJBs, are the backbone of any serious J2EE application.
YMMV...
Dave
To email me remove '_spamjam' from my email address
dlorde at 2007-11-10 2:46:37 >
# 5 Re: logins and sessions
Couple of points, 1) JSP applications existed long before EJB. They also existed before the jsp:useBean etc attributes. EJB is a pretty poor solution for 90% of the web-sites it's touted on. The distribution concept of EJB is not needed for small to medium websites, and the poor performance of EJB containers, plus the equally poor object skills of many of the EJB coders (it was marketed at database programmers) mean that the nice parts of the EJB design have mainly been wasted. On paper EJB is fair, to nice, in reality it's an immensely abused, poorly used system.
2) Our definition of Bean is being pretty vague here. By bean I mean the JSP bean tags. They're limited to dealing with primitive/String types. Until Sun get their standard taglib out the door, they have no iterating concepts. And when that does happen, it will just create a new programming language that at first web designers will be expected to handle "cuz it looks like HTML", and then people will realise the developers have to use as web designers generally fall over at concepts like nested iteration.
3) To address some of your questions. Passing session data around, there's a perfectly good session object to be used :) Database access, GAH. Database access belongs nowhere near jsp-beans. Jsp-beans are at a high level in terms of tiers, database access should be a long way from this. This is somethign good that EJBs do, but any other good solution will have the same feature. And did, long before EJB. Avoid beans in custom-tags, well certainly. Custom tag libraries replace the jsp-bean. Business-logic will continue to be a management thorn. A bean doesn't manage business logic well. The strict java-bean spec shows that a bean is just a data holder, so any business logic can only happen when data is accessed/set. The concept of set/get is not usually a good match to most bits of business logic. Jsp-beans just give you a different way to stick a random object in the session.
I agree that EJBs and Javabeans are the backbone of any serious J2EE application. That's the definition of a J2EE application pretty much. However, that says nothing about the inadequacies and overcomplications of the J2EE architecture. EJBs do not fit the area that they have been marketed to, and "Javabean" has become an abused, mis-used piece of technology.
Maintaining Javabean standards is very important in an application. *duracells ready for recharge*
Bayard
bayard@generationjava.com
http://www.generationjava.com
Brainbench MVP for Java
http://www.brainbench.com
bayard at 2007-11-10 2:47:33 >
# 6 Re: logins and sessions
1. We have found EJBs to be an excellent solution for our web applications. That they can be used incorrectly or inappropriately or just badly is no more a criticism of EJBs than of any other programming technique or library. Poor programmers or poorly trained programmers produce poor designs and poor code. If you're writing object-based systems you need object-based skills. As for performance, obviously it depends to some extent on the containers, which are improving, but in fact, queries to EJBs may often outperform direct JDBC SQL queries due to caching of EJB data by the container (I have found this to be true for some of our applications running on the Weblogic server). Figures I have seen recently (again for Weblogic server) indicate that the choice of JVM is important (e.g. IBM's JVM and Sun's 1.2.2 JVM can outperform Sun's JDK 1.3+Hotspot by 7 or 8 times in some situations. However, the figures indicate that for typical web shopping/catalogue applications, given a moderately competent design and adequate web server resources, the performance bottleneck is generally at the database (based on Oracle). Improving the database server hardware and tuning the database generally has a greater potential for improving performance of such sites under heavy use than tweaking the application code.2. OK, when I see bean, I take it to be the generic 'bean' from which Beans, JavaBeans, EJBs and others are derived (basically a class with default constructor and getXxx() and setXxx() for properties). JSP bean tags (jsp:usebean et al?) are certainly limited, but there are several libraries out there (e.g. Apache's Jakarta 'Struts' tag libraries) that support HTML controls, templates, iteration, logic, and bean properties, creation, and output, giving great flexibility... Most of our web pages now contain no Java scriplets, and very little HTML. Just because it doesn't come directly from Sun, doesn't mean it's no good, and coming from Sun doesn't make it a standard (after all, Java is proprietary, there is no recognised Java standard such as exists for C, C++, COBOL, etc).
3. My point was what will you put into the session object if not some kind of bean? As you say, database access should be handled by intermediate layers of code. Typically these will consist of various kinds of beans, often JavaBeans and EJBs, distanced from the application-specific JSP/servlet code by intervening layers of application and business logic beans (typically JavaBeans).
ISTM many of these arguments arise out of semantic problems relating to the somewhat ill-defined 'bean' lexicon...
Dave
To email me remove '_spamjam' from my email address
dlorde at 2007-11-10 2:48:30 >
# 7 Re: logins and sessions
I agree on the ill-defined bean lexicon. My initial statement was against the jsp-bean concept. Not beans in general.To answer each of your points:
1) An object-oriented caching system should severely out-perform a database. My issue is that the areas EJBs are marketed at are unable to use this. Putting an EJB system above an existing database is useless for example, as the database is the master data, and not the java application. So people are forever going under the EJB tier with tools like Crystal Reports and TOAD. Weird that Hotspot can be outperformed so heavily, I would have said it should be the other way around, for a web application, hotspot is meant to be the major power. Until EJB allows containers to run without distributed concepts, it's a heavy architecture for web-applications. Most can happily run on a single machine.
2) Yep, struts is nice. Sun's lack of open-source involvement means that the stuff coming from Apache and others is of a far higher quality than the 'standard's that Sun are pushing out. Bean usually means a generic bean to me, except in specific contexts, such as this thread's start and heavily ejb'd threads.
3) I'm not convinced by the idea of storing lots of objects etc in a Session. My architecture preference is for the 'web' layer to be untyped, while the business layer and below is typed. So access to data is through stringified IDs. Any caching of objects for performance sake are dealt with by code lower down, any stateful concepts are just dealt with by temporary business objects.
Bayard
bayard@generationjava.com
http://www.generationjava.com
Brainbench MVP for Java
http://www.brainbench.com
bayard at 2007-11-10 2:49:33 >
# 8 Re: logins and sessions
Weird that Hotspot can be outperformed so heavilyIndeed, but I have to emphasise, this was for only some applications (I got no details of the differences between the apps, but it seems that there were no obvious indicators). In most cases, it performed better than Sun's JVM 1.2.2, but not as consistently as IBM's JVM. Hotspot seems to have idiosyncratic caching and optimization algorithms that can be very effective, but can also perform poorly in a few situations. The conclusion was that to be certain of getting the best performance, all available (& suitable) JVM's for the platform/webserver should be tried.
I get the feeling that the core of Struts and associated developments may be used or endorsed as part of Sun's eventual custom taglibrary releases... there seems to be some close collaboration with Sun's team.
I wouldn't store lots of objects in a session, but it is a simple and easy way to pass value beans to the JSP for display, and is ideal for accumulation of limited session-scope data that may be abandoned (e.g. shopping trolley, or user preference data).
Dave
To email me remove '_spamjam' from my email address
dlorde at 2007-11-10 2:50:34 >
