> First, what is your requirements for this generated XML? > Can I be sure that it will remain compatible with newer versions? i.e. > I can export from Artemis 1.0.0 and import it to Artemis 2.0.0. >
I would say the tool is part of the user interface. There is a request to improve the format a bit (use a zip file and have each message being its own file on the zip), to be similar to what's being used on Apollo. But if we implement such thing the current format would still be supported as it's part of the current "public interface" > There are a few issues with the tools in their current state that > prevents me to use them. > > * The exporter only prints to System.out. This is a bug as it should > be able to print to its ActionContext's out stream instead. > * The error are written to System.err. Again, this should be printed > to the ActionContext's err stream instead. > * The commands uses the io.airlift library to display errors. > => that one is a problem for us. We have our own library to deal with > user input and output. If a problem occurs in the command, I would > like to have access to the exception directly and handle the > presentation to the user myself. > I have had a refactoring for the examples on the CLI, that I believe would address some of that. > Would it make sense to split these exporter/importer into 2 classes? > * one doing the actual job of reading files and creating the XML. I > would then use this class > * a wrapper built with io.airlift that would be used by artemis-cli I have done some of that on the CLI.. a method that would take parameters.. etc. > > I also noticed a problem with the check in DataAbstract that expects > all directories (journal, paging, bindings, largeMessages) to exist > before exporting their content. > That's actually not true. Artemis will autocreate the journal and > paging directories if the corresponding parameters (create-journal-dir > and create-bindings-dir) is set to true in its configuration. There is > no such parameters for the paging and largemessages directories. I'm not sure this is an issue on master. Did you check it recently? > > Somehow when our app server starts Artemis, Artemis also creates the > largemessages directory but the paging dir is not created until paging > is actually performed. it's changed on master already. > > Note that you don't see that when using standalone Artemis as the > "artemis run" command explicitly creates them. > > What is the correct way to deal with this? > * should the exporter tool accept that some directories do not exist? I think so, yeah. > * should artemis also allow to auto create the paging and largemessages dir? > the CLI is laready creating those now... Can you check master? I"m planning a release soon.
