Re: JSR-168 and Struts

2003-10-29 Thread Craig R. McClanahan
Don Brown wrote:

Pretty much the only dependency of struts-chain is a recent build of
jakarta-commons-sandbox/chain.  To fully build commons-chain, in addition
to other commons jars, you need the porlet api jar, the servlet jar, and
the latest jsf jar from the sun web services pack 1.3 I believe.  However,
you should be able to build commons-chain with one of these jars missing
if you don't need their related chain classes.
Currently, struts-chain implements most of Struts functionality in the
form of small commands, strung together by chain-config.xml.  For any
commands that would have a use outside servlets, there exist abstract
classes in org.apache.struts.chain in the form of Abstract*.java  which
perform all possible tasks without accessing servlet apis.  The abstract
commands are implemented in o.a.s.c.servlet by servlet specific commands
which handle all direct servlet contact.
To make struts-chain work with the portlet api, a new package will be
created, o.a.s.c.portlet, which will contain implementations of the
abstract classes in o.a.s.chain.  These commands will take the context,
cast it into a PortletContext (I believe that's the name), and access
portlet apis directly just as the servlet commands did.
These commands, particularly the api dependent ones, are very short and
should be very easy to port.  Of course Struts in a portlet context will
use a different chain-config.xml with commands pointing to the porlet
implementations rather than the servlet ones, but it should pretty much be
the same structure and behavior.
 

All of the above will be needed, but there's a couple of additional 
wrinkles to the portlet environment that are going to be interesting:

* Portlet doesn't let you do a RequestDispatcher.forward(), which is
 the normal way that Struts passes final control to the JSP or other
 resource that renders the response.  I suspect we can deal with this
 by using RequestDispatcher.include() instead.
* Portlet divides the lifetime of a request into two phases ("processAction"
 and "render") -- in a Struts world, that roughly corresponds to everything
 before the processForwardConfig() call and the processForwardConfig()
 itself.  I suspect this is probably best modelled as two separate chains
 (but both executing on the same Context instance, so stuff accumulated
 during processAction is available during rendering) but haven't thought it
 all the way through yet.
I'm new to struts-chain, so hopefully this is an accurate description of
the current state of struts-chain and how the portlet api will be
supported.
Don

 

Craig


On Wed, 29 Oct 2003, Mete Kural wrote:

 

Hello Struts and Pluto developers,

There was a thread about developing JSR-168 support into Struts 2.0 in the pluto-dev list and we thought it might be best to continue this thread on both lists, pluto-dev and struts-dev synchronously. Below is the last email in the thread send by Scott Weaver to the pluto-dev list. Please "reply all" so that your emails will go to both groups.

Thanks,
Mete
Scott's message:

-- Original Message --
From: "Weaver, Scott" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date:  Wed, 29 Oct 2003 15:33:03 -0500
Hi Martin,

   

-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 3:16 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Pluto and Struts
On Wed, 29 Oct 2003, Weaver, Scott wrote:

 

Maybe it's just me, but I tried to build the contrib stuff in the CVS
   

for struts a while back as I wanted to start taking a look at.  However, I
could never get it built.  There were deps I had never heard of, nor did I
know were to get them.
If you could let me know what you're having problems with, I'll try to
help you through getting it all built. The chances are that anything you
haven't heard of comes from Jakarta Commons or the Commons Sandbox. (For
example, 'chain' is currently in the sandbox.)
 

I know most of the stuff in commons proper, I don't think that's were my issue lies.  I am pretty sure it was chain that I couldn't find and, at the time, I am not sure it was available, even within commons-sandbox.  I don't remember the specific issues as this was around 2 months ago when I last tried.

   

I was actually having the same problem but from the other side of the
coin, as it were. I need to build 'chain' against the Portlet API, but I
couldn't get Pluto to build, and couldn't figure out the deps for that.
(BTW, since Pluto's build.xml depends on ant-contrib, '-projecthelp'
doesn't work until that's configured, which is quite mysterious until you
look at the build file itself. ;)
 

