That fixed my build errors, but for some reason none of the jersey .jars are included in the webapp.war file, but oddly asm-3.1.jar IS, so it doesn't work when I deploy, I have to copy the jersey jars over manually.
-----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, November 10, 2009 11:17 AM To: [email protected] Subject: Re: OLIO-40/Java Shanti, Unfortunately, your checkin for OLIO-40 overwrote the changes for my bug fix for OLIO 107. Did you apply your changes to the updated workspace? In any case, I'm reapplying my changes to your latest checkins. James: Wait until you see my checkin, then please update the WebappUtil.java class. If you are not on the svn commit olio alias, then you should be able to get your changes in about 15 minutes. I'll be committing shortly. kim Revision 831998 - (view) (annotate) - [select for diffs] Modified Mon Nov 2 18:20:05 2009 UTC (8 days ago) by shanti File length: 20954 byte(s) Diff to previous 831489 (colored) Fixes for OLIO-40. Extensive since primary key for PERSON changed to new field. Revision 831489 - (view) (annotate) - [select for diffs] Modified Fri Oct 30 23:42:00 2009 UTC (10 days, 19 hours ago) by klichong File length: 20561 byte(s) Diff to previous 822866 (colored) OLIO 107 - have to paginate the friends.jsp page as well, as well as the user profile page. Made the WebappUtil.getPagedList generic rather than just for SocialEvent. 408 shanti 831998 409 public static List<SocialEvent> getPagedList (List<SocialEvent> list, int index) { 410 klichong 773143 int size = list.size(); 411 int numPages = getNumPages(list); 412 if (size <= WebappConstants.ITEMS_PER_PAGE) { 413 return list; 414 } 415 416 int startIndex = index * WebappConstants.ITEMS_PER_PAGE; 417 if (startIndex > size) { 418 startIndex -= WebappConstants.ITEMS_PER_PAGE; 419 } 420 421 int endIndex = startIndex + WebappConstants.ITEMS_PER_PAGE; 422 if (endIndex > size) 423 endIndex = size; 424 425 shanti 831998 List<SocialEvent> slist = list.subList(startIndex, endIndex); 426 klichong 773143 return slist; 427 } > Hi James, > > I can reproduce your error. Since this is my checkin, let me take a > look. > > kim >> 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/a >> pps/webapp/src/java/org/apache/olio/webapp/controller/PersonAction.ja >> va >> >> 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.multipa >>> rt.FormDataBodyPart>> >>> >>> [javac] required: >>> java.util.Map<java.lang.String,com.sun.jersey.multipart.FormDataBody >>> Part> >>> >>> [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 >>>> >>>> >> >> >
