Re: Included Actions

2001-08-01 Thread Dan Connelly



 
Gregor says: Output of an "included 
action" in a JSP.  I think I understand this.
 
I do something like it for my "Struts Inside of 
Struts" project.  In doing so I am pushing the FormBean concept to its 
logical (and absurd) conclusion.
 
My FormBean contains only a StringBuffer 
attribute.  The View JSP for this is extirely empty (almost) except 
for the expression of the StringBuffer.
 
The function of my (outer) Action is to just invoke 
an HTTP session on an inner Action (a Struts Action in some other application on 
some other server), then to capture the HTML output of that HTTP 
session, to modify some of its critical tag attributes and, finally, 
to stuff that HTML character stream into the StringBuffer of the 
ActionForm.
 
I really thought that this would have horrible 
display latency before I tried it.   Not really.  Its almost 
bearable.  But don't try it 3 deep.  
 
 
Dan Connelly    (who is 
not Dan Connolly)
 
 
 
PS.  
 
By the way, Struts works nicely for this absurd 
usage.  I will still claim I honored MVC, although my View is vacuous 
and the Model knows damn well how it is to be rendered 
(almost).   One disappointment in all this 
is java.net.HTTPSession.  It doesn't deal cookies, so this 
implementation has problems for Session Tracking under 
Struts.   
 
I am not the only person displeased by 
java.net.HTTPSession.  There are alternative classes that produce can 
transfer cookie values (from Tigris, for example).  I just haven't 
tried any of them yet. 
 
N.B., however, with respect to Struts, that 
if my action form's (viewable) text is really 
huge, StringBuffer is not goint to work out.  Struts would have to be 
re-architected into producer-consumer threads for the Model logic and the View 
(rendering) logic, respectively.  This is an interesting 
thought.
 
  
 
