1
votes

this is a tricky one (at least for me):

I've created a Javascript file, let's call it "test.js", which I uploaded to the Shared Components -> Static Files repository with no application associated in particular.

This file it's been referenced by page X with NO cache setting, on the Javascript -> File URLs field like this: #WORKSPACE_IMAGES#test.js

So far so good, the functions on the library were been called and executed correctly.

But I've came across a little bug in the file which I've proceeded to correct and then modify in the uploaded version of the file (been the file lesser than 30000 bytes I was able to modify it on the spot, hitting apply changes). After this I've deleted the history and temp files on the browser. However when I run the page again the error persists, because, as shown on the console, the file been used is the previous one, not the fixed version. A little weird...ok, but that's not all, I've decided to delete the file from the repository and upload it again (same name "test.js") with no application associate again, delete the history and temp files on the browser again, and run the page (again ). And again (hehe...) the error persists and the file been called is the nonexistent one.

So lastly I've decided to make a little magic trick and delete the file but not upload it, leaving the reference to #WORKSPACE_IMAGES#test.js on the page properties, delete history and temp file on the browser and run it once more, this time decided to break the page, and yet it works!, wrongly because it's the buggy file but it's there!, then I said: "ok, browser issue..", run it on Chrome (by the first time ever) and the file it's there, then I said: "ok, machine issue..", run it on a new machine (by the first time) and the same nonexistent buggy file it's been loaded...

This file it's not been referenced by any other application (yet). On runtime the nonexistent url's file is:

http://192.168.141.14/apex/wwv_flow_file_mgr.get_file?p_security_group_id=3321831433497474&p_fname=test.js

I've uploaded the same file with a new name let's say test_1.js, change the page reference to this new name and then the page load the correct new file. But this it's not a desirable behavior I was lucky that this was the first reference to the file, but if this would happen on a more advanced stage it would be a major problem.

Sorry for making it a little extensive but I tried to be thorough with this, did I miss something? Why is this happening? Any help will be appreciated.

I'm using:

APEX build 4.2.3.00.08

Database

  • CORE 11.1.0.7.0 Production
  • NLSRTL Version 11.1.0.7.0 - Production
  • Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit
  • Production PL/SQL Release 11.1.0.7.0 - Production
  • TNS for Solaris: Version 11.1.0.7.0 - Production
2
Sounds completely like a caching issue. I think you can set options in Apex for how long the file is cached in WORKSPACEKevin Brown
@KevinBrown how would you do that?Typo
I had to do something here, using this documentation docs.oracle.com/cd/E21611_01/doc.11/e21058/… as www_flow_files* was in my configuration which cached all the images.Kevin Brown
sometimes you could also just add a random parameter on the url as in ttp://192.168.141.14/apex/wwv_flow_file_mgr.get_file?p_security_group_id=3321831433497474&p_fname=test.js?random=7386734 where "random" changes with each callKevin Brown
@KevinBrown let me try that tomorrow and comeback to you later on.Typo

2 Answers

1
votes

I've found a workaround for this problem, that looks it's been around since APEX v3.1

From PLSQL Developer run the code below as the apex workspace owner:

set serveroutput on
declare
  l_security_group_id number;
begin
  select workspace_id into l_security_group_id
  from   APEX_040200.APEX_WORKSPACES;

  wwv_flow_api.set_security_group_id
      (p_security_group_id => l_security_group_id);

  wwv_flow_api.create_or_remove_file
    ( p_name           => 'test.js'
    , p_location       => 'WORKSPACE'
    , p_mode           => 'REMOVE'
    , p_type           => 'JS'
    );
  commit;
end;

First part sets the apex engine to point to the correct workspace id in Apex.

Second part is the procedure that should remove your file from the database.

Still, this shouldn't be necessary if the apex engine deleted the file as intended...

0
votes

I've seen this question a few times (eg https://community.oracle.com/thread/867412?start=0&tstart=0) and I have a feeling it's a known issue, but I can't find a decent reference

Here is a deeper conversation on the topic https://community.oracle.com/thread/674635?start=0&tstart=0

I've found deleting the file and reloading is a workaround, or store you files on the web server - if possible.