On Friday, January 17, 2014 5:07 PM, David Taylor <davidseantay...@gmail.com>
wrote:
improvements in configurability/extensibility of the reverse proxy
servlet module by using spring framework and spring bean assembling
configuration as well. It's a perfect time to gather contirubtions. Let us
know if you want to help. :-)
Definitely. One of the tasks in the Roadmap is to look into upgrading
Spring. In projects I've worked on recently, I've been using annotations
or
Spring configurations in Java, not the 'old' XML configurations. There
is
the new Spring 4.0 to consider. There could be benefit to APA and Jetspeed
sharing the same Spring core
On Thu, Jan 16, 2014 at 4:19 PM, Woonsan Ko <woon_...@yahoo.com> wrote:
Hi David,
Thanks for the quick response!
On Thursday, January 16, 2014 9:58 PM, David S Taylor <
da...@bluesunrise.com> wrote:
> Do you have any objections or different ideas?
>
>No objections at all. Makes sense to separate the webapp vs portlet app
>usage. Hopefully we can get these new improvements included in the next
>Jetspeed release.
Cool! Thanks!
If you mean the target release date, April 2014, then I think it's
feasible.
>
>> new, more intuitive transformation rules abstracting something
like
>htmlcleaner's TagTransformation [1]2. reverse-proxy
>
>So we are going to be basically dumping the existing transformation
rules
>and replacing it with HtmlCleaner? I don't have a problem with
that,
>progress :)
Yeah, probably. :-)
The XML based rule configuration was quite okay, I believe, but now I feel
like it lacks of programmagic transformation support based on
extensible/simple API, and it doesn't seem to cover challenging
transformation needs. I'd like to rethink it over to find simpler/nicer
API
and its representation (in configuration) as well. HtmlCleaner is just one
of reference for now. Maybe we can use it or we can steal some of their
design. It's still open to any other alternatives. Anyway, I expect the
content-rewriter submodule be a unique/simple/powerful library for many use
cases.
By the way, as some people asked for this and were even willing to
contribute, I also want to see improvements in
configurability/extensibility of the reverse proxy servlet module by using
spring framework and spring bean assembling configuration as well. It's
a
perfect time to gather contirubtions. Let us know if you want to help. :-)
Thanks again and cheers,
Woonsan
>
>
>--
>David S Taylor
>CEO, Bluesunrise
>707 529-9194
>da...@bluesunrise.com
>
>
>
>
>On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <woon_...@yahoo.com>
wrote:
>
>> Hi,
>>
>> I'd like to restructure the modules of apa-webcontent and
refactor the
>> html content rewriting modules.
>> Some people including me use only reverse-proxy servlet in
non-portlet
>> applications in some situations, and the current html content
rewriter
>> feature seems to be tightly coupled with portlet api, so it's
hard to
use
>> it in that situation. Also, the rewriter rule mechanism
doesn't seem to
>> have been improved for long time and it doesn't look very
intuitive any
>> more.
>> So, I'm considering new module structure like the following
(in the
>> current structure with webcontent-jar and webcontent-war, you have
to
put
>> every Java module in webcontent-jar):
>>
>> 1. content-rewriter
>> - content rewriting classes
>> - no dependency on portlet api or servlet-api
>>
>> - new, more intuitive transformation rules abstracting
something
like
>> htmlcleaner's TagTransformation [1]2. reverse-proxy
>> - reverse proxy servlet
>> - no dependency on portlet api
>> - using content-rewriter module
>>
>> 3. webcontent-portlets
>> - portlet classes
>> - using (or extending) content-rewriter
>>
>> 4. webcontent-war
>> - portlet war
>> - using all the other modules above
>>
>> Then I think we can reuse many good features of apa-webcontent in
many
>> scenarios.By the way, I would bump up the trunk version to 2.0
with
moving
>> the current trunk to a 1.x branch if there's no objection.
(Also
probably
>> we'd better change the package name to
>> 'org.apache.portals.applications.webcontent2' as well.)
>>
>> Do you have any objections or different ideas?
>>
>> Cheers,
>>
>> Woonsan
>>
>>
>> [1] http://htmlcleaner.sourceforge.net/javause.php
>>
>
>
>
