You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wookie.apache.org by bu...@apache.org on 2012/09/21 11:32:25 UTC

svn commit: r832673 - in /websites/staging/wookie/trunk/content: ./ wookie/docs/faq.html

Author: buildbot
Date: Fri Sep 21 09:32:25 2012
New Revision: 832673

Log:
Staging update by buildbot for wookie

Modified:
    websites/staging/wookie/trunk/content/   (props changed)
    websites/staging/wookie/trunk/content/wookie/docs/faq.html

Propchange: websites/staging/wookie/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Sep 21 09:32:25 2012
@@ -1 +1 @@
-1358249
+1388388

Modified: websites/staging/wookie/trunk/content/wookie/docs/faq.html
==============================================================================
--- websites/staging/wookie/trunk/content/wookie/docs/faq.html (original)
+++ websites/staging/wookie/trunk/content/wookie/docs/faq.html Fri Sep 21 09:32:25 2012
@@ -64,6 +64,7 @@
 <li><a href="/wookie/docs/developer/features.html">Extension Features</a></li>
 <li><a href="/wookie/docs/developer/widgets.html">Deploying Widgets</a></li>
 <li><a href="/wookie/docs/develop.html">Environment</a></li>
+<li><a href="/wookie/docs/developer/release-management.html">Release Management</a></li>
 <li><a href="/wookie/docs/developer/issues.html">Issue Tracker</a></li>
 <li><a href="/wookie/docs/developer/index.html">Management</a></li>
 <li><a href="/wookie/docs/developer/parser.html">W3C Widget Parser</a></li>
@@ -78,7 +79,7 @@
   </div>
 
   <div id="content">
-    <h1 id="how_do_widgets_in_wookie_get_around_same-origin_restrictions_for_ajax_requests">How do widgets in Wookie get around same-origin restrictions for Ajax requests?</h1>
+    <h1 id="how-do-widgets-in-wookie-get-around-same-origin-restrictions-for-ajax-requests">How do widgets in Wookie get around same-origin restrictions for Ajax requests?</h1>
 <p>The Widget javascript object available to running widgets has a <code>proxify()</code> method for just this purpose. Proxify wraps the request in a call to a proxy server.</p>
 <p>So: </p>
 <p><code>widget.proxify("http://example.org/myservice/")</code> </p>
@@ -88,15 +89,15 @@
 <p>Wookie lets you use either; see the <em>widgetserver.properties</em> configuration file. This  contains instructions for specifying either no proxy, the Wookie service, or the Shindig one (assuming its available).</p>
 <p>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 and using W3C WARP.</p>
 <p>Note: as widget.proxify() is not part of the W3C Widget Interface specification, to make your widget work properly in other W3C Widget engines you should always  check the function exists before trying to call it.</p>
-<h1 id="how_does_localization_work_in_wookie">How does localization work in Wookie?</h1>
+<h1 id="how-does-localization-work-in-wookie">How does localization work in Wookie?</h1>
 <p>Wookie implements the localization model described in the <a href="http://www.w3.org/TR/widgets/#internationalization-and-localization">W3C Widgets: Packaging and Configuration</a> 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 <a href="http://site.icu-project.org/">ICU4J</a> for all locale processing, including locating system defaults.</p>
-<h1 id="when_i_run_wookie_in_tomcat_i_get_a_javasecurityaccesscontrolexception_access_denied_javautilpropertypermission_userdir_read">When I run Wookie in Tomcat I get a "java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read)"</h1>
+<h1 id="when-i-run-wookie-in-tomcat-i-get-a-javasecurityaccesscontrolexception-access-denied-javautilpropertypermission-userdir-read">When I run Wookie in Tomcat I get a "java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read)"</h1>
 <p>This problem occurs when the security manager is enabled in Tomcat, but without the proper permission assigned for Wookie. There is documentation that can help you define the security policy properly in section on <a href="developer/running.html#running_wookie_with_a_security_manager">Running Wookie</a>.</p>
-<h1 id="wookie_throws_a_javalangnosuchmethoderrorjavaxservletservletcontextgetcontextpath_exception_when_i_try_to_load_a_widget">Wookie throws a "java.lang.NoSuchMethodError:javax.servlet.ServletContext.getContextPath()" exception when I try to load a widget</h1>
+<h1 id="wookie-throws-a-javalangnosuchmethoderrorjavaxservletservletcontextgetcontextpath-exception-when-i-try-to-load-a-widget">Wookie throws a "java.lang.NoSuchMethodError:javax.servlet.ServletContext.getContextPath()" exception when I try to load a widget</h1>
 <p>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 <a href="https://issues.apache.org/jira/browse/WOOKIE-105">Issue WOOKIE-105</a> for more information</p>
