I have probably maximized my inquries today LOL. HOWEVER! I have yet another question regarding custom jars, I am not a java person, so I apologize. I was reading this: https://commandbox.ortusbooks.com/release-history/5.x-versions/whats-new-in-5.3.1#recursive-jar-scanning-libdirs The reason I pondered on this is after using

server forget

to delete some servers, I forgot that there were jars that I needed to put back after creating the new server. Then I thought how it would be nice to be able to delete a server and spin up a new server at whim without having to manually add jar files back into the lib folder within Lucee. I read this and used

server set app.libDirs=lib

I verified it is within the server.json. Also, I confirmed the jars are in the new custom lib folder. I restarted the server, but the website errors because it cannot find the jar file. I moved the lib folder around to see what, if any, different errors may occur and it does throw an error in commandbox when it cannot find the lib folder, so I am pretty sure that the lib folder is getting recognized during the spin up. The following is the line that errors:

<cfset flyway = createObject("java", "org.flywaydb.core.Flyway").init()>

Maybe I cannot do this or this is not pointed in the cfset correctly now that the flyway jar is in a custom lib?

the libDirs is an absolute path or relative to server.json so

server set app.libDirs=lib

implies that lib is in the same directory as server.json

right, and it is in the same directory

ok so a quick look at the java docs Flymay does not have an empty constructor you will need something like

flyway = createObject("java", "org.flywaydb.core.Flyway").configure().dataSource(url, user, password).load();

hmm, reading this doc again, it says that CommandBox used to only load jar files found in the root. Is that the root of where server.json lives or the web root?

@ryan Do a

--trace --console

start and you'll see a list of every jar that CommandBox class loads from your lib dirs 🙂

ok

CommandBox doesn't have any folder it loads jars from automatically. You have to tell it

right, you chimed in and I didn't finish LOL

You are totally correct to not want to have to manually install the jars every time

I need to refrain from using Application.cfc because it is in a repo that goes to production that will not have the lib directory. I like the box.json approach as it is essentially non-evasive to any repo files.

I solve that by hosting prod on CommandBox as well, but to each their own 😆

I actually will need to read up on regarding commandbox and production, but we get a lot of clients that have various different setups, so we essentially leave it that way.

We use Docker for prod, but it's great for the env vars, cfconfig, server.json, etc to just be the same all the way across the board

right, i noticed the env vars

Generally speaking, using CommandBox on production is the same as using it on dev. Just ensure your

profile

is set to

production

so it's secure by default and set it up as a Windows service (which we have a module for)

very nice

We have clients doing this just with windows Vms because it's easier to deploy a new server than a typical CF install and manual setup

yes, it is haha

The next version of CommandBox will support mod_cfml out of the box which will remove the last big blocker for people

it makes life so much easier for development

you'll finally be able to sit a single CommandBox instance behind Nginx/Apache/IIS to have it host multiple web roots

very nice

did you see the comment above? you can not use .init() the class does not have an empty constructor

flyway = createObject("java", "org.flywaydb.core.Flyway").configure().dataSource(url, user, password).load();

i overlooked that @thisOldDave. Checking

@thisOldDave This is interesting because it worked this way when I threw the jars into the Lucee lib folder previously

@ryan Did you run

box install

or just add the dependency

got it

Yep, or you could do it the other way around. Run

install "jar:<https://search.maven.org/remotecontent?filepath=com/github/spt-oss/flyway-core/5.2.4.0/flyway-core-5.2.4.0.jar>"

and it will • download/install the jar • add it to the

box.json

for you

oh very nice

I don't really know enough about your setup to know what you've got going on.

that's exactly what I have in my server.json

Note, the

intsall

command just piuts the jar on disk. A CommandBox isn't going to load it unless you tell it to

It has loaded the jar based on the

--trace

No, CF Mappings have nothing at all to do with loading jars

I believe the file pulled from search.maven.org is not quite the same as the file that I have been using. The file name is essentially the same except that my maven's file is 5.2.4.0 and mine is named with 5.2.4. When I swap these files and place the file I know is good into the subdirectory, then everything works. The definition for the class does not exist in the jar that is pulled from the maven website.

cannot load class through its string name, because no definition for the class with the specified name [org.flywaydb.core.Flyway] could be found caused by (java.lang.ClassNotFoundException:org.flywaydb.core.Flyway not found by lucee.core [48];java.lang.ClassNotFoundException:org.flywaydb.core.Flyway;)

The Error Occurred in
\htdocs\db_migrate.cfm: line 56 
55:
56: <cfset flyway = createObject("java", "org.flywaydb.core.Flyway").configure().dataSource(jdbcUrl, user, password, initSqls).load()>
57:

This indicates to me that everything is working in terms of Commandbox and all, it is just the file itself is not exactly the same as was expected.