You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Alex Victoria (JIRA)" <ta...@jakarta.apache.org> on 2005/12/16 00:49:45 UTC
[jira] Commented: (TAPESTRY-807) Tapestry 4.0 RC-1 Incompatible w/ Sun JDK 1.3.1 and IBM (WAS 5.0.1) JDK 1.31
[ http://issues.apache.org/jira/browse/TAPESTRY-807?page=comments#action_12360540 ]
Alex Victoria commented on TAPESTRY-807:
----------------------------------------
NOTE: Also, i'm using Hivemind 1.1-RC1. I also noticed another 1.3 issue with its use of StringBuffer... perhaps this has been fixed in 1.1. I will double check.
> 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
> 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org