Jeff Pollet

Ranch Hand
+ Follow
since Jul 20, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jeff Pollet

Thanks for the suggestions, Bear. You've been helpful every single time I've posted here, even when you have to school me!

I'm in a bit over my head, obviously, but the article you linked to is full of great information. I'll start there and work on it some more.

Thanks again for your help.
14 years ago
JSP
Hello all,

I have the feeling that the answer to my question is pretty simple, but I've been scouring JR for quite a while now, not to mention googling till my fingers have bled, and I can't find the answer to this question.

I have a jsp page with a form that has a dropdown menu. I want some options in the dropdown to appear to some users (based on their login to the webapp) but not to others. I can do this as a scriptlet, but I'd rather not. I also know how to do it using the jstl <req:isUserInRole> tag:


If I can get away with doing this without having to add the request-taglib library, I'd be happy. Is there another way of doing this sort of in-page authentication that filters content for different users in a jsp page? pageContext.request looks promising, but it doesn't seem to be able to get the userID...what am I missing?

If it matters, I am using Tomcat 5.0.

Thanks in advance for any help!
14 years ago
JSP
I recently upgraded our container from Tomcat 4.x to Tomcat 5.5.20. Everything now seems to be working fine (thanks to some help from the javaranchers!) but now I have noticed a problem during the login process--and here's the strange thing: The problem only occurs in Firefox 2.0, not in IE6!

I'm using the the j_security_check form action, j_username and j_password type of authentication. So, when the user goes to the index.html page, she gets redirected to a login.jsp. After logging in, she is then redirected back to index.html, if the login is correct. The user's session ends if it times out, or if she closes the browser window.

But here's what's happening in Firefox:
1. User is redirected to the login page (so far so good).
2. Correct login is entered, but, instead of a redirect, the page stays exactly the same.
3. If, at this point, the user enters the index.html url, she'll be taken to that page as if she had logged in correctly.
4. If, at this point, the user tries to login again, the following familiar error crops up:

5. If, at this point, the user enters the index.html url into the browser, she is redirected as if she has logged in correctly.

So, obviously, the login is *working* on some level, but the user isn't being redirected to the index page. Again, this is only happening in Firefox, not in IE6.

Furthermore, Firefox doesn't seem to be stopping the session if she just closes the browser window (rather than logging out on our logout screen). Again, IE6 doesn't have this problem. According to the tomcat logs, the login in occurring just as it does for IE...there isn't an output to the log when the redirect happens in either case, so it's hard to tell what's going wrong.

I know this is a sort of vague problem, but has anybody else had problems with Firefox in this way?
14 years ago
Bear, I swear I posted here as a last resort, because you've always been so helpful and I had an intuition that there was something simple and stupid I was doing wrong. Sure enough, I was. Just discovered that there were more than one of the jsp pages in question, and that I had been editing the wrong one.

Sorry. Thanks for your time.
14 years ago
JSP
sorry about that, I was trying to generalize it. It's actually startRow attribute in one case and value attribute in another.
14 years ago
JSP
Hello all,

Using:
Tomcat 5.5.20 (moving from 4.1)
JSTL 1.1
JSP 2.4

I'm getting the following error:
According to TLD or attribute directive in tag file, attribute X does not accept any expressions

