By the way, I will describe more in the wiki page later, but just for clarification, the main purpose of using spring framework is only to leverage its IoC and component weaving features and so simplify the implementation code.
In the past, someone asked me if it's possible to configure reverse proxy mappings in spring xml configurations, but that's still not a goal, IMO. The reason is that we need to enable administrators to configure reverse proxy mappings in simple text based configuration files, neither in (relatively complicated) spring xml nor annotated java code. That said, I've not been fully satisfied with the current properties file configuration for reverse proxy mapping yet. It took advantage of commons-configuration library (especially its subset configuration feature [1]), but still it is complex and unintuitive. XML configuration files are somethings I always want to avoid for this kind of mapping configurations, so I'm currently evaluating YMML [2] instead of properties or INI file. YAML looks a lot more intuitive than any other alternatives. For example, here's an example [3] in a properties file (with the current version): # reverseproxy.properties proxy.http.connManager.param.maxTotalConnections = 200 # … proxy.reverse.pass = apache, portals proxy.reverse.pass.apache.local = /apache/ proxy.reverse.pass.apache.remote = http://www.apache.org/ proxy.reverse.pass.portals.local = /portals/ proxy.reverse.pass.portals.remote = http://portals.apache.org/ The above configuration might be replaced with these in YAML: # reverse-proxy-http-settings.yaml maxTotalConnections: 200 # reverse-proxy-mappings.yaml --- local: /apache/ remote: http://www.apache.org/ --- local: /portals/ remote: http://portals.apache.org/ In YAML, administrator can simply copy one block to add something new very intuitively, IMO. Please share your thoughts about using YAML in apa-webcontent-2.0. Cheers, Woonsan [1] http://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration/Configuration.html#subset%28java.lang.String%29 [2] http://www.yaml.org/ [3] http://portals.apache.org/applications/webcontent/rproxy.html > On Friday, January 17, 2014 5:07 PM, David Taylor <davidseantay...@gmail.com> > wrote: > >> improvements in configurability/extensibility of the reverse proxy > servlet module by using spring framework and spring bean assembling > configuration as well. It's a perfect time to gather contirubtions. Let us > know if you want to help. :-) > > Definitely. One of the tasks in the Roadmap is to look into upgrading > Spring. In projects I've worked on recently, I've been using annotations > or > Spring configurations in Java, not the 'old' XML configurations. There > is > the new Spring 4.0 to consider. There could be benefit to APA and Jetspeed > sharing the same Spring core > > > On Thu, Jan 16, 2014 at 4:19 PM, Woonsan Ko <woon_...@yahoo.com> wrote: > >> Hi David, >> >> Thanks for the quick response! >> >> >> On Thursday, January 16, 2014 9:58 PM, David S Taylor < >> da...@bluesunrise.com> wrote: >> >> > Do you have any objections or different ideas? >> > >> >No objections at all. Makes sense to separate the webapp vs portlet app >> >usage. Hopefully we can get these new improvements included in the next >> >Jetspeed release. >> >> Cool! Thanks! >> If you mean the target release date, April 2014, then I think it's >> feasible. >> >> > >> >> new, more intuitive transformation rules abstracting something > like >> >htmlcleaner's TagTransformation [1]2. reverse-proxy >> > >> >So we are going to be basically dumping the existing transformation > rules >> >and replacing it with HtmlCleaner? I don't have a problem with > that, >> >progress :) >> >> Yeah, probably. :-) >> The XML based rule configuration was quite okay, I believe, but now I feel >> like it lacks of programmagic transformation support based on >> extensible/simple API, and it doesn't seem to cover challenging >> transformation needs. I'd like to rethink it over to find simpler/nicer > API >> and its representation (in configuration) as well. HtmlCleaner is just one >> of reference for now. Maybe we can use it or we can steal some of their >> design. It's still open to any other alternatives. Anyway, I expect the >> content-rewriter submodule be a unique/simple/powerful library for many use >> cases. >> >> By the way, as some people asked for this and were even willing to >> contribute, I also want to see improvements in >> configurability/extensibility of the reverse proxy servlet module by using >> spring framework and spring bean assembling configuration as well. It's > a >> perfect time to gather contirubtions. Let us know if you want to help. :-) >> >> Thanks again and cheers, >> >> Woonsan >> >> > >> > >> >-- >> >David S Taylor >> >CEO, Bluesunrise >> >707 529-9194 >> >da...@bluesunrise.com >> > >> > >> > >> > >> >On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <woon_...@yahoo.com> > wrote: >> > >> >> Hi, >> >> >> >> I'd like to restructure the modules of apa-webcontent and > refactor the >> >> html content rewriting modules. >> >> Some people including me use only reverse-proxy servlet in > non-portlet >> >> applications in some situations, and the current html content > rewriter >> >> feature seems to be tightly coupled with portlet api, so it's > hard to >> use >> >> it in that situation. Also, the rewriter rule mechanism > doesn't seem to >> >> have been improved for long time and it doesn't look very > intuitive any >> >> more. >> >> So, I'm considering new module structure like the following > (in the >> >> current structure with webcontent-jar and webcontent-war, you have > to >> put >> >> every Java module in webcontent-jar): >> >> >> >> 1. content-rewriter >> >> - content rewriting classes >> >> - no dependency on portlet api or servlet-api >> >> >> >> - new, more intuitive transformation rules abstracting > something >> like >> >> htmlcleaner's TagTransformation [1]2. reverse-proxy >> >> - reverse proxy servlet >> >> - no dependency on portlet api >> >> - using content-rewriter module >> >> >> >> 3. webcontent-portlets >> >> - portlet classes >> >> - using (or extending) content-rewriter >> >> >> >> 4. webcontent-war >> >> - portlet war >> >> - using all the other modules above >> >> >> >> Then I think we can reuse many good features of apa-webcontent in > many >> >> scenarios.By the way, I would bump up the trunk version to 2.0 > with >> moving >> >> the current trunk to a 1.x branch if there's no objection. > (Also >> probably >> >> we'd better change the package name to >> >> 'org.apache.portals.applications.webcontent2' as well.) >> >> >> >> Do you have any objections or different ideas? >> >> >> >> Cheers, >> >> >> >> Woonsan >> >> >> >> >> >> [1] http://htmlcleaner.sourceforge.net/javause.php >> >> >> > >> > >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
