EAR Redeploy

I have deployed an .EAR archive with some EJB-Jars within in my autodeployment
directory /<domain>/applications and everthing is working fine when I start my
Admin Server.
Now I make some changes to an EJB-JAR, create a new EAR and copy it to my /applications
directory. In the console application I unset my "deployed"-flag of the EAR-Application
and after the application has been undeployed I set the flag and try to deploy
the updated archive.
Now the following problem occurs: When undeploying the EAR Archive the config.xml
is corrupted. WLS thinks the EJB-JARs are standalone JAR's in the /applications
directory and not in /application.<app>.ear.
After correcting the mistake I have to restart my servers before the problem is
solved.
Has anyone an idea why my config.xml is corrupt?
Thanks.
Karsten

Are you in windows and using OCI driver ? This is an issue in the OCI driver.
If so, please start OC4J as follows:
java -Doracle.mdb.fastUndeploy=<no of seconds> -jar oc4j.jar
such as
java -Doracle.mdb.fastUndeploy=20 -jar oc4j.jar
regards
Debu

Similar Messages

  • WorkingDir should be relative to config not weblogic root directory

    I would like to use the jsp-descriptor tag workingDir to specify the name of
              a directory where WebLogic Server saves the generated Java and compiled
              class files for a JSP. Hopefully, this would allow compiled jsp classes
              to be re-used on ear redeployment.
              But if I specify a relative location such as WEB-INF\classes, the
              sub-directory is stored under the weblogic root directory. If I want it
              placed under a specific config, I would need to identify it as
              config\domain1\applications\WEB-INF\classes.
              The problem here is that the EAR file is no longer config independent. I
              want to be able to deploy the EAR to any of several configurations...
              Integration, SQA, Demo, Release, etc. without having to build a separate EAR
              for each config.
              Using the same workingDir would have more than one configuration instance
              writing to the same workingDir. Maybe OK if a single EAR is deployed, but
              not if different versions.
              There does not seem to be any way to do it. Ideas?
              

    <p>Add the location of the java jar file to your managed servers classpath, under the server start tab of your servers configuration. See "Set Java options for servers started by Node Manager" in WLS 9 console or edit the setEnv script and add your JDBC driver to the classpath there.</p>
    <p>
    Hussein Badakhchani</br>
    </p>

  • HOT Redeployment of EAR fails with Classloader error

    App Server: WLS 10.3
    OS: Solaris 9
    I have installed WLS installed with a domain, admin and a managed server. Everything is working fine.
    I have WAR and EAR deployed successfully on the Managed Server.
    HOT deployment of WAR files works perfectly fine.
    There is this EAR "IIA.ear" with @ 8 WAR files and 1 jar "Manager.jar". The EAR has been deployed in the "nostage" mode.
    I do not have any separate "Deployment" plan.
    In order to "redeploy" the EAR I go to the Admin console >> Deployments >> Select the EAR >> update >> Source Path remains the same >> Finish
    I get the following error :
    +#####################+
    weblogic.application.CannotRedeployException: Module 'Manager.jar' has the same ClassLoader as the Application 'IIA'. Consider redeploying the entire application.
    Update operation failed - no deployments changed.
    +#####################+
    The log files shows below error
    +#####################+
    +<Sep 15, 2009 9:18:52 AM MEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with+
    ID '1252999132033' for task '8'. Error is: 'weblogic.application.CannotRedeployException: Module 'Manager.jar' has the
    same ClassLoader as the Application 'IIA'. Consider redeploying the entire application.'
    weblogic.application.CannotRedeployException: Module 'Manager.jar' has the same ClassLoader as the Application 'IIA'. Consider redeploying the entire application.
    at weblogic.application.internal.AppClassLoaderManagerImpl.updatePartialDeploySet(AppClassLoaderManagerImpl.java:299)
    at weblogic.application.internal.flow.TailModuleRedeployFlow.validateClassLoaderStructure(TailModuleRedeployFlow.java
    +:135)+
    at weblogic.application.internal.flow.TailModuleRedeployFlow.validateRedeploy(TailModuleRedeployFlow.java:97)
    at weblogic.application.internal.BaseDeployment$ValidateRedeployStateChange.next(BaseDeployment.java:801)
    at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
    Truncated. see log file for complete stacktrace
    +>+
    +#####################+
    does WLS 10 supports HOT deployment of EAR files? Is it any issue with "Class Loading"? Anything to be changed to make this HOT redeployment successful?

    App Server: WLS 10.3
    OS: Solaris 9
    I have installed WLS installed with a domain, admin and a managed server. Everything is working fine.
    I have WAR and EAR deployed successfully on the Managed Server.
    HOT deployment of WAR files works perfectly fine.
    There is this EAR "IIA.ear" with @ 8 WAR files and 1 jar "Manager.jar". The EAR has been deployed in the "nostage" mode.
    I do not have any separate "Deployment" plan.
    In order to "redeploy" the EAR I go to the Admin console >> Deployments >> Select the EAR >> update >> Source Path remains the same >> Finish
    I get the following error :
    +#####################+
    weblogic.application.CannotRedeployException: Module 'Manager.jar' has the same ClassLoader as the Application 'IIA'. Consider redeploying the entire application.
    Update operation failed - no deployments changed.
    +#####################+
    The log files shows below error
    +#####################+
    +<Sep 15, 2009 9:18:52 AM MEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with+
    ID '1252999132033' for task '8'. Error is: 'weblogic.application.CannotRedeployException: Module 'Manager.jar' has the
    same ClassLoader as the Application 'IIA'. Consider redeploying the entire application.'
    weblogic.application.CannotRedeployException: Module 'Manager.jar' has the same ClassLoader as the Application 'IIA'. Consider redeploying the entire application.
    at weblogic.application.internal.AppClassLoaderManagerImpl.updatePartialDeploySet(AppClassLoaderManagerImpl.java:299)
    at weblogic.application.internal.flow.TailModuleRedeployFlow.validateClassLoaderStructure(TailModuleRedeployFlow.java
    +:135)+
    at weblogic.application.internal.flow.TailModuleRedeployFlow.validateRedeploy(TailModuleRedeployFlow.java:97)
    at weblogic.application.internal.BaseDeployment$ValidateRedeployStateChange.next(BaseDeployment.java:801)
    at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
    Truncated. see log file for complete stacktrace
    +>+
    +#####################+
    does WLS 10 supports HOT deployment of EAR files? Is it any issue with "Class Loading"? Anything to be changed to make this HOT redeployment successful?

  • Trying unsuccessfully to redeploy an older ear on WLS9.2

    Hi All,
    I've spent a few days trying to get a redeploy of an ear working on WLS9.2 using the wldeploy ant task. It works where the ear file is newer that the one already deployed, but redeploy just doesn't take effect if the ear we want is older than the one that is already deployed. It doesn't give an error, the log says that it's redeployed, but the redeploy doesn't take effect. This wldeploy task worked fine with WLS8.1 no matter when the ear was built.
    It seems to be the same issue as
    http://forums.bea.com/bea/thread.jspa?forumID=2033&threadID=400002694&messageID=400007471#400007471
    I'm out of ideas, so any help would be gratefully received!
    The original deployment via the console was fine, specifying DDOnly. The ear was loaded from the location C:\EARS\app.ear on the machine "host1" We then specified that the location from which the ear would be available would be \\host1\ears\app.ear which is the same location simply specified as a network drive.
    An Ant task, not the wldeploy task, copies the ear we want from any development machine to the networked host1 location. This step works fine.
    Then we try to redeploy using the wldeploy task. This only seems to work if the ear file we're trying to deploy is newer than the one we already had running.
    The task was as follows, with all options valid and one target server specified in targets:
              <wldeploy action="redeploy"
                   source="${source}"
                   name="${appname}"
                   user="${user}"
                   password="${pass}"
                   verbose="true"
                   adminurl="${adminurl}"
                   debug="true"
                   targets="${targets}">
              </wldeploy>
    Source is specified as \\host1\ears\app.ear
    Since then, we've been changing all kinds of options in wldeploy trying to get it to work for older ears, but it won't.
    extract from one of many log files showing wldeploy logging for an older ear. In this case, we're trying to replace deployed version built at 10:30 with version built at 10:22. It shows successful but the version from 10:30 is still deployed on the managed server ManagedServer1 after the redeploy. The task is:
              <wldeploy action="redeploy"
                   retiretimeout="1"
                   source="${source}"
                   name="${appname}"
                   user="${user}"
                   password="${pass}"
                   verbose="true"
                   adminurl="${adminurl}"
                   debug="true"
                   graceful="false"
                   targets="${targets}">
              </wldeploy>
    copy_ear:
    [delete] Deleting 1 files from \\HOST1\EARS
    [copy] Copying 1 file to \\HOST1\EARS
    weblogic_redeploy:
    [echo] message="ant wldeploy classpath is: /bea/weblogic92/server/lib/weblogic.jar"
    [wldeploy] weblogic.Deployer -debug -verbose -noexit -name app1 -source \\host1\ears\app.ear -targets ManagedServer1 -adminurl t3://host1:5001 -user weblogic -password ******** -redeploy -retiretimeout 1
    [wldeploy] weblogic.Deployer invoked with options: -debug -verbose -noexit -name app1 -source \\host1\ears\app.ear -targets ManagedServer1 -adminurl t3://host1:5001 -user weblogic -redeploy -retiretimeout 1
    [wldeploy] [WebLogicDeploymentManagerImpl.<init>():103] : Constructing DeploymentManager for J2EE version V1_4 deployments
    [wldeploy] [WebLogicDeploymentManagerImpl.getNewConnection():146] : Connecting to admin server at host1:5001, as user weblogic
    [wldeploy] [ServerConnectionImpl.getEnvironment():288] : setting environment
    [wldeploy] [ServerConnectionImpl.getEnvironment():291] : getting context using t3://host1:5001
    [wldeploy] [ServerConnectionImpl.getMBeanServer():239] : Connecting to MBeanServer at service:jmx:t3://host1:5001/jndi/weblogic.management.mbeanservers.domainruntime
    [wldeploy] [ServerConnectionImpl.getMBeanServer():239] : Connecting to MBeanServer at service:jmx:t3://host1:5001/jndi/weblogic.management.mbeanservers.runtime
    [wldeploy] [DomainManager.resetDomain():36] : Getting new domain
    [wldeploy] [DomainManager.resetDomain():39] : Using pending domain: false
    [wldeploy] [MBeanCache.addNotificationListener():96] : Adding notification listener for weblogic.deploy.api.spi.deploy.mbeans.TargetCache@40ece0
    [wldeploy] [MBeanCache.addNotificationListener():103] : Added notification listener for weblogic.deploy.api.spi.deploy.mbeans.TargetCache@40ece0
    [wldeploy] [MBeanCache.addNotificationListener():96] : Adding notification listener for weblogic.deploy.api.spi.deploy.mbeans.ModuleCache@1954f89
    [wldeploy] [MBeanCache.addNotificationListener():103] : Added notification listener for weblogic.deploy.api.spi.deploy.mbeans.ModuleCache@1954f89
    [wldeploy] [ServerConnectionImpl.initialize():171] : Connected to WLS domain: OGPDomain
    [wldeploy] [ServerConnectionImpl.init():161] : Initializing ServerConnection : [email protected]e9
    [wldeploy] [BasicOperation.dumpTmids():690] : Incoming tmids:
    [wldeploy] [BasicOperation.dumpTmids():692] : {Target=ManagedServer1, WebLogicTargetType=server, Name=app1}, targeted=true
    [wldeploy] [RedeployOperation.setupPaths():86] : in place redeploy: false from moduleArchive: \\host1\ears\app.ear
    [wldeploy] [RedeployOperation.setupPaths():95] : redeploy src path: \\host1\ears\app.ear
    [wldeploy] [BasicOperation.deriveAppName():139] : appname established as: app1
    [wldeploy] <08-Aug-2007 10:18:00 o'clock IST> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating redeploy operation for application, app1 [archive: \\host1\ears\app.ear], to ManagedServer1 .>
    [wldeploy] [BasicOperation.dumpTmids():690] : Incoming tmids:
    [wldeploy] [BasicOperation.dumpTmids():692] : {Target=ManagedServer1, WebLogicTargetType=server, Name=app1}, targeted=true
    [wldeploy] [BasicOperation.loadGeneralOptions():607] : Delete Files:false
    [wldeploy] Timeout :3600000
    [wldeploy] Targets:
    [wldeploy] ManagedServer1
    [wldeploy] ModuleTargets={}
    [wldeploy] SubModuleTargets={}
    [wldeploy] }
    [wldeploy] Files:
    [wldeploy] null
    [wldeploy] Deployment Plan: null
    [wldeploy] App root: C:\dev\RELEASE\config\deployments\conord\app1
    [wldeploy] App config: C:\dev\RELEASE\config\deployments\conord\app1\plan
    [wldeploy] Deployment Options: {isRetireGracefully=false,isGracefulProductionToAdmin=false,isGracefulIgnoreSessions=false,rmiGracePeriod=-1,retireTimeoutSecs=1,undeployAllVersions=false,archiveVersion=null,planVersion=null,isLibrary=false,libSpecVersion=null,libImplVersion=null,stageMode=null,clusterTimeout=3600000,altDD=null,altWlsDD=null,name=app1,securityModel=null,securityValidationEnabled=false,versionIdentifier=null,isTestMode=false,forceUndeployTimeout=0,defaultSubmoduleTargets=true,timeout=0}
    [wldeploy] [BasicOperation.execute():424] : Initiating redeploy operation for app, app1, on targets:
    [wldeploy] [BasicOperation.execute():426] : ManagedServer1
    [wldeploy] [RedeployOperation.initializeTask():55] : Starting task with path: \\host1\ears\app.ear
    [wldeploy] Task 69 initiated: [Deployer:149026]deploy application app1 on ManagedServer1.
    [wldeploy] Task 69 completed: [Deployer:149026]deploy application app1 on ManagedServer1.
    [wldeploy] Target state: redeploy completed on Server ManagedServer1
    [wldeploy]
    [wldeploy] [ServerConnectionImpl.close():334] : Closing DM connection
    [wldeploy] [ServerConnectionImpl.close():354] : Unregistered all listeners
    [wldeploy] [ServerConnectionImpl.closeJMX():374] : Closed JMX connection
    [wldeploy] [ServerConnectionImpl.closeJMX():386] : Closed Runtime JMX connection
    [wldeploy] [ServerConnectionImpl.closeJMX():398] : Closed Edit JMX connection
    install_app:
    install_app:
    BUILD SUCCESSFUL
    Total time: 21 seconds
    Thanks for your time,
    ConorD

    Daniel Greeney wrote:
    So I just purchased an internal drive (separate from my system drive) to use as a Time Machine drive, for both of my computers (only one partition). Since they will be backing up every day, I will retain much more recent material in case of drive failure.
    Let Time Machine back up every hour, as it's designed. That will protect you best.
    My question is this - if I have a drive failure on my current internal system drive, and the internal Time Machine is intact, is it possible for me to take my external bootable backup (say 3 weeks older than Time Machine in how recently it was backed up), make a cone of that on a new internal system drive, and then use Time Machine to restore that drive to what is most current on Time Machine?
    Does this question make sense?
    The question makes sense until you realize that Time Machine backups contain everything you need (unless you do something silly, like exclude your system files).
    Once the new drive is installed and formatted, you can restore your entire system from the TM backups faster than you can copy the clone to the new internal HD. See #14 in the Frequently Asked Questions *User Tip,* also at the top of this forum. Note that you use the Snow Leopard Install disc only for the Installer on it; you don't install OSX from it.

  • Developing using EAR structure gives redeploy/classpath issues

    I am very keen to get people's opinions and methods of developing and packaging
    EARs/WARs/EJBs under WL6.1 sp2.
    What method do you use and what problems do you get...
    We have recently migrated to WL6.1 sp2, and looked forward to using the Enterprise
    Applications Archive expanded structure to deploy and develop under. However I
    have come across a few fundamental problems that seem to make development in this
    structure worthless.
    It seems it's easier just have all the expanded classes paths on the Java Classpath
    and just restart the server after a individual class file recompile ?
    Problems :-
    - With an expanded EAR structure, I believe you can only redeploy the WHOLE EAR
    (by touching the REDEPLOY file), not an individual ejb jar or just the WAR part.
    I have tried putting a REDEPLOY file in the WAR \WEB-INF\ directory, as recommended,
    but I think this only works outside of the EAR structure. If you use the Console
    to just undeploy an redeploy the Web App, it redeploys the whole EAR. So this
    leaves us having to undeploy everything to test out a change.
    - The classloaders hierarchy available with an EAR structure seems ideal at first,
    e.g. the Web App can see all EJB jar classes. We have our EJB jars containing
    the beans and just the DEPENDANT classes (often these are abstract types), this
    keeps the jars lean and avoids duplicated classes across ejb jars. But this leaves
    some classes which are not in any EJB jar at all (often subclasses or implementations
    of these abstract types), however the Web App still needs them. It is difficult
    to isolate these individual classes. So for now we have two solutions which don't
    seem quite right :-
    Make one of the EJB.jars contain ALL the Server side classes, not just dependant
    classes. Or make a full jar of ALL server side classes and add this jar to the
    Web Apps \META-INF\manifest Class-Path like you would do with an EJB jar.
    Is there a way to have a non-EJB jar at the EJB classloader level ? This would
    solve this and allow Web Apps to see other non-ejb jars.
    How do you guys works and avoid the problems we've hit ?

    Pete <[email protected]> wrote:
    Is there a way to have a non-EJB jar at the EJB classloader level ? Sure, just add it to the Class-Path: manifest entry in your ejb.jar.
    Dimitri

  • Error loading servlet: 'EbuController' java.lang.NoClassDefFoundError after redeploy EAR in weblogic 6.1

              Hi, there:
              we have deployed our application in EAR format in \config\mydomain\applications.
              This EAR contains one ejb.jar and one web.war. I can access a servlet after I
              deployed the EAR file into weblogic 6.1 sp1. However, if I redeploy this EAR file
              from within weblogic console. I got the following error when I revisit that servlet
              again.
              <Jan 17, 2002 9:30:41 PM PST> <Error> <HTTP> <[WebAppServletContext(1485918,plat
              form,/platform)] Error loading servlet: 'EbuController'
              java.lang.NoClassDefFoundError
              at java.lang.Class.newInstance0(Native Method)
              at java.lang.Class.newInstance(Class.java:237)
              at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubIm
              pl.java:665)
              at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStub
              Impl.java:643)
              at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubI
              mpl.java:588)
              at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.
              java:368)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
              pl.java:242)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
              pl.java:200)
              at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe
              rvletContext.java:2456)
              at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm
              pl.java:2039)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              >
              <Jan 17, 2002 9:30:41 PM PST> <Error> <HTTP> <[WebAppServletContext(1485918,plat
              form,/platform)] Error loading servlet: "EbuController"
              java.lang.NoClassDefFoundError
              at java.lang.Class.newInstance0(Native Method)
              at java.lang.Class.newInstance(Class.java:237)
              at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubIm
              pl.java:665)
              at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStub
              Impl.java:643)
              at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubI
              mpl.java:588)
              at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.
              java:368)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
              pl.java:242)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
              pl.java:200)
              at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe
              rvletContext.java:2456)
              at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm
              pl.java:2039)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              Your help is highly appreciated!
              Jerry
              

              Hi, there:
              we have deployed our application in EAR format in \config\mydomain\applications.
              This EAR contains one ejb.jar and one web.war. I can access a servlet after I
              deployed the EAR file into weblogic 6.1 sp1. However, if I redeploy this EAR file
              from within weblogic console. I got the following error when I revisit that servlet
              again.
              <Jan 17, 2002 9:30:41 PM PST> <Error> <HTTP> <[WebAppServletContext(1485918,plat
              form,/platform)] Error loading servlet: 'EbuController'
              java.lang.NoClassDefFoundError
              at java.lang.Class.newInstance0(Native Method)
              at java.lang.Class.newInstance(Class.java:237)
              at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubIm
              pl.java:665)
              at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStub
              Impl.java:643)
              at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubI
              mpl.java:588)
              at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.
              java:368)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
              pl.java:242)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
              pl.java:200)
              at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe
              rvletContext.java:2456)
              at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm
              pl.java:2039)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              >
              <Jan 17, 2002 9:30:41 PM PST> <Error> <HTTP> <[WebAppServletContext(1485918,plat
              form,/platform)] Error loading servlet: "EbuController"
              java.lang.NoClassDefFoundError
              at java.lang.Class.newInstance0(Native Method)
              at java.lang.Class.newInstance(Class.java:237)
              at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubIm
              pl.java:665)
              at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStub
              Impl.java:643)
              at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubI
              mpl.java:588)
              at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.
              java:368)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
              pl.java:242)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
              pl.java:200)
              at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe
              rvletContext.java:2456)
              at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm
              pl.java:2039)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              Your help is highly appreciated!
              Jerry
              

  • Redeploying war files independent of Ear

    Hii all,
    I have one doubt..
    Can we redeploy one of the war files of an ear application independently and if yes then how on jboss server?
    Thanks and regards
    Sandeep

    RTFM

  • Partial redeploy of an application ear fails intermittently

    Hi,
    I am trying to redeploy my application ear using deployment API provided by weblogic. The list of files which i try to redeploy are couple of jars and couple of wars one at a time. The problem is most of the times the deployment paritally goes through informing me that weblogic has transitioned application status from activated at last. But in some cases i see "<b>javax.management.InstanceAlreadyExistsException"</b> though the application is already present. Why does this happen where in the handle to ApplicationMBean tries to register the application as though it was new which is not the case. Check the exception below.
    javax.management.InstanceAlreadyExistsException: vgndomain:Location=VgnVCMServer,Name=VgnVCMServer_VgnContentSvcs,ServerRuntime=VgnVCMServer,Type=ApplicationRuntime
         at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134)
         at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2371)
         at com.sun.management.jmx.MBeanServerImpl.registerMBean(MBeanServerImpl.java:876)
         at weblogic.management.internal.RemoteMBeanServerImpl.private_registerMBean(RemoteMBeanServerImpl.java:582)
         at weblogic.management.internal.RemoteMBeanServerImpl.registerMBean(RemoteMBeanServerImpl.java:524)
         at weblogic.management.runtime.RuntimeMBeanDelegate.register(RuntimeMBeanDelegate.java:166)
         at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:122)
         at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:85)
         at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:62)
         at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:74)
         at weblogic.j2ee.J2EEApplicationRuntimeMBeanImpl.<init>(J2EEApplicationRuntimeMBeanImpl.java:42)
         at weblogic.j2ee.J2EEApplicationContainer.initRuntimeMBean(J2EEApplicationContainer.java:781)
         at weblogic.j2ee.J2EEApplicationContainer.<init>(J2EEApplicationContainer.java:448)
         at weblogic.j2ee.J2EEApplicationContainerFactory.createApplicationContainer(J2EEApplicationContainerFactory.java:131)
         at weblogic.j2ee.J2EEApplicationContainerFactory.getOrCreateApplicationContainer(J2EEApplicationContainerFactory.java:113)
         at weblogic.management.deploy.slave.SlaveDeployer$Application.getContainer(SlaveDeployer.java:3011)
         at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.createContainer(SlaveDeployer.java:2550)
         at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare(SlaveDeployer.java:2474)
         at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(SlaveDeployer.java:798)
         at weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(SlaveDeployer.java:507)
         at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDeployer.java:465)
         at weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHandler.java:25)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
    Any help on this would be appreciated.
    Thanks,
    Sandeep

    The info for the 149080 error is included below:
    Basically, you can only do a partial redeploy if you are using an exploded directory app.
    Error: A partial update of an archived application is not allowed. Application app cannot be redeployed.
    Description
         There was an attempt to partially redeploy an archived application. Partial redeployment of an archived application is not allowed.
    Cause
         There was an attempt to partially redeploy an archived application
    Action
         Try deploying entire application
    Refer to the deployment documentation for more info.
    http://download.oracle.com/docs/cd/E11035_01/wls100/deployment/redeploy.html#wp1031505
    8.1.2.2 Partial Redeployment of J2EE Modules
    Partial redeployment also enables you to redeploy a single module or subset of
    modules in a deployed Enterprise Application. Again, partial deployment is
    supported only for applications that are deployed using an exploded archive directory.

  • PDK Java Portlet looses edit default values everytime I redeploy EAR

    Hello All,
    I have a PDK Java portlet (Portal - Oracle 10g). It works as expected perfectly till I redeploy my EAR. As soon as I redeploy EAR, it looses the settings that user had set using edit defaults link. Is there anyway to prevent this? Application runs on OC4J server.
    I urgently need solution to this problem and any help would be greatly appreciated.
    Thanks,
    Kinnaree

    Just to be sure, you are registering the PDK producer with a WebCenter portal?
    Or are you just using the PDK provider in an oracle portal environment and you don't use webcenter?
    If you are using webcenter, can you also test this behavior in Oracle portal? Do you also loose the values in oracle portal or is it just in webcenter? This way we can see if it's a webcenter or portlet issue.
    If you loose the values on both the oracle portal and webcenter side, than it has something to do with the portlet. If they are working correctly in oracle portal, than it might be a bug in the PDK bridge in Webcenter.
    Edited by: Yannick Ongena on Jun 23, 2011 11:14 AM

  • Redeploying of exploded EJBs within an exploded EAR

    Hi all,
    I've an exploded EAR application which has an exploded EJB. Inside my exploded EJB, I've a META-INF folder with a REDEPLOY file, if I update my EJB & touches the REDEPLOY file inside the META-INF, the EJB doesn't get redeployed. I'd to touched the REDEPLOY inside the META-INF folder of the exploded EAR, is this behavior correct?
    Or am I missing something here?
    Thanks!

    Hi,
    If you are only attempting to read the file, you should read the file as a resource. If you are planning on writing to this file, then it is not a good idea that you depend on where this file is deployed, just place it anywhere else.
    Anyhow, if you have to do it, the best way is to obtain the resource URL, and from that the file name. BTW, there is no warranty that the war will get exploded, that you may be able to freely modify the file, nor that the file name be null :-S
    {the Classloader of your choice}.getResource(<Resource name>).getFile()
    should do the trick.
    Regards,
    LG

  • Incremental Version releases without redeploying the ear

    We had deployed the ear in oracleAS10g server on windows2000 platform.
    We need to apply the incremental version(patches) changes of jsp/.class files without redeploying the ear file. Where exactly we need to change the files for this to happen, So that we the changes in the files can be viewed. At most we may stop/start server without redeployment of the ear. Plz help usASAP.
    Thanks & regards.
    S. Anand Mohan

    Hi Andreas,
    Thanks for Your help. Could you plz help us in the .class files. What should we do to get the .class files changed without redeploying the ear.
    My mail Id is [email protected]
    with regards,
    S. Anand Mohan

  • Redeploying EAR in OC4J

    Hi, I have an installation of Oracle's Business Intelligence Analytics ( formerly Siebel Analytics ) and I am following an oracle note to patch the application the redeploy it through OC4J. OC4J standalone comes bundled with the BI analytics.
    The application is currently deployed as an EAR file ( analytics.ear ) in $OBIEE_HOME/oc4j_bi/j2ee/home/applications and indeed within OC4J you can see that the analytics application is pointing to this EAR file.
    Another directory $OBIEE_HOME/web holds an identical copy of this EAR file and it is this source directory that the patch changes. You are then asked to recreate the EAR file using
    jar –cf analytics.ear –C app .
    The copy the EAR file into $OBIEE_HOME/oc4j_bi/j2ee/home/applications for redeploying
    Q1. Since the EAR filename will not have changed from the original, do I actually need to go through the process of redeploying within OC4J or will it automatically do this when the OC4J is stopped / started ?
    When I do actually try a redeploy, the Web Module name and the Context root are different from the original ( the port number is the same )
    i.e. the Module name comes up as analytics.ear.war when it was previously analytics, the Context root comes up as /analytics.ear when it previously was simply /analytics
    During the re-deploy the Web Module Name is not editable.
    Q2. Where is this module name set - can it be changed ?
    When redeploying, OC4J shows the application as up and running, however when I try the original url ( http://inibidev:9704/analytics/saw.dll?Answers ) to access the application I simply get Web Page cannot be found
    Q3. Is this due to the differences in my Web Module Name and Context root ?
    any help appreciated,
    Jim

    Ans1: Yes you have to redploy this EAR file again.
    Ans2: Now you have to use new context URL and module name
    Ans3: Yes

  • Redeploying .ear in WLS6.0SP1 fails?

    When we redeploy an .ear file (uncheck the deployed box, copy the .ear
    file, check the deployed box - autoredeploy = off in this case ) in
    WLS6.0SP1 th EJB's are successfully redeployed, but the web-app always
    fails. It complains that the webapp xxx is already in use. (That
    figures, because we redeploy.).
    Another - related? - issue is when automatic redeploy is enabled under
    WinNT and you have a learge .ear file, it starts unjarring the file
    before it's completely copies thus throwing a zipfile in use error.

    When we redeploy an .ear file (uncheck the deployed box, copy the .ear
    file, check the deployed box - autoredeploy = off in this case ) in
    WLS6.0SP1 th EJB's are successfully redeployed, but the web-app always
    fails. It complains that the webapp xxx is already in use. (That
    figures, because we redeploy.).
    Another - related? - issue is when automatic redeploy is enabled under
    WinNT and you have a learge .ear file, it starts unjarring the file
    before it's completely copies thus throwing a zipfile in use error.

  • 10.1.3 bugs - redeployment of an EAR. Toplink and PermGen related

    This is very annoying! We're trying to use the OC4J 10.1.3 specific ant task to perform redeployment of our application. Basically we see, that redeployment of an EAR can't be performed successfully - (this can be reproduced from within OEM).
    By specifying orion-application.xml specific settings, we're forcing our application not to use the toplink shared library. All required libraries are part of our EAR file.
    There are two things noteworthy about this.
    1) Upon calling redeploy, the appserver is unable to remove the toplink.jar file which is stored in the libs directory of the respective EAR. I have no clue why this is happening, but it looks like the appserver is now holding on to our toplink.jar which is part of the application.
    2) Retrying this step, leads to a PermGen Out-of-Memory error.
    I'm hoping one of the Oracle gurus can comment on this (quickly ;-) )
    BTW; we're using OC4J standalone for development.

    To give some more info, here is the output I get upon redeploy:
    D:\oc4j10.1.3.0.0\j2ee\home\applications\NLSIS
    java.io.IOException:Unable to remove D:\oc4j10.1.3.0.0\j2ee\home\applications\NLSIS
      at oracle.oc4j.util.FileUtils.recursiveRemove(FileUtils.java:249)
      at oracle.oc4j.admin.internal.ApplicationUnDeployer.removeFiles(ApplicationUnDeployer.java:146)
      at oracle.oc4j.admin.internal.ApplicationUnDeployer.doUndeploy(ApplicationUnDeployer.java:117)
      at oracle.oc4j.admin.internal.UnDeployerBase.execute(UnDeployerBase.java:91)
      at oracle.oc4j.admin.internal.UnDeployerBase.execute(UnDeployerBase.java:72)
      at oracle.oc4j.admin.jmx.server.mbeans.deploy.OC4JUnDeployerRunnable.doRun(OC4JUnDeployerRunnable.java:46)
      at oracle.oc4j.admin.jmx.server.mbeans.deploy.UnDeployerRunnable.run(UnDeployerRunnable.java:69)
      at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:819)
      at java.lang.Thread.run(Thread.java:595)
    2006-05-03 14:41:15.368 WARNING WARNING: Unable to remove appDir D:\oc4j10.1.3.0.0\j2ee\home\applications\NLSIS
      : Unable to remove D:\oc4j10.1.3.0.0\j2ee\home\applications\NLSIS
    2006-05-03 14:41:15.462 NOTIFICATION Application UnDeployer for NLSIS COMPLETES.

  • Partial redeployment in exploded EAR gets blown away on restart

    I have an exploded EAR with an (exploded) WAR and a JSP inside the WAR. On the filesystem it looks like this:
    /.../foo.ear/blah.war/my.jsp
    The EAR was initially deployed in stage mode, then I switched to nostage. my.jsp is still under development and continues to change. I wrote a simple script that has two steps: 1) copy my.jsp from /some/dir to /.../foo.ear/blah.war/ 2) do a partial deployment/update with weblogic.Deployer -targets <cluster> -name foo -redeploy blah.war/my.jsp .
    The cluster is WL 10.3.3 in Production mode. I start the managed server, run the script that deploys changed JSPs and test the app. Everything is good. Then I restart the managed server...and my changed JSP is no longer there. I have to run the script again in order to make the managed server update the JSP.
    I can't run the deploy script on every server restart. What am I missing here?

    No one here is going to do anything about it. Send feedback to Apple.
    http://www.apple.com/feedback/ipad.html
    Basic troubleshooting steps. 
    17" 2.2GHz i7 Quad-Core MacBook Pro  8G RAM  750G HD + OCZ Vertex 3 SSD Boot HD 

Maybe you are looking for