You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When try to install a new copy of FTLDB into another schema, installation process fails.
Investigation
The problem appeared with the solution of issue #1.
The reason is in coincidence of using the genmissing option and granting execute privilege on FTLDB classes to PUBLIC. When the second installation runs, loadjava checks if the missing classes to be generated already exist in the system. It is done by selecting the all_objects dictionary view with no filter applied to owner. The installer sees the classes (actually owned by another user) and doesn't create them in the target schema. Then the dependent FreeMarker classes cannot be resolved (with the default resolver) and installation fails.
Possible solution
Add a new installation step for revoking privileges from autogenerated classes.
The text was updated successfully, but these errors were encountered:
For Oracle 11+ divided loading of freemarker.jar classes into 2 steps:
1. Loading and generating missing classes.
2. Resolving and granting to public only for Freemarker classes, not the generated ones.
Also fixed some typos.
Problem
When try to install a new copy of FTLDB into another schema, installation process fails.
Investigation
The problem appeared with the solution of issue #1.
The reason is in coincidence of using the
genmissing
option and granting execute privilege on FTLDB classes to PUBLIC. When the second installation runs,loadjava
checks if the missing classes to be generated already exist in the system. It is done by selecting theall_objects
dictionary view with no filter applied toowner
. The installer sees the classes (actually owned by another user) and doesn't create them in the target schema. Then the dependent FreeMarker classes cannot be resolved (with the default resolver) and installation fails.Possible solution
Add a new installation step for revoking privileges from autogenerated classes.
The text was updated successfully, but these errors were encountered: