Class loader: saaj-api conflict

I need to load saaj-api from my application which is newer than the one that comes w/ith oc4j 10.1.3 which is loaded by the system class loader with name api from webservices/lib/saaj-api.jar.
remove-inherited doesn't seem to do the trick.
Any suggestions would be appreciated.
Thanks,
Jindong.

While I understand where you're coming from, it sounded to me that oc4j lacks the flexibility to allow application to use newer version of certain component.
For example, certain JDK level supports certain JAXP, but there is indeed an extension mechnism to allow application plug in newer JAXP?
I believe other j2ee contains are a lot flexbile in terms of this...I don't think J2EE spec says that applications running in its container can not use newer software components?
I think it only makes sense that the minimum supported level is j2ee 1.4, but nothing should stop applications from having their own version of any thing.
I strongly suggest that this to be considered for what ever release you guys are working on or a work around can be provided for the current version we're using.
Jindong.

Similar Messages

  • 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

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

    Does resteasy API have class loader issues when using via OSGi

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

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

  • Problem in Class Loading

    I am using Sun implementation of JAXB(jaxb-api.jar) for java-to-xml binding in my web application deployed in the latest version of oracle app server(10g release 3). The web server is loading Oracle implementation of JAXB from the shared archive xml.jar. To direct the web server to load application specific JAXB classes, I have used the property(<web-app-class-loader search-local-classes-first="true" include-war-manifest-class-path="false" />) in the deployment description - orion.xml file. But it does not solve the problem!
    Thanks & regards

    Hi,
    Refer to this link on OC4J's Classloading Framework... http://download-east.oracle.com/docs/cd/B25221_04/web.1013/b14433/classload.htm#sthref58 there are a couple of options you may be able to employ, including overriding the shared library - there is an example of doing this with the Oracle XML parser and Xerces.
    I'm guessing you're on the right track, but you may want to try include-war-manifest-class-path="true". Also, are you sure that you've got your deployment descriptor file defined correctly? Its normally called orion-application.xml, and that particular element isn't defined in the documentation (http://download-east.oracle.com/docs/cd/B25221_04/web.1013/b14433/descriptors.htm#sthref337). You could always try configuring it through the administration console.

  • How to resolve setPrefix() in SOAP(saaj API) with weblogic/webservices jar?

    Hi,
    I am facing a problem deploying a Web-Application in Weblogic containing SOAP related code.
    My environment is as below:
    1) Weblogic 8.1 SP2 server
    2) Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
    3) A method is exposed as web-service
    4) A client program(which is a part of Action class of Webb-app) written with SOAP APIs containing the following section:
         MessageFactory mf = MessageFactory.newInstance();
         SOAPMessage sm = mf.createMessage();
         SOAPPart sp = sm.getSOAPPart();
         sp.setPrefix("soapenv");
         SOAPEnvelope se = sp.getEnvelope();
         se.addNamespaceDeclaration("soapenv","http://orion:7001");
    giving the following error at runtime:
    Exception in thread "main" java.lang.AbstractMethodError:
    weblogic.were.soap.SOAPEnvelopeImpl.setPrefix(Ljava/lang/String;)V
    at Client.main(Client.java:39)
    I am able to compile without any error/warning all the time.
    This is giving only when putting the saaj(jwsdp-1.4) jars along with weblogic/webservices jars in classpath.
    I am able to run the same application(outside Web-application as a stand-alone java program) without
    any error while not using weblogic/webservices jar in the classpath.
    The saaj jars needed to run without any error are:
    saaj-api.jar
    saaj-impl.jar
    mailapi.jar
    activation.jar
    xercesImpl.jar
    xalan.jar
    dom.jar
    jdom.jar
    I thinks this is a compatibility issue. Please suggest to resolve it.
    Thanks in advance,
    pal_sk

    Hi,
    I am facing a problem deploying a Web-Application in Weblogic containing SOAP related code.
    My environment is as below:
    1) Weblogic 8.1 SP2 server
    2) Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
    3) A method is exposed as web-service
    4) A client program(which is a part of Action class of Webb-app) written with SOAP APIs containing the following section:
         MessageFactory mf = MessageFactory.newInstance();
         SOAPMessage sm = mf.createMessage();
         SOAPPart sp = sm.getSOAPPart();
         sp.setPrefix("soapenv");
         SOAPEnvelope se = sp.getEnvelope();
         se.addNamespaceDeclaration("soapenv","http://orion:7001");
    giving the following error at runtime:
    Exception in thread "main" java.lang.AbstractMethodError:
    weblogic.were.soap.SOAPEnvelopeImpl.setPrefix(Ljava/lang/String;)V
    at Client.main(Client.java:39)
    I am able to compile without any error/warning all the time.
    This is giving only when putting the saaj(jwsdp-1.4) jars along with weblogic/webservices jars in classpath.
    I am able to run the same application(outside Web-application as a stand-alone java program) without
    any error while not using weblogic/webservices jar in the classpath.
    The saaj jars needed to run without any error are:
    saaj-api.jar
    saaj-impl.jar
    mailapi.jar
    activation.jar
    xercesImpl.jar
    xalan.jar
    dom.jar
    jdom.jar
    I thinks this is a compatibility issue. Please suggest to resolve it.
    Thanks in advance,
    pal_sk

  • Dynamic Class Loading in an EJB Container

    Hello,
    We have a need to load classes from a nonstandard place with in an ejb container, ie a database or secure store. In order to do so we have created a custom class loader. Two issues have come up we have not been able to solve, and perhaps some one knows the answer to.
    Issue 1.
    Given the following code:
    public static void main(String args[])
    MyClassLoader loader = new MyClassLoader("lic.dat");
    System.out.println("Loading class ..." + "TestObject");
    Object o = Class.forName("TestObject",true,loader).newInstance();
    System.out.println("Object:" + o.toString());
    TestObject tstObj = (TestObject) o;
    tstObj.doIt();
    What happens when executed is as follows. Class.forName calls our loader and does load the class as we hoped, it returns it as well, and the o.toString() properly executes just fine. The cast of the object to the actual TestObject fails with a class not found exception. We know why this happens but don't know what to do about it. It happens because the class that contains main was loaded by the system class loader (the primordial class loader as its sometimes called), That class loader does not know about TestObject, so when we cast even though the class is "loaded" in memory the class we are in has no knowledge of it, and uses its class loader to attempt to find it, which fails.
    > So the question is how do you let the main class know to use our class loader instead of
    the system class loader dispite the fact is was loaded by the system class loader.
    Issue 2:
    To make matters worse we want to do this with in an EJB container. So it now begs the question how do you inform an EJB container to use a specific class loader for some classes?
    Mike...

    Holy crap! We are in a similar situation. In creating a plugin engine that dynamically loads classes we use a new class loader for each plugin. The purpose is so that we can easily unload and/or reload a class at runtime. This is a feature supposedly done by J2EE app servers for hot-deploy.
    So our plugins are packaged as JAR files. If you put any class in the CLASSPATH, the JVM class loader (or the class loader of the class that is loading the plugin(s)), will load the class. The JavaDoc API states that the parent classloader is first used to see if it can find the class. Even if you create a new URLClassLoader with NULL for parent, it will always use the JVM class loader as its parent. So, ideally, in our couse, plugins will be at web sites, network drives, or outside of the classpath of the application and JVM.
    This feature has two benefits. First, at runtime, new updates of plugins can be loaded without having to restart the app. We are even handling versions and dependencies. Second, during development, especially of large apps that have a long startup time, being able to reload only one plugin as opposed to the annoying startup time of Java apps is great! Speeds up development greatly.
    So, our problem sounds just like yours. Apparently, the Client, which creates an instance of the plugin engine, tries to access a plugin (after the engine loades it via a new classloader instance for each plugin). Apparently, it says NoDefClassFound, because as you say, the client classloader has no idea about the plugin class loaded by another classloader.
    My co-developer came up with one solution, which I really dont like, but seems to be the only way. The client MUST have the class (java .class file) in its classpath in order to work with the class loaded by another class loader. Much like how in an EJB container, the web server calling to EJB MUST contain the Home and Remote interface .class files in its classpath, the same thing needs to be done here. For us, this means if a plugin depends on 5 others, it must contain ALL of the .class files of those plugins it depends on, so that the classloader instance that loads the plugin, can also see those classes and work with them.
    Have you got any other ideas? I really dislike that this has to be done in this manner. It seems to me that the JVM should be able to allow various class loaders to work with one another in such a way that if a client loaded by one classloader has an import statement in it to use a class, the JVM should be able to fetch the .class out of the other classloader and share it, or something!
    This seems to me that there really is no way to actually properly unload and then reload a class so that the JVM will discard and free up the previous class completely, while using the new class.
    I would be interested in discussing this topic further. Maybe some others will join in and help out on this topic. I am surprised there isn't a top-level forum topic about things like class loaders, JVM, etc. I wish there was a way to add one!

  • Dynamic class loading in J2ME

    Hi all,
    Couple of questions. Is dynamic class loading using classloaders supported in any, if not all versions of J2ME? I guess I should ask first, what exactly does J2ME cover? I see KVM, but do watches and PDA's, set top boxes, refrigerators and so forth all run the same J2ME JVM? Or are their "less feature full" versions? I was hoping the J2ME spec would be the "lowest common denominator" to program for, but I thought I read somewhere that small devices like watches may even have a "smaller" J2ME JVM or something, less capable. So can I write code for J2ME and it will run on all small devices like cell phones, pda's, and so forth? Or is there another J2ME version, perhaps small than J2ME.
    So, from what I have found so far, it appears dynamic class loading is done at startup from a DB (of sorts) as opposed to being able to dynamically find/load classes. If this is so, is there any way to support downloading and reloading new classes like you can with J2SE, such as the hot-swap feature of web servers? Does Class.forName() at least work in that you can "replace" a class with a new version, even if it is not able to have a separate classloader instance? My guess is that J2ME supports only a single classloader space, but I thought I read somewhere that Class.forName() is available. J2ME API shows it I believe, but I could be wrong.
    Any help on this topic would be appreciated.
    Thanks.

    Dynamic class loading is not available in most (if not all) J2ME profiles and configurations. Class.forName() is available (at least in the MID profile), but not to be used for dynamic class loading. It can be used when using device-specific APIs where you can try to load a class containing device specific methods (for example a class that works only on certain Nokia phones, and has methods playSound() and vibrate(), which are not available in MIDP), and if you catch a ClassNotFound exception you can load a class that doesn't use the device specific APIs and contains stubs of the methods, or you can disable certain features in you application that need those features. For an example implementation you can have a look at Nokia's Block Game example (available from their developer site - http://www.forum.nokia.com/main.html).
    As for your other more general questions about different JVM's and such, you should read all about the different configurations and profiles available in J2ME (plenty of information using in the J2ME link on this site).

  • Dynamic Class Loading and Stubs

    How Dynamic Class Loading is used on Java RMI, since stubs are generated on clients using Reflection API?
    I was reading Dynamic code downloading using JavaTM RMI (http://java.sun.com/javase/6/docs/technotes/guides/rmi/codebase.html), it seems to be out of date.
    For example, "The client requests the class definition from the codebase. The codebase the client uses is the URL that was annotated to the stub instance when the stub class was loaded by the registry. Back in step 1, the annotated stub for the exported object was then registered with the Java RMI registry bound to a name."

    "Enhancements in J2SETM 5.0
    Dynamic Generation of Stub Classes
    This release adds support for the dynamic generation of stub classes at runtime, obviating the need to use the Java(tm) Remote Method Invocation (Java RMI) stub compiler, rmic, to pregenerate stub classes for remote objects. *Note that rmic must still be used to pregenerate stub classes for remote objects that need to support clients running on _earlier versions_.*
    When an application exports a remote object (using the constructors or static exportObject methods(1) of the classes java.rmi.server.UnicastRemoteObject or java.rmi.activation.Activatable) and a pregenerated stub class for the remote object's class cannot be loaded, the remote object's stub will be a java.lang.reflect.Proxy instance (whose class is dynamically generated) with a java.rmi.server.RemoteObjectInvocationHandler as its invocation handler.
    An existing application can be deployed to use dynamically generated stub classes unconditionally (that is, whether or not pregenerated stub classes exist) by setting the system property java.rmi.server.ignoreStubClasses to "true". If this property is set to "true", pregenerated stub classes are never used.
    Notes:
    * If a remote object has pre-5.0 clients, that remote object should use a stub class pregenerated with rmic or the client will get an ClassNotFoundException deserializing the remote object's stub. Pre-5.0 clients will not be able to load an instance of a dynamically generated stub class, because such a class contains an instance of RemoteObjectInvocationHandler, which was not available prior to this release.
    * Prior to the J2SE 5.0 release, exporting a remote object would throw a java.rmi.StubNotFoundException if the pregenerated stub class for the remote object's class could not be loaded. With the added support for dynamically generated stub classes, exporting a remote object that has no pregenerated stub class will silently succeed instead. A user deploying a server application to support pre-5.0 clients must still make sure to pregenerate stub classes for the server's remote object classes, even though missing stub classes are no longer reported at export time. Such errors will instead be reported to a pre-5.0 client when it deserializes a dynamically generated stub class.
    (1) The static method UnicastRemoteObject.exportObject(Remote) is declared to return java.rmi.server.RemoteStub and therefore cannot be used to export a remote object to use a dynamically generated stub class for its stub. An instance of a dynamically generated stub class is a java.lang.reflect.Proxy instance which is not assignable to RemoteStub."
    http://java.sun.com/j2se/1.5.0/docs/guide/rmi/relnotes.html

  • Class loading and reflection

    Hi,
    I am trying to use a custom class loader to dynamically load Java classes so that I can get some info (e.g. methods) about the classes via reflection. My problem is that my class loader is written to load Java core classes (i.e. java.lang, java.util, etc.), which as far as I know cannot be done since ClassLoader.defineClass() disallows such attempts. The reason I need to load the core classes is because my program extensively uses Java 5 features (thus have to run using JRE version 5) but need access to Java 1.4 classes in order to get the class' info via reflection.
    I am almost out of ideas and thought that what I am trying to do might be achievable if there is a way where I can use the reflection APIs without loading a class first -- I doubt that this can be done using standard Java API, but I will appreciate it if anyone knows any tools/libraries that can do this or if anyone can give other suggestions to solve my problem.
    Thanks,
    Hendrik

    slackiz wrote:
    Hi,
    I am trying to use a custom class loader to dynamically load Java classes so that I can get some info (e.g. methods) about the classes via reflection. My problem is that my class loader is written to load Java core classes (i.e. java.lang, java.util, etc.), which as far as I know cannot be done since ClassLoader.defineClass() disallows such attempts. The reason I need to load the core classes is because my program extensively uses Java 5 features (thus have to run using JRE version 5) but need access to Java 1.4 classes in order to get the class' info via reflection.
    Just to be clear in case someone else in the future finds this....
    You cannot and must not attempt to "load" core classes from different VM versions into the same VM.
    It doesn't matter what the reason is it is will always be wrong.
    Conversely I am guessing the OP just wants to look/interpret the classes versus actually loading them. So BCEL should work or one could always roll their own class file reader.

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

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

  • 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

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

  • Class loader question

    Hi,
    I got NoClassDefFoundError and when I use ClasspathDebug jsp it shows that the class is loaded by "java.net.URLClassLoader". I put the jar file containing the class in <domain>/lib directory. According to docs the jar under <domain>/lib should be loaded by system class loader. what is "java.net.URLClassLoader"? why isn't system loader loading my class? I am using wls91. Thanks
    weblogic.servlet.jsp.TagFileClassLoader
    weblogic.utils.classloaders.ChangeAwareClassLoader
    weblogic.utils.classloaders.GenericClassLoader
    weblogic.utils.classloaders.GenericClassLoader
    java.net.URLClassLoader
    sun.misc.Launcher$AppClassLoader
    sun.misc.Launcher$ExtClassLoader
    Bootstrap classloader

    I'm not sure from reply 2 whether you figured out what's going on or not. It sounds like you did, but just in case...
    The null/primordial/bootstrap class loader loads classes in the core API--stuff it finds in the ext dir(s?) (e.g. rt.jar)--Object, String, java.util.*, java.sql.*, etc. It has no parent. It is the root of the normal delegating classloader tree.
    The system classloader is the one that uses classpath to load your classes and 3rd party classes. Everything not in the core API, as long as neither you nor those other classes explicitly specify a different classloader.
    The way the normal delegation mechanism works is that a request to load a class is first passed to the loader that loaded the current class. This loader first gives its parent a chance to load it, and so on up the tree to the primordial loader.
    Once it hits the root (null/primordial/bootstrap), that classloader tries to load it. If it can't (and the primordial loader can't, in fact, load your class, since it's not in the ext dir), then it hands it back to its child. This continues down the line, with the parent getting first shot at loading, then the child trying if the parent fails.
    The primordial loader (which loaded the JdbcOdbcDriver) can't load your class. It hands it back to its child--the system classloader--which can and does load it, using classpath.
    I hope that answers any lingering questions, if there were in fact such questions.

Maybe you are looking for