This is a partial stacktrace when I try to unmarshall a collection of ServiceProvider instances from the triplestore (via Lyo Store):

org.eclipse.lyo.store.ModelUnmarshallingException: org.eclipse.lyo.oslc4j.core.exception.OslcCoreMisusedOccursException:
OSLC012: Multiple values for method setCreated of class org.eclipse.lyo.oslc4j.core.model.ServiceProvider 
that supports at most one value
	at org.eclipse.lyo.store.internals.SparqlStoreImpl.getResourcesFromModel(SparqlStoreImpl.java:365)

Create a separate project to support creation of SHACL shapes.

We shall also stop including HttpCore because HttpClient already does that and keeps the version in sync.

I am not able to merge eclipse/lyo.designer#16 PR because of too strict signature check in the org.eclipse.lyo.oslc4j.core.model.ResourceShapeFactory#validateSetMethodExists method.

For a getter getValue(): ArrayList<T> we should only check that the setter also accepts a collection and its generic parameter is the same as of the getter's return type.

should we migrate Core to use the Jena 3.6.0?
All CQs are now already approved
https://docs.google.com/spreadsheets/d/1L0pFrUTW7c4Irt8eti6riersSZF3jNl_hXxFrrZBq84/edit?ts=5af0d1d6#gid=242671613

The commit
adad011 removes all logic from isWritable.

But one should not return true, when the "type" parameter is an array!

When the response is a query response (array), simply returning true, leads to the wrong OslcRdfXmlProvider Provider being called, instead of the expected OslcRdfXmlArrayProvider.

This causes JenaModelHelper to fail since it is not implemented to handle such a scenario.
Where it currently fails is in JenaModelHelper::recursivelyCollectNamespaceMappings, since the resourceClass parameter is an array instead of being a single object. This leads to the call "resourceClass.getPackage()" to return null, and hence cause an exception.

If we want isWritable to be true in this abstract class, then we need to change the logic in the OslcRdfXmlProvider::isWritable method to make sure it returns false upon an array parameter.
What about all other classes that specialize this abstract class?

xml-apis jar is conflicting with other jars in the bundle at the runtime causing runtime error. After updating the pom file or store-core project, this jar is getting fetched as a transitive dependency. This jar should be excluded.

Right now we only use it in testing but good to have a CQ done for the future use in src:

    <dependency>
      <groupId>org.jetbrains.kotlin</groupId>
      <artifactId>kotlin-stdlib-jdk8</artifactId>
      <version>${kotlin.version}</version> <!--     <kotlin.version>1.3.20</kotlin.version> -->
    </dependency>

RTC responds to a request to read a ServiceProvider with text/xml. OslcClient can't read this because AbstractOslcRdfXmlProvider.getSerializtionLanguage() doesn't recognize MediaType.TEXT_XML
Adding:

		mediaPairs.add(new AbstractMap.SimpleEntry<>(OslcMediaType.TEXT_XML_TYPE,
				 RDFLanguages.strLangRDFXML));

fixes it, but I don't know why this might have been removed, or what might have changed in RTC so that it is returning text/xml instead of application/rdf+xml.

Providers rely on annotation inheritance in JAX-RS - this resulted from a difference in how Wink vs Jersey handle annotation inheritance. Andrew will fix this.

a reminder for a future refactoring

JHM unmarshall method returns null through JAX-RS in spring boot application.

Version: 4.0.0.202001221327

I am using the Lyo Standalone application.

I followed the toolchain modelling workshop as closely as possible, but no web.xml configuration is generated.

https://ci.eclipse.org/lyo/job/lyo-core-master/49556/console

org.eclipse.lyo.oslc4j.provider.jena.AbstractOslcRdfXmlProvider#isWriteable has the logic that checks the underlying type of the array for the OSLC annotations on the base class:

		if (type.getAnnotation(OslcResourceShape.class) != null ||
			type.getAnnotation(OslcNotQueryResult.class) != null)
		{
			// We do not have annotations when running from the non-web client.
			if (isCompatible(actualMediaType, requiredMediaTypes))
			{
				return true;
			}
		}

This is bad for 2 reasons:

1. It behaves differently under an OSLC Server (adaptor) and a standalone OSLC Client.
2. Its "smartness" will only work when, for example, a Requirement[] is returned where a method returns Object[].

