Re: JavaScriptTag and multiple forms.

[Adam Hardy]

On 04/04/2004 01:10 AM Joe Germuska wrote:
What if you were using ValidatorActionForm/DynaValidatorActionForm 
instead of ValidatorForm/DynaValidatorForm?  Then the server side 
validation rules are looked up based on the path, not the name.  With 
the form classes, this can be encapsulated cleanly in a way that is 
invisible in the struts-config, (and even more so thanks to Niall's 
recent patch)  But that's invisible to the html:javascript tag.

By the way, the names for those classes have to be one of the most 
confusing things about Struts; I only just really grokked the difference 
in the last couple of months, and most of the developers I work with are 
still kind of fuzzy about it.
I totally agree that the class names for ValidatorActionForm and 
ValidatorForm don't help. And the actual concept is something I am 
always forgetting.

Something like PathDefValidatorForm and FormDefValidatorForm. Perhaps 
something less cludgey.

Adam

--
struts 1.2 + tomcat 5.0.19 + java 1.4.2
Linux 2.4.20 Debian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JavaScriptTag and multiple forms.

[Adam Hardy]

I guess it's because the term 'Action' has become seriously over-used.



On 04/04/2004 11:48 AM Adam Hardy wrote:
On 04/04/2004 01:10 AM Joe Germuska wrote:

What if you were using ValidatorActionForm/DynaValidatorActionForm 
instead of ValidatorForm/DynaValidatorForm?  Then the server side 
validation rules are looked up based on the path, not the name.  With 
the form classes, this can be encapsulated cleanly in a way that is 
invisible in the struts-config, (and even more so thanks to Niall's 
recent patch)  But that's invisible to the html:javascript tag.

By the way, the names for those classes have to be one of the most 
confusing things about Struts; I only just really grokked the 
difference in the last couple of months, and most of the developers I 
work with are still kind of fuzzy about it.


I totally agree that the class names for ValidatorActionForm and 
ValidatorForm don't help. And the actual concept is something I am 
always forgetting.

Something like PathDefValidatorForm and FormDefValidatorForm. Perhaps 
something less cludgey.

Adam



--
struts 1.2 + tomcat 5.0.19 + java 1.4.2
Linux 2.4.20 Debian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Refactoring Struts Initialization (was RE: Splitting struts-config into multiple jar...)

[Joe Germuska]

This thread seems to have taken a turn into something I'm interested in;
too bad the subject didn't change with it so I could have started
following sooner.
You really didn't miss much yet...

I really don't like methods that throw Exception so I like
ServletException better.
No problem.  I just really don't like many layers of wrapper 
exceptions that make it hard to get to the root of the problem. 
ExceptionUtils in commons-lang helps, of course.  Anyway, in this 
case, it's unlikely that there will be many layers, so consider that 
changed.

IMO, Struts datasource handling should be deprecated and removed.  It had
it's place in the past but now Struts has no business "managing"
datasources; that's the containers job and most of them do it better than
Struts.  I would like part of Struts 2.x to focus on simplifying users'
lives and removing this feature follows in that spirit; but that may be
for another thread.
Well, I was thinking about doing this refactoring in a pre 2.x 
timeline and maintaining compatibility.  But I agree that datasource 
handling should be left out of Struts.


At this point isn't ActionServlet merely init. code plus delegation to the
RequestProcessor?  In the future ActionServlet may just be delegating to
init. classes and to Commons Chain so I agree that we should probably
limit passing it around.  It's really more of a starting point for a
request than anything else.
Yes, it is, but the PlugIn interface still calls for it.  Of course, 
the Servlet is already storing itself in Application context under 
Globals.ACTION_SERVLET_KEY, so I suppose we could leave it out of the 
interface while still maintaining backwards compatibility.  Since 
ActionServlet.datasources is protected and I was putting 
"ClassicConfigurator" in the o.a.s.action package, that's really all 
that's necessary to deal with both of these issues.

How does that sound?

Of course, ActionServlet is tangled up in the API for Action and 
ActionForm too, so we probably aren't going to really be able to 
clean that up before Struts 2.  Still, I think it's good to point the 
direction.  Besides backwards compatibility, in those cases, is there 
any reason we should be passing the Servlet and not just the 
ServletContext?

While we're on the thread, I remembered one other thing: right now, 
the configuration freezes each module config.  I've never been 100% 
clear on why Struts uses 'freeze' to lock things down.  Is there any 
legitimate reason for more than one configurator to be involved in 
setting up a ModuleConfig?  If so, we need to either take out the 
freezing or push it up into ActionServlet to do after it has given 
each StrutsConfigurator a chance to do its thing.  In my "draft", I 
just left the moduleConfig.freeze() inside the "ClassicConfigurator", 
but I wanted to check on this question.

Just thought of one more thing: technically, since the Configurator 
has access to the entire ServletContext, should we have a destroy() 
method also?  I would kind of prefer to leave that out and keep it 
simple, since otherwise it might get confusing about where cleanup 
responsibilities lie...  but we may not be able to avoid it.  (Then 
again, we may be able to wait until someone asks for it/has a use 
case.)

Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
  "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
-- Jef Raskin

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

