Validator and Resourcebundles and modules

Hi Since there where no takers on the users list : Is there a way of telling the Validator which Resourcebundle it should get its resources from? I have multi-module Strut application, each module has its own Resourcebundle (ApplicationResources-moda.poperties, ApplicationResources-modb.poperties

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

let automatically recognize 'META-INF/struts- > > > > > > config.xml' resources in any JAR files that were included in the > > > > > > application." > > > > > > > > > > > > When in struts? > > > > > > &

RE: Splitting struts-config into multiple jar and read them as re source stream

Yes, but concrete mechanisms for (re-)loading configurations could be pluggable, and therefore optional. One can imagine storing struts config files in a central database, and providing a loader that could load / reload them from there. The location of the configuration files doesn't seem

DO NOT REPLY [Bug 27228] - nested errors and messages does not have correct nesting for property

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27228>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bu

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

s in any JAR files that were included in the > > > > > application." > > > > > > > > > > When in struts? > > > > > > > > > > Can I help? > > > > > > > > I think we do the same sort of thing in Commons Chain, n'

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

; > > > When in struts? > > > > > > > > Can I help? > > > > > > I think we do the same sort of thing in Commons Chain, n'est pas? > > > > > > > This particular functionality was in relationship to automatically finding and > &

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

r servlet automatically recognize 'META-INF/struts- > > > config.xml' resources in any JAR files that were included in the > > > application." > > > > > > When in struts? > > > > > > Can I help? > > > > I think we do the sam

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

resources in any JAR files that were included in the > > application." > > > > When in struts? > > > > Can I help? > > I think we do the same sort of thing in Commons Chain, n'est pas? > This particular functionality was in relationship to automati

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

arch 23, 2004 12:34 To: Struts Developers List Subject: Re: Splitting struts-config into multiple jar and read them as resource stream On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: > Perfect! What you did in JSF is exatcly what we need: > > "the controller serv

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

On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: > Perfect! What you did in JSF is exatcly what we need: > > "the controller servlet automatically recognize 'META-INF/struts- > config.xml' resources in any JAR files that were included in the > application." > > When in struts? > > Can I he

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

e- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2004 18:33 To: 'Struts Dev Mailing List' Subject: Re: Splitting struts-config into multiple jar and read them as resource stream Quoting Joe Germuska <[EMAIL PROTECTED]>: > >We'd like not to sub

Re: Tiles for alternative presentation technologies (RE: branching 1.2 and 1.3 and CVS reorg for TLP status)

> I managed to make Tiles work with struts-chain with a single > pre-processor Command. It basically looks up a tiles definition and > replaces the ForwardConfig returned from an action with its own that > has a path which RequestDispatcher to which can forward. > > But it still us

Tiles for alternative presentation technologies (RE: branching 1.2 and 1.3 and CVS reorg for TLP status)

turn, this probably means we might need an API abstraction that alternative presentation tier technologies can use to integrate themselves into the underlying support. I managed to make Tiles work with struts-chain with a single pre-processor Command. It basically looks up a tiles definitio

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

Ted Husted wrote: On Sun, 21 Mar 2004 10:55:00 -0800 (PST), Martin Cooper wrote: I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

g that could possibly work. As > > > > you've said, we can always change things around later. > > > > > > The problem is that is that we already have the simplest thing. And, if we > > want multiple Maven-based products with independent release cycles, then what

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

t could possibly work. As > > > > you've said, we can always change things around later. > > > > > > The problem is that is that we already have the simplest thing. And, if > we want multiple Maven-based products with independent release cycles, then > what

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

s change things around later. > > > > The problem is that is that we already have the simplest thing. And, if we > want multiple Maven-based products with independent release cycles, then what > we have won't work. :) > > We already have the simplest thing in terms o

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

ht be a good idea to bring Tiles and Validator up as top-level directories. We might want to think about ways that other frameworks, like JSF, could use these without have to buy into the whole 900lb Struts gorilla. -Ted. -

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

On Sun, 21 Mar 2004 10:55:00 -0800 (PST), Martin Cooper wrote: > I am now leaning towards 3 repos myself: > > > struts-legacy >This is our current repo, renamed. I don't really care for this >name, but I can't think of anything better right now, and I hate &g

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

On Sun, 21 Mar 2004 12:05:44 -0800, Nathan Bubna wrote: > Martin Cooper said: > .. >> Another thought on this. When we get to Struts 2, I'd like to see >> us remove all of the JSP-ness of Struts from the core, and also >> add some degree of support for other presenta

DO NOT REPLY [Bug 27662] - Add filter attribute to and

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27662>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bu

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

multiple repositories. I'm with Martin here. We don't need multiple repositories; I think we can organize a single repository in such a way that achieves the same goal with less administrative overhead. I do see some value to having "struts-legacy" distinct from "str

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

Martin Cooper said: ... > Another thought on this. When we get to Struts 2, I'd like to see us > remove all of the JSP-ness of Struts from the core, and also add some > degree of support for other presentation technologies, such as XSLT and > Velocity. So, instead of having '

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

ge things around later. > > > > The problem is that is that we already have the simplest thing. And, if we want > > multiple Maven-based products with independent release cycles, then what we have > > won't work. :) > > We already have the simplest thing in terms o

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

dy have the simplest thing. And, if we want > multiple Maven-based products with independent release cycles, then what we have > won't work. :) We already have the simplest thing in terms of one repo, but we have far from the simplest thing when it comes to organising within that repo. T

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote: > Option 1 works for me. Simplest thing that could possibly work. As > you've said, we can always change things around later. The problem is that is that we already have the simplest thing. And, if we want multiple Maven-bas

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

t: Re: branching 1.2 and 1.3 and CVS reorg for TLP status > > > On Sat, 20 Mar 2004, Craig R. McClanahan wrote: > > > Quoting Joe Germuska <[EMAIL PROTECTED]>: > > > > > At 2:48 PM -0500 3/14/04, Ted Husted wrote: > > > >I'd say we c

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

On Sat, 20 Mar 2004, Craig R. McClanahan wrote: > Quoting Joe Germuska <[EMAIL PROTECTED]>: > > > At 2:48 PM -0500 3/14/04, Ted Husted wrote: > > >I'd say we could branch what we have as 1.2 and start thinking of > > >the HEAD as 1.3. > > > >

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

- Original Message - From: Ted Husted <[EMAIL PROTECTED]> Date: Sat, 20 Mar 2004 18:09:53 -0500 To: Struts Developers List <[EMAIL PROTECTED]> Subject: Re: branching 1.2 and 1.3 and CVS reorg for TLP status > Meanwhile, I would have no problem with calling for a VOTE

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

Quoting Joe Germuska <[EMAIL PROTECTED]>: > At 2:48 PM -0500 3/14/04, Ted Husted wrote: > >I'd say we could branch what we have as 1.2 and start thinking of > >the HEAD as 1.3. > > > >IMHO, the quickest way to sort out what we need to do with the > &g

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

m > >jar files)? > > It seems plausible that a factory class could be factored out of the > ActionServlet. I'd think you could do this in Struts 1 in a backwards > compatible fashion. I think people would like to be able to > configure struts from a variety of sour

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

