OC4J class loader issues

Hi,
I'm developing four JSF-Icefaces web apps. with Eclipse and OC4J as required for my customer.
I created a common classloader inside of the folder C:\oc4j_extended_101340\j2ee\home\applib in order to avoid the repetition of the inclusion of several common jars (like commons, jsf, icefaces among many others) inside the folder web-inf/lib for all these apps.
However, this approach is not working, for some reason OC4J always throws all kinds of "ClassNotFoundException" when using this common classloader, so I have to copy the bunch of jars in web-inf/lib of all apps.
What's wrong? Thanks!!!

Like we told you. If the code for a class changes, Java will not automatically notice and load the new version, until you start up the JVM again. If you do not want to re-start the VM, you can create a new ClassLoader (CL), and use it to load the new code for the class.
Now, the problem is, the second CL may think it has to reload many of other classes, since it has no record of loading them itself. You will end up with duplicates of many classes.
If that doesn't suit you, there is not much alternatives.
You could rename the new version of the class, which would mean you'd have to manually track down all the old versions and upgrade them ( by using the new Ctor). You'd then have to update all the references to make them point to the new object. You can make that particular job easier by making both classes (old and new) extend a common base class, or implements the same interface, and use the interface reference (i.e program to an interface).
Another less-than-perfect possibility would be to use serialization where you serialise version-marked objects and reconstitute them with new code...
Good luck.