Try "build driver", there are custom ant tasks that get included when you call the "build" script.

I really don't do much at all with Pluto portal implementation in that my focus, concerning Jetspeed, is the core Pluto container itself.  That is were I spend most of my time in regards to Pluto.

That bein

RE: JSR-168 and Struts

2003-10-29 Thread Don Brown
Pretty much the only dependency of struts-chain is a recent build of
jakarta-commons-sandbox/chain.  To fully build commons-chain, in addition
to other commons jars, you need the porlet api jar, the servlet jar, and
the latest jsf jar from the sun web services pack 1.3 I believe.  However,
you should be able to build commons-chain with one of these jars missing
if you don't need their related chain classes.

Currently, struts-chain implements most of Struts functionality in the
form of small commands, strung together by chain-config.xml.  For any
commands that would have a use outside servlets, there exist abstract
classes in org.apache.struts.chain in the form of Abstract*.java  which
perform all possible tasks without accessing servlet apis.  The abstract
commands are implemented in o.a.s.c.servlet by servlet specific commands
which handle all direct servlet contact.

To make struts-chain work with the portlet api, a new package will be
created, o.a.s.c.portlet, which will contain implementations of the
abstract classes in o.a.s.chain.  These commands will take the context,
cast it into a PortletContext (I believe that's the name), and access
portlet apis directly just as the servlet commands did.

These commands, particularly the api dependent ones, are very short and
should be very easy to port.  Of course Struts in a portlet context will
use a different chain-config.xml with commands pointing to the porlet
implementations rather than the servlet ones, but it should pretty much be
the same structure and behavior.

I'm new to struts-chain, so hopefully this is an accurate description of
the current state of struts-chain and how the portlet api will be
supported.

Don


On Wed, 29 Oct 2003, Mete Kural wrote:

> Hello Struts and Pluto developers,
>
> There was a thread about developing JSR-168 support into Struts 2.0 in the pluto-dev 
> list and we thought it might be best to continue this thread on both lists, 
> pluto-dev and struts-dev synchronously. Below is the last email in the thread send 
> by Scott Weaver to the pluto-dev list. Please "reply all" so that your emails will 
> go to both groups.
>
> Thanks,
> Mete
>
> Scott's message:
>
> -- Original Message --
> From: "Weaver, Scott" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date:  Wed, 29 Oct 2003 15:33:03 -0500
>
> Hi Martin,
>
> > -Original Message-
> > From: Martin Cooper [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, October 29, 2003 3:16 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Pluto and Struts
> >
> > On Wed, 29 Oct 2003, Weaver, Scott wrote:
> >
> > > Maybe it's just me, but I tried to build the contrib stuff in the CVS
> > for struts a while back as I wanted to start taking a look at.  However, I
> > could never get it built.  There were deps I had never heard of, nor did I
> > know were to get them.
> >
> > If you could let me know what you're having problems with, I'll try to
> > help you through getting it all built. The chances are that anything you
> > haven't heard of comes from Jakarta Commons or the Commons Sandbox. (For
> > example, 'chain' is currently in the sandbox.)
>
> I know most of the stuff in commons proper, I don't think that's were my issue lies. 
>  I am pretty sure it was chain that I couldn't find and, at the time, I am not sure 
> it was available, even within commons-sandbox.  I don't remember the specific issues 
> as this was around 2 months ago when I last tried.
>
> >
> > I was actually having the same problem but from the other side of the
> > coin, as it were. I need to build 'chain' against the Portlet API, but I
> > couldn't get Pluto to build, and couldn't figure out the deps for that.
> > (BTW, since Pluto's build.xml depends on ant-contrib, '-projecthelp'
> > doesn't work until that's configured, which is quite mysterious until you
> > look at the build file itself. ;)
> >
>
> Try "build driver", there are custom ant tasks that get included when you call the 
> "build" script.
>
> I really don't do much at all with Pluto portal implementation in that my focus, 
> concerning Jetspeed, is the core Pluto container itself.  That is were I spend most 
> of my time in regards to Pluto.
>
> That being said, there should be no fork in development to support either Pluto 
> Portal or Jetspeed 2.  In fact, if we do this correctly, the whole thing should be 
> transparent to the Struts portlet app and that app should be easily portable to any 
> other JSR-168 portal.
>
> p.s.
>
> I have no issues whatsoever with joining the Struts-dev mailing list, however, I 
> think it might be in the best interest of all involved that we cross-post to both 
> struts-dev and pluto-dev.
>
> I look forward to working with you.
>
> Regards,
> **
> | Scott T Weaver |
> | <[EMAIL PROTECTED]>|
> | Apache Jetspeed Portal Project |
> | Apache Pluto Portlet Container |
> **
>
>
>
> --

RE: JSR-168 and Struts

2003-10-29 Thread Mete Kural
Hello Struts and Pluto developers, 

There was a thread about developing JSR-168 support into Struts 2.0 in the pluto-dev 
list and we thought it might be best to continue this thread on both lists, pluto-dev 
and struts-dev synchronously. Below is the last email in the thread send by Scott 
Weaver to the pluto-dev list. Please "reply all" so that your emails will go to both 
groups.

Thanks,
Mete

Scott's message:

-- Original Message --
From: "Weaver, Scott" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date:  Wed, 29 Oct 2003 15:33:03 -0500

Hi Martin,

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 29, 2003 3:16 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Pluto and Struts
> 
> On Wed, 29 Oct 2003, Weaver, Scott wrote:
> 
> > Maybe it's just me, but I tried to build the contrib stuff in the CVS
> for struts a while back as I wanted to start taking a look at.  However, I
> could never get it built.  There were deps I had never heard of, nor did I
> know were to get them.
> 
> If you could let me know what you're having problems with, I'll try to
> help you through getting it all built. The chances are that anything you
> haven't heard of comes from Jakarta Commons or the Commons Sandbox. (For
> example, 'chain' is currently in the sandbox.)