On Fri, 19 Mar 2004 19:32:40 -0800 (PST), Martin Cooper wrote: > If people want to start on 1.3.x, then I'd suggest we all pitch in > and try to get 1.2.1 in shape for release ASAP. Works for me. There are a couple of tickets with patches that I can try tonight. If there's anyth

DO NOT REPLY [Bug 27228] - nested errors and messages does not have correct nesting for property

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27228>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bu

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

. I feel very strongly that we should not be relying on sandbox components in the mainstream of Struts. We've been through the pain of that several times before, and I don't want to have to deal with it again. I agree with this too. I haven't done enough with the code to feel li

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

On Fri, 19 Mar 2004, Joe Germuska wrote: > At 2:48 PM -0500 3/14/04, Ted Husted wrote: > >I'd say we could branch what we have as 1.2 and start thinking of > >the HEAD as 1.3. > > > >IMHO, the quickest way to sort out what we need to do with the > >Struts-C

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

rg/viewcvs.cgi/ant/ There are questions about what the best way to reorganize (or "rationalize") our now-rambling Struts project into several subprojects. But, I think we were going to do that regardless. And no one is going to want to sacrifice the CVS logs :) I do think we shou

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

--- Joe Germuska <[EMAIL PROTECTED]> wrote: > At 2:48 PM -0500 3/14/04, Ted Husted wrote: > >I'd say we could branch what we have as 1.2 and start thinking of > >the HEAD as 1.3. > > > >IMHO, the quickest way to sort out what we need to do with the > &g

