When I deploy newer version of my GWT application, I get sometimes this log error:
SEVERE: GwtRpcEventSrvc: WARNING: Failed to get the SerializationPolicy 'www.host.com:22041/MYAPP/'; a legacy, 1.3.3 compatible, serialization policy will be
a result.
Question 1) Is it a problem of serialization policy files remaining
in browser cache?
Question 2) How to prevent such log message? I tried to add changing
URL request param to nocache.js (<script
src="MyApp.nocache.js?v=123"...) but it did not help.
Try clearing your browser cache. It worked for me.. after searching a lot of a lot of ways to solve it.
See:
how to clear cache in gwt?
Stop browser scripts caching in GWT App
GWT Caching Concept
In summary: you need to set HTTP headers not to cache the .nocache.js files via your web server or a servlet filter
Related
I am facing 503 AuthenticationSupport service missing. Cannot authenticate request error every time server is started. This happened many times. There is no such broken error information on the error log file. I have even deleted the repository but didn't help much. I even use oak but still no use. I had set up it multiple times to skip this error but I don't feel confident with this approach. For better information, I am attaching the latest error log file.
https://drive.google.com/file/d/1aXEcZP_Tvk1ebBxfOmR9Q1ffk2KLeW66/view?usp=sharing
NOTE: I am a beginner in AEM. Please be gentle
java -Xmx6000m -jar oak-run-1.8.0.jar check --bin=-1 C:\Users\mahinder.singh\Documents\Projects\Adobe\author\crx-quickstart\repository\segmentstore
This is usual. Might be taking a little longer time than usual to load. Wait for a while.
If the issue still persists reinstall the instance and allow the aem to get kicked up on it's own.
I'm having difficulty in integrating AEM 5.6.1 with Site Catalyst. It allows me to connect in the configuration successfully, but does not work on the framework setup.
I've followed the standard procedure to connect AEM to SC and it accepts my login in the configuration, but fails on the framework set up with the browser message 'We were not able to login to SiteCatalyst. Please check your credentials and try again.'. Behind the scenes in the server log;
12.12.2014 14:10:06.967 *WARN* [0:0:0:0:0:0:0:1 [1418393406764] POST /libs/cq/analytics/sitecatalyst/service.json HTTP/1.1] com.day.cq.analytics.sitecatalyst.impl.SitecatalystHttpClientImpl Data center 'https://api3.omniture.com/admin/1.3/rest/' responded with errors {"error":{"code":500,"message":"Internal Server Error"}}
12.12.2014 14:10:06.967 *ERROR* [0:0:0:0:0:0:0:1 [1418393406764] POST /libs/cq/analytics/sitecatalyst/service.json HTTP/1.1] com.day.cq.analytics.sitecatalyst.impl.servlets.SitecatalystServlet Call to SiteCatalyst method 'Company.GetReportSuites' failed com.day.cq.analytics.sitecatalyst.SitecatalystException: not authenticated
I've tried accessing via the API Explorer and it works.
I've tried the troubleshooting guide without success.
I can log in to Site Catalyst, I'm an admin, I am in the web services access group.
I've tried using a clean install of CQ5.6.1 with geometrixx - it doesn't work either.
I've tried this from a server and from a localhost/dev machine with the same results. No proxy. I've even tried using the shared secret as the password but then it doesn't connect at all, and fails on the configuration screen.
What might cause this to fail?
If it doesn't work with a fresh install and Geometrixx, then it's probably an Adobe bug. That's typically the first thing support will ask you about.
I would also verify using Geometrixx Outdoors, or a more recent demo site, on your fresh install, just to ensure it's not an outdated ClientLib issue.
I know this isn't a direct answer to your question, but honestly, I would approach the integration differently. I've worked with the AEM-SC framework and it's buggy at best. It's very finicky, it doesn't REALLY work the way the documentation claims, and it requires that you're very specific about what Clientlibs are on the page.
Moving forward, I think using Adobe Dynamic Tag Manager is the better approach, for many reasons. My understanding is that it's Adobe's recommendation as well. I'd consider moving to that. In AEM 5.6.1, you'll have to customize your integration with DTM, but it's not very hard.
Solution: Add a property on the configuration node for sitecatalyst: (eg. /etc/cloudservices/sitecatalyst/my-sc-configuration)
server=https://api.omniture.com/admin/1.2/rest/
it also seems to work with newer API versions such as https://api3.omniture.com/admin/1.3/rest/
It would appear that for 5.6.1 it ignores the OSGi configuration, at least for the configuration screens. With this extra property, the framework page loads without error and allows selection of the RSID.
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 have a GWT app deployed onto our client's machines. As an ongoing
development alongside, we have to release new improved versions of the
application fron time to time. Everytime we release a new version we
often run into the problem where the client's browser has cached the
old scripts scriptsand for a while it behaves strangly as the data it
is trying to work with is not quite compatible with it. What is the
best way to overcome this problem. Currently I have to tell the users
to clear their browser's cache for a new release but it would be nice
they don't have to do this.
Possible solution depends on the way you are hosting your application. If you are hosting directly from servlet container, then you can use servlet filter like the one described here:
http://seewah.blogspot.com/2009/02/gwt-tips-2-nocachejs-getting-cached-in.html
Here are appropriate filters from tadedon library:
http://code.google.com/p/tadedon/source/browse/tadedon-servlet/src/main/java/com/xemantic/tadedon/servlet/CacheDisablingFilter.java
http://code.google.com/p/tadedon/source/browse/tadedon-servlet/src/main/java/com/xemantic/tadedon/servlet/CacheForcingFilter.java
And here is guice ServletModule which enables them for the whole guice web application:
http://code.google.com/p/tadedon/source/browse/tadedon-gwt/src/main/java/com/xemantic/tadedon/gwt/http/GwtHttpCachingModule.java
If you are using some reverse proxy in front of tomcat it would be even simpler. In case of apache (e.g. mod_proxy, mod_jk), and assuming that all the application resources (html, graphics, java scripts, css, etc.) are put on apache, just set these options in apache configuration:
<Files *.nocache.*>
ExpiresDefault "access"
</Files>
<Files *.cache.*>
ExpiresDefault "now plus 1 year"
</Files>
It is described here:
http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html
in "Perfect Caching" section. Such deployment scenario assumes that only rpc requests should go through reverse proxy to tomcat. If for some reasons all the application context is proxied to tomcat you can still use apache's LocationMatch directive instead of Files directive.
By default, the bulk of your app should be cached by the browser until a new version of it is generated by your build process.
It might help to understand the GWT bootstrapping model to understand how this works.
The first script your client requests, your-app-name.nocache.js, is not cached, and it does nothing except check the browser's user agent and capabilities, and make a second request for the relevant app JS.
At this point, the script it requests should be cached by the browser if it's been requested before. This is a {indistinguisable-numbers-and-letters}.cache.html file.
When you redeploy your app, the nocache.js file will be executed and ask for a different cache.html file from the server, which will not already be present in the cache, but which will get cached by the browser once it is downloaded.
Are you doing anything unusual with deferred binding, or with caching headers on your server? This might potentially be causing your nocache.js file to get cached after all, which would make it request old cache.htmls from the browser cache.
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.