[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jetty-users] JDBCSessionManager with Jetty 7
- From: Erki Harand <erki@xxxxxxxxx>
- Date: Sat, 09 Jan 2010 14:32:13 +0200
- Delivered-to: firstname.lastname@example.org
- User-agent: RoundCube Webmail/0.2.2
This is quite hard to do for us and it seems a bit "backwards" for me,
because BaseESchoolSessionContext is totally "userland" code here. It is
just a custom class (consisting of other custom classes) that we put in
HttpSession with setAttribute() . Putting it in lib/ext would equate
putting important parts of our webapp there and thus splitting up our
webapp source code.
Is there some other possibility here?
If there isn't I guess we'll have to refactor the classes we are keeping in
PS: I have also been experimenting with "parentLoaderPriority" (
http://docs.codehaus.org/display/JETTY/Classloading ) with no results .
On Sat, 09 Jan 2010 12:04:20 +1100, Jan Bartel <janb@xxxxxxxxxxx> wrote:
> If you've put the BaseESchoolSessionContext into WEB-INF/lib then it
> can't be seen by the classes that are loaded from lib/ext due to the
> restrictions on the webapp classloader.
> Try putting all your SessionManager, Session and SessionIdManager impls
> into lib/ext, along with memcached libs.
> Erki Harand wrote:
>> Thanx for responding. This issue was due to our configuration mixup of
>> several contexts. I got it solved now (by only having one context :-) .
>> got the JDBCSessionManager working now on Oracle (had to change the SQL
>> code a bit). Since what we really needed is MemcachedSessionManager I
>> experimenting with this:
>> . I have it compiled and running but I get a Memcached serialization
>> when trying to serialize the session object:
>> 2010-01-08 18:41:37.950 WARN
>> net.spy.memcached.transcoders.SerializingTranscoder: Caught CNFE
>> 692 bytes of data
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>> at java.security.AccessController.doPrivileged(Native Method)
>> BaseESchoolSessionContext is the class that we keep our session data in
>> HttpSession. Since the class was not found I tried including it (and all
>> the subclasses that were necessary) in the MemcacehdSessionManager JAR.
>> Then I got an error that "ee.ekool.session.BaseESchoolSessionContext
>> be cast to ee.ekool.session.BaseESchoolSessionContext" . Well thats
>> Please somebody correct my understanding of the problem:
>> Right now I am loading the MemcachedSessionIdManager in jetty.xml wich
>> configures org.eclipse.jetty.server.Server . This leads me to belive
>> there is exactly one (Memcached)SessionIdManaged per Jetty instance
>> possible and all contexts share the same SessionIdManager. Am I right?
>> And I am loading the MemcachedSessionManager from jetty-web.xml in one
>> my contexts. And from jetty-web.xml I am configuring the
>> org.eclipse.jetty.webapp.WebAppContext class and there should be as many
>> WebAppContext classes as there is contexts defined for Jetty. Am I
>> If I am right on both accounts then what is the logic of this: I could
>> a (Memcached)SessionIdManager (Server level) and (JDBC)SessionManager
>> (Webapp level) in one running Jetty instance? Aren't the
>> and SessionManager implementations kind-of dependant on each other?
>> That brings me back to my current problem. I am loading Memcached JAR
>> lib/ext/ on Jetty server startup (because thats when the
>> is defined). My SessionManager that is in one of my running contexts is
>> also using this Memcached JAR. But for some reason the Memcached library
>> cannot "see" the classes that are defined in my webapp and thus the
>> above. Any help would be highly appreciated.
>> On Thu, 07 Jan 2010 09:15:00 +1100, Jan Bartel <janb@xxxxxxxxxxx> wrote:
>>> Hi Erki,
>>> Turn up debug logging may help (instructions are over at the Jetty
>>> Maybe post the full stack trace and you config files to the list so we
>>> them too.
>>> Erki Harand wrote:
>>>> I have followed the instructions here:
>>>> After some troubles (JDBCSessionManager doesn't play well with Oracle)
>>>> have got this thing running. But when I connect to our website I get
>>>> following warning in stderr:
>>>> 2010-01-06 18:29:24.263:WARN::/index_en.html:
>>>> org.eclipse.jetty.server.session.HashSessionManager$Session cannot be
>>>> to org.eclipse.jetty.server.session.JDBCSessionManager$Session
>>>> And the server replies with "404 Not Found".
>>>> >From this log I can not get any hints why something is trying to use
>>>> HashSessionManager (instead of JDBCSessionManager) and why it is
>>>> cast it. How can I get a stack-trace in this situation? Any other good
>>>> PS: I am working with Jetty 7 SVN trunk version and ultimately will
>>>> get the memcached session manager (
>>>> http://code.google.com/p/jetty-session-memcached/ ) working on Jetty
>>>> jetty-users mailing list
>> jetty-users mailing list