Issue 80469

Summary: unopkg: Enhance errorhandling for invalid bootstrapping parameters
Product: General Reporter: joerg.skottke
Component: codeAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues
Version: 680m222   
Target Milestone: ---   
Hardware: All   
OS: Solaris   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description joerg.skottke 2007-08-08 12:01:51 UTC 
Reproduction:
- execute ./unopkg add --shared -env:UserInstallation=/tmp/testdir <path to
extension> as root

[Java framework] Error in function createSettingsDocument (elements.cxx).javaldx
failed! 

ERROR: exception occured raising singleton
"/singletons/com.sun.star.configuration.theDefaultProvider":
MultiStratumBackend: Could not create Backend Stratum Service:  Not a Valid File
URL:
"/tmp/testdir/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/registry"

unopkg failed.


Please handle the exception. Usually this would not be a problem, as the
file-URL mostly resides in configuration files but as it is possible to specify
-env as a command line parameter we need syntax checking and a useful error
message here.

BTW: Is this parameter documented somewhere? It is a possible workaround for the
"sudo" problem that the data is written to the user's homedir.
Comment 1 joachim.lingner 2007-08-08 12:19:41 UTC 
The variable UserInstallation should be documented somewhere, since the office
uses it for quite some time now. I do not know where.
Comment 2 joachim.lingner 2007-08-08 12:42:58 UTC 
The unopkg cannot handle this exception since it does not know the content and
the meaning of the bootstrap variables. Only the code which uses the variable
can determine the cause of error. The problem this, that it is not possible to
transport the initial error unmodified to the user. One reason is that UNO
interfaces must declare the allowed exceptions at a method. If now a function
throws an exception according to its specification but the calling function
cannot handle this exception nor can it throw it (because it does not define
that it can throw this exception) then it must throw something other, in which
case some information is lost. No image a deep stack of function calls ....
In short, there is currently no useful concept of handling these kind of errors.
Every now and then someone tries to tackle this ... However, according to JSC
there is a new attempt being made. Let's see what comes of it.
Comment 3 joachim.lingner 2007-08-08 12:43:40 UTC 
.
Comment 4 joerg.skottke 2007-08-10 09:31:24 UTC 
Reopen
Comment 5 joerg.skottke 2007-08-10 09:32:44 UTC 
To jsc - according to jl you are working on a solution for this. Can you provide
an issue id?
Thanks!
Comment 6 jsc 2007-08-10 10:20:05 UTC 
no i am not working on this. The info was that a group of engineers will discuss
a general error handling concept. The whole area is much more complex and can't
be easy addressed with one issue. In the concrete issue of the unopkg script the
error appears first in javaldx, the next part is the configuration. It is more
or less impossible to detect all errors depending on bootstrap variables here.
We need an overall concept for errors. The unopkg script is only one place that
would benefit from a well defined error handling concept.
I send the issue to kr for further comments or opinions related error handling
in context of bootstrap variables.

jsc -> kr: please comment or better provide a solution
Comment 7 kay.ramme 2007-12-18 13:54:46 UTC 
No solution insight -> re-targetd to 3.0.
Comment 8 kay.ramme 2008-08-26 09:28:01 UTC 
Moved target to 3.1 

By the way, would be an "IllegalArgumentException", to be throwable by any method, a valid approach? The 
configuration could throw it after determining that the provided "UserInstallation" directory is invalid. We could
precise it with a "BootstrapParameterException" or so ...