Re: Short term plans
Thought are welcome, patches are appreciated. Test cases are ... really nice :-) If there's one thing I've found, persistence (polite persistence) is a very good thing to have as well ;-) John Yu wrote: At 08:31 pm 01-03-03, you wrote: First, David was probably trying to be helpful. (Why reinvent the wheel?) No dispute about that! David's and other committers' dedication of time and energy is much appreciated. But to answer your question, I think the litmus test would be whether there is a working patch annexed. [snipped] Meanwhile, if we have a good suite of tests, and a patch comes along, it will be easier for any of us to commit it (since the tests will help catch any problems). Summing up, is it fair to say that an enhancement request which comes with a patch (and possibly some test cases) will be given relatively higher priority, regardless whether its functionality overlaps with other technologies? (And persistence counts as well.) Shall this be added somewhere on the webpage? -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
Thank you for reminding us of that - seems (nearly) everyone (except you, I, and [ probably still ] Craig) wants to do that in 1.2.0 and that was, at the time we decided to make 1.2.x move to an incremental build system, determined to be more than 1.2.0 should entail. open-mouth/ insert-foot/ ... and folks wonder why it takes a year to see a release ... David Graham wrote: The plan is to change the base servlet requirement in 2.0 not 1.2. David -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term plans
Craig R. McClanahan wrote: On Sat, 1 Mar 2003, Ted Husted wrote: Date: Sat, 01 Mar 2003 17:56:04 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Short term plans Craig R. McClanahan wrote: My personal preferences on the immediate future are to make Struts 1.2 an evolutionary path for existing 1.0 and 1.1 users, but adopt a release often model of 1.2.x releases like what the Apache HTTPD server does, and what Tomcat 4.1 and 5.0 have adopted -- release a new milestone when you've added a new feature or two, or fixed enough bugs to be worthwhile. For 1.2, how about if we finish the Commons-Resources migration, along with whatever api/bug-fixes turn up in the meantime, and call it a release? That by itself would certainly be enough for a 1.2.0, but there's a bunch of other things we've deferred that would make sense in the 1.2.x lifetime. I beleive that was the deal that was struck back some time ago. Not to rain on anyone's parade, but Craig just hit the nail on the head. We went through the debate on that already -- and it was pulling hairs to get consensus. Let's not open it up for discussion again, please. Quick 1.2.0 (bug-fixes) - couple more features in 1.2.x - servlet api change in 2.0. That's how it went, I believe (I think folks can find it on the web site, as a matter of fact [ thanks Ted! ]). -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Relative action URL's for FormTag
Erik, If you could put your patch into Bugzilla (file it against the bug report, please - create a bug report for issues that don't have one yet) we'd much appreciate it. By just sending it to the list, you risk it being lost -- and very likely missed or forgotten. If it's in Bugzilla, whichever one of us gets to tackle that bug will have your patch right there for consideration. If possible, always submit output from 'cvs diff -u' (looks like that's probably what you did - thanks!) and ... I suppose that's it. http://issues.apache.org/bugzilla Thanks for the effort! Erik Tennant wrote: I needed (for reasons beyond my control) to have html:form.. create an action= with a relative URL. Searching the mailing list, I ran across others who were seeking similar functionality. I wrote up a simple addition to FormTag.java that allows an optional isRelative attribute inside the form tag. Image tags have something functionally equivalent, so I'm guessing it may be functionality you are interested in. If you need something else from me, let me know. Thanks, Erik -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Relative action URL's for FormTag
Erik Tennant wrote: ok, I entered it in as bug 17449. Good job - thanks! Unfortunately the firewall at work keeps me from accessing the cvs repository, which is why I did a diff from rc1 instead of from cvs. Maybe there is a cvs client that can operate through a http proxy- I will have to go look into that. Although I assume since rc1 was just released that the cvs head version is the same as rc1 at this point? Hrm ... yeah should be pretty close. If not then CVS generally does a pretty good job of figuring out what needs done. If it turns out to be a problem then whoever applies your patch will just eye-ball the patch and figure out what needs done. That doesn't generally happen though. I wouldn't worry about it as close as we are to RC1. Of course, if you find yourself able to do the diff against RC1 later on you can always post and update and just make note of what you're doing ... or leave it for the commiter handling the bug to figure out ;-) Generally, most of us appreciate someone pointing us in the right direction though :-) Just put something like Updated patch - please use this instead of attachment #. That should suffice. Thanks, Erik No, thank *you* ;-) -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] allow relative actions in struts-config.xml
Thank you, but please either find a bug in bugzilla to attach it to or create one and attach it. We'll probably just lose the patch if you expect the list to keep track of it. http://issues.apache.org/bugzilla -- That's where you can put it. Thanks for the help! Graham Leggett wrote: Hi all, The attached patch allows relative paths to be specified for actions defined in the action-mappings element of struts-config.xml. If the path attribute of the action element is specified without a leading slash, struts now suffix matches the action-mapping paths against the path in the request, instead of doing an exact match. Previously in this case the path would never match. If the path attribute is specified with a leading slash, the behaviour is to find an exact match the same as now. This feature is useful where you want struts to ignore directories in your URL, for example: http://somewhere/context/struts/-country-/show/info.do might display info on a particular country. Defining the action-mapping path as show/info will match all URLs ending with show/info.do regardless of the value of -country-. Previously -country- would have to be specified as either a cookie (not always on), in the session (which may be lost at any time), or as a parameter (requiring link mangling on pages). Comments...? Regards, Graham -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Proposed New Committer: James Turner
+1 - anyone that likes black bears can't be too bad. ;-) Craig R. McClanahan wrote: James Turner has been a long-time contributor of patches to Struts, took over commons-validator when it was languishing (he's a committer there), and is the author of Struts Kick Start. I'd like to propose him as a committer on Struts as well. Here's my +1. Craig -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
I don't really think we need a revote, but if others do you can count in my +1. At this stage, I'm all for marking new bugs as LATER for the next release (whether that be a beta or final). By all means, let's try to knock out the bugs we can between now and the time the beta is cut, but let's cut it none-the-less. (What is the next milestone we're aiming for? 1.1-final? 1.1-beta-4?) Peace Martin Cooper wrote: On Thu, 26 Dec 2002, Ted Husted wrote: Ok, I'll update the Roadmap and the B3 plan with the appropriate queries, and add a box next to the bugs we are swatting to indicate their status. This will at least make the static list easier to maintain =:0) I just updated the site with your updated release plan. Given that the plan has changed from what people voted on, do we need to ((re-)re-)vote on the updated release plan? sigh/ I hope not, but I fear so. FYI, we had 9 +1/+0 responses and no -1/-0 responses, so 9 committers responding out of 14 currently listed. -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/actionExceptionHandler.java
Ugh. I should have credited Erik Hatcher for this patch, but I forgot to put it in on the commit notes. Is there a way I can fix this? [EMAIL PROTECTED] wrote: ekbush 2002/12/25 01:01:46 Modified:src/share/org/apache/struts/action ExceptionHandler.java Log: Make ExceptionHandler obey the controller's inputForward rule. Also, create ActionError instance by passing ex.getMessage() as the first replacement parameter. PR: 12871 -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/actionExceptionHandler.java
You're not that hard to put up with ;-) You just wanted it fixed right and it took finally having time to sit down and examine the situation properly to see it in the correct light. While you may not care about getting the credit, I care about giving it to you :-) Erik Hatcher wrote: No worries... I don't need the credit... I'm just glad it got patched and Struts is all the better for it! :) Thanks Eddie for putting up with my persistence on this issue. I'll give a nightly or beta3 build a try one of these days soon. Erik On Wednesday, December 25, 2002, at 05:15 AM, Eddie Bush wrote: Ugh. I should have credited Erik Hatcher for this patch, but I forgot to put it in on the commit notes. Is there a way I can fix this? [EMAIL PROTECTED] wrote: ekbush 2002/12/25 01:01:46 Modified:src/share/org/apache/struts/action ExceptionHandler.java Log: Make ExceptionHandler obey the controller's inputForward rule. Also, create ActionError instance by passing ex.getMessage() as the first replacement parameter. PR: 12871 -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tying Up Loose Ends
What I've been doing is going to the query page, selecting all severities except enhancement - then selecting struts. I believe this is the method Martin was using, though he could tell you better - as best I can recall, that is the method to use. Ted Husted wrote: Is it not the idea that the computers are suppose to do the counting for us? =:0) =:0) 12/24/2002 2:45:11 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: Count the non-enhancement ones :-). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
Martin Cooper wrote: -- Vote: Struts 1.1b3 Release Plan [X] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable tohelp support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why are people are up on Struts
micael wrote: Anyone who calls vim vi is simply not in a position to judge it. Anyway, I do understand the initial ease of a GUI. I like the speed you get after spending a half-hour to an hour learning something like vim. I hate moving a mouse around and would rather do it with my fingers that are already on the keyboard. Micael The executable on my system is still called vi :-) ... so I feel I'm justified in calling it vi ;-O I too see a place for the IDEs - powering a plugin to enable UML-ing things is one feature that I'm finding attractive. I need to get back to trying Eclipse soon -- and that oomoogoo plugin for UML (no that's not the exact name - the one at elcipseuml.org). Plus ... refactorings etc - there are a few reasons to like an IDE - I don't view straight coding as one of them though ;-O -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why are people are up on Struts
When I fire up vi, it calls itself vim, so ... yes and no. I use it lots of times actually (for super-simple in/out type stuff) - but I haven't really attempted to learn more about it than I already know. micael wrote: The fact that you have vi does not mean you don't have vim, Eddy. Did you try vim? At 01:48 PM 12/14/2002 -0600, you wrote: micael wrote: Anyone who calls vim vi is simply not in a position to judge it. Anyway, I do understand the initial ease of a GUI. I like the speed you get after spending a half-hour to an hour learning something like vim. I hate moving a mouse around and would rather do it with my fingers that are already on the keyboard. Micael The executable on my system is still called vi :-) ... so I feel I'm justified in calling it vi ;-O I too see a place for the IDEs - powering a plugin to enable UML-ing things is one feature that I'm finding attractive. I need to get back to trying Eclipse soon -- and that oomoogoo plugin for UML (no that's not the exact name - the one at elcipseuml.org). Plus ... refactorings etc - there are a few reasons to like an IDE - I don't view straight coding as one of them though ;-O -- Eddie Bush -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why are people are up on Struts
A lot of the power of emacs is contained in it's commands - not just the key-sequences. I'm sure vi users would say the same thing about vi (or vim). Eclipse is certainly a very nifty IDE though - and it's evident they're fighting to be/stay on top. David Graham wrote: Eclipse has an emacs key bindings setting so you can use those commands if you like. In the upcoming version it supports user defined key bindings so you could use vi commands or anything else. David -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] Re: Why are people are up on Struts
LOL - which is one reason why I prefer Emacs :-) ... that, and, for the astute observer, Emacs shows you how to *exit* as soon as you start it (assuming you open it with no arguments)!! If there's one thing I dispise, it's getting trapped in a )@(#%* program - and, yes, when I was first learning vi I got trapped in it! David Graham wrote: Isn't it vi not VI? Or six as I like to call it ;-). I loved my first experience with vi...Why the hell can't I type anything?. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] Re: Why are people are up on Struts
I can live with vi if it's forced upon me, but I much prefer Emacs. 'Course nowadays, assuming you're using an x terminal (or are on windows) both of them are fairly easily used through their toolbars ... at least, I think vim has one now (or can perhaps - nearly certain). I suppose that's for the mortals among us ;-O I just go for the arcane key sequences personally - so much more efficient. One nifty thing I really like about Emacs is that, sometimes I can remember the command name but not it's key sequence - and it tells you what the sequence is once you invoke it the long way. So, I can keep important shortcuts in my head, and, when I run across a situation that requires me to use something that I don't recall the shortcut for, I can invoke it manually and get a referesher on what the sequence is to invoke it. I really like that feature :-) It works great so long as you can remember the command name or ... at least have an idea (as it has completion assistance for commands too). David Graham wrote: I like vi now that I know how to use it but why couldn't they put common commands at the bottom of the screen for us mortals? David -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] Re: Why are people are up on Struts
Here, here! \C-c SPC Esc- \M-x indent-regionEnter I'm reminded of being a lab assistant when I was still in school. Kids that were taking programming 1 for their foreign language credits would constantly as Why is this doing that? type of questions -- *many* of which could have been easily resolved if they only got into the habbit of pressing Ctrl-j at the end of a line instead of just hitting Enter. The first thing I usually did was mark their entire buffer and reformat it (as most of it was aligned neatly to the left margin). From there, determining things like Um ... you know that for loop will only control one statement unless you put the block in curly-braces, right? was a snap. As the semester progressed I'd get nasty too - If I walked up to the terminal of someone I'd helped (generally several times) before, I'd take one look at their code - if it looked like crap I'd tell them to come get me again when they cleaned it up so I could tell what was going on! LOL ... I got (most of) them trained eventually! (Damn slackers!) 'Course that was all C/C++/Pascal/Shell/Scheme type stuff then ... but it's a fine editor for Java too :-) About the only language I've seen that Emacs didn't have a good editor for was COBOL ... but that's more an abomination than a language anyway ;-O (Yes, I realize COBOL is still a very used language, but I also *wish* people would let it die!) Peace! Eddie Benjamin Tomasini wrote: Normally a reader only in this list, but here are 2 cents... With a basic knowledge of Emacs, Ant, and Perl you can conquer the world faster than with any IDE I know of. And conquer it from pretty much any shell - bash, X, even Windows! Plus, Emacs is great for cleaning up messy code. Its indent feature in java-mode (cc-mode) is quite handy. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT]AW: Why are people are up on Struts
I'm not familiar with that version ... I have been intending to try Eclipse again, since I heard they had a kick'n UML plugin that was free. I should do that sometime ... Edgar P. Dollin wrote: The version to try for windoze is lugaru / epsilon. If you learn the keystrokes you will never give it up. Edgar -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Action chaining: (was - Re: Why are people up on Struts)
LOL - this is getting comical :-) Personally, I chain for the same reaons that Laird notes. Ex: deleteDetail.do has a success forward to showDetails.do. Call it illegal, but it works just fine :-) One thing I do do is always redirect instead of forward -- I can certainly see where forwarding to another action could have adverse side-effects (when you consider how form population works). V. Cekvenich wrote: I too get unsure what bus. logic is. But I am all +1 that you have a good practice example. I think it is text book as to what is action and what is not. (if / then ) But that is not chaining. To me chaining means that you have a series of workflow processing that you solve... oh wait. confused. OK, there is good chaining and bad chaining. But thats splitting hairs now. I don't know I guess. Hope Ted chimes in. .V -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Action Organization (was: Action chaining)
Naw - I think what he's saying is that, like you'd have a showUsers which would populate a userForm, then you'd have, say ... createUser, readUser, updateUser, deleteUser. Your deleteUser would then chain back to showUsers so the list could be viewed again. At least ... I think that's kind of what is being discussed :-) You're over-generalizing I believe, Matt ;-) You've got a nifty though, but I'd think it would be a big PITA to implement. Matt Raible wrote: I can't help chiming in as I'm in the midst of writing an example application using Struts for a Wrox book (Professional JSP 2.0). On my last Struts application, I used LookupDispatchAction's for all my actions. I basically organized it by entities, so that I had a UserAction, SearchAction, EventAction for the different types of activities. This seemed to work pretty well, and each class had their respective CRUD details. What Erik seems to be suggesting is having a handful of generic actions - so you end up with DeleteAction, SaveAction, etc. that maybe use reflection to figure out the entity to delete, save, etc? Am I reading this correctly? Sounds like a neat idea, and would probably work, unless you had to have custom business logic for the deletion of an entity. For instance, when I delete a user, I need to delete all other entities associated with that user. Hmmm, sounds like I might want to stick with my LDA architecture. Thoughts? Matt -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: pre-populated ActionForms / suggestion [patch] for beta1.1b2
Thomas Heller wrote:
[ posted to struts-user but i just realized struts-dev might be a better
place for this]
... actually, it's a struts-user question.
Hi there,
I'm trying to create a form with some pre-filled which either come from a
cookie or a database. i browsed the archive and found a comment from Craig
where he says the best way to do this is by routing the specified request
into a action and populate the form there. IMHO this way would complicate
the Actions execute method unnecessary complicat cause it must have a
action-case for prepopulate.
That's the way it's done.
IMHO the best way to handle what i would want to do would be done like this.
1. introduce a prepare(HttpServletRequest request) method info
ActionForm
2. invoke this method in RequestUtils.createActionForm(...) right after
instance.setServlet(servlet) in line 638
Forms are just a conduit by which data is transferred from the user to
an action. In addition, you may wish to use the same form with
different actions (and have it contain different data). The forms
should be as stupid as possible - your suggestions don't allow that. Of
course, if you really insist on this behavior ... you have the source :-)
inside the Forms prepare (populate or some other name) Method i could
prepare all fields like i want including setting values from session,
request, cookies, context, db, etc since i get the current request as a
method param.
You can do that in your action :-) and since you can associate a form
with many different actions you have the flexibility to populate it in
different ways depending on the action that actually populates it ;-)
dunno how to submit patches to struts but it would look something like this:
http://issues.apache.org/bugzilla --- Our bug database. Create a bug
and then attach your code as a cvs diff -u.
class: org.apache.struts.action.ActionForm
[snip]
/**
* Prepare the form before it gets displayed first.
* p
* The default implementation does nothing. Subclasses can
* override this method to insert values from a DB/Cookie into
* the form
*
* @param request The servlet request we are processing
*/
public void prepare(HttpServletRequest request) {
; // Default implementation does nothing
}
[/snip]
All forms written before this method would still work and it eases the work
of setting form values by cookies alot.
I don't really see how it does anything but limit the use of the form.
You would have no additional functionality available to you in the
proposed prepare method compared to what you can do in an action's
execute method. Again, if you wish to make your forms so specfic,
there's nothing to keep you from doing it - the source if freely
available, and there's nothing that keeps you from modifying it to suit
your own needs.
Comments welcome ...
thanks,
Thomas Heller
--
Eddie Bush
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RequestProcessor and processValidate
Eric Beaumier wrote: Hi guys, I have a question regarding the order of using Commons-Validator in Struts 1.1. Actually Struts feed the FORM before doing validation on this one. Because the FORM must not throw exception during this feeding, usually your FORMBEAN use only String datatype as setter/getter. But in the case I receive a Composite Value Object from EJB, using a complexe structure with beans using differents datatypes (String, boolean, long , BigDecimal, ...), I can't use it directly with Nested Tag for editing. Because I can't validate input before feeding a BigDecimal for example! If the user enter hello in Textbox where it suppose to be a BigDecimal, an Exception is Throw ... note what you called your object - you called it a Composite Value Object. Ok, that's cool - still, it's a Value Object. Forms are not meant to be VOs; nor are VOs supposed to be used as forms. Forms *only* exist to give a limbo area for data to sit, in exactly the same state as the user placed it there, until the form passes validation. Only once the form passes validation should your data be copied from the form to your VO. If you use the EJB as your VO, you will not be able to preserve user input because - just like the case you described - some fields might complain about the values that get assigned to them and cause the user input to be lost. Do you will look to add option to do the validation on the Request object first? I don't really see the need. Your VO should always contain valid data. Like this, we can do the unit validation accordingly the validation.xml and when all unit validation is done, you can feed the FORM ... Nested Tag will redisplay the value from Request object at the place of FormBean getter. Give me your feedback ... Thanks. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RequestProcessor and processValidate
David Graham wrote: After you form passes validation you can validate the business rules by copying the form data into your VO and calling some business method. The form validation is only meant to check things like, Is this a credit card number format? or Is this a valid email format?. You need to call a business method to determine if the credit card number is actually valid. David Right. I should have said syntactically valid ;-) I guess that's what you're chewing me out for. Only business rules can determine that they are, in fact, 100% valid. From: Eddie Bush [EMAIL PROTECTED] Subject: Re: RequestProcessor and processValidate Eric Beaumier wrote: Hi guys, I have a question regarding the order of using Commons-Validator in Struts 1.1. Actually Struts feed the FORM before doing validation on this one. Because the FORM must not throw exception during this feeding, usually your FORMBEAN use only String datatype as setter/getter. But in the case I receive a Composite Value Object from EJB, using a complexe structure with beans using differents datatypes (String, boolean, long , BigDecimal, ...), I can't use it directly with Nested Tag for editing. Because I can't validate input before feeding a BigDecimal for example! If the user enter hello in Textbox where it suppose to be a BigDecimal, an Exception is Throw ... note what you called your object - you called it a Composite Value Object. Ok, that's cool - still, it's a Value Object. Forms are not meant to be VOs; nor are VOs supposed to be used as forms. Forms *only* exist to give a limbo area for data to sit, in exactly the same state as the user placed it there, until the form passes validation. Only once the form passes validation should your data be copied from the form to your VO. If you use the EJB as your VO, you will not be able to preserve user input because - just like the case you described - some fields might complain about the values that get assigned to them and cause the user input to be lost. Do you will look to add option to do the validation on the Request object first? I don't really see the need. Your VO should always contain valid data. Like this, we can do the unit validation accordingly the validation.xml and when all unit validation is done, you can feed the FORM ... Nested Tag will redisplay the value from Request object at the place of FormBean getter. Give me your feedback ... Thanks. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ted Husted, Member of the Apache Software Foundation
WT - Go Husted! Congratulations! Well-deserved :-) Craig R. McClanahan wrote: Please join me in congratulating Ted -- at the Apache Software Foundation Member's Meeting (held last night at ApacheCon), Ted was approved for membership in the ASF. Way to go Ted! Craig (PS: Struts In Action is for sale at the bookstore, and I've autographed several copies already :-) -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL] How to implement XHMTL support
You're continually help us newcomers understand things better (at least, you're helping me understand things) - thanks Ted ;-) Ted Husted wrote: The thing with voting at Apache, in respect to coding, is that it usually implies dissent. We take affirmative votes as to granting write access and as to releases, but day-to-day coding is subject to lazy consensus. This means a change is assumed to be kosher unless someone says otherwise. When someone does say otherwise, then we can resort to an actual product-change vote. In some Apache circles, voting on a product change is considered crude. It's believed that we should be able to discuss these things politely and make graceful changes without the overhead of a formal [VOTE]. A consensus vote is a last resort should polite discussion fail. I think in this case, we are actually taking a [POLL] to find out how people feel. In the end, someone will take responsibility for making the change. If we try and we like it, then whatever change is made sticks. But if we try it and we don't like it, then we'll have to change it until we do. I think using the [POLL] header to call attention to a plan is a good idea, but we might want to reserve [VOTE] for new committers, releases, and disputed product-changes. We should also make it clear that we are always interested in what ~everyone~ thinks, developers and committers alike. One subtle point is that Committers are obligated to indicate that we *may* veto an action as soon as possible. So sometimes we mention -1 in the context of discussing a course of action. But that itself is not a veto, but the forewarning of a veto. At Apache, code only rules. -Ted. (I'm not exactly sure myself what that least sentance means, but it shore sounds pretty =;) -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] How to implement XHMTL support
whisperDon't bother drawing a ballot up - these guys don't use it! They're all like thinking outside the box and adding options to it, dude! ... and there's that one fellow who is always saying put your code where your mouth is - we only vote on code - while standing there with a wild, Clint Eastwood look on his face! (Go ahead punk - make my release-candidate!) In any case, most people will tell you to ask for forgiveness instead of permission./whisper I would follow Martin's suggest course of action, plan A. This way, you wind up having access to the tag, which is the Information Expert here. I don't agree with Martin's suggestion that this is a more robust way to handle things - I just think it's sensless to create things you don't need to. It's irrelevant whether you put a Boolean or the tag-handler out there with respect to the mucking of variables - the tag-handler is a java-bean, right? Thus, it could easily be updated at any stage too (ie futzed with). I do think it would be more efficient (albeit ever-so slightly) to just use the tag, since there is no additional creation of a Boolean object to stuff into the request. In either case, yes, you're going to want to add some key to Globals - the name of it I wouldn't hazard a guess at. What you have sounds ok, but it's really representing the tag now, so perhaps it should reflect that in it's name? (ok, fine, I will hazard a pseudo-guess at it! ;-) David Graham wrote: I'm still unclear on the direction we should take here. I'd like to hear from other committers :-). Thanks, Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How to implement XHMTL support
Martin Cooper wrote: On Wed, 13 Nov 2002, David Graham wrote: What would html:isXhtml/ do? This would be the way Craig was seeking for an included page to tell its own Struts tags whether to render XHTML or plain HTML. It would set a *page* context attribute, which the subsequent tags on that page would check. As a corollary, the html:html xhtml=true tag should set the key in *page* scope rather than request scope, so that each page has to make its own decision. If we're going to use a tag I think it should be like this: html:xhtml html:form html:text/ /html:form /html:xhtml Do you mean a separate tag from the html:html tag, instead of using html:html xhtml=true, or are you referring to another tag for the XHTML-ness ;-) of the content? If the former, I'm not sure why we would want that. If the latter, I disagree that it should be a body tag, since it needs to be an all-or-nothing tag, not one that applies only to its body. I too am confused as to why we would need an additional tag. Any tag inside html:xhtml would be rendered as xhtml. This tag would only be useful for jsp included files. Another question: what if html:xhtml is nested inside html:html xhtml=false? I think we should probably log a warning. In many cases, the resulting output will work, but we need to flag that there's a potential problem. -- Martin Cooper David If the outermost document is meant to enforce XHTML, how can an included piece *not* conform to XHTML and the entire document still be XHTML? I ... feel like we're attempting to over-design - but maybe I'm just showing my own ignorance (which is something I don't think I'll ever learn not to do - I learn way too much from being willing to do it). -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How to implement XHMTL support
Martin Cooper wrote: On Wed, 13 Nov 2002, Eddie Bush wrote: big-snip/ If the outermost document is meant to enforce XHTML, how can an included piece *not* conform to XHTML and the entire document still be XHTML? I ... feel like we're attempting to over-design - but maybe I'm just showing my own ignorance (which is something I don't think I'll ever learn not to do - I learn way too much from being willing to do it). It can't, and that's in part what Craig pointed out. Since each included page must also be XHTML, each of those pages should state explicitly that it is XHTML, instead of having the decision about whether or not to generate XHTML be made externally (i.e. on the topmost page). Given that the non-Struts tags on the page must also be explicitly XHTML, that makes sense. Ah - so the tag would serve to say This is XHTML-compliant so that you could then say Wait a sec - you asked for an XHTML document - but you included this and it's not XHTML. I think I understand the reasoning better now. Sorry about being so thick-headed. I figured I was confuzzled, but I wanted to be clear. Thanks Martin ;-) -- Martin Cooper -- Eddie Bush -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts 1.0.2 + Xerces 2.2.0
Yes, I've run into this too -- in my struts config files :-) If you remove the unneeded -- this error should vanish. Examine all comments for occurences of -- which do not belong (ie. do not occur at the start or end of the comment). Ex: Change anything like !-- Foo -- Bar -- to !-- Foo Bar -- David Graham wrote: Have you looked for -- within comments in the xml files your parsing? The error seems pretty clear. David -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Unclear semantics on form use for wizards
I remember someone kind of scoffing at us defaulting forms to session scope -- and adding further that request is really what we should have gone with. They further added that this functionality could not be easily changed, since there were so many Struts apps deployed that undoubtedly relied on the behavior. So ... is this something to slate for 2.0? :-) (if we even still *have* the notion of a form-bean!) Martin Cooper wrote: I'm probably missing something obvious here, since nobody else has mentioned it so far, but wouldn't the simplest way of achieving what you want be to *not* use session-scoped form beans? If each page includes the data for all of the wizard pages, then reset() can safely reset all of the fields in the form bean, in the knowledge that the request will contain the values for all of those fields. Simply use hidden fields for those fields which are not part of the visible page, and those values will be safely round-tripped for you, without having to worry about session data and selective resetting of fields. -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [Vote] Modify classloading in RequestUtils
3.2 isn't even a current release is it? Shouldn't we reserve such a change for compliance with *current* implementations (of the 3.x series - ie TC 3.3-series)? Is there some valid reason, of which I am unaware, that would make it difficult for folks to upgrade? Is there some drawback to using the 3.3-series over the 3.2-series? If issues center around folks making use of proprietary features that are no longer present in the 3.3-series ... well, we all know the risk you run when you do such things. I would think that those folks deeply invested in the 3.x-series features should be able to go to TC 3.3 pretty painlessly - which Struts run fine on (right?). Why is this a bad option for those users? David Graham wrote: Do people still use Tomcat 3.2? It's not like they have to pay to upgrade to 4.1.12. Maybe this isn't such a big deal. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [Vote] Modify classloading in RequestUtils
Martin Cooper wrote: -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Subject: RE: [Vote] Modify classloading in RequestUtils Do people still use Tomcat 3.2? For what it's worth, I believe we agreed, prior to the release of 1.1-b2, to drop support for Tomcat 3.2.x in favour of support for 3.3.x. ... which is what prompted creation of TC 3.3 unit tests, if memory serves. So, if we've dropped support for the container, and we run fine on the container that we do support, there's no issue - right? If there is a solution that fits all containers (ie. nothing will be broken by the change) I think it's reasonable we would do it. If there is not a solution that fits all containers I think it's reasonable we would close the bug with WONTFIX and suggest the upgrade their container. Do we have folks that can properly test this on various containers? I like Craig's suggestion. -- Martin Cooper It's not like they have to pay to upgrade to 4.1.12. Maybe this isn't such a big deal. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [Vote] Modify classloading in RequestUtils
Ted Husted wrote: I think its important to keep in mind that we don't support containers, we support specifications. In practice, we sometimes make allowances for certain containers, so long as they are not too far out of spec. In the past, Struts has generated a few service packs to bring containers into compliance. (Yeah! Us!) The problem I sense here is that some containers might misbehave on this point. We don't have a testing lab with WebSphere and iPlanet and WebLogic and JRun and SilverStream and so on all lined up in row where we can run these tests. We have to rely on the kindness of strangers to try this for us and report back. IMHO, this does not seem like not the time to mess about with the classloaders (and we all know how much we ~love~ classloaders). Unless someone is going to tag this as a showstopper for the 1.1 release, I'd say we can mark this LATER and move on. -Ted. +1 - sounds good. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [OT] Logging with Log4J
RODRIGO CARVALHO DOS SANTOS wrote: I know this is out of topic for this list, but is a common problem for us all. I am using Log4J in my Struts app, and I need to use a component encapsulated in a JAR file that uses Log4J too. How is the best way to configure the Singleton Logger? Have you used Log4J much? Typical use is that you instantiate a private static logger per class and name it after that class. An example of this can be found in the Struts User Guide ... and many, many other places. This is precisely how I would do a singleton or any other class. I need to configure my loggers and the component need to configure his own Loggers. Unless the component has done something special or you do something special to make a different file be used, both configurations would reside in a single lo4j.properties file which is in the classpath. I intend to encapsulate part of my code as components that use Log4J, how should I document my configuration needs? If you follow convention, users of your components may, by knowing the package structure of your component and the class names, enable/disable logging in as coarse-/fine-grained way as they like. If any one has a good link for the topic, it will very helpfull. See the log4j site. See the Struts User Guide for a short blurb. I would also examine commons-logging. By doing so, it suddenly becomes irrelevant if your users have chosen to use the jdk1.4 logger, log4j, or insert favorite logging package here - they all work equally well. Thanks in advance, Rodrigo Santos. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
faqs.xsl
Is this file not in CVS? We're using it to build the website, but I don't think the file got checked in. Could whomever owns faqs.xsl please add it to CVS, so the rest of us can build the website too? :-) (I updated it to use struts.xsl for now - works ... but I'd like to have the real one) Thanks! -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-struts/doc/stylesheets faqs.xsl
You da man! Thanks, Ted! [EMAIL PROTECTED] wrote: husted 2002/11/06 11:27:00 Added: doc/stylesheets faqs.xsl Log: Stylesheet for the new FAQ area. Revision ChangesPath 1.1 jakarta-struts/doc/stylesheets/faqs.xsl -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: New To Struts
This is a struts-user question. I'll forward it over there for you. Maya Menon wrote: Hi all, I am new to Struts and plan to do my Enterprise application in WSAD using Struts framework. can anyone please guide me on the steps that I should proceed with ? If any one has a link please send it to me. Thanks Maya Menon -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Nightly build issue
Erik Hatcher wrote: I'm still not having any luck with this issue (now at the 20021029 build). I've been toying with the request.setURL call in a Cactus beginXXX method, but that has no effect at all on this even though I can tell my setting of the servlet path is working (in my testXXX I println request.getServletPath()). Very strange. I wonder if it has to do with the request value of RequestProcessor.INCLUDE_SERVLET_PATH being blank instead? Anyone have thoughts on this? Would you mind making the than change, Eddie? I can try it on the next build to see if my tests then start working. Not a bit. I'd intended to do this already but life has been slightly frantic here recently. I'll endeavor to have it there for the next nightly. Thanks, Erik -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Nightly build issue
Can you verify your assumption with the logging output? It should say
what the value of matchPath is. This would be a debug-level logging
statment indicated by a line stating:
Selecting module for path matchPath
You may have to turn up the volume on your logging output to see it.
I'd be most interested in what's going on here.
If there is a case where the first character of matchPath may not be a
/ then that condition needs to change to a instead of !=. I was of
the impression that the first element of that string would always be a /.
Erik Hatcher wrote:
More information after digging a bit. The change to RequestUtils (in
version 1.61) has this log:
Revision : 1.61
Date : 2002/10/15 17:37:25
Author : 'ekbush'
State : 'Exp'
Lines : +33 -11
Description :
Change RequestUtils.selectApplication so that it looks for an exact
match
rather than using the startsWith criteria.This fixes a problem where
an incorrect module would be selected that either became aparant when
the application had modules where the name of one could be used as the
root
of the other.The bug also manifests itself when an action is invoked
from
the default module, which has a path that could be interpreted as a
root of
a non-default module.
Ex:modules /foo and /foobar
module /foo and action /foo in the default module
PR: 12702
And here is the relevant change:
while (prefix.equals()
((lastSlash = matchPath.lastIndexOf(/)) != 0)) {
// We may be in a non-default module. Try to get it's
prefix.
matchPath = matchPath.substring(0, lastSlash);
// Match against the list of module prefixes
for (int i = 0; i prefixes.length; i++) {
if (matchPath.equals(prefixes[i])) {
prefix = prefixes[i];
break;
}
}
}
lastIndexOf is obviously returning -1 meaning that there is no / in
matchPath. My application works fine deployed, so this seems like an
interaction with StrutsTestCase or Cactus with the servlet path being
null.
If anyone has ideas on where to dig further to see where a fix is
needed then I'd happily take it the extra distance and give it a shot
to fix it.
Erik
--
Eddie Bush
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [struts-el] HTML taglib
Yes - that's what I have installed globally. NB just updated to 1.5 the other day as well (yes, 1.5.1), so that should be gold too. I still manage the Struts compiles fromt he command-line though (so it's always built using 1.5.1). Rob Leland wrote: Eddie Bush wrote: Ok - this nearly *has* to be an issue with either Ant 1.4.1 or NB. Just for Reference to properly build Jakarta-Commons you'll need to use Ant 1.5.1. -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Validator Integration
I just forwarded the discussion to you, David. It happened on the 23rd. David Graham wrote: It struck me the other day that the validator could be further integrated into struts. I'm not sure about my ideas so I want to get your thoughts. Why should people need to subclass ValidatorActionForm instead of ActionForm to use the validator? What forms have you built that didn't need validation? My idea is that the ValidatorActionForm and ValidatorForm (why are there 2?) behavior should be included in ActionForm and have those classes removed. I think this will maintain backward compatibility because if the developer hasn't defined any validation rules for a form then we could return null from validate(). Further, we could include validator configuration tags in struts-config.xml instead of using a plugin. This would signify that validator is an integral piece of struts that most people want to use (which I believe they do). This is probably a post 1.1 idea but I thought I'd throw it out here. What do you think? David _ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [struts-el] HTML taglib
It doesn't appear to make any difference inside NB. I even restarted NB to ensure if there was some funky caching going on I was unaware of it would (hopefully) be updated. No dice. I think testing it directly under Tomcat shows this is an issue with NB though. I'm fairly certain this probably has to do with the JSP compiler. More precisely, I believe it probably has to do with the JSP compiler available under Tomcat 4.0. I'm not 100% certain on this though. Is this conceivable? I have a couple different installs of Tomcat. One is used by NB internally (TC 4.0.4) and another which I installed from binary (4.1.12, I think). Under NB there are issues. However, I've seen that the TC 4.1.12 install will compile the page just fine. If that doesn't just blow a person's mind. Perhaps it has something to do with my running JDK 1.4_01. In any case, I think we can rest assured it's not a bug in struts-el. I'll just deal with it. Thanks for your assistance though, David. If you have any other suggestions, I'm happy to try them. David M. Karr wrote: Eddie == Eddie Bush [EMAIL PROTECTED] writes: Eddie Ok - this nearly *has* to be an issue with either Ant 1.4.1 or NB. I finally Eddie got a chance to try it under Tomcat (4.1.12) and it worked *just fine*. Sorry Eddie - next time test outside of the IDE before I assume something is up. What a Eddie PITA. There's something silly I'd like you to try, just as an experiment, if you can still get it to fail in NB. In ELHtmlTag.java, add just the following line: private static Class beanInfoClass = ELHtmlTagBeanInfo.class; and retest. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Validator Integration
Sounds cool - sounds like a pretty substantial change though. Maybe we could table it for now and pick it up for 2.0.x? Of course, at that point, we'll have JSF coming in (most likely) and it will bring it's own pluggable field validators ... and what else will we need? David Graham wrote: Actually, I think that's what I really wanted without knowing it :-). Struts already provides pluggable RequestProcessors for the ActionServlet, maybe it should allow pluggable Validators for ActionForms. This way, we don't mandate the use of the commons validator or anything else, we just allow different implementations. My first thought is that there could be a Validator (or ActionFormValidator, etc.) interface with a method like: ActionErrors validate(ActionForm form, any other needed params); We could provide a compliant implementation class for the commons validator. Just like RequestProcessor, the validator implementation could be configured in struts-config.xml. I think this addresses Ted's concerns of mandating the use of certain technologies because it creates a pluggable service layer. What do you think? David -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [struts-el] HTML taglib
Me too ;-) Karr, David wrote: At end. -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] David M. Karr wrote: Eddie == Eddie Bush [EMAIL PROTECTED] writes: Eddie Ok - you asked for it. Note that this error *only* arises if I try to use the Eddie html tag (ELHtmlTag class). It occurs during page compilation - Eddie not during execution. Eddie index.jsp [-1:-1] java.lang.ExceptionInInitializerError Eddie at java.lang.Class.forName0(Native Method) Eddie at java.lang.Class.forName(Class.java:130) Eddie Caused by: java.lang.NullPointerException Eddie at Eddie org.apache.struts.util.MessageResources.getMessageResources(Me ssageResources.java:577) Eddie at org.apache.struts.taglib.html.HtmlTag.clinit(HtmlTag.java:91) Ok, I've thought about this a bit, but I only have a minute now. I have a couple of wild guesses to make. Are you using Tomcat, and just using the Manager to reload your application, after you added the references to html-el:html? If so, do a remove on the application and reinstall it. If that works, I think this might be a bug/feature in Tomcat, wrt reflection, classloading, and BeanInfo classes. Impossible. Recall (did I not mention this? maybe I didn't ...) I build an absolutely new app - very small - which includes that one tag. If I use the struts-html set all is good. If I use struts-html-el it ... pukes :-( It's not a matter of running. It's *compiling* (hasn't run at this point) when the error occurrs. I do run Tomcat though, but this doesn't happen as part of a reload. This happens in Netbeans. It happens only if I use ELHtmlTag. It happens only during compilation. I'll move the app over to a webapp folder and see if it pukes under TC. I'm not certain how compiling in Netbeans works. I just use it as a debugger and do a remote attach. I believe your problem may be related to the fact that the BeanInfo class is only loaded by reflection, and not by a direct reference. In Netbeans, will it only compile and load the source files you explicitly add to the project, or will it compile all the source files in a directory? If it is somehow not compiling and loading the BeanInfo classes, you might see this problem. Ok - I build struts/struts-el/insert any other .java sources here by using ant directly. The JSP files I let NB handle whenever it things it needs to. That really isn't relevant here though, since I have a compiled binary distribution in a web application. I dump JARs into the app - compiled by ant from the command-line. In other words, if it's in need of compilation, it will get compiled. I love NB for easing certain things, but I *always* compile using ant. So - in essence, I'm working with a nightly binary distribution. Compilation of the library has been done successfully. It's only when NB goes to compile the JSP page that it pukes. So far as compilation goes (since you asked), NB will compile anything under a given leg that you tell it to compile. It relies on you mounting JARs and filesystems which contain the libraries you will be using (this is how you add things to your classpath). As I said though, this is not an issue. The odd thing is that the ELHtmlTag class is the only one I've had problems with thus far. The others use bean info classes too, from what I can tell... so I'd think it would be a more widespread problem if it were something of that nature giving fits. I'm just a wee bit stumped. I haven't had a chance to dump that little test app over to TC yet. I've got other fish that need fried. Once I do that I'll let you know what happens. Is it conceivable this would be a bug in ant? NB uses 1.4.1 (I believe) for things. Maybe I need to go figure out how to make ant 1.5 (my global install) do that too. :-/ IDEs are cool things, but they just don't move as fast as one might like wrt keeping pace on revisions of things. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [struts-el] HTML taglib
David M. Karr wrote: Eddie == Eddie Bush [EMAIL PROTECTED] writes: Eddie Ok - you asked for it. Note that this error *only* arises if I try to use the Eddie html tag (ELHtmlTag class). It occurs during page compilation - Eddie not during execution. Eddie index.jsp [-1:-1] java.lang.ExceptionInInitializerError Eddie at java.lang.Class.forName0(Native Method) Eddie Caused by: java.lang.NullPointerException Eddie at Eddie org.apache.struts.util.MessageResources.getMessageResources(MessageResources.java:577) Eddie at org.apache.struts.taglib.html.HtmlTag.clinit(HtmlTag.java:91) That seems to point to a problem in my ELHtmlTagBeanInfo class (I've noticed I get an error like this if I make a mistake in the PropertyDescriptor array). Unfortunately, the way the BeanInfo class is used, if you make a mistake in setting the PropertyDescriptor array, the stack trace doesn't even include the BeanInfo class. Unfortunately, I'm not having any trouble building, deploying, or running the strutsel-exercise-taglib, which is using that tag. Could you trace this in the debugger? I assume you've recently cvs updated? I'm building out of head :-( -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [struts-el] HTML taglib
David M. Karr wrote: Eddie == Eddie Bush [EMAIL PROTECTED] writes: Eddie Ok - you asked for it. Note that this error *only* arises if I try to use the Eddie html tag (ELHtmlTag class). It occurs during page compilation - Eddie not during execution. Eddie index.jsp [-1:-1] java.lang.ExceptionInInitializerError Eddie at java.lang.Class.forName0(Native Method) Eddie at java.lang.Class.forName(Class.java:130) Eddie Caused by: java.lang.NullPointerException Eddie at Eddie org.apache.struts.util.MessageResources.getMessageResources(MessageResources.java:577) Eddie at org.apache.struts.taglib.html.HtmlTag.clinit(HtmlTag.java:91) Ok, I've thought about this a bit, but I only have a minute now. I have a couple of wild guesses to make. Are you using Tomcat, and just using the Manager to reload your application, after you added the references to html-el:html? If so, do a remove on the application and reinstall it. If that works, I think this might be a bug/feature in Tomcat, wrt reflection, classloading, and BeanInfo classes. Impossible. Recall (did I not mention this? maybe I didn't ...) I build an absolutely new app - very small - which includes that one tag. If I use the struts-html set all is good. If I use struts-html-el it ... pukes :-( It's not a matter of running. It's *compiling* (hasn't run at this point) when the error occurrs. I do run Tomcat though, but this doesn't happen as part of a reload. This happens in Netbeans. It happens only if I use ELHtmlTag. It happens only during compilation. I'll move the app over to a webapp folder and see if it pukes under TC. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [struts-el] HTML taglib
Ok - this nearly *has* to be an issue with either Ant 1.4.1 or NB. I finally got a chance to try it under Tomcat (4.1.12) and it worked *just fine*. Sorry - next time test outside of the IDE before I assume something is up. What a PITA. Thanks, David, Eddie -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] James Mitchell as Struts Committer
Not that you need it now :-) but +1 Ted Husted wrote: James Mitchell has been a long-time contributor of good ideas as well as patches on the developer list. He is also generous with his help on the user list. I believe it's time that we nominated James as a Committer. After all, we can always use another Evangelist. Here's my +1 -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: HTML formatting of newline characters with bean:write tag
There are already taglibs that do this transformation, aren't there? Doesn't the taglibs project have things that address this? Is there a way to do this using the JSTL (Martin?)? David Graham wrote: If this is a common problem, maybe we could add a method to Action like breakNewLines(String) that does this transformation. The bean:write tag should not do any transformation, just display what it's given. What do you think? Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: HTML formatting of newline characters with bean:write tag
Let me correct myself. It does not appear there is such an animal in taglibs at this point in time. There was someone wanting c:out to provide this behavior, and the response was that the string taglib may provide this functionality in the future. You may wish to join taglibs-user or taglibs-dev to influence this development. Eddie Bush wrote: There are already taglibs that do this transformation, aren't there? Doesn't the taglibs project have things that address this? Is there a way to do this using the JSTL (Martin?)? David Graham wrote: If this is a common problem, maybe we could add a method to Action like breakNewLines(String) that does this transformation. The bean:write tag should not do any transformation, just display what it's given. What do you think? Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: HTML formatting of newline characters with bean:write tag
Yeah - I don't think Struts should be responsible for this either. As I said - check out Jakarta Taglibs. There is discussion of implementing this behavior in the string taglib I think. edgar wrote: Wouldn't the solution be, rather than rewriting the bean:write tag, be for *someone* to write a tag which in the processing of the body substitutes \n for br /. You would use it like usertag:brbean:write property='' //usertag:br I have one which sticks in tr /tr after a given number of td or th if you want a sample. This way there is a clean deliniation between struts and user code. Edgar -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
[struts-el] HTML taglib
Is anyone else unable to compile JSPs which make use of the struts-html-el:html tag? I was changing some struts-html stuff over to use struts-html-el so I could just remove all references to struts-html (one less thing to refer to and I don't have to think about whether I can use EL or not - just use it if I need to [later]), and started noticing pages weren't compiling. I tracked it down to (so far just) the ELHtmlTag class. I can provide the listing for the error if need be. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [struts-el] HTML taglib
Ok - you asked for it. Note that this error *only* arises if I try to use the html tag (ELHtmlTag class). It occurs during page compilation - not during execution. index.jsp [-1:-1] java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:130) at org.apache.strutsel.taglib.html.ELHtmlTagBeanInfo.class$(ELHtmlTagBeanInfo.java:91) at org.apache.strutsel.taglib.html.ELHtmlTagBeanInfo.getPropertyDescriptors(ELHtmlTagBeanInfo.java:91) at java.beans.Introspector.getTargetPropertyInfo(Introspector.java:420) at java.beans.Introspector.getBeanInfo(Introspector.java:361) at java.beans.Introspector.getBeanInfo(Introspector.java:132) at org.apache.jasper.compiler.TagCache.setTagHandlerClass(TagCache.java:116) at org.apache.jasper.compiler.TagBeginGenerator.init(TagBeginGenerator.java:146) at org.netbeans.modules.web.jspparser.AnalyzerParseEventListener.addGenerator(AnalyzerParseEventListener.java:156) at org.netbeans.modules.web.jspparser.AnalyzerParseEventListener.handleTagBegin(AnalyzerParseEventListener.java:955) at org.apache.jasper.compiler.DelegatingListener.handleTagBegin(DelegatingListener.java:221) at org.apache.jasper.compiler.DelegatingListener.handleTagBegin(DelegatingListener.java:216) at org.apache.jasper.compiler.Parser$Tag.accept(Parser.java:878) at org.apache.jasper.compiler.Parser.parse(Parser.java:1145) at org.apache.jasper.compiler.Parser.parse(Parser.java:1103) at org.apache.jasper.compiler.Parser.parse(Parser.java:1099) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:214) at org.netbeans.modules.web.jspparser.JspParserImpl.callTomcatParser(JspParserImpl.java:130) at org.netbeans.modules.web.jspparser.JspParserImpl.analyzePage(JspParserImpl.java:97) at org.netbeans.modules.web.core.jsploader.JspDataObject.createCompiler(JspDataObject.java:323) at org.netbeans.modules.web.core.jsploader.JspCompilerSupport.addToJob(JspCompilerSupport.java:67) at org.openide.loaders.CompilerSupport.prepareJobFor(CompilerSupport.java:183) at org.openide.loaders.CompilerSupport.prepareJob(CompilerSupport.java:150) at org.openide.actions.AbstractCompileAction.compileNodes(AbstractCompileAction.java:106) at org.openide.actions.AbstractCompileAction.performAction(AbstractCompileAction.java:47) at org.openide.util.actions.NodeAction.performAction(NodeAction.java:179) at org.openide.util.actions.NodeAction.actionPerformed(NodeAction.java:170) at org.netbeans.core.ModuleActions$1.run(ModuleActions.java:100) at org.openide.util.Task.run(Task.java:136) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:599) Caused by: java.lang.NullPointerException at org.apache.struts.util.MessageResources.getMessageResources(MessageResources.java:577) at org.apache.struts.taglib.html.HtmlTag.clinit(HtmlTag.java:91) ... 31 more Karr, David wrote: Tell us what happened, Eddie. -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Wednesday, October 23, 2002 1:41 PM To: Struts Developers List Subject: [struts-el] HTML taglib Is anyone else unable to compile JSPs which make use of the struts-html-el:html tag? I was changing some struts-html stuff over to use struts-html-el so I could just remove all references to struts-html (one less thing to refer to and I don't have to think about whether I can use EL or not - just use it if I need to [later]), and started noticing pages weren't compiling. I tracked it down to (so far just) the ELHtmlTag class. I can provide the listing for the error if need be. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [struts-el] HTML taglib
Oh, btw, it does not matter if it is a page fragment or a full page. I think you noted that fragments can be problematic sometimes. I am using JDK 1.4_01 and Netbeans 3.4 - I suppose it could be related to one of those, but this is the only tag that seems to give me fits. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts-EL - BUILD FAILED
I got angry because the more I fixed the more that got broke - and wound up just hacking it to work. I'll revisit this soon and give it a proper fix. I was actually trying to do something else when this cropped up ... Karr, David wrote: Dunno. I've never tried to use relative paths myself. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: HTML, XML, XHTML and html:html
Matt, have you tried br / as was suggested yesterday or the day before? Someone made note that br/ would not work, but br / would work. The reason is that the browser will try to interpret everything between and as a tag. The space makes it think that the slash is an unknown attribute instead of part of the tag name. I don't know this for a fact, but I never saw you give a rebuttal for this point so I thought I'd restate it as a possibility. I can't claim any great degree of familiarity with the top - just trying to help. Matt Read wrote: I don't agree I'm afraid. I'm also fairly aware of the difference between CSS and XHTML. Try this in Netscape 4.x and then in IE 4-6. htmlbodyLine 1br/Line2/body/html Matt. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: HTML, XML, XHTML and html:html
Matt Read wrote: Sorry that I keep using the br tag as an example because I agree it's not a particularly good, although it does demonstrate my point. I see a problem not with the br tag in particular as obviously Struts taglibs don't generate them, but that to be absolutely certain that there aren't any major problems with older browsers and XHTML, we would have to run a very comprehensive regression test on a significant number of browser/OS/version combinations. As far as I know neither struts or the browser vendors have the regression tests available for this. I'm not arguing for or against :-) Just stating something I thought you missed. I have to say that you make a very valid point though. As much as I'd like to be able build sites that worked only in Mozilla 1.0 and IE6.0, my customers still feel that the minority browsers are important. Until that trend finishes (I think we've got at least a year yet), I would hate to be stalled on a particular version of struts when we could easily make it a configurable option. As Craig mentioned, that would be the way to do it. Make it optional - default current behavior (off). How about a compromise... instead of each tag having to be explicitly configured, add a generic request processor configuration item in struts-config.xml? Can we save it for 1.2.x? :-) ... or is this something we've stated would be in 1.1F and I'm just not familiar with it? Matt. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bugzilla down?
Anyone? It's just looking at me funny and timing out. I think I ticked off that giant ant on the main page! Anyone else having problems? -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Bugzilla down?
I think that box is down - can someone confirm? I can't ping it. Who do I inform? Eddie Bush wrote: Anyone? It's just looking at me funny and timing out. I think I ticked off that giant ant on the main page! Anyone else having problems? -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts-EL - BUILD FAILED
Ok - exploring that path. I need to know how the directory structure is on the machine nightlies run on (Craig's machine?). Does he have the different servlet APIs out there on the same level as the Struts directory? Either all paths have to be specified as relative or they must be absolute (duh!). Currently they're relative - but incorrect (at least in my updated checkout they are). Should we stay relative and expect there will be checkouts of the dependencies on the same level as the jakarta-struts directory (ie jakarta-taglibs, etc), or move to specifying those base directory names independently? Any preference? Which is best? I'm thinking that the least painful approach would be to stick with relative paths and expect people would have the dependencies checked out on the same level as struts. Sound good? When I say same level, I mean: someDirectory/ jakarta-struts/ jakarta-taglibs/ somethingElse/ they all share the same parent directory. Karr, David wrote: You don't really need to build the JSTL, just use the binary package. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts-EL - BUILD FAILED
Well the default build is looking at things like ../somewhere and it needs to at least go to ../../../somewhere. At least, I'd think it should. Yes, it could probably be overriden in a custom properties file, but shouldn't there be reasonable default values? Martin Cooper wrote: I haven't looked at the struts-el build, but are you sure this relative path thing isn't just a question of default values which can be overridden in your build.properties file? -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts-EL - BUILD FAILED
Karr, David wrote: Well, the exercise-taglib is supposed to do some of this. Over time, I've been adding several things to the strutsel-exercise-taglib that aren't in the base app. Every time I write an example that I realize isn't covered, I add it to the app. Some of these could be added to the base app, with modifications. There's also the unit tests, which are convenient in that they can be run automatically (as opposed to the exercise app), but they test the tag code directly, and bypass the TLD and the JSP compilation process. Ok, so that may not be as useful as I though. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts-EL - BUILD FAILED
Craig R. McClanahan wrote:
On Mon, 21 Oct 2002, Eddie Bush wrote:
Date: Mon, 21 Oct 2002 13:45:38 -0500
From: Eddie Bush [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Struts-EL - BUILD FAILED
Ok - exploring that path. I need to know how the directory structure is
on the machine nightlies run on (Craig's machine?). Does he have the
different servlet APIs out there on the same level as the Struts directory?
I leverage the following statements at the top of the build.xml file:
property file=${user.home}/build.properties/
property file=build.properties/
to allow me to put all my default paths into the single global file
(shared across all projects), with occasional individual overrides in a
local build.properties file. Therefore, my particular directory structure
doesn't need to have any influence over the standard build.xml files we
ship, or the build.properties.example files we provide.
Gotcha.
Either all paths have to be specified as relative or they must be
absolute (duh!). Currently they're relative - but incorrect (at least
in my updated checkout they are). Should we stay relative and expect
there will be checkouts of the dependencies on the same level as the
jakarta-struts directory (ie jakarta-taglibs, etc), or move to
specifying those base directory names independently?
I think relative paths like this for the default property values are a
reasonable default convenience, but everything should be parameterized
(for example, each JAR file should have its own property) so that
individual users can easily adapt.
For things like servlet api, do you prefer servlet.jar (we're actually
using two different ones here, right?) or should (for struts-el) we use
something like servlet23.jar?
Any preference? Which is best? I'm thinking that the least painful
approach would be to stick with relative paths and expect people would
have the dependencies checked out on the same level as struts. Sound
good?
When I say same level, I mean:
someDirectory/
jakarta-struts/
jakarta-taglibs/
somethingElse/
they all share the same parent directory.
This happens to be true of my build environment (for the Jakarta packages
I'm interested in building, chiefly Struts and Commons), but *not* of what
I actually compile with -- I will often point at production releases of
particular commons packages, for example.
Karr, David wrote:
You don't really need to build the JSTL, just use the binary package.
That's one of my examples for being independent of the directory structure
-- my global build.properties file includes (among others) the following
directives to force the use of a binary release of JSTL:
standard.home=/usr/local/standard-1.0.1
jstl.jar=${standard.home}/lib/jstl.jar
standard.jar=${standard.home}/lib/standard.jar
so the default values for the latter two properties are totally irrelevant
to me.
Gotcha.
--
Eddie Bush
Craig
--
Eddie Bush
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts-EL - BUILD FAILED
David - where does it dump out the JARs for the standard taglib? Do they really go in Destination JAR for tag library, or are my properties maybe not configured well? The build went fine (for the standard taglib), but I sure have some odd directory names ... Karr, David wrote: -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, October 21, 2002 10:55 AM To: Struts Developers List Subject: Struts-EL - BUILD FAILED The build script for struts-el seems to not be working for me. I'm fixing it right now. Anyone else experiencing difficulties? I haven't updated in a few days, but I haven't seen any problems with my local build. What is happening? -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts-EL - BUILD FAILED
Any thoughts on going maven in 1.2? Craig R. McClanahan wrote: On Mon, 21 Oct 2002, Eddie Bush wrote: [snip] For things like servlet api, do you prefer servlet.jar (we're actually using two different ones here, right?) or should (for struts-el) we use something like servlet23.jar? For the main parts of Struts, use servlet.jar -- it will compile against either. For struts-el use servlet23.jar instead (although, of course, it will also compile against the Servlet 2.4 APIs). -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Struts-EL - BUILD FAILED
The build script for struts-el seems to not be working for me. I'm fixing it right now. Anyone else experiencing difficulties? -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts-EL - BUILD FAILED
That may be a good thing to do too. ... but why? What other level is
there that isn't covered? We have the top struts dist covered - that
*should be* inherited if it is to be used (currently it's explicitly not
inheriting, I believe). The struts-el has a opportunity to set things.
The users file is being used. Where else do we really need one?
Craig R. McClanahan wrote:
On Mon, 21 Oct 2002, James Mitchell wrote:
Date: Mon, 21 Oct 2002 16:41:23 -0400
From: James Mitchell [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: RE: Struts-EL - BUILD FAILED
The quickest solution for me (temporary solution, since my refresh
overwrites everything) was to change the struts-el from:
property file=${user.home}/build.properties/
to:
property file=../../build.properties/
Why not just add this as a third source of properties?
Craig
--
Eddie Bush
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts-EL - BUILD FAILED
Craig R. McClanahan wrote: On Mon, 21 Oct 2002, Eddie Bush wrote: Date: Mon, 21 Oct 2002 15:28:43 -0500 From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Struts-EL - BUILD FAILED Any thoughts on going maven in 1.2? It's definitely on the list of things I want to look at. I'd sure like to see them get to a 1.0 final first, though. Craig Yeah - I noticed they hadn't had a 1.0 release yet. It looks like they're getting close though (that's why I was saying 1.2, but there's no guarantee they'll have one then either). Would that remedy these sorts of issues? -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts-EL - BUILD FAILED
Something like that should be post 1.1 though, IMHO. (as useful as it would be) Eddie Bush wrote: Did you patch it already? If you have file the bug and attach the patch. If not, I'll continue as per what has been discussed here (going off Craig's suggestions). So far as testing: Wouldn't it be good of us to have a struts-test app which we could exercise things in? ... or struts-regressions? ... something we target our tests on specifically? It wouldn't necessarily be aimed at showing the users a functional application as it would be at testing struts - though there would undoubtedly be some good examples in it too. James Mitchell wrote: I've already filled out a bug for this very issue, and will be submitting it shortly. There are a couple of issues I would like to see address wrt building and testing of the entire project. James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Craig R. McClanahan wrote: Three quick notes: * We should specifically ask on the user list about the timing of Servlet 2.3 / JSP 1.2 dependence. I would expect this to be a bit controversial on that short a time frame. On the other hand, knowing we could interoperate with (and not just integrate with) JSTL (and JSF when done) would be nice. +0 * If the STXX folks are still interested, I'd like to see more formal support for XML processing pipelines be included in a 1.2 time frame. This will help people who want to leverage Struts in a web services hype world, as well as being generally useful. +1 Yep - lots of interest there, I think. * I'd defer a decision on whether Struts 2.0 advances to Servlet 2.4 and JSP 2.0 or not for a while yet -- to me, it really depends on the adoption rate for J2EE 1.4 and the availability of products that run it. From the Struts perspective, Servlet 2.3-2.4 doesn't buy a lot, but the JSP 1.2-2.0 changes are going to be very very useful. +1 Yep. Craig -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Struts Roadmap
Here, here ... David Graham wrote: I don't think Jan. 2003 is a reasonable time to get 1.2 out. Jakarta projects don't advertise release dates and I don't think we should start now. David -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
+1 Ted Husted wrote: Erik, If you'd like to write a section for the UserGuide on using XDoclet with Struts, I'm sure we'd all love to read it =:0) -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
I'm thick-headed and stupid - that's the problem. I was misreading the document earlier. My apologies. Ted stated Remaining ..., but I read in 1.2. shake-head/ I'm sorry. Martin Cooper wrote: I'm beginning to think that you and Eddie are reading a different document that the one I'm seeing. I don't see anything in this doc that mentions contrib libraries at all, and regarding Eddie's comment, Tiles is listed under Struts 1.1, not 1.2. Regarding Struts-EL, I fully expect that it will be included as a contrib taglib in the Struts 1.1 release. This is very cool stuff. -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Byrne, Steven wrote: Here's the draft roadmap that I wrote up. Struts 1.1 * Servlet 2.2 / JSP 1.1 based * tiles validator first class citizens * tiles module aware * validator module aware * Struts-el tag lib at contrib status * [need help here] ??? factored out into jakarta commons * resources factored out into commons-resources? Struts 1.2 January 2003 [duration: 2 months? ] * Servlet 2.3 / JSP 1.2 based -1 * Struts-el tag lib integrated * Support for distributed struts components within a single application (either by just having a list of them or by using some assembling technology) * tiles JSTL aware ? What is the problem with Tiles' JSTL awareness? * 1.1 bug fixes This would be about the only thing here IMHO. * [need help here] ??? factored out into jakarta commons Struts 2.0 Q2 2003 [duration: ??? months ] * Servlet 2.4 / JSP 2.0 -1 - 2.0 will be 2.3 /1.2 * JSF integration Right. [I'm not sure whether to tie these items in with the above roadmap or not] Struts 1.2 * investigate and prototype alternative module organizations including * arbitrary levels of nesting This can be done now. * locale based structuring * inheritance of elements from base types * struts-config * tiles [already has this, but there may be ways to make it cleaner] * validators * investigate adding identifier namespaces The sharing is the thing we're struggling with - more precisely the timing of implementing it. It has been suggested this would happen in 1.2, and I think that's acceptable. I think (personally) 1.2 should focus *only* on how we will give more brains to modules. It should be a *quick* turn-around - throwing in 2.3 / 1.2 will do nothing to aid it's quick delivery, and Craig himself suggested those changes (along iwth JSF) be slated for 2.0. I like his idea. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: template status
Daniel Honig wrote: mega-snip/ So I guess we just be little those who use template, ahaha.Your still template, that's so 2000' ;) -Daniel Is it Friday and I don't know it? ROFL - good one Daniel :-) I wouldn't try it unless Craig is off on a trip though ;-O -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Moving/deprecated of StrutsValidator StrutsValidatorUtilPropertyMessageResources.java
Robert Leland wrote: I wasn't suggesting that was the way it had be. Doing that would have *all* validator-related things living under o.a.s.v though. I really was agreeing with you, that it --could-- be beneficial. I didn't feel strongly one way or the other. It is possible that when Java Server Faces comes that having it in a different package, would encourage its reuse. Eddie spoke and it was so: LOL! You're killing me, Rob! Welcome to the club. Ok, Now I am through hazing you :-D ! Thank you - I feel the love ;-) I think I'm going on the -0 side though. I think I agree with Martin that moving it would would logically include having it live it it's own taglib - and that just isn't justified with only one tag. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Terminology: modules versus sub-apps
Aye +1 Ted Husted wrote: +1 for modules. If the documentation refers to sub-apps anyplace today, that would be a bug =:0) I did try using both, and sub-apps becomes clumsy. YES! I can identify! It is probably true that 1.1 is only supporting one possible implementation of modules, but that's something we can sort out later. (Sub modules versus nested modules, or whatever.) Right. 1.2 will do that. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Terminology: modules versus sub-apps
Craig R. McClanahan wrote: On Wed, 16 Oct 2002, Martin Cooper wrote: Date: Wed, 16 Oct 2002 18:22:42 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Terminology: modules versus sub-apps One other point I neglected to mention, which may actually make the question moot at this point: We use $M to denote the current module in forward URLs. If we choose the term sub-apps, we'd have to explain why we use $M as the abbreviation... This was done after Ted started committing docco changes that said module and nobody complained ... I'm OK with either, but somewhat prefer modules. Agreed. Plus (IMHO) sub-app implies a super-app (thinking OO here), so modules really is a lot more appropriate name for what they are - at least in 1.1. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Moving/deprecated of StrutsValidator StrutsValidatorUtil
Robert Leland wrote: It seems like StrutsValidatorUtil StrutsValidator really belong in o.a.s.validator so I propose to deprecated o.a.s.util.StrutsValidator o.a.s.util.StrutsValidatorUtil and copy them to o.a.s.validator.StrutsValidator o.a.s.validator.StrutsValidatorUtil +0 Only the o.a.s.t.html.JavascriptValidatorTag uses the StrutsValidatorUtil, other than the o.a.s.validator. classes We could move that too and update the TLD, couldn't we? ... if we're moving ... (maybe put it in o.a.s.v.t.html? It might get lonely there though ...) And o.a.s.util.StrutsValidator is not used anywhere except by the the validator.xml files. So before struts 1.1 final the util versions would be removed. Comments ? -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Exactly. Though, hopefully, we each will do some things not just because it's a need *we* have. It's only understandable we'd scratch our own itch first, but, provided we have time to implement additional things, I like to think we would do that too. (but remember - we have families we like to see too, and we don't get paid to do this!) Ted Husted wrote: 10/17/2002 2:28:38 PM, Eddie Bush [EMAIL PROTECTED] wrote: The sharing is the thing we're struggling with - more precisely the timing of implementing it. It has been suggested this would happen in 1.2, and I think that's acceptable. Whether and when something happens will always depend on whether someone *makes* it happen. As individuals, each of us can say that we plan to work on this or that in some timeframe, but I don't think anyone can foresee what feature will appear in what release until there is code on the table. We can slot the platform requirements for a given code tree (1.2.x vs 2.0.x), but what ends up being implemented will really depends on who has time to do what. The roadmap is a useful tool, but let's not start thinking of it like some type of requirements document. We all have enough of that at our real jobs. Here, we should be doing what we ~want~ to do, not simply what got put up on the whiteboard. -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
I think what we established for a roadmap yesterday seperated the 2.3 compliance conversion out into something past 1.2. There are a number of things that aren't going to meet everyone's approval wrt 1.1F. Those things, and only those things, as I understand it, would be in 1.2. We need to clean up before we make another mess :-) Craig mentioned lumping the 2.3 compliance conversion and JSF into one release - probably 2.0. Find his bucket post from yesterday :-) So far as servlet spec 2.4 is concerned, I have no clue. What platform will our users be on? We don't want to upgrade ourselves out of a user-base. Yes, many of us will be able to switch - but there will be many forced to stay on 2.3 spec containers too - just like a lot of folks are stuck on 2.2 spec containers now. I don't have awareness enough of what everyone's flexibility is like wrt switching containers to have input on this really though. I would very much like to see David's work incorporated as a first-class citizen. I can't say how handy I find that set of tools! Anyone that has used them understands - anyone who hasn't doesn't. So far as Validator/Tiles are concerned, they will be there in 1.1F, if I have any say about it (speaking with my code, as Ted suggested!). Validator, I believe, is there. If you experience problems with it's module-friendliness just yell. That's mine. I intend to have to fix anything I missed or messed up. I don't think there will be problems with it in that regard though ;-) My suggested order of operation would be: 1.1F - finish what we're doing 1.2 - clean-up wrt modules ... and after that - whatever. It's very important that we clean up our mess though. While I don't anticipate the code-base to change much in 1.2, I do expect to see a lot more functionality in it. Byrne, Steven wrote: What are people's feelings about supporting Servlet 2.2 in post 1.1? Is it time that we can say in 1.2 and beyond that servlet 2.3 is required? I was thinking about the roadmap, and realizing that while a Struts version that was JSF aware was probably a ways off, a version with JSTL incorporated into it (and here I'm thinking about Mr. Karr's work) as a first class citizen would not be as far off, and we may not want to hold up incorporating that technology waiting for JSF integration. That makes me think that it would be a good thing to say that in 1.2 Servlet 2.3 is required. Remember, 1.2 will be a few months out from now, so it doesn't seem that at that time 2.3/JSP 1.2 would be that bad of a thing to say is the lower end of what is supported? Comments? I'm going to write up a draft roadmap tomorrow and send it around for comments. If you want to provide input into it, please speak up now so I can incorporate your ideas. Right now I can think of two basic buckets: 1.2 Servlet 2.3 / JSP 1.2 based (assuming no objections JSTL tag library incorporated as a first class citizen Support for distributed struts components within a single application (either by just having a list of them or by using some assembling technology) 1.1 bugs fixes 2.0 Servlet 2.4 based (?) JSF integration This presumes that 1.1 has Tiles and Validator in place as first class citizens and working properly with sub applications. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Validator 1.0 Release and bug 10868
How about cringe/ an alternate DTD? James Turner wrote: At 07:31 PM 10/16/2002, Craig R. McClanahan wrote: One bug under Struts that should really be addressed in the base code is the question of specifying alternate resource bundles forms and fields (bug #10868). As I understand it, this will cause problems for Validator with sub-apps under Struts. Should I try to tackle it? Please do! Ok, but I can't think of a clean way to handle it. Here's the issue: The base Validator doesn't deal with resource bundles (or errors messages for that matter) at all. It's the validator Framework that does all that stuff. So putting bundle= support into the base Validator DTD for forms isn't very clean, since it required putting Struts-specific stuff into the Validator DTD (and adding a bundle property to the Field class) Any thoughts on how we can implement this in a way that keeps Validator Struts-neutral? James -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Steve :-) I appreciate your effort, but we're *not* going to 2.3 / 1.2 in Struts 1.2! 1.2 is for clean-up only - to solidify modules. One of the goals of 1.2 is still *backward-compatability* with 1.0! We cannot move to 2.3 / 1.2 and maintain this! Byrne, Steven wrote: I was given to understand that Struts-el needed Servlet 2.3, and so that's why I suggested having it in 1.2. But my main purpose was to create a common definition of what was going to be in each release (and have it track as things change), so it should reflect the shared belief of the developers. David Karr -- care to chime in on whether Struts-el needs Servlet 2.3/JSP 1.2? Steve -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Yeah - what he said ;-) Ted Husted wrote: I like Craig's idea of slotting 2.3/1.2 for 2.0.x for now. Let's do some actually work on 1.2.x before committing to a requirements change. If we start to feel hamstrung, we can decide that based on a specific need (keep it agile). -Ted. 10/16/2002 8:06:58 PM, Byrne, Steven [EMAIL PROTECTED] wrote: What are people's feelings about supporting Servlet 2.2 in post 1.1? Is it time that we can say in 1.2 and beyond that servlet 2.3 is required? -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Cedric, I wasn't trying to step on toes :-) I can't say how much more I'd prefer you refactor Tiles than me. You (obviously) are a *lot* more familiar with it's inner workings! The point to keep in mind though is that 1.1 *is* about seperatism. Would it, in your opinion, require undoing changes made in 1.1 to enforce seperatism to acheive a better affect in 1.2? I like your intent, I believe, very much. 1.2 is really the target for making modules work together though - that should be it's primary focus. If you're working on resolving this I'll just bow out and let you have it :-) Please let me know. I'm still reviewing the code to make absolutely sure I know what I'm doing before I go to changing anything, and I'd hate to be throwing wasted time into the effort - especially when a much more competent person is at hand. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Looks good. Ted Husted wrote: I posted a starter version of the roadmap so we'd have something to patch :0) http://jakarta.apache.org/struts/status.html -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: template status
David Graham wrote: Thanks for the info Martin. I wanted to make sure I was pointing people in the right direction. This came up on the user list today and I recommended using Tiles. I agree with deprecating the template library, that's part of the reason I asked :-). It's confusing when there are 2 libraries that do the same basic thing. ... especially when one is a super-set of the other. How do you deprecate a taglib? -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Peter A. J. Pilgrim wrote: As a core contributor for Expresso Framework I find this discussion interesting. In Expresso one of the contributors put together a XML Augmentator that parse several XML configuration files. We integrated Struts 1.0.2 so we do not have a special notation of sub applications, but just the one struts-config file, but we can have several *expresso-struts-config* files. If the expresso-strut config implement the same XML DTD then in theory they can merged together internally in a giant DOM. This is what I think the contribotor ( Mike Rimov, I think) did for Expresso. I am not sure how it solves the modules problem though in pure Struts. I have a little difficult understanding the terminology here. Is a module the same as a subapplication? Yes. I am not sure who started that nomenclature, but I find it more intuative. Plus - sub-apps implies there is a super-app ;-) and there isn't. I can see a might have a little bit work ahead of me, when I start trying to integrate Struts 1.1 with the latest Expresso if I do not under all the sub application issues. For Expresso it will make sense to subapplications to know about the default application (which is in our case Expresso). A sub application should be able to find out about sub applications also loading into the system. But hey may be I am way of base here. TRYING TO KEEP TEXT SHORT, TOO MUCH STRAIN ON MY EYES. You may wait to see what's in 1.2 before you try to incorporate a newer release. I can't say exactly what it will look like, but modules are anticipated to be somewhat more knowledgable about one another in that release. 1.1 is, as Ted noted Wall of China seperatism. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
I don't think anyone is trying to say that Struts isn't useful without Tiles/Validator. They *are* very handy though, IMHO! I'm not sure what our leadership has in mind for deprecating/removing Tiles/Validator in later releases. Right now, the task at hand is 1.1F. As Ted mentioned, ... the die is cast We just need to execute and deliver. Joe Germuska wrote: At 2:26 PM -0600 2002/10/16, David Graham wrote: To me, validator and tiles are part of the core. Without them, struts loses much of its utility and importance. I think that's a bit extreme. Action classes are part of the core; RequestProcessor is part of the core. I've built several Struts apps and barely touched either Tiles or Validator, and haven't missed them. Furthermore, Validator will be mostly obsoleted by Java Server Faces. If committers think it's best to keep them in the core distribution, I'm not going to make a fuss about it. But I think it's selling Struts very short to suggest that it's not very useful or important if you aren't using Validator or Tiles. And if decoupling useful components from a core distribution helps maintain focus and cut a 1.1 release, I would think there's something to be said for that. Joe -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Moving/deprecated of StrutsValidator StrutsValidatorUtilPropertyMessageResources.java
I wasn't suggesting that was the way it had be. I was just saying that, if we're moving things to live together, there are other things we might consider moving too :-) Doing that would have *all* validator-related things living under o.a.s.v though. Robert Leland wrote: Robert Leland wrote: Eddie spoke and it was so: LOL! You're killing me, Rob! Only the o.a.s.t.html.JavascriptValidatorTag uses the StrutsValidatorUtil, other than the o.a.s.validator. classes We could move that too and update the TLD, couldn't we? ... if we're moving ... (maybe put it in o.a.s.v.t.html? It might get lonely there though ...) True there is no rule that says all the taglibs classes need be in the same directory. +0 -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
Actually, looking back at that, I think I disagree with postponing Tiles' update to 1.2. I love the idea of having a roadmap up though ;-) Ted Husted wrote: I posted a starter version of the roadmap so we'd have something to patch :0) http://jakarta.apache.org/struts/status.html -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Ted Husted wrote: snip/ But for now, if + each module could use its own attribute to store it Definitions, and + we can still specify a list of configuations for each module, and + we can specify contextRelative=True where appropriate (on an element-by-element basis) I think we would be good =:0 I think that's probably the best solution we have for 1.1. -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Hi again, Cedric :-) Cedric Dumoulin wrote: Hi Eddie, Eddie Bush wrote: Cedric, I wasn't trying to step on toes :-) I can't say how much more I'd prefer you refactor Tiles than me. You (obviously) are a *lot* more familiar with it's inner workings! The point to keep in mind though is that 1.1 *is* about seperatism. If you have a strong separation between modules with Tiles, you go against the Tiles philosophy (share to reuse, to reduce maintenance, ...). If you do strong separation, you will be consistent with the module philosophy, but you will be inconsistent with the Tiles one. So, peoples using Tiles will not use modules because they will loose one of its main advantage. So, we need a way to conciliate both philosophy. My idea was to have one Tiles factory per module, and to have a syntax allowing cross references between module namespaces (for URL). Also, a same tiles config file could be used by several factories, allowing some commons basic definitions. This later requirement bring some problems: the shared config file namespace is not the same depending on the loading module. In this case, how to specify URLs in a way consistent to module philosophy ? Should we mark all as contextRelative=false ? If yes, what will happen if the module name change ? This is such little things that need to be solved in order to propose a consistent behavior. After that, it will be more easy to implement something ! You and I are in the same camp on this, but I don't think now is the time for significant change. We need to hurry 1.1, and the only way I see to do that is for each of us to agree to seperatism in 1.1 - understanding and *expecting* that 1.2 will be our chance to solve the problems we wanted to solve in 1.1 but couldn't (because of time). Would it, in your opinion, require undoing changes made in 1.1 to enforce seperatism to achieve a better affect in 1.2? I like your intent, I believe, very much. 1.2 is really the target for making modules work together though - that should be it's primary focus. The Tiles goal of sharing common pages should be maintained in 1.1. The module goal is to let separate teams work independently on different modules. In this context, Tiles should combine both goals. See Ted's note about specifying global definitions. I think that may suffice. I *know* :-) it's not something you (or I) will find ideal, but can we please overlook that for 1.1 and focus on utopia in 1.2? There's a lot of folks that would love to use 1.1 right now, and can't simply because it has a beta in it's name. Those people who *are* using modules would not be affected by us at all from what I can tell - they simply cannot use tiles at this point :-( not in non-default modules! (I resorted to using definitions defined in JSP - that *does* work. It's a compromise I'd like to get away from as quickly as possible though). So, can we *please* aim for seperatism in 1.1 and then focus purely on how sharing should be done in 1.2? If you're working on resolving this I'll just bow out and let you have it :-) Please let me know. I'm still reviewing the code to make absolutely sure I know what I'm doing before I go to changing anything, and I'd hate to be throwing wasted time into the effort - especially when a much more competent person is at hand. Your help is welcome. Also, someone else than me with a very well understanding of the Tiles philosophy and its current implementation is more than welcome. But, please, don't forget to expose your intention to other commiters before making heavy changes. The best is to describe your goals, your expected behavior, and maybe a simple example of use. Only after that you can propose an implementation. Thanks for the guidebook :-) I don't think I've heard anything stated so clearly about how to proceed - that certainly does make a lot of sense to me though. Cedric -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Ted Husted wrote: 10/18/2002 9:19:26 AM, Eddie Bush [EMAIL PROTECTED] wrote: You and I are in the same camp on this, but I don't think now is the time for significant change. We need to hurry 1.1, and the only way I see to do that is for each of us to agree to seperatism in 1.1 - understanding and *expecting* that 1.2 will be our chance to solve the problems we wanted to solve in 1.1 but couldn't (because of time). Could we please speak in terms of Sruts 1.2.x ? Sorry - yes. That's actually what I meant, but I do see where it's not clear. If we implement some other useful things, and this new module implementation isn't ready, I don't want statements like this to come backs as a veto on a 1.2.0 release. Please, no more gotta have its targeted for a specific release. If a feature is ready, it's ready, if not, it can wait for the next iteration. (We just need more iterations :0) We do need to be agile in terms of the remaining tasks for 1.1.0. But I'm concerned that there be any implication that we are ready to sacrifice quality for expediency. Agreed. What is in 1.1.0 should be solid. That's not to say it will be as feature-full as we would like (wrt sharing). We all agree that there are other approaches to modules, but we need to finish this one before we consider the others. I don't believe that's hurrying, it's simply coding and releasing one use-case at a time. Right. -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Going to other context and/or server in 1.1
Is there some way I'm unaware of by which Struts will forward/redirect a user to another site? When modules came along, we were then faced with either being relative to the module or the application. I don't know if causing an inability to forward/redirect to another site was a conscious decison, or a mere oversight. I can't see a way to accomplish this behavior though. Am I missing something obvious? RequestProcessor seems to send everything through the moudleRelativeRedirect or moduleRelativeForward. Should we have a way to say go to a different context/machine? -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Going to other context and/or server in 1.1
Naw, that's just another person saying they have the same problem, I think. I didn't see a patch in the attachment - but the question remains if this is something we want to allow. Personally, I think we should. If so, I'll see about getting it fixed-up. That is the bug I was looking at though, yes. There have been others wanting this ability too. One thought that comes to mind is to check the path specified to see if it starts out http://...; - and just treat that differently. That would be easy enough for users to do, and I don't think it would require too significant of a change to implement. This is one time I think startsWith criteria would suffice ;-) but I'm open to suggestions. David Graham wrote: Are you referring to this bug? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13721 Looks like someone has submitted a patch. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 12861] - URL address changed when I usepath-mapping on servlet
Yep - good point. I think the question still remains how the URL is changing though. That would have to be caused by a redirect. His original URL indicates in no way that the controller should be involved. Struts certainly isn't doing a redirect unless he's telling it to. [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12861 URL address changed when I use path-mapping on servlet --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 15:27 --- See section 4.7.2: http://jakarta.apache.org/struts/userGuide/building_controller.html#action_servlet -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Going to other context and/or server in 1.1
David Graham wrote: I thought of the http:// matching as well. Are there any cases when this logic wouldn't work? Hardcoding the protocol may be a bad idea. I don't like that idea either, but I can't think of a better approach. As I said, I'm open to suggestions :-) You could look for /word.word.word/, but I think that would be ... just as bad and a lot nastier to implement. Very problematic, I would think. Looking for http: seems the best solution that I can think of. David -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Going to other context and/or server in 1.1
Well, we could implement a static array of protocols somewhere - and iterate over them to see if there's a match (like was being done with module prefixes before). Then, adding support for another protocol would just be a matter of editing that one array. Should this go in Globals? You've got a good point, Cliff. Cliff Rowley wrote: I would have thought the same would apply for any specified protocol scheme. For example someone may wish to redirect to an ftp:// through the action forward, or maybe news:// - who knows. Without a protocol specification of any description it's probably safe to assume we want context relative. Having said that, I don't know enough to spot any possible caveats. -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: 18 October 2002 16:29 To: [EMAIL PROTECTED] Subject: Re: Going to other context and/or server in 1.1 I thought of the http:// matching as well. Are there any cases when this logic wouldn't work? Hardcoding the protocol may be a bad idea. David -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