-<h1 id="why_cant_i_add_any_widgets_either_through_the_admin_interface_or_by_dropping_them_into_the_deploy_folder">Why can't I add any widgets, either through the admin interface or by dropping them into the deploy folder?</h1>
+<h1 id="why-cant-i-add-any-widgets-either-through-the-admin-interface-or-by-dropping-them-into-the-deploy-folder">Why can't I add any widgets, either through the admin interface or by dropping them into the deploy folder?</h1>
 <p>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.</p>
-<h1 id="my_widgets_do_not_seem_to_be_updating_the_preference_data_in_wookie">My widgets do not seem to be updating the preference data in wookie</h1>
+<h1 id="my-widgets-do-not-seem-to-be-updating-the-preference-data-in-wookie">My widgets do not seem to be updating the preference data in wookie</h1>
 <p>This is a known issue. See <a href="https://issues.apache.org/jira/browse/WOOKIE-44">Issue WOOKIE-44</a> for more information. This problem typically occurs when using Internet Explorer (version 8 and less).  It is only flagged here as a warning because depending on how the widget calls the widget javascript API, you may or may not encounter a problem.  In essence there are two ways of setting a preference in your widgets javascript implementation...</p>
 <p>(1) widget.preferences.setItem("foo", "bar");
 (2) widget.preferences.foo = "bar";</p>
@@ -106,9 +107,9 @@
 OR
 (2) install Internet Explorer version 9, which should resolve the problem.</p>
 <p>Other browsers should be unaffected by this issue.</p>
-<h1 id="why_when_i_update_my_widget_and_load_it_back_onto_wookie_do_i_get_two_copies_of_my_widget_in_the_gallery">Why when I update my widget and load it back onto wookie do I get two copies of my widget in the gallery?</h1>
+<h1 id="why-when-i-update-my-widget-and-load-it-back-onto-wookie-do-i-get-two-copies-of-my-widget-in-the-gallery">Why when I update my widget and load it back onto wookie do I get two copies of my widget in the gallery?</h1>
 <p>If your widget does not have an id defined in the widget's config.xml file or the id is not a valid URI then wookie will load but not update your widget.&nbsp; If this is the case then (for the moment) you will need to manually remove the old version of the widget using wookie's admin page.</p>
-<h1 id="why_do_i_get_a_dialog_box_saying_session_error_when_i_try_to_view_my_widget">Why do I get a dialog box saying "session error" when I try to view my widget?</h1>
+<h1 id="why-do-i-get-a-dialog-box-saying-session-error-when-i-try-to-view-my-widget">Why do I get a dialog box saying "session error" when I try to view my widget?</h1>
 <p>There is a known issue when using Tomcat 7.* with Wookie (see <a href="https://issues.apache.org/jira/browse/WOOKIE-222">WOOKIE-222</a>). Sometimes when a widget is actually loaded, a browser alert box sometimes appears informing the user of a "Session Error". </p>
 <p>This is caused by the DWR library used by Wookie for Comet-based widgets handling HTTP-only cookies incorrectly;  Tomcat 7 uses HTTP-only cookies as the default setting to prevent cross-site scripting (XSS) attacks.</p>
 <p>A workaround is to add the following to the WEB-INF/web.xml file</p>
@@ -120,9 +121,16 @@ OR
 
 
 <p>Note that XSS prevention will still be in place in Tomcat 7; this just disables the additional mechanism implemented in DWR that conflicts with it.</p>
-<p>This is an issue for DWR 2.<em> with Tomcat 7.</em> (or earlier versions of Tomcat where useHttpOnly="true" is set.)             <br />
-</p>
-<h1 id="can_i_run_wookie_from_a_usb_drive">Can I run Wookie from a USB drive?</h1>
+<p>This is an issue for DWR 2.<em> with Tomcat 7.</em> (or earlier versions of Tomcat where useHttpOnly="true" is set.)</p>
+<p>To set this to false for tomcat 7 you can add this to the context definition for wookie.
+This is found in</p>
+<p>TOMCAT-ROOT/conf/Catalina/localhost/wookie.xml</p>
+<p>The first line of xml needs to look like this</p>
+<div class="codehilite"><pre><span class="o">&lt;</span><span class="n">Context</span> <span class="n">crossContext</span><span class="o">=</span><span class="s">&quot;true&quot;</span> <span class="n">useHttpOnly</span><span class="o">=</span><span class="s">&quot;false&quot;</span><span class="o">&gt;</span>
+</pre></div>
+
+
+<h1 id="can-i-run-wookie-from-a-usb-drive">Can I run Wookie from a USB drive?</h1>
 <p>Yes, more information can be found <a href="portable.html">here</a>.</p>
   </div>