So…last August I am in Italy “living the dream” (a.k.a working while on vacation) and I am trying to replicate some application changes to our production server over a pretty slow wireless connection.
Didn’t matter whether I was on my TIM SIM Card with the MiFi or using the WiFi provided by the villa (I love saying that!)…replicating the production application was so bad that some of the application was corrupted and I needed to act quickly to fix it.
Not a good thing at all. Nerve wracking.
Part of the reason for the issue was that we stored our application’s third-party JAR files in the NSF. This made the application size quite large and during replication over a poor network it caused some problems.
In my previous existence as a corporate developer I always recommended keeping everything within the NSF as much as possible. Application portability was valued above all in that environment for me.
Nowadays I work on a publicly available hosted XPage application. Given the different process requirements I live with now, application portability is much less of a priority while ensuring accurate production updates is truly mission-critical.
Solution: I removed all of the third party JAR files from the NSF and relocated them to the servers’ hard drives within the JVM ext folder.
Replication over a low quality connection was instantly improved.
Moving those files to the JVM ext folder means that no Java permissions needed to be changed and the size of the NSF dropped by 340MB. Since this is a design template, that savings is multiplied by the number of customer NSF files we create.
Saving space was not the primary goal but using less is a nice bonus.
The downside? Domino server upgrades will require a little more thought and, of course, new server deployments take a bit more effort. Given that our failover strategy has been successfully tested, our DR plan is in place and that we do not deploy new servers at the drop of a hat…this was an easy decision to make.
This solution clearly will not work in all Domino environments but food for thought.
This works fine for us since several years. But since 8.5.3 IBM seemed to had changed the Service Pack Installer. If you install an SP your jar files are wiped and you have to manually reinstall them. Another caveat is that when you want to add or change your jars you have to restart your domino server
Definitely. That is why this solution is not for everyone.
Russ, if it's an XPages application, why not wrap them in a single OSGi plugin that re-exports the JARs, and put them in the Dominodatadominoworkspaceapplicationseclipseplugins folder? This why they are loaded by the Xpages OSGi context, but part of the data tree rather than the program tree.
Even better, wrap them in one or more OSGi plugins, bundle that together as a feature, and then load it into an Eclipse Update Site NSF on the server. Then set that NSF to be an OSGi Dynamic Bundle source in the Server Configuration. That way you can replicate the NSF to multiple servers (such as a DR environment) automatically and be assured you have current versions.
Setting all this up once would take only a short while and would be guaranteed to save you considerable time and improve reliability in the future.
Short answer: Deadlines and priorities.
Longer answer: We'll get to it because I figured there was some sort of dynamic provisioning mechanism available. Now I know what to do so thanks!
You also could….
take the OpenNTF 8.5 UpdateSite template apart. There's code inside that copies attached files into the Domino File system. With little energy you can remap the path to lib/ext (then the Jars work for your agent too). But Nathan's suggestion is clearly the recommended way
An update site setup as a dynamic OSGi Bundle supplier in the notes.ini takes about 5 minutes to setup from an admin point of view.
Creating the plugin/feature and deploying to the updatesite takes about 10 minutes from a developer point of view and can even be done from DDE in the plugin perspective.
This is how we roll out iTextPDF, Apache Commons and a few other jar plugins and the nice thing is that because it is separate to the NSF using the plugin if you have another app that needs those capabilities then they are already there on the server so no duplication of jars anywhere.
( also as Nathan mentioned you can then replicate the updatesite nsf to all servers so all servers have the same setup )
Yup.
I'm all in as soon as we have the time! LIkely after 9 upgrade though.
I can't help but imagine it took you more than 15 minutes to write this blog post. 🙂
You're right and it was a guilty pleasure at that. Didn't really have the time to spare.
Russell,
I attended one of your XPage conferences, and am still referencing the conference material.
I came across this post because of our scenario that we're trying to package our own jars so that we can reference them across many databases without having to do any work of importing them individually. I put them in the jvm/lib/ext folder as you stated and had the server restarted. I would assume it found these jars at run time, because the error message went away that it couldn't find the class files. However, I now get a message "Script interpreter error, line=1, col=50: Error while calling java constructor 'com.xxxxxx.xxxxxx.xxxxxx()' (java.lang.reflect.InvocationTargetException).
com.ibm.xsp.model.domino.DominoUtils" when the code runs. This works fine in an agent if I run that code, so I would assume this has something specific with Xpages. Do you have any advice for my scenario to look into?
Hi Ryan…have you determined exactly where the constructor is being invoked? The stacktrace should show you exactly where the problem occurs.
I traced it down to trying to run the DominoUtil class within a jar. If I pass my session object from a java file in a Notes database to the class in the jar file, it works and does error, but once a reference to DominoUtils occurs in code from a jar file in the jvm/lib/ext folder, it gives out the InvocationTargetException. Do you have any experience with this file as to have any clue why this might occur?
Did you mean "…it works and does NOT error…"?
I don't have experience with it but it is possible that the security permissions are also giving you a problem. Is code running in the Notes client or just through browsers?
A basis of what I am trying to do is have an intermediate class that I could call for logging. This class then calls OpenLog, so that if our logging process changes, we can just change it out of the single jar file and not in every database. This intermediate file is a jar file itself residing in jvm/lib/ext. If I pass into the intermediate far file the session object, it works and does not error, writing out its entry to Openlog. If I try to run the DominoUtil to get the session in that intermediate jar file, it errors. I tried to run it off an Xpage in the client and on the browser, which gets the same results.
Uh yeah…I think what you got there is a special problem! 🙂
My Third-Party Jars do not use any Domino artifacts. My guess is that, while it might not be impossible, it might be very tough to get hold of the same context you are running in an XPage from a Jar file located on the hard drive. However, there might be a very easy way to do it that I just don't know.
I'd recommend posting that on StackOverflow.com to see what comes back or just leave that one in the NSF if you want keep moving forward.
Just an update. I think it has something to do with security, and I think using some sort of authentification would have been needed to write out to a Notes database. Instead of doing that, I just decided to pass into the Jars the session object created from the Notes Database being called from. This appears to be my best option at the moment until I run across something else.
Thought I'd give an update in case someone else was trying the same thing I was.
Thanks Ryan. I think it will be helpful to someone else.
You could temporarily disable the Java policy security on your test server to test that out but I don't see any issue doing it the way you got wokring.