Classloader In Ejb

"Imagine we're using this class from a WAR, but that this class is also used within an EJB Jar in the same EAR. This class will have been loaded by the EJB
class loader, and will be unable to load classes within the WAR.
The solution is to provide the ability to pass in a ClassLoader.Do not use this constructor within the EJB tier.Obtaining the class loader is illegal on behalf of an EJB."
Anybody can tell me the details of classloader in EJB? I don't know above paragraph's accurate meaning.

Have a look at
http://www.onjava.com/pub/a/onjava/2001/07/25/ejb.html
Instantiating objects of a same class in different subunits will not cause errors, but it is true that, according to the classloading policy (configurable in application server), the behaviors of creational mecanisms such as singleton for example, can vary.
Bruno
http://www.practicalsoftwarearchitect.com

Similar Messages

Where is RAR classloader in the classloader hierarchy?

          The 6.1 docs re: packaging
          (http://e-docs.bea.com/wls/docs61/programming/packaging.html)
          state:
          "When WebLogic Server deploys an application, it creates two new classloaders:
          one for EJBs and one for Web applications. The EJB classloader is a child of the
          Java system classloader and the Web application classloader is a child of the
          EJB classloader. This allows classes in a Web application to locate EJB classes,
          but EJB classes cannot locate Web application classes."
          So where is a RAR's classloader in this scheme? Is another classloader created
          as a peer of the EJB classloader? In that case, how can EJB's ever use classes
          in common with a resource adapter? The case I have in mind is a resource-adapter-specific
          subclass of ManagedConnectionFactory (call it FooManagedCnxnFactory): when
          FooManagedCnxnFactory.equals(FooManagedCnxnFactory fmcf)
          is called by the appserver during a Connection request, fmcf is not an instanceof
          FooManagedCnxnFactory (although that's its classname) because it was loaded by
          another classloader. How do the various classloaders relate, and how should I
          package my resource adapter so that the classes get loaded by the proper classloader?
          Thanks.
          Jim Tomlinson


"Jim Tomlinson" <[email protected]> wrote in message
          news:[email protected]...
          >
          > The 6.1 docs re: packaging
          > (http://e-docs.bea.com/wls/docs61/programming/packaging.html)
          > state:
          >
          > "When WebLogic Server deploys an application, it creates two new
          classloaders:
          > one for EJBs and one for Web applications. The EJB classloader is a child
          of the
          > Java system classloader and the Web application classloader is a child of
          the
          > EJB classloader. This allows classes in a Web application to locate EJB
          classes,
          > but EJB classes cannot locate Web application classes."
          >
          > So where is a RAR's classloader in this scheme? Is another classloader
          created
          > as a peer of the EJB classloader? In that case, how can EJB's ever use
          classes
          > in common with a resource adapter? The case I have in mind is a
          resource-adapter-specific
          > subclass of ManagedConnectionFactory (call it FooManagedCnxnFactory): when
          > FooManagedCnxnFactory.equals(FooManagedCnxnFactory fmcf)
          > is called by the appserver during a Connection request, fmcf is not an
          instanceof
          > FooManagedCnxnFactory (although that's its classname) because it was
          loaded by
          > another classloader. How do the various classloaders relate, and how
          should I
          > package my resource adapter so that the classes get loaded by the proper
          classloader?
          > Thanks.
          There's no any connection between RAR classloader and EJB classloader. So
          whenever you need any classes from RAR, you must have a copy in EJB-JAR. But
          still you'll get a lot of classloader-related problems (like
          ClassCastException). That's really a vague area in JCA 1.0
          >
          > Jim Tomlinson
          Dmitri "Vinny" Girenko [email protected]
          Software Developer http://www.akumiitti.fi/
          Akumiitti Ltd GSM: +358 40 846 2486
          Tammasaarenkatu 5 B Tel: +358 201 500 574
          00180 Helsinki FAX: +358 201 500 502
          Finland

Bug! Hot-deploying the same bean more than once results in a DeploymentException!

Hi all,
Anyone else having this problem? When re-deploying an EJB within a
running WL server 4.5.1 w/ sp9 more than once results in the following
DeploymentException. The first time we re-deploy it works fine, but any
re-deployments after that fail.
This is potentially fatal in that if we have to make more than one
change to a bean over time and re-deploy those changes, we have to cycle
the server, which is NOT acceptable for a production environment!
Any clues or workarounds would be greatly appreciated.....Thanks!
BP
[xxxx.xxxx.com] < /pkg/bea > java -classpath
/pkg/bea/classes:/pkg/bea/lib/weblogicaux.jar weblogic.deploy -redeploy
xxxxxxx file:/pkg/bea/classes/OurSessionBean.jar
weblogic.ejb.common.DeploymentException: Unable to create bean
classloader:
weblogic.ejb.common.DeploymentException: loading EJB JAR
/local/pkg/bea/depot/weblogic-4.51/classes/OurSessionBean.jar; nested
exception is:
java.io.EOFException
java.io.EOFException
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Compiled Code)
at java.lang.Throwable.<init>(Compiled Code)
at java.lang.Exception.<init>(Compiled Code)
at java.io.IOException.<init>(IOException.java:35)
at java.io.EOFException.<init>(EOFException.java:43)
at java.io.DataInputStream.readUnsignedShort(Compiled Code)
at
weblogic.utils.classfile.LineNumberTable_attribute$line_num_struct.read(Compiled
Code)
at
weblogic.utils.classfile.LineNumberTable_attribute.read(Compiled Code)
at weblogic.utils.classfile.AttributeTable.read(Compiled Code)
at weblogic.utils.classfile.Code_attribute.read(Compiled Code)
at weblogic.utils.classfile.AttributeTable.read(Compiled Code)
at weblogic.utils.classfile.ClassMember.read(Compiled Code)
at weblogic.utils.classfile.MethodTable.read(Compiled Code)
at weblogic.utils.classfile.ClassFile.read(Compiled Code)
at weblogic.utils.classfile.ClassFile.<init>(Compiled Code)
at weblogic.ejb.internal.EJBJarLoader.computeExclude(Compiled
Code)
at weblogic.ejb.internal.EJBJarLoader.initialize(Compiled Code)
at weblogic.ejb.internal.EJBJarLoader.<init>(Compiled Code)
at weblogic.ejb.internal.EJBJarLoader.<init>(Compiled Code)
at weblogic.ejb.internal.EJBJarDeployment.setup(Compiled Code)
at weblogic.ejb.internal.EJBJarDeployment.redeploy(Compiled
Code)
at
weblogic.ejb.internal.EJBJarDeployment.redeploy(EJBJarDeployment.java:629)
at
weblogic.ejb.internal.EJBManagerImpl.redeploy(EJBManagerImpl.java:266)
at
weblogic.ejb.common.EJBManager_WLSkel.invoke(EJBManager_WLSkel.java:169)
at
weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(Compiled Code)
at
weblogic.rmi.extensions.BasicRequestHandler.handleRequest(Compiled Code)
at
weblogic.rmi.extensions.BasicRequestDispatcher$BasicExecuteRequest.execute(Compiled
Code)
at weblogic.t3.srvr.ExecuteThread.run(Compiled Code)
at java.lang.Throwable.fillInStackTrace(Native Method)
at
weblogic.rmi.extensions.BasicRequest.sendReceive(BasicRequest.java:44)
at
weblogic.ejb.common.EJBManager_WLStub.redeploy(EJBManager_WLStub.java:312)
at weblogic.deploy.deploy(deploy.java:129)
at weblogic.deploy.runBody(deploy.java:79)
at weblogic.utils.compiler.Tool.run(Tool.java:55)
at weblogic.deploy.main(deploy.java:140)

how about undeploy an already deployed bean first and then trying to redeploy.
becoz i know there's an option like that with DDDeploy. I am talking of 5.1 but the
logic should probably work in 4.5 too.
Try doing it and see what happens.
-Vikas
Blah Blah wrote:
Hi all,
Anyone else having this problem? When re-deploying an EJB within a
running WL server 4.5.1 w/ sp9 more than once results in the following
DeploymentException. The first time we re-deploy it works fine, but any
re-deployments after that fail.
This is potentially fatal in that if we have to make more than one
change to a bean over time and re-deploy those changes, we have to cycle
the server, which is NOT acceptable for a production environment!
Any clues or workarounds would be greatly appreciated.....Thanks!
BP
[xxxx.xxxx.com] < /pkg/bea > java -classpath
/pkg/bea/classes:/pkg/bea/lib/weblogicaux.jar weblogic.deploy -redeploy
xxxxxxx file:/pkg/bea/classes/OurSessionBean.jar
weblogic.ejb.common.DeploymentException: Unable to create bean
classloader:
weblogic.ejb.common.DeploymentException: loading EJB JAR
/local/pkg/bea/depot/weblogic-4.51/classes/OurSessionBean.jar; nested
exception is:
java.io.EOFException
java.io.EOFException
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Compiled Code)
at java.lang.Throwable.<init>(Compiled Code)
at java.lang.Exception.<init>(Compiled Code)
at java.io.IOException.<init>(IOException.java:35)
at java.io.EOFException.<init>(EOFException.java:43)
at java.io.DataInputStream.readUnsignedShort(Compiled Code)
at
weblogic.utils.classfile.LineNumberTable_attribute$line_num_struct.read(Compiled
Code)
at
weblogic.utils.classfile.LineNumberTable_attribute.read(Compiled Code)
at weblogic.utils.classfile.AttributeTable.read(Compiled Code)
at weblogic.utils.classfile.Code_attribute.read(Compiled Code)
at weblogic.utils.classfile.AttributeTable.read(Compiled Code)
at weblogic.utils.classfile.ClassMember.read(Compiled Code)
at weblogic.utils.classfile.MethodTable.read(Compiled Code)
at weblogic.utils.classfile.ClassFile.read(Compiled Code)
at weblogic.utils.classfile.ClassFile.<init>(Compiled Code)
at weblogic.ejb.internal.EJBJarLoader.computeExclude(Compiled
Code)
at weblogic.ejb.internal.EJBJarLoader.initialize(Compiled Code)
at weblogic.ejb.internal.EJBJarLoader.<init>(Compiled Code)
at weblogic.ejb.internal.EJBJarLoader.<init>(Compiled Code)
at weblogic.ejb.internal.EJBJarDeployment.setup(Compiled Code)
at weblogic.ejb.internal.EJBJarDeployment.redeploy(Compiled
Code)
at
weblogic.ejb.internal.EJBJarDeployment.redeploy(EJBJarDeployment.java:629)
at
weblogic.ejb.internal.EJBManagerImpl.redeploy(EJBManagerImpl.java:266)
at
weblogic.ejb.common.EJBManager_WLSkel.invoke(EJBManager_WLSkel.java:169)
at
weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(Compiled Code)
at
weblogic.rmi.extensions.BasicRequestHandler.handleRequest(Compiled Code)
at
weblogic.rmi.extensions.BasicRequestDispatcher$BasicExecuteRequest.execute(Compiled
Code)
at weblogic.t3.srvr.ExecuteThread.run(Compiled Code)
at java.lang.Throwable.fillInStackTrace(Native Method)
at
weblogic.rmi.extensions.BasicRequest.sendReceive(BasicRequest.java:44)
at
weblogic.ejb.common.EJBManager_WLStub.redeploy(EJBManager_WLStub.java:312)
at weblogic.deploy.deploy(deploy.java:129)
at weblogic.deploy.runBody(deploy.java:79)
at weblogic.utils.compiler.Tool.run(Tool.java:55)
at weblogic.deploy.main(deploy.java:140)

11g Release 1 Patch Set 3 (WLS 10.3.4)

Hi.
While creating new server in OEPE Helios(11.1.1.6) I found that WLS 10.3.4 is available for selection. However I didnt find any information neither links to download it. Only 10.3.3 is available.
When and where it is\would be available for download?
Thanks

frf,
Hello, as part of the WebLogic 10.3.4 release on friday - we verified JPA 2.0 functionality for enterprise users using JPA as their persistence pattern. The main issues were JPA 2.0 XSD validation and JPA 2.0 container managed persistence unit injection.
The details of the following post outline what happens out of the box and how JPA 2.0 can be officially enabled on JEE5 compliant WebLogic 10.3.4 install +(with or without the QWG8 patch)+
In 10.3.3.0 you were required to use the FilteringClassLoader via the *<wls:prefer-application-packages>* addition to your application managed persistence unit - this workaround is now deprecated and not required in 10.3.4.0 for both application and container managed persistence contexts.
Specifically we will start retesting EE applications using a SSB injected @PersistenceContext container managed JTA transactional JPA 2.0 persistence units with/without JPA 2.0 XSD elements.
I verified the server and it is using SVN rev# *8635 from 6 Dec 2010* https://fisheye2.atlassian.com/changelog/eclipselink/?cs=8635
Essentially in order to enable JPA 2.0 functionality on WebLogic 10.3.4 shipped on 14 Jan 2011 - you apply the QWG8 patch below or manually edit your server classpath to put the JPA 2.0 persistence specification API jar and the com.oracle.jpa2support_1.0.0.0_2-0.jar ahead of the other liibraries on the classpath.
commEnv.cmd: line 67
@rem Set BEA Home
set BEA_HOME=C:\opt\wls1034r20110115
@rem Enable JPA 2.0 functionality on WebLogic Server 10.3.4 with the following patch line for commEnv.cmd:67
set PRE_CLASSPATH=%BEA_HOME%\modules\javax.persistence_1.0.0.0_2-0-0.jar;%BEA_HOME%\modules\com.oracle.jpa2support_1.0.0.0_2-0.jarEverything is shipped with WebLogic 10.3.4 but JPA 1.0 is enabled by default so that this JEE5 capable server is backwards compatible with JEE5/JPA1 out of the box. Without the above patch you will see the following.
<15-Jan-2011 5:58:40 o'clock PM EST> <Info> <Management> <BEA-141107> <Version: WebLogic Server 10.3.4.0 Fri Dec 17 20:47:33 PST 2010 1384255 >
[EL Info]: 2011-01-15 18:06:38.082--ServerSession(48997950)--Thread(Thread[[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--EclipseLink, version: Eclipse Persistence Services - 2.1.2.v20101206-r8635
[EL Info]: 2011-01-15 18:06:38.082--ServerSession(48997950)--Thread(Thread[[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--Server: 10.3.4.0
We have the required bundles in the modules directory...
javax.persistence_1.0.0.0_2-0-0.jar (upgraded from 1-0-2)
org.eclipse.persistence_1.0.0.0_2-1.jar (upgraded from 2-0)
A very quick test of a JPA 2.0 container managed app with the following persistence.xml in the ejb.jar works as detailed below.
There are 3 issues we must check.
1) JPA 2.0 XSD parsing errors: as expected there are no more JPA 2.0 schema parsing issues.
2) New JPA 2.0 schema elements like the *<shared-cache-mode>NONE</shared-cache-mode>* element - this passes validation but we need to verify runtime functionality
3) JPA 2.0 runtime API like a entityManager.getMetamodel(); call on the Servlet or Statless session bean
4) JPA 2.0 weaving/instrumentation - Again we need to verify something like weaving of Entities contaiing lazy IndirectLists are weaved properly by the container.
Note: All testing in this post is on a WebLogic 10.3.4.0 install out-of-the-box. The only modification I made was in creating a derby 10.5.3.0 JTA global datasource "localJTA" on the server - and drop a container managed JPA 2.0 app as an EAR in the autodeploy directory on the default user domain.
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
    <persistence-unit name="example" transaction-type="JTA">
        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> 
        <jta-data-source>localJTA</jta-data-source>
        <shared-cache-mode>NONE</shared-cache-mode>
        <properties>
            <property name="eclipselink.target-server" value="WebLogic_10"/>
            <property name="eclipselink.target-database" value="Derby"/>
            <property name="eclipselink.logging.level" value="FINEST"/>
            
            <property name="eclipselink.logging.logger" value="DefaultLogger"/>
            
            
        </properties>
    </persistence-unit>For 3) we get the following exception out of the box on a servlet if we do not apply the above mentioned patch below - because the container defaults to Java EE 5 functionality - or JPA 1.0
http://download.oracle.com/docs/cd/E18476_01/doc.220/e18480/weblogicchap.htm
java.lang.NoSuchMethodError: javax/persistence/EntityManager.getMetamodel()Ljavax/persistence/metamodel/Metamodel;
at org.eclipse.persistence.example.jpa.server.weblogic.enterprise.presentation.FrontController.processGliderComm
and(FrontController.java:346)
or 3) The same exception if we try to run JPA 2.0 on the DI entityManager from the SSB in the EJB container classLoader
javax.ejb.EJBException: EJB Exception: : java.lang.NoSuchMethodError: javax/persistence/EntityManager.getMetamodel()Ljavax/persistence/metamodel/Metamodel;
+     at org.eclipse.persistence.example.jpa.server.business.ApplicationService.insertObjects(ApplicationService.java:66)+
+     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)+
+     at java.lang.reflect.Method.invoke(Method.java:597)+
+     at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)+
+..+
+     at $Proxy74.insertObjects(Unknown Source)+
+     at org.eclipse.persistence.example.jpa.server.business.ApplicationService_5ptwty_ApplicationServiceLocalImpl.__WL_invoke(Unknown Source)+
We also get the Kodo/OpenJPA provider when we attempt to weave.
+<openjpa-1.1.1-SNAPSHOT-r422266:965591 fatal user error> org.apache.openjpa.util.MetaDataException: "org.eclipse.persistence.example.jpa.server.business.Cell.id" declares generator name "EL_SEQUENCE_CELL", but uses the AUTO generation type. The only valid generator names under AUTO are "uuid-hex" and "uuid-string".+
+     at org.apache.openjpa.persistence.AnnotationPersistenceMetaDataParser.getGeneratedValueStrategy(AnnotationPersistenceMetaDataParser.java:1226)+
Therefore there is still a little bit of configuration required.
Enabling JPA2 support
1) install the QWG8 patch, or
2) manually add the com.oracle.jpa2support_1.0.0.0_2-0.jar ahead of the server classpath by following the instructions in the documentation at
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13720/using_toplink.htm#EJBAD1309
or doing it manually by modifying the following line
C:\opt\wls10340_pub110115\wlserver_10.3\common\bin\commEnv.cmd
set PRE_CLASSPATH=%BEA_HOME%\modules\javax.persistence_1.0.0.0_2-0-0.jar;%BEA_HOME%\modules\com.oracle.jpa2support_1.0.0.0_2-0.jar
Results
The following code
@Local
@Stateless
public class ApplicationService implements ApplicationServiceLocal {
    @PersistenceContext(unitName="example", type=PersistenceContextType.TRANSACTION)
    private EntityManager entityManager;
    public boolean insertObjects(List<Cell> classes) {
        try {
            for(int i=0; i< classes.size(); i++) {
                entityManager.persist(classes.get(i));
            System.out.println("JPA 2.0 Metamodel: " + entityManager.getMetamodel());           ...prints out the JPA 2.0 EntityManager dependency injected into the SSB proxy for the life of the transaction in the function
JPA 2.0 Metamodel: MetamodelImpl@34817119 [ 5 Types: , 2 ManagedTypes: , 2 EntityTypes: , 0 MappedSuperclassTypes: , 0 EmbeddableTypes: ]+
+[EL Finer]: 2011-01-15 22:36:00.33--UnitOfWork(34913451)--Thread(Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--TX beforeCompletion callback, status=STATUS_ACTIVE+
You can see that when we debug the stateless session bean $Proxy that has our injected EntityManager...
this     ApplicationService_5ptwty_Impl (id=11616)
     __WL_EJBContext     SessionEJBContextImpl (id=11654)
     entityManager     $Proxy73 (id=11639)
          h     TransactionalEntityManagerProxyImpl (id=11638)
               appName     "org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEAR" (id=11513)
               closeMethod     Method (id=11663)
               moduleName     "org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB.jar" (id=11515)
               persistenceUnit     PersistenceUnitInfoImpl (id=11665)
               persistenceUnitName     "org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEAR#org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB.jar#example" (id=11666)
               queryMethods     HashSet<E> (id=11668)
               transactionAccessMethod     Method (id=11669)
               transactionalMethods     HashSet<E> (id=11670)
               txHelper     TransactionHelperImpl (id=11523)
               txRegistry     ServerTransactionManagerImpl (id=11524)
               unqualifiedPersistenceUnitName     "example" (id=11672)     ...no longer complains about an unknown getMetamodel() JPA 2.0 method signature
Oracle WebLogic Server 11gR1 PatchSet 3 r20110115 at localhost [Oracle WebLogic Server]
     Java HotSpot(TM) Client VM[localhost:8453]
          Daemon Thread [[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'] (Running)
          Daemon Thread [[ACTIVE] ExecuteThread: '18' for queue: 'weblogic.kernel.Default (self-tuning)'] (Suspended)
               TransactionalEntityManagerProxyImpl.invoke(Object, Method, Object[]) line: 18
               $Proxy59.getMetamodel() line: not available [local variables unavailable]
               ApplicationService_5ptwty_Impl(ApplicationService).insertObjects(List<Cell>) line: 60
..               JdkDynamicAopProxy.invoke(Object, Method, Object[]) line: 204
               $Proxy71.insertObjects(List) line: not available
               ApplicationService_5ptwty_ApplicationServiceLocalImpl.__WL_invoke(Object, Object[], int) line: not available
               SessionLocalMethodInvoker.invoke(BaseLocalObject, MethodDescriptor, Object[], int, String, Class<?>) line: 39
               ApplicationService_5ptwty_ApplicationServiceLocalImpl.insertObjects(List) line: not available
               FrontController.generateGlider(PrintWriter) line: 252
..               FrontController(HttpServlet).service(ServletRequest, ServletResponse) line: 820
               StubSecurityHelper$ServletServiceAction.run() line: 227
..               ExecuteThread.run() line: 176
arg1     Method (id=11511)
     clazz     Class<T> (javax.persistence.EntityManager) (id=8312)
     name     "getMetamodel" (id=11543)
     returnType     Class<T> (javax.persistence.metamodel.Metamodel) (id=11545)     For 4) Weaving is occuring as expected on either the JPA 1.0 or JPA 2.0 entities. We check this by either checking that our Entity is an instanceof org.eclipse.persistence.internal.weaving.PersistenceWeaved interface, or debug into the Entity and look for our bytcode instrumented weaved fields that start with _persistence*. The question is - we need a weaved field or weaved function that was introduced for JPA 2.0
[4]     Cell (id=11571)
     _persistence_fetchGroup     null
     _persistence_primaryKey     null
     _persistence_session     null
     _persistence_shouldRefreshFetchGroup     false
     aCellAttribute     null
     id     null
     left     null
     peers     HashSet<E> (id=11572)
          map     HashMap<K,V> (id=11575)
com.oracle.jpa2support_1.0.0.0_2-0.jar forensicsI had a look at the patch jar com.oracle.jpa2support_1.0.0.0_2-0.jar that WebLogic 10.3.4 ships with that allows installers to enable JPA 2.0 (JSR-317) support to superceed the default JPA 1.0 (JSR-220) support. It looks like the container proxy code for container managed EntityManagerFactory and EntityManager $Proxy objects has been updated so that a JPA 2.0 EntityManager $Proxy object get injected with the proper API level object via the InvocationHandlerFactory, FactoryInterceptor. The Query proxy has been updated as well. There is a fix for Kodo(OpenJPA) and OpenJPA related to the recent change and deprecation of certain functions of those providers. The EclipseLink JPA 2.0 provider (as the provider for TopLink) did not need weblogic changes beyond placing the JPA javax.peristence 2.0 specification jar higher on the classpath.
The root EclipseLink tracking bug is 334468
https://bugs.eclipse.org/bugs/show_bug.cgi?id=334468
OTN downloadhttp://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-main-097127.html
Patching
http://download.oracle.com/docs/cd/E18476_01/doc.220/e18480/weblogicchap.htm
Documentationhttp://download.oracle.com/docs/cd/E17904_01/web.1111/e13852/toc.htm
Supported Oracle WebLogic Server Versionshttp://download.oracle.com/docs/cd/E15315_06/help/oracle.eclipse.tools.weblogic.doc/html/SupportedServerVersions.html
TopLink JPA 2.0 Specifichttp://download.oracle.com/docs/cd/E17904_01/web.1111/e13720/using_toplink.htm#EJBAD1309
see related
JPA 2: Reverify JPA 2.0 XSD support in persistence.xml on AM/CM app on WebLogic 10.3.3.0
http://bugs.eclipse.org/331569
JPA 2.0: Add WebLogic 10.3 configuration process to enable the JPA 2.0 library functionality - updated
http://bugs.eclipse.org/296271
http://en.wikipedia.org/wiki/Oracle_WebLogic_Server - updated
JPA: Add downloadable 60k weblogic.EAR to wiki page (outside of SVN) - reopened
http://bugs.eclipse.org/294745
JPA: support WebLogic 10.3.4.0 introduction of new JPA MBean that changes the default JPA provider
http://bugs.eclipse.org/312824
JPA: Update tutorial wiki for WebLogic 10.3 to match the Oracle WebLogic 11g 10.3.3.0 - assigned
http://bugs.eclipse.org/310849
To be answered
OTN Post: WebLogic 10.0 + JPA 2.0 = errors - updated
Re: WebLogic 10.0 + JPA 2.0 = errors
Deploy Hibernate based EAR file on Weblogic 10.3.3?
OTN Post: Default JPA provider for Weblogic Server 10.3.2 (11g) - updated
Default JPA provider for Weblogic Server 10.3.2 (11g)
OTN Post: Hibernate 3.6 Final (JPA 2.0) + WL 10.3.x :Unable to deploy sample appn - updated
Hibernate 3.6 Final (JPA 2.0) + WL 10.3.x :Unable to deploy sample appn
WebLogic 10.0 + JPA 2.0 = errors
OTN Post: EJB with Hibernate On Weblogic - updated
Re: EJB with Hibernate On Weblogic
OTN Post: OEPE 1.6 - Oracle WebLogic Server 11gR1 PatchSet 3 requres WLS 10.3.4 - answered
OEPE 1.6 - Oracle WebLogic Server 11gR1 PatchSet 3 requres WLS 10.3.4
OTN Post: EJB with Hibernate On Weblogic - updated
Re: EJB with Hibernate On Weblogic
OTN Post: OpenJPA_2.0 NoSuchMethod error (getValidationMode()) - updated
OpenJPA_2.0 NoSuchMethod error (getValidationMode())
JPA 2.0 features used on WebLogic even if they are not available at runtime - notified
http://netbeans.org/bugzilla/show_bug.cgi?id=189205
Option to enable JPA 2.0 for dev WebLogic - notified
http://netbeans.org/bugzilla/show_bug.cgi?id=189348
False-positive error badge on project with JPA targeting WebLogic - notified
http://netbeans.org/bugzilla/show_bug.cgi?id=189626
Giving up on Hibernate (for now), trying EclipseLink...
http://forums.netbeans.org/post-94817.html
http://blogs.sun.com/arungupta/entry/which_java_ee_6_app
Eclipselink 2.0 + WebLogic 10 => No joy (Unable to get Eclipse link 2.0 working with WebLogic 10) - answered
http://www.eclipse.org/forums/index.php?t=msg&goto=644000&S=40e13288641c0af5dc8489343b896348#msg_644000
eclipselink-users Problem of eclipselink upgrade (2.0.2) - WebLogic 10.3.3.0 - answered
http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg04631.html
Re: EclipseLink + JPA 2 in Weblogic 10.3.0
http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg04375.html - answered below
Re: eclipselink-users Problems with Eclipselink 2 (JPA 2.0) & WebLogic 10,
http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg05609.html
[eclipselink-users] Problems with Eclipselink 2 (JPA 2.0) & WebLogic 10 - answered
http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg05639.html
To be Deprecated
JPA 2: Reverify JPA 2.0 XSD support in persistence.xml on AM/CM app on WebLogic 10.3.3.0
http://bugs.eclipse.org/331569
JPA 2.0: Add WebLogic 10.3 configuration process to enable the JPA 2.0 library functionality
http://bugs.eclipse.org/296271
WebLogic 10.3 availability?
/ Michael O'Brien
http://www.eclipselink.org

Weblogic Class Loader issues.

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

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

Cast Exceptions within a WAR

We have a couple of servlets running on WLS 5.1 where the behavior when
          sharing context seems to be broken on WebLogic within a WAR?
          In the init method of one we initialize a single-ton class. It is then
          placed in the ServletContext. Later a 2nd servlet is invoked and also within
          the init method we first check for the existence of that class. The class is
          found, but the moment we tried to cast it to its original form we get a Cast
          exception.
          We tried using both the servletContext returned by the
          config.getServletContext as well as the
          config.getServletContext().getContext("/someURI"). Both returned the same
          object and in both cases the moment the cast is attempted the exception is
          raised.
          Note that a similar exercise when using an Object of type String it works
          fine. This originally led me to believe that maybe is a classpath issue, but
          I pointed the weblogic.classpath to the WEB-INF/lib directory where the jar
          files are, but no luck.
          Any ideas?


Cheers (and if Im wong PLEASE LET ME KNOW too!)                    Nope, you are spot on!
          Cameron Purdy, LiveWater
          "Robert Masters" <[email protected]> wrote in message
          news:[email protected]...
          > It gets even more fun when you start integrating WAR packaged Servlets and
          > EAR packaged enterprise beans. Basically weblogic deals with no less that
          4
          > classloaders:
          >
          > the standard classloader for the VM (loads everything from the classpath)
          > the WLAS server classloader (loads classes from the weblogic.class.path)
          > the Servlet classloader(war files etc)
          > the EJB classloader (for ejbs!)
          >
          >
          > My findings so far have show that you must ensure that ANY objects that an
          > EJB shares (via the public interfaces) are ONLY stored in one of the jars
          (i
          > put then in the ejb jar). You see what happens is this:
          >
          > the EAR jar directory sort of "exports" the ejb home , remote interface
          and
          > ANY classes found in the ejb method signatures to the WeblogicClassloader.
          > These classes are then sortof "passed" onto the Servlet classloader.
          > However, if the classes are ALREADY in the WAR they take precedence over
          the
          > classes in the EAR which will ultimately cause a ClassCastException.
          >
          > The simple rule is to ensure that you keep all EJB and related classes in
          > the EAR and any serblet/jsp stuff in the WAR. If you have common classes
          > that are used internally by BOTH Serlet and/or EJB's that are NOT part of
          > the EJB signaures you can put these into the weblogic Classpath
          >
          >
          > Pheewww. It took me a couple of hours to figure all this out but now my
          > Servlet, JSP's and EJBs are all working nicely :)
          >
          >
          > Cheers (and if Im wong PLEASE LET ME KNOW too!)
          >
          > Regards
          >
          > Rob
          > "Cameron Purdy" <[email protected]> wrote in message
          > news:[email protected]...
          > > It is probable that if you execute a .jsp directly immediately after you
          > > launch WL5.1 that this error will not happen. There is a terrible
          > > architectural problem with class loaders in WL and the behavior is
          > extremely
          > > weird (although at least predictable). If the first request to the WL
          > > server goes to a Servlet pkgd in a WAR, then JSPs will be loaded in a
          > > completely different class loader context, including classes from your
          WAR
          > > that the JSP uses! So if you (for example) put something in the
          > > HttpServletRequest attribute table from your Servlet and try to get it
          out
          > > from your JSP, you will get a ClassCastException! (You'd think they
          would
          > > have tried that at least once :-(
          > >
          > > Now here is the weirdness: If, after starting the server, you put in a
          > URL
          > > for a .jsp (and make sure you refresh just in case it was cached), then
          > > subsequent requests to Servlets will work when they forward to JSPs ...
          > > that's right the class loader is somehow set up differently depending on
          > > where the very first HTTP request gets routed to!
          > >
          > > We found this by accident ... we thought we were going to have to scrap
          WL
          > > because of the ClassCastException, but a developer "accidently"
          refreshed
          > a
          > > JSP first and then everything worked!
          > >
          > > Cameron Purdy, LiveWater
          > >
          > > "Julio Castillo" <[email protected]> wrote in message
          > > news:[email protected]...
          > > > We have a couple of servlets running on WLS 5.1 where the behavior
          when
          > > > sharing context seems to be broken on WebLogic within a WAR?
          > > >
          > > > In the init method of one we initialize a single-ton class. It is then
          > > > placed in the ServletContext. Later a 2nd servlet is invoked and also
          > > within
          > > > the init method we first check for the existence of that class. The
          > class
          > > is
          > > > found, but the moment we tried to cast it to its original form we get
          a
          > > Cast
          > > > exception.
          > > >
          > > > We tried using both the servletContext returned by the
          > > > config.getServletContext as well as the
          > > > config.getServletContext().getContext("/someURI"). Both returned the
          > same
          > > > object and in both cases the moment the cast is attempted the
          exception
          > is
          > > > raised.
          > > >
          > > > Note that a similar exercise when using an Object of type String it
          > works
          > > > fine. This originally led me to believe that maybe is a classpath
          issue,
          > > but
          > > > I pointed the weblogic.classpath to the WEB-INF/lib directory where
          the
          > > jar
          > > > files are, but no luck.
          > > >
          > > > Any ideas?
          > > >
          > > >
          > >
          > >
          >
          >

Can't get the Home interface of a Session bean,please!

when I run a client of a SessionBean,(use command "java ....";
the Exception was thrown:
java.lang.ClassCastException
at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
at clientTest.ClientTest.main(ClientTest.java:35)
the mothed main() :
java.util.Properties jndiProperties = new java.util.Properties();
jndiProperties.put("java.naming.provider.url","iiop://localhost:3700");
jndiProperties.put("java.naming.factory.initial","com.sun.jndi.cosnaming.CNCtxFactory");
try {
javax.naming.directory.DirContext jndiCtx = new javax.naming.directory.InitialDirContext(jndiProperties);
Object obj = jndiCtx.lookup("ejb/Stock");
System.out.println(obj);
StockHome sh = (StockHome)PortableRemoteObject.narrow(obj, StockHome.class); //exception was thrown
}catch (javax.naming.NamingException ne) {
ne.printStackTrace();
} catch (Exception e){
e.printStackTrace();
Must I run it in the jar file deployed to appServer?
it's very inconvenient!
Thanks!!

Hello
Inline there are the answers
[email protected] (Grand Gana) wrote:
Hi !
I want to know how to get the local interface of a session ejb from a
jsp page ???
My session ejb is in a jar, and my jsp page is in a war. (they're not
together in a ear)You cannot call your EJB by a local interface by this way.
The war and the ejb-jar must be in the same ear.
This is due to classloading architecture.
I can have access to a remote interface of an other session ejb from
a
jsp page doing :
     InitialContext ctx = new InitialContext();
     Object objref = ctx.lookup("article.ArticleManagerHome");
     ArticleManagerHome home = (ArticleManagerHome)
PortableRemoteObject.narrow(objref,
ArticleManagerHome.class);
But I can't have access to the local interface from the same jsp page
doing :
     MyManagerLocalHome home = (MyManagerLocalHome)ctx.lookup
("article.MyManagerLocalHome");
I get the following error :
javax.naming.NameNotFoundException: Unable to
resolve 'article.ArticleManagerLocalHome' Resolved: 'article'
Unresolved:'ArticleManagerLocalHome' ; remaining
name 'ArticleManagerLocalHome' This is another problem.
Check the jndi name in the ejb-deployment descriptor or check the jndi on your
server to verify that a local interface implementation has been bound to it.
>
What should I do ???
(I don't want to put them in the same ear)
An EJB reference in the web.xml of my war ??? How ?
A lookup with java/comp/... ??? How ?
I don't understand !!! It's so difficult to do simple things !
Bloody EJBs !!!Noooooo ;)
But I can agree with you on local interfaces ....
The J2EE specs speak about "same virtual machine" ....
But classloading architecture "speaks about" "same classloader" (same ejb-jar)
or "related classloaders" (war and ejb in same ear).
I think something is still missing ....
>
TIA
JCMark

ClassNotFoundException in EJB's and Threads (Classloader issue)

A very interesting bug has cropped up in WebLogic 6.1. When a J2EE
application packaged appropriately, a client application running in a
user-created Thread will always throw a ClassNotFoundException when
attempting to get back a user-created object from an EJB living on
another cluster. This error does not happen when the call is being made
from outside a Thread.
Sounds strange, I know, so I'll try to give everyone as much detail as
possible so they can avoid this bug, and so that the folks at BEA can
fix it.
* A java class running inside a clustered WL6.1 server is attempting to
reference an EJB on another clustered WL 6.1 server. Accessing the bean
is not a problem, the client class is able to obtain a remote reference
to the bean and make method calls on it. Calling a method causes the
following stack trace:
2002-01-11 10:36:57,331 [Thread-4] ERROR
wpni.app.mywp.display.DisplayJobs$JobsMonitor -
wpni.app.mywp.display.DisplayJobs$JobsMonitor.run: Error checking Jobs
status.
java.rmi.UnmarshalException: failed to unmarshal class
wpni.app.jobs.JobsData; nested exception is:
java.lang.ClassNotFoundException: wpni.app.jobs.JobsData: This
error could indicate that a component was deployed on a cluster member
but not other members of that cluster. Make sure that any component
deployed on a server that is part of a cluster is also deployed on all
other members of that cluster
java.lang.ClassNotFoundException: wpni.app.jobs.JobsData: This error
could indicate that a component was deployed on a cluster member but
not other members of that cluster. Make sure that any component deployed
on a server that is part of a cluster is also deployed on all other
members of that cluster
at
weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:146)
at
weblogic.rjvm.MsgAbbrevInputStream.readClassDescriptor(MsgAbbrevInputStream.java:211)
at
weblogic.common.internal.ChunkedObjectInputStream$NestedObjectInputStream.readClassDescriptor(ChunkedObjectInputStream.java:290)
at
java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:906)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at
java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at
weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:107)
at
weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:115)
at weblogic.rmi.internal.ObjectIO.readObject(ObjectIO.java:56)
at
weblogic.rmi.internal.BasicRemoteRef.unmarshalReturn(BasicRemoteRef.java:230)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:254)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:220)
at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
at $Proxy140.getJobsData(Unknown Source)
at
wpni.app.mywp.display.DisplayJobs$JobsMonitor.run(DisplayJobs.java:48)
at java.lang.Thread.run(Thread.java:484)
* The class that is not found (JobsData) is definitely in the EAR file
on both the client cluster and the server cluster, and in the
appropriate location.
* When we attempted to run the code outside of a Thread, everything
worked perfectly, so it was definitely the Thread that was causing the
problem.
* Deploying the EJB on the client cluster did not do anything to solve
the problem.
* Adding the JobsData to the System CLASSPATH at the startup of the
WebLogic server DID solve the problem. But of course that defeats the
purpose of packaging everything in the EAR file.
So, the conclusion seems to be that when DisplayJobs$JobsMonitor kicked
off the Thread, the Thread should have been created in either the WAR's
classloader or the JAR's classloader (wouldn't matter, since the
JobsData class is in the JAR's classloader, which is a parent of the
WAR's classloader). But instead, the Thread is being created in the
System classloader, which can't find the JobsData class!
We believe that any Thread created by a class living within an EAR's
classloader should remain within that same classloader, and not migrate
to any other classloader, in order to avoid situations like this. We're
opening a case with BEA to attempt to get this resolved. In the
meantime, we recommend to developers that if they have to make
cross-cluster RMI calls from inside user-created Threads, that they only
attempt to receive primitive types or standard JDK objects. Otherwise,
you'll have to add the classes to the System CLASSPATH at startup of the
WebLogic instance.
Thanks,
Erin
* "[White House spokeperson Ari] Fleischer
* warned Democrats this morning against
* investigations into the Bush administration's
* dealings with Enron. 'The American people
* are tired of partisan witch hunts and endless
* investigations,' he said." [Ed.: Uh... ]
* www.washingtonpost.com/wp-dyn/articles/A25159-2002Jan10.html
* Erin Reid Myers, Chief Architect
* WashingtonPost.Newsweek Interactive
* [email protected]
* Work: (703) 469-3154
* Cell: (703) 725-3050
[att1.html]

Things can go seriously wrong if your application uses user threads (violating
EJB spec programming restrictions and BEA recommendations).
I'm curious, does it work if you enable network classloading on the server
which invokes remote EJB (in config.xml -
<Server NetworkClassLoadingEnabled="true" ...
</Server>
Erin Reid Myers <[email protected]> wrote:
A very interesting bug has cropped up in WebLogic 6.1. When a J2EE
application packaged appropriately, a client application running in a
user-created Thread will always throw a ClassNotFoundException when
attempting to get back a user-created object from an EJB living on
another cluster. This error does not happen when the call is being made
from outside a Thread.
Sounds strange, I know, so I'll try to give everyone as much detail as
possible so they can avoid this bug, and so that the folks at BEA can
fix it.
* A java class running inside a clustered WL6.1 server is attempting to
reference an EJB on another clustered WL 6.1 server. Accessing the bean
is not a problem, the client class is able to obtain a remote reference
to the bean and make method calls on it. Calling a method causes the
following stack trace:
2002-01-11 10:36:57,331 [Thread-4] ERROR
wpni.app.mywp.display.DisplayJobs$JobsMonitor -
wpni.app.mywp.display.DisplayJobs$JobsMonitor.run: Error checking Jobs
status.
java.rmi.UnmarshalException: failed to unmarshal class
wpni.app.jobs.JobsData; nested exception is:
java.lang.ClassNotFoundException: wpni.app.jobs.JobsData: This
error could indicate that a component was deployed on a cluster member
but not other members of that cluster. Make sure that any component
deployed on a server that is part of a cluster is also deployed on all
other members of that cluster
java.lang.ClassNotFoundException: wpni.app.jobs.JobsData: This error
could indicate that a component was deployed on a cluster member but
not other members of that cluster. Make sure that any component deployed
on a server that is part of a cluster is also deployed on all other
members of that cluster
at
weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:146)
at
weblogic.rjvm.MsgAbbrevInputStream.readClassDescriptor(MsgAbbrevInputStream.java:211)
at
weblogic.common.internal.ChunkedObjectInputStream$NestedObjectInputStream.readClassDescriptor(ChunkedObjectInputStream.java:290)
at
java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:906)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at
java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at
weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:107)
at
weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:115)
at weblogic.rmi.internal.ObjectIO.readObject(ObjectIO.java:56)
at
weblogic.rmi.internal.BasicRemoteRef.unmarshalReturn(BasicRemoteRef.java:230)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:254)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:220)
at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
at $Proxy140.getJobsData(Unknown Source)
at
wpni.app.mywp.display.DisplayJobs$JobsMonitor.run(DisplayJobs.java:48)
at java.lang.Thread.run(Thread.java:484)
* The class that is not found (JobsData) is definitely in the EAR file
on both the client cluster and the server cluster, and in the
appropriate location.
* When we attempted to run the code outside of a Thread, everything
worked perfectly, so it was definitely the Thread that was causing the
problem.
* Deploying the EJB on the client cluster did not do anything to solve
the problem.
* Adding the JobsData to the System CLASSPATH at the startup of the
WebLogic server DID solve the problem. But of course that defeats the
purpose of packaging everything in the EAR file.
So, the conclusion seems to be that when DisplayJobs$JobsMonitor kicked
off the Thread, the Thread should have been created in either the WAR's
classloader or the JAR's classloader (wouldn't matter, since the
JobsData class is in the JAR's classloader, which is a parent of the
WAR's classloader). But instead, the Thread is being created in the
System classloader, which can't find the JobsData class!
We believe that any Thread created by a class living within an EAR's
classloader should remain within that same classloader, and not migrate
to any other classloader, in order to avoid situations like this. We're
opening a case with BEA to attempt to get this resolved. In the
meantime, we recommend to developers that if they have to make
cross-cluster RMI calls from inside user-created Threads, that they only
attempt to receive primitive types or standard JDK objects. Otherwise,
you'll have to add the classes to the System CLASSPATH at startup of the
WebLogic instance.
Thanks,
Erin
* "[White House spokeperson Ari] Fleischer
* warned Democrats this morning against
* investigations into the Bush administration's
* dealings with Enron. 'The American people
* are tired of partisan witch hunts and endless
* investigations,' he said." [Ed.: Uh... ]
* www.washingtonpost.com/wp-dyn/articles/A25159-2002Jan10.html
* Erin Reid Myers, Chief Architect
* WashingtonPost.Newsweek Interactive
* [email protected]
* Work: (703) 469-3154
* Cell: (703) 725-3050
Dimitri

