On 5/8/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
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
Yah, that is probably a compelling enough reason to make the change here as well, for consistency. 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.
OK, if it doesn't invalidate *all* of the 1.2 releases, then it's much less important to try to change this. "Upgrade to 1.2.9" is going to be much more palatable than "upgrade to 1.3.x" even after 1.3 goes GA. 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.
More precisely, it relies on 1.3 continuing to provide legacy support for the old RP approach :-). But your point is well taken -- the 1.3 version of the library should definitely be rearchitected to use CRP. I'll put in an RFE for that. Niall Craig
Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
