Class Loading Strategy for Security MBeans

Hi, can someone point me to a good reference or explain how security mbeans load referenced classes? I'm trying to reference my auditor class, which is archived in an audit.jar, from within my authentication provider mbean implementation class. I've added the attribute class-path:audit.jar in the manifest file of the mbean jar file containing the authentication provider class. Every time I start the server I get a "NoClassDefFoundError" exception. Any ideas?

Someone else can probably answer with more authority, but I think that statement is true because Java 2 introduced context class loaders, or at least formalized the hierarchical relationship between context class loaders.
Each thread by definition has a context class loader, possibly (probably) through inheritance from its parent thread.
According to the API doc, Class.forName() loads a class using the current class's classLoader, whereas getContextClassLoader().loadClass() loads a class using the thread's context class loader.
I think there could be cases where a context class loader could have access to resoures that the class's class loader doesn't. If anyone can shed more light on this, that would be helpful.
There's some discussion of this here:
http://java.sun.com/products/jndi/tutorial/beyond/misc/classloader.html, mainly in regards to JNI.

Similar Messages

  • How do I generate stub classes with wsimport for secured (SSL) WSDL?

    I'm trying to use the wsimport utility from the JWSDP1.6 to generate the stub classes for a web service client. The problem is that the WSDL location is secured on it's server, and when you navigate to it via a browser it asks you to authenticate before it'll show it. I have access to the WSDL, via a username and password, but I have no idea how to send those parameters to it through wsimport. Here's my error message from wsimport:
    [ERROR] Failed to read the WSDL document: https://-removed4companysecurityreasons-.com/ObsidianAdService.asmx?WSDL, because 1) could not find the document
    ; /2) the document could not be read; 3) the root element of the document is not <wsdl:definitions>.
    unknown location
    Can anyone offer me any advice/solutions here?

    I'm not sure we had support for secured web services access in 10.1.2 - try JDeveloper 10.1.3 instead:
    http://www.oracle.com/technology/products/jdev/howtos/1013/wssecure/10gwssecurity_howto.html#CreateSecureProxy

  • How to improve class-loading performance for missing classes

    Hi,
    do you have any ideas how we can improve the class-loading performance on a weblogic 12c running on jrockit? We spend about 20-30 ms per request in class-loading due to the way hibernate criteria API works (it tries to load quite a lot of missing classes). The only thing I came up with was to invert the class-loading using the weblogic descriptor for those missing classes (which are actually no real classes but some parts of a generated JPQL) which does improve performance a bit.
    Thanks
    Dimo

    Hi,
    do you have any ideas how we can improve the class-loading performance on a weblogic 12c running on jrockit? We spend about 20-30 ms per request in class-loading due to the way hibernate criteria API works (it tries to load quite a lot of missing classes). The only thing I came up with was to invert the class-loading using the weblogic descriptor for those missing classes (which are actually no real classes but some parts of a generated JPQL) which does improve performance a bit.
    Thanks
    Dimo

  • Why do we use only dynamic class loading for JDBC drivers

    Hi,
    My JDBC experience is that we always use dynamic class loader for drivers.
    If we have a well defined package from a vendor, why do we use this dynamic class loading feature for drivers??

    chandunitw wrote:
    Hi,
    My JDBC experience is that we always use dynamic class loader for drivers.
    If we have a well defined package from a vendor, why do we use this dynamic class loading feature for drivers??Oftentimes, the driver class name is set in a configuration file, not in code. So the thing which processes the configuration file has no idea ahead of time which driver or drivers it will support, so it is not coded specifically for any. So it loads the driver by reflection, since it is given the class name as a string it can use with the reflection API.

  • 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

  • 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

  • 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:33 PM

    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:33 PM

  • EC-CS Data Loading Strategy

    Hello. We are currently in the process of implementing the Enterprise Consolidation Transaction Data InfoCube (0ECCS_C01).
    We are attempting to develop a data loading strategy for the InfoCube. Since this InfoCube does not have a delta process, reloading the entire cube on a daily basis is not feasable due to the length of time. We would like to set it up where it would load the current month for actuals plus into the future for forecast dollars.
    Has anyone established a data loading process for their consolidated accounting InfoCube that works well and keeps data loading time to a minimum?
    Best regards,
    Lynn

    Hi,
    You could prepare packages:
    one which you upload all data from previous years/months
    second with OLAP variables (for example 0DAT) which you upload data only from present day/month/year - depends which variable you select (add this package to the chain).
    When the second package will crash, you have to repeat procedure.
    Regards,
    Dominik

  • 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

  • Implementing a secure class loader..

    Hello,
    We have a custom class loader which loads in custom packages from the database or from the file system. We want to ensure that these custom classes do not read or write into the file system. I want to restrict access to these classes when creating them. I read that by setting the proper permissions when defining the class, this could be possible. Here is my implementation of the class loader :
    import java.io.File;
    import java.io.FileInputStream;
    import java.io.FilePermission;
    import java.io.IOException;
    import java.net.SocketPermission;
    import java.net.URL;
    import java.security.AccessController;
    import java.security.CodeSource;
    import java.security.PermissionCollection;
    import java.security.Permissions;
    import java.security.PrivilegedExceptionAction;
    import java.security.SecureClassLoader;
    public class TestClassLoader extends SecureClassLoader {
            JarParser jp;
            public TestClassLoader(JarParser jp) {
              super();
                    this.jp = jp;
            public Class findClass(final String name) throws ClassNotFoundException {
                   try {
                       return(Class)
                               AccessController.doPrivileged (
                                     new PrivilegedExceptionAction() {
                                                   public Object run() throws ClassNotFoundException {
                                                         byte[] buf = null;
                                                            try {
                                                               if(jp == null)
                                                                      throw new ClassNotFoundException("Jar file not found");
                                                                    String className = name.replace( '.', '/' ) + ".class";
                                                                    buf = jp.getResource(className);
                                                                    if(buf == null || buf.length == 0)
                                                                          throw new ClassNotFoundException("Class not found");
                                                                    CodeSource cs = getCodeSource(name);
                                                                    return defineClass(name, buf, 0, buf.length, cs);
                                                           catch(Exception e) {
                                                                throw new ClassNotFoundException(name, e);
                   catch(Exception e) {
                        throw new ClassNotFoundException(name, e);
          * @param name
         protected CodeSource getCodeSource(String name) {
                   try {
                       return new CodeSource(new URL("file", "localhost", name), null);
                   catch(Exception e){
                         e.printStackTrace();
                    return null;
            protected PermissionCollection getPermissions(CodeSource cs) {
              PermissionCollection pc = new Permissions();
                    pc.add(new RuntimePermission("exitVM"));
                    pc.add(new FilePermission("${user.home}${/}*", "read"));
                    pc.add(new FilePermission("${user.dir}${/}*", "read"));
             pc.add(new SocketPermission("localhost", "resolve"));
                    return pc;
            public static void main(String[] args) {
                    try {
                       byte[] bytes = new byte[8192];
                      long ttlBytesRead = 0;
                      int noOfBytesToRead = 0;
                            File readFile = new File("test.jar");
                            // "length" here indicates the total no of bytes to read.
                          // This is equal to the file size sans the offset value.
                            long length = readFile.length();
                            Long temp;
                          FileInputStream readFis = null;
                            // Create the RandomAccessFile
                      try{
                                 readFis = new FileInputStream(readFile);
                           catch(Exception e) {
                                throw new IOException(e.getMessage());
                           long tempLong;
                      StringBuffer buffer = new StringBuffer();
                            do {
                                if ((length - ttlBytesRead) > 8192)
                                         tempLong = 8192;
                                    else
                                        tempLong = (length - ttlBytesRead);
                                 temp = new Long((length - ttlBytesRead) > 8192 ? 8192 : (length - ttlBytesRead));
                                   noOfBytesToRead = temp.intValue();
                                  if(noOfBytesToRead == 0)
                                            break;
                              // Read the specified no of bytes into the byte
                                    // array from the file.
                             try {
                                       readFis.read(bytes,0,noOfBytesToRead);
                                   catch(Exception e1) {
                                       throw new IOException(e1.getMessage());
                                   String str  = new String(bytes, 0, noOfBytesToRead);
                                buffer.append(str);
                                    ttlBytesRead += noOfBytesToRead;
                            } while(ttlBytesRead < length);
                     try {
                               readFis.close();
                           catch(Exception e1) {}
                            JarParser jp = new JarParser("test.jar", buffer.toString().getBytes());
                     TestClassLoader tcl = new TestClassLoader(jp);
                      Class class1 = tcl.findClass("com.test.TestFileWrite");
                     Object obj = class1.newInstance();
                   catch(Exception e) {
                        e.printStackTrace();
    }JarParser is the class which parses through the jar file and caches the contents as bytes.
    The test.jar contains a single class which writes into the user's home directory. As you can see, I have granted only read access on the home dir.
    When I run this however, the newly loaded class does manage to write into the file system with no problems. Is there anything further that I need to do to enable restriction on the file system ?
    Thanks.

    If I've been reading correctly, they don't want you
    subclassing SecurityManager for security any more.
    Everything should be handled by the AccessController
    using Permission objects. The easiest way to configure
    the AccessController is through policy files.erg. where did you read this? I checked the 1.5.0 beta API just now, and nothing is officially deprecated.
    :{  I don't have time to figure out the AccessController API right now.
    I have yet to find a good tutorial on the matter of
    security and classloaders. If anyone has a good
    reference, it would be much appreciated.I second that.
    And as a temporary solution (because we're already behind schedule), I went ahead and wrote my own SecurityManager, using the ideas I mentioned above.
    I'm posting it at the site below in case anyone can offer any feedback (such as pointing out fatal weaknesses). We tried yesterday for an hour or so to break it, and it withstood all our tests; but security is not our specialty, so there's probably room for improvement.
    (I'd post it in this message, but it's a wee bit large.)
    www.personal.utulsa.edu/~jeremy-wood/software/ThreadBasedSecurityManager.java
    (And if it passes your scrutiny and looks useful, feel free to use it. But note the disclaimers.)

  • Simple RMI/IIOP app : "no security manager: RMI class loader disabled"

    Hello colleagues!
    I do not understand the problem at all, and asking for your kind help.
    This is my first code for RMI/IIOP. We are using JBoss as application server.
    What I've done :
    1) created test.Command interface , extending Remote
    2) created test.CommandImpl , implementing above mentioned interface and java.io.Serializable, and extending javax.rmi.PortableRemoteObject.
    BTW, Serializable is not implemented in some tutorials, but absence of Serializable causes NotSerializableException when trying to rebind (next step).
    3) in server code, created initial context and called
    context.rebind("test/Command",new CommandImpl());
    4) Ran rmic -iiop test.CommandImpl . A result was two new cass files, CommandImplTie.class and CommandStub.class , both are also in package "test".
    5) Created remote client and put CommandStub.class to client
    classpath (under package "test", too).
    6) In client code, initialized the context and called
    context.lookup("test/Command").
    On this line (lookup), the following exception is being raised :
    javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException: test.CommandImpl (no security manager: RMI class loader disabled)
         at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:368)
         at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:161)
         at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
         at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
         at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
         at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
         at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:30)
         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:514)
         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:471)
         at javax.naming.InitialContext.lookup(InitialContext.java:347)
    Is _Stub class all that client needs from server classes, to obtain
    the reference ? I tried to put _Tie also to client, but with the same result.
    All Jndi paths to JBoss server are correct, as I've used them successfully in other applications.
    Many thanks in advance,
    Daniel

    Next few words to the topic.
    I made tests with canonical RMI/IIOP tutorial from Sun.
    When I use Sun's ORB (orbd.exe) , everything work fine. I started
    orbd on the same PC as JBoss, and client and server are running
    remotely.
    But with JBoss ORB, I have the same exception as described above.
    Server starts and registers in JNDI successfully, but client can not
    obtain a remote reference. Exception is being thrown on
    context.lookup().
    So the difference is definitely in security managers for two ORBs.
    I also tried to create new RMISecurityMananger and set it, but with
    no effect.
    Any ideas ?
    TIA,
    Daniel.

  • How can I make server use single class loader for several applications

    I have several web/ejb applications. These applications use some common libraries and should share instances of classes from those libraries.
    But applications are being deployed independently thus packaging all them to EAR is not acceptable.
    I suppose the problem is that each application uses separate class loader.
    How can I make AS use single class loader for a set of applications?
    Different applications depend on different libraries so I need a way that will not share library for all applications on the domain but only for some exact applications.
    When I placed common jar to *%domain%/lib* - all works. But that jar is shared between all applications on the domain.
    When I tried to place common jar to *%domain%/lib/applibs* and specified --libraries* attribute on deploying I got exception
    java.lang.ClassCastException: a.FirstDao cannot be cast to a.FirstDaoHere http://download.oracle.com/docs/cd/E19879-01/820-4336/6nfqd2b1t/index.html I read:
    If multiple applications or modules refer to the same libraries, classes in those libraries are automatically shared.
    This can reduce the memory footprint and allow sharing of static information.Does it mean that classes should be able to be casted ?

    You didn't specify which version of the application server you are using, but the config is similar as long as you know what to look for. Basically, you need to change the classloader delegation. Here's how it is done in 8.2
    http://download.oracle.com/docs/cd/E19830-01/819-4721/beagb/index.html

  • 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

  • An XJC compilation error - Could not load class (..) for type cvsversion

    I've got a strange compilation error using NetBeans 4.0 (I'd guess the version does not matter here) and Ant 1.6.2. When the following task is executed,
    <target name="compile_ofx_schema">
    <antcall target="clean-ofx"/>
    <delete dir="${ofx-jaxb-src.dir}"/>
    <mkdir dir="${ofx-jaxb-src.dir}" />
    <xjc schema="${schema.dir}/ofx102.xsd" package="com.xxx.ofx102" target="${ofx-jaxb-src.dir}">
    <arg value="-nv" />
    <arg value="-extension" />
    </xjc>
    </target>
    I get the error from NetBeans console,
    Class org.xml.sax.SAXException loaded from parent loader (parentFirst)
    Class java.io.IOException loaded from parent loader (parentFirst)
    D:\appserver\build.xml:797: unable to parse the schema. Error messages should have been provided
    at com.sun.tools.xjc.XJCTask._doXJC(XJCTask.java:334)
    at com.sun.tools.xjc.XJCTask.doXJC(XJCTask.java:283)
    at com.sun.tools.xjc.XJCTask.execute(XJCTask.java:227)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
    at org.apache.tools.ant.Task.perform(Task.java:364)
    at org.apache.tools.ant.Target.execute(Target.java:341)
    at org.apache.tools.ant.Target.performTasks(Target.java:369)
    at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
    at org.apache.tools.ant.Project.executeTargets(Project.java:1062)
    at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:217)
    at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:236)
    at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)
    BUILD FAILED (total time: 4 seconds)
    Could not load class (org.apache.tools.ant.tasksdefs.cvslib.CvsVersion) for type cvsversion
    Could not load class (org.apache.tools.ant.tasksdefs.cvslib.CvsVersion) for type cvsversion
    And when I run the Ant task from the command line, I don't get the error at all.
    Any help is greatly appreciated.

    That was a great finding from you. Thank you.
    I followed your alternative approach and updated the ant.jar file. The "Could not load class..." error went away but the stack trace still remains. Now I am clueless again since I have ant on the debug mode and can't find any more useful info.
    Class com.sun.tools.xjc.reader.internalizer.LocatorTable loaded from ant loader (parentFirst)
    Class java.util.HashSet loaded from parent loader (parentFirst)
    Class javax.xml.parsers.DocumentBuilderFactory loaded from parent loader (parentFirst)
    Couldn't load Resource org/netbeans/core/xml/DOMFactoryImpl.class
    Couldn't load ResourceStream for META-INF/services/javax.xml.parsers.DocumentBuilderFactory
    Class org.apache.crimson.jaxp.DocumentBuilderFactoryImpl loaded from parent loader (parentFirst)
    Class javax.xml.parsers.SAXParserFactory loaded from parent loader (parentFirst)
    Couldn't load Resource org/netbeans/core/xml/SAXFactoryImpl.class
    Couldn't load ResourceStream for META-INF/services/javax.xml.parsers.SAXParserFactory
    Class org.apache.crimson.jaxp.SAXParserFactoryImpl loaded from parent loader (parentFirst)
    Class javax.xml.parsers.DocumentBuilder loaded from parent loader (parentFirst)
    Class java.util.Map loaded from parent loader (parentFirst)
    Class javax.xml.parsers.SAXParser loaded from parent loader (parentFirst)
    Finding class com.sun.tools.xjc.reader.xmlschema.parser.XMLSchemaInternalizationLogic$ReferenceFinder
    Loaded from D:\bbw\build\Common_3.6\Packaged\appserver\lib\jaxb\jaxb-xjc.jar com/sun/tools/xjc/reader/xmlschema/parser/XMLSchemaInternalizationLogic$ReferenceFinder.class
    Finding class com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl
    Loaded from D:\bbw\build\Common_3.6\Packaged\appserver\lib\jaxb\jaxb-xjc.jar com/sun/tools/xjc/reader/internalizer/AbstractReferenceFinderImpl.class
    Class org.xml.sax.helpers.XMLFilterImpl loaded from parent loader (parentFirst)
    Class com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl loaded from ant loader (parentFirst)
    Class com.sun.tools.xjc.reader.xmlschema.parser.XMLSchemaInternalizationLogic$ReferenceFinder loaded from ant loader (parentFirst)
    Class org.xml.sax.XMLFilter loaded from parent loader (parentFirst)
    Finding class com.sun.tools.xjc.reader.internalizer.VersionChecker
    Loaded from D:\bbw\build\Common_3.6\Packaged\appserver\lib\jaxb\jaxb-xjc.jar com/sun/tools/xjc/reader/internalizer/VersionChecker.class
    Class com.sun.tools.xjc.reader.internalizer.VersionChecker loaded from ant loader (parentFirst)
    Finding class com.sun.tools.xjc.reader.internalizer.DOMBuilder
    Loaded from D:\bbw\build\Common_3.6\Packaged\appserver\lib\jaxb\jaxb-xjc.jar com/sun/tools/xjc/reader/internalizer/DOMBuilder.class
    Finding class com.sun.xml.bind.marshaller.SAX2DOMEx
    Loaded from D:\bbw\build\Common_3.6\Packaged\appserver\lib\jaxb\jaxb-impl.jar com/sun/xml/bind/marshaller/SAX2DOMEx.class
    Class org.xml.sax.ContentHandler loaded from parent loader (parentFirst)
    Class com.sun.xml.bind.marshaller.SAX2DOMEx loaded from ant loader (parentFirst)
    Class com.sun.tools.xjc.reader.internalizer.DOMBuilder loaded from ant loader (parentFirst)
    Class java.util.Stack loaded from parent loader (parentFirst)
    Class org.w3c.dom.Document loaded from parent loader (parentFirst)
    Class org.xml.sax.XMLReader loaded from parent loader (parentFirst)
    Class org.w3c.dom.Node loaded from parent loader (parentFirst)
    Class org.w3c.dom.Element loaded from parent loader (parentFirst)
    Class javax.xml.parsers.ParserConfigurationException loaded from parent loader (parentFirst)
    Class org.xml.sax.SAXException loaded from parent loader (parentFirst)
    Class java.io.IOException loaded from parent loader (parentFirst)
    D:\bbw\build\Common_3.6\Packaged\appserver\build.xml:799: unable to parse the schema. Error messages should have been provided
    at com.sun.tools.xjc.XJCTask._doXJC(XJCTask.java:334)
    at com.sun.tools.xjc.XJCTask.doXJC(XJCTask.java:283)
    at com.sun.tools.xjc.XJCTask.execute(XJCTask.java:227)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
    at org.apache.tools.ant.Task.perform(Task.java:364)
    at org.apache.tools.ant.Target.execute(Target.java:341)
    at org.apache.tools.ant.Target.performTasks(Target.java:369)
    at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
    at org.apache.tools.ant.Project.executeTargets(Project.java:1062)
    at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:217)
    at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:236)
    at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)
    BUILD FAILED (total time: 1 second)
    Any suggestions? BTW, I did not upgrade NetBeans to v5.5 due that my code is still JDK1.4 based.

  • Design patterns for Dynamic Class Loading

    Hi,
    I have to develop a program for uni that dynamically loads classes based on names in a text file. All the classes subclass an abstract class with a constructor that takes one argument. This means I can't use the Class.forName(className).newInstance() method of class loading. I have researched some design patterns I could use and have come up with the following 3:
    Factory pattern; "Robocode" pattern (not it's real name, but Robocode uses it); and, the "one I made up myself" pattern.
    The robocode pattern instantiates a class using the default no-argument constructor then immediately sets all properties that shoud have been provided in the constructor:
    Object o = Class.forName(myClass).newInstance();
    o.setProperty(property);Personally I think this is ugly and a cheap fix instead of doing it properly.
    My own pattern finds the constructor that takes the arguments I need then calls it to create the object:
    Class c = Class.forName(myClass);
    Constructor cons = c.getConstructor(new Class[]{Class.forName("java.lang.String")});
    Object o = cons.newInstance(new Object[]{"hello"});What's the best to use? Are there any other patterns I should consider?

    My own pattern finds the constructor that takes the
    arguments I need then calls it to create the object:
    Class c = Class.forName(myClass);
    Constructor cons = c.getConstructor(new
    Class[]{Class.forName("java.lang.String")});
    Object o = cons.newInstance(new Object[]{"hello"});
    I have followed this basic 'pattern' several times though I would use
    Constructor cons = c.getConstructor(new Class[]{String.class});
    It works great.

Maybe you are looking for