in reply to Re: CGI::Session Compilation Issues
in thread CGI::Session Compilation Issues

My apologies. Never copied the example part of the question I had.
#declared earlier using our $session = new CGI::Session("driver:File", undef, {Directory=>$perl_sessions}); #--- Storing the session id (this is where the browser complains $wCookie = $query->cookie(-name => "wweb", -value => $session->id);

Replies are listed 'Best First'.
Re^3: CGI::Session Compilation Issues
by Corion (Patriarch) on Feb 22, 2010 at 20:15 UTC

    So $session is not defined. Either you didn't show the relevant parts of the script, as in, a self-contained, runnable, minimal script that reproduces the error, or the $session you're using to print is not the $session you declared further above. Also, read the CGI::Session documentation for ->new. It says Constructor. Returns new session object, or undef on failure. So, if there is an error when constructing the session, it might return undef. Maybe because your $perl_sessions directory does not exist.

      I included the line where the constructor is called. The only thing regarding $session above that is the declaration of the variable. If I run the perl script by itself on the same server the perl script works fine, compiling the script using PDK and running it from the same directory doesn't. It gives the error I previously posted. The directory does exist, checked and it works for the perl script. Do you know what dependencies there are for CGI::Session?

        CGI::Session likely is installed properly, as your script compiles. As you still didn't provide a self-contained, minimal script that exhibits the behaviour, I can't reproduce your problem. Also, you still keep the value of $perl_directory to yourself, so I can only guess that it is either a relative path, and your webserver does not have the same current directory as you have when you run your script through the shell, or that it is a permission issue and the user your webserver runs as does not have the same permissions as you have on $perl_directory. But then again, you seem bent on blaming this on a CGI::Session compilation issue again and again, so maybe you'll find the solution there.