portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weaver, Scott" <Swea...@rippe.com>
Subject RE: is it possible to use Struts with Jetspeed
Date Mon, 24 Mar 2003 22:02:19 GMT

Takes a while to become a committer, but you can definitely contribute!  If David does not
respond to this I will email him directly, and ask him about the Struts progress.   I don't
know the timeline for 2.0, so I think starting in on Struts right now in 1.4 probably would
not duplicate any existing work and could possibly be ported straight into 2.0.

I have done 2 full Struts applications myself and feel fairly comfortable with the framework
and since I have also done a couple Turbine based apps also, we should be able to work together
to find lowest common denominator integration points to get this to work.


What is the status on Struts integration in 2.0?  Should we look at starting integration in
the 1.4x code base?  If people are willing to contribute, I think we should start in 1.4x,
since anyone can access that.

* Scott T Weaver                    *
* Jakarta Jetspeed Portal Project   *
* weaver@apache.org                 *

> -----Original Message-----
> From: James H Nguyen [mailto:james.nguyen@us.ibm.com]
> Sent: Monday, March 24, 2003 4:35 PM
> To: jetspeed-dev@jakarta.apache.org
> Subject: RE: is it possible to use Struts with Jetspeed
> from what i've read so far in the portlet api draft in the jetspeed cvs
> project. there's a PortletAdaptor class that most portlets will extend to
> obtain the portlet API hooks such as the portlet container context etc
> etc.
> since i've been working with struts for the few months on a client
> engagement, i've managed to become familiar enough to the point where i
> think we can extend struts from the RequestPreprocessor class and truncate
> all the unnessary servlet calls and provide for the simplified portlet
> interface. most of the struts dispatch actions come from the
> RequestPreprocessor class since struts v1.1x.
> the problem is i have all these ideas, but am stuck on weather i should
> implement them or not because i would hate to be duplicating work that
> someone else already has. and if that's the case, i would like to
> contribute in other areas where needed. =) i would love to see jetspeed be
> the leader in opensource portal server projects with the correct best of
> practices approach to portal servers.
> how would come about being a commiter for jetspeed and help out? i
> currently already have the latest cvs head and it's running great under
> websphere studio advanced developer 5. only problem was that it wouldn't
> run on WAS5 server... that i will try to figure out later, but for now i'm
> testing it with tomcat 4.1.x which runs great.
> please let me know. i'm dying to see how jetspeed 2.0 looks. ;)
> james nguyen
> ibm global services
> ams enterprise application development
> james.nguyen@us.ibm.com
> >>From what he told me, committer access is required to get a hold of 2.0.
> I am a committer, but I haven't had a chance to peruse 2.0.
> >>That does not mean we can't start in the 1.4x code base. I think we have
> to take it slow, first try delegating Struts' Actions to Struts from
> within
> the current Jetspeed implementation. To do this, I have a feeling are
> going
> to have to get our hands dirty we it comes to inner workings of Struts and
> knowing what pieces we need.
> >>After we have some comfort level with that, then we can look at a
> pluggable framework model for Jetspeed. This would allow the end developer
> to choose his/her framework of choice using a thin layer of abstraction
> between jetspeed and said framework.
> >>*===================================*
> >>* Scott T Weaver *
> >>* Jakarta Jetspeed Portal Project *
> >>* weaver@apache.org *
> >>*===================================*
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message