Hi Shnati,
Thanks for fixing this. This is not used in the driver but part of the
JAX-RS services available for the person. I'll have to add
documentation on how to use/test this.
kim
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
