Re: OLIO-40/Java

Tue, 10 Nov 2009 10:48:44 -0800 

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/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

Reply via email to