You are viewing a plain text version of this content. The canonical link for it is here.
Posted to portalapps-user@portals.apache.org by Woonsan Ko <wo...@yahoo.com> on 2014/01/16 20:28:53 UTC
APA-WebContent Refactoring
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
Re: APA-WebContent Refactoring
Posted by Ate Douma <at...@douma.nu>.
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 <rw...@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
>> <da...@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 <wo...@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
>> <wo...@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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: APA-WebContent Refactoring
Posted by Ate Douma <at...@douma.nu>.
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 <rw...@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
>> <da...@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 <wo...@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
>> <wo...@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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
Re: APA-WebContent Refactoring
Posted by Ate Douma <at...@douma.nu>.
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 <rw...@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
>> <da...@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 <wo...@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
>> <wo...@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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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 <rw...@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
> <da...@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 <wo...@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
> <wo...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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 <rw...@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
> <da...@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 <wo...@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
> <wo...@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
>
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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 <rw...@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
> <da...@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 <wo...@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
> <wo...@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
>
Re: APA-WebContent Refactoring
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 <da...@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 <wo...@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 <wo...@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
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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 <da...@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 <wo...@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 <wo...@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
>> >>
>> >
>> >
>> >
>>
>
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
On Friday, January 17, 2014 5:07 PM, David Taylor <da...@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
Sounds good.
I'll write a wiki page soon (probably by Friday) to share and discuss what/how to do for apa-webcontent-2.0 with community.
Cheers,
Woonsan
>
>
>On Thu, Jan 16, 2014 at 4:19 PM, Woonsan Ko <wo...@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 <wo...@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
>> >>
>> >
>> >
>> >
>>
>
>
>
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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 <da...@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 <wo...@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 <wo...@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-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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 <da...@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 <wo...@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 <wo...@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
>> >>
>> >
>> >
>> >
>>
>
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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 <da...@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 <wo...@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 <wo...@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
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
On Friday, January 17, 2014 5:07 PM, David Taylor <da...@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
Sounds good.
I'll write a wiki page soon (probably by Friday) to share and discuss what/how to do for apa-webcontent-2.0 with community.
Cheers,
Woonsan
>
>
>On Thu, Jan 16, 2014 at 4:19 PM, Woonsan Ko <wo...@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 <wo...@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
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
On Friday, January 17, 2014 5:07 PM, David Taylor <da...@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
Sounds good.
I'll write a wiki page soon (probably by Friday) to share and discuss what/how to do for apa-webcontent-2.0 with community.
Cheers,
Woonsan
>
>
>On Thu, Jan 16, 2014 at 4:19 PM, Woonsan Ko <wo...@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 <wo...@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-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
On Friday, January 17, 2014 5:07 PM, David Taylor <da...@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
Sounds good.
I'll write a wiki page soon (probably by Friday) to share and discuss what/how to do for apa-webcontent-2.0 with community.
Cheers,
Woonsan
>
>
>On Thu, Jan 16, 2014 at 4:19 PM, Woonsan Ko <wo...@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 <wo...@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
>> >>
>> >
>> >
>> >
>>
>
>
>
Re: APA-WebContent Refactoring
Posted by David Taylor <da...@gmail.com>.
> 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 <wo...@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 <wo...@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
> >>
> >
> >
> >
>
Re: APA-WebContent Refactoring
Posted by David Taylor <da...@gmail.com>.
> 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 <wo...@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 <wo...@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
> >>
> >
> >
> >
>
Re: APA-WebContent Refactoring
Posted by David Taylor <da...@gmail.com>.
> 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 <wo...@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 <wo...@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
> >>
> >
> >
> >
>
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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
>david@bluesunrise.com
>
>
>
>
>On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <wo...@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-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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
>david@bluesunrise.com
>
>
>
>
>On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <wo...@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
>>
>
>
>
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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
>david@bluesunrise.com
>
>
>
>
>On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <wo...@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
Re: APA-WebContent Refactoring
Posted by Woonsan Ko <wo...@yahoo.com>.
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
>david@bluesunrise.com
>
>
>
>
>On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <wo...@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
>>
>
>
>
Re: APA-WebContent Refactoring
Posted by David S Taylor <da...@bluesunrise.com>.
> 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.
> 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 :)
--
David S Taylor
CEO, Bluesunrise
707 529-9194
david@bluesunrise.com
On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <wo...@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
>
Re: APA-WebContent Refactoring
Posted by David S Taylor <da...@bluesunrise.com>.
> 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.
> 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 :)
--
David S Taylor
CEO, Bluesunrise
707 529-9194
david@bluesunrise.com
On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <wo...@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
>
Re: APA-WebContent Refactoring
Posted by David S Taylor <da...@bluesunrise.com>.
> 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.
> 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 :)
--
David S Taylor
CEO, Bluesunrise
707 529-9194
david@bluesunrise.com
On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <wo...@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
>
Re: APA-WebContent Refactoring
Posted by David Taylor <da...@gmail.com>.
[Sorry I need rejoin some of these mailing lists, Im getting rejected with
my new email account, and then monitoring them with my other email account]
> 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.
> 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 :)
On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <wo...@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
>
--
David