This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal



Feb 23, 2011, 5:25 AM
38 Posts
topic has been resolvedResolved

Using Java classes in WEB-INF folder in your Java Agents

  • Category: Server Side JavaScript
  • Platform: Windows
  • Release: 8.5.1
  • Role: Developer
  • Tags: XPages,Java,SSJS
  • Replies: 7
Ok, heres my problem.

As we all know that we can use Java classes defined in the WebContent/WEB-INF folder (which we later add in the build path of the project) in our XPages SSJS code. One of the examples I found was here - http://www.jmackey.net/groupwareinc/johnblog/johnblog.nsf/d6plinks/GROC-7GAFVQ

BUT how can I use the same Java class in my Java Agent? When I import the package it gives me error that package was not found and suggests me to "Fix project setup...". After that error goes. But even after doing that while running the agent it throws "ClassNotFoundException". When I open the agent AGAIN the error reappears.
 
I have a set of Java classes and JAR files that I would be required to use in both XPages and agents. As of now I have to put these classes/JARs in WEB-INF directory (for XPages) and Java script library (for agents) which leads to duplicate code and also increases size of NSF file.

Is there a workaround for this problem?  
Feb 23, 2011, 8:06 AM
261 Posts
Re: Using Java classes in WEB-INF folder in your Java Agents
Good question. I faces the same problem while making some changes to the Bildr application.
 
The only way I can think of is to store the JAR's on the server (<domino>/jvm/lib/ext folder). This will make the classes available to agents, although I haven't tested if they also will be available to an XPage.


Feb 23, 2011, 9:32 AM
16 Posts
Re: Using Java classes in WEB-INF folder in your Java Agents
 Hi
 
I have quite a lot of experience with exactly this issue... 
 
--> You cannot use a jar-file added to your project to be used with XPages in a Java agent. The agent runs in its own JVM (i.e. different class loader). 
 
I have discussed this with a few IBM'ers, including Steve Nikopoulos, Stephan Wissel, and Maureen Leeland. I have tried to implement my own class loader to be able to load the jar-file in the agent (or a webservice - which has the same limitations) - but without success.
 
I would also like to do this for other reasons than sharing the jar-file between XPages and agents - e.g. for easy deployment through the ntf-file.
 
So what are your options?
 
1. Add the jar-file to your agent
However, there is a memory leak in the function that detaches (automatically) the jar-file before using it in the agent. It will make your jvm crash. This is true for agents and webservices. It does not matter whether you attach the jar-file to the agent/webservice itself or a Java Library that you then include. I have verified this as a problem in versions 7.02 to 8.5.2 (on SuSE Linux and Windows).
 
2. Add the jar-file to the jvm/lib/ext directory 
This works fine - it just needs the jvm to be restarted one time after the jar-file is added. This can be a pain for Java code called by Notes clients. And it does take a few more steps when deploying on servers... But it runs stable and fast :-)
 
3. Rethink your agent to an "XAgent" 
An "XAgent" is an XPage which does not render any output. It can access the resources as you already do. You could then call this "XAgent" through a url. It depends on your application's logic whether this is an option for your.
 
/John 
Feb 24, 2011, 8:00 AM
38 Posts
Re: Using Java classes in WEB-INF folder in your Java Agents
Thanks John for your reply.
 
With your reply I can safely say that as of now what I am looking for is not possible. Atleast I wont break my head over this anymore. :)
 
Option 1 & 2 are not feasible for me. Option 3 sounds interesting and might just be able to take care some part of my problems. But I want some of my agents to run on schedule and XAgents wont be able to do that (Pls correct me if I am wrong on this one, because if I am then all my problems are solved). 
Feb 24, 2011, 10:45 AM
16 Posts
Re: Using Java classes in WEB-INF folder in your Java Agents
Oh, yes, I forgot to add that twist.
 
You can just create a simple scheduled agent that calls your "XAgent" through a url. If you need to pass data to your XAgent you can add them as url arguments :-)
 
Looking a little further ahead I think we will start to use OSGi for such tasks. But most of us would still need to learn a lot more about OSGi before doing that. Specifically, I am thinking of deployment and daily operations - and of course some best practices for development :-)
 
/John 
Feb 24, 2011, 10:53 AM
261 Posts
Re: Using Java classes in WEB-INF folder in your Java Agents
See here: http://www.bleedyellow.com/blogs/m.leusink/entry/using_scheduled_xpages?lang=nl how to mimic "scheduled XPages" by calling them using a scheduled Java agent.
Feb 24, 2011, 8:01 AM
11 Posts
Re: Using Java classes in WEB-INF folder in your Java Agents
" I have verified this as a problem in versions 7.02 to 8.5.2 (on SuSE Linux and Windows)"
Do you have a SPR7PMR or any other reference to this problem? Is it going to be fixed in 8.5.3?
Feb 24, 2011, 10:39 AM
16 Posts
Re: Using Java classes in WEB-INF folder in your Java Agents
No, I don't.
 
It is fairly easy to reproduce. Just add a JDBC-driver to an agent, write a little code to call a database, schedule the agent to run every x minutes and wait.... It will crash within a fairly short number of calls (depending on the environment and code, expect 5-10 runs). 
 
I have spoken to some of the developers on this at LotusPhere the last couple of years. It seems they need to re-write much of the way the JVM was implemented for agents and webservices to fix this. A much better approach going forward would be to look at OSGi to do some of the same things - and obviously find a solution for deployment. But it seems someone is working on/considering this.

/John 

This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal