[
http://jira.amdatu.org/jira/browse/AMDATU-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bram de Kruijff updated AMDATU-283:
-----------------------------------
Attachment: AMDATU-283-v1.patch
Ok, this has been way more work then expected but I think I've got the
mechanism done now. I'd like a review on code/naming/impact and merge. Patch is
attached an can be applied to trunk r926 (or just testdrive the AMDATU-283-dev
branch).
Summarized list of changes:
* HttpContextServiceFactory (non whiteboard) has been replaced by
HttpContextManagerService (whiteboard)
* Developers can register their own HttpContext if they whish to do so.. but
must specify contextId
* .. or register one or more ResourceProvider/SecurityHandler/MimetypResolver
services with a contextId
that the HttpContextManager joins and registers as a
(Delegating)HttpContext
* If a servlet/filter specifies a contextId initialization is delayed until the
HttpContext
is available to the dispatcher. A servlet/filter that does not specify
a contextId gets a default
dummy HttpContext that only tries to load resource from the registrars
bundle
* JSP/Resource support now have their own service interface that signifies
their availibility
(JspSupport / ResourceSupport) and specify the registration property key
* JSP/Resource support no longer work based on string concatenation based
conventions and delegated all
resource loading to HttpContext. Only JSP classpath still consults
registrars bundle.
* A ResourceProvider may specify additional jspAlias/resourceAlias registration
properties
to activate jsp/resource support for it.
* contextId now is a logical name. I have introduced the conventions of using
one per subproject for
now. Eg all opensocial components use httpcontext 'amdatu-opensocial'.
Not sure if this will
remain / turn out to be usefull yet
Backward incompatibility:
* Developers must remove any HttpContextServiceFactory related code
* Developers must either remove contextId registration properties if they want
a default or...
* Developers must register a HttpContext with the proper contextId themselves
or
* Developers must register at least one DelegatingHttpContext delegate (eg
ResourceProvider)
with the proper contextId
* Developers must add JSP/Resource alis proerpties as required
Open consideration;
* Merge httpcontext into dispatcher? They don't really do anything usefull
without eachother and seem
rather coupled in terms of releasecycle. Now developer typically need
to depend on both artifacts.
* Publish JSP/Resource support alias keys on central interface? Now developer
typically need to depend
on both artifacts.
> Refactor web httpcontext mechanism
> ----------------------------------
>
> Key: AMDATU-283
> URL: http://jira.amdatu.org/jira/browse/AMDATU-283
> Project: Amdatu
> Issue Type: Improvement
> Components: Amdatu Web
> Affects Versions: 0.1.0
> Reporter: Bram de Kruijff
> Assignee: Bram de Kruijff
> Fix For: 0.2.0
>
> Attachments: AMDATU-283-v1.patch
>
>
> As discussed and documented at
> http://lists.amdatu.org/pipermail/amdatu-developers/2011-January/002474.html
> the current HttpContext requires some refactoring to be really usefull and
> support advanced use cases (including security).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers
