Another missed thing in migration: GlobalConfig (STOPPED AGAIN...)

All of my data importers, that ultimately will load data from our legacy ancient system into our Jmix application have:

workDirPath = String.format("%s/import", configuration.getConfig(GlobalConfig.class).getDataDir());

However it seems GlobalConfig was removed in Jmix, and there’s no mention of where the equivalent functionality went to in Jmix.

We’re stuck until I get an answer on this!

Hello Jon

I had this same problem and Alexander provided his feedback here: Jmix replacements for CUBA Configuration Interfaces and built-in Freemarker functionality?

In the meantime I have refactored my implementation using the “Type-safe Configuration Properties” as suggested by Alexander and have also seen that it is used in Jmix with “Constructor binding” in several places.

I hope that this information helps. Good luck.

Best regards
Chris

I need to know where/how to get the directory that in CUBA was returned by getDataDir() - or its equivalent.

Hi Jon

All configuration interfaces can be seen in the injection menu.
image

image

I think that this will give the desired path to the file storage: localFileStorageProperties.getStorageDir()

@andrey_vb - FileStorage doesn’t sound like the right place - I’m not wanting to work with the file storage here, I just need a working directory to get CSV files and other files I’m using to import data from our legacy system.

In CUBA, GlobalConfig.getDataDir() returns (in development mode):

C:\Users\jon\StudioProjects\MedFlexJ\deploy\tomcat/../app_home/medflex/work

The Jmix call you suggested returns (!!! sadly !!!): null

I tried various other get???Dir() methods of CoreProperties as well and they are also not returning anything in the deploy path:

Work: C:\Users\jon\IdeaProjects\jmix-pm-dec21/.jmix/work
DB: null
Conf: C:\Users\jon\IdeaProjects\jmix-pm-dec21/.jmix/conf
Temp: C:\Users\jon\IdeaProjects\jmix-pm-dec21/.jmix/temp
LFS: null

Still definitely need an answer on this. It seems the directory structure is completely different between CUBA and Jmix (there’s no deploy directory!?!?!). @krivopustov ? Anyone?

Anything? (10 chars.)

“just need a working directory to get CSV files and other files I’m using to import data from our legacy system.”

I don’t know the direct answer to your question (I stayed on CUBA for now), but, maybe I can suggest something. Maybe you can do this in an alternative way - put your config entries into a database table, simple and easy. Also, maybe your legacy data transfer application can be CUBA application? As long as it works … it’s a one-time operation.

Kind regards,
Mladen

Hi,
Jmix doesn’t have specific “deploy” directory anymore. The layout of the deployed application has changed because of the changed runtime (Jmix uses Spring Boot).

I’m sorry but this is by no means a blocker. Even if there would be no direct analog for this property in Jmix, you can store the files in any directory you want. You are completely free to do that. I don’t understand why do you need so much some built-in configurable directory in the platform?

The closest analog of the getDataDir() is the getWorkDir() in the io.jmix.core.CoreProperties configuration bean that can be injected to any bean. E.g. this directory is used by the “file system” file storage implementation.

Because in most platforms, you can’t just store files in arbitrary directories. And, I need a way to get a path from somewhere, at runtime, to know where files are, for processing them. It’s pretty basic…

I’m about to open a bunch of CSV files… I need to know where they are… I ask the platform. And it tells me. This is how CUBA worked. O_O

Yeah, as I said in the earlier post, that returns C:\Users\jon\IdeaProjects\jmix-pm-dec21/.jmix/work while running in the IDE Jmix Application run config. Is that directory safe to put random files/etc into and have them not removed/.etc? And what’s that call going to return at runtime in a deployed configuration?

Well, in CUBA/Jmix the platform didn’t obligate you to store files in any specific place, because the platform didn’t control the deployment runtime. So it depends on the deployment runtime. In Google Cloud for example, you can only write data to some specific directories, while when deploying to bare metal - you can write anywhere.

Jmix doesn’t control deployment runtime. It’s up to deployment environment - to control, where you can put files and where you cannot. Although nowadays it is considered a bad habit to put files locally in the file system. Cloud file storages like Amazon S3 are used to store files reliably. In the enterprise networks shared dedicated file servers like NFS may be used.

The same value, unless you change the value of the jmix.core.work-dir configuration property in the deployment environment. This property is controlled by you.

Amazon charges money for this. No point in paying them…when disc space is absurdly cheap these days.

Also, in this specific case, this is a one-time use of a few hundred CSV files containing data from our clients’ in some cases TWENTY SEVEN YEARS worth of data, to be moved from our legacy system into our Jmix app. We cannot expect clients to convert to our new system without bringing their historical data over.

… LOL. There won’t be a C:\Users\jon\IdeaProjects\jmix-pm-dec21/.jmix... directory at runtime, because likely it won’t be deployed on my local Windows machine that I’m using for development. Likely it will be in a Docker container, so I’m wondering what directory that will end up being. And I can’t just test it, because the app DOESN’T RUN YET because you guys rushed the migration to market by at least 6-8 months it looks like.

The promises of “easy migration” are definitely not even close to being met. I think our subscription warrants a little better support than this.

Oops
I meant, the default value is jmix.core.work-dir = ${user.dir}/.jmix/work.
The user.dir is the directory where java was run from, where you started the JVM.

Fair enough. So it should all “just work” like it used to.

Now to figure out how to query the user database and figure out why the continual generation of broken Liquibase changelogs. (I have posts up about those issues too.)