FAQ

How do widgets in Wookie get around same-origin restrictions for Ajax requests?

The Widget javascript object available to running widgets has a proxify() method for just this purpose. Proxify wraps the request in a call to a proxy server.

So proxify("http://example.org/myservice/") results in a URL like http://my.wookie.org/proxy?url=http://example.org/myservice/&api_key=myapikey

Shindig also uses the same method for OpenSocial applications, and has its own bundled proxy service.

Wookie lets you use either; see the widgetserver.properties configuration file. This contains instructions for specifying either no proxy, the Wookie service, or the Shindig one (assuming its available).

Wookie's bundled proxy servlet is a bit stricter than the one bundled in Shindig, as it only allows text, xml or json (not binary), and can also be controlled using a whitelist set up by the Wookie administrator.

How does localization work in Wookie?

Wookie implements the localization model described in the W3C Widgets: Packaging and Configuration specification. This means that Widgets contain "locale" folders for specific locales (eg. "/locales/et/index.html"), and Wookie will serve resources in matching locale folders in preference to generic resources. Wookie uses the 'locale' parameter of a request for a new widget as the preferred locale for resource requests; if this is absent then Wookie uses the server's default locale as picked up through system settings. We use ICU4J for all locale processing, including locating system defaults.

Wookie messed up my widget's <script> tags when I imported it! What happened?

Wookie uses HtmlCleaner to inject its own script tags into your Widget's start file when it is uploaded. This works fine in most cases; however if you use self-closing script tags things can go wrong. To avoid this always use regular HTML-style script tags e.g <script src="main.js"></script> and not <scripr src="main.js"/>. See Issue WOOKIE-42 for more information.

When I run Wookie in Tomcat I get a "java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read)"

This problem occurs when the security manager is enabled in Tomcat, but without the proper permission assigned for Wookie. There is a How-To that can help you define the security policy properly.

Wookie installs fine in Tomcat, but when I try to see it I get "org.hibernate.HibernateException: flush is not valid without active transaction"

This problem occurs when running Tomcat with Security Manager enabled, but without having granted permissions for Wookie to access the database server. For development purposes its better to just run Tomcat without Security Manager enabled; otherwise you need to edit your catalina.policy file as described in the Tomcat Security Manager How-To.

Wookie throws a "java.lang.NoSuchMethodError:javax.servlet.ServletContext.getContextPath()" exception when I try to load a widget

This problem occurs in version of Apache Tomcat that do not support the current Servlet specification; to avoid this error update to Tomcat 6.0 or higher. See Issue WOOKIE-105 for more information

I shut down my Wookie and now when I try to run it I get an error. How do I run it again?

Whenever you execute the ant run command to run Wookie in standalone (developer) mode, the database is recreated. This means that if you stop and re-run Wookie you'll get an error message. To avoid this problem use ant clean-db run instead.

Why can't I add any widgets, either through the admin interface or by dropping them into the deploy folder?

One of the most common reasons for this is that the application doesn't have permission to write to the wookie/wservices directory, which is where Wookie expands widgets when they are uploaded. For example, if you are deploying Wookie on Tomcat, make sure webapps/wookie is owned by the tomcat user and not by root.