I've now packaged all my classes in the JAR file which is supposed to contain only my login code.
But now it's complaining that it can't find any of the spring classes.
So, does this mean I should package the spring, hibernate and all the other jars within this thisSiteLoginCode-1.0.jar
Does that mean I should rename the supporting jars (ex spring-1.0.jar) and put them in the /repository/login/jars/ directory? Then put each of them as a dependency above the Login code dependency?
Is there something else I should be doing?
Probably, but it's difficult to tell what without knowing more about what you are doing now. Can you post your geronimo plan?
On Mar 22, 2006, at 9:46 AM, EricCho@kryos.com wrote:
Thanks for the help..... but as with most things....."2 steps forward... 1 step back"
As you suggested, I put the security gbean at the end of my web deploy plan (geronimo-web.xml) and I put the login dependency at the top of the web app plan since it is just a single web app.
This surely beats having a separate deploy plan for the security realm.
At any rate, now when I attempt to go to the login page I get a series of NoClassDefFoundErrors. I figure its because the class doesn't exist in the JAR file. So, I tried adding the class it's complaining about into the JAR, but after every addition, it complains about another. Shouldn't it be looking for the class in the WAR if it doesn't find it in the dependent JAR?
It should, but due to the way the web classloaders in 1.0 and trunk work, it won't :-( This is fixed in the (currently taken apart into small pieces spread all over the floor, i.e. not working) 1.1 branch.
Do you recommend I just JAR up all the classes?
yes, at least until 1.1 is available.
Note: I do have the context priority classloader set to false in the web deploy plan.
That's probably going to help things work :-)
On Mar 21, 2006, at 10:40 AM, EricCho@kryos.com wrote:
I think I've made some headway.... although I'm still having problems.
Here's the latest.....
In the thisSiteLoginCode-1.0.jar I have the loginModule and custom userCallback classes (and a custom exception).
In my custom loginModule, I create a callback array:
Callback callbacks = new Callback;
callbacks = new NameCallback("Enter user name");
callbacks = new PasswordCallback("Enter password",true);
callbacks = new UserCallback();
then I ask the callbackHandler to handle it....
Then it goes into the loginCallBackHandler and I iterate through the callback array
for (int i=0; i < callbacks.length; i++)
if (callbacks[i] instanceof NameCallback)
else if (callbacks[i] instanceof PasswordCallback)
else if (callbacks[i] instanceof UserCallback)
throw new UnsupportedCallbackException(callbacks[i]);
It gets through i = 0 , then i=1 but when i =2 it seems as though "callbacks instanceof UserCallback" doesn't work.
I put some debug code in there (System.out.println(callbacks.toString());) and it does show the appropriate class name.
So, I'm wondering if perhaps when the original UserCallback was instantiated and put into the callbacks array, it was the class from the separated jar file. And now when it does the instanceof, is it possible that it's referencing the UserCallback in the packaged WAR file?
yes, that is definitely a possibility. If you have contextPriorityClassloading=true (I think that's the default) that is almost certainly happening.
Has anyone else had a problem with this?
yes, in various ways. At least some fixes for it will be in 1.1.
Should I not be including the JARed classes in the WAR?
I think that will help a lot. I'm not exactly sure how many plans/configurations/application parts you have here. If you have a single web app what I would do is combine everything into one plan: take the gbean configurations out of the console-generated plan and put them at the end of your web app plan, and put the dependency at the beginning of your web app plan, and take the login module jar out of the WEB-INF/lib. This should make very sure that you login module classes are only loaded in one classloader.
If this is not practical, you need to make sure that the login configuration is loaded as a parent of your application. You can do this by including something like
where the login configuration has configId="foo/bar/42/car"
You can probably see why I think having only one plan is simpler :-)
I hope the syntax here is sufficiently accurate, I've been immersed in 1.1 where we have significantly changed the syntax....
hope this helps
The console does not yet let you specify a JAR where it should look
for the login module code -- there's an outstanding JIRA issue for
this. So what you need to do is configure things in the console (but
don't have it try a login), and then instead of deploying the security
realm right there, have it generate a plan for you, put the
<dependency> element David described into the plan (at the top, just
inside the main element), and then save that to a file and deploy it
on the command line like:
java -jar bin/deployer.jar deploy my-security-plan.xml
On 3/21/06, David Jencks <email@example.com> wrote:
> On Mar 20, 2006, at 6:50 PM, EricCho@kryos.com wrote:
> Since I've got a custom login module I've went ahead and packaged the
> module, callback, callbackHandler and principal into a jar and threw it into
> the /repository/login/thisSiteLoginCode-1.0.jar.
> Assuming this is the geronimo repository, it should be in
> The plan that defines the GenericSecurityRealm and the LoginModule gbean
> needs to include
> Then I created a securty realm using the console defining, the module class,
> control flag to "requred", servier side to "servier side" and "no" support
> advanced mapping.
> Restarted the server and when I try a login, I get the following exception:
> Unable to instantiate login module
> further down:
> Caused by: java.lang.ClassNotFoundException:
> I checked the common libraries and the jar seems to be there...... so what
> am I missing.
> I'm not exactly sure what the console does, so I recommend checking the
> plans it generates and posting them if the above doesn't work.
> david jencks