In my case, I hit the second problem because I was truly returning an Object[] with an instance of one valid OSLC resource class instance in [0] and another (different) valid OSLC resource class instance in [1].

Currently, the client is generated as part of the entire server source code through the toolchain generator.

However they can be entirely decoupled and have no shared dependencies aside from the domains (which might be generated separately anyways). I've been manually moving the client after I regenerate it into a separate project, but I think it would be very helpful to be able to configure this in the generator directly.

1. commons-io 2.5 vs 2.6
2. httpclient 4.4.1 vs 4.5.3

See #109

One PR got merged that messed up the POM file

I am trying to take advantage of the patch #29 by @neormx.

I tried replacing the code I had for naive unmarshalling of multiple classes (ie try this, if you get an exception try that and so on) with the code that simply unmarshalls a superclass (code in Kotlin):

//            val action: IExtendedResource = OslcHelpers.navTry(plan, step.action,
//               DropBelt::class.java, MoveToWp::class.java,
//                PickShelf::class.java)
            val action: IExtendedResource = OslcHelpers.navTry(plan, step.action,
                ExecutableAction::class.java)

The code fails. I tried the following:

• replace ExecutableAction with IExecutableAction (both generated with Lyo). Fail - because IExecutableAction generated by Lyo is an interface without any annotations and does not extend IResource. There is no way to put that one in JMH.
• make ExecutableAction abstract. I recall that Ricardo wanted to make it work only if the class you passed was explicitly abstract or an interface to avoid breaking any code. No luck. The problem here seems to be that ExecutableAction is annotated with an RDF type and JMH looks for it exactly; without adding RDFS reasoning it's impossible to do so (plus LyoD should them generate an RDFS vocab that can be used by Jena reasoner). model.listSubjectsWithProperty returns 0 resources.
• remove OSLC annotations from the generated ExecutableAction class. The Pet class from Ricardo's unit tests did not have any annotations, so I have removed mine too. This actually moved the debugging forward, now I get 1 resource in the resourceList! At this stage, however, a completely wrong package got scanned in the createObjectResultList. For some reason, the beanClass was set to the class name which holds properties of abstract types. False hope, that was accidental trigger of the debugger with an unrelated JMH call.

The classes discussed here are located in https://github.com/EricssonResearch/scott-eu/tree/master/lyo-services/domain-pddl/src/main/java/eu/scott/warehouse/domains/scott

Thanks in advance!

[WARNING] Bundle org.eclipse.lyo.oslc4j.core:repackaging.jersey:jar:2.4.0-SNAPSHOT : Invalid value for Bundle-RequiredExecutionEnvironment, JavaSE-1.8 does not match CDC-1.0/Foundation-1.0|CDC-1.1/Foundation-1.1|OSGi/Minimum-1.[1-9]|JRE-1.1|J2SE-1.2|J2SE-1.3|J2SE-1.4|J2SE-1.5|JavaSE-1.6|JavaSE-1.7|PersonalJava-1.1|PersonalJava-1.2|CDC-1.0/PersonalBasis-1.0|CDC-1.0/PersonalJava-1.0

Just noticed in the log output while building #27. @yashkhatri do you have a fix in mind to address this warning?

I tried to add an extended property and by mistake supplied a UriBuilder instead of a URI object. JMH skipped the property without a warning.

@neormx raised this separate of #63 and I am not sure if that PR will resolve this issue.

Currently, the ShaclDataType annotation has value of type ValueType which is OSLC based. Shacl may provide support for more data types. Hence, good to keep a Shacl Data Type enum separate from OSLC.

Given that the latter is now unchecked, we should use it instead of general IllegalState/IllegalArgument exceptions that were used to avoid checked exceptions.

By default, with the INFO logging level enabled, you'd see many messages like this:

