[ http://issues.apache.org/jira/browse/TAPESTRY-807?page=all ]
Howard M. Lewis Ship resolved TAPESTRY-807:
-------------------------------------------
Resolution: Duplicate
Assign To: Howard M. Lewis Ship
Again, great research.
> 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]
