I’d like to avoid embedding my vaadin app in an iframe if at all possible.
The problem I’m running into is my vaadin app and the standard web app i’d like to embed it in are running on different servers, well actually, same server, different ports, but that’s one in the same.
So when I try to reference, say, localhost with a different port number from the web page that gets rejected by the browser cause of the cross domain javascript calls.
I tried putting a simple proxy/redirect servlet into the webapp that will take any request for /v/* and forward it onto vaadin (stripping the /v/ first).
This almost works. If I inspect the page in chrome, everything seems to have come across in tact, all the javascript files reference in the widget set, even the widgetset javascript itself. It’s just that nothing else is ever embedded in the page, the div w/ the id specified in the vaadin configuration remains empty no matter what i do.
Any suggestions for workarounds or remedies are much appreciated.
I’ll give this a shot (although the descriptions seem to be out of date – jar files & class name don’t match).
Any ideas on when this will be a ‘final’ release? The application I’m working on will be a production application, and I’m not keen on using code that’s not ready to go or even supported.
I spoke too soon, the build posted on that page does not seem to work:
[09:16:10.412]
javax.servlet.ServletException: java.lang.NullPointerException
[09:16:10.412]
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.handleServiceException(AbstractApplicationServlet.java:969)
[09:16:10.412]
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:530)
[09:16:10.412]
at org.vaadin.jsonp.server.ApplicationServlet.service(ApplicationServlet.java:60)
[09:16:10.412]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
[09:16:10.412]
at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[09:16:10.412]
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
[09:16:10.412]
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:241)
[09:16:10.412]
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:268)
[09:16:10.412]
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:586)
[09:16:10.412]
at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:690)
[09:16:10.412]
at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:612)
[09:16:10.412]
at java.lang.Thread.run(Thread.java:680)
[09:16:10.412]
Caused by: java.lang.NullPointerException
[09:16:10.412]
at org.vaadin.jsonp.server.ApplicationServlet.isSameReferer(ApplicationServlet.java:260)
[09:16:10.412]
at org.vaadin.jsonp.server.ApplicationServlet.getExistingApplication(ApplicationServlet.java:234)
[09:16:10.412]
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.findApplicationInstance(AbstractApplicationServlet.java:743)
[09:16:10.412]
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:438)
[09:16:10.412]
... 10 more
This also has the nasty side effect of forcing the page containing (or attempting to contain) the vaadin application to reloading every couple seconds. So unless the user is quick to navigate away from the page, they’re stuck in an endless loop of reloads.
Curious if anyone besides the dev team is using this add-on?
Don’t use the VJSONP version. Refer to README file more than the IMPLEMENTATION_NOTES, which is from VSJONP era. It was a proof of concept version of the idea. Try either building the addon from SVN (maven project), or use this jar from here: http://dl.dropbox.com/u/4041822/vaadin-xs-0.0.1-SNAPSHOT.jar
I uploaded it there for eager tester who don’t master maven.
I guess nobody else, but me has actually tested the addon at this point. And that is the reason why it is not yet available in the Directory. I have eagerly tried to find someone to test it from Vaadin Ltd, but I guess none of our projects needs this kind of feature. So I’m more than happy if you dare to try it and share experiences. You can get support straight from me in case you face some issues.
Cool, I’ll give that version a shot, I appreciate the update.
I’m happy to be a guinea pig for you as this is a feature that we need to support any realistic production deployment of this type of integration, so if I can help push it forward by testing, I’m happy to do so.
Does not work in Firefox 3.5.5, the little loading icon comes up for a second, but then it display a blank area. I did a view of the generated source, and it looks like some of the page layout is there, but I could not find any of the actual widgets for the application. But there are no errors shown in the servlet container logs that would indicate any issues. Just a completely blank application.
Seems to work ok in Safari 9 and Chrome 8. I use the contextmenu plugin from the addins directory, and it does a really poor job with that. The placement of the menu is different by 50-100 pixels (diagonally down and to the right) – it is normally placed at the point of the mouse click. It also is not correctly synced with its drop shadow, which appears to be off diagonally by about the same amount.
Also, with the context menu, in Safari, it will stay open after the user clicks on an item in the menu. This does not happen when the application runs normally.
I am also having some troubles with detecting double clicks in the app, trying to isolate if that’s recent change to my codebase or something to do w/ the integration into the web page.
Also, if i have the developer console open with chrome, every click seems to trigger a breakpoint in pgp.js. No idea how or why, and seems to be a chrome only thing. afaik Safari’s web inspector is the same thing and it does not seem to display this behavior.
Also, it seems to not work stand-alone. Using chrome or safari, things are ok, but if i go directly to the app i get this:
[13:41:25.610]
java.lang.NullPointerException
[13:41:25.610]
at com.vaadin.addons.xs.server.XSApplicationServlet.service(XSApplicationServlet.java:84)
[13:41:25.610]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
[13:41:25.610]
at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[13:41:25.610]
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
[13:41:25.610]
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:241)
[13:41:25.610]
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:268)
[13:41:25.610]
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:586)
[13:41:25.610]
at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:690)
[13:41:25.610]
at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:612)
[13:41:25.610]
at java.lang.Thread.run(Thread.java:680)
If guess I fixed the null pointer issue and one obsolete debugger call in the javascript file. But I’m afraid it is neither of those that cause the essential Firefox issue. First, is there a reason why you are using firefox 3.5.5? FF is going in 3.6.13 atm. With that my test app worked fine, I didn’t hunt for a non supported FF version. Does this page work for you?
If it doesn’t it is probably an issue with old FF or some settings in your FF profile. If it works we need to check what’s wrong with your setup.
The context menu issue seems like a bug in the addon itself. Probably an issue in portal and standard (same origin) embedding too. It is not a supported addon so I wont rush fixing it. To get it fixed you have tree viable options:
buy a vaadin expert to fix it via Pro tab on this site
beg the addon developer to fix it
fix it yourself and post patch to the original developer
I noticed that it does not work in FF 3.5.5 because I was testing on all the browsers on my system, IE aside since I’m not running windows, I have multiple versions of each browser for conducting tests.
As for the context menu, is there something in Vaadin core I can use instead?
Ok you are really taking testing seriously. And your own installation works also with the latest FF version? If so, I’m afraid we’ll leave the issue as it is. FF4 should be released quite soon too and at least at that point 3.5.x FF is ancient.
The core Vaadin supports context menu in Tree and Table only.
PS. In case you are not not building your vaadin-xs jar from svn, I updated the jar in the dropbox location advertised earlier in this thread.
Ok, I’m just getting back to this after a detour onto another project. The file in the dropbox does not seem to exist anymore, what’s the pointer to SVN? I"ll just build it from the source, that’s probably easier.
Actually, I managed to find it, but its unclear to me how to build it, I’m not a maven user, so it might be something obvious that I’m missing, but trying some different mvn targets does not seem to work. Can you give me a hint? =)
I decided it was probably easier to just embed the code in my application as I might need to make some changes.
I’m seeing this exception upon calling getEmbedJs:
[11:31:54.277]
java.lang.NullPointerException
[11:31:54.277]
at com.vaadin.Application.getPropertyNames(Application.java:690)
[11:31:54.277]
at com.clarkparsia.sextant.ui.Sextant.getProperties(Sextant.java:537)
[11:31:54.277]
at com.clarkparsia.sextant.ui.Sextant.init(Sextant.java:249)
[11:31:54.277]
at com.vaadin.addons.xs.server.XSApplicationServlet.getSharedFakeApplication(XSApplicationServlet.java:584)
[11:31:54.277]
at com.vaadin.addons.xs.server.XSApplicationServlet.getApplicationForWritingHtmlSnippet(XSApplicationServlet.java:565)
[11:31:54.277]
at com.vaadin.addons.xs.server.XSApplicationServlet.getEmbedJs(XSApplicationServlet.java:181)
[11:31:54.277]
at com.vaadin.addons.xs.server.XSApplicationServlet.service(XSApplicationServlet.java:95)
[11:31:54.277]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
[11:31:54.277]
at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[11:31:54.277]
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
[11:31:54.277]
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:241)
[11:31:54.277]
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:268)
[11:31:54.277]
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:586)
[11:31:54.277]
at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:690)
[11:31:54.277]
at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:612)
[11:31:54.277]
at java.lang.Thread.run(Thread.java:680)
Looking at Application.java:690, properties is obviously null. It appears to be set in the start() method – I’m assuming this is called as my app’s init method is called and that is invoked from start, but the properties that are passed in are null.
I noticed in getSharedFakeApplication you call init directly without calling start, so the internal state of the application, properties included, is not set. I changed the method to call start and pass in the required information, the code for the updated method is below.
One thing is I had to re-create the applicationProperties because its private in Application and I did not want to fork the core just for that change. You might consider making that protected or adding an accessor to make this a little cleaner. Furthermore, the default properties in an Application should probably be an empty set of Properties rather than a null object so you don’t end up with nasty NPE’s, but that’s my two cents.
private synchronized Application getSharedFakeApplication(HttpServletRequest request) throws ServletException {
if (sharedApp == null) {
sharedApp = getNewApplication(request);
Properties props = new Properties();
for (final Enumeration<String> e = getServletConfig().getInitParameterNames(); e.hasMoreElements();) {
final String name = e.nextElement();
props.setProperty(name, getServletConfig().getInitParameter(name));
}
// Overrides with server.xml parameters
final ServletContext context = getServletConfig().getServletContext();
for (final Enumeration<String> e = context.getInitParameterNames(); e.hasMoreElements();) {
final String name = e.nextElement();
props.setProperty(name, context.getInitParameter(name));
}
try {
sharedApp.start(getApplicationUrl(request), props, getApplicationContext(request.getSession(true)));
}
catch (MalformedURLException e) {
throw new ServletException(e);
}
}
return sharedApp;
}