You are viewing a plain text version of this content. The canonical link for it is here.
Posted to olio-dev@incubator.apache.org by Shanti Subramanyam <sh...@gmail.com> on 2009/11/10 17:11:18 UTC
Re: OLIO-40/Java - UsersResource.java compile
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: Shanti.Subramanyam@Sun.COM [mailto:Shanti.Subramanyam@Sun.COM]
> Sent: Monday, November 02, 2009 10:54 AM
> To: olio-dev@incubator.apache.org
> 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
>>
>>
Re: OLIO-40/Java - UsersResource.java compile
Posted by Kim LiChong <Ki...@Sun.COM>.
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: Shanti.Subramanyam@Sun.COM [mailto:Shanti.Subramanyam@Sun.COM]
>> Sent: Monday, November 02, 2009 10:54 AM
>> To: olio-dev@incubator.apache.org
>> 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
>>>
>>>
>