ERROR: Not a registered SWP service class - how to fix?

[Tim Smith]

Hi,

I've been running (and working on) the same set of SWPs for weeks now and this evening I'm getting the "Not a registered SWP..." error message.

It's the same file, (*.ui.ttlx), same class, etc...  I've had the error before, usually when there is some sort of import problem but no errors about that now.  Typically refreshing the system entries does the trick.  No luck this time.

I restarted TBC into a new workspace and imported everything from the previous one.  The SWP is still unregistered.  I did receive a few instances of this error during the import:

Problems occurred when invoking code from plug-in: "org.eclipse.jface".

The stack trace is below and seems to indicate something related to TBCFileRegistry.  Is there a way to see what SWPs are registered?  Can I trace this error further somehow?  

Thanks,

Tim

TBC 6.4.1

org.eclipse.core.runtime.AssertionFailedException: null argument:
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:73)
at org.eclipse.ui.internal.decorators.DecorationReference.<init>(DecorationReference.java:35)
at org.eclipse.ui.internal.decorators.DecorationScheduler.queueForDecoration(DecorationScheduler.java:150)
at org.eclipse.ui.internal.decorators.DecoratorManager.labelProviderChanged(DecoratorManager.java:747)
at org.eclipse.jface.viewers.BaseLabelProvider$1.run(BaseLabelProvider.java:72)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:50)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:173)
at org.eclipse.jface.viewers.BaseLabelProvider.fireLabelProviderChanged(BaseLabelProvider.java:69)
at org.topbraidcomposer.core.io.FileRegistryDecorator.updateFile(FileRegistryDecorator.java:70)
at org.topbraidcomposer.core.io.TBCFileRegistry$1.fileAdded(TBCFileRegistry.java:103)
at org.topbraid.core.registry.impl.FileRegistry$FRChange.tellRegister(FileRegistry.java:84)
at org.topbraid.core.registry.impl.FileRegistry.safeRegister(FileRegistry.java:689)
at org.topbraid.core.registry.impl.FileRegistry.register(FileRegistry.java:508)
at org.topbraid.core.registry.impl.FileRegistry.registerAndProcessImports(FileRegistry.java:739)
at org.topbraidcomposer.core.io.TBCFileRegistry.handleFileAdded(TBCFileRegistry.java:190)
at org.topbraidcomposer.core.io.TBCFileRegistry.handleFileDelta(TBCFileRegistry.java:272)
at org.topbraidcomposer.core.io.TBCFileRegistry.access$0(TBCFileRegistry.java:248)
at org.topbraidcomposer.core.io.TBCFileRegistry$3.visit(TBCFileRegistry.java:288)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:64)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:75)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:75)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:75)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:75)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48)
at org.topbraidcomposer.core.io.TBCFileRegistry.handleResourceChange(TBCFileRegistry.java:284)
at org.topbraidcomposer.core.io.TBCFileRegistry.access$1(TBCFileRegistry.java:282)
at org.topbraidcomposer.core.io.TBCFileRegistry$5.run(TBCFileRegistry.java:430)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)

eclipse.buildId=unknown
java.version=1.8.0_222
java.vendor=AdoptOpenJDK
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Command-line arguments:  -os win32 -ws win32 -arch x86_64

[Holger Knublauch]

Hi Tim,

a list of known web services can be found at the "Available Web Services" admin page.

Another page that may be helpful just to confirm against missing imports is the Base URI Management page

I occasionally see the DecorationReference bug too, but it looks more like an Eclipse-internal regression than a true bug in our code. I think it happens sometimes after adding files to a workspace at the wrong moment. Of course I may be wrong on this one, but it shouldn't have any impact if the issue remains after restart and no new error log entry.

I am puzzled and would need more info, sorry.

Holger

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0Wbn%2BS-YiG%3DFchYKgd541E73woDOOo8Cv6J9Q%2BC0%3DFSJ_iBQ%40mail.gmail.com.

[Richard Cyganiak]

The org.eclipse.jface message and stack trace is probably unrelated and harmless.

The message “Not a registered SWP service class” indicates that the class passed as _viewClass is not of type ui:NodeClass, taking subclass inference into account. The type statement must be in the UI graph, that is, in a graph whose graph URI ends in .ui, or in the owl:import closure of such a graph.

This can be verified by asking this SPARQL query (written here from memory):

    ASK { GRAPH ui:graph { ?viewClass rdf:type/rdfs:subClassOf* ui:NodeClass } }

Where ?viewClass needs to be replaced with the value passed as _viewClass.

