Re: [jetty-users] JDBCSessionManager with Jetty 7

[Erki Harand <erki@xxxxxxxxx>]

Hello,

Thankyou Jan for your replies. I have managed to get
MemcachedSessionManager ( http://code.google.com/p/jetty-session-memcached/
) working with current Jetty 7 trunk .

I did have to make some changes to MemcachedSessionManager source code. The
problem with classloading was already solved in JDBC session manager by a
nifty little class called "ClassLoadingObjectInputStream" . If you take a
look at JDBCSessionManager.loadSession you can see an example of its usage.
So I just "ported" it to MemcachedSessionManager . In the proccess I had to
replace the default net.spy.memcached.transcoders.SerializingTranscoder -
in order to plug the "ClassLoadingObjectInputStream" into it, but that was
not really too hard. It seems to me that the original
MemcachedSessionManager only worked when putting common java types (String,
Integer, etc.) in session or maybe the classloading rules were different on
Jetty 6.

Additionally the MemcachedSessionIdManager.idInUse was not implemented
(always returned false). I just wrote some lines of code for it:
--------------
@SuppressWarnings("unchecked")
public boolean idInUse(String id) {
if (id == null) { return false; }
synchronized (MemcachedSessionManager.JSESSION_MONITOR) {
List<String> jsessions = (List<String>)
_memcached.get(MemcachedSessionManager._JSESSIONS);
if (jsessions == null) { jsessions = new LinkedList<String>(); }
if(jsessions.contains(id)) {
	return true;
} else {
	return false;
}
}
}
--------------



Regards,
Erki




On Sat, 09 Jan 2010 14:32:13 +0200, Erki Harand <erki@xxxxxxxxx> wrote:
> Hello,
> 
> 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
> HttpSession .
> 
> 
> PS: I have also been experimenting with "parentLoaderPriority" (
> http://docs.codehaus.org/display/JETTY/Classloading ) with no results .
> 
> Regards,
> Erki
> 
> 
> 
> 
> On Sat, 09 Jan 2010 12:04:20 +1100, Jan Bartel <janb@xxxxxxxxxxx> wrote:
>> Erki,
>> 
>> 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.
>> 
>> Jan
>> 
>> 
>> Erki Harand wrote:
>>> Hello,
>>> 
>>> Thanx for responding. This issue was due to our configuration mixup of
>>> several contexts. I got it solved now (by only having one context :-) .
> I
>>> got the JDBCSessionManager working now on Oracle (had to change the SQL
>>> code a bit). Since what we really needed is MemcachedSessionManager I
>>> begun
>>> experimenting with this:
>>> http://code.google.com/p/jetty-session-memcached/
>>> . I have it compiled and running but I get a Memcached serialization
>>> error
>>> when trying to serialize the session object:
>>> ------------
>>> 2010-01-08 18:41:37.950 WARN
>>> net.spy.memcached.transcoders.SerializingTranscoder:  Caught CNFE
>>> decoding
>>> 692 bytes of data
>>> java.lang.ClassNotFoundException:
>>> ee.ekool.session.BaseESchoolSessionContext
>>> 	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
>>> the
>>> 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
>>> cannot
>>> be cast to ee.ekool.session.BaseESchoolSessionContext" . Well thats
>>> weird.
>>> 
>>> 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
> that
>>> 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
> of
>>> 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
> right?
>>> 
>>> If I am right on both accounts then what is the logic of this: I could
>>> mix
>>> a (Memcached)SessionIdManager (Server level) and (JDBC)SessionManager
>>> (Webapp level) in one running Jetty instance? Aren't the
> SessionIdManager
>>> and SessionManager implementations kind-of dependant on each other?
>>> 
>>> That brings me back to my current problem. I am loading Memcached JAR
>>> from
>>> lib/ext/ on Jetty server startup (because thats when the
> SessionIdManager
>>> 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
> error
>>> above. Any help would be highly appreciated.
>>> 
>>> 
>>> Regards,
>>> Erki
>>> 
>>> 
>>> 
>>> 
>>> 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
>>> Eclipse
>>>> wiki
>>>> http://wiki.eclipse.org/Jetty). 
>>>>
>>>> Maybe post the full stack trace and you config files to the list so we
>>> can
>>>> check 
>>>> them too.
>>>>
>>>> cheers
>>>> Jan
>>>>
>>>> Erki Harand wrote:
>>>>> Hello,
>>>>>
>>>>> I have followed the instructions here:
>>>>>
>>>
> http://docs.codehaus.org/display/JETTY/Session+Clustering+with+a+Database
>>>>> .
>>>>> After some troubles (JDBCSessionManager doesn't play well with
Oracle)
>>>>> I
>>>>> have got this thing running. But when I connect to our website I get
>>>>> the
>>>>> following warning in stderr:
>>>>> ---------------------------
>>>>> 2010-01-06 18:29:24.263:WARN::/index_en.html:
>>>>> java.lang.ClassCastException:
>>>>> org.eclipse.jetty.server.session.HashSessionManager$Session cannot be
>>>>> cast
>>>>> 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
> trying
>>>>> to
>>>>> cast it. How can I get a stack-trace in this situation? Any other
good
>>>>> suggestions?
>>>>>
>>>>>
>>>>> PS: I am working with Jetty 7 SVN trunk version and ultimately will
>>>>> want
>>>>> to
>>>>> get the memcached session manager (
>>>>> http://code.google.com/p/jetty-session-memcached/ ) working on Jetty
> 7.
>>>>>
>>>>> Regards,
>>>>> erkulas
>>>>> _______________________________________________
>>>>> jetty-users mailing list
>>>>> jetty-users@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>> _______________________________________________
>>> jetty-users mailing list
>>> jetty-users@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/jetty-users
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-users