I know most of the stuff in commons proper, I don't think that's were my issue lies.  
I am pretty sure it was chain that I couldn't find and, at the time, I am not sure it 
was available, even within commons-sandbox.  I don't remember the specific issues as 
this was around 2 months ago when I last tried.

> 
> I was actually having the same problem but from the other side of the
> coin, as it were. I need to build 'chain' against the Portlet API, but I
> couldn't get Pluto to build, and couldn't figure out the deps for that.
> (BTW, since Pluto's build.xml depends on ant-contrib, '-projecthelp'
> doesn't work until that's configured, which is quite mysterious until you
> look at the build file itself. ;)
> 

Try "build driver", there are custom ant tasks that get included when you call the 
"build" script.  

I really don't do much at all with Pluto portal implementation in that my focus, 
concerning Jetspeed, is the core Pluto container itself.  That is were I spend most of 
my time in regards to Pluto.

That being said, there should be no fork in development to support either Pluto Portal 
or Jetspeed 2.  In fact, if we do this correctly, the whole thing should be 
transparent to the Struts portlet app and that app should be easily portable to any 
other JSR-168 portal.

p.s.

I have no issues whatsoever with joining the Struts-dev mailing list, however, I think 
it might be in the best interest of all involved that we cross-post to both struts-dev 
and pluto-dev.

I look forward to working with you.

Regards,
** 
| Scott T Weaver |
| <[EMAIL PROTECTED]>| 
| Apache Jetspeed Portal Project |
| Apache Pluto Portlet Container |
**



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JSR 168 and Struts

2003-08-29 Thread BaTien Duong
Clay Richardson wrote:

I apologize if anyone has already asked this question, but I searched
the board and didn't see it.  Also, I tried the user forum first, but
figured maybe this was more appropriate.


JSR 168 has the following line in it (Section PLT.16.3):



"Servlets and JSPs included from portlets should not use the servlet
RequestDispatcher forward method as its behavior may be
non-deterministic."
 

Yes, this is one of my concern as well and did not response to this 
question in user group since i have not put enough time in it.