- Original Message - 
From: "Gregor Rayman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 31, 2001 1:03 PM
Subject: Included Actions
> Hi all,> > is it somehow possible to include the 
output of an action in one JSP?> > Now, when I try to include a 
*.do page, the server complains, it cannot> forward to the action's jsp 
(of course, since I don't want to forward,> I want to inlcude).> 
> The only "solution" I've found, is to len the Action's perform 
method> return null and include the action (*.do) as well as the jsp. 
(Which> I really do not like, since then the including page plays the 
role of> the controller)> > Where should I start if I 
wanted to change the Action servlet, to include> instead of 
forward?> > (I include actions' output in my templates. Where one 
part is the content> and another part is the in an action generated 
menu)> > --> gR> > 


Re: OFFTOPIC: Solaris and Tomcat problems!

2001-07-02 Thread Dan Connelly

There is no compiler class (jar) distributed with Tomcat, out of the box.
Apparently there are none in open source.  Apache will only distribute open
source.

Of course, Sun (and others) distribute "tools.jar" (or equiv) gratis.
Modify your startup.sh (or is it setenv.sh ??) to include the tools.jar on
the Tomcat classpath.   Then all is well.


- Original Message -
From: "Mikkel Bruun" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 02, 2001 3:09 PM
Subject: OFFTOPIC: Solaris and Tomcat problems!


> This has nothing to do with struts, but I know this list has a couple of
> guru's and demigods lurking...
>
> I have just installed solaris 8 on an intel machine.
> I installed tomcat 3.2.2 and it runs the servlets examples without any
> problems...BUT
> There seems to be a problem running the jsp files...
> Whenever i request a jsp file it just freezes, and i get no respond...
> Looking into the matter I saw that the jsp was succesfully compiled to a
> .java file...BUT
> The jsp compiler seems to be endlessly looping in the translation, because
> it keeps writing the same line over and over again (until im out of disk
> space)...
> I looked into the tomcat mailling archives and saw that somebod had
> experienced this problem before, but I wasnt able to find a solution...
>
> Any suggestions
>
> thanks in advance...
>
> Mikkel
>
>
>
>




Re: Implementing 2 new scopes using Struts

2001-06-26 Thread Dan Connelly



You would think that the ALL WEB APPs scope 
(or hierarchicial scopes) would be easy to do.  It is not.  I had 
thought that by having one app run another app, the controlling app could 
"peek".   Doesn't work that way either.  (Too bad.)
 
One can fetch the sessionid's of other HttpSessions 
from the the HttpSessionContext.  However, this does not grant access to 
objects in the session scope of the other sessions (as I had once 
thought).  Prohibited by (7.3) of the Servlet Specification.
 
Craig McC. recently posted that the standard 
mechanisms are EJBs and (persistent) database.  I am intrigued with 
the idea of a hierachically scope managed by an EJB.  (The database 
thing is always possible but seems totally inelegant for this 
purpose.)   Has anyone tried to coordianate objects between app (in 
Struts) using EJBs?
 

  - Original Message - 
  From: 
  Jonathan 
  Asbell 
  To: [EMAIL PROTECTED] 
  
  Sent: Monday, June 25, 2001 8:23 AM
  Subject: Implementing 2 new scopes using 
  Struts
  
  I will be implementing new scopes using Struts 
  for our unique needs, and they need to be application 
  server independent.  
   
  One scope will work 
  across (between) web-applications:  Ex. user logs on, and an object 
  representing the users values and state is placed into a scope where ALL WEB 
  APPLICATIONS can see it.
   
  Another scope is 
  restricted to specified directories inside of an application:  Ex. 
  data saved would only be visible when inside a specific 
  sub-directory.
   
  I am currently examining 
  the 2.3 servlet spec.  Does anyone have any advice as to what to watch 
  out for in implementing this considering I want to be able to be 
  compatible with servlet containers in general and leverage container 
  management and web.xml configuration.  Could anyone refer me to some 
  specific sections in the servlet spec that you feel I should pay specific 
  attention to while I am doing this. 
   
  Thank you
  Jonathan


External Workflow Engine for Struts ??

2001-05-15 Thread Dan Connelly
Title: new window browser for each request



Has anyone tried connecting a Struts application to a 
back-end workflow engine?
 
For instance, WfTK is a workflow engine with 
a Source Forge distribution.  It demos with a Perl front-end but 
many web-ends are possible.  A Struts front end would be nice, probably 
nicer than most.  (But current work is on PHP.  Go 
figure.)
 
WfTK is written in C/Tcl./Tk.    There 
are some pure Java engines listed on Source Forge, but no distros out 
yet for them.   Doesn't matter.  I need only a loose coupling at 
this point.   WfTK has the essential features of Workflow.   
Seems to work OK.
 
An exercise like this would help to clarify 
Workflow requirements  within  Struts (Release 1.1), I 
think.


Re: Cookies and Clusters (Cookies)

2001-04-23 Thread \(Home\) Dan Connelly



I will reply to Malcolm Davis in two parts: 
Cookies, then (later) Clusters:
 
Cookies:
 
Yes, my presentation of the DHTML and JS stuff was 
a bit confusing.  And unnecessary.
 
Let me boil it down.   
 
What I was musing about was a hack (??) I had just 
seen in a non-Struts MVC app whereby the current page gets updated, in 
situ, through the cookie(s) that head-up an SC_NO_CONTENT 
page just sent from the server.  The JavaScript in the current page reads 
the cookie(s) and updates its own document model.  No screen 
flash.  Very smooth.  A nice MVC screen effect.  Think of the 
Color Chooser, the canonical MVC application.   Smooth 
updates.
 
Is it a hack?  Would we consider such a 
technique for Struts?
 
Of course, having the client code read cookies 
might be considered weird.  But why not.  This is the web.  We 
survived the frameset mish-mash.   Many B2B apps have captive clients 
on dedicated PCs.   If the app wants cookies, he should get cookies, 
right?  These are session cookies, not persistent cookies.  Privacy is 
not a big concern.  If the browser is loading up on cookies from other apps 
and maxes out, he gets a nice warning to quit screwing around.
 
I did not write this MVC-ish app that I am talking 
about.  I am merely testing it, aggresively, looking for hacks.   
I don't have access to the servlet code but I can see the cookies 
arriving at the browser.  No JSESSIONID there.  Just 4k of encoded 
state.   You ask, does this app use HttpSession?  Apparently 
not.  It bakes its own cookies, complex cookies.  
 
Bad.  Bad.  Bad.  
 
But I like it.   It contributes to 
MVC.  Why not do it, do it, do it??
 

  - Original Message - 
  From: 
  malcolm 
  davis 
  To: [EMAIL PROTECTED] 
  
  Sent: Monday, April 23, 2001 1:47 
AM
  Subject: RE: Cookies and Clusters
  
  Dan, 
   
  > Cookies get a 
  lot of bad press.  But, cookies (or complex URL encoding) are the 
  fall-back 
  > when session beans are not going to 
  be  used.   
  Many JSP developers will shun session > 
  beans because the app might get deployed on clustered servers 
  (reverse proxied).  > 
  Each POST might then be dispatched to a different JVM.  Session 
  beans were not shared > correctly among clustered JVMs until Servlet 
  2.3.  (Correct me if I am wrong.)   > 
  Nobody is there yet in the commercial offerings.
   
  iPlanet does, and I'm sure other vendors 
  do also.
   
  I'm a little lost here about the DHTML & JS stuff, 
  but you might have a misunderstanding about cookies. 
   
  You can turn cookies 
  off in the browser, but the Appserver should 
  implement them via 
  the jsessionid.  Cookies are 
  fine for a cluster environment.  
  
  The servlets must be marked as sticky, 
  meaning each subsequent request will 
  return to the correct 
  JVM.  Of course, this might depend 
  on the Appserver being 
  used, and how your 
  cluster is configured.At my present job, we have 3 machines running 10 
  JVM’s, a total of 30 JVM’sin the cluster. If your not using 
  session beans, are you using 
  HttpSession?
   
  - 
  malcolm


Cookies and Clusters

2001-04-22 Thread \(Home\) Dan Connelly



I have recently ran 
across this interesting, web app.  It is a quite MVC-ish with a 
Controller servlet and Model beans, but too much logic in the JSPs to be 
strictly Views (no taglibs).
 
This app features a page with a hierarchical, 
walking menu, somewhat like a "DHTML Labs" HierMenu.
 
However, each step through this menu hiearchy 
requires (??) an interaction with the web server.  [I leave open the 
possibility that the "walking" requests to the server might be overkill in 
this case.]
 
Fetching each successive level of  the 
walking menu from the server is handled in a complex JavaScript 
in this app.  This JS sends a request, a POST, to the 
controlller, giving the level in the hierarchy and the OPTION picked 
in the last traversed SELECT list.  The browser gets back a 
Status Code=204, NO CONTENT.   The screen is not updated, except as 
noted below.  The document model (including JavaScript) is not 
replaced.  The JS now examines the Cookies where it finds the encoded 
options for the next select list.  It then fills in that select list with 
the newly received options.  Very smooth screen changes.  The MVC 
ideal.     
 
(So OK, the graphics aren't so great.  It 
not really a HierMenu.  It doesn't really "walk"  The "menu" is 
fully extended to begin with.  The "unwalked" lists on the right are 
empty.  But its the same idea.  And it could scale up nicely beyond 
what DHTML could do with wimpey static hierarchies.)
 
Is this legal?  I think so.  It does seem 
to be what 204 (NO CONTENT) is intended to be used for.  So that's 
kosher.
 
Cookies get a lot of bad press.  But, cookies 
(or complex URL encoding) are the fall-back when session beans are 
not going to be used.   Many JSP developers will shun 
session beans because the app might get deployed on clustered servers 
(reverse proxied).  Each POST might then be dispatched to a different 
JVM.  Session beans were not shared correctly among clustered JVMs until 
Servlet 2.3.  (Correct me if I am wrong.)   Nobody is there yet 
in the commercial offerings.
 
Is there any one of us working on a taglib 
for Sruts with cookie hacks like this?  Or, am I going to 
get a well-deserved flaming for even suggesting the possiblity.
 
Dan Connelly  
(Not the famous guy at W3C).
 
 
 


Re: A Server-side Color Chooser, the Struts v. Barracuda Bake-off

2001-02-25 Thread Dan Connelly



 
The interesting thing about building a Struts Color 
Chooser app is that I am being forced to program the multiple update 
dependencies.  Each of my Color Views (five of them at last 
count) will be an Observer of all of the others, on the server-side.  This 
is not a problem in such a trivial case, but I am hoping to find a more general 
way of dealing with this.  (In another application I may want to modify an 
 collections on the fly this way.  Seems like this 
should work.)
 
For the Color Chooser I will render each Color View 
through a JSP into a separate mini-frame on the browser window.  I 
cannot resist referring to these dependent mini-frames as 
"framelets" (forgive me).   Each framelet will hold a 
minimal .   When any of these formlets 
(ugh!) gets submitted, I will need to update all the other 
framelets.  Since the HTTP allows only one response I will probably select 
a Master Color View for the single response to any form submission.  
(But in other apps, the update pattern may be much more complex.)
 
The standard references tell me that, in order to provide 
an update to each of the other framelets, I will have to supply an 
"onLoad" JavaScript as a knowledgeable loader in the rendering of the 
Master Color View.   That JavaScript program will explicitly load 
the subordinate Color Views.  (How to generalize??) 
 
I am beginning to understand the relevance of CRM's remark, in 
another context, that the JSP is a way to get a program to write a 
program.
 
(BTW.  I want to 
use Microsoft's "HyperText Component" slider widget, available at 
http://msdn.microsoft.com/workshop/c-frame.htm?/workshop/author/default.asp , in my Struts Color Chooser.  All the classic choosers 
use a slider.   It does not bother me that only IE 5.5 supports HTCs, 
also known as DHTML Behaviours.  Of course, there are potentially a huge 
number of these things.  Creating a new Struts tag for each one is not an 
option.  More problems of generalization.)
 


A Server-side Color Chooser, the Struts v. Barracuda Bake-off

2001-02-23 Thread Dan Connelly



 
The canonical MVC application in the GUI world is the 
Color Chooser.  
 
You will see the Color Chooser in standard texts on both 
Motif and Swing, but with very different implementations of the "Observer" 
pattern.  The Patterns people claim that the Observer is at the heart of 
MVC loose coupling.   I agree, although that pattern is 
an arch wide enough to drive several implementation buses 
through.
 
Your Java 2 jdk distribution probably contains a Color Chooser 
application under demo/jfc/SwingSet2.  However, that app is quite 
complex, more demo than tutorial.   The O'Reilly book by Eckstein, Lay 
and Wood has a more approachable example.  Source code is available in 
either case.
 
I propose that we have a "contest" to implement 
a Struts Color Chooser, with a goal being to provide as much as possible of 
the liveliness that one sees in the Java/Swing app and to support a 
server-side Color Database.   This is an exercise left to 
you, the reader.  It is not to be part of the Struts 
codebase.
 
You can find numerous examples of simple Javascript Color 
Choosers which operate totally on the client-side using very static color 
tables.  These "apps" do not have a sever-side except for the 
HTML pages.  To show off Struts, I want to add a server-side.  The 
Struts Color Chooser must support a database of Color 
Names.   However, that term database is loose.  It need not be 
persistent, but it must be accessible to all concurrent Color Chooser web 
apps.
 
So There will be a Color Model, with various Color Views 
(e.g., RGB Sliders, RGB Numerics, HSV Numerics and Color Names).   The 
various Views must update each other in timely fashion (somehow).  There 
should be a "ComboBox" allowing the user to scroll a (dynamic) database of Color 
Names.  There must be Color Actions for adding, editing and deleting Color 
Names on the shared database (which need not be persistent across 
server-side reloads of the Struts Color Chooser).  
 
We can try this in Struts, Baracuda, 
Turbine and Hammock (about which I know nothing).  You may also 
want to try it in your favorite scriptable template engine, but this would be 
unlikely to beat out any of the above four.
 
BTW, on closer reading of the Barracuda "Overview" I see that 
Barracuda does not (now) claim any mechanism to map client-side 
events to server-side handlers.  This is more limiting than I was 
expecting, given the rhetoric from Barracuda that would 
support a Swing-style Event/Listener model.   (But not for 
the Barracuda View ??)  I incorrectly imputed to Barracuda a desire for 
propagating client-side events when i posted comparing Struts to 
Barracude.  This is not true.  Like Struts, the only client-side event 
that Barracude builds in is an HTTP Request generated by a 
Form/Submit.)
 
