Class loading in WebLogic 7.0

Hi,
My Enterprise application contains personalInfoController.war file and personalInfoEJB.jar file. One class in .war depends on classes in .jar. I set Class-Path in Manifest.mf for both of them:
Manifest-Version: 1.0
Created-By: 1.3.1 (Sun Microsystems Inc.)
Class-Path: personalInfoController.war personalInfoEJB.jar
But when I try to start up WebLogic, it complains that can not find the class on which .war depends:
java.lang.NoClassDefFoundError: infomation.PersonalInfoHome>
<Aug 16, 2002 4:20:02 PM PDT> <Error> <HTTP> <101216> <Servlet: "PersonalInfoCon
troller" failed to preload on startup in webapp: "personalInfoController"
javax.servlet.ServletException: [ServletContext(id=3269283,name=personalInfoCont
roller,context-path=/personalInfoController)]: Servlet class PersonalInfoControl
ler for servlet PersonalInfoController could not be loaded because a class on wh
ich it depends was not found in the classpath E:\bea\user_projects\mydomain\myse
rver\stage\_appsdir_personalInfoController_war\personalInfoController.war;E:\bea
\user_projects\mydomain\.\myserver\.wlnotdelete\_appsdir_personalInfoController_
war_personalInfoController_3269283\jarfiles\cls63471.jar.
java.lang.NoClassDefFoundError: infomation.PersonalInfoHome
at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubI
mpl.java:701)
at weblogic.servlet.internal.WebAppServletContext$ServletInitAction.run(
Can anybody gives hint? Thx

The war and ejb-jar files are in separate ClassLoaders, so there's no way for them to "see" each other. What you need to do is make a separate "client" jar for inclusion into the WEB-INF/lib directory of the war file. This client jar should contain, generally, the Home and Remote interfaces to any EJBs, any data objects that are passed between the JSPs/servlets in the war and the EJBs, and any custom Exceptions.
An alternative is to put both the ejb-jar file and the war into an EAR file. Tyler Jewell (did I spell that right?), one of the BEA gurus, has an excellent article on app server ClassLoaders at http://www.onjava.com from last June or July.

Similar Messages

  • Dynamic Class Loading in Weblogic Workshop

    Hi, I am developing a web service with weblogic workshop. The JWS file references
    other classes one of which is a factory for distributing various implementations
    of an interface. I am trying to dynamically load the relevant class to be distributed
    from the factory via its name, e.g. Class c = Class.forName(className)
    However I keep getting a classNotFoundException. The class exists in the same
    package as the factory. I can insantiate the class in the normal way, i.e new
    ClassName(); but cant seem to dynamically load it via its name. However I have
    found that if I declare a private member of that type in the Factory but do nothing
    with it, I can then dynamically create the class. However I dont really want
    to do this for every type that the factory can create
    Any ideas ??

    Graeme,
    Could you please send us a relevant snippet of the JWS and your factory
    class, to clarify the issue and help us replicate it here.
    Thanks,
    Anurag
    "Graeme Dougal" <[email protected]> wrote in message
    news:3e799b78$[email protected]..
    >
    Hi, I am developing a web service with weblogic workshop. The JWS filereferences
    other classes one of which is a factory for distributing variousimplementations
    of an interface. I am trying to dynamically load the relevant class to bedistributed
    from the factory via its name, e.g. Class c = Class.forName(className)
    However I keep getting a classNotFoundException. The class exists in thesame
    package as the factory. I can insantiate the class in the normal way,i.e new
    ClassName(); but cant seem to dynamically load it via its name. However Ihave
    found that if I declare a private member of that type in the Factory butdo nothing
    with it, I can then dynamically create the class. However I dont reallywant
    to do this for every type that the factory can create
    Any ideas ??

  • Issue in class loading in weblogic 10.3

    Hi,
    let me explain the problem.
    I have a jar file called table.jar in WEB-INF/lib folder. I'm able to deply the war file on weblogic 9.2. But when I'm trying to deploy the same war on 10.3 it gives and error while deployment:
    Servlet: "StartupSetup" failed to preload on startup in Web application: "ebc.war". java.lang.NoClassDefFoundError: com/united/common/util/table/xmlBean/TableDocument$Factory
    but this class is present in the table.jar which is in the WIB-INF/lib

    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

  • Class loading analyzing tool not working

    I want to enable class loading in weblogic so I deployed wls-cat.war to the server. When I test the war I get Error 503 Unavailable service.Please let me know what is to be done.

    Hi,
    If your domain is running in development mode the application being an internal application is deployed automatically on on-demand first time access. If you have manually deployed it then undeploy it. When domain is running in production mode then you have to deploy it manually just like any other war application.

  • EJB Class loader and regular Java files class loader.

    Hi,
    Is the EJB's class loader the same as a "regular" java files class loader OR weblogic
    has 2 class loaders, one for each???
    Thanks,
    les.

    les <[email protected]> wrote:
    Hi,
    Is the EJB's class loader the same as a "regular" java files class loader OR weblogic
    has 2 class loaders, one for each???Yes. Exact classloading architecture depends on which WebLogic version you use. If you
    use 6.x+, you may want to read this article:
    http://www.onjava.com/pub/a/onjava/2001/07/25/ejb.html
    Thanks,
    les.--
    Dimitri

  • Class Loader Hierarchy in Weblogic 7.0

    I have read the BEA documentation on the class loader hierarchy in Weblogic Server,
    and I have some questions regarding some behavior I am seeing.
    I am running Weblogic Server 7.0.
    I have an ear file that contains 3 web apps (wars) and several utility jars. The
    web apps' manifests contain the Class-Path entry for the utility jars. My understanding
    of this is that each web app SHOULD have its own class loader. Also, the utility
    jars will be scoped in a separate class loader and WILL NOT have visibility to
    the web app classes. The web app classes should have visibility to the utility
    jars.
    Is this correct????
    I added a static segment of code in each web app and printed the class loader
    for each servlet when it was loaded. I also printed the class loader from a class
    that is DEFINITELY contained in one of the utility jars. Here is the result:
    Utility Class ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Utility Class
    Parent ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
    Servlet 1 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet 1 Parent
    ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
    Servlet 2 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet 2 Parent
    ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
    I'm a little confused.... I expected to see 3 different class loaders (i.e. one
    for each class above). I believe the above printout says that all 3 classes are
    being loaded by the SAME class loader instance (Launcher$AppClassLoader@b9d04).
    Am I interpreting this correctly? If so, what's going on?

    I rechecked the classpath for the user that starts Weblogic, and in the classpath
    I found the project "src" directory (must have missed it earlier). When we did
    our build, the classes are placed in the src structure then copied to the build
    area. That's the reason I was not seeing the appropriate class loader hierarchy.
    Thanks for all of the comments.
    "Sanjeev Chopra" <[email protected]> wrote:
    >
    "Mark Cotherman" <[email protected]> wrote in message
    news:[email protected]...
    Thanks for your comments again Mark. I'm just trying to get a goodhandle
    on how
    this is working.
    I'll assume that somehow my web app classes are being loaded into theroot
    classloader.
    The next question is... why??Just to be sure - is there any way these classes are sneaking into the
    system classpath ?
    My ear file contains the following:
    a.war
    b.war
    c.war
    lib/util1.jar
    lib/util2.jar
    lib/util3.jar
    lib/util4.jar
    The manifest in all three wars reference all util jars. This ear deployssuccessfully
    on Weblogic with no errors.
    How could these separate servlets (one in each war) not have seperateclass loaders
    seperate from the root where the utils should reside. I don't thinkthat
    I have
    any control over where Weblogic loads the war classes, or do I?
    See comments below....
    Mark Spotswood <[email protected]> wrote:
    Mark Cotherman wrote:
    Thanks for the follow-up.
    I want to make sure I follow what you are saying. All classes in
    the
    manifest
    Class-Path of WARs are exported to the parent classloader.That's right.
    To me this is the correct behavior since the manifest Class-Path
    is
    meant to provide
    a way to share common utility classes among several web apps. AllEJB jars and
    manifest Class-Path entries should be loaded by the same class loader.Its a way to share class definitions, but not necessarilly class
    instances. I don't think that a web application should be extending
    the classpath of its parent's classloader. This leads to namespace
    problems as well as reloadability issues.
    Ok, you lost me here. Shouldn't delegation handle the namespacecollisions??
    If the web app class loader has a class definition (webapp:com.xyz.ClassA) with
    exactly the same name in the same package as the root class loader(rootloader:
    com.xyz.ClassA), I thought the web app would use (delegate loading)the
    class
    definition from the root class loader when PreferWebInf is set to false.
    Isn't this why the PreferWebInf attribute, when set to true, can causeClassCastExceptions??
    The web app when creating an instance of (webapp: com.xyz.ClassA)from
    the web
    app class loader can potentially pass a reference to this instanceto a
    class
    instance loaded from the root loader. The root class loader has adifferent class
    definition for ClassA.
    REALLY what makes since is that all common jar files be defined
    in
    the manifest
    Class-Path OF THE ear FILE (if the WAR(s) are in an ear). These
    jar
    files should
    then be loaded by the same class loader as the EJB jars. There shouldbe no need
    for the WARs to have any reference to the utility jars since the
    EJB
    class loader
    is the parent of the WAR class loaders.The ear file doesn't have a manifest classpath, but what you are getting
    at makes sense. If you add a manifest to any EJBs in your app, theall
    webapps (as well as all other EJBs) will be able to see it, sincewith
    our structure, EJBs are loaded into the application's root classloader.
    My problem is that the ACTUAL SERVLET classes are NOT being loadedby a separate
    class loader from the EJB and common jar class loader. This is
    completely
    against
    what is being said in the Weblogic documentation. The Manifest
    Class-Path
    should
    have nothing to do with where the classes that reside in
    WEB-INF/classes
    of my
    servlet are loaded.Classloaders will ask their parent for the class first before loading
    it
    themselves. So if the parent classloader somehow has visibility to
    classes that your webpapp references, then it will get loaded by the
    parent classloader.
    I am in the middle of migrating an app from an older version of
    Weblogic,
    and
    it would be helpful to have the ACTUAL class loading hierarchy welldocumented.
    The basic hierarchy is all EJBs are in a root shared classloader and
    each web application is loaded by a classloader that is a child of
    that root.
    Again, am I missing something here???My suspicion is that somehow these servlets are in the classpath ofthe
    root classloader, so when the webapp classloaders delegate to thatone,
    it will come up with the class.
    mark
    Mark Spotswood <[email protected]> wrote:
    I believe what you are seeing is a bug in the servlet container.
    The classloader organization is what you expect, but each webapp
    is exporting the classpath information from its manifest to the
    classloader above its classloader (which is common to all
    three webapps) rather than to its own classloader. So because
    of the delegation that happens with classloading, the common
    parent classloader is the one that loads the class.
    I believe that this behavior exists as an attempt to avoid
    ClassCastExceptions, but I don't think that it is the right
    solution to this problem. In our 8.1 release, this behavior
    has been changed. That is, web applications no longer export
    manifest classpath information to the parent of their classloader.
    This change has not been ported back to the 7.x line, but a bug
    report has been created (CR099889). You should be able to follow
    up with support with this CR number.
    mark
    Mark Cotherman wrote:
    I have read the BEA documentation on the class loader hierarchy
    in
    Weblogic Server,
    and I have some questions regarding some behavior I am seeing.
    I am running Weblogic Server 7.0.
    I have an ear file that contains 3 web apps (wars) and several
    utility
    jars. The
    web apps' manifests contain the Class-Path entry for the utility
    jars.
    My understanding
    of this is that each web app SHOULD have its own class loader.
    Also,
    the utility
    jars will be scoped in a separate class loader and WILL NOT have
    visibility
    to
    the web app classes. The web app classes should have visibility
    to
    the utility
    jars.
    Is this correct????
    I added a static segment of code in each web app and printed the
    class
    loader
    for each servlet when it was loaded. I also printed the class loaderfrom a class
    that is DEFINITELY contained in one of the utility jars. Here is
    the
    result:
    Utility Class ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04
    Utility
    Class
    Parent ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
    Servlet 1 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet1 Parent
    ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
    Servlet 2 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet2 Parent
    ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
    I'm a little confused.... I expected to see 3 different class loaders(i.e. one
    for each class above). I believe the above printout says that all
    3
    classes are
    being loaded by the SAME class loader instance
    (Launcher$AppClassLoader@b9d04).
    Am I interpreting this correctly? If so, what's going on?

  • WebLogic class loading conflict causing ClassCastException

    Hi everyone,
    I am using Oracle XML Parser v2 for my JCA adapter and I am getting the following exception when method from my adapter is invoked.
    java.lang.ClassCastException: weblogic.xml.jaxp.RegistryDocumentBuilderFactory cannot be cast to oracle.xml.jaxp.JXDocumentBuilderFactory
    I have already placed Oracle XML Parser v2 library (xmlparserv2.jar) inside $DOMAIN_DIR/lib. Below is the line that throws above exception.
    JXDocumentBuilderFactory factory =(JXDocumentBuilderFactory)JXDocumentBuilderFactory.newInstance();
    So it seems like WebLogic is using different JXDocumentBuilderFactory and there seems to be problem with class loading. How can I resolve this issue? Thanks in advance.
    Regards,
    K.H
    Edited by: K Hein on Dec 16, 2010 12:38 AM

    HI,
    You can use Class Loader Filtering feature of WebLogic to isolate the Classloaders....as described in the following link: http://middlewaremagic.com/weblogic/?page_id=192
    Thanks
    Jay SenSharma
    http://middlewaremagic.com/weblogic (Middleware Magic Is Here)

  • Cocoon2 weblogic (5.1 sp6) class loader security problem

    Hello folks,
    System:
    Cocoon: v2.0
    JDK: Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C),
    Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
    OS: NT4 SP5
    Servlet: v2.2
    AppServer: Weblogic 5.1 SP6
    Symptoms:
    I've updated our application from Cocoon 1.7.4 to Cocoon2. After I
    figured out what libraries I need on the Weblogic's classpath, I managed
    to envoke the MyServlet (MyServlet extends CocoonServlet). The technique
    I am using is the one I used with the Cocoon v1.7.4: extend Cocoon
    servlet and wrap the HttpServletRequest in MyRequest to provide the XML
    content. I changed the line <map:generators default="request"> in
    sitemap.xmap to specify the location of the source. Configuration files
    seem to be read correctly and the file
    <myWebAppContext>/WEB-INF/_tmp_war/org/apache/cocoon/www/sitemap_xmap.java
    is generated (but there is no class file generated)!
    I looked at the cocoon.log file and looks like a class loader security
    problem: the \WEB-INF\_tmp_war gets locked! Is there any workaround this
    problem? Any help is much appreciated!
    cocoon.log file generated:
    DEBUG 62 [cocoon  ] (ExecuteThread-11): Using configuration file:
    /cocoon.xconf
    INFO 62 [cocoon  ] (ExecuteThread-11): Reloading from:
    file:D:/Programs/cocoon-1.8.2/samples/cocoon.xconf
    DEBUG 93 [cocoon  ] (ExecuteThread-11): New Cocoon object.
    DEBUG 93 [cocoon  ] (ExecuteThread-11): Using parser:
    org.apache.cocoon.components.parser.JaxpParser
    DEBUG 109 [cocoon  ] (ExecuteThread-11): Creating Repository with
    this directory: D:\programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
    DEBUG 109 [cocoon  ] (ExecuteThread-11): Classpath =
    D:\Programs\cocoon-1.8.2\samples\WEB-INF\classes;D:\Programs\cocoon-1.8.2\samples\WEB-INF\lib\javac.jar;D:\avue\lib\servlet.jar;D:\avue\lib\jaxp.jar;D:\avue\lib\xerces.jar;D:\avue\lib\xalan.jar;D:\avue\lib\cocoon.jar;D:\avue\lib\avalonapi.jar;D:\avue\lib\logkit.jar;D:\avue\lib\maybeupload.jar;D:\avue\lib\jakarta-regexp-1.2.jar;D:\avue\lib\jstyle.jar;D:\avue\lib\javac.jar;D:\weblogic\lib\weblogic510sp6boot.jar;D:\weblogic\classes\boot;
    DEBUG 109 [cocoon  ] (ExecuteThread-11): Work directory =
    D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
    DEBUG 125 [cocoon  ] (Thread-0): ComponentFactory creating new
    instance of org.apache.cocoon.components.parser.JaxpParser.
    DEBUG 140 [cocoon  ] (Thread-0): ComponentFactory creating new
    instance of org.apache.cocoon.components.parser.JaxpParser.
    DEBUG 140 [cocoon  ] (Thread-0): ComponentFactory creating new
    instance of org.apache.cocoon.components.parser.JaxpParser.
    DEBUG 140 [cocoon  ] (Thread-0): ComponentFactory creating new
    instance of org.apache.cocoon.components.parser.JaxpParser.
    DEBUG 390 [cocoon  ] (ExecuteThread-11): Root configuration:
    cocoon
    DEBUG 390 [cocoon  ] (ExecuteThread-11): Configuration version:
    2.0
    DEBUG 390 [cocoon  ] (ExecuteThread-11): Setting up components...
    DEBUG 406 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.parser.Parser =
    org.apache.cocoon.components.parser.JaxpParser)
    DEBUG 406 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.language.generator.ProgramGenerator =
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl)
    DEBUG 406 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.url.URLFactory =
    org.apache.cocoon.components.url.URLFactoryImpl)
    DEBUG 406 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.saxconnector.SAXConnector =
    org.apache.cocoon.components.saxconnector.NullSAXConnector)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.avalon.util.datasource.DataSourceComponentSelector =
    org.apache.cocoon.components.CocoonComponentSelector)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.avalon.util.pool.PoolController =
    org.apache.cocoon.components.ComponentPoolController)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.language.programming.ProgrammingLanguageSelector
    = org.apache.cocoon.components.CocoonComponentSelector)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.language.markup.MarkupLanguageSelector =
    org.apache.cocoon.components.CocoonComponentSelector)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.store.Store =
    org.apache.cocoon.components.store.MemoryStore)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.classloader.ClassLoaderManager =
    org.apache.cocoon.components.classloader.ClassLoaderManagerImpl)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Setting up the sitemap.
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Sitemap location =
    sitemap.xmap
    DEBUG 703 [cocoon  ] (ExecuteThread-11): ComponentFactory creating
    new instance of org.apache.cocoon.components.url.URLFactoryImpl.
    DEBUG 703 [cocoon  ] (ExecuteThread-11): Getting the URLFactories
    DEBUG 703 [cocoon  ] (ExecuteThread-11): for protocol:
    resource org.apache.cocoon.components.url.ResourceURLFactory
    DEBUG 718 [cocoon  ] (ExecuteThread-11): for protocol: context
    org.apache.cocoon.components.url.ContextURLFactory
    DEBUG 718 [cocoon  ] (ExecuteThread-11): Beginning sitemap
    regeneration
    DEBUG 718 [cocoon  ] (ExecuteThread-11): Making URL from
    file:/D:/Programs/cocoon-1.8.2/samples/sitemap.xmap
    DEBUG 718 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.
    DEBUG 718 [cocoon  ] (Thread-1): Could not find ComponentHandler,
    attempting to create one for role:
    org.apache.cocoon.components.language.generator.ServerPagesSelector
    DEBUG 718 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.language.generator.GeneratorSelector.
    DEBUG 718 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.
    DEBUG 718 [cocoon  ] (Thread-1): CocoonComponentSelector setting
    up with root element:
    DEBUG 718 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of org.apache.cocoon.components.CocoonComponentSelector.
    DEBUG 718 [cocoon  ] (Thread-1): CocoonComponentSelector setting
    up with root element: markup-languages
    DEBUG 734 [cocoon  ] (Thread-1): Adding
    org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage for
    xsp
    DEBUG 734 [cocoon  ] (Thread-1): Adding
    org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage
    for sitemap
    DEBUG 734 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of org.apache.cocoon.components.CocoonComponentSelector.
    DEBUG 734 [cocoon  ] (Thread-1): CocoonComponentSelector setting
    up with root element: programming-languages
    DEBUG 750 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.language.programming.java.JavaLanguage.
    DEBUG 750 [cocoon  ] (Thread-1): Looking up
    org.apache.cocoon.components.classloader.ClassLoaderManager
    DEBUG 750 [cocoon  ] (Thread-1): Setting the parameters
    DEBUG 750 [cocoon  ] (Thread-1): Adding
    org.apache.cocoon.components.language.programming.java.JavaLanguage for
    java
    DEBUG 765 [cocoon  ] (Thread-1): The instance was not accessible,
    creating it now.
    DEBUG 765 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
    DEBUG 1718 [cocoon  ] (Thread-1): Making URL from
    jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
    DEBUG 1718 [cocoon  ] (Thread-1): Logicsheet
    Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
    WARN 4109 [cocoon  ] (Thread-1): Could not load class for program
    'org\apache\cocoon\www\sitemap_xmap'
    java.security.AccessControlException: access denied
    (java.io.FilePermission
    \D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
    at
    java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
    at
    java.security.AccessController.checkPermission(AccessController.java:399)
    at
    java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
    at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
    at
    java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
    at
    java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
    at
    org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
    at
    org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
    at
    org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 4109 [cocoon  ] (Thread-1): Language Exception
    org.apache.cocoon.components.language.LanguageException: Could not load
    class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
    java.security.AccessControlException: access denied
    (java.io.FilePermission
    \D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
    at
    org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
    at
    org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 4109 [cocoon  ] (Thread-1): ComponentFactory decommissioning
    instance of
    org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
    DEBUG 4109 [cocoon  ] (Thread-1): Can't load ServerPage
    org.apache.avalon.ComponentManagerException: Could not add component for
    class: org.apache.cocoon.www.sitemap_xmap
    at
    org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
    at
    org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:172)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 4109 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
    DEBUG 4359 [cocoon  ] (Thread-1): Making URL from
    jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
    DEBUG 4359 [cocoon  ] (Thread-1): Logicsheet
    Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
    WARN 6109 [cocoon  ] (Thread-1): Could not load class for program
    'org\apache\cocoon\www\sitemap_xmap'
    java.security.AccessControlException: access denied
    (java.io.FilePermission
    \D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
    at
    java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
    at
    java.security.AccessController.checkPermission(AccessController.java:399)
    at
    java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
    at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
    at
    java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
    at
    java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
    at
    org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
    at
    org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
    at
    org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 6109 [cocoon  ] (Thread-1): Language Exception
    org.apache.cocoon.components.language.LanguageException: Could not load
    class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
    java.security.AccessControlException: access denied
    (java.io.FilePermission
    \D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
    at
    org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
    at
    org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 6109 [cocoon  ] (Thread-1): ComponentFactory decommissioning
    instance of
    org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
    ERROR 6109 [cocoon  ] (Thread-1): Error compiling sitemap
    org.apache.avalon.ComponentManagerException: Could not add component for
    class: org.apache.cocoon.www.sitemap_xmap
    at
    org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
    at
    org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:219)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 6109 [cocoon  ] (ExecuteThread-11): Changing Cocoon
    context(sitemap.xmap) to prefix()
    DEBUG 6109 [cocoon  ] (ExecuteThread-11): from
    context(file:/D:/Programs/cocoon-1.8.2/samples/) and prefix()
    DEBUG 6109 [cocoon  ] (ExecuteThread-11): at URI
    DEBUG 6109 [cocoon  ] (ExecuteThread-11): New context is
    file:/D:/Programs/cocoon-1.8.2/samples/
    ERROR 6140 [cocoon  ] (ExecuteThread-11): Problem with servlet
    org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is
    not available.
    at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:106)
    at org.apache.cocoon.Cocoon.process(Cocoon.java:218)
    at
    org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:417)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:123)
    at
    weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:761)
    at
    weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:708)
    at
    weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:252)
    at
    weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:346)
    at
    weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)
    INFO 6187 [cocoon  ] (ExecuteThread-11): '' Processed by Apache
    Cocoon 2.0a4 in 5.75 seconds.
    ================================================================
    Regards,
    Georgi

    Hello folks,
    System:
    Cocoon: v2.0
    JDK: Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C),
    Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
    OS: NT4 SP5
    Servlet: v2.2
    AppServer: Weblogic 5.1 SP6
    Symptoms:
    I've updated our application from Cocoon 1.7.4 to Cocoon2. After I
    figured out what libraries I need on the Weblogic's classpath, I managed
    to envoke the MyServlet (MyServlet extends CocoonServlet). The technique
    I am using is the one I used with the Cocoon v1.7.4: extend Cocoon
    servlet and wrap the HttpServletRequest in MyRequest to provide the XML
    content. I changed the line <map:generators default="request"> in
    sitemap.xmap to specify the location of the source. Configuration files
    seem to be read correctly and the file
    <myWebAppContext>/WEB-INF/_tmp_war/org/apache/cocoon/www/sitemap_xmap.java
    is generated (but there is no class file generated)!
    I looked at the cocoon.log file and looks like a class loader security
    problem: the \WEB-INF\_tmp_war gets locked! Is there any workaround this
    problem? Any help is much appreciated!
    cocoon.log file generated:
    DEBUG 62 [cocoon  ] (ExecuteThread-11): Using configuration file:
    /cocoon.xconf
    INFO 62 [cocoon  ] (ExecuteThread-11): Reloading from:
    file:D:/Programs/cocoon-1.8.2/samples/cocoon.xconf
    DEBUG 93 [cocoon  ] (ExecuteThread-11): New Cocoon object.
    DEBUG 93 [cocoon  ] (ExecuteThread-11): Using parser:
    org.apache.cocoon.components.parser.JaxpParser
    DEBUG 109 [cocoon  ] (ExecuteThread-11): Creating Repository with
    this directory: D:\programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
    DEBUG 109 [cocoon  ] (ExecuteThread-11): Classpath =
    D:\Programs\cocoon-1.8.2\samples\WEB-INF\classes;D:\Programs\cocoon-1.8.2\samples\WEB-INF\lib\javac.jar;D:\avue\lib\servlet.jar;D:\avue\lib\jaxp.jar;D:\avue\lib\xerces.jar;D:\avue\lib\xalan.jar;D:\avue\lib\cocoon.jar;D:\avue\lib\avalonapi.jar;D:\avue\lib\logkit.jar;D:\avue\lib\maybeupload.jar;D:\avue\lib\jakarta-regexp-1.2.jar;D:\avue\lib\jstyle.jar;D:\avue\lib\javac.jar;D:\weblogic\lib\weblogic510sp6boot.jar;D:\weblogic\classes\boot;
    DEBUG 109 [cocoon  ] (ExecuteThread-11): Work directory =
    D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
    DEBUG 125 [cocoon  ] (Thread-0): ComponentFactory creating new
    instance of org.apache.cocoon.components.parser.JaxpParser.
    DEBUG 140 [cocoon  ] (Thread-0): ComponentFactory creating new
    instance of org.apache.cocoon.components.parser.JaxpParser.
    DEBUG 140 [cocoon  ] (Thread-0): ComponentFactory creating new
    instance of org.apache.cocoon.components.parser.JaxpParser.
    DEBUG 140 [cocoon  ] (Thread-0): ComponentFactory creating new
    instance of org.apache.cocoon.components.parser.JaxpParser.
    DEBUG 390 [cocoon  ] (ExecuteThread-11): Root configuration:
    cocoon
    DEBUG 390 [cocoon  ] (ExecuteThread-11): Configuration version:
    2.0
    DEBUG 390 [cocoon  ] (ExecuteThread-11): Setting up components...
    DEBUG 406 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.parser.Parser =
    org.apache.cocoon.components.parser.JaxpParser)
    DEBUG 406 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.language.generator.ProgramGenerator =
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl)
    DEBUG 406 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.url.URLFactory =
    org.apache.cocoon.components.url.URLFactoryImpl)
    DEBUG 406 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.saxconnector.SAXConnector =
    org.apache.cocoon.components.saxconnector.NullSAXConnector)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.avalon.util.datasource.DataSourceComponentSelector =
    org.apache.cocoon.components.CocoonComponentSelector)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.avalon.util.pool.PoolController =
    org.apache.cocoon.components.ComponentPoolController)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.language.programming.ProgrammingLanguageSelector
    = org.apache.cocoon.components.CocoonComponentSelector)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.language.markup.MarkupLanguageSelector =
    org.apache.cocoon.components.CocoonComponentSelector)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.store.Store =
    org.apache.cocoon.components.store.MemoryStore)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Adding component
    (org.apache.cocoon.components.classloader.ClassLoaderManager =
    org.apache.cocoon.components.classloader.ClassLoaderManagerImpl)
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Setting up the sitemap.
    DEBUG 422 [cocoon  ] (ExecuteThread-11): Sitemap location =
    sitemap.xmap
    DEBUG 703 [cocoon  ] (ExecuteThread-11): ComponentFactory creating
    new instance of org.apache.cocoon.components.url.URLFactoryImpl.
    DEBUG 703 [cocoon  ] (ExecuteThread-11): Getting the URLFactories
    DEBUG 703 [cocoon  ] (ExecuteThread-11): for protocol:
    resource org.apache.cocoon.components.url.ResourceURLFactory
    DEBUG 718 [cocoon  ] (ExecuteThread-11): for protocol: context
    org.apache.cocoon.components.url.ContextURLFactory
    DEBUG 718 [cocoon  ] (ExecuteThread-11): Beginning sitemap
    regeneration
    DEBUG 718 [cocoon  ] (ExecuteThread-11): Making URL from
    file:/D:/Programs/cocoon-1.8.2/samples/sitemap.xmap
    DEBUG 718 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.
    DEBUG 718 [cocoon  ] (Thread-1): Could not find ComponentHandler,
    attempting to create one for role:
    org.apache.cocoon.components.language.generator.ServerPagesSelector
    DEBUG 718 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.language.generator.GeneratorSelector.
    DEBUG 718 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.
    DEBUG 718 [cocoon  ] (Thread-1): CocoonComponentSelector setting
    up with root element:
    DEBUG 718 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of org.apache.cocoon.components.CocoonComponentSelector.
    DEBUG 718 [cocoon  ] (Thread-1): CocoonComponentSelector setting
    up with root element: markup-languages
    DEBUG 734 [cocoon  ] (Thread-1): Adding
    org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage for
    xsp
    DEBUG 734 [cocoon  ] (Thread-1): Adding
    org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage
    for sitemap
    DEBUG 734 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of org.apache.cocoon.components.CocoonComponentSelector.
    DEBUG 734 [cocoon  ] (Thread-1): CocoonComponentSelector setting
    up with root element: programming-languages
    DEBUG 750 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.language.programming.java.JavaLanguage.
    DEBUG 750 [cocoon  ] (Thread-1): Looking up
    org.apache.cocoon.components.classloader.ClassLoaderManager
    DEBUG 750 [cocoon  ] (Thread-1): Setting the parameters
    DEBUG 750 [cocoon  ] (Thread-1): Adding
    org.apache.cocoon.components.language.programming.java.JavaLanguage for
    java
    DEBUG 765 [cocoon  ] (Thread-1): The instance was not accessible,
    creating it now.
    DEBUG 765 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
    DEBUG 1718 [cocoon  ] (Thread-1): Making URL from
    jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
    DEBUG 1718 [cocoon  ] (Thread-1): Logicsheet
    Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
    WARN 4109 [cocoon  ] (Thread-1): Could not load class for program
    'org\apache\cocoon\www\sitemap_xmap'
    java.security.AccessControlException: access denied
    (java.io.FilePermission
    \D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
    at
    java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
    at
    java.security.AccessController.checkPermission(AccessController.java:399)
    at
    java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
    at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
    at
    java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
    at
    java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
    at
    org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
    at
    org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
    at
    org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 4109 [cocoon  ] (Thread-1): Language Exception
    org.apache.cocoon.components.language.LanguageException: Could not load
    class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
    java.security.AccessControlException: access denied
    (java.io.FilePermission
    \D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
    at
    org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
    at
    org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 4109 [cocoon  ] (Thread-1): ComponentFactory decommissioning
    instance of
    org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
    DEBUG 4109 [cocoon  ] (Thread-1): Can't load ServerPage
    org.apache.avalon.ComponentManagerException: Could not add component for
    class: org.apache.cocoon.www.sitemap_xmap
    at
    org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
    at
    org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:172)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 4109 [cocoon  ] (Thread-1): ComponentFactory creating new
    instance of
    org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
    DEBUG 4359 [cocoon  ] (Thread-1): Making URL from
    jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
    DEBUG 4359 [cocoon  ] (Thread-1): Logicsheet
    Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
    WARN 6109 [cocoon  ] (Thread-1): Could not load class for program
    'org\apache\cocoon\www\sitemap_xmap'
    java.security.AccessControlException: access denied
    (java.io.FilePermission
    \D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
    at
    java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
    at
    java.security.AccessController.checkPermission(AccessController.java:399)
    at
    java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
    at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
    at
    java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
    at
    java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
    at
    org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
    at
    org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
    at
    org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 6109 [cocoon  ] (Thread-1): Language Exception
    org.apache.cocoon.components.language.LanguageException: Could not load
    class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
    java.security.AccessControlException: access denied
    (java.io.FilePermission
    \D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
    at
    org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
    at
    org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 6109 [cocoon  ] (Thread-1): ComponentFactory decommissioning
    instance of
    org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
    ERROR 6109 [cocoon  ] (Thread-1): Error compiling sitemap
    org.apache.avalon.ComponentManagerException: Could not add component for
    class: org.apache.cocoon.www.sitemap_xmap
    at
    org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
    at
    org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
    at
    org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:219)
    at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
    at java.lang.Thread.run(Thread.java:484)
    DEBUG 6109 [cocoon  ] (ExecuteThread-11): Changing Cocoon
    context(sitemap.xmap) to prefix()
    DEBUG 6109 [cocoon  ] (ExecuteThread-11): from
    context(file:/D:/Programs/cocoon-1.8.2/samples/) and prefix()
    DEBUG 6109 [cocoon  ] (ExecuteThread-11): at URI
    DEBUG 6109 [cocoon  ] (ExecuteThread-11): New context is
    file:/D:/Programs/cocoon-1.8.2/samples/
    ERROR 6140 [cocoon  ] (ExecuteThread-11): Problem with servlet
    org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is
    not available.
    at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:106)
    at org.apache.cocoon.Cocoon.process(Cocoon.java:218)
    at
    org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:417)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:123)
    at
    weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:761)
    at
    weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:708)
    at
    weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:252)
    at
    weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:346)
    at
    weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)
    INFO 6187 [cocoon  ] (ExecuteThread-11): '' Processed by Apache
    Cocoon 2.0a4 in 5.75 seconds.
    ================================================================
    Regards,
    Georgi

  • 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
              >
              

  • 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

  • Weblogic Class Loader caching/writing classes to weblogic/myServer/classfiles

    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
              

    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
              >
              

  • Performance issues with class loader on Windows server

    We are observing some performance issues in our application. We are Using weblogic 11g with Java6 on a windows 2003 server
    The thread dumps indicate many threads are waiting in queue for the native file methods:
    "[ACTIVE] ExecuteThread: '106' for queue: 'weblogic.kernel.Default (self-tuning)'" RUNNABLE
         java.io.WinNTFileSystem.getBooleanAttributes(Native Method)
         java.io.File.exists(Unknown Source)
         weblogic.utils.classloaders.ClasspathClassFinder.getFileSource(ClasspathClassFinder.java:398)
         weblogic.utils.classloaders.ClasspathClassFinder.getSourcesInternal(ClasspathClassFinder.java:347)
         weblogic.utils.classloaders.ClasspathClassFinder.getSource(ClasspathClassFinder.java:316)
         weblogic.application.io.ManifestFinder.getSource(ManifestFinder.java:75)
         weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:67)
         weblogic.application.utils.CompositeWebAppFinder.getSource(CompositeWebAppFinder.java:71)
         weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:67)
         weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:67)
         weblogic.utils.classloaders.CodeGenClassFinder.getSource(CodeGenClassFinder.java:33)
         weblogic.utils.classloaders.GenericClassLoader.findResource(GenericClassLoader.java:210)
         weblogic.utils.classloaders.GenericClassLoader.getResourceInternal(GenericClassLoader.java:160)
         weblogic.utils.classloaders.GenericClassLoader.getResource(GenericClassLoader.java:182)
         java.lang.ClassLoader.getResourceAsStream(Unknown Source)
         javax.xml.parsers.SecuritySupport$4.run(Unknown Source)
         java.security.AccessController.doPrivileged(Native Method)
         javax.xml.parsers.SecuritySupport.getResourceAsStream(Unknown Source)
         javax.xml.parsers.FactoryFinder.findJarServiceProvider(Unknown Source)
         javax.xml.parsers.FactoryFinder.find(Unknown Source)
         javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source)
         org.ajax4jsf.context.ResponseWriterContentHandler.<init>(ResponseWriterContentHandler.java:48)
         org.ajax4jsf.context.ViewResources$HeadResponseWriter.<init>(ViewResources.java:259)
         org.ajax4jsf.context.ViewResources.processHeadResources(ViewResources.java:445)
         org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:193)
         org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
         org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
    On googling this seems to be an issue with java file handling on windows servers and I couldn't find a solution yet. Any recommendation or pointer is appreciated

    Hi shubhu,
    I just analyzed your partial Thread Dump data, the problem is that the ajax4jsf framework ResponseWriterContentHandler triggers internally a new instance of the DocumentBuilderFactory; every time; triggering heavy IO contention because of Class loader / JAR file search operations.
    Too many of these IO operations under heavy load will create excessive contention and severe performance degradation; regardless of the OS you are running your JVM on.
    Please review the link below and see if this is related to your problem.. This is a known issue in JBOSS JIRA when using RichFaces / ajaxJSF.
    https://issues.jboss.org/browse/JBPAPP-6166
    Regards,
    P-H
    http://javaeesupportpatterns.blogspot.com/

  • How to write a class loader to solve the class confliction in rt.jar?

    Hello guys:
    The weblogic.jar has the javax.management.*, it is conflict with rt.jar's
    I want to use JMX 1.0 to communicate with weblogic 8.1. The client should be run in the Java 1.5
    It throw
    java.io.InvalidClassException: javax.management.ObjectName; local class incompatible:
    stream classdesc serialVersionUID = -5467795090068647408, local class serialVersionUID = 1081892073854801359
    java.io.InvalidClassException: javax.management.ObjectName; local class incompatible:
    stream classdesc serialVersionUID = -5467795090068647408, local class serialVersionUID = 1081892073854801359I know the reason is java 1.5 has JMX 1.2 in it.
    So how can I program a class loader to load the weblogic.jar classes in? I have tried a lot of code, but failed.
    Is there any sample here?
    I want to use the JMX 1.0 in weblogic.jar at jdk1.5 run time
    Thanks a lot,
    Qiang

    Hello guys:
    The weblogic.jar has the javax.management.*, it is conflict with rt.jar's
    I want to use JMX 1.0 to communicate with weblogic 8.1. The client should be run in the Java 1.5
    It throw
    java.io.InvalidClassException: javax.management.ObjectName; local class incompatible:
    stream classdesc serialVersionUID = -5467795090068647408, local class serialVersionUID = 1081892073854801359
    java.io.InvalidClassException: javax.management.ObjectName; local class incompatible:
    stream classdesc serialVersionUID = -5467795090068647408, local class serialVersionUID = 1081892073854801359I know the reason is java 1.5 has JMX 1.2 in it.
    So how can I program a class loader to load the weblogic.jar classes in? I have tried a lot of code, but failed.
    Is there any sample here?
    I want to use the JMX 1.0 in weblogic.jar at jdk1.5 run time
    Thanks a lot,
    Qiang

  • Dynamic class loading from JARs in web application

    Hello,
    I'm working on a web project in which we would like to dynamically load plugins without server restart.
    We have developed our own ClassLoader in order to load the plugins from a path or with a user interface upload function.
    The class loader hierarchy should be something like this:
          Bootstrap
              |
           System
              |
           Common
    Catalina   Shared
            Webapp1  OurSystem
                       PluginClassLoaderThe all works fine within the classes loaded in the PluginClassLoader, but classes loaded in OurSystems class loader cannot access classes loaded in PluginClassLoader. For example when Hibernate tries to load classes definied in mapping files we got a java.lang.ClassNotFoundException.
    Is there a way to load classes dynamically to OurSystems class loader or notify it about PluginClassLoaders classes?
    Or is this a bad way to do it?
    Best regards,
    Kristoffer Renholm

    Hi,
    Sounds like a classpath problem that the folks in the workshop newsgroup
    could help with. Try asking your question in:
    http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=xover&group=weblogic.developer.interest.workshop&utag=
    Bruce
    Graeme Dougal wrote:
    >
    Hi, I am developing a web service with weblogic workshop. The JWS file references
    other classes one of which is a factory for distributing various implementations
    of an interface. I am trying to dynamically load the relevant class to be distributed
    from the factory via its name, e.g. Class c = Class.forName(className)
    However I keep getting a classNotFoundException.
    Any ideas ??

  • Dynamic class loading from directory on server

    Hello,
    I am not sure if this is right forum, but I think it is more weblogic then ADF issue...
    I am trying to create and load dynamically classes in weblogic (10.3.2.0). It is ADF application which I deploy to the weblogic server.
    When I print ((GenericClassLoader)this.getClass().getClassLoader()).getFinderClassPath()I see the path to my directory (of course not just this path) C:\...\system11.1.1.2.36.55.36\DefaultDomain\servers\DefaultServer\tmp\_WL_user\test\753the\dynamicClasses(I have added directory dynamicClasses to manifest for deployment WAR profile).
    In this directory I create class files. I have checked it, files are really created there.
    When I try to load created class with the same classloader, for which I have printed classpath, ClassNotFoundException is thrown.
    Please where could be the problem? Isn't it possible to load classes from directory instead of jar, do I need some special server configuration,...?
    Thank you in advance
    Qjeta

    Hi Qjeta,
    I am not sure but you can give it a try using URLClassLoader...Which we generally use for DynamicClassLoading:
    import java.net.URLClassLoader;
    <font color=maroon>
    String path="C:/.../system11.1.1.2.36.55.36/DefaultDomain/servers/DefaultServer/tmp/_WL_user/test/753the/dynamicClasses";
    *URLClassLoader loader = new URLClassLoader(new URL[] { new URL(path) });*
    Class c = loader.loadClass ("your.class.NameHere");
    </font>
    // Load class from class loader. filly qualified class name (means classname with package name) is the name of the class to be loaded
    in the above code the "C:/.../system11.1.1.2.36.55.36/DefaultDomain/servers/DefaultServer/tmp/_WL_user/test/753the/dynamicClasses" should be the location of the directory where your classes are placed....If you want to load a perticular Jar then you need to write the jarfile name as well like following:
    C:/.../system11.1.1.2.36.55.36/DefaultDomain/servers/DefaultServer/tmp/_WL_user/test/753the/dynamicClasses/Myapplication.jar
    .================================
    If the above code works for you then later you can even try to enhance your code by doing the following:
    Thread.currentThread().setContextClassLoader(urlClassLoaderRef);
    Thanks
    Jay SenSharma
    http://jaysensharma.wordpress.com (WebLogic Wonders Are Here)

Maybe you are looking for

  • How can I find out the first intial row in VA02-output transaction??

    How can I find out the first intial row in the screen which appears during sales order change (VA02) >>enter the sales order number >>after the first screen appears >>in the menu bar go to EXTRAS>>OUTPUT>>HEADER>>EDIT?? I have to find out the first r

  • Problem with activation

    The error code is:E_ADEPT_REQUEST_EXPIRED WHO CAN HELP ME?

  • TP4 FileExplorer tree: change Folder icon when expanded/collapsed

    I am trying to create a tree similar with FileExplorer from the Demo application. I am trying to use two icons for every node: one for expanded node and another one for collapsed. I use a rowDisclosureListener tag rowDisclosureListener="#{menuBean.me

  • Notification center is not filling the screen

    Ever since I updated to 8.3 When I pull down to view notification center on my iPhone 6 Plus it only fills about 1/4 of the screen vertically.   To the point where I can only see the icon and the x to clear the notification the words in the individua

  • Create new DataFile in another partition??

    Hi, I used database oracle10g, and I set (oradata) in partition (C) and i want to load large data on database but i haven't enough space in this partition . Can I create new DataFile in another partition like partition (D) ??? And if yes, will it eff