Idea: Coldbox Module + JavaLoader

[homestar9]

Starting a fresh issue and replying to: I'm willing to consider it, though my initial reaction is that I probably don't want to introduce another dependency (to keep it as simple as possible for those not using ColdBox as well). But maybe we can find a middle ground.

Could you open another issue to discuss this? And in it, can you explain how cbjavaloader makes it easier to use? Does it download the jars for you? Right now I'm not entirely understanding the friction. Thanks!

I completely understand. Honestly, I think the module will get more use from the community if it works with or without Coldbox so my approach might be a bit too opinionated based on how I personally build apps these days. The more flexible the better.

In terms of JavaLoader, what I like about it is that it makes instantiating custom jar files super easy. I chose the dependency "CBJavaLoader", but you could just as easily use vanilla JavaLoader (https://github.com/markmandel/JavaLoader). My favorite part of using JavaLoader (or CBJavaLoader) is that you can offload the responsibility of configuring jar paths to the module, so the root application that is using pdfbox doesn't need any special configuration. One good example of this is the module BCrypt. BCrypt uses JavaLoader so it can use jbcrypt.jar without the developer having to configure or mess with the root application. Once the module is installed it works out of the box (no pun intended).

Another advantage of JavaLoader is that you get a little more control when instantiating Java objects. For example, in pdfbox, you override Lucee's PDFBox version on line 503: createObject("java", "org.apache.pdfbox.pdmodel.PDDocument", "org.apache.pdfbox.app"); With JavaLoader/CBJavaLoader, you're always bypassing Lucee's native Java objects, so that line can be transformed to: javaloader.create( "org.apache.pdfbox.pdmodel.PDDocument" );

Bottom line, I think you're probably better off keeping pdfbox flexible so both Coldbox and non-ColdBox apps can use it. However, I do like JavaLoader, so you can have better control over which Jars are loaded and instantiated. It might also make configuration easier if pdfbox users don't have to make any changes to their application.cfc also.

[mjclemente]

Ahhh - the Bcrypt module helped me understand, specifically the ModuleConfig.cfc.

In there, the path to the jar is set as the libPath module setting, which is then passed to cbjavaloader.

I'm wondering if I could get similar behavior without the dependency, so that within ColdBox, you could just install it, but you'd also be able to just drop it into another app, as long as you had the jars mapped...

I'll need to mess around with it a bit - it'll be on my to-do list, but I can't promise I'll be fast.

Thanks for the suggestion!

[mjclemente]

No real progress here, but just documenting my thoughts.

Lucee enables the passing of a classPath to createObject (which is actually an existing option within the module). While I think that this could be modified to support the install-and-use approach, it wouldn't work for ACF (despite there being very old tickets requesting this functionality. A solution that supported both engines would be preferable.

It seems like the javaloader approach is the established ColdBox approach for loading jars files. It's also used in cfzxing. It would be really cool if ColdBox allowed modules to pass in jar paths that could be appended to this.javasettings, similarly to how mappings work. I need to talk to folks about that possibility.

Still on the fence about manually adding javaloader and using it internally. Definitely see the utility though.