[ http://issues.apache.org/jira/browse/TAPESTRY-807?page=comments#action_12360608 ]
Alex Victoria commented on TAPESTRY-807: ---------------------------------------- Thanks. I guess I didn't find this issue because I had only searched for JDK 1.3 specific issues. > Tapestry 4.0 RC-1 Incompatible w/ Sun JDK 1.3.1 and IBM (WAS 5.0.1) JDK 1.31 > ----------------------------------------------------------------------------- > > Key: TAPESTRY-807 > URL: http://issues.apache.org/jira/browse/TAPESTRY-807 > Project: Tapestry > Type: Bug > Components: Framework > Versions: 4.0 > Environment: 1. IBM Websphere 5.0.1 (normal, not enterprise) on Windows XP > 2. Tomact 5.0.28 running on WAS 5.0.1 IBM JDK 1.3.1 on Windows XP > 3. Tomcat 5.0.28 tunning on SUN JDK 1.3.1_16 on Windows XP > Reporter: Alex Victoria > Assignee: Howard M. Lewis Ship > Priority: Blocker > > Tapestry initialization fails on JDK 1.3.1 because of the order in which the > ApplicationInitializer objects are loaded. I think this is because the > Hivemind Orderer class uses Hashmap and it seems to behave slightly > differently on JDK 1.3 vs. JDK 1.5.. The Hivemind Orderer class returns the > list of ApplicationInitializers in different orders depending on which VM I'm > using. The reason this is a Tapestry bug is because there is no ordering > enforced in the Hivemind XML files that define these two Initializers even > though there is an explicit dependency between them. Ultimately, we > shouldn't rely on Hashmap to always return things in the same order. Here's > details: > When running on JDK 1.5, the Initializers load in this order: > List: <SingletonProxy for > tapestry.init.WebContextInitializer(org.apache.tapestry.services.ApplicationInitializer)> > List: <SingletonProxy for > tapestry.init.ApplicationSpecificationInitializer(org.apache.tapestry.services.ApplicationInitializer)> > List: <SingletonProxy for > tapestry.globals.SetupServletApplicationGlobals(org.apache.tapestry.services.ApplicationInitializer)> > When running on JDK 1.3, the Initializers load in this order: > List: <SingletonProxy for > tapestry.init.WebContextInitializer(org.apache.tapestry.services.ApplicationInitializer)> > List: <SingletonProxy for > tapestry.globals.SetupServletApplicationGlobals(org.apache.tapestry.services.ApplicationInitializer)> > List: <SingletonProxy for > tapestry.init.ApplicationSpecificationInitializer(org.apache.tapestry.services.ApplicationInitializer)> > SetupServletApplicationGlobals has an explicit dependency on > ApplicationSpecificationInitializer because of the getActivatorName() method. > In the JDK 1.3 case, SetupServletApplicationGlobals attempts to access the > WebActivator on the Globals object but it is null because the > ApplicationSpecificInitializer hasn't run yet. > It seems like the propert solution is to explicitely define this dependency > in the Hivemind XML files that define ApplicationInitializers. > My quick workaround is here: > First, in my hivemodule.xml I had to redefine "ChainBuilder" like so: > <implementation service-id="hivemind.lib.ChainBuilder"> > <invoke-factory> > <construct class="AlexChainBuilder"> > <set-service property="classFactory" > service-id="hivemind.ClassFactory"/> > </construct> > </invoke-factory> > </implementation> > Then, I added my AlexChainBuilder implementation to HACK it to reorder the > Initializers before running. This isn't meant as a solution, but helped > prove the problem existed for me: > import java.util.Collections; > import java.util.Comparator; > import java.util.Iterator; > import java.util.List; > import org.apache.hivemind.lib.chain.ChainBuilderImpl; > import org.apache.tapestry.services.ApplicationInitializer; > public class AlexChainBuilder extends ChainBuilderImpl { > public Object buildImplementation(Class clazz, List list, String > string) { > if (clazz == ApplicationInitializer.class) { > System.out.println("AlexChainBuilder: Building: " + > clazz.getName()); > System.out.println( "AlexChainBuilder: HACK - resorting > application initializers" ); > for (Iterator i = list.iterator(); i.hasNext();) { > Object initer = (Object) i.next(); > System.out.println("AlexChainBuilder: PreSort > List: " + initer.toString()); > } > Collections.sort(list, new Comparator() { > public int compare(Object o1, Object o2) { > ApplicationInitializer a1 = > (ApplicationInitializer) o1; > ApplicationInitializer a2 = > (ApplicationInitializer) o2; > if > (a1.toString().indexOf("SetupServletApplicationGlobals") >= 0) { > return 1; > } > if > (a2.toString().indexOf("SetupServletApplicationGlobals") >= 0) { > return -1; > } > return 0; > } > }); > for (Iterator i = list.iterator(); i.hasNext();) { > Object initer = (Object) i.next(); > System.out.println("AlexChainBuilder: PostSort > List: " + initer.toString()); > } > } > return super.buildImplementation(clazz, list, string); > } > } > Is anyone running Tapestry 4.0-rc1 on Websphere 5.0.1? It seems from other > bugs on this list that there may be. Interestingly, the problem also occurs > with Tomcat and Sun 1.3.1_16, which leads me to believe that this is not > specific to Websphere but actually JDK 1.3.1 in general. Surely someone has > tried to run a Tapestry 4.0-rc1 app in Sun JDK1.3.1? Maybe not? > Thanks for you help resolving this issue. > Alex -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
