I'm trying to implement OpenNTF Domino API as a replacement in our project but it fails with this message:
"OpenNTF Domino API: org.openntf.domino.utils.Factory is not initialized for this thread!"
Code snippet:
boolean init = Factory.isInitialized(); // false
Database db = Factory.getSession().getCurrentDatabase(); // This fails of course because no Session
I'm implementing the call in a JAVA DAO behind a EXTLib Servlet in XPages.
So it's not called by an XPage but as an REST API call.
The Domino API Demo DB is working so the server install seems to be OK.
Is there a setup, properties I'm missing to init it ?
Yes, there is specific setup require for non-XPages access, as done in OsgiWorlds on OpenNTF. Nathan has added a DAS extension specifically for REST access from Graph database. You basically need to initialise the session for the Factory before trying to access it, generally done in the Servlet when it initiates the HTTP connection. Please contact me on Twitter (Paulswithers) so the team can work with you. Also it's worth you having a look at the OsgiWorlds source code. Although that's for a Vaadin servlet and allows defining a development user to run as, in production mode it also uses the logged on user name and the configuration class and calls to it from the servlet are effectively what you need from the REST servlet.
Related
Is there a way to expose a Java rest web service in Liferay but not in a portlet, that can receive JSON request and store the data in Journal Article?
Therefore when a user logs into Liferay they will be see web content
Yes there is : JSONWebServiceActionsManagerUtil.registerJSONWebServiceAction
For instance :
Class<?> serviceImplClass;
Method serviceMethod;
Object serviceImpl;
String path = jsonWebServiceMappingResolver.resolvePath(serviceImplClass, serviceMethod);
String method = jsonWebServiceMappingResolver.resolveHttpMethod(serviceMethod);
JSONWebServiceActionsManagerUtil.registerJSONWebServiceAction("/yourwspath", serviceImpl, serviceImplClass, serviceMethod, path, method);
You should then be able to see the new web service in http://SERVER/api/jsonws
Well yes, Liferay has a full API (even JSON-based, SOAP optional, no classic REST though) that you can use. A simple Stackoverflow answer is not the right place to give a full introduction on how to work with Liferay's API, but you might want to look up Servicebuilder (which is used to create Liferay's API) and then look at JournalArticleService and related services: The Web Content Management API is called "Journal" in Liferay (for historical reasons)
We're moving most of our web presence to our SharePoint server in the cloud. Our current setup uses a MVC Web API for data retrieval from DB. We do not want to host the API under a separate domain and thus need to move the API under SharePoint domain as well. There is no relaxation in this requirement.
Is there a way to publish my API to SharePoint? Or is there a SharePoint specific API project template in Visual Studio? If not what are my options?
EDIT Initially I have asked that MVC API needs to be part of the SharePoint 2013. But now things are such that API can reside anywhere - inside or outside - of SharePoint, as long as it is accessible from the root domain - which so far it seems not allowed (Error message: Calls to WebProxy without an app context are not allowed."). Still trying to see if this is possible, and if yes, how?
It sounds like the proxy you want to create is already part of SharePoint JSOM. Have a look at these:
http://msdn.microsoft.com/en-us/library/office/fp179895(v=office.15).aspx
http://msdn.microsoft.com/en-us/library/office/jj245162(v=office.15).aspx
This will allow you to overcome cross origin issues. The SP.WebProxy and SP.WebRequestInfo allow you to use javascript to make a call outside of the domain where the javascript executes.
What really happens behind the scenes is that SharePoint's javascript API sends the request to your sharepoint.com tenancy server, which will then invoke the service from the SharePoint server, and return the response back to your javascript. You can implement it like so in a sharepoint-hosted app:
// this javascript executes from my-company.sharepoint.com
var responseDocument = undefined;
$('#cross').click(function () {
var ctx = SP.ClientContext.get_current();
var request = new SP.WebRequestInfo();
request.set_url('https://www.somewebapi.com/my/custom/route');
request.set_method("GET");
responseDocument = SP.WebProxy.invoke(ctx, request); // executes on sp server
ctx.executeQueryAsync(onSuccess, onError);
});
function onSuccess() {
var response = responseDocument.get_body();
alert('success ' + response);
}
function onError(err) {
alert(JSON.stringify(err));
}
...and since the remote api hosted at the other domain is called from the server, you don't have to worry about any of the cross-domain issues.
Update
To answer your update, please check the results from this link.
Have you added the remote endpoint to your AppManifest.xml?
SharePoint doesn't give you a chance to define you own routes. Thats why you can not use old fashioned SharePoint solution to publish asp.net web api. You may consider using apps for SharePoint. It's like separate App with some connections to SharePoint.
Ultimately switched to JSONP solution. Installed the WebApiContrib.Formatting.JsonP in my MVC Web API project in Visual Studio, and modified SharePoint JavaScript, that calls the API, to include ?callback=? (callback is equal to question mark). Everything stays the same. No SharePoint's proxy caller needed! No SharePoint app needed!
So far I have:
installed and started sbt.sample-1.0.0.20140125-1133.ear on my WebSphere Application
Server,
added an URL resource for the SBT Properties file.
The Social Business Toolkit Samples app runs fine and I'm able to connect to my IBM Connections and retrieve some ActivityStream entries.
When I first loaded the application, I noticed this error:
Exception stack trace: com.ibm.websphere.naming.CannotInstantiateObjectException: A NameNotFoundException occurred on an indirect lookup on the name java:comp/env/url/ibmsbt-managedbeansxml. The name java:comp/env/url/ibmsbt-managedbeansxml maps to a JNDI name in deployment descriptor bindings for the application performing the JNDI lookup. Make sure that the JNDI name mapping in the deployment descriptor binding is correct. If the JNDI name mapping is correct, make sure the target resource can be resolved with the specified name relative to the default initial context.
In the Samples application's ibm-web-bnd.xml file I found this line:
<resource-ref name="url/ibmsbt-managedbeansxml" binding-name="url/ibmsbt-managedbeansxml" />
And in the web.xml:
<resource-ref>
<description>Reference to a URL resource which points to the managed bean configuration for the Social Business Toolkit.</description>
<res-ref-name>url/ibmsbt-managedbeansxml</res-ref-name>
<res-type>java.net.URL</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
I'm wondering, why should there be an URL resource to the JSF Application Configuration Resource File (managed-beans.xml) in the first place? According to the Java EE documentation the JavaServer Faces implementation will look for it in the /WEB-INF/ folder.
Does the SBT uses JavaServer Faces technology somewhere? Or can I choose not to use the managed-beans.xml file in my own applications that use the SBT?
I wouldn't recommend you consider them related. managed-beans.xml had a prior name, and it's just a set of configuration objects. The project itself does not use Java Server Faces.
I just read the documentation again, more carefully than the first time, and I think I now have a better understanding of what I asked in my second question. From the documentation:
In a web application SBTFilter (HTTP servlet filter) is responsible
for initializing the application using servlet context. Application
does the initialization like loading the managed beans and properties
factories.
The sample app is a web application. I think in my own application I can choose to use com.ibm.commons.runtime.impl.app.ApplicationStandalone instead of com.ibm.commons.runtime.impl.servlet.ApplicationServlet and then configure an endpoint programmatically. Or alternatively do not use an Application at all, like so:
RuntimeFactory runtimeFactory = new RuntimeFactoryStandalone();
Application application = runtimeFactory.initApplication(null);
Context.init(application, null, null);
Is it possible to somehow override the login method of the Secure.java class of the Secure-Module in Play! Framework, so that another version of the login form is displayed?
In my case, i want to display a mobile version of the login-form if a mobile browser is detected.
I know i should not change the Secure.java class itself, but i don't really see any other solution to this problem.
As discussed in other posts you have the request in your Play! controller. So in this request you could ask which agent is trying to view your website:
String agentInfo = request.headers.get("user-agent");
The you can determine which template will be rendered for this agent:
if (agentType.isWhatEverHeIs) {
renderTemplate("Application\mobileTemplateForBadPractise.html");
} else {
render();
}
But what I would encourage you to do is responsive webdevelopment. Create your templates as smart as possible, let the template and css and javascript do this and keep your business logic in your controller.
You could use the Twitter Bootstrap to achieve this, but there are many more! Like Skeleton.
You even got the request object inside your templates so that you can optionally render things in your template (or not) based on the agent.
Even simpler, simply create/override the secure/login.html template and use responsive design : media queries. No need to change the controller or check agent or whatever.
I want to set different themes to my Vaadin application, depending on the user agent.
In particular I want to distinguish at least between mobile devices (iPhone, Android,...) and desktop web browser.
Vaadin's API reveals two interesting classes:
BrowserInfo
WebBrowser
BrowserInfo seems to do the job perfectly for my needs, but fails on instancing via its get-method:
SEVERE: javax.servlet.ServletException: ...
Caused by: java.lang.UnsatisfiedLinkError: com.vaadin.terminal.gwt.client.BrowserInfo.getBrowserString()Ljava/lang/String;
Couldn't find a way to access WebBrowser from within my application either.
Did I choose the right approach for browser distinction?
Why does accessing BrowserInfo fail?
As #quickanalysis pointed out, you've to be aware of the separation of client-/server-side components.
For getting the user agent string on server-side, the following code snippet does the job:
ApplicationContext context = this.getContext();
if (context instanceof WebApplicationContext) {
String userAgent = ((WebApplicationContext)this.getContext()).
getBrowser().getBrowserApplication();
}
From what class you are trying to call this method? The BrowserInfo is available at client-side as WebBrowser ar the server-side. Take a look at the package naming.