Bug report for Struts [2004/04/04]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  866|New|Enh|2001-03-06|Clean Way to Add Parameters to Redirecting Forward|
| 3202|Opn|Enh|2001-08-21|OptionsTag.doEndTag -> calls method to populate se|
| 5395|Opn|Enh|2001-12-12|ActionContext class   |
| 5566|New|Enh|2001-12-21|[PATCH] html:link bug |
| 5739|Opn|Enh|2002-01-08|Struts fails silently in too many places  |
| 5937|New|Enh|2002-01-21|html:form trims all extensions|
| 6686|New|Enh|2002-02-26|make "action" attribute of html:form tag optional |
| 6847|Opn|Enh|2002-03-04|Multiple file upload not possible due to MultiPart|
| 7892|Opn|Enh|2002-04-09|Using Multiple Resource Bundles for an Application|
| 7902|Opn|Enh|2002-04-10|The exception handling declaration in the DTD does|
| 9088|Opn|Enh|2002-05-15|FormTag.getActionMappingURL() assumes 1 servlet ma|
| 9616|New|Enh|2002-06-05|Some more Struts docs |
| 9748|New|Enh|2002-06-10|attribute labelKeyProperty for Options tag|
|10550|New|Enh|2002-07-08|Delegate path-management to ActionForwards|
|10551|Opn|Enh|2002-07-08|Allow a struts-config element to extend another   |
|10552|New|Enh|2002-07-08|create helper objects in struts-config|
|10867|Opn|Enh|2002-07-16|Add indexedProperty attribute in html taglibs |
|11154|Opn|Enh|2002-07-25|html:link tag extension for multiple parameters   |
|11733|Opn|Enh|2002-08-15|Make error keys more specific |
|12170|Opn|Enh|2002-08-29|Added functionality when extending another definit|
|12301|Opn|Enh|2002-09-04|nested:messages Tag does not work as expected |
|12313|Opn|Enh|2002-09-04|Chaining of RequestProcessors--contribution   |
|12342|Ass|Enh|2002-09-05|Add default exception handler attribute to  ta|
|13521|New|Enh|2002-10-11|CombinedDispatchAction|
|13544|Opn|Enh|2002-10-11|[exception] support contextRelative paths |
|13565|Opn|Enh|2002-10-12|To "errors", add prefix, suffix, header, footer at|
|13638|Opn|Enh|2002-10-15|add Config Factory|
|14068|Opn|Enh|2002-10-29|Why can't I use forwards with exception elements i|
|14071|Opn|Enh|2002-10-29|Need clear info on which Struts attributes produce|
|14183|New|Enh|2002-11-01|html:img does not support forward attribute   |
|14749|Opn|Enh|2002-11-21|Action "input" not starting with '/' and not a val|
|15023|Opn|Enh|2002-12-03|Use attribute 'id' instead of 'name' in html:form-|
|15188|Opn|Enh|2002-12-09|roles attribute of tags and definitions only allow|
|15422|Opn|Enh|2002-12-17|Form Tag exportFormName  attribute|
|15604|Opn|Enh|2002-12-22|Struts framework should use getInstance Method for|
|15670|Opn|Enh|2002-12-26|Doc for "exception" element needs to mention "page|
|15673|Opn|Enh|2002-12-26|Default Action in ActionMapping   |
|15805|Opn|Enh|2003-01-05|Enhance ModuleException to allow getting chained E|
|15816|Opn|Enh|2003-01-06|html:form focus in pages with several forms   |
|15849|Opn|Enh|2003-01-07|Incorrect documentation for "Developing Your Own M|
|15912|Opn|Enh|2003-01-09|Client-side validation fails if not all form-field|
|15921|Opn|Enh|2003-01-09|Allow relative actions in struts-config.xml   |
|15935|Opn|Enh|2003-01-09|WSAD 5.0 Instructions for Struts Example  |
|15969|Opn|Enh|2003-01-10|Ability to use TilesRequestProcessor even if it no|
|16074|New|Enh|2003-01-14|html:form uses 'action' not 'input' to select mapp|
|16104|Opn|Enh|2003-01-15|default handler parameter value for LookupDispatch|
|16107|Opn|Enh|2003-01-15|Configure if you want to call ActionForm.reset() i|
|16207|Opn|Enh|2003-01-17|Add ability to import tile attributes into a java.|
|16249|Opn|Enh|2003-01-20|localized float validation|
|16388|Opn|Enh|2003-01-24|documentation of the currentPlugInConfigObject|
|16401|New|Enh|2003-01-24|ActionValidatorUtil   |
|16480|Opn|

Mail Archive

[Niall Pemberton]

I notice that the mail archive doesn't have any messages since 26/27 March - I assume 
this is something to do with the TLP change & email address changing to dev/[EMAIL 
PROTECTED]

http://www.mail-archive.com/struts-dev%40jakarta.apache.org/
http://www.mail-archive.com/struts-user%40jakarta.apache.org/

Is this going to be resolved?

Niall

Re: Fw: UrlValidator() takes options - but how?

[Niall Pemberton]

I have submitted a patch in commons to UrlValidator which returns a code

http://issues.apache.org/bugzilla/show_bug.cgi?id=28190

The existing isValid(value) method still works returning true/false.

I have added isValid(Object value, boolean expandedCode) method which
returns
an integer code.

If expandedCode is false it returns a code indicating which part of the url
is
invalid (general format, scheme, authority, path, query or fragment).

If expandedCode is true it returns a more detailled code indicating a more
specific error with the url.

Niall

Robert Leland wrote:
>
> Given that fits with the Validator framework, I know its implementation
would be easy.  The grouping of error message is also nice.
> Since we could use an int/long then I would probably group items by powers
of two, but thats just a preference. If you have already created a patch
with the above scheme I would commit it unchanged.
>
> -Rob



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

Re: Fw: UrlValidator() takes options - but how?

[David Graham]

--- Niall Pemberton <[EMAIL PROTECTED]> wrote:
> I have submitted a patch in commons to UrlValidator which returns a code
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28190
> 
> The existing isValid(value) method still works returning true/false.
> 
> I have added isValid(Object value, boolean expandedCode) method which
> returns
> an integer code.

Why does it take an Object parameter instead of a String like the other
isValid() method?

David

