GWT 2.8 websocket support - gwt

Does jetty server in gwt 2.8 support websocket now? As I know it did not support before. If there is a positive answer, then how to make it work? Stripping out jetty-8 and replaceing it with jetty-9 is not a good idea I think.

then how to make it work?
I want to elaborate a bit on this after the GWT 2.8.0 release. The only thing required for using javax.websocket is the knowledge of the Jetty version packaged with GWT and the following set of Maven dependencies (see also the Jetty WebSocket examples on GitHub):
<project>
<properties>
<sdm.jetty.version>9.2.14.v20151106</sdm.jetty.version>
</properties>
<dependencies>
<dependency>
<groupId>org.eclipse.jetty.websocket</groupId>
<artifactId>websocket-server</artifactId>
<version>${sdm.jetty.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.eclipse.jetty.websocket</groupId>
<artifactId>javax-websocket-server-impl</artifactId>
<version>${sdm.jetty.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.websocket</groupId>
<artifactId>javax.websocket-api</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
</depencies>
</project>
Make doubly sure that the scope is provided - for the former two this will mean they are not packaged into the final app - you will be requiring those only when running the SuperDev-Mode (SDM). Ifjava.websocket-apiwas on your classpath probably the annotation-based configuration will not work at all (at least in embedded Tomcat and Jetty) due to the annotations being picked up by the wrong class loader (see also related question WebSocket 404 error for more info on this topic).

GWT 2.8 has switched to Jetty 9.2, and now supports Servlets 3.1 servlets container initializers, which I think are being used to setup WebSockets.
I haven't tried it but I suppose that you can now have WebSockets in DevMode, provided you add the required dependencies to the classpath.
You can also simply use a separate server rather than the one embedded into DevMode.

Related

Necessity for declaring RestEasy dependencies although bundled with WildFly?

According to the RESTEasy modules in WildFly documentation:
In WildFly, RESTEasy and the JAX-RS API are automatically loaded into
your deployment's classpath if and only if you are deploying a JAX-RS
application (as determined by the presence of JAX-RS annotations).
However I don't really understand this paragraph. What does it exactly mean? As an exmaple, let's say I want to use ResteasyClient in a class. My IDE tells me that I must add this dependency in the corresponding pom.xml. But then how does that go with the above quote?
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-client</artifactId>
</dependency>
My pom.xml already includes this:
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-jakartaee8-with-tools</artifactId>
<version>20.0.1.Final</version>
<scope>import</scope>
<type>pom</type>
</dependency>
When looking at this BOM it looks as if the resteasy-client is already included?
My IDE tells me that I must add this dependency in the corresponding pom.xml
Yes, you must declare this dependency in your pom.xml if you use the API of it, but you only need provided-scope, because as the documentation said, it is already included in your deployment's classpath. If you use only the standard api defined in wildfly-jakartaee8, you do not need this dependency.

REST with JAX-RS tomcat server returning "requested resource is not available"

I was following short tutorial on creating REST api using JAX-RS. I am using Tomcat server v7.0. When I run the application on the server I get error 404-requested resource is not available.
The project is Maven based, and my pom.xml file includes the following line
<properties>
<failOnMissingWebXml>false</failOnMissingWebXml>
</properties>
I do not have web.xml file as a result. That was how the tutorial was achieved. I do not have index.html/jsp file. I have created two classes RESTconfig.java and BookResources.java
...import statements
#ApplicationPath("api")
public class RESTconfig extends Application {
}
...import statements
#Path("books")
public class BookResources {
#GET
#Produces(MediaType.TEXT_PLAIN)
public String books() {
return "Hello world";
}
}
My pom.xml file looks like this
<groupId>com.dere</groupId>
<artifactId>myrest</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>war</packaging>
<properties>
<failOnMissingWebXml>false</failOnMissingWebXml>
</properties>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
Once I run the application on the server and go to http://localhost:9090 I am able to see Tomcat home page, but if try to get data http://localhost:9090/myrest/api/books I get the 404 error, i.e requested resource is not available, I mentioned above.
Most of the examples or usage I saw online involve using web.xml and providing root of the application and using a servlet. This is my first exposure to building REST api. I may have misunderstood the whole thing or I skipped some step. I look forward for your help.
I am using Eclipse Photon for Java EE
Look at this
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
</dependency>
This is nothing more than basically a bunch of interfaces for the EE spec. There is no implementation. Java EE servers will have the implementation. Tomcat is not an EE server. The only part of the EE spec it will definitely have the implementation for is Servlets and JSP (the web profile). If you want an EE server, checkout Glassfish or Wildfly.
You are trying to work with the JAX-RS spec, where Tomcat for sure by default does not have an implementation for. So you need to add that implementation. The easiest implementation, IMO to get started with, is Jersey. You can simply add this dependency
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.25.1</version>
</dependency>
and it will get you up and running. Keep the Jersey User Guide handy. It will come in use.

SOAP web services NPE on redeployment Tomcat 6

I'm using Tomcat 6 and I have a web application that uses a SOAP web service. I generated the client classes to use using cxf-codegen-plugin in maven, my dependencies are :
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-api</artifactId>
<version>2.6.1</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>2.6.1</version>
</dependency>
Everything works until I redeploy my war on tomcat (or even doing a simple touch on it: no code modification at all). Using the same url to access my page that makes the SOAP service call I have this weird NPE:
java.lang.NullPointerException
at com.ctc.wstx.util.SymbolTable.findSymbol(SymbolTable.java:385)
at com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1831)
at com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:2997)
at com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2941)
at com.ctc.wstx.sr.BasicStreamReader.handleRootElem(BasicStreamReader.java:2078)
at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2058)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1117)
at com.sun.xml.internal.ws.util.xml.XMLStreamReaderFilter.next(XMLStreamReaderFilter.java:81)
at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.next(XMLStreamReaderUtil.java:78)
at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.nextContent(XMLStreamReaderUtil.java:99)
at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.nextElementContent(XMLStreamReaderUtil.java:89)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.hasWSDLDefinitions(RuntimeWSDLParser.java:209)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:119)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:254)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:217)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:165)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:93)
at javax.xml.ws.Service.<init>(Service.java:56)
at some.package.flightinfo.model.flightstatsv2.soap.AirportsV1SoapService.<init>(AirportsV1SoapService.java:48)
at some.package.flightinfo.adapter.FlightStatsV2ContentAdapter.getAirportsByGPSCoordinate(FlightStatsV2ContentAdapter.java:107)
The only way I can get my web application working again is to restart tomcat which is no option at all.
I am totally clueless on what's going on, has anyone ever experienced this problem before?
Cheers.
Well, you are missing the cxf-rt-frontend-jaxws dependency. Thus, you are ending up using the JAX-WS reference impl built into the JDK, not CXF. If you add the CXF dependencies, does that fix it? Could be a bug in the RI or something.

