WSAD, EJB, runtime class load error

In WSAD 5.1.1, for my EJB Project
I added required JAR files to Java Build Path correctly
I have compliled my EJB successfully.
I have Generated RMIC and Deploy ...
- MY EJB runs fine to display "Hello"
- But When I run the same EJB to connect the database which requires a JAR file
it gives error class not found at : Class.forName(driver).newInstance();
Can any one tell how to add JAR file to EJB class path to run my EJB successfully??
Thanks in advance...

1. After you add jar to your project build path, it ONLY helps in compiling these java source code. Those jars do nothing while you EJBs and helper classes running in EJB container.
2. While EJBs and helper classes running in container, the Application Server (WSAD test server or Websphere application server) will look for jars in server's classpath.
The best approach for adding jars as I know:
1. You usually have a J2EE application project (EAR project).
2. Add (copy) jars into the EAR project.
3. Other projects (EJB or Java project) set dependency in project properties rather than adding jar into build path.
This approach will help your code running anywhere. Also you may find the following article by IBM very helpful to you.
http://www-106.ibm.com/developerworks/websphere/library/techarticles/0112_deboer/deboer.html
Regards,
Joe

Similar Messages

Error building project using kXML2 - "Class loading error: Wrong name"

Hi,
I'm testing the XML-Parser KXML2 and downloaded the latest package, but the minimal version (kxml2-min.zip). I put this file into the directory "%j2mewtk%\apps\KxmlTest\lib" and wrote the lines
import org.kxml2.io.*;
import org.xmlpull.v1.*;
When I try to build the project with the Wireless Toolkit (v1.04) it spits out the following error:
Error preverifying class kxml2.io.KXmlParser
Class loading error: Wrong name
com.sun.kvem.ktools.ExecutionException: Preverifier returned 1
Build failed
I also tried the full package "kxml2.zip" but the same error occurs.
How can I get rid of this? Thanks in advance!

Okay, finally worked it out (hopefully). I unpacked the archive to a directory (say "%J2MEWTK%\apps\KxmlTest\tmpclasses") and then preverified them "manually":
%J2SDK%\bin\preverify.exe -classpath "%J2MEWTK%\apps\KxmlTest\tmpclasses";"%J2MEWTK%\lib\midpapi.zip" org.kxml2.io.KXmlParser
%J2SDK%\bin\preverify.exe -classpath "%J2MEWTK%\apps\KxmlTest\tmpclasses";"%J2MEWTK%\lib\midpapi.zip" org.xmlpull.v1.XmlPullParser
%J2SDK%\bin\preverify.exe -classpath "%J2MEWTK%\apps\KxmlTest\tmpclasses";"%J2MEWTK%\lib\midpapi.zip" org.xmlpull.v1.XmlPullParserException
Then I packed them again to a jar-file:
%J2SDK%\bin\jar.exe -cvf kxml2-min.jar %J2MEWTK%\apps\KxmlTest\tmpclasses\output\.
That was all!

Runtime class loading

