RE: Session Persistence in WebSphere -- JAVA400-L

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: joe@zappie.net
+---