Apache OpenOffice (AOO) Bugzilla – Issue 68285
loadComponentFromUrl has changed behaviour between 1.1 et 2.0
Last modified: 2013-02-24 21:08:48 UTC
Assuming the url address is inexistent (but syntactically correct) : - version 1.1.x : loadComponentFromUrl returns a Null object - version 2.0.3 throws the exception : Type: com.sun.star.lang.IllegalArgumentException Message: URL seems to be an unsupported one. This exception is not appropriate because the argument is legal, the URL is correct. This is a problem with macros created with versions 1.1.x. Now with version 2.0.x you must have an exception handler (which gives a more complex code for simple macros). Next attachment is an example.
Created attachment 38364 [details] Demo of loadComponentFromURL for a non-existent file
jsc -> as: can you please verify this issue. I would agree that this exception is wrong here.
AS->bmarcelly: Sorry ... but this change was requested from other users of OOo. They wished to be informed in case an URL was wrong. And if the core of OOo does not accept an URL in upper case notation I cant distinguish it against the use case where a realy unsupported URL was given (as e.g. "blubber://something/illegal/ nonesense"). Sory ... but from this point of view I must reject this issue as "INVALID". Please track the issue #68293# to be notified in case the problem behind case sensitive URL's will be fixed. In such case there wont be such exception any longer .-)
.
In your answer you are mixing this issue and issue 68293. Here I am only dealing with correct URL, which should have retrieved a file if it existed. 1 - "this change was requested from other users of OOo. They wished to be informed in case an URL was wrong." These unknown users apparently did not know that they could test the result returned by loadComponentFromURL : a null value evidently shows that the URL could not be retrieved. If they wanted to know if the URL syntax was incorrect, then the current design does not distinguish this from file inexistence. 2 - This evolution is against the classical development rule: as far as possible be backward compatible. This could have been possible by setting a new option in the PropertyValue sequence (4th parameter). 3 - As explained in my report, IllegalArgumentException is not appropriate to a syntactically correct URL which points to a non-existing file. This will lead to a misleading user message. A more specific exception (or more general if you can't distinguish syntax error from file existence) should have been raised. I wish your decision be re-estimated by the development team.
Sorry - but I dont mix something here. The problems more in detail: What do you mean, which of the following URLs is right and which is wrong ? "file:///f:/temp/test.odt" "http://www.any.org/test.odt" "vnd.sun.star.expand://1904678/test.odt" "vfs://Desktop/test.odt" "blubber://myfiles/test.odt" ANY Of these URL's can be right or wrong. Why ? Do you know the UCB. It's our internal used service to access contents in a generic way. And these UCB provides a "plugin" concept. You can register several further UNO components bound to an URL schema. The most well known URL schemas are implemented inside OOo itself. "vnd.sun. star.expand:/" is a special schema to access contents inside UNO-Packages; "vfs: /" was designed to bind gnome VFS contents to OOo and "blubber:/" does not exists currently - but it can be written might be by you .-) On the other side I cant ask the UCB how many and which type of contents it supports. Because there is a special fetaure inside gnome. So the "vfs:/" content provider is also registered for the schema "*:/". What does it mean ? Gnome knows the same plugin concept. You can extends gnome vfs by plugins so it can support several URL schemas. And because OOo does not know which URL schemas are supported by gnome ... OOo must forward all unknown URLs to Gnome. Another problem: Inside OOo (means the current design of the UCB) there is no function like "File::exists()". Because some programmer decided, that such function cant work in a multithreaded and shared environment (which is IMO right). The only way to know if a file exists or not is to open it and handle errors. But the UCB can not provide the right errors here ... because he also not know (sometimes) if the URL was wrong (because not supported by any plugin ... think about "*:/") or if the requested file does not exists. Another (small) problem: Do you know the URL schemas "private:factory/*" or "component.db:/" or "bibliography:/" ? Such URL's cant be used to create a stream. They are supported by special FrameLoader implementations, which create the content programmaticly. These schemas has to be handled manually to know if a failed stream creation was realy an error or not. I know - it's not perfect ... But if your bug with upper case URL's will be fixed everything will work as aspected. And such "false positive IllegalArgumentExceptions" wont occure any longer. The only way to reproduce this bug then will be: using of realy realy unsupported URL schemas or (!) providing an illegal content as e.g. "file:///f:/temp/test.pdf" for loading. The same exception will occure in case the file exists ... but its format type is unknown or not supported for loading (because PDF can be exported by OOo only). Sorry again: but the decission about changing the behaviour was made some months before and we cant redefine it every day. The signature of the API method isnt perfect ... the internal designs are also not perfect (They are flexible but not perfect). But now I can guarantee (more then before) that in case you dont got an exception the return value will be valid and can be used. Please dont reopen this task. The decision about this behaviour is final. Only a new implementation XComponentLoader2:loadComponentFromURL2() can help to solve (some) problems. But currently there is no decision about that.
I've forgot: > 2 - This evolution is against the classical development rule: as far as possible be > backward compatible. This could have been possible by setting a new option in > the PropertyValue sequence (4th parameter). No it does not break "backward compatibility". Because your code has to handle such exceptions even if they dont occure. So returning NULL will be the same then handling an exception. The content could not be loadd. My change can break your code only in case your "old 1.1 code example" does not handle exceptions in general. Of course you cant distinguish between diffrent type of errors .. but as I've explained: I cant distinguish between these errors internaly too .-)
The Issue you raised has been marked as 'Resolved' and not updated within the last 1 year+. I am therefore setting this issue to 'Verified' as the first step towards Closing it. If you feel this is incorrect, please re-open the issue and add any comments. Many thanks, Andrew Cleaning-up and Closing old Issues ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html
As per previous posting: Verified -> Closed. A Closed Issue is a Happy Issue (TM). Regards, Andrew
Created attachment 73123