You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Matt Raible <mr...@gmail.com> on 2006/08/30 18:48:48 UTC
Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
I believe this is the correct forum, but if I should ask 2.0.0
questions on the user mailing list (or in IRC), please let me know.
I was successfully able to upgrade AppFuse from WW 2.2.2 to 2.2.3 w/o
any issues. I then tried to upgrade to Stuts 2.0.0 (from SVN) and had
the following issues:
1. WARN - XmlConfigurationProvider.verifyResultType(298) | Result
class [org.apache.struts2.views.jasperreports.JasperReportsResult]
doesn't exist (ClassNotFoundException) at result-type -
file:/opt/dev/Tools/jakarta-tomcat-5.0.28/work/Catalina/localhost/appfuse-struts/loader/struts-default.xml:23:108,
ignoring
java.lang.ClassNotFoundException:
org.apache.struts2.views.jasperreports.JasperReportsResult
I had to remove this reference in struts-default.xml for things to work.
Index: struts-default.xml
===================================================================
--- struts-default.xml (revision 438253)
+++ struts-default.xml (working copy)
@@ -20,8 +20,6 @@
<result-type name="plaintext"
class="org.apache.struts2.dispatcher.PlainTextResult" />
<!-- third party integration -->
- <result-type name="jasper"
class="org.apache.struts2.views.jasperreports.JasperReportsResult"/>
-
<result-type name="jsf"
class="org.apache.struts2.jsf.FacesResult" />
</result-types>
2. When I try to go to
http://localhost:8080/appfuse/uploadFile!default.html, I get the
following error:
Struts Problem Report
The Struts has detected an unhandled exception:
Messages: The default() is not defined in action class
org.appfuse.webapp.action.FileUploadAction
File: com/opensymphony/xwork2/DefaultActionInvocation.java
Line number: 337
Stacktraces
java.lang.IllegalArgumentException: The default() is not defined in
action class org.appfuse.webapp.action.FileUploadAction
I have the following in struts.properties:
struts.compatibilityMode.WebWork=true
As well as in FileUploadAction.java, I have:
public String doDefault() {
return INPUT;
}
Am I doing something wrong here? Should I enter these issues into JIRA?
Thanks,
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
If we are talking about the struts-extras JAR, then why not
encapsulate all this in an struts-extras package that people can
include when they include the extras JAR.
One of the remarkable things about Struts 2 is how easiy it is to add
your own interceptor or your own result. We should encourage people to
help themselves, and try to break out of the mindset that Struts is a
blackbox.
Distributing the Extras as an optional plugin, that is not directly
linked to the core, is an excellent opportunity to show people how
easy it is to extend Struts, without touching the original
distribution.
-Ted.
On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> I believe that Struts should work, out of the box, to require as little
> effort as possible. We want to make things easier right? Well, a good
> place to start is to build in functionality that can be used as easily
> as possible. This means:
>
> - To use Struts Extras features, just add the jar. No extra
> configuration/work required.
> - The default stack should do just about anything you need it to do.
> Only the most advanced users will need to create their own interceptors
> and stacks.
> - Custom struts.xml shouldn't be needed for most apps. By adopting
> Able-style conventions, a new user should be able to throw the Struts
> jar in, write an Action, and write a JSP. No need to read cryptic
> reference docs or learn new XML schemas to throw up a simple app.
>
> Sure, each of these things, by themselves, could be debated and aren't
> strictly necessary, but taken as a whole, they represent a significant
> effort to make development easy. It is that overarching vision that I
> think we are lacking here, choosing rather to debate all these minor
> features, which will result in a framework that reflects its confused
> development.
>
> Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Don Brown <mr...@twdata.org>.
I believe that Struts should work, out of the box, to require as little
effort as possible. We want to make things easier right? Well, a good
place to start is to build in functionality that can be used as easily
as possible. This means:
- To use Struts Extras features, just add the jar. No extra
configuration/work required.
- The default stack should do just about anything you need it to do.
Only the most advanced users will need to create their own interceptors
and stacks.
- Custom struts.xml shouldn't be needed for most apps. By adopting
Able-style conventions, a new user should be able to throw the Struts
jar in, write an Action, and write a JSP. No need to read cryptic
reference docs or learn new XML schemas to throw up a simple app.
Sure, each of these things, by themselves, could be debated and aren't
strictly necessary, but taken as a whole, they represent a significant
effort to make development easy. It is that overarching vision that I
think we are lacking here, choosing rather to debate all these minor
features, which will result in a framework that reflects its confused
development.
Don
Ted Husted wrote:
> On 8/30/06, Don Brown <mr...@twdata.org> wrote:
>> The jasper reports result _should_ be there,
>
> Why?
>
>> however, we do need to
>> reduce the warn message to perhaps an info. The idea is we should list
>> results that may not be available to make it easy to use the new results
>> when the struts-extras.jar is present.
>
> It's already easy to add new results to any package. I don't think we
> should go overboard by trying to bundle everything into the default
> package. People who use JSF or JasperReport results can just add them
> to their own package.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Don Brown <mr...@twdata.org>.
Yes, another good example of an area I need to revisit. I'll wrap these
two items up in a new ticket.
Don
Matt Raible wrote:
> On 8/30/06, Ted Husted <hu...@apache.org> wrote:
>> On 8/30/06, Don Brown <mr...@twdata.org> wrote:
>> > The jasper reports result _should_ be there,
>>
>> Why?
>>
>> > however, we do need to
>> > reduce the warn message to perhaps an info. The idea is we should
>> list
>> > results that may not be available to make it easy to use the new
>> results
>> > when the struts-extras.jar is present.
>>
>> It's already easy to add new results to any package. I don't think we
>> should go overboard by trying to bundle everything into the default
>> package. People who use JSF or JasperReport results can just add them
>> to their own package.
>
> I think it's OK that they're there, as long as users aren't *aware*
> they're there. Here's what I get in regards to JSF:
>
> WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable
> to load con
> fig class org.apache.struts2.jsf.FacesSetupInterceptor at interceptor
> - jar:file
> :/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/lib/strut
>
> s2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:54:97 probably due to a
> missing j
> ar, which might be fine if you never plan to use the jsfSetup interceptor
> WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable
> to load con
> fig class org.apache.struts2.jsf.RestoreViewInterceptor at interceptor
> - jar:fil
> e:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/lib/stru
>
> ts2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:55:100 probably due to
> a missing
> jar, which might be fine if you never plan to use the jsfRestore
> interceptor
> WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable
> to load con
> fig class org.apache.struts2.jsf.ApplyRequestValuesInterceptor at
> interceptor -
> jar:file:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/l
>
> ib/struts2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:56:105 probably
> due to a
> missing jar, which might be fine if you never plan to use the jsfApply
> intercept
> or
> WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable
> to load con
> fig class org.apache.struts2.jsf.ProcessValidationsInterceptor at
> interceptor -
> jar:file:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/l
>
> ib/struts2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:57:108 probably
> due to a
> missing jar, which might be fine if you never plan to use the
> jsfValidate interc
> eptor
> WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable
> to load con
> fig class org.apache.struts2.jsf.UpdateModelValuesInterceptor at
> interceptor - j
> ar:file:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/li
>
> b/struts2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:58:105 probably
> due to a m
> issing jar, which might be fine if you never plan to use the jsfUpdate
> intercept
> or
> WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable
> to load con
> fig class org.apache.struts2.jsf.InvokeApplicationInterceptor at
> interceptor - j
> ar:file:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/li
>
> b/struts2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:59:105 probably
> due to a m
> issing jar, which might be fine if you never plan to use the jsfInvoke
> intercept
> or
>
> I think it'd be best if I didn't have to add results to my struts.xml
> - I'd prefer that they're available when I add the appropriate
> dependencies (i.e. JasperReports or MyFaces). I'd be more than happy
> to see a warning if I tried to use one of these results and I didn't
> have the dependent JARs in my classpath.
>
> Matt
>>
>> -Ted.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Don Brown <mr...@twdata.org>.
Ted Husted wrote:
> If we are going to have optional result types, then let's have
> optional result types. Let's add an "optional" attribute, so that we
> can render more meaningful logging statements.
>
> 1 When optional=true, and the support class is absent, then nothing is
> logged.
>
> 2 When optional=true, and the support class is present, then a DEBUG
> logging statement saying the result is enabled is logged
>
> 3 When optional=false (the default), and the support class is absent,
> a runtime exception is logged and thrown (fail fast).
>
> 4 When optional=false, and the support class is present, then nothing
> is logged (the nominal case).
>
> Even if we mark a result type optional in the configuration, we can
> still override the setting in a package, so if we need to do a problem
> determination, we can add the result again as "optional=false" in a
> package, so that we can be sure the system sees the result, but not
> the JAR.
I like this idea. I'll to add the text to the JIRA ticket.
Don
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Bob Lee <cr...@crazybob.org>.
We should actually make it work like interceptors do: don't check for
the class until the user actually tries to use the result type. If the
user tries to use it and we don't have the class, don't just log a
warning: blow up with an exception.
Bob
On 8/30/06, Ted Husted <hu...@apache.org> wrote:
> In my experience, the easiest way to flatten the learning curve is consistency.
>
> Right now, our approach to default result types is inconsistent. Most
> results work out of the box, but some require people to add optional
> JARs to the distribution. For the "optional" results, we've started to
> add apologetic logging statements, saying "Oops, I'm here, but my JAR
> isn't, but you probably don't care anyway."
>
> If we are going to have optional result types, then let's have
> optional result types. Let's add an "optional" attribute, so that we
> can render more meaningful logging statements.
>
> 1 When optional=true, and the support class is absent, then nothing is logged.
>
> 2 When optional=true, and the support class is present, then a DEBUG
> logging statement saying the result is enabled is logged
>
> 3 When optional=false (the default), and the support class is absent,
> a runtime exception is logged and thrown (fail fast).
>
> 4 When optional=false, and the support class is present, then nothing
> is logged (the nominal case).
>
> Even if we mark a result type optional in the configuration, we can
> still override the setting in a package, so if we need to do a problem
> determination, we can add the result again as "optional=false" in a
> package, so that we can be sure the system sees the result, but not
> the JAR.
>
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> I guess what I'm saying here is that the Struts learning curve should be
> as flat as possible, allowing developers to ease into the framework
> without forcing them to learn about things like custom interceptors and
> results when they don't have the need for them.
In my experience, the easiest way to flatten the learning curve is consistency.
Right now, our approach to default result types is inconsistent. Most
results work out of the box, but some require people to add optional
JARs to the distribution. For the "optional" results, we've started to
add apologetic logging statements, saying "Oops, I'm here, but my JAR
isn't, but you probably don't care anyway."
If we are going to have optional result types, then let's have
optional result types. Let's add an "optional" attribute, so that we
can render more meaningful logging statements.
1 When optional=true, and the support class is absent, then nothing is logged.
2 When optional=true, and the support class is present, then a DEBUG
logging statement saying the result is enabled is logged
3 When optional=false (the default), and the support class is absent,
a runtime exception is logged and thrown (fail fast).
4 When optional=false, and the support class is present, then nothing
is logged (the nominal case).
Even if we mark a result type optional in the configuration, we can
still override the setting in a package, so if we need to do a problem
determination, we can add the result again as "optional=false" in a
package, so that we can be sure the system sees the result, but not
the JAR.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Don Brown <mr...@twdata.org>.
Matt Raible wrote:
> If you include MyFaces as a default dependency in pom.xml, I think
> users will wonder what the heck is going on.
MyFaces should be listed as an optional dependency, meaning its jars
aren't included in the distribution.
Don
>
> Matt
>
>>
>> Don
>>
>> Ted Husted wrote:
>> > On 8/30/06, Don Brown <mr...@twdata.org> wrote:
>> >> As I've said previously, I disagree. I think we should aim to
>> work 100%
>> >> out of the box.
>> >
>> > But, in the case of JSF and JasperReports, that's not an achievable
>> goal.
>> >
>> > We can't distribute JasperReports, and I don't think we want to start
>> > picking a JSF implementation for people. If they have to go to trouble
>> > of obtaining the JARs, they can add a results element to the package
>> > that uses the JAR.
>> >
>> > If we have to display a logging message as to why the result isn't
>> > working, it's better to leave out the result, and let the developer do
>> > his or her job.
>> >
>> > Again, we're talking about use case where it does not, and cannot,
>> > work 100% of the box.
>> >
>> >
>> >> By minimizing the amount of framework learning
>> >> developers have to go through to use Struts, we enable them to get
>> >> started quicker and spent more time figuring out how to solve more
>> >> important, business problems. Let's be honest - Struts is just
>> one more
>> >> library in probably 40 or 50 that they are using, we shouldn't assume
>> >> they have the time or interest to learn all about how it works.
>> >> Providing a library that "just works" shows we respect the
>> developer's
>> >> time. Personally, I hate open source libraries that assume I have
>> >> nothing better to do than learn their inner workings to make it do
>> the
>> >> most simple things.
>> >
>> > But, we are not talking about core functionality. We are talking about
>> > support for third-party libraries, outside of our normal purview.
>> >
>> >
>> >> > We can't distribute the JasperReports JAR, but in the case of JSF,
>> >> > this is an ideal opportunity to demonstrate plugging in a new
>> result
>> >> > via the showcase application.
>> >> The JSF support already has a section in the showcase application.
>> >
>> > Yes, and I added the JSF result to that package,.
>> >
>> > -Ted.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Matt Raible <mr...@gmail.com>.
On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> I think the bottom line is that you and I disagree on the fundamental
> issue on whether Struts should "just work" or whether it should
> encourage folks to "get to know it better".
>
> In this particular case, I feel since we provide the result in
> struts-extras, we should put the result configuration in the default
> configuration file. Therefore, all the user has to do is drop in the
> jasperreports jar and they can immediately use the result. This is
> especially important when they are using some sort of able-style
> autoconfiguration that doesn't require a struts.xml at all.
>
> In the JSF case, we should allow a user that wants to use JSF to get
> started immediately without any hassle. Sure, the more advanced user
> will want, down the road, to perhaps pick a different JSF
> implementation, and that's fine. However, for many beginning users, and
> even advanced ones at the start, we should work, out of the box, with as
> little extra effort as possible. Even for advanced users, this lets
> them not have to learn everything about Struts all up front, but as
> their needs for new interceptors or different JSF implementations come
> up, they will be able to learn and do what they need.
>
> I guess what I'm saying here is that the Struts learning curve should be
> as flat as possible, allowing developers to ease into the framework
> without forcing them to learn about things like custom interceptors and
> results when they don't have the need for them.
IMO, everything should be configured to use JasperReports and JSF
out-of-the-box. However, they won't be useable until the users
actually add the dependencies.
If you include MyFaces as a default dependency in pom.xml, I think
users will wonder what the heck is going on.
Matt
>
> Don
>
> Ted Husted wrote:
> > On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> >> As I've said previously, I disagree. I think we should aim to work 100%
> >> out of the box.
> >
> > But, in the case of JSF and JasperReports, that's not an achievable goal.
> >
> > We can't distribute JasperReports, and I don't think we want to start
> > picking a JSF implementation for people. If they have to go to trouble
> > of obtaining the JARs, they can add a results element to the package
> > that uses the JAR.
> >
> > If we have to display a logging message as to why the result isn't
> > working, it's better to leave out the result, and let the developer do
> > his or her job.
> >
> > Again, we're talking about use case where it does not, and cannot,
> > work 100% of the box.
> >
> >
> >> By minimizing the amount of framework learning
> >> developers have to go through to use Struts, we enable them to get
> >> started quicker and spent more time figuring out how to solve more
> >> important, business problems. Let's be honest - Struts is just one more
> >> library in probably 40 or 50 that they are using, we shouldn't assume
> >> they have the time or interest to learn all about how it works.
> >> Providing a library that "just works" shows we respect the developer's
> >> time. Personally, I hate open source libraries that assume I have
> >> nothing better to do than learn their inner workings to make it do the
> >> most simple things.
> >
> > But, we are not talking about core functionality. We are talking about
> > support for third-party libraries, outside of our normal purview.
> >
> >
> >> > We can't distribute the JasperReports JAR, but in the case of JSF,
> >> > this is an ideal opportunity to demonstrate plugging in a new result
> >> > via the showcase application.
> >> The JSF support already has a section in the showcase application.
> >
> > Yes, and I added the JSF result to that package,.
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Don Brown <mr...@twdata.org>.
I think the bottom line is that you and I disagree on the fundamental
issue on whether Struts should "just work" or whether it should
encourage folks to "get to know it better".
In this particular case, I feel since we provide the result in
struts-extras, we should put the result configuration in the default
configuration file. Therefore, all the user has to do is drop in the
jasperreports jar and they can immediately use the result. This is
especially important when they are using some sort of able-style
autoconfiguration that doesn't require a struts.xml at all.
In the JSF case, we should allow a user that wants to use JSF to get
started immediately without any hassle. Sure, the more advanced user
will want, down the road, to perhaps pick a different JSF
implementation, and that's fine. However, for many beginning users, and
even advanced ones at the start, we should work, out of the box, with as
little extra effort as possible. Even for advanced users, this lets
them not have to learn everything about Struts all up front, but as
their needs for new interceptors or different JSF implementations come
up, they will be able to learn and do what they need.
I guess what I'm saying here is that the Struts learning curve should be
as flat as possible, allowing developers to ease into the framework
without forcing them to learn about things like custom interceptors and
results when they don't have the need for them.
Don
Ted Husted wrote:
> On 8/30/06, Don Brown <mr...@twdata.org> wrote:
>> As I've said previously, I disagree. I think we should aim to work 100%
>> out of the box.
>
> But, in the case of JSF and JasperReports, that's not an achievable goal.
>
> We can't distribute JasperReports, and I don't think we want to start
> picking a JSF implementation for people. If they have to go to trouble
> of obtaining the JARs, they can add a results element to the package
> that uses the JAR.
>
> If we have to display a logging message as to why the result isn't
> working, it's better to leave out the result, and let the developer do
> his or her job.
>
> Again, we're talking about use case where it does not, and cannot,
> work 100% of the box.
>
>
>> By minimizing the amount of framework learning
>> developers have to go through to use Struts, we enable them to get
>> started quicker and spent more time figuring out how to solve more
>> important, business problems. Let's be honest - Struts is just one more
>> library in probably 40 or 50 that they are using, we shouldn't assume
>> they have the time or interest to learn all about how it works.
>> Providing a library that "just works" shows we respect the developer's
>> time. Personally, I hate open source libraries that assume I have
>> nothing better to do than learn their inner workings to make it do the
>> most simple things.
>
> But, we are not talking about core functionality. We are talking about
> support for third-party libraries, outside of our normal purview.
>
>
>> > We can't distribute the JasperReports JAR, but in the case of JSF,
>> > this is an ideal opportunity to demonstrate plugging in a new result
>> > via the showcase application.
>> The JSF support already has a section in the showcase application.
>
> Yes, and I added the JSF result to that package,.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> As I've said previously, I disagree. I think we should aim to work 100%
> out of the box.
But, in the case of JSF and JasperReports, that's not an achievable goal.
We can't distribute JasperReports, and I don't think we want to start
picking a JSF implementation for people. If they have to go to trouble
of obtaining the JARs, they can add a results element to the package
that uses the JAR.
If we have to display a logging message as to why the result isn't
working, it's better to leave out the result, and let the developer do
his or her job.
Again, we're talking about use case where it does not, and cannot,
work 100% of the box.
> By minimizing the amount of framework learning
> developers have to go through to use Struts, we enable them to get
> started quicker and spent more time figuring out how to solve more
> important, business problems. Let's be honest - Struts is just one more
> library in probably 40 or 50 that they are using, we shouldn't assume
> they have the time or interest to learn all about how it works.
> Providing a library that "just works" shows we respect the developer's
> time. Personally, I hate open source libraries that assume I have
> nothing better to do than learn their inner workings to make it do the
> most simple things.
But, we are not talking about core functionality. We are talking about
support for third-party libraries, outside of our normal purview.
> > We can't distribute the JasperReports JAR, but in the case of JSF,
> > this is an ideal opportunity to demonstrate plugging in a new result
> > via the showcase application.
> The JSF support already has a section in the showcase application.
Yes, and I added the JSF result to that package,.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Don Brown <mr...@twdata.org>.
Ted Husted wrote:
> On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
>> I think it'd be best if I didn't have to add results to my struts.xml
>
> Why?
>
> I think one of the biggest problems we have in enterprise web
> development today is that everyone expects everything to come out of
> the box. We should encourage people to write their own results when
> needed and to plugin in special-purpose results as needed.
As I've said previously, I disagree. I think we should aim to work 100%
out of the box. By minimizing the amount of framework learning
developers have to go through to use Struts, we enable them to get
started quicker and spent more time figuring out how to solve more
important, business problems. Let's be honest - Struts is just one more
library in probably 40 or 50 that they are using, we shouldn't assume
they have the time or interest to learn all about how it works.
Providing a library that "just works" shows we respect the developer's
time. Personally, I hate open source libraries that assume I have
nothing better to do than learn their inner workings to make it do the
most simple things.
>
> We can't distribute the JasperReports JAR, but in the case of JSF,
> this is an ideal opportunity to demonstrate plugging in a new result
> via the showcase application.
The JSF support already has a section in the showcase application.
Don
>
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
> I think it'd be best if I didn't have to add results to my struts.xml
Why?
I think one of the biggest problems we have in enterprise web
development today is that everyone expects everything to come out of
the box. We should encourage people to write their own results when
needed and to plugin in special-purpose results as needed.
We can't distribute the JasperReports JAR, but in the case of JSF,
this is an ideal opportunity to demonstrate plugging in a new result
via the showcase application.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Matt Raible <mr...@gmail.com>.
On 8/30/06, Ted Husted <hu...@apache.org> wrote:
> On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> > The jasper reports result _should_ be there,
>
> Why?
>
> > however, we do need to
> > reduce the warn message to perhaps an info. The idea is we should list
> > results that may not be available to make it easy to use the new results
> > when the struts-extras.jar is present.
>
> It's already easy to add new results to any package. I don't think we
> should go overboard by trying to bundle everything into the default
> package. People who use JSF or JasperReport results can just add them
> to their own package.
I think it's OK that they're there, as long as users aren't *aware*
they're there. Here's what I get in regards to JSF:
WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable to load con
fig class org.apache.struts2.jsf.FacesSetupInterceptor at interceptor - jar:file
:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/lib/strut
s2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:54:97 probably due to a missing j
ar, which might be fine if you never plan to use the jsfSetup interceptor
WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable to load con
fig class org.apache.struts2.jsf.RestoreViewInterceptor at interceptor - jar:fil
e:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/lib/stru
ts2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:55:100 probably due to a missing
jar, which might be fine if you never plan to use the jsfRestore interceptor
WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable to load con
fig class org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
jar:file:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/l
ib/struts2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:56:105 probably due to a
missing jar, which might be fine if you never plan to use the jsfApply intercept
or
WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable to load con
fig class org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
jar:file:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/l
ib/struts2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:57:108 probably due to a
missing jar, which might be fine if you never plan to use the jsfValidate interc
eptor
WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable to load con
fig class org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor - j
ar:file:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/li
b/struts2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:58:105 probably due to a m
issing jar, which might be fine if you never plan to use the jsfUpdate intercept
or
WARN - InterceptorBuilder.constructInterceptorReference(59) | Unable to load con
fig class org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor - j
ar:file:/Users/mraible/Work/appfuse/web/struts-war/target/work/webapp/WEB-INF/li
b/struts2-core-2.0.0-SNAPSHOT.jar!/struts-default.xml:59:105 probably due to a m
issing jar, which might be fine if you never plan to use the jsfInvoke intercept
or
I think it'd be best if I didn't have to add results to my struts.xml
- I'd prefer that they're available when I add the appropriate
dependencies (i.e. JasperReports or MyFaces). I'd be more than happy
to see a warning if I tried to use one of these results and I didn't
have the dependent JARs in my classpath.
Matt
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> The jasper reports result _should_ be there,
Why?
> however, we do need to
> reduce the warn message to perhaps an info. The idea is we should list
> results that may not be available to make it easy to use the new results
> when the struts-extras.jar is present.
It's already easy to add new results to any package. I don't think we
should go overboard by trying to bundle everything into the default
package. People who use JSF or JasperReport results can just add them
to their own package.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Matt Raible <mr...@gmail.com>.
On 8/31/06, Ted Husted <hu...@apache.org> wrote:
> On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> > Yeah, overriding themes is a big ticket that needs to be addressed.
>
> What about individual tags?
>
> I had understood that we could override an individual template by
> including a replacement at the base of the classpath. But when I try
> that with something like
>
> <#if (actionErrors?exists && actionErrors?size > 0)>
> <table>
> <#list actionErrors as error>
> <strong><tr><td></strong><span
> class="errorMessage">${error}</span><strong></td></tr></strong>
> </#list>
> </table>
> </#if>
>
> It seems to be ignored.
>
> Is it suppose to be recognized?
I don't think it's at the base of the classpath, I believe it's in the
"template" directory. I have this directory in my webapp, but it may
work at the classpath root as well. For example:
src/main/webapp/template/xhtml/file.ftl
Matt
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
Never mind. I needed to add to appropriate "package" too. It's working
like a charm.
On 8/31/06, Ted Husted <hu...@apache.org> wrote:
> On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> > Yeah, overriding themes is a big ticket that needs to be addressed.
>
> What about individual tags?
>
> I had understood that we could override an individual template by
> including a replacement at the base of the classpath. But when I try
> that with something like
>
> <#if (actionErrors?exists && actionErrors?size > 0)>
> <table>
> <#list actionErrors as error>
> <strong><tr><td></strong><span
> class="errorMessage">${error}</span><strong></td></tr></strong>
> </#list>
> </table>
> </#if>
>
> It seems to be ignored.
>
> Is it suppose to be recognized?
>
> -Ted.
>
--
HTH, Ted.
* http://www.husted.com/struts/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> Yeah, overriding themes is a big ticket that needs to be addressed.
What about individual tags?
I had understood that we could override an individual template by
including a replacement at the base of the classpath. But when I try
that with something like
<#if (actionErrors?exists && actionErrors?size > 0)>
<table>
<#list actionErrors as error>
<strong><tr><td></strong><span
class="errorMessage">${error}</span><strong></td></tr></strong>
</#list>
</table>
</#if>
It seems to be ignored.
Is it suppose to be recognized?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Don Brown <mr...@twdata.org>.
Yeah, overriding themes is a big ticket that needs to be addressed. The
bottom line is you have to ensure, manually, all the content from the
original template is in the new one.
While WW also suffers this overriding problem, the reason you are seeing
it in Struts is that we had to remove the tooltip, editor, and calendar
Javascript widgets from WW and replace them with non-LGPL versions. We
chose to use Dojo, and therefore, dojo is now required for those tags.
Don
Matt Raible wrote:
> On 8/30/06, Don Brown <mr...@apache.org> wrote:
>> ATM, Dojo is required for the XHtml theme, due to its use in tooltips
>> and several other features. The head tag should inject the proper dojo
>> setup script elements.
>
> Hmmm, I've customized a couple of the FreeMarker templates for both
> xhtml and css_xhtml. I'm assuming I'm not overriding something
> properly?
>
> https://appfuse.dev.java.net/svn/appfuse/trunk/web/struts-war/src/main/webapp/template/
>
>
> It worked in WW. ;-)
>
> Matt
>
>>
>> Don
>>
>> Matt Raible wrote:
>> > I tried renaming my doDefault() to start() and changing my URL to:
>> >
>> > http://localhost:8080/appfuse-struts-war/uploadFile!start.html
>> >
>> > ... and it works.
>> >
>> > Now I'm onto a new issue - it seems like Dojo is getting included at
>> > the bottom of my signup form.
>> >
>> > <!-- javascript that is needed for tooltips -->
>> > <script language="JavaScript"
>> >
>> type="text/javascript">dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");</script>
>>
>> >
>> >
>> > This results in the following error in my Canoo WebTest:
>> >
>> > Signup:
>> >
>> > BUILD FAILED
>> > /Users/mraible/Work/appfuse-webwork/build.xml:585: The following error
>> > occurred while executing this line:
>> > /Users/mraible/Work/appfuse-webwork/test/web/web-tests.xml:160: Canoo
>> > Webtest: R_1263.
>> > Test failed.
>> > Test step invoke
>> > (/Users/mraible/Work/appfuse-webwork/test/web/web-tests.xml:166: )
>> > named "click signup link" failed with message "Step[invoke "click
>> > signup link" (2/19)]: Script error loading page executing webtest at:
>> > invoke TypeError: Cannot call method "require" of null (Embedded
>> > script in http://localhost:8080/appfuse-struts-war/signup.html#1)
>> > Source code:
>> >
>> dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");"
>> >
>> > Total time: 11 seconds
>> >
>> > Is this something that's new in Struts 2.0.0? Do I need to include
>> > Dojo includes in my <head>?
>> >
>> > Thanks,
>> >
>> > Matt
>> >
>> >
>> > On 8/30/06, Ted Husted <hu...@apache.org> wrote:
>> >> Thanks, Matt. I've added both points to the release notes.
>> >>
>> >> Let us know if you find anything else.
>> >>
>> >> -Ted.
>> >>
>> >> On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
>> >> > I think it's fine to refactor, as long as it's documented.
>> Currently,
>> >> > it's not listed on the release notes.
>> >> >
>> >> > http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.0
>> >> >
>> >> > Another item missing is the need to rename com.opensymphony.xwork
>> >> > references to com.opensymphony.xwork2.
>> >> >
>> >> > Matt
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Matt Raible <mr...@gmail.com>.
On 8/30/06, Don Brown <mr...@apache.org> wrote:
> ATM, Dojo is required for the XHtml theme, due to its use in tooltips
> and several other features. The head tag should inject the proper dojo
> setup script elements.
Hmmm, I've customized a couple of the FreeMarker templates for both
xhtml and css_xhtml. I'm assuming I'm not overriding something
properly?
https://appfuse.dev.java.net/svn/appfuse/trunk/web/struts-war/src/main/webapp/template/
It worked in WW. ;-)
Matt
>
> Don
>
> Matt Raible wrote:
> > I tried renaming my doDefault() to start() and changing my URL to:
> >
> > http://localhost:8080/appfuse-struts-war/uploadFile!start.html
> >
> > ... and it works.
> >
> > Now I'm onto a new issue - it seems like Dojo is getting included at
> > the bottom of my signup form.
> >
> > <!-- javascript that is needed for tooltips -->
> > <script language="JavaScript"
> > type="text/javascript">dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");</script>
> >
> >
> > This results in the following error in my Canoo WebTest:
> >
> > Signup:
> >
> > BUILD FAILED
> > /Users/mraible/Work/appfuse-webwork/build.xml:585: The following error
> > occurred while executing this line:
> > /Users/mraible/Work/appfuse-webwork/test/web/web-tests.xml:160: Canoo
> > Webtest: R_1263.
> > Test failed.
> > Test step invoke
> > (/Users/mraible/Work/appfuse-webwork/test/web/web-tests.xml:166: )
> > named "click signup link" failed with message "Step[invoke "click
> > signup link" (2/19)]: Script error loading page executing webtest at:
> > invoke TypeError: Cannot call method "require" of null (Embedded
> > script in http://localhost:8080/appfuse-struts-war/signup.html#1)
> > Source code:
> > dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");"
> >
> > Total time: 11 seconds
> >
> > Is this something that's new in Struts 2.0.0? Do I need to include
> > Dojo includes in my <head>?
> >
> > Thanks,
> >
> > Matt
> >
> >
> > On 8/30/06, Ted Husted <hu...@apache.org> wrote:
> >> Thanks, Matt. I've added both points to the release notes.
> >>
> >> Let us know if you find anything else.
> >>
> >> -Ted.
> >>
> >> On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
> >> > I think it's fine to refactor, as long as it's documented. Currently,
> >> > it's not listed on the release notes.
> >> >
> >> > http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.0
> >> >
> >> > Another item missing is the need to rename com.opensymphony.xwork
> >> > references to com.opensymphony.xwork2.
> >> >
> >> > Matt
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Don Brown <mr...@apache.org>.
ATM, Dojo is required for the XHtml theme, due to its use in tooltips
and several other features. The head tag should inject the proper dojo
setup script elements.
Don
Matt Raible wrote:
> I tried renaming my doDefault() to start() and changing my URL to:
>
> http://localhost:8080/appfuse-struts-war/uploadFile!start.html
>
> ... and it works.
>
> Now I'm onto a new issue - it seems like Dojo is getting included at
> the bottom of my signup form.
>
> <!-- javascript that is needed for tooltips -->
> <script language="JavaScript"
> type="text/javascript">dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");</script>
>
>
> This results in the following error in my Canoo WebTest:
>
> Signup:
>
> BUILD FAILED
> /Users/mraible/Work/appfuse-webwork/build.xml:585: The following error
> occurred while executing this line:
> /Users/mraible/Work/appfuse-webwork/test/web/web-tests.xml:160: Canoo
> Webtest: R_1263.
> Test failed.
> Test step invoke
> (/Users/mraible/Work/appfuse-webwork/test/web/web-tests.xml:166: )
> named "click signup link" failed with message "Step[invoke "click
> signup link" (2/19)]: Script error loading page executing webtest at:
> invoke TypeError: Cannot call method "require" of null (Embedded
> script in http://localhost:8080/appfuse-struts-war/signup.html#1)
> Source code:
> dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");"
>
> Total time: 11 seconds
>
> Is this something that's new in Struts 2.0.0? Do I need to include
> Dojo includes in my <head>?
>
> Thanks,
>
> Matt
>
>
> On 8/30/06, Ted Husted <hu...@apache.org> wrote:
>> Thanks, Matt. I've added both points to the release notes.
>>
>> Let us know if you find anything else.
>>
>> -Ted.
>>
>> On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
>> > I think it's fine to refactor, as long as it's documented. Currently,
>> > it's not listed on the release notes.
>> >
>> > http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.0
>> >
>> > Another item missing is the need to rename com.opensymphony.xwork
>> > references to com.opensymphony.xwork2.
>> >
>> > Matt
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
I opened WW-1425 to cover the incomplete or unnecessary dojo references.
* https://issues.apache.org/struts/browse/WW-1425
-T.
On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
> Now I'm onto a new issue - it seems like Dojo is getting included at
> the bottom of my signup form.
>
> <!-- javascript that is needed for tooltips -->
> <script language="JavaScript"
> type="text/javascript">dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");</script>
>
> This results in the following error in my Canoo WebTest:
>
> Signup:
>
> BUILD FAILED
> /Users/mraible/Work/appfuse-webwork/build.xml:585: The following error
> occurred while executing this line:
> /Users/mraible/Work/appfuse-webwork/test/web/web-tests.xml:160: Canoo
> Webtest: R_1263.
> Test failed.
> Test step invoke
> (/Users/mraible/Work/appfuse-webwork/test/web/web-tests.xml:166: )
> named "click signup link" failed with message "Step[invoke "click
> signup link" (2/19)]: Script error loading page executing webtest at:
> invoke TypeError: Cannot call method "require" of null (Embedded
> script in http://localhost:8080/appfuse-struts-war/signup.html#1)
> Source code:
> dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");"
>
> Total time: 11 seconds
>
> Is this something that's new in Struts 2.0.0? Do I need to include
> Dojo includes in my <head>?
>
> Thanks,
>
> Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Matt Raible <mr...@gmail.com>.
I tried renaming my doDefault() to start() and changing my URL to:
http://localhost:8080/appfuse-struts-war/uploadFile!start.html
... and it works.
Now I'm onto a new issue - it seems like Dojo is getting included at
the bottom of my signup form.
<!-- javascript that is needed for tooltips -->
<script language="JavaScript"
type="text/javascript">dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");</script>
This results in the following error in my Canoo WebTest:
Signup:
BUILD FAILED
/Users/mraible/Work/appfuse-webwork/build.xml:585: The following error
occurred while executing this line:
/Users/mraible/Work/appfuse-webwork/test/web/web-tests.xml:160: Canoo
Webtest: R_1263.
Test failed.
Test step invoke
(/Users/mraible/Work/appfuse-webwork/test/web/web-tests.xml:166: )
named "click signup link" failed with message "Step[invoke "click
signup link" (2/19)]: Script error loading page executing webtest at:
invoke TypeError: Cannot call method "require" of null (Embedded
script in http://localhost:8080/appfuse-struts-war/signup.html#1)
Source code:
dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");"
Total time: 11 seconds
Is this something that's new in Struts 2.0.0? Do I need to include
Dojo includes in my <head>?
Thanks,
Matt
On 8/30/06, Ted Husted <hu...@apache.org> wrote:
> Thanks, Matt. I've added both points to the release notes.
>
> Let us know if you find anything else.
>
> -Ted.
>
> On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
> > I think it's fine to refactor, as long as it's documented. Currently,
> > it's not listed on the release notes.
> >
> > http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.0
> >
> > Another item missing is the need to rename com.opensymphony.xwork
> > references to com.opensymphony.xwork2.
> >
> > Matt
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
Thanks, Matt. I've added both points to the release notes.
Let us know if you find anything else.
-Ted.
On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
> I think it's fine to refactor, as long as it's documented. Currently,
> it's not listed on the release notes.
>
> http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.0
>
> Another item missing is the need to rename com.opensymphony.xwork
> references to com.opensymphony.xwork2.
>
> Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Matt Raible <mr...@gmail.com>.
On 8/30/06, Ted Husted <hu...@apache.org> wrote:
> On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> > Yes, this is true - we removed support for do* methods. Perhaps in this
> > one case, however, we should allow a doDefault method. Create a ticket
> > for it. Perhaps do* support itself should be put back in, but only be
> > enabled when in compatibility mode.
>
> I don't know. We don't want to retain support for this WW1-ism
> indefinately. Ultimately, people are going to need to refactor
> application that use "default" and "do", if they want to stay current
> with the latest release.
>
> Why not get it over with and do it now, while everything else is being renamed?
I think it's fine to refactor, as long as it's documented. Currently,
it's not listed on the release notes.
http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.0
Another item missing is the need to rename com.opensymphony.xwork
references to com.opensymphony.xwork2.
Matt
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
On 8/30/06, Don Brown <mr...@twdata.org> wrote:
> Yes, this is true - we removed support for do* methods. Perhaps in this
> one case, however, we should allow a doDefault method. Create a ticket
> for it. Perhaps do* support itself should be put back in, but only be
> enabled when in compatibility mode.
I don't know. We don't want to retain support for this WW1-ism
indefinately. Ultimately, people are going to need to refactor
application that use "default" and "do", if they want to stay current
with the latest release.
Why not get it over with and do it now, while everything else is being renamed?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Don Brown <mr...@twdata.org>.
Matt Raible wrote:
> On 8/30/06, Ted Husted <hu...@apache.org> wrote:
>> On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
>> > I believe this is the correct forum,
>>
>> Yep.
>>
>> > I had to remove this reference in struts-default.xml for things to
>> work.
>>
>> Thanks, I removed that in r438570, so don't bother with a ticket.
>
> I just did an update on core/src/main/resources/struts-default.xml and
> it's still there:
>
> <result-type name="jasper"
> class="org.apache.struts2.views.jasperreports.JasperReportsResult"/>
>
> ...
> U core/src/main/resources/struts-default.xml
> Updated to revision 438573.
The jasper reports result _should_ be there, however, we do need to
reduce the warn message to perhaps an info. The idea is we should list
results that may not be available to make it easy to use the new results
when the struts-extras.jar is present.
>
>>
>> > struts.compatibilityMode.WebWork=true
>>
>> If you update to the current head, or tomorrow morning's nighly JAR,
>> you can remove this setting now.
>>
>
> What does it do?
>
>> > Messages: The default() is not defined in action class
>> > org.appfuse.webapp.action.FileUploadAction
>>
>> Is there a default method in that class?
>
> No, there's a doDefault() method - which worked fine with WebWork.
> default is a keyword, so I can't have a default() method. I can try
> renaming my method, but it seems that backwards compatibility has been
> broken.
Yes, this is true - we removed support for do* methods. Perhaps in this
one case, however, we should allow a doDefault method. Create a ticket
for it. Perhaps do* support itself should be put back in, but only be
enabled when in compatibility mode.
Don
>
>
>>
>> Did that used to map to execute or something in WW? If so, it doesn't
>> anymore, and we need to add that to the release notes.
>
> Yes, using !methodName in WW delegated to doMethodName(). Is the "do"
> prefix deprecated or simply not implemented?
>
> Matt
>
>>
>> -Ted.
>>
>> On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
>> > I believe this is the correct forum, but if I should ask 2.0.0
>> > questions on the user mailing list (or in IRC), please let me know.
>> >
>> > I was successfully able to upgrade AppFuse from WW 2.2.2 to 2.2.3 w/o
>> > any issues. I then tried to upgrade to Stuts 2.0.0 (from SVN) and had
>> > the following issues:
>> >
>> > 1. WARN - XmlConfigurationProvider.verifyResultType(298) | Result
>> > class [org.apache.struts2.views.jasperreports.JasperReportsResult]
>> > doesn't exist (ClassNotFoundException) at result-type -
>> >
>> file:/opt/dev/Tools/jakarta-tomcat-5.0.28/work/Catalina/localhost/appfuse-struts/loader/struts-default.xml:23:108,
>>
>> > ignoring
>> > java.lang.ClassNotFoundException:
>> > org.apache.struts2.views.jasperreports.JasperReportsResult
>> >
>> > I had to remove this reference in struts-default.xml for things to
>> work.
>> >
>> > Index: struts-default.xml
>> > ===================================================================
>> > --- struts-default.xml (revision 438253)
>> > +++ struts-default.xml (working copy)
>> > @@ -20,8 +20,6 @@
>> > <result-type name="plaintext"
>> > class="org.apache.struts2.dispatcher.PlainTextResult" />
>> >
>> > <!-- third party integration -->
>> > - <result-type name="jasper"
>> > class="org.apache.struts2.views.jasperreports.JasperReportsResult"/>
>> > -
>> > <result-type name="jsf"
>> > class="org.apache.struts2.jsf.FacesResult" />
>> > </result-types>
>> >
>> > 2. When I try to go to
>> > http://localhost:8080/appfuse/uploadFile!default.html, I get the
>> > following error:
>> >
>> > Struts Problem Report
>> >
>> > The Struts has detected an unhandled exception:
>> > Messages: The default() is not defined in action class
>> > org.appfuse.webapp.action.FileUploadAction
>> > File: com/opensymphony/xwork2/DefaultActionInvocation.java
>> > Line number: 337
>> > Stacktraces
>> > java.lang.IllegalArgumentException: The default() is not defined in
>> > action class org.appfuse.webapp.action.FileUploadAction
>> >
>> > I have the following in struts.properties:
>> >
>> > struts.compatibilityMode.WebWork=true
>> >
>> > As well as in FileUploadAction.java, I have:
>> >
>> > public String doDefault() {
>> > return INPUT;
>> > }
>> >
>> > Am I doing something wrong here? Should I enter these issues into
>> JIRA?
>> >
>> > Thanks,
>> >
>> > Matt
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>> --
>> HTH, Ted.
>> * http://www.husted.com/struts/
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Matt Raible <mr...@gmail.com>.
On 8/30/06, Ted Husted <hu...@apache.org> wrote:
> On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
> > I believe this is the correct forum,
>
> Yep.
>
> > I had to remove this reference in struts-default.xml for things to work.
>
> Thanks, I removed that in r438570, so don't bother with a ticket.
I just did an update on core/src/main/resources/struts-default.xml and
it's still there:
<result-type name="jasper"
class="org.apache.struts2.views.jasperreports.JasperReportsResult"/>
...
U core/src/main/resources/struts-default.xml
Updated to revision 438573.
>
> > struts.compatibilityMode.WebWork=true
>
> If you update to the current head, or tomorrow morning's nighly JAR,
> you can remove this setting now.
>
What does it do?
> > Messages: The default() is not defined in action class
> > org.appfuse.webapp.action.FileUploadAction
>
> Is there a default method in that class?
No, there's a doDefault() method - which worked fine with WebWork.
default is a keyword, so I can't have a default() method. I can try
renaming my method, but it seems that backwards compatibility has been
broken.
>
> Did that used to map to execute or something in WW? If so, it doesn't
> anymore, and we need to add that to the release notes.
Yes, using !methodName in WW delegated to doMethodName(). Is the "do"
prefix deprecated or simply not implemented?
Matt
>
> -Ted.
>
> On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
> > I believe this is the correct forum, but if I should ask 2.0.0
> > questions on the user mailing list (or in IRC), please let me know.
> >
> > I was successfully able to upgrade AppFuse from WW 2.2.2 to 2.2.3 w/o
> > any issues. I then tried to upgrade to Stuts 2.0.0 (from SVN) and had
> > the following issues:
> >
> > 1. WARN - XmlConfigurationProvider.verifyResultType(298) | Result
> > class [org.apache.struts2.views.jasperreports.JasperReportsResult]
> > doesn't exist (ClassNotFoundException) at result-type -
> > file:/opt/dev/Tools/jakarta-tomcat-5.0.28/work/Catalina/localhost/appfuse-struts/loader/struts-default.xml:23:108,
> > ignoring
> > java.lang.ClassNotFoundException:
> > org.apache.struts2.views.jasperreports.JasperReportsResult
> >
> > I had to remove this reference in struts-default.xml for things to work.
> >
> > Index: struts-default.xml
> > ===================================================================
> > --- struts-default.xml (revision 438253)
> > +++ struts-default.xml (working copy)
> > @@ -20,8 +20,6 @@
> > <result-type name="plaintext"
> > class="org.apache.struts2.dispatcher.PlainTextResult" />
> >
> > <!-- third party integration -->
> > - <result-type name="jasper"
> > class="org.apache.struts2.views.jasperreports.JasperReportsResult"/>
> > -
> > <result-type name="jsf"
> > class="org.apache.struts2.jsf.FacesResult" />
> > </result-types>
> >
> > 2. When I try to go to
> > http://localhost:8080/appfuse/uploadFile!default.html, I get the
> > following error:
> >
> > Struts Problem Report
> >
> > The Struts has detected an unhandled exception:
> > Messages: The default() is not defined in action class
> > org.appfuse.webapp.action.FileUploadAction
> > File: com/opensymphony/xwork2/DefaultActionInvocation.java
> > Line number: 337
> > Stacktraces
> > java.lang.IllegalArgumentException: The default() is not defined in
> > action class org.appfuse.webapp.action.FileUploadAction
> >
> > I have the following in struts.properties:
> >
> > struts.compatibilityMode.WebWork=true
> >
> > As well as in FileUploadAction.java, I have:
> >
> > public String doDefault() {
> > return INPUT;
> > }
> >
> > Am I doing something wrong here? Should I enter these issues into JIRA?
> >
> > Thanks,
> >
> > Matt
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
> HTH, Ted.
> * http://www.husted.com/struts/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Posted by Ted Husted <hu...@apache.org>.
On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
> I believe this is the correct forum,
Yep.
> I had to remove this reference in struts-default.xml for things to work.
Thanks, I removed that in r438570, so don't bother with a ticket.
> struts.compatibilityMode.WebWork=true
If you update to the current head, or tomorrow morning's nighly JAR,
you can remove this setting now.
> Messages: The default() is not defined in action class
> org.appfuse.webapp.action.FileUploadAction
Is there a default method in that class?
Did that used to map to execute or something in WW? If so, it doesn't
anymore, and we need to add that to the release notes.
-Ted.
On 8/30/06, Matt Raible <mr...@gmail.com> wrote:
> I believe this is the correct forum, but if I should ask 2.0.0
> questions on the user mailing list (or in IRC), please let me know.
>
> I was successfully able to upgrade AppFuse from WW 2.2.2 to 2.2.3 w/o
> any issues. I then tried to upgrade to Stuts 2.0.0 (from SVN) and had
> the following issues:
>
> 1. WARN - XmlConfigurationProvider.verifyResultType(298) | Result
> class [org.apache.struts2.views.jasperreports.JasperReportsResult]
> doesn't exist (ClassNotFoundException) at result-type -
> file:/opt/dev/Tools/jakarta-tomcat-5.0.28/work/Catalina/localhost/appfuse-struts/loader/struts-default.xml:23:108,
> ignoring
> java.lang.ClassNotFoundException:
> org.apache.struts2.views.jasperreports.JasperReportsResult
>
> I had to remove this reference in struts-default.xml for things to work.
>
> Index: struts-default.xml
> ===================================================================
> --- struts-default.xml (revision 438253)
> +++ struts-default.xml (working copy)
> @@ -20,8 +20,6 @@
> <result-type name="plaintext"
> class="org.apache.struts2.dispatcher.PlainTextResult" />
>
> <!-- third party integration -->
> - <result-type name="jasper"
> class="org.apache.struts2.views.jasperreports.JasperReportsResult"/>
> -
> <result-type name="jsf"
> class="org.apache.struts2.jsf.FacesResult" />
> </result-types>
>
> 2. When I try to go to
> http://localhost:8080/appfuse/uploadFile!default.html, I get the
> following error:
>
> Struts Problem Report
>
> The Struts has detected an unhandled exception:
> Messages: The default() is not defined in action class
> org.appfuse.webapp.action.FileUploadAction
> File: com/opensymphony/xwork2/DefaultActionInvocation.java
> Line number: 337
> Stacktraces
> java.lang.IllegalArgumentException: The default() is not defined in
> action class org.appfuse.webapp.action.FileUploadAction
>
> I have the following in struts.properties:
>
> struts.compatibilityMode.WebWork=true
>
> As well as in FileUploadAction.java, I have:
>
> public String doDefault() {
> return INPUT;
> }
>
> Am I doing something wrong here? Should I enter these issues into JIRA?
>
> Thanks,
>
> Matt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted.
* http://www.husted.com/struts/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org