RE: XSL instead of JSP

[Ludwig, Pat]

hi,
   with no offense meant, isn't the notion of promoting non-browser-like
clients counter-productive to one of the basic benefits of network
programming such as code maintenance and distribution? i certainly
understand that this may be the best solution for some intranet and legacy
apps, but it comes with a significant cost.  whether you communicate with
these fat clients using SOAP or any other protocol, it doesn't change the
fact that you have a substantial non-standard code resource on the client
which will require periodic upgrades and bug fixes.  browsers remain
frustratingly difficult to program sophisticated UI, but shouldn't we be
focusing more on making browsers better client platforms than scrapping the
benefits of zero client maintenance with custom clients?

Pat Ludwig
Silverstream Software

> -Original Message-
> From: Joaquim Carvalho [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 08, 2001 8:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: XSL instead of JSP
>
>
> I think one way to go would be to implement a SOAP layer on top of
> struts.
> SOAP is a protocol to expose the functionality of an application to a
> remote client through the use of XML requests/and answers
> travelling on
> top of http. Typically a SOAP client constructs a remote call to the
> server much in the same way as a web form is filled with
> information in
> a browser. A post of this xml call could be sent to a struts
> app where
> it would be decoded in the same way a form is, creating the
> form beans
> and all that. The struts app them, instead of rendering the answer in
> HTML would render it in XML according to the SOAP answer specs. The
> client application can be done in anything that can write and read to
> http connection.
>
> Check the SOAP project at xml.apache.org to get the idea of the thing
> although that particular project is not directly usefull in
> this context.
>
> Some time ago I though of this and even inquired the list if this
> SOAP/STRUTS idea was interesting but  got no feed back and moved to
> other things. My recollection is that it would be easy to
> extend struts
> to recognize a XML post  besides of a Form Post and so SOAP
> and Struts
> could be easily mingled.
>
> I have just finished a project of converting a legacy C web app to a
> SOAP/Web app and the result is very encouraging. The same
> code that is
> answering the direct browser requests also handles requests
> from clients
> written in VisualBasic. We even have APSs as XML clients of our app.
>
>
>
> On Monday, May 7, 2001, at 10:24 PM, Mike Williams wrote:
>
> > Guess I'll add my 2 cents :)  I'm also researching using XML in the
> > view component of struts.
> >
> > My needs may be a little off from what you're looking at
> though.  We
> > have a application that currently runs as a web app.
> However, some of
> > our clients are a bit spoiled to the GUI of a desktop app.
> So, I need
> > to leverage our current expertise in servlets to interact with a
> > desktop application.  That's where I hope XML will come into play.
> >
> > The idea is to use Struts as the framework since we will
> probably still
> > have some clients using the web based system.  Hey, that's
> the power of
> > the MVC pattern after all.  You can easily plug a different
> view in and
> > everyone is happy :)
> >
> > XML will basically be a messaging protocol between the client and
> > server.

AW: XSL instead of JSP

[Nestel, Frank]

Hi,

initially I thought struts would be the answer to our web design
needs, but then we decided how strongly it was tied to JSP. We are
now using a primive framework which is somewhat inspired by struts,
but much more simpleminded, which uses XSL as a renderer. We have a
central servlet which first dispatches requests to certain XML
generating classes and then gives that XML to a stylesheet processor.
Our framework is more lightweight than cocoon and also adresses
problems like parameters, form handling, things I did not find in
Cocoon when I looked at it long time ago.

* XSL is definately slower than JSP yet, though we use SAX Events as
  communication within the application. But its getting better and
  better and you can do quite a few tricks with caching.
* If XML data comes in, the Java programming often can be very easy
  filtering.
* Work separation between design and programming is very clear. You
  just give the designers a bunch of XMLs (or even a DTD/Schema) and
  say, try to render this. If he needs other information he has to
  ask the programmer for more xml. In JSP it is bad style but easily
  possible to include more and more code in your design.
* Training to the actual designer wasn't to hard here, since they 
  were all used to HTML sourcecode hacking.

The next Servlet API seems to adress this problem differently by
allowing any outputs interposed by appropriate filters.

