Re: How should i proceed with
- Original Message - From: "Dror Matalon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 29, 2002 7:16 AM Subject: Re: How should i proceed with Hi, -- CLIP > > 1. IsUserInRole() is about authorization, so that won't solve > > the problem at all, I fear. With this method, you can check > > what a user is allowed to do. You can't check if the user > > tries to log in twice, regardless of the authentication > > scheme used. > > No true. The way "BASIC" authentication works, you set things up > so that the user can't log in twice. Now this is interesting. How would one 'set things up' so that a user can't log in twice using declarative security? I may be dumb, but I just didn't find any fitting mechanism for that. Considering realms: I always had the impression that realms were basically a (container-specific) means of telling Tomcat where to look for the credentials and map usernames to roles. I can't see why using BASIC authentication makes any difference in this context. In fact, even re-reading the Tomcat realms how-to didn't help. I just can't see what roles may have to to with the number of logins a user may perform concurrently. But obviously I'm wrong or missing something. Would you care to explain the details? -- CLIP > While this might be true, most modern day web applications are > almost useless if they can't trust their database to be up. On top > of that, most modern databases are at least as reliable as the > servlet engine (after all dbs have been around for a lot longer), > so your database uptime's going to be much higher. Specifically > in our case, I find our database, Postgres, to be quite a bit > more solid than Tomcat. YMMV. We even use the 'unbreakable' one, but that's not the point. If you store session state information in a database - which may be a necessity in distributed applications -, you'll also have to have a means to keep the database in sync with the web tier. Otherwise, if the web tier crashes, the 'active' flag will still be there, effectively keeping the user out. @Ravi: http://www.stardeveloper.com/articles/display.html?article=200901&page=1 http://www.stardeveloper.com/articles/display.html?article=2001112001&page=1 How to implement a global UserRegistryBean stored in the ServletContext (application scope) is also explained in detail in the O'Reilly JSP book. You can easily adapt the mechanism described there to not storing a token in the session scope after succesful authentication, but maintaining a Collection of loginNames in ServletContext instead, using a listener in place of a filter and the like. If you don't have the book, you might still want to look at the example sources, available from http://www.thejspbook.com/download.jsp. -- Chris (SCPJ2) === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: exit from the current loop
Honestly: read a book. -- Chris (SCPJ2) - Original Message - From: "karthik s" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 23, 2003 12:52 PM Subject: exit from the current loop > hi all, > Is there any thing to exit from the current loop in Java as we hav > break in c++. > Rgds, > Karthik === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: exit from the current loop
Some more guesses? http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#6 842 -- Chris (SCPJ2) - Original Message - From: "Francisco Manuel Martínez Suárez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 23, 2003 1:00 PM Subject: Re: exit from the current loop > Yes, but it will go to the condition to check it again. This may cause to be > in the loop again if the condition is true. > > Regards > Fran === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Oracle-JDBC Driver For Linux platform
Hm. From Oracle TechNet? Check out otn.oracle.com :) -- Chris (SCPJ2) - Original Message - From: "S Senthil Raja" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 19, 2003 5:17 PM Subject: Re: Oracle-JDBC Driver For Linux platform > Sir, > From where I will get a free Oracle Driver in JAVA (Linux) > > >-thanx. > >From: Amit Ghaste <[EMAIL PROTECTED]> > >Reply-To: A mailing list about Java Server Pages specification and > >reference <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Oracle-JDBC Driver For Linux platform > >Date: Sat, 15 Mar 2003 12:33:45 -0800 > > > >u can fing one at www.oracle.com > > > >-Original Message- > >From: A mailing list about Java Server Pages specification and reference > >[mailto:[EMAIL PROTECTED]]On Behalf Of S Senthil Raja > >Sent: Tuesday, February 18, 2003 7:00 AM > >To: [EMAIL PROTECTED] > >Subject: Oracle-JDBC Driver For Linux platform > > > > > >sir/madam, > >I'm working in Linux platform.I want to connect Oracle driver in this > >platform.I need to know where Oracle driver is available to connect Oracle > >Db using JAVA. > >-thanks. > > > > > >_ > >The new MSN 8: smart spam protection and 2 months FREE* > >http://join.msn.com/?page=features/junkmail > > > >=== > >To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > >JSP-INTEREST". > >For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST > >DIGEST". > > > >Some relevant archives, FAQs and Forums on JSPs can be found at: > > > > http://java.sun.com/products/jsp > > http://archives.java.sun.com/jsp-interest.html > > http://forums.java.sun.com > > http://www.jspinsider.com > > > >=== > >To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > >JSP-INTEREST". > >For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST > >DIGEST". > > > >Some relevant archives, FAQs and Forums on JSPs can be found at: > > > > http://java.sun.com/products/jsp > > http://archives.java.sun.com/jsp-interest.html > > http://forums.java.sun.com > > http://www.jspinsider.com > > > _ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > === > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". > For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". > > Some relevant archives, FAQs and Forums on JSPs can be found at: > > http://java.sun.com/products/jsp > http://archives.java.sun.com/jsp-interest.html > http://forums.java.sun.com > http://www.jspinsider.com > > === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: displaying 5th record
Am Donnerstag, 5. Juni 2003 19:28 schrieb Amit Ghaste: > rownum is assigned before the order by is performed > > therfore the retured rows wont the the last 5 rows of the database. > but u will get the first five rows which are then ordered by sal or > row id ... which wont change.. > > ROWNUM IS ASSIGNED PREVIOUS TO ORDER BY > > i would say use a subquery to get the max(ROWID) + the 4 rowids > lesser than that. then find the max of salary on them Just to add that 'rowid' ist a pseudo-column and string-typed, so keep heed of possible string-sorting pitfalls at least. Apart from that, Oracle rowids tend to change with each server version. Generally, this pseudo column exists for the sole purpose of exactly identifiying a certain database row, but doesn't help otherwise. In particular, the shortcomings of an improper database design can't be 'retro-healed' via using rowid, and it can't and shouldn't be used as a replacement in case of a poor database design. In particular, rowid doesn't replace the need for a (usually sequence-generated) ID column or timestamps and shouldn't be misused this way. Rownum, on the other hand (available since 8i) works on the result set delivered by the query; it may be applied before or after the ORDER BY clause, but order makes no real difference if there are only SQL aggregate functions involved which always deliver a single result. > Hope that helps > Amit HTH, -- Chris (SCPJ2) -- CLIP! === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Large vector filling select box
Am Freitag, 20. Juni 2003 19:23 schrieb Yee, Richard K,,DMDCWEST: > Brian, > Have you tried different browsers? It might be a browser limitation. > You might want to re-think your user interface design. Putting more than 30 items in a combobox might not be the best idea to think of, but in this case, *countries*. Hm. All sites I know of always present the country list this way. Hm. Anyway: if it's a browser limitation, you can instantly tell by looking at the HTML sources. If the missing items are there, the browser is the culprit. If not, something unexpected happened in-between. Given that Vector is thread-safe, the code that puts it in (request | page?) scope might be not. But one thing does strike me here, still, as appparently the countries list is being read from the back end facade each time the page is displayed. There could be reasons for doing so, but if it's just a dumb list of all countries known so far: what hinders you to from putting the Vector into application scope upon initialisation of the whole thing and leaving it there until either the server is rebooted or yet another rebellion is successful? If you just read from the list, an un-synchronized - read: faster - Collection like ArrayList might be fitting the needs as well and might be preferable to Vector in this case, too. HTH, -- Chris (SCPJ2) > Rgds, > > Richard > > > -Original Message- > > From: Brian P Bohnet [SMTP:[EMAIL PROTECTED] > > Sent: Friday, June 20, 2003 10:21 AM > > To: [EMAIL PROTECTED] > > Subject: Large vector filling select box > > > > Hello all, [CLIP!] === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Post a form and popup a window.
Am Dienstag, 15. Juli 2003 20:12 schrieb Ed Ventura:
> That works fine, but I have 3 buttons and I only want to popup a new
> window on 1 of the buttons. All the others should just post the form
> normally. Any ideas?
>
> Thanks,
> Ed.
>
What I usually do is something like this (note: I'm using Struts and
JSTL): I pass the command string to an Action that puts the search
results (or whatever, read: dynamic data ) in request scope and
forwards to a JSP (the View part) that just takes the results and
displays that.
Though I usually tend to steer clear from JavaScript, for popup windows
I found it to be just necessary, so I put something like this into the
originating page:
}
Then, I invoke the Action from that page by something like this:
')">
The Action now talks to the model, does whatever is possible in Java and
adds the results to the request (sorry for the crappy formatting):
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws
IOException, ServletException {
int id =
ServletUtilities.stringToInt(request.getParameter(Constants.SC_PARAM_ID));
CustomerBean cb = PersistenceFacade.getInstance().getUserDetails(id);
request.setAttribute(Constants.SC_CUSTOMER_BEAN_TOKEN, cb);
return mapping.findForward(Constants.SC_SUCCESS);
}
In struts-config.xml, the mapping for the successful scenario finally
forwards to a page that displays the final results. This page just
takes the information passed and displays that in the popup window
created by the JavaScript part (using JSTL), which was invoked via the
link. Should not make any real difference here if you're using POST and
forms instead of mere links or don't make use of Struts at all; even if
you have to deal with several submit buttons, you may tell them apart
from each other because the one the user finally presses ends up as a
parameter (so better keep heed of the 'name' property) in your request.
If you need further help, just send me a mail :-)
HTH,
-- Chris (SCPJ2)
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant archives, FAQs and Forums on JSPs can be found at:
http://java.sun.com/products/jsp
http://archives.java.sun.com/jsp-interest.html
http://forums.java.sun.com
http://www.jspinsider.com
Re: Form bean issue- not in master configure file ( need help!!!)
Am Mittwoch, 13. August 2003 20:58 schrieb Yan Gong: > Hi Struts experts. Hi Yan, > I have a problem with formbean. I created a search form by extending > org.apache.struts.action.DynaActionForm, The strange things happend > was when I filled the search options in the search page from > differnce machine(differet IE ),It shared the same search options. > It seems server only create one > instance of the search form. the scope of the form bean define in > configure file is session scope. The configure file is not master > configure file, we are doing plugin, so this happened when forms > configure in another configure file, If I put the search form > configure into struts-config.xml, It works fine, so anyone knows what > happend with mutiple configure files.I thought it should no > differece, Though I'm neither using DynaForms nor Plugins (Tiles?) and don't have any real experience with those, my understanding is that Struts puts the fom bean into either request or session scope. The latter, which seems to be your case as well, enables one to use information previously entered in one request for a second one, but AFAIK, everything's just limited to either session or request scopes. The problem you describe, though, would imply that the form bean gets saved in application scope, and Struts just doesn't do that, and that definitely wouldn't make any sense, anyway. So what I would check out would be as follows: 'Different IE instance' is not necessarily equal to 'different machine'. Obviously, for some reason, both instances somehow seem to share the same session. Find out what might be the reason behind this and test with a 'real' different machine for comparison. Note that the session information is kept on the client via either cookies or encoded URLs. Check if you're really using session cookies or permanent ones. Furthermore check - in case of URL encoding - if the URLs your'e using contain the same session info on the 'second machine' (the cryptic 'jsessionid' string appended to the URL: is it the same on both 'machines'?). Or: is your second browser instance sharing the same session? If you just press CTRL-N, this doesn't mean you're really creating a different browser instance. The general thought behind this is: Struts doesn't share information between different sessions, so in fact you seem to be dealing with two browser instances acessing the same session for some reason. This is very likely no Struts problem, but something related to your individual setup. Really: test this from a 'physically' different machine first and see if the problem still arises. If it does, we may go on. > Thanks a lot. Never mind :-) > -Yan -- Chris (SCPJ2) === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Vector needs include in Tomcat?
Am Montag, 18. August 2003 12:16 schrieb Jan Arenö: > Hi > > Im trying to move my jsp pages from an Oracle 8i server (with apache > and JServ (Think this is what comes in the default installation?) ) > to an Tomcat server (4.1.27). > Tomcat wants me to include the Vector class, but Oracle didn't, how > come? I can understand why I have to do this, but why didn't I have > to before? Is there a way to include this on all of my pages (I use > it quite alot) from any conf file in tomcat In Java, you generally have to import everything except the java.lang package, so if the OSE (always reminded me of 'Pigs On The Wing' (a Pink Floyd title) somehow; you'll know why) behaved otherwise, it's been kind of a a side effect. So I'm afraid you'll have to retro-fit your pages with java.util.* import statements on this occasion. There is no 'server switch' I know of, and considering that Oracle will drop the OSE in future releases anyway, while OC4J (the Orion server || iAS 9i J2EE tier) is strictly J2EE- (and Java-) compliant, this behaviour is just what's to be expected. Note that the JSTL doesn't need explict imports of the Collection classes and removes several other common pains when dealing with the web tier, so it might make sense to upgrade to this state-of-art technology - if possible -, too. The JSTL makes so many things so much easier, but acknowledging its true value requires hands-on experience with it and possibly a design change. But then... > //Jan HTH, -- Chris (SCPJ2) === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Why use servlets?
Am Mittwoch, 27. August 2003 17:21 schrieb Campano, Troy: I think Dan Wells already mentioned all the necessary aspects and though we're using Struts instead of Tapestry, there's nothing to object. Indeed, it's more kind of an architectural issue, as JSPs get compiled to servlets anyway. Following the MVC2 design idiom (among others), JSPs are best for the View role and should be as dumb as possible IMHO, while the Front Controller -> Service To Worker parts (which don't directly present anything on the client tier) are generally better suited for servlets. This part is more or less handled by Struts already, which allows for declarative configuration via an XML file and relieves some of the major pains of dealing with the HTTP protocol, too. Struts delegates the request to Struts Actions, which are basically normal Java classes forming the interface to the Model. 'Below' Struts and the web tier, there usually comes a lot of additional complexity plus several additional layers, and things should no longer be web-related in any kind at this stage. Note that the lifespan of Business Logic and Persistence in particular is much longer than that of the web tier which may be gone tomorrow and be replaced by something more powerful, who knows? Apart from that, calling Java classes direcly may lead to significant thread issues, bottlenecks or transaction problems, and I generally wouldn't recommend this approach. Same is true for 'direct-linking' the web tier to EJBs, I'm afraid. HTH, -- Chris (SCPJ2) NB. Note that the existence of JSPs at all stems from the fact that pure servlets proved to be not too well-suited for visual output, but are powerful nonetheless when it comes to other tasks, such as delivering something other than just ordinary text (including HTML, WML and the like). > I'm curious as to what the reason is to use Servlets. > I write straight java class/methods and call them from my JSP. > My business logic goes into these classes. > > JSP handles the interface and handles request/response. > Usually I guess it's a Servlet that handles the request/response but > it seemed to me like an added extra step. > I didn't really see what I was gaining by using a Servlet. > > So I'm curious of what the point of Servlets areis there > something they give you that JSP doesn't? > So I know I'm missing somethingwhy use Servlets? > > Thank you for your responses! > > ~ t r o y ~ > > Troy Campano > IAS Database Management > Liberty Mutual > (603) 245 4092 > [EMAIL PROTECTED] > > > > = >== To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with > body: "set JSP-INTEREST DIGEST". > > Some relevant archives, FAQs and Forums on JSPs can be found at: > > http://java.sun.com/products/jsp > http://archives.java.sun.com/jsp-interest.html > http://forums.java.sun.com > http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: javax.xml.rpc.namespace.QName
Am Montag, 1. September 2003 12:38 schrieb lee hwaying: > I am now starting to code xml using java. > may i know which is the most mimic VB msxml2 package in JAVA? If you mean you want a tree-like representation of XML elements, JDOM may be the best choice. JDOM is neither DOM nor SAX, but provides an object-oriented API to XML files similar to DOM, yet in a Java (ie. language-) specific way. But the same is true for VB, and behind JDOM there are people like Jason Hunter and Brett McLaughlin, that is, some of the heavyweights in this whole direction. > a friend recommend jdom. > I find it quite good but, when using, the tooltip doesn't shows on > NetBeans, even though it compiles nicely/ > > any idea? In NetBeans 3.5, just rightclick on the JDOM package, find the 'Tools' submenu and select 'Update code completions' there. This option existed for a long time in Forte | NetBeans, but was named otherwise in previous releases. In any case, a dialog pops up, you select the appropriate visibility levels for classes | fields | methods and give it a go. NetBeans- based IDEs get their code completion info from a database which has to be (re)generated for new or altered packages. HTH, -- Chris (SCPJ2) === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: JSP testing tool
Am Mittwoch, 3. September 2003 12:25 schrieb Balasubramanian S: > Hi, > > I would like to know any open source testing tools for JSP and > Servlet. What exactly do you mean by 'testing'? Asssuming you're not looking for a JSP debugger (which is integrated in NetBeans and most other IDEs today, Eclipse is AFAIK still an exception to the rule), I'm unclear about whether you mean unit tests (code quality) or load tests. In both cases, I'd look if there's a JUnit module available for your favored IDE (there is one for NetBeans and JDeveloper, at least), and for load testing, I'd look for Grinder 3 on sourceforge.net first if it comes to open source. Note there's an integrated profiler in Oracle's JDeveloper 9i (I think it is called 'Code Coach'), but as that IDE is free for download, but not open source, so it doesn't really match the criteria (plus, this feature requires using the OJVM, and that one only works under Windows and possibly not with a Sun JDK in the 1.4.x line), but otherwise, it's excellent. HTH, -- Chris (SCPJ2) HttpUnit also comes to mind on this occasion, but I don't have any experience with it. > thanks in adv, > Bala > > = >== To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with > body: "set JSP-INTEREST DIGEST". > > Some relevant archives, FAQs and Forums on JSPs can be found at: > > http://java.sun.com/products/jsp > http://archives.java.sun.com/jsp-interest.html > http://forums.java.sun.com > http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
JDeveloper 10g Preview
Hi, just to drop some note that today Oracle released the preview version of JDeveloper 10g (g for 'grid computing'; the Internet obviously seems to have become kind of unappealing in Oracle Marketing's view - even though in the alphabet, it means several steps back ;-) It's available as usual from OTN (otn.oracle com, 230 MB). Well, I downloaded the thing and had a first glance at it. Though it's definitely no lightweight, this is definitely an improvement in all major aspects, and JDeveloper 9i already was a kind of its own to me. It's impossible to mention all the new or improved features here, and the preview obviously has some bugs still (though I must admit I'm running it under Linux and with JDK 1.4.2, which is definitely against all rules), but as far as I can tell from my still limited experiences, the final release will be hell of an IDE. Considering web applications, be prepared for integrated JSTL and visual Struts 1.1 support (like in Struts Studio), automatic deployment to Tomcat versions 4/5 and JBoss (among others), an HTML/JSP designer that really deserves that name now, plus tons of other improvements and helpful features, including subtle things like syntax error highlighting (like in Visual Studio .NET), even in CSS files. Note it's still a preview and not ready for a production environment, but IMHO, there's a real killer Java IDE underway. Let's hope they still distribute it for 'free' when it comes to the final release. -- Chris (SCPJ2) No, I'm not paid for this in any kind :-) === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: JSTL weblogic
Am Donnerstag, 11. September 2003 08:27 schrieb Manoj Kansal:
Hi,
I think I don't really understand what you're heading for. Generally,
it's sufficient to download the JSTL jars (note: JSTL consists
of more than just standard.jar; you may want to consult the
Apache Jakarta site for details), put those .jars into the /lib
directory (the one underneath WEB-INF) of your server,
and that's it. Basically, there's no additional configuration
required, as the .tld files are already contained in the .jars.
If you want to have them separately, you may put the
.tld files in WEB-INF or some other directory (WEB-INF/tld,
for example, as recommended by the specification) and
declare them in web.xml, but that's not a requirement.
One thing to note might be that your taglib references
should look somewhat different in the first case,
resembling something like
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>
This won't really result in a call to the Sun site, but just
tell the resolver that's built into you container how to
map the references in your JSP to a certain taglib.
Considering the CLASSPATH, there generally is no
need for manually including these files the system
classpath in any kind. Taglibs were designed to be
as easy to use as possible for the consumer, and
with JSP 1.2, it became even possible to include
more than one taglib into a single .jar file, but the
specifics are mere details. Microsoft .NET named
his 'xcopy install' and makes a great fuss about
that. In Java, it's just already there. And AFAIK,
even BEA WebLogic is standards-compliant
at this (specification) level.
HTH,
-- Chris (SCPJ2)
> Hi all,
> I am using weblogic 7.0 on NT 4.0 machine.
> I have downloaded standard.jar file required for JSTL.
> I have unzip standard.jar file and retireve all the tld files. I have
> placed tld files in WEB-INF/tld folder. I have added standard.jar
> file in classpath. I have verified that standard.jar file is my
> classpath of startWLS.cmd file and is fine.
>
> following is a sample code where I am using JSTL.
>
>
> <%-- Declare the core library --%>
> <%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
>
>
>
> Please enter your name.
>
>
> Hello !
>
>
> <%out.println("test"); %>
>
>
>
> It gives error mentioned below. It could not locate cannot find tag
> class: 'org.apache.taglibs.standard.tag.common.core.CatchTag' which
> is already there in my standard.jar file. that is already in my
> classpath. Can anyone tell me where I am doing mistake. What else I
> need. I have downloaded standard.jar file from apache site. Do I need
> any other jar file.
>
>
> <11-Sep-2003 11:46:09 IST> <101020>
> <[ServletContext(id=16733562, name=DefaultWebApp,context-path=)]
> Servlet failed with Exception weblogic.servlet.jsp.JspException:
> (line 4): Error in using tag library uri='/WE B-INF/tld/c.tld'
> prefix='c': cannot find tag class: 'org.apache.taglibs.standard
> .tag.common.core.CatchTag'
> at
> weblogic.servlet.jsp.StandardTagLib.tld_jspException(StandardTagLib.j
> ava:1135)
> at
> weblogic.servlet.jsp.StandardTagLib.parseTagDD(StandardTagLib.java:12
> 19)
> at
> weblogic.servlet.jsp.StandardTagLib.parseDD(StandardTagLib.java:1161)
>
> at
> weblogic.servlet.jsp.StandardTagLib.(StandardTagLib.java:221)
> at
> weblogic.servlet.jsp.TagLibHelper.loadTagLib(TagLibHelper.java:315)
> at weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:144) at
> weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java:49
> 82)
> at
> weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java:4820)
> at weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java:4666) at
> weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:2086) at
> weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1872) at
> weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java:1745) at
> weblogic.servlet.jsp.JspLexer.parse(JspLexer.java:959) at
> weblogic.servlet.jsp.JspParser.doit(JspParser.java:90) at
> weblogic.servlet.jsp.JspParser.parse(JspParser.java:213) at
> weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:119) at
> weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:258
> )
> at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:353)
> at
> weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:211) at
> weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:164) at
> weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.
> java:517)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
> pl.java:351)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
> pl.java:445)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
> pl.java:306)
> at
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
> n.run(WebAppServletContext.java:5445)
Re: Struts question
Am Montag, 20. Oktober 2003 15:29 schrieb Jan Arenö:
> Hi
Hi Jan,
> I'm learning Struts at the moment and just finished a very easy
> example. Now when I want to extend it I don't know for sure where to
> put it, or if I have missunderstood something.
>
> I'm also new to taglibs. So i don't know exacly how they work either,
> but I think I start to get a hang of it
>
> I have inputpage with ActionForm and Action-servlets
There is only one ActionServlet. You surely mean Struts Actions?
> On my input page i have 2 fields at the moments, destination and
> type. These fields are validated and errormessages are returned as
> they should etc etc. When validated I go to page2.jsp that writes
> "Hello World"
>
> Ok. Heter is my problem.
> I now want to change my destination from a inputform to a
> selectbox . And I would like to populate it with a
> Vector that I shall get from a database.
First of all: Struts most elegantly supports this via the
tag. You might also want to have a look at the
tag. Both are very flexible. The basic idea is that you populate your
select box with values coming from a Bean. The selected value then
is passed via the property. The Collection itself can
be put in any scope (request, session, application). For static lists,
as may be your case as well, I usually use a Listener to put
everything in application scope when the app starts. Here comes
an code snippet of a very basic listener:
package listeners;
import java.util.*;
import javax.servlet.*;
import PersistenceFacade; // some Singleton DAO class that does
the JDBC part
public class ResourceListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent e) {
Collection coll = PersistenceFacade.getInstance().getSomeList();
e.getServletContext().setAttribute("MY_LIST", coll);
}
public void contextDestroyed(ServletContextEvent e) {
((ServletContext)
e.getServletContext()).removeAttribute("MY_LIST");
}
The Collection itself is usually an ArrayList built from
LabelValueBeans (org.apache.struts.util) as follows
(note: code heavily simplified here for sake of brevity) -
your DAO that does the database access might
look like this somewhere (though I prefer the iBATIS
Database Layer recently, credits to Ted Husted who
pointed me there (www.ibatis.com)):
[..]
Collection coll = new ArrayList();
while (rs.next()) {
b = new LabelValueBean(rs.getString(),
rs.getString());
coll.add(b);
}
return coll;
So you finally have your your list stored in some scope. Now,
in the JSP page, you can just put something like this:
When the users selects something, it ends up in the
'selectedValue' property of your ActionForm. You can
specify a default value ("-1" in this case) by setting
the 'value' property of .
> Earlier (before struts) I would create a bean conn. Then call :
>
> conn.createDBConnection();
If your server allows, don't use DriverManager anymore,
but make use of DataSources and use JNDI to locate
it. Some more code in this direction:
private DataSource getDataSource() {
DataSource ds = null;
try {
Context ctx = new InitialContext();
ds = (DataSource) ctx.lookup(Constants.SC_JNDI_DATASOURCE);
} catch (NamingException e) { log(e.getMessage()); }
return ds;
}
If you have luckily got a DataSource, it's easy to get
a Connection object from that:
private Connection getConnection() {
Connection conn = null;
try {
conn = getDataSource().getConnection();
if (conn != null) {
conn.setAutoCommit(false);
}
} catch (SQLException e) { log(e.getMessage()); }
return conn;
}
Then, it's business as usual.
> Vector myDest = conn.getDestinations(); conn.closeDBConnection();
>
> Where should I now do this? Where should I store the Vector?
No. Though it can be done, you should store the Vector (better
not say 'Vector', as that is implementation-specific, but make
use of interfaces instead, and Vector implements the Collection
interface) apart from the form. You can use any scope you
like, request for 'per-incident' lists, session scope for each
user individually or application scope for all of them. Each
'scope' has a setAttribute() method, so you're free to choose :-)
> In the ActionForm? I thought that it only had references to the
> fields that the user are supposed to submit. The Action class is not
> called until ActionForm is validated, ain't it so?
Exactly. The information *what* is in the list normally comes
from somewhere else. The value the user finally selects ends
up as a property in your ActionForm.
> How should this be done...
>
> Thanks for any help
HTH,
-- Chris (SCPJ2)
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant archives, FAQs and Forums on JSPs can
Re: Struts question
- Original Message -
From: "Jan Arenö" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 21, 2003 1:31 PM
Subject: Re: Struts question
> Thanks for your response, I will get right on it... And ttry to figure
> it out...
> Have some questions though...
No problem.
> I get the idea of the listener, but if you populate it with stuff from a
> database, this would be wrong I guess, since this collection never
> updates (except when you restart you application). So what you do here
> is to create a constant (based on stuff when the aplication starts)...
> Or did I get i wrong?
No, of course - but IIRC I said 'static lists', didn't I? :-)
> If i'm not going to do the listner "thing", since my list must refresh
> from database once and awile... Where do I put the Colloction creating
> code, say this:
> Collection coll = new ArrayList();
> for(int i = 0; i < 10; i++) {
> b = new LabelValueBean("1",1);
> coll.add(b);
> }
> request.setAttribute("MY_LIST", coll);
This depends. If it's a request scope thing that should
be updated on each request, put it in an Action that
puts the Collection in request scope and then forward
to the input page. If it's a per-user thing, I usually
put the Collection in session scope (session.setAttribute())
when the session is initially created, often right after
successful authentication. But you can always add the
list at a later stage or update | replace it whenever it
seems fitting ;-)
> And when I do this on my jsp-page:
>
> labelProperty="label" />
>
> Do "value" and "label" represent a getValue() and getLabel() function in
> LabelValueBean?
Exactly. LabelValueBean is basically a 'convenience' Value
Object that is just there because it's used so often. But you
could take any other Bean as well. Then you would have to
specify which properties should be used for the s
value and description. IIRC you can even omit specifying the
property and labelProperty attributes if the Bean accessors
are named "label" rsp. "value", but I never actually tried.
> Thanks again for your response, cleared up alot in my head :D
/Jan
Cheers,
-- Chris (SCPJ2)
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant archives, FAQs and Forums on JSPs can be found at:
http://java.sun.com/products/jsp
http://archives.java.sun.com/jsp-interest.html
http://forums.java.sun.com
http://www.jspinsider.com
Re: Struts question
Am Dienstag, 21. Oktober 2003 20:55 schrieb jini us: > If you are new to struts I suggest you download > community edition(free)of struts called strutsstudio > from www.strutsstudio.com. Or www.exadel.com. And there's visual Struts support just like in Struts Studio in Oracle JDev 10g Preview as well, just to note here. Still: these are only tools. But no tool shows you how to actually use Patterns or write a well-designed app. When it comes to actually coding, you're always on your own. But you have to do so, anyway. It's better to understand the ideas behind what you are doing instead of focusing on concrete implementations. Just as always. Then use a tool for the details. > It is the best of the lot ( in my opinion)because this > particular company is focusing on building an IDE for > struts framework AS IS. Unlike alot of these other > vendors who want to give you everything and you will > waste your life time working out which framework you > should use. Well, I am in personal contact with a lot of the high-profile characters (won't mention names here) in the Struts and MVC scenes, and all of them basically share your viewpoint, that is: Struts is a step in the right direction. But it's clearly not the end of all things. > There are three ORM frameworks which I know of which > are being used alot with struts when using databases > with struts. ORM on the other hand is nothing Struts- or generally webtier-related. Struts is entirely focused on getting input from web-based user interfaces in a MVC-like fashion known as Model2 in the J2EE blueprints, plus inter- facing with the Model | Business Logic tier via Actions. The first version was hacked by Craig McClanahan over a weekend, and still: Struts doesn't make any assumptions about subsequent layers, including the integration layer things like OR mappers may belong to. > you can find two of them at http://db.apache.org > OJB & Torque. > OJB - is an Object/Relational mapping tool that > allows transparent persistence for Java Objects > against relational databases. http://db.apache.org/ojb > Torque - > I am personally favouring cayenne from > www.objectstyle.org. Both Torque and Object Relational Bridge are proven solutions to the O/R impedance problem. There are may others. But one thing I would definitely have a closer look at is the iBATIS Database Layer (www.ibatis.com). Credits go to Ted Husted here who gave me the link here. Before that, I favored Castor (www.exolabs.org), but what's the effective difference in the end? > Incidently struts is also developed at apache.org. > As these vendors don't have technical skills or > expertise to build their own framework, > why use a cut & pasted one and pay for the pleasure > of buggy & outdated framework. I think I don't understand the above. Struts is developed at apache.org, and its inventor Craig R. McClanahan is both a committer to apache.org and JSF specificiation lead for Sun. Considering technical skills, don't underestimate the people working for almost any software company I know of, they're generally the best of breed when it comes to all major companies, good people throughout. Then: Struts may be the most popular framework forJava web MVC2 nowadays, but even it's inventor says things could be done better. Won't comment on the second part here any further, as it speaks for itself. So we both agree Struts is good? -- Chris (SCPJ2) === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Struts question
Am Mittwoch, 22. Oktober 2003 21:56 schrieb jini us: > There seems to be 90% agreement. 95%? ;-) > With the vendor point of view > , you can look at another way. > You can become a vendor too because > the underlying work is done for you. Well, I'm not a vendor and I currently don't plan to become one. Maybe I work for a vendor, but not for one who sells frameworks or other base technologies. > I am favouring cayenne because having read > his ideas from the website, they are very much in > agreement with principals I have across. So I'll check out Cayenne, too, as you recommended it here and I'm neither arrogant nor dumb beyond the average level ;-) > Principals used in software with 300 + tables > in a database. Principals used in software with only 150+ tables, but 3 mio customers, acessed by ~300 users concurrently at 8:00 AM when they start up their PCs. I generally don't tend to cite from the experiences of others. And it works, still :-) The most important thing is getting the job done, by whatever means. -- Christian. === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Prev/Next Using JSP
Am Donnerstag, 23. Oktober 2003 20:11 schrieb S Senthil Raja: Hi Raja, you might want to have a closer look at the popular display tag library, available from http://edhill.its.uiowa.edu/display/ (hope I got this right :-)). Have a look at the online examples and see if it fits your need. It's open source and IMHO very cool. HTH, -- Chris (SCPJ2) > Dear sir, > I'm fetching some "n" of records with the 5 columns from > Database(Server side), all the values are stored in one StringBuffer, > Now I want to display(Client Side) 10 records per page using > link.How we will do in JSP anybody can suggest me, give > some code for this process. Thanx and regards. > -Raja. === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: [Shameless Plug] Servlets and JavaServer Pages; the J2EE Web Tier
Am Sonntag, 16. November 2003 22:42 schrieb Mark Galbreath: One may object that Jayson Falkner isn't exactly a no-name himself when it comes to the matters in question. -- Chris. > Are there any reviews or comments from Marty Hall, Jason Hunter, Hans > Bergsten, David Geary, David Flannigan, or any other recognized > authority in the field? AFAIK, nobody is using 2.4/2.0 in production > yet so how valuable is the info? Is this yet another "rush to > publish" to get sales at the expense of content? > > The book is not listed on Amazon. > > Mark > > -Original Message- > From: Jayson Falkner > Sent: Saturday, November 15, 2003 5:36 PM > > "Servlets and JavaServer Pages; the J2EE Web Tier" is a book that > teaches an HTML savvy Java developer how to build complete web > applications. The book focuses on the latest Servlet and JSP > specifications, Servlets 2.4 and JSP 2.0, and it includes many > explanations and code examples of the all the popular features of > these technologies. > > You can find more information, including user feedback, code and > sample chapters at the book support site: > > http://www.jspbook.com > > Kevin Jones and I have worked hard on the book, and we hope to make > it the definitive guide to Servlets and JavaServer Pages. Please > check out the book support site, and if you are interested, pick up a > copy of the book! > > Jayson Falkner > [EMAIL PROTECTED] > > = >== To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". > For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST > DIGEST". > > Some relevant archives, FAQs and Forums on JSPs can be found at: > > http://java.sun.com/products/jsp > http://archives.java.sun.com/jsp-interest.html > http://forums.java.sun.com > http://www.jspinsider.com > > = >== To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with > body: "set JSP-INTEREST DIGEST". > > Some relevant archives, FAQs and Forums on JSPs can be found at: > > http://java.sun.com/products/jsp > http://archives.java.sun.com/jsp-interest.html > http://forums.java.sun.com > http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: JSP issue
Am Montag, 22. Dezember 2003 13:19 schrieb Mikil: > Hello everyone, Hi, > I have a scenario which is very common but don't know the solution > and thats where I need some help. > > Scenario: > > After signing out from a web application the cookies are killed and > sessions invalidated. But when I click on the back arrow key of the > browser, the page with the user name appears though infact the value > is null. > > Solution: > > I am looking for the solution that when I click on the back arrow of > the browser, it should not allow what I mentioned above but instead > should direct to a new page or home page. 1.) Add the appropriate no-cache headers to your JSP so the contents doesn't get cached. 2.) Upon authentication, put some token in session scope and have your JSP check if it's still there before executing. If not, redirect to your login page. > Await for your replies. > > Thank you in advance. > > Rgds > > Mikil HTH, -- Chris (SCPJ2) === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: JSP browser snooper
Am Montag, 12. Januar 2004 19:52 schrieb Michael Coughlan: On the server side, you have to live with what you get from the request. That is, you can evaluate the headers, from where the request came from, which protocol was used, what MIME types are accepted and so on. Still, you can't get details about the client configuration beyond what you can tell from that information. Additional information may be available via JavaScript, and BrowserHawk itself seems to make extended use of it. Just to note, when testing the link given the information proved to be not too reliable. Most tests (Konqueror 3.1, SuSE Linux 9.0, Sun Java 1.4.2, Applets accepted, JavaScript enabled, Acrobat Reader 5 installed; I have a P4, 512MB of RAM and hdb has 120GB, 77% free) failed with my current setup. Still, none of the latter got detected. Therefore, I wouldn't rely on BrowserHawk or the like. Note: the fact it correctly detected Konqueror 3.1 is due to the circumstance I didn't tell it to cloak as Explorer, whatever version desired, and you can do the same with Opera on Windows too, at least. Then, if your app really depends on such info, I guess you're on the wrong track somewhere. For web applications, all this extra info is not needed, so you can't rely on anything except what the headers tell you. In a JSP browser snoop page, you're limited to exactly the same. There already is such a page in the standard Servlet demos, and getting any information beyond that is a really hard job, I guess. Mind: snooping the concrete user's system configuration was not part of the deal when they invented HTTP. HTH, -- Chris (SCPJ2) > I need to write a browser-snoop JSP page similar to this paid > product. http://www.cyscape.com/showbrow.asp > > I found this free JSP snooper. > http://cyscape.com/browserinfo.asp > > But it is missing this following mandatory columns. > Adobe Version > IP Address > Service pack > OS > Browser settings (MSVM settings) > MB RAM > Hard disk space available > Java version being used (sun or MSFT) + version # > > I'm sure someone has already invented this wheel. If anyone knows of > another free download please let me know. > > Also, does anyone know if all of the above columns are reportable? > (such as Hard disk space available or RAM?) > > I'm new to JSP. At this point, I simply need to make sure that this > information is accessible in JSP. > > Thanks in advance, > > Mike C > > = >== To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with > body: "set JSP-INTEREST DIGEST". > > Some relevant archives, FAQs and Forums on JSPs can be found at: > > http://java.sun.com/products/jsp > http://archives.java.sun.com/jsp-interest.html > http://forums.java.sun.com > http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: JSP browser snooper
Am Dienstag, 13. Januar 2004 15:24 schrieb Michael Coughlan:
> Thanks for the reply Christain.
Never mind :-)
[CLIP!]
> > There already is such a page in the
> > standard Servlet demos...
>
> I'd love to see that. Is that on the Sun site? On the Oreilly site?
> Any links would be appreciated.
The Snoop servlet is part of the 'official' Servlet
demos; shipped with the Oracle iAS and Tomcat,
at the least. Resin ships with an improved JSP-
based version, and you can extend all of these
as you wish. For instance, you can get a long
list of all the Java Runtime properties (as long
as accessing this information not forbidden by
security constraints) by adding this to your
'snoop' JSP:
Java Runtime
<% for (Enumeration spn = System.getProperties().propertyNames();
spn.hasMoreElements() ;) {
String propertyName = (String) spn.nextElement();
String propertyValue = System.getProperty(propertyName); %>
<%= propertyName %><%= propertyValue %>
<% } %>
But: a better idea would be to look at the Servlet APIs -
that's exactly what you can get on server side from the
request. Check out getRemoteHost(), getProtocol(),
getHeader() and the like. Unless the client info is not
made available via headers, you may well be doomed
to have a closer look at JavaScript.
HTH,
-- Chris (SCPJ2)
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant archives, FAQs and Forums on JSPs can be found at:
http://java.sun.com/products/jsp
http://archives.java.sun.com/jsp-interest.html
http://forums.java.sun.com
http://www.jspinsider.com
Re: Image using response.getOutputStream...
On Wednesday 25 February 2004 06:26, Narayanan Ravi Chandran wrote: Hi, > Hi, > > I am finding a typical problem with the below JSP code. The problem No wonder. Never seen anything like that. > is when I use the response.getOutputStream() to display the image > generated @ server the text and text boxes are never shown in the > page, I am getting only the image. > > Could some body help me on this. Well...something important first: HTML means *text*. Each and every web page is basically just simple and plain text. It may contains links to other resources, as is the case with tags, but these are loaded in a separate request. It's the browser that finally fits the pieces together, so that the images seem to be 'embedded' in the page, but that's 'browser magic' and not related to the HTML protocol. Therefore, if you want to generate images to be displayed in your page, you have to split up your design into two different pieces at least: one Servlet that delivers the image as a binary stream (don't forget to set the MIME headers accordingly), plus the HTML page which con- tains the text. Map the image servlet to a name it can be called by (web.xml) and possibly wrap this to a Struts action (the standard forward action suffices). Then, replace the <%=response.getOutputStream()%> part with the image servlet path (/image.do, for example). To get an idea how this works: one of the projects I was recently involved in is www.anwalt4you.com. Each of the user pictures comes from an Oracle BLOB, with the byte stream generated on the fly by just the aforementioned Servlet (which is dead simple). Btw, the site runs on a Tomcat 5 cluster and heavily uses MVC2 and Struts 1.1. HTH, -- Chris (SCPJ2) > Thanks in advance. > RCDran -- CLIP! === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: JSP debugging in eclipse
On Wednesday 25 February 2004 15:36, Murali Krishna Devarakonda wrote: > Lomboz plugin is free, and does have some useful features, including > automatic deployment and elemantary syntax coloring (when I last used > it in December). The syntax coloring was pretty rudimentary and the > error message reporting by it's compiler was quite inadequate. > Debugging - breakpoints in JSP source- are/were not possible. Also, > there was a tab for the corresponding Servlet source, but it was > pretty much readonly. Though my mainstay is Oracle's JDeveloper 9i/10g, I also did some things with Eclipse. You're right about the Lomboz plugin which I use sometimes (at home) for Resin-related work. It's one of my favorites. Considering the syntax coloring, though, there's a much better solution for free in form of the Colorer plugin which is not limited to JSPs (Lomboz) or Java code (Eclipse), but also colorizes HTML pages, CSS and so on. Don't have an URL at hand, but Google may help out. IIRC I got the original hint from Matt Raible's site (www.raibledesigns.com); look for his favorite Eclipse plugins there. HTH, -- Chris (SCPJ2) === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Secure static files?
On Wednesday 25 February 2004 17:58, Eric Cho wrote: > Hi all, Hi, > Here's the background to my question. > > A web application sitting on WebSphere 4.x (soon to be Websphere > 5.x). On the web application we have many links to various documents > (pdfs, docs, xlsetc) and static html files. > But there is a requirement to secure many, if not all, these static > documents/pages. > > How would we go about doing that? > > I realize, we could change the html files to jsp and add our security > code but the problem is these html files are generated by a third > party tool and the content is often changed. One important question: is it only the content that changes or the file names as well? > Upon every change, it > generates a whole new set of html files. Where upon we will have to > go back and change them to jsps and add the security code. This > would be very time consuming. And as you may easily forget a single page, it's error-prone, too. This is definitely not the way to go. > Even so, if we could do this, how would we secure the pdfs, docs and > etc? Ideally what we'd like to see happen is, if a user was to have a > URL and path to a file, they would be thrown to a login page if they > weren't first authenticated. > > So if any of you have ideas from both the application and/or server > side, it'd be much appreciated. There a two possible approaches that have already been mentioned. A third suggesting would be to move all files to a 'secure' location where they can't be accessed directly (anywhere underneath /WEB-INF or to a directory which is protected by other means, .htaccess, for example. Then, route all access through a Servlet which handles the necessary security issues in a central place and just delivers the files from the protected directory. When using Struts, you can leave this task to ActionServlet, but you have to wrap each page into a ForwardAction initially in struts-config.xml (adhering the 'Action first' rule). And in both cases, you have to make sure possible links in your pages don't contain static references, but call either your Servlet or the related Struts action instead. Whether you use Struts or not, the ability of handling security issues in a central place is one of the numerous benefits of an MVC design. If your current app was not architectured in this manner, it's usually easier to use a filter or container security mapped to paths, as mentioned before. HTH, -- Chris. > Thank you, > > Eric Cho > Web Solutions > Celero Solutions > [EMAIL PROTECTED] > www.celero.ca === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: How to download automatically?
On Friday 27 February 2004 03:09, Edward King wrote:
> I want to realize file automatically function.File located
> c:\1.txt,when user explore this page,IE reminder user if download
> file "1.txt".I write following code.But when I explore this page,IE
> didn't remind me if download file and it didn't domnload file at
> all.How to correct following code to realize automatically download?
> What errors is in my code?
>
> public void doPost(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
> response.setContentType(CONTENT_TYPE);
> String file_name=new String("c:\\1.txt");
>
> response.setHeader("Content-Disposition","attachment;filename="+file_
>name); PrintWriter out = response.getWriter();
> out.println(data);
> }
>
> Thanks in advances!
> Edward
I have a sample Servlet (sources included) available from my site
under
http://www.christianbollmeyer.de/dl?downloadFile=DownloadServlet.war
which should contain everything desired, including GZip compression.
Considering the code example given: out is a Writer, a text stream.
For delivering binary contents, you have to use another kind of
stream (the exact flavor depends on whether it's compressed,
buffered and the like). The sources should tell you all you need
to know about these matters.
HTH,
-- Chris (SCPJ2)
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant archives, FAQs and Forums on JSPs can be found at:
http://java.sun.com/products/jsp
http://archives.java.sun.com/jsp-interest.html
http://forums.java.sun.com
http://www.jspinsider.com
Re: how to display image from mysql using jsp
On Thursday 01 July 2004 19:06, lee hwaying wrote:
> hi.
Hi,
first of all, let's get clear about the focus of JSP in the
overall aspect of Java web technology. JSP is based
upon the Servlet API and provides an easy means
to generating HTML or other text output in the first
degree. Though you *can* use JSPs to deliver binary
contents (such as images), that's nothing recommendable.
For streamed content, Servlets are much easier to
handle and straightfoward. It has never been a good
idea just to put <% and %> tags into a JSP and then
code the whole program inside these.
Then, you have to hold two things apart: the HTML
page itself which is a text document and can well
be rendered by using JSPs. Note that images are
not 'embedded' in the page, but only *referred* to
by tags. Delivering the real content
is where Servlets come in. For delivering images
stored in a database (don't know much about
MySQL, as we're on Oracle, but in the end that
doesn't matter much), I would write a simple
Servlet that takes the byte array retrieved from
the db (or a stream or whatever) and delivers
it via HTTP. Note that HTTP is different from
HTML.. Some sample code to illustrate this:
package de.christianbollmeyer.struts.qna.servlets;
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import de.christianbollmeyer.qna.Constants;
import de.christianbollmeyer.qna.persistence.PersistenceFacade;
import de.christianbollmeyer.util.ServletUtilities;
public class ImageServlet extends HttpServlet {
private static final String CONTENT_TYPE = "image/jpeg";
private static final int BUF_SIZE = 1024;
public void init(ServletConfig config) throws ServletException {
super.init(config);
}
public void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
String user = request.getParameter(Constants.SC_PARAM_ID);
int userId = ServletUtilities.stringToInt(user);
if (userId == Constants.UNDEFINED) {
userId = Constants.POOL_USER;
}
response.setContentType(CONTENT_TYPE);
response.addHeader("Cache-Control", "No-cache; No-store;
Must-revalidate; Proxy-revalidate");
response.addDateHeader("Expires", 1L);
response.addHeader("Pragma", "No-cache");
byte[] buffer = new byte[BUF_SIZE];
OutputStream outstream = response.getOutputStream();
InputStream instream = null;
instream = PersistenceFacade.getInstance().getUserImage(userId);
if (instream == null) {
instream =
PersistenceFacade.getInstance().getUserImage(Constants.POOL_USER);
}
try {
int size = -1;
while (-1 != (size = instream.read(buffer, 0, BUF_SIZE))) {
outstream.write(buffer, 0, size);
}
} catch (Exception ex) {
System.out.println(ex.getMessage());
} finally {
if (instream != null) {
try { instream.close(); } catch (IOException e) { ; }
instream = null;
}
if (outstream != null) {
try { outstream.close(); } catch (IOException e) { ; }
outstream = null;
}
}
}
}
Just to get the principles. It won't compile, for the supporting
classes are missing. PersistenceFacade, for instance, reads
a user image from the db and dumbly returns it as a stream for
whatever use. The Servlet takes that and copies it bytewise
down the HTTP stream (try..catch block), with the 'image/jpeg'
MIME header being sent before (note: no HTML here at all).
You can pass a parameter to the Servlet ('user') telling the
Servlet which image to show. Then, there's some standard
code to forbid caching, but that's it. The Servlet is mapped
to a URL in web.xml, /img or whatever, and in the HTML
page including the db pictures, the references simply look
like i have search on the net for 3 days for sample code of displaying a
> byte[] from mysql image field using jsp but without success.
>
> 1. I have found sample code for php in doing that
> http://www.onlamp.com/pub/a/onlamp/2002/05/09/webdb2.html?page=1
>
> 2. It can be done via servlet. But i am reluctant to emit all html
> content using servlet in this case.
>
>
> Can anyone help? Is there a way using jsp to do so?
>
> many many thanks
> hy
>
> _
> Download ringtones, logos and picture messages from MSN Malaysia
> http://www.msn.com.my/mobile/ringtones/default.asp
>
> =
>== To unsubscribe: mailto [EMAIL PROTECTED] with body:
> "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with
> body: "set JSP-INTEREST DIGEST".
>
> Some relevant archives, FAQs and Forums on JSPs can be found at:
>
> http://java.sun.com/products/jsp
> http://archives.java.sun.com/jsp-interest.html
> http://forums.java.su
Re: URL mapping ...
On Tuesday 30 November 2004 17:03, Guy Katz wrote: > in tomcat, in a shared environment you still get your own 'host' > element so taht you can map your domain (www.yourdomain.com) to your > application. if those guys in your hosting company know what they are > doing, you will have this options also. this is kind of basic stuff. > if they cant do it. i would suggest to find someone who can... Same is possible in Resin, but many providers don't know how to handle it right. If nothing helps, I'd put an index.jsp into the root | base directory that just forwards to the 'default' application: <%@ page contentType="text/html; charset=ISO-8859-1" session="false" %> At later stages, the exact context may show up in the address line, but who really cares (you can always rename the context to something more fitting like 'enterprise', 'cms' or 'gateway'). Anyway, the important first page will not only be automatically | transparently invoked, but search bots will directly relate the sub-context contents to your primary domain. HTH, -- Chris (SCPJ2) > -Original Message- > From: A mailing list about Java Server Pages specification and > reference [mailto:[EMAIL PROTECTED] Behalf Of Ming > Sent: Tuesday, November 30, 2004 5:27 PM > To: [EMAIL PROTECTED] > Subject: Re: URL mapping ... > > > Thanks for the reply, Guy. But I'm in a shared environment running > Resin and the support staff doesn't want to make configuration > changes for just one customer... > > Is there any other way to solve the problem? === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Newbie question about using the JAR file
On Friday 10 December 2004 13:56, Thomas Tsang wrote: Make sure you've put the *,jar files in a directory where the classloader can find them. If unsure, put them in your application's /WEB-INF/lib directory, not one of the Tomcat server's directories. Then, I'm not sure about the Session thing. AFAIK there's a Session in Java Mail as well, not to be mixed up with the usual HttpSession, and I guess the former one may be the culprit here. If this is fixed, look at the the settings you provide the (mail) Session with. Though I'm no JavaMail expert, IIRC the whole thing works by setting several System properties, but before going into the details, the whole thing you're experiencing looks more like a simple classloader problem to me: the classes contained in the *.jar files are just not found. HTH, -- Chris (SCPJ2) > Thank for your information, but I think the main case is I don;t know > how to install the jar in the server, the same error is retuen when I > add the code you provide, and even I remark the line 'Session > mailSession = ...', the similar error is returm for the next line > == > InternetAddress cannot be resolved or is not a type > == > > = >== To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with > body: "set JSP-INTEREST DIGEST". > > Some relevant archives, FAQs and Forums on JSPs can be found at: > > http://java.sun.com/products/jsp > http://archives.java.sun.com/jsp-interest.html > http://forums.java.sun.com > http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: servlets beans and jsp
Hi everyone, now, as Hans has spoken already, I'd also recommend reading his book. I've read the first edition a year ago and bought the second one unseen last month. I rather seldom give praise to computer books, but O'Reilly's 'Java Server Pages' is one of the few books on JSP that - as you may only find out after- wards - really teach you something. It's fun to read, too. This is not just my own personal thinking, but also the feedback I get from my co-developers. In fact from every- one I found worth lending or at least recommending rea- ding it :) The book is often criticized (especially the first version) for making extensive use of the custom taglib Hans provided with the first edition. People saying this have not really read it from beginning to end, I say. Taglibs are meant to make things easier, but from a developer's view, they don't spare you from having to understand the details behind the scenes first, and that's the context in which the 'ora' tags live as well. Apart from that, the book takes you from the first simple steps in JSP to more and more advan- ced designs, giving a short, understandable, but always concise overview on different designs (from pure JSP implementations to alternatives including servlets and J2EE). There are chapters on load balancing | clustering, different possible approa- ches to security issues, thread safety and all such things that you sooner or later stumble about when developing real-world applications. Hans shows you all this if you just persist in your efforts. This is something that makes the book remarkable in some way. There are quite a lot of books on my shelf, some with 'Mastering', 'Professional' or 'Core' in their titles. But if I want to look up something, the first book I usually get first is 'Java Server Pages'. In the second edition, things got more difficult, for the book has grown to some degree. Coming back to the 'ora' tags: these have mostly been replaced by the JSTL now which Hans (of course) focuses on in the second edition. Still, it's alway a good idea to look at the sources (www.thejspbook.com). Apart from his fame from Gefion (try the LWS!) or the Apache Project, these are just examples of good coding IMHO, well documented and easy to understand (if you have some Java background). Some clever things to be discovered there :) Of course, I don't agree with Hans Bergsten on all of the topics. Mostly about details. Personally, for example, I think that Strut's ActionForms (which are beans | value objects after all) are basically a good thing and not irrevocably tying you to the Struts framework, especially when it comes to the Presentation layer. You can happily use the ActionForward mechanism and just replace the View (JSP and the Struts taglibs) component in MVC with an XML/XSLT processor like Castor (www.exolabs.org) or something else with bean2xml serialization. There's a rather influential article on www.javaworld.com' by some lead developers from orbeon.com, covering the basics of the XSLT approach, I recommend reading that. But that's just an alternative, and the book is about JSP, after all. By the way: the JSTL and JSTL EL are explained in detail in the second edition, and that's still my reference on this topic. Considering Chapter 18: if I hadn't read the first edition first, which cove- red the 'action' approach, my learning curve would have been steeper. But well...nothing's perfect, after all. So, finally coming to some- thing near the end, at least, from my own experiences I'd recommend to read 'The JSP book', if you can. From that you may get on to explore other grounds, but you'll have a solid foundation, at least. Considering MVC in general, I'd recommend installing the Struts .wars, briefly studing the documentation and then analyse a 'real-world' example of MVC2, comfortably named 'struts-example.war'. This one's also got a tutorial walk-through that explains the details, but you need some background about the Struts 'action' MVC implementation for really understanding things, and it quite heavily uses the Struts taglibs. Still, this is also a good example you can learn something from. Whew. So much text, no one will read it in detail anyway, so I'm going to bed. Leaves one question: Androids may dream of electric sheep (remember Blade Runner?), but is the same thing true for developers as well? Tomorrow we might now :) Good night from -- Chris (SCPJ2) > -Original Message- > From: A mailing list about Java Server Pages specification > and reference [mailto:[EMAIL PROTECTED]] On Behalf Of sri sri > Sent: Tuesday, November 26, 2002 7:00 AM > To: [EMAIL PROTECTED] > Subject: servlets beans and jsp > > > Hi, > > I have been going through a lot of stuff about how an > application can be built using MVC architecture. But , I > didnt get a good site which explains a basic example using > the above structure and interacts with a database.There is a > site ...www.stardeveloper.com , which explains how to use > thes
Re: How should i proceed with
Well... if I most humbly might make some objections... 1. IsUserInRole() is about authorization, so that won't solve the problem at all, I fear. With this method, you can check what a user is allowed to do. You can't check if the user tries to log in twice, regardless of the authentication scheme used. 2. The database approach may work to some degree, but it has some major drawbacks. First, you multiply the critical points of failure. If *either* (|) the web tier or the resource (database) tiers fail for some reason, the user gets locked out. Why? Because the database flag is still set to 'active' or some boolean representation of that state. The same will happen if the session just times out, i.e. if the user doesn't log out as he should (thus, calling something in your code that finally resets the flag after calling session.invalidate()), but just closes the browser. Never assume that something like that will not happen. Most people just close their browsers. I do so, too. 3. You can set the session timeout in web.xml. There is no need for an additional .properties file. 4. No criticism without an alternative suggestion. Mine is loosely as follows: As I understand, no user should be able to log in twice to the same application. So you need application-wide control over things. Luckily, there's something like an application context, and you can store objects in it. Hm. So what hinders you from putting something like a LoginRegistry there? You can use a Vector or an ArrayList, for example, storing the login name there if authentication was successful and the session is created. The difference between Vector and ArrayList is that access to the former's elements is thread-safe while the latter's is not. In this case, as changes are only made at a single point (storing the username; if it already exists, just exit and call session.invalidate() if your code had already created a new session at this stage) and all subsequent operations are read-only, an ArrayList might suffice, and it's faster than a Vector due the aforementioned reasons. During the authentication process, check if there already is a username entry in the Registry. If so, exit and call session invalidate() as explained before. If not, add the username to the LoginRegistry and proceed. In case the user logs out, you just remove the username entry from the LoginRegistry. Advantages over the database solution: if the web tier fails for some reason, the login state is auto- matically reset, as the LoginRegistry is gone for good as well in this case. If the database crashes, that doesn't affect logins anyway (unless your application depends on that elsewhere), for you don't need it to to achieve the result. Still, there's one single critical point left: you have to make sure that the LoginRegistry is kept up-to-date if the container decides to remove a session because a timeout happened. Two approaches are possible: you can either check periodically or get informed. If your Java server implements the current specification (Servlet 2.3/JSP 1.2), you can easily intercept this event via an HttpSessionListener instance. HTH, -- Chris (SCPJ2) > -Original Message- > From: A mailing list about Java Server Pages specification > and reference [mailto:[EMAIL PROTECTED]] On Behalf Of > Dror Matalon > Sent: Thursday, November 28, 2002 8:36 PM > To: [EMAIL PROTECTED] > Subject: Re: How should i proceed with > > > At this point you would be replicating a lot of the functionality of > roles in the servlet. Might as well use the built in stuff. Check > out request.isUserInRole(); > > Dror > > > On Thu, Nov 28, 2002 at 11:12:22AM -, Peter Dolukhanov wrote: > > A small concern with this is if the user's network > connection dies, or > > the user closes his browser without properly logging off. > To circumvent > > this you should have a method which is called whenever the session > > time's out (expires) and performs the same function to > reset that value > > in the DB. > > > > Regards, > > Peter > > > > -Original Message- > > From: A mailing list about Java Server Pages specification > and reference > > [mailto:[EMAIL PROTECTED]] On Behalf Of > Kesavanarayanan, Ramesh > > (Cognizant) > > Sent: 28 November 2002 06:18 > > To: [EMAIL PROTECTED] > > Subject: Re: How should i proceed with > > > > you can have a boolean value at the DB which will be > default to zero. > > once > > he is logged in make that to 1. > > when he logs out make that to zero again. in this way if he logs in > > again > > you can check the value in the DB and prevent him. > > > > HTH > > > > Regards > > > > Ramesh Kesavanarayanan > > [EMAIL PROTECTED] > > > > > > > > -Original Message- > > From: V.T.R.Ravi Kumar [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, November 28, 2002 10:17 AM > > To: [EMAIL PROTECTED] > > Subject: How should i proceed with > > > > > > Hi , > > > > I have a situtation where in i have to restrict the access > of an user in > > such w
Re: Info about Model-View-Controller
Hi Cristian, Model-View-Controller is a design idiom originally deve- loped at the Xerox labs in the early 80's., primarily with GUIs in mind back then. IIRC it has first been implemen- ted in SmallTalk, but influenced other frameworks of the 90's in a major way, including the Document-View-Archi- tecture of Microsoft's MFC (in fact, they bought this framework to some degree. It has also influenced the Java Foundation Classes framework, the entire Swing UI makes intensive use of this design paradigm. The basic idea behind MVC is to strictly separate the tasks | roles associated to each component in the Presentation layer. Basically, the View component (screen) is what the user gets to see, the Controller part (keyboard, mouse) coordinates the input the user provides and controls the information flow to the Model, which otherwise is known as the (abstract) Business Logic which is completely shielded from its actual representation this way. The general concept is to shield different applica- tion layers from each other, there's an abundance of additional layers below the Business Logic level | facade, with each layer providing a clearly defined interface, abstracting and hiding the inter- nal implementation. As long as the interface is guaranteed, you are free to change the internal behavior as you like later on. Look upon this all as object orientation ported to system architec- ture, some way. When web technology became prominent, it was soon decovered that the MVC concept fits quite well there, too. In a typical, commercial-grade web application, MVC usually is implemented in the following way: the View component is made of JSPs. A Servlet is assigned the Controller task, retrieving the input the user provides (via HTML forms), collecting the requested information by talking to the Model (which may be a database, an Enterprise Java Bean or even just another (service) layer and delivering the result back to the View part, usually by forwarding it to JSPs that perform the actual representation. In a more advanced design, implemented in Struts for example, the Controller uses a Delegate pattern otherwise known as the 'action' approach. In Struts, the Controller servlet handles the entire web-specific communication, delegating requests to specialized 'action' classes. These are basically just normal Java classes, having access to all the capabili- ties the platform provides, which retrieve or modify 'data' (in fact, by calling subse- quent application layers) and point the Controller to where to look for the results, afterwards. Struts heavily makes use of so-called 'ActionForms' in this context, which in fact are simple Java Beans or Value Objects in EJB slang, providing an additional layer of abstration this way, and uses a declarative mechanism for telling 'what will happen next' to the application known as 'ActionMapping'. The Struts design is truly powerful. In fact, it is flexible enough to replace the entire View part, which is made of JSP and custom taglibs currently to one using an XML/XSLT approach. This was originally described by two French Java architects from orbeon.com in an article on Java World. There is a more advanced design around known as StrutsCX, pub- lished and explained in a German Java magazine some time ago. You may get the details from http://it.cappuccinonet.com/strutscx/ it's also available from SourceForge now. The Struts implementation of things follows something to be recognized as 'MVC2'. If I'm correct, there is no fixed definition of MVC anyway, but in a case of doubt, I'd refer to the Struts documen- tation first which explains the foundations it has been developed on, too. You can get it from here: http://jakarta.apache.org/struts/userGuide/introduction.html#mvc Finally, the official Sun J2EE 'blueprint' explanation of MVC/MVC2 is to be found here: http://java.sun.com/blueprints/guidelines/designing_enterprise_applicati ons_2e/web-tier/web-tier5.html HTH, -- Chris (SCPJ2) > -Original Message- > From: A mailing list about Java Server Pages specification > and reference [mailto:[EMAIL PROTECTED]] On Behalf Of > Cristian G. Amayo > Sent: Monday, December 02, 2002 7:33 PM > To: [EMAIL PROTECTED] > Subject: Info about Model-View-Controller > > > Hello, > > Does somebody remember the "Model-View-Controller" Sun > definition (1999-2000)? > I was trying to find the pages related at the > http://java.sun.com site but nothing. > > Can somebody send me > some links or info about? > > Thank you, regards. > > Cristian G. Amayo > http://cgamayo.tripod.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp h
Re: Controlling session when user is out
Hi Christian, this is exactly what session timeouts are made for. HTTP is request-response based, ie. a statusless protocol, so if the user doesn't log out as designed (giving your app a chance to call session.invalidate() somewhere), there is no means to tell if he is still connected or not. As the session state is kept on the server, an indication that the session may have come to an end is the interval of activity between two requests (or: the lack of another request, in this case). You can specify the interval in question in web.xml or by calling setMaxInactiveInterval() somewhere in you code. HTH, -- Chris (SCPJ2) > -Original Message- > From: A mailing list about Java Server Pages specification > and reference [mailto:[EMAIL PROTECTED]] On Behalf Of > Christian Hamann L > Sent: Friday, December 13, 2002 4:26 PM > To: [EMAIL PROTECTED] > Subject: Re: Controlling session when user is out > > > Hi All > I have applications in my Application Server, which everybody > are connecting > to database, for some applications i use beans to manage > information, but > whne the user close the browser i dont know how can control > his session, i > can put a button for inavlidate sessions, but the user dont > use that option, > what can i do to controll it. Because it does lowest to my > Server, because > the session wasn't invalidated. > > atte > > Christian Hamann L. > > == > = > To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". > For digest: mailto [EMAIL PROTECTED] with body: "set > JSP-INTEREST DIGEST". > Some relevant FAQs on JSP/Servlets can be found at: > http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: JSP/TOMCAT problem
Hi, > -Original Message- > From: A mailing list about Java Server Pages specification > and reference [mailto:[EMAIL PROTECTED]] On Behalf Of > Saket Barve > Sent: Thursday, December 19, 2002 7:08 PM > To: [EMAIL PROTECTED] > Subject: JSP/TOMCAT problem > > > I have tomcat 4.1.12 installed on a UNIX machine. For > now, all I am trying to do is use a testConnection.jsp > page to access database through a ConnectionBean.java > file. The files are under package ta You also put this into /WEB-INF/classes/ta then? And compiled the package sources to .class files? Just to make sure. > All the files are located in the appropriate > directories (viz .java file in /classes/package_name/ > and .jsp in webapps/package_name/) within the tomcat JSPs don't have to be put into 'package' dirs, but still. > installation. Also, I have made appropriate changes to > the server.xml file. This is not necessary. If you follow the web app specs, making an app directory underneath /webapps with the structure (/WEB-INF, /WEB-INF/classes, WEB-INF/lib/ and so on) described there and then putting your files there accordingly, the class loader(s) will automatically mount your app. > Every time I try to open the testConnection.jsp file > on the browser, I get an error saying that the package > ta does not exist. So it's not found, then. > I removed the package only to get an error of the type > undefined variable: class ConnectionBean. > > CLASSPATH doesn't seem to be the issue because I > copied the one from my team member's .cshrc and he can > access his database over the browser just fine. .cshrc contains the user-specific 'system' classpath, among other things. I'd recommend to have a look at Tomcat's Classloader HOW-TO again, it's included in the documentation. In Tomcat 4, there are multiple class loaders. Normally, classes specified in the system classpath should be available to Tomcat as well, but as I almost never use this approach, I can't tell for sure if it works. In any case, I wouldn't make use of the system classpath in a web app. Makes no real sense when later deploying your app in a .war file... It's much better to just have to tell your customers to copy the .war to the /webapps directory and have everything else handled by common magic than explaining a whole lot of Java or Unix details and have Java illicits follow your instructions in vi or something comparable. > Any suggestions or ideas to resolve this issue would > be really appreciated. > > Thanks, > Saket HTH, -- Chris (SCPJ2) === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Use of Vector
Am Freitag, 3. Januar 2003 09:56 schrieb Vikramjit Singh: > > -Original Message- > > From: Eric Noriega [mailto:[EMAIL PROTECTED]] > > Sent: Friday, January 03, 2003 1:31 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Use of Vector > > > > > > This is totaly false. You do need to worry about > > threading, if the > > variable is static to the class (not instance). Yes. The scheduler can take away control any time, regardless of a variable being static or not. Considering static variables, this is what class locks are meant for. RTFM, one might be tempted to say. Or get certified, if this is an option. You won't pass if you don't know Java threads in and out. > Yups thats true, that when a variable is static, and two threads are > accessing the static variable then the value of the variable can be > changed. But my dear, what i am saying is that in web applications, the > container takes part of the threading issues for you, and where every user > has got a different session for him. Sorry, but this is *utterly wrong*. Unlike the J2EE tier (where the 'synchronized' keyword is even forbidden), the *web container* doesn't care about thread safety at all. It's entirely the program- mer's responsibility to take care of all threading issues. Further- more, this has nothing to do with Sessions, too. In fact, the opposite is true. Even within a session, a user can happily send multiple requests to the web tier which are then executed as different threads by the JSP rsp. servlet instance. > >Even a vaiable in the > > session could be accessed by two threads. Yes. In JSP terms, only the page and request scopes are safe. Session and application scopes are not. > What exactly do you mean by session could be accessed by two threads? Open another window in Explorer and see for yourself. > >Also I've seen some poeple > > mention not to use Vector because it is "old". This is also not true, > > Vector can be useful and is not depricated at this time. In opposition to some opinions I've read here, I think using a Vector is quite state-of-art. Vector is the synchronized equiva- lent of ArrayList and a Collection now. I don't see any advantages in using techniques to make an ArrayList behave as if it were a Vector. Considering "old": in the beginning, there were no Collection classes at all. There were only Vector, Hashtable and Java arrays. Then they introduced the Collection classes, first as an optional package, later being integrated into the J2SE core. Nowadays, a Vector is just another Collection type, and a thread-safe one. If you have a proper design and code against interfaces, you can easily exchange the specific implementa- tion by something better suited, a linked list implementation of the Collection interface, for example. This entirely depends on your concrete application. If doing so, and the Collection chosen is not thread-safe by itself, you may use static helper functions to deal with that issue, if necessary. If Vector or Hashtable suffice, just stick to these. > Vector has its own uses, and I dont see down the lane also vector being > deprecated. Unless someone comes up with a real good reason some day, this definitely is true. HTH, -- Chris (SCPJ2) -- CLIP! (some whole lot of stuff) ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Location.href
Am Donnerstag, 9. Januar 2003 16:36 schrieb KEITH KOSMICKI:
> I have a button on a page that uses location.href to go to other pages.
> One of these buttons options goes to the previous page.
> However, it loads the page out of history rather than loading a new page
> from the server.url Replace does not work and gives syntax error and other
> options so far load a blank page. Any suggestions.
Obviously, the previous page was cached. For dynamic pages that should
be requested again each time, you have to tell the browser | proxy that it
shouldn't use the cache. Unfortunately, the mechanism is not standardized,
but putting the following lines in your JSP page somewhere before
sending body content should normally suffice:
<%
response.addHeader("Pragma", "no-cache");
response.setHeader("Cache-control", "no-cache");
response.setDateHeader("Expires", 0);
%>
There is a fourth possible line which I saw once but don't remember
right now, but that's kind of esoteric anyway. As this is a common task,
you can also write a handy little tag for such stuff, as described in
O'Reilly's JSP book, for example (www.TheJSPBook.com). If the
page in question is static HTML, those lines should go into
tags in the section of your page.
HTH,
-- Chris (SCPJ2)
OK, I'll also add the code for my own solution. Most parts are
generated by Sun ONE Studio, as I was lazy and used the
wizard, so the code is kind of verbose. But still. Here it comes:
package de.christianbollmeyer.tags;
import javax.servlet.jsp.tagext.TagSupport;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.PageContext;
import javax.servlet.ServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.jsp.tagext.BodyTagSupport;
import javax.servlet.jsp.tagext.BodyContent;
import javax.servlet.jsp.JspWriter;
import java.io.PrintWriter;
import java.io.IOException;
import javax.servlet.jsp.tagext.Tag;
import javax.servlet.jsp.tagext.IterationTag;
import javax.servlet.jsp.tagext.BodyTag;
public class NoCacheTag extends TagSupport {
public NoCacheTag() {
super();
}
// doStartTag()
public void otherDoStartTagOperations() {}
public boolean theBodyShouldBeEvaluated() {
return false;
}
// doEndTag()
public void otherDoEndTagOperations() {
HttpServletResponse rsp
= (HttpServletResponse)(Object) pageContext.getResponse();
rsp.addHeader("Pragma", "No-cache");
rsp.addHeader("Cache-Control", "no-cache");
rsp.addDateHeader("Expires", 0L);
}
public boolean shouldEvaluateRestOfPageAfterEndTag() {
return true;
}
// doAfterBody()
public boolean theBodyShouldBeEvaluatedAgain() {
return false;
}
/** .//GEN-BEGIN:doStartTag
*
* This method is called when the JSP engine encounters the start tag,
* after the attributes are processed.
* Scripting variables (if any) have their values set here.
* @return EVAL_BODY_INCLUDE if the JSP engine should evaluate the tag
body, otherwise return SKIP_BODY.
* This method is automatically generated. Do not modify this method.
* Instead, modify the methods that this method calls.
*
*/
public int doStartTag() throws JspException, JspException {
otherDoStartTagOperations();
if (theBodyShouldBeEvaluated()) {
return EVAL_BODY_INCLUDE;
} else {
return SKIP_BODY;
}
}//GEN-END:doStartTag
/** .//GEN-BEGIN:doEndTag
*
*
* This method is called after the JSP engine finished processing the tag.
* @return EVAL_PAGE if the JSP engine should continue evaluating the JSP
page, otherwise return SKIP_PAGE.
* This method is automatically generated. Do not modify this method.
* Instead, modify the methods that this method calls.
*
*/
public int doEndTag() throws JspException, JspException {
otherDoEndTagOperations();
if (shouldEvaluateRestOfPageAfterEndTag()) {
return EVAL_PAGE;
} else {
return SKIP_PAGE;
}
}//GEN-END:doEndTag
}
> Best,
>
>
> Keith E. Kosmicki
> Applications Consultant
> State of IL Human Services
> STL Technology Partners
>
>
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set
> JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at:
>
> http://archives.java.sun.com/jsp-interest.html
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.jsp
> http://www.jguru.com/faq/index.jsp
> http://www.jspinsider.com
==To
unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found
Re: how to make JSP Pgms faster
Am Sonntag, 12. Januar 2003 05:33 schrieb arun s: > hi all, > Im using JSP and DB2. Now..what should I recommend upon this? Using Oracle instead of DB2? Well, if that would help... > My program is running very slow . Check what exactly *is* slow. If JSP alone were slow, you probably wouldn't even notice. But database queries might take quite a lot of time if coded sub-optimal. It all depends on the concrete app you're developing. From an abstract view, neither JSP nor DB2 are slow. Either your task is very complex, or you're making a mistake somewhere. But where, I just can't tell from the infor- mation given. > How can I make it faster. Is there some thing to make programs faster. JSPs are translated into Servlets and then executed as Java code, and on the server, Java is comparatively fast. I really doubt this is the bottleneck, as we're talking about the millisecond range here. Still, a single mis-programmed query can easily take 10 seconds or more to complete, depending on the database size and the effectiveness of the query itself. Look there first, I'd say, but as I don't know anything about your app, I can't say more on your problem. Optimizing the Java side probably wouldn't be the key, still. > If so plz reply me at the earliest. > Thanx in advance > karthik HTH, -- Chris (SCPJ2) ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Structs and HTTPS ?
Am Montag, 13. Januar 2003 09:15 schrieb Bengt Bäverman: > Is there anything that prevents me from using Struts when I need to use > HTTPS ? Hi, there is no problem to be expected with Struts and HTTPS. HTTPS is handled transparently to the application by the server, and the app components - may it be Struts or something else - are behind that. Considering certificates, you might want to check out the JSSE extensions available from java.sun.com. You can either make that a system extension (by just copying the .jar files to the /jre/lib/ext directory or setting the JSSE_HOME variable to point at the JSSE dirs. Then, using the keytool app that comes with the JDK, generate the keys and tell the server where to find them. If you're using Tomcat, there is an SSL-HowTo included in the documentation describing each and every detail, so you can't go wrong. Note that both the passwords for the keystore (you can have multiple ones) and the tomcat user have to be identical, but they don't necessarily have to be 'changeit', which is the default. If something goes wrong, just delete the .keystore file and try again. If you're using explicit keystores reserved for the Tomcat server, you may have to edit server.xml (you'll have to remove the comments for enabling the SSL adapter anyway), specifying the keystoreFile and keystorePass attributes as needed (yes, you have to provide the password in clear text, so protect the file :). But as I said, there is an SSL-HowTo included in the Tomcat documentation, so I'll better stop being redundant. HTH, -- Chris (SCPJ2) > /Bengt B > > ps > If I only had a certificate I could try this myself but, alas, I don't. > ds ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Fwd: Re: Oracle Connections
Am Donnerstag, 16. Januar 2003 13:52 schrieb John Smith: > I'm sorry if this is rather a basic question for the list, Not too basic, as security is alway complex. > but I am just > getting started using JSP to front-end an Oracle server. I can > successfully connect to the database and produce HTML pages full of data, > but before I can make any real use of this I have to implement security. > What I think that I want is to have the user provide a name and password, > which is then used to establish a connection to Oracle from a connection > pool. As we're talking about a web app here and the credentials are sent in clear text, first of all, I'd make sure the connection is encrypted, that is, using SSL and HTTPS instead of HTTP. > This connection needs to time-out on inactivity or when the browser > closes, causing any subsequent attempt to load a page to be re-directed to > the login page. The only way to get aware of a session having ended is by either getting notified by the user (by explicitly logging out) or timeouts. You can check if a request already belongs to a session by calling HTTPRequest.getSession(false). This will either return the Session the request belongs to, or null if there is no session yet. In case of the latter, your FrontController would forward the request to the login page, and so on. > Any comments or suggestions of things I may not have > thought of appreciated. Well, considering connection pools: pooled connections do have the advantage of improving speed, but at the cost of losing granularity when it comes to user rights on the database tier. With connection pools, it's possible to group users into different categories, i.e. maintaining different connection pools for diffe- rent classes of users. What AFAIK is not really possible is to make use of a connection pool on the one hand and still control user rights the same way Oracle does on the other hand. Well, of course you could implement a connection pool for each individual user, but what real sense would that make? In the end, you'll have decide for yourself what may still be tolerable regarding security concerns, and what is not. One thing that may help you on the backend is to prevent direct access to the table owner's schema. Instead, you could have different 'users' for each group, accessing the table owner's objects indirectly, either via synonyms or even (usually read-only, yet (if coding against Oracle) even updatable) database views. If you're *really* into Oracle and use Designer for ERM, you could even extend this to Table API, replacing direct SQL access by Oracle packages. Still, one general problem remains: in the end, the web (or J2EE tier) has to make an Oracle connection, providing the necessary credentials (user/password, LDAP, NDS and so on) and thus being authenticated. What you may do in Oracle entirely depends on this critical point. If you put Oracle connections in a pool, which in most cases definitely is a good choice, each 'pool' user finally has the same rights as each other one in the group on the back end objects. In most cases, not really much to worry about. Still, be aware of that point. > I have found all of the bits that appear to be required, but am unsure how > to hang them together. Surely this must be a fairly common requirement and > has been done before? Can anyone direct me to a resource where I can find > a complete set of pages, beans etc that I can then start customising rather > than have to re-invent it from scratch? otn.oracle.com, for example. > Thanks for any help. > John HTH, -- Chris (SCPJ2) --- ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Security (was: Oracle Connections)
Hi everyone, considering the security question, I was kind of short in just recommending SSL. Of course, this is not enough, but this issue just came to my mind afterwards. Probably the two most important statements on security issues are: 1. Never trust your users, and 2. Never trust input data - always validate before processing it. I'll give an example for that to show what I mean. Consider a common login form, used for sending the credentials to your app. This form, as most others in the real world, sports two fields where the user may enter his username and password, among other things. This information is then sent to your application for further processing, well guarded against all kinds of external attacks by SSL or even a tunnelled IPSEC connection. Now, how would you authenticate these credentials against an SQL database? The most obvious way would be to have a user table where you store a list of valid users and their passwords. You may even encrypt everything, if you like, it doesn't matter. In any case, somewhere in your application, you somewhere issue a SQL statement to validate the credentials given. It may very likely look like this: SELECT * FROM valid_users WHERE UPPER(username) = UPPER(:username) AND password = :password or even SELECT '#' FROM valid_users WHERE UPPER(username) = UPPER(:username) AND password = :password if you don't need additional info and just want to check if the query returns data or not. Now, user#1 logs in, knowing nothing about technical intricacies and just wanting to do his work. Given that he's listed in the VALID_USERS table, the query is expanded to this: SELECT * FROM valid_users WHERE UPPER(username) = UPPER(scott) AND password = tiger This will work just fine in 99% of all cases. But then, probably someone like me or you enters the scenario, bearing nothing really good in mind for whatever reason thinkable of. Given that I'd know or guess the login name of the DBA, I could easily enter something like this into the aforementioned login form: Username: SYS Password: dontKnow OR 1 = 1 If the authentication part of your app is still implemented in the aforementioned way, this, of course, will expand to: SELECT '#' FROM valid_users WHERE UPPER(username) = UPPER(:username) AND password = dontKnow OR 1 = 1 Yes. SYS access...let's see what I can do. Always wondered about the mystic DROP DATABASE noone really ever uses... and will they have backups at hand? Serves them right! And so on. But I think you get what I mean. It doesn't suffice to just have secure connections, for this would work fine as well if I'd just be user JohnDoe from the marketing division, SSL for instance doesn't make any difference in this direction. So *please* look out for trapholes like this in your app code. Solution strategies to avoid a possible disaster would have been to simply check for valid characters in the credential strings and rejecting just that humble '=' sign; with regular expressions, this is just another line, but there are many other strategies ensuring only valid data in the way of [a-zA-Z0-9] may be be processed. Just an example, maybe, still one I forgot to mention before. -- Chris (SCPJ2) --- ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Security (was: Oracle Connections)
Am Freitag, 17. Januar 2003 21:24 schrieb Hans Bergsten: > Since we're talking Java here, PreparedStatement is the simple solution > to this problem. It's been discussed in more detail here before so > search the archives if you don't understand how it solves the problem. > > Hans Definitely, and I also should have added that. Still, as I found virtually noone I met seemed to know (or care) about this issue, I just found it worth being mentioned on this occasion. Should better have kept to myself and studied the list archives first, of course. Yet, as even some of the Java examples on Oracle Technology Network do seem quite vulnerable to such simple kinds of attack, and as recent studies by c't magazine in Germany show that much more sites are error-prone this way than one would believe, even some of the major ones, I just thought it was a good idea mentioning the problem and its causes again, as Oracle security issues and web applications were in question; but well, could be I was wrong. Never mind :) -- Chris (SCPJ2) NB: This is a cross-language problem, therefore the mentioning of regular expressions (Perl, mostly). In Java, one would skip ordinary Statements and use PreparedStatement instead, even if the query is executed just once. SQL variables are automatically checked for illegal characters that way. ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Coding for a clustered environment
Am Samstag, 18. Januar 2003 03:59 schrieb Sajag Patel: When coding for clustered applications, generally keep special heed of Singletons in your app. Apart from that, clustering capability heavily depends on your app's architecture in the first place and IMHO is a topic too complex to be laid out here in detail. HTH, -- Chris (SCPJ2) > I was wondering if anyone knew of any special coding technique or changes > that need to be made > to run an application on an clustered iplanet application servers. Any > feedback would be helpful. > Thanks. > > > > Sajag ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: cannot resolve symbol
Am Montag, 20. Januar 2003 18:55 schrieb Juan Carlos Montenegro: Hi Juan, did you double-check that the Core book packages are in your $CLASSPATH? HTH, -- Chris (SCPJ) NB. Note that the Core book and the included examples are rather 'old' (my copy is dated early 2000, and it's already a reprint). JDBC has been developed into version 2.0 since, and the 3.0 specification is out. Many things that had to be hand-coded are part of the API now, including connection pools, which are part of JDBC 3.0 and were available for 2.0 as an optional package. In addition to the Core books, I would also recommend something more up-to-date, and O'Reilly's JSP book (2nd edition) in particular. Every- thing you really have to know about connection pools is laid out there, with practical examples given, and Hans Bergsten also provides a wrapper class suited for JDBC 1.0 drivers. Don't get fooled by the Sun logo and the flashy coffee pot holo on the back; the first Core book is rather outdated, and I rather guess I won't buy the Advanced one. > These are the errors: -- CLIP! ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: [ANN] LiteWebServer 3.0 Released
Am Montag, 20. Januar 2003 20:17 schrieb Hans Bergsten: > Gefion Software is proud to announce the release of LiteWebServer 3.0. This is really good news - Servlets 2.3 and JSP 1.2 in LWS! While the download continues, I already congratulate on this major new release. -- Chris (SCPJ2) ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: Web Server vs History Question
Am Donnerstag, 23. Januar 2003 17:51 schrieb KEITH KOSMICKI: Could be I don't understand everything right, but browser history and browser caches are two different things. The 'history' may load a page from the cache if the page was cached, or request a new page from the server if the page isn't in the cache. Dynamic pages normally shouldn't be cached. Such caching may be performed on the client, a possible proxy in-between and finally the server itself. Ruling out the server on this occasion, you have to tell the proxy | browser cache that it shouldn't store the pages in question, but request a fresh version each time, may it be going back in the history or not. The 'history' is just a list of URLs and has nothing to do with where the content displayed finally is loaded from. If this is your problem, first try to go back in the history and hit the browser's 'reload' button. This should force the browser to reload a fresh page regardless of the browser cache. Check if the application displays the correct values, afterwards. If it does, your pages are missing some header info to avoid caching. I already posted the details on this issue on 9th of January, with an additional follow-up by Adrian Janssen. The topic was 'location.href'; you might want to check out the list archives for possible solutions if this proves to be your problem as well. HTH, -- Chris (SCPJ2) > A user has indicated that even though a new item was added to a particular > area, the list would not reflect that when going back to that screen. > > Those lists are application lists that only change if the administrator > makes a change to that list in the table. There is code there to set that > application(whatever) = "" but for some reason it is pulling the history > page rather than opening a refreshed page. > > Is there a way to pull a fresh page from the web server rather than reload > a page out of history? > > > TIA, > > > Keith E. Kosmicki > Applications Consultant > State of IL Human Services > STL Technology Partners ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: HttpClient to Servlet
Am Montag, 3. Februar 2003 15:15 schrieb Adrian Janssen: Hi, well, he's right. Sessions are a server-side thing, so the server has to generate and track them later on in its effort to overcome the statelessness of the HTTP protocol. There are at least three common approaches to this (cookies, URL rewriting, hidden fields), and a Java server commonly supports the first two by default and transparently to the application. If you say HTTPRequest.getSession(true), a new Session instance is created on the server. The details about how session info is kept on the client side (in any case, the client has to provide some 'token' upon each subsequent request identi- fying it as belonging to a specific session), are beyond that. Normally, the server tries to use cookies first, as this is the fastest and most reliable approach; but if that fails (people not knowing about the intricacies of cookies, but have heard somewhere that cookies may be kind of 'dangerous' regarding privacy concerns (which is not true in case of mere session cookies; still: try to find an end user being able to distinguish :)) tend to generally turn them off), it uses URL rewriting (if you did as well, look out for a JSESSIONID= thing appended to the URL when accessing a Java web app). In this case, if your app is not browser-based, but a Java GUI client, it should suffice to extract the session id string from the response and append that to subsequent requests. Can't say for sure here, as I never tried it, but it should work, still :) HTH, -- Chris (SCPJ2) Note that the server app should be able to handle URL rewriting as well. Though this is not specific to GUI clients talking to a Java server, but some- thing to be expected from any Java server app, keep special heed of that issue, still. With URL rewriting, you have to make sure the JSESSIONID string is sent back on all responses and returned on each subsequent request, and generally be aware of the URLEncode() method (where that belongs to depends on the JDK version rsp. the Servlet/JSP version the app is coded for). Btw.: one of the 'new' things in KDE 3.1 (Konqueror | KHTML, the thing Apple's new 'Safari' browser is based on) is a fourth option in cookie handling (accept all | reject all | accept only session cookies, each combined with 'ask for permittance each time') that lets you treat all cookies as if they were session cookies, that is, if you close the browser, they're gone for good, regardless of the lifetime they may claim. Just to note. > I thought the browser generated them, but perhaps you are correct and the > server generates them on first request. If so, then you will need to send > the session id back to your client app on first request and then each > subsequent request the client app sends it back to the server. > > Sorry don't really know, let me know what you find out though! -- CLIP! === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: HttpClient to Servlet
Well, in fact there are three ways to use getSession(), a 'default' one plus a method that takes a boolean as input indicating whether to explicitly create a Session or not. Normally, one would use the default implementation (getSession()). This will either return a reference to the Session if one already exists, _or_ create a new one and return a reference to that (lic: Singleton pattern). In both cases, after calling getSession(), a valid Session instance should exist. If you pass an additional boolean parameter to this (overloaded) method, you can control session creation behavior on your own. So if you just want to check if a request already belongs to a Session, you pass 'false' and then check for null being returned (or the other way round). If you want a new Session to be explicitly created each time, you pass 'true'. You can easily get these details from the API docs, just to note. HTH, -- Chris (SCPJ2) NB. I said I never tried, but looking for JSESSIONID (still wonder if this is correct, could be some '_' goes some- where; but then, I might be mixing this up with form-based login) would be my first approach for session-enabling the GUI thing. Thought I made that somewhat clear before. Didn't I? > -Original Message- > From: A mailing list about Java Server Pages specification > and reference [mailto:[EMAIL PROTECTED]] On Behalf Of > Evan Wright, iLabs Inc. > Sent: Tuesday, February 04, 2003 11:39 AM > To: [EMAIL PROTECTED] > Subject: Re: HttpClient to Servlet > > > Create a session object the first time the client connects > (log in) with > getSession(true) and each subsequent getSession(false) would > return that > object. (?) [CLIP] === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: HttpClient to Servlet
Am Mittwoch, 5. Februar 2003 00:19 schrieb Sloan Michael: > According to http://java.sun.com/products/servlet/2.3/javadoc/index.html > > It looks like getSession() and getSession(true) do the same thing. > getSession(true) does not > create a new session if one already exists. You're absolutely right, and I was absolutely wrong on the latter issue, of course. Should really have checked in practice before. Well, it wouldn't make much sense otherwise, I guess. Thanks for the correction :) -- Chris (SCPJ2) [CLIP] === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: On (free) IDEs
Am Freitag, 28. Februar 2003 13:23 schrieb Omer Tariq: > Hi there, > I'm about to start on my first professional JSP/Servlet project and have > done some "hands dirtyin'" on the Sun One Studio IDE. I'd like to know how > reliable and popular this IDE is and how does it compare to others. > Regards, > Omer Hi Omer, the reliability of S1 Studio is heavily discussed on the Sun EAP list, currently, and a number of people people obviously found it to be not stable enough for their personal tastes. Others complain it's slow when compared to the rather bare-bone Eclipse. I won't judge, check for yourself. Telling from my own experience I found hat S1 (as NetBeans) is a great IDE for web development in particular, as it has full- fledged support for that, including a HTTP monitor which is extremely useful when problems arise. Most other IDEs, even 'commercial' ones, seem pale to comparison in this direction, and you get database support, CORBA, RMI and a lot of other things for free from the Community edition. S1 gene- rally supports the latest standards in Sun Terms, that is: Servlets 2.3 and JSP 1.2. It won't touch existing web application descriptors complying to earlier versions, but it's hard to create those for earlier versions directly in S1 for new projects. Apart from that, getting com- fortable with S1 may take some time if you're already accustomed to other IDEs. On the other hand, Forte 4 | Sun ONE Studio is something like JBuilder Professional for free for both non-profit and commercial projects. I say it's good and well worth a look. Eclipse may be faster, but this is no wonder, as it's so limited you wouldn't want to take it in consideration for real-world projects beyond applets and applications without GUIs. You can get that web support via plugins, but most of them are in a real early stage, rather instable and no competitive alternative, currently, at least. Or buy IBM's WebSphere Application Developer (WSAD), but with all the lacking features on board, it's really slow, too. Well, after evaluating quite a number of IDEs, both commercial and 'free' ones (including Sun ONE, JBuilder 7 Enterprise, WSAD, Visual Cafe, Together 6, VisualAge EE, IntelliJ and numerous less-known alter- natives), my current mainstay is Oracle's JDeveloper 9i which you should check out as well. This is something like JBuilder 8 for free, with integrated Struts support and some nice other features, including J2EE, and I do a lot of Oracle-related work, so it fits best in general for my purposes. The good thing about JDev 9i is that you can switch off all those proprietary extensions and still have a professional, J2EE-supporting IDE. It's really stable, but it's not perfect. In comparison to S1, it sometimes even falls short. S1 has a better JSP debu- gger, which also shows you the servlet code generated from JSPs, a feature I heavily missed recently when Resin failed to compile JSPs which worked perfectly under Tomcat, Orion, Oracle iAS and LWS 3.0, and I also miss the HTTP Monitor integrated into S1, as that one shows you just everything conveivable about your web app's actions, whereas in JDev 9i, using the TCP Monitor, you end up with just the clear-text versions of request/response without any info about request parameters, session state and everything. Well, after all, there is no perfect IDE. At work, we use Sun ONE studio and are quite content with it. -- Chris (SCPJ2) === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: screen format
Am Dienstag, 25. März 2003 14:50 schrieb Peter: > Hi all Hi Peter, > I am doing a web page which has multiple rows from database > in that i am giving modify option thru which user can modify the contents > in each row say like this > > name age > - > abc 12 > edf 13 > hjk 12 > > Modify Looks somewhat strange to me. Do I understand right that you have a global 'Modify' button for all of the values currently presented on the screen? This is the way you do it in normal GUI applications, but not on the web. Otherwise, given that such an approach might theoretically work to some degree, you end up with a real multitude of parameters sent to and fro. If I'm right, in fact your forms seem to send the values of unmodified columns anyway, updating the database with the same values as before in that case; makes no difference as long there's no trigger involved keeping track of modification times. Can't really tell from the details given, but normally, one would put a (generated) 'Modify' button at the end of each row, presenting some 'details' form after clicking it where the user may edit the specific entry's data, with a 'Save' button at the lower end which finally sends the modified data to the database, one specific item at a time, and presents some list view of the database contents afterwards. And so on. If you want to provide some 'temporary' persistence, allowing for 'Undo' capabilities, you could provide for that by sending everything to a Collection maintained in Session scope and providing some means in your application saying 'Commit Changes' (a button or something) which finally sends the entire Collection to the Persistence Layer | database. This is kind of what 'cached updates' do in GUI applications, but even there, the advantages (reduced network traffic plus 'Undo' capabilities) have to be weighted against several severe drawbacks (having to keep the cache in sync in a multi-user environment is just one of these; in general, there's a database transaction | locking problem in such 'decoupled' scenarios). In a web appli- cation, in particular, I would generally recommend to keep things as simple as possible: detail form, submit, insert | update, next detail form - an so on. > but the overhead incurred is if i use request.getparametervalues > all the rows even unmodified it returns which in turn is a huge overhead in > database how to detect the rows that has only been modified please do > advice If you directly read from the database, this is the expected behaviour. From the database view, there are no 'modified' values. Either something is (permanently) commited or it's not; there is no 'modified' stage somewhere in-between. A different question is which values the database may present you while a transaction lasts, i.e. as long as the changes are not permanently committed. As each transaction could also result in a Rollback, there's no safety here re- garding 'definite' values; check your database manuals for things like 'transaction isolation'. If your database doesn't support transactions (some versions of MySQL, for example), you won't have to bother about such things, but expect all kinds of inconstencies in the database itself afterwards. > Regards > Peter HTH, -- Chris (SCPJ2) ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: DB Connection in web.xml
Am Mittwoch, 26. März 2003 13:03 schrieb Deepak: Hi Deepak, this is about JNDI and, in fact, core J2EE. As your Java server obviously supports JNDI (which is good), I would probably drop all those things (could likely be some question from the SCWCD exam, btw) in favor of ones, but the details are too compli- cated to lay out in detail here. Instead of that, I'd get a good book which covers even that issue hands-down, like Hans Bergsten's 'Java Server Pages 2.0' (O'Reilly). Sorry for not presenting alternatives, but this one never has left me out in the open, and so it's my personal reference. IMHO it's even kind of crucial when dealing with JSTL (and probably, JSP 2.0). Other people may recommend other books, but from my limited point of view, this is the one that still serves me best. Of course, you could contact Hans directly, and I'm sure he would help you on this specific occasion (pp. 485-489), but anyway, I think this generally is a must-have in your library. No, I'm not being paid for that statement. -- Chris (SCPJ2) > Hi > > As you explained I added the to the web.xml and tried to > call it in my javabean as below: -- CLIP! ==To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
Re: CALANDAR
Am Samstag, 5. April 2003 09:02 schrieb Affan Qureshi: > The coolest DHTML calendar i saw is: > http://students.infoiasi.ro/~mishoo/site/calendar.epl > > and its pretty simple to set up. Wow. Definitely the coolest yet, and it also works in Konqueror (3.1). Now, someone should try to put that into a tag :) > Affan -- Chris (SCPJ2) > > - Original Message - > From: "N.B.Bopanna" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, April 05, 2003 11:17 AM > Subject: Re: CALANDAR [CLIP!] === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
