Thanks very much for your answer Joe. Details below.
Joe Germuska wrote:
I'll cvs update today.My other questions still stand.
1. is someone actively working on that code right now ?
2. does someone have struts-chain installed and configured correctly ?
from where did you get it ? Any caveats for the build ?
4. I used maven to build struts: the maven dist target's result differs
significantly from ant's dist, and contrib/struts-chain makes some
assumptions about what's 2 levels above that are not met by the maven build.
This is whay I had to use a nightly build.
is there a way to generate jakarta-struts's build.properties from maven ?-)
As a matter of fact, yes, I've put in a few patches to struts-chain over the last couple of weeks. Specifically last night I committed a change to struts-chain which will now require the newest nightly build of Struts (2004/01/19 or later) -- this is to more correctly support declarative exception handling for superclasses of the thrown exception. I also recently put in support for Tiles, although that is not in the default chain-config.xml
So yes, in doing this, I have been using a struts-chain installation. I built from CVS, and of course, i'm using Struts itself also built from CVS. It works fine. I'm running it under Tomcat 4.1.29, but I doubt that makes a difference.I use tomcat 4.1.29 as well. I agree it should not make a difference anyway.
It's true that because the build.xml for struts-chain relies on the Ant build of Struts, it would be fairly tedious to get it to work the way it is now using Struts built only with Maven.
You can't generate the Struts build.properties from Maven, but it might be helpful for us to put in a version of build.properties.sample based on defining your maven repository home and then computing the paths to all of the jars based on that.
I'll try to do that: this may indeed be the easiest short term way of solving this ant/maven problem.
I can send you my build.properties privately if you want a head start on that. Of course, it would be better to rewrite the struts-chain build to explicitly identify the JARs it needs, when time allows.
I'm not sure this would be better.
Mavenizing struts-chain would be the best, but then with how maven is currently operating, you would need to explicitly declare all dependencies in struts-chain, thus duplicating struts dependencies in this subproject.
My colleague Alejandro Abdelnur, whom I CC here, has a very interesting maven enhancement proposal to solve that kind of issue: enhance the resolver to determine dependencies in a transitive way.
Today maven's resolver resolves inter-project dependencies for the multiproject plugin just for ordering the build. This goes one step further and will allow for one subproject to reuse the dependencies of a project it depends on.
My initial reaction to Alejandro's proposal was not very enthusiastic, since you want to be able to build a project in isolation.
But struts-chain, which you can build only in the context of an existing stuts build is a perfect use case for this.
The example here will be:
struts-chain depends on struts, thus it will add all the dependencies from struts automatically.
He has a working prototype that I will try with struts-chain, to see if this flies.
If you take my build.properties, change the maven repository path, and do "ant dist" in the Struts CVS root, you may have an easier time building struts-chain.I got struts-chain to build using a nightly build instead of my maven local build, but the example app still does not work.
I'm going to have a go at this build.properties and build everything locally from a fresh cvs update.
The problem you identified with the example struts-config.xml may not be the only one; I tried using that a bit when I was working on getting Chain installed, and ended up finding it easier to just put the ComposableRequestProcessor in the app I was working on rather than getting it working with the struts-chain example app. If you have the time to fix up the struts-config.xml to work correctly, patches would be gratefully accepted. (Preferably attached to a bugzilla entry.)I'll send a patch when I succeed in making that stuff work.
So my understanding is that the current struts-config.xml in struts-chain is out of sync with the struts example application, and you work with a different web application to test your work.
Do I understand right ?
The changes I made in struts-nightly struts-config.xml to use the ComposableRequestProcessor are:
modify original struts-example struts-config.xml to add just the chains related stuff
<!-- P@ <controller pagePattern="$M$P" inputForward="true" /> -->
<!-- pagePattern: use this pattern when creating URIs to resources.
$M=module, $P=path -->
<!-- inputForward: The "input" parameter on "action" elements is the name of a
local or global "forward" rather than a module-relative path -->
<controller>
<!-- The "input" parameter on "action" elements is the name of a
local or global "forward" rather than a module-relative path -->
<set-property property="inputForward" value="true"/>
<!-- Use the composable request processor implementation -->
<set-property
property="processorClass"
value="org.apache.struts.chain.legacy.ComposableRequestProcessor"/>
</controller>
<!-- P@ -->
<!-- Configure the command chains to be used -->
<plug-in className="org.apache.struts.chain.legacy.CatalogConfiguratorPlugIn">
<set-property
property="resource"
value="org/apache/struts/chain/chain-config.xml"/>
</plug-in>
When I do that I get the welcome page but all links go to blank pages. Did I miss something ? Could you please send me in a private email: - the war you use to test struts-chain - your build.properties
Thanks very much for your help.
P@
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
