From nhajratw@ford.com Wed Nov 20 14:50:57 2002 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18EasD-0002iG-00 for bug-jel@gnu.org; Wed, 20 Nov 2002 14:50:57 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18Eas4-0002Rn-00 for bug-jel@gnu.org; Wed, 20 Nov 2002 14:50:54 -0500 Received: from dymwsm06.mailwatch.com ([204.253.83.42]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Earv-0002Ki-00; Wed, 20 Nov 2002 14:50:39 -0500 Received: from MWSC0213.MW4.MAILWATCH.COM (mwsc0213.mw4.mailwatch.com [204.253.83.252]) by dymwsm06.mailwatch.com (8.11.0/8.11.0) with ESMTP id gAKJobF12342; Wed, 20 Nov 2002 14:50:37 -0500 Received: from mail pickup service by MWSC0213.MW4.MAILWATCH.COM with Microsoft SMTPSVC; Wed, 20 Nov 2002 14:50:37 -0500 Received: from 204.253.83.71 ([204.253.83.71]) by MWSC0213 with SMTP id 0002000dc26125d1-26b1-4793-8c79-e0bdd35ef48c; Wed, 20 Nov 2002 14:50:33 -0500 Received: from ecpo1.azell.com (ecpo1.azell.com [136.1.7.4]) by dymwsm09.mailwatch.com (8.12.6/8.12.6) with ESMTP id gAKJoVSk024478; Wed, 20 Nov 2002 14:50:32 -0500 Received: from na1fcs02.dearborn.ford.com ([19.59.112.118]) by ecpo1.azell.com (Mirapoint Messaging Server MOS 3.2.0.52-EA) with ESMTP id AIU25262; Wed, 20 Nov 2002 14:50:28 -0500 (EST) Received: by na1fcs02.dearborn.ford.com with Internet Mail Service (5.5.2655.15) id ; Wed, 20 Nov 2002 14:50:28 -0500 Message-ID: <2193DEC532DCD311BCF8009027DE2410177927CD@na1ecm05.dearborn.ford.com> From: "Hajratwala, Nayan (N.)" To: "'bug-jel@gnu.org'" , "'help-jel@gnu.org'" Date: Wed, 20 Nov 2002 14:50:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.15) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C290CE.1142C646" X-MW-BTID: 090025000020023247143200024 X-MW-CTIME: 1037821832 HOP-COUNT: 1 X-MAILWATCH-INSTANCEID: 0102000dc26125d1-26b1-4793-8c79-e0bdd35ef48c X-OriginalArrivalTime: 20 Nov 2002 19:50:37.0620 (UTC) FILETIME=[18F57F40:01C290CE] Subject: [Bug-jel] Class Not Found Sender: bug-jel-admin@gnu.org Errors-To: bug-jel-admin@gnu.org X-BeenThere: bug-jel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Distributes bug reports, bug fixes and suggestions for improvements to the active maintainers of GNU JEL. List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C290CE.1142C646 Content-Type: text/plain Folks, I am using JEL 0.9.10 and have a problem. When evaluating an expression, I get the message below. The problem is that I only get the error when running it on IBM WebSphere 3.5. It seems to work fine under WebSphere 4.0 and also works fine under the WebSphere Test Environment in VAJ 4.0. The classpath for WebSphere contains the class indicated, so that's not the problem. I think it's something having to do with JEL using it's own ClassLoader, but am pretty much stuck as to how to approach a resolution. Thanks! java.lang.NoClassDefFoundError: com/ford/hr/framework/user/IUser at dump.evaluate_boolean(Unknown Source) at com.ford.hr.framework.security.UriAccessController.evaluate(Unknown Source) at com.ford.hr.framework.security.UriAccessController.hasReadAccess(Unknown Source) at com.ford.hr.framework.user.User.hasReadAccess(Unknown Source) at com.ford.hr.framework.security.Franchise.hasAccess(Unknown Source) at com.ford.hr.framework.security.FranchiseFactory.getAccessibleMainFranchises(Compiled Code) at com.ford.hr.framework.security.FranchiseFactory.routeTo(Unknown Source) at com.ford.hr.framework.controller.HRServlet.processRequest(Compiled Code) at com.ford.hr.framework.controller.HRServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.ibm.servlet.engine.webapp.StrictServletInstance.doService(ServletManager.java:644) at com.ibm.servlet.engine.webapp.StrictLifecycleServlet._service(StrictLifecycleServlet.java:160) at com.ibm.servlet.engine.webapp.IdleServletState.service(StrictLifecycleServlet.java:287) at com.ibm.servlet.engine.webapp.StrictLifecycleServlet.service(StrictLifecycleServlet.java:105) at com.ibm.servlet.engine.webapp.ServletInstance.service(ServletManager.java:371) at com.ibm.servlet.engine.webapp.ValidServletReferenceState.dispatch(ServletManager.java:793) at com.ibm.servlet.engine.webapp.ServletInstanceReference.dispatch(ServletManager.java:719) at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.handleWebAppDispatch(Compiled Code) at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.dispatch(Compiled Code) at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:189) at com.ibm.servlet.engine.srt.WebAppInvoker.doForward(WebAppInvoker.java:61) at com.ibm.servlet.engine.srt.WebAppInvoker.handleInvocationHook(Compiled Code) at com.ibm.servlet.engine.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:67) at com.ibm.servlet.engine.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:155) at com.ibm.servlet.engine.oselistener.OSEListenerDispatcher.service(OSEListener.java:300) at com.ibm.servlet.engine.oselistener.SQEventListenerImp$ServiceRunnable.run(SQEventListenerImp.java:230) at com.ibm.servlet.engine.oselistener.SQEventListenerImp.notifySQEvent(SQEventListenerImp.java:104) at com.ibm.servlet.engine.oselistener.serverqueue.SQEventSource.notifyEvent(SQEventSource.java:216) at com.ibm.servlet.engine.oselistener.serverqueue.SQWrapperEventSource$SelectRunnable.notifyService(SQWrapperEventSource.java:354) at com.ibm.servlet.engine.oselistener.serverqueue.SQWrapperEventSource$SelectRunnable.run(Compiled Code) at com.ibm.servlet.engine.oselistener.outofproc.OutOfProcThread$CtlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) --- - Nayan Hajratwala - Chikli Consulting LLC - http://www.chikli.com ------_=_NextPart_001_01C290CE.1142C646 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Class Not Found

