Xpages - Java - How to start writing code - xpages

I am new to Java but not Lotus Notes. Here are some of my questions:
Main method in Java class - Can I run a simple HelloWorld.java in DDE as I would in Ecplise?
Do I use Java design element or create Java classes in project explorer?
Would it be better to uninstall other JVMs before starting on working Java in DDE?
Thanks
Arun

I strongly recommend you to invest some time to learn how Xpages and Java are used in DDE/Notes/Domino as:
the JVM of IBM is completely separated from other JVM you may have installed
Java classes don't have a main method - except you refer to those that come from an Agent
if you create a Java class for an XPages app you always use the Java class element
A good point to start is David Leedy's NotesIn9 series. You can check the whole compendium of video tutorials here: http://www.mindmeister.com/de/280533435/notesin9

If you just want to play with Java (not the XPages part) create a Java project in Domino Designer (change to the Java perspective) and then use the main to write code. When you run it as a Java program it will output to the console. You can still access Domino objects. For example, the code below shows how to do that... I did this to test out some data models and concepts and then copied the code to an actual NSF for use as a bean after I proved out my concept. It is so much easier to experiment and test running your code as a Java program and viewing the output in the browser.
Howard
public static void main(String[] args) {
try {
NotesThread.sinitThread(); // start thread
Session s = NotesFactory.createSession((String) null, (String) null, "cessna");
//do whatever
} catch (Exception e) {
e.printStackTrace();
} finally {
NotesThread.stermThread(); // must terminate every thread
}
}

As you tagged your question with XPages my answer will cover only Java development in DDE for XPages.
You can't use the main method as usually. Create a HelloWorld.java with a static methode hello() and call this method in an XPage with {javascript:com.package.HelloWorld.hello()}
You can use Java design elements. Those are easy to access in DDE and included in build path already. For larger projects you can create your own directory structure in Package explorer and include those in build path. As long as they included in build path you can use them in XPages.
The JVM is included in and get used from Domino server. You don't need to uninstall JVM on your computer.

I'm not sure what you mean by not wanting to run the whole program. The "program" is the same XPages runtime you'll have been running when writing SSJS. The JVM is created as part of that runtime, for a specific NSF. That runtime includes all the relevant OSGi plugins on which a lot of your Java code will depend (thinks like FacesContext classes, ExtLibUtil etc). Testing of "the program" in XPages is usually no different to testing of "the program" in traditional Notes development.
You can test from Eclipse, but you need to be able to connect to a Domino server in order to run the code in a similar way to how you need to be able to connect to a Domino server to run the debugger. So if running the debugger is an issue, running from Eclipse is a non-starter.
From Eclipse, unless you're running code from a OSGi plugin, you'll still need to copy and paste your code outside the NSF, unless you use test cases within the ODP.
If you want to run junit tests, an OpenNTF project is available for that. But from my experience of Java and junit testing, I don't think I would have been capable of using that to test my code when I was just starting out with Java. So it's not something I'd recommend.
Static methods (utility methods that are not in a managed bean) can be tested from standalone XPages. I've used that method before. Otherwise, beans can be added to a standalone XPage pointing to whatever data you wish or initialised with whatever values you wish, so you have the control to test part of it, if the application architecture allows it.

Check for the article "the double headed beast" from Bob Balaban. It explains the approach you want to take. While it was written for agents it applies to Java too.
What you need to do: write your businesses logic (the part you want to unit test) without dependencies to xpages specifics. Hand over the key objects in method calls: session database. You can initialize them in a main routine.
I wrote an article about that, Check it out.

Related

Domino 9 Update site osgi class not found

I'm trying to use an Updatesite.nsf to deploy jar to a test server. I can see it in this case the jdbc driver plugin at the server console using the http osgi ss command. But when I use it I get a java.lang.ClassNotFoundException com.mysql.jdbc.driver. What I'm missing or doing wrong. Thank you
The immediate answer is that the code that's calling Class.forName will need to have the MySQL driver in its classloader one way or another, which an XPage or in-NSF Java won't have by default.
To expand on it a bit:
If you're trying to call it from an XPage or Java code in an NSF, it would have to be part of an XPages Library from another plugin, which in turn depends on and re-exports the driver plugin.
If you're trying to call it from another plugin, that other plugin should have a Require-Bundle or Import-Package entry to bring it in.
The class will be available to NSFs by default if you plunk it in jvm/lib/ext, though that admittedly gives up the niceties of OSGi-based deployment.
The reason it works for the XPages JDBC support is that the wrapped plugins created by the wizard in Designer include a special extension point to provide the driver class to the ExtLib code that wants it, but they don't make it automatically available to XPages apps themselves.

Access server xsp.properties value in osgi servlet

I am building an application that will run solely on the Domino Server. It will not be bound specifically to any application and there is no designer library associated with it. I still need to access configuration values in order to get it to run correctly.
My first thought is to use the server xsp.properties file. Because this does not exist at first I will copy the sample and put my own properties into it. How can I access those values when I am only using the OSGi servlet?
I do have an ODA (openNTF Domino API) dependency, albeit an older version from September 2014.
With OpenNTF Domino API, you can use ODAPlatform.getXspPropertyAsString(). This goes through Platform.getProperty() (I believe this one uses xsp.properties of the application / server), System.getProperty(), then OS.OSGetEnvironmentString() (i.e. notes.ini). This is what the OpenLog functionality uses, as does a lot of code for getting org.openntf.domino xsp.property settings.
Alternative, you can have a look at the XPages OpenLog Logger code, which is where I originally wrote the code. The com.paulwithers.openLog.OpenLogUtil class has a getXspProperty(String, String) method, which uses com.ibm.xsp.application.ApplicationEx.getInstance().getApplicationProperty(String propertyName, String defaultValue)).

