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.
Related
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.
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 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.
I have an existing project using RIAServices with Entity Framework. The project builds correctly and generates the AmsiWeb.g.cs file with all the context classes for my services.
I am converting my designer based entities and ObjectContext with Code First entities and DbContext. I installed the RIAServices.EntityFramework NuGet package to the web application that contains my services. However, now when I build the AmsiWeb.g.cs file only contains the WebContext class. It doesn't contain any generated services.
I have only at this point converted a single EDMX model to Code First and DbContext and made the requisite changes to the services that use that model to inherit from DbDomainService.
I am using EF 5.0... not sure if that matters cause I'm not sure how adding a DLL to the AmsiWeb application project would break code generation.
What would cause this to no longer work and how can I fix it?
Maybe it's a problem within the msbuild task that generates the proxy code (I mean the *.g.cs file). Probably it's looking for the wrong version of a entity framework. Have a look at this blog post http://mcasamento.blogspot.it/2012/10/entity-framework-5-code-first-and-wcf.html in the final part I wrote an assembly redirect statement that did the trick
It turns out that their needs to be a redirect for Entity Framework 5.0 (4.4.0.0 since I was using .Net 4.0) in the web.config. But, since my RIA Services were in a web application project that was not my root project the code wasn't generating.
Once I added the redirect to the web.config of the web application with the RIA services in it, the context code was correctly generated.
I have a portlet project that needs to do some Group querying. I've not created the project but it was made with the Eclipse Liferay SDK plugin.
I've added a DynamicQueryFactoryUtil.forClass(Group.class) but it fails in runtime. It complains about not finding GroupImpl.class, which is implementation for interface Group. My project dependencies doesn't include portlet-impl (it contains GroupImpl.class).
I'm not sure if I should:
include that jar into dependencies for compiling
include that jar into portlet jar
Or I'm doing something wrong and querying groups would be available right out of the box.
PS: I'm pretty newbie in Liferay things...
PS2: It's Liferay 6.1
To enable Liferay to retrieve the right class, you need to provide a correct classloader to the initialization of your DynamicQuery, in this case the portal's classloader because that one has access to the model implementations:
DynamicQueryFactoryUtil.forClass(Group.class, PortalClassLoaderUtil.getClassLoader())