branching 1.2 and 1.3 and CVS reorg for TLP status

At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light

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

do something useful, I > would like to submit some patches. What is the correct way to > submit patches? You can create a ticket in bugzilla, and then go back and attach a DIFF. http://jakarta.apache.org/struts/using.html#Patches This is also quite good: http://www.netbeans.org/communi

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

ay to submit patches? Regards, Diego.- > -Original Message- > From: Joe Germuska [mailto:[EMAIL PROTECTED] > Sent: Viernes, 19 de Marzo de 2004 11:30 a.m. > To: Struts Developers List > Subject: Re: Splitting struts-config into multiple jar and > read them as resource str

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

his in Struts 1 in a backwards compatible fashion. I think people would like to be able to configure struts from a variety of sources; another popular request is for dynamic reconfiguration -- without a redeploy -- but that's a different and more complicated question. Joe -- Joe Germuska

Splitting struts-config into multiple jar and read them as resource stream

o "notify" his presence by calling, in a subclassed ActionServlet, a method with this signature: - public void addStrutsConfigXML (Class callerClass, String prefix, String StrutsConfigXML) This method was written copying some part of Struts ActionServlet's code. Here is the ma

DO NOT REPLY [Bug 27662] - Add filter attribute to and

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27662>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bu

DO NOT REPLY [Bug 27662] - Add filter attribute to and

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27662>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bu

DO NOT REPLY [Bug 27662] - Add filter attribute to and

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27662>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bu

DO NOT REPLY [Bug 27662] New: - and tags lack "filter" attribute

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27662>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bu

DO NOT REPLY [Bug 22633] - Document how to use web.xml "maxFileSize" and how to deal with "MaxLengthExceededException"

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22633>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

Re: 1.2.x and beyond (was Tagging and Freezing)

14:20 +, Niall Pemberton wrote: > Ted, > > > Whats happening with your Jericho proposal - I looked in the > cvs/contrib and just saw the overview - is there anything more > concrete anywhere else and are you still looking at pursuing this > 'struts revolution'? &g

Re: 1.2.x and beyond (was Tagging and Freezing)

Ted, Whats happening with your Jericho proposal - I looked in the cvs/contrib and just saw the overview - is there anything more concrete anywhere else and are you still looking at pursuing this 'struts revolution'? Niall - Original Message - From: "Ted Husted" &l

Re: 1.2.x and beyond (was Tagging and Freezing)

On Fri, 27 Feb 2004 23:27:35 -0800, Craig R. McClanahan wrote: > * Create a CVS branch for this release, which starts as a snapshot > of the development tree when the release candidate is initially > created, and allows the RM to incorporate whatever subsequent HEAD > branch commit

DO NOT REPLY [Bug 27312] New: - amend html:submit with a "label" and "labelKey" attribute for multi-linguality

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27312>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

Re: Tagging and freezing (was Re: Bug in JavascriptValidatorTag)

Quoting Martin Cooper <[EMAIL PROTECTED]>: > On Wed, 25 Feb 2004, Joe Germuska wrote: > > > Perhaps this is understood, but I'm assuming that we also want to say > > that the RM "owns" the release tags for the release he or she is > > managing

Re: Tagging and freezing (was Re: Bug in JavascriptValidatorTag)

On Thu, 26 Feb 2004 10:54:49 -0800 (PST), Martin Cooper wrote: > On Wed, 25 Feb 2004, Joe Germuska wrote: > > >> Perhaps this is understood, but I'm assuming that we also want to >> say that the RM "owns" the release tags for the release he or she >> is ma

Re: Tagging and freezing (was Re: Bug in JavascriptValidatorTag)

On Wed, 25 Feb 2004, Joe Germuska wrote: > Perhaps this is understood, but I'm assuming that we also want to say > that the RM "owns" the release tags for the release he or she is > managing, and only the RM should *ever* move the tags? It's never been stated as su

Re: Tagging and freezing (was Re: Bug in JavascriptValidatorTag)

So, at least as long as folks are happy with me as the RM, please allow me the leeway of a short freeze period between tagging and releasing the build, so that I can do the job as best I can. I don't think that should be too onerous. Fair enough: being RM is a lot of work, I'm sure, and

Tagging and freezing (was Re: Bug in JavascriptValidatorTag)

nt. Here's why. The tag happens before the release build is made, and so obviously before that build is tested. It is quite common that some tweaks need to be made after the tag is initially applied, and before the release is made available. Examples are updating an incorrect version number, ei

Struts Haiku ( RE: 1.2.0 uploaded (Re: 1.2.0 is tagged and frozen))

> From: Tim Chen [mailto:[EMAIL PROTECTED] > > Haiku Hint: > Gentoo rule supreme. > Suse should be a girls name. > Red Hat is for Fools. http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsHaiku -Wendy - To unsubscribe, e-mail:

Re: 1.2.0 uploaded (Re: 1.2.0 is tagged and frozen)

: The release is built, but I have a couple of problems. 1) My ISP has gone flaky on me, and I haven't been able to upload it to minotaur. They claim the problems should be fixed tomorrow, so hopefully I'll be able to upload it then. The release is now, finally, on minotaur. You c

RE: 1.2.0 uploaded (Re: 1.2.0 is tagged and frozen)

On Wed, 25 Feb 2004, Matt Raible wrote: > The first thing I noticed is that struts-el is missing from the > download. I used the one I had from a nightly build in December and it > didn't seem to cause conflicts. Fooey. I don't know why that would have happened. I'll tak

DO NOT REPLY [Bug 27228] New: - nested errors and messages does not have correct nesting for property

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27228>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

RE: 1.2.0 uploaded (Re: 1.2.0 is tagged and frozen) - watch out for ActionErrors -> ActionMessages in validation code

olean validateTwoFields(Object bean, ValidatorAction va, Field field, ActionErrors errors, HttpServletRequest request) However, you can get some nasty silent errors from struts if you do this, as the 'errors' variable won't be populated (it'll be null, due to struts now expecting it to be the A

RE: 1.2.0 uploaded (Re: 1.2.0 is tagged and frozen)

The first thing I noticed is that struts-el is missing from the download. I used the one I had from a nightly build in December and it didn't seem to cause conflicts. I tried 1.2.0 in AppFuse and all tests pass! Nice work gents. I didn't even have to modify any files - my last Str

1.2.0 uploaded (Re: 1.2.0 is tagged and frozen)

On Sun, 22 Feb 2004, Martin Cooper wrote: > The release is built, but I have a couple of problems. > > 1) My ISP has gone flaky on me, and I haven't been able to upload it to > minotaur. They claim the problems should be fixed tomorrow, so hopefully > I'll be able to upl

