Thanks Craig I can confirm that shale-remoting works fine without the other Shale components in Glassfish. As a work around, I've stripped things down to just using shale-remoting-1.0.3.jar and a few of the commons classes in the shale distribution. Dojo calls using shale remoting seem to work fine with the following added to our classpath:
SERVER_CLASSPATH=$SERVER_CLASSPATH:$SHALE_HOME/lib/shale-remoting-1.0.3. jar:$SHALE_HOME/lib/commons-chain-1.1.jar:$SHALE_HOME/lib/commons-lang-2 .1.jar:$SHALE_HOME/lib/commons-collections-3.1.jar:$SHALE_HOME/lib/commo ns-digester-1.7.jar:$SHALE_HOME/lib/commons-beanutils-1.7.0.jar So, our current work around is to only use remoting at this time. But we'll track progress on the 1.2 work. Thanks Robert > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Craig McClanahan > Sent: Wednesday, October 04, 2006 5:09 PM > To: [email protected] > Subject: Re: Shale incompatibility with Glassfish > > On 10/4/06, Cyril Bouteille <[EMAIL PROTECTED]> wrote: > > > > Hi Craig, > > Is there anything you could recommend us to try or any > information we > > could provide you to help figure out the incompatibility with the > > latest glassfish v1 JSF implementation? > > > I'm running into a challenge trying to test this ... the > shale-test framework doesn't yet support JSF 1.2 APIs. It > turns out that Trinidad (the ADF Faces components that are > incubating and will end up in the MyFaces > project) have the same need, so I'm going to take a whack at > updating the test classes first, so these problems can be > debugged more easily. > > Also, as a temp workaround for us, is it safe/ok to use remoting w/o > > shale-core in our classpath? It seems to work... > > > That should work fine if you only need the remoting features > -- remoting only depends on Commons Logging (and JSF, of course). > > Craig > > Thanks, > > > > Craig McClanahan wrote: > > > On 10/3/06, Paul Tabor <[EMAIL PROTECTED]> wrote: > > >> > > >> There appears to be at least two issues with the current > > >> incarnation of Shale with Glassfish v1ur1b12, b13, b14 / JSF > > >> 1.2_02-b03-FCS. This problem has been verified with Shale 1.0.2, > > >> 1.0.3, and nightly build 20060926. > > >> > > >> 1) f:param's and jsp:param's do not get passed to the request > > >> parameters. > > >> > > >> 2) c:forEach appears to be broken when using a deferred > value for > > >> the items attribute. The iteration works fine with Tomahawk > > >> t:dataList and with a standard h:dataTable. > > >> > > >> In both cases, the problems persist if the > shale-core.jar is on the > > >> classpath. If we remove the shale-core.jar from our > classpath, the > > >> c:forEach and f:param/jsp:param work fine. > > >> > > >> Would this have something to do with Shale's use of ValueBinding > > >> versus JSF 1.2's ValueExpression? > > > > > > > > > From our experience with JSF 1.2 in Creator, I suspect this isn't > > > the problem area ... the backwards compatibility seems to > be quite good. > > > I do > > > suspect that this has sometthing to do with the changes > in the way > > > that the component tree is prebuilt (for JSP views) in JSF 1.2, > > > versus the way they were built as the components were rendered in > > > JSF 1.1. That's going to take some research to untangle. > > > > > > Craig > > > > > > > >