A merger between Struts and a more direct XSL application would be
an interesting technology.

Just thoughts,
Frank

cvs commit: jakarta-struts/src/share/org/apache/struts/util LocalStrings.properties RequestUtils.java

[craigmcc]

craigmcc01/05/09 12:31:33

  Modified:doc  struts-bean.xml struts-html.xml struts-logic.xml
   src/share/org/apache/struts/taglib/bean IncludeTag.java
LocalStrings.properties
   src/share/org/apache/struts/taglib/html LinkTag.java
LocalStrings.properties RewriteTag.java
   src/share/org/apache/struts/taglib/logic
LocalStrings.properties RedirectTag.java
   src/share/org/apache/struts/util LocalStrings.properties
RequestUtils.java
  Log:
  Refactor the hyperlink-generation code used in the ,
  , , and  tags to use common
  utility methods based on URLs rather than Strings.  This will ensure
  consistency in implementation, and make it easy to provide full
  URL-processing functionality to other tags as necessary.
  
  Revision  ChangesPath
  1.4   +22 -0 jakarta-struts/doc/struts-bean.xml
  
  Index: struts-bean.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/struts-bean.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- struts-bean.xml   2001/04/22 00:46:19 1.3
  +++ struts-bean.xml   2001/05/09 19:31:00 1.4
  @@ -353,6 +353,17 @@
   
   
   
  +  anchor
  +  false
  +  true
  +  
  +  Optional anchor tag ("#xxx") to be added to the generated
  +  hyperlink.  Specify this value without any
  +  "#" character.
  +  
  +
  +
  +
 forward
 false
 true
  @@ -404,6 +415,17 @@
 
 Context-relative URI (starting with a '/') of the web application
 resource to be included.
  +  
  +
  +
  +
  +  transaction
  +  false
  +  true
  +  
  +Set to true if you want the current
  +transaction control token included in the generated
  +URL for this include.
 
   
   
  
  
  
  1.9   +81 -6 jakarta-struts/doc/struts-html.xml
  
  Index: struts-html.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/struts-html.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- struts-html.xml   2001/05/05 00:59:50 1.8
  +++ struts-html.xml   2001/05/09 19:31:01 1.9
  @@ -3704,6 +3704,17 @@
   
   
   
  +  anchor
  +  false
  +  true
  +  
  +  Optional anchor tag ("#xxx") to be added to the generated
  +  hyperlink.  Specify this value without any
  +  "#" character.
  +  
  +
  +
  +
 forward
 false
 true
  @@ -3735,6 +3746,19 @@
   
   
   
  +  name
  +  false
  +  true
  +  
  +  The name of a JSP bean that contains a Map
  +  representing the query parameters (if property
  +  is not specified), or a JSP bean whose property getter is
  +  called to return a Map (if property
  +  is specified).
  +  
  +
  +
  +
 page
 false
 true
  @@ -3751,15 +3775,54 @@
   
   
   
  -  name
  +  paramId
 false
 true
 
  -  The name of a JSP bean that contains a Map
  -  representing the query parameters (if property
  -  is not specified), or a JSP bean whose property getter is
  -  called to return a Map (if property
  -  is specified).
  +  The name of the request parameter that will be dynamically
  +  added to the generated hyperlink.  The corresponding value is
  +  defined by the paramName and (optional)
  +  paramProperty attributes, optionally scoped by
  +  the paramScope attributel
  +  
  +
  +
  +
  +  paramName
  +  false
  +  true
  +  
  +  The name of a JSP bean that is a String containing the
  +  value for the request parameter named by paramId
  +  (if paramProperty is not specified), or a JSP
  +  bean whose property getter is called to return a String
  +  (if paramProperty is specified).  The JSP bean
  +  is constrained to the bean scope specified by the
  +   

RE: XSL instead of JSP

[Rapheal Kaplan]

I intend to try to implement a way of using Cocoon with Struts.  It should
actually not be extraordinarily hard.  Has anyone else done something
similar?