Webservice client in xPages doesn't work

I need to use webservice client in xPages.
I found a simple ws to test, called CurrencyConverter. WSDL is here: http://www.webservicex.net/CurrencyConvertor.asmx?WSDL
First of all, I created a java classes using wsimport tool in JDK6.
I made sure that my project uses Java 1.6
Then I created a new java project in my Eclipse Juno and imported those files into src folder
Then I created a simple class to test it:
CurrencyConvertor service = new CurrencyConvertor();
CurrencyConvertorSoap msg = service.getCurrencyConvertorSoap();
double rate = msg.conversionRate(Currency.USD, Currency.CZK);
System.out.println("USD to CZK rate = " + rate);
It worked perfectly.
Then I wanted to use the same approach in xPages.
First of all, I created a new Domino Application
Then I made sure that it uses Java 1.6
Then in Package Explorer I created a new folder called src and added it to Build Path
Then I imported those java files, made by wsimport tool into this folder
Then I created a new class called TestBean and in it I created a new method getCurrency() with the same code as above
Then I registered this TestBean in faces-config.xml as 'service' using a view scope
Then I created a new xPage called home
Then I put a new ComputedField into this xpage:
value="#{service.currency}"
And you know what? It doesn't work. It throws a WebServiceException with a message: class net.webservicex.ConversionRate do not have a property of the name {http://www.webserviceX.NET/}FromCurrency
So, am I doing anything wrong, or is it just typical IBM Notes/Domino issue?
EDIT: I created a typical project on Domino 9 server. Can someone check and try it, please? Maybe I'm just doing something wrong.
Here is the test application.
I suggest you try it without a managed bean first.
The Java version that your Eclipse uses probably differs from Domino java version. There might be a bug in Domino Java version (version has been updated in 9.0.1) or you may need different wsimport options (like -p) for that version.
Another approach which has worked for me is to use Apache CXF wsdl2java. I've used it starting from from Domino 8.5.3. I made a JAR from the generated code and called it from Java code in Code/Java-elements.
Here are some of my experiences about it.
Version 9.0.1 has added the Apache Axis jars back into the class path so WS clients can be created with SSJS.
To do it via java you have to add the apache axis jars to the system/application class path and then call the code from the library.

Is it possible to use Java classes from the WEB-INF directory in Java agents

Currently I am busy with a brand new XPages project. I use Java and Managed Beans to access the data.
Till now I don't have to use Lotusscript ;-)
One of the last things is to create a scheduled agent to perform some backend stuff. There is already some logic in Java classes, who are in a directory in the WEB-INF directory.
I son't want rewrite these Java logic to Lotusscript, but reuse.
Is is possible to access these Java classes, from a (scheduled) Java agent??
Assuming that the WEB-INF directory that you are talking about is inside the NSF the answer is going to be NO.
Java Agents in Lotus Domino are self contained and can't see that part of the NSF. You could package those particular classes into a jar file and then attach the jar to the java agent or just copy the classes directly to the java agent. Either way you will have to maintain two sets of code.
Maybe another option for you. I'll post on Monday sample code how to use Eclipse jobs on Domino triggered from XPages. These jobs can run on behalf of the current user. The Eclipse jobs framework also allows scheduling them.
Both XPages and your Eclipse jobs run in the http process and you can access the jobs from your XPages. In other words jobs can use the same code in the WEB-INF directory.
Teaser: http://www.youtube.com/watch?v=uYgCfp1Bw8Q
Update: Posted the sample here http://www.openntf.org/Internal/home.nsf/blogEntry.xsp?permaLink=NHEF-8SJB2R
Yes, if the WEB-INF/classes is on the classpath when the java agent executes. The other way to do it would be to put the classes in there own jar, and distribute the jar with the webapp and the java agent code.

Grails and dynamic modifications at runtime

A deployable Grails war-File contains groovy files as well as a groovy.jar.
Is there a groovy agent running when the application is deployed?
Is it possible to make dynamic modifications for the application via Groovy at runtime?
if yes, how can this be prevented?
Edit:
After the grails application war is deployed on let's say on Tomcat: Is there some kind of Groovy Shell/Process/Agent running where someone who has access to the system can connect to? And if this is possible can he make dynamic modifications to the application without touching any files on the file system?
You can use the Console plugin which provides a web-based version of the Groovy Console/Grails Console. Like the Swing-based app it has a ctx variable in scope to give you access to all of the app's Spring beans, and it will run arbitrary Groovy code in the context of your running web app, can access GORM, etc.
Obviously this is dangerous, so be sure to guard it with a security plugin
I wrote a blog post a while back about using a similar web-based console (which I've since merged into the plugin) to fix a bug in a running server: http://burtbeckwith.com/blog/?p=155
By default Grails apps do not ship with a console that will let you execute arbitrary Groovy code at runtime.

Resources