Re: 1.2.0 is tagged and frozen

On Tue, 24 Feb 2004 06:26:47 -0800, Paul Sundling wrote: > Taking a step back, here is how some other projects are dealing > with this issue: The example I'd be most willing to follow would be the one set by the httpd project: IMHO, these are the true "gia

Re: 1.2.0 is tagged and frozen

Struts is a community and as such its important to know the roles people play in that community - people need to know or be able to find out who the comitters are and, just as importantly, who they are not. If I'm discussing submitting a change to struts - knowing whether people encou

Re: 1.2.0 is tagged and frozen

Ted, I want to start off by saying I look up to you and respect you. I don't consider myself an equal to you or several of the other giants on this project, but I do consider myself part of this community now. In fact, earlier today I changed my email address from [EMAIL PROTECTED] to [

DO NOT REPLY [Bug 22633] - Document how to use web.xml "maxFileSize" and how to deal with "MaxLengthExceededException"

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22633>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

Re: 1.2.0 is tagged and frozen

On Mon, 23 Feb 2004 11:23:08 -0800, Paul Sundling wrote: > I should probably still remove tags from the docs and > consolidate those into the volunteers page also. I'm afraid that our volunteers page is subject to the same considerations as the author tags. :( * Low hanging s

Re: 1.2.0 is tagged and frozen

