Vince's xwork log

About software and other stuff




Your email is safe with us? (linkedin)

Linkedin shows you profile photo's of several connections to motivate you to trust them with your gmail password. Not sure this bunch is helping though....

I have seen better mug shots :P






ok, enough is enough, no more Java source folder (XPages)

Like Tommy I have been beating my head against the table trying to get all my code in the Java Source folder (8.5.3), but it is just not stable enough.
Either the page crashes for no obvious reason, or it suddenly fails to recognize the classes (File access error: Error while getting information on item $FileData Note item not found) or even worse the signature was found invalid (java.lang.SecurityException: Error verifying signature for resource WEB-INF/classes/...class).
Rebuilding and/or cleaning the application often is not enough, you have to create a new class and copy THE SAME!!! code back in :(

Everytime you open the database something gets screwed and until IBM fixes the issue I am 'reverting' back to a custom Webcontent/WEB-INF folder.






Classic errors resulting in Domino performance loss

Did another performance audit today and yes all the classic errors resulting in a non-responsive Domino environment where there:
- No compact jobs on system databases (average use of 30%)
- Verbose logging to log.nsf (5 Gb, luckily they had the cut-off date set to 7 days )
- Reporting on 'normal events' (which includes the verbose logging events) (6.5 Gb)
- Last but not least: Virus scanner on all Domino data directories
Yes, they are right: Domino does not scale ;)







Recompile code when opening in designer (xPages)

I found out the hard way that opening a database in Designer 8.5.3 can recompile all the code in the Java source folder, even if the 'Build Automatically' is unchecked.

So if you open a database that is in use, it might crash the database with:
07-12-2011 13:13:10 HTTP JVM: java.lang.SecurityException: Error verifying signature for resource WEB-INF/classes/xpages/Demo.class. For more detailed information, please consult error-log-0.xml located in /data/notesdata/domino/workspace/logs
After that the only way to get the database back online is to clean the database in designer.

If you plan to open databases in designer on production servers (not even modifying anything) or work with multiple people on the same database, setting the preference to not recompile xPages automatically will save you a lot of grief (or your job).









xAgents, xAgents everywhere....

I am currently working on several concurring development projects and I noticed that the focus is shifting from creating 'pure' xPage documents to xAgents (an xPage set to behave like an agent) to replace 'webagents' used for WebQueryOpen, WebQuerySave or Ajax events.
The 'old' functionality was written in either LotusScript agents, Java agents or Servlets.
The reason for converting the 'webagents' to 'xAgents' is that they offer more performance than LS agents, are more stable than Java agents and easier to deploy and maintain than servlets.
Especially the move from java agents to xAgents is very easy, even if you don't use xPages anywhere else in your application.

1. Create a new xPage, set rendered to "false" and copy your java code in it.
2. Change the current 'PrintWriter' to 'ResponseWriter' like this:

// get the response and set header info
var response = facesContext.getExternalContext().getResponse();;
response.setContentType("application/json");
response.setHeader("Cache-Control", "no-cache");
// get the output writer and print the data
var pageOut = facesContext.getResponseWriter();
pageOut.write("{'jsonvar'='jsonvalue'");
pageOut.endDocument();
pageOut.close();
facesContext.responseComplete();

3. If you have supporting classes put them in the 'code/Java' section
4. Change the calls to the agent to your new xAgent and you should be good to go :)

P.S. Does not work on pre 8.5 Domino versions ;)