Created attachment 45154 [details]
error screenshot

Created attachment 45155 [details]
source code for test case

changing version to current I see this problem in m211 ( no idea if it is in
other minors or not )

the test case sources should build in a staroffice or openoffice build env (
just unzip the zip file in the root source dir ) 
It works at least under linux ( and should work also under windows etc. ) 

note: the problem also happens under windows ( the original component which
prompted me to write the bare essentials test case failed on both platforms ) 

after doing a 'build' it also will produce an extension 'testExt.oxt' in the
output ( e.g unxlngi6/bin ) directory, to reproduce the error simply build the
module and deploy the extension using the extension manager ( or unopkg, doesn't
matter which )

setting the env variable  DISABLE_PROBLEM to YES will build a version that
doesn't cause the problem ( the env variable controls which implementation name
is given to the component )

issue is obviously not a patch

I have the same problem when testing VBA support build as extension. The Package
Manager rejects to install the extension beacause it uses the following declaration:

extern sdecl::ServiceDecl const serviceDecl(
    serviceImpl,
    "ScVbaGlobals",
    "org.openoffice.vba.Globals" );
}

Changing it to 

extern sdecl::ServiceDecl const serviceDecl(
    serviceImpl,
    "org.openoffice.vba.Globals",
    "org.openoffice.vba.Globals" );
}

and some refactoring (s/ScVbaGlobals/Globals/g) did the trick.

.

->jl
if this turns out to be a genuine problem ( and not a result of something stupid
that I have done ) could you post here the cws this fix will go into ( when of
course that happens ) - so I can pick up the patch, thanks. 

This seems to be a problem of the implentation of the ServiceDecl class in
comphelper.
@dbo: yours?

@npower, rail: Servicedecl is used and tested with implName!=serviceName(s),
e.g. in desktop/deployment, so I doubt that this causes the registration to
fail. Please debug why "ScVbaGlobals" fails and please also try first to use a
different one (e.g. "ScVbaGlobalsEx"); maybe that implementation key is already
registered in your rdb.
Moreover, does the registration or the live deployment (activation) fail?

>Servicedecl is used and tested with implName!=serviceName(s),
>e.g. in desktop/deployment, so I doubt that this causes the registration to
>fail.
I also doubt it is the cause 
  o ordinary registration e.g. via regcomp works fine
  o using the extension even after deployment fails ( on next office launch )
also works ( for the simple case )

but please have a look at the minimum test-case I provided ( to rule out
programmer error ), if you wish to try the test component it should build in
staroffice without problems
.
>Please debug why "ScVbaGlobals" fails and please also try first to use a
>different one (e.g. "ScVbaGlobalsEx"); maybe that implementation key is already
>registered in your rdb.
Please forget about ScVbaGlobals ( this is a much more complex component, why
waste time debugging it ) I provided a very very very simple test component to
demonstrate the problem the key 'TestNamesComp' definitely doesn't exist in the rdb
>Moreover, does the registration or the live deployment (activation) fail?
using unopkg standalone without the office running also produces the error
all this detail is above already though.....
so I say again, unless there is a problem with the simple test case then there
is a problem with the extension/package manager 

@jochen: yours again, seems unrelated to servicedecl.

Created attachment 45284 [details]
patch

change to patch.

So, it appears that BackendImpl::ComponentPackageImpl::getComponentInfo(..) will
use the singleton service entry ( stored abit strangely under the
implementations key ) as an implementation name ( and additioanlly as a
singleton name ) see. below. The attached patch fixes this imo.



 / IMPLEMENTATIONS
   / org.openoffice.test.Names   <----------------------
     / UNO
       / SINGLETONS
         / org.openoffice.test.theNames
           Value: Type = RG_VALUETYPE_UNICODE
                  Size = 52
                  Data = L"org.openoffice.test.Names"

   / TestNamesComp
     / UNO
       / ACTIVATOR
         Value: Type = RG_VALUETYPE_STRING
                Size = 34
                Data = "com.sun.star.loader.SharedLibrary"

just to clarify this patch is of course a fix for this issue. The root cause was
the component trying (and of course failing) to returns a factory for an
implementation name of "org.openoffice.test.Names"

.

jl->jsk: please verify registering services. You can also use the attached test
service (linux) or just ask me.
To see if registration worked you can use basic. For example to check if the
attached service works you can run:

Sub Main
'test service
o= createUnoService("TestNamesComp")
msgbox o.dbg_supportedInterfaces

'test singleton
ctx = getDefaultContext
factory = ctx.getValueByName("org.openoffice.test.Names")
msgbox o.dbg_supportedInterfaces

End Sub

.

The extension loads and is enabled.
An automated test has been created:
framework\basic\f_basic_extension_errors.bas::tExtensionError77436

Verified

This works ok for Linux but fails on Solaris with just another errormessage:

 (com.sun.star.uno.RuntimeException) { { Message =
"::osl::File::createTempFile() failed!", Context = (com.sun.star.uno.XInterface)
@0 } }


jsk->jl: I would expect that the sample extension provided by noel should work
on Solaris Sparc as well. If this is not the case, this is still an exception
that should be handled -> New issue.

Reop

Adjusted summary to contain the phrase "Extension Manager" for easier query.
To jl.

>jsk->jl: I would expect that the sample extension provided by noel should work
on Solaris Sparc as well.
Unless the sample code has been rebuilt and repacked for solaris then no, I
wouldn't expect it to work as this extension contains a native component ( so it
also won't work on windows either )
> If this is not the case, this is still an exception that should be handled
that very well may be but that a completely seperate ( and pre-existing ) issue
( and this issue should not be reopened or used for that )
I would think in this case ( assuming the root cause is attempting to register a
native component on a different platform ) ) the exception cannot be handled at
all, it just is indicating a non-recoverable error

Back to me, the lib included in the package is linux only. Will add this to the
testcase.

Setting back to fixed/verified, will open another issue for the exception

jsk->npower: Thanks for the hint (Ijust found out myself ;-) almost
simultaneously). Closing