And looking through the examples, it does indeed look like the "right" thing to
do is to just set up the InitialContext, not knowing if the password is correct
or not, and then throw an exception on remote method invocation if it isn't
correct. Yippee!
Am I the only one who things this is a aw
My conclusion so far:
To do a login, first create an InitialContext using a plain old
org.jnp.interfaces.NamingContextFactory as the initial context factory. On the
server side, have a bean called "LoginCheck" or something, which takes a
username and password as args, and returns boolean. On
Ok, now I am finding out more: it seems like the security check doesn't happen
until a secured method is invoked, and if the security check fails, it just
throws an exception. This seems ridiculous, but that's what I'm finding in
docs like this:
http://www.awprofessional.com/articles/article.a
This system is madenning. Who could write a whole security infrastructure but
not provide a way for a user to do a simple username / password login like
people have been using for the past several decades? All I want is to be able
to log in and use JNDI to look up remote objects, but if the pa
And I found out the problem: The thread died because some jar wasn't in the
path. This is bad for a thread to die silently, and it is a bug in Java, but
oh well, I got that fixed.
Now I have the whole thing working as long as the password is correct for the
login. This is big progress. But w
I found out what was happening, sort of: the thread that's creating my
InitialContext just silently dies. I don't get it. The thread itself
collapses. I put:
InitialSystem.out.println("start");
| Context context = new InitialContext(properties);
| System.out.println("done.");
I see the "
