In addition to the WebSocket support we've added into the next major release of WebLogic Server (version 12.1.2 with all usual caveats with respect to release timeframes, no guarantee, etc.) we've also added support for the HTML5 ServerSent-Event model through collaborating with the GlassFish team and integrating the GlassFish ServerSent-Event feature.
The HTML5 ServerSent-Event model provides a mechanism to allow
browser clients to establish a uni-directional communication path to a
server, where the server is then able to push messages to the browser at
any point in time.
A common JavaScript API (EventSource) is provided in modern
browsers that allows the client to establish connections
to the server and register callback functions to handle events as they come in over
the connection, which can then be used to make any necessary page updates.
Some good sources of information on ServerSent-Events/EventSources are:
This new feature in WebLogic Server and GlassFish provides a small Java API and a couple of annotations that
developers use to create and publish ServerSent-Event handlers, from
which applications on the server can use to send messages to connected
browser clients at any time, essentially enabling applications to push
messages to clients over standard HTTP(S).
The runtime component of the feature uses CDI to instantiate and manage the handlers and support the injection of them into other application components as well as setting up and managing the asynchronous connection for each client.
Jitu from the GlassFish team provided some information on the feature earlier in the year:
Bhakti also from the GlassFish team has a posting with an example of a SSE application that fetches data from a twitter feed and republishes to clients:
Here it is running on a development build of WebLogic Server 12.1.2.
Besides being an interesting new feature with lots of possibilities, this also serves to demonstrate how the WebLogic and GlassFish teams are cooperating and producing innovative outcomes.
The Buttso Blathers
Interrupt Driven Posting ... When I think of something to write, I'll write it.
24 September 2012
18 September 2012
WebSockets on WebLogic Server
We've been busy working on putting in support for the WebSocket Protocol into WebLogic Server with the intent to include it in the next major release (usual caveats apply with respect to dates, times, features, etc.). Running the Autobahn WS Testsuite, which seems to be the industry defacto WebSocket compatibility verifier, we are seeing reports with very high levels of compatibility.
As there's no standard WebSocket Java API at this point, we've chosen to model the API on the Grizzly WebSocket API with some minor changes where necessary. Once the results of JSR-356 (Java API for WebSocket) becomes public, we'll look to implement and support that.
In the background we have also done some integration work with the earlier WebSocket-SDK that was being used as a vehicle for WebSocket API investigations in order to try it out and look at the SPI requirements -- but we won't expose it in WLS 12.1.2 and will wait for the formal Java API for WebSocket to be finalized.
Back to WLS 12.1.2 and it's WebSocket API, as an exercise, I just ported the Apache Tomcat WebSocket demo called snake to run on WLS.
The original Tomcat demo source is here:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/snake/
Here it is running on a development build of WebLogic Server 12.1.2.
There are some differences in terms of handling of connections and the registration approach but it was a pretty straight forward exercise and took about 30 minutes. The demo didn't require too many major changes as the APIs are semantically similar in terms of accepting connections, handling messages and sending/broadcasting messages to clients. Thankfully I didn't have to do anything on the client JavaScript side ... :-)
We also have the Grizzy/GlassFish Chat demo running on WLS as well.
More info to come as we progress the documentation, etc. Should be some demos of this running at OOW this year too I'd guess.
As there's no standard WebSocket Java API at this point, we've chosen to model the API on the Grizzly WebSocket API with some minor changes where necessary. Once the results of JSR-356 (Java API for WebSocket) becomes public, we'll look to implement and support that.
In the background we have also done some integration work with the earlier WebSocket-SDK that was being used as a vehicle for WebSocket API investigations in order to try it out and look at the SPI requirements -- but we won't expose it in WLS 12.1.2 and will wait for the formal Java API for WebSocket to be finalized.
Back to WLS 12.1.2 and it's WebSocket API, as an exercise, I just ported the Apache Tomcat WebSocket demo called snake to run on WLS.
The original Tomcat demo source is here:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/snake/
Here it is running on a development build of WebLogic Server 12.1.2.
There are some differences in terms of handling of connections and the registration approach but it was a pretty straight forward exercise and took about 30 minutes. The demo didn't require too many major changes as the APIs are semantically similar in terms of accepting connections, handling messages and sending/broadcasting messages to clients. Thankfully I didn't have to do anything on the client JavaScript side ... :-)
We also have the Grizzy/GlassFish Chat demo running on WLS as well.
More info to come as we progress the documentation, etc. Should be some demos of this running at OOW this year too I'd guess.
Labels:
WebLogic Server,
WebSockets
02 July 2012
JSF Managed Beans, @PostConstruct and CDI
In a similar vein to my last post, with this blog I'd like to try and raise the visibility of another bug that is being seen in a few different places, and for which there is already a patch available for it.
The basic issue here is that when an application is using JSF Managed Beans that in turn make use of the @PostContruct lifecycle annotation to execute some post-construction tasks, if the WEB-INF/beans.xml file is included and thus enables the CDI circuitry, the @PostConstruct method on the JSF ManagedBean is no longer invoked.
The good news is that if this scenario is part of your application design, then you can pick up and apply a patch for WLS 12c that will resolve the issue.
The relevant base bug # is 13703600 and the Smart Update patch ID is UXPH.
From what I've read in the bug logs, we're also looking to include this fix in one of the patch-set-updates (PSUs) we are providing, so anyone that applies the relevant PSU should automatically get this fix.
Labels:
CDI,
jsf,
WebLogic Server
25 June 2012
Multipart File Upload with WLS 12c
Multipart File Upload with WLS 12c
Just a word for anyone out there looking to use the Servlet 3.0 file upload feature with WLS 12c.
If you use the annotation approach on the Servlet class, it works perfectly well
However if you use the web.xml file to specify or override specific values using the multipart-config settings, then we have a small issue when we parse and apply those settings to the underling configuration bean. This results in the maxFileSize value always being set to a value of 0.
Ultimately this manifests itself as a problem when uploading any file since the file size will always exceed the maximum allowed size of 0.
The good news is there's a fix already available for it -- if you run into it, look for the patch for bug#14915431 or SmartUpdate patch 8EC8.
Just a word for anyone out there looking to use the Servlet 3.0 file upload feature with WLS 12c.
If you use the annotation approach on the Servlet class, it works perfectly well
However if you use the web.xml file to specify or override specific values using the multipart-config settings, then we have a small issue when we parse and apply those settings to the underling configuration bean. This results in the maxFileSize value always being set to a value of 0.
Ultimately this manifests itself as a problem when uploading any file since the file size will always exceed the maximum allowed size of 0.
The good news is there's a fix already available for it -- if you run into it, look for the patch for bug#14915431 or SmartUpdate patch 8EC8.
Labels:
Servlet,
WebLogic Server
04 April 2012
WebLogic and EJB 3.1 @Singleton @Startup with @PostConstruct
That's quite the mouthful of annotations ..
A question was posed recently on the WLS EJB OTN forum asking about why WLS doesn't correctly support this combination of annotations, where the method with the @PostConstruct annotation was not being called as expected.
I thought I'd check it out with a simple test, which I'm sharing here.
1. Using NetBeans, I created a new "Web Application" project and assigned it to use my local WebLogic Server 12c installation.
2.Within the project, I created an EJB 3.1 Singleton using the NetBeans wizard. Not that creating EJBs in Java EE 6 requires this sort of assistance any more, having done away with most of the gunk from earlier versions of the specification. With EJB 3.1, an EJB can now be just a class with annotations and the logic. That's it. Simple.
3. On the EJB 3.1 Singleton, I then added the @Startup annotation to indicate that the bean must be instantiated when the container starts. I also added a method which I annotated with @PostContruct to indicate it should be called after the class has been instantiated via its constructor. The method prints a message to standard out when it is called.
I also added an instance variable with a default value, that is subsequently changed in the init method. Accessing this from a servlet will also show whether the init method was invoked.
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package sab.demo;
import java.util.Date;
import javax.annotation.PostConstruct;
import javax.ejb.Singleton;
import javax.ejb.LocalBean;
import javax.ejb.Startup;
/**
*
* @author sbutton
*/
@Singleton
@Startup
public class TestSingletonBean {
private String TESTVAL = "IF YOU SEE THIS @POSTCONSTRUCT HAS NOT BEEN CALLED";
@PostConstruct
void init() {
TESTVAL = "@PostConstruct method was called on " + new Date();
System.out.printf("\n\nIn init: %s\n", TESTVAL);
}
public String getTestVal() {
return TESTVAL;
}
}
5. Since this test app is making use of the new Java EE 6 ease-of-use features that support the deployment of EJBs in Web applications, I could simply deploy this web application to see if the EJB Singleton was started on deployment and whether the @PostConstruct method was called.
Looking on the console where WebLogic Server was started in NetBeans, the message from the init method is seen right after the application deployment completes.
This demonstrates that WebLogic Server is correctly handling EJB 3.1 with @Singleton, @Startup and @PostConstruct.
6. Taking it one minor step further.
To independently observe the value of TESTVAL to ensure it has been modified via the init method, in the same project (it's very handy this web and ejb cohabitation ...) I added a servlet using the @WebServlet annotation.
In the servlet, I used the @EJB annotation to obtain a reference to the @Singleton and displayed the result of calling its getTestVal method on the page.
To independently observe the value of TESTVAL to ensure it has been modified via the init method, in the same project (it's very handy this web and ejb cohabitation ...) I added a servlet using the @WebServlet annotation.
In the servlet, I used the @EJB annotation to obtain a reference to the @Singleton and displayed the result of calling its getTestVal method on the page.
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package sab.demo;
import java.io.IOException;
import java.io.PrintWriter;
import javax.ejb.EJB;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
*
* @author sbutton
*/
@WebServlet(name = "TestServlet", urlPatterns = {"/TestServlet", "/test"})
public class TestServlet extends HttpServlet {
@EJB
TestSingletonBean singleton;
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
try {
out.println("");
out.println("");
out.println("<title>Servlet TestServlet</title>");
out.println("");
out.println("");
out.println("<h1>Servlet TestServlet at " + request.getContextPath() + "</h1>");
out.printf("<p>Singleton TESTVAL: %s</p>", singleton.getTestVal());
out.println("");
out.println("");
} finally {
out.close();
}
}
}
7. Calling this from a browser shows the value of TESTVAL to be that set in the init method.
So in summary, this simple example shows WebLogic Server 12c supporting the EJB @Singleton and @Startup semantics correctly.
Labels:
ejb,
NetBeans,
singleton,
WebLogic Server
05 March 2012
WebLogic Server Singleton Services
WebLogic Server has supported the notion of a Singleton Service for a number of releases, in which WebLogic Server will maintain a single instance of a configured singleton service on one managed server within a cluster. The singleton can be migrated to another server in the cluster, either automatically if it's current hosting server becomes available, or manually at an operators request. The singleton can be optionally be configured with a preferred server to run on, as well as a set of named servers to which it can be migrated. A singleton can be deployed as a standalone service or as part of an application deployment.
The documentation for the singleton server is here:
http://docs.oracle.com/cd/E24329_01/web.1211/e24425/service_migration.htm#i1051668
With this capability, a question arises from time-to-time whether the Singleton Service feature in WebLogic Server can be used to provide a cluster wide singleton service for applications to use
The answer to this is yes, but it requires you to do a few things to expose the singleton instance to applications running in the cluster so that it can be looked up and used.
Since a singleton service is basically a POJO that implements the weblogic.cluster.singleton.SingletonService interface, which gets instantiated and managed by WebLogic Server, it doesn't have a surface area that allows it to be seen by applications running in the cluster.
To allow the singleton service to be used by applications, in addition to implementing the basic logic that is required, it also needs to perform the following tasks:
Deploying and Configuring the Singleton
To deploy the singleton in standalone mode, compile and package the classes into a JAR file and put the JAR file into the WebLogic Server classpath. Note this needs to be done on each physical machine where the managed servers in the cluster run.
You configure a singleton service instance for cluster using the WebLogic Server console.
This ultimately writes an entry in the domain's config.xml as such:
Applications wishing to use the singleton service then need to look it up from the cluster-wide JNDI tree, narrow it to singleton service type and invoke it's methods as needed.
This is obviously a fairly simple example but it should highlight the basic requirements and method to create an cluster wide singleton that can be used by applications.
The documentation for the singleton server is here:
http://docs.oracle.com/cd/E24329_01/web.1211/e24425/service_migration.htm#i1051668
With this capability, a question arises from time-to-time whether the Singleton Service feature in WebLogic Server can be used to provide a cluster wide singleton service for applications to use
The answer to this is yes, but it requires you to do a few things to expose the singleton instance to applications running in the cluster so that it can be looked up and used.
Since a singleton service is basically a POJO that implements the weblogic.cluster.singleton.SingletonService interface, which gets instantiated and managed by WebLogic Server, it doesn't have a surface area that allows it to be seen by applications running in the cluster.
To allow the singleton service to be used by applications, in addition to implementing the basic logic that is required, it also needs to perform the following tasks:
- Provide an RMI Remote interface that the singleton service additionally implements, which then allows it to be accessed and invoked from any server in the cluster
- When the singleton service is activated, it binds itself into the cluster-wide JNDI tree
- When the singleton service is deactivated, unbinds itself from the cluster-wide JNDI tree
package sab.demo.wlssingletoninstance;
import java.rmi.Remote;
import java.rmi.RemoteException;
/**
*
* @author sbutton
*/
public interface DemoSingleton extends Remote {
public final String JNDI_NAME="DemoSingleton";
public String singletonLocation();
public String getWebLogicServerName();
public String getHostName();
public int increment();
public int value();
}
DemoSingletonImplpackage sab.demo.wlssingletoninstance;
import java.net.InetAddress;
import java.net.UnknownHostException;
import java.rmi.RemoteException;
import java.util.logging.Logger;
import javax.naming.Context;
import javax.naming.NamingException;
import javax.rmi.PortableRemoteObject;
import weblogic.cluster.singleton.SingletonService;
import weblogic.jndi.Environment;
/**
* Example of a WebLogic Server Singleton Service that can be accessed from
* other deployed components.
*
* @author sbutton
*/
public class DemoSingletonImpl implements DemoSingleton, SingletonService {
private Integer counter = 0;
final private Logger logger = new Logger().getLogger("DemoSingletonImpl");
public DemoSingletonImpl() {
super();
logger.info("Constructor");
}
// ================================================================ //
// ===================== Singleton Service Methods ================ //
// ================================================================ //
@Override
public void activate() {
logger.info("Activate on " + singletonLocation());
counter = 0;
try {
Environment env = new Environment();
Context ctx = env.getInitialContext();
ctx.rebind(JNDI_NAME, this);
logger.info("Executed bind for: " + JNDI_NAME);
logger.info(String.format("Looking up JNDI_NAME returns: %s", ctx.lookup(JNDI_NAME).getClass().getName()));
//quickTest();
} catch (NamingException e) {
logger.warning("Unable to bind: " + this.getClass().getName() + " into JNDI as:" + this.getClass().getName() + ", Error: " + e.getMessage());
}
}
@Override
public void deactivate() {
logger.info("Deactivate on " + singletonLocation());
try {
Environment env = new Environment();
Context ctx = env.getInitialContext();
ctx.unbind(JNDI_NAME);
logger.info("Executed unbind for: " + JNDI_NAME);
} catch (NamingException e) {
System.out.println("\tUnable to unbind from JNDI as: " + JNDI_NAME + ", Error: " + e.getMessage());
}
}
// ================================================================ //
// ========================= Remotable Methods ==================== //
// ================================================================ //
@Override
public String singletonLocation() {
return String.format("%s %s",
getHostName(),
getWebLogicServerName());
}
@Override
public String getWebLogicServerName() {
return Utilities.getWebLogicServerName();
}
@Override
public String getHostName() {
return Utilities.getHostName();
}
@Override
public synchronized int increment() {
counter++;
return counter.intValue();
}
@Override
public int value() {
return counter.intValue();
}
// ================================================================ //
// ========================== Private Methods ===================== //
// ================================================================ //
/**
* Called on activate to verify binding is available
*/
private void quickTest() {
try {
Environment env = new Environment();
Context ctx = env.getContext();
DemoSingleton singleton =
(DemoSingleton) PortableRemoteObject.narrow(ctx.lookup(DemoSingleton.JNDI_NAME), DemoSingleton.class);
logger.info("quickTest: " + singleton.singletonLocation());
} catch (Exception ne) {
logger.log(Logger.SEVERE, ne);
logger.severe("Error: %s" + ne.getMessage());
}
}
}
Deploying and Configuring the Singleton
To deploy the singleton in standalone mode, compile and package the classes into a JAR file and put the JAR file into the WebLogic Server classpath. Note this needs to be done on each physical machine where the managed servers in the cluster run.
You configure a singleton service instance for cluster using the WebLogic Server console.
This ultimately writes an entry in the domain's config.xml as such:
<singleton-service> <name>DemoSingleton</name> <user-preferred-server>Mike</user-preferred-server> <class-name>sab.demo.wlssingletoninstance.DemoSingletonImpl</class-name> <cluster>Tingles</cluster> </singleton-service>When the preferred managed server starts, the singleton service will be instantiated.
<Mar 2, 2012 3:25:32 PM CST> <Notice> <Cluster> <BEA-000102> <Joining cluster Tingles on 239.192.0.0:7001> <Mar 2, 2012 3:25:33 PM CST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to RUNNING.> <Mar 2, 2012 3:25:33 PM CST> <Notice> <WebLogicServer> <BEA-000360> <The server started in RUNNING mode.> [] INFO Activate on Steve-Button-MacBook-Pro.local Mike [] INFO Executed bind for: DemoSingleton [] INFO Looking up JNDI_NAME returns: sab.demo.wlssingletoninstance.DemoSingletonImpl [] INFO quickTest: Steve-Button-MacBook-Pro.local MikePerforming a manual migration using the console, the singleton gets deactivated on the current server and activated on another.
[] INFO Deactivate on Steve-Button-MacBook-Pro.local Mike [] INFO Executed unbind for: DemoSingleton <Mar 2, 2012 3:25:34 PM CST> <Notice> <WebLogicServer> <BEA-000360> <The server started in RUNNING mode.> [] INFO Activate on Steve-Button-MacBook-Pro.local James [] INFO Executed bind for: DemoSingleton [] INFO Looking up JNDI_NAME returns: sab.demo.wlssingletoninstance.DemoSingletonImpl [] INFO quickTest: Steve-Button-MacBook-Pro.local JamesUsing the Singleton
Applications wishing to use the singleton service then need to look it up from the cluster-wide JNDI tree, narrow it to singleton service type and invoke it's methods as needed.
private DemoSingleton getSingleton() throws ClassCastException, NamingException {
Context ctx = getInitialContext()
DemoSingleton singleton = (DemoSingleton) PortableRemoteObject.narrow(ctx.lookup(DemoSingleton.JNDI_NAME), DemoSingleton.class);
return singleton;
}
Using this in a servlet for example, you can see how the servlet running on the managed server Mike is able to access the singleton service running on managed server James.
When the singleton service is migrated, the servlet then seamlessly accesses it on the other managed server, where it is now co-located in this specific example below.
Summary
This is obviously a fairly simple example but it should highlight the basic requirements and method to create an cluster wide singleton that can be used by applications.
Labels:
cluster,
singleton,
WebLogic Server
01 March 2012
WebLogic Server 11g (10.3.6) Documentation
The OTN documentation pages don't appear yet to have a link to the WLS 10.3.6 documentation set.
If you are looking for it in the interim you can find it here:
http://docs.oracle.com/cd/E23943_01/wls.htm
While this is predominantly a patchset, there are a number of new features listed in the What's New in WebLogic Server document.
Some worthy examples are:
If you are looking for it in the interim you can find it here:
http://docs.oracle.com/cd/E23943_01/wls.htm
While this is predominantly a patchset, there are a number of new features listed in the What's New in WebLogic Server document.
Some worthy examples are:
- Java SE 7 support
- Storing transaction logs (TLOG) in a database
- GlassFish web deployment descriptor support
- Enable RESTful Web Services with JAX-RS and Jersey 1.9
- DataSource changes to support setting credentials on a connection and using proxy connections
- Application scoped JDBC drivers, where a JDBC driver can be deployed within an EAR file
Labels:
glassfish,
java 7,
jax-rs,
WebLogic Server
Web application filtering classloader documentation update
Following a posting on here last year that described using the filtering classloader within a web application, several folks commented that it wasn't described in the documentation.
The WebLogic Server 12c (12.1.1.0) documentation shows the prefer-application-packages and prefer-application-resources elements as being available in the weblogic.xml file.
http://docs.oracle.com/cd/E24329_01/web.1211/e21049/weblogic_xml.htm#autoId24
The WebLogic Server 11g (10.3.6.0) documentation should also include this when it gets pushed out to OTN.
The WebLogic Server 12c (12.1.1.0) documentation shows the prefer-application-packages and prefer-application-resources elements as being available in the weblogic.xml file.
http://docs.oracle.com/cd/E24329_01/web.1211/e21049/weblogic_xml.htm#autoId24
The WebLogic Server 11g (10.3.6.0) documentation should also include this when it gets pushed out to OTN.
<wls:weblogic-web-app>
<wls:weblogic-version>12.1.1</wls:weblogic-version>
<wls:context-root>FilterWeb</wls:context-root>
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>com.oracle.foo</wls:package-name>
</wls:prefer-application-packages>
</wls:container-descriptor>
</wls:weblogic-web-app>
Labels:
classloading,
WebLogic Server
12 December 2011
WebLogic Server 12c - Identifying versions of modules, libraries, frameworks
Now that WebLogic Server 12c has been released, it's interesting to look at the various libraries, modules and open-source frameworks it uses.
One approach to doing this is to use the wls-cat utility to search for a known class from the framework, module or open-source framework you are interested in looking at, and observing where the class is loaded from and the corresponding library version.
JavaServer Faces
One important item to note here is that as of the WebLogic Server 12c release, the JSF implementation has been added directly to the WebLogic Server classpath. This is a change from the WebLogic Server 11g release where the JSF implementation was provided as an optional shared-library, which needed to be deployed in order for applications to use JSF. With WebLogic Server 12c, JSF is now an integral part of the server and can be used without the necessity of deploying and referencing the shared-library.
javax.faces.webapp.FacesServlet:
![]() |
com.sun.faces.facelets.Facelet:
Using:
- JSF 2.1
- Mojarra 2.1.5
Java Persistence API / EclipseLink
javax.persistence.Entity:

org.eclipse.persistence.jpa.JpaEntityManager:
Using:
- JPA 2.0
- EclipseLink 2.3
Context and Dependency Injection/Weld
javax.enterprise.inject.Model:

org.jboss.weld.Container:
Using:
- CDI 1.0
- Weld 1.1.3-SP1
SLF4J
org.slf4j.Logger:
Using:
- SLF4J 1.6.1
WebLogic Server 12c - Maven Usage Notes
Note: apologies for the formatting, this posting was a cut and paste from a .docx document and thus has all the styles inlined. In the interests of time, I thought it was better to just post it as-is and make it available, rather than try and reformat it. Which I know I'd keep pushing off until eternity.
This document provides a short overview of installing, configuring and using the new wls-maven-plugin provided in WebLogic Server 12c.
Convention Over Configuration
With the wls-maven-plugin:12.1.1.0 we have followed the theme of Maven and used a convention-over-configuration approach. This means that for a set of the commonly used configuration elements, we have adopted a sensible, consistent set of default values that can be used across all of the goals. This reduces the amount of configuration necessary to use the plugin and helps achieve uniform goal executions, even in different environments.
The common configuration elements are:
middlewareHome: ${project.basedir}/Oracle/Software
weblogicHome: “wlserver” or “wlserver_12.1”, depending on the install type
domainHome: ${project.basedir}/Oracle/Domains
source: ${project.build.directory}/${project.build.finalName}.${project.packaging}
adminurl: t3://localhost:7001
While these configuration parameters have default values, they can all be overridden in a pom.xml file or on the command line as need be.
However by having them be sensible defaults, they can be left out of a configuration section and used consistently across all of the goals.
As an example, it’s possible to issue the following commands that all use the same WLS installation and domain without specifying any repetitive values:
$ wls:install -
DartifactLocation=/Users/sbutton/Downloads/wls/wls_1211/wls1211_dev.zip
DartifactLocation=/Users/sbutton/Downloads/wls/wls_1211/wls1211_dev.zip
$ wls:create-domain –Duser=weblogic –Dpassword=welcome1
$ wls:start-server
Installing the Plugin
For WLS 12c, the wls-maven-plugin is provided as a pre-built jar file and the
accompanying pom.xml file is also provided as an easily accessible file in the same directory.
$MW_HOME/wlserver/server/lib/wls-maven-plugin.jar
$MW_HOME/wlserver/server/lib/pom.xml
The wls-maven-plugin is installed using the following commands:
$ cd $MW_HOME/wlserver/server/lib
$ mvn install
$ mvn install:install-file –Dfile=wls-maven-plugin.jar –DpomFile=pom.xml
The default pom.xml file now has the required setting to enable the use of the “wls” goal prefix enabled by default.
To use the “wls” goalPrefix, you will need to edit the Maven settings.xml file and add the following entry:
<pluginGroups>
<pluginGroup>com.oracle.weblogic</pluginGroup>
</pluginGroups>
Once you have installed the plugin, you can very simply validate it using the wls:help goal.
$ mvn wls:help
This goal does not require a project or pom.xml and will display the list of goals available in the wls-maven-plugin if the plugin has been successfully installed.
Basic Configuration of Plugin
Below is an example of a basic Java EE 6 Web Application pom.xml file that enables the use of the wls-maven-plugin.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>demo.sab</groupId>
<artifactId>maven-demo</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<name>maven-demo</name>
<properties>
<endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<plugins>
...
...
<!-- WebLogic Server 12c Maven Plugin -->
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>wls-maven-plugin</artifactId>
<version>12.1.1.0</version>
</plugin>
</plugins>
</build>
</project>
Install
This goal installs WLS into a local directory to enable it to be used execute the other goals, as well as a installation to create a WLS domain that can be used to deploy and test the application represented as the Maven project.
To install, you need a distribution to install. This is specified using the <artifactLocation> configuration element in the wls-maven-plugin section of the pom.xml, or specify it using the –DartifactLocation property when Maven is invoked.
The target directory for the installation is specified using the optional weblogicHome configuration element. This is set to ${basedir}/Oracle/Software by default. Specifying a <middlewareHome> value will direct the install to be performed in the specified location.
I will focus on the zip distribution since it reflects a development usage model.
The location of the zip distribution can be specified as one of the following:
a) local file reference
For a local file reference, you specify the path on the local file system
<!-- WebLogic Server 12c Maven Plugin -->
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>wls-maven-plugin</artifactId>
<version>12.1.1.0</version>
<configuration>
<artifactLocation>
/Users/sbutton/Downloads/wls/wls_1211/wls1211_dev.zip
</artifactLocation>
</configuration>
</plugin>
The execution of the wls:install goal is shown below.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- wls-maven-plugin:12.1.1.0:install (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++ wls-maven-plugin: install ++
[INFO] ++====================================================================++
[INFO] Installing /Users/sbutton/Downloads/wls/wls_1211/wls1211_dev.zip into /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software
[INFO] Installing the product, this may take some time.
[INFO] Executing: [cmd:[/bin/bash, -c, chmod +x ./configure.sh; ./configure.sh]]
[INFO] Process being executed, waiting for completion.
[INFO] [exec] **************************************************
[INFO] [exec] WebLogic Server 12c (12.1.1.0) Zip Configuration
[INFO] [exec]
[INFO] [exec] MW_HOME: /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software
[INFO] [exec] JAVA_HOME: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
[INFO] [exec] **************************************************
...
...
...
[INFO] [exec] BUILD SUCCESSFUL
[INFO] [exec] Total time: 0 seconds
[INFO] [configure script] exit code: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:53.210s
[INFO] Finished at: Wed Nov 23 15:46:53 CST 2011
[INFO] Final Memory: 3M/81M
[INFO] ------------------------------------------------------------------------
b) URL reference
<!-- WebLogic Server 12c Maven Plugin -->
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>wls-maven-plugin</artifactId>
<version>12.1.1.0</version>
<configuration>
<artifactLocation>
http://test.us.oracle.com:7001/downloads/wls1211_dev.zip
</artifactLocation>
</configuration>
</plugin>
The execution of the wls:install goal is shown below.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- wls-maven-plugin:12.1.1.0:install (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++ wls-maven-plugin: install ++
[INFO] ++====================================================================++
[INFO] Installing http://test.us.oracle.com:7001/downloads/wls1211_dev.zip into /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software
[INFO] Attempt to download artifact from maven repo failed - Artifact not found
[INFO] Attempt to download the weblogic server instance directly from url.
[INFO] Downloading the file ...
...
...
...
[INFO] [exec] BUILD SUCCESSFUL
[INFO] [exec] Total time: 0 seconds
[INFO] [configure script] exit code: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4:23.710s
[INFO] Finished at: Wed Nov 23 15:53:21 CST 2011
[INFO] Final Memory: 3M/81M
[INFO] ------------------------------------------------------------------------
c) Maven Artifact
Here the distribution is retrieved from the local Maven repository itself. This means it needs to have been installed into the repository or pulled over from a remote repository at some point.
To install wls1211-dev.zip into Maven repository the following type of command can be used:
sbutton:~ $ mvn install:install-file -Dfile=wls1211_dev.zip
-DgroupId=com.oracle.weblogic -DartifactId=wls-dev
-Dpackaging=zip -Dversion=12.1.1.0
-DgroupId=com.oracle.weblogic -DartifactId=wls-dev
-Dpackaging=zip -Dversion=12.1.1.0
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-pom ---
[INFO] Installing /Users/sbutton/Downloads/wls/wls_1211/wls1211_dev.zip to /Users/sbutton/.m2/repository/com/oracle/weblogic/wls-dev/12.1.1.0/wls-dev-12.1.1.0.zip
[INFO] Installing /var/folders/cL/cLTyZKXjGgmQhEpoV+U-DE+++TI/-Tmp-/mvninstall7575420374983698784.pom to /Users/sbutton/.m2/repository/com/oracle/weblogic/wls-dev/12.1.1.0/wls-dev-12.1.1.0.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 11.089s
[INFO] Finished at: Wed Nov 23 15:30:17 CST 2011
[INFO] Final Memory: 3M/81M
[INFO] ------------------------------------------------------------------------
This installs wls1211-dev.zip as a Maven artifact with the following coordinate:
com.oracle.weblogic:wls-dev:zip:12.1.1.0
To use this Maven artifact as the distribution to install, the plugin looks like the below.
<!-- WebLogic Server 12c Maven Plugin -->
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>wls-maven-plugin</artifactId>
<version>12.1.1.0</version>
<configuration>
<artifactLocation>
com.oracle.weblogic:wls-dev:zip:12.1.1.0
</artifactLocation>
</configuration>
</plugin>
The execution of the wls:install goal is shown below.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- wls-maven-plugin:12.1.1.0:install (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++ wls-maven-plugin: install ++
[INFO] ++====================================================================++
[INFO] Installing com.oracle.weblogic:wls-dev:zip:12.1.1.0 into /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software
[INFO] Installing the product, this may take some time.
[INFO] Executing: [cmd:[/bin/bash, -c, chmod +x ./configure.sh; ./configure.sh]]
[INFO] Process being executed, waiting for completion.
[INFO] [exec] **************************************************
[INFO] [exec] WebLogic Server 12c (12.1.1.0) Zip Configuration
[INFO] [exec]
[INFO] [exec] MW_HOME: /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software
[INFO] [exec] JAVA_HOME: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
[INFO] [exec] **************************************************
[INFO] [exec]
...
...
...
[INFO] [exec]
[INFO] [exec] Your environment has been set.
[INFO] [exec]
[INFO] [exec] BUILD SUCCESSFUL
[INFO] [exec] Total time: 0 seconds
[INFO] [configure script] exit code: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:57.549s
[INFO] Finished at: Wed Nov 23 15:35:32 CST 2011
[INFO] Final Memory: 4M/81M
[INFO] ------------------------------------------------------------------------
Unless the <middlewareHome> configuration paramter is specified, the installation is performed in the ${basedir}/Oracle/Software directory.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ ls -l
total 8
drwxr-xr-x 3 sbutton staff 102 23 Nov 15:44 Oracle
-rw-r--r-- 1 sbutton staff 3597 23 Nov 15:43 pom.xml
drwxr-xr-x 3 sbutton staff 102 23 Nov 15:03 src
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ ls -l Oracle/Software/
total 64
-rw-r--r-- 1 sbutton staff 5808 23 Nov 15:45 README.txt
-rw-r--r-- 1 sbutton staff 3064 23 Nov 15:45 configure.cmd
-rwxr-xr-x 1 sbutton staff 2857 23 Nov 15:45 configure.sh
-rw-r--r-- 1 sbutton staff 3189 23 Nov 15:45 configure.xml
-rw-r--r-- 1 sbutton staff 133 23 Nov 15:45 domain-registry.xml
drwxr-xr-x 508 sbutton staff 17272 23 Nov 15:46 modules
-rw-r--r-- 1 sbutton staff 1138 23 Nov 15:45 registry.template
-rw-r--r-- 1 sbutton staff 1320 23 Nov 15:46 registry.xml
drwxr-xr-x 3 sbutton staff 102 23 Nov 15:45 utils
drwxr-xr-x 7 sbutton staff 238 23 Nov 15:46 wlserver
Create-Domain
This goal creates a standard WLS domain from the specific WLS installation.
The location of the domain is specified using the optional <domainHome> configuration element. By default <domainHome> is set to ${basedir}/Oracle/Domains so it will be created in an Oracle/Domains subdirectory of the root directory of the Maven project.
The WLS installation to be used is specified using the optional <middlewareHome> configuration element. This is set to ${basedir}/Oracle/Software by default, so if the default location has been used to execute the install goal, it can be left out of this goal.
To create a domain, a user and password are required. These can be specified as configuration parameters using the <user> and <password> properties or they can be specified on the command line.
<!-- WebLogic Server 12c Maven Plugin -->
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>wls-maven-plugin</artifactId>
<version>12.1.1.0</version>
<configuration>
<artifactLocation>
com.oracle.weblogic:wls-dev:zip:12.1.1.0
</artifactLocation>
<user>weblogic</user>
<password>welcome1</user>
</configuration>
</plugin>
The execution of the wls:install goal is shown below.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:create-domain
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- wls-maven-plugin:12.1.1.0:create-domain (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++ wls-maven-plugin: create-domain ++
[INFO] ++====================================================================++
[INFO] Domain creation script:
readTemplate('/Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software/wlserver/common/templates/domains/wls.jar')
cd('/Security/base_domain/User/weblogic')
set('Name', 'weblogic')
set('Password', '***')
writeDomain('/Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Domains/mydomain')
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 39.345s
[INFO] Finished at: Wed Nov 23 16:01:13 CST 2011
[INFO] Final Memory: 24M/81M
[INFO] ------------------------------------------------------------------------
Unless the <domainHome> configuration property is specified, the domain will be created in the ${basedir}/Oracle/Domains directory of the project.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ ls -l Oracle/Domains/mydomain
total 16
drwxr-xr-x 3 sbutton staff 102 23 Nov 16:01 autodeploy
drwxr-xr-x 10 sbutton staff 340 23 Nov 16:01 bin
drwxr-xr-x 10 sbutton staff 340 23 Nov 16:01 config
drwxr-xr-x 3 sbutton staff 102 23 Nov 16:01 console-ext
-rw-r--r-- 1 sbutton staff 462 23 Nov 16:01 fileRealm.properties
drwxr-xr-x 7 sbutton staff 238 23 Nov 16:01 init-info
drwxr-xr-x 3 sbutton staff 102 23 Nov 16:01 lib
drwxr-xr-x 6 sbutton staff 204 23 Nov 16:01 security
drwxr-xr-x 3 sbutton staff 102 23 Nov 16:01 servers
-rwxr-x--- 1 sbutton staff 293 23 Nov 16:01 startWebLogic.sh
Start-Server
This goal executes a startWebLogic command on a given domain, starting the WebLogic Server instance for use.
This goal also uses the <middlewareHome> and <domainHome> configuration elements to specify the location of the WLS installation and domain to use.
If you have followed the convention-over-configuration approach and adopted the default values, these configuration elements do not need to be specified.
If you have installed WLS or created a domain in a different location, you must specify the location using the <middlewareHome> and <domainHome> configuration elements in the pom.xml or specify them as parameters on the command line.
Using the convention-over-configuration approach, the default domain ${basedir}/Oracle/Domains/mydomain using the WLS installation in ${basedir}/Oracle/Software can be started as shown below.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:start-server
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- wls-maven-plugin:12.1.1.0:start-server (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++ wls-maven-plugin: start-server ++
[INFO] ++====================================================================++
.[INFO] Starting server in domain /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Domains/mydomain
[INFO] Check stdout file for details: /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Domains/mydomain/server-2388282492279558044.out
[INFO] Process being executed, waiting for completion.
.........
[INFO] Server started successful
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9.137s
[INFO] Finished at: Wed Nov 23 16:23:07 CST 2011
[INFO] Final Memory: 4M/81M
[INFO] ------------------------------------------------------------------------
Deploy
The deploy goal deploys an application.
The convention-over-configuration approach uses the defaults available for middlewareHome, adminurl, and the source file to deploy allowing the goal to be executed without any additional configuration.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:deploy
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- wls-maven-plugin:12.1.1.0:deploy (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++ wls-maven-plugin: deploy ++
[INFO] ++====================================================================++
weblogic.Deployer invoked with options: -noexit -user weblogic -deploy -source /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/target/maven-demo.war
<Nov 23, 2011 4:36:51 PM CST> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, maven-demo [archive: /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/target/maven-demo.war], to configured targets.>
Task 0 initiated: [Deployer:149026]deploy application maven-demo on AdminServer.
Task 0 completed: [Deployer:149026]deploy application maven-demo on AdminServer.
Target state: deploy completed on Server AdminServer
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.803s
[INFO] Finished at: Wed Nov 23 16:36:52 CST 2011
[INFO] Final Memory: 6M/81M
[INFO] ------------------------------------------------------------------------
Stop-Server
The stop-server goal stops an executing server using the stopWebLogic script on the specified domain.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:stop-server
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- wls-maven-plugin:12.1.1.0:stop-server (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++ wls-maven-plugin: stop-server ++
[INFO] ++====================================================================++
[INFO] Stop server in domain: /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Domains/mydomain
[INFO] Process being executed, waiting for completion.
[INFO] [exec] Stopping Weblogic Server...
[INFO] [exec]
[INFO] [exec] Initializing WebLogic Scripting Tool (WLST) ...
[INFO] [exec]
[INFO] [exec] Welcome to WebLogic Server Administration Scripting Shell
[INFO] [exec]
[INFO] [exec] Type help() for help on available commands
[INFO] [exec]
[INFO] [exec] Connecting to t3://localhost:7001 with userid weblogic ...
[INFO] [exec] Successfully connected to Admin Server 'AdminServer' that belongs to domain 'mydomain'.
[INFO] [exec]
[INFO] [exec] Warning: An insecure protocol was used to connect to the
[INFO] [exec] server. To ensure on-the-wire security, the SSL port or
[INFO] [exec] Admin port should be used instead.
[INFO] [exec]
[INFO] [exec] Shutting down the server AdminServer with force=false while connected to AdminServer ...
[INFO] [exec] WLST lost connection to the WebLogic Server that you were
[INFO] [exec] connected to, this may happen if the server was shutdown or
[INFO] [exec] partitioned. You will have to re-connect to the server once the
[INFO] [exec] server is available.
[INFO] [exec] Disconnected from weblogic server: AdminServer
[INFO] [exec] Disconnected from weblogic server:
[INFO] [exec]
[INFO] [exec]
[INFO] [exec] Exiting WebLogic Scripting Tool.
[INFO] [exec]
[INFO] [exec] Done
[INFO] [exec] Stopping Derby Server...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.921s
[INFO] Finished at: Wed Nov 23 16:41:14 CST 2011
[INFO] Final Memory: 4M/81M
[INFO] ------------------------------------------------------------------------
APPC
The appc goal executes the WebLogic Server application compiler tool to prepare the application for deployment.
This benefits from the convention-over-configuration model, allowing it to be executed using the defaults of the project.
An example of the goal being executed is shown below. Note this example uses the –verbose flag to highlight the activities the appc utility is performing. This is not normally necessary.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:appc -Dverbose
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- wls-maven-plugin:12.1.1.0:appc (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++ wls-maven-plugin: appc ++
[INFO] ++====================================================================++
<Nov 23, 2011 4:43:08 PM CST> <Info> <J2EE> <BEA-160230> <Created working directory: /var/folders/cL/cLTyZKXjGgmQhEpoV+U-DE+++TI/-Tmp-/appcgen_1322028788639_maven-demo.war>
[JspcInvoker]Checking web app for compliance.
[jspc] -webapp specified, searching . for JSPs
[jspc] Compiling /index.jsp
<Nov 23, 2011 4:43:12 PM CST> <Info> <J2EE> <BEA-160220> <Compilation completed successfully.>
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.281s
[INFO] Finished at: Wed Nov 23 16:43:12 CST 2011
[INFO] Final Memory: 16M/81M
[INFO] ------------------------------------------------------------------------
WLST
The WLST goal enables the WebLogic Scripting Tool (WLST) to be used to execute scripts that configure resources or perform other operational actions on a WebLogic Server domain. The WLST used by the wlst Maven goal is the standard environment WebLogic Server WLST environment so all existing scripts should be able to be used.
Benefitting again from the convention-over-configuration, the middlewareHome and domainHome locations do not need to be specified if the defaults are used.
The WLST goal can execute an external script specified using the <fileName> configuration element or a sequence of WLST calls can be specified within the pom.xml using the <script> configuration element.
<!-- WebLogic Server 12c Maven Plugin -->
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>wls-maven-plugin</artifactId>
<version>12.1.1.0</version>
<configuration>
<artifactLocation>
com.oracle.weblogic:wls-dev:zip:12.1.1.0
</artifactLocation>
<user>weblogic</user>
<password>welcome1</user>
<filename>create-datasource.py</fileName>
</configuration>
</plugin>
An execution of the wlst goal is shown below.
sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:wlst -DfileName=create-datasource.py
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- wls-maven-plugin:12.1.1.0:wlst (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++ wls-maven-plugin: wlst ++
[INFO] ++====================================================================++
*** Creating DataSource ***
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'mydomain'.
Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.
Location changed to edit tree. This is a writable tree with
DomainMBean as the root. To make changes you will need to start
an edit session via startEdit().
For more help, use help(edit)
Starting an edit session ...
Started edit session, please be sure to save and activate your
changes once you are done.
Activating all your changes, this may take a while ...
The edit lock associated with this edit session is released
once the activation is completed.
Activation completed
Location changed to serverRuntime tree. This is a read-only tree with ServerRuntimeMBean as the root.
For more help, use help(serverRuntime)
**** DataSource Details ****
Name: cp
Driver Name: Oracle JDBC driver
DataSource: oracle.jdbc.xa.client.OracleXADataSource
Properties: {user=demo}
State: Running
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10.686s
[INFO] Finished at: Wed Nov 23 16:55:25 CST 2011
[INFO] Final Memory: 13M/81M
[INFO] ------------------------------------------------------------------------
Labels:
12c,
Maven,
WebLogic Server
Subscribe to:
Posts (Atom)















