Re: Using UseBean tag in weblogic 4.5.1
Is your bean in a package? I've used JSP's w/ Weblogic 4.5.1 and you must
put the fully qualified name in the useBean tag. For instance:
package com.simple.example
public class try1{
}
<@page import="com.simple.example">
Even though you put the package in the import statement, you still have to
put the entire thing in the class property of useBean. One would think that
because you've imported the class, you could just reference the try1 class
in the useBean tag, but this is not the case. At least, not in Weblogic
4.5.1. Perhaps this will help?
-ryan
-Original Message-
From: vaidyanathan_g
To: [EMAIL PROTECTED]
Sent: 2/25/00 9:04 AM
Subject: Using UseBean tag in weblogic 4.5.1
Hi ,
If I have a bean as follows
public class try1{
private String userName;
public void setUserName(String str1)
{
userName = str1;
}
public String getUserName()
{
return userName ;
}
}
In the jsp I am using it like this:
<@page import=try1>
This gives an error that it is not able to find the class try1 in the
working directory for jsp. But the class is available in the directory
specified in the classpath (servletclasses directory itself).
This code works fine in jswdk-1.0 and orion. Anypointers for this
problem?
Thanks
regards,
Vaidyanathan G
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
Re: OFFTOPIC: RANT
I completely concur with Bradley on this one. Like him, I don't proclaim to be a servlet or JSP expert. I'm learning about these technologies along with everyone else. However, I'm very tired of having my mailbox filled with messages from this list from folks who have obviously not done 10 minutes of research before posting their question. Sun's JSP area (http://java.sun.com/products/jsp/) has a host of documents, all free of charge, that address many of the simple questions posted to this list. Go out there, download these documents and READ THEM. Plunk down $30 for a JSP/Servlet book. Read it. Educate yourself. If there are concepts, ideas or methodologies that are unclear or up for discussion, please post them here. But all these syntax and "how do I..." questions that have been answered a thousand times are starting to become annoying. You know, for being a young person I hate to rant like a bitter old man. But it's just very frustrating when the same questions are posted to this mailing list over and over and over. All of which could have been answered had the person spent 10 minutes and done some research on their own time instead of wasting everyone elses. -ryan -Original Message- From: Bradley McLain To: [EMAIL PROTECTED] Sent: 3/23/00 10:10 AM Subject: OFFTOPIC: RANT i guess i am beginning to agree with those who complain about the number of silly questions posted to this list. i'm no hotshot java dude myself, and i get a lot out of much of the 'elementary' discussion that takes place here. but it does get a bit discouraging to go through dozens of 'what is a webserver?' questions each morning. in the spirit of trying to help those who are coming over to the java platform, i've tried to help with what little i know, and i know others have too. but doesn't anyone know how to use the web? a little searching answers all of those questions without inundating busy people. you don't know how to set up your servlet container? don't know how to reference a bean? don't know what a bean is? can't understand form post? getting funny 'class not found' errors? don't know where to place a servlet? etc., etc., etc. do what i and many others did. lurk on the forums, check the faqs, puzzle over it a bit, search list archives, look through several books, read the apis, try several angles, call/email the company you got the software from. then, if nothing else works, post a question. post only as a last resort. as i understand it (please correct me if i'm wrong), a list like this one is for discussions such as the model 2 stuff that has been going back and forth, or for advanced programming questions that are genuinely hard to find answers for. alright, now i'll go get my coffee and calm down.. bradley mclain >From: Brenda Tung <[EMAIL PROTECTED]> >Reply-To: Brenda Tung <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Date: Thu, 23 Mar 2000 15:41:12 +0800 > >hi everyone, > >I've just started reading up on JSP. I'm quite confused by what's the >difference between java servlets and JSP. And where do java beans come >into the pictures. Do i just use the use bean tags in JSP ? > >Thank you all for your kind attention. > >Brenda > >=== >To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff >JSP-INTEREST". >Some relevant FAQs on JSP/Servlets can be found at: > > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets __ Get Your Private, Free Email at http://www.hotmail.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: Browser back button
> Hello! > Is it possible to disable the browser back button( using > Javascript,etc.)? No, you can't disable the back button. There is a read-only Javascript attribute for getting access to the button, but you cannot disable it. > Or atleat force execution of a user's function on > click of browser > back button? The problem is that I have a file on submit of > which, I get a > second file. But I don't want the user to resubmit the first file, by > entering into it using the browser back button. Is setting a flag and > checking it each time one enters the file, the only alternative. > Thanx > Divya. You can try to turn caching off on the first page (say first.jsp) and at the top check to make sure the first page is called from some other page (index.jsp). If first.jsp is called from any other page besides index.jsp, redirect and don't load the page. This of course assumes first.jsp at no time gets cached on the user's machine. ryan > > == > = > To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets > === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
JSP/JavaBean/XML Architecture
Hello all,
We're developing a Java site for a customer and I wanted to get some
feedback on the architecture we're using. Specifically, how is anyone else
out there getting their XML data from a database into the JSP page?
>From the top down, our architecture is:
JSP
JavaBeans
Middle-layer Java classes
Database-layer Java classes
Database
All SQL queries that return ResultSets get parsed into an XML Document at
the Database-layer and returned up the chain to the JavaBean. Once the XML
is in the JavaBean, we've used three different approaches for rendering its
data on the JSP.
Originally we were parsing the XML into a Vector and passing this back to
the JSP, which would iterate through the Vector and display the results.
This worked OK, but there was overhead converting the XML to the Vector,
passing the entire Vector back to the JSP and then casting back to the
appropriate type.
Solution #2 was to parse the XML into a Vector but leave the Vector in the
Bean. We wrote an iterator method in the Bean that wrapped the Vector,
something like:
public Object getNextAddress(){}
>From the JSP you would call JavaBean.getNextAddress() on the Vector to get
the next item in the Vector, cast it to the correct type and then use it in
the page.
Solution #3, the most current solution, is to pass the XML back to the
JavaBean and wrap the XML document with an iterator method in the Bean. Same
idea as above, but
public Object getNextAddress(){}
gives me the next ElementNode in the XML Document, from which I can pick out
the pieces of data I need to display on the page using
ElementNode.getAttribute(). When getNextAddress() returns a null (ie there
are no more Elements in the XML), I quit my looping on the JSP page. It's
the simplest and most elegent way I've found thus far of getting the XML
data into a JSP page.
Is anyone else doing this? If so, how are you doing it? I think I'm on the
right path but it's always good to have some peer feedback. Thanks.
ryan
Ryan Shriver - Consultant
The Whitlock Group eBusiness Solutions
[EMAIL PROTECTED]
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: Model 2 & 3 Architecture
> -Original Message- > From: Andrew S Tomlinson [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 09, 2000 9:17 AM > To: [EMAIL PROTECTED] > Subject: Re: Model 2 & 3 Architecture > > 3. building XSL files is a radically different proposition to > building HTML > (and by extension JSP). This means that you lose the > *division of labour* > that assigns UI construction to (presumably less *technical*) > Web Designers. > Again I have found this to be the case for anything other > than the most > trivial of cases. > > How does this compare to others' experiences? This is a very important point for developers in shops like mine where we break down the development of a project to different units. Our Creative department meets with the customer and hammers out the "look and feel" of the site. The deliverable from creative is HTML pages that the customer has approved. This is a seperate thread from Application Development. Developers like myself focus on putting the data in the pages. We can take the HTML pages produced by creative, changed their extension to .jsp, add actions to the tags and drop in tags and send it down the line. We tried the XSL approach about 6-8 months ago and got burned. The problem was that after creative produced the HTML that met the customer's approval, developers had to deconstruct the HTML and reproduce it again using XSL. Lots and lots of development hours were spent trying to reproduce with XSL what was already there to begin with, a workable HTML document. The gains of going the XSL route didn't outway the costs in development hours. Just my .02. ryan === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: Model 2 & 3 Architecture
I've been following this discussion and find your example below interesting. I've also been reading about tab librarys and just downloaded JRun's most recent one (ships with JRun 3.0 CR1). The library isn't tied to JRun specifically, but there's a feature that might help out with this. I haven't actually used the library, but from reading the docs perhaps it'll help. Let me explain. The example again... > Let's see if I get the whole process with a very small sample > > 1.- You give the XML file to the designer > Name="John Doe"> > > > > > 2.- The designer wants to produce the following output > > Name:John Doe > Account 0112030$ > Account 02-50$ > > > 3.- So he produces this XSLT > > > Name: /> > > > > > > Account > > > name="bgcolor">red > > > > > > > 4.- The JSP you would like to produce would be something like.. Assuming you have customer.xml (#1 above) and customer.xsl (#3 above) as files in the same directory, you could use the xslt tag to perform the XSL transformation of the xml. The syntax would be: <%@ taglib uri="/WEB-INF/taglib.tld" prefix="stl" %> If customer.xml was dynamically produced, you could use this alternative syntax: There's other tags/tools for getting ResultSets into XML documents that could produce the above code, but that's another topic :-). Since all of your display logic and format are in the xsl file, there's no need to redo these in the JSP. Changing of logic would require a change to your xsl file but not your JSP file, since it's just putting the xml on the page. Might this be a viable option? ryan === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: Weblogic & JavaBeans
Make sure you're doing the following: 1. Import the Bean's package: <%@ page import="com.package.whatever.myBean" %> 2. Refer to the Bean's entire package in the useBean: 3. Make sure the above mentioned class is in your classpath. I have known Weblogic 4.51 to not find classes that are in .jar files in my classpath. So if your class is in the .jar you might explode it out into a directory that's already in your class path. Do these things and it should work ok. You don't need to worry about the weblogic.properties file for simple JavaBeans. However, for debugging you might want to add the following in the JSP section of weblogic.properties: weblogic.httpd.initArgs.*.jsp=\ keepgenerated=true There will already be other initArgs, but adding keepgenerated=true to the end will keep the servlet.java file that was generated when compiling the JSP page. You can look at this servlet's source and see how it's trying to find the class. Enjoy. ryan > -Original Message- > From: Kaylon Daniels [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 22, 2000 1:03 PM > To: [EMAIL PROTECTED] > Subject: Re: Weblogic & JavaBeans > > > Thanks Ken, > > I have read most of the properties file info, there is a section on > configuring > the JSPServlet. I have the server configured to run JSP's, > any JSP which > does not > access a Bean via the useBean tag works fine. I just can't > get it to locate > my beans. > Is there any special configuration within the properties file > for locating > javabeans? > > -Original Message- > From: Wasetis, Ken [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 19, 2000 6:15 PM > To: [EMAIL PROTECTED] > Subject: Re: Weblogic & JavaBeans > > > There is a section in the weblogic.properties file. One > section for EJBs > and one for servlets. The properties file is pretty well > documented. It > should be located in the \weblogic folder. > > -Original Message- > From: Kaylon Daniels [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 19, 2000 2:51 PM > To: [EMAIL PROTECTED] > Subject: Re: Weblogic & JavaBeans > > > Does anyone know how to get the Weblogic 5.1 server > to "find" Javabeans? I continue to get ClassNotFoundErrors > whenever I try to load a JSP with a javabean. > I am using a standard tag. > I have set the java classpath using the BEA Systems online > help examples. > > Any insight would be helpful. > > Kaylon D > [EMAIL PROTECTED] > > == > = > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets > > == > = > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets > > == > = > To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets > === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