-Original Message-
From: Nestel, Frank [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 09, 2001 9:47 AM
To: '[EMAIL PROTECTED]'
Subject: AW: XSL instead of JSP


Hi,

initially I thought struts would be the answer to our web design
needs, but then we decided how strongly it was tied to JSP. We are
now using a primive framework which is somewhat inspired by struts,
but much more simpleminded, which uses XSL as a renderer. We have a
central servlet which first dispatches requests to certain XML
generating classes and then gives that XML to a stylesheet processor.
Our framework is more lightweight than cocoon and also adresses
problems like parameters, form handling, things I did not find in
Cocoon when I looked at it long time ago.

* XSL is definately slower than JSP yet, though we use SAX Events as
  communication within the application. But its getting better and
  better and you can do quite a few tricks with caching.
* If XML data comes in, the Java programming often can be very easy
  filtering.
* Work separation between design and programming is very clear. You
  just give the designers a bunch of XMLs (or even a DTD/Schema) and
  say, try to render this. If he needs other information he has to
  ask the programmer for more xml. In JSP it is bad style but easily
  possible to include more and more code in your design.
* Training to the actual designer wasn't to hard here, since they
  were all used to HTML sourcecode hacking.

The next Servlet API seems to adress this problem differently by
allowing any outputs interposed by appropriate filters.

A merger between Struts and a more direct XSL application would be
an interesting technology.

Just thoughts,
Frank

Re: XSL instead of JSP

[Taylor Cowan]

I don't know a lot about Cocoon, but I believe it is similar to Struts in
that it has a "master" servlet which is awakened by requests matching a
particular expression.  In that sense they are mutually exclusive.
Sometimes I'm tempted to consider the benefits of combining the two but I
always end up realizing its not an improvement.  For example, if you want
some view feature of struts, it would be better to do it in XSL with Cocoon,
not combining the two.

One way I can see a combination is where the app is basically struts, but an
include page (either through frames, templates, jsp:include or @ include )
is sourced from Cocoon.  Basically a portal with a window into Cocoon, since
iteraction with Cocoon is just a URL.  But still the two frameworks act
independently.

Taylor
- Original Message -
From: "Rapheal Kaplan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 09, 2001 3:26 PM
Subject: RE: XSL instead of JSP


> I intend to try to implement a way of using Cocoon with Struts.  It should
> actually not be extraordinarily hard.  Has anyone else done something
> similar?
>

RE: XSL instead of JSP

[Rapheal Kaplan]

Well, what I was thinking is that most of the presentation of struts is
rightfully pushed off to JSP, which like Cocoon, is really just another
stand along servlet.  I think all we really need is a few support libraries
for Cocoon.

I think it might well be as simple as developing XSP tag libraries that are
the same as the JSP tag libraries for form input.

However, then there is the fact that I think that cocoon really should not
be used for form input (we tried that where I used to work).  A framework
for that is sort of something altogether different.  But it can be done.
There may even be applications where doing so is a good idea.

But for display of large and complex things, I believe Cocoon is really
nice - less the performance issues.

-Original Message-
From: Taylor Cowan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 09, 2001 4:53 PM
To: [EMAIL PROTECTED]
Subject: Re: XSL instead of JSP


I don't know a lot about Cocoon, but I believe it is similar to Struts in
that it has a "master" servlet which is awakened by requests matching a
particular expression.  In that sense they are mutually exclusive.
Sometimes I'm tempted to consider the benefits of combining the two but I
always end up realizing its not an improvement.  For example, if you want
some view feature of struts, it would be better to do it in XSL with Cocoon,
not combining the two.

One way I can see a combination is where the app is basically struts, but an
include page (either through frames, templates, jsp:include or @ include )
is sourced from Cocoon.  Basically a portal with a window into Cocoon, since
iteraction with Cocoon is just a URL.  But still the two frameworks act
independently.

Taylor
- Original Message -
From: "Rapheal Kaplan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 09, 2001 3:26 PM
Subject: RE: XSL instead of JSP


> I intend to try to implement a way of using Cocoon with Struts.  It should
> actually not be extraordinarily hard.  Has anyone else done something
> similar?
>

RE: XSL instead of JSP

[Greg Reddin]

We're at the end of the process of writing a pretty large app using Struts with
XSL instead of JSP.  Like you, most of our data was represented as XML
internally.  However, if I was doing it again, I'd probably use JSP.

Here's what we've done.
We get XML data from the backend.  For each request we keep an object at request
scope that represents our "messages".  We merge the backend data with literals,
web app data, etc. into that message.  We have one JSP that invokes Xalan to do
the transform.  To accomplish this approach we extended Struts 0.5 a bit to
force it to pre-process and post-process the message on each request.

This approach works, but it's rather "kludgey".  We had to open up our backend
to XML, but in hindsight, we should have made our app J2EE-centric instead of
XML-centric.  XML would have worked much better as an adapter layer, and Struts
would work much better with JSP.  Much painful work that performs poorly would
have been avoided.

But that's not to say that it can't be done well.

-Original Message-
From: [EMAIL PROTECTED] 
Sent: Monday, May 07, 2001 7:20 PM
To: [EMAIL PROTECTED]
Subject: XSL instead of JSP


Has there been a discussion on using XSL/XML for the
view portion of Struts?  If not, does anyone have any
ideas on how to proceed.  I need to add this
functionality.  This development will gladly be
submitted to Apache.

Some vague ideas on how to use XSL:
-add a  section to struts-config.xml
-add a package org.apache.struts.view
-add ViewServlet, View, etc
-Xalan support

A few reasons to use XSL:
-Most of my application data is already stored in XML.
-I have more experience with XSL than JSP.
-XSL gives less power to the GUI designer. :)


