On 5/8/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 5/8/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
> The struts-faces-example2 app is not initializing when deployed, failing
> on a ClassNotFoundException for the MyFaces startup class. In turn, this is
> because the MyFaces implementation library ( myfaces-impl-1.0.9.jar) is
> not being included in the WEB-INF/lib directory (as it is on the first
> example app). I'll see if I can fix this, if no one else beats me to it.
> Looks like it's probably a missing dependency in the POM, because there are
> a few other missing JAR files that the MyFaces impl would be declaring.
>
I had some time to do further digging in on this one, and have made some
progress (I'm at the JAX conference, but my talks are all tomorrow and most
of the sessions today are in German, which does me little good :-).
I've got a patch prepared (see below) that cleans up most of the issues. In
brief, it does the following:
* Restore FacesTilesRequestProcessor.java to the build,
after making processValidate() throw InvalidCancelException
(see below for more on this issue).
* Correct dependency issues in the pom.xml for the second example.
* Correct references to the tiles TLD file to use the canonical
URL (but there's an outstanding problem here).
* Correct struts-config.xml to load the internal copies of the
validator-rules.xml resource.
* Make struts-tiles a compile time dependency for faces.
I can commit these to the trunk anytime it won't disrupt trying to get a
release out. However, these changes do not completely address everything.
The second faces example will still fail, for at least two reasons:
* The missing DTD files in struts-tiles-xxx.jar that Jurgen Zimmerman
reported.
* The fact that META-INF/tld/struts-tiles.tld is *also* missing from this
jar file. It looks like Maven's resource copying process is not
recursive by default, so perhaps it's missing this due to the nested "tld"
directory?
The only problem I have with the attached patch is the change to the
processValidate() method signature -- adding InvalidCancelException as a
*checked* exception makes it impossible to write a single version of the
struts-faces library that supports both 1.2 and 1.3. Worst case, we can
probably branch the "faces" sources and create a variant that works there
(potentially acceptable because the "faces" library hasn't ever had a GA
release) -- but would you guys also consider making this an unchecked
exception instead of a checked exception? That way, it would not need to be
added to the throws clause, and wouldn't break compilation on
FacesTilesRequestProcessor.
Firstly FacesRequestProcessor has had the InvalidCancelException added
to the processValidate() method signature, so you probably want to
consider that as well:
http://svn.apache.org/viewcvs.cgi?rev=392070&view=rev
The problem is that Struts 1.2.9 has been released with the
processValidate() method declaring the InvalidCancelException
exception. This does at least mean that if you do add
InvalidCancelException to the method signature then it can be used
with 1.2.9+ versions. If not and you still think changing it to an
unchecked exception is the best approach, then it would need a new
1.2.x release. The only solution I can see that accomodates all
versions though is to remove the implementation of the
processValidate() method from the faces RP implementations - since all
they do is debug logging - this would seem a good approach IMO.
Maybe a bigger issue though is that faces doesn't really support 1.3
at all - since it relies on the existing RP - rather than providing a
set of Commands to plug into the ComposableRequestProcessor.
Niall
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
