[Deploying Sakai] Sakai fails to load.

[John Bush]

If you think of Sakai as not necessarily an application that runs
inside Tomcat, but as an application that comes bundled with Tomcat it
might make more sense, although we don't actually distribute it that
way.

Sakai has its own specific services with their own classloaders that
augment Tomcat's own classloader which look to isolate tomcat's
bootstrapping from things that might be shared across web applications
or isolated to web applications.

These services have their own classloaders in order that each service
might rely on its own version of dependencies (to a point anyway).

I think its probably a valid criticism to say that we haven't as a
community provided the best distribution that is production ready, or
interweves well with linux packaging solutions.  Practically speaking,
I think that is really because every organization has its own
operational procedures and deployment practices, so putting a bunch of
effort into creating such a distribution has never gotten a lot of
focus, because it might not be used for anything but demo's or
prototypes, etc.  At once point my company made an InstallAnywhere
installation package, and that is all it was ever used for.

Even if we made a something that worked with Debian ootb there would
still be issues of how to you upgrade a Sakai instance into an
existing Debian package.  Clean the env, persists the necessary config
changes etc.  That's why I like to think of Tomcat as something that
is part of Sakai, not a separate component, its interwoven at a fairly
deep level.  There's a point where package management tools stop
(rpm,yum, apt) and configuration management starts: bash scripts,
puppet, chef, or whatever you fancy...

On Tue, Jan 21, 2014 at 4:25 PM, Steve Swinsburg
<steve.swinsburg at gmail.com> wrote:
> Cool. All of that was from memory and written hasty, glad you could decipher
> it :)
>
> The component directory is a special area of Sakai that holds the API
> implementation code. Spring knows to look here to find the classes. This is
> so that individual web apps can communicate with each other via the API.
>
> There was a post by Zach a while back about the specific issues with the
> distributed versions of Tomcat. I don't think this is ever going to change
> though since it is so specific so the go is to just use the archived
> distributions rather than the packages.
>
>
> On Wed, Jan 22, 2014 at 9:25 AM, Gesh hseG <gesh at gesh.uni.cx> wrote:
>>
>> Did what you said, with a few changes:
>> - In step 4, I checked out
>> https://source.sakaiproject.org/svn/sakai/trunk, as the link you provided
>> was not a maven project.
>> - In step 8, I passed ../logs/catalina.out to tail. Again, I suspect you
>> missed a component.
>> - Since tomcat was complaining about a lack of memory, I created the
>> setenv.sh file as directed in step 5.7
>> Apart from that, it works!
>> Thank you very much. I can't begin to express the relief that this is
>> finally over.
>> Gesh.
>> P.S. Why won't the distributed version of tomcat work with Sakai?
>>      That is to say, why does Sakai depend on having the components
>> directory
>>      and why aren't there instructions in the wiki explaining how to
>> reverse the patching
>>      done by distributions that breaks the components directory?
>
>
>
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"



-- 
John Bush
602-490-0470

** This message is neither private nor confidential in fact the US
government is storing it in a warehouse located in Utah for future
data mining use cases should they arise. **