On further consideration of the issue of event notification, I 
am less pessimistic about the "mud".  I do think that both Struts and 
Barracuda, in their current distributions, could host applications which 
implement client-side events that are notifiers to server-side 
actions.  This can be done with slightly less fuss than I previously 
imagined because the set of client-side events to be accommodated is already 
identified and limited.   There is a clear path to the 
application code to send notifications for these events.  But this 
code may be repetitious and inelegant.   That is 
the crux of the matter.
 
In Struts, the onXXX JavaScript handlers in the html 
tags be coded as event notifiers that interact with server 
actions.   I would guess (just guessing) that Baracuda wants 
to use Java applets for this.  The SOAP/Biztalk books 
now filling your local bookshop have examples of client-side 
events being sent server-side using 
JScript/SOAP/XML. The examples there are even more 
repetitious and inelegant, being totally in static HTML.  But this is how 
Microsoft captures a market and then sells its Visual tools.
 
As far as my contest is concerned, almost anything is 
fair.   I requre that at least one of the two "standard" 
browsers be supported in one of its standard realeases.  You can require 
any browser setting you need.  But, no plug-in or ActiveX downloads are 
permitted.  Also, you must build the application on top 
of some standard distribution of your chosen framework.  You may 
use any extensions that this framework permits, but you must not 
alter the framework in the cases where it is open source (Struts, Turbine, 
Barracuda).
 
