Steve Button
Buttsohttp://www.blogger.com/profile/03968454565733104381noreply@blogger.comBlogger211125
Updated: 11 hours 59 min ago
Solaris VM Templates for WebLogic Server 12.1.3
A new set of VM Templates for Solaris have been made available on OTN.
These templates provide a quick and easy way to spin up pre-built WebLogic Server 12.1.3 instances using either Solaris Zones or Oracle VM Server for Sparc.
http://www.oracle.com/technetwork/server-storage/solaris11/downloads/solaris-vm-2621499.html
These templates provide a quick and easy way to spin up pre-built WebLogic Server 12.1.3 instances using either Solaris Zones or Oracle VM Server for Sparc.
http://www.oracle.com/technetwork/server-storage/solaris11/downloads/solaris-vm-2621499.html
WebLogic Server 12.1.3 Developer Zip - Update 3 Posted
An update has just been posted on OTN for the WebLogic Server 12.1.3 Developer Zip distribution.
WebLogic Server 12.1.3 Developer Zip Update 3 is built with the fixes from the WebLogic Server 12.1.3.0.4 Patch Set Update, providing developers with access to the latest set of fixes available in the corresponding production release.
See the download page for access to the update:
http://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-for-dev-1703574.html
http://download.oracle.com/otn/nt/middleware/12c/wls/1213/wls1213_dev_update3.zip
The Update 3 README provides details of what has been included:
http://download.oracle.com/otn/nt/middleware/12c/wls/1213/README_WIN_UP3.txt
WebLogic Server 12.1.3 Developer Zip Update 3 is built with the fixes from the WebLogic Server 12.1.3.0.4 Patch Set Update, providing developers with access to the latest set of fixes available in the corresponding production release.
See the download page for access to the update:
http://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-for-dev-1703574.html
http://download.oracle.com/otn/nt/middleware/12c/wls/1213/wls1213_dev_update3.zip
The Update 3 README provides details of what has been included:
http://download.oracle.com/otn/nt/middleware/12c/wls/1213/README_WIN_UP3.txt
NetBeans 8.1 Remote Debugging with WebLogic
Need to debug your application? With NetBeans 8.1 (dev) and WebLogic it's very easy to do.
First start your WebLogic server in debug mode. The startup scripts generated for a domain provide an option to start the server in debug mode.
To run in debug mode, set the environment variable "debugFlag" to a value of "true" and start the server.
This launches the server with a command line such as that shown below, which sets the standard Java debug properties:
Now on the NetBeans side, create a new Server entry for your WebLogic instance using the new Remote Domain option:
Check the Server debug mode enabled option and specify the port (8453 by default):
First start your WebLogic server in debug mode. The startup scripts generated for a domain provide an option to start the server in debug mode.
To run in debug mode, set the environment variable "debugFlag" to a value of "true" and start the server.
$ export debugFlag="true"
$ ./startWebLogic.sh
This launches the server with a command line such as that shown below, which sets the standard Java debug properties:
Starting WLS with line:The console will display a message confirming the debug Java VM is using:
/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java -server -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n -Djava.compiler=NONE -Xmx512m -Dweblogic.Name=myserver -Djava.security.policy=/tmp/dev_update2/wls12130/wlserver/server/lib/weblogic.policy -Xverify:none -Djava.endorsed.dirs=/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/endorsed:/tmp/dev_update2/wls12130/wlserver/../oracle_common/modules/endorsed -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbconsole... -Dwls.home=/tmp/dev_update2/wls12130/wlserver/server -Dweblogic.home=/tmp/dev_update2/wls12130/wlserver/server -Dweblogic.utils.cmm.lowertier.ServiceDisabled=true weblogic.Server
Listening for transport dt_socket at address: 8453
Now on the NetBeans side, create a new Server entry for your WebLogic instance using the new Remote Domain option:
Check the Server debug mode enabled option and specify the port (8453 by default):
Now to debug your application, simply set a break point in your code and select the Debug option for the project:
This will build and deploy the application to the WebLogic remotely then open the Debugger in the IDE and connect it automatically to the WebLogic debug port.
From here you can use all the standard debug facilities to step through your code, view stacks, instance data and so forth.
Debug away!
This will build and deploy the application to the WebLogic remotely then open the Debugger in the IDE and connect it automatically to the WebLogic debug port.
From here you can use all the standard debug facilities to step through your code, view stacks, instance data and so forth.
Debug away!
Deploying applications remotely with WebLogic REST Management Interface
WebLogic 12.1.3 provides a fully documented REST Management Interface that enables deployment and management operations to be performed using REST calls.
The table of contents from the documentation lists the set of operations available:
To use the REST Management Interface, it first must be enabled for a domain. This can be done from the WebLogic Console.
Domain > Configuration > General [Advanced] > Enable RESTful Management Services
To deploy an application to a remote server, the REST Management Interface provides the ability to upload an application archive and execute the deployment operation:
To perform this type of deployment operation a HTTP POST on the deployment URL is invoked specifying:
When this REST call is made with curl, the application archive specified as @/tmp/basicwebapp.war is uploaded as a binary file using the form field deployment and the configuration information supplied in the model form parameter used to define and perform the deployment.
The response returned from the REST call contains a payload with the result of the operation that was performed.
Further information about the deployment resource can be obtained using a further REST call, which provides links to operations that can be performed on the application, URLs to access the application, context-paths for registered servlets, runtime data and other useful information.
Which returns a response containing a payload with details of the deployment:
The documentation provides extensive coverage of the many resources and entity types that can be reached via the REST Management Interface.
The table of contents from the documentation lists the set of operations available:
To use the REST Management Interface, it first must be enabled for a domain. This can be done from the WebLogic Console.
Domain > Configuration > General [Advanced] > Enable RESTful Management Services
To deploy an application to a remote server, the REST Management Interface provides the ability to upload an application archive and execute the deployment operation:
To perform this type of deployment operation a HTTP POST on the deployment URL is invoked specifying:
- The HTTP Header of multipart/form-data;
- The application archive is supplied as form field deployment;
- The deployment information specified using the form field model in which the application name, targets and other attributes are supplied;
$ curl \
--user weblogic:welcome1 \
-H X-Requested-By:TestForRest \
-H Accept:application/json \
-H Content-Type:multipart/form-data \
-F "model={
name: 'basicwebapp',
targets: [ 'AdminServer' ]
}" \
-F "deployment=@/tmp/basicwebapp.war" \
-X POST http://adc2101001.us.oracle.com:7001/management/wls/latest/deployments/application
When this REST call is made with curl, the application archive specified as @/tmp/basicwebapp.war is uploaded as a binary file using the form field deployment and the configuration information supplied in the model form parameter used to define and perform the deployment.
The response returned from the REST call contains a payload with the result of the operation that was performed.
{
"messages": [{
"message": "Deployed the application 'basicwebapp'.",
"severity": "SUCCESS"
}],
"links": [{
"rel": "job",
"uri": "http://adc2101001:7001/management/wls/latest/jobs/deployment/id/3"
}],
"item": {
"name": "ADTR-3",
"id": "3",
"type": "deployment",
"status": "completed",
"beginTime": 1428541581923,
"endTime": 1428541584150,
"targets": [{
"name": "AdminServer",
"type": "server",
"errors": [],
"status": "completed"
}],
"description": "[Deployer:149026]deploy application basicwebapp on AdminServer.",
"operation": "deploy",
"deploymentName": "basicwebapp"
}
}
Further information about the deployment resource can be obtained using a further REST call, which provides links to operations that can be performed on the application, URLs to access the application, context-paths for registered servlets, runtime data and other useful information.
$ curl \
--user weblogic:welcome1 \
-H Accept:application/json \
http://adc2101001:7001/management/wls/latest/deployments/application/id/basicwebapp
Which returns a response containing a payload with details of the deployment:
{
"links": [
{
"rel": "parent",
"uri": "http://adc2101001:7001/management/wls/latest/deployments/application"
},
{
"rel": "action",
"uri": "http://adc2101001:7001/management/wls/latest/deployments/application/id/basicwebapp/redeploy",
"title": "redeploy"
},
{
"rel": "action",
"uri": "http://adc2101001:7001/management/wls/latest/deployments/application/id/basicwebapp/update",
"title": "update"
},
{
"rel": "action",
"uri": "http://adc2101001:7001/management/wls/latest/deployments/application/id/basicwebapp/start",
"title": "start"
},
{
"rel": "action",
"uri": "http://adc2101001:7001/management/wls/latest/deployments/application/id/basicwebapp/stop",
"title": "stop"
},
{
"rel": "bindables",
"uri": "http://adc2101001:7001/management/wls/latest/deployments/application/id/basicwebapp/bindables"
}
],
"item": {
"name": "basicwebapp",
"state": "active",
"type": "application",
"displayName": "basicwebapp",
"targets": ["AdminServer"],
"planPath": "/scratch/sbutton/Oracle/Middleware/user_projects/domains/arq_domain/servers/AdminServer/upload/basicwebapp/plan/Plan.xml",
"urls": ["http://adc2101001:7001/basicwebapp"],
"openSessionsCurrentCount": 1,
"sessionsOpenedTotalCount": 1,
"servlets": [
{
"servletName": "JspServlet",
"contextPath": "/basicwebapp",
"aggregateMetrics": {
"executionTimeTotal": 0,
"invocationTotalCount": 0,
"reloadTotalCount": 0,
"executionTimeHigh": 0,
"executionTimeLow": 0
},
"servletMetrics": [{
"serverName": "AdminServer",
"executionTimeTotal": 0,
"invocationTotalCount": 0,
"reloadTotalCount": 0,
"executionTimeHigh": 0,
"executionTimeLow": 0
}]
},
{
"servletName": "Faces Servlet",
"contextPath": "/basicwebapp",
"aggregateMetrics": {
"executionTimeTotal": 22,
"invocationTotalCount": 1,
"reloadTotalCount": 1,
"executionTimeHigh": 22,
"executionTimeLow": 22
},
"servletMetrics": [{
"serverName": "AdminServer",
"executionTimeTotal": 22,
"invocationTotalCount": 1,
"reloadTotalCount": 1,
"executionTimeHigh": 22,
"executionTimeLow": 22
}]
},
{
"servletName": "FileServlet",
"contextPath": "/basicwebapp",
"aggregateMetrics": {
"executionTimeTotal": 0,
"invocationTotalCount": 0,
"reloadTotalCount": 0,
"executionTimeHigh": 0,
"executionTimeLow": 0
},
"servletMetrics": [{
"serverName": "AdminServer",
"executionTimeTotal": 0,
"invocationTotalCount": 0,
"reloadTotalCount": 0,
"executionTimeHigh": 0,
"executionTimeLow": 0
}]
}
],
"ejbs": [],
"deploymentPath": "servers/AdminServer/upload/basicwebapp/app/basicwebapp.war",
"applicationType": "war",
"health": {"state": "ok"}
}
}
The documentation provides extensive coverage of the many resources and entity types that can be reached via the REST Management Interface.
Fronting Oracle Maven Repository with Sonatype Nexus
The Sonatype team have announced the release of Nexus 2.1.1 which is a minor update that now works with the Oracle Maven Repository.
I was going to write a bit up about it but Manfred Moser from Sonatype has already put together a blog and video on it:
With the new Nexus 2.11.2 release we are supporting the authentication mechanism used for the Oracle Maven repository in both Nexus OSS and Nexus Pro. This allows you to proxy the repository in Nexus and makes the components discoverable via browsing the index as well as searching for components. You will only need to set this up once in Nexus and all your projects. Developers and CI servers get access to the components and the need for any manual work disappears. On the Nexus side, the configuration changes can be done easily as part of your upgrade to the new release.
Check it out @ Using the Oracle Maven Repository with Nexus
I was going to write a bit up about it but Manfred Moser from Sonatype has already put together a blog and video on it:
With the new Nexus 2.11.2 release we are supporting the authentication mechanism used for the Oracle Maven repository in both Nexus OSS and Nexus Pro. This allows you to proxy the repository in Nexus and makes the components discoverable via browsing the index as well as searching for components. You will only need to set this up once in Nexus and all your projects. Developers and CI servers get access to the components and the need for any manual work disappears. On the Nexus side, the configuration changes can be done easily as part of your upgrade to the new release.
Check it out @ Using the Oracle Maven Repository with Nexus
Oracle Maven Repository - Rolling News
Oracle Maven Repository Is Live The Oracle Maven Repository is live and available for public access to the public APIs, libraries, utilities and archetypes that are shipped as part of the Oracle WebLogic Server 12.1.2 and 12.1.3 releases, including corresponding Coherence versions.
** The repository also publishes the same from the ADF, SOA, OSB and other Fusion Middleware options.
Oracle Maven Repository http://maven.oracle.com
Using the Oracle Maven Repository https://maven.oracle.com/doc.html
Rolling News Oracle Maven Repository is Live
https://redstack.wordpress.com/2015/01/14/happy-new-year-happy-new-oracle-maven-repository
WebLogic Server and Oracle Maven Repository
https://blogs.oracle.com/WebLogicServer/entry/weblogic_server_and_the_oracle
Oracle Maven Repository Index Available
https://redstack.wordpress.com/2015/01/23/oracle-maven-repository-index-now-available-more-to-come/
https://blogs.oracle.com/WebLogicServer/entry/oracle_maven_repository_index_now
JFrog Artifactory Supports Oracle Maven Repositoryhttp://www.jfrog.com/confluence/display/RTF/Artifactory+3.5.1
http://buttso.blogspot.com.au/2015/02/fronting-oracle-maven-repository-with.html
Sonatype Nexus Supports Oracle Maven Repositoryhttps://github.com/archenroot/nexus-oss/releases/tag/nexus-2.11.2-01
https://issues.sonatype.org/browse/NEXUS/fixforversion/14525/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
** The repository also publishes the same from the ADF, SOA, OSB and other Fusion Middleware options.
Oracle Maven Repository http://maven.oracle.com
Using the Oracle Maven Repository https://maven.oracle.com/doc.html
Rolling News Oracle Maven Repository is Live
https://redstack.wordpress.com/2015/01/14/happy-new-year-happy-new-oracle-maven-repository
WebLogic Server and Oracle Maven Repository
https://blogs.oracle.com/WebLogicServer/entry/weblogic_server_and_the_oracle
Oracle Maven Repository Index Available
https://redstack.wordpress.com/2015/01/23/oracle-maven-repository-index-now-available-more-to-come/
https://blogs.oracle.com/WebLogicServer/entry/oracle_maven_repository_index_now
JFrog Artifactory Supports Oracle Maven Repositoryhttp://www.jfrog.com/confluence/display/RTF/Artifactory+3.5.1
http://buttso.blogspot.com.au/2015/02/fronting-oracle-maven-repository-with.html
Sonatype Nexus Supports Oracle Maven Repositoryhttps://github.com/archenroot/nexus-oss/releases/tag/nexus-2.11.2-01
https://issues.sonatype.org/browse/NEXUS/fixforversion/14525/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
Fronting Oracle Maven Repository with Artifactory
The JFrog team announced this week the release of Artifactory 3.5.1, which is a minor update that now works with the Oracle Maven Repository.
http://www.jfrog.com/confluence/display/RTF/Artifactory+3.5.1
I spent a little while yesterday having a look at it, working through the configuration of a remote repository and testing it with a maven project to see how it worked.
Once I'd downloaded it and started it up -- much love for simple and obvious bin/*.sh scripts -- it was a very simple two step process:
1. Since we live behind a firewall first add a proxy configuration to point at our proxy server.
2. Add a new remote repository and pointed it at the Oracle Maven Repository, specifying its URL and using my OTN credentials as username and password.
The Artifactory 3.5.1 documentation stated that the Advanced Settings > Lenient host authentication and Enable cookie management options must be checked when accessing the Oracle Maven Repository.
The Test button is handy to verify the server settings have been entered correctly.
3. Use the Home tab > Client Settings > Maven Settings link to generate and save a settings.xml file that uses the artifactory server.
With the repository running, configured and the settings.xml saved, its then possible to try it out with an existing maven project such as https://github.com/buttso/weblogic-with-arquillian.
I also nuked my local repository to force/verify that the dependencies were fetched through the specified Artifactory server.
Viewing the output of the mvn process and the running Artifactory server you can see that maven is downloading dependencies from http://localhost:8081/artifactory and correspondingly Artifactory is downloading the requested artifact from https://maven.oracle.com.
Once the maven process has completed and all the requested artifacts downloaded, Artifactory will have cached them locally for future use.
Using the Search functionality of the Artifactory Web UI you can search for weblogic artifacts.
Using the Repository Browser functionality of the Artifactory Web UI you can view and navigate around the contents of the remote Oracle Maven Repository.
Nice JFrog > Artifactory team - thanks for the quick support of our repository.
One further thing I'd look at doing is enabling the Configure Passwords Encryption option in the Security settings to encrypt your OTN password, so that it's not stored in cleartext in the etc/artifactory.config.latest.xml file.
http://www.jfrog.com/confluence/display/RTF/Artifactory+3.5.1
I spent a little while yesterday having a look at it, working through the configuration of a remote repository and testing it with a maven project to see how it worked.
Once I'd downloaded it and started it up -- much love for simple and obvious bin/*.sh scripts -- it was a very simple two step process:
1. Since we live behind a firewall first add a proxy configuration to point at our proxy server.
The Artifactory 3.5.1 documentation stated that the Advanced Settings > Lenient host authentication and Enable cookie management options must be checked when accessing the Oracle Maven Repository.
The Test button is handy to verify the server settings have been entered correctly.
3. Use the Home tab > Client Settings > Maven Settings link to generate and save a settings.xml file that uses the artifactory server.
With the repository running, configured and the settings.xml saved, its then possible to try it out with an existing maven project such as https://github.com/buttso/weblogic-with-arquillian.
I also nuked my local repository to force/verify that the dependencies were fetched through the specified Artifactory server.
$ rm -fr ~/.m2/repository/com/oracle
$ mvn -s artifactory-settings.xml test
Viewing the output of the mvn process and the running Artifactory server you can see that maven is downloading dependencies from http://localhost:8081/artifactory and correspondingly Artifactory is downloading the requested artifact from https://maven.oracle.com.
Once the maven process has completed and all the requested artifacts downloaded, Artifactory will have cached them locally for future use.
Using the Search functionality of the Artifactory Web UI you can search for weblogic artifacts.
Using the Repository Browser functionality of the Artifactory Web UI you can view and navigate around the contents of the remote Oracle Maven Repository.
Nice JFrog > Artifactory team - thanks for the quick support of our repository.
One further thing I'd look at doing is enabling the Configure Passwords Encryption option in the Security settings to encrypt your OTN password, so that it's not stored in cleartext in the etc/artifactory.config.latest.xml file.
Oracle Maven Repository - Viewing Contents in Eclipse
With the Oracle Maven Repository now accessible one way to have explore its contents is to use the Maven Repositories viewer feature available in most development tools. I've seen the repository contents displayed easily in NetBeans so I decided to take a look at what it looks like in Eclipse as well.
I had to make a few minor setting changes to get it to work so decided to document them here. If you've gotten it to work with less setting changes, let me know!
As initial setup, I configured my local maven environment to support access to the Oracle Maven Repository. This is documented here https://maven.oracle.com/doc.html. I also installed maven-3.2.5 that includes the updated Wagon module that supports authentication.
Next I downloaded and used the new network installer that the Oracle Eclipse team has published on OTN to install the latest version of Oracle Enterprise Pack for Eclipse.
This network installer lets developers select the version of Eclipse to install and the set of Oracle extensions -- Weblogic, GlassFish and other stuff -- to add in to it.
Once Eclipse is installed, you can add the Maven Repository viewer by selecting Window > Show View > Other > Maven Repositories from the Eclipse toolbar.
I also added a Console > Maven viewer to see what was happening under the covers and arranged them so they were visible at the same time:
With the Maven views ready to go, expand the Global Repositories node. This will show Maven Central (any other repositories you may have configured) and the Oracle Maven Repository if you have configured it correctly in the settings.xml file.
The initial state of the Oracle Maven Repository doesn't show any contents indicating that its index hasn't been downloaded to display.
Right mouse clicking on it and selecting the Rebuild Index option causes an error to be shown in the console output indicating that the index could not be accessed.
To get it to work, I made the following changes to my environment.
Configure Eclipse to Use Maven 3.2.5Using the Eclipse > Preferences > Maven > Installation dialog, configure Eclipse to use Maven 3.2.5. This is preferred version of Maven to use to access the Oracle Maven Repository since it automatically includes the necessary version of the Wagon HTTP module that supports the required authentication configuration and request flow.
Configure Proxy Settings in Maven Settings File ** If you don't need a proxy to access the Internet then step won't be needed **
If you sit behind a firewall and need to use a proxy server to access public repositories then you need to configure a proxy setting inside the maven settings file.
Interestingly for command line maven use and NetBeans a single proxy configuration in settings.xml was enough to allow the Oracle Maven Repository to be successfully accesses and its index and artifacts used.
However with Eclipse, this setting alone didn't allow the Oracle Maven Repository to be accessed. Looking at the repository URL for the Oracle Maven Repository you can see ity's HTTPS based -- https://maven.oracle.com and it appears for Eclipse that a specific HTTPS based proxy setting is required for Eclipse to access HTTPS based repositories.
Rebuild Index SuccessWith the settings in place, the Rebuild Index operation succeeds and the contents of the Oracle Maven Repository are displayed in the repository viewer.
I had to make a few minor setting changes to get it to work so decided to document them here. If you've gotten it to work with less setting changes, let me know!
As initial setup, I configured my local maven environment to support access to the Oracle Maven Repository. This is documented here https://maven.oracle.com/doc.html. I also installed maven-3.2.5 that includes the updated Wagon module that supports authentication.
Next I downloaded and used the new network installer that the Oracle Eclipse team has published on OTN to install the latest version of Oracle Enterprise Pack for Eclipse.
This network installer lets developers select the version of Eclipse to install and the set of Oracle extensions -- Weblogic, GlassFish and other stuff -- to add in to it.
Once Eclipse is installed, you can add the Maven Repository viewer by selecting Window > Show View > Other > Maven Repositories from the Eclipse toolbar.
I also added a Console > Maven viewer to see what was happening under the covers and arranged them so they were visible at the same time:
With the Maven views ready to go, expand the Global Repositories node. This will show Maven Central (any other repositories you may have configured) and the Oracle Maven Repository if you have configured it correctly in the settings.xml file.
The initial state of the Oracle Maven Repository doesn't show any contents indicating that its index hasn't been downloaded to display.
Right mouse clicking on it and selecting the Rebuild Index option causes an error to be shown in the console output indicating that the index could not be accessed.
To get it to work, I made the following changes to my environment.
Configure Eclipse to Use Maven 3.2.5Using the Eclipse > Preferences > Maven > Installation dialog, configure Eclipse to use Maven 3.2.5. This is preferred version of Maven to use to access the Oracle Maven Repository since it automatically includes the necessary version of the Wagon HTTP module that supports the required authentication configuration and request flow.
Configure Proxy Settings in Maven Settings File ** If you don't need a proxy to access the Internet then step won't be needed **
If you sit behind a firewall and need to use a proxy server to access public repositories then you need to configure a proxy setting inside the maven settings file.
Interestingly for command line maven use and NetBeans a single proxy configuration in settings.xml was enough to allow the Oracle Maven Repository to be successfully accesses and its index and artifacts used.
However with Eclipse, this setting alone didn't allow the Oracle Maven Repository to be accessed. Looking at the repository URL for the Oracle Maven Repository you can see ity's HTTPS based -- https://maven.oracle.com and it appears for Eclipse that a specific HTTPS based proxy setting is required for Eclipse to access HTTPS based repositories.
Rebuild Index SuccessWith the settings in place, the Rebuild Index operation succeeds and the contents of the Oracle Maven Repository are displayed in the repository viewer.
Bare-Bones Example of Using WebLogic and Arquillian
The Arquillian project is proving to be very popular for testing code and applications. It's particularly useful for Java EE projects since it allows for in-container testing to be performed, enabling unit tests to use dependency injection and all the common services provided by the Java EE platform.
Arquillian uses the concept of container adapters to allow it to execute test code with a specific test environment. For the Java EE area, most of the Java EE implementations have an adapter than can be used to perform the deployment of the archive under test and to execute and report on the results of the unit tests.
A handy way to see all the WebLogic Server related content on the Arquillian blog is this URL: http://arquillian.org/blog/tags/wls/For WebLogic Server the current set of adapters are listed here: http://arquillian.org/blog/2015/01/09/arquillian-container-wls-1-0-0-Alpha3/
There are multiple adapters available for use. Some of them are historical and some are for use with older versions of WebLogic Server (10.3).
We are actively working with the Arquillian team on finalizing the name, version and status of a WebLogic Server adapter.The preferred adapter set from the WebLogic Server perspective are these:
These adapters utilize the WebLogic Server JMX API to perform their tasks and are the adapters used internally by the development teams when working with Arquillian. They have been tested to work with WebLogic Server [12.1.1, 12.1.2, 12.1.3]. We also have been using them internally with the 12.2.1 version under development to run the CDI TCK and other tests.
To demonstrate WebLogic Server working with Arquillian a bare-bones example is available on GitHub here: https://github.com/buttso/weblogic-with-arquillian
This example has the most basic configuration you can use to employ Arquillian with a Maven project to deploy and execute tests using WebLogic Server 12.1.3.
The README.md file in the project contains more details and a longer description. In summary though:
1. The first step is to add the Arquillian related dependencies in the Maven pom.xml:
2. The next step is to create an arquillian.xml file that the container adapter uses to connect to the remote server that is being used as the server to run the tests:
3. The last step is to create a unit test which is run with Arquillian. The unit test is responsible for implementing the @Deployment method which constructs an archive to deploy that contains the code to be tested. The unit test then provides @Test methods in which the deployment is tested to verify its behaviour:
Executing the unit tests, with the associated archive creation and deployment to the server is performed using the maven test goal:
The tests can be executed directly from IDEs such as NetBeans and Eclipse using the Run Test features:
Executing Tests using NetBeans
Arquillian uses the concept of container adapters to allow it to execute test code with a specific test environment. For the Java EE area, most of the Java EE implementations have an adapter than can be used to perform the deployment of the archive under test and to execute and report on the results of the unit tests.
A handy way to see all the WebLogic Server related content on the Arquillian blog is this URL: http://arquillian.org/blog/tags/wls/For WebLogic Server the current set of adapters are listed here: http://arquillian.org/blog/2015/01/09/arquillian-container-wls-1-0-0-Alpha3/
There are multiple adapters available for use. Some of them are historical and some are for use with older versions of WebLogic Server (10.3).
We are actively working with the Arquillian team on finalizing the name, version and status of a WebLogic Server adapter.The preferred adapter set from the WebLogic Server perspective are these:
- org.jboss.arquillian.container » arquillian-wls-remote-12.1.2
- org.jboss.arquillian.container » arquillian-wls-managed-12.1.2
These adapters utilize the WebLogic Server JMX API to perform their tasks and are the adapters used internally by the development teams when working with Arquillian. They have been tested to work with WebLogic Server [12.1.1, 12.1.2, 12.1.3]. We also have been using them internally with the 12.2.1 version under development to run the CDI TCK and other tests.
To demonstrate WebLogic Server working with Arquillian a bare-bones example is available on GitHub here: https://github.com/buttso/weblogic-with-arquillian
This example has the most basic configuration you can use to employ Arquillian with a Maven project to deploy and execute tests using WebLogic Server 12.1.3.
The README.md file in the project contains more details and a longer description. In summary though:
1. The first step is to add the Arquillian related dependencies in the Maven pom.xml:
2. The next step is to create an arquillian.xml file that the container adapter uses to connect to the remote server that is being used as the server to run the tests:
3. The last step is to create a unit test which is run with Arquillian. The unit test is responsible for implementing the @Deployment method which constructs an archive to deploy that contains the code to be tested. The unit test then provides @Test methods in which the deployment is tested to verify its behaviour:
Executing the unit tests, with the associated archive creation and deployment to the server is performed using the maven test goal:
The tests can be executed directly from IDEs such as NetBeans and Eclipse using the Run Test features:
Executing Tests using NetBeans
Social Coding Resolves JAX-RS and CDI Producer Problem
The inimitable Bruno Borges picked up tweet earlier today commenting on a problem using @Produces with non-CDI libraries with WebLogic Server 12.1.3.
The tweeter put his example up on a github repository to share - quite a nice example of using JAX-RS, CDI integration and of using Arquillian to verify it works correctly. Ticked a couple of boxes for what I've been looking at lately
Forking his project to have a look at it locally:
https://github.com/buttso/weblogic-producers
Turns out that the issue was quite a simple and common one - a missing reference to the jax-rs:2.0 shared-library that is needed to use JAX-RS 2.0 on WebLogic Server 12.1.3. Needs a weblogic.xml to reference that library.
I made the changes in a local branch and tested it again:
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] producers .......................................... SUCCESS [ 0.002 s]
[INFO] bean ............................................... SUCCESS [ 0.686 s]
[INFO] web ................................................ SUCCESS [ 7.795 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
With the tests now passing, pushed the branch to my fork and sent Kuba a pull request to have a look at the changes I made:
https://github.com/buttso/weblogic-producers/tree/steve_work
I now just hope it works in his environment too :-)
The GitHub model is pretty magical really.
The tweeter put his example up on a github repository to share - quite a nice example of using JAX-RS, CDI integration and of using Arquillian to verify it works correctly. Ticked a couple of boxes for what I've been looking at lately
Forking his project to have a look at it locally:
https://github.com/buttso/weblogic-producers
Turns out that the issue was quite a simple and common one - a missing reference to the jax-rs:2.0 shared-library that is needed to use JAX-RS 2.0 on WebLogic Server 12.1.3. Needs a weblogic.xml to reference that library.
I made the changes in a local branch and tested it again:
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] producers .......................................... SUCCESS [ 0.002 s]
[INFO] bean ............................................... SUCCESS [ 0.686 s]
[INFO] web ................................................ SUCCESS [ 7.795 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
With the tests now passing, pushed the branch to my fork and sent Kuba a pull request to have a look at the changes I made:
https://github.com/buttso/weblogic-producers/tree/steve_work
I now just hope it works in his environment too :-)
The GitHub model is pretty magical really.
Using the WebLogic Embedded EJB Container
The WebLogic Server 12.1.3 EJB Developers Guide was recently updated to note that the embedded EJB container can be used by adding a reference to weblogic.jar to the CLASSPATH when the EJB client is being executed.
https://docs.oracle.com/middleware/1213/wls/EJBAD/embedejb.htm#EJBAD1403
This is very convenient since it enables the WebLogic Server embedded EJB container to used by simply adding weblogic.jar to the classpath when running the client:
Or for example if you are developing unit tests using JUnit and running them from a maven project, you can configure the maven-surefire-plugin to use WebLogic Server to run the EJB test code in its embedded EJB container:
A fully working example of using this is available in this GitHub repository:
https://github.com/buttso/weblogic-embedded-ejb
For more information have a look at the repository and check out the example.
https://docs.oracle.com/middleware/1213/wls/EJBAD/embedejb.htm#EJBAD1403
This is very convenient since it enables the WebLogic Server embedded EJB container to used by simply adding weblogic.jar to the classpath when running the client:
Or for example if you are developing unit tests using JUnit and running them from a maven project, you can configure the maven-surefire-plugin to use WebLogic Server to run the EJB test code in its embedded EJB container:
A fully working example of using this is available in this GitHub repository:
https://github.com/buttso/weblogic-embedded-ejb
For more information have a look at the repository and check out the example.
WebLogic Maven Plugin - Simplest Example
I've seen a question or two in recent days on how to configure the weblogic maven plugin.
The official documentation is extensive ... but could be considered TL;DR for a quick bootstrapping on how to use it.
As a late friday afternoon exercise I just pushed out an example of a very simple project that uses the weblogic-maven-plugin to deploy a web module. It's almost the simplest configuration that can be done of the plugin to perform deployment related operations of a project/module:
https://github.com/buttso/weblogic-maven-plugin
This relies on the presence of either a local/corporate repository that contains the set of weblogic artefacts and plugins - OR - you configure and use the Oracle Maven Repository instead.
Example pom.xml
The official documentation is extensive ... but could be considered TL;DR for a quick bootstrapping on how to use it.
As a late friday afternoon exercise I just pushed out an example of a very simple project that uses the weblogic-maven-plugin to deploy a web module. It's almost the simplest configuration that can be done of the plugin to perform deployment related operations of a project/module:
https://github.com/buttso/weblogic-maven-plugin
This relies on the presence of either a local/corporate repository that contains the set of weblogic artefacts and plugins - OR - you configure and use the Oracle Maven Repository instead.
Example pom.xml
Updated WebLogic Server 12.1.3 Developer Zip Distribution
We've just pushed out an update to the WebLogic Server 12.1.3 Developer Zip distribution containing the bug fixes from a recent PSU (patch set update).
This is great for developers since it maintains the high quality of the developer zip distribution and the convenience it provides - avoids reverting to the generic installer to then enable the application of patch set updates. For development use only.
Download it from OTN:
http://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-for-dev-1703574.html
Check out the readme for the list of bug fixes:
http://download.oracle.com/otn/nt/middleware/12c/wls/1213/README_WIN_UP1.txt
This is great for developers since it maintains the high quality of the developer zip distribution and the convenience it provides - avoids reverting to the generic installer to then enable the application of patch set updates. For development use only.
Download it from OTN:
http://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-for-dev-1703574.html
Check out the readme for the list of bug fixes:
http://download.oracle.com/otn/nt/middleware/12c/wls/1213/README_WIN_UP1.txt
Updating a GitHub forked repository
Mostly a reminder to self but thought I'd post the link in case anyone else is looking for this. More pointers the merrier.
Simple, straight forward steps to synchronise a forked repository with its upstream repository and keep it up to date.
https://help.github.com/articles/syncing-a-fork
Syncing a fork
Up-to-date fork of the weblogic-docker repositoryTake care to read the final tip in the guide that notes that the steps only update a local copy - the fetch and merge changes still need to be pushed back to the GitHub remote repository.
Tip: Syncing your fork only updates your local copy of the repository. To update your fork on GitHub, you must push your changes.
Simple, straight forward steps to synchronise a forked repository with its upstream repository and keep it up to date.
https://help.github.com/articles/syncing-a-fork
Syncing a fork
Sync a fork of a repository to keep it up-to-date with the upstream repository.
...
Following these simple steps enables a forked repository to be easily and regularly updated with changes from the upstream repository. ...
Up-to-date fork of the weblogic-docker repositoryTake care to read the final tip in the guide that notes that the steps only update a local copy - the fetch and merge changes still need to be pushed back to the GitHub remote repository.
Tip: Syncing your fork only updates your local copy of the repository. To update your fork on GitHub, you must push your changes.
Oracle Maven Repository is Live with WebLogic Server Artifacts
Oracle Maven Repository
Very. Exciting. News.
The Oracle Maven Repository has just gone live and is now available for public access, loaded with WebLogic Server artifacts from the 12.1.2 and 12.1.3 releases.
Want free and easy access to WebLogic Server APIs, libraries and plugins - just have at it!
http://maven.oracle.com
https://blogs.oracle.com/WebLogicServer/entry/weblogic_server_and_the_oracle
Exploring DevOps with Chef and WebLogic Server
I'm about to embark on a journey that explores the use of WebLogic Server within a DevOps regime. My first port of call for this journey will be using Chef.
A loose travel itinerary is:
The Docker project is here on GitHub:
I also tried a quick experiment with using Oracle Linux as the base docker image:
The Dockerfile contains the set of instructions required to install the ChefDK and the necessary utilities into the docker image when it is built.
With this Dockerfile a build operation can be performed that produces a docker image, which can then be run to provide an environment in which start exploring the Chef.
This is just a brief outline - I will describe this first task in more detail once I get a bit further along and can verify everything has been installed and works correctly.
A loose travel itinerary is:
- Setting up an environment to explore the basic operations of Chef - using the Chef Development Kit (ChefDK)
- Exploring the basics of how Chef works to install Java and WebLogic Server on a single node
- Installing and examining some of the existing cookbooks that are available for Java and WebLogic Server
- Extending the environment to provision multiple nodes to create a typical multiple machine clustered WebLogic Server environment
The Docker project is here on GitHub:
I also tried a quick experiment with using Oracle Linux as the base docker image:
The Dockerfile contains the set of instructions required to install the ChefDK and the necessary utilities into the docker image when it is built.
#
# Dockerfile for Chef 4 WLS Environment
#
FROM ubuntu
MAINTAINER Steve Button <>
ENV DEBIAN_FRONTEND noninteractive
# Install Utilities
RUN apt-get update
RUN apt-get install -yq wget
RUN apt-get install -yq curl
RUN apt-get install -yq git
# Install Chef
RUN wget https://opscode-omnibus-packages.s3.amazonaws.com/ubuntu/12.04/x86_64/chefdk_0.3.5-1_amd64.deb
RUN dpkg -i chefdk*.deb
# Verify and Setup Chef
RUN chef verify
RUN echo 'eval "$(chef shell-init bash)"' << ~/.bashrc
...
CMD ["/bin/bash"]
With this Dockerfile a build operation can be performed that produces a docker image, which can then be run to provide an environment in which start exploring the Chef.
$ docker build -t buttso/chef4wls .
$ docker run -ti buttso/chef4wls
oracle@5481a3330f27:~$ which chef-client
/opt/chefdk/embedded/bin/chef-client
This is just a brief outline - I will describe this first task in more detail once I get a bit further along and can verify everything has been installed and works correctly.
Retro Day - Workload Management in WebLogic Server
Quite recently, I stumbled across this older but still very relevant whitepaper on the workload management capabilities of WebLogic Server. Written by one of the key engineers at the time, who later went on to become an architectect, it explains the workings of the new work load management feature introduced into WebLogic Server at the time and covers the concepts of work-manager configuration and effect, work scheduling and prioritization, overload protection and more.
This is well worth a read if you are ever looking for good information on the work load management feature of WebLogic Server:
http://www.oracle.com/technetwork/articles/entarch/workload-management4-101578.html
This is well worth a read if you are ever looking for good information on the work load management feature of WebLogic Server:
http://www.oracle.com/technetwork/articles/entarch/workload-management4-101578.html
JSON Parsing is Cake with WebLogic Server 12.1.3
Another feature of WebLogic Server 12.1.3 that developers will find really useful is the inclusion of an implementation of JSR-353 Java API for JSON Processing.
See Chapter 10 Java API for JSON Processing in the Developing Applications for Oracle WebLogic Server book @ http://docs.oracle.com/middleware/1213/wls/WLPRG/java-api-for-json-proc.htm#WLPRG1055
The original JSR submission for this API provides a good description of what it sets out to do.
JSR 353: JavaTM API for JSON Processing
This new API, working from the foundations provided by earlier implementations such as Jackson, Jettison and Google JSon, provides a standard API for working with JSON from Java. The goals and objectives of the API are described in the specification request as:
JSON(JavaScript Object Notation) is a lightweight data-interchange format.
Many popular web services use JSON format for invoking and returning the data.
Currently Java applications use different implementation libraries to produce/consume JSON from the web services. Hence, there is a need to standardize a Java API for JSON so that applications that use JSON need not bundle the implementation libraries but use the API. Applications will be smaller in size and portable.
The goal of this specification is to develop such APIs to:
Unlike JAX-RS 2.0 and JPA 2, both of which have pre-existing specification versions that need to be supported by default, there are no additional steps required for applications to use this API with WebLogic Server 12.1.3. It's simply included as a default module of the server and available for any application to make use of.
The API and implementation is located in this jar file in a WebLogic Server 12.1.3 installation:
In the my previous post, Using the JAX-RS 2.0 Client API with WebLogic Server 12.1.3
I have a short example of using the API to parse an JAX-RS supplied InputStream to marshall a JSON payload into a Java object.
http://docs.oracle.com/javaee/7/tutorial/doc/jsonp.htm
Arun Gupta also has a good hands-on lab under development for Java EE 7 that uses the JSON API to read and write JSON into Java objects that represent a movie database. His examples collaborate with JAX-RS to issue both GET and POST calls to read and update data using JSON payload.
https://github.com/javaee-samples/javaee7-samples
See Chapter 10 Java API for JSON Processing in the Developing Applications for Oracle WebLogic Server book @ http://docs.oracle.com/middleware/1213/wls/WLPRG/java-api-for-json-proc.htm#WLPRG1055
The original JSR submission for this API provides a good description of what it sets out to do.
JSR 353: JavaTM API for JSON Processing
This new API, working from the foundations provided by earlier implementations such as Jackson, Jettison and Google JSon, provides a standard API for working with JSON from Java. The goals and objectives of the API are described in the specification request as:
JSON(JavaScript Object Notation) is a lightweight data-interchange format.
Many popular web services use JSON format for invoking and returning the data.
Currently Java applications use different implementation libraries to produce/consume JSON from the web services. Hence, there is a need to standardize a Java API for JSON so that applications that use JSON need not bundle the implementation libraries but use the API. Applications will be smaller in size and portable.
The goal of this specification is to develop such APIs to:
- Produce and consume JSON text in a streaming fashion(similar to StAX API for XML)
- Build a Java object model for JSON text using API classes(similar to DOM API for XML)
Unlike JAX-RS 2.0 and JPA 2, both of which have pre-existing specification versions that need to be supported by default, there are no additional steps required for applications to use this API with WebLogic Server 12.1.3. It's simply included as a default module of the server and available for any application to make use of.
The API and implementation is located in this jar file in a WebLogic Server 12.1.3 installation:
$ORACLE_HOME/wlserver/modules/javax.json_1.0.0.0_1-0.jar
In the my previous post, Using the JAX-RS 2.0 Client API with WebLogic Server 12.1.3
I have a short example of using the API to parse an JAX-RS supplied InputStream to marshall a JSON payload into a Java object.
...
GeoIp g = new GeoIp();
JsonParser parser = Json.createParser(entityStream);
while (parser.hasNext()) {
switch (parser.next()) {
case KEY_NAME:
String key = parser.getString();
parser.next();
switch (key) {
case "ip":
g.setIpAddress(parser.getString());
break;
case "country_name":
g.setCountryName(parser.getString());
break;
case "latitude":
g.setLatitude(parser.getString());
break;
case "longitude":
g.setLongitude(parser.getString());
break;
case "region_name":
g.setRegionName(parser.getString());
break;
case "city":
g.setCity(parser.getString());
break;
case "zipcode":
g.setZipCode(parser.getString());
break;
default:
break;
}
break;
default:
break;
}
}
...
The Java EE 7 tutorial has a section showing how to use the new javax.json API which is well worth having a look at if working with JSON is your thing.
http://docs.oracle.com/javaee/7/tutorial/doc/jsonp.htm
Arun Gupta also has a good hands-on lab under development for Java EE 7 that uses the JSON API to read and write JSON into Java objects that represent a movie database. His examples collaborate with JAX-RS to issue both GET and POST calls to read and update data using JSON payload.
https://github.com/javaee-samples/javaee7-samples
Developing with JAX-RS 2.0 for WebLogic Server 12.1.3
In an earlier post on the topic of Using JAX-RS 2.0 with WebLogic Server 12.1.3, I described that we've utilized the shared-library model to distribute and enable it.
This approach exposes the JAX-RS 2.0 API and enlists the Jersey 2.x implementation on the target server, allowing applications to make use of it as when they are deployed through a library reference in a weblogic deployment descriptor.
The one resulting consideration here from a development perspective is that since this API is not part of the javaee-api-6.jar nor is it a default API of the server, it's not available in the usual development API libraries that WebLogic provides.
For instance the
To develop an application using JAX-RS 2.0 to deploy to WebLogic Server 12.1.3, the javax.ws.rs-api-2.0.jar needs to be sourced and added to the development classpath.
Using maven, this is very simple to do by adding an additional dependency for the
Note here that the scope is set to provided since the library will be realized at runtime through
For other build systems using automated dependency management such as Gradle or Ant/Ivy, the same sort of approach can be used.
For Ant based build systems, the usual approach of obtaining the necessary API libraries and adding them to the development CLASSPATH will work. Be mindful that there is no need to bundle the jax.ws.rs-ap-2.0.jar in the application itself as it will be available from the server when correctly deployed and referenced in the weblogic deployment descriptor.
This approach exposes the JAX-RS 2.0 API and enlists the Jersey 2.x implementation on the target server, allowing applications to make use of it as when they are deployed through a library reference in a weblogic deployment descriptor.
The one resulting consideration here from a development perspective is that since this API is not part of the javaee-api-6.jar nor is it a default API of the server, it's not available in the usual development API libraries that WebLogic provides.
For instance the
$ORACLE_HOME/wlserver/server/lib/api.jar
doesn't contain a reference to the JAX-RS 2.0 API, nor do the set of maven artifacts we produce and push to a repository via the oracle-maven-sync plugin contain the javax.ws.rs-api-2.0.jar
library.To develop an application using JAX-RS 2.0 to deploy to WebLogic Server 12.1.3, the javax.ws.rs-api-2.0.jar needs to be sourced and added to the development classpath.
Using maven, this is very simple to do by adding an additional dependency for the
javax.ws.rs:javax.ws.rs-api:2.0
artifact that is hosted in public maven repositories:<dependency>
<groupid>javax.ws.rs</groupid>
<artifactid>javax.ws.rs-api</artifactid>
<version>2.0</version>
<scope>provided</scope>
</dependency>
Note here that the scope is set to provided since the library will be realized at runtime through
jax-rs-2.0.war
shared-library that it deployed to the target server and referenced by the application. It doesn't need to be packaged with the application to deploy to WebLogic Server 12.1.3.For other build systems using automated dependency management such as Gradle or Ant/Ivy, the same sort of approach can be used.
For Ant based build systems, the usual approach of obtaining the necessary API libraries and adding them to the development CLASSPATH will work. Be mindful that there is no need to bundle the jax.ws.rs-ap-2.0.jar in the application itself as it will be available from the server when correctly deployed and referenced in the weblogic deployment descriptor.