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.
Related
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)).
I wanted to use the Apache POI classes for Streaming Excel spreadsheets. If I import the log4j-1.2.17.jar file into my Jars in the nsf then no XPages will load.
If I don't I get an error:
java.lang.NoSuchMethodError:
javax/xml/stream/XMLEventFactory.newFactory()Ljavax/xml/stream/XMLEventFactory;
at
org.apache.poi.openxml4j.opc.internal.marshallers.PackagePropertiesMarshaller.<clinit>(PackagePropertiesMarshaller.java:45)
at
java.lang.J9VMInternals.initializeImpl(Native Method)
at
java.lang.J9VMInternals.initialize(J9VMInternals.java:201)
at
Since many third party Java apis seem to use the log4j is there a solution? I think this is the same issue that came up with the web services API in XPages?
Your best course of action is to deploy OpenNTF essentials. It contains the POI classes and quite some ready made wrappers to make your life easier.
Deploy into sever via update site nsf approach and deploy to your designer too
Maybe your error can be from the same reason than in that questions. It's a problem of standard jars which come along with the domino installation.
Using External jar causing Error
Axis 1.4 log4j-1.2.8.jar incompatible with XPages?
Howard, put the jar file on the server as well as your local notes client and open up Java security permissions, I think that should do it. Also check that the version you are importing is compatible with Java version on Domino.
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.
Many sources noted that in Domino 8.5.4/9 should be clean way of starting OSGi bundles on HTTP startup as noted for example here http://lekkimworld.com/2011/07/08/dots_and_automatic_startup_of_bundles.html
Currently I'm still not able to find any documentation about it. Is there some extension point or other configuration that can be used for that?
In Domino 8.5.3 we did ugly hack when bundles pretend to be Dojo libraries and so they started automatically. On one of our Domino 9 test machines this probably causes troubles (every other restart server complains that No Dojo library could be found), so I wanted to cleanup our code.
Bundle is our workflow engine and since it can do some automatic processing we need to start it even when no request comes to server.
The webdav plug-in on OpenNTF has an autostart option. In this case it was linked to the Servlet extension point. That might help. Are you extending Activiti?
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.