I have just checked in jersey-multipart. Thanks for the catch.
Regarding UsersResource.java, I have fixed line 174 thus :
Map<String,List<FormDataBodyPart>> bodyList = multiPart.getFields();
This causes the compilation to go through.
Kim - I can't find any references to this class. Is it really being used
? If the above fix is okay, I'll check it in. But I don't see any way to
test it.
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
