RE: Tomcat 4.1.x

2002-09-25 Thread Russ Bonsall


You need to add an admin role to one of the users.  I worked for me
anyway.

Russ

-Original Message-
From: Peter A. J. Pilgrim [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 24, 2002 8:45 PM
To: Struts Developers List
Subject: Re: Tomcat 4.1.x


David Graham wrote:
 I think he already found his problem but yes I do have a better idea 
 :-).  You could just put a breakpoint before calling PropertyUtils and 
 step through the struts code until the exception is thrown.  Then you 
 could inspect the variables surrounding that situation.
 
 Dave
 

BTW: I just downloaded Tomcat 4.1.12 just now. I cant get into the
`/admin' web application. I thought the username and passwords were in
`$CATALINA_HOME/conf/tomcat-users.xml'

Anyone know the correct credentials?

-- 
Peter Pilgrim +-\ +-+++++
Java Technologist | | | ||||| 'n' Shine
   |  O  | | ||  --+| ---+
 /\| ._  / | | \  \ ||
/  \   | | \ \ | |+--  || ---+ A new day
   /_  _\  Up| | | | | ||||| is coming
 ||+-+ +-+ +-+++++
home page=http://www.xenonsoft.demon.co.uk/; /


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

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




RE: [Core] Truly global globa-forwards

2002-09-19 Thread Russ Bonsall


Just thought I would chime in as another developer that finds the idea of a
hierarchy of modules most useful.  Hopefully you don't find my comments to
verbose.

My company has decided to move forward with using Struts for one of our
applications that is being migrated from a client-server app to a web-based
app.  It was obvious that we would benefit from using the Struts framework.
We created some prototypes to prove its usefulness and see if it could
handle some specific customer requirements.  

While creating some prototypes we wanted to leverage the sub-apps that
Struts 1.1 provides.  We found, however, that the default module did not
behave as we expected.  We assumed that if we used messages or errors
(bean:message and html:errors) within a sub-app and the message was not
found in the message resources for that sub-app, that Struts would look to
the default app for the messages.  We did not like the idea of duplicating
messages across all sup-apps.  For example, most all of our modules will be
using messages for our buttons like Save, New, Cancel, Delete, etc. (we are
using i18n so it's not feasible to hard-code these).  We wanted to define
these once in the message resources for the default app and override the
message in the sub-app as necessary.

We have since extended the framework to handle this scenario since we also
needed to fulfill a customer requirement that allows the customer to switch
between customer-defined labels and system-defined labels.  

We haven't extended the framework to deal with global forwards in the same
fashion yet, but I'm sure we will need to do so as well.

So, in short we would love to see the hierarchy of modules idea apply to
sub-apps.

Russ


-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 14, 2002 4:53 PM
To: 'Struts Developers List'
Subject: RE: [Core] Truly global globa-forwards


The issue here is the model for module usage.

The current design came about primarily as a solution for the problem of
development scalability. On a large project, having several people making
frequent changes to struts-config.xml gets out of hand rather quickly.
Breaking the application into modules allows multiple teams to develop their
modules independently.

The usage model is multiple independent modules that have little or no
communication between them. All modules are treated the same, with the
default module's *only* distinguishing characteristic being the lack of a
prefix. The existence of a default module is primarily for backwards
compatibility reasons. It has no special status in a Struts app.

This is quite different from the usage model that I needed for my web app,
and I think from what you are looking for too. What I needed is a hierarchy
of modules. The root module is two things - a framework into which the
remaining modules are plugged, and a set of shared behaviours useful to
those other modules. To build this, I needed to extend Struts in several
ways so that I have a comprehensive hierarchical model.

The reason I referred to using the default module for truly global
forwards, by itself, as hacky is because it confuses the usage model. The
modules are no longer independent, per the current design, but they don't
form a true hierarchy either, because all the other pieces needed for a
fully hierarchical application are missing.

Ultimately, what we want to do is collect information on how people are
using modules, and how they want to be able to use them, and think through
the design issues of the various usage models. Then we'll be able to take a
more comprehensive look at how we might incorporate multiple models into the
Struts code base.

To respond to a couple of other points you made:

* I can't put my code into contrib, sorry - it belongs to my employer, not
to me individually.

* Forward patterns were added for 1.1-b2. It's mentioned briefly in the
release notes, but the only real description is currently here:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10268

Note, however, that $A was subsequently changed to $M.

--
Martin Cooper


 -Original Message-
 From: Eddie Bush [mailto:[EMAIL PROTECTED]]
 Sent: Saturday, September 14, 2002 12:04 PM
 To: Struts Developers List
 Subject: Re: [Core] Truly global globa-forwards
 
 
 (this started on struts-user -- see thread of same name there for 
 background)
 
 Martin Cooper wrote:
 
 I can't say for sure whether this is likely to become part 
 of the Struts
 core or not. However, what you are asking gives us another 
 data point on the
 way modules are going to be used in Struts 1.1 apps.
 
 I think it's very logical that you would have the ability to 
 make use of 
 a global configuration (of most things) in addition to the 
 sub-application configuration (data-sources, properties, you 
 name it). 
  Craig, for compatability reasons I'm sure (and to simplify 
 things too, 
 I'd wager), made the application root yet another sub-app -- 
 and I