Re: ActionContext chain changes committed
We don't see a case for a switching contexts within the request cycle to a ViewContext. - Based on *last weeks* code, we created our own context named ActContext that extends ServletWebContext, so we could add convenience methods on it that keep our action code clean (like we want to get the bean in scope by calling getBean on the context, getIDParameter to get a request parameter named ID we use as rowId etc etc) With tonight's svn, it could probably extend ActionContext. To plug it in, we extended ComposableRequestProcessor. I suspect that extending the default context will be a pretty standard thing to do, so it might be a good idea to allow this: controller processorClass=org.apache.struts.chain.ComposableRequestProcessor contextClass=aaa.bbb.ccc.MyContext/ Switching contexts within the request cycle would make all this more difficult. - We also created a DispatchCmd that is modeled after DispatchAction, so commands that extend it can have methods like save(Context context) when the url is /do/testCmd?method=save The sample app code incl. environment (Eclipse 3.1M4 etc) is there at http://sourceforge.net/projects/infonoia/ I will see that it gets updated tomorrow based on the nightly build of tonight's svn. Best regards, Wolfgang Gehner Joe Germuska wrote: I have just committed the suite of changes I was emailing about a few weeks ago. Please be aware that nightly builds are probably now the least stable that they've been in some time. I have spent some time this weekend working on a simple site using the new code (including struts-taglib and struts-tiles jars build from SVN head) and things aren't horribly broken, but there may be some quirks. Odds are good that most of them have to do with the ServletActionContext class not always putting things in request scope that JSPs or utility classes are accustomed to retrieving from the request scope. I find it kind of odd to store things in both places, but it seems like a necessity for a while for backwards compatibility. I hope to continue using this code as I begin prototype work on a new project, but of course, the more people who can get their hands on this code, the better. This also installs the split between the process-action and process-view sub-chains, although I haven't yet changed the SelectInput command to return false to eliminate the need for later commands to check to see if the form was valid. I think the big outstanding question in my mind now is what kind of context we want to pass into the process-view subchain. In some earlier discussions, there was talk about a ViewContext -- I haven't touched that at all, but I'm whether it's worth distinguishing that from the ActionContext. As it is now, I have my own command which sometimes gets used in the view chain and sometimes in the action chain; as it is now, I have to test whether the context is an ActionContext or a ServletWebContext -- I need to get to the request parameters and scope/map, and by not using the ActionContext in the view, it seems more awkward than it should be. It would be pretty easy just to change the chain-config.xml file to use the new WrappingLookupCommand so that the same ActionContext gets sent into both halves, but I didn't want to do that just yet. I'd like to hear if anyone has justifications for a different kind of context for a ViewContext (noting that I have one real use case where the same command is used in both sides, so a ViewContext would be just as awkward as what I have now.) I was also wondering whether we ought to routinely put the context into the request scope so that that object is available to view technologies like JSPs and Velocity templates. It seems like it would be handy. So, for the brave, please dive in and start trying to apply the SVN head to some applications and help to flush out anything that's not quite right... Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionContext chain changes committed
- Based on *last weeks* code, we created our own context named ActContext that extends ServletWebContext, so we could add convenience methods on it that keep our action code clean (like we want to get the bean in scope by calling getBean on the context, getIDParameter to get a request parameter named ID we use as rowId etc etc) With tonight's svn, it could probably extend ActionContext. To plug it in, we extended ComposableRequestProcessor. I suspect that extending the default context will be a pretty standard thing to do, so it might be a good idea to allow this: controller processorClass=org.apache.struts.chain.ComposableRequestProcessor contextClass=aaa.bbb.ccc.MyContext/ Switching contexts within the request cycle would make all this more difficult. I agree that extending the default context will be a common use case. As I implemented, you'd do this by changing the default chain config, specifying a different ContextWrapper class for the WrappingLookupCommand. I thought about putting this in the controller instead, but the general idea of a WrappingLookupCommand seemed useful enough. I was leery of adding too much config to the base struts config until I felt that some of the design ideas were more widely vetted. Also note that ActionContext is an interface, although there is an ActionContextBase implementation which extends ContextWrapper and should provide a pretty straightforward starting point for any non-servlet Struts implementation. Portlet implementations could extend WebActionContext, and Servlet implementations could of course extend ServletActionContext. Unfortunately, all of the concrete implementations of the chain commands have dependencies on the Servlet API, but that's just a legacy of Struts own dependencies. I'm hoping that we can begin to make changes to use the ActionContext class in signatures which previously depended on Servlet API classes. As we do that, we may be able to push more and more behavior into commands which only depend on Struts' own API. - We also created a DispatchCmd that is modeled after DispatchAction, so commands that extend it can have methods like save(Context context) when the url is /do/testCmd?method=save Note that there is a DispatchCommand in the nightly builds of commons-chain also; no one has talked much about a release, but it's there for those who are interested. Thanks for the quick feedback! Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts View
[EMAIL PROTECTED] wrote the following on 2/4/2005 9:59 PM: I've written a small test application with it too. Do you have a demo app somewhere that I could look at or something explaining in a more practical example of how it works? Thanks. My only fear with these kind of proposed implementations is the time factor. In other words, does the cost in learning how the elequent solutions work pay off. For example, those comfortable with Struts could relate to a suggestion like I proposed Validate in your Action class and make sure your view is always prepped there vs possibly having to learn a whole new procedure within Struts. I'm not saying we shouldn't change Struts for the better to handle these sorts of problems, but the cost of how much change is implemented needs to be weighed out. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to add to STRUTS Consultant list?
Hi All Not sure if this is the right place to ask how to add to the Struts consultant list (ie http://wiki.apache.org/struts/StrutsConsultants). We would like to add Australia - Mad Art Services Pty Ltd (www.madart.com.au) to the list. Thanks. Regards Michael Mok - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsConsultants
Date: 2005-02-07T06:53:36 Editor: MichaelMok Wiki: Apache Struts Wiki Page: StrutsConsultants URL: http://wiki.apache.org/struts/StrutsConsultants Added Australia Consultant Change Log: -- @@ -11,6 +11,10 @@ }}} === By Country === +'''Australia''' + + * Mad Art Services -- http://www.madart.com.au/ + '''Belgium''' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33423] New: - Addition of HTML:DOCTYPE / tag.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33423. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33423 Summary: Addition of HTML:DOCTYPE / tag. Product: Struts Version: Unknown Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P2 Component: Unknown AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] I would like to see a tag (or have it automatically added as part of the html:html tag) that would add the DOCTYPE automatically to the document. Since the jsp file will eventually be passed as html to the browser and the (x)html specs require a doctype [1, 2] then it seems prudent to have a tag that will do the job automatically. Like I mentioned there are two possible ways of dealing with this. The first is to add one automatically as part of the html:html tag, and add a couple of new attributes for the tag or have a new tag entirely for the purpose of doctype. Personally I fall into the second camp. My suggestion for the format of the tag would be this (sorry if there is a formal way of describing this): Tag: doctype Attributes: * type : Required. This lists the type of markup (regular html or xhtml) * version : Optional. The level of markup. Important for deprecation of tags and refinements. Possible values for html are 3.2, 4.0, 4.01 (html default) and for xhtml is 1.0 (default) and 1.1. * level : Optional: This determines what level the user would like. The possible values are strict (default), trans, and frames. In html 4.01 the transitional maps to the loose.dtd. Examples: html:doctype type=xhtml version=1.1 level=strict / html:doctype type=html version=4.01 level=trans /+ html:doctype type=html version=4.0 level=frames / [1] http://www.w3.org/TR/html401/struct/global.html [2] http://www.w3.org/TR/xhtml1/#docconf -- Personally, I say author to meet the standards body regulations, or don't bother authoring at all. No point otherwise. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33417] - Kickstart FAQ Patch for Shale
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33417. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33417 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 16:30 --- Applied. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r151720 - in struts/core/trunk: build.xml doc/faqs/kickstart.xml
Ted, one thing to note about the dependency on collections. I thought we
all agreed to move to commons-beanutils.1.7.0.jar (which has
o.a.c.c.FastHashMap) so we don't need commons-collections jar.
Did I miss something?
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 07, 2005 10:29 AM
Subject: svn commit: r151720 - in struts/core/trunk: build.xml
doc/faqs/kickstart.xml
Author: jmitchell
Date: Mon Feb 7 07:29:55 2005
New Revision: 151720
URL: http://svn.apache.org/viewcvs?view=revrev=151720
Log:
fix for http://issues.apache.org/bugzilla/attachment.cgi?id=14192, and
update project version in ant build
Modified:
struts/core/trunk/build.xml
struts/core/trunk/doc/faqs/kickstart.xml
Modified: struts/core/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/struts/core/trunk/build.xml?view=diffr1=151719r2=151720
==
--- struts/core/trunk/build.xml (original)
+++ struts/core/trunk/build.xml Mon Feb 7 07:29:55 2005
@@ -144,7 +144,7 @@
property name=project.name value=struts/
!-- Version of the project --
-property name=project.version value=1.2.6/
+property name=project.version value=1.3.0-dev/
!-- == Derived Properties
--
@@ -201,6 +201,7 @@
path id=compile.classpath
pathelement location=${commons-beanutils.jar}/
pathelement location=${commons-chain.jar}/
+ pathelement location=${commons-collections.jar}/
pathelement location=${commons-digester.jar}/
pathelement location=${commons-fileupload.jar}/
pathelement location=${commons-logging.jar}/
Modified: struts/core/trunk/doc/faqs/kickstart.xml
URL:
http://svn.apache.org/viewcvs/struts/core/trunk/doc/faqs/kickstart.xml?view=diffr1=151719r2=151720
==
--- struts/core/trunk/doc/faqs/kickstart.xml (original)
+++ struts/core/trunk/doc/faqs/kickstart.xml Mon Feb 7 07:29:55 2005
@@ -21,7 +21,14 @@
lia href=#licenseHow is Struts licensed?/a/li
lia href=#usageCan Struts be used in a commercial
application?/a/li
lia href=#creditsDo I have to credit Struts on my own
website?/a/li
- /ulul
+ /ul
+ ul
+lia href=#shale/a/li
+lia href=#shale-fork/a/li
+lia href=#classic/a/li
+lia href=#classic2/a/li
+ /ul
+ ul
lia href=#whereWhere can I get a copy of Struts?/a/li
lia href=#installHow do I install Struts?/a/li
lia href=#jarWhen do I need the struts.jar on my
classpath?/a/li
@@ -43,7 +50,7 @@
lia href=#newsgroupIs there a Struts Newsgroup?/a/li
lia href=#mailbounceWhy didn't my posting show up on the user
list?/a/li
lia href=#unsubscribeHow do I unsubscribe from the mailing
list?/a/li
- /ul
+ /ul
/section
section href=why name=Why do we need Struts?
@@ -88,6 +95,35 @@
Required if you've used the source code to create your own server that you
are redistributing to other people./p
/section
+section href=shale name=Why are you offering both Struts Shale and
Struts Classic? Don't they compete for new development?
+pWe do offer Struts developers a choice, but, hey, choice is good. :)/p
+pPeople who want to create and maintain Struts Classic are welcome to do
so./p
+pPeople who want to create and maintain Struts Shale are equally
welcome./p
+pAs a volunteer organization, we are not constrained by the economics of
competition. All we need are volunteers who are ready, willing, and able to
do the work. So long as we have volunteers, we have work for them to do.
:)/p
+pRight now, we have volunteers who want to leverage the new JavaServer
Faces framework by using Struts Shale for new development. We also have
volunteers who prefer to leverage their existing investment in Struts
Classic. All are welcome./p
+pFor more about volunteering, visit our a
href=http://struts.apache.org/faqs/helping.html;how to help page/a./p
+/section
+
+section href=2x name=Is Shale likely to become Struts 2.x?
+pStruts Shale has its own identity and its own release cycle. Struts
Classic is one subproject, and Struts Shale is another./p
+pSo, no, it is not likely that Struts Shale will become Struts Classic
2.x./p
+pRight now, there are no concrete plans for a 2.x release of Struts
Classic. The people working on the 1.x series want to evolve the code base
without breaking backward compatibility./p
+pThe reasons to roll the major version number are when/p
+ul
+lia new codebase is created, or/li
+lithere is a break in backward compatability./li
+/ul
+pShould either of these things happen, then, in that event, there might
be a Struts Classic 2.x./p
+pFor example, right now, most everyone is using Java 1.3, so that it is
what Struts Classic targets. But, if someone wanted to start a Struts
Tiger codebase, using
DO NOT REPLY [Bug 33426] New: - html:base / enhancement
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33426. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33426 Summary: html:base / enhancement Product: Struts Version: Unknown Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P2 Component: Standard Actions AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] This enhancement is to the html:base tag. The reason for this enhancement request is that the base tag as it stands only points to the jsp file that it is contained in. However the base tag is exceptionally useful when pointed at the root of the URL. My proposal is to add an optional attribute to the html:base tag. If the attribute is missing (or is set to false) then the tag acts as it normally does. With the addition of the attribute being set to true then the tag points to the root of the URL (ie //www.mysite.com/ or //locahost/mysite/). Currently the only way of getting this is currently to have a block of JavaScript code in every webpage and still needs to be set for each site and copied into everypage. tag: base attributes: * root : Optional. Boolean value that determines whether the base tag points at the root URL or the current page. The default is false. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33426] - html:base / enhancement
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33426. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33426 --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 18:21 --- This seems reasonable, although I think I'd prefer some attribute other than root. To me, root could mean either the server root or the webapp root, but probably doesn't mean the current URL minus the file part, which is what I think you mean. perhaps dir? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33430] New: - BaseFieldTag uses value.toString() instead of ConvertUtils.convert(value)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33430. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33430 Summary: BaseFieldTag uses value.toString() instead of ConvertUtils.convert(value) Product: Struts Version: Unknown Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Custom Tags AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] I've registered Converters but still get not formatted value in input fields. This is because BaseFieldTag uses value.toString() instead of ConvertUtils.convert(value). here is the fix: in BaseFieldTag change a line in methode formatValue(Object value): old line: return TagUtils.getInstance().filter(value.toString()); new line: return TagUtils.getInstance().filter(ConvertUtils.convert(value)) Thanks, Eugene -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33430] - BaseFieldTag uses value.toString() instead of ConvertUtils.convert(value)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33430. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33430 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 22:46 --- *** This bug has been marked as a duplicate of 32197 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32197] - Taglibs should use ConvertUtils.convert(Object) instead of .toString()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32197. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32197 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 22:46 --- *** Bug 33430 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33434] New: - el taglibs cause jspc crash?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33434.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33434
Summary: el taglibs cause jspc crash?
Product: Struts
Version: 1.2.4
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Custom Tags
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]
I try to pre-compile my JSPs using a jspc task in my build.xml.
This is the error message that I get:
[echo] precompiling JSPs to ./src/www
[jspc] 22:49:09,468 ERROR [org.apache.struts.util.MessageResourcesFactory]
MessageResourcesFactory.createFactory
[jspc] java.lang.ClassNotFoundException:
org.apache.struts.util.PropertyMessageResourcesFactory
[jspc] at java.net.URLClassLoader$1.run(Unknown Source)
[jspc] at java.security.AccessController.doPrivileged(Native Method)
[jspc] at java.net.URLClassLoader.findClass(Unknown Source)
[jspc] at java.lang.ClassLoader.loadClass(Unknown Source)
[jspc] at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
[jspc] at java.lang.ClassLoader.loadClass(Unknown Source)
[jspc] at
org.apache.struts.util.RequestUtils.applicationClass(RequestUtils.java:119)
[jspc] at
org.apache.struts.util.MessageResourcesFactory.createFactory(MessageResourcesFactory.java:150)
[jspc] at
org.apache.struts.util.MessageResources.getMessageResources(MessageResources.java:495)
[jspc] at org.apache.struts.taglib.html.HtmlTag.clinit(HtmlTag.java:50)
[jspc] at java.lang.Class.forName0(Native Method)
[jspc] at java.lang.Class.forName(Unknown Source)
[jspc] at
org.apache.strutsel.taglib.html.ELHtmlTagBeanInfo.class$(ELHtmlTagBeanInfo.java:48)
[jspc] at
org.apache.strutsel.taglib.html.ELHtmlTagBeanInfo.getPropertyDescriptors(ELHtmlTagBeanInfo.java:48)
[jspc] at java.beans.Introspector.getTargetPropertyInfo(Unknown Source)
[jspc] at java.beans.Introspector.getBeanInfo(Unknown Source)
[jspc] at java.beans.Introspector.getBeanInfo(Unknown Source)
[jspc] at
org.apache.jasper.compiler.Generator$TagHandlerInfo.init(Generator.java:3676)
[jspc] at
org.apache.jasper.compiler.Generator$GenerateVisitor.getTagHandlerInfo(Generator.java:2098)
[jspc] at
org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1579)
[jspc] at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1441)
[jspc] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2163)
[jspc] at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2213)
[jspc] at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2219)
[jspc] at org.apache.jasper.compiler.Node$Root.accept(Node.java:456)
[jspc] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2163)
[jspc] at
org.apache.jasper.compiler.Generator.generate(Generator.java:3268)
[jspc] at
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:189)
[jspc] at org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
[jspc] at org.apache.jasper.JspC.processFile(JspC.java:854)
[jspc] at org.apache.jasper.JspC.execute(JspC.java:989)
It seems to fail on my struts-html-el taglib (and -logic and probably -bean).
When I strip the -el in the taglib location in the web.xml, in other words:
...taglib-location/WEB-INF/tld/struts-html.tld/taglib-location...
instead of:
...taglib-location/WEB-INF/tld/struts-html-el.tld/taglib-location...
the problem disappears. It only occurs when pre-compiling the JSPs, it doesn't
show up when post-compiling :-)
Though it looks like it can't find
org.apache.struts.util.PropertyMessageResourcesFactory (that's what it says), I
am sure that its jar (struts.jar) is on my class path (see below). Besides, it
is just as necessary when I use the non-el versions, and then it doesn't
complain.
My ant jsp task looks like:
target name=jsp-compile description=compiles the jsp files into
java files,
which are placed among the other .java files
taskdef classname=org.apache.jasper.JspC name=jspc
classpath id=jspc.classpath
pathelement location=${base.dir}/tmp/
fileset dir=${lib.dir}
include name=*.jar/
/fileset
fileset dir=${base.dir}/ref
include name=*.jar/
/fileset
/classpath
/taskdef
echoprecompiling JSPs to ${www.dir}/echo
jspc
DO NOT REPLY [Bug 33434] - el taglibs cause jspc crash?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33434. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33434 --- Additional Comments From [EMAIL PROTECTED] 2005-02-07 23:21 --- Created an attachment (id=14200) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14200action=view) in fact this is the log4j output of the jspc Ant task, and it shows the same error as I already mentioned -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsChain
Date: 2005-02-07T14:43:58 Editor: JoeGermuska Wiki: Apache Struts Wiki Page: StrutsChain URL: http://wiki.apache.org/struts/StrutsChain Update to reflect big commit of chain changes. Change Log: -- @@ -3,30 +3,23 @@ Some of the changes for this are fairly wide ranging, so it is risky to commit them to SVN until more is accomplished. We'll use this page to discuss implementation plans and questions, and to link to interim distributions. === What's in SVN === -The code committed to [http://struts.apache.org/acquiring.html#SourceCode SVN] is substantially similar to the old standalone struts-chain project. Here is a summary of the changes: +The code committed to [http://struts.apache.org/acquiring.html#SourceCode SVN] has started to diverge from the old standalone struts-chain project. Here is a summary of the changes: * Struts has been updated so that the ActionServlet initializes chain catalogs using the value of the init parameter '''chainConfig''', which should consist of one or more paths to XML files which can be processed by the standard Chain [http://jakarta.apache.org/commons/chain/apidocs/org/apache/commons/chain/config/ConfigParser.html ConfigParser]. The paths may be either classpath resources or servlet context resources; the initialization process has methods for checking in both places without additional configuration. This and the changes to the RequestProcessor obsolete the CatalogConfiguratorPlugIn. If no '''chainConfig''' parameter is specified, then Struts defaults to looking for '''org/apache/struts/chain/chain-config.xml''' which is included in struts.jar. If any '''chainConfig''' value is specified, then if you also want Struts to use the default config, you must include it in the list of config files. * Struts has been adjusted to use the ComposableRequestProcessor by default. You may switch back to the original RequestProcessor by specifying it as the '''processorClass''' in the '''controller''' element of your '''struts-config''' file. By default, the ComposableRequestProcessor begins processing with the '''servlet-complete''' command in the '''struts''' catalog. This may be changed by specifying the '''catalog''' and '''command''' attributes in the '''controller''' element of your '''struts-config''' file. * You can now specify a chain command to be executed as part of any '''action''' element in a '''struts-config''' file. Simply include values for the '''catalog''' and '''command''' attributes. If a command is configured, then it will be executed before (or instead of) any action, forward, or include which is also configured in the '''action''' element. This effectively obsoletes the ChainAction class. Note that this functionality is '''only''' implemented in a chain command; if you revert to using the original RequestProcessor, these configuration values will be ignored. -=== What's under development === -JoeGermuska is working on implementing an ActionContext interface which clarifies the API with which Commands can interact with Struts. This class provides typesafe properties for all of the configuration values which are used by more than one command, and provides analogs for all of the methods which are part of the base Action class. + * The default chain has been reconfigured to be a bit simpler, and most importantly, to split processing into two sub-chains. These chains are process-action and process-view, and while the default process-view chain is only PerformForward, this seems to be a cleaner arrangement. It will also allow a command to terminate action processing early (such as when a form is determined to be invalid), saving later actions from the trouble of re-checking to see if the form is valid. + + * As part of this reconfiguration, the process-action chain is provided with an instance of a new interface, ActionContext. This allows the commands to use typesafe methods to extract values like the ActionForm and ActionConfig rather than having to rely upon +String constants and casting. This is something which still merits user feedback, as there are some questions about the best time and manner to construct an ActionContext, whether it should also be passed to the process-view chain, and whether it should even be made available outside of Struts in a final view handling technology like JSP or Velocity. -Code in the development builds includes a WrappingLookupCommand which creates a ServletActionContext class wrapping the current chain Context. It might be worth brief debate about whether it's safe to wrap the current context, or if instead the command which launches the '''process-action''' chain should copy values into and out of the context. The problem with the copying is that if users want to pass more values in, the copy process would have to be locally modified. -
DO NOT REPLY [Bug 33426] - html:base / enhancement
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33426. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33426 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 00:09 --- (In reply to comment #1) This seems reasonable, although I think I'd prefer some attribute other than root. To me, root could mean either the server root or the webapp root, but probably doesn't mean the current URL minus the file part, which is what I think you mean. perhaps dir? That is correct, however to me root is the lowest valid web address. If you are interested this is the JS source I use (now attached to bug) - it might be useful in explaining it better. I don't think 'dir' is a better term - to me it suggests that any directory, not the lowest level directory available. I'll have a think on something that would be more descriptive. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33426] - html:base / enhancement
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33426. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33426 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 00:10 --- Created an attachment (id=14202) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14202action=view) The JavaScript code I use -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts View Proposal
Hello fellow Struts Developers, My name is Paul Benedict and I am an active and professional developer who uses Struts on a daily basis and have been using it for over a year now. I am really enthused with the framework, and I think it is moving towards something great -- despite the false rumors of its demise with JSF :) In fact some of the great ideas people are proposing for Struts 2.x do perplex me somewhat, as many chunks could be applied right now to the 1.x branch. Anyway, what I am trying to say that I pay attention to its development, methodologies, and the opinions from industry experts, and feel motivated to contribute my sweat too. I have often encountered the problem of not being able to retain certain objects across requests without putting them in the session. I really crawled the web for different methodologies, and I still think Rick Reumman stated this problem the best (reumann.net/struts/articles/request_lists.jsp). So I am trying to take a professional stab at this problem for the open-source community. This is also my first attempt at open-source software so please be kind to juvenile mistakes I may make! I am dedicate to providing a real solutions for all Struts developers and hope it will be finished in time for Struts 1.3, if the committers find it worthwhile, and donate it to ASF. My solution is tentatively called Struts View, and it's purpose is to allow views or conversations to be managed across HTTP requests. You can find my proposal and source code at http://members.aol.com/benedictpa/struts-view.html. Please, if you have suggestions, comments, or constructive criticisms, send them my way and I will change and implement anything sound. I hope to get as many people interested and involved as possible so that I -- and you -- don't have to continue reinvent a solution to this problem. Thanks everyone and God bless, Paul Benedict - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33439] New: - Unable to get bean:define to work on One of two server types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33439. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33439 Summary: Unable to get bean:define to work on One of two server types Product: Struts Version: 1.2.4 Platform: Sun OS/Version: SunOS Status: NEW Severity: major Priority: P2 Component: Custom Tags AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] I have two different servers one is a linux/weblogic Server8.1 SP3/jvm jrockit81sp3_142_04 and the other Sun(OS 5.8)/ weblogic Server8.1 SP1/ jvm Sun jdk 1.4.2 Bean:define taglib work fine in the linux server but the same code when promoted to the Sun machine fails. The bean:define never initalize the variable that my id defines. bean:define id='curApp' name=userSearch property=searchApp / This fails with cannot resolve symbol for curApp were ever referenced. Although using this code below will define the variable. jsp:useBean id=userSearch scope=request class=com.abc.forms.UserSearch / % String curApp = userSearch.getSearchApp(); % It won't initialize the id variable even if I set a value attribute. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsConsultants
Date: 2005-02-07T19:38:45 Editor: NeilAggarwal Wiki: Apache Struts Wiki Page: StrutsConsultants URL: http://wiki.apache.org/struts/StrutsConsultants Added JAMM Consulting to list of USA consultants. Change Log: -- @@ -144,6 +144,7 @@ * ISIS Networks -- http://www.isisnetworks.net * Jade Cove Solutions (Atlanta) -- http://www.jadecove.com * James Holmes (Struts committer, creator of Struts Console) -- http://www.jamesholmes.com + * JAMM Consulting, Inc. (Plano, TX) -- http://www.JAMMConsulting.com * J.P. Evans, Inc. (Washington, D.C.) -- http://www.jpevans.com/ * nVISIA, LLC -- http://www.nvisia.com/struts * ObjectSource LLC -- Consulting, Training and Publishing -- http://www.objectsource.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