The contest will be "judged" on the basis of both 
functionality and elegance.  The time limit should be very generous so that 
we can share ideas.  Say one year.
 
 
 
Dan Connelly
 


Re: How does Struts compare to Barracuda?

2001-02-20 Thread Dan Connelly



 
Okay, that's a good question.
 
Here is my instant analysis of Barracuda v. Struts.  
("Instant" and therefore probably worthless.  BTW, I haven't used 
Barracuda.  And my experience with Struts is confined to toy 
applications.)   
 
Barracuda has apparently bitten of the Event/Listener model 
as its top-priority task.  Struts has deferred this design decision 
until a later release.   And there certainly are a ton of more mundane 
concepts to work through.
 
The Event/Listener Model appears on the Struts 1.1 to-do 
list.  My guess is that it will actually not make 1.1, that it will be 
delayed until 2.0 because of the massive refactoring required.  Just 
guessing.
 
The Barracuda docs say that the Event/Listener Model is the 
crux of the matter for leveraging MVC on the Web.  Yes.  Yes.  
Yes.  Very True, IMHO.  You screw it up, you lose.
 
But also Very Difficult given the client-server division of 
labor in HTTP and the on-going Browser War.   (Just one war, 
obviously.)  
 
It does seem wise to me that Struts should not make a hasty 
decision on its Event/Listener Model, but not past the point where it would 
break everything to put it in.
 
