Navigation
User login
jsecurity tags and ehcache?
I have just completed a basic jsecurity implementation in a struts 2 web project. I based a lot of what I did on one of the spring examples and created my own default realm, user, & role classes. I have also downloaded and included the ehcache jar, and am simply using the default configuration for that.
However, I seem to be having problems with the jsecurity tags from time to time. Sometimes I'll reach a page that conditionally exposes parts of the JSP, depending on a defined role. I currently have 3 roles (STUDENT, STAFF, ADMIN), and have a JSP that conditionally shows a list of items (school applications) belonging to the user depending on their role. If they have the role of STUDENT then they only see their own applicaitons, but if they have STAFF or ADMIN then they can see all applications in the system. Below is a snippet of my JSP
<jsec:hasRole name="STUDENT">
...
show the student's applications in a table view
...
</jsec:hasRole>
<jsec:hasAnyRoles name="ADMIN,STAFF">
...
show a different table with all the application in the system
...
</jsec:hasAnyRoles>
What I'm seeing sometimes when I wait on a page and then continue, is that both of the tags fail and I get nothing.
I don't know if this is related to the ehcache or not, but when I refresh the page about 3-4 times after this happens, then I get one of the tables appropriate for the role of the user currently logged in as mentioned above.
Any suggestions or ideas?
Thanks,
TK
Share
Hi, could you please share this struts 2 project with us? I'd like to see how it works on MVC.
Thank you
Jack Stuard
Struts 2 project
Hi Jack,
I'm just now wrapping up the project that I'm working on, but when I get some free time (in about a week or so) I'd be happy to post a simple struts 2 project that utilizes jsecurity.
Todd Kofford
tkofford@ku.edu
jsecurity tags and ehcache?
TK - are there any errors in the logs that might provide a clue? Any chance you could put together a smaller test app that demonstrates the problem?
Here is what I keep seeing
Here is what I keep seeing in the logs that caught my attention and made me suspicious of ehcache. Keep in mind that I have done absolutely nothing with configuring ehcache including an ehcache.xml file, it's totally using defaults all the way through. Also, maybe on the test app, I'll have to see if I can dig up some time if nothing obvious surfaces.
WARN [TP-Processor12] ehcache.CacheManager.[] Jun/02 15:03:26 - Creating a new instance of CacheManager using the diskStorePath "/apps/tomcat/temp/jsecurity-ehcache" which is already used by an existing CacheManager.
The source of the configuration was InputStream java.io.ByteArrayInputStream@7691c0.
The diskStore path for this CacheManager will be set to /apps/tomcat/temp/jsecurity-ehcache/ehcache_auto_created_1212437006813.
To avoid this warning consider using the CacheManager factory methods to create a singleton CacheManager or specifying a separate ehcache configuration (ehcache.xml) for each CacheManager instance.
--TK
Ah, I've seen this
Ah, I've seen this before.
The defaults are fine if you're only running one application with JSecurity + EhCache. If you run more than one instance on the same machine/host, they'll try to point to the same location on disk for cached data.
I recommend two things:
First, disable ehcache entirely (don't include it in the classpath) as a quick test. If you see the jsec tags showing data every time, then we know for a fact is is an ehcache configuration issue. If ehcache doesn't even exist and then you see this issue, then there is a problem. We haven't ever seen this happen in production environments though, so I assume it is an ehcache issue. Please let us know what you find when doing this test.
If you then find out it is an ehcache config issue, then create an ehcache.xml file at the root of your classpath. You can use JSecurity's failsafe as a template.
(ours is in that package on purpose - yours will need to be at the root of the classpath).
In the copied file, change the
<diskStore path="java.io.tmpdir/jsecurity-ehcache"/>line to be something likejava.io.tmpdir/applicationName/jsecurity-ehcacheor maybeuser.home/.applicationName/jsecurity-ehcache. You shouldn't see any warnings any more.Regards,
Les
Thanks!
First of all, Thank you so much for the prompt replies to my issue. It's really refreshing to see quick (and detailed) replies to an issue that you're trying hard to resolve.
Secondly, mark this one as resolved. I removed the ehcache jars from my webapp and everything started working as expected again. I really appreciate the help.
Lastly, good job on jsecurity as a whole. It is a great package that packs a lot of power, and is easy to implement once the basics are understood. I am currently implementing it for the first time in a struts 2 webapp, but I'm thinking that it will become my de facto standard for implementing security in any of the applications that might have the need.
Thanks again,
Todd Kofford (TK)
tkofford@ku.edu
University of Kansas - IT
Hi Todd, Glad to help! I'm
Hi Todd,
Glad to help! I'm assuming the ehcache.xml file at the root of the classpath solved the problem? I'm assuming you're still using caching...
And thanks for the kind words - they're definitely the most rewarding thing about working on JSecurity ;)
Anyway, I hope all continues to go well. Please don't hesitate to drop by the forums or mailing lists if you need anything else.
Cheers,
Les
Hi TK, It seems that the
Hi TK,
It seems that the code snippet was truncated. Could you try again using < and > codes?
Thanks,
Les
Seems like you fixed it.
Seems like you fixed it. Thanks ;)
Yup, fixed it (the post not
Yup, fixed it (the post not the problem). Sorry.
--TK