Second compilation of same sources produces different set of gwt.rpc files - gwt

I would like to follow up on this question gwt-serialization-policy-hosted-mode-out-of-sync. In short - when I do a RPC from hosted browser then this call fails on server with the exception.
INFO: GwtRpcEventSrvc: ERROR: The serialization policy file '/84EC7BA65AF8175BAA99B47877FDE163.gwt.rpc' was not found; did you forget to include it in this deployment?
SEVERE: GwtRpcEventSrvc: WARNING: Failed to get the SerializationPolicy '84EC7BA65AF8175BAA99B47877FDE163' for module 'http://host:19980/MYAPP/'; a legacy, 1.3.3 compatible, serialization policy will be used. Youmay experience SerializationExceptions as a result.
SEVERE: Exception while dispatching incoming RPC call
While when I do the same RPC from browser then the request is performed successfully on server.
In addition I observed a strange behavior of GWT compiler that could result in a problem with hosted browser mode.
I assume when I do two subsequent compilations of an exact same code then the result of the individual compilations is supposed to be same. I mean at least the xxxxx.html and yyyyy.gwt.rpc files have to be same. (Where xxxxx and yyyyy are the long numbers such as 84EC7BA65AF8175BAA99B47877FDE163.)
Currently I have two versions of my project.
An old project compiled by GWT 1.7 that does not suffer from problem with the hosted browser described in gwt-serialization-policy-hosted-mode-out-of-sync
A new project that is compiled by GWT 2.0.4. This new project is based on the old project. This project suffer from the hosted browser problem.
Case 1: Old project with GWT 1.7
I took my old project that was compiled by GWT 1.7. I did two compilations and I compared compilation artifacts. gwt.rpc files were same while html files had different content and name. Since the gwt.rpc files were alwas same I did not have a problem with hosted browser.
Case 2: New project with GWT 2.0.4
I compiled it twice and both gwt.rpc and html files were different. Therefore RPC call in hosted browser failed on server because of missing gwt.rpc file.
Case 3: Old project with GWT 2.0.4
I compiled it twice and both gwt.rpc and html files were different. Therefore RPC call in hosted browser failed on server because of missing gwt.rpc file.
I did some investigation and identified that when I comment out a data member in a class Data that is transmitted from server to client, then compiled files start being same.
class Data implements IsSerializable {
List<IsSerializable> data;
...
}
I wanted to do same thing in the new project but it seems that there are many classes to be modified. So the problem is growing as the project is growing.
I don't know what to use instead of
List<IsSerializable> data;
to transfer data.

You need to read some more on GWT serialization policies:
Serializable Types
Usually you don't mingle with .rpc files unless your are doing advanced RPC calls directly to your server.
Your serializable object :
class Data implements IsSerializable {
List<IsSerializable> data;
...
}
A user-defined class is serializable if all of the following apply:
It is assignable to IsSerializable or Serializable, either because it directly implements one of these interfaces or because it derives from a superclass that does
All non-final, non-transient instance fields are themselves serializable, and
As of GWT 1.5, it must have a default (zero argument) constructor (with any access modifier) or no constructor at all.
So you should probably have something like:
class Data implements IsSerializable {
List<YOUR_TYPE> data;
...
}
Your list's template is a type, you don't set 'IsSerializable'... it should be something like :
List<int> data;

Related

Ecore EMF PackageNotFoundException

I have to work with a project I didn't wrote myself. It uses Ecore EMF (I have no experience with this) and I can't figure out how to solve this error:
At some point the program loads a .xmi file with this function: org.eclipse.emf.ecore.xmi.impl.XMLHandler.getPackageForURI()
And this results in this error:
org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package with uri 'platform:/plugin/Animals/model/Animals.ecore' not found. (file:/C:/Users/model917.xmi, 2, 193)
It seems like the file model917.xmi exists and is not the origin of this error. I think the problem is caused because the Animals.ecore file is not found. In the model917.xmi file I found this statement:
xmlns: Animals ="platform:/plugin/Animals/model/Animals.ecore
So I think the model in file model917.xmi uses another model defined in Animals.ecore which can't be found and causes the error.
I have access to the Animals.ecore file and found out that EMF/ecore uses something like a registry to find such files. So it seems like I have to add the Animals.ecore file to this registry and I found some answers online which didn't work and I run out of ideas what to try next. Can someone give me an easy way to register this file so it will be found? I am using Eclipse if this is relevant/maybe there is an easy way to do it with Eclipse.
Usually, EMF-based softwares should rely on the so-called "namespace URI" (nsURI) of EPackages, which are usually of the form "http://foo/bar/Animals".
"http://foo/bar/Animals" should be registered in the EMF Registry and dispatch depending on your actual runtime situation to a URI that looks like "platform:/plugin/bar.foo/Animals.ecore" (when file Animals.ecore is deployed in an Eclipse plugin for an Eclipse-based application), or "platform:/resource/bar.foo/Animals.ecore" (when file Animals.ecore is deployed in the workspace of the running Eclipse-based application) or even "file:///path/to/Animals.ecore" (anywhere on the filesystem).
Technically you can use any of those URI forms as long as they are correctly resolved at runtime, but you must understand that not all URIs make sense in all contexts, for instance "platform:/" URIs only make sense in Eclipse-based context. nsURIs are supposed to be resolveable in all contexts (thanks to the registry!)
Is your code meant to be running in the context of an Eclipse-based application ? Then the project containing Animals.ecore should be deployed as a plugin, and I am guessing it is currently not.
Is your code meant to be standalone? Then the reference in your xmi file, to the ecore file, should not be of the form "platform:/..." but rather of the form "http://foo/bar/Animals" (the nsURI of the EPackage that is the root element of Animals.ecore)

