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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
