I double checked and re-synced, I have revision 831489 of that file. Still have the error.
Path: olio/webapp/java/trunk/ws/apps/webapp/src/java/org/apache/olio/webapp/controller/PersonAction.java Name: PersonAction.java URL: http://svn.apache.org/repos/asf/incubator/olio/webapp/java/trunk/ws/apps/webapp/src/java/org/apache/olio/webapp/controller/PersonAction.java Repository Root: http://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 834569 Node Kind: file Schedule: normal Last Changed Author: klichong Last Changed Rev: 831489 Last Changed Date: 2009-10-30 16:42:00 -0700 (Fri, 30 Oct 2009) Text Last Updated: 2009-11-10 10:07:48 -0800 (Tue, 10 Nov 2009) Checksum: 6abb3010d00467ebddd0d40b656b67a3 -----Original Message----- From: Shanti Subramanyam [mailto:[email protected]] Sent: Tuesday, November 10, 2009 8:30 AM To: [email protected] Subject: Re: OLIO-40/Java James, I believe you don't have the correct version of PersonAction.java - can you please re-sync ? Shanti James Zubb wrote: > a Couple of issues. > > 1. olio/webapp/java/trunk/ws/lib/jersey/jersey-multipart-1.0.3.1.jar > is missing from SVN (assuming that is the version you want) > > 2. I am getting these 2 errors when trying to build the app: > > bpp-actual-compilation: > [echo] Compiling webapp > [javac] Compiling 26 source files to > /root/olio/webapp/java/trunk/ws/apps/webapp/build/classes > [javac] > /root/olio/webapp/java/trunk/ws/apps/webapp/src/java/org/apache/olio/webapp/controller/PersonAction.java:127:getPagedList(java.util.List<org.apache.olio.webapp.model.SocialEvent>,int) > in org.apache.olio.webapp.util.WebappUtil cannot be applied to > (java.util.List<org.apache.olio.webapp.model.Person>,int) > [javac] List friendList = WebappUtil.getPagedList(list, > index); > [javac] ^ > [javac] > /root/olio/webapp/java/trunk/ws/apps/webapp/src/java/org/apache/olio/webapp/rest/UsersResource.java:174: > incompatible types > [javac] found : > java.util.Map<java.lang.String,java.util.List<com.sun.jersey.multipart.FormDataBodyPart>> > [javac] required: > java.util.Map<java.lang.String,com.sun.jersey.multipart.FormDataBodyPart> > [javac] Map<String,FormDataBodyPart> bodyList > =multiPart.getFields(); > [javac] > ^ > > > > james > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Monday, November 02, 2009 10:54 AM > To: [email protected] > Subject: Re: OLIO-40/Java > > Folks, > I have just committed all the changes for this. The changes are quite > extensive due to the fact that the primary key for the PERSON table had to be > changed. The changes are both to the webapp and workload directories. I > would really appreciate it if others can test this out as well. > > Thanks > Shanti > > Akara Sucharitakul wrote: > >> In kind of a hurry, I put together a fix for OLIO-40 for the Java kit. >> There are a couple of choices made without the best of confidence. >> Without thorough testing, we'll never know we're dealing with the >> right choice. >> >> I'm trying to conceptually stick with the original idea of processing >> the file uploads without saving to any file. I think it is a great >> idea, but presents a good amount of challenges. So we will insert a >> record with whatever we have in the request before the first uploaded >> file - in one transaction, in order to obtain the key (user or event >> id). Then we save the image into place and process the thumbnail at >> the same time. The complete record will be written in an update, >> complete with image locations. The address will be created and linked >> at update time (after the initial insert) just to be sure all the >> address information has arrived, and also to be sure we don't create >> the address twice and call the geocoder twice. >> >> If this strategy doesn't work, the alternative is to do the address >> and geocoder in the first create. We need to make sure the sequence >> the field arrives is so that the images and literature arrive last. >> The update needs to be narrowed down to just the image file (for >> which we don't have the file name at create) in the update - just >> like how we do it in php. >> >> Since I'm not going to be available for a week, I have to leave the >> patch up here for review and comments. Please feel free to test it >> out if you have the time. Let me know any fixes you make. I'll resume >> testing after I'm back. Again, any comments about this initial code >> as well as the strategy taken is most welcome. >> >> Regards, >> -Akara >> >>
