DO NOT REPLY [Bug 33989] New: - ant test.tomcat.40 fails: taskdef class org.apache.cactus.ant.RunServerTestsTask cannot be found, task name runservertests
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=33989.
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=33989
Summary: ant test.tomcat.40 fails: taskdef class
org.apache.cactus.ant.RunServerTestsTask cannot be
found, task name runservertests
Product: Struts
Version: 1.2.6 Beta
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Test
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]
Environment: jdk1.5, cygwin
Normally, the builds is so nice to get the required jars automatically:
...
Adding reference: compile.classpath
[ant] Entering C:\Documents and Settings\RalfCHauser\My
Documents\psph\workspace\struts\build-tests.xml...
Build sequence for target(s) `test.tomcat.40' is [init, prepare.test,
compile.test, prepare.test.war, prepare.test.tomca
t.40, test.tomcat.40]
Complete build sequence is [init, prepare.test, compile.test, prepare.test.war,
prepare.test.tomcat.40, test.tomcat.40,
stop.tomcat.50, prepare.test.tomcat.32, test.tomcat.32, prepare.test.tomcat.50,
start.tomcat.41, start.tomcat.40, stop.t
omcat.33, stop.tomcat.32, prepare.test.tomcat.41, test.tomcat.41,
prepare.test.tomcat.33, run.test, start.tomcat.50, sto
p.tomcat.41, stop.tomcat.40, test.tomcat.50, test.junit, start.tomcat.33,
start.tomcat.32, , test.tomcat.33]
init:
dropping C:\opt\Apache\jakarta-cactus-13-1.4.1\lib\cactus-ant-1.4.1.jar from
path as it doesn't exist
Finding class org.apache.cactus.ant.RunServerTestsTask
[taskdef] C:\Documents and Settings\RalfCHauser\My
Documents\psph\workspace\struts\build-tests.xml:129: , taskdef clas
s org.apache.cactus.ant.RunServerTestsTask cannot be found, task name
runservertests
[ant] Exiting C:\Documents and Settings\RalfCHauser\My
Documents\psph\workspace\struts\build-tests.xml.
When configuring the build.properties to use the latest
(integration/ant/dist-13/lib/) cactus-ant-1.8dev.jar, it appears that in
build-test.xml,
target name=init
taskdef name=runservertests
classname=org.apache.cactus.integration.ant.RunServerTestsTask
the path no longer is org.apache.cactus.ant.RunServerTestsTask.
also, this adds a dependency on commons-logging.jar, so that classpath in the
same init target also needs
pathelement location=${commons-logging.jar}/
also, got many more errors for jar files not present in the /opt tree, it would
be great if those were automatically downloaded like in cactus.
--
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: [Shale] subview component XML composition extension
Mike Kienenberger wrote:
I haven't used JSF enough to see if it fits the same pattern, but the
component-based frameworks I've used in the past have always made Tiles
unnecessary. Components are tiles.
I think that many might prefer using a component XML base technique for page
composition but there will still be people that want to take advantage of the
wizz-bang IDE's being developed for JSF JSP that provide a palette of
components, drag and drop and component based property editors. Tiles would
still be very helpful for JSF/JSP development.
You build a component representing your layout and stick your other layout
components in it. Then you reference your layout component from your
general application pages.
Tiles works really well for page layout / composition too, allowing you to pull
together a bunch of page fragments in a declarative way. The strength of my
solution is in building the content of the page fragments to promote reuse. In
the subview XML, each node defined has to tied to a faces component and each
component is associated with a renderer. It's focus is on constructing the
meat of a page and would not allow a mix of HTML and faces component
declaration unless the HTML was represented as a faces component and renderer.
I'll pull from my example where I defined a city/state/zip page fragment. It
has validators and listeners and messages included. The panelGrid component
represents a table with two rows having 4 columns. The second row is for
validation messages. This example is for a agents address and the agent must
live in the state so the state field is a static output value.
!-- an agent must live in the same state, state is a static field --
displayElement elementId=agentCityStateZipPanel extends=panelGrid
attributes
set name=columns value=4 /
/attributes
element renderId=1 elementId=outputLabel
attributes
set name=value value=City/State/Zip: /
set name=for value=city /
/attributes
/element
element renderId=2 elementId=inputText id=city
attributes
set name=value value=#{managed-bean-name.city} /
set name=size value=20 /
set name=maxlength value=30 /
set name=required value=true /
/attributes
/element
element renderId=3 elementId=outputText
attributes
set name=value value=#{managed-bean-name.state} /
/attributes
/element
!-- 2 types methods for binding change listeners and a converter --
element renderId=4 elementId=inputText id=zip
attributes
set name=value useValueLateBinding=true
value=#{managed-bean-name.zip} /
set name=maxlength value=9 /
set name=size value=5/
set name=valueChangeListener useMethodLateBinding=true
value=#{managed-bean-name.zipValueChange} /
/attributes
converter elementId=integerConverter /
validator elementId=validateLongRange /
valueChangeListener elementId=testValueChangeListener /
/element
element renderId=5 elementId=space /
element renderId=6 elementId=message
attributes
set name=for value=city /
/attributes
/element
element renderId=7 elementId=space /
element renderId=8 elementId=message
attributes
set name=for value=zip /
/attributes
/element
/displayElement
In another view, we want to provide a full address where the states are a
droplist and a required field. Using faces and JSP, you would have to copy the
page fragment and make the changes and then use tiles to override at the page
level what fragment you wanted to include. What I'm trying to offer is a
method of reusing and extending the first page fragment. This example extends
the definition overriding the state and adding a validation message.
!-- extends the agent address making the state a droplist --
displayElement elementId=cityStateZipPanelEx
extends=agentCityStateZipPanel
!-- override with a nested element --
element renderId=3 elementId=selectOneMenu id=states
attributes
set name=value value=#{managed-bean-name.state} /
set name=required value=true /
/attributes
element renderId=0 elementId=selectItem
attributes
set name=itemLabel value= /
set name=itemValue value= /
/attributes
/element
element renderId=1 elementId=selectItem
attributes
set name=itemLabel value=Colorado /
set name=itemValue value=CO /
/attributes
/element
element renderId=2 elementId=selectItem
attributes
set name=itemLabel value=Illinois /
set name=itemValue value=IL /
/attributes
/element
/element
!-- add a message for the required state overriding a space --
element renderId=7 elementId=message
attributes
set
DO NOT REPLY [Bug 33991] New: - test date formatting for the bean:write 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=33991. 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=33991 Summary: test date formatting for the bean:write tag Product: Struts Version: 1.2.6 Beta Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Test AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] The org.apache.struts.taglib.bean.TestWriteTag.testWriteTagNameFormat*() methods appear to only test for org.apache.struts.taglib.bean.TestWriteTag.TEST_INTEGER_VAL and TEST_DOUBLE_VAL, but not for the 3 variants of dates (see also Bug 33861) multiplied by a number of locales ot test. Therefore, please add such test cases (plus eventually also for timezones as per bug 33867) -- 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 33982] - taglibs build failure
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=33982. 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=33982 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-03-13 17:04 --- Thanks for your help. I'm actually right in the middle of making changes to get the taglibs back up and running. I've decided to go with a more standard approach (Maven cactus plugin) as apposed to what we used to do with Ant. I have the complete cactus test suite running locally, but I need to fix 1 small issue before committing my changes. Thanks again for your help. -- 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 33989] - ant test.tomcat.40 fails: taskdef class org.apache.cactus.ant.RunServerTestsTask cannot be found, task name runservertests
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=33989. 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=33989 --- Additional Comments From [EMAIL PROTECTED] 2005-03-13 17:07 --- Can you please restate what issue you are having? I find it difficult to follow what you put here. -- 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: [Shale] subview component XML composition extension
Le Mar 12, 2005, à 3:52 PM, Mike Kienenberger a écrit : David Geary [EMAIL PROTECTED] wrote: I think this is all good stuff, but I'd rather see integration with Tiles instead of reinventing Tiles. Tiles has already covered some of this ground and I see no reason for us to follow. I haven't used JSF enough to see if it fits the same pattern, but the component-based frameworks I've used in the past have always made Tiles unnecessary. Components are tiles. Interestingly enough, Tiles was originally called Components. You build a component representing your layout and stick your other layout components in it. Then you reference your layout component from your general application pages. An example (and possibly not the best example) from a four-year-old Webobjects project. Note that WebObjects (and Tapestry as well from what I understand -- RenderBody?) both allow you to access the parent document content. It's unclear to me whether JSF is component-based enough to do this as I haven't built any components with it yet. (Someone asked me this question last week, and I haven't had time to find an answer yet.) Component-based models allow you to do things differently, and I'm just wondering if you're dragging some old-school methodologies into it unnecessarily. Perhaps the answer is that there's no need to reinvent Tiles OR integrate Tiles. Perhaps, but assuming we want the same functionality that Tiles currently provides, such as XML tile definitions, tile inheritance, role-based tiles, controllers, etc., you're going to have to reinvent it unless you leverage Tiles somehow. You can have layout components, certainly, but that would just be the tip of the Tiles iceberg. I would advocate a layer of Shale components/renderers/variable resolvers/whatever that integrate with Tiles. Perhaps we could make layout components an option instead of layout JSP pages, as is the default for Tiles, although I bet most people would prefer the latter. david -Mike InternalExternalPageContent == WEBOBJECT NAME=InternalExternalJSHeader WEBOBJECT NAME=ShouldShowLeftSideMenuConditional WEBOBJECT NAME=IsInternalConditionalWEBOBJECT NAME=LeftSideMenu /WEBOBJECT/WEBOBJECT WEBOBJECT NAME=IsExternalConditionalWEBOBJECT NAME=LoginPanel /WEBOBJECT/WEBOBJECT div class=content /WEBOBJECT WEBOBJECT name=ParentContent/WEBOBJECT WEBOBJECT NAME=ShouldReturnToLastPageConditional WEBOBJECT NAME=ReturnToLastPageHyperlinkReturn To Last Page/WEBOBJECT p / /WEBOBJECT WEBOBJECT NAME=ShouldReturnToURLConditional WEBOBJECT NAME=ReturnToURLHyperlinkReturn To Last Page/WEBOBJECT p / /WEBOBJECT WEBOBJECT NAME=IsInternalConditionalWEBOBJECT NAME=InternalFooter /WEBOBJECT/WEBOBJECT WEBOBJECT NAME=IsExternalConditionalWEBOBJECT NAME=ExternalFooter /WEBOBJECT/WEBOBJECT WEBOBJECT NAME=ShouldShowLeftSideMenuConditional /div /WEBOBJECT /WEBOBJECT === ==Pages in the app that use the above== !-- !DOCTYPE HTML PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml11/DTD/transitional.dtd; -- html WEBOBJECT NAME=CommonHeadTags titleDEMO - Online Bill Payment/title Any other head tags you want to add or modify /WEBOBJECT WEBOBJECT NAME=InternalExternalPageContent This is where your page content would go for any particular page...ie, body/ content /WEBOBJECT /html === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33989] - ant test.tomcat.40 fails: taskdef class org.apache.cactus.ant.RunServerTestsTask cannot be found, task name runservertests
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=33989.
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=33989
--- Additional Comments From [EMAIL PROTECTED] 2005-03-13 19:02 ---
sorry for having been unclear:
1) in build-test.xml, target name=init
taskdef name=runservertests
classname=org.apache.cactus.ant.RunServerTestsTask
is wrong with newer cactus builds
2) the same task also needs now
pathelement location=${commons-logging.jar}/
3) it would be great if there was a download.xml mechanism to get the missing
jar's into /opt like cactus has it
--
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: [Shale] subview component XML composition extension
David Geary Wrote:
Perhaps, but assuming we want the same functionality that Tiles
currently provides, such as XML tile definitions, tile inheritance,
role-based tiles, controllers, etc., you're going to have to reinvent
it unless you leverage Tiles somehow. You can have layout components,
certainly, but that would just be the tip of the Tiles iceberg.
I would argue that the point of the xml subview component would be to provide
something that tiles could not. For another example, a dataTable that defines
first and last name. Notice the EL for the value attribute of the dataTable
#{managed-bean-name.persons}. The managed-bean-name will be replaced with the
id attribute of the subview component in the JSP this allows a definition to be
used against more than one managed bean/ view controller. In the next
displayElement definition, a couple columns are added to the personTable
component. The only way to do this with JSP and tiles is to create two JSP's
and use tiles to pull in a different fragment.
JSP Tag
sh:xsubview id=personTable elementId=personTable /
sh:xsubview id=employeeTable elementId=employeeTable /
XML view definition
displayElement elementId=personTable extends=dataTable
attributes
set name=value useValueLateBinding=true
value=#{managed-bean-name.persons}/
set name=var value=e/
set name=rows value=5/
set name=first value=1/
set name=border value=1/
set name=cellpadding value=3/
/attributes
element renderId=1 elementId=firstNameColumn/
element renderId=2 elementId=lastNameColumn/
/displayElement
displayElement elementId=employeeTable extends=personTable
element renderId=0 elementId=ssnColumn/
element renderId=3 elementId=birthDateColumn/
/displayElement
I would advocate a layer of Shale components/renderers/variable
resolvers/whatever that integrate with Tiles. Perhaps we could make
layout components an option instead of layout JSP pages, as is the
default for Tiles, although I bet most people would prefer the latter.
I don't see the two options being mutually exclusive.
Gary
Re: [Shale] subview component XML composition extension
Ah, okay, I see. This capability, which essentially lets you plug
component attributes (including managed bean properties) into
components at runtime, is more fine-grained than Tiles and is certainly
JSF-specific. In fact, a while back, I had a client ask for something
like this: they wanted to use the same tile for different managed
beans, selected at runtime.
This reminds me of something I've been thinking about for some time:
Tapestry-like HTML views that dovetail with XML component definitions
(see Hans' Bergsten's article about dumping JSP with JSF at
onjava.com). In that case an HTML view references components in a
component definition file. If you could select a component definition
file at runtime for a view, I believe you'd have analagous
functionality to what Gary is proposing here.
david
Le Mar 13, 2005, à 11:09 AM, [EMAIL PROTECTED] a écrit :
David Geary Wrote:
Perhaps, but assuming we want the same functionality that Tiles
currently provides, such as XML tile definitions, tile inheritance,
role-based tiles, controllers, etc., you're going to have to reinvent
it unless you leverage Tiles somehow. You can have layout components,
certainly, but that would just be the tip of the Tiles iceberg.
I would argue that the point of the xml subview component would be to
provide something that tiles could not. For another example, a
dataTable that defines first and last name. Notice the EL for the
value attribute of the dataTable #{managed-bean-name.persons}. The
managed-bean-name will be replaced with the id attribute of the
subview component in the JSP this allows a definition to be used
against more than one managed bean/ view controller. In the next
displayElement definition, a couple columns are added to the
personTable component. The only way to do this with JSP and tiles is
to create two JSP's and use tiles to pull in a different fragment.
JSP Tag
sh:xsubview id=personTable elementId=personTable /
sh:xsubview id=employeeTable elementId=employeeTable /
XML view definition
displayElement elementId=personTable extends=dataTable
attributes
set name=value useValueLateBinding=true
value=#{managed-bean-name.persons}/
set name=var value=e/
set name=rows value=5/
set name=first value=1/
set name=border value=1/
set name=cellpadding value=3/
/attributes
element renderId=1 elementId=firstNameColumn/
element renderId=2 elementId=lastNameColumn/
/displayElement
displayElement elementId=employeeTable extends=personTable
element renderId=0 elementId=ssnColumn/
element renderId=3 elementId=birthDateColumn/
/displayElement
I would advocate a layer of Shale components/renderers/variable
resolvers/whatever that integrate with Tiles. Perhaps we could make
layout components an option instead of layout JSP pages, as is the
default for Tiles, although I bet most people would prefer the latter.
I don't see the two options being mutually exclusive.
Gary
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33672] - struts-faces is incompatible with myfaces
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=33672. 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=33672 --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 03:21 --- This is great news! I'll clean up the wrapper class stuff soon (still in a huge email backlog). By the way, is the Incubator CVS still the place to get the latest MyFaces source code? -- 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 33995] New: - ActionServlet.initChain() fails to load additional config files
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=33995. 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=33995 Summary: ActionServlet.initChain() fails to load additional config files Product: Struts Version: Nightly Build Platform: Macintosh OS/Version: Mac OS X 10.3 Status: NEW Severity: normal Priority: P2 Component: Controller AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] If you specify multiple chain configuration files using an inititialization parameter, where each config file is separated by a comma, only the first resource will load. -- 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 33995] - ActionServlet.initChain() fails to load additional config files
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=33995. 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=33995 --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 04:49 --- Created an attachment (id=14483) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14483action=view) Change to ActionServlet.initChain() so multiple config files are loaded correctly. -- 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: Compiling STRUTS and STRUTS-FACES with servlet 2.4 and jsp 2.0
FYI, as soon as I apply some recent patches (to remove the wrapper class) this whole area will become a non-issue for struts-faces. In the general case, however, it is not currently feasible to create a wrapper that works across 2.3 and 2.4 unless you're willing to do a little work with Java reflection to transparently deal with the 2.4 methods that are not there in 2.3 (and therefore you cannot delegate to the underlying wrapper). Craig On Sat, 12 Mar 2005 09:16:39 -0500, Bill Siggelkow [EMAIL PROTECTED] wrote: On 2005-03-11 00:25:35 -0500, Martin Cooper [EMAIL PROTECTED] said: On Tue, 1 Mar 2005 09:11:28 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: Doing the simple version of a change like this will cause the wrapper class to not be compilable against a 2.2 or 2.3 version of the servlet API any longer, which is a particular problem for the standard Struts release. I don't believe that's the case. The current implementation of MultipartRequestWrapper uses exactly the same technique that Ramiro mentions to allow compilation against the Servlets 2.3 API. Adding extra methods to the implementation class allows it to compile against the newer API, while the methods become just ordinary class methods when compiled against the older API. It's true that the dummy methods added to satisfy the newer API are not useful (without the use of reflection, as you suggest below), but that doesn't seem to have caused problems for people using the Servlets 2.3 API while we've been dummying up the methods new to that version over Servlets 2.2. Well, I ran into this the other day -- and while it seemed like I could just no-op (or wrapper) for the new methods in the Servlet API (getLocalAddr() etc.) there are other problems in the taglibs against the JSP API -- because JSP 2.0 introduces new classes like ExpressionEvaluator. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33996] New: - ChainAction does not support non-default catalogs
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=33996. 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=33996 Summary: ChainAction does not support non-default catalogs Product: Struts Version: Nightly Build Platform: Macintosh OS/Version: Mac OS X 10.3 Status: NEW Severity: normal Priority: P2 Component: Standard Actions AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] The ChainAction does not support the use of a mapping parameter that specifies the chain to load using the 'catalogName:chainName' convention. This issue could be resolved by upgrading to a later build of commons chain that supports the CatalogFactory.getCommand() method. However, the ChainAction would need to be modified. -- 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: Compiling STRUTS and STRUTS-FACES with servlet 2.4 and jsp 2.0
Having the wrapper extend the HttpServletRequestWrapper (introduced in Servlet 2.3) resolves this - just need to remove the dummy methods. Niall - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Monday, March 14, 2005 4:11 AM Subject: Re: Compiling STRUTS and STRUTS-FACES with servlet 2.4 and jsp 2.0 FYI, as soon as I apply some recent patches (to remove the wrapper class) this whole area will become a non-issue for struts-faces. In the general case, however, it is not currently feasible to create a wrapper that works across 2.3 and 2.4 unless you're willing to do a little work with Java reflection to transparently deal with the 2.4 methods that are not there in 2.3 (and therefore you cannot delegate to the underlying wrapper). Craig On Sat, 12 Mar 2005 09:16:39 -0500, Bill Siggelkow [EMAIL PROTECTED] wrote: On 2005-03-11 00:25:35 -0500, Martin Cooper [EMAIL PROTECTED] said: On Tue, 1 Mar 2005 09:11:28 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: Doing the simple version of a change like this will cause the wrapper class to not be compilable against a 2.2 or 2.3 version of the servlet API any longer, which is a particular problem for the standard Struts release. I don't believe that's the case. The current implementation of MultipartRequestWrapper uses exactly the same technique that Ramiro mentions to allow compilation against the Servlets 2.3 API. Adding extra methods to the implementation class allows it to compile against the newer API, while the methods become just ordinary class methods when compiled against the older API. It's true that the dummy methods added to satisfy the newer API are not useful (without the use of reflection, as you suggest below), but that doesn't seem to have caused problems for people using the Servlets 2.3 API while we've been dummying up the methods new to that version over Servlets 2.2. Well, I ran into this the other day -- and while it seemed like I could just no-op (or wrapper) for the new methods in the Servlet API (getLocalAddr() etc.) there are other problems in the taglibs against the JSP API -- because JSP 2.0 introduces new classes like ExpressionEvaluator. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] usecases app
On Sat, 12 Mar 2005 16:11:04 +0100, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I am just starting to play with Shale framework by building some simple JSF/Shale web apps. The ViewController interfaces is very nice and the its default implemention (both in *core* framework) also! The primary reason for a default implementation in the core framework is to protect users from evolution of the interface (for example, adding new methods later would normally break all implementations of that interface). For those that subclass the default implementation, we can provide default behaviors that mirror the previous version, and make maintaining backwards compatibility easier. You see this kind of thing a lot in JavaBeans event related designs ... an interface describing the available events, and an adapter class that provides default implementations. If you extend the latter, you gain the benefit of only overriding methods where you want something non-default, but also protection from future changes in the interface. I looked at BaseViewController that is super clazz for all backing beans inside the usecases app. However, I think the getBean(String name) and its getFacesContext() from BaseViewController are very useful generell. So why are that not included into the interface? Any idea? There are several reasons for this. One of the knocks against a framework like Struts 1.x is that it is relatively difficult to construct unit tests for an Action, because you have to set up a tremendous amount of infrastructure to make it work. I want ViewController implementations to have the simplest possible interface, to minimize the amount of setup work you need to do for these things. (The importance of this argument is lessened because Shale has a test framework available as well, with all the gory details taken care of, but the principle still applies). Another reason relates to the Hollywood Principle (don't call us, we'll call you) that is the basis for most IoC container designs today. Thinking of the ViewController methods as callbacks means you are focused on responding to events that are occurring, where the underlying framework takes responsibility of notifying you when something interesting happens. Utility methods like getBean() and getFacesContext() are things that the ViewController implementation itself would call, rather than things the framework would call, so they don't seem to mix very well. Finally, it is definitely feasible to implement a ViewController that doesn't require access to these methods. Why should *every* implementation be forced to implement them, even if they are not going to be used? On the other hand, if you need them, just subclass the default implementation. Thanks, Matthias Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] usecases app
On Sat, 12 Mar 2005 17:27:39 +0100, Matthias Wessendorf
public static Object getBean(String name) {
Over my development career, about 98% of the time I have implemented
static utility methods like this, I have been sorry later.
Inevitably, someone wants to specialize the behavior of the
(theoretically) universal utilities, and you just can't do that with
static methods.
I can see a case for a ShaleUtils type class that was *delegated* to,
but BeanUtils (and similar cases) has taught me to never again believe
that a framework author can know, ahead of time, all the possible use
cases for their utility code.
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33996] - ChainAction does not support non-default catalogs
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=33996. 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=33996 --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 05:57 --- I think it just hasn't been updated since named catalogs were introduced. There is another similar problem, where it assumes that the exception handler is in the default catalog, which is not true by default since the provided catalog is named 'struts'. -- 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: [Shale] subview component XML composition extension
On Sat, 12 Mar 2005 17:52:17 -0500, Mike Kienenberger [EMAIL PROTECTED] wrote: David Geary [EMAIL PROTECTED] wrote: I think this is all good stuff, but I'd rather see integration with Tiles instead of reinventing Tiles. Tiles has already covered some of this ground and I see no reason for us to follow. I haven't used JSF enough to see if it fits the same pattern, but the component-based frameworks I've used in the past have always made Tiles unnecessary. Components are tiles. The ability to create layout components was indeed one of the motivations for the API design in JSF. Indeed, if you are using a templating approach that does *not* allow intermixing static template text (which is not the case for JSP, or for Tapestry), then you are pretty much stuck with using components to do your layout for you. The benefit, on the other hand, is that you can delegate responsibility for dealing with all the nit-picky details (such as browser incompatibilities) to your layout components, instead of having to deal with them in your reusable template text fragments. You build a component representing your layout and stick your other layout components in it. Then you reference your layout component from your general application pages. An example (and possibly not the best example) from a four-year-old Webobjects project. Note that WebObjects (and Tapestry as well from what I understand -- RenderBody?) both allow you to access the parent document content. It's unclear to me whether JSF is component-based enough to do this as I haven't built any components with it yet. (Someone asked me this question last week, and I haven't had time to find an answer yet.) When you use f:subview in JSF, the components defined in the dynamically included fragment (a tile, in the case of Tiles) are grafted in to the component tree of the parent page, so you can use getParent() recursively to access outer state. Is that what you meant? Component-based models allow you to do things differently, and I'm just wondering if you're dragging some old-school methodologies into it unnecessarily. Perhaps the answer is that there's no need to reinvent Tiles OR integrate Tiles. There are people who like both philosophies. Especially people that have existing Tiles based applications that they wish to port. It's not (yet) clear to me that Shale should only cater to one or the other approach. -Mike Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33998] New: - Some @link() tags are still there
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=33998. 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=33998 Summary: Some @link() tags are still there Product: Struts Version: 1.2.6 Beta Platform: All URL: http://struts.apache.org/api/org/apache/struts/action/Ac tionServlet.html OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: Documentation AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] ActionServlet javadoc contains three @link() tags in the final output, as can be seen in the URL above. When this report is submitted (March 14, 2005) the latest release is 1.2.6 so I assume this is the version on-line. There is only 1.2.6beta version in the bug submittion form so I mark it as the relevant version -- 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]
svn commit: r157394 - in struts/apps/trunk: examples/src/java/org/apache/struts/webapp/validator/LocaleAction.java shared/src/java/org/apache/struts/apps/mailreader/actions/LocaleAction.java
Author: martinc
Date: Sun Mar 13 22:00:29 2005
New Revision: 157394
URL: http://svn.apache.org/viewcvs?view=revrev=157394
Log:
Bugzilla #33998: Fix incorrect @link syntax.
Modified:
struts/apps/trunk/examples/src/java/org/apache/struts/webapp/validator/LocaleAction.java
struts/apps/trunk/shared/src/java/org/apache/struts/apps/mailreader/actions/LocaleAction.java
Modified:
struts/apps/trunk/examples/src/java/org/apache/struts/webapp/validator/LocaleAction.java
URL:
http://svn.apache.org/viewcvs/struts/apps/trunk/examples/src/java/org/apache/struts/webapp/validator/LocaleAction.java?view=diffr1=157393r2=157394
==
---
struts/apps/trunk/examples/src/java/org/apache/struts/webapp/validator/LocaleAction.java
(original)
+++
struts/apps/trunk/examples/src/java/org/apache/struts/webapp/validator/LocaleAction.java
Sun Mar 13 22:00:29 2005
@@ -37,7 +37,7 @@
/**
* Implementation of strongAction/strong that changes the user's
- * @link(java.util.Locale and forwards to a page, based on request level
+ * [EMAIL PROTECTED] java.util.Locale} and forwards to a page, based on
request level
* parameters that are set (language, country, amp; page).
*
*/
@@ -50,7 +50,7 @@
/**
* p
- * Change the user's @link(java.util.Locale) based on @link(ActionForm)
+ * Change the user's [EMAIL PROTECTED] java.util.Locale} based on [EMAIL
PROTECTED] ActionForm}
* properties.
* /p
* p
@@ -58,7 +58,7 @@
* codecountry/code properties on the given form, constructs an
* appropriate Locale object, and sets it as the Struts Locale for this
* user's session.
- * Any codeActionForm, including a @link(DynaActionForm), may be used.
+ * Any codeActionForm, including a [EMAIL PROTECTED] DynaActionForm},
may be used.
* /p
* p
* If a codepage/code property is also provided, then after
Modified:
struts/apps/trunk/shared/src/java/org/apache/struts/apps/mailreader/actions/LocaleAction.java
URL:
http://svn.apache.org/viewcvs/struts/apps/trunk/shared/src/java/org/apache/struts/apps/mailreader/actions/LocaleAction.java?view=diffr1=157393r2=157394
==
---
struts/apps/trunk/shared/src/java/org/apache/struts/apps/mailreader/actions/LocaleAction.java
(original)
+++
struts/apps/trunk/shared/src/java/org/apache/struts/apps/mailreader/actions/LocaleAction.java
Sun Mar 13 22:00:29 2005
@@ -30,7 +30,7 @@
/**
- * pChange user's Struts @link(java.util.Locale)./p
+ * pChange user's Struts [EMAIL PROTECTED] java.util.Locale}./p
*/
public final class LocaleAction extends BaseAction {
@@ -44,13 +44,13 @@
}
/**
- * pParameter for @link(java.util.Locale) language property.
+ * pParameter for [EMAIL PROTECTED] java.util.Locale} language property.
* [language]/p
*/
private static final String LANGUAGE = language ;
/**
- * pParameter for @link(java.util.Locale) country property.
+ * pParameter for [EMAIL PROTECTED] java.util.Locale} country property.
* [country]/p
*/
private static final String COUNTRY = country;
@@ -73,7 +73,7 @@
/**
* p
- * Change the user's Struts @link(java.util.Locale) based on request
+ * Change the user's Struts [EMAIL PROTECTED] java.util.Locale} based on
request
* parameters for language, country.
* After setting the Locale, control is forwarded to an URI path
* indicated by a page parameter, or a forward indicated by a
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r157395 - struts/core/trunk/src/share/org/apache/struts/action/ActionServlet.java struts/core/trunk/src/share/org/apache/struts/action/RequestProcessor.java struts/core/trunk/src/share/org/apache/struts/actions/LocaleAction.java
Author: martinc Date: Sun Mar 13 22:00:56 2005 New Revision: 157395 URL: http://svn.apache.org/viewcvs?view=revrev=157395 Log: Bugzilla #33998: Fix incorrect @link syntax. Modified: struts/core/trunk/src/share/org/apache/struts/action/ActionServlet.java struts/core/trunk/src/share/org/apache/struts/action/RequestProcessor.java struts/core/trunk/src/share/org/apache/struts/actions/LocaleAction.java Modified: struts/core/trunk/src/share/org/apache/struts/action/ActionServlet.java URL: http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/action/ActionServlet.java?view=diffr1=157394r2=157395 == --- struts/core/trunk/src/share/org/apache/struts/action/ActionServlet.java (original) +++ struts/core/trunk/src/share/org/apache/struts/action/ActionServlet.java Sun Mar 13 22:00:56 2005 @@ -90,9 +90,9 @@ * liThere can be bone/b instance of this servlet class, * which receives and processes all requests that change the state of * a user's interaction with the application. The servlet delegates the - * handling of a request to a @link(RequestProcessor) object. This component + * handling of a request to a [EMAIL PROTECTED] RequestProcessor} object. This component * represents the controller component of an MVC architecture./li - * liThe codeRequestProcessor/code selects and invokes an @link(Action) class to perform + * liThe codeRequestProcessor/code selects and invokes an [EMAIL PROTECTED] Action} class to perform * the requested business logic, or delegates the response to another resource./li * liThe codeAction/code classes can manipulate the state of the application's * interaction with the user, typically by creating or modifying JavaBeans @@ -100,7 +100,7 @@ * they need to be available). Such JavaBeans represent the model * component of an MVC architecture./li * liInstead of producing the next page of the user interface directly, - * codeAction/code classes generally return an @link(ActionForward) to indicate + * codeAction/code classes generally return an [EMAIL PROTECTED] ActionForward} to indicate * which resource should handle the response. If the codeAction/code * does not return null, the codeRequestProcessor/code forwards or * redirects to the specified resource (by utilizing Modified: struts/core/trunk/src/share/org/apache/struts/action/RequestProcessor.java URL: http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/action/RequestProcessor.java?view=diffr1=157394r2=157395 == --- struts/core/trunk/src/share/org/apache/struts/action/RequestProcessor.java (original) +++ struts/core/trunk/src/share/org/apache/struts/action/RequestProcessor.java Sun Mar 13 22:00:56 2005 @@ -43,7 +43,7 @@ /** * pstrongRequestProcessor/strong contains the processing logic that - * the @link(ActionServlet) performs as it receives each servlet request + * the [EMAIL PROTECTED] ActionServlet} performs as it receives each servlet request * from the container. You can customize the request processing behavior by * subclassing this class and overriding the method(s) whose behavior you are * interested in changing./p Modified: struts/core/trunk/src/share/org/apache/struts/actions/LocaleAction.java URL: http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/actions/LocaleAction.java?view=diffr1=157394r2=157395 == --- struts/core/trunk/src/share/org/apache/struts/actions/LocaleAction.java (original) +++ struts/core/trunk/src/share/org/apache/struts/actions/LocaleAction.java Sun Mar 13 22:00:56 2005 @@ -50,7 +50,7 @@ /** * p - * Change the user's @link(java.util.Locale) based on @link(ActionForm) + * Change the user's [EMAIL PROTECTED] java.util.Locale} based on [EMAIL PROTECTED] ActionForm} * properties. * /p * p @@ -58,7 +58,7 @@ * codecountry/code properties on the given form, constructs an * appropriate Locale object, and sets it as the Struts Locale for this * user's session. - * Any codeActionForm, including a @link(DynaActionForm), may be used. + * Any codeActionForm, including a [EMAIL PROTECTED] DynaActionForm}, may be used. * /p * p * If a codepage/code property is also provided, then after - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r157397 - in struts/core/branches/STRUTS_1_2_BRANCH/src: example/org/apache/struts/webapp/example/ examples/org/apache/struts/webapp/validator/ share/org/apache/struts/action/ share/org/apache/struts/actions/
Author: martinc
Date: Sun Mar 13 22:20:47 2005
New Revision: 157397
URL: http://svn.apache.org/viewcvs?view=revrev=157397
Log:
Bugzilla #33998: Fix incorrect @link syntax.
Modified:
struts/core/branches/STRUTS_1_2_BRANCH/src/example/org/apache/struts/webapp/example/LocaleAction.java
struts/core/branches/STRUTS_1_2_BRANCH/src/examples/org/apache/struts/webapp/validator/LocaleAction.java
struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/ActionServlet.java
struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/RequestProcessor.java
struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/actions/LocaleAction.java
Modified:
struts/core/branches/STRUTS_1_2_BRANCH/src/example/org/apache/struts/webapp/example/LocaleAction.java
URL:
http://svn.apache.org/viewcvs/struts/core/branches/STRUTS_1_2_BRANCH/src/example/org/apache/struts/webapp/example/LocaleAction.java?view=diffr1=157396r2=157397
==
---
struts/core/branches/STRUTS_1_2_BRANCH/src/example/org/apache/struts/webapp/example/LocaleAction.java
(original)
+++
struts/core/branches/STRUTS_1_2_BRANCH/src/example/org/apache/struts/webapp/example/LocaleAction.java
Sun Mar 13 22:20:47 2005
@@ -30,7 +30,7 @@
/**
- * pChange user's Struts @link(java.util.Locale)./p
+ * pChange user's Struts [EMAIL PROTECTED] java.util.Locale}./p
*/
public final class LocaleAction extends BaseAction {
@@ -44,13 +44,13 @@
}
/**
- * pParameter for @link(java.util.Locale) language property.
+ * pParameter for [EMAIL PROTECTED] java.util.Locale} language property.
* [language]/p
*/
private static final String LANGUAGE = language ;
/**
- * pParameter for @link(java.util.Locale) country property.
+ * pParameter for [EMAIL PROTECTED] java.util.Locale} country property.
* [country]/p
*/
private static final String COUNTRY = country;
@@ -73,7 +73,7 @@
/**
* p
- * Change the user's Struts @link(java.util.Locale) based on request
+ * Change the user's Struts [EMAIL PROTECTED] java.util.Locale} based on
request
* parameters for language, country.
* After setting the Locale, control is forwarded to an URI path
* indicated by a page parameter, or a forward indicated by a
Modified:
struts/core/branches/STRUTS_1_2_BRANCH/src/examples/org/apache/struts/webapp/validator/LocaleAction.java
URL:
http://svn.apache.org/viewcvs/struts/core/branches/STRUTS_1_2_BRANCH/src/examples/org/apache/struts/webapp/validator/LocaleAction.java?view=diffr1=157396r2=157397
==
---
struts/core/branches/STRUTS_1_2_BRANCH/src/examples/org/apache/struts/webapp/validator/LocaleAction.java
(original)
+++
struts/core/branches/STRUTS_1_2_BRANCH/src/examples/org/apache/struts/webapp/validator/LocaleAction.java
Sun Mar 13 22:20:47 2005
@@ -37,7 +37,7 @@
/**
* Implementation of strongAction/strong that changes the user's
- * @link(java.util.Locale and forwards to a page, based on request level
+ * [EMAIL PROTECTED] java.util.Locale} and forwards to a page, based on
request level
* parameters that are set (language, country, amp; page).
*
*/
@@ -50,7 +50,7 @@
/**
* p
- * Change the user's @link(java.util.Locale) based on @link(ActionForm)
+ * Change the user's [EMAIL PROTECTED] java.util.Locale} based on [EMAIL
PROTECTED] ActionForm}
* properties.
* /p
* p
@@ -58,7 +58,7 @@
* codecountry/code properties on the given form, constructs an
* appropriate Locale object, and sets it as the Struts Locale for this
* user's session.
- * Any codeActionForm, including a @link(DynaActionForm), may be used.
+ * Any codeActionForm, including a [EMAIL PROTECTED] DynaActionForm},
may be used.
* /p
* p
* If a codepage/code property is also provided, then after
Modified:
struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/ActionServlet.java
URL:
http://svn.apache.org/viewcvs/struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/ActionServlet.java?view=diffr1=157396r2=157397
==
---
struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/ActionServlet.java
(original)
+++
struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/ActionServlet.java
Sun Mar 13 22:20:47 2005
@@ -89,9 +89,9 @@
* liThere can be bone/b instance of this servlet class,
* which receives and processes all requests that change the state of
* a user's interaction with the application. The servlet delegates the
- * handling of a request to a @link(RequestProcessor) object. This
component
+ * handling of a request to a [EMAIL PROTECTED] RequestProcessor}
DO NOT REPLY [Bug 33998] - Some @link() tags are still there
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=33998. 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=33998 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 07:22 --- Fixed in both trunk and the 1.2.x branch. -- 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]
svn commit: r157398 - struts/core/trunk/src/share/org/apache/struts/action/Action.java
Author: martinc Date: Sun Mar 13 22:46:22 2005 New Revision: 157398 URL: http://svn.apache.org/viewcvs?view=revrev=157398 Log: Bugzilla #33876: Fix typos in Javadocs. Modified: struts/core/trunk/src/share/org/apache/struts/action/Action.java Modified: struts/core/trunk/src/share/org/apache/struts/action/Action.java URL: http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/action/Action.java?view=diffr1=157397r2=157398 == --- struts/core/trunk/src/share/org/apache/struts/action/Action.java (original) +++ struts/core/trunk/src/share/org/apache/struts/action/Action.java Sun Mar 13 22:46:22 2005 @@ -240,11 +240,10 @@ /** -* Adds the specified errors keys into the appropriate request -* attribute for use by the for use by the lt;html:errorsgt; tag, -* if any messages are required. -* Initialize the attribute if it has not already been. -* Otherwise, ensure that the request attribute is not set. +* Adds the specified errors keys into the appropriate request attribute + * for use by the lt;html:errorsgt; tag, if any messages are required. +* Initialize the attribute if it has not already been. Otherwise, ensure + * that the request attribute is not set. * * @param request The servlet request we are processing * @param errors Errors object @@ -422,7 +421,8 @@ /** * pReturn codetrue/code if there is a transaction token stored in * the user's current session, and the value submitted as a request - * parameter with this action matches it. Returns codefalse/code./p + * parameter with this action matches it. Returns codefalse/code under + * any of the following circumstances:/p * ul * liNo session associated with this request/li * liNo transaction token saved in the session/li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r157399 - struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/Action.java
Author: martinc Date: Sun Mar 13 22:46:54 2005 New Revision: 157399 URL: http://svn.apache.org/viewcvs?view=revrev=157399 Log: Bugzilla #33876: Fix typos in Javadocs. Modified: struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/Action.java Modified: struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/Action.java URL: http://svn.apache.org/viewcvs/struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/Action.java?view=diffr1=157398r2=157399 == --- struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/Action.java (original) +++ struts/core/branches/STRUTS_1_2_BRANCH/src/share/org/apache/struts/action/Action.java Sun Mar 13 22:46:54 2005 @@ -241,11 +241,10 @@ /** -* Adds the specified errors keys into the appropriate request -* attribute for use by the for use by the lt;html:errorsgt; tag, -* if any messages are required. -* Initialize the attribute if it has not already been. -* Otherwise, ensure that the request attribute is not set. +* Adds the specified errors keys into the appropriate request attribute + * for use by the lt;html:errorsgt; tag, if any messages are required. +* Initialize the attribute if it has not already been. Otherwise, ensure + * that the request attribute is not set. * * @param request The servlet request we are processing * @param errors Errors object @@ -309,9 +308,8 @@ * pReturn the specified data source for the current module./p * * @param request The servlet request we are processing - * @param key The key specified in the - * codelt;message-resourcesgt;/code element for the - * requested bundle + * @param key The key specified in the codelt;data-sourcesgt;/code + *element. * * @since Struts 1.1 */ @@ -459,7 +457,8 @@ /** * pReturn codetrue/code if there is a transaction token stored in * the user's current session, and the value submitted as a request - * parameter with this action matches it. Returns codefalse/code./p + * parameter with this action matches it. Returns codefalse/code under + * any of the following circumstances:/p * ul * liNo session associated with this request/li * liNo transaction token saved in the session/li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33876] - Javadoc typo (org.apache.struts.action.Action.java)
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=33876. 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=33876 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 07:47 --- Fixed in both trunk and the 1.2.x branch. -- 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 33511] - 1.2.4 validator.xml problems
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=33511. 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=33511 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 08:09 --- Closing due to lack of information. -- 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 33672] - struts-faces is incompatible with myfaces
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=33672. 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=33672 --- Additional Comments From [EMAIL PROTECTED] 2005-03-14 08:20 --- (In reply to comment #3) By the way, is the Incubator CVS still the place to get the latest MyFaces source code? yes, the infra@ guys are working on scripts for movement to own CVS ;) -- 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 33999] New: - [resources] move WriteTag.formatValue() to org.apache.commons.resources
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=33999. 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=33999 Summary: [resources] move WriteTag.formatValue() to org.apache.commons.resources Product: Commons Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Resources AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] CC: dev@struts.apache.org org.apache.struts.taglib.bean.WriteTag.formatValue() is an excellent method to format a (e.g. date) bean according to a locale. IMHO, the need for this is not limited to the jsp environment of the Struts-MVC, but e.g. once James becomes multilingual, its error messages could benefit from this as well. Therefore, I suggest to factor out the jsp related part and move the core functionality that will only be dependent on the Locale and the *MessageResources*, to org.apache.commons.resources. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsTraining
Date: 2005-03-13T23:59:28 Editor: EricSeynaeve Wiki: Apache Struts Wiki Page: StrutsTraining URL: http://wiki.apache.org/struts/StrutsTraining no comment Change Log: -- @@ -2,6 +2,9 @@ ''Trainers'': Please place in alphabetical order. +'''Belgium''' + * ABIS Training Consulting -- http://www.abis.be/ + '''Denmark''' * Lund Bendsen ApS -- http://www.lundogbendsen.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