When I worked on MVC apps in C++/Motif, we addressed this 
issue less generally, as Update Dependencies.  We 
compiled the UD declarations into Mapping objects using a 
preprocessor.   This seemed adequate for building lively apps and gave 
quite good performance, but Motif widgets had a much finer granularity of 
interaction in the application logic than do FormBeans.
 
Of course, the Swing-style Event/Listener Model is much 
more run-time oriented in its approach than is a UD 
preprocessor.  Java favors late binding.  C++ favors early 
binding.  It is a continuum.   Each Framework needs to pick its 
spot on this continuum regardless of its implementation language.
 
My guess, and it is just a guess, is that Struts will end up 
with some flavor of static UDs in the struts-config.xml, and that will be 
about the best you can do for HTTP Web apps.   
 
Barracuda will have to stick its hands very deeply into the 
DHTML mud to map the client-side events out to server-side objects.  This 
is a mess.  Once Barracuda is stuck there, then it falls victim to the 
"real" barracudas (the proprietary vendor interests) .  
 
If you need something very dynamic, very programmatic in 
your application's Event/Listener Model, then you need a different protocol 
than HTTP over the wire.  Period.   IMHO.  Surely X-style 
"GUI Servers" will become part of the Web in due time.  Same goes for 
Critrix-style "Terminal Servers".   (Were it not for firewalls, this 
would already be true.)   And if that doesn't happen, then look who's 
betting on SOAP (nee XML-RPC) to put events (as RPCs) on the 
wire.   Clever marketing can easily morph SOAP into an 
Event/Listener Model on its own, eventually escaping HTTP 
altogether.    
 
Struts is wise to avoid this fray, for now.    
But, I'll bet that others in the Struts community feel strongly just the other 
way, that early engagement would be best.   Maybe Barracuda 
has already done succeeded in mapping client-side events.  ??
 
 
Dan Connelly 
 
 
 
 
 
 
- Original Message - 
From: "Johan Compagner" <[EMAIL PROTECTED]>
To: "Struts" <[EMAIL PROTECTED]>
Sent: Tuesday, February 20, 2001 7:28 AM
Subject: How does Struts compare to 
Barracuda?
> Here is the link:> 
http://barracuda.enhydra.org/Barracuda/> 
> Can we learn something from it?> Is it better or worse?> 
> Johan> > 


Re: Strange Error with

2001-02-19 Thread Dan Connelly



This one came up earlier this month.   Nothing to do 
with  per se.  A large number of tags on a page can 
cause this. 
 
Check the archive at http://marc.theaimsgroup.com/
 
Search struts-user for the topic "Illegal target of branch or 
jump"
 
The last post on that topic says that the cure is 
to give yourself more heap in the JVM with -mx and -ms
 
(I wonder if its really more stack 
space per thread that on needs for a large number of tags on a JSP 
(??).  I haven't looked into it, but stack(s) are usually more fragile 
than heap in multi-threaded system.)
 
- Original Message - 
From: "Neal Kaiser" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 19, 2001 9:45 AM
Subject: Strange Error with 

