Re: APA-WebContent Refactoring

I fully agree Woonsan, I think switching to YAML would make this much 
easier/clearer, so +1 from me!

Regards, Ate

On 01/20/2014 12:53 AM, Woonsan Ko wrote:
> 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 <[email protected]> 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
>> <[email protected]> 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 <[email protected]>
>> wrote:
>>>>
>>>>>     Hi David,
>>>>>
>>>>>     Thanks for the quick response!
>>>>>
>>>>>
>>>>>     On Thursday, January 16, 2014 9:58 PM, David S Taylor <
>>>>>    [email protected]> 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
>>>>>     >[email protected]
>>>>>     >
>>>>>     >
>>>>>     >
>>>>>     >
>>>>>     >On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko
>> <[email protected]>
>>>>   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: [email protected]
>>>   For additional commands, e-mail: [email protected]
>>>
>>>
>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: [email protected]
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>