Well, we're going to refactor the module and change many things anyway in 2.0 with breaking APIs (so, we'll rename the package names, too). I think it would be nice to change the configuration format as well during this refactoring if the change could give more intuitiveness without learning something *uncommon*.
In reality, the configuration customizations are needed only to remove/add reverse proxy mappings in most cases (e.g, adding '/example/' mapping for 'http://www.example.com/'). The things *uncommon* with the properties file is, for instance, that users have to add a name in the 'proxy.reverse.pass' property first and they have to define new properties prefixed by 'proxy.reverse.pass.*example*' like the following example. proxy.reverse.pass = portals, example # <-- add a new name here first ... proxy.reverse.pass.example.local = /example/ # <-- now start defining new props with 'example'.. proxy.reverse.pass.example.remote = http://www.example.com/ ... So, users have to understand the special style of commons-configurations, which looks very uncommon with regard to normal Java properties file. I have noticed that people should have spend much time on understanding how to configure it unnecessarily. In my opinion, I don't think this change is a change for change's sake. By splitting configuration files into multiple YAML files and allowing to define multiple reverse proxy mappings in the same name:value pattern without having to prefix each properties set, I believe users can easily understand it more quickly and do configuration tasks more easily without unnecessary errors. Also, it would help code maintainability as well because it is error-prone to handle configurations as subset always by invoking Configuration#setset(). Regards, Woonsan > On Sunday, January 19, 2014 2:33 PM, Ron Wheeler > <rwhee...@artifact-software.com> wrote: > > I don't see very much value in adding another language/tool to the mix > to same a bit of cutting and pasting. > > In your example, the properties are very clearly named, so the YAML > version is almost the same. > > Lets not introduce change for change's sake. > > Ron > > > On 18/01/2014 8:56 PM, Woonsan Ko wrote: >> 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-user-unsubscr...@portals.apache.org >> For additional commands, e-mail: jetspeed-user-h...@portals.apache.org >> >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jetspeed-user-unsubscr...@portals.apache.org > For additional commands, e-mail: jetspeed-user-h...@portals.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: jetspeed-user-unsubscr...@portals.apache.org For additional commands, e-mail: jetspeed-user-h...@portals.apache.org
