I prefer to keep my jars in Archive folder
But some bloggers says better to keep in \jvm\lib\ext\ path.
I'm testing my project on my client later it will work as scheduler.So, I tried to remove my jar from "Archive" folder and placed in following path on my local ,
Restarted my client and recompiled my code, It stop detecting Oracle driver class and suggested following,
Next, I thought to set in Java build path. So, I added my jar in Libraries->Add external jars of project properties. Now, I was able to compile my code but when ran it throws an error "Class is missing".
So, Now I'm again back to my working solution i.e., adding jars in archive folder of an agent.It works perfectly on my client but when I tried making it as a scheduler . It didn't work and server console says,
Should I assume it's because agent is not able to detect "odbc.jar" ?
But some bloggers say "Java.lang.UnsupportedClassVersionError: Bad version number" because when you compile a .java file with one version of JDK and running the .class file with a different version of JVM.
I'm compiling my code on 8.5.1 and server is 8.0.1 ( Linux OS ).
What I would like to know ,
* Where should I keep my jars for client or server based Domino Java apps ?
* If domino client and server are not using same JDK version, How do I make sure my compile code works perfectly on any Domino server?
Posts
September 8, 2010 at 12:27 AM
Hi Rishi,
Guess you missed one little stumbling block.
you have to put the jar in the jvm/lib/ext of the server, too!
When its scheduled it runs on the vm of the server. But the server-vm does not have the ojdbc6.jar in its jvm/lib/ext. Only your client.
I had strange problems with attaching jars directly to the agents back in Domino7/6. Never figured out why. Shallow libraries like java-commons.lang created no problems, but more complex like jdbc-drivers or xml-libraries did.
If it worked, I would like the attach to agent style better. Its easier to deploy for example.
regards
Axel
September 8, 2010 at 12:33 AM
@Axel,
Thanks! My first assumptions is may be odbc jar causing the problem.But,such case it should say "Class not found".I'm going to write some code to deploy my odbc jar on server's jvm/lib/ext folder because I don't have access to server file system :( . Will post my findings.
Rishi
September 8, 2010 at 12:49 AM
Keeping jars within an agent project is OK for development, but once you're looking to deploy, you definitely want those jars in the standard place on the server (i.e. lib/ext). And as Axel says, obviously you need this stuff on the server when it 's supposed to be running there!
(And when it comes to projects in Eclipse / other IDEs, the "lib" folder is the standard for external dependencies).
File system storage is a requirement for some third party packages anyway -- e.g. some of the Apache stuff -- because reflection doesn't work too well when the jar in question is attached to a note within an NSF (as is the case when you attach all dependencies directly to your agent project).
September 8, 2010 at 8:39 AM
The best option *grins* is to upgrade to 8.5.2 and put your libraries into an OSGi Bundle you deploy to client and server --- the bundle will "survive" upgrades and re-installs while lib/ext often falls prey to cleaning admins.
September 8, 2010 at 9:08 AM
The *best* option *grins* is to upgrade to 8.5.2 and package your libraries as OSGi bundle. This survives upgrades and reinstalles where lib/ext often gets wipes by trigger happy admins.
September 9, 2010 at 4:34 AM
A few points (repeating what others said).
1. Java.lang.UnsupportedClassVersionError
This error means that you have compiled code for a JVM which is set to run to lower version of that code. For example you have compiled to Java5 but you have the JVM5 set to only run code at 1.4.2 level.
By default the server is set to run legacy compiled code in java. See the following tech note for changing it.
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/07152009034956PMMSTR75.htm
2. Where the code is executing you need the jars in the jvm/lib/ext of that (Domino/Notes).
You can put the jars into the agent and it will work. However when you do this there is initialization and transfer overhead.
For example. The user clicks on the agent, the agent has to then pull the attached jars from the server to the client and initialize them to run. This happens every time the agent executes regardless if it is the same user executing it.
3. The reason they should go into the lib/ext path is that is how notes/domino designed for the developer. You can put jars into jvm/lib/security, but there is no guarantee that the jar will be allowed to run (now or in the future). So you risk causing your agent/app to fail on next release.
NotesSensei has the coolest option for maintaining your jars.