jspwiki-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ajaqu...@apache.org
Subject svn commit: r630396 - in /incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc: Java 5 changes LICENSE.Stripes.txt LICENSE.cos
Date Sat, 23 Feb 2008 06:44:18 GMT
Author: ajaquith
Date: Fri Feb 22 22:44:17 2008
New Revision: 630396

URL: http://svn.apache.org/viewvc?rev=630396&view=rev
Log: (empty)

    incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/Java 5 changes

Added: incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/Java 5 changes
URL: http://svn.apache.org/viewvc/incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/Java%205%20changes?rev=630396&view=auto
--- incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/Java 5 changes (added)
+++ incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/Java 5 changes Fri Feb 22 22:44:17
@@ -0,0 +1,347 @@
+Eclipse... Software Update
+New Remote Site: 
+Name: Findbugs
+URL: http://findbugs.cs.umd.edu/eclipse
+Name: CheckStyle Eclipse Plug-in
+URL: http://eclipse-cs.sourceforge.net/update
+Class Hierarchy
+WikiContext is the all-singing, all-dancing "request context" class in JSPWiki. It encapsulates
the idea of "doing a wiki activity": viewing a page, editing a group, commenting, etc. In
Stripes parlance, these are what you'd call "ActionBeans."
+WikiContext was originally conceived to encompass everything and everything you might want
to do to a wiki page. In JSPWiki 2.4 and higher, WikiContext got overloaded with lots of activities
that have nothing to do with pages, like creating groups and registering. 
+It has been clear for a while that WikiContext needed to split itself into multiple classes
and interfaces. The most logical thing to do is make WikiContext the general class or interface
actions that deal exclusively with pages. Therefore: WikiContext becomes an abstract subclass
of AbstractActionBean. 
+Note that because WikiContext becomes abstract, we need to change all of the direct instantiations
of WikiContext. So, what I've done is created a WikiContext subclass (a Stripes ActionBean,
in fact) called ViewActionBean that is for the "view page" context. 
+The new class hierarchy for WikiContext and related types, for 3.0, looks like this:
+    WikiActionBean extends ActionBean [Stripes]
+    AbstractActionBean implements WikiActionBean
+     |
+     +--WikiContext extends AbstractActionBean
+     |   |
+     |   +--ViewActionBean extends WikiContext
+     |   +--EditActionBean extends WikiContext
+    ... ... ...
+     +--GroupActionBean extends AbstractActionBean
+     |
+     +--UserPreferencesActionBean extends AbstractActionBean
+    ...     
+[NOTE: it would be nice if we could deprecate "WikiContext" in favor of, for example, "PageActionBean"
to clearly denote that it's about page activities. Maybe PageActionBean becomes the interface,
and we start coding to that...]
+The new class structure means that techniques for creating WikiContexts will change. Old
instantiations of WikiContext looked like this:
+WikiContext dummyContext = new WikiContext( m_engine, m_context.getPage() );
+WikiContext dummyContext = new WikiActionBean( m_engine, m_context.getPage() );
+In 3.0, if you want to create a new ViewActionBean you can do it via the zero-arg constructor
[WikiContext context = new ViewActionBean()] -- although you must immedidately also call setActionBeanContext()
and set the ActionBeanContext's WikiEngine reference. It's much easier, instead, to call the
factory method WikiActionBeanFactory.newActionBean( WikiPage page), which does it for you
(see below).
+Other significant changes to WikiContext:
+- The setRequestContext() method disappears (it was only used in like 5 places anyway), because
the WikiContext subclasses *are* the contexts. getReqeustContext() merely looks up a special
JSPWiki class-level annotation that specifies the context. (For example: @WikiRequestContext("view"))
+- WikiContext.getCommand() goes away, as do the other Command-related methods. Command interface
is eliminated. It was a pretty dodgy idea to begin with.
+- getLocale(). Not used in JSPs or core code. Because Stripes takes care of a lot of this,
it's not needed.
+- hasAccess()/requiredPermission(). This are handled by our own Stripes interceptor/controller
(WikiInterceptor) in combination with event-level annotations. So these methods should absolutely
be eliminated.
+WikiActionBean Security
+In 2.4, security permissions were added to WikiContexts. Each WikiContext could specify what
Permission a user needed to access that context by causing the method requiredPermission()
to return a value. This worked well, although it required each WikiContext type ("view","edit"
etc.) to figure out a way to express the Permission through code. This, in part, was what
let to the disaster that is the Command class.
+In 3.0, Permissions are much more flexible because they are annotation-driven. Moreover,
they are specified at the method level, NOT at the class (WikiContext) level. Because WikiContext
(and its subclasses) implement ActionBean, this is another way of saying, "Permissions annotate
methods that do things." For example, consider ViewActionBean, which is a WikiContext subclass
that displays a wiki page. Its default event is the "view()" method, which simply forwards
control to itself and causes the page to display. Here's the method signature:
+    @DefaultHandler
+    @HandlesEvent("view")
+    @EventPermission(permissionClass=PagePermission.class, target="${page.qualifiedName}",
+    public Resolution view() { ... }
+Note the @EventPermission annotation. It defines the Permission class and its target and
actions. The "permissionClass" attribute tells use that the Permission class this method needs
is "PagePermission". Note also the JSTL-style syntax in the target and actions attributes
-- these allow JSTL-access to bean properties for the instantiated ViewActionBean. In this
case, "page" is the bean attribute that returns the value of this ViewActionBean's getPage()
method. The nested syntax "page.qualifiedName" is equivalent to getPage().getQualifiedName().
Neat, huh?
+Switching to Stripes for URL building (via URLBuilder) causes UTF-8 strings to be created
by the getURL methods:
+<a class="wikipage" href="/Wiki.jsp?page=%C4itiSy%F6%D6ljy%E4">ÄitiSyöÖljyä</a>
+<a class="wikipage" href="/Wiki.jsp?page=%C3%84itiSy%C3%B6%C3%96ljy%C3%A4">ÄitiSyöÖljyä</a>
+Migration to Stripes tags:
+stripes:form. must change accept-charset to acceptcharset
+WikiTagBase extents StripesTagSupport in 3.0, not TagSupport. That means we needed to create
a few methods that are in TagSupport but aren't in StripesTagSupport. Easily done...
+Also, the method TagSupport.findAncestorWithClass which is used by TabTag needs to be replaced
by StripesTagSupport.getParentTag (without need for classcast).
+Thoughts on URLConstructor
+Looks like we could rewrite everything!
+For inbound requests: if UrlRewrite is the first servlet filter it will translate correctly
coming in. Thus: /wiki/Page1 might forward to /wiki/Wiki.jsp?page=Page1. 
+For outbound responses: UrlRewrite needs to be the last thing that manipulates the URL. For
outbound URLs, you can generate a useful URL by calling HttpServletResponse.encodeURL(String),
where the parameter is the URL you want to re-write. 
+    --> Note: this means WikiServlet goes away (the destroy logic goes to WikiServletFilter
for now)
+Making things a little tricker: Stripes Resolutions also generate their own URLS. This is
done by creating a new RedirectResolution(WikiActionBean), where the WikiActionBean is the
"url" you want to redirect to. Add parameters as necessary. 
+To tie all of this together:
+Some classes currently call the URLConstructor directly. Mostly, this is WikiContext and
WikiEngine (about 22 references in the JSPWiki core classes, plus 2 in the JSPs). However,
most classes get their URLs by calling WikiContext.getViewURL(), getRedirectURL(), and getURL()/getURL()
-- 73 references within the core, and 23 references in the templates. These probably should
not be changed for compatibility's sake. However, we could easily cause these WikiContext/WikiEngine
references to URLContructor instead to use Resolution.getURL + response.encodeURL().
+Thus: to get a proper URL from inside a method that takes a WikiContext we'd do this: 
+// Create a new resolution and add the page parameter to it
+Resolution resolution = new RedirectResolution(ViewActionBean.class);
+resolution.addParameter("page", page.getName();
+// Get the response from the WikiContext (its superclass returns the ActionBeanContext, which
has it)
+HttpServletResponse response = context.getContext().getResponse();
+// Now, encode the URL (passing it up the chain until it hits the UrlRewrite filter)
+String url = response.encodeURL( resolution.getURL() );
+A better example, this time with UrlBuilder:
+            // Make Stripes URL
+            String groupUrl = ViewGroupActionBean.class.getAnnotation(UrlBinding.class).value();
+            UrlBuilder urlBuilder = new UrlBuilder(  groupUrl, true );
+            urlBuilder.addParameter("group", name);
+            String url = urlBuilder.toString();
+            // Make re-written URL
+            String rewriteUrl = context.getContext().getResponse().encodeURL( url );
+--> Note: this means we need to replace WikiEngine.getURL() calls with equivalent calls
to UrlBuilder + response.encodeUrl() 
+WikiEngine.getURL goes away completely. Now, we need to get the ActionBeanContext in order
to generate an URL.
+ContentTemplates, JSPs, URLPatterns and RequestContexts
+In 2.4 we welded ContentTemplates, JSPs and RequestContexts together in the Command class.
This helped unify some things, but it really doesn't fit in with Stripes all that well. Frankly,
specifying a content template is really in the domain of JSP markup, and shouldn't be in classes.
The URLPatterns are there because we need them for the URLConstructor. But if we delegate
URL construction to Stripes and UrlRewrite, then we don't need this anymore. RequestContexts
are still useful because we need to look up ActionBeans (e.g., WikiContexts) that way. We
should still allow them, but deprecate them.
+General behaviors need to change in the JSP layer so that instead of looking up a URL and
then calling redirect directly, we need instead to obtain RedirectResolutions.
+Stashing variables in PageContexts
+WikiTagBase chokes hard when it can't find a WikiContext associated with the the PageContext.
That's because there's an expectation that the top-level JSP will stash the right context.
In the new world WikiContexts are supplanted by ActionBeans. Do the page-specific tags need
guaranteed access to a WikiContext? Hmm.... how can we stick one in there upstream? Do we
name specific beans PAGE_BEAN, GROUP_BEAN, etc. or do push/pop operations
+Contract ought to be: top-level JSP *guarantees* that it will inject a WikiActionBean, with
a well-known name ACTIONBEAN ("wikiActionBean"), into request scope. WikiTagBase should first
look for the well-known ActionBean, then iterate through the stored attributes and grab the
first value it finds of type ActionBean. If an ActionBean can't be found, throw a WikiException.
(Like what we do now.)
+Thus: by convention, top-level JSPs MUST add a tag similar to this to the top of their pages
if they want the bean recognized later by WikiTagBase:
+<stripes:useActionBean beanclass="com.ecyrd.jspwiki.action.____ActionBean"/>
+The first JSP to to use the useActionBean class will, by definition, cause the ACTIONBEAN
request attribute to be set with this name binding. WikiTagBase's m_actionBean will obtain
this value. 
+Note: redefining m_context as m_actionBean (with type change to WikiActionBean) makes 32
out of 70 JSP tags fail to compile because they expect a getPage() method. We will need to
supply guidance on how to migrate tags. 
+In JSPs, the fact that the WikiActionBean for the page is bound as 'wikiActionBean' means
that JSTL markup can access this parameter directly. It also means that we can *probably*
get rid of the WikiContext.getContext() static method. In fact, we probably should. But for
now, it's best to leave it but redefine the return type so that it's a WikiActionBean. That
will break a few things.
+Dead Code
+WikiEngine.getRedirectURL(). Not used anywhere in the new code, and only once in the old
Wiki.jsp. Eliminated.
+WikiEngine.createContext(). Better to use WikiActionBeanFactory.find...
+WikiEngine.getSpecialPageReference(). Used exactly once, in NewBlogEntry.jsp. Eliminated.
+WikiTagBase now guarantees that the protected field m_page will be set if it's a WikiContext
This eliminates lots of classcasting.
+Things I haven't solved yet
+Stopwatch from Wiki.jsp
+WatchDog from Wiki.jsp
+API Changes
+VariableManager.getValue method sigs widened to WikiActionBean (from WikiContext to WikiActionBean)
+ContentTag's default content page is Beanclass name - "ActionBean" + "Content.jsp"
+Stripes ActionBeanContext wraps the request/response objects and provides information about
the servlet context. It is created anew for each request, I think. So it's not suitable for
"merging" with WikiSession.
+WikiContext getLocale(). Not used in JSPs or core code. Because Stripes takes care of a lot
of this, it's not needed.
+WikiContext hasAccess(). Really, this should be handled by the stripes interceptor/controller.
So these methods should absolutely be eliminated.
+WikiActionBean Contract
+WikiActionBeans are the core action class in JSPWiki 3.0. All WikiActionBeans are expected
to adhere to the following contract:
+- must have a zero-argument constructor
+- must set the ActionBeanContext immediately after instantiation (setContext)
+- must set the associated ActionBeanContext's WikiEngine immediately after instantiation
+WikiActionBeans can be created in four ways:
+1) Injection by UseActionBeanTag due to <stripes:useActionBean> tag in JSP. This is
the preferred way because it can be done with little effort, and only requires single line
at effort, and only requires single line at the top of a top-level JSP:
+<stripes:useActionBean beanclass="com.ecyrd.jspwiki.action.____ActionBean"/>
+Technically, the WikiActionBean is looked up by Stripes' configured ActionResolver (by default,
the AnnotatedClassActionResolver); the bean itself is instantiated using its zero-argument
constructor. Stripes guarantees that the following things happen after instantiation, as part
of its ActionBeanResolution lifecycle stage:
+- The WikiActionBean's setActionBeanContext() method is called (by AnnotatedClassActionResolver);
this causes a reference to a new WikiActionBeanContext to be set in the WikiActionBean
+- The WikiActionBeanContext's setServletContext() method is called (by UseActionBeanTag);
this sets an internal reference to the WikiEngine
+- The WikiActionBeanContext's setRequest/setResponse methods are called (by DefaultActionBeanContextFactory).
This will also retrieve and set a reference to the user's WikiSession
+Thus, when <stripes:useActionBean> is used in a JSP, the WikiActionBean in question
is guaranteed to have a non-null, valid WikiActionBeanContext associated with it. This WikiActionBeanContext,
in turn, is guaranteed to return non-null results for its getResponse/getRequest/getServletContext
methods, as well as its getWikiEngine and getWikiSession methods.
+2) Injection by DispatcherServlet due to POST/GET to /dispatcher, /action/* or *.action URLs.
This method appears to be used, in particular, by generated Stripes form elements. It is rare
that a user would actually specify one of these URLs directly.
+As with the previous method, the WikiActionBean is looked up by Stripes' configured ActionResolver.
The same guarantees apply: after resolution and instantiation, the WikiActionBean will have
a non-null, valid WikiActionBeanContext, and that the WikiActionBeanContext will return non-null
results for getResponse/getRequest/getServletContext/getWikiEngine/getWikiSession.
+In addition to these activities, in cases 1) and 2), after the ActionBeanResolution stage
completes, JSPWiki's custom WikiInterceptor executes. It will do two things:
+- Stash the resolved WikiActionBean into the HTTP request's ACTIONBEAN attribute (see above)
+- Check for proper access by calling the the bean's requiredPermission() method and checking
that the user has that permission (null means "allowed"). If not, a RedirectResolution is
returned that directs the user to the login page and appends all request parameters. (Note:
we should make it check for authentication; if the user is already logged in, it should redirect
to a "forbidden" page.
+These two techniques are the preferred ways to create WikiActionBeans. There are two other,
less preferred, ways:
+3) WikiActionBeanFactory.newActionBean(HttpServletRequest,HttpServletResponse,Class<?
extends WikiActionBean>).
+In this case, JSPWiki does things a little differently than how Stripes does it, but the
result is the same. Like Stripes, it will instantiate a new WikiActionBean and associate it
with a new WikiActionBeanContext.
+4) WikiActionBeanFactory.newActionBean( HttpServletRequest request, WikiPage page) and 
+WikiActionBeanFactory.newActionBean( WikiPage page).
+Both of these methods instantiate ViewActionBeans and associate a WikiActionContext with
the bean. The WikiActionContext's setWikiEngine and setServletContext methods are called after
instantiation. If an HttpServletRequest was supplied, it is associated with the WikiActionContext.
+Thus, when the createContext() methods are used, the resulting ViewActionBean is guaranteed
to have a non-null, valid WikiActionBeanContext associated with it. This WikiActionBeanContext,
in turn, is guaranteed to return non-null results for its getServletContext/getWikiEngine
methods. Its getRequest() method may or may not be null.
+WikiTagBase changes slightly to support Stripes. Instead of extending import javax.servlet.jsp.tagext.TagSupport,
it now extends StripesTagSupport. However, StripesTagSupport does not supply the methods setId/GetId.
So, we've had to implement these.
+newActionBean()  This method performs a similar role to the &lt;stripes:useActionBean&gt;
tag, in the sense that it will instantiate an arbitrary WikiActionBean class and, in the case
of WikiContext subclasses, bind a WikiPage to it. However, it lacks some of the capabilities
the JSP tag possesses. For example, although this method will correctly identity the page
requested by the user (by inspecting request parameters), it will not do anything special
if the page is a "special page." If special page resolution and redirection is required, use
the &lt;stripes:useActionBean&gt; JSP tag instead.
+Eclipse Tools Notes
+TestEngine: Because of its use of Stripes mock objects, TestEngine needs to be able to find
the various implementations provided in JSPWiki. Therefore, it is extremely sensitive to changes
in the build path. In particular, the mock servlet filter used by TestEngine hard-wires in
the relative location build for finding ActionBeans. This is the directory (relative to the
project root) that the Ant build scripts use for placing generated Java class files. The Eclipse
project configuration must configure itself the same way. To run unit tests in Eclipse, the
build directory absolutely must place generated class files in this directory, rather than
the Eclipse default of classes. If unit tests do not run in Eclipse for some reason, this
is the likeliest culprit.
+Use JVM args -Xmx1024m
+URL Rewriting
+Bugs Bugs Bugs
+This should be an <a class="attachment" href="/attach/Test/TestAtt.txt">attachment
link</a><a href="/PageInfo.jsp?page=Test/TestAtt.txt"><img src="/images/attachment_small.png"
border="0" alt="(info)" /></a>
+This should be an <a class="attachment" href="/attach/?page=Test/TestAtt.txt">attachment
link</a><a href="/PageInfo.jsp?page=Test/TestAtt.txt"><img src="/None.jsp?page=images/attachment_small.png"
border="0" alt="(info)" /></a>
+Solution: hacked WikiConext so that getUrl() special-cases the AttachActionBean and NoneActionBean
+<a class="createpage" href="/Edit.jsp?page=Foobar%202" title="Create &quot;Foobar
2&quot;">Foobar 2</a><br />
+<a class="createpage" href="/Edit.jsp?page=Foobar%202" title="Create &quot;Foobar
2&quot;">Foobar 2</a><br /><a class="createpage" href="/Edit.jsp?page=Page1000"
title="Create &quot;Page1000&quot;">Page 1000</a><br /><a class="createpage"
href="/Edit.jsp?page=Page1001" title="Create &quot;Page1001&quot;">Page 1001</a><br
/><a class="createpage" href="/Edit.jsp?page=Page1002" title="Create &quot;Page1002&quot;">Page
1002</a><br /><a class="createpage" href="/Edit.jsp?page=Page1003" title="Create
&quot;Page1003&quot;">Page 1003</a><br />
+Testing issues
+Both tests needed to be changed because Stripes encodes in UTF-8. 
+        Old value of 'page': %C4itiSy%F6%D6ljy%E4
+        New value: %C3%84itiSy%C3%B6%C3%96ljy%C3%A4
+        Old value of 'page': %C5%E4Test
+        New value: %C3%85%C3%A4Test
+Discovered Groups plugin has this line in it:
+String rewriteUrl = context.getContext().getResponse().encodeURL( url );
+...but the test ran without being in a MockServletContext. Thus, its parent WikiActionBeanContext
had no associated response! Plugin test should *always* test inside a mock object.
+Also, in TestEngine I had to override all of the getHTML methods so that the manufactured
WikiContext had properly injected requests and responses.
+GroupsPlugin right now does not generate Groups.jsp links, but Group.action links. Maybe
it should generate .jsp links?
+JSP Tier changes
+All of the non-top-level JSPs that shouldn't be directly instantiated are moved to /WEB-INF/jsp/layout.
+Some changes:
+JSPs don't need this any more:  <fmt:setBundle basename="templates.default"/>
+...because we set a context parameter in web.xml.
+Scriptlet code in JSPs that needs to obtain a reference to the WikiEngine can simply use
+Good practice: whenever useActionBean is used in a JSP, author should always set the 'var'
attribute so that downstream JSPs can use the variables.
+WikiInterceptor will attempt to set the current WikiActionBean and WikiPage into page scope.
These are available as ${wikiPage}. It will also set ${wikiEngine} and ${wikiSession}. These
are set in request scope.
+Migration: this means...
+  WikiContext c = WikiContext.findContext(pageContext);
+  WikiPage wikipage = c.getPage();
+...can simply be replaced by ${wikiPage}.
+BUG: LinkTag didn't always init its m_containedParameters map. (So, I fixed it...)
+2.6 commonheader.jsp
+	'JsonUrl' : '<%=  WikiContext.findContext(pageContext).getURL( WikiContext.NONE, "JSON-RPC"
) %>'
+	'JsonUrl' : 'JSON-RPC'
+JSP Locale Support
+Because Stripes automatically sets the locale, there is no need to use methods like this:
+LocaleSupport.getLocalizedMessage(pageContext, "attach.tab")
+Instead, you can simply use:
+<fmt:message key="attach.tab"/>
+Stripes layout system
+This is replaced:
+      <wiki:Content/>
+Scriptlet code (e.g., PageTab.jsp)
+	WikiContext c = WikiContext.findContext( pageContext );
+Replaced by
+	WikiContext c = (WikiContext)WikiInterceptor.findActionBean();
+Wiki:Tab needs to be able to evaluate attribute contents... now it doesn't...

Added: incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/LICENSE.Stripes.txt
URL: http://svn.apache.org/viewvc/incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/LICENSE.Stripes.txt?rev=630396&view=auto
--- incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/LICENSE.Stripes.txt (added)
+++ incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/LICENSE.Stripes.txt Fri Feb
22 22:44:17 2008
@@ -0,0 +1,176 @@
+                              Apache License
+                        Version 2.0, January 2004
+                     http://www.apache.org/licenses/
+1. Definitions.
+   "License" shall mean the terms and conditions for use, reproduction,
+   and distribution as defined by Sections 1 through 9 of this document.
+   "Licensor" shall mean the copyright owner or entity authorized by
+   the copyright owner that is granting the License.
+   "Legal Entity" shall mean the union of the acting entity and all
+   other entities that control, are controlled by, or are under common
+   control with that entity. For the purposes of this definition,
+   "control" means (i) the power, direct or indirect, to cause the
+   direction or management of such entity, whether by contract or
+   otherwise, or (ii) ownership of fifty percent (50%) or more of the
+   outstanding shares, or (iii) beneficial ownership of such entity.
+   "You" (or "Your") shall mean an individual or Legal Entity
+   exercising permissions granted by this License.
+   "Source" form shall mean the preferred form for making modifications,
+   including but not limited to software source code, documentation
+   source, and configuration files.
+   "Object" form shall mean any form resulting from mechanical
+   transformation or translation of a Source form, including but
+   not limited to compiled object code, generated documentation,
+   and conversions to other media types.
+   "Work" shall mean the work of authorship, whether in Source or
+   Object form, made available under the License, as indicated by a
+   copyright notice that is included in or attached to the work
+   (an example is provided in the Appendix below).
+   "Derivative Works" shall mean any work, whether in Source or Object
+   form, that is based on (or derived from) the Work and for which the
+   editorial revisions, annotations, elaborations, or other modifications
+   represent, as a whole, an original work of authorship. For the purposes
+   of this License, Derivative Works shall not include works that remain
+   separable from, or merely link (or bind by name) to the interfaces of,
+   the Work and Derivative Works thereof.
+   "Contribution" shall mean any work of authorship, including
+   the original version of the Work and any modifications or additions
+   to that Work or Derivative Works thereof, that is intentionally
+   submitted to Licensor for inclusion in the Work by the copyright owner
+   or by an individual or Legal Entity authorized to submit on behalf of
+   the copyright owner. For the purposes of this definition, "submitted"
+   means any form of electronic, verbal, or written communication sent
+   to the Licensor or its representatives, including but not limited to
+   communication on electronic mailing lists, source code control systems,
+   and issue tracking systems that are managed by, or on behalf of, the
+   Licensor for the purpose of discussing and improving the Work, but
+   excluding communication that is conspicuously marked or otherwise
+   designated in writing by the copyright owner as "Not a Contribution."
+   "Contributor" shall mean Licensor and any individual or Legal Entity
+   on behalf of whom a Contribution has been received by Licensor and
+   subsequently incorporated within the Work.
+2. Grant of Copyright License. Subject to the terms and conditions of
+   this License, each Contributor hereby grants to You a perpetual,
+   worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+   copyright license to reproduce, prepare Derivative Works of,
+   publicly display, publicly perform, sublicense, and distribute the
+   Work and such Derivative Works in Source or Object form.
+3. Grant of Patent License. Subject to the terms and conditions of
+   this License, each Contributor hereby grants to You a perpetual,
+   worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+   (except as stated in this section) patent license to make, have made,
+   use, offer to sell, sell, import, and otherwise transfer the Work,
+   where such license applies only to those patent claims licensable
+   by such Contributor that are necessarily infringed by their
+   Contribution(s) alone or by combination of their Contribution(s)
+   with the Work to which such Contribution(s) was submitted. If You
+   institute patent litigation against any entity (including a
+   cross-claim or counterclaim in a lawsuit) alleging that the Work
+   or a Contribution incorporated within the Work constitutes direct
+   or contributory patent infringement, then any patent licenses
+   granted to You under this License for that Work shall terminate
+   as of the date such litigation is filed.
+4. Redistribution. You may reproduce and distribute copies of the
+   Work or Derivative Works thereof in any medium, with or without
+   modifications, and in Source or Object form, provided that You
+   meet the following conditions:
+   (a) You must give any other recipients of the Work or
+       Derivative Works a copy of this License; and
+   (b) You must cause any modified files to carry prominent notices
+       stating that You changed the files; and
+   (c) You must retain, in the Source form of any Derivative Works
+       that You distribute, all copyright, patent, trademark, and
+       attribution notices from the Source form of the Work,
+       excluding those notices that do not pertain to any part of
+       the Derivative Works; and
+   (d) If the Work includes a "NOTICE" text file as part of its
+       distribution, then any Derivative Works that You distribute must
+       include a readable copy of the attribution notices contained
+       within such NOTICE file, excluding those notices that do not
+       pertain to any part of the Derivative Works, in at least one
+       of the following places: within a NOTICE text file distributed
+       as part of the Derivative Works; within the Source form or
+       documentation, if provided along with the Derivative Works; or,
+       within a display generated by the Derivative Works, if and
+       wherever such third-party notices normally appear. The contents
+       of the NOTICE file are for informational purposes only and
+       do not modify the License. You may add Your own attribution
+       notices within Derivative Works that You distribute, alongside
+       or as an addendum to the NOTICE text from the Work, provided
+       that such additional attribution notices cannot be construed
+       as modifying the License.
+   You may add Your own copyright statement to Your modifications and
+   may provide additional or different license terms and conditions
+   for use, reproduction, or distribution of Your modifications, or
+   for any such Derivative Works as a whole, provided Your use,
+   reproduction, and distribution of the Work otherwise complies with
+   the conditions stated in this License.
+5. Submission of Contributions. Unless You explicitly state otherwise,
+   any Contribution intentionally submitted for inclusion in the Work
+   by You to the Licensor shall be under the terms and conditions of
+   this License, without any additional terms or conditions.
+   Notwithstanding the above, nothing herein shall supersede or modify
+   the terms of any separate license agreement you may have executed
+   with Licensor regarding such Contributions.
+6. Trademarks. This License does not grant permission to use the trade
+   names, trademarks, service marks, or product names of the Licensor,
+   except as required for reasonable and customary use in describing the
+   origin of the Work and reproducing the content of the NOTICE file.
+7. Disclaimer of Warranty. Unless required by applicable law or
+   agreed to in writing, Licensor provides the Work (and each
+   Contributor provides its Contributions) on an "AS IS" BASIS,
+   implied, including, without limitation, any warranties or conditions
+   PARTICULAR PURPOSE. You are solely responsible for determining the
+   appropriateness of using or redistributing the Work and assume any
+   risks associated with Your exercise of permissions under this License.
+8. Limitation of Liability. In no event and under no legal theory,
+   whether in tort (including negligence), contract, or otherwise,
+   unless required by applicable law (such as deliberate and grossly
+   negligent acts) or agreed to in writing, shall any Contributor be
+   liable to You for damages, including any direct, indirect, special,
+   incidental, or consequential damages of any character arising as a
+   result of this License or out of the use or inability to use the
+   Work (including but not limited to damages for loss of goodwill,
+   work stoppage, computer failure or malfunction, or any and all
+   other commercial damages or losses), even if such Contributor
+   has been advised of the possibility of such damages.
+9. Accepting Warranty or Additional Liability. While redistributing
+   the Work or Derivative Works thereof, You may choose to offer,
+   and charge a fee for, acceptance of support, warranty, indemnity,
+   or other liability obligations and/or rights consistent with this
+   License. However, in accepting such obligations, You may act only
+   on Your own behalf and on Your sole responsibility, not on behalf
+   of any other Contributor, and only if You agree to indemnify,
+   defend, and hold each Contributor harmless for any liability
+   incurred by, or claims asserted against, such Contributor by reason
+   of your accepting any such warranty or additional liability.
\ No newline at end of file

Added: incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/LICENSE.cos
URL: http://svn.apache.org/viewvc/incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/LICENSE.cos?rev=630396&view=auto
--- incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/LICENSE.cos (added)
+++ incubator/jspwiki/branches/JSPWIKI_2_9_STRIPES_BRANCH/doc/LICENSE.cos Fri Feb 22 22:44:17
@@ -0,0 +1,78 @@
+Copyright (C) 2001-2002 by Jason Hunter, jhunter_AT_servlets.com.
+All rights reserved.
+The source code, object code, and documentation in the com.oreilly.servlet
+package is copyright and owned by Jason Hunter.
+This license is granted on the binary form of the com.oreilly.servlet.*
+packages that is distributed with the Stripes open source library.  Source
+code and documentation of the com.oreilly.servlet.* packages is available from
+http://servlets.com/cos.  You may, at your discretion, choose to use the
+com.oreilly.servlet.* packages under the terms defined in this license, or the
+terms defined in the license located at http://servlets.com/cos/license.html.
+The licenses are mutally-exclusive and may not apply concurrently to any usage
+of the com.oreilly.servlet.* packages.
+Permission is granted to use the com.oreilly.servlet.* packages in the
+development of any commercial or non-commercial project, where "use" is
+defined excluslively as "deployment of the com.oreilly.servlet.* packages in
+unmodified binary form, solely for the purpose of satisfying the dependency of
+the Stripes open source library".  For this use you are granted a
+non-exclusive, non-transferable limited license at no cost.
+This license does not confer upon the licensee the permission to extend or
+modify the com.oreilly.servlets package, nor to create additional software
+that directly uses or references the com.oreilly.servlets packages.
+Commercial redistribution rights of the com.oreilly.servlet.* packages are
+available by writing jhunter_AT_servlets.com.
+Non-commercial redistribution is permitted provided that:
+1. You redistribute the package object code form only (as Java .class files or
+a .jar file containing the .class files), as part of the Stripes open source
+library, a derivative work of the Stripes open source library, or as part of
+an application that uses and redistributes the Stripes open source library.
+2. The product containing the package is non-commercial in nature.
+3. The distribution includes copyright notice as follows: "The source code,
+object code, and documentation in the com.oreilly.servlet package is copyright
+and owned by Jason Hunter." in the documentation and/or other materials
+provided with the distribution.
+4. You reproduce the above copyright notice, this list of conditions, and the
+following disclaimer in the documentation and/or other materials provided with
+the distribution.
+5. Licensor retains title to and ownership of the Software and all
+enhancements, modifications, and updates to the Software.
+Note that the com.oreilly.servlet package is provided "as is" and the author
+will not be liable for any damages suffered as a result of your use.
+Furthermore, you understand the package comes without any technical support.
+You can always find the latest version of the com.oreilly.servlet package at
+Jason Hunter

View raw message