Problem with EJB skeleton classloader

Hi
We have been migrating an enterprise application from Weblogic 7 to 9.2 and experienced strange problem with EJBs. Our EAR contains (beside the other elements) an EJB module with EJBs and some common POJO classes inside. At the deploy and run phase everything seems working fine, but when the remote client invokes a method which receives one of the common classes as a parameter we get ClassNotFoundException on the server side (talking precisely, the exception is thrown from the EJB skeleton, trying to unmarshall the parameter).
It seems that our EJB's skeletons do not see the classes from EAR. We have tried moving the common classes to the APP-INF/lib directory or placing them at the root of EAR archive and adding reference in Manifest file of EJB module and it won't help.
The only workaround we've found is to add the missing classes to the server classpath but this is unacceptable (however, it works).
We are not using any custom classloader hierarchy.
The other JARs have no problem loading the content of our EJB module (including the common classes, which cause the problem).
So, why is the RMI classloader ommiting our application contents?

The problem was fixed by upgrading to version 9.2.1

EJB Classloader issue (dmcl40 library.dll already loaded)

I have written a stateless session bean. The session bean calls a documentum connection pool. This connection pool are java classes that use a dll (dmcl40.dll).
The Project is wrapped into a DC (one for ejb, one for app libs)
The dll-directory is set in the PATH environmentvariable.
Also, I set the classpath to my jar files in application-j2ee-engine.xml (tab expert settings -> classpath).
My problem is the EJB classloading. Any time the createSession method in the EJB (documentum) tries to create a session pool, i get the dmcl40 library already loaded error.
1. Where do I have to set the path to the library in WebAS to fix this?
2. is there a setting in the VisualAdmin, where one can set the path. Where can i set the path for parent classloader?
I am greateful for any hints.
thanks markus