> I am using Orion 1.4.7. I 
don't know if this is an Orion bug, or possibly> Struts?  I have a 
jsp which uses the include directive to read in a list of> 
countries:> > > The jsp looks like this:> > 
> <%@ 
include file="../util/countries.jsp" %>> > 
> > And the countries.jsp is something like this:> 
..> Tuvalu> 
U.S. Virgin Islands > 
Uganda> > If I 
have 223 lines in my countries.jsp file, it works, no problem. However,> 
if I go over 223 lines (no matter what line it is) I get this error:> 
> Error parsing JSP page /galacy/register/layout.jsp> > 
Error creating jsp-page instance: java.lang.VerifyError: (class:> 
__jspPage28_register_regstep2_jsp, method: _jspService signature:> 
(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletRespo> 
nse;)V) Illegal target of jump or branch> > I just tried putting 
the select list in the .jsp rather than using an> include -- same 
error.> > I am leaning towards this being a container bug, not a 
Struts one. But I> just wanted to verify and make sure this wasn't know 
with Struts first...> > Thanks, Neal> 


Re: More HTML element examples []

2001-02-18 Thread Dan Connelly



 
Robert Taylor wrote:

> I've been through the examples included in the struts0.5 
release.> Specifically I'm looking for examples of using the 
 element with> dynamically generated . I 
have seen the  element and read> its definition but still 
am unclear on how to use it.> 
I, too, found the documentation inadequate in this 
area.   However, the question has apparently been brought up on this 
listserv before.   There are examples in the listserv archive.  
The fundamental idea is the same as is used for the "User Database" in the 
Example example.
 
Have a look at http://marc.theaimsgroup.com/    
Its a searchable Mail ARChive (MARC) covering this listserv (and lots of other 
interesting ones too).  Just search on "options" for 
struts-user.
 
The thread "Need some help please" explores the use of the 
 tag.  (The "Subject" text here could use some help!  
But, Hey, the same goes for "More HTML element examples".)   
Continuing...  The "Need some ... " thread is slightly 
misleading.  It has examples that use the  
tag.  I believe that that tag has now been replaced by 
, a switch which undoubtedly contributes to the confusion 
on this topic.
 
Also, have a look at the "Options Tag" thread (Yes, 
good Subject text here), but some indications in that thread that there are 
existing bugs in indexed array accesses.   (??)
 
Ted H's reply on the "Need some.."  thread indicates that 
a Struts "collection"  should be synthesized from a "database."  
Maybe, maybe not.  I can see that a "static" collection, which is often we 
really want, would be better derived from a Properties file.  However, 
in either case, the preferred method in Struts for instantiating such 
a collection (for use with ) is to have an 
made-to-purpose application Servlet which you code up to do the "heavy 
lifting".  The collection get instantiated in that 
Servlet's init method, when the application is loaded into the server 
container.  Bottom line, you roll your own.  See 
"DatabaseServlet.java" in the Example app, for an example.
 
If you are reading Hans Bergten's book on JSPs, 
which discusses a Struts-like architecture, you might naively assume 
that the Struts built-in ActionServlet would contain some packaged support for 
cons-ing up your collections for you.  Not in Rev 1.0 by what I see.  
I don't see it on the Rev 1.1 ToDo list either, although "Better Database 
Support" could be stretched in that direction.  Maybe, in that 
case, we should be looking at better J2EE Support instead.  (IMHO 
Application Scope Bean collections are not at all the same thing as Persistent 
EJB collections, which is where "databases" really fit in.  Just my 
opinion.) 
 
OK.  OK.  I'm rambling.   
 
 isn't the only area where coding examples 
that use (ordered) collections under Struts would be helpful.  Has 
anyone got an example of  Previous 
and Next submit buttons to scan over a 
collection for FormBeans?  That should be simple, and nice.
 
Better yet, how about an example of 
an IE5.5-style Floating Popup containing a scrolling list of FormBean 
ids that would dynamically update of the parent page when clicked 
...?   OK.  I'm still rambling.   And futuring.  
(Except that it should be possible to do a very sweet, very MVC Floating 
Popup now, with Struts 1.0, if you limit yourself to IE5.5)
 
 
Dan Connelly
South Burlington, Vermont
 
 
 
 


Re: which development tool to use? (XML Editor)

2001-02-16 Thread Dan Connelly



Tag editor for struts:    Try Xeena from IBM 
Alphaworks.  
Its free; its Java; its fragile.   Create/edit like 
a Bean??  Dunno.
But Xeena works great for struts-config.xml, web.xml 
and deployment XMLs in general.
 
 
- Original Message - 
From: "Steven D. Wilkinson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 08, 2001 6:43 PM
Subject: Re: which development tool to use?
> Malcolm Davis 
wrote:> > > > 3.  Do you have a preference on Tag 
editors/creators?> > I'm looking for something that creates/edit tags 
like I would a bean.> > Does JBuilder Enterprise do this and I'm just 
missing something?> > > I only have JBuilder4 Professional, so 
I don't know what else the Enterprise> brings to the table other than EJB 
wizards.  > > I too am interested in something that 
creates/edits tags like a bean.  I haven't> found one yet.  If 
you hear of one please let us know on the mail list.> > 
Thanks,> Steve


