[MGNLTOOLS-2] Provide binary/executable assembly Created: 01/Jul/08  Updated: 10/Jan/14  Resolved: 04/Jul/08

Status: Closed
Project: Repository Tools
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Task Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MGNLTOOLS-45 Running RemoveNode on a UUID doesn't ... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:

 Comments   
Comment by Magnolia International [ 02/Jul/08 ]

now uses a custom classloader to reuse the webapp's lib folder and is packaged in zip and tar.gz files !

Comment by Philipp Bracher [ 03/Jul/08 ]

Would like to improve that in a way that the original arguments are passed to the executable as they may contain extra arguments (uuid of a node, different set of optinos, ...).

We could change it as such as the Launcher reads only the lib option. Then it executes the static main class of the loaded class. This would make the Launcher more flexible and usable for all executables (only condition is having a static main method). The AbstractExecutable would remain as it has been before.

Comment by Magnolia International [ 03/Jul/08 ]

Like I thought earlier (when we discussed the observation module vs jackrabbit dependency) : a class won't load if it imports other classes which are not available in its classloader.

This is the reason I had to introduce the ExecutableConfig class: the Executable implementations import magnolia-core classes, so even if the cli parsing is done in the abstract superclass, the implementations won't load, since we don't have the option yet that tells Launcher where the libs are.

Since you need the Options instance to parse the args[], we're more or less stuck; as it is, the options are rather easy to use, since, by default, you only need to specify the webapp location (which defaults to the current directory), the libs directory defaults to <webapp>/WEB-INF/lib

We could still pass the original arguments or the CommandLine instance to the exec() method, but even if cumbersome, the cleanest way to have additional/different options at the moment would be subclass Launcher. I'll refactor a little to make it easier. Since you anyway need to specifiy both the launcher and launched class in the pom, it seems ok... no ?

(alternatively, custom launchers might not need the executable class name passed as a parameter, since they'd probably be specific to said executable - but the end result would still be that you'd need 2 classes if you need custom options)

Comment by Magnolia International [ 03/Jul/08 ]

Additionally, moving all the cli stuff away from Executable makes the implementations much more testable !

Comment by Philipp Bracher [ 04/Jul/08 ]

I'm not convinced. If the class loader of the loaded class is the isolated one it should work (at least it works for me). Ideally the launcher has no dependencies (so I would not use cli to parse the options).

Comment by Magnolia International [ 04/Jul/08 ]

provided BasicLauncher (common magnolia-related options) and SimpleLauncher (lib options and wrapping other arguments) + samples

Generated at Mon Feb 12 10:40:09 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.