thanks
Paul Flynn


__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Re: XSL instead of JSP

[Mike Williams]

Pat,

I agree with you.  Believe me it's not by choice that I'm doing this! 
Unfortunately, I haven't been able to convince management and customers 
:(  We're not going to scrap the browser based side anyway.  For a lot 
of our clients this is a better solution.

I haven't given up the fight but, I have to get this solution together 
first.  The biggest problem with our webapp is that we picked the wrong 
commercial framework in the beginning and are now paying the price.  The 
worst part about it is that most of the current development team wasn't 
around when the choice was made and we're paying the price :(

There is still hope.  Looks like some of our clients that want to stick 
with the browser based app are wanting better performance.  I see an 
opening for a rewrite with a better framework.., bet you can guess which 
one I'll pick :)

Mike


Ludwig, Pat wrote:

> hi,
>with no offense meant, isn't the notion of promoting non-browser-like
> clients counter-productive to one of the basic benefits of network
> programming such as code maintenance and distribution? i certainly
> understand that this may be the best solution for some intranet and legacy
> apps, but it comes with a significant cost.  whether you communicate with
> these fat clients using SOAP or any other protocol, it doesn't change the
> fact that you have a substantial non-standard code resource on the client
> which will require periodic upgrades and bug fixes.  browsers remain
> frustratingly difficult to program sophisticated UI, but shouldn't we be
> focusing more on making browsers better client platforms than scrapping the
> benefits of zero client maintenance with custom clients?
> 
> Pat Ludwig
> Silverstream Software
> 
> 
>> -Original Message-
>> From: Joaquim Carvalho [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, May 08, 2001 8:28 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: XSL instead of JSP
>> 
>> 
>> I think one way to go would be to implement a SOAP layer on top of
>> struts.
>> SOAP is a protocol to expose the functionality of an application to a
>> remote client through the use of XML requests/and answers
>> travelling on
>> top of http. Typically a SOAP client constructs a remote call to the
>> server much in the same way as a web form is filled with
>> information in
>> a browser. A post of this xml call could be sent to a struts
>> app where
>> it would be decoded in the same way a form is, creating the
>> form beans
>> and all that. The struts app them, instead of rendering the answer in
>> HTML would render it in XML according to the SOAP answer specs. The
>> client application can be done in anything that can write and read to
>> http connection.
>> 
>> Check the SOAP project at xml.apache.org to get the idea of the thing
>> although that particular project is not directly usefull in
>> this context.
>> 
>> Some time ago I though of this and even inquired the list if this
>> SOAP/STRUTS idea was interesting but  got no feed back and moved to
>> other things. My recollection is that it would be easy to
>> extend struts
>> to recognize a XML post  besides of a Form Post and so SOAP
>> and Struts
>> could be easily mingled.
>> 
>> I have just finished a project of converting a legacy C web app to a
>> SOAP/Web app and the result is very encouraging. The same
>> code that is
>> answering the direct browser requests also handles requests
>> from clients
>> written in VisualBasic. We even have APSs as XML clients of our app.
>> 
>> 
>> 
>> On Monday, May 7, 2001, at 10:24 PM, Mike Williams wrote:
>> 
>> 
>>> Guess I'll add my 2 cents :)  I'm also researching using XML in the
>>> view component of struts.
>>> 
>>> My needs may be a little off from what you're looking at
>> 
>> though.  We
>> 
>>> have a application that currently runs as a web app.
>> 
>> However, some of
>> 
>>> our clients are a bit spoiled to the GUI of a desktop app.
>> 
>> So, I need
>> 
>>> to leverage our current expertise in servlets to interact with a
>>> desktop application.  That's where I hope XML will come into play.
>>> 
>>> The idea is to use Struts as the framework since we will
>> 
>> probably still
>> 
>>> have some clients using the web based system.  Hey, that's
>> 
>> the power of
>> 
>>> the MVC pattern after all.  You can easily plug a different
>> 
>> view in and
>> 
>>> everyone is happy :)
>>> 
>>> XML will basically be a messaging protocol between the client and
>>> server.
>> 


-- 



Mike Williams
[EMAIL PROTECTED]
http://www.mikesbox.com

May the Source be with you!

cvs commit: jakarta-struts/src/share/org/apache/struts/upload DiskMultipartRequestHandler.java MultipartIterator.java

[mschachter]

mschachter01/05/09 17:56:54

  Modified:src/share/org/apache/struts/upload
DiskMultipartRequestHandler.java
MultipartIterator.java
  Log:
   - Modified DiskMultipartRequestHandler to attempt to retrieve the value of
 the ServletContext attribute "javax.servlet.context.tempdir" before
 all other possible temporary directories specified
   - Fixed bug in MultipartIterator that incorrectly parsed filenames from
 windows file server
  
  Revision  ChangesPath
  1.9   +14 -14
jakarta-struts/src/share/org/apache/struts/upload/DiskMultipartRequestHandler.java
  
  Index: DiskMultipartRequestHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/DiskMultipartRequestHandler.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- DiskMultipartRequestHandler.java  2001/04/11 22:56:19 1.8
  +++ DiskMultipartRequestHandler.java  2001/05/10 00:56:54 1.9
  @@ -192,20 +192,20 @@
* property, or a system property, in that order
*/
   protected void retrieveTempDir() { 
  -//get a handle to some temporary file and open
  -//a stream to it
  -tempDir = servlet.getTempDir();
  -if (tempDir == null) {
  -//attempt to retrieve the servlet container's temporary directory
  -ServletContext context = servlet.getServletConfig().getServletContext();
  -
  -try {
  -tempDir = (String) 
context.getAttribute("javax.servlet.context.tempdir");
  -}
  -catch (ClassCastException cce) {
  -tempDir = ((File) 
context.getAttribute("javax.servlet.context.tempdir")).getAbsolutePath();
  -}
  -
  +
  +//attempt to retrieve the servlet container's temporary directory
  +ServletContext context = servlet.getServletConfig().getServletContext();
  +   
  +try {
  +tempDir = (String) 
context.getAttribute("javax.servlet.context.tempdir");
  +}
  +catch (ClassCastException cce) {
  +tempDir = ((File) 
context.getAttribute("javax.servlet.context.tempdir")).getAbsolutePath();
  +}   
  +
  +if (tempDir == null) {
  +//attempt to retrieve the temporary directory from the controller
  +tempDir = servlet.getTempDir();
   
   if (tempDir == null) {
   //default to system-wide tempdir
  
  
  
  1.13  +4 -0  
jakarta-struts/src/share/org/apache/struts/upload/MultipartIterator.java
  
  Index: MultipartIterator.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/MultipartIterator.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- MultipartIterator.java2001/04/18 14:21:20 1.12
  +++ MultipartIterator.java2001/05/10 00:56:54 1.13
  @@ -182,6 +182,10 @@
   //from linux jdk's the entire filepath
   //isn't parsed correctly from File.getName()
   int colonIndex = filename.indexOf(":");
  +if (colonIndex == -1) {
  +//check for Window's SMB server file paths
  +colonIndex = filename.indexOf("");
  +}
   int slashIndex = filename.lastIndexOf("\\");
   
   if ((colonIndex > -1) && (slashIndex > -1)) {
  
  
  

cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

[craigmcc]

craigmcc01/05/09 19:31:37

  Modified:src/share/org/apache/struts/action ActionServlet.java
  Log:
  Allow initDataSources() to throw ServletException like the other
  initialization methods do, to indicate a fatal initialization error.
  
  PR: Bugzilla #1672
  Submitted by: Jim Richards <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.67  +9 -5  
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
  
  Index: ActionServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
  retrieving revision 1.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- ActionServlet.java2001/04/23 22:45:36 1.66
  +++ ActionServlet.java2001/05/10 02:31:35 1.67
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v 1.66 
2001/04/23 22:45:36 craigmcc Exp $
  - * $Revision: 1.66 $
  - * $Date: 2001/04/23 22:45:36 $
  + * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v 1.67 
2001/05/10 02:31:35 craigmcc Exp $
  + * $Revision: 1.67 $
  + * $Date: 2001/05/10 02:31:35 $
*
* 
*
  @@ -228,7 +228,7 @@
* 
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.66 $ $Date: 2001/04/23 22:45:36 $
  + * @version $Revision: 1.67 $ $Date: 2001/05/10 02:31:35 $
*/
   
   public class ActionServlet
  @@ -1048,8 +1048,10 @@
   /**
* Initialize use of the data sources associated with this
* application (if any).
  + *
  + * @exception ServletException if a fatal initialization error occurs
*/
  -protected void initDataSources() {
  +protected void initDataSources() throws ServletException {
   
   synchronized (dataSources) {
   Iterator keys = dataSources.keySet().iterator();
  @@ -1063,6 +1065,8 @@
   ((GenericDataSource) dataSource).open();
   } catch (SQLException e) {
   log(internal.getMessage("initDataSource", key), e);
  +throw new ServletException
  +(internal.getMessage("initDataSource", key), e);
   }
   }
   getServletContext().setAttribute(key, dataSource);
  
  
  

Re: cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

[Jim Richards]

Man I love open source ...

>   Modified:src/share/org/apache/struts/action ActionServlet.java
>   Log:
>   Allow initDataSources() to throw ServletException like the other
>   initialization methods do, to indicate a fatal initialization error.
> 
>   PR: Bugzilla #1672
>   Submitted by: Jim Richards <[EMAIL PROTECTED]>

Scheduled Events

[Taylor Cowan]

What do you folks think about a scheduled event daemon?  J2EE doesn't cover
this, I don't think any other frameworks do it yet, and it is similar to
request event handling except the events are "anonymous" and don't contain a
request object.

It could be implemented around a server startup servlet which reads a config
file, much like the Action servlet, and at designated intervals invokes the
"action" class specified in the config file.  Instead of passing in the
request object it would only be able to send the servlet context.  There are
a lot of uses for something like this, for instance, downloading messages
from a pop3 server, checking load info and sending out warnings, or anything
that we might have used cron to do 'back in the day'. (Well, some of you may
not know what Cron is and it's probably better that way ).

I suppose it could be implemented entirely separate to Struts, however, it
would make a nice addition.

Taylor Cowan

Re: Scheduled Events

[Taylor Cowan]

I quick look through "Turbine" and I found it.  Never mind.

Taylor
- Original Message -
From: "Taylor Cowan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 09, 2001 9:40 PM
Subject: Scheduled Events


> What do you folks think about a scheduled event daemon?  J2EE doesn't
cover
> this, I don't think any other frameworks do it yet, and it is similar to
> request event handling except the events are "anonymous" and don't contain
a
> request object.
>
> It could be implemented around a server startup servlet which reads a
config
> file, much like the Action servlet, and at designated intervals invokes
the
> "action" class specified in the config file.  Instead of passing in the
> request object it would only be able to send the servlet context.  There
are
> a lot of uses for something like this, for instance, downloading messages
> from a pop3 server, checking load info and sending out warnings, or
anything
> that we might have used cron to do 'back in the day'. (Well, some of you
may
> not know what Cron is and it's probably better that way ).
>
> I suppose it could be implemented entirely separate to Struts, however, it
> would make a nice addition.
>
> Taylor Cowan

cvs commit: jakarta-struts/src/share/org/apache/struts/actions ForwardAction.java IncludeAction.java LocalStrings.properties

[craigmcc]

craigmcc01/05/09 20:13:36

  Modified:src/share/org/apache/struts/actions LocalStrings.properties
  Added:   src/share/org/apache/struts/actions ForwardAction.java
IncludeAction.java
  Log:
  Add standard actions that let you integrate other web application
  components via RequestDispatcher.forward() and
  RequestDispatcher.include(), but still take advantage of the preprocessing
  performed by the controller servlet (such as auto-population and
  validation of ActionForm beans).
  
  Revision  ChangesPath
  1.2   +5 -0  
jakarta-struts/src/share/org/apache/struts/actions/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/actions/LocalStrings.properties,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LocalStrings.properties   2001/03/29 18:41:53 1.1
  +++ LocalStrings.properties   2001/05/10 03:13:33 1.2
  @@ -4,3 +4,8 @@
   dispatch.method=Action[{0}] does not contain method named {1}
   dispatch.parameter=Request[{0}] does not contain handler parameter named {1}
   dispatch.return=Action[{0}] invalid return type for method {1}
  +forward.path=No context-relative URI specified via the 'parameter' attribute
  +forward.rd=Cannot create request dispatcher for path {0}
  +include.path=No context-relative URI specified via the 'parameter' attribute
  +include.rd=Cannot create request dispatcher for path {0}
  +
  
  
  
  1.1  
jakarta-struts/src/share/org/apache/struts/actions/ForwardAction.java
  
  Index: ForwardAction.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/actions/ForwardAction.java,v 1.1 
2001/05/10 03:13:32 craigmcc Exp $
   * $Revision: 1.1 $
   * $Date: 2001/05/10 03:13:32 $
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999-2001 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Struts", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   */
  
  
  package org.apache.struts.actions;
  
  
  import java.io.IOException;
  import javax.servlet.RequestDispatcher;
  import javax.servlet.ServletException;
  import javax.servlet.http.HttpServletRequest;
  import javax.servlet.http.HttpServletResponse;
  imp

Re: cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

[Craig R. McClanahan]

On Thu, 10 May 2001, Jim Richards wrote:

> 
> Man I love open source ...
> 

Me too :-)

Craig

> >   Modified:src/share/org/apache/struts/action ActionServlet.java
> >   Log:
> >   Allow initDataSources() to throw ServletException like the other
> >   initialization methods do, to indicate a fatal initialization error.
> > 
> >   PR: Bugzilla #1672
> >   Submitted by: Jim Richards <[EMAIL PROTECTED]>
> 

Re: Scheduled Events

[Craig R. McClanahan]

On Wed, 9 May 2001, Taylor Cowan wrote:

> What do you folks think about a scheduled event daemon?  J2EE doesn't cover
> this, I don't think any other frameworks do it yet, and it is similar to
> request event handling except the events are "anonymous" and don't contain a
> request object.
> 

I think this would be an intriguing addition.

I've seen approaches to this in Turbine, and (I think) Enhydra, but I
don't know of any specific implementations based on Struts.

> It could be implemented around a server startup servlet which reads a config
> file, much like the Action servlet, and at designated intervals invokes the
> "action" class specified in the config file.  Instead of passing in the
> request object it would only be able to send the servlet context.  There are
> a lot of uses for something like this, for instance, downloading messages
> from a pop3 server, checking load info and sending out warnings, or anything
> that we might have used cron to do 'back in the day'. (Well, some of you may
> not know what Cron is and it's probably better that way ).
> 

Ah, you should really say nice things about cron!  That's where your
nightly builds of Struts come from, after all.  :-) :-) :-)

> I suppose it could be implemented entirely separate to Struts, however, it
> would make a nice addition.
> 

It seems to me that a generic "background job scheduling" class library
would be the way to do this, with a Struts-based administration front
end.  The back end part of this might also be appropriate to consider for
the Jakarta Commons project  so that it
could be used (and enhanced by users of ;-) other environments as well.

> Taylor Cowan
> 

Craig

Need some help.......

[Jiten Mohanty]

Hi all

I am trying to set-up the logon programme which is available on 'bluestone'
site(Trail Map-6) and run on weblogic.But i am getting an error which is
mentioned below.

Parsing of JSP File '/logon.jsp' failed:


 /logon.jsp(2): Error in using tag library uri='/WEB-INF/struts-form.tld'
prefix='form': The Tag class 'org.apache.struts.taglib.html.ImageTag' has no
setter method corresponding to TLD declared attribute 'path', (JSP 1.1 spec,
5.4.1)
probably occurred due to an error in /logon.jsp line 2:
<%@ taglib uri="/WEB-INF/struts-form.tld" prefix="form" %>

Can somebody help me out.

Thanks

Jiten
Software Engineer
ip|SEAL Inc.
Colorado

Re: Need some help.......

[Craig R. McClanahan]

You should not be using struts-form.tld -- it is deprecated, and replaced
by struts-html.tld.

Craig


On Wed, 9 May 2001, Jiten Mohanty wrote:

> Hi all
> 
> I am trying to set-up the logon programme which is available on 'bluestone'
> site(Trail Map-6) and run on weblogic.But i am getting an error which is
> mentioned below.
> 
> Parsing of JSP File '/logon.jsp' failed:
> 
> 
>  /logon.jsp(2): Error in using tag library uri='/WEB-INF/struts-form.tld'
> prefix='form': The Tag class 'org.apache.struts.taglib.html.ImageTag' has no
> setter method corresponding to TLD declared attribute 'path', (JSP 1.1 spec,
> 5.4.1)
> probably occurred due to an error in /logon.jsp line 2:
> <%@ taglib uri="/WEB-INF/struts-form.tld" prefix="form" %>
> 
> Can somebody help me out.
> 
> Thanks
> 
> Jiten
> Software Engineer
> ip|SEAL Inc.
> Colorado
> 
> 

I'm back!

[Craig Tataryn]

Hi guys, I haven't been participating lately in the mailing list because
I recently moved from the US back to Canada so I haven't had too much
spare time.  Any how, now that I am settled in I would like to start
work on the Struts Workflow TODO.  I was wondering if anyone other than
my self and Nic would be interested in participating?

Also, my webserver was down the other day.  The owner had to do some
maintenance.  It's back up, and actually instead of using the old us-eh
address to get to my struts tutorial you can get to it via:

http://www.computer-programmer.org/articles/struts/

Ted, can you update your web page to point to the new
computer-programmer address?

Thanks,

RE: I'm back!

[Gogineni, Pratima]

Hi Craig,

I would love to participate in this.

pratima

-Original Message-
From: Craig Tataryn [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 09, 2001 10:55 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: I'm back!


Hi guys, I haven't been participating lately in the mailing list because
I recently moved from the US back to Canada so I haven't had too much
spare time.  Any how, now that I am settled in I would like to start
work on the Struts Workflow TODO.  I was wondering if anyone other than
my self and Nic would be interested in participating?

Also, my webserver was down the other day.  The owner had to do some
maintenance.  It's back up, and actually instead of using the old us-eh
address to get to my struts tutorial you can get to it via:

http://www.computer-programmer.org/articles/struts/

Ted, can you update your web page to point to the new
computer-programmer address?

Thanks,