> 
> If expandedCode is false it returns a code indicating which part of the
> url
> is
> invalid (general format, scheme, authority, path, query or fragment).
> 
> If expandedCode is true it returns a more detailled code indicating a
> more
> specific error with the url.
> 
> Niall
> 
> Robert Leland wrote:
> >
> > Given that fits with the Validator framework, I know its
> implementation
> would be easy.  The grouping of error message is also nice.
> > Since we could use an int/long then I would probably group items by
> powers
> of two, but thats just a preference. If you have already created a patch
> with the above scheme I would commit it unchanged.
> >
> > -Rob
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

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

Re: Fw: UrlValidator() takes options - but how?

[Niall Pemberton]

Sorry, it is a String in the patch - I just typed it in wrong on the email.

Niall

- Original Message - 
From: "David Graham" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, April 04, 2004 6:16 PM
Subject: Re: Fw: UrlValidator() takes options - but how?


>
> --- Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > I have submitted a patch in commons to UrlValidator which returns a code
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=28190
> >
> > The existing isValid(value) method still works returning true/false.
> >
> > I have added isValid(Object value, boolean expandedCode) method which
> > returns
> > an integer code.
>
> Why does it take an Object parameter instead of a String like the other
> isValid() method?
>
> David
>
> >
> > If expandedCode is false it returns a code indicating which part of the
> > url
> > is
> > invalid (general format, scheme, authority, path, query or fragment).
> >
> > If expandedCode is true it returns a more detailled code indicating a
> > more
> > specific error with the url.
> >
> > Niall
> >
> > Robert Leland wrote:
> > >
> > > Given that fits with the Validator framework, I know its
> > implementation
> > would be easy.  The grouping of error message is also nice.
> > > Since we could use an int/long then I would probably group items by
> > powers
> > of two, but thats just a preference. If you have already created a patch
> > with the above scheme I would commit it unchanged.
> > >
> > > -Rob
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> __
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
> http://promotions.yahoo.com/design_giveaway/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



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

Re: Mail Archive

[Adam Hardy]

On 04/04/2004 06:40 PM Niall Pemberton wrote:
I notice that the mail archive doesn't have any messages since 26/27 March - I assume this is something to do with the TLP change & email address changing to dev/[EMAIL PROTECTED]

http://www.mail-archive.com/struts-dev%40jakarta.apache.org/
http://www.mail-archive.com/struts-user%40jakarta.apache.org/
Is this going to be resolved?

Niall


I noticed this too. Same thing at marc.theaimsgroup.com. But 
http://news.gmane.org/ to have fixed theirs already.

Adam
--
struts 1.2 + tomcat 5.0.19 + java 1.4.2
Linux 2.4.20 Debian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JavaScriptTag and multiple forms.

[Niall Pemberton]

Now that the four flavours of validator form (ValidatorForm,
ValidatorActionForm, DynaValidatorForm, DynaValidatorActionForm) have a
getValidatorKey() method, maybe the JavaScriptTag should get hold of these
and call the getValidatorKey() - that way the formName could become
optional, or even removed?

Then no coupling at all.

Niall

- Original Message - 
From: "Robert Leland" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 03, 2004 5:35 PM
Subject: JavaScriptTag and multiple forms.


> Every since I applied the patch to allow the validator to work,
> with multiple forms, there has been one thing that has bothered me:
>
> The JavaScriptTag requires the name of the form.
>
> So now both the form name and the action name are required in the JSP, and
this increases the coupling.
>
> How about we change it to take an 'action' instead of a form name ?
> That way the JSP need only know about the actions.
>
> -Rob
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



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

Re: JavaScriptTag and multiple forms.

[Matt Raible]

On Apr 4, 2004, at 2:11 PM, Niall Pemberton wrote:

Now that the four flavours of validator form (ValidatorForm,
ValidatorActionForm, DynaValidatorForm, DynaValidatorActionForm) have a
getValidatorKey() method, maybe the JavaScriptTag should get hold of 
these
and call the getValidatorKey() - that way the formName could become
optional, or even removed?

Then no coupling at all.
+1 - sounds like the logical choice to me!

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

RE: Mail Archive

[Martin Cooper]

