I try to use the com.google.gwt.user.server.Base64Utils to encode my image on the server side, but the compiler giving me this info (later causing an error):
*"[INFO] [ERROR] Errors in 'jar:file:/C:/.../....rpc-1.12-SNAPSHOT.jar!/...////PictureFileDTO.java'
[ERROR] Line 46: No source code is available for type com.google.gwt.user.server.Base64Utils; did you forget to inherit a required module?"*
Using GWT 2.1.0 and Maven in Eclipse.
What am I missing here? Any ideas?
The gwt-user.jar is the library you develop against, regardless whether you develop client-side or server-side code. It contains everything, UI widgets, utility-classes for the client-side, as well as utility-classes for the server-side.
The gwt-servlet.jar is used at runtime. I'm not talking about development mode, but about running your web application on some web server (Apache, IIS...). The gwt-servlet.jar contains the classes that are needed by the web server to run server-side GWT stuff.
So yes, the Base64Utils class is in both JAR files. Nevertheless it is not available for client-side development.
If you need something that work on both sides, check this out:
http://www.source-code.biz/base64coder/java/
Related
I have created an ESB application which fails to execute the flow because the library js-engine-1.1-jdk14.jar is present in Mule Runtime server 3.9.0 Community Edition.
So I want to know how can I remove this jar js-engine-1.1-jdk14.jar from the mule runtime server in Anypoint Studio so that my flow can execute properly.
Error is :
com.sun.phobos.script.util.ExtendedScriptException:
org.mozilla.javascript.EcmaError: ReferenceError: "load" is not
defined. (#3) in at line number 3
You should never remove a jar from the runtime, under risk of breaking it. Same with thing with overriding or updating them. Instead, at least for Mule 3.x, you have to adapt your application to the libraries provided.
You didn't mention what was the error or problem why it fails. If the application is using a different and incompatible version than the one provided, then it needs to be modified to use the same one than the runtime.
In the EE you have the alternative method of fine grained class loading control though it is not useful for every use case.
The lib can be found inside plugins/org.mule.tooling.server.3.9.0_6.4.0.201710051922\mule\lib\opt. We can remove it from there.
I think answer on my question is NO. But still, I'm wondering is it possible to run gwt applicaton as frontend for example on Apache HTTPD server. The idea that compiled gwt is pure javascript and don't need java backend (if we don't use java based RPC)
There's nothing stopping you. GWT code breaks down into two parts; server-side and client-side code. As you say the client-side code compiles down into pure javascript which can be easily served up by httpd.
The main advantage of using gwt's classes on the server is that data you request via RPC will arrive in your client code as java objects with no work on your part. But you can easily make calls to any old service using the RequestBuilder class, or XMLHttpRequest if you need more control.
Edit: There is one special bit of configuration you should do to make sure httpd works well with your client-side gwt code:
<Files *.nocache.*>
ExpiresDefault "access"
</Files>
<Files *.cache.*>
ExpiresDefault "now plus 6 months"
</Files>
This makes sure that when you upload a new version of the app users' browsers will download it automatically, but also makes sure that they won't download the entire app every time they visit your website. Very useful.
Your opinion is wrong. You can create a gwt application which is designed only for front-end.
To test that you can do the following
Create a sample gwt application which has only front end content
Compile and build the application
Place the build content folder in your Apache web directory.
Ee : if you created a project called test-gwt, the JS and HTML contents are in test-gwt directory created inside the war directory.
Access the new application through a web browser, like http://localhost/test-gwt
Hope this would help.
That is possible and works like a charm as long as you don't write your server component with gwt.
Here is an simple gwt client only htaccess password app (currently only german) as an example, wich i've coded for fun.
"I'm wondering is it possible to run gwt applicaton as frontend for example on Apache HTTPD server".
The answer is NO. GWT UI frontend does not run on any server at all. It runs only on a browser with Javascript enabled.
But if I ignore the language semantics of the question and answering the gist of it - the answer is Yes. Pardon me, but I think the language you should have written is
"is it possible to SERVE the gwt applicaton frontend from an Apache HTTPD server".
Just deploy your servlet-less war onto the HTTPD (removing the WEB-INF folder).
In fact, you could even write RequestBuilder requests to request for static json streams from files placed in the GWT module development "public" folder. Where the GWT compiler would copy the contents of the "public" folder to the deployed application root.
Or you could use script-include to get your GWT client request for dynamic content jsonp from another server - which would not create any servlet in your app. I documented the script-include technique here: http://h2g2java.blessedgeek.com/2011/06/gwt-requestbuilder-vs-rpc-vs-script.html.
I'm trying to create a Web Service Client using the option WSDL URL in NetBeans IDE 7.0. Unfortunately, it is not able to create one and is failing with the following error:
Saxon cannot write a DOMResult unless saxon9-dom.jar is on the classpath
After seeing this error message, I even confirmed whether saxon9-dom.jar is added to the Libraries in NetBeans. Yes, it is already available. I don't know why still the error is appearing. Can somebody let me know what is going wrong?
I'm trying to create web service client for this WSDL. I'm choosing JAX-WS Style in Client Style option while creating New Web Service Client in NetBeans.
UPDATE:
After googling, I read about some clues from the following 2 places:
1) http://www.mail-archive.com/fop-dev#xmlgraphics.apache.org/msg09659.html
This is due to the new event-handling framework that has been added
after 0.95. The step in the build process that generates the resource
files for the various messages, seems to require a writable DOM
implementation.
As the message indicates, Saxon offers such an implementation in a
separate JAR, which needs to be added to the classpath when building
FOP Trunk.
2) http://xmlbeans.apache.org/sourceAndBinaries/index.html
Using XPath/XQuery requires an additional download of
saxonb9-0-0-4j.zip and placing on the classpath of the files
saxon9.jar and saxon9-dom.jar that it contains. The zip is available
here. We cannot distribute this zip in a binary distribution due to
licensing issues.
So, I thought of changing saxon9-dom.jar in the classpath. I was using saxon9-dom.jar from saxonb9-1-0-8j.zip before, but when I tried to include saxon9-dom.jar available in saxonb9-0-0-8j.zip, now this error has disappeared and am getting a different error now as shown below. Any ideas/clues?
Web Services are described using WSDL files, so in order to create a Web Consumer for them you'll have to specify the WSDL url.
You can obtain it by adding ?WSDL ar the and of the url.
For example:
CrudService.asmx becomes
CrudService.asmx?WSDL
(It you have tested your web service and it appears ?Tester at the end, just replace it with ?WSDL).
I created a web application project. It ran successfully, but shows one message.
i.e. GWT Module needs to BE (re)compiled message displayed. How to solve this error/warning?
"GWT Module need to BE (re)compiled" - that means, you should call the app with the gwt.codesvr parameter, for example:
http://localhost:8080/MyProject/index.html?gwt.codesvr=172.16.0.43:9997
This message must be coming If you are running GWT in Development mode? check if you have installed the GWT browser plugin properly, check if there are any errors shown in the development mode tab(in eclipse).
I'm trying to call a web service in my back end java code when it's
running in hosted mode. Everything loads fine, the GWT RPC call works
and I can see it on the server, then as soon as it tries to call an
external web service (using jax-ws) the jetty falls over with a
Internal Server Error (500).
I have cranked the log all the way up to
ALL but I still don't see any stack traces or cause for this error. I just get one line about the 500 Error with the request header and response.
Does anyone know if the internal jetty keeps a log file somewhere, or
how I can go about debugging what's wrong?
I'm running GWT 1.7 on OS X 10.6.1
Edit: I know that I can use the -noserver option, but I'm genuinely interested in finding out where this thing lives!
From the documentation:
You can also use a real production
server while debugging in hosted mode.
This can be useful if you are adding
GWT to an existing application, or if
your server-side requirements have
become more than the embedded web
server can handle. See this article on
how to use an external server in
hosted mode.
So the simplest solution would be to use the -noserver option and use your own Java server - much less limitations that way, without any drawbacks (that I know of).
If you are using the Google Plugin for Eclipse, it's easily set up in the properties of the project. Detailed information on configuration can be found on the official site.
Edit: you could try bypassing the Hosted Mode TreeLogger, as described here: http://blog.kornr.net/index.php/2009/01/27/gently-asking-the-gwt-hosted-mode-to-not):
Just create a file called
"commons-logging.properties" at the
root of your classpath, and add the
following line:
[to use the Log4j backend]
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
[to use the JDK14 backend]
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
[to use the SimpleLog backend]
org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
Edit2: the trunk of GWT now also supports the -logfile parameter to enable file logging, but it probably won't help in this case, since the problem lies in the way the Hosted Mode treats the exceptions, not the way it presents them.