Hi Markus,
Can u please let me know how did u solve ur problem?..
I am facing same problem and not able to fix it. So ur answer may be greatful to fix my problem..
Thanks in Advance.
Waiting ur Reply.
Best Regards,
Sadik.

EJB lookup returned stub from a different classloader.

I've written an EJB for doing authenitcation. This EJB is accessed by an security-mbean (BEA's login module).
- The EJB is deployed in an EAR.
- The EJB-stubs are extracted and is included as part of the MBEAN Jar.
When I hit a webapp causing the EJB lookup to occur, the stub object returned is created by the webapp's classloader. This cause a ClassCastException when trying to cast the returned home interface into the home interface of the MBEAN's classloader.
Note that all this is happening on the same BEA server running WLS8.1.
I don't want to put the EJB jar on the system classpath so I can redeploy the EJB, the Application's EAR and the MBEAN to a cluster.
-alex

Robert Greig <[email protected]> wrote:
Thanks for responding to my question, which newsgroup is more appropriate for
my line of question?
But before I move this thread, I would like to add:
I've already handled the recursion problem on top of the ejb-lookup before JNDI
becomes avaliable (while doing server startup) problem.
The advantage with the EJB model is this. By changing the host/port configuration,
I can switch between a local-authentication server or a remote provide authentication
server network configuration.
If I were to include the necessary classes in the mbean JAR from our application,
there maybe resources issues since I now have 2 classloaders loading my server-portion
of classes. Not sure how that will workout with resources and all. This model
has the disadvantage of any classes I have in the mbean JAR will require updates
outside my EAR. This wroks against the EAR deployment model.
-alex
Alex Cheung wrote:
I've written an EJB for doing authenitcation. This EJB is accessedby an security-mbean (BEA's login module).
- The EJB is deployed in an EAR.
- The EJB-stubs are extracted and is included as part of the MBEANJar.
This isn't a good approach. You are pretty much stuffed mainly for the
reasons you outline.
Also note that if you continue to go down this road you will have to
handle the potential recursion (i.e accessing an EJB will invoke a
security call to your provider!).
Why do you need to implement this as an EJB? The main advantages of EJBs
are security and container managed transactions neither of which is
relevant here surely?
Robert