> -Original Message-
> From: Adam Hardy [mailto:[EMAIL PROTECTED]
> Sent: Sunday, April 04, 2004 10:32 AM
> To: Struts Developers List
> Subject: Re: Mail Archive
>
>
> On 04/04/2004 06:40 PM Niall Pemberton wrote:
> > I notice that the mail archive doesn't have any messages since
> 26/27 March - I assume this is something to do with the TLP
> change & email address changing to dev/[EMAIL PROTECTED]
> >
> > http://www.mail-archive.com/struts-dev%40jakarta.apache.org/
> > http://www.mail-archive.com/struts-user%40jakarta.apache.org/
> >
> > Is this going to be resolved?
> >
> > Niall
>
>
> I noticed this too. Same thing at marc.theaimsgroup.com. But
> http://news.gmane.org/ to have fixed theirs already.

I sent messages to all of these folks, pointing out our changes and
requesting that they pick them up. I got an ack from Gmane, but not a peep
from the others. I also asked our own folks if I should be doing anything
else, but silence there also. I'm not sure what else I can do. ;-(

--
Martin Cooper


> Adam
> --
> struts 1.2 + tomcat 5.0.19 + java 1.4.2
> Linux 2.4.20 Debian
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



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

Re: Mail Archive

[Niall Pemberton]

I just found out that messages are in the Mail Archive but because the list
addresses have changed, their locations in the Mail Archive have also. If
you enter just "struts" and click on the "Find List" as well as "struts-dev"
and "struts-user" there are now "dev" and "user" lists which contain the
messages since the change.


Niall

- Original Message - 
From: "Martin Cooper" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, April 04, 2004 8:28 PM
Subject: RE: Mail Archive


>
>
> > -Original Message-
> > From: Adam Hardy [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, April 04, 2004 10:32 AM
> > To: Struts Developers List
> > Subject: Re: Mail Archive
> >
> >
> > On 04/04/2004 06:40 PM Niall Pemberton wrote:
> > > I notice that the mail archive doesn't have any messages since
> > 26/27 March - I assume this is something to do with the TLP
> > change & email address changing to dev/[EMAIL PROTECTED]
> > >
> > > http://www.mail-archive.com/struts-dev%40jakarta.apache.org/
> > > http://www.mail-archive.com/struts-user%40jakarta.apache.org/
> > >
> > > Is this going to be resolved?
> > >
> > > Niall
> >
> >
> > I noticed this too. Same thing at marc.theaimsgroup.com. But
> > http://news.gmane.org/ to have fixed theirs already.
>
> I sent messages to all of these folks, pointing out our changes and
> requesting that they pick them up. I got an ack from Gmane, but not a peep
> from the others. I also asked our own folks if I should be doing anything
> else, but silence there also. I'm not sure what else I can do. ;-(
>
> --
> Martin Cooper
>
>
> > Adam
> > --
> > struts 1.2 + tomcat 5.0.19 + java 1.4.2
> > Linux 2.4.20 Debian
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



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

Re: Mail Archive

[Joe Germuska]

At 8:45 PM +0100 4/4/04, Niall Pemberton wrote:
I just found out that messages are in the Mail Archive but because the list
addresses have changed, their locations in the Mail Archive have also. If
you enter just "struts" and click on the "Find List" as well as "struts-dev"
and "struts-user" there are now "dev" and "user" lists which contain the
messages since the change.
yet another reason to use Gmane, which not only unifies the archives, 
but (IMO) has a much nicer interface too...

For whatever reason, I particularly can't stand the interface at Mail 
Archive.  MARC is a little better, but I won't bother now that I've 
started using Gmane.

Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
  "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
-- Jef Raskin

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

RE: JavaScriptTag and multiple forms.

[Martin Cooper]

> -Original Message-
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sent: Saturday, April 03, 2004 3:10 PM
> To: Struts Developers List
> Subject: Re: JavaScriptTag and multiple forms.
>
>
> >  > If you did that, how would it know whether to use the 'path' or the
> >>  'name' to look up the validation rules?
> >
> >Wouldn't it alway use the 'name' it looked up from the given action ?
> >Is there a time it would ever use the 'path' ? I guess I don't
> understand ?
>
> What if you were using ValidatorActionForm/DynaValidatorActionForm
> instead of ValidatorForm/DynaValidatorForm?  Then the server side
> validation rules are looked up based on the path, not the name.  With
> the form classes, this can be encapsulated cleanly in a way that is
> invisible in the struts-config, (and even more so thanks to Niall's
> recent patch)  But that's invisible to the html:javascript tag.
>
> By the way, the names for those classes have to be one of the most
> confusing things about Struts; I only just really grokked the
> difference in the last couple of months, and most of the developers I
> work with are still kind of fuzzy about it.

+1000! The first time I looked at these to figure out why we had two, I
actually thought they were the same. It wasn't until I really studied the
Javadocs that I realised the difference. (Yay for Javadocs!) I'm still not
clear, though, on why we actually *need* two different mechanisms.

--
Martin Cooper


> There is something attractive about somehow involving the ActionForm
> class in the client side validation, but that seems kind of
> challenging.  Maybe for Struts 2.0... ?
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
>"Imagine if every Thursday your shoes exploded if you tied them
> the usual way.  This happens to us all the time with computers, and
> nobody thinks of complaining."
>  -- Jef Raskin
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



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

RE: Why struts-documentation ?

[Martin Cooper]

> -Original Message-
> From: Robert Leland [mailto:[EMAIL PROTECTED]
> Sent: Saturday, April 03, 2004 7:18 AM
> To: [EMAIL PROTECTED]
> Subject: Why struts-documentation ?
> 
> 
> Why does struts-documentation include all the jar files for struts
> when it contains no JSP's or struts-config.xml ?
> Not having to run tomcat to view the DOCS is a big Plus.

I think this is one of those "it seemed like a good idea at the time" things. ;-) I 
suggested getting away from this some time ago, and unless I'm mistaken, Craig 
suggested the same thing quite recently (but I don't have a pointer for you). Maybe we 
should do this for 1.3?

--
Martin Cooper


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



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

Re: Mail Archive

[Ate Douma]

What about the mbox archives previously available at
http://jakarta.apache.org/mail ?
I have to work a lot in environments where I don't have direct access to
internet.
For that I use the mbox archives to take with me. Now are those gone or just
placed somewhere else?

Ate

Martin Cooper wrote:
>> -Original Message-
>> From: Adam Hardy [mailto:[EMAIL PROTECTED]
>> Sent: Sunday, April 04, 2004 10:32 AM
>> To: Struts Developers List
>> Subject: Re: Mail Archive
>>
>>
>> On 04/04/2004 06:40 PM Niall Pemberton wrote:
>>> I notice that the mail archive doesn't have any messages since
>> 26/27 March - I assume this is something to do with the TLP
>> change & email address changing to dev/[EMAIL PROTECTED]
>>>
>>> http://www.mail-archive.com/struts-dev%40jakarta.apache.org/
>>> http://www.mail-archive.com/struts-user%40jakarta.apache.org/
>>>
>>> Is this going to be resolved?
>>>
>>> Niall
>>
>>
>> I noticed this too. Same thing at marc.theaimsgroup.com. But
>> http://news.gmane.org/ to have fixed theirs already.
>
> I sent messages to all of these folks, pointing out our changes and
> requesting that they pick them up. I got an ack from Gmane, but not a
> peep from the others. I also asked our own folks if I should be doing
> anything else, but silence there also. I'm not sure what else I can
> do. ;-(
>
>
>> Adam
>> --
>> struts 1.2 + tomcat 5.0.19 + java 1.4.2
>> Linux 2.4.20 Debian
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



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

RE: Mail Archive

[Martin Cooper]

> -Original Message-
> From: Ate Douma [mailto:[EMAIL PROTECTED]
> Sent: Sunday, April 04, 2004 1:48 PM
> To: Struts Developers List
> Subject: Re: Mail Archive
>
>
> What about the mbox archives previously available at
> http://jakarta.apache.org/mail ?
> I have to work a lot in environments where I don't have direct access to
> internet.
> For that I use the mbox archives to take with me. Now are those
> gone or just
> placed somewhere else?

Since Struts is now an Apache top level project, the mail archives are no
longer under Jakarta but are here instead:

http://struts.apache.org/mail/

--
Martin Cooper


> Ate
>
> Martin Cooper wrote:
> >> -Original Message-
> >> From: Adam Hardy [mailto:[EMAIL PROTECTED]
> >> Sent: Sunday, April 04, 2004 10:32 AM
> >> To: Struts Developers List
> >> Subject: Re: Mail Archive
> >>
> >>
> >> On 04/04/2004 06:40 PM Niall Pemberton wrote:
> >>> I notice that the mail archive doesn't have any messages since
> >> 26/27 March - I assume this is something to do with the TLP
> >> change & email address changing to dev/[EMAIL PROTECTED]
> >>>
> >>> http://www.mail-archive.com/struts-dev%40jakarta.apache.org/
> >>> http://www.mail-archive.com/struts-user%40jakarta.apache.org/
> >>>
> >>> Is this going to be resolved?
> >>>
> >>> Niall
> >>
> >>
> >> I noticed this too. Same thing at marc.theaimsgroup.com. But
> >> http://news.gmane.org/ to have fixed theirs already.
> >
> > I sent messages to all of these folks, pointing out our changes and
> > requesting that they pick them up. I got an ack from Gmane, but not a
> > peep from the others. I also asked our own folks if I should be doing
> > anything else, but silence there also. I'm not sure what else I can
> > do. ;-(
> >
> >
> >> Adam
> >> --
> >> struts 1.2 + tomcat 5.0.19 + java 1.4.2
> >> Linux 2.4.20 Debian
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



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

RE: JavaScriptTag and multiple forms.

[Joe Germuska]

At 1:05 PM -0700 4/4/04, Martin Cooper wrote:
+1000! The first time I looked at these to figure out why we had two, I
actually thought they were the same. It wasn't until I really studied the
Javadocs that I realised the difference. (Yay for Javadocs!) I'm still not
clear, though, on why we actually *need* two different mechanisms.
If one wanted to use the same form bean in different cases, one might 
have different validation rules.  For example, you might have a user 
ID be required when creating a record, but not even have it editable 
when editing the record.  By associating your validation with the 
submission path instead of the form bean name, you can use the same 
form bean with different validation rules.

I personally haven't used this a lot, but I can see the justification.

Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
  "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
-- Jef Raskin

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

RE: JavaScriptTag and multiple forms.

[Ted Husted]

Personally, I'd like to deprecate the alternate form. It only confuses people. If you 
want to use the same form bean in different circumstances, you can give the same form 
bean different names. I'd like to add extends to all the elements in 1.3, including 
DynaActionForm, so you'd be able to reuse DynaActionForms too.  David W did add this 
to fulfill a specific user request, but we may have been too solicitous :)

-Ted.


On Sun, 04 Apr 2004 17:18:17 -0500, Joe Germuska wrote:
> At 1:05 PM -0700 4/4/04, Martin Cooper wrote:
>> +1000! The first time I looked at these to figure out why we had
>> two, I actually thought they were the same. It wasn't until I
>> really studied the Javadocs that I realised the difference. (Yay
>> for Javadocs!) I'm still not clear, though, on why we actually *
>> need* two different mechanisms.
>>
>
> If one wanted to use the same form bean in different cases, one
> might have different validation rules.  For example, you might have
> a user ID be required when creating a record, but not even have it
> editable when editing the record.  By associating your validation
> with the submission path instead of the form bean name, you can use
> the same form bean with different validation rules.
>
> I personally haven't used this a lot, but I can see the
> justification.
>
>
> Joe




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

RE: Why struts-documentation ?

[Ted Husted]

On Sun, 04 Apr 2004 13:08:47 -0700, Martin Cooper wrote:
>
>
>> -Original Message-
>> From: Robert Leland [mailto:[EMAIL PROTECTED]
>> Sent: Saturday, April 03, 2004 7:18 AM
>> To: [EMAIL PROTECTED]
>> Subject: Why struts-documentation ?
>>
>>
>> Why does struts-documentation include all the jar files for
>> struts when it contains no JSP's or struts-config.xml ? Not
>> having to run tomcat to view the DOCS is a big Plus.
>>
>
> I think this is one of those "it seemed like a good idea at the
> time" things. ;-) I suggested getting away from this some time ago,
> and unless I'm mistaken, Craig suggested the same thing quite
> recently (but I don't have a pointer for you). Maybe we should do
> this for 1.3?

+1

 We should turn the docs into a static web site for 1.3. The utility of including the 
JARs has long since been replaced by things like the LIB distribution and the blank 
application, not to mention Maven before long :)

-GTed.



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

Re: Refactoring Struts Initialization (was RE: Splitting struts-config into multiple jar...)

[Ted Husted]

On Sun, 04 Apr 2004 09:04:24 -0600, Joe Germuska wrote:
>> IMO, Struts datasource handling should be deprecated and removed.
>>  It had it's place in the past but now Struts has no business
>> "managing" datasources; that's the containers job and most of
>> them do it better than Struts.  I would like part of Struts 2.x
>> to focus on simplifying users' lives and removing this feature
>> follows in that spirit; but that may be for another thread.
>>
>
> Well, I was thinking about doing this refactoring in a pre 2.x
> timeline and maintaining compatibility.  But I agree that
> datasource handling should be left out of Struts.

It's important to note that the DataSource manager is not managing the underlying 
implementations in the way a container would, but making them available through a 
"catalog" interface. This component just takes whatever datasource instances it is 
handed and retains the references as a list. Before deprecating and removing anything 
like this, we should create a standalone version that people could plugin. I am quite 
certain many people still use it and 1.x is suppose to be backward compatible. Someone 
could add it to the legacy package, or find some other home for it. But, personally, 
I'd say removing it would seem to be more trouble than leaving it be. Unlike our 
ill-fated datasource implementation, the manager is  zero maintenance. :)

-Ted



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

Re: Refactoring initiaization code [was: Splitting struts-config into multiple jar and read them as reso urce stream]

[Ted Husted]

Just changing the subject line per David's suggestion :)

On Sat, 03 Apr 2004 23:05:44 -0800 (PST), David Graham wrote:
> This thread seems to have taken a turn into something I'm
> interested in; too bad the subject didn't change with it so I could
> have started following sooner.  If this is about refactoring Struts
> initialization code out of ActionServlet then I'm definitely
> interested.  In fact, I took a look at this some time ago but
> stopped to pursue other items.



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

RE: Splitting struts-config into multiple jar and read them as reso urce stream

[Ted Husted]

On Thu, 01 Apr 2004 22:48:03 -0800, Martin Cooper wrote:
> Let me throw out a few thoughts on this thread, and modules in
> general, as I try to catch up. (I'm still in this seemingly-
> perpetual state of not having the time to fully expound on my
> thoughts on future enhancements to modules, darn it! ;)

Another thing to think about is that we also want to position ourselves to support JAR 
168 portlets before long.

Is there going to be a relationship between portlets and modules? Are we going to be 
able to use modules as portlets? Or are we going to be able to have modules within 
portlets?


> 4) As I've mentioned before (in this same thread, I think), I
> believe we need to factor out the configuration code and make it
> pluggable. Going forward, the Struts Core should rely on certain
> configuration objects being defined, without caring about how they
> got there. The default config reader, obviously, would do what we
> do today, but we should make it easy to provide an alternate config
> reader that might do its thing in an entirely different manner.
> (I'm sure the IoC fans out there will have something to say on this
> topic. ;)

+1

I haven't looked at Joe's code yet, but it would be very helpful if we could 
manufacture configurations in a testing environment, without having to read them in 
from an XML file. Once we have contexts in the signatures, it will be easy to test the 
core components independently.

-Ted.



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

2.3 for 1.3? (was Counting down to 1.2.1)

[Ted Husted]

So, I'm going to knuckle down and do whatever we need to do to get 1.2.1 ready to cut 
this week.

In the meantime, I'm wondering if we want to just bite the bullet and move the minimum 
to servlet 2.3 for the Struts 1.3.x series?

People using 2.2 can still use 1.2.x, and having 2.3 available might simplify some of 
the configuration discussions we're having now.

Struts 2.0 is being slated for 2.4, so it's a clean continuum.

As to the subproject reorg, I'd imagine we'd still keep taglib-classic on 2.2, and 
taglib-jstl and taglib-faces on 2.3.

-Ted.



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

Re: Mail Archive

[Ate Douma]

Martin Cooper wrote:
> Since Struts is now an Apache top level project, the mail archives
> are no longer under Jakarta but are here instead:
> 
> http://struts.apache.org/mail/
> 
Ok, when will that be available (I get a Not Found page here)?


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

RE: 2.3 for 1.3? (was Counting down to 1.2.1)

[Martin Cooper]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Sunday, April 04, 2004 6:14 PM
> To: Struts Developers List
> Subject: 2.3 for 1.3? (was Counting down to 1.2.1)
>
>
> So, I'm going to knuckle down and do whatever we need to do to
> get 1.2.1 ready to cut this week.

Oh. I thought I was supposed to be cutting it this weekend (at your
suggestion ;). The only reason that's not actually done is because CVS is
locking up on me (in the Struts repo only). Should I not be trying to do
this?

> In the meantime, I'm wondering if we want to just bite the bullet
> and move the minimum to servlet 2.3 for the Struts 1.3.x series?

I feel pretty strongly that we shouldn't be breaking backwards compatibility
in a point release.

> People using 2.2 can still use 1.2.x, and having 2.3 available
> might simplify some of the configuration discussions we're having now.

I haven't caught up completely on that thread yet. (Long messages sometimes
get pushed down on my stack, I'm afraid, and I was trying to focus on
1.2.1.) What is it about moving to 2.3 that would help (other than allowing
for the mechanism I suggested, which would be optional anyway)?

> Struts 2.0 is being slated for 2.4, so it's a clean continuum.
>
> As to the subproject reorg, I'd imagine we'd still keep
> taglib-classic on 2.2, and taglib-jstl and taglib-faces on 2.3.

Right now (or at least after 1.2.1 is out), I think we need to focus on the
other parts of our TLP move. I'll start a separate thread on that.

--
Martin Cooper


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



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

RE: Mail Archive

[Martin Cooper]

> -Original Message-
> From: Ate Douma [mailto:[EMAIL PROTECTED]
> Sent: Sunday, April 04, 2004 2:05 PM
> To: Struts Developers List
> Subject: Re: Mail Archive
>
>
>
> Martin Cooper wrote:
> > Since Struts is now an Apache top level project, the mail archives
> > are no longer under Jakarta but are here instead:
> >
> > http://struts.apache.org/mail/
> >
> Ok, when will that be available (I get a Not Found page here)?

When we can get the web site moved over from Jakarta to Struts. The problem
right now is that we're waiting for Unix permissions to be able to do that,
so there's a redirect from the new site to the old, which is why you can't
see those archives.

--
Martin Cooper


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



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

TLP conversion status

[Martin Cooper]

Here's an update on where we are on getting everything morphed over into
Struts TLP status.

First off, this is taking *much* longer than I'd expected. Part of it is
that there are a lot of things to do, but much of it is because I don't
have enough permission to do things myself, and the infra folks seem to be
busy doing other things (like playing with all their new boxes ;).

As I'm sure you know, the mailing lists have been created and are up and
running in their new incarnations. Unfortunately, the mbox archives are
not yet available - see earlier thread on archives. The Jakarta web site,
though, still refers to the old lists, so we probably need to change that
pretty soon.

The wiki pages have finally been moved over from the old wiki to the new
one. By now, they could be out of date, but doubt there's anything we can
do about that. The remaining problems with the wiki are that the new pages
are not editable (and the old ones still are), and the initial page is
still a default MoinMoin front page. I have a request in to get the page
permissions changed, so until that happens, we can't do anything about the
latter.

A Unix group for Struts has been created, but it currently has no members.
I have a Jira issue in for that.

The new web site location is ready, but we can't do anything to put a site
there yet, because permissions are set for the Struts group that, as
mentioned above, currently has no members.

I have not done anything myself about new content for the new site. We're
going to need some pages for things that we've heretofore relied on the
Jakarta site for. Before that, we'll need to discuss how we want to
organise the new site (a) to incorporate the new content, and (b) if we
want to reorganise anything to make it more TLP-like.

If you want to track all of this, here are the Jira issues that I
submitted:

INFRA-48: New Unix group for Struts committers
INFRA-49: Web site infrastructure for Struts
INFRA-51: Need Struts wiki pages copied from old wiki
INFRA-52: Change default AssignedTo for Struts in Bugzilla

Of these, #49 is done, but we can't do anything until #48 is done, and #51
is done, but we can't do anything until the page perms are changed. I
thought I could do #52 myself, but apparently cannot (or just haven't
figured out how).

All very frustrating, frankly.

--
Martin Cooper

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

Re: Refactoring Struts Initialization (was RE: Splitting struts-config into multiple jar...)

[Craig R. McClanahan]

Joe Germuska wrote:

[snip]
While we're on the thread, I remembered one other thing: right now, 
the configuration freezes each module config.  I've never been 100% 
clear on why Struts uses 'freeze' to lock things down.  Is there any 
legitimate reason for more than one configurator to be involved in 
setting up a ModuleConfig?  If so, we need to either take out the 
freezing or push it up into ActionServlet to do after it has given 
each StrutsConfigurator a chance to do its thing.  In my "draft", I 
just left the moduleConfig.freeze() inside the "ClassicConfigurator", 
but I wanted to check on this question.
The original motivation for freezing the configuration was to allow 
HashMap lookups during execution to run without time-wasting (for the 
99.9% use case) synchronization.  When 1.1 introduced PlugIn, we also 
moved the freeze() call to after PlugIns have executed their 
initialization, so that PlugIns can dynamically modify the configuration 
information as well.  We'd certainly want to do the same thing with 
configurators ... not freeze until they've all had their shot at 
updating the configuration.

I personally believe that, even if we implemented dynamic 
reconfiguration support for the config files themselves, developers will 
be disappointed in how little this helps in a development cycle -- 
you're not going to pick up added or changed Java classes without a 
container-managed restart of the webapp (except on *some* containers 
where you haven't yet loaded the class in question), so typical 
development use cases like "add the next Action" are going to require 
restarts anyway.

Just thought of one more thing: technically, since the Configurator 
has access to the entire ServletContext, should we have a destroy() 
method also?  I would kind of prefer to leave that out and keep it 
simple, since otherwise it might get confusing about where cleanup 
responsibilities lie...  but we may not be able to avoid it.  (Then 
again, we may be able to wait until someone asks for it/has a use case.)
Yes, I can see use cases for this (such as saving current state 
information that will be used the next time the configuration is 
loaded).  But if you add a destroy method, haven't you just recreated 
the PlugIn API?  Indeed, isn't configuring Struts just a special case of 
what PlugIn is for (albeit its one that we'd probably want to ensure ran 
before user-defined PlugIns)?

Joe
Craig



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

Re: Splitting struts-config into multiple jar and read them as reso urce stream

[Craig R. McClanahan]

Filippo Munafò wrote:
[snip]
Craig said:

 

Along the same lines, one of the things we did in JavaServer Faces (with regards
to configuration) is to have the controller servlet automatically recognize
"META-INF/faces-config.xml" resources in any JAR files that were included in
the application.  This makes it very easy to package a module, or some other
sub-unit of an overall webapp, as a single JAR file that self-configures.
   

Why it is so in JSF and could not be in Struts?
 

It can, but we need to resolve the issue of how autoconfiguration 
relates to modules (something that JSF didn't have to deal with, because 
JSF does not have any such concept).

Ideally, we'd have a way to make this association without the 
configuration file inside the JAR needing to know what module(s) it 
belongs to.  That's a part of the problem that needs more exploring.

Filippo
 

Craig



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

Re: Validator Plugin

[Craig R. McClanahan]

David Graham wrote:

--- Robert Leland <[EMAIL PROTECTED]> wrote:
 

Currently the Validator PlugIn doesnâEUR^(TM)t validate the XML file. I have
updated it to remove the deprecated methods and to validate the XML
files.
Here is the question: Currently, the validator plugin fails by logging a
message but doesnâEUR^(TM)t take advantage of throwing an exception. I believe
it should throw an exception if the validator file is invalid. Are there
any thoughts or objections to throwing an exception, is that too
incompatable  with its current behaviour ?
   

I agree that we should throw the exception.  IMO, it should fail fast and
loud at startup if you've misconfigured the validations.
 

I agree with this as well, but of course the same concept should apply 
to all our other configuration information.  How many of us have 
mistyped the name of a form bean class, for example (raises hand :-).

There was an interesting thread on a similar situation with Hivemind on 
COMMONS-DEV last week, where those developers seem to believe that users 
shouldn't want such support ever.  I don't agree with that extreme a 
viewpoint, but it might be nice to make such checks a configuration 
parameter option (I'd vote for default=true because it probably won't 
hit startup performance enough to matter for most people).

David
 

Craig

 





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



__
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

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

Re: Refactoring Struts Initialization (was RE: Splitting struts-config into multiple jar...)

[Joe Germuska]

Just thought of one more thing: technically, since the Configurator 
has access to the entire ServletContext, should we have a destroy() 
method also?  I would kind of prefer to leave that out and keep it 
simple, since otherwise it might get confusing about where cleanup 
responsibilities lie...  but we may not be able to avoid it.  (Then 
again, we may be able to wait until someone asks for it/has a use 
case.)
Yes, I can see use cases for this (such as saving current state 
information that will be used the next time the configuration is 
loaded).  But if you add a destroy method, haven't you just 
recreated the PlugIn API?
More or less, yes.  That had crossed my mind.  The major difference 
being, of course, when the methods get called.  I suppose one could 
write a plugin which instantiated more action mappings, form beans, 
etc. (I bet someone already has!) but it doesn't seem very tidy...

If someone had an idea for how to coordinate the timing of calls to 
plugins to distinguish between configuration responsibilities (the 
new use case) and other plugin uses, I'd be happy to hear it.  I was 
more looking for "the simplest thing that could possibly work" to 
open up configuration along the lines of recent discussion on the DEV 
list.

Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
  "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
-- Jef Raskin

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

Re: 2.3 for 1.3? (was Counting down to 1.2.1)

[Robert Leland]

Ted Husted wrote:

So, I'm going to knuckle down and do whatever we need to do to get 1.2.1 ready to cut this week. 

In the meantime, I'm wondering if we want to just bite the bullet and move the minimum to servlet 2.3 for the Struts 1.3.x series?

I have been thinking this for a long time. Folks will still have the
1.2.X release series.
It may be possible for 1.3 struts to remain backwards compatable, but to
start experimenting with
servlet 2.3 features. I had thought about taking a poll, but now think
better of that.
I believe we should start moving forward. Perhaps we can adopt
Bugzilla's and Linux scheme
of even/odd build numbers. Even is stable production releases and odd is
development builds. The development
builds would give us CVS space to start experimenting with whats been on
paper. If we find out that
making Struts 1.4 (The stable release) backward compatable based on what
is learned with Struts 1.3 development build
then we scratch 1.4 and go right to 2.0 (which is by the way an even
build number)
It may be that a full blown Jerico would be struts 3.0, but we have to
start somewhere.


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

Re: TLP conversion status

[Robert Leland]

Martin Cooper wrote:

Here's an update on where we are on getting everything morphed over into
Struts TLP status.
First off, this is taking *much* longer than I'd expected. Part of it is
that there are a lot of things to do, but much of it is because I don't
have enough permission to do things myself, and the infra folks seem to be
busy doing other things (like playing with all their new boxes ;).
As I'm sure you know, the mailing lists have been created and are up and
running in their new incarnations. Unfortunately, the mbox archives are
not yet available - see earlier thread on archives. The Jakarta web site,
though, still refers to the old lists, so we probably need to change that
pretty soon.
The wiki pages have finally been moved over from the old wiki to the new
one. By now, they could be out of date, but doubt there's anything we can
do about that. The remaining problems with the wiki are that the new pages
are not editable (and the old ones still are), and the initial page is
still a default MoinMoin front page. I have a request in to get the page
permissions changed, so until that happens, we can't do anything about the
latter.
A Unix group for Struts has been created, but it currently has no members.
I have a Jira issue in for that.
The new web site location is ready, but we can't do anything to put a site
there yet, because permissions are set for the Struts group that, as
mentioned above, currently has no members.
I have not done anything myself about new content for the new site. We're
going to need some pages for things that we've heretofore relied on the
Jakarta site for. Before that, we'll need to discuss how we want to
organise the new site (a) to incorporate the new content, and (b) if we
want to reorganise anything to make it more TLP-like.
If you want to track all of this, here are the Jira issues that I
submitted:
INFRA-48: New Unix group for Struts committers
INFRA-49: Web site infrastructure for Struts
INFRA-51: Need Struts wiki pages copied from old wiki
INFRA-52: Change default AssignedTo for Struts in Bugzilla
Of these, #49 is done, but we can't do anything until #48 is done, and #51
is done, but we can't do anything until the page perms are changed. I
thought I could do #52 myself, but apparently cannot (or just haven't
figured out how).
 

At my last contract I was one of the Bugilla Admins (2.6.X) series.
So I am familar with Buzilla 2.6 but 2.4 may have that in an entirely 
different place.
I don't know it well enought to tell you from memory.


All very frustrating, frankly.

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


 



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

DO NOT REPLY [Bug 28195] New: - TEST ONLY - test transition of default owner of Struts bug reports

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28195

TEST ONLY - test transition of default owner of Struts bug reports

   Summary: TEST ONLY - test transition of default owner of Struts
bug reports
   Product: Struts
   Version: Unknown
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Struts-Faces Library
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]

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