Showing posts with label Deployment. Show all posts
Showing posts with label Deployment. Show all posts

Solved Oracle Jdevelper 12.1.3 Quick install missing SOA Suite Tiers


After installing Oracle jdeveloper 12.1.3 Quick Install successfully, one can't able to find SOA Tiers to create SOA & BPM applications. I solved this problem by simply updating the Oracle jdevelper as below :

1) Click Help>Check for Updates


























NoClassDefFoundError When Deploying JSF Application Using Commons-Logging And Log4j to Oracle WebLogic

Symptoms

When a single JSF page application with a backing bean that contains an apache commons logging statement using Log4j.jar as the logging provider is deployed,Weblogic always throws an exception.
Including commons-logging.jar and log4j.jar on the classpath causes the exception.


com.sun.faces.mgbean.ManagedBeanCreationException: Cant instantiate class: view.backing.Hello.
at com.sun.faces.mgbean.BeanBuilder.newBeanInstance(BeanBuilder.java:193)
at com.sun.faces.mgbean.BeanBuilder.build(BeanBuilder.java:105)
at com.sun.faces.mgbean.BeanManager.createAndPush(BeanManager.java:369)
at com.sun.faces.mgbean.BeanManager.create(BeanManager.java:230)
at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:88)
Truncated. see log file for complete stacktrace
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: No suitable Log constructor
[Ljava.lang.Class;@16b7343 for org.apache.commons.logging.impl.Log4JLogger (Caused by
java.lang.NoClassDefFoundError: org/apache/log4j/Logger) (Caused by
org.apache.commons.logging.LogConfigurationException: No suitable Log constructor
[Ljava.lang.Class;@16b7343 for org.apache.commons.logging.impl.Log4JLogger (Caused by
java.lang.NoClassDefFoundError: org/apache/log4j/Logger))

at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at view.backing.Hello.<init>(Hello.java:14)
Truncated. see log file for complete stacktrace
org.apache.commons.logging.LogConfigurationException: No suitable Log constructor
[Ljava.lang.Class;@16b7343 for org.apache.commons.logging.impl.Log4JLogger (Caused by
java.lang.NoClassDefFoundError: org/apache/log4j/Logger)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
Truncated. see log file for complete stacktrace
java.lang.NoClassDefFoundError: org/apache/log4j/Logger
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.getConstructor(Class.java:1657)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
Truncated. see log file for complete stacktrace
java.lang.ClassNotFoundException: org.apache.log4j.Logger
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
Truncated. see log file for complete stacktrace


Cause

The webapp classes are not overriding the system classes.

Solution

Add the parameter "prefer-web-inf-classes" to your web-app's weblogic.xml:

   <container-descriptor>
      <prefer-web-inf-classes>true</prefer-web-inf-classes>
   </container-descriptor>


To create a weblogic.xml descriptor:
  1. Right click your ViewController Project in JDeveloper, select New.
  2. Go to Deployment Descriptors > WebLogic Deployment Descriptors > Click OK.
  3. Choose weblogic.xml and follow through.

Deploying Application on Oracle Weblogic 10.3.x throws java.lang.NoClassDefFoundError: org/apache/log4j/Priority


Symptoms

Deploying an ear application onto a WLS 10.3.x domain throws the following error:
Web application: "DataExtractWeb2".
java.lang.NoClassDefFoundError: org/apache/log4j/Priority
  at org.sagph.dataextract.web.DxWebStartup.loadProperties(DxWebStartup.java:101)
  at org.sagph.dataextract.web.DxWebStartup.init(DxWebStartup.java:60)
  at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:283)
  at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
Caused By: java.lang.NoClassDefFoundError: org/apache/log4j/Priority
  at org.sagph.dataextract.web.DxWebStartup.loadProperties(DxWebStartup.java:101)
  at org.sagph.dataextract.web.DxWebStartup.init(DxWebStartup.java:60)
  at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:283)
  at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
  at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
The same application works fine on WLS 10MP1 but it is not working on WLS 10.3.x.



Cause


In WLS versions prior to 10.3.0, the log4j.jar is present in the class path and it gets loaded automatically at the time of server start. But this is not the case for WLS 10.3.0 and later releases. In WLS 10.3.0 and higher, the log4j file is no longer automatically loaded. In this case, the customer application had a dependency on log4j, and so it failed when log4j.jar was no longer automatically loaded with the WLS installation.


Solution


There are two ways to resolve, as below:

The first solution is to load the log4j jar file on startup. To accomplish this, change the value of load-on-startup tag to 1 from -1in web.xml for the servlet code that is referring to log4j. For example, in web.xml, make this change:
<load-on-startup>1</load-on-startup>

The second solution is to place the jar file in the APP-INF/lib directory of the ear file, i.e., <ear_file>/APP-INF/lib. The jar file will be loaded with the ear file and provide the jar file when the application needs it. After adding the jar file to the ear, redeploy the application and restart.

Oracle Weblogic: Deployment of Applications Failing with java.lang.ClassCastException

Sometime weblogic throws ClassCastException while application deployment. Below is one of the scenario and steps how go through with this issue.

Symptoms


WebLogic Server deployment of applications using stax classes is failing with a ClassCastException:

java.lang.ClassCastException: com.ctc.wstx.stax.WstxInputFactory

Cause

This issue was because the customer application uses a different stax jar file version as compared to jar file used by system class loader. Since both have "com.ctc.wstx.stax.WstxInputFactory" as a member, the class is loaded by the system class loader rather than the application class loader, and that is incompatible with its use by the application code.

Solution


To resolve this issue, use the FilteringClassLoader in weblogic.xml (or) weblogic-application.xml descriptor files to load particular classes/packages (in this case, "com.ctc.wstx.stax.*") from the application jar file instead of the system classloader. Below is a snippet of weblogic-application.xml file which has FilteringClassLoader implementation (<prefer-application-packages>) for reference.
UTF-8" ?>
<wls:weblogic-application xmlns:wls="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd">
<wls:application-param>
<wls:param-name>webapp.encoding.default</wls:param-name>
<wls:param-value>UTF-8</wls:param-value>
</wls:application-param>

<prefer-application-packages>
<package-name>javax.jws.*</package-name>
<package-name>org.apache.xerces.*</package-name>
<package-name>com.sun.xml.messaging.saaj.*</package-name>
<package-name>com.ctc.wstx.stax.*</package-name>
<package-name>javax.xml.stream.*</package-name>
</prefer-application-packages>


Java.Lang.OutOfMemoryError In weblogic.WLST Remote Deploy Command


Symptoms


Failure to remotely deploy a very large enterprise application using WLST or the Admin console and getting out of memory error while loading the ear file.
WLSTException: 'Error occured while performing deploy : Target exception thrown while deploying application: Error occured while performing deploy :
Deployment Failed. Error occurred while performing deploy : Deployment Failed.

Use dumpStack() to view the full stacktrace.
The load of a remotely located ear file also fails via the Administration console with the following message:

An unexpected exception has occurred processing your request Message:
  Stack Trace: java.lang.NullPointerException
  at com.bea.console.actions.app.install.Flow.uploadApp(Flow.java:256)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

Cause


The issue was addressed in bug 9456759. As part of the fix, a system property flag weblogic.deploy.UploadLargeFile was added. In WLS 10.3.4 and higher, this flag should be added to the Java startup options for the deployment client if large files are to be deployed. For earlier versions, apply the patch below: no flag is needed.


Solution


Patches are available for Bug 9456759:
PATCH INFORMATION
WLS VersionPatch Number
9.2.2Patch 9456759
9.2.3Patch 9456759
10.0.1Patch 9456759
10.0.2Patch 9456759
10.3.0Patch 9456759
10.3.1Patch 9456759
10.3.2Patch 9456759

Fixed in: 9.2.4, 10.3.4
To apply one of these patches, click on the link for your WLS version and download the appropriate patch from My Oracle Support. You can also search in My Oracle Support for the patch number for your WLS version:


NOTE: Patches are applied per WLS installation and not per domain. That is, if you apply this patch on one WLS installation, then all of the servers from all the domains in that installation will have this patch. On the other hand, if you have a managed server in another machine in a domain (that is, set up with its own WLS installation), you need to install this patch on that other machine as well. Generally, patches can only be applied while the server is not running because WLS locks the needed files while it is running. If, however, you are able to apply a patch while WLS is running, you must restart WLS before the patch will take effect.

Deploying an Application using Production Redeployment Strategy with WLST


This document provides steps for deploying applications using the Production Redeployment strategy with WebLogic Scripting Tool (WLST). Production Redeployment provides application users with 24x7, high availability access without interrupted services.

Solution

In this example we assume that we are deploying application names "survey_web.war" (attached to this note) to an Admin Server running on localhost and port 7001. The username and password will be weblogic/weblogic.
  1. Set WebLogic environment variables by running the setDomainEnv script.
     
  2. Connect to WLST offline mode using below command
    java weblogic.WLST
  3. Connect to the domain using below connect command (to go online):
    connect('weblogic','weblogic','t3://localhost:7001')
  4. Initial deployment and subsequent deployments must be accomplished by naming the deployment versions to ensure high availability and continuity of service:
    Please refer below OTN documentation for more details on options
    http://www.oracle.com/pls/as1111/lookup?id=WLSTC202

    For the first time you deploy application, deploy the application using version number in this example, we will take version number as 10-2.

    Syntax: deploy ('<application name>','<source location>', targets='<target server or cluster>', stageMode='<stage, no stage or external stage>', versionIdentifier='<application version>'
    deploy('survey_web','D:/survey_web.war', targets='AdminServer', stageMode='nostage', versionIdentifier='10-2')

    After deploying the application you can use application name with version number "survey_web (10-2)" in active state in console.
     
  5. To deploy the same application with some updates, deploy the application as below in WLST.

    Syntax: deploy('<application name>','<source location>', archiveVersion='<current version of application>', appVersion='<new version of application>')
    deploy('survey_web','D:/survey_web.war', archiveVersion='10-2', appVersion='10-3')

    The new version of application, 10-3 in this case, will be active and the older archiveVersion 10-2 will go into the retire state after deploying the application with WLST command. So you will have two versions of application: one in active state, and other in retired state.

    The version of the application in the retired state will serve all the existing requests. All new requests will be routed to version of application which is active.