I have a GWT project(GWT version 2.4). I want to start up Spray-servlet in server side GWT, but GWT does not support servlet-3.0, therefore I wanted to use org.apache.sling.extensions.gwt.servlet-3.0.0.jar for using servlet-3.0.0.
How I can use org.apache.sling.extensions.gwt.servlet-3.0.0.jar in GWT?
EDIT
If sling does not help me, then how can I run spray-servlet-1.2-RC1 in server side GWT?
org.apache.sling.extensions.gwt.servlet-3.0.0.jar is not a Servlet 3.0 package for GWT, but an extension to Apache Sling meant to allow server-side GWT code to run.
It's not what you're looking for.
Related
I have one Eclipse RCP3 project.Now I need to call a rest api|(java) and Post some information using that API. Need Help.
Being a Java application, an Eclipse RCP app can use most existing Java REST client libraries. My opinion is that the easiest way is to use the ECF JAX-RS Jersey Client. I recently wrote an article about how to incorporate this into an Eclipse RCP application:
https://www.modumind.com/2020/05/19/eclipse-rcp-and-rest-an-introduction/
In short, the JAX-RS Jersey Client is an OSGi Remote Services client created as part of the Eclipse Communications Framework (ECF) project. It embeds a Jersey/Jackson JAX-RS implementation that allows you to create REST clients as annotated interfaces that are made available as OSGi services locally. Jackson is used to data bind the REST responses to Java POJOs which require little or no annotation.
This solution allows you to skip most of the scaffolding code that usually has to be written to make REST calls in a Java application. But of course, you can also use Jersey and Jackson directly, those plugins are made available via Eclipse Orbit project.
http://www.eclipse.org/orbit
The GitHub repository for the ECF JAX-RS Jersey Client can be found here:
https://github.com/ECF/JaxRSProviders
I am working on CQ5.6.1 version and trying to recompile jsp files. When I try to hit http://localhost:4502/system/console/slingjsp . I am getting 404 error as below. Any Idea where the problem is?
The requested page was not found. If you are not forwarded in 3 seconds to the Web Console, please click here
Thanks,
I don't have a running CQ 5 instance but I think that it didn't had the FSClassLoader that handles the compiled JSP in my AEM 6.1 instance. So you probably receive a 404 because this plugin is not be installed.
If you want to find more about your concrete issue tail the error.log file and also you may check that the following bundles are in the Active state:
Apache Sling JSP Tag Library
Apache Sling Scripting Core
Apache Sling Scripting Implementation API
Apache Sling Scripting Java Support
Apache Sling Scripting JavaScript Support
Apache Sling Scripting JSP Support
Apache Sling Scripting JST Support
As a response to your question, in CQ 5 you can achieve what you want by manually deleting the compiled nodes found in the repository at /var/classes and /var/clientlibs.
What version of GWT is Vaadin 7.4/7.5 based on?
I know vaadin includes their own version of GWT with some addons and possible additional bug fixes but what version is vaadin 7.4/7.5 based on?
Surely you need to know this if you intend to switch from GWT jars to vaadin provided jars. For example GWT RPC does not work in development mode when you use GWT jars on the client and vaadin jars on the server even when vaadin is based on the same version of GWT. e.g Vaadin 7.1 which I believe is based on GWT 2.5.1
We have a GWT application that uses RPC and also a Vaadin application. We've had to make sure the vaadin gwt version and the gwt application use the same version of GWT (if you know what I mean).
We want to move to vaadin 7.4/7.5 so I am assuming we will need to migrate our GWT application to the same version vaadin 7.4/7.5 is based on?
I'd say 2.7 with some changes for vaadin.
I can't say for sure, but my assumptions are based on the property
gwt.version=2.7.0.vaadin3
in this file: https://github.com/vaadin/vaadin/blob/7.5/build.properties
Here the same file fore vaadin 7.4: https://github.com/vaadin/vaadin/blob/7.4/build.properties
Is is possible to implement the client side of a Play Framework 2.x web application using GWT or Vaadin?
Play 1.x has a special module that provides GWT integration, but I can not find examples of the use of these technologies together in Play 2.x version. Can these technologies be integrated? Is there a module, or must some other approach be used?
GWT and Play2 can work together seamlessly, just as GWT can be used with python and go backends.
Using GWT with Play2 has two parts, serving static files and client-server communication.
For the GWT produced static files (js, css, img..) you can just add them to the Play2 public directory, and they will be accessible based on the routes configuration.
For client-server communication your best bet is using a pure json-rest approach, as request-factory, gwt-rpc have some dependency on J2EE servlets.
There are plenty examples of providing a json/REST api with Play2, and plenty examples of interacting with json/REST APIs with GWT.
Henri Kerola demoed this recently for play 2.x and will give a talk at javaone this year:
http://www.youtube.com/watch?v=IwuqAh0VSek
I found a project on github which integrates Vaadin with Play 2.2:
https://github.com/henrikerola/play-vaadin-integration
You can't use Vaadin with play2. Vaadin is basically a Java EE servlet that must live in a Java EE container such as Tomcat.
Play is not based on Java EE, it uses its own server.
As for GWT all server side code needs a Java EE container. But if you just want the client side then it's totally possible as it is with any web framework.
Just create json web services and remove server dependancies.
For an example in php : http://gwtquickstart.blogspot.fr/2009/11/call-php-script-from-gwt.html
How do you setup a JNDI server on GWT's hosted mode (they seem to use an embedded Jetty server)?
You can switch to any external Java server and use it without problems with GWT (I'm assuming here that you already have a working configuration and you don't want to migrate it to GWT's embedded Jetty, which may or may not prove to be difficult). For more details see the good docs.