RE: [shale] Rolodex example
I was able to use Shale with Weblogic 8.1 which is certified on J2EE 1.3. (Servlet 2.3/JSP 1.2) I think relying on Java 1.4 is fine because all the major vendors support it in their current versions but BEA still hasn't released a J2EE 1.4 compliant server so it would be nice if Shale could avoid any J2EE 1.4 dependencies if possible, at least until upgrading to Weblogic 9 is an option. Normally I have little sympathy for people not being able to use the latest and greatest frameworks if they haven't kept their servers up to date but in this case shale should attempt to target the same specs that JSF targets and for now that is Servlet 2.3. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, July 07, 2005 1:57 PM To: Struts Developers List Subject: Re: [shale] Rolodex example From: [EMAIL PROTECTED] I created a bugzilla ticket yesterday with this patch included: http://issues.apache.org/bugzilla/show_bug.cgi?id=35639 Sorry! I got as far as making sure the issue was still present in the source code, but didn't check Bugzilla. [The 'Known Issues' link on the Struts home page still points at Jakarta's bug page, and I went off looking for that, then decided it was much too late and gave up for the night.] It was probably not there. It might have been early this morning... Can someone comment on minimum requirements for Shale? I thought JSF was minimum Servlet 2.3/JSP 1.2, but I didn't have any luck with the struts-shale-usecases.war on Tomcat 4.1.31 last night. So maybe not. Digester complains (among other things) that 'Document Invalid: no grammar found'. I was able to get the usecase example to run under Tomcat 4.1 but I had to swap out the stardard.jar with the JSTL 1.0 version. I also had to change the start of the web deployment descriptor and reorder the env- entry. ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app ... env-entry env-entry-nameenv/String/env-entry-name env-entry-valueString Value/env-entry-value env-entry-typejava.lang.String/env-entry-type /env-entry env-entry env-entry-nameenv/Integer/env-entry-name env-entry-value10/env-entry-value env-entry-typejava.lang.Integer/env-entry-type /env-entry I only hit a couple pages so all the features might not be supported. Gary Thanks, -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Tiles] Subproject Questions
Would it make sense to rename the current struts/tiles directory struts/struts-tiles and it would eventually serve as the glue between struts/core and struts/tiles? For the time being it would have a copy of tiles but eventually struts would use the stand-alone tiles jar. The struts-tiles bridge code could also move back into core since supporting tiles could be considered a core feature of struts at this point, the same way supporting validator is core. -Original Message- From: David Geary [mailto:[EMAIL PROTECTED] Sent: Thursday, May 26, 2005 4:59 PM To: Struts Developers List Subject: [Tiles] Subproject Questions Ted Husted has convinced me that Tiles should, afterall, be a Struts subproject. But I have a couple of questions. First, should I put this in a directory called struts/tiles? There's already a Struts top- level directory named tiles, so reusing that name might cause confusion. Should I name it tiles-standalone, or something like that? Second, I'm not sure about packages. Right now, I've got org.apache.tiles instead of the original org.apache.struts.tiles, but of course, that will break existing code. OTOH, if I switch back to the original package names, then we run the risk of clashing with the Struts packages. Thoughts? david - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [shale] Tiles + Shale
Yes he is the original author of Tiles. There has been much talk of pulling Tiles out of Struts but I'm more interested in the putting it into Shale part. Dave was the original author of the now removed template tag library. The Components library, later re-named Tiles was written by Cedric Dumoulin and was backwards compatible with Dave's template tag library but I don't believe it shared any code from Dave's template implementation. I could be mistaken but that was always my understanding. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant or Maven (Pick one please)
I have seen few if any Ant-based projects which didn't require at least a bit of tweaking to a local build.properties file; on the other hand, most Maven projects just work if you have Maven installed. I was presently surprised yesterday to checkout the head of XDoclet and just run the ant build (all from within Eclipse) and it built the whole XDoclet distribution including all the various sub modules. I imagine they used a combination of checking in dependencies or downloading them but it was a very pleasant ant build experience. With either ant or maven a clean checkout should build without any property files being tweaked. The property files should exist for developers that want to override some default like using a different version of some jar file or sending the build output somewhere else. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: access?
I think Krupa was confusing viewcvs.cgi errors with a lack of access.
The Apache ViewCVS interface (which works with Subversion) is not
working right now but it's not working for everybody.
http://svn.apache.org/viewcvs?view=revrev=125442
The Apache Software Foundation ViewCVS Subversion interface is
currently down while we investigate a problem with ViewCVS.
Sorry for any inconvenience.
Thanks,
The Apache Software Foundation
-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 18, 2005 11:06 AM
To: Struts Developers List
Subject: Re: access?
On Tue, 18 Jan 2005 11:23:37 +, Krupa Vyaghra [EMAIL PROTECTED]
wrote:
Dear Craig,
Is it possible for a non contributer to have access to the CVS? I am
a
silent participent of this list for my keen interest in Struts and
its
future direction. For all the links that I get, I cannot see the
contents.
I avoided posting this message and wrote this mail because I didn't
want to flood many inboxes with a question that does not need
attention
of all people.
Everyone can have *anonymous* access to the source code (i.e. you can
check it out, but you cannot commit anything unless you are a
committer). However, to get access to the Struts sources, you'll need
to use a Subversion (SVN) client (http://subversion.tigris.org), since
we recently moved from CVS to SVN. The command to check out all the
current source is something like this (if you use the command line
client):
mkdir struts
cd struts
svn co http://svn.apache.org/repos/asf/struts/current
There are also nightly packages of the source code:
http://struts.apache.org/builds/struts/nigthly/src/
The ZIP or TAR.GZ files found there are snapshots of checking out the
current repository as described above.
Craig
Any response will be appreciated. Apologies for any inconveniences.
Regards,
Krupa.
On 17 Jan 2005, at 20:33, [EMAIL PROTECTED] wrote:
Author: craigmcc
Date: Mon Jan 17 12:33:38 2005
New Revision: 125442
URL: http://svn.apache.org/viewcvs?view=revrev=125442
Log:
Clean up build process to work with the MyFaces 1.0.8 milestone
release,
which will work if you put the following in your
build.properties
file:
jsf.home=/usr/local/myfaces-1.0.8 -- Or wherever you
installed
it
jsf-api.jar=${jsf.home}/lib/myfaces-jsf-api.jar
jsf-impl.jar=${jsf.home}/lib/myfaces-impl.jar
Also, add forgotten immediate properties on the cancel buttons in
the
logon dialog.
Modified:
struts/sandbox/trunk/struts-shale-usecases/build.xml
struts/sandbox/trunk/struts-shale-usecases/src/web/WEB-INF/web.xml
struts/sandbox/trunk/struts-shale-usecases/src/web/logon/profile1.jsp
struts/sandbox/trunk/struts-shale-usecases/src/web/logon/profile2.jsp
struts/sandbox/trunk/struts-shale-usecases/src/web/logon/profile3.jsp
Modified: struts/sandbox/trunk/struts-shale-usecases/build.xml
Url:
http://svn.apache.org/viewcvs/struts/sandbox/trunk/struts-shale-
usecases/build.xml?view=diffrev=125442p1=struts/sandbox/trunk/
struts-shale-usecases/build.xmlr1=125441p2=struts/sandbox/trunk/
struts-shale-usecases/build.xmlr2=125442
===
===
--- struts/sandbox/trunk/struts-shale-usecases/build.xml
(original)
+++ struts/sandbox/trunk/struts-shale-usecases/build.xml Mon
Jan
17
12:33:38 2005
@@ -67,7 +67,7 @@
classname=com.sun.faces.RIConstants
classpath=${jsf-impl.jar}/
available property=myfaces.present
-
classname=net.sourceforge.myfaces.config.MyfacesConfig
+
classname=org.apache.myfaces.config.MyfacesConfig
classpath=${jsf-impl.jar}/
!-- Build Defaults --
@@ -138,7 +138,6 @@
echo message=commons-chain.jar =${commons-chain.jar}/
echo message=jsf-api.jar = ${jsf-api.jar}/
echo message=jsf-impl.jar = ${jsf-impl.jar}/
-echo message=mailreader.jar = ${mailreader.jar}/
echo message=shale.jar =${shale.jar}/
echo message=jsfri.present =${jsfri.present}/
echo message=myfaces.present= ${myfaces.present}/
@@ -228,11 +227,19 @@
target name=libraries.myfaces depends=libraries
if=myfaces.present
-!-- Copy additional libraries required by MyFaces
implementation
--
+!-- Copy additional libraries required by MyFaces (version
1.0.8) --
copy
todir=${build.home}/${context.path}/WEB-INF/lib
file=${jsf.home}/lib/commons-codec-1.2.jar/
copy
todir=${build.home}/${context.path}/WEB-INF/lib
file=${jsf.home}/lib/commons-el.jar/
+copy
todir=${build.home}/${context.path}/WEB-INF/lib
+
RE: RoadMap [was Re: ViewUtils ... ]
Webstart has been around for awhile and it has its place but it's not going to make web applications go away any time soon. If JNDC and SandraSF do for Swing what Struts did for web applications, that will be good for Swing app developers but it has little to do with writing web applications. If you want a rich client, Swing via Webstart is one way to do that. Struts solved problems with Servlet/JSP specifications, but it built on their foundation. Now that the JSF standard has come along which has learned from the myriad of web application frameworks in existence, I think it would be in line with the Struts legacy to build around that standard and add value. I think the cycle of standard - open source innovation - standard - open source innovation - etc is a good one. We, in java land, are sort of at the point in the cycle where open source has several innovations that aren't yet standardized, but that doesn't mean that standards don't have value for all the usual reasons: Developer skill investment portability, application portability across vendor and time, IDE vendors return on investment for support standards, employers being able to draw on pool of skilled developers, etc. I haven't had a chance to use JSF for a client but I look forward to making the investment in learning it and I hope that the Struts community embraces it for 2.0. Based on the IBM JSF based framework and Springs ability to plug-in their managed bean factory, it seems like JSF is a very extensible framework that you can build web applications around, including next generation web applications, once the right JSF components are available. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vic Sent: Wednesday, December 29, 2004 2:09 PM To: dev@struts.apache.org Subject: Re: RoadMap [was Re: ViewUtils ... ] Craig McClanahan wrote: I believe that Struts will become gradually less relevant for new application development unless it adopts JSF strongly; :-). I don't think so. and it would be a shame to have to *compete* with Struts instead of *being* Struts. Why not have JSF compete with HTML tag libs? Like Velcotiy does, etc. No need to have a view Religion locked in MVC implementation - the C part. If so, then lets all agree on one true DAO 1st, that is more mature EJB? iBatis? Which JDO? Hibreante? Spring JDBC? Roll your own JDBC? ... which is the official one? Best thing about Java is choice. I think Caraig said way back over my dead body will there be a lock on a one DAO, or words to that effect. I will agree that the view has been done in '04. If anyone has doubt as to what view will win out in '05, take a look at my sample at http://www.boardVU.com (in IE only for now - click on IE link. Also SandraSF.com has javadocs. It's a chain based dispatcher that I will port to Struts chain after chain becomes a bit more stable.). I see the light, it's a diferent light. By next X-mass, JDNC will be a very polular view tech in production, ahead of JSF and Tapestry. If I was to limit myself to DHTML tech only... then clearly PHP is best, look at all the PHP apps. Java is most competetive w/ JDNC. That is my religion, the one true one, so all pray to my god! ;-) No mater how much skill and effort is put in JSF, it will not get production market share, it will only move people to .NET ASP, thats all. I do not think people should be disallowed to do JSF as view in Struts, choice is good. If JSF makes improves... GREAT!!! I hope Struts contines to be View agnostic and that it even have some SoA dispatch support in version 2 and 3. .V Craig -- RiA-SoA w/JDNC http://www.SandraSF.com forums - help develop a community My blog http://www.sandrasf.com/adminBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Porting changes to the 1.2.x branch
Would you use svn merge on the directories you changed? http://copenhagen.pm.org/presentations/subversion/subversion.htm See slide Tags and branches or http://deadbeast.net/~branden/svn_pres/merging_and_resolving.html or http://svnbook.red-bean.com/en/1.0/re16.html -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 28, 2004 6:34 PM To: Struts Developers List Subject: Re: Porting changes to the 1.2.x branch Martin Cooper wrote: I just made a giant commit to the EL taglibs to bring them into alignment with the non-EL tags. Now these changes need to be ported to the 1.2.x branch, since the omission of these changes was, in part, the reason for classifying 1.2.6 as Beta rather than GA, and we'll want to get to another GA release on that branch at some point, probably sooner rather than later. So now that we're in SVN-land, what is the simplest way of taking the changes in one commit and applying them to another branch? Dunno, perhaps you could get a diff between the two versions then apply the patch to the other branch. Don -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Porting changes to the 1.2.x branch
You could do this, without the --dry-run option and with the appropriate committer urls. svn checkout http://svn.apache.org/repos/asf/struts/el/branches/STRUTS_1_2_BRANCH/ struts-el cd struts-el svn merge -r106044:123473 --dry-run http://svn.apache.org/repos/asf/struts/el/trunk svn diff svn commit -Original Message- From: Deadman, Hal [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 28, 2004 6:49 PM To: Struts Developers List Subject: RE: Porting changes to the 1.2.x branch Would you use svn merge on the directories you changed? http://copenhagen.pm.org/presentations/subversion/subversion.htm See slide Tags and branches or http://deadbeast.net/~branden/svn_pres/merging_and_resolving.html or http://svnbook.red-bean.com/en/1.0/re16.html -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 28, 2004 6:34 PM To: Struts Developers List Subject: Re: Porting changes to the 1.2.x branch Martin Cooper wrote: I just made a giant commit to the EL taglibs to bring them into alignment with the non-EL tags. Now these changes need to be ported to the 1.2.x branch, since the omission of these changes was, in part, the reason for classifying 1.2.6 as Beta rather than GA, and we'll want to get to another GA release on that branch at some point, probably sooner rather than later. So now that we're in SVN-land, what is the simplest way of taking the changes in one commit and applying them to another branch? Dunno, perhaps you could get a diff between the two versions then apply the patch to the other branch. Don -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Extracting taglibs
Haven't look into this much but it would seem better to have a completely separate tiles sub-project that struts core would use. Don't JSF and Spring currently use tiles and have to include struts.jar when all they really want is tiles? -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 21, 2004 7:51 PM To: Struts Developers List Subject: Extracting taglibs My basic assumption in approaching taglibs extraction into its own subproject is it can reference Struts classes, but Struts classes shouldn't reference it. If that is correct, here are the changes I see happening to extract taglibs: 1. Move o.a.s.taglib out into its own subproject src tree 2. Remove methods in RequestUtils that delegate to TagUtils. They are marked as deprecated anyways and explicitly say they will be removed after 1.2. 3. Move properties in o.a.s.taglib.html.Constants that are referred to in Struts core code into o.a.s.Globals. (cancel and token keys) 4. Move o.a.s.taglib.tiles to o.a.s.tiles.taglib This one I'm not sure about. Should/can tiles be used w/o its jsp taglibs? If not, then it should stay in core w/ tiles. Otherwise, it could be moved out too. That should be it, as far as I can tell. taglibs are already pretty well isolated from the rest of Struts which will make the extraction pretty straightforward. I'd like to get this done before Christmas (25th) if there are no objections. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts + Chain enhancement idea
By the way, for the benefit of our developer community, i just read an article Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate http://www.sys-con.com/story/?storyid=46977DE=1 that demonstrates the readiness of involved technologies. I like to add 2 things to what the article has revealed: 1) Jsf and tiles are fuly integrated under myfaces. You do not need 2 jsp pages for every view (a wrapper page and a real fragment). Just 1 fragment jsp that makes a new page and 1 tiles definition. For those who used Struts-1.x + Tiles to create a portal page (e.g. our current portal and LifeRay), you may choose to forget about the portlet layout to gain maximum flexibility for the portlet view i.e. perfectly fit for a complete jsf dynamic fragment + total flexibility to scrap an html fragment over the Internet + mixing of [Jsf + Jsp + Jstl] in the portlet fragment. (I had this issue and asked the Jsf forum. I took me 4 days to have it worked out and answered myself for the question) Does struts-faces provide a way for the JSF reference implementation to work with tiles and not require two jsps per view? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Package removal with new Digester
Are you using Eclipse? If so you can set Eclipse up to ignore a certain pattern (that package) in a particular source directory. It would be nice if the dependent jars and .project and .classpath files were checked into SVN the way spring does it. Then someone could import team project set and have all the various sub-projects automatically checked out and setup as projects in Eclipse. -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Thursday, December 02, 2004 2:25 PM To: Struts Developers List Subject: Re: Package removal with new Digester That change was made at the end of October. So now what? Instead of ignoring those classes, shouldn't we fix the problem? Like include the examples from digester or remove our files that refer to the no longer existing package and classes? I am *not* looking for a vi vs. ide debate, but this is simply aggravating. Frankly, I'm tired of cutting off the end of the ham ;) -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; Martin Cooper [EMAIL PROTECTED] Sent: Thursday, December 02, 2004 1:52 PM Subject: Re: Package removal with new Digester Wow, I was missing something. I just noticed this in build-webapp.xml: ... ... !-- Excludes for tiles-documentation to reflect the fact that Commons Digester 1.6 no longer ships the RSS demo classes -- exclude name=org/apache/struts/webapp/tiles/rssChannel/*.java/ ... ... -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, December 02, 2004 1:14 PM Subject: Re: Package removal with new Digester Hmm, that's odd. How are you trying to build? I can run 'ant clean dist' just fine with Digester 1.6, and that builds tiles-documentation.war. -- Martin Cooper On Thu, 2 Dec 2004 09:54:36 -0500, James Mitchell [EMAIL PROTECTED] wrote: I can't compile the tiles-documentation sources with Digester 1.6, it requires the rss package that was moved to src/examples/api/rss according to the release notes. Did I miss something? How are we dealing with this? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] SVN / Eclipse / Subclipse error
Subclipse just released an updated version today. http://subclipse.tigris.org/0.9.23/changelog.html (Note the Feature Change - IMPORTANT paragraph is not true, that change didn't make the release) I am subscribed to their dev list to keep tabs on the progress. They are still working on it and a new committer just joined that has been contributing a good deal. Synchronization is still not working but Subclipse definitely works although it's not yet up to the high standards of Eclipse CVS. -Original Message- From: Michael Rasmussen [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 1:53 PM To: Struts Developers List Subject: Re: [OT] SVN / Eclipse / Subclipse error I tried subclipse over the weekend, and I would have to agree. I am really dissapointed so far. I am well versed with the Eclipse CVS stuff, but Subclipse was a nightmare. It hosed my repository and It may have been the cause of my hosed eclipse install. I don't know what version of Subversion Apache is using, but if it is anything besides 1.1rc2 subclipse is not tested with it. All in all, I decided it is too early for subclipse, which is dissapointing, because I am not sure tigris sis still supporting/developing it. If you do get it working, please let me know. I want to post some instructions for using it with Struts. On Tue, 30 Nov 2004 08:55:15 -0600, Matt Bathje [EMAIL PROTECTED] wrote: James Mitchell wrote: Sorry for the OT, but I figured some folks here are doing this. I'm trying out Subclipse and getting this error: http://cvs.apache.org/~jmitchell/server-cert-invalid.jpg How are you getting around this? Command line works fine for me, but I would really like to use Eclipse. James - maybe this will be of some help, I have it bookmarked from when I first started using Subclipse... http://archives.real-time.com/pipermail/cocoon-devel/2004- May/033497.html (I don't remember what exactly I had to do at the command line though...) Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Wiki Etiquette: Niall's Help
Some of your word choices, if not personal attacks, would definitely qualify as inflammatory considering the importance of the subject matter. As an example of unnecessarily inflammatory language: I appreciate all you have done and I appreciate the ImageButtonBean solution too, although I am certain it is outmoded and vastly inferior. Outmoded and vastly inferior? Are we are talking about the problem of multiple buttons on a form? I have worked on several Struts based web-apps over the last few years and when I encounter this situation I think I just write an if statement. I suppose that technique is vastly inferior and should be jettisoned? Part of me enjoys your postings because they are over the top hostile. They are basically the antithesis of the consistently excellent postings by Struts committers like Craig, Ted and Martin who are all remarkably patient and professional, while still being forceful and persuasive. Some of my favorite lines from this last posting: Your [ideas] are, simply put, the ones I jettisoned some time ago, Your grasp of this particular area on Struts seems to me to be suspect and you seem to have no sense of the look and feel of this wiki page. Your efforts just muddy it up in sense and look. -Original Message- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: Friday, September 24, 2004 12:05 PM To: Struts Developers List Subject: Re: Struts Wiki Etiquette: Niall's Help The only reference to you, Niall, so far as I remember, was to credit your work as yours. I did not want my name associated with those thoughts. I have credited others on the page. I did not laud you, because you are trying to include ideas I am explicitly trying to critique and to surpass. I don't see any personal attacks on you, nor do I feel antagonistic in any way towards you. I am not going to get into the personal attacks thing more than I have. I would like to be able to present some ideas coherently. Your grasp of this particular area on Struts seems to me to be suspect and you seem to have no sense of the look and feel of this wiki page. I am very interested in a debate of any kind on these things. But, you and I will have to separate our ideas on this. Yours are, simply put, the ones I jettisoned some time ago, so they hardly will fit in the center of any presentation of what I am thinking. Why not put up your own page on those solutions instead of trying to inject them into a page that explicitly is rejecting them? I simply am trying to keep this space clean as it is a very complex page. Your efforts just muddy it up in sense and look. We have a different approach on this and are not likely to see things the same. That is of no concern to me. But, cleaning up this wiki after you on a constant basis is too much for me. The wiki is certainly for collaborative efforts, but not all on one page? I also must state that it is clear that we have no collaboration on this point. You adapt the ImageButtonBean approach and I used and rejected that. I am presenting a series of new approaches. You continue to put the old approach right in the middle of the wiki. That is not collaboration. We are not going to collaborate here. We disagree, apparently. That is okay. Part of the wiki is presenting alternative ideas, I would think. Why won't you let me do that in peace? Is there no place to present alternative solutions to what you like, without you putting in what you like in those places? That is the difficulty. I appreciate all you have done and I appreciate the ImageButtonBean solution too, although I am certain it is outmoded and vastly inferior. Like I said, I have no animosity towards you. All I am is upset at having to clean up the messes. Hopefully this will be a new day. I don't want to get too huffed up about your changes, or the wiki will be nuked. Michael McGrady Niall Pemberton wrote: OK Contact me off list if you wish, however I respected what you requested in the FiveMultipleButtonsSolution wiki page and all I did was add two links which were related to the subject - I added no opinions, just the links which is what you suggested people should do. You then added opinions on that page (seems to me you should have put them on the comments page you set up and asked others to use?) and you also put references to me all over the page. I was not happy with you making reference to me so last night I went through removing all those references. If you hadn't put my name all over that page then the only thing I would have changed was adding the two links to alternatives. The whole idea of a wiki is a collaborative effort - but you seem to want your own personal space which no-one else should touch, maybe if thats the case then you should go put it on your own blog and just provide a link to it directly from the wiki. If you do, please though, don't include any reference to me - just tell people what your
RE: On Martin Cooper's DownloadAction...
You won't need to make all the action mappings have to be the same type. You can use the action className= attribute to change the type of one particular action mapping. (I think, haven't done it myself) action className The fully qualified Java class name of the ActionMapping subclass to use for this action mapping object. Defaults to the type specified by the enclosing action-mappings element or to org.apache.struts.action.ActionMapping if not specified. [org.apache.struts.action.ActionMapping] -Original Message- From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 3:40 PM To: Struts Developers List Subject: Re: On Martin Cooper's DownloadAction... You guys are frankly delving into some things I haven't been exposed to before... I'm doing some reading right now and I THINK I get what your saying... (1) Extend ActionMapping and have accessors and mutators for all the extra attributes needed (whatever they may actually be, still open for debate) (2) In Struts-config, I would have someting like this: action-mappings type=org.apache.struts.action.StandardStreamDownloadMapping action path=/test type=org.apache.struts.action.StandardSreamDownloaderAction set-property property=streamInfoType value=org.apcahe.struts.DatabaseStreamInfo set-property property=dbTable value=whatever1 / set-property property=dbField value=whatever1 / set-property property=dbQuery value=whatever1 / /action /acton-mappings (Any other Actions aside from the download types should still work, but it would be nice if you could define some Actions as using this Mapping and others using the usual Mapping... action-mappings is a single element max. though, right? I suppose I could just go look at the DTD... I'm so lazy :) ) (3) Implement Martin's class such that it instantiates the StreamInfo named in the mapping, nothing needs to actually change in his code then, just need to implement the getStreamInfo() method as his comments indicate. Did I get that right? As I said, there's a couple of new concepts in here for me (like I didn't know you could specify a different Mapping class, and I don't think I knew about the set-property elements either), so did I get close? Assuming so, this makes sense to me, and I'd be happy to go off and write the implementations if everyone agrees it's the right approach. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, September 21, 2004 3:19 pm, Niall Pemberton said: +1 We have have graph generating actions using JFreeChart and pdf generating actions using iText and none of them use any of the attributes that your blob action has - so leaving that abstract is a good idea IMO. Niall - Original Message - From: Deadman, Hal [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 8:05 PM Subject: RE: On Martin Cooper's DownloadAction... Rather than adding lots of new attributes to the existing action mapping element, maybe you should add your properties to an ActionConfig sub-class and use nested set-property elements to configure your download action mapping. Then your download action implementation could be used with older versions of struts. I haven't played with with set-property but I think you would reference your new ActionConfig or ActionMapping sub-class with the action className= attribute and then use nested set-property property= value=/ elements for each property that needs to be set for a particular impl. !ELEMENT action (icon?, display-name?, description?, set-property*, exception*, forward*) You should probably leave Martin's class as is and add your new impl along with a new config class that has all the attributes your action impl needs. That would leave Martin's class available for use by people that have some other means of getting the stream. -Original Message- From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 2:24 PM To: [EMAIL PROTECTED] Subject: On Martin Cooper's DownloadAction... Since the thread I originally started with regard to a BLOB download Action kind of veered off into a different territory, I was hoping starting a new thread could the discussion get back on topic. I have a bit of a vested interest in this now because I started the discussion and I hate leaving anything undone, so... The code posted earlier today by Martin Cooper strikes me as a good approach, better than my own on the whole. As per my comments in the previous thread, I'd like to incorporate some of what I did with my suggested Action however... Basically, the premise I'm proceeding from is that a large part of Struts is declarative, I.e., done through config files. My goal with the Action I wrote was to continue in that vein. Although
RE: On Martin Cooper's DownloadAction...
Looking at the RequestProcessor code there are some casts to ActionMapping so you probably need to extend that rather than ActionConfig. You will also be extending Martin's DownloadAction abstract class to write a version that knows how to instantiate a StreamInfo from mapping properties. I don't see where any other interfaces would help. I think the fact that StreamInfo is an interface is enough. -Original Message- From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 4:05 PM To: Struts Developers List Subject: Re: On Martin Cooper's DownloadAction... Did you really mean to say don't base the ACTION on a concrete subclass? If so, I'm a bit confused (which is my usual state of being, so all is well)... The way I am looking at it, the only thing I'm extending is the ActionConfig, which is a class. The Action Martin wrote of course extends Action. Did I completely miss your meaning? (Ok, let me amend that to cover the most likely scenarioa: IN WHAT *DID* I completely miss your meaning? :) ) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, September 21, 2004 3:46 pm, Joe Germuska said: (1) Extend ActionMapping and have accessors and mutators for all the extra attributes needed (whatever they may actually be, still open for debate) Admitting that I haven't been following this thread closely... please, base the Action on an interface, not a concrete subclass of ActionMapping (ActionConfig). The last thing we need is another single-inheritance trap. Thanks Joe BTW, I think it would be cool to have some core stuff which demonstrates the idea of using custom ActionMappings, as it's a powerful piece of functionality that I think is generally not understood by beginning Struts developers. -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.1 tld uri - RE: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp
I made a patch for this issue and added it to the bug report Matthias created. http://issues.apache.org/bugzilla/show_bug.cgi?id=31021 If this is OK it should be easy to do for struts-el and struts-faces as well. Let me know if you would like patches for those as well. From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Thu 9/2/2004 1:04 AM To: Struts Developers List; Craig McClanahan Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp So, do we need changes for the 1.2.3 release? If so, a quick fix/patch would be appreciated. ;-) -- Martin Cooper On Wed, 1 Sep 2004 21:28:13 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Wed, 1 Sep 2004 18:45:22 -0400, Deadman, Hal [EMAIL PROTECTED] wrote: Maybe Craig's point was that you could put two copies of the tld in the jar's META-INF, one with the old URI and one with the new. The tlds would be otherwise identical but auto-discovery would work no matter what URI the application was using. Not sure how else you would acheive this: That was exactly my point. (Struts 1.2.x should recognize both the old and new tag library URIs, but shouldn't require applications to switch.) Otherwise, a Struts 1.1 application that relies on the implicit TLD registration done by the container (i.e. *not* listing the TLDs explicitly in web.xml) will go down in flames when run against Struts 1.2.x, unless you go fix the taglib directives in every single page. Basically, it's the same reason that Struts 1.2.x accepts and processes 1.0 and 1.1 versions of struts-config.xml files ... so that older apps can run with minimal changes when you upgrade Struts. It turns out that this doesn't matter for the particular commit message I replied on (which only changed the URI for the struts-faces TLD), but it's an important backwards compatibility principle in general. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp
The auto-discovery mechanism for tld files depends on the uri in the tld so changing it can break applications that upgrade if they depend on the auto-discovery of tlds. (They don't need a mapping in web.xml). Since the uri is just a meaningless string (that should be globally unique), there is very little reason to change it. Since you have changed the uri, someone who relied on auto-discovery would either have to change all their jsps that import taglibs or add resolution entries to web.xml. I have used auto-discovery in Weblogic 8.1 but ended up mapping uri-tld location in web.xml when an Eclipse JSP plugin didn't support the auto-discovery. The auto-discovery will be a nice feature once it's widely supported and the uris stay constant. From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Wed 9/1/2004 3:07 PM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp I didn't change anything that referenced Struts 1.1 or Struts 1.2 - just the struts-faces tld and the referencs in the struts-faces jsps for that tld. Just means that struts-faces now reflects the Strut's TLP status. If it causes a problem I'm happy for the changes to be reversed, but I can't see why it would. Niall - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 6:16 PM Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp On 1 Sep 2004 11:34:00 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: niallp 2004/09/01 04:34:00 Modified:contrib/struts-faces/web/example logon.jsp mainMenu.jsp registration.jsp subscription.jsp contrib/struts-faces/web/example2 footer.jsp header.jsp layout.jsp layout1.jsp loggedoff.jsp loggedon.jsp logon.jsp mainMenu.jsp registration.jsp subscription.jsp contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp Log: Change jsp taglib URIs to struts.apache.org - thanks to Matthias Wessendorf for spotting this Doesn't this mean that the apps would not run in a Struts 1.1 environment? If so, that's not acceptable, and I'm -1 on this change. (Struts 1.2.x should recognize both the old and new tag library URIs, but shouldn't require applications to switch.) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp
Maybe Craig's point was that you could put two copies of the tld in the jar's META-INF, one with the old URI and one with the new. The tlds would be otherwise identical but auto-discovery would work no matter what URI the application was using. Not sure how else you would acheive this: (Struts 1.2.x should recognize both the old and new tag library URIs, but shouldn't require applications to switch.) From: Deadman, Hal [mailto:[EMAIL PROTECTED] Sent: Wed 9/1/2004 6:31 PM To: Struts Developers List Subject: RE: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp I noticed the change a few months ago and wondered if they understood the ramifications but I didn't say anything. I realize it's easy to deal with them changing but there is no real value in the URIs being consistent across taglibs while there is some value in them staying consistent over time. The only time someone should care about the URI in the tld is if they are using auto-discovery, since they can make up their own URIs if they are mapping them in web.xml. From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Wed 9/1/2004 6:16 PM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp Actually, it wasn't my decision to change the tld's uri - all I've done is correct the inconsitency that eight were changed (bean, html, logic, nested, tiles, bean-el, html-el and logic-el) and two were not (tiles-el and faces). The original changes were done four months ago and no one objected then. Whatever the argument for or against doing this, they should be consistent. Having said it wasn't my decision - I agree with it though with Struts moving out of jakarta to a TLP. Its not like this is going to happen regularly (probably won't ever need to change again) and as you said adding resolution entries to web.xml will resolve this - and that isn't exactly difficult to do for someone upgrading if they happen to have used auto-discovery. Niall - Original Message - From: Deadman, Hal [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 10:17 PM Subject: RE: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp The auto-discovery mechanism for tld files depends on the uri in the tld so changing it can break applications that upgrade if they depend on the auto-discovery of tlds. (They don't need a mapping in web.xml). Since the uri is just a meaningless string (that should be globally unique), there is very little reason to change it. Since you have changed the uri, someone who relied on auto-discovery would either have to change all their jsps that import taglibs or add resolution entries to web.xml. I have used auto-discovery in Weblogic 8.1 but ended up mapping uri-tld location in web.xml when an Eclipse JSP plugin didn't support the auto-discovery. The auto-discovery will be a nice feature once it's widely supported and the uris stay constant. From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Wed 9/1/2004 3:07 PM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp I didn't change anything that referenced Struts 1.1 or Struts 1.2 - just the struts-faces tld and the referencs in the struts-faces jsps for that tld. Just means that struts-faces now reflects the Strut's TLP status. If it causes a problem I'm happy for the changes to be reversed, but I can't see why it would. Niall - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 6:16 PM Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp On 1 Sep 2004 11:34:00 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: niallp 2004/09/01 04:34:00 Modified:contrib/struts-faces/web/example logon.jsp mainMenu.jsp registration.jsp subscription.jsp contrib/struts-faces/web/example2 footer.jsp header.jsp layout.jsp layout1.jsp loggedoff.jsp loggedon.jsp logon.jsp mainMenu.jsp registration.jsp subscription.jsp contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp Log: Change jsp taglib URIs to struts.apache.org - thanks to Matthias Wessendorf for spotting this Doesn't this mean that the apps would not run in a Struts 1.1 environment? If so, that's not acceptable, and I'm -1 on this change. (Struts 1.2.x
RE: Struts CVS Dependencies on Commons Libraries e.g Collections 3.1
I don't think commons-lang is a runtime dependency, it's just used by unit tests. From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Fri 8/27/2004 1:06 PM To: Struts Developers List Subject: Re: Struts CVS Dependencies on Commons Libraries e.g Collections 3.1 At 4:59 PM +0100 8/27/04, Pilgrim, Peter wrote: Quick fire questions What are Struts CVS Dependencies with Commons ? commons-beanutils: 1.6.1 commons-collections: 2.1 commons-digester: 1.5 commons-fileupload: 1.0 commons-lang: 2.0 commons-logging: 1.0.4 commons-validator: 1.1.3 (cribbed from project.xml) Can Struts 1.2.2* work with Common-Collections 3.1? I don't know, but it looks as though James is trying for you... Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana --_-1118495557==_ma-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