Classloading [EAR] - [webapp.war+ejb.jar]

Hi.
I've got a problem with the classloader hierarchy in WL 6.0.
When I deploy my war/ejb application as an EAR, everything works fine.
But I want (for several reasons) to deploy
EJB jars and WebApp wars (or exploded Web Apps) seperately.
WL 6.0 EJB classloader doesn't export remote/home interfaces and
helper classes,
so my web app can't find them.
When I include that interfaces/classes in my Web App, I get
occasionally ClassCastExceptions (I assume depending on classloader
caching).
Is there a way to configure the classloader hierarchy, or do you have
any other solution for this?
Thanks,
Roman

Hello,
I have a big application to do.
So, one solution should be to use an EAR for one
module, containing the WAR for the web-tier and the
EJB-JAR for the business-tier.
It would be better doing like this than creating a
big WAR, in order to avoid to deploy a big WAR when a
modification is done in one module.Are you using local EJBs or remote EJBs? The only way for a war to talk to a local EJB is to package the war along with the ejb-jar in an EAR file because they need to be collocated. You can not simply bundle EJB classes in a war file.
If you are using remte EJBs, then you can package the EJB client view classes along with the servlets and JSPs in the war file and deploy the war separately. But again your war will be one big war.
If your EJBs are just entity beans, then Java EE 5 (see http://weblogs.java.net/blog/ss141213/archive/2005/12/using_java_pers.html) allows you some nice options.
>
What about the problem of the session ?
In fact, I have to declare a context-root for one
EAR.
And at each context-root is created an object
HttpSession on the server.
So, I have some questions about this :
- How can I configure my WARs in order to use only
one HttpSession object for every WARs ?
There is no standard way to do this. Relying on any application server specific feature can only make your app non-portable. So I strongly recommend you not to do this.
- Can I put multiple WARs in one EAR ?Of course you can.
If yes, what about the context-root ? This solution would resolve
the session problem.Can't be solved using any standard way. So I suggest you stick to one big war, if that's what your business requirement is.To speed up development-deployment-test cycle, any appserver allows a rapid deployment option where in you can deploy incremental changes to server. Use this facility during development. DON'T sacrifice portability of your app by using any product specific configuration that you may not find any where else.
Thanks,
Sahoo

Ejb deployment - classloader question

Hi Guys
I have a very basic question regarding EJB deployment in Weblogic 6.1 sp2.
Is it possble to create an EAR file such that -
1>it contains a WAR file [of servlets/jsps/client classes] - A
2>a jar file containing our core server classes[not EJBs] - B
3>a jar file containing EJBs - C
here A and C are definitely getting loaded by different class loaders - I want
the classloader for B to be parent of the classloaders for A and C - so that both
A and C can see B. - is this possible by some EAR/Weblogic specific way.
OR
the best solution is to place the B in the main classpath and deploy the C and
A in an EAR?
thanks
Anamitra

Inline.
Anamitra wrote:
Hi Guys
I have a very basic question regarding EJB deployment in Weblogic 6.1 sp2.
Is it possble to create an EAR file such that -
1>it contains a WAR file [of servlets/jsps/client classes] - A
2>a jar file containing our core server classes[not EJBs] - B
3>a jar file containing EJBs - C
here A and C are definitely getting loaded by different class loaders - I want
the classloader for B to be parent of the classloaders for A and C - so that both
A and C can see B. - is this possible by some EAR/Weblogic specific way.Made possible by placing B in the ear at the root level and referring to B with the
Class-Path manifest directive in the ejb jar file for C. This will put B in the ejb
classloader's classpath making it visible to C and to A since the classloader for C
is the parent of the classloader for A. Which, is the recommended way.
>
OR
the best solution is to place the B in the main classpath and deploy the C and
A in an EAR?
This works, but the classfiles in B are now static for the uptime of the server. If
you want to make changes in B, you must restart the server. If you configure it the
way described above, you can reload the B classes by redeploying the application ear.
>
thanks
AnamitraHere is the link with all of the info:
http://edocs.bea.com/wls/docs61/programming/packaging.html#1029830
Bill

EJB classloader, xerces

Hi,
on a BEA 6.1, system administrators put xerces 1 into the classpath. I need to
deploy a EJB which user xerces 2, so I've unpacked xerces2 jar and included all
the classes into my EJB jar.
This doesn't work, i still have, correctly, the classloaders to load the xerces
1 classes. There's a way to force an "inverse" delegation for the EJB classloader
(as in a web app with, preferwebinfclasses).
Thank you!
Stefano.

The classloader that loades EJB is the root classloader of your application. One way to add more libraries to that classloader is modifying the orion-applicaiton.xml.

EJB n ClassLoading ..

Hi,
I trying to load different versions of ejb-client jar files into different ClassLoaders ..
I am actually able to load the versioned valueobjects, but when I invoke a method on the bean ( using reflection ) passing the valueobjects I loaded, I get a 'NoSuchMethodException'.
I think its because: the bean is loaded ( during home.create() ) by some network ( RMI ) ClassLoader and the valueobjects are actually loaded by my custom ClassLoader from jar file .. any help is greatly appreciated.
Thanks.

Ok,
First, define the Server :
Go to "Window" --> "Show View" --> "Other" ,
Go to the node "Server", expand it then choose "Server"
On the server view, right click then choose "New" --> "Server" then configure your Server paramaters.
Then you can create a "J2EE Enterprise Application project", choose you Server as "Target Runtime".
This should define your classpath correctly.
But, if you are new to j2ee, this is just a warm up beceause EJB are not
very easy to develop.
Note : This allow you to create EJB 2.1 only !!!!!
Regards,
Sebastien Degardin.

Classloader In Ejb

Similar Messages

Maybe you are looking for