java.xml.namepsace error - SOAP (Webservice) in Java

I have no experience with WebService, especially SOAP, but I have to deal with it. I work with Java 11 and with the latest Eclipse IDE. In the beginning I read a lot and also developed my own WebService. This service can only calculate the BMI. There are no errors in this service on the server side.
I had the client automatically generated with the Java API for XML Webservices. However, several errors are displayed in the generated classes.
First Error:
"The package javax.xml.namespace is accessible from more than one module: java.xml, jaxrpc"
If I try to fix the error, then there is a new error. Let's get back to trying to fix the bug. In some other forums I have read that in the module information "module-info.java" the "requires java.xml" should be commented out. The error seems to disappear for now, but it leads to two new errors:
"The type javax.xml.namespace.QName is not accessible" and "The type javax.xml.namespace.QName cannot be resolved. It is indirectly referenced from required .class files"
Here are a few code:
module Client {
exports ws;
requires axis;
requires java.instrument;
requires java.logging;
requires java.management;
requires java.naming;
requires java.net.http;
requires java.prefs;
requires java.rmi;
//requires java.xml;
requires jaxrpc;}
Here is a example of the DemolmplServiceLocater where java.xml.namepace are underlined red:
public DemolmplServiceLocator(java.lang.String wsdlLoc, javax.xml.namespace.QName sName) throws javax.xml.rpc.ServiceException {
super(wsdlLoc, sName);
}
This is the class DemolmplService.java with the second error and "fixed" first error.
The lost one ist the Build Path from my project.
Among other things I opened a client in Java-SE1.8 project and tried out the client there. There no error was displayed and the method bmi(weight,height) was executed successfully. But I need the project at least in Java 10 or higher.
Can anyone offer me a solution, preferably a step-by-step guide?
I thank you in advance!

java.lang.LinkageError: loader constraint violation when developing a SOAP plugin in JIRA

I am trying to implement a listener in JIRA which uses SOAP to contact
a web service, (in fact it is OTRS, another issue management system).
I chose to following a SimpleListener implementation (JIRA Listener
Event), rather than an atlassian-event.
I chose to implement it via the plug-in mechanism, rather than
installing a one-off static class into JIRA's CLASSPATH.
(maybe that was the wrong decision, I do not know).
Notice: I do not know much about SOAP, WSDL, nor the internals of JIRA
(codehouse, osgi).
I followed by and large the instructions given at:
https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project/create-a-helloworld-plugin-project
(and subsequent instruction pages).
I have created a plugin for JIRA using the atlas-create-jira-plugin.
I generated (using the org.apache.axis.wsdl.WSDL2Java class -- I think
it is called Apache's Axis version 1 -- in a command-line-mode from
the WSDL file: standardTicketActionsSoap.wsdl)
a bunch of Java classes which I added to the plug-in, such as:
org/otrs/www/TicketConnector/GenericTicketConnector.java
org/otrs/www/TicketConnector/GenericTicketConnectorLocator.java
org/otrs/www/TicketConnector/GenericTicketConnector_BindingStub.java
org/otrs/www/TicketConnector/GenericTicketConnector_PortType.java
org/otrs/www/TicketConnector/OTRS_Article.java
org/otrs/www/TicketConnector/OTRS_Attachment.java
org/otrs/www/TicketConnector/OTRS_DynamicField.java
org/otrs/www/TicketConnector/OTRS_Error.java
org/otrs/www/TicketConnector/OTRS_PendingTime.java
org/otrs/www/TicketConnector/OTRS_TicketCreate_Ticket.java
org/otrs/www/TicketConnector/OTRS_TicketGetResponse_Article.java
org/otrs/www/TicketConnector/OTRS_TicketGetResponse_Attachment.java
org/otrs/www/TicketConnector/OTRS_TicketGetResponse_Ticket.java
org/otrs/www/TicketConnector/OTRS_TicketSearch_DynamicField.java
org/otrs/www/TicketConnector/OTRS_TicketSearch_TicketFlag.java
org/otrs/www/TicketConnector/OTRS_TicketUpdate_Ticket.java
org/otrs/www/TicketConnector/SessionCreate.java
org/otrs/www/TicketConnector/SessionCreateResponse.java
org/otrs/www/TicketConnector/TicketCreate.java
org/otrs/www/TicketConnector/TicketCreateResponse.java
org/otrs/www/TicketConnector/TicketGet.java
org/otrs/www/TicketConnector/TicketSearch.java
org/otrs/www/TicketConnector/TicketSearchResponse.java
org/otrs/www/TicketConnector/TicketUpdate.java
org/otrs/www/TicketConnector/TicketUpdateResponse.java
I had to manually modify two generated classes according to:
How to solve SAXException: Invalid element in,
to avoid a "org.xml.sax.SAXException: Invalid element " error.
I have three issues with this approach, of which the third one is the
real problem:
a) the refresh with FastDev or with atlas-cli 'pi' command does not
work, with the "[INFO] Waiting for commands..." symtom (as:
in atlassian's answers page topic: fastdev-not-end-up-the-processing
but the fix won't work for me) , I always need to shutdown the full
JIRA test installation and restart it. This may be due to some false
plug-in configuration and, though a pain in the neck, I can live with that for the time being.
b) a command-line build via Maven (atlas-run or atlas-build) does not
report any error, while compiling the project with Eclipse will fail
with:
Project build error: Unresolveable build extension: Plugin com.atlassian.maven.plugins:maven-jira-plugin:5.0.13 or one of its dependencies could not be resolved: Failure to find com.atlassian.maven.plugins:maven-jira-plugin:jar:5.0.13 in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced
c) when the listener is executed I get a nasty:
java.lang.LinkageError: loader constraint violation: when resolving field "service" the class loader (instance of org/apache/felix/framework/ModuleImpl$ModuleClassLoader) of the referring class, org/apache/axis/client/Stub, and the class loader (instance of org/apache/catalina/loader/WebappClassLoader) for the field's resolved type, org/apache/catalina/loader/WebappClassLoader, have different Class objects for that type
at
org.otrs.www.TicketConnector.GenericTicketConnector_BindingStub.(GenericTicketConnector_BindingStub.java:98)
This is the real show-stopper.
Could this be a simple Maven configuration issue?
thanks,
Michele