Blank Newbie (on Tomcat)

2001-02-16 Thread Dan Connelly



 
Here is a solution, not a problem !
 
I recently posted to the struts-dev list that the new 
application, struts-blank, should include a blank form to 
be submitted, that I had trouble when I tried to add even the simplest form 
(although the un-edited application worked OK).  I suspected that I was 
making some Newbie mistake putting the form together.  I was.
 
Should you also have trouble with this, the Newbie problem (my 
problem, now solved) is that you must re-deploy the application if you make a 
change to the struts-config.xml.   (Is this obvious?  It wasn't 
to me.   In fact, the splash screen on struts-blank implies 
otherwise.)
 
The splash screen on struts-blank tells you that you can just 
edit, seemingly everything, seemingly after deployment, while Tomcat is 
running..  
 
Yes.  You can do this for index.jsp.  It 
works.  No problem.  So you press on.
 
You can also write the code and add your BlankForm 
class and your BlankAction class in situ to /WEB-INF/classes while Tomcat 
is running.   No problem.
 
However, when you edit struts-config.xml (as you must do 
to incorporate the BlankForm and the BlankAction into the application), 
then you must re-deploy.  (Well, its slightly easier on 
Tomcat.) 
 
The struts-config.xml is ingested on deployment, not whenever 
index.jsp runs (as a Newbie might suppose).  However, on Tomcat you 
can still edit struts-config.xml in situ, instead of remaking the WAR, which you 
could also do.   But, in either case, you must shutdown and 
(re) startup Tomcat to get have your changes to struts-config.xml 
made effective.  (J2EE platforms allow dynamic deployment.)
 
 


Struts/Motif

2001-02-10 Thread Dan Connelly


Struts for Motif.  Okay, wash my mouth out with SOAP!

But, look, lots of neat, old X/Motif applications were written using the MVC
architecture.

What good did it do X, Motif, ... or MVC?

And, don't try blaming it all on the X Server being such a heavy "client".
On the other hand, don't try to claim that the Web-way is the only way.

[We could also consider Struts for Swing, but that clouds the argument I am
about to make.]

A Motif MVC app I recently worked on had MVC features similar to Struts,
like an action map "digester".  Well, the Motif app digester was written in
awk and it was a preprocessor.  The mappings got compiled into the code.
But it was similar, a nice high level view of the internal data
architecture.


Unfortunately, I also see some disturbing similarities between the
weaknesses of MVC Motif (as commonly programmed) and Struts, such as



1.   A difficult and impoverished widget set.

For instance, do we have a high-level Tree widget to plug into Struts?
Having third-party Tree widgets and scripting hacks for Trees didn't make
Motif competitive with the Win-mill.  ( ?? "COMpetitive"  ??)

 2.  Ad hoc Database-to-Model mappings.

For instance, if a number of browser sessions, perhaps hierarchically
related browser sessions, are looking at the same Persistent EJBs, how do
these sessions coordinate their separate (hierarchical) Models?  Their
database updates?  Their screen Updates?   Is this to be left to the realm
of "Business Logic"?   It's system logic, for sure.It invites trouble to
let the bit jockeys be responsible for getting this right, for buggering the
MVC.


The Motif MVC app I worked on used the windowing hieirachy in X/Motif to
build a Model hierarchy of database views.  This was very ad hoc, very
quirky and quite buggy, but nice.  Or so I thought.   The nuances escaped
many in the user community.  And, eventually the programmers also lost track
of the ad hoc programming needed to sustain the Model hierarchy.   So it
goes.

But, jeez, it did make for a very lively GUI when it all went well, with
model changes rippling from window to window.  Made Win-doze apps look
absolutely static in comparison.  Unfortunately, I don't see much (yet) in
Struts to make a more dynamic display out of (hierarchical) web browser
sessions.   Or, is this just a feature in search of an audience??


Dan Connelly





Ted's FAQ "What Web sites are already Powered by Struts?"

2001-02-07 Thread Dan Connelly




  Brewtrade - http://java-genius.com/ 
  TeaTimeJ - http://www.webappcabaret.com/teatimej/ 
  
What!  Only two public sites powered by Struts?  And, 
java-genius.com always gives me a DNS error anyway.  So there's really only 
one site in this list that I would dare suggest to people who ask me 
about Struts in the real world.
 
