Posts tagged weblogic
Production redeployment is a facility in WebLogic that provides the ability to temporarily have multiple versions of the same web application of web service active at the same time.
Sometimes, changes in application functionality require redeployment of the application. In the theoretical case of instantaneous responses from applications, we could argue that the roll out of a new version of an application is akin to the flip-of-the-switch: request A is handled by version X, the switch is flipped to bring version X+1 live and the next request B is taken care of by the new version. This, however, is not the reality. Requests take longer to process than no time at all. Besides, requests live in the context of a session – this applies to database as well as application server. This means that replacing version X with a new version X+1 in a throw-the-switch manner would not only potentially interrupt pending non-zero duration requests but would also – and far more harmfully – destroy all pending sessions. This would definitely not constitute zero-downtime application upgrade.
Recently I did an audit on a WebLogic 11g platform of one of our customers. There were many problems with the availability of their JAVA Applications. Some of the problems we’re platform related ( installation, configuration and infrastructure related) but a lot of them already existed in an earlier stage at application programming and configuration level.
So I decided to bundle some tips for JAVA programmers how they should configure their EJB, MDB and Servlet applications when they will be deployed on a WebLogic cluster.
This is an example of a typical EJB application architecture in WebLogic Server:
Some hints and tips:
Creating a EIS ConnectionFactory in your Database Adapter can be done with the WebLogic Administration Console, but of course this is also “scriptable”. What I needed was a script that created a Data Source with EIS Connection factory bound to the specific datasource.
First I created a properties file, let’s call it DsCf.properties. Everything between <> should be replaced with your own values:# Propertie file for creating datasource and EIS DB Adapter # Created by Michel Schildmeijer # Domain settings domainname="<your WLS DOMAIN>" adminurl=<WLS HOST:Admin Port> adminusername=weblogic adminpassword=<passwd weblogic> #datasource settings datasourcename=<Name DataSource> datasourcedatabasename=<database> datasourcetarget=<targeted manaegd server> datasourcefilename= datasourcename + '.xml' datasourcejndiname= 'jdbc/' + datasourcename datasourcedriverclass=oracle.jdbc.OracleDriver datasourceurl=jdbc:oracle:thin:@<db host>:1521:<db sid> datasourceusername=<db user> datasourcepassword=<db user password datasourcetestquery=SQL SELECT * FROM DUAL #EIS Connection Factory settings connfactname=eis/DB/<Connection factory More >
Where as in WebLogic 11g JPA was not support by default, in WebLogic 12c it is the default persistency provider.JPA 2.0 is part of JAVA EE 6.
I was trying some new JAVA EE 6 features in WebLogic 12c, so here is a is a way to create a Web Application with JPA under WebLogic 12c
Some of the JAVA EE 6 specifications weâ€™re already supported in WebLogic 11g. JPA 2.0 was one of them. Though version 1.0 was the default. 2.0 also worked.Unless an explicit <provider>…</provider> wass specified in the persistence.xml file of a deployed application, WebLogic 11g used OpenJPA/Kodo by default.
The default JPA provider setting is exposed via a new MBean: JPAMBean on the DomainMBean, and persists the configuration into the config.xml file.
Furthermore, you needed to install the patch QWG8 – Enable JPA 2.0 support on WebLogic Server.
To make it work on 11g, you had to use Oracle TopLink as the persistency provider like the image shows youÂ in the WebLogic Admin Console
Now for 12c this is not needed anymore, TopLink will be the default JPA Provider
Using the Oracle WebLogic Technology Adapters with custom Java – Message Driven Bean (MDB) triggered by File Adapter (part of the story)3
Oracle’s product portfolio contains the Technology Adapters. A set of JCA Connectors that provide a bridge between various technologies – such as JMS, AQ, Database (SQL and PL/SQL), FTP and File System – on the one hand and the world of JEE on the other. The SOA Suite 11g and Oracle Service Bus leverage these adapters to connect to and from these technologies. For example: through the adapters, instances of composite applications can be instantiated through the appearance of a file on the file system or a new record in a database table. And, in the outbound direction: OSB and SOA Suite can call out to PL/SQL procedures, send messages to JMS Topics or an AQ queue and write files to an FTP server.
The technology adapters comply with the JEE standard specification of JCA (Java Connector Architecture). They are deployed as a special type of resource – JCA Adapter – on WebLogic Server. And they can be connected to custom Java components – in addition to their better known usage with SOA Suite and Oracle Service Bus.
I have tried to use the File Adapter in an inbound fashion to trigger a Message Driven Bean when a new file is received in a specific directory. This article describes my More >
Sharing session state between JEE web applications through WebLogic session descriptor of sharing-enabled2
Session state in Java Web application is associated with a single (user) browser session on the one hand and typically with a specific web application on the other (server side) hand. Session state is created and maintained in the context of a usually a single web application. However…
We ran into a situation where our web application was assuming gigantic proportions. To complex to quickly deploy or even easily build, compile and test. On closer inspection, it was quickly revealed that the application really consisted of a number of relatively independent modules – say one for each of the options in the main menu and one for the entry point – main menu, login, manage user preferences etc. From a functional point of view, the big web app monster was by and large a collection of almost individual web applications. Almost because a substantial number of navigations took place between pages in these modules. And some context data – including credentials – should be passed on these navigations. The application was developed with such information stored in the session scope – as all modules always have access to a (shared) session scope, it was thought.
We got to the point where for More >