portals-portalapps-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Woonsan Ko <woon_...@yahoo.com>
Subject Re: APA-WebContent Refactoring
Date Sun, 19 Jan 2014 23:53:39 GMT
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 <rwheeler@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 
> <davidseantaylor@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_san@yahoo.com> 
> wrote:
>>> 
>>>>    Hi David,
>>>> 
>>>>    Thanks for the quick response!
>>>> 
>>>> 
>>>>    On Thursday, January 16, 2014 9:58 PM, David S Taylor <
>>>>   david@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
>>>>    >david@bluesunrise.com
>>>>    >
>>>>    >
>>>>    >
>>>>    >
>>>>    >On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko 
> <woon_san@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-unsubscribe@portals.apache.org
>>  For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> 

Mime
View raw message