Java 7 and Application.setOpenURIHandler
James Tomson
james.b.tomson at gmail.com
Wed May 22 14:52:31 PDT 2013
I've run into this issue as well with jdk7u_21, and just entered (another)
bug on the subject - 9003054.
Looking at the system log in Console.app when this occurs, there's a but
more info in the exception description:
----------
JavaAppLauncher[74278]: -[NSAppleEventDescriptor
paramDescriptorForKeyword:] called on invalid NSAppleEventDescriptor
----------
It appears that since the QueueingApplicationDelegate is only keeping
references to those event objects instead of making deep copies of them,
the event descriptor for the initial URI that launches the app is
invalidated by the time the app actually gets around to processing it.
The following patch seems to resolve the issue:
-----------
diff -r fd2743154fcf
src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m
--- a/src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Wed May
08 16:52:22 2013 -0700
+++ b/src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Wed May
22 12:41:08 2013 -0400
@@ -110,8 +110,14 @@
- (void)_handleOpenURLEvent:(NSAppleEventDescriptor *)openURLEvent
withReplyEvent:(NSAppleEventDescriptor *)replyEvent
{
+ // Make an explicit copy of the passed events as they may be
invalidated by the time they're processed
+ NSAppleEventDescriptor *openURLEventCopy = [openURLEvent copy];
+ NSAppleEventDescriptor *replyEventCopy = [replyEvent copy];
+
[self.queue addObject:[^(){
- [self.realDelegate _handleOpenURLEvent:openURLEvent
withReplyEvent:replyEvent];
+ [self.realDelegate _handleOpenURLEvent:openURLEventCopy
withReplyEvent:replyEventCopy];
+ [openURLEventCopy release];
+ [replyEventCopy release];
} copy]];
}
-----------
I'm not quite sure of the process required to get these patches considered,
but I've included the above diff in the bug report - hopefully it's of some
use and not completely off track :)
-James
>I submitted a bug for this but it's been "not available" for a few weeks:
>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000081
>
>Can anybody comment on this issue with the
>Application.setOpenURIHandler and custom protocols?
>
>Custom protocols really are useful especially now that applets are
>dying a slow death with everybody disabling java in their browser...
>
>Thanks,
>-Aj
>
>
>On Mon, Feb 18, 2013 at 7:28 PM, AJ Gregory <ajgregory at gmail.com> wrote:
>> I have an app bundled with Java 7 (1.7.0_13) which registers a custom
>> URL scheme using CFBundleURLSchemes in it's Info.plist and uses the
>> Application.setOpenURIHandler to register a listener.
>>
>> When I click on a link that has the custom URL scheme in the browser
>> it launches the app OK but doesn't call the handler and the following
>> dump is in the console.
>>
>> I tried to submitted a bug as well but never got a bug number so not
>> sure if it was created.
>>
>> Anybody else have experience with this?
>>
>> Thanks,
>> -Aj
>>
>>
>>
>> 2/6/13 8:46:21.473 AM JavaAppLauncher[842]: (
>> 0 CoreFoundation 0x00007fff898200a6
>> __exceptionPreprocess + 198
>> 1 libobjc.A.dylib 0x00007fff840043f0
>> objc_exception_throw + 43
>> 2 CoreFoundation 0x00007fff8981fe7c
>> +[NSException raise:format:] + 204
>> 3 Foundation 0x00007fff8c29f763
>> -[NSAppleEventDescriptor paramDescriptorForKeyword:] + 71
>> 4 liblwawt.dylib 0x0000000168fb2b77
>> -[ApplicationDelegate _handleOpenURLEvent:
>> withReplyEvent:] + 137
>> 5 libosxapp.dylib 0x00000001690588b1
>> __-[QueuingApplicationDelegate
>> _handleOpenURLEvent:withReplyEvent:]_block_invoke_1 + 135
>> 6 libosxapp.dylib 0x00000001690597bf
>> -[QueuingApplicationDelegate processQueuedEventsWithTargetDelegate:] +
>> 134
>> 7 libosxapp.dylib 0x0000000169057857
>> OSXAPP_SetApplicationDelegate + 153
>> 8 liblwawt.dylib 0x0000000168fb1899
>> __+[AWTStarter start:swtMode:swtModeForWebStart:]_block_invoke_1 + 111
>> 9 Foundation 0x00007fff8c2cf677
>> __NSThreadPerformPerform + 225
>> 10 CoreFoundation 0x00007fff8979f101
>> __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
>> 11 CoreFoundation 0x00007fff8979ea25
>> __CFRunLoopDoSources0 + 245
>> 12 CoreFoundation 0x00007fff897c1dc5
>> __CFRunLoopRun + 789
>> 13 CoreFoundation 0x00007fff897c16b2
>> CFRunLoopRunSpecific + 290
>> 14 HIToolbox 0x00007fff872880a4
>> RunCurrentEventLoopInMode + 209
>> 15 HIToolbox 0x00007fff87287d84
>> ReceiveNextEventCommon + 166
>> 16 HIToolbox 0x00007fff87287cd3
>> BlockUntilNextEventMatchingListInMode + 62
>> 17 AppKit 0x00007fff8e331613
>> _DPSNextEvent + 685
>> 18 AppKit 0x00007fff8e330ed2
>> -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
>> 19 libosxapp.dylib 0x0000000169057b56
>> -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] +
>> 124
>> 20 AppKit 0x00007fff8e328283
>> -[NSApplication run] + 517
>> 21 libosxapp.dylib 0x00000001690579b9
>> +[NSApplicationAWT runAWTLoopWithApp:] + 156
>> 22 liblwawt.dylib 0x0000000168fb181a
>> -[AWTStarter starter:] + 1591
>> 23 Foundation 0x00007fff8c2cf677
>> __NSThreadPerformPerform + 225
>> 24 CoreFoundation 0x00007fff8979f101
>> __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
>> 25 CoreFoundation 0x00007fff8979ea25
>> __CFRunLoopDoSources0 + 245
>> 26 CoreFoundation 0x00007fff897c1dc5
>> __CFRunLoopRun + 789
>> 27 CoreFoundation 0x00007fff897c16b2
>> CFRunLoopRunSpecific + 290
>> 28 libjli.dylib 0x00000001001cb88d
>> CreateExecutionEnvironment + 871
>> 29 libjli.dylib 0x00000001001c603c
JLI_Launch + 1952
>> 30 JavaAppLauncher 0x00000001000629cb launch +
5035
>> 31 JavaAppLauncher 0x00000001000614f6 main + 102
>> 32 JavaAppLauncher 0x0000000100061484 start + 52
>> 33 ??? 0x0000000000000002 0x0 + 2
>> )>
More information about the jdk7u-dev
mailing list