In case anyone is interested, I BELIEVE I found the issue (which ties in to my next little bugaboo). My JSPs were secured by an ACL, but my servlets were not. It seems that when you move from a secured component to a non-secured component, the session doesn't go with you (which makes sense, and it says so in the error log). That explains pretty much all the anomalies, including the "restoration" of the session when I went from the (unsecured) servlet back to the (secured) JSP. So now I'm happy, I think. All I have to do is secure my servlets, and everything will be both hunky AND dory. Right? Well, maybe. Here's my problem with that particular issue. This is more of an application thing than anything else, and I'll admit I haven't done all the research I did on the previous problem, but maybe somebody can save me some late night teeth-gnashing. I'm using the default application to do all my work. I haven't messed around with any deployment issues, haven't used any .servlet files (like the WebSphere examples use), and I'm going along quite happily. In general, my stuff works like this: In the UserData directory, under WebASAdv/default/hosts/default_host/default_app, there live two directories, "web" and "servlets". Up until now I've been stuffing all my servlets into "servlets", but I've been using subdirectories under "web" for my JSPs. At the same time, way up in ProdData/WebASAdv, I've also got the same subdirectories, where my HTML goes. Okay, at this point, I'm still a little confused why some things go into ProdData and some into UserData. I'm sure a good thorough reading of the manuals would tell me why, but I haven't needed to do that yet (those who are yelling loudly "RTFM!!", please let me know which is the best manual to read for this specific information - I'd really appreciate it). So far it's been no problem, because everything works just fine. Okay, now I realize that what I really need to do is secure my servlets. So, I'm thinking to myself that I can secure my servlets by putting them in a subdirectory underneath "servlets", and then attaching an ACL to that directory. Seems like a plan, no? No. Instead, when I attempt to execute a servlet thusly: http://myIP/servlet/test/MyServlet I get a rather nasty error: Root Error-1: test java.lang.ClassNotFoundException: test java/lang/Exception.(Ljava/lang/String;)V+1 (Exception.java:45) Oh snorkle. It seems that when I try to convince the servlet engine to use a subdirectory, he's thinks the subdirecory name is actually a class name (and I assume he's looking for an inner class "MyServlet" inside the class "test"). So am I going to have to add a new directory to the CLASSPATH for default_app in the servlet engine? Okay, I do that. Now, my servlets come up just fine with the following: http://myIP/servlet/MyServlet Notice that I don't have to specify the "test" subdirectory. I sense I'm coming to the home stretch. All I need to do know is secure the test subdirectory and I am home free, baby. I go into the administration instance and pop up my "Document Protection" display. I add the subdirectory "/servlet/test" and stop and start my HTTP server. I go in... and no protection. Doesn't even look twice at me, just hands over the servlet like I've got the keys to the kingdom. Not particularly secure. So I try the old way: http://myIP/servlet/test/MyServlet And it challenges me! And I answer the challenge! And I get the same old error: Root Error-1: test java.lang.ClassNotFoundException: test java/lang/Exception.(Ljava/lang/String;)V+1 (Exception.java:45 Dammit. This is tiring. Then I notice that the actual directory the servlets come from is not "servlet/test" but is instead "servlets/test" (gotta love those UNIX holdovers). Okay, let's try that instead. I protect that directory with an ACL. Restart my server. Try to access it... and I can. Sigh. So. Here I sit. Wondering how in the heck I can secure my servlets. It seems like the only way to have some secured servlets and some unsecured in the same application is to secure them by naming convention (that is, have a common prefix for all secured servlets). I guess the HTTP security is on the HTTP URL (which makes sense) and knows nothing about how the servlet engine translates that to an actual servlet class. But things would be so much easier if I could just create a subdirectory underneath my servlet directory and access that in the HTTP URL. http://myIP/servlet/subdir/ServletName That ought to work just fine, but it doesn't. Anyone know why? Ah well, that's life I guess. Joe +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: email@example.com +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.