ResourceFactory.java does not implement "newUrlResource(...)", but manual says it does.

[Thomas Ochsenfarth]

Hello there,

I am using Drools and want to use ResourceFactory.newUrlResource(myUrl). The manual/documentation says it is part of the specification 

https://docs.drools.org/8.29.0.Final/drools-docs/docs-website/drools/_images/KIE/BuildDeployUtilizeAndRun/KieResources.png 

So is this a bug or on purpose? And is this the right forum to ask for it?

I declare my need for this function :) 

Thanks for help.

Thomas

[Thomas Ochsenfarth]

Here the link to the Java class. At the moment on Branch master there isn't a method like that.

https://github.com/kiegroup/drools/blob/main/kie-internal/src/main/java/org/kie/internal/io/ResourceFactory.java

[Mario Fusco]

Hi Thomas,

What you found in Drools docs is a leftover of the 7.x series. We're already fixing the documentation removing that section, thanks for having reported this.

In Drools 8 we decided to remove the possibility of loading a resource from any possible external URL mostly because we believe that this could open a potentially big security hole. That said I'd be curious to know for which reason you wanted to use that feature. I must admit that we thought that nobody was using it anyway, but if you have a compelling use case that we missed it would be great if you could share it and we may reconsider this decision.

Thanks,
Mario

[Thomas Ochsenfarth]

Hi Mario,

thanks for the reply. Okay, having a relict from previous versions in the manual is totally valid :) 

Indeed it could be a security hole, but I think you could say that is up to the developer and software architect to decide whether or not to take the security risk. Right? :)

The case of our company is as follows:

We have a rather big application which is deployed at like 12 Locations in an internal network. In order to keep our drools excel-sheets separate, we manage them in dedicated repository with one responsible maintainer for that. It's accessible read-only for users without credentials. Those 12 Locations access that repository via HTTP-URL i.e. ResourceFacotory.newUrlResource(). We developed an extra function to reload Drools-Sheets in real time in our application.

This approach has a few advantages: We don't need further infrastructure to provide all locations with the newest drools-rules, just the git repository and in our case (gitblit, yeah old, but works for this purpose). We can update the drools rules without deploying the entire software-package or restarting the application. Drools rules are maintained at a single spot and easily edited, since the repository just has a few rule-sheets and is therefore low in MB-Size. 

 
It's easily setup, easy to maintain, maximum flexible and works absolutely fine for us. Even the not so skilled developers easily understand this setup.

Without the access via URL, we need to make the drools files available at each location which means extra effort to distribute and update.

Please let me know if you plan to bring that feature in again, since we will have to adapt and figure out a different solution for us to make the drools-sheets at all locations accessible and easily updated. :)

Thanks,

Thomas

[Mario Fusco]

Hi Thomas,

I understand your use case and it makes totally sense. However I still believe that this feature shouldn't be natively present in Drools for a twofold reason:

1. As I wrote in my former email I'm afraid that it may create a security problem. I agree that it is up to the developer and software architect to decide whether or not to take the security risk, but it is up to library/framework/toolkit provider to make sure that his software doesn't open the door to that security risk out of the box :)
2. As a general guideline we're trying to make the core of Drools minimal and more modular. Following this idea I believe that reading a resource from an arbitrary URL shouldn't belong to a rule engine, in the same way than allowing requests to arbitrary LDAP and JNDI servers shouldn't belong to a logging framework https://en.wikipedia.org/wiki/Log4Shell

That said I don't see why you couldn't keep your architecture exactly how it is. You could take the original URLResource class that we removed from the Drools code base and basically use it as it is (or with very small adaptations) in your own code https://github.com/kiegroup/drools/blob/d7f565879f21d2670a7eea4e513d32379fdfad91/drools-core/src/main/java/org/drools/core/io/impl/UrlResource.java

Do you think this could work for you and solve your problem? Am I missing something?

Cheers,

Mario

[Thomas Ochsenfarth]

Hi Mario,

I enjoyed your first point. Haha.

Copying the original Class came to our mind, too. I just wanted to have clarification whether it is a bug or conscious choice to have parted from the URLResource and whether or not the manual is just not up to date or there is really missing something in the implementation.

 

Always feels, gently said, odd to customize, even if it is only a small cherrypick, a public, well maintained project. My common sense said better to have a nice and fun chat with the developers first :)

Since you recommended that solution now, we will go with that and I predict too it will do perfectly well for us.

Thanks and cheers,

Thomas