Base URI for Resources

[Jeff Bradley]

We need to store XSD and XML in a database (not on a file system), exposed over http. I see that there is a base URI property of the URIResourceLocator, but it is not clear how to utilize this. Here is an example of what we are trying to accomplish:

In this scenario, we map EDI to Java. There are three config resources:

1. The schema XSD.

2. The java bean mapping XML.

3. The smooks config file that references both files above.

Here is the example smooks config file:

<?xml version="1.0" encoding="UTF-8" ?>
<smooks-resource-list
xmlns="https://www.smooks.org/xsd/smooks-2.0.xsd"
xmlns:edi="https://www.smooks.org/xsd/smooks/edi-2.0.xsd">

<edi:parser schemaURI="http://localhost:8081/shipment-status-message"
segmentTerminator="~"
dataElementSeparator="*"
compositeDataElementSeparator="^"/>

<import file="http://localhost:8081/shipment-status-message-map"/>

</smooks-resource-list>

Is such a config possible (over http), and if so, how can we specify the base URI in the properties file so that the URI in the config file can address just the resource name, as below:

<import file="shipment-status-message-map"/>

[Claude Mamo]

<edi:parser schemaURI="http://localhost:8081/shipment-status-message"
segmentTerminator="~"
dataElementSeparator="*"
compositeDataElementSeparator="^"/>

I don't think Daffodil supports referencing schemas from HTTP. It doesn't even appear possible to configure its schema URI resolver as commented in https://issues.apache.org/jira/browse/DAFFODIL-1073. It might be good to remind the Daffodil folks about this issue. The next best thing could be to create a file from http://localhost:8081/shipment-status-message right before initialising Smooks and reference that file from schemaURI. This might not be ideal since edi:parser won't take in the latest schema if the schema stored inside the database is updated.

<import file="http://localhost:8081/shipment-status-message-map"/>

As you hinted, it should be possible to customise URIResourceLocator so that Smooks fetches the external config from HTTP. You can set your own URIResourceLocator on Smooks#getApplicationContext#setResourceLocator(...).

Claude

--
You received this message because you are subscribed to the Google Groups "Smooks Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smooks-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smooks-user/324229d8-013d-499a-aba1-3aed513b556cn%40googlegroups.com.

[Jeff Bradley]

Thanks for the response. I am able to fetch the smooks config and the imported file over HTTP, so that is good. As for XSD files, we will have thousands of them that will be constantly changing (imagine a team of users dedicated to maintenance of such schemas). Unfortunately, without the ability to store the XSD files in a database or in cloud storage, this solution is severely limited. Even if we digress to storing files on disk as opposed to database, in a modern Kubernetes architecture like we use that becomes a pain and is usually not permitted by our devops engineers. 

[Claude]

You could extend edi:parser to create your own reader that fetches the schema from the HTTP endpoint and save it to a temporary file. Alternatively, you could avoid extending the reader and just configure edi:parser programmatically to reference the temporary file schema. Of course, the problem still remains that the local schema won't be refreshed if the schema in the database is updated. One idea to solve this problem may be to create a pool of Smooks instances which expire after a while. After expiration, the pool would fetch again the latest schema and create a Smooks instance to replace the expired instance. Even more sophisticated would be a solution where the pooled Smooks instances are invalidated after a schema change.

Claude

[Claude Mamo]

And now that I'm giving it further thought, you could reduce the solution to a pool of readers instead of a pool of Smooks instances. It would require implementing your own ContentDeliveryRuntimeFactory and ReaderPool but it should be doable.

Claude

You received this message because you are subscribed to a topic in the Google Groups "Smooks Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smooks-user/-7GlPzJeYNQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smooks-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smooks-user/6da3b599-459a-4938-b3ad-4b08db9b8d2bn%40googlegroups.com.

[Jeff Bradley]

Those are great suggestions. Thank you.

[Jeff Bradley]

Reading the schema from a file on the local file system is not working either. With the XSD stored in /tmp/mappings/test directory, the reader still cannot find it. 

EdiReaderConfigurator configurator = new EdiReaderConfigurator("/tmp/mappings/test");
configurator.setCompositeDataElementSeparator("^");
configurator.setDataElementSeparator("*");
configurator.setSegmentTerminator("~");
smooks.addConfiguration(configurator.toConfig().get(0));

That throws the same error, even though that file contains the schema:

Caused by: org.smooks.api.SmooksConfigException: java.lang.RuntimeException: Schema Definition Error: No schema document at location /tmp/mappings/test.

It seems that the XSD has to be in the module's resources folder. 

[Claude Mamo]

The URI scheme needs to be file:

EdiReaderConfigurator configurator = new EdiReaderConfigurator("file:/tmp/mappings/test");

Claude

To view this discussion on the web visit https://groups.google.com/d/msgid/smooks-user/2b55899b-82a2-4d88-a30f-ca7fe24e793an%40googlegroups.com.

[Jeff Bradley]

That did it. You're awesome.