Folks,

I am using JEL 0.9.10 and = have a problem.

When evaluating an = expression, I get the message below.  The problem is that I only = get the error when running it on IBM WebSphere 3.5.  It seems to = work fine under WebSphere 4.0 and also works fine under the WebSphere = Test Environment in VAJ 4.0.  The classpath for WebSphere contains = the class indicated, so that's not the problem.

I think it's something = having to do with JEL using  it's own ClassLoader, but am pretty = much stuck as to how to approach a resolution.  Thanks!

java.lang.NoClassDefFoundError: = com/ford/hr/framework/user/IUser
        at dump.evaluate_boolean(Unknown = Source)
        at = com.ford.hr.framework.security.UriAccessController.evaluate(Unknown = Source)
        at = com.ford.hr.framework.security.UriAccessController.hasReadAccess(Unknown= Source)
        at = com.ford.hr.framework.user.User.hasReadAccess(Unknown Source)
        at = com.ford.hr.framework.security.Franchise.hasAccess(Unknown = Source)
        at = com.ford.hr.framework.security.FranchiseFactory.getAccessibleMainFranchi= ses(Compiled Code)
        at = com.ford.hr.framework.security.FranchiseFactory.routeTo(Unknown = Source)
        at = com.ford.hr.framework.controller.HRServlet.processRequest(Compiled = Code)
        at = com.ford.hr.framework.controller.HRServlet.doGet(Unknown Source)
        at = javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
        at = javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at = com.ibm.servlet.engine.webapp.StrictServletInstance.doService(ServletMan= ager.java:644)
        at = com.ibm.servlet.engine.webapp.StrictLifecycleServlet._service(StrictLife= cycleServlet.java:160)
        at = com.ibm.servlet.engine.webapp.IdleServletState.service(StrictLifecycleSe= rvlet.java:287)
        at = com.ibm.servlet.engine.webapp.StrictLifecycleServlet.service(StrictLifec= ycleServlet.java:105)
        at = com.ibm.servlet.engine.webapp.ServletInstance.service(ServletManager.jav= a:371)
        at = com.ibm.servlet.engine.webapp.ValidServletReferenceState.dispatch(Servle= tManager.java:793)
        at = com.ibm.servlet.engine.webapp.ServletInstanceReference.dispatch(ServletM= anager.java:719)
        at = com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.handleWebAppDispat= ch(Compiled Code)
        at = com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.dispatch(Compiled = Code)
        at = com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.forward(WebAppRequ= estDispatcher.java:189)
        at = com.ibm.servlet.engine.srt.WebAppInvoker.doForward(WebAppInvoker.java:61= )
        at = com.ibm.servlet.engine.srt.WebAppInvoker.handleInvocationHook(Compiled = Code)
        at = com.ibm.servlet.engine.invocation.CachedInvocation.handleInvocation(Cach= edInvocation.java:67)
        at = com.ibm.servlet.engine.srp.ServletRequestProcessor.dispatchByURI(Servlet= RequestProcessor.java:155)
        at = com.ibm.servlet.engine.oselistener.OSEListenerDispatcher.service(OSEList= ener.java:300)
        at = com.ibm.servlet.engine.oselistener.SQEventListenerImp$ServiceRunnable.ru= n(SQEventListenerImp.java:230)
        at = com.ibm.servlet.engine.oselistener.SQEventListenerImp.notifySQEvent(SQEv= entListenerImp.java:104)
        at = com.ibm.servlet.engine.oselistener.serverqueue.SQEventSource.notifyEvent= (SQEventSource.java:216)
        at = com.ibm.servlet.engine.oselistener.serverqueue.SQWrapperEventSource$Sele= ctRunnable.notifyService(SQWrapperEventSource.java:354)

        at = com.ibm.servlet.engine.oselistener.serverqueue.SQWrapperEventSource$Sele= ctRunnable.run(Compiled Code)
        at = com.ibm.servlet.engine.oselistener.outofproc.OutOfProcThread$CtlRunnable= .run(Compiled Code)
        at java.lang.Thread.run(Compiled = Code)