I'm working on an application and I need to do something kind of tricky. The classes needed to run will vary depending on what a user selects in the gui. If one thing is selected use these classes, if the other thing is selected use these other classes. The worst part of all this is that the jar files that contain the different classes interfere with each other. So if I put all of the jars in the classpath it stops working.
So what I'd like to do is use the URLClassLoader, if possible. So in my code I have this:
File root = new File(System.getProperty("user.dir"),"lib");
File[] jars = root.listFiles();
URL[] urls = new URL[jars.length];
for(int i=0;i<jars.length;i++) {
urls[i] = jars.toURL();
loader = URLClassLoader.newInstance(urls,Main.class.getClassLoader());
In the File(System.getProperty("user.dir"),"lib") directory I put the jar files and it seems to be loading properly. But now what? Do I specifically load each class before I can use it using loader.loadClass()?

Well, I spent most of today working on it and I'm not any closer than I was a week ago.
Here's where I go wrong:
At this point in my code
     if(serverType.equalsIgnoreCase("weblogic")) {
          rmbs = new WebLogicServerInstance();
     else if(serverType.equalsIgnoreCase("websphere")) {
          rmbs = new WebSphereServerInstance();
     }I'm trying to use a static initializer in the WebLogicServerInstance, it looks like this:
static {
     try {
          File root = new File(System.getProperty("user.dir")+File.separator+"lib","weblogic.jar");
          urlLoader = new URLClassLoader(new URL[] { root.toURL() } );
     urlLoader.loadClass("javax.management.AttributeNotFoundException");
     urlLoader.loadClass("javax.management.InstanceNotFoundException");
urlLoader.loadClass("javax.management.MalformedObjectNameException");
     urlLoader.loadClass("javax.management.MBeanAttributeInfo");
     urlLoader.loadClass("javax.management.MBeanException");
     urlLoader.loadClass("javax.management.MBeanInfo");
     urlLoader.loadClass("javax.management.MBeanServer");
     urlLoader.loadClass("javax.management.ObjectInstance");
     urlLoader.loadClass("javax.management.ObjectName");
     urlLoader.loadClass("javax.management.ReflectionException");
     urlLoader.loadClass("weblogic.management.Helper");
     urlLoader.loadClass("weblogic.management.MBeanHome");
     urlLoader.loadClass("weblogic.management.WebLogicMBean");
          catch(Exception ex) {
               ex.printStackTrace();
     }and what I'm getting is
java.lang.NoClassDefFoundError: javax/management/MBeanServer
at mbeanbrowser.MBeanBrowserMainWindow.login(MBeanBrowserMainWindow.java:191)
Line 191 is rmbs = new WebLogicServerInstance();
So it looks like one of three things.
First, the static initializer isn't being run. I tried adding a System.out.println("Initializer"); to the top of it and it never prints it. So maybe that is the problem. But I also tried a constructor instead of a static initializer and got exactly the same results at exactly the same point.
Second, you can't us URLClassLoader to load jar files that are not in the classpath. According to all my research (Google is a nice tool for developers) URLClassLoader CAN load jar files that are not in the classpath. So I hope I'm wrong about that one.
Third, I am too stupid to live. Right now my brain has turned to oatmeal so that's the way I'm leaning.
Any help for me or am I lost in the woods?

Question about a Class loading error

how can we obtain to reduce the size of classes throughout run time as the source code of my project alone is about 8 MB and this is too heavy for a me program.
so anybody has any suggestions?

I see thanks.
Did you consider keeping that data outside of device (at some web server)? That way, MIDlet would be installed without it and later would download the data from web. Download, in turn, can be done either every time it is needed, or once at MIDlet first launch - in the latter case, downloaded data could be stored in rms for next time it is needed.
Another idea that comes to mind is to keep data in "auxiliary" MIDlet(s) in different suite(s). That way, again, "main" MIDlet would be installed without it but there will be need to install "auxiliary" MIDlet suites with data. In order to provide data access for "main" MIDlet in other suite, the auxiliary MIDlet would need to run and store the data in a shared-access record store - that is, in store created with [AUTHMODE_ANY access parameter|http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/rms/RecordStore.html#AUTHMODE_ANY].

Newbie Class Loader Errors on javax/mail/Part

I'm a newb to Java but have experience in other languages. I built a command line application using Eclipse 3.0 that runs great in Eclipse. The app takes incoming .eml files from a WinXP server's drop dir, parses the attachments and stashes them as blobs in a database. I've jarred my .class files together and set my Class-Path attributes in the Manifest file and the proggie looks like it wants to run until I get to line 102 in main() where I call on one of my helper classes.
The line reads:
MimeWalker objMime = new MimeWalker();
In my MimeWalker class upon instantiation, I have the initialization routine set up some class objects as follows:
public class MimeWalker {
     private int w;
     private boolean headerParsed;
     private String subject;
     private Address from;
     private Address to[];
     private Date sentDate;
     private InputStream bodyCopy;
     private String bodyMimeType;
     private Properties props;
     private Session mailSession;
     private MimeMessage message;
     private Multipart mPart;
     private int partCount;
     private String partContentType;
     private String partDisposition;
     private String partFilename;
     private String partMimeType;
     private InputStream partData;
     /* This method sets the private variables to the necessary values
     * to open a file at this point.
     public MimeWalker(){
          this.props = System.getProperties();
          this.props.put("mail.host", "smtp.dummydomain.com");
          this.props.put("mail.transport.protocol", "smtp");
          this.mailSession = Session.getDefaultInstance(this.props, null);
I have imported javax.mail.*; and javax.mail.internet.*; in my MimeWalker class and since this is the first point in the program where a call to that library is used this is where it's bombing. The bomb message I get is as follows:
Exception in thread "main" java.lang.NoClassDefFoundError: javax/mail/Part
at com.jwt.emailProc.EmailProcessor.main(EmailProcessor.java:102)
I've been dealing with this off anf on for almost 2 days now and have searched countless websites for some insight. I have two hypothesis at this point but don't know how valid either is.
1. javax/mail/Part is actually an Interface and not a class so could that be causing my problems? If so how?
2. Because the mail API relys on the activation.jar library there's some anomaly that is preventing it from working properly. activation.jar just like all the other necessary libraries are located in ./stuff/*.jar in relation to my emailProc.jar application.
Thanks in advance for any help you can provide!
--James

I found out what my problem was. So for all you Java newbs like me remember this!
In the MANIFEST.MF file if you have a line that is longer than 72 bytes (not characters... bytes) the end of the line is scrapped.
That was my problem. As soon as I broke my Class-Path line down into 3 seperate lines with each line starting with a single space and each previous line ending with a single space and cr my app just started working.
The JAR tutorial on this site is a great resource! I advise anyone attempting to Jar their distributions to use it.
-- James

EJB Class loader and regular Java files class loader.

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

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

Error trying to deserialize EJB HomeHandle and EJB Handle classes

I get the following exception when I try to deserialize both a javax.ejb.HomeHandle and a javax.ejb.Handle. I serialize and immediately deserialize within the same application using the same classloader so there are not alot of external variables that may cause the problem. Any ideas on why I can't deserialize an ejb handle?
The reason I am doing this is to try and get around the need to reference another application just to call a remote method in that application. I want to serialize the remote home interface handle or the remote component interface handle and deserialize it using my local application classloader. Does anybody know if this would work?
#1#java.lang.ClassNotFoundException: Loader /L_service:ejb could not load class turtle.registry.SBRegistryRemoteHome
     at com.sap.vmc.core.impl.sapjvm.sharing.NativeSharedClassLoaderImpl.loadClass(NativeSharedClassLoaderImpl.java:609)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:265)
     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:333)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:242)
     at java.io.ObjectInputStream.resolveProxyClass(ObjectInputStream.java:656)
     at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1499)
     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1462)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
     at com.sap.engine.services.ejb3.runtime.impl.LocalHandleDelegate.readStub(LocalHandleDelegate.java:177)
     at com.sap.engine.services.ejb3.runtime.impl.ServerHandleDelegate.readStub(ServerHandleDelegate.java:64)
     at com.sap.engine.services.ejb3.runtime.impl.LocalHandleDelegate.readEJBHome(LocalHandleDelegate.java:101)
     at com.sap.engine.services.ejb3.runtime.impl.StatelessHomeHandleImpl.readObject(StatelessHomeHandleImpl.java:73)
     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:585)
     at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
     at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1818)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1718)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
     at turtle.common.util.SerializationHelper.convertObject(SerializationHelper.java:43)
     at turtle.common.server.connect.RemoteFactory.getRemoteSAPWAS(RemoteFactory.java:206)
     at turtle.common.server.connect.RemoteFactory.getRemote(RemoteFactory.java:46)
     at turtle.common.server.connect.RemoteProxyFactory.getRemote(RemoteProxyFactory.java:99)
     at turtle.common.server.connect.RemoteProxyFactory.create(RemoteProxyFactory.java:91)
     at turtle.common.server.connect.RemoteProxyFactory.createProxy(RemoteProxyFactory.java:52)
     at turtle.server.runtime.registry.RegistryFacade.connectToRegistry(RegistryFacade.java:932)
     at turtle.server.runtime.registry.RegistryFacade.getGenericRegistryBI(RegistryFacade.java:987)
     at turtle.server.runtime.registry.RegistryFacade.unbindObjectsInProject(RegistryFacade.java:857)
     at turtle.registry.ProjectRegistrar$1$1.run(ProjectRegistrar.java:130)
     at java.security.AccessController.doPrivileged(Native Method)
     at javax.security.auth.Subject.doAs(Subject.java:337)
     at turtle.common.security.auth.AuthenticatorBase.doAs(AuthenticatorBase.java:387)
     at turtle.registry.ProjectRegistrar$1.run(ProjectRegistrar.java:172)
     at java.util.TimerThread.mainLoop(Timer.java:512)
     at java.util.TimerThread.run(Timer.java:462)

Has anyone been able to get this to work? Or can anyone confirm that this is a bug?
As a simpler test, I modified the UserManagementBean of the Car Rental example application. I added some code in the register method that serializes and deserializes the Handle object obtained from the SessionContext.getEJBObject().getHandle() method. The serialization completes without issue. However, I get the same error when trying to deserialize the Handle object:
java.lang.ClassNotFoundException: Loader /L_service:ejb could not load class com.sap.engine.examples.epf.ejb.controller.customer.UserManagementHome
     at com.sap.vmc.core.impl.sapjvm.sharing.NativeSharedClassLoaderImpl.loadClass(NativeSharedClassLoaderImpl.java:609)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:265)
     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:333)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:242)
     at java.io.ObjectInputStream.resolveProxyClass(ObjectInputStream.java:656)
     at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1499)
     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1462)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
     at com.sap.engine.services.ejb3.runtime.impl.LocalHandleDelegate.readStub(LocalHandleDelegate.java:177)
     at com.sap.engine.services.ejb3.runtime.impl.ServerHandleDelegate.readStub(ServerHandleDelegate.java:64)
     at com.sap.engine.services.ejb3.runtime.impl.LocalHandleDelegate.readEJBHome(LocalHandleDelegate.java:101)
     at com.sap.engine.services.ejb3.runtime.impl.StatelessHomeHandleImpl.readObject(StatelessHomeHandleImpl.java:73)
     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:585)
     at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
     at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1818)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1718)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
     at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1917)
     at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1841)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1718)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
     at com.sap.engine.examples.epf.ejb.controller.customer.SerializationUtils.deSerialize(SerializationUtils.java:33)
     at com.sap.engine.examples.epf.ejb.controller.customer.SerializationUtils.deepClone(SerializationUtils.java:59)
     at com.sap.engine.examples.epf.ejb.controller.customer.UserManagementBean.register(UserManagementBean.java:75)

Duplicate class definition error while invoking EJB from ADF project

Hi,
I am using Jdeveloper TP3 and facing the following problem.
I have built an EJB project and am ran them successfully in the embedded OC4J via a standalone java program.
Now I created another project with ADF capabilities and when I tried to ping the EJB i get the following exception
The application named, current-workspace-app, could not start due to an error.
duplicate class definition: javax/faces/context/FacesContextFactory Invalid class: javax.faces.context.FacesContextFactory Loader
This is happenning due to class conflicts between javaee.jar and trinidad-impl.jar/adf-richclient-impl.jar.
Is there any way of bypassing this class loader issue?

Hi,
actually I didn' try the JNDI lookup but used resource injection instead
In a JSF managed bean I use
@EJB Ejb30SessionFacadeLocal myLocalInterface;
public SortableModel getTableModel() {
List rows = new ArrayList<Employees>();
rows = myLocalInterface.queryEmployeesFindAll();
this.tableModel = new SortableModel(rows);
return tableModel;
Its a EJB 3.0 session bean that accesses a Local interface. However, if the remote is on the same server then I would think that using @EJB Ejb30SessionFacadeRemote myRemoteInterface; does similar
Frank

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!

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

Re: MBean calling ejb class loading issue

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

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

8iR3; EJB deploy; "Unable to read class bits" error

Hi,
I have a strange situation going on at the moment. Every time I wish to deploy an EJB to 8iR3, the JDeveloper Message View shows the following (after app specific messages):
"Reading Deployment Descriptor...done
Verifying Deployment Descriptor...done
Gathering users...done
Generating Comm Stubs...............................................done
Compiling Stubs...done
Generating Jar File...done
Loading EJB Jar file and Comm Stubs Jar file...
Unable to read class bits from library/sqlhelper/sjb/SQLHelperOperations.class
*** Errors occurred while deploying the EJB to 8i JVM ***
*** Deployment completed ***
If I then just redeploy without changing a thing, it deploys fine and everything works.
I haven't seen a post on this forum like this, is there a configuration problem at my end?
Cheers,
Jono
null

I think it is due to the fact that I am writing a 'business interface' for my EJB, then including it in my deployment package.
This technique is recommended in O'Reilly's 'Enterprise Java Beans' 2nd Edition p344 to ensure the bean interface and the bean match their signature.
I don't get the 'class bits' error when I write EJB from the wizard, but when I add a business interface it happens first deploy, and is OK for the second one.
Hope this helps anyone else who is getting this behaviour, I guess we'll have to see what happens in OC4J/Orion.

I tried downloading the new update for itunes I get these error messages: Visual C runtime library R6034 an application has made an attempt to load the C runtime library incorrectly Error 7 windows error 1114. What should I do to correct this?

I tried downloading the new update for my desktop PC I get the following error messages:
Visual C++ Runtime library
R6034
an application has made an attempt to load the C runtime library incorrectly Error 7 Windows Error 1114

Click here and follow the instructions. You may need to completely remove and reinstall iTunes and all related components, or run the process multiple times; this won't normally affect its library, but that should be backed up anyway.
(99907)

When im trying to download itunes it keeps saying application has made an attempt to load the c runtime library incorrectly error 7 windows error 1114 can anyone help me

When im trying to download itunes it keeps saying R6034 application has made an attempt to load the C runtime library incorrectly error 7 windows error 1114

This forum is for questions from those managing sites on iTunes U, Apple's service for colleges and universities to post educational material in the iTunes Store. You'll be most likely to get help with this issue if you ask in the general iTunes for Windows forum.
Regards.

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 “web-inf/classes” 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

WSAD, EJB, runtime class load error

Similar Messages

Maybe you are looking for