Sorry to have wasted anyone's time. I discovered that shell.env did expand wild cards, so was able to handle the large classpath with no problem.
Peter On Thu, Jul 18, 2019 at 7:28 AM Peter Abramowitsch <[email protected]> wrote: > Hello > > I'm looking for advice from anyone who might have experience in this > particular area. I've got an entity which is not pre built, so I'm using > the VanillaJavaApp. This app, however has a very large class path which > includes both many jars and large numbers of XML files. Literally > hundreds. Unless I'm not sure how to escape it properly, it seems as if > wildcards used in Brooklyn classpath definitions are not expanded at the > remote end. > > I've used both the list and string versions of the classpath, as in > > vanillaJavaApp.classpath: "lib/*.jar:resource/*" > > or > > vanillaJavaApp.classpath: > - lib/*.jar > - resource/* > > I've tried using paths relative to run.dir and absolute paths But the > problem seems to be in the expansion, not the file path > > Here are options I've thought of, but perhaps you have a better suggestion? > > 1. List every item in a classpath - well over 200 items: Ugly > 2. Converting to a VanillaSoftwareProcess and controlling a script to > launch my java process. That, I assume, could expand wildcards at the > remote end Ugly, but easy > 3. Finding some way to harness $brooklyn:external to populate the > classpath. Can it be done? > 4. Referring an environment variable in the class path configuration that > is expanded at the remote end: Not sure how to do this > 5. Turning the whole thing into a single executable jar file: Ugly and > unwieldy > 6. Subclassing VanillaJavaApp changing its behavior at the remote end to > be able to process wildcards: Not sure if it can be done > > Many thanks in advance for your suggestions! > > Peter >