As an aside to Joe, the person who was bringing up the licenses a couple weeks ago was me. :) From what I read on the instructions for the license file stuff I also need to update the xml that is transformed into our documentation and add a comment to that as well. I'll submit another

Re: 1.2.0 is tagged and frozen

e it's not a Final release? The same > > > lists, or a subset? Thoughts? > > > > Following Craig's description of the Tomcat release approach (copy below), > I'd say we should make an announcement to the Struts DEV and USER lists, with > an URL leading to one o

Re: 1.2.0 is tagged and frozen

Here is what I understood (and used with Validator) Action Response Step #0) Vote for release process to start. RM begins grueling work. Step #1) A release is made. An announcement made on DEVSavvy users download, test. #2) After a period

Re: 1.2.0 is tagged and frozen

hts? > > Following Craig's description of the Tomcat release approach (copy below), I'd say > we should make an announcement to the Struts DEV and USER lists, with an URL leading > to one of our home directories (or wherever Tomcat and others have been posting such > things

Re: 1.2.0 is tagged and frozen

pproach (copy below), I'd say we should make an announcement to the Struts DEV and USER lists, with an URL leading to one of our home directories (or wherever Tomcat and others have been posting such things), but not the Jakarta announcement list. I imagine we'd now reserve the latte

Re: 1.2.0 is tagged and frozen

The release is built, but I have a couple of problems. 1) My ISP has gone flaky on me, and I haven't been able to upload it to minotaur. They claim the problems should be fixed tomorrow, so hopefully I'll be able to upload it then. 2) Some of the exercise-taglibs tests are failing:

1.2.0 is tagged and frozen

Please hold off on all checkins until the release is done. Thanks. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22633] - Document how to use web.xml "maxFileSize" and how to deal with "MaxLengthExceededException"

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22633>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26486] - enhance "required" and other validation actions for form reuse

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26486>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26788] - HTML-EL Frame tag does not process marginheight and marginwidth correctly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26788>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

Re: DO NOT REPLY [Bug 26788] - HTML-EL Frame tag does not process marginheight and marginwidth correctly

At 12:24 PM +0100 2/10/04, Björn Moritz wrote: A quick scan of the source shows, that marginwidth and marginheight are only rendered if they are > 0, so in your case they are not rendered. I don't know if this is the correct behaviour, maybe the > 0 should read >= 0. That's a bu

Re: DO NOT REPLY [Bug 26788] - HTML-EL Frame tag does not process marginheight and marginwidth correctly

A quick scan of the source shows, that marginwidth and marginheight are only rendered if they are > 0, so in your case they are not rendered. I don't know if this is the correct behaviour, maybe the > 0 should read >= 0. Björn > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YO

DO NOT REPLY [Bug 26788] - HTML-EL Frame tag does not process marginheight and marginwidth correctly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26788>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26788] - HTML-EL Frame tag does not process marginheight and marginwidth correctly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26788>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26788] - HTML-EL Frame tag does not process marginheight and marginwidth correctly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26788>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26788] - HTML-EL Frame tag does not process marginheight and marginwidth correctly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26788>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26788] New: - HTML-EL Frame tag does not process marginheight and marginwidth correctly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26788>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26678] - tag must support formatting (format and formatKey attributes)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26678>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26678] - tag must support formatting (format and formatKey attributes)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26678>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26678] New: - tag must support formatting (format and formatKey attributes)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26678>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26486] New: - enhance "required" and other validation actions for form reuse

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26486>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26406] - amend example for wizard form (one big form) with forward and stay/backward steps

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26406>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26406] New: - amend example for wizard form (one big form) with forward and stay/backward steps

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26406>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

RE: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)

t for existing packages that want to do evolutionary development, this is an important issue. My own experience with Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is important for existing users. And it will continue to be. *Nobody* in the real world can migrate to more cur

DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bu

  1   2   3   4   5   6   7   8   9   10   >