Changing Default JPA Provider in WebLogic Server

Changing Default JPA Provider in WebLogic Server :

WebLogic Server has been providing both Kodo and TopLink as JPA providers since WLS 10.3.1.

Unless an explicit <provider>...</provider> is specified in the persistence.xml file of a deployed application, WLS will use Kodo by default.

With the release of WLS 10.3.3, we have now provided a way to change the default JPA provider at the domain level, allowing you to switch between Kodo or TopLink as the default persistent provider that weblogic server will use.

The default JPA provider setting is exposed via a new MBean: JPAMBean on the DomainMBean, and persists the configuration into the config.xml file.

Steps to Change the Default provider:

• Login to weblogic server console
• Click on the Domain and click on JPA
• Change the Default JPA Provider to TopLink and click on Save

Oracle TopLink is the default persistence provider in WebLogic Server 12c and later but you can change to Kodo if required.

Modifying the DVM’s and Business Rules using SOA Composer

Modifying the DVM’s and Business Rules using SOA Composer

Oracle SOA Suite Composer is a J2EE application deployed into the weblogic server that help us to edit the DVM’s and the Business Rules after the deployment  to the Oracle SOA Suite server during the runtime.

The SOA Composer application can be accessed using the following URL

http://<SOA Server Host>:<SOA Server port>/soa/composer/

To modify the DVM’s or the Business Rules the weblogic user must have the SOADesigner role.

When using Oracle SOA Composer, you can save your customizations in a sandbox environment without applying them to a running instance and later return to the sandbox to make additional customizations. These customizations are only applied to the running instance when you click Commit.

Modify DVM:

• Login to SOA Composer
• Click on open and then click on Open DVM, this will list all the DVM’s deployed to MDS

java.lang.ClassCastException: weblogic.jms.common.DurableSubscription cannot be cast to weblogic.jms.backend.BEConsumerCommon

 java.lang.ClassCastException: weblogic.jms.common.DurableSubscription cannot be cast to weblogic.jms.backend.BEConsumerCommon

I was receiving the following exception in my local Oracle SOA Suite environment 11.1.1.6.0.

java.lang.ClassCastException: weblogic.jms.common.DurableSubscription cannot be cast to weblogic.jms.backend.BEConsumerCommon

        at weblogic.jms.backend.BackEnd.dump(BackEnd.java:2880)

        at weblogic.jms.JMSService.dump(JMSService.java:1169)

        at weblogic.jms.common.JMSDiagnosticImageSource.createDiagnosticImage(JMSDiagnosticImageSource.java:43)

        at weblogic.diagnostics.image.ImageSourceWork.run(ImageSourceWork.java:111)

        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)

        Truncated. see log file for complete stacktrace

After analysis found that this is a known issue related to weblogic server versions 10.3.4 and 10.3.5.

Solution:

Download and apply the patch 10023173 from Metalink.

Cluster Constraint for the deployment in weblogic server

Cluster Constraint for the deployment in weblogic server

Cluster constraint specifies that deployments targeted to a weblogic cluster succeed only if all servers in the cluster are running.

When this option is enabled, WebLogic Server enforces a strict two-phase deployment policy for all Managed Servers in a domain—ensuring that application deployment to a cluster succeeds only if all Managed Servers in the cluster are reachable and can deploy the application. If any server instance in the cluster is unreachable, the application is not deployed to any of the Managed Servers.

If you do not enable this option, WebLogic Server allows deployment to a partial cluster. When the unreachable Managed Server becomes available, deployment to that server instance will be initiated.

By default, cluster constraints are disabled and deployment is attempted only on the servers that are reachable at the time of deployment from the Administration Server.

To Enable Cluster Constraint:

• Login to Weblogic Admin Console
• Click on the domain name
• Select the Check box against “Enable Cluster Constraint”

Installing the patches to weblogic server using Oracle Smart Update

Installing the patches to weblogic server using Oracle Smart Update:

Oracle Smart Update tool help us to apply and manage the patches for weblogic server.

As of Smart Update 3.3.0, the Get Patches tab has been removed, and you can no longer use Smart Update to download patches, service packs, maintenance packs, or version upgrades. You must first download the appropriate patch or patches directly from My Oracle Support. Once downloaded, you can use Smart Update to apply the patches.

Smart Update 3.3.0 no longer prompts you to register for security updates from Oracle Configuration Management (OCM).

The version can be verified from Help -> About.

This blog will explain the steps to install the patches to a weblogic server using Oracle Smart Update.

Steps to install the patches to a weblogic server using Oracle Smart Update

• Download the patch through metalink using the patch id or bug no.
• Uncompress patch zip file to $MWHOME/utills/bsu/cache_dir (If the cache_dir folder is not available then create the same)

•  Launch the Oracle Smart Update Tool (bsu.cmd) from $MWHOME\utils\bsu, this will list all the applied patchs and all those patches that are ready for installation.