Arquillian and jboss-4.2.3.GA

i am workign on a jboss-4.2.3.GA project. Its a old project but we cant upgrade to new server.
I am trying to use Arquillian for JPA..
We are using folliwng entry in pom for JPA
<dependency>
<groupId>com.jboss</groupId>
<artifactId>ejb3-persistence.jar</artifactId>
<version>4.2.3</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>hibernate</groupId>
<artifactId>hibernate3</artifactId>
<version>3.2.4.SP1</version>
<scope>provided</scope>
</dependency>
I am trying to configure Arquillian but i am getting some issue like nosuchmethod found or some time no default container set.
Anyone help me what container i need to set and any dependency settings ?
Add the arquillian-bom to the dependencyManagement section of your pom, see the Getting Started Guide: http://arquillian.org/guides/getting_started/#add_the_arquillian_apis
That will update the version of the dependencies the jbossas adapter has on arquillian core. Without it you will be running a mix of Core 1.0.1.Final and Core X (what ever the adapter happens to be compiled against currently which may or may not be compatible with the 1.0.1.Final Core artifacts).

Using Drools on Jetty

I am trying to start up a webapp that uses Drools 5.2.0.M1. I get the following stacktrace on startup:
java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/CategorizedProblem;
at org.drools.commons.jci.compilers.EclipseJavaCompiler$3.acceptResult(EclipseJavaCompiler.java:336)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:335)
at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:366)
at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:51)
at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:366)
at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:55)
I have the jars in my pom:
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>5.2.0.M1</version>
</dependency>
<dependency>
<groupId>org.eclipse.jdt.core.compiler</groupId>
<artifactId>ecj</artifactId>
<version>3.5.1</version>
</dependency>
Why Can't it find CompilationResult.getProblems()?
JDT isn't backwards compatible.
Check the drools-compiler pom (of exactly the version you're using) on which version of ecj it depends and use that version. Or don't declare ecj at all, it's a transitive dependency for drools-compiler anyway.
PS: upgrade to drools 5.2.0.CR1 (or final once it's out)
I had a similar problem. I was having a web-app using Jetty 6. Jetty 6 which apparently bringing in a non-compatible version of JDT. After switching to Jetty 7 the problem was solved.