It seems to me that Struts needs to be refactoring to be MVC for 
portlets since portlets can delegate the creation of content to servlet 
and JSP via PortletRequestDispatcher. If there is a proper hook then 
Tiles can still be an intelligent assembling part of the view. Craig is 
the best guy to iron these issues.

BaTien
DBGROUPS



I am no expert on Struts, although I have used it quite a bit.  It seems
that if I wanted to wrap my Struts app in a Portlet and access various
actions through the PortletRequestDispatcher (the most logical
approach), I would run afoul of this warning.


Lacking an implementation to test my hypothesis (*$&# IBM legal
department), I am unsure whether this actually fails or not.  My gut
instinct is that it probably wouldn't, but that it may not be reliable
across implementations of servlet and portlet containers.  



I wanted to get some thoughts from the Struts community about this
possible issue.  Also, I wanted to know what the impact would be of
using RequestDispatcher's include method instead?  Or at least providing
the facility to portlet developers?


I apologize if I have wrongly assumed anything in my question.  This is
my best estimate based on what I have read.


Thanks,





Clay Richardson





W. Clay Richardson

Adjunct Professor of Computer Science

Northern Virginia Graduate Center

Virginia Polytechnic Institute and State University



"Oh, and how is "education" supposed to make me feel smarter?  Besides,
every time I learn something new, it pushes some old stuff out of my
brain.  Remember when I took that home wine-making course and I forgot
how to drive?" - Homer J. Simpson








 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: JSR 168 and Struts

2003-08-29 Thread Rick Hightower
Regarding:" Lacking an implementation to test my hypothesis (*$&# IBM legal
department), I am unsure whether this actually fails or not.  My gut
instinct is that it probably wouldn't, but that it may not be reliable
across implementations of servlet and portlet containers."

Jaco Portal Server is a Java portal server which is compliant with the
Portlet Specification (JSR-168).
 
http://pharos.inria.fr/Java/display.jsp?id=c_14701

I have a client that is mixing Portlets and Struts. I am not an expert on
Portlets. 

They did a lot of research on the best ways to mix the two technologies
(white papers, prototypes, etc.). 



Rick Hightower
Chief Technology Officer
Trivera Technologies
http://www.triveratech.com
520 290 6855 (Phone)
520 977 8605 (Mobile)
 

-Original Message-
From: Clay Richardson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 28, 2003 9:05 PM
To: [EMAIL PROTECTED]
Subject: JSR 168 and Struts

I apologize if anyone has already asked this question, but I searched
the board and didn't see it.  Also, I tried the user forum first, but
figured maybe this was more appropriate.

 

JSR 168 has the following line in it (Section PLT.16.3):

 

"Servlets and JSPs included from portlets should not use the servlet
RequestDispatcher forward method as its behavior may be
non-deterministic."

 

I am no expert on Struts, although I have used it quite a bit.  It seems
that if I wanted to wrap my Struts app in a Portlet and access various
actions through the PortletRequestDispatcher (the most logical
approach), I would run afoul of this warning.

 

Lacking an implementation to test my hypothesis (*$&# IBM legal
department), I am unsure whether this actually fails or not.  My gut
instinct is that it probably wouldn't, but that it may not be reliable
across implementations of servlet and portlet containers.  

 

I wanted to get some thoughts from the Struts community about this
possible issue.  Also, I wanted to know what the impact would be of
using RequestDispatcher's include method instead?  Or at least providing
the facility to portlet developers?

 

I apologize if I have wrongly assumed anything in my question.  This is
my best estimate based on what I have read.

 

Thanks,

 

 

Clay Richardson

 

 

W. Clay Richardson

Adjunct Professor of Computer Science

Northern Virginia Graduate Center

Virginia Polytechnic Institute and State University

 

"Oh, and how is "education" supposed to make me feel smarter?  Besides,
every time I learn something new, it pushes some old stuff out of my
brain.  Remember when I took that home wine-making course and I forgot
how to drive?" - Homer J. Simpson

 

 

 

 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]