Now, I've researched a lot here at the ranch, and lots of other people have had this problem, but I think I have ticked off the things they were doing wrong, and those things are in place. That is, I've included the correct JSP version in my web.xml, I'm using the jstl.jar, I've gotten rid of the TLD folder altogether (because everything shoudld be in jstl.jar), I don't have any taglib elements in my web.xml, I've made the taglib header change (i.e.<%@ taglib prefix="sql" uri="http://java.sun.com/jsp/jstl/sql" %> instead of <%@ taglib prefix="sql" uri="http://java.sun.com/jstl/sql" %>.

The other thing is: I have LOTS of other attributes with expressions in other jsp pages in this webapp, and they work fine. I'm only getting this error with two different pages, and I can't figure out why. (The problem lines in question involve both <c:out> and <sql:query>, if that matters.)

I also tried the simple page that Bear suggested two years ago to somebody else:

...and it works just fine.

Some ideas I have:
--Somehow Tomcat is caching my old TLD's, which of course won't work with JSTL 1.1. But I've cleared out the work directory in between tries and that doesn't help. Does Tomcat cache TLD's in some other way? If so, can I flush them?
--Actually, that's the only idea I have.

Any help would be greatly appreciated!
14 years ago
JSP
Ulf--
Thanks so much for your timely response.

Upon further research, you're absolutely right, of course. Thanks again, and thanks for the link!
Hello All.

Very new to Java, and learning from various books all at once, wondering if somebody could help me with one line of this code snippet, which is an HTTP request:


My question is: What purpose does the last line of code serve?

Thanks for any help in advance.
I figured out what was going on, in case anybody else runs into this. Starting with 5.5, the <tomcat-home>/conf/web.xml file has listings set to 'false' by default (under <servlet>), which explains why my listings weren't coming up.
14 years ago
I posted about this in the apache-tomcat forum, but now I realize maybe it's more appropriate to put it here.

I want a jsp page which shows a part of the directory structure of the server my webapp lives on. Currently, as was set up before I came onto the scene, this was done by creating a separate webapp for each directory structure that we wanted to show.

So, if we want the page to show C:/logs, we include a link in our main webapp to the /logs webapp. That webapp has a context but no real components (no class files, no jsp pages or the like). Click on the link and you're taken from the main webapp to the 'log' webapp, which has as it's docBase "/log".

Is there a better, simpler way to do this? Does this question even make sense?

Any help would be greatly appreciated.
14 years ago
JSP
Hello all,

I am slowly migrating a simple set of webapps from Tomcat 4.1 to 5.5.20.

In one of our webapps, we have pages which allow users to look at particular directories through the browser. In order to do this, we created separate webapps, each with their own contexts and context files. So, the main webapp has a link to webapp2, which has it's own webapp2.xml context file that gives "/webapp2" as the context path and "somedirectorystructure/directory2" as the docBase. Click on the webapp2 link, and you see a page that shows directory2.

I'm not sure if this is the only way to accomplish this, but that's how we had it in 4.1 and it worked just fine. Now, however, with 5.5.20, with the introduction of the context.xml file, it seems that our various webapp.xml files aren't being used -- at least that's what I'm thinking because now when the user clicks on the webapp2 link, we get a 'requested resource /webapp2/directory2 not available' error.

Is there a way with 5.5.20 to provide multiple contexts? Or perhaps I just need to place them somewhere else? Or perhaps there's a better way to allow a user to see directories through the browser altogether?

Any help would be greatly appreciated.
14 years ago
This is probably way to late to help you but:

Did you install TC 5.5 as the Windows Installer Service? If so, TC can be started and stopped from the windows services menu (I only know this because I didn't want it installed as a service!). If you istalled the core from the .tar or .zip, then you should have the startup.bat and shutdown.bat scripts.
14 years ago
At the risk of inundating this forum with more newbie questions, I have yet another (thanks Ben for all of your help so far).

Once again, I am migrating a simple webapp from Tomcat 4.1 to 5.5.20. One problem I'm having now is at startup--from the catalina log:

SEVERE: Exception processing Global JNDI Resources
javax.naming.NamingException: Could not load resource factory class [Root exception is java.lang.ClassNotFoundException: org/apache/tomcat/dbcp/dbcp/DataSourceConnectionFactory.class]



This problem (among others) is leading (I think) to a "No suitable driver" error in my webapp anytime I have a jsp that needs to get to my database. ( BTW, apparently, the MemoryUserDatabaseFactory class is being loaded just fine, as I'm able to login to my app and such, and there is no error on startup regarding that class.)

Thing is, this class is where it should be, within . And TC is loading other classes from that directory. I suppose it could still be a CLASSPATH problem, but why in the world would this jar not be part of Tomcat's CLASSPATH for loading?

What other reasons for not loading the resource factory class (besides CLASSPATH problems) might I investigate?

Any help would be very much appreciated. Thanks!
14 years ago
Ben--
You're right, of course. What confused me was this (from this part of the documentation):

The valid attriutes for a <Resource> element are as follows:


auth Specify whether the web Application code signs on to the corresponding resource manager programatically, or whether the Container will sign on to the resource manager on behalf of the application. The value of this attribute must be Application or Container. This attribute is required if the web application will use a <resource-ref> element in the web application deployment descriptor, but is optional if the application uses a <resource-env-ref> instead.

description Optional, human-readable description of this resource.

name The name of the resource to be created, relative to the java:comp/env context.

scope Specify whether connections obtained through this resource manager can be shared. The value of this attribute must be Shareable or Unshareable. By default, connections are assumed to be shareable.

type The fully qualified Java class name expected by the web application when it performs a lookup for this resource.



I guess I took "the valid attributes for a Resource element" to be all-inclusive. But, as you point out, the examples given have more than these attributes.

Thanks for your help.
14 years ago
Hello All,

I'm attempting to upgrade from Tomcat 4.1 to 5.5.20, and running into some trouble that I'm having a hard time figuring out. The newest problem is figuring out how to include my database resource properly. In the 5.5 documentation, it is strongly suggested that:

Please note that for tomcat 5, unlike tomcat 4.x, it is NOT recommended to place <Context> elements directly in the server.xml file. Instead, put them in the META-INF/context.xml directory of your WAR file or the conf directory as described above.



So, I'm attempting to put the <Resource> elements within the <Context> element in said context.xml. However, according to the 5.5 documentation, I'm only allowed to place auth, description, name, scope and type elements within the <Resource> element in the context.xml. So, whereas previously I defined my database resource in the server.xml file like so:

I am now supposed to define it this way in the context.xml:

or, something *like* the above. I'm only allowed a few elements, so my resource definition ends up being:


So, where the heck does the *rest* of the context/resource information go? Where do I place the rest of my elements, i.e.


I get the feeling I'm missing something big here. Any help?
[ October 25, 2006: Message edited by: Jeff Pollet ]
14 years ago