Re: Large response: Apache adaptor changing content-length header to Integer.MAX_VALUE
Hi Hugi, Yes, this is a known problem with the WO api. You cannot patch it… like we have done with NSArray in the past to get generics support. “Patching” means making another .java class with the same package name and loading it before Apple’s… In this case, patching won’t cure it because we need a “long” instead of an “integer” and there are several places where this API would have to change. The simple answer is to live with the 2GB limit. The longer answer… only by rewriting WO can you get around this, like TB is trying to do. AARON ROSENZWEIG / Chat 'n Bike e: aa...@chatnbike.com t: (301) 956-2319 On May 8, 2014, at 5:15 AM, Hugi Thordarson wrote: > Thanks, but it’s not that. Apache handles large files just fine, so the > problem seems to be with the WO adaptor. > > Cheers, > - hugi > > > > On 8.5.2014, at 09:09, Þór Sigurðsson wrote: > >> Rebuild Apache with: >> -DLARGEFILE_SOURCE -DFILE_OFFSET_BITS=64 >> >> And you'll be rollin' >> >> Með kveðju, >> Þór Sigurðsson >> Tölvunarfræðingur - Forritari >> Sími: 480-6000 >> >> >> >> Samgöngustofa - www.samgongustofa.is >> Umferðarstofa, Borgartúni 30, 105 Reykjavík >> >> On 8.5.2014, at 08:49, Hugi Thordarson wrote: >> >>> Hi all >>> >>> I’m attempting to stream a ~3GB file from a WO app. When I DirectConnect to >>> the app, the content-length header is correctly set to “3371573248”, but if >>> the response goes through the Apache adaptor (CentOS 5.5/Apache 2.2), the >>> content-length header is changed to “2147483647” (Integer.MAX_VALUE), >>> resulting in a truncated file for most clients. >>> >>> I just attempted to install the most recent compiled Wonder adaptor from >>> wocommunity org, but it doesn’t solve the problem. >>> >>> Anyone familiar with this? >>> >>> Cheers, >>> - hugi >>> ___ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/thors%40samgongustofa.is >>> >>> This email sent to th...@samgongustofa.is >> >> >> >> Fyrirvari á tölvupósti / e-mail disclaimer >> http://samgongustofa.is/fyrirvari/ > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com > > This email sent to aa...@chatnbike.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ERPDFGeneration problem
Hi David:
I guess I’m not alone in the wilderness! At least this means it isn’t my fault
- this time!! I haven’t had time to look into it at all today. Maybe the
supporting libraries were updated and something got broken. When I have a
chance I’ll start looking at when the ERPDFGeneration framework may have had
updates.
Tim
UCLA GSE&IS
On May 8, 2014, at 1:11 PM, David Holt wrote:
> I am seeing the same issue that you are with ERPDFGeneration. Disabling click
> to open has no impact on the problem.
>
> David
>
>
> On 2014-05-08, at 12:29 PM, Timothy Worman wrote:
>
>> I was suspecting the _componentName attribute yesterday and I was looking
>> for properties to turn it off. After a quick search I didn’t find anything.
>> It does appear that clickToOpen could be involved and I have the property
>> set true in my props. I haven’t used it so I don’t know why I have it
>> enabled. And I seem to remember reading it caused issues with excel
>> generation. This could be it. I’ll respond with more after some
>> investigation.
>>
>> Tim
>> UCLA GSE&IS
>>
>> On May 8, 2014, at 9:41 AM, Fabian Peters wrote:
>>
>>> I somehow assumed this problem occurred in deployment. Still, if Bastian is
>>> on the right track, then this should help:
>>>
>>> public boolean clickToOpenEnabled(WOResponse response, WOContext
>>> context) {
>>> return false;
>>> }
>>>
>>>
>>> Am 08.05.2014 um 18:15 schrieb Bastian Triller :
>>>
I think the _componentName attribute is the problem. There's a switch to
turn that off.
On Wed, 2014-05-07 at 19:33 -0700, Timothy Worman wrote:
> All:
>
>
> I have a problem that recently popped up with PDF generation. I have a
> custom component that utilizes the simple FlyingSaucerImpl in
> ERPDFGeneration. My component was failing with:
>
>
> "[org.xml.sax.SAXParseException] The markup in the document preceding the
> root element must be well-formed."
>
>
> So, I simplified things and basically made a test component content sth
> like SimplePDFGeneration1 from the ERPDFExamples. Same issue -
> SAXParseException. I overrode appendToResponse to generate some
> diagnostics on the content I’m trying pdf-ify (is that allowed?). Below
> is what it sayeth. So, what the heck is in line 0, column 2 in the
> document?
>
>
> May 07 19:20:21 eTimesheet[5] WARN NSLog -
> 'edu.ucla.gseis.employee.components.TimesheetCalendarPDFComponent' caused
> a SAXParseException
> Message: 'The markup in the document preceding the root element must be
> well-formed.'
> Line : 0
> Column : 2
> --- content begin ---
> 1
> 2 "edu.ucla.gseis.employee.components.TimesheetCalendarPDFComponent" lang =
> "en">
> 3
> 4
> 5 ERPDFGeneration Examples
> 6
> 7 href="/cgi-bin/WebObjects/eTimesheet.woa/_wr_/wodata=/Users/worman/Source/etswo/eTimesheet/WebServerResources/print.css"
> media="print"/>
> 8
> 9
> 10
> 11
> 12
> 13
> --- content end —
>
>
> Tim
> UCLA GSE&IS
>
>
>
>
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (
> Webobjects-dev@lists.apple.com
> )
> Help/Unsubscribe/Update your Subscription:
>
> https://lists.apple.com/mailman/options/webobjects-dev/bastian.triller%40gmail.com
>
>
> This email sent to
> bastian.tril...@gmail.com
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/lists.fabian%40e-lumo.com
This email sent to lists.fab...@e-lumo.com
>>>
>>
>>
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/programmingosx%40mac.com
>>
>> This email sent to programming...@mac.com
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
