On 12/24/06, Dale Newfield <[EMAIL PROTECTED]> wrote:
Ted Husted wrote:
> I cleared out the logs and restarted the server.

Thank you.  What version of struts is running there now?

The latest release, which is 2.0.1 beta.


> Of course, if anyone is doing more than browsing the examples, the
> best thing is to deploy the WARs from the struts-apps distribution,
> and study them at leisure on localhost.

That works fine for 2.0.1, but I'm using an svn checkout in order to use
2.0.2-SNAPSHOT.

It's not the nightly build anyway.


My attempts to build this war seem to have failed, and
I've found no documentation for how to do so.

Change to the showcase source directory and run mvn install

It builds the WAR under target.


While the quickstart
route is still documented, I don't believe that is functional any longer.

Quickstart is being being superceded by the jetty plugin, but I don't
use either one myself.

* https://issues.apache.org/struts/browse/WW-1524


In apps/showcase I run "mvn war:war", copy then copy
target/struts2-showcase.war to tomcat's webapps directory, then start
tomcat.  It unpacks the war and then fails to start the webapp, and I've
been unable to get any better logs than the following to tell me why:

INFO: Deploying web application archive struts2-showcase.war
Dec 23, 2006 1:02:59 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
Dec 23, 2006 1:02:59 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/struts2-showcase] startup failed due to previous errors

Is "mvn war:war" in the showcase directory the correct way to build that
war?  Is this known to work with Tomcat/5.5.20?

I've lost basically the last week and a half trying to get a single form
working that contains a datepicker, a timepicker, some checkboxes, and a
file upload (each of which have caused separate problems).  I am now
using 2.0.2 because I could not get it to work with 2.0.1, but I've
never gotten the datepicker or timepicker widgets working.  Is there
something I should know about them, or about what must be done to set up
dojo?

I'm not using these tags myself, so I can' t be of any help. The best
thing is to post the code you are working on to the user list so that
others can be of more help.

There's an open issue that suggest reverting the 2.0.2 datepicker,
which I may try to apply today.

* https://issues.apache.org/struts/browse/WW-1555



For example, while I would rather not have to make changes to struts to
get it to work, I got much farther (but still don't succeed) after
making the following one character change:

Actually, we'd prefer people did make changes to Struts to make it
work or make it work better, and then donate back the patches. :)
We're all working-stiffs here, just like you.

If the datepickers works better for your with the trwithout the
trailing slash, then post a patch. It does seem to be broken in the
2.0.1 beta, since the picker doesn't go away after selecting a field.

Also, don't be afraid to use other solutions. If the Struts 2.0.1
datepicker doesn't work, I expect that there are many others out there
that would. It is not our intention for people to treat Struts like a
blackbox and use only whatever happens to be in the distribution.

And, honestly, if someone doesn't fix the datepicker tag soon, it's
not going to be in the GA distirbution anyway.



> Index: core/src/main/resources/template/simple/head.ftl
> ===================================================================
> --- core/src/main/resources/template/simple/head.ftl    (revision 489708)
> +++ core/src/main/resources/template/simple/head.ftl    (working copy)
> @@ -1,7 +1,7 @@
>  <script language="JavaScript" type="text/javascript">
>      // Dojo configuration
>      djConfig = {
> -        baseRelativePath: "<@s.url includeParams='none' value='/struts/dojo' 
includeParams="none" encode='false'/>",
> +        baseRelativePath: "<@s.url includeParams='none' value='/struts/dojo/' 
includeParams="none" encode='false'/>",
>          isDebug: ${parameters.debug?default(false)},
>          bindEncoding: "${parameters.encoding}",
>          debugAtAllCosts: true // not needed, but allows the Venkman debugger 
to work with the includes

Any advice about where I'm going wrong would be appreciated.

I'm sure there are a number of snippets from configuration files that
might help diagnose--let me know what would help...

Thanks in Advance!

-Dale Newfield
  [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to