14321 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcJsonLdArrayProvider was registered as a JAX-RS MessageBodyReader provider for [Ljava.lang.Object; Java types and application/ld+json media types.
14321 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcTurtleArrayProvider was registered as a JAX-RS MessageBodyReader provider for [Ljava.lang.Object; Java types and text/turtle media types.
14322 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcTurtleCollectionProvider was registered as a JAX-RS MessageBodyReader provider for java.util.Collection Java types and text/turtle media types.
14323 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcTurtleProvider was registered as a JAX-RS MessageBodyReader provider for all Java types and text/turtle media types.
14323 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcCompactRdfProvider was registered as a JAX-RS MessageBodyReader provider for org.eclipse.lyo.oslc4j.core.model.Compact Java types and application/x-oslc-compact+xml media types.
14324 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcXmlCollectionProvider was registered as a JAX-RS MessageBodyReader provider for java.util.Collection Java types and text/xml media types.
14324 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcXmlProvider was registered as a JAX-RS MessageBodyReader provider for all Java types and text/xml media types.
14324 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcXmlArrayProvider was registered as a JAX-RS MessageBodyReader provider for [Ljava.lang.Object; Java types and text/xml media types.
14325 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcRdfXmlArrayProvider was registered as a JAX-RS MessageBodyReader provider for [Ljava.lang.Object; Java types and application/rdf+xml media types.
14325 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcRdfXmlProvider was registered as a JAX-RS MessageBodyReader provider for all Java types and application/rdf+xml media types.
14325 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcRdfXmlCollectionProvider was registered as a JAX-RS MessageBodyReader provider for java.util.Collection Java types and application/rdf+xml media types.
14326 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcXmlCollectionProvider was registered as a JAX-RS MessageBodyReader provider for java.util.Collection Java types and application/xml media types.
14326 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcXmlProvider was registered as a JAX-RS MessageBodyReader provider for all Java types and application/xml media types.
14326 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcXmlArrayProvider was registered as a JAX-RS MessageBodyReader provider for [Ljava.lang.Object; Java types and application/xml media types.
14327 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcJsonLdProvider was registered as a JAX-RS MessageBodyWriter provider for all Java types and application/ld+json media types.
14327 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcJsonLdCollectionProvider was registered as a JAX-RS MessageBodyWriter provider for java.util.Collection Java types and application/ld+json media types.
14328 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcJsonLdArrayProvider was registered as a JAX-RS MessageBodyWriter provider for [Ljava.lang.Object; Java types and application/ld+json media types.
14328 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcTurtleArrayProvider was registered as a JAX-RS MessageBodyWriter provider for [Ljava.lang.Object; Java types and text/turtle media types.
14328 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcTurtleCollectionProvider was registered as a JAX-RS MessageBodyWriter provider for java.util.Collection Java types and text/turtle media types.
14329 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcTurtleProvider was registered as a JAX-RS MessageBodyWriter provider for all Java types and text/turtle media types.
14329 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcCompactRdfProvider was registered as a JAX-RS MessageBodyWriter provider for org.eclipse.lyo.oslc4j.core.model.Compact Java types and application/x-oslc-compact+xml media types.
14330 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcXmlCollectionProvider was registered as a JAX-RS MessageBodyWriter provider for java.util.Collection Java types and text/xml media types.
14330 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcXmlProvider was registered as a JAX-RS MessageBodyWriter provider for all Java types and text/xml media types.
14331 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcXmlArrayProvider was registered as a JAX-RS MessageBodyWriter provider for [Ljava.lang.Object; Java types and text/xml media types.
14332 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcRdfXmlArrayProvider was registered as a JAX-RS MessageBodyWriter provider for [Ljava.lang.Object; Java types and application/rdf+xml media types.
14334 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcRdfXmlProvider was registered as a JAX-RS MessageBodyWriter provider for all Java types and application/rdf+xml media types.
14334 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcRdfXmlCollectionProvider was registered as a JAX-RS MessageBodyWriter provider for java.util.Collection Java types and application/rdf+xml media types.
14334 [INFO] Providers - The class org.eclipse.lyo.oslc4j.provider.jena.OslcXmlCollectionProvider was registered as a JAX-RS MessageBodyWriter provider for java.util.Collection Java types and application/xml media types.

This is actually the output with the date & logger shortened already. Problems:

• Some messages are printed more than once: see OslcXmlArrayProvider ... and text/xml media types.
• The messages are overly verbose. How about Registered OslcJsonLdArrayProvider as a MessageBodyReader for 'application/ld+json' MIME type. If you want the original one, we can leave it at a TRACE level
• I don't think it's an important INFO. We can make them DEBUG messages.

In org/eclipse/lyo/oslc4j/provider/jena/AbstractOslcRdfXmlProvider.java:167, we do something really strange: we catch all exceptions and rethrow them as a WebApplicationException. Apparently, this was done to trigger a 500 error on the server side (which is wrong, because it's not Lyo's job to decide what code will the OSLC Server return when dealing with unexpected error). Worse still, when I hit this exception through Lyo Client, it fails similarly, making me think that the server returned 500 in response, while in fact Lyo Client did not even send a request yet.

Suggestion: rethrow an IllegalStateException

I am updating my OSLC server to JAX-RS 2.0 (from the 4.0 snapshot deps) but there is some conflict with the JSR311 (JAX-RS spec no.) dependency. It IS NOT in my POM file by mistake, it should come from Lyo Core somewhere:

2019-02-17 03:26:17.448:WARN:oeja.AnnotationParser:qtp1321640594-13:
javax.ws.rs.ext.MessageBodyWriter scanned from multiple locations:
jar:file:///tmp/jetty[...]/lib/javax.ws.rs-api-2.1.jar!/javax/ws/rs/ext/MessageBodyWriter.class,
jar:file:///tmp/jetty[...]lib/jsr311-api-1.1.1.jar!/javax/ws/rs/ext/MessageBodyWriter.class

Note that the JSR311 dependency is of the wrong version.

Due to #109

Requires #110 before release

Obsoletes #58

Writing to 'application/ld+json' MIME type never work , OslcJsonLdProvider is never called.
Probably same problem for OslcJsonLdCollectionProvider and OslcJsonLdArrayProvider.

Cause:

OslcRdfXmlProvider.isWriteable(Class<?>, Type, Annotation[], MediaType) in the parent OslcRdfXmlProvider class hard codes accepted media types when calling static isWriteable(...)

During the startup of an adaptor, the following exception is thrown:

java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder;
	at javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:119)
	at org.eclipse.lyo.oslc4j.core.OSLC4JUtils.servletUriBuilderFrom(OSLC4JUtils.java:478)

I initially suspected the problem with some leftover JAX-RS 1.1 maven dependencies, which has lead me to attempt removing jsr311-api from the trs-server repo: eclipse/lyo.trs-server#7. Only later I understood that Wink never supported JAX-RS 2.0 and instead it is likely that we accidentally depend on some JAX-RS 2.0 APIs before having migrated to Jersey!

I will keep this issue updated as my investigation progresses.

Sometimes one needs to include a Lyo library (core, client, trs) as Eclipse plugins. provide an update site for people to download such plugins.

There has been a number of pull requests (attempts) at this, but here is an issue to collect some ideas.

• #62 in Core
• #35 in Core
• #62 in Core
• eclipse/lyo.designer#41 in LyoDesigner

setChangeLog(ChangeLog changeLog) sets the URI of the changeLog to null.
This makes sense from the TrackedResourceSet perspective, but also destroyes the changeLog, which can be used in other context when it is not a blank node. for example, when one calls http://.../.../trs/changeLog/1.
Can we instead use JMH annotations to control how the changLog is seralized, without change it?

public void setChangeLog(ChangeLog changeLog) throws URISyntaxException {
       // Make sure the About URI of the change log is null since it will
       // become a blank node in the turtle output
       changeLog.setAbout(null);
       this.changeLog = changeLog;
   }

Comparing to other plugin projects under LyoDesigner, it seems that oslc4j-bundle does not specify its version. Could this be the reason I have had some issues using this bundle - sometimes?

That is, the pom.xml file should be

  <artifactId>oslc4j-bundle</artifactId>
  <name>${bundle.symbolicName}</name>
  <version>2.4.0-SNAPSHOT</version> <!-- This version should match the version of your project in the MANIFEST.MF -->
  <packaging>bundle</packaging>

We have an exception under https://github.com/eclipse/lyo.trs-client/blob/master/src/main/java/org/eclipse/lyo/oslc4j/trs/client/exceptions/JenaModelException.java

But it would be useful to combine all kinds of Jena-caused exceptions in the Core in a similar way.

I would suggest to move the exception to Core?

3.6.0 causes problems with deps convergence; see #57

As reported in https://github.com/eclipse/lyo.client/issues/49, I am unable to send an Object array via a Client requests. Further attempts indicate that I am equally unable to serve Object arrays either. Tested with Turtle and RDF/XML MIME types just to be on the safe side.