I went thru the 1 hour Tomcat setup.
Then I went thru the SAF implementation. The admin function works just fine.. but when I go to edit the Roles using the admin interface.. I get a "HTTP Status 500 - Error retrieving attribute roles"
So I looked in the STDOUT.. and I found a SEVERE error during startup. It seems that they are related.
Here is the output:
Aug 5, 2005 12:42:49 PM org.apache.catalina.mbeans.GlobalResourcesLifecycleListener createMBeans
SEVERE: Exception creating UserDatabase MBeans for UserDatabase
javax.management.MBeanException: nested exception is java.lang.Exception: ManagedBean is not found with JzosRoleDatabase
java.lang.Exception: ManagedBean is not found with JzosRoleDatabase
at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:760)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:195)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:163)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:125)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:97)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2306)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
at java.lang.reflect.Method.invoke(Method.java:391)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)
Exception creating UserDatabase MBeans for UserDatabase
Which specific release of Tomcat are you running?
The error that you are getting seems to indicate that Tomcat can't find the MBean descriptor for the realm. Check the following document, and verify that there aren't any typos in the changes that you made to server.xml.
http://jzos.com/docs/saf.html
In particular, check that you changed the Listener tag to point to descriptors="/com/dovetail/jzos/tomcat/mbean-descriptors.xml"
Here's a relavent Tomcat document:
http://jakarta.apache.org/tomcat/tomcat ... howto.html
The error that you are getting seems to indicate that Tomcat can't find the MBean descriptor for the realm. Check the following document, and verify that there aren't any typos in the changes that you made to server.xml.
http://jzos.com/docs/saf.html
In particular, check that you changed the Listener tag to point to descriptors="/com/dovetail/jzos/tomcat/mbean-descriptors.xml"
Here's a relavent Tomcat document:
http://jakarta.apache.org/tomcat/tomcat ... howto.html
Per the instructions
http://jzos.com/index.html?http://jzos. ... omcat.html
I installed 5.0.28 of Tomcat.
I will check the file again.
I ended up re-installing Tomcat to get everything back to vanilla. The install to get up and running works very well.
On the SAF section though.. I have a question about a couple of the updates to the server.xml
1) in the section where there is
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" debug="0"/>
I am actually updating this entry to look like
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" debug="0" descriptors="/com/dovetail/jzos/tomcat/mbean-descriptors.xml"/>
Correct?
2) I am assuming that I will need to update the jzos-roles.xml with manager role as well.
BTW,
I want to express my thanks at having the documentation to run jzos and tomcat .. it is really nice. I am just starting to play with java on z/OS .. to see what it can do for us.
-Rob.
http://jzos.com/index.html?http://jzos. ... omcat.html
I installed 5.0.28 of Tomcat.
I will check the file again.
I ended up re-installing Tomcat to get everything back to vanilla. The install to get up and running works very well.
On the SAF section though.. I have a question about a couple of the updates to the server.xml
1) in the section where there is
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" debug="0"/>
I am actually updating this entry to look like
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" debug="0" descriptors="/com/dovetail/jzos/tomcat/mbean-descriptors.xml"/>
Correct?
2) I am assuming that I will need to update the jzos-roles.xml with manager role as well.
BTW,
I want to express my thanks at having the documentation to run jzos and tomcat .. it is really nice. I am just starting to play with java on z/OS .. to see what it can do for us.
-Rob.
Rob Schramm
1) yes, this looks right. Are you still getting the same exception? You are using JZOS 1.2.1, correct? Please double check that you have the right version of the jzos-realm.jar in your classpath and that it is not corrupted and contains the descriptors xml file. (A previous version of JZOS had a slightly different name for the descriptors file).
2) jzos-roles.xml maps Tomcat role names to SAF class/entities. So, yes, if you want to use the Tomcat manager role, you should add it to jzos-roles.xml and assign a SAF class/entity name to use for it. This would seem to me unrelated to your problem.
-- Is anyone else using SAF security with Tomcat 5.0.28? I believe that we tested it with that release, but Tomcat is not too careful about breaking their Realm apis between versions.
2) jzos-roles.xml maps Tomcat role names to SAF class/entities. So, yes, if you want to use the Tomcat manager role, you should add it to jzos-roles.xml and assign a SAF class/entity name to use for it. This would seem to me unrelated to your problem.
-- Is anyone else using SAF security with Tomcat 5.0.28? I believe that we tested it with that release, but Tomcat is not too careful about breaking their Realm apis between versions.
-
Guest
The warning message is because you probably have a web application that uses a security role without defining it. Here's a document that describes this, and the fix:
http://www.murach.com/dloads/jsps/jsps_tomcat-5.5.pdf
Can you be specific as to what was wrong with your SAF configuration to cause the original errors? If we knew what caused this / what you fixed, then we would know what to correct the next time.
http://www.murach.com/dloads/jsps/jsps_tomcat-5.5.pdf
Can you be specific as to what was wrong with your SAF configuration to cause the original errors? If we knew what caused this / what you fixed, then we would know what to correct the next time.
-
Guest
One of the reasons that I wanted to install Tomcat was to run JSPWiki http://www.jspwiki.org version jspwiki-2.2.28.bin.
1) I re-installed Tomcat
2) I updated the tomcat-users.xml for admin and manager roles.
3) Installed JSPWiki
4) Read your post ... and decided to re-read the instructions very carefully
5) made a copy of the server.xml as you suggested.
6) made sure all changes were exact. Last time I tried to introduce comments <!-- --> for certain items to maintain only one server.xml. This time I made no such attempt ( I think my comment attempt may have contributed to my problem)
7) the security role name "user" looks like it is from the JSPWiki.
I added the following to the web.xml for the JSPWiki application.
<security-role>
<description>administrator</description>
<role-name>admin</role-name>
</security-role>
<security-role>
<description>user</description>
<role-name>user</role-name>
</security-role>
Which effectively eliminated the error.
The wonderful part of the SAF implementation is that the Wiki pages now are globally viewable but only updateable by people with the proper SAF credentials.
1) I re-installed Tomcat
2) I updated the tomcat-users.xml for admin and manager roles.
3) Installed JSPWiki
4) Read your post ... and decided to re-read the instructions very carefully
5) made a copy of the server.xml as you suggested.
6) made sure all changes were exact. Last time I tried to introduce comments <!-- --> for certain items to maintain only one server.xml. This time I made no such attempt ( I think my comment attempt may have contributed to my problem)
7) the security role name "user" looks like it is from the JSPWiki.
I added the following to the web.xml for the JSPWiki application.
<security-role>
<description>administrator</description>
<role-name>admin</role-name>
</security-role>
<security-role>
<description>user</description>
<role-name>user</role-name>
</security-role>
Which effectively eliminated the error.
The wonderful part of the SAF implementation is that the Wiki pages now are globally viewable but only updateable by people with the proper SAF credentials.
Glad you were able to resolve all of your issues!
BTW, I like JSPWiki as well, although I usually don't run it on z/OS. How is the performance?
I agree with you that the SAF authentication and role-based security is terrific on z/OS. It allows you to effectively control security within your application while at the same time offloading the administration chores to somebody else
BTW, I like JSPWiki as well, although I usually don't run it on z/OS. How is the performance?
I agree with you that the SAF authentication and role-based security is terrific on z/OS. It allows you to effectively control security within your application while at the same time offloading the administration chores to somebody else
-
Guest
First time page loads are a bit slow... but I am running it on a tech lpar that is fairly constrained on cpu.
But other than that it seems pretty good.
I also changed the template on it to use the "Power of 2" template.
Just having the normal ID/password check is so much better than running the wiki on something else.
I wanted to run the wiki on z/OS as a demostration of compatibility. Additionally, to have the mainframe sysprogs use a wiki that is running on our platform.
But other than that it seems pretty good.
I also changed the template on it to use the "Power of 2" template.
Just having the normal ID/password check is so much better than running the wiki on something else.
I wanted to run the wiki on z/OS as a demostration of compatibility. Additionally, to have the mainframe sysprogs use a wiki that is running on our platform.