Develop Reference

filenet JAVA API retention periode not updated

I've been working on a project that use filenet for multiple parts of the project.
I've been asked to remove a boatload of file's that need to be removed. The reason why I was asked is because the assumtion was made we could remove the data through a java application.
And so far so good honestly. I've been able to use code left by former project members to create a delete application. However, i've come to a single problem in this issue: the retention date.
When I delete a file it will display the error message: Content Engine cannot delete or move content because the retention period for the item has not yet expired. Current time: 9/16/21 8:43 AM; Storage period: 20-12-99 1:00.
I've created code that does change this. However the above error is still appearing. I;ve doubled checked the retentiondate property in the specifice file, and this has been changed.
I've looked through all the properties of the file and have not spotted anything that includes this date.
So my questions is, what am I missing? Is this something from filenet?

The retention period is probably additionally set on the storage device and the storage device is not aligned with filenet.
What type of storage backend are you using.

Please check this doc https://www.ibm.com/docs/en/filenet-p8-platform/5.2.1?topic=objects-retention-limitations-constraints
And this https://www.ibm.com/docs/en/filenet-p8-platform/5.2.1?topic=objects-security-permissions-required-setting-modifying-retention
Sure that you have enough permissions for the principal that you are using for API calls.
And check this page https://www.ibm.com/docs/en/filenet-p8-platform/5.2.1?topic=sweeps-deleting-objects-sweep and this https://www.ibm.com/docs/en/filenet-p8-platform/5.2.1?topic=sweeps-updating-object-retention as alternative way to delete objects without API and custom app.

Best way of cache-management with spring for static files

I want use cache control in spring mvc for static files.
I have gone through the following scenarios
Using WebContentHandlerInterceptor.
Using browser cache headers.
Using mvc:resources
Version number/build number for the js files.
But my problem is when the user comes for the first time it is loaded with the latest static files. If I update any JS files that are needed to be updated in the test or production server before the cache expiration. The browser is taking only from cache until I reload using F5 or Ctrl+F5.
When the user is requested a page, then all static files are to be checked and if they are not modified then it has to use cache otherwise take the latest one from the server.
Please help me.. I am newbee to this stackoverflow.

To ensure browser to download the latest version of your static files is to add a parameter to the URL.
For example, your request will look like resources/scripts/menu.js?ver=1.0.

Remove .html extension using Google Appengine with Java

I am incredibly confused here. I've been using Google Appengine for our webserver and it's been working out great so far, but I had a request to have the webpages load without the .html extension. I've been doing some reading and see that I need to create an app.yaml file to map the url to something else? This is what I have in my file so far:
application: company-website
version: 1
runtime: java
threadsafe: true
handlers:
- url: /about
script: about.html
I've been trying to read how to do this on their documentation site but I can't seem to find anything referencing how to remove the extension and still have it point to the right html file. Can anyone help me out? Can I just do this in the appengine-web.xml file, also? It seems like I could just do it in there without creating an app.yaml file.
Any help would be appreciated. Thanks!
edit: tried some more things.. Tried moving the file I'm trying to remove the extension on to its own folder like so:
/root
-index.html
-/about
-index.html
And this was OK, when I typed my domain.com/about/ it appears to be working but when I typed domain.com/about it does not. Very frustrating.