How to share a GWT RPC RemoteServiceServlet among multiple client modules / apps

I have several GWT modules and web apps running in Jetty. They each want to use my LoginService RPC interface, so I put this interface and its servlet implementation in a common module. I serve the servlet (LoginServiceImpl) from my root web context, and web.xml exposes it at the url "/loginService". In a another GWT module, to use this service, I had to set the entry point, like this...
LoginServiceAsync loginService = GWT.create(LoginService.class);
ServiceDefTarget t = (ServiceDefTarget)loginService;
t.setServiceEntryPoint("/loginService");
Now, the module trying to use the loginService is called discussions, and I get this error on the server.
ERROR: The serialization policy file
'/discussions/discussions/7B344C69AD493C1EC707EC98FE148AA0.gwt.rpc' was not found;
did you forget to include it in this deployment?
So the servlet is reporting an error that mentions the client (the discussions module). I'm guessing that the RPC plumbing passed the name of this .rpc file through from the client, and the servlet is now looking for it. (?) As an experiment, I copied, the *.gwt.rpc files from the discussions module into the root web context, so the servlet could find them. This did stop the error. But I still get another error:
com.google.gwt.user.client.rpc.SerializationException: Type
'mystuff.web.shared.User' was not assignable to
'com.google.gwt.user.client.rpc.IsSerializable' and did not have a custom field
serializer. For security purposes, this type will not be serialized.: ...
This class is serializable; it worked before in other modules, so now I'm lost.
What is the right way to use the LoginService from multiple clients modules?
Update:
This error was showing up in hosted devmode, and it went away after a full compile. Maybe this is related to gwt serialization policy hosted mode out of sync . I will update again if I can better reproduce the problem.
See my answer here. The short answer is: you'll need to make mystuff.web.shared.Users source available at compile-time to your discussions module.

Strange GWT Error with external jar on server side

I want to use a external jar (Apache Mahout) on the server side of my GWT Applicatopn.
As far as i know using external jars on the server side shouldn't cause an error. Only on the client side but when i try to run the code i get the following error:
"no source code is available for de.unimannheim.paniscus.server..."
Whats wrong here ?
Please help me i need to solve this for my thesis
Hi guys i created now an collbaorative.gwt.xml where i inherited all classes from apache mahout that are used within de.unimannheim.paniscus.server.collaborative but it's still not working. Sorry i'm helpless whats wrong here ?
I agree with Dusty Campbell, you should not inherit the jar in the *.gwt.xml. The <inherits> tag in the *.gwt.xml specifies gwt-modules which should be inherited. So only client-side-compatible code can be inherited.
Citation from the gwt docs: "<inherits name="logical-module-name" /> : Inherits all the settings from the specified module as if the contents of the inherited module's XML were copied verbatim. Any number of modules can be inherited in this manner"
see also: http://code.google.com/webtoolkit/doc/1.6/DevGuideOrganizingProjects.html#DevGuideInheritingModules
My guess is that you (by mistake) use a class from the "de.unimannheim.paniscus.server" package in client-side or shared code. Even just an import statement (import de.unimannheim.paniscus.server.*) will cause this exception.