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