There must be more public sites than this.   There's http://jakarta.apache.org/struts  at 
least (although it doesn't do anything showy).
 
Please help me explain to MVC-clueless colleagues and bosses why I am 
spending so much time getting into Jakarta Struts (as opposed to the 
superficially similar, released, commercial, freely downloadable JSP 
taglibs, like Allaire's JRun Tag Library or WDIG's 
TeaServlets). Please post up some additions to 
Ted's list.
 
Also, how about adding more "Struts competitors" to my 
list of two?  (And, while you're at it, do the competitive 
analysis.)
 
Dan Connelly  (who is not Dan Connolly, W3C)
 
 


WEB-INF/lib problems

2001-01-28 Thread Dan Connelly



 
I am new here, and new J2EE deployment issues.  Forgive 
me if these observations are naive.
 
I gather from recent complaints on this list that 
deployment of struts WARs into J2EE environments (with the WARs 
packaged into EAR files) is not working as expected.  The 
struts.jar isn't getting cpath'ed from the demo apps WEB-INF/lib at 
deployment time, or gets put in some sub-directory of WEB-INF/lib, where it is 
not found.  
But, the struts demos do work OK on stand-alone Tomcat (if you use 
Xerces and avoid JAXP).   
 
One workaround people try is to put struts.jar into the j2ee 
server's CLASSPATH, but this is a bad idea because j2ee is an "embedded 
environment", ie, a total platform into which apps are installed 
dynamically.  Anyway, juking the CLASSPATH just causes other 
problems (in "example" for example).
 
(Rough summary of various threads.)
 
I am seeing this too. I my case the problems are on the 
freebee j2eesdk1.2.1 server that I downloaded from Sun.  This may be 
related to the WL and iPlanet problems that others have reported.  (Except 
that you paid good money for that software and you are getting excellent support 
from your vendor, right?  No annoyance issues, right?)
 
The Sun Bug Report I have posted below seems 
relevant to these problems.  I kept thinking that Sun must know about 
(and would quickly fix ??) such an obvious problem in their own SDK 
implementation.  So I kept searching their site for such a fix.  
Apparently not.  Perhaps deadlines are tight at Sun.
 
Anyway, .
 
This particular Bug Report is quite old and is 
listed as closed.  But, skeptic that I am, I am not convinced that it was 
fixed anywhere but on Tomcat.   And it could be that various 
commercial implementations of j2ee (inlcuding the Sun "reference") employed 
workarounds for this bug, which ended up as regressions. 
 
Also, what does "javaxservlet:api 3.0beta" mean in this 
context, given that the latest Servlet API I know of is Release 
2.3.
 
 
Dan Connelly  (who is not Dan Connolly, 
W3C, but likes his ideas anyway)
 
 
 
 
 

  
  
Bug 
  Id 
4282385
  
Votes 
0
  
Synopsis 
ServletLoader cannot load 
  jars from WEB-INF/lib directory.
  
Category 
javaxservlet:api
  
Reported Against 
  
1.1beta
  
Release Fixed 
  
3.0beta
  
State 
Closed, 
  fixed
  
Related Bugs 

 
  
Submit Date 
  
Oct 18, 
  1999 
  
Description 
jcheck tests are failing with both tomcat and j2ee.  You did not
see it fail when running under tomcat because moo.jar is in
the classpath when you started tomcat web-server.

So, the tomcat server found all the classes.

But on J2EE, (where there is no classpath related issues) you
saw all of them fail because the ServletLoader is unable to
load up classes.

Here is the problem with the ServletLoader as it exists today:

It can load classes from the WEB-INF/classes and
WEB-INF/lib directories but it *cannot* load *jars* from the
WEB-INF/lib directory.

I am going to file a bug against the tomcat implementation.

Meanwhile, I have a suggestion to whoever is responsible
for jcheck. Please *do not* start the tomcat server with
any more classes than whats required. Can you or
anyone else in your team remove moo.jar from the classpath?




  
Workaround 
None.
  
Evaluation 
in an embedded environment (ie j2ee) and for war
docbases tomcat was not able to access WEB-INF/lib/*jar
classes due to the fact that the war protocol handler
registration moved from server package to the optional
shell package and thusly was not made available to the
hosting environment.

the fix involved modifying the protocol handler to manage
both war and jar uri's alike and update the ServletLoader
to generate "jar" uri references (vs war uri references)
so that for environments which have a specified war protocol
handler (eg tomcat/jdk1.1.x) will get work as well as
environments which which run on jdk1.2.x where JarUrlConnection
is natively available. cool fix.


x@x 1999-10-28