I have two questions:
1. Which Jetty version is used by GWT 2.5.1 in dev-mode?
2. Is there a way to change this version?
6.1.11 (source: https://gwt.googlesource.com/gwt/+/2.5.1/dev/build.xml)
Note that 2.6 and 2.7 use Jetty 8.1.12.v20130726, and 2.8 uses Jetty 9.2.14.v20151106
Yes, you can implement a ServletContainerLauncher that starts another version of Jetty. Beware of classpath conflicts though! (but I suppose you'll want to use a recent version and the new versions use org.eclipse.jetty rather than org.mortbay.jetty as a root package so there shouldn't be any problem (with the old GWT pre-2.6).
FYI, gwt-dev will be split into several JARs in the next version of GWT (or maybe the one after that) and the dependency on Jetty will be moved to an optional JAR, and will possibly be updated as well. (note though that GWTTestCase also depends on Jetty)
EDIT: this finally happens with GWT 2.8, but Jetty is needed for SDM (CodeServer) and Jetty has a bad track of backwards compatibility.
Related
I want to change GWT's v. 2.7.0 embedded Jetty version v. 8.1.12.v20130726 to later jetty v. 9.2.22.v20170606, because for some reason Atmosphere
websockets do not work with jetty 8 version (while it works with 9).
To make sure that it's Jetty that's causing problems for Atmosphere (and not GWT super dev mode), I deployed application.war to tomcat/Jetty servers:
Tomcat 7.0.79: works
Jetty 9.2.22.v20170606: works
Jetty 8.1.12.v20130726: does not work
I found a thread asking quite a similar question, GWT: Jetty version in dev mode, and I would like to expand on that. If I were to implement ServletContainerLauncher , would it not conflict with JettyLauncher ? How should I go about writting my own ServletCotainerLauncher for dev mode?
If you have any better ideas then writing my own ServletContainerLauncher, I would like to hear them.
GWT 2.8 underwent specific modifications to make this possible - it wasn't simple, though if you review the commits, you could probably make the same changes.
Instead, I strongly urge you to consider moving to GWT 2.8.2, the latest version of GWT, released just a few days ago. The version you are using, GWT 2.7.0, is almost three years old, and has a number of other bugs that have been resolved since then.
I am developing an Angularjs frontend which talks to a REST backend. I am developing using Eclipse and was using a Glassfish webserver.
I had the need to create htaccess redirect for Angular routes (see here: htaccess redirect for Angular routes) but to do this I need to change my webserver from Glassfish to Apache Tomcat since the htaccess stuff doesn't exist for the Glasshfish webserver.
When I created the new apache tomcat server v8.0, upon starting the log gave multiple errors for missing JAR files. These JARs were:
avalon-framework-4.1.3.jar
batik-css-1.6-1.jar
batik-ext-1.6-1.jar
batik-gui-util-1.6-1.jar
batik-util-1.6-1.jar
commons-configuration-1.5.jar
logkit-1.0.1.jar
nekohtml-1.9.11.jar
xercesImpl-2.8.1.jar
xml-apis-1.3.03.jar
Additionally, it wants the following JAR which doesn't not seem to be around anymore:
antisamy-1.3-SNAPSHOT.jar
A lot of the JARS mentioned above are old versions of the JARS. What can I do about the missing JAR that is not around anymore?
Also, how do I know if these JARs are the most current versions I should be using? (I added all of them I could find manually in the tomcat /lib directory)
Thanks in advance - I'm quite new to all this stuff so go easy on me:)
EDIT 1: I've included the non-snapshot version of the JAR as per unwichtich's answer. However this doesn't fix the error. Why would the Apache Tomcat v8.0 require such old JAR files to work, especially a snapshot jar? Where would one look to see where these JAR's are configured? Is it possible to know which newer versions of the JARs are compatible with my setup?
antisamy-1.3-SNAPSHOT.jar
First, you should NOT depend on SNAPSHOT dependencies, they can change the programs behaviour in the same version....
Second, SNAPSHOT versions might be seen as beta steps to the final release, so you can not expect that these SNAPSHOT versions are still available online when the final version was released.
A quick googling didn't suggest any old link to antisamy-1.3-SNAPSHOT.jar, but you may try this one: https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/owaspantisamy/antisamy-bin.1.3.jar. This should be the final of 1.3 and if you are lucky it contains the same API as the SNAPSHOT version you used before. If not, you may have to update your code so that it works with the final.
There seem to be newer versions of the lib, you also may want to try them.
I know this question was asked a lot of times, since I searched for hours for a solution, but it was never answered (or at least not for my situation).
I am using Wildfly 8.0 (ex JBoss), so I understand that I do not need to add jstl jars nor JSF jars since the implementation is already shipped with JBoss.
Now even when telling eclipse to use the Wildfly runtime libraries, I get the above error. I checked and the jboss-jstl-api_1.2_spec-1.0.4.Final.jar is part of the library
How can I get through this? I tried putting downloading jstl jars (from https://jstl.java.net/) and putting them in the lib directory but it is not working.
Copying the jars into "lib" works perfectly when I use Tomcat which doesn't have its jstl implementation. But not with Wildfly (maybe because eclipse ignores the jars I put in the lib directory since Wildfly has its own jars? But then why do I get the error in the first place? I am confused).
Thanks to anyone who could help me with this.
Edit: I forgot to precise that even with these errors on all my JSPs, the project builds and works perfectly on the server.
These errors are eclipse specific, it does not recognize the taglibs and displays annoying error messages at taglib declarations and warnings when using these (unknown to eclipse) tags. Plus, I can't use code completion.
Edit: I bypassed the problem, for the moment, by adding standalone myfaces and jstl libraries to the build path. I would like though that eclipse uses the jars available on server side. (For JPA for example I did not need to add the hibernate library to the build path, I simply told eclipse that the JPA implementation si available on server runtime and it worked fine with code completion and everything).
Alright, to not have to add any additional libraries (that are not needed by the server) here's what I had to do in addition to adding the Wildfly runtime library to the project:
Go to Project/Properties/Project Facets/Java Server Faces and chose Library Provided by Target Runtime in the library type (instead of a User Library).
I'm truly disappointed JSF support in eclipse. I'm encountering such caveats all the time.
I'm using JBoss 7.1.1 and even adding JBoss as the Target Runtime of the project didn't help.
The only solution that worked for me, was to define new JSF library inside Eclipse: Window Preferences -> Java -> Build Path -> User Libraries -> click New (pointing to the jsf-impl.jar and jsf-api.jar). And then adding such library to the build path of the project.
It solved all annoying eclipse errors can not find tag library. So it is pretty similar to the #Riccatti first solution.
Btw: answer which I found on the eclipse forum says that this error is usually caused by not existing JSF tag libraries (that are present in jsf-impl.jar) on the classpath.
I am using GWT 2.4 with Hibernate 3.0. I wanted to know what changes I need to make in my application for integrating GWT 2.5 in my application ?
Nothing special.
Replace 2.4.0 dependencies with 2.5.0-rc1 ones (depending on how you manage dependencies, either download the SDK and drop the new JARs to replace the previous ones, or bump the version number in your POM –if using Maven– or similar build file).
If you're using Maven and the gwt-maven-plugin, make sure you re-define the plugin dependencies too (note gwt-maven-plugin 2.4.0 also needs gwt-servlet to be overridden); or you can test the gwt-maven-plugin 2.5.0-rc1.
Check the list of breaking changes though; chances are small that they affect you, but there's still a risk.
I am currently developing an application which has a server part based on JavaEE 6.0 on JBoss 7.1 and a client based on Eclipse RCP 3.7.
For a simple OSGi package for a shared API I already run into trouble due to some differences in versions and depdencenies. The API requires "org.osgi.framework." for the bundle activator and "org.slf4j." for the slf4j logging API.
Currently my client is working very well, but JBoss tells me that the expected version of the OSGi import and the also the imports for slf4j do not fit...
I there a best practice to share OSGi bundles between Eclipse and JBoss? Do I need to get back to simple import and export declarations or can I used Require-Bundle somehow? Do I need to create some compatibility bundles for JBoss to get it running? What is the best way to proceed here?
UPDATE
I solved the issue by using Import-Package exclusively. For the dependency like org.osgi.framework is use version="0.0" to explain it does not matter. :-( It is not very safe, but currently I do not see another option. Is there a better way?
UPDATE 2
One also needs to pay attention to implement the correct verion of the OSGi Framework. JBoss 7.1.x only has OSGi 4.2 implemented, which has no support for typesafe service retrieval.
The best practice would be to use an import package statement with a range from the minimum version which you're using to the next major increment.
For example, if RCP expects version 1.5 of a package and JBoss expects 1.3.6, import version="[1.3.6,2)".
The Semantic Versioning whitepaper (pdf) explains why this style of import is safe and wise.