Uploaded image for project: 'Click'
  1. Click
  2. CLK-293

click-examples from 1.4-RC2 not works on x86_64 linux distribution

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: examples
    • Labels:
      None
    • Environment:
      Linux, OpenSUSE 10.3, AMD64, JDK1.5.0_14, Tomcat 6.0.14, click-1.4-RC2

      Description

      click-examples.war not works on Linux Java 1.5 AMD64.
      Tomcats's log (catalina.out) see below:
      23.01.2008 22:18:07 org.apache.catalina.core.AprLifecycleListener init
      INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /home/vic/bin/jdk1.5.0_14/jre/lib/amd64/server:/home/vic/bin/jdk1.5.0_14/jre/lib/amd64:/home/vic/bin/jdk1.5.0_14/jre/../lib/amd64
      23.01.2008 22:18:07 org.apache.coyote.http11.Http11Protocol init
      INFO: Initializing Coyote HTTP/1.1 on http-8080
      23.01.2008 22:18:07 org.apache.catalina.startup.Catalina load
      INFO: Initialization processed in 650 ms
      23.01.2008 22:18:08 org.apache.catalina.core.StandardService start
      INFO: Starting service Catalina
      23.01.2008 22:18:08 org.apache.catalina.core.StandardEngine start
      INFO: Starting Servlet Engine: Apache Tomcat/6.0.14
      [INFO ] [net.sf.click.extras.cayenne.DataContextFilter] DataContextFilter initialized with: auto-rollback=true, session-scope=false, shared-cache=true
      java.lang.ExceptionInInitializerError
      at java.lang.Class.forName0(Native Method)
      at java.lang.Class.forName(Class.java:242)
      at net.sf.click.util.ClickUtils.classForName(ClickUtils.java:443)
      at net.sf.click.ClickApp.deployControls(ClickApp.java:684)
      at net.sf.click.ClickApp.deployFiles(ClickApp.java:740)
      at net.sf.click.ClickApp.init(ClickApp.java:288)
      at net.sf.click.ClickServlet.init(ClickServlet.java:229)
      at net.sf.click.extras.spring.SpringClickServlet.init(SpringClickServlet.java:267)
      at javax.servlet.GenericServlet.init(GenericServlet.java:212)
      at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1161)
      at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981)
      at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4045)
      at org.apache.catalina.core.StandardContext.start(StandardContext.java:4351)
      at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
      at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
      at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
      at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
      at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
      at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
      at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
      at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
      at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
      at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
      at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
      at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
      at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
      at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
      at org.apache.catalina.core.StandardService.start(StandardService.java:516)
      at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
      at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:585)
      at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
      at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
      Caused by: java.util.MissingResourceException: Can't find bundle for base name click-control, locale ru_RU
      at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:836)
      at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:805)
      at java.util.ResourceBundle.getBundle(ResourceBundle.java:549)
      at net.sf.click.control.Form.<clinit>(Form.java:519)
      ... 35 more
      23.01.2008 22:18:11 org.apache.coyote.http11.Http11Protocol start
      INFO: Starting Coyote HTTP/1.1 on http-8080
      23.01.2008 22:18:11 org.apache.jk.common.ChannelSocket init
      INFO: JK: ajp13 listening on /0.0.0.0:8009
      23.01.2008 22:18:11 org.apache.jk.server.JkMain start
      INFO: Jk running ID=0 time=0/27 config=null
      23.01.2008 22:18:11 org.apache.catalina.startup.Catalina start
      INFO: Server startup in 3770 ms

      But on x86(i386) distribution works fine.

      P.S some other progs (e.g zkdemo - demo of zkoss.org framework) works well on my AMD64 configuration

        Activity

        Hide
        medgar Malcolm Edgar added a comment -

        Fix will be available in release 1.4-RC3

        Show
        medgar Malcolm Edgar added a comment - Fix will be available in release 1.4-RC3
        Hide
        medgar Malcolm Edgar added a comment -

        Bob, yes was thinking about this as well. We need to standardize on our use of classloaders for accessing resources and creating new class instances. I copied this null check concept from the JDK code, in reality I an not sure if we need it at all. If we can't get the classloader from the current Thread I think we are pretty well screwed.

        If click JARs are not stored in the WEB-INF/lib directory, but in a global app server lib directory, and if the current thread classloader returns null, and we resort to Clicks classloader, it is unlikely that it would be able to access the applications Page classes and resources.

        regards Malcolm Edgar

        Show
        medgar Malcolm Edgar added a comment - Bob, yes was thinking about this as well. We need to standardize on our use of classloaders for accessing resources and creating new class instances. I copied this null check concept from the JDK code, in reality I an not sure if we need it at all. If we can't get the classloader from the current Thread I think we are pretty well screwed. If click JARs are not stored in the WEB-INF/lib directory, but in a global app server lib directory, and if the current thread classloader returns null, and we resort to Clicks classloader, it is unlikely that it would be able to access the applications Page classes and resources. regards Malcolm Edgar
        Hide
        sabob Bob Schellink added a comment -

        Malcolm, it seems using the detault ClassLoader for bundles caused the issue.

        Btw I notice in ClickUtils#getBundle that you check if ContextClassLoader is null and then resort to systemClassLoader. Perhaps the following will work better?

        if (classLoader == null) {
        classLoader = ClickUtils.class.getClassLoader();
        }

        This will retrieve the current ClassLoader which loaded the ClickUtils class. The current ClassLoader's parent (or further up the hierarchy) will be the SystemClassLoader anyway.

        Could it be that some containers will not set the Thread's contextClassLoader. Probably So checking if classLoader is null and fallback to a default classLoader seems like good backup plan.

        Perhaps we can have a private method ClickUtils#getClassLoader which encapsulates classLoader retrieval?

        Show
        sabob Bob Schellink added a comment - Malcolm, it seems using the detault ClassLoader for bundles caused the issue. Btw I notice in ClickUtils#getBundle that you check if ContextClassLoader is null and then resort to systemClassLoader. Perhaps the following will work better? if (classLoader == null) { classLoader = ClickUtils.class.getClassLoader(); } This will retrieve the current ClassLoader which loaded the ClickUtils class. The current ClassLoader's parent (or further up the hierarchy) will be the SystemClassLoader anyway. Could it be that some containers will not set the Thread's contextClassLoader. Probably So checking if classLoader is null and fallback to a default classLoader seems like good backup plan. Perhaps we can have a private method ClickUtils#getClassLoader which encapsulates classLoader retrieval?
        Hide
        sabob Bob Schellink added a comment -

        Hi Victor

        Thanks alot for your help testing this issue!

        Would be good to know if it works on Centos too.

        kind regards

        bob

        Show
        sabob Bob Schellink added a comment - Hi Victor Thanks alot for your help testing this issue! Would be good to know if it works on Centos too. kind regards bob
        Hide
        victor72 Victor added a comment -

        Thanks

        The examples, builded from svn-source, works now with Jetty and Tomcat 6 on x86_64 OpenSUSE10.3.
        Later, i can try run it on Centos 5 x86_64.

        victor

        Show
        victor72 Victor added a comment - Thanks The examples, builded from svn-source, works now with Jetty and Tomcat 6 on x86_64 OpenSUSE10.3. Later, i can try run it on Centos 5 x86_64. victor
        Hide
        sabob Bob Schellink added a comment -

        Hi Victor,

        The easiest would be to grab the latest source from svn. Here are the steps you can follow:

        #1 Create a directory somewhere

        prompt> mkdir /tmp/click-svn

        #2 Grab source from svn

        prompt> svn co https://click.svn.sourceforge.net/svnroot/click/trunk/click click

        #3 After the download finish, Click source will be available here -> '/tmp/click-svn/click'

        #4 Navigate to 'tmp/click-svn/click/build' and type:

        ant get-deps

        #5 After the all dependencies have been downloaded you can build click:

        ant build-all

        #6 Click jars will be available here -> 'tmp/click-svn/click/dist'

        #7 On subsequent builds you can simply repeat #2 and #5.

        kind regards

        bob

        Show
        sabob Bob Schellink added a comment - Hi Victor, The easiest would be to grab the latest source from svn. Here are the steps you can follow: #1 Create a directory somewhere prompt> mkdir /tmp/click-svn #2 Grab source from svn prompt> svn co https://click.svn.sourceforge.net/svnroot/click/trunk/click click #3 After the download finish, Click source will be available here -> '/tmp/click-svn/click' #4 Navigate to 'tmp/click-svn/click/build' and type: ant get-deps #5 After the all dependencies have been downloaded you can build click: ant build-all #6 Click jars will be available here -> 'tmp/click-svn/click/dist' #7 On subsequent builds you can simply repeat #2 and #5. kind regards bob
        Hide
        victor72 Victor added a comment -

        Yes, i can test it.
        From where can i take these fixes?

        Show
        victor72 Victor added a comment - Yes, i can test it. From where can i take these fixes?
        Hide
        medgar Malcolm Edgar added a comment -

        Potential fix checked in. Victor can you build and test this fix in your environment?

        regards Malcolm Edgar

        Show
        medgar Malcolm Edgar added a comment - Potential fix checked in. Victor can you build and test this fix in your environment? regards Malcolm Edgar
        Hide
        medgar Malcolm Edgar added a comment -

        Hi Bob,

        Yes, the alternative method for loading resources, sounds like the first thing to test here.

        regards Malcolm Edgar

        Show
        medgar Malcolm Edgar added a comment - Hi Bob, Yes, the alternative method for loading resources, sounds like the first thing to test here. regards Malcolm Edgar
        Hide
        medgar Malcolm Edgar added a comment -

        Hi Victor,

        If we can supply some builds to fix this issue, can you test them on your environment?

        regards Malcolm Edgar

        Show
        medgar Malcolm Edgar added a comment - Hi Victor, If we can supply some builds to fix this issue, can you test them on your environment? regards Malcolm Edgar
        Hide
        sabob Bob Schellink added a comment -

        It looks like the Form is loaded by the Thread's contextClassLoader, which triggers the static block in Form to load resources. But the bundle cannot be found.

        I wonder if the above will work if a bundle called click-control_ru_RU.properties is added to the classpath?

        Another thing we can look at is to replace ResourceBundle#getBundle(String) with ResourceBundle#getBundle(String, Locale, ClassLoader) and supply the Threads contextClassLoader.

        ResourceBundle#getBundle(String) uses the current classLoader.

        Show
        sabob Bob Schellink added a comment - It looks like the Form is loaded by the Thread's contextClassLoader, which triggers the static block in Form to load resources. But the bundle cannot be found. I wonder if the above will work if a bundle called click-control_ru_RU.properties is added to the classpath? Another thing we can look at is to replace ResourceBundle#getBundle(String) with ResourceBundle#getBundle(String, Locale, ClassLoader) and supply the Threads contextClassLoader. ResourceBundle#getBundle(String) uses the current classLoader.

          People

          • Assignee:
            medgar Malcolm Edgar
            Reporter:
            victor72 Victor
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development