Much easier than that. Look at TestAIS.scala:
https://github.com/apache/daffodil/pull/651/files#diff-59f6bd4163627aa9de0ed8b2ff04ba8c60c7c45fc99e6abed430d0a6a46c4c91 You just call LayerCompilerRegistry.Register( AISPayloadArmoringLayerCompiler) >From the test object. That's all an application using Daffodil with a custom layer has to do also. Honestly, I almost prefer this to dynamic loading. On Wed, Oct 6, 2021 at 3:50 PM Steve Lawrence <slawre...@apache.org> wrote: > Don't those only work because they are built in to Daffodil and > pre-registered? If someone wants to keep their layer outside of > Daffodil, it needs to be manually registered, but that can't be done by > the TDML Runner or CLI? > > On 10/6/21 3:38 PM, Mike Beckerle wrote: > > The TDML runner invoked from JUnit works fine. > > The AIS Payload Armoring, and the CheckDigits and the IPv4 examples in > > daffodil-test work this way, and anyone's DFDL schema could do the same > > thing. > > > > I plan to update the ethernetIP and PCAP schemas to compute their > checksums > > this way. > > > > Only the CLI is left out. > > > > > > On Wed, Oct 6, 2021 at 2:26 PM Steve Lawrence <slawre...@apache.org> > wrote: > > > >> If we don't support dynamic loading and instead require that users > >> manually register the layer, that means that externally defined layers > >> cannot be tested using the TDML runner, right? It also means there's no > >> way to run schemas with external layers using the CLI? > >> > >> I guess that's not an issue until there are external layers, so maybe > >> not critical, but still feels pretty important. Maybe adding it to the > >> next release is reasonable, since that's probably when external layers > >> might start showing up? > >> > >> On 10/6/21 1:47 PM, Mike Beckerle wrote: > >>> I have done a bunch of improvements to the code for this layer loading > >>> based on the prior PR. > >>> > >>> It is now stabilized and worth it to examine/reexamine the PR at this > >> point. > >>> > >>> https://github.com/apache/daffodil/pull/651 > >>> > >>> I have also changed the goals here somewhat. I split out the > >>> defining/creation of a Java API for layers, and true dynamic loading > via > >>> service loaders into a separate JIRA ticket DAFFODIL-2567. > >>> > >>> I think that experience with what we have so far makes sense before > >>> defining any Java API for doing this. I also think the need for true > >>> dynamic detect and load behavior is far less critical than the basic > >>> ability to define these in external jars that aren't part of daffodil. > >>> > >>> This PR now includes just the modularization of layers, so they can be > >>> written in scala and defined in a jar outside of Daffodil, An > application > >>> must register them for use by calling > >> LayerCompilerRegistry.register(...). > >>> > >>> All the built-in layers are in daffodil-runtime1-layers which is a new > >>> module. > >>> > >>> Other layers are defined in daffodil-test for testing that > >> checksums/check > >>> digits work. The example AIS payload encoding layer is also now defined > >> and > >>> tested in daffodil-test. > >>> > >>> On Sat, Sep 25, 2021 at 8:31 PM Mike Beckerle <mbecke...@apache.org> > >> wrote: > >>> > >>>> Please see: > >>>> > >> > https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Dynamically+loading+Layer+Transformations > >>>> > >>>> Also: https://issues.apache.org/jira/browse/DAFFODIL-1927 > >>>> > >>>> See related PR: https://github.com/apache/daffodil/pull/643 which is > >> for > >>>> https://issues.apache.org/jira/browse/DAFFODIL-2221 > >>>> > >>>> Please add comments or directly edit that wiki page, or discuss in > this > >>>> email thread if you prefer. > >>>> > >>>> > >>> > >> > >> > > > >