---
- Nayan Hajratwala
- Chikli Consulting = LLC
- http://www.chikli.com

------_=_NextPart_001_01C290CE.1142C646-- From metlov@fzu.cz Wed Nov 20 15:22:00 2002 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18EbMG-0001p0-00 for bug-jel@gnu.org; Wed, 20 Nov 2002 15:22:00 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18EbM7-0001XI-00 for bug-jel@gnu.org; Wed, 20 Nov 2002 15:21:59 -0500 Received: from pc175e.fzu.cz ([147.231.127.175]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18EbM4-0000Pp-00 for bug-jel@gnu.org; Wed, 20 Nov 2002 15:21:49 -0500 Received: (from root@localhost) by pc175e.fzu.cz (8.11.0/8.11.0) id gAKKKmU18725 for bug-jel@gnu.org.KAV; Wed, 20 Nov 2002 21:21:13 +0100 Received: from fzu.cz (sarka.fzu.cz [147.231.26.40]) by pc175e.fzu.cz (8.11.0/8.11.0) with ESMTP id gAKKJXA18312; Wed, 20 Nov 2002 21:19:33 +0100 Received: from pc119b.fzu.cz (pc119b [147.231.26.119]) by fzu.cz (8.11.6+Sun/8.11.6) with ESMTP id gAKKJEV16866; Wed, 20 Nov 2002 21:19:14 +0100 (MET) Date: Wed, 20 Nov 2002 21:16:18 +0100 (CET) From: "Konstantin L. Metlov" To: "Hajratwala, Nayan (N.)" cc: bug-jel@gnu.org In-Reply-To: <2193DEC532DCD311BCF8009027DE2410177927CE@na1ecm05.dearborn.ford.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Bug-jel] Re: Class Not Found Sender: bug-jel-admin@gnu.org Errors-To: bug-jel-admin@gnu.org X-BeenThere: bug-jel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Distributes bug reports, bug fixes and suggestions for improvements to the active maintainers of GNU JEL. List-Unsubscribe: , List-Archive: Dear Nayan Hajratwala, The situation you have encountered is not a bug in JEL, but rather a manifestation of intricacy of Java classloaders. In short, the problem is related to the fact that your class "com.ford.hr.framework.user.IUser" might be present in the classpath TWICE by being accessible by two _different_ classloaders at the same time. This often happens in a servlet engines having both "default" and so called "zone-specific" classloaders. The solution is to load JEL (preferably as a whole, but loading only gnu.jel.ImageLoader class is sufficient) into your JVM using the same "zone-specific" classloader your classes (e.g. com.ford.hr.framework.user.IUser) are loaded with. Thank you for your interest in JEL ! If some questions still remain, please ask. With the best regards, Konstantin. APPENDIX For more detailed explanation, please read the following excerpt from my E-mail to one of JEL users having the same problem (in this explanation class "Message" plays the same role as your "com.ford.hr.framework.user.IUser", and "TestRouter" stands for a class within your package referring to "com.ford.hr.framework.user.IUser" directly, e.g. not through JEL): -------------- First, a little of common knowledge (probably redundant). A ClassLoader is a java class, which loads other Java classes into the memory of Java VM and maintains their namespace. Actually, the only way to load a bytecode into JVM is via a ClassLoader of some kind. There can be several classloaders active at the same time, and, thus several namespaces. Servlet engines, often, separate different parts of the web site (sometimes they are called "servlet zones") by using different classloaders for each zone. Additionally, in each JVM instance, there is a "default" classloader, which loads classes from a global JVM classpath. When loading compiled expressions into JVM, JEL does it in the same context (e.g. in the namespace of the same classloader) the class gnu.jel.ImageLoader (a part of JEL library) was loaded. This means, if JEL is in the global classpath -- the compiled expressions will be loaded in the context of "default" classloader. Servlets, on the other hand, are loaded by a classloader specific to their "servlet zone". The problem arizes when JEL is loaded by "default" classloader and the same classes (in your case "Message") can be loaded both by "default" and zone-specific classloaders (e.g. they are on "classpath" of both). In this case, when expression is compiled the byte code contains only a link to Message class. When it is loaded into JVM this link is resolved using the "default" classloader and your Message class is loaded by it. On the other hand, there exists another instance of Message class (please note the difference with object), which is loaded by zone-specific classloader (the one, which allows you to access Message from within your HttpServlet implementation). Next, when you call the expression, you pass the instance of Message class held in Router.msg (which was loaded by zone-specific classloader) into JEL expression, containing the reference to Message class (which was loaded by "default" classloader). The main point is that these two classes are considered DIFFERENT by JVM and can not be converted into one another. See e.g. http://216.239.53.100/search?q=cache:A0_GzRToobgC:www.dcs.gla.ac.uk/~huw/papers/eufurt.ps.gz+%22two+classes+with+the+same+name%22+%22different+classloaders%22+ClassCastException&hl=en&ie=UTF-8 for reference. Therefore, please check that the whole JEL (and gnu.jel.ImageLoader in particular) is loaded into your JVM not via global CLASSPPATH, but through the same zone-specific classloader you use to load TestRouter class. --------------------- and its continuation, with some simple pictures: --------------------- May be this will explain the situation with classloaders better. Each classloader has a "parent" classloader to which it passes the requests to load the classes it can not resolve. This allows to organize classloaders into a tree (since a single classloader can be a parent of many). The "default" classloader is a root. WRONG SITUATION |--------> "default" | namespace: | java.lang.* | java.net.* | ... | gnu.jel.ImageLoader(g.j.I) | Message | |------------------------------- .... ------- | | | g.j.I (instance1) g.j.I (instance2) servlet classloader namespace: namespace: namespace: gnu.jel.E_1 gnu.jel.E_2 TestRouter Message The class message appears in two namespaces. This is because the compiled expression refers to it, at its load time the g.j.I classloader, obviously (because it does not know about anything except JEL expressions), passes the request to load its parent (which is "default" classloader in this case). The second Message appears in servlet classloader namespace because TestRouter refers to it, and this reference is resolved upon loading of the TestRouter class. CORRECT SITUATION |--------> "default" | namespace: | java.lang.* | java.net.* | ... | --------------- | | ------> servlet classloader | namespace: | TestRouter | Message | ... | gnu.jel.ImageLoader | |------------------------------- .... | | g.j.I (instance1) g.j.I (instance2) namespace: namespace: gnu.jel.E_1 gnu.jel.E_2 In this case the parent of JEL classloaders is "servlet classloader", to which g.j.I (correctly) readdressed request to load Message class, so that only one instance of Message class exists in JVM. One g.j.I per compiled expression is required to enable the garbage collection of classes (additionally to objects). --------------- From nhajratw@ford.com Wed Nov 20 15:38:45 2002 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18EbcS-0001DD-00 for bug-jel@gnu.org; Wed, 20 Nov 2002 15:38:44 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18EbcK-00019i-00 for bug-jel@gnu.org; Wed, 20 Nov 2002 15:38:42 -0500 Received: from dymwsm17.mailwatch.com ([204.253.83.165]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18EbcJ-00019Y-00 for bug-jel@gnu.org; Wed, 20 Nov 2002 15:38:36 -0500 Received: from mwsc0219.mw4.mailwatch.com (mwsc0219.mw4.mailwatch.com [204.253.83.141]) by dymwsm17.mailwatch.com (8.11.0/8.11.0) with ESMTP id gAKKcZc17274 for ; Wed, 20 Nov 2002 15:38:35 -0500 Received: from mail pickup service by mwsc0219.mw4.mailwatch.com with Microsoft SMTPSVC; Wed, 20 Nov 2002 15:38:35 -0500 Received: from 204.253.83.34 ([204.253.83.34]) by MWSC0219 with SMTP id 00020013dde619ca-e2c0-4be2-ae52-032a22604d27; Wed, 20 Nov 2002 15:38:34 -0500 Received: from ecpo1.azell.com (ecpo1.azell.com [136.1.7.4]) by dymwsm12.mailwatch.com (8.12.6/8.12.6) with ESMTP id gAKKcW06000964 for ; Wed, 20 Nov 2002 15:38:34 -0500 Received: from na1ecs06.dearborn.ford.com ([19.5.116.123]) by ecpo1.azell.com (Mirapoint Messaging Server MOS 3.2.0.52-EA) with ESMTP id AIU35924; Wed, 20 Nov 2002 15:38:30 -0500 (EST) Received: by na1ecs06.dearborn.ford.com with Internet Mail Service (5.5.2655.15) id ; Wed, 20 Nov 2002 15:38:30 -0500 Message-ID: <2193DEC532DCD311BCF8009027DE2410177927CF@na1ecm05.dearborn.ford.com> From: "Hajratwala, Nayan (N.)" To: "'Konstantin L. Metlov'" Cc: bug-jel@gnu.org Subject: RE: [Bug-jel] Re: Class Not Found Date: Wed, 20 Nov 2002 15:38:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.15) Content-Type: text/plain X-MW-BTID: 090325000020023247431400026 X-MW-CTIME: 1037824713 HOP-COUNT: 1 X-MAILWATCH-INSTANCEID: 01020013dde619ca-e2c0-4be2-ae52-032a22604d27 X-OriginalArrivalTime: 20 Nov 2002 20:38:35.0026 (UTC) FILETIME=[CC06CF20:01C290D4] Sender: bug-jel-admin@gnu.org Errors-To: bug-jel-admin@gnu.org X-BeenThere: bug-jel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Distributes bug reports, bug fixes and suggestions for improvements to the active maintainers of GNU JEL. List-Unsubscribe: , List-Archive: Thanks! It worked! FYI, under WebSphere 3.5, I simply placed the JEL classes right along with my regular application code rather than in the classpath for the JVM. Strange but true =) -----Original Message----- From: Konstantin L. Metlov [mailto:metlov@fzu.cz] Sent: Wednesday, November 20, 2002 3:16 PM To: Hajratwala, Nayan (N.) Cc: bug-jel@gnu.org Subject: [Bug-jel] Re: Class Not Found Dear Nayan Hajratwala, The situation you have encountered is not a bug in JEL, but rather a manifestation of intricacy of Java classloaders. In short, the problem is related to the fact that your class "com.ford.hr.framework.user.IUser" might be present in the classpath TWICE by being accessible by two _different_ classloaders at the same time. This often happens in a servlet engines having both "default" and so called "zone-specific" classloaders. The solution is to load JEL (preferably as a whole, but loading only gnu.jel.ImageLoader class is sufficient) into your JVM using the same "zone-specific" classloader your classes (e.g. com.ford.hr.framework.user.IUser) are loaded with. Thank you for your interest in JEL ! If some questions still remain, please ask. With the best regards, Konstantin. APPENDIX For more detailed explanation, please read the following excerpt from my E-mail to one of JEL users having the same problem (in this explanation class "Message" plays the same role as your "com.ford.hr.framework.user.IUser", and "TestRouter" stands for a class within your package referring to "com.ford.hr.framework.user.IUser" directly, e.g. not through JEL): -------------- First, a little of common knowledge (probably redundant). A ClassLoader is a java class, which loads other Java classes into the memory of Java VM and maintains their namespace. Actually, the only way to load a bytecode into JVM is via a ClassLoader of some kind. There can be several classloaders active at the same time, and, thus several namespaces. Servlet engines, often, separate different parts of the web site (sometimes they are called "servlet zones") by using different classloaders for each zone. Additionally, in each JVM instance, there is a "default" classloader, which loads classes from a global JVM classpath. When loading compiled expressions into JVM, JEL does it in the same context (e.g. in the namespace of the same classloader) the class gnu.jel.ImageLoader (a part of JEL library) was loaded. This means, if JEL is in the global classpath -- the compiled expressions will be loaded in the context of "default" classloader. Servlets, on the other hand, are loaded by a classloader specific to their "servlet zone". The problem arizes when JEL is loaded by "default" classloader and the same classes (in your case "Message") can be loaded both by "default" and zone-specific classloaders (e.g. they are on "classpath" of both). In this case, when expression is compiled the byte code contains only a link to Message class. When it is loaded into JVM this link is resolved using the "default" classloader and your Message class is loaded by it. On the other hand, there exists another instance of Message class (please note the difference with object), which is loaded by zone-specific classloader (the one, which allows you to access Message from within your HttpServlet implementation). Next, when you call the expression, you pass the instance of Message class held in Router.msg (which was loaded by zone-specific classloader) into JEL expression, containing the reference to Message class (which was loaded by "default" classloader). The main point is that these two classes are considered DIFFERENT by JVM and can not be converted into one another. See e.g. http://216.239.53.100/search?q=cache:A0_GzRToobgC:www.dcs.gla.ac.uk/~huw/papers/eufurt.ps.gz+%22two+classes+with+the+same+name%22+%22different+classloaders%22+ClassCastException&hl=en&ie=UTF-8 for reference. Therefore, please check that the whole JEL (and gnu.jel.ImageLoader in particular) is loaded into your JVM not via global CLASSPPATH, but through the same zone-specific classloader you use to load TestRouter class. --------------------- and its continuation, with some simple pictures: --------------------- May be this will explain the situation with classloaders better. Each classloader has a "parent" classloader to which it passes the requests to load the classes it can not resolve. This allows to organize classloaders into a tree (since a single classloader can be a parent of many). The "default" classloader is a root. WRONG SITUATION |--------> "default" | namespace: | java.lang.* | java.net.* | ... | gnu.jel.ImageLoader(g.j.I) | Message | |------------------------------- .... ------- | | | g.j.I (instance1) g.j.I (instance2) servlet classloader namespace: namespace: namespace: gnu.jel.E_1 gnu.jel.E_2 TestRouter Message The class message appears in two namespaces. This is because the compiled expression refers to it, at its load time the g.j.I classloader, obviously (because it does not know about anything except JEL expressions), passes the request to load its parent (which is "default" classloader in this case). The second Message appears in servlet classloader namespace because TestRouter refers to it, and this reference is resolved upon loading of the TestRouter class. CORRECT SITUATION |--------> "default" | namespace: | java.lang.* | java.net.* | ... | --------------- | | ------> servlet classloader | namespace: | TestRouter | Message | ... | gnu.jel.ImageLoader | |------------------------------- .... | | g.j.I (instance1) g.j.I (instance2) namespace: namespace: gnu.jel.E_1 gnu.jel.E_2 In this case the parent of JEL classloaders is "servlet classloader", to which g.j.I (correctly) readdressed request to load Message class, so that only one instance of Message class exists in JVM. One g.j.I per compiled expression is required to enable the garbage collection of classes (additionally to objects). --------------- _______________________________________________ Bug-jel mailing list Bug-jel@gnu.org http://mail.gnu.org/mailman/listinfo/bug-jel From mike.squance@altus-solutions.com Wed Nov 27 19:34:52 2002 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18HCdn-0001hE-00 for bug-jel@gnu.org; Wed, 27 Nov 2002 19:34:51 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18HCdm-0001go-00 for bug-jel@gnu.org; Wed, 27 Nov 2002 19:34:51 -0500 Received: from smtp2.tidc.telus.com ([209.171.56.4] helo=smtp.tidc.telus.com) by monty-python.gnu.org with smtp (Exim 4.10) id 18HCdl-0001fm-00 for bug-jel@gnu.org; Wed, 27 Nov 2002 19:34:49 -0500 Received: (qmail 9441 invoked from network); 28 Nov 2002 00:35:18 -0000 Received: from unknown (HELO outserv.altus-solutions.com) (207.81.211.2) by smtp2.tidc.telus.com with SMTP; 28 Nov 2002 00:35:18 -0000 Received: by outserv.altus-solutions.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Nov 2002 16:34:23 -0800 Message-ID: <294A9D90D398D3118A8C0008C709BFED6A9FF9@outserv.altus-solutions.com> From: Mike Squance To: "'bug-jel@gnu.org'" Date: Wed, 27 Nov 2002 16:34:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Bug-jel] Data type of compiled expressions Sender: bug-jel-admin@gnu.org Errors-To: bug-jel-admin@gnu.org X-BeenThere: bug-jel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Distributes bug reports, bug fixes and suggestions for improvements to the active maintainers of GNU JEL. List-Unsubscribe: , List-Archive: Hi, First, let me say that I've been extremely happy with JEL and I hope it continues to be supported. I'm having a bit of trouble with the data type of expressions that I suspect is a limitation of the software, but I thought I'd ask anyways. I rely on the getType() result to validate whether an expression has been entered correctly with respect to the data type that the expression is supposed to be producing. For example: There are 2 measurements defined: RAW1 of type Integer RAW2 of type Integer A derived measurement is defined: DERIVED1 of type Integer An expression is written to derive DERIVED1 from the available measurements. I look at the result of getType() to ensure that the result of the expression for DERIVED1 is of type Integer. In general, with expressions like "RAW1 + RAW2", "RAW1 + 10", this works fine. I get Integer as the resulting data type. However, with an expression "RAW1" or "(RAW1 > RAW2)?(RAW1):(RAW2)", I get Object as the resulting data type. I know that I can do "RAW1+0" to work around this, but this is not very desirable. Here is a bit of code, based on the YourTestBed example. The DVResolver was updated to support Integer. resolver.addProperty("RAW1", new Integer( 10 ) ); resolver.addProperty("RAW2",new Integer( 3 ) ); expr=gnu.jel.Evaluator.compile("RAW2",lib); System.out.println("DATATYPE = " +expr.getType() ); System.out.println("RAW2="+expr.evaluate(context)); expr=gnu.jel.Evaluator.compile("(1>0)?(RAW1):(RAW2)",lib); System.out.println("DATATYPE = " +expr.getType() ); System.out.println("MYRESULT = " +expr.evaluate(context) ); First, is this a bug? If not, can you suggest a better alternative than the "+0" approach? Thanks for any help, Mike. From metlov@fzu.cz Thu Nov 28 07:37:45 2002 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18HNvN-0006pJ-00 for bug-jel@gnu.org; Thu, 28 Nov 2002 07:37:45 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18HNvL-0006oy-00 for bug-jel@gnu.org; Thu, 28 Nov 2002 07:37:44 -0500 Received: from pc175e.fzu.cz ([147.231.127.175]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18HNvL-0006ny-00 for bug-jel@gnu.org; Thu, 28 Nov 2002 07:37:43 -0500 Received: (from root@localhost) by pc175e.fzu.cz (8.11.0/8.11.0) id gASCbbe31764 for bug-jel@gnu.org.KAV; Thu, 28 Nov 2002 13:37:37 +0100 Received: from fzu.cz (sarka.fzu.cz [147.231.26.40]) by pc175e.fzu.cz (8.11.0/8.11.0) with ESMTP id gASCbYT31751; Thu, 28 Nov 2002 13:37:34 +0100 Received: from pc119b.fzu.cz (pc119b [147.231.26.119]) by fzu.cz (8.11.6+Sun/8.11.6) with ESMTP id gASCbZV01435; Thu, 28 Nov 2002 13:37:35 +0100 (MET) Date: Thu, 28 Nov 2002 13:34:14 +0100 (CET) From: "Konstantin L. Metlov" To: Mike Squance cc: "'bug-jel@gnu.org'" Subject: Re: [Bug-jel] Data type of compiled expressions In-Reply-To: <294A9D90D398D3118A8C0008C709BFED6A9FF9@outserv.altus-solutions.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bug-jel-admin@gnu.org Errors-To: bug-jel-admin@gnu.org X-BeenThere: bug-jel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Distributes bug reports, bug fixes and suggestions for improvements to the active maintainers of GNU JEL. List-Unsubscribe: , List-Archive: Dear Mike, Thank you for your message. I can assure you that I have no plans to abandon JEL, it will remain supported by me for a long period of time. In the worst case of circumstances beyond my control, anyone will be able to take over my role, because JEL is Free Software and essentially all its sources are released (there are no secrets). Should the worst happen I can even transfer my copyright to the new reliable maintainer, so that he can continue with the current business model. The fact that there were no new releases for about 6 months is connected with my feeling that JEL had reached a kind of feature saturation. In my CVS there are some changes, which reduce the size and improve performance slightly more, but I just don't feel they are significant enough to release a new version at this time. I'm also not aware of any bugs, should one be found the new version will be released immediately. In the situation you've described I'd say JEL behaves as intended (e.g. it tries to preserve as much of the original types as possible). And, since in the conditional there is no necessity to unwrap objects in order determine the result type and to compile it -- unwrapping is not done. To get the behaviour you want (e.g. to guarantee a certain result type, so that you do not have to check it at all) it is better to use the three-argument version of "compile". E.g. in your example replace expr=gnu.jel.Evaluator.compile("RAW2",lib); by expr=gnu.jel.Evaluator.compile("RAW2",lib,Integer.TYPE); This will make JEL convert the result into "int" automatically, and generate a compile-time message if it can't (for example when expression is "RAW1+1.5F"), suggesting the user to insert explicit type conversion (e.g. "round(RAW1+1.5F)"). If you fix the result type, as described above, it becomes possible to use .evaluate_int(...) method of your compiled expression directly with no checks of .getType(). If you do so, the performance of your application may increase significantly. Also, if you have only a fixed set of variables (e.g. RAW1, RAW2 and no more) -- it is possible to avoid using the so-called "Dynamic Variables Interface" (e.g resolver) and just add them into a class as public members of type "int", making that class a part of JEL's dynamic library. This way the number object creations will be reduced, further improving performance of your application. If you may have a variable number of RAW variables of the same type it is still possible to improve performance by placing them into an array (to be accessed within expressions as RAW[0], RAW[1], etc...). Thank you for your interest in JEL ! With the best regards, Konstantin. From msquance@telus.net Fri Nov 29 03:42:01 2002 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18Hgin-0002Fm-00 for bug-jel@gnu.org; Fri, 29 Nov 2002 03:42:01 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18Hgii-00024Z-00 for bug-jel@gnu.org; Fri, 29 Nov 2002 03:41:58 -0500 Received: from defout.telus.net ([199.185.220.240] helo=priv-edtnes16-hme0.telusplanet.net) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Hgih-00021U-00 for bug-jel@gnu.org; Fri, 29 Nov 2002 03:41:55 -0500 Received: from mike50vpzh81kz ([66.183.54.129]) by priv-edtnes16-hme0.telusplanet.net (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20021129075905.PFNM20485.priv-edtnes16-hme0.telusplanet.net@mike50vpzh81kz> for ; Fri, 29 Nov 2002 00:59:05 -0700 Reply-To: From: "Mike Squance" To: Subject: RE: [Bug-jel] Data type of compiled expressions Date: Thu, 28 Nov 2002 23:59:08 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: bug-jel-admin@gnu.org Errors-To: bug-jel-admin@gnu.org X-BeenThere: bug-jel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Distributes bug reports, bug fixes and suggestions for improvements to the active maintainers of GNU JEL. List-Unsubscribe: , List-Archive: Konstantin, Thanks for your suggestions. The 3-argument compile is definitely what I should be using and solves my problem (and a couple others) perfectly. It had been quite a long time since I wrote the initial code using JEL so I didn't think to look through the APIs again. I do need to make use of the resolver interface, as I do some fairly complex dynamic resolution. I simplified my example quite a bit. I'm wondering if there are still performance improvements to be gained by using the evaluate_int (for example) if I am going to construct a Java object from the primitive or does this basically amount to the same as just using evaluate? Thanks and regards, Mike. -----Original Message----- From: bug-jel-admin@gnu.org [mailto:bug-jel-admin@gnu.org]On Behalf Of Konstantin L. Metlov Sent: Thursday, November 28, 2002 4:34 AM To: Mike Squance Cc: 'bug-jel@gnu.org' Subject: Re: [Bug-jel] Data type of compiled expressions Dear Mike, Thank you for your message. I can assure you that I have no plans to abandon JEL, it will remain supported by me for a long period of time. In the worst case of circumstances beyond my control, anyone will be able to take over my role, because JEL is Free Software and essentially all its sources are released (there are no secrets). Should the worst happen I can even transfer my copyright to the new reliable maintainer, so that he can continue with the current business model. The fact that there were no new releases for about 6 months is connected with my feeling that JEL had reached a kind of feature saturation. In my CVS there are some changes, which reduce the size and improve performance slightly more, but I just don't feel they are significant enough to release a new version at this time. I'm also not aware of any bugs, should one be found the new version will be released immediately. In the situation you've described I'd say JEL behaves as intended (e.g. it tries to preserve as much of the original types as possible). And, since in the conditional there is no necessity to unwrap objects in order determine the result type and to compile it -- unwrapping is not done. To get the behaviour you want (e.g. to guarantee a certain result type, so that you do not have to check it at all) it is better to use the three-argument version of "compile". E.g. in your example replace expr=gnu.jel.Evaluator.compile("RAW2",lib); by expr=gnu.jel.Evaluator.compile("RAW2",lib,Integer.TYPE); This will make JEL convert the result into "int" automatically, and generate a compile-time message if it can't (for example when expression is "RAW1+1.5F"), suggesting the user to insert explicit type conversion (e.g. "round(RAW1+1.5F)"). If you fix the result type, as described above, it becomes possible to use .evaluate_int(...) method of your compiled expression directly with no checks of .getType(). If you do so, the performance of your application may increase significantly. Also, if you have only a fixed set of variables (e.g. RAW1, RAW2 and no more) -- it is possible to avoid using the so-called "Dynamic Variables Interface" (e.g resolver) and just add them into a class as public members of type "int", making that class a part of JEL's dynamic library. This way the number object creations will be reduced, further improving performance of your application. If you may have a variable number of RAW variables of the same type it is still possible to improve performance by placing them into an array (to be accessed within expressions as RAW[0], RAW[1], etc...). Thank you for your interest in JEL ! With the best regards, Konstantin. _______________________________________________ Bug-jel mailing list Bug-jel@gnu.org http://mail.gnu.org/mailman/listinfo/bug-jel From metlov@fzu.cz Fri Nov 29 14:27:00 2002 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18Hqmx-00051h-00 for bug-jel@gnu.org; Fri, 29 Nov 2002 14:26:59 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18Hqmv-00051Q-00 for bug-jel@gnu.org; Fri, 29 Nov 2002 14:26:59 -0500 Received: from pc175e.fzu.cz ([147.231.127.175]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Hqmv-00050s-00 for bug-jel@gnu.org; Fri, 29 Nov 2002 14:26:57 -0500 Received: (from root@localhost) by pc175e.fzu.cz (8.11.0/8.11.0) id gATJQpm01854 for bug-jel@gnu.org.KAV; Fri, 29 Nov 2002 20:26:51 +0100 Received: from fzu.cz (sarka.fzu.cz [147.231.26.40]) by pc175e.fzu.cz (8.11.0/8.11.0) with ESMTP id gATJQo901846; Fri, 29 Nov 2002 20:26:50 +0100 Received: from pc119b.fzu.cz (pc119b [147.231.26.119]) by fzu.cz (8.11.6+Sun/8.11.6) with ESMTP id gATJQqV22412; Fri, 29 Nov 2002 20:26:52 +0100 (MET) Date: Fri, 29 Nov 2002 20:23:26 +0100 (CET) From: "Konstantin L. Metlov" To: mike.squance@altus-solutions.com cc: bug-jel@gnu.org Subject: RE: [Bug-jel] Data type of compiled expressions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bug-jel-admin@gnu.org Errors-To: bug-jel-admin@gnu.org X-BeenThere: bug-jel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Distributes bug reports, bug fixes and suggestions for improvements to the active maintainers of GNU JEL. List-Unsubscribe: , List-Archive: Dear Mike, > I do need to make use of the resolver interface, as I do some fairly complex > dynamic resolution. I simplified my example quite a bit. A gain in performance can still be achieved by using the newly introduced DVmap class instead of DVresolver, which allows to translate the variable names at compile-time into values of Java primitive types (e.g. integers). This way it is possible (but can be tricky, with feasibility depending on a particular application) to eliminate string lookups of variable names during the expression run-time and replace them by direct indexed access. > I'm wondering if there are still performance improvements to be gained by > using the evaluate_int (for example) if I am going to construct a Java > object from the primitive or does this basically amount to the same as just > using evaluate? There is a very small one, because evaluate() does type checking, whereas new Integer(evaluate_int()) (or similar, with any other specialized version of evaluate) does not. This performance gain will be very small (because type checking is done by integer switch) compared to potential performance gains from using Java primitive types (eliminating object creation/garmage collection) and eliminating variable name lookups at compile-time. With the best regards, Konstantin.