Fresh on the heels of working with Marc Ritter of Wimba, I spent this week in Vancouver working with the developers of SiteMaker (www.gvcsitemaker.com) to do an initial integration of SiteMaker into Sakai using a prototype version of IMS LTI 2.0. Jonathan presented this approach in his SiteMaker talk at the the Newport Beach.
Chuck Hill of GVC did a great job on the SiteMaker side. We produced a really simple user interface that mimics YouTube's approach - "cut and paste this bit" to make this as simple as possible. The user never has to touch any XML. Jonathan Maybaum of UM deserves the credit for the clever UI design - he always tries to think about things from the user perspective and he wanted it as simple as possible.
We also implemented the shared secret security with message signing with SHA hashing. We spent some time thinking about how to improve the security further.
The code modifications to SiteMaker really support all of the UI including needed persistence and the code is complete and checked into the trunk of SiteMaker.
Here are some screenshots of the SIteMaker Configuration Screens
SiteMaker Access Configuration
SiteMaker Configuring Remote Participant Access
I ended up building a new Sakai JSR-168 portlet that is unique to LTI-2.0 to make it much cleaner and simpler than LTI 1.0 - this new portlet is now in SVN here:
https://source.sakaiproject.org/contrib/sakai-portlets/trunk/
Here are some Sakai screenshots:
Sakai Configuration Screen
Sakai Launching SiteMaker using LTI in the frame set portal
There is more work to be done and the LTI specification is still being developed so this code will need to evolve over time - but this much progress is a testimate as to how much simpler Learning Tools Interoperability 2.0 is when compared to IMS Tools Interoperability 1.0.
At the last IMS meeting, a lot of progress was made on IMS LTI 2.0 - I am now very excited about this spec and have pretty much switched my efforts from IMS TI 1.0 to IMS LTI 2.0.
The key is the amazing work and investment on the part of Wimba (www.wimba.com). Marc Ritter of Wimba has done some super work - he did a great demo of an BlackBoard building block working with Wimba to pull Wimba into Blackboard - they are also working on a Moodle Module as well.
Not wanting to be left out when cool code is starting to work - I worked with Marc to connect Wimba into Sakai using his early version of LTI 2.0. Here are screenshots:
Wimba Running in Sakai using LTI 2.0
Wimba running in BlackBoard using LTI 2.0
This is very exciting - more soon on making Sakai and SiteMaker working together using LTI 2.0.
The Mac Air is the first time in recent memory where I went to a computer with less. Less disk - less screen real estate, less plugs, and nicely - less weight.
Here are my notes.
My biggest problem was that my home directory was too large to fit on the new laptop's hard drive - too much video editing, many copies of Sakai source code, etc.
My plan is to use both computers all the time with the Air being my portable computer and the MacBook Pro being my "Desktop" - the MBP will do video capture and editing and heavy development. Also the MBP will be the only one I run Parallels on to do PC stuff - mostly teaching tutorials and testing.
So the first thing is to expand the hard drive of the Air. I went out and bought two new disk drives. (1) A USB-powered SimpleTech 320GB Black Cherry (320 Juicy Dripping Gigabytes) for $140 at Best By and (2) a 500GB Maxstor full-size USB drive for $120 at Office Max - all on sale Saturday morning.
I am going to use the 320 GB bit to hold the less-accessed bits of my home directory and my development files - this way I can do development on either platform by moving a little disk back and forth.
On my old Mac Book Pro, I had been using TimeMachine all along to another 320GB USB drive. I needed to get my directory smaller. So first I make a copy of my entire /Users/csev directory onto the little USB drive with a simple drag/drop of the whole thing - folders and all.
Then I make a tar and gzip back up of my home directory to the new 500GB MaxStor - I tar first and then GZIP later when I have lots of time.
cd /Users
tar cf /Volumes/500GB/csev.tar csev
cd /Volumnes/500GB
gzip csev.tar
The tar was just an "emergency" second complete copy backup before I started whittling down my home directory.
Then I picked large parts of my home directory that were the new "stuff that will live only on USB" and then deleted them - using rm -r (trash looked like it would take days). I got my home directory down to about 30GB.
Then I plugged in the TimeMachine disk into the MBP and asked for a backup to start immediately (nice feature on the task bar that was recently added in an update).
Then I plugged in the TimeMachine Disk into my Air and ran the MigrationAssistant and restored it all. 30 GB took about 2 hours - but I had coffee and was busy formatting my family windows PC because of a hard disk crash so I was having fun.
By the way - I got wireless MigrationAssistant to start - it said it would take 18 hours and 41 minutes for 30GB - and then 30 minutes later - it still said 18 hours and 41 minutes - hence the us of the disk to do the transfer.
After MigrationAssistant finished the restore flawlessly, I fired things up and logged in on my newly migrated account on the Air - it was very nice. Desktop was fine - My dock looked just like the other computer - all was well - I connected the USB version of my home directory and compiled all of Sakai - flawless.
The only post-migration issue was that Mail wanted to reindex my inbox - this made me a bit nervous. It might be related to a rocky transition from 10.4 to 10.5 which I blame on how my home directory was set up.
http://www.dr-chuck.com/csev-blog/000381.html
But I went ahead and did it - the mail rebuild took about 20 minutes - and worked flawlessly. My iTunes and iPhone found each other as if nothing had changed.
All together - a very uneventful transition with a neat way to split my heavy duty bits of my home directory into the USB drive for easy transport back and forth between my "Laptop (Air)" and my "Portable Desktop (Mac Book Pro)".
I moved my book folder to the middle of my desktop to remind myself to start writing now that I have a cool light laptop with a better battery.
The OSP group was discussion options for workflow and Mark Breuker opened up the topic of using IMS Learning Design to solve workflow problems. While I have not discussed this much except with a few pals - using IMS LD as workflow a pet idea of mine.
So I wrote up this response.
I have felt for a very long time that we should use IMS LD as the workflow core of Sakai. With a couple of comments and caveats:
- IMS LD is more than just workflow - it contains some workflow and a simple language to express trigger conditions and a name space for triggers, etc. - this is the part of IMS LD that I would take and implement.
- I wish CopperCore could be pulled in - I bet we could get a non-GPL version if we asked nicely. I don't think that we need all of what CopperCore is - we need some bits and pieces that implement the general workflow bits. The good news is that we could look at CC and redo the bits if the license could not be worked out.
- I think that we need to keep the IMS LD workflow bits separate from the IMS LD loader and player - this is where people kind of get religious and want to argue about IMS LD's "pedagogy" - this is a fun argument which is endless - particularly because it is not technical. I think that it is a flaw in the IMS LD spec that these things are mixed together in the same spec - it has limited the uptake of LD because many people look at the pedagogy first and have a negative or non-positive reaction - then they look no further and miss the real nuggets of value in the spec.
- I am guessing that if we were to start to try to use the workflow bits of IMS LD - we should expect to find places where improvement is needed - this is cool - we should expect to extend where needed and then feed back those improvements into the IMS LD spec.
The overall issue here is that it is not as simple as the sentence "Use IMS LD for workflow." This will take quite a bit of thinking, iteration, and resources to make it happen in my opinion. The problem is that no one will pay for this as best I can tell because there is so much up front investment before there is real payoff - it is simpler to whip up some ad hock workflow and solve the itch of the moment in something like portfolio, resources, melete, assignments, or mneme. Because then with a pretty fixed bit of work - the immediate needs are met and the cost-benefit to the stakeholders is reasonable - but we keep pushing back the time that a general purpose workflow solution is deeply integrated into Sakai.
Taking on a general workflow in Sakai requires a long-term commitment that does not have the immediate payoff that most of the resources working on Sakai are not willing to invest at this time.
Many others have many opinions on Workflow in Sakai. This is only *my* personal opinion.
I just came up with that one and wanted to write it down. I am about to end my hippie phase of growing my hair long and go back to the short hair cut. So now I will once again match my pictures on the web. It is easier to get a haircut than to update all of my profile pictures around the web.
The MIT Open Courseware project is a success at producing reusable learning materials for public consumption. As the impact of Open Courseware is broadened and more institutions provide open courseware materials, we will need to find ways to organize dynamic learning around those materials involving participants inside classrooms, outside of classrooms, and a mixture of both. Specifically, we will need to create global learning communities and support the ability of their members to work through materials collaboratively. As part of an effort to explore possible next steps beyond Open Content, we are taking a novel approach to teaching university courses where all of the course materials and participant interactions are done in the open. In these courses, anyone can join and participate in the learning community utilizing Sakai. Course materials are produced and published immediately - each participant is presented with one of three views determined on the basis of their relationship to the university course. (1) A public view available to anyone with an Internet connection and a browser. These participants see all the course material, but do not see or participate in the discussion or email interactions. (2) A learning community member view is available to anyone (including the general public) using a University of Michigan Friend account to join the course site. These participants engage in the course materials and the interactive tools. (3) A student view is available to students formally enrolled in the class. The only difference between the student view and the learning community view is that the students have access to an assignments tool which allows the submission and grading of assignments and exams. This poster will describe our experience using this approach in a masters-level class and an undergraduate class, and discuss the implications of our experience for teaching future classes.
Charles Severance and Stephanie D. Teasley, University of Michigan
I got the following question:
I think I'm most interested in what "stretching Sakai" to be a portal
would look like, a clearer picture of what the challenges and
solutions would be. Do you know someone in the community who is
trying to take this tack?
Here is my answer.
This could be two things:
(1) stretching Sakai to completely function *within* a portal such as uPortal - use uPortal's layout AuthZ, etc
Because we promised this in the Mellon grant - I thought abut this for *years*. All my attempts failed - for lots of reasons - mostly because the CMS and Portal are just different beasts and one cannot contain the other. As best I can tell other than some exec types that saw this as sharing commonality and improving efficiency (this is sensible at a high level) - there was zero on-the-ground interest for this as best I could tell. Toward the end of the Sakai funding of uPortal we had a small group meeting where we worked all the details to make it possible to have uP 3.0 (sandbox) function as a LMS using Sakai tools. But there was never any interest in either technical community in working on this. Further - the portal community did not want an LMS becoming part of their portal. They have good technical reasons frankly. It really comes down to scalability - Portal folks want to scale to lots of clicks so they don't want portlets with 10MB non-sticky sessions and they don't want their portal JVMs to crash because an emedded application has a memory leak. The portal guys mostly want to pull RSS, XML, and JSON and show it in their rectangle - so they can be the dynamic bookmarking source for the campus like FaceBook. They can tune such a system nicely and keep unchanged release-wise for years because all the flexibility is in uploaded XSL style sheets (since they are not modifying data). The don't want Sakai in their JVM any more than they want Peoplesoft in the uPortal JVM. Other issues like class loaders and frequency of upgrade of a CMS application also give the portal teams fits.
(2) stretching Sakai to function *as* a portal - effectively replacing uPortal
When we added JSR-168 support to Sakai - I began to imagine that Sakai could function as a simple organizational / small enterprise portal - I knew that Sakai would never challenge uPortal as an enterprise portal. The Sakai community would never make the significant investment needed to add the needed enterprise features that uPortal frankly already has in a very tasty form. Enterprise portal use cases are about eyeballs and getting content in front of eyeballs.
However I have strongly felt that in time, Sakai could function as a simple, basic workgroup portal - replacing a small Mambo, Drupal, or Joomla install for example. A few others follow me in this thinking - it is mostly Anthony (eat our own dogfood) and the research application folks like NCIBI where they have a single multipurpose server that meets both the outreach and collaboration needs. I wrote this up a while back:
https://source.sakaiproject.org/svn/reference/trunk/docs/architecture/sakai_workgroup_portal.doc
This approach has a long way to go - mostly uphill - I think it is a valid but small use case - I don't put a lot of time in his use case - but I make a little progress here and there. Making the iFrame portlet frameless is one example of how Sakai can become a better "portal". Another example is improving the RSS (news) tool to have more options to make it "pretty".
---------
When we put JSR-168 into Sakai - it was not my primary purpose to advance either of these use cases. I see JSR-168 support as a way to share functionality between enterprise portals and a CLE like Sakai - JSR-168 is one of Sakai's supported plugins. uPortal has its iChannel portlets and JSR-168 plugins. Also remember that there are portable and non-portable JSR-168 portlets. Most rich portlets in uPortal depend on uPortal specific APIs and conventions. My goal for JSR168 support in Sakai was to support the simpler *portable* JSR-168 portlets - not the more complex non-portable JSR-168 portlets.
I have been developing a set of portlets that work in Sakai, uPortal, and GridSphere just for my own interest and to learn how to make portable portlets. Here are those portlets:
https://source.sakaiproject.org/contrib/portlets/trunk/
JSR-168 also provides a standard way to have multiple interactive independent rectangles on the same screen like our home page in Sakai. So for example if we had resources - we should rewrite all the synoptic tools as portlets *immediately*. The home page would then lose its frames in an instant! The nice thing is that the Velocity/Jetspeed portlets that came from CHEF have the exact same data model as portlets - I am slowly working on a shim that might allow all of the velocity tools to become portlets and thus become iFrame-free. I am laying the foundation for generalizing the switch of Velocity tools in Sakai to JSR-168 - starting with my experiments with the iFrame tool. Helpers are an issue. So my next tool to portletize might be the mail tool.
All a bunch of work for which I simply have too little time :)
I am preparing to merge SAK-11544 into the trunk - I invite folks to take a look at the code and give a shout out if they see any "gotchas".
The code structure in this branch is a little strange because I wanted not to disturb broadly used APIs so that I could produce a patch version for post-2.5 and post-2.4 without spewing tiny API changes over a bunch of modules - to ease QA concerns for folks who want this in patch form.
I have cleaned up the APIs in question in SAK-12837. SAK-12837 is already done and committed in trunk. So when I merge SAK-11544 into the trunk it will be laid out a little differently and much more cleanly than the patch version in the branches below.
However the code that does all the work to page in SQL will be exactly the same as what is in these branches and the pattern will be the same.
It is a simple concept - do paging in SQL rather than in memory. Previously the mail tool read all the messages into memory and kept them in the session for *every user* - for sakai-dev this is 25K messages which would be 25- 50MB per user in session - ick.
The work also makes it so that a reindex of a site with a large mail archive does not crash the system.
This work makes *no* changes to data model - it just uses the current data model as efficiently as possible.
You will also notice that in the branches - there is still debugging - this will all be removed before my final patch versions for 2.5 and 2.4 are produced and will be removed before the trunk merge - they are there for you to see what is going on and to make some tests if you like.
This code has been tested by Tony Atkins (2.5) and Thomas Amsler (2.4) with good performance improvement - and no more servers out of memory / overloaded sessions. Stephen Marquad will help test the trunk code after merge.
So unless you have some strong concerns or see something that should be improved - I will start moving the two patch versions and the trunk version to final release - removing all debugging and then doing a final round of tests.
One final question to consider (perhaps in a different thread) is whether this should go into 2-5-x and then into 2.5.1? There is a slight functionality change in this code - when the MailTool detects that there are too many messages to efficiently sort by subject or from, it gives an error saying "too many messages to sort by subject". So that is a functionality change. The functionality only goes away above an admin set limit of messages in the archive. And frankly, the UI that folks saw in these large archive sites was likely a traceback anyways :)
It has been suggested to put this in 2-5-x - I agree on the grounds that it keeps servers from crashing. We can set the property to a high number like 1000 messages so the functionality reduction is almost never seen - at the cost of chunky sessions - just like the current situation. But if folks feel that it should not go into the 2-5- branch - I am totally cool with that - less work for me :)
Feel free to pore over the code and the JIRA.
http://bugs.sakaiproject.org/jira/browse/SAK-11544
Instructions for patching 2.5 or trunk
rm -rf db message mailarchive search
svn co https://source.sakaiproject.org/svn/message/branches/SAK-11544/ message
svn co https://source.sakaiproject.org/svn/mailarchive/branches/SAK-11544/ mailarchive
svn co https://source.sakaiproject.org/svn/db/branches/SAK-11544/ db
svn co https://source.sakaiproject.org/svn/search/branches/SAK-11544/ search
/Chuck
Open Source Learning Management systems like Moodle and Sakai are becoming an increasingly significant segment of the LMS market. Open Source systems are adopted at all levels from young children to higher education and life long learning. While it is nice to get software for free - the ultimate impact of these systems will be how they change our thinking about teaching with technology. Most of the commercial LMS systems are based on a very structured model of teaching and learning with technology from the late 1990's. However products like Sakai and Moodle are increasingly pushed to function in a Web 2.0 / Facebook oriented world - where the learning is brought naturally into a student's multi-tasking and very busy life at the right point in that student's life. By allowing those that teach and use these systems to have greater influence over the capabilities of these systems - the open source systems naturally evolve toward the real needs of teaching and learning. Having two or more strong entries in the Open Source LMS space insures that both products continue to innovate over time. And in particular there is increasing cross-pollination of ideas in one community that naturally move into another community. Perhaps the Sakai community will think of an innovation first and then Moodle community will improve on it or vice versa. With open source philosophy at the core of the communities developing and maintaining these systems sharing of ideas and innovations in pedagogy is as natural as sharing source code. While each community is very proud of their particular value, these communities tend not to feel that any one community "owns" any one innovative idea.
I used Oracle for the first time in my life today - thanks to help from David Haines - it was not nearly as scary as I had imagined. David told me about henplus - which is the "vi" of database debugging tools - fits my style perfectly.
He walked me through my properties and getting connected to the database. Once connected - it felt a lot like any other database. Hey - put semicolons at the end.
The MailArchive paging code came together in three compiles. Here are some cool queries.
select * from ( select a.*, rownum rnum from ( select XML from MAILARCHIVE_MESSAGE where (CHANNEL_ID = ? ) order by MESSAGE_DATE desc ) a where rownum <= 20 ) where rnum >= 11
Note that the rows start from 1 - unlike the LIMIT in HSQL or MySql - where the rows start from zero. But all in all pretty straightforward.
Generally when you are doing podcasts using Sakai you end up doing uploads using webdav because the files are so large - they end up busing the single file upload limit in the Resources tool.
I have become increasingly unhappy with the Apple's Web Dav client built into Mac OS/X 10.5. It seems to be always downloading all the time - I am guessing that perhaps my operating system is trying to show me little preview icons in my finder view - so it downloads 300MB of data each time I mount the Dav drive.
Whatever the cause - Mac's incessant unnecessary downloading was making my uploads unreliable - so I switched to Goliath.
Goliath makes up loads much nicer - it is a simple tool - it only retrieves information when you do something - more like a smart FTP. The built in support for Dav is using DAVFS - which is faking a real disk using webdav. This leads to some extra load on the server.
However Goliath marks the Mime-Type of the file as text - Yikes! My students download the podcasts and see gibberish in their browsers or end up with files with a suffix of .txt and Quicktime won't play them! Grrr.
The Sakai Resources tool comes to the rescue - thanks to a feature added for OSP a long time ago, you can control the MIME-type of an uploaded file.
Go to Resources - find the file - and in the Actions menu (yay Harriet, Jim and the whole resources 2.4 re-design team) - find the Edit Details option.
Scroll down and change the MIME Type to application / octet-stream - save the properties - and viola - browsers save them properly - players play them - they end up with the right suffixes. All is well.
This week was really dominated by Teaching so I was only able to slip a few hours in on the weekend to work on MailArchvie performance.
I pretty much unbroke the MailAction.java bits - mostly making the single message view work again with the new focus on not reading all the messages into memory.
My next steps are doing the Oracle variants of the database limit stuff and testing. Then I make an initial back-port to 2.4 and have Thomas do some testing for me. Then it is on to cleanup and final testing of the post 2.4 and post-2.5 branches.
Then it is time to move this toward trunk and clean up bits of the Storage API while I am at it.
Teaching in a Web 2.0 world is a new experience for me. People pick technical things up so quickly that this saying summarizes my feelings about teaching technology:
"In teaching, I no longer have a goal to know more than my students and impart my knowledge to them - my new goal is to get my students to the point where they know more than me as quickly as possible."
Wow - busy few days. I built three small distributions of Ruby on Rails 1.2.6 for use in my course. There is support for Windows and Mac OS/X 10.4.
The basic idea is to come up with a distribution that works from a USB drive for students working in a lab as well as a really simple distribution that does not mess with your system configuration and it can be put anywhere in a directory structure including on a shared file server.
Then I built printed documentation for each of them and a podcast for each version to walk my students through the installation process.
This whole thing is available at:
Have fun.
The tricky bit is in this setup script (I kind of nicked the idea from Instant Rails and then improved on it). This script sets up all the necessary environment variables to point the path and Ruby runtime to wherever the script is running from.
This leads to a bit clunky interface as you have to run this script every time you open a command window - but after teaching Rails for a while I have learned that students learn to love the command line interface and trying to hid the real world from them is a disservice. Students learning command-line for the first time are a little uncomfortable - but after a few days they are command line wizards.
The essence of the script is setting the parameters - here is the one that uses AFS space and sets all the paths to somewhere deep in AFS space so it is a 500 byte install if AFS is mounted already :) But the essence of the script can be adapted to any environment.
This also tells the environment variables that Ruby listens to:
HERE=/afs/umich.edu/user/c/s/csev/Public/html/teachrails/rte-mac/
if [ -r $HERE/ruby/bin/ruby ] ;
then
echo Setting up Ruby Environment using AFS
export DYLD_LIBRARY_PATH=$HERE/ruby/lib/
export GEM_HOME=$HERE/ruby/lib/ruby/gems/1.8
export PATH=$HERE/ruby/bin/:$HERE/ruby/bin/:/bin:/sbin:/usr/bin:/usr/sbin
export RUBYLIB=$HERE/ruby/lib/ruby/:$HERE/ruby/lib/ruby/1.8/:$HERE/ruby/lib/ruby/site_ruby/1.8:$HERE/ruby/lib//ruby/1.8/universal-darwin8.0/
export RUBYGEMS=$HERE/ruby/lib/ruby/site_ruby/1.8
ruby --version
rails --version
else
echo
echo '******* Error ******'
echo Unable to find AFS space with ruby-mac installation
echo $HERE
fi
Feel free to tell me how confused I am - some of this was guesswork - just keep adding paths to variables until it worked. Someone wiser than me can clearly improve on this.
Pretty much useless information - warning - this might mess things up.
gem environment
RubyGems Environment:
- VERSION: 0.9.4 (0.9.4)
- INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8
- GEM PATH:
- /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8
- /Library/Ruby/Gems/1.8
- REMOTE SOURCES:
- http://gems.rubyforge.org
cd /Library/Ruby/Gems/1.8
rm cache/*
rm sourcecache
rm gems/act*
rm gems/rails*
rm specifications/act*
rm specifications/rails*
This is from Ian - I am sure that it will make more sense when the time comes for me to use it :)
https://source.sakaiproject.org/svn/portal/branches/post-2-4
When you want to merge from trunk into a working copy of the branch. do...
to get the copy point do
svn log --stop-on-copy https://source.sakaiproject.org/svn/portal/branches/post-2-4
then merge will be
svn merge -rxxx:HEAD https://source.sakaiproject.org/svn/portal/trunk .
where xxx is the last copy point revision
into the working directory, followed by a commit.
Playing with MySql and the MailArchive Performance Fix.
getSummarizableReference
getSummarizableReference
dbReadLock
udhcp-macvpn-972:~ csev$ mysql -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3 to server version: 5.0.20-max
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> create database sakai default character set utf8;
Query OK, 1 row affected (0.00 sec)
mysql> grant all on sakai.* to sakaiuser@'localhost' identified by 'sakaipassword';
Query OK, 0 rows affected (0.00 sec)
mysql> grant all on sakai.* to sakaiuser@'127.0.0.1' identified by 'sakaipassword';
Query OK, 0 rows affected (0.00 sec)
mysql>
http://confluence.sakaiproject.org/confluence/display/DOC/Install+Guide+-+DB+%282.4%29#InstallGuide-DB%282.4%29-create
Just add this:
hibernate.dialect=org.hibernate.dialect.MySQLDialect
vendor@org.sakaiproject.db.api.SqlService=mysql
driverClassName@javax.sql.BaseDataSource=com.mysql.jdbc.Driver
url@javax.sql.BaseDataSource=jdbc:mysql://localhost:3306/sakai?useUnicode=true&characterEncoding=UTF-8
username@javax.sql.BaseDataSource=sakaiuser
password@javax.sql.BaseDataSource=sakaipassword
validationQuery@javax.sql.BaseDataSource=show variables like 'version'
defaultTransactionIsolationString@javax.sql.BaseDataSource=TRANSACTION_READ_COMMITTED
cp ~/dev/keepzips/mysql-connector-java-3.1.11/mysql-connector-java-3.1.11-bin.jar ~/dev/jakarta-tomcat-5.5.9/common/lib/