If _viewClass is a prefixed name, then a missing prefix declaration, or clashing declarations in different graphs included into the UI graph, could also cause this problem. This possibility can be excluded by using the full URI as the value of _viewClass (%-encoded if it contains # or &).

Richard

[Tim Smith]

Hi Richard,

Thanks to you and Holger for your assistance.  This has been a strange one.

Per Holger's suggestion, I checked for my service using the "Available Web Services" page.  My service was in the list and displaying properly, including the prefix.   There were no base URI issues either.

The SWP is a direct subclass of ui:Service and is declared in the .ui.ttlx file, so no issues there.

Next, I checked the prefixes.  First, I attempted to run the SWP using the fully qualified URL.  It worked!  Thus a prefix must be the problem.  Using this query, I listed all the imports into my SWP graph.  Nothing jumped out as a problem.

SELECT *
WHERE {
    ?s owl:imports ?o .
}

To find where my prefix might have been used, I switched perspectives and ran a full text search of the entire workspace.  I found that the same prefix (l5x) was defined in an example file that I had prepared.  This file is not imported by anything in the workspace, including my SWP.  I was able to change the prefix in that file, refresh system registries and now the prefixed SWP call works properly.

Obviously using the same prefix for different graphs is not a good practice.  This instance resulted from me copying my SWP file to the example file and stripping it down to create a unit test for another problem I'm having.  Thus, this was an oversight.  I can see where using the same prefix for two different graphs would be a problem if they were imported into the same import closure (not the case here).  Should it have been a problem since the two graphs never connected other than being in the same workspace?  If using the same prefix is an issue and TBC is scanning the files to harvest prefixes, is it possible to generate a warning when duplicate prefixes are found?

Thanks again for your assistance.  Off to the next problem :)

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/3EE9477C-F252-403B-9373-92DAE41C51A1%40topquadrant.com.

[Richard Cyganiak]

> On 3 Sep 2020, at 16:25, Tim Smith <smith...@gmail.com> wrote:
>
> I can see where using the same prefix for two different graphs would be a problem if they were imported into the same import closure (not the case here). Should it have been a problem since the two graphs never connected other than being in the same workspace? If using the same prefix is an issue and TBC is scanning the files to harvest prefixes, is it possible to generate a warning when duplicate prefixes are found?

I don't know, to be honest. The behaviour of prefixes is... complicated... and in some cases seems to be more the result of accident than design. There are several oddities that I'm aware of, and I'll have to add the one you describe to that list. What works for me is being very careful when declaring a new prefix, and then never changing it to a different URI. Basically, act as if there was only a single global prefix mapping, and each graph has a subset of the mapping.

Richard

[dprice]

I explain the idea of a “global prefix” set as a best practice to all the customer projects in which I’m involved.

I also always define *the* prefix in the originating graph (i.e. don’t default), then no other graph has to re-defined a prefix for anything it imports reducing the chance of error.

Cheers,

David

Richard

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/C1689A88-2ED0-44B4-933F-8AF6AFE2C4FB%40topquadrant.com.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Tim Smith]

I will adopt the notion of a "global prefix" but that will break the minute an external ontology overlaps with a prefix I already use.  Hopefully better prefix handling is on the development roadmap, particularly where a prefix issue is preventing a webservice from being invoked using the prefix.  Diagnosing my issue was especially difficult since the Available Web Services page showed my service as available with the prefix in the syntax.  

Thanks for your help,

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/47E38F13-9FB7-4C5B-A3B1-9CF16058BC1A%40topquadrant.com.

[Holger Knublauch]

On 4/09/2020 01:25, Tim Smith wrote:

Hi Richard,

Thanks to you and Holger for your assistance.  This has been a strange one.

Per Holger's suggestion, I checked for my service using the "Available Web Services" page.  My service was in the list and displaying properly, including the prefix.   There were no base URI issues either.

The SWP is a direct subclass of ui:Service and is declared in the .ui.ttlx file, so no issues there.

Next, I checked the prefixes.  First, I attempted to run the SWP using the fully qualified URL.  It worked!  Thus a prefix must be the problem.  Using this query, I listed all the imports into my SWP graph.  Nothing jumped out as a problem.

SELECT *
WHERE {
    ?s owl:imports ?o .
}

To find where my prefix might have been used, I switched perspectives and ran a full text search of the entire workspace.  I found that the same prefix (l5x) was defined in an example file that I had prepared.  This file is not imported by anything in the workspace, including my SWP.  I was able to change the prefix in that file, refresh system registries and now the prefixed SWP call works properly.

And the file also did not end with .ui.ttlx by any chance? All those ui. files are merged together into a large union graph, and the services will respond using that graph. If it is indeed not referenced and has no .ui.* ending then I have no idea why it would use that conflicting prefix.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0WbnK_KyWaUtZD99DVRNxKb-GH0YR5ASP-ZKYVXU%2BQzJo%3Daw%40mail.gmail.com.

[Tim Smith]

Ahhh... that would explain it.. The file contains SWPs and ends in .ui.ttlx.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1bf72a87-f890-f709-2c0f-98d0c3dd1edf%40topquadrant.com.