Similar Messages

  • Oc4j class-loading-heirarchy - enabling "search-local-classes-first" option

    Guys,
    I need some assistance with regards to oc4j class-loading hierarchy. Would appreciate some feedback on this...
    Let me give you a bit of context first.
    Basically we have 3 war modules which we initially were deployed separately on oc4j (transparently deployed by oc4j as ear). Now all of a sudden we have come to the need of instead bundling all the wars in one ear. The problem i started seeing is with respect to the output logs for the application, which was one per war modules initially (this was not clutter everything in one single log file and instead have one per deploy-able unit). The way this was implemented is that we had a log4j.properties bundled with each war with the output-file configuration, and since these 3 wars were deployed separately, the ear class-loader for each application would find one log4j.properties within each, and hence output-logs were generated as expected.
    BUT now all of a sudden as we have changed the whole deployment structure, i.e. one EAR, all the application log-outputs are going to one single log file (instead of one for each war). My immediate impression was setting the "search-local-classes-first" would resolve this issue, since then the "web-module-class-loader" (one for each war) would come into play (which i believe doesn't otherwise) and would load/search for the resources/classes first (log4j.properties in our case) from the web-module (both in WEB-INF/lib and WEB-INF/classes folder) and if not found, only then it would give the job to the parent class-loader, which would be the ear-class-loader. But it doesnt seem like its working like that, since even after enabling this option, all logs are going to one log-output file, based on whichever war-module/log4j.properties is loaded first.
    Thanks in advance and Regards,
    Farhan.
    Edited by: FarhanS on Nov 3, 2008 12:36 PM

    Guys, i need some input here....
    I turned on the class-loading trace and found out as to what is going on...but still wondering as to whats the reason for this behavior...
    So basically browsing through the trace, gave me the following important segments (as below with my comments)....
    1) Firstly, as the class-loading trace below, the log4j.jar is loaded up from the ear/lib directory (and hence by the ear-class-loader) and as it says the one in the web-inf/lib is ignored....Wonder why it picks up the one from ear/lib directory WHEN i have set the search-local-classes-first to "true", isn't the very purpose of the attribute to delegate the class-loading to the parent class-loader IFF the same is not found locally...
    Code-source /oracle_apps/j2ee/portal/applications/wes-ear/wes-wicket-1.3.X-SNAPSHOT/WEB-INF/lib/log4j-1.2.15.jar (from WEB-INF/lib/ directory in /oracle_apps/j2ee/portal/applications/wes-ear/wes-wicket-1.3.X-SNAPSHOT/WEB-INF/lib)
    has been ignored. It is a copy of /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib), which is already visible in the search path of
    loader wes-ear.web.wes-wicket-1.3.X-SNAPSHOT:0.0.0. 2) Now on the other hand as you would see from the log-excerpts below, the log4j.properties resource file (with the log-output-file-name and all) is picked up from the very web-module class-loader, but as you would notice further, the log4j classes are initialized by the ear-loader itself with which the log4j classes are visible to all the other war-modules and hence don't even require re-initializing the log4j.properties...
    ====== THE RESOURCE CORRECTLY LOCATED BY THE WEB-CLASS-LOADER ======
    Resource found: log4j.properties. Loader: wes-ear.web.wes-wicket-1.3.X-SNAPSHOT:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/wes-wicket-1.3.X-SNAPSHOT/WEB-INF/classes/
    (from WEB-INF/classes/ in /oracle_apps/j2ee/portal/applications/wes-ear/wes-wicket-1.3.X-SNAPSHOT/WEB-INF/classes)
    === ALL THE Log4j CLASSES BELOW ARE BEING INITIALIZED/LOADED BY THE EAR-CLASS-LOADER =====
    Class found: java.net.URL. Initiating loader: wes-ear.root:0.0.0. Defining loader: jre.bootstrap:1.5.0_06. Source: jre bootstrap
    Class to be defined: org.apache.log4j.PropertyConfigurator (12024 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
    Class found: org.apache.log4j.PropertyConfigurator. Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
    Class to be defined: org.apache.log4j.helpers.FileWatchdog (1875 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
    Class found: org.apache.log4j.helpers.FileWatchdog. Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
    Class to be defined: org.apache.log4j.PropertyWatchdog (753 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
    Class found: org.apache.log4j.PropertyWatchdog. Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
    Class found: java.io.InputStream. Initiating loader: wes-ear.root:0.0.0. Defining loader: jre.bootstrap:1.5.0_06. Source: jre bootstrap
    Class found: java.io.FileInputStream. Initiating loader: wes-ear.root:0.0.0. Defining loader: jre.bootstrap:1.5.0_06. Source: jre bootstrap
    Class found: java.util.Properties. Initiating loader: wes-ear.root:0.0.0. Defining loader: jre.bootstrap:1.5.0_06. Source: jre bootstrap
    Class found: java.util.StringTokenizer. Initiating loader: wes-ear.root:0.0.0. Defining loader: jre.bootstrap:1.5.0_06. Source: jre bootstrap
    Class to be defined: org.apache.log4j.Appender (676 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
    Class found: org.apache.log4j.Appender. Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
    Class to be defined: org.apache.log4j.DailyRollingFileAppender (5724 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)
    Class to be defined: org.apache.log4j.FileAppender (4764 bytes). Loader: wes-ear.root:0.0.0. Source: /oracle_apps/j2ee/portal/applications/wes-ear/lib/log4j-1.2.15.jar (from application.xml <library-directory> in /oracle_apps/j2ee/portal/applications/wes-ear/lib)Thanks in advance and Regards,
    Farhan.
    Edited by: FarhanS on Nov 4, 2008 2:43 PM
    Edited by: FarhanS on Nov 4, 2008 2:47 PM

  • Does resteasy API have class loader issues when using via OSGi

    Does resteasy API have class loader issues when using via OSGi

    Hi Scott,
    THis isnt an answer to ur Question, but could u tell me which jar files are needed for the packages:
    com.sap.portal.pcm.system.ISystems
    com.sap.portal.pcm.system.ISystem
    and under which path I coul dfind them.
    Thnx
    Regards
    Meesum.

  • Integrated WL/Jdeveloper class loading issue

    Hello,
    I am trying to run a deployed project , getting into this class loading issue. Any idea?
    javax.security.auth.login.LoginException: java.lang.LinkageError: loader constraint violation: when resolving interface method "com.scat.util.identity.UserFactory.lookup(Ljava/lang/String;)Lcom/scat/domain/identity/User;" the class loader (instance of weblogic/utils/classloaders/ChangeAwareClassLoader) of the current class, com/scat/auth/authentication/login/UserLoginModule, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, com/scatl/util/identity/UserFactory, have different Class objects for the type com/scat/domain/identity/User used in the signature
    Thanks
    Ram

    How many times are you loading the com/scat/domain/identity/User type?
    Is this in the system classloader and the application? and are you using class loading filtering in the application, for example,
    in weblogic.xml - prefer-web-inf-classes?

  • Class loading issue in 10.1.2?  commons-codec

    Hi All,
    I'm attempting to deploy a pretty strait forward web application (wrapped in an EAR) that includes commons-codec-1.2.jar (used by axis2). The codec jar is included in the WEB-INF\lib directory but doesn't appear to be picked (I get a NoClassDefFoundError) up unless I copy it into the ...\system\appserver\oc4j\j2ee\home\applib directory? I'm guessing this is a weird classloader issue but I can't seem to find the codec jar in another location...
    I can get around the problem but I was wondering if anyone had an explanation?
    Cheers,
    Dan

    Dan,
    You need to set the search-local-classes-first attribute of element web-app-class-loader in file "orion-web.xml" to 'true' (the default is 'false') in order for OC4J to locate the "axis2" classes. Please refer to the White Paper, Classloading in OC4J (PDF):
    http://www.oracle.com/technology/tech/java/oc4j/pdf/ClassLoadingInOC4J_WP.pdf
    Or, if you don't like your Web browser directly opening PDF files (like I don't), there is a link to the White Paper from this Web page:
    http://www.oracle.com/technology/tech/java/oc4j/index.html
    Note however, that in OC4J 10.1.3 the class loading mechanisms are completely different to previous versions (including 10.1.2).
    Good Luck,
    Avi.

  • ConversionManager - Override and Class Loader Issues

    Hi
    We are using Toplink 10.1.3 deployed withiin 10gAS 10.1.3.
    We have overridden the ConversionManger as documented in tips.
    1. MyConversionManager extends ConversionManager.
    2. We have overriden convertObject
    3. We have a pre-login SessionEventAdapter that sets the ConversionManager.
    We have had issues of classloading within the application previously, particularly where we have two versions of our application deployed on the same App Server instance (potentially with differing versions of MyConversionManager).
    For this reason we only set the ConversionManager within the preLogin event on the Session as follows:
    *//Just set the conversion manager for the session.*
    event.getSession().getLogin().getPlatform().setConversionManager(getConversionManager());
    We no longer set the default conversion manager, as my understanding was that this would set it at the root level within the OC4J instance (meaning that each deployment would override the previous).
    Additionally, we have had to sepcify the class loader to use, within the ovverriden convertObject method, as otherwise start up of Toplink falied, as it was unable to solve references to application classes specified within class indicator mappings. We do this as follows:
    *@Override*
    *public Object convertObject(final Object source, final Class javaClass) {*
    super.setShouldUseClassLoaderFromCurrentThread(true);
    The only know issue with this, is that if I try and use OEM to veiw the Toplink Cache, I just get and AnnotatedClassNotFoundException as it is attempting to use the system class loader (that does not contain our Application classes).
    Two questions therefore:
    1. Is the deployment we have now stable, i.e. overriding the class loader within the overriden Conversion Manager, and only loading this against the session??
    2. How can I get mutiple versions of the application to still work, together with being able to view the Toplink Cache from within OE:M.
    Any help or insight, would be greatly appreciated.
    Marc

    Looks fine, you may also wish to investigate using Converters in your mappings instead of customizing the ConversionManager.
    For the OEM issue, try setting the class loader to be your application class loader instead of the thread one, i.e. MyAppClass.getLoader().
    James : http://www.eclipselink.org

  • WebSphere class loading issue

    Hi,
    We ran into this issue and have been trying to resolve since yesterday with no luck. I'm wondering if anybody else has encountered this and has any thoughts ...
    We are trying to call the methods of the com.ibm.websphere.runtime.ServerName class in a utility class that is packaged into a jar and put onto the JVM classpath in WebSphere 6.1. And we are running into NoClassDefFound errors. So we just did Class.forName("com.ibm.websphere.runtime.ServerName") in that utility class and got the ClassNotFoundException as expected. But when we do the same in a separate utility class that is outside of the classpath, both the forName and the actual method calls work without any problem.
    That kind of suggested that the com.ibm.websphere.runtime.ServerName class is not "available"(/loaded) by the time our utility class gets loaded, may be. So we turned on the Verbose Class Loading to see the order in which the classes are loaded when the JVM starts up. But the com.ibm.websphere.runtime.ServerName class is loaded way before our utility class from the jar in the classpath.
    So I'm wondering:
    Why would it give me a ClassNotFound exception in my utility class (which is put on the classpath) when the log shows that the utility class is already loaded by the time this class starts loading?
    Any feedback or thoughts would be greatly appreciated.
    Thanks,
    Bharathi

    Java_Unlimited wrote:
    We could figure out the answer from your responses, thank you guys!
    It is true that our jar is being loaded by a different class loader, to which the ServerName class is not available. Also in one of the articles quoted in the responses, it mentioned specifying the jar in the ws.ext.dirs property, not in the classpath for the ws ext classes to be available to the jar. And that fixed the problem. We defined a custom property ws.ext.dirs and put the jar file in there.
    Thanks everyone!
    Edited by: Java_Unlimited on Feb 6, 2009 10:42 AMBharati, we're glad to help and thanks for lettings us know what you did to make it work.

  • Weblogic Class Loading issue

    Note: I am not sure what is the best suitable subject for this issue.
    Stack Trace:
    Error 1)
    &lt;Dec 30, 2011 11:02:51 AM GMT+05:30&gt; &lt;Error&gt; &lt;HTTP&gt; &lt;BEA-101017&gt; &lt;[ServletContext@29472630[app:EM11X module:Web path:/Web spec-version:2.5], request: weblogic.servlet.internal.ServletRequestImpl@14d05d1[
    POST /Web/GenerateMealPlanAction.do HTTP/1.1
    Via: 1.1 INDCHN-MGMT01
    Cookie: org.ditchnet.jsp.tabs:CommercialFormulaTabs=; org.ditchnet.jsp.tabs:KitchenTabs=; JSESSIONID=sZQFT9MJQc6vS6MCSXtdjWwSTLCcG6nqL12Fdyj1NFHcp4WnpkCB!1348500068
    Referer: http://130.78.88.83:7001/Web/GenerateMealPlanAction.do?vo.viewCode=generateMealPlanFrame&method=1&&menu_id=DS_DFLT&module_id=DS&function_id=DS_GEN_MEAL_PLAN&function_name=Generate%20Meal%20Plan&function_type=R&access=YYYYN&desktopFlag=N&vo.functionId=DS_GEN_MEAL_PLAN
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; InfoPath.1)
    Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
    Accept-Language: en-us
    Pragma: no-cache
    Connection: Keep-Alive
    Content-Length: 488
    ]] Root cause of ServletException.
    java.lang.IllegalArgumentException: Cannot invoke com.vo.GenerateMealPlanVO.setServingDate on bean class 'class com.vo.GenerateMealPlanVO' - argument type mismatch - had objects of type &quot;java.lang.String&quot; but expected signature &quot;com.core.util.Date&quot;
         at org.apache.commons.beanutils.PropertyUtilsBean.invokeMethod(PropertyUtilsBean.java:2181)
         at org.apache.commons.beanutils.PropertyUtilsBean.setSimpleProperty(PropertyUtilsBean.java:2141)
         at org.apache.commons.beanutils.PropertyUtilsBean.setNestedProperty(PropertyUtilsBean.java:1948)
         at org.apache.commons.beanutils.PropertyUtilsBean.setProperty(PropertyUtilsBean.java:2054)
         at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1015)
         Truncated. see log file for complete stacktrace
    Caused By: java.lang.IllegalArgumentException: argument type mismatch
         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:597)
         at org.apache.commons.beanutils.PropertyUtilsBean.invokeMethod(PropertyUtilsBean.java:2155)
         Truncated. see log file for complete stacktrace
    &gt;
    Error 2)
    &lt;Dec 30, 2011 11:11:19 AM GMT+05:30&gt; &lt;Error&gt; &lt;HTTP&gt; &lt;INDCHN-EPORT01&gt; &lt;AdminServer&gt; &lt;[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'&gt; &lt;&lt;WLS Kernel&gt;&gt; &lt;&gt; &lt;&gt; &lt;1325223679258&gt; &lt;BEA-101017&gt; &lt;[ServletContext@29472630[app:EM11X module:Web path:/Web spec-version:2.5], request: weblogic.servlet.internal.ServletRequestImpl@1da8bfe[
    POST /Web/LookupAction.do HTTP/1.1
    Via: 1.1 INDCHN-MGMT01
    Cookie: org.ditchnet.jsp.tabs:CommercialFormulaTabs=; org.ditchnet.jsp.tabs:KitchenTabs=; JSESSIONID=GhG4T9TJ0ytD8dhRSGBFv2c3v1hNLftTTCJQHp6Qn9C5SnMGTVYF!1348500068
    Referer: http://130.78.88.83:7001/Web/core/lookup/jsp/LookupCriteria.jsp?undefined
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; InfoPath.1)
    Accept: */*
    Accept-Language: en-us
    Pragma: no-cache
    Connection: Keep-Alive
    Content-Length: 304
    ]] Root cause of ServletException.
    java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to java.lang.String
         at com.lookup.pojo.web.LookupAction.doActionQuery(LookupAction.java:107)
         at com.core.pojo.web.BaseAction.execute(BaseAction.java:97)
         at org.springframework.web.struts.DelegatingActionProxy.execute(DelegatingActionProxy.java:106)
         at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
         at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
         at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
         at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
         at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
         at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3717)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
         at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
         at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
         at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
         at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
    &gt;
    [b]Analysis:
    Migrating J2EE Application from Oracle 10g Application Server to Oracle 11g Weblogic Server. I am stuck with above two issues. This issue not present while running in Oracle 10g Application Server
    1) I was thinking it is something to do with JSTL versions and the below command is executed to make the JSTL version to jstl 1.1.2
    java weblogic.Deployer -adminurl t3://localhost:7001 -user weblogic -password weblogic -deploy -library D:/Oracle/Middleware/wlserver_10.3/common/deployable-libraries/jstl-1.1.2.war
    The problem remains same.
    2) Now &lt;wls:prefer-web-inf-classes&gt;true&lt;/wls:prefer-web-inf-classes&gt; is added to weblogic.xml to make the Web application to load application specific libraries from WEB-INF/lib directory.
    The problem remains same.
    3) I checked Class Loader Analysis Tool and found conflicting classes and based on CAT recommendation the below list is added to weblogic.xml and &lt;wls:prefer-web-inf-classes&gt;true&lt;/wls:prefer-web-inf-classes&gt; is removed since both cannot co-exist.
         &lt;wls:prefer-application-packages&gt;
                   &lt;wls:package-name&gt;antlr.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;antlr.collections.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;antlr.collections.impl.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;antlr.debug.misc.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;com.mysql.jdbc.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.ejb.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.ejb.spi.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.enterprise.deploy.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.jms.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.management.j2ee.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.resource.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.resource.cci.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.resource.spi.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.security.jacc.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.servlet.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.servlet.http.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.servlet.jsp.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.transaction.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.transaction.xa.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.xml.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.xml.datatype.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.xml.namespace.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.xml.parsers.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.xml.registry.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.xml.transform.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.xml.validation.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;javax.xml.xpath.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.core.lmx.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.core.lvf.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.aq.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.connector.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.dcn.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.diagnostics.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.driver.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.internal.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.oci.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.oracore.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.pool.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.rowset.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.util.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jdbc.xa.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jpub.runtime.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.jsp.provider.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.net.ano.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.net.aso.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.net.jdbc.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.net.jndi.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.net.ns.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.net.nt.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.net.resolver.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.security.o3logon.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.security.o5logon.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.sql.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;oracle.sql.converter.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;org.apache.commons.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;org.apache.derby.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;org.apache.oro.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;org.apache.xerces.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;org.apache.xmlcommons.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;org.gjt.mm.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;org.joda.time.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;org.w3c.dom.*&lt;/wls:package-name&gt;
                   &lt;wls:package-name&gt;org.xml.sax.*&lt;/wls:package-name&gt;
              &lt;/wls:prefer-application-packages&gt;
    The problem remains same.
    Your help is greatly appreciated as I am stuck with this issue.

    No I cannot ignore this error while deplyment. I'm not able to deploy the war.
    More ovet this needs to be working as during startup, the servlet loads some xml files and convert into tables for the kiosk in the airport to be working.
    Edited by: [email protected] on Mar 27, 2009 12:24 PM

  • Oracle Class Loading issue

    Hello All
    I am trying to implement Dbunit in my project. My project uses OAS 10.1.3 and JDK 1.5. I have my dbunit.jar, slf4j-api.jar and slf4j-simple.jar in my shared-library and I have imported them using the class loader while deploying my application. But still I am getting NoclassDefFoundError Missing Dependent class LoggerFactory NotFound.
    Please let me know what could be issue.
    Thanks
    Sri

    Hello All
    I am trying to implement Dbunit in my project. My project uses OAS 10.1.3 and JDK 1.5. I have my dbunit.jar, slf4j-api.jar and slf4j-simple.jar in my shared-library and I have imported them using the class loader while deploying my application. But still I am getting NoclassDefFoundError Missing Dependent class LoggerFactory NotFound.
    Please let me know what could be issue.
    Thanks
    Sri

  • Help! -- different class loader issue

    From within an EJB I am trying to cast a serializable object, that was passed into this EJB, to its original type. The process ended with a ClassCastException, even though I have double checked that the object being casted is of the correct type and fully qualified package path. It turns out that the problem is caused by the involvment of 2 different class loaders -- The class loader that loads the object is not the same one that loads the EJB doing the casting. The thing that confuses me the most is that this program used to work fine without the exception when it was running in an older environment. Is this a VM issue? Do we have control over what class loader to use when load certain classes/objects? What's the fix to the problem?
    Please help!
    Thanks in advance.
    Lifeng

    It is a Java platform version issue. Since Java 2 The classloaders are lay out in a hierarchy. You can read about it in the public chapters of the book "Inside the Java 2 Virtual Machine" by Bill Venners at
    www.artima.com
    This may be helpful for you . It specifies the class loaders used by a thread to load subsequent classes: aThread.setContextClassLoader(aClassLoader)
    Other soulution is to have the object and EJB being loaded by the same class loader, which could be a common parent class loader for the ones that in your code are actually asked to load these objects
    Otherwise, java.lang.reflect can deal with objects whose type is not known by the compiler.

  • Apparent EJB Class Loader Issue

    I am having a problem loading narrowing an EJB. It appears to be a class loader
    problem. I am getting a ClassCastException with the following message: Cannot
    narrow remote object to com.dte.ejb.facade.AccessoryServiceHome.
    Here is my code that looks up the EJB (I've ommitted the 'catch' clauses):
    EJBHome ejbHome = (EJBHome) cache.get(homeClass);
    try {
    Object temp = ctx.lookup("ejb/" + homeClass.getName());
    if (ejbHome == null) {
    ejbHome = (EJBHome) PortableRemoteObject.narrow(temp, homeClass);
    cache.put(homeClass, ejbHome);
    Here is the output of some debugging information from the above method. Here I've
    displayed the class.getName and the class.getClassLoader for the Class object
    passed to this method and the remote object being cast by the narrow method:
    homeClass : com.dte.ejb.facade.AccessoryServiceHome
    homeClass : weblogic.utils.classloaders.ChangeAwareClassLoader@29164c finder:
    weblogic.utils.classloaders.MultiClassFinder@300ec4
    From Lookup: com.dte.ejb.facade.AccessoryServiceBean_krx5el_HomeImpl
    From Lookup: weblogic.utils.classloaders.GenericClassLoader@1ea02f finder: weblogic.utils.classloaders.MultiClassFinder@6fca08
    As you can see, the Class passed into this method has been loaded with the ChangeAwareClassLoader
    but the HomeImpl class was loaded with the GenericClassLoader. I think that is
    the problem (please correct me if I am wrong).
    The application in question is an .ear with 2 .war modules and a ejb.jar file.
    It was my understanding that all classes needed by any module in a .ear were all
    loaded with the same class loader. Is this true? If so, then why am I having this
    problem?
    Thank you in advance for your help.

    I just want to add few comments hoping the iPlanet engineer will be able to help me.
    I mange to get one deployment of a war file with the client weblogic EJB to work; only if I add the Installation Directory path of the war file plus &#8220;web-inf/classes&#8221; to the classpath of the JVM configuration.
    This tells me that the class loader looks for the JVM classpath to load the EJB home class at run time. I think; if I can make iPlanet class loader to look for the application classpath instead of the JVM my problem will go away.
    Thank you in advance,
    Nad

  • MBean calling ejb class loading issue

    Hi,
    I would like to have an mbean call an ejb. I have come against a (predictable!!)
    class loading problem. The EJB Home cant be bundled with the mbean because the
    mbean class loader would load the interface, preventing ejb reload( Thats what
    the error msg indicates) and the ejb doesnt get deployed.
    I have moved to an mlet based scheme (beacuse an mlet is a class loader) to
    load the mbeans, but now I have the problem that when the mbean looks up the
    home in jndi the cast fails ie the jndi object has an interface class loaded by
    the ejb class loader but the mlet has its own loaded home interface. These class
    loaders appear to be sibblings - but I havnt printed out the trees.
    This is WLS 702 which seems to be JMX 1.1. Has anyone got a way around this?
    Have I invented a problem that doesnt exist? I cant go to WLS8.
    My current way forward is to have the mbean find the class loader that loaded
    the interface class (jndi object) and then have the mbean use that class loader
    to load its copy of the interface class. Seems a bit complex. Im sure I missed
    something obvious.
    Thanks
    Pete Marshall

    Pete,
    could you explain better your thoughts...
    I'm interested to hear them.
    regards,
    Pedro Salazar.
    Pete Marshall wrote:
    Must think before typing..
    If I have the ejb register a listener on the mbean and have the mbean emit an
    event the detyped notification from the mbean will break the link between the
    mbean class loader and the ejb loader. I think ;-) Ill try it.
    Pete
    "Pete Marshall" <[email protected]> wrote:
    Hi,
    I would like to have an mbean call an ejb. I have come against a (predictable!!)
    class loading problem. The EJB Home cant be bundled with the mbean because
    the
    mbean class loader would load the interface, preventing ejb reload( Thats
    what
    the error msg indicates) and the ejb doesnt get deployed.
    I have moved to an mlet based scheme (beacuse an mlet is a class loader)
    to
    load the mbeans, but now I have the problem that when the mbean looks
    up the
    home in jndi the cast fails ie the jndi object has an interface class
    loaded by
    the ejb class loader but the mlet has its own loaded home interface.
    These class
    loaders appear to be sibblings - but I havnt printed out the trees.
    This is WLS 702 which seems to be JMX 1.1. Has anyone got a way around
    this?
    Have I invented a problem that doesnt exist? I cant go to WLS8.
    My current way forward is to have the mbean find the class loader that
    loaded
    the interface class (jndi object) and then have the mbean use that class
    loader
    to load its copy of the interface class. Seems a bit complex. Im sure
    I missed
    something obvious.
    Thanks
    Pete Marshall

  • Class Loader Issues

    I am dynamically creating .class files on the fly in my application. Often I need to rebuild the same class (including client classes) multiple times. The problem is that the system ClassLoader keeps the 1st .class file in memory and will not return to the disk to retrieve the new version after the class file(s) have changed.
    Do I need to write a new Classloader and substitute it for the main systems class loader? Is there a better way to instantiate the class other than Class.forName( blah ) that will solve this problem?
    Thanks,
    -Jeff Harman

    Like we told you. If the code for a class changes, Java will not automatically notice and load the new version, until you start up the JVM again. If you do not want to re-start the VM, you can create a new ClassLoader (CL), and use it to load the new code for the class.
    Now, the problem is, the second CL may think it has to reload many of other classes, since it has no record of loading them itself. You will end up with duplicates of many classes.
    If that doesn't suit you, there is not much alternatives.
    You could rename the new version of the class, which would mean you'd have to manually track down all the old versions and upgrade them ( by using the new Ctor). You'd then have to update all the references to make them point to the new object. You can make that particular job easier by making both classes (old and new) extend a common base class, or implements the same interface, and use the interface reference (i.e program to an interface).
    Another less-than-perfect possibility would be to use serialization where you serialise version-marked objects and reconstitute them with new code...
    Good luck.

  • Weblogic Class Loader issues.

    Hi all!
    Let me explain my problem.
    I have an EJB which has in its same Java package some support classes
    & also a startup class. I created an EJB jar file (containing the home,
    remote, bean, the deployment descriptors & the container generated stubs)
    for deployment. I also compiled all the support classes & the startup class
    into the /weblogic/myserver/serverclasses directory. I also added the
    required entries in the weblogic.properties file for the startup class.
    Now the problem is that the support classes & the startup class contain
    methods & constructors which have package level access (i.e the default
    access in Java). At runtime, when my bean tries to access one of these
    methods, an IllegalAccessException is thrown.
    I understand that this exception is thrown when one tries to access a
    method which should not be accessed (like private/protected/cross-package
    access). However, both the EJB & these classes are in the same package.
    So this should not be thrown.
    Now the next thing I thought is that the EJB & the support classes are
    being loaded by 2 different classloaders. I guess the classes under
    /weblogic/myserver/serverclasses are being loaded by the WebLogic
    Server ClassLoader & the EJB bean classes are being loaded by the
    specialized EJB ClassLoader.
    Now my question is,
    1) Is it the case that the WebLogic Server does not recognize that the
    EJB Bean class is in the same package as the support classes because
    they are loaded by 2 separate class loaders? Please note that the EJB
    jar file does not contain any support classes - so there is no
    duplicate classes here.
    2) Is this a bug?
    3) What should I do to prevent this problem?
    Some workarounds that I have done are:
    1) Copied the Bean.class (implementation class of EJB bean) into the
    serverclasses directory. Now the server does not throw any
    IllegalAccessException. -- This, however, does not appeal as a solution
    since it looks like the Bean class is now being loaded by the WebLogic
    Class Loader instead of from the EJB jar file.
    2) I changed all the default package access methods to public methods.
    Works like a charm. -- Problem is that this is a third party set of classes
    which I would like to avoid modifying.
    Hope this is not too confusing. Please let me know if you need any further info.
    Thanks much in advance,
    --Das

    You have to tell WLAS where to load your new classes. You can change
              workingDir of your JSP configuration in weblogic.properties to point to your
              new class directory.
              Cheers - Wei
              Hyung-Jin Kim <[email protected]> wrote in message
              news:[email protected]..
              > It seems that if I compile a class that a JSP uses while Weblogic is
              > running, Weblogic's class loader has this nasty habit of caching/writing
              > the class that already has loaded into memory into:
              >
              > weblogic/myServer/classfiles
              >
              > Weblogic then refers to the older class file under the above directory
              > when the server is started again. Is there any way to turn this "class
              > loader caching" off in Weblogic? Thanks!
              >
              > -hjk
              >
              

  • Re: MBean calling ejb class loading issue

    Must think before typing..
    If I have the ejb register a listener on the mbean and have the mbean emit an
    event the detyped notification from the mbean will break the link between the
    mbean class loader and the ejb loader. I think ;-) Ill try it.
    Pete
    "Pete Marshall" <[email protected]> wrote:
    >
    Hi,
    I would like to have an mbean call an ejb. I have come against a (predictable!!)
    class loading problem. The EJB Home cant be bundled with the mbean because
    the
    mbean class loader would load the interface, preventing ejb reload( Thats
    what
    the error msg indicates) and the ejb doesnt get deployed.
    I have moved to an mlet based scheme (beacuse an mlet is a class loader)
    to
    load the mbeans, but now I have the problem that when the mbean looks
    up the
    home in jndi the cast fails ie the jndi object has an interface class
    loaded by
    the ejb class loader but the mlet has its own loaded home interface.
    These class
    loaders appear to be sibblings - but I havnt printed out the trees.
    This is WLS 702 which seems to be JMX 1.1. Has anyone got a way around
    this?
    Have I invented a problem that doesnt exist? I cant go to WLS8.
    My current way forward is to have the mbean find the class loader that
    loaded
    the interface class (jndi object) and then have the mbean use that class
    loader
    to load its copy of the interface class. Seems a bit complex. Im sure
    I missed
    something obvious.
    Thanks
    Pete Marshall

    Pete,
    could you explain better your thoughts...
    I'm interested to hear them.
    regards,
    Pedro Salazar.
    Pete Marshall wrote:
    Must think before typing..
    If I have the ejb register a listener on the mbean and have the mbean emit an
    event the detyped notification from the mbean will break the link between the
    mbean class loader and the ejb loader. I think ;-) Ill try it.
    Pete
    "Pete Marshall" <[email protected]> wrote:
    Hi,
    I would like to have an mbean call an ejb. I have come against a (predictable!!)
    class loading problem. The EJB Home cant be bundled with the mbean because
    the
    mbean class loader would load the interface, preventing ejb reload( Thats
    what
    the error msg indicates) and the ejb doesnt get deployed.
    I have moved to an mlet based scheme (beacuse an mlet is a class loader)
    to
    load the mbeans, but now I have the problem that when the mbean looks
    up the
    home in jndi the cast fails ie the jndi object has an interface class
    loaded by
    the ejb class loader but the mlet has its own loaded home interface.
    These class
    loaders appear to be sibblings - but I havnt printed out the trees.
    This is WLS 702 which seems to be JMX 1.1. Has anyone got a way around
    this?
    Have I invented a problem that doesnt exist? I cant go to WLS8.
    My current way forward is to have the mbean find the class loader that
    loaded
    the interface class (jndi object) and then have the mbean use that class
    loader
    to load its copy of the interface class. Seems a bit complex. Im sure
    I missed
    something obvious.
    Thanks
    Pete Marshall

Maybe you are looking for

  • "The selected topic is currently unavailable"in iPhoto help

    I get the message in quotes on everything when I selet Help from an application menu. I get a menu of help items but when I select an item from that menu, I get the message. I have gone to that same menu in another way(I don't remember how I got ther

  • Please insert disk CS6 MstrColl 2 to continue

    I have mounted CS6 MstrColl 2, and it is showing in Windows Explorer, and yet Adobe CS6 intallation cannot see it, and never gets the product installed. I have tried mounting with both Daemon Tools and Virtual Clone Drive, and the same issue occurs.

  • Import video via iMovie and play iTunes simultaneously...?

    Yo there, Mac forum! I'm a new Mac user and am pretty dang psyched to be posting my first question. I love my new PowerBook. woo! So I'm in an improv comedy troupe and I use the PowerBook to play music and sound effects during our shows. I also video

  • Encore in Prem pro CS3

    Have spent a while looking how to get encore to work in my downloaded trial copy of Prem pro CS3 I have put in markers when I go to export Encore is light greyed out and not in dark grey am I missing something??

  • I am having trouble changing my billing info

    Here is my problem, My mom is in charge of my itunes account and authorized my itunes on my computer. It registers as her account, but the billing info is not correct. She corrected it from her computer and it is working from her computer, iphone, an