In an ideal world we would have the option to configure a rewrite like apache's mod_rewrite in the underlying web server. Sadly it is not possible to configure a rewrite on such a level.
I searched around a bit and found that the most common answer for a rewrite is to user either UrlRewriteFilter or to wire up the servlets yourself. Both options are explained in
Catch-all URL rewrite on Google App Engine (Java)
Pretty URLs in Google App Engine
Both work in the same way and will require the app to serve static content through app engine. This will result in app engine instance hours and slower responses since all you static files move from Google's content delivery network (cdn) to your bottleneck app. The aproaches possibly also require you to deploy your static files as resource instead (How-To configure static-files and resources), at least that is how i have done this before.
These are the 'pure Java' options you have. The app.yaml approach that Josep Valls described will work in with Java on App Engine. The main question here is if the app.yaml configuration is low level enough to be a rewrite that google recognizes in its cdn, or whether you'll still burn through instance hours because all content is served through instances.
The documentation tells us:
For efficiency, App Engine stores and serves static files separately
from application files. Static files are not available in the
application's file system. If you have data files that need to be read
by the application code, the data files must be application files, and
must not be matched by a static file pattern.
Since this comes right before the section that explains how to configure the static file pattern handlers one should assume that the configuration of such handlers will not break the logic that is mentioned above - that is
stores and serves static files separately from application files
Whether this assumption is correct is an easy experiment which i shall conduct given time and report my findings here.
These are all the existing options I could find and know of. If anyone knows more on this topic, please comment / respond.
EDIT (7.12.2015)
My maven target appengine:devserver is completely oblivious to settings in the app.yaml. I'll have to experiment with this during one of the next deployment phases or use mvn gcloud:run.
... later that day:
Rewriting the URL via Servlet (like with Paul Tuckey's UrlRewriteFilter) does not work for static files. You would have to deploy the files as resource files. Static files reside somewhere else and will not be found if forwarded to by a servlet. At least that's how i understand it.

In Python and Go you can use regular expression matching in your url handlers; if Java also uses app.yaml you could probably do this:
- url: /(about|other|sections)$
static_files: \1\.html

Verify Files in Local Machine is Up to Date with Dropbox server

I am developing a java app. i want to add feature to my app for verify files in my local dropbox folder is match with the files in dropbox server. how could i check my local dropbox folder is up to date ?
i found this on dropbox api. https://www.dropbox.com/developers/reference/api#delta
but haven't idea about how to use it.

The /delta call is the best way to keep your app's state up to date with Dropbox (as long as you're interested in more than just one file or folder.) You've already found the docs:
https://www.dropbox.com/developers/reference/api#delta
There are also two posts with some notes from the beta period:
https://www.dropbox.com/developers/announcements/15
https://www.dropbox.com/developers/announcements/16
You can find the Java SDK here:
https://www.dropbox.com/developers/reference/sdk
Inside the Java SDK, you'll find a working example app that uses /delta, named "SearchCache".
While the above resources will do a much better job explaining /delta, the basic idea is that when you first call it, you get the state of the Dropbox account, and on all subsequent calls, you get the "delta" of what you need to know to get up to date.

Tomcat 7 keeps using an old jsp after an update

We (the people at my company) have created an application for Tomcat that uses servlets and jsp's as a GUI a while ago.
We've just now finished an update where one of those jsp's is heavily altered. But when we replace the war file on one computer, it keeps using the old jsp (of which all traces were deleted from said computer) whereas it works perfectly everywhere else.
The problem persists even after the computer was restarted.
Has anyone ever seen such behaviour? What can be done about it?

This may be because of the caching. First of all make confirm that the project is cleaned properly. and check the html of the page if the page contains old code or the latest one if old code is there then browser is getting the old files so try to clear the cache of your browser and then try to execute.
how to cleare cache firefox chrome

Does deleting all traces also imply a "clean" on the server? You probably know that it keeps some classes(especially compiled jsps) in the "work" folder

The problem very likely is caused by timestamp mismatch. The newly uploaded JSP page or servlet has an older timestamp than that of the cached page or servlet on the server. To avoid the problem, ensure the system clock on the machine where the JSP or servlet uploaded from is in sync with the system clock of the machine where the server is running on. To remedy the problem, check the following:
• Make sure the file transfer client (like winscp known to cause problem) date, time and time zone is in sync with the Apache Tomcat server.
• Verify the JSP date, time and time zone is up to date with the Apache Tomcat server. If not, re-deploy the JSP with the correct timestamp.
• If updating the JSP timestamp failed, the last thing you want to do is to remove the JSP in Apache Tomcat work directory if you don’t have important sessions to keep.

Stop the server.
Delete webapps/APP_NAME folder
Replace webapps/APP_NAME.war with the new one.
Start the server.
this should help :)

I had the same problem but it wasn't the tomcat.
My Apache was set to allow browsercaching for text/html and text/plain types for 1 month.
The call of that page was made per JavaScript and even if you reload the page with Ctrl+F5 those JavaScript calls are still loaded from the browsercache.
After clearing the browsercache i got the right page.
From now on i don't enable browsercaching for those types in apache anymore.

The problem persists even after the computer was restarted.
If you've deleted the JSPs, then the problem has to be compiled JSPs in the work directory tree. Take off and nuke them from orbit :-)