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.

$ 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:
/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

The console will display a message confirming the debug Java VM is using:

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 specify the new server as the destination to use to run the application:

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!

NetBeans 8.1 Remote Deployment for WebLogic

Stoked that NetBeans 8.1 will have support for deployment to remote WebLogic Server instances.

http://wiki.netbeans.org/NewAndNoteworthyNB81#Remote_WebLogic

#lovethistool

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 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.

Deploying a Random JSF 2.0 Example on WebLogic Server using Maven and NetBeans and Maven

I had a bit of a hunt around yesterday looking for some JSF 2.0 example applications to deploy.  I quickly came across a comprehensive JSF 2.0 tutorial @ http://www.coreservlets.com/JSF-Tutorial/jsf2/ published by Marty Hall.

For each of the tutorial sections on this site, the example code and pages that are used to demonstrate the concepts and discussion are published as accessible source code.

So I thought I'd try a few of them out with WebLogic Server 10.3.5. 

The examples I looked at didn't contain a build script, so I very simply converted them into Maven projects, which I then was able to open immediately in NetBeans (this feature rocks!).  I then built, packaged and ran the application on a WebLogic Server 10.3.5 domain, all from NetBeans.

All up, I'd say it tool ~2 mins to get the example loaded and building in NetBeans and deployed to  WebLogic Server.

It takes a lot more to describe it below than it does to actually do it.

Here's what I did to get the data-tables example to build, package and deploy to WebLogic Server. 

1. Download the zip file from http://www.coreservlets.com/JSF-Tutorial/jsf2/code/data-tables.zip.

2. Extract the zip file to a local directory, which produces:

/data-tables/WebContent
/data-tables/src
/data-tables/build

3. Generate a Java EE  Web Application using the Maven Archetype mechanism.  What a great feature this is in Maven. 

$ mvn archetype:generate
...
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
...
263: remote -> webapp-j2ee13 (-)
264: remote -> webapp-j2ee14 (-)
265: remote -> webapp-javaee6 (-)
266: remote -> webapp-jee5 (-)
...
Choose a number: 107: 266
Choose version:
1: 1.0
2: 1.0.1
3: 1.1
4: 1.2
Choose a number: 4:
Define value for property 'groupId': : coreservlets
Define value for property 'artifactId': : data-tables
Define value for property 'version':  1.0-SNAPSHOT: :
Define value for property 'package':  coreservlets: :
Confirm properties configuration:
groupId: coreservlets
artifactId: data-tables
version: 1.0-SNAPSHOT
package: coreservlets
 Y: : y

4. Copy the WebContent and src directories from the data-tables example into the new Maven project structure.

$ cp -rp ~/Projects/Java/data-tables/WebContent/* src/main/webapp/
$ cp -rp ~/Projects/Java//data-tables/src/ src/main/java/


5. Start NetBeans and simply open the data-tables/pom.xml file to load the project into the IDE.



Click around and explore the project to get a sense of what it contains.

6. Add the jsf-api dependency to the POM so the ManagedBean classes can be compiled.

You can either manually add this direct to the pom.xml as:
    
    <dependency>
        <groupId>javax.faces</groupId>
        <artifactId>jsf-api</artifactId>
        <version>2.0</version>
        <scope>provided</scope>
    </dependency>

Or use the "Add Dependency" option on the project to search for it and enter it via a dialog:

7. Add a weblogic.xml deployment descriptor to reference the JSF 2.0 shared-library deployed on the WLS domain.

I simply coped in an existing version of the file I had used before.  You can also use the "New --> WebLogic --> WebLogic Descriptor" option in NetBeans to add it.

Add a library-ref to the jsf-2.0.war shared-library deployed on the WLS 10.3.4 domain.

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app>
  <context-root>/data-tables-1.0-SNAPSHOT</context-root>
  <library-ref>
    <library-name>jsf</library-name>
    <specification-version>2.0</specification-version>
    <implementation-version>1.0.0.0_2-0-2</implementation-version>
  </library-ref>
</weblogic-web-app>

8. Run the project, select the WLS 10.3.5 Server type and watch it get built and packaged via Maven and deployed by NetBeans.  This will start the WLS 10.3.5 server if necessary.

9. View the example application in a browser

Summary: there it is, a random JSF 2.0 example application, converted to a Maven project, opened in NetBeans and deployed to WebLogic Server 10.3.5, all in ~ 2mins.

JSF 2.0, JPA 2.0 and Bean Validation on WebLogic Server

For some time now, I’ve been meaning to build a simple application to demonstrate the use of JSF 2.0, JPA 2.0 and Bean Validation with WebLogic Server 10.3.4.  But I hadn’t gotten around to it until I had a couple of hours free late last week.

Seeing as I didn’t have all that much time, I thought I’d try and repurpose the Java EE 6 CRUD (create-remove-update-delete) application that NetBeans generates for GlassFish 3.x, and see if I could get it to run on WebLogic Server. 

The short answer to that was a resounding yes, with only a few minor changes or tricks.

In this blog, I’m going to step through what I did and highlight the changes that I played around with in order to make it work.  I'm not going to make this a tutorial (at this point) since most of the steps that are required are simply using the NetBeans IDE and its wizards to generate the requisite components and pages.

Developing the Application

1. The starting point for this app was a single table, Widgets, created in a local Derby database. 
   
   
2. Using NetBeans 7.0, a new Java EE Enterprise Application was created, using Java EE 6 and targetted at the GlassFish 3.1 server installed with NetBeans.  This produces two child projects: a Web project and an EJB project.
   
   
   
   
3. In the EJB project, use the "Entity Classes from Database" to generate a JPA 2.0 Entity from the Widget table.
   
   
   
   Worth pointing out here is the use of the Bean Validation specification to declare constraints on the various fields of the Widget entity. 
   
   I particularly appreciated the smarts NetBeans uses to provide a suggested @Pattern regular expression for an email field
   
   @Pattern(regexp="[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?", message="Invalid email")//if the field contains email address consider using this annotation to enforce field validation
   @Size(max = 100)
   @Column(name = "EMAIL")   
   private String email;
   
   
4. Next, invoke the "Sessions Bean For Entity Classes ..." to generate a session facade with CRUD methods for the Widget entity. 
   
   
   
   Worth noting here are two points:   First, the use of a Generics based Abstract class for the base CRUD operations, which is then subclassed by the WidgetFacade session bean to work specifically with the Widget entity.  Second, the use of the JPA 2.0 Criteria API to build a number of queries in the base class.
   
   public List<T> findRange(int[] range) {
       javax.persistence.criteria.CriteriaQuery cq getEntityManager().getCriteriaBuilder().createQuery();
       cq.select(cq.from(entityClass));
       javax.persistence.Query q = getEntityManager().createQuery(cq);
       q.setMaxResults(range[1] - range[0]);
       q.setFirstResult(range[0]);
       return q.getResultList();
   }
   
   This session bean is created with a local interface since the EJB 3.0 implementation in WebLogic Server requires the use of a business interface.
   
   
5. In the persistence.xml file, a trick worth keeping in mind here which may save you some pain later is to explicitly specify the JPA provider to use.  This helps later on when you deploy the completed application to WebLogic Server, where the default JPA provider is Kodo/OpenJPA.  This can be overridden at the WLS domain level, but setting it in persistence.xml within the application itself is an easy way to do it now.
   
   <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
   
   For more details on changing the default JPA provider for a WLS domain, see here:
   
   http://buttso.blogspot.com/2010/05/changing-default-jpa-provider-in.html
   
   
6. With the EJB project now complete, the JSF pages can be generated for the application.  In the Web project, this is done using the "JSF Pages from Entity Classes ..." wizard. 
   
   
   
   What this wizard generates is a set of JSF pages to represent each of the CRUD operations, a Controller ManagedBean to handle the various tasks required by each of the JSF view pages and the data interactions (with paging) and a EJB 3.1 @Stateless session bean to act as a session facade on the Widget entity.
   
   The new EJB in WAR packaging option available with Java EE 6 is not yet available on WebLogic Server, so the first trick here is to change the Web project to use the session facade that has already been generated in the EJB project.  This is possible because the NetBeans wizards generate the same underlying code for the session facade whether it is for an EJB specific project or as part of the JSF Pages for Entity Classes wizard. 
   
   Delete the session bean bean in the Web project, then adjust the JSF controller to use the local interface for the session bean in the EJB project:
   
   //@EJB
   //private sab.demo.widget.service.WidgetFacade ejbFacade;
   @EJB
   private sab.demo.widget.service.WidgetFacadeLocal ejbFacade;
   
   Note that EJB 3.1 supports a No-Interface view of an EJB, which WebLogic Server doesn't yet support.  So here we have changed the injection point to use the Local interface from our EJB project.
   
   There is also a getFacade method which needs this simple type change as well:
   
   //private WidgetFacade getFacade() {
   private WidgetFacadeLocal getFacade() {
       return ejbFacade;
   }
   
   
7. Delete the persistence.xml file generated within the Web project, since this will now be supplied with the EJB project.
   
   
8. Modify the web.xml file and change the "version" attribute to be "2.5" to specify a valid version for WebLogic Server:
   
   <web-app version="2.5" ... >
   
   
9. Using the "New ..." wizard, add a WebLogic Deployment descriptor to the Web project, and specify a shared library reference to the JSF 2.0 shared library that WebLogic Server supplies.
   
   <?xml version="1.0" encoding="UTF-8"?>
   <weblogic-web-app>
       <context-root>Widget</context-root>
       <library-ref>
           <library-name>jsf</library-name>
          <specification-version>2.0</specification-version>
          <implementation-version>1.0.0.0_2-0-2</implementation-version>
       </library-ref>   
   </weblogic-web-app>
   
   See the links for more details about JSF 2.0 and WebLogic Server, including instructions for how to deploy and reference the shared-library:
   
   http://buttso.blogspot.com/2010/05/jsf-20-support-in-weblogic-server-1033.html
   http://buttso.blogspot.com/2011/03/jsf-with-managed-beans-and-dependency.html
   
   
10. Build the final application into an EAR file that is ready for deployment.
    
    

Deploying the Application to WebLogic Server

1. To deploy a JSF 2.0 application to WebLogic Server, the JSF 2.0 shared-library must be deployed.  See links referenced above for details on how to do this.
   
   http://buttso.blogspot.com/2010/05/jsf-20-support-in-weblogic-server-1033.html
   http://buttso.blogspot.com/2011/03/jsf-with-managed-beans-and-dependency.html
   
   
2. To use JPA 2.0 with WebLogic Server, two optional libraries within the WebLogic Server installation must be placed into the classpath.  This can be automated through the use of a SmartUpdate patch, or it can be performed manually by setting a PRE_CLASSPATH environment variable and specifying the required libraries before starting the WebLogic Server domain. 
   
   $ export PRE_CLASSPATH=/Users/sbutton/Java/wls-1035-dev/modules/com.oracle.jpa2support_1.0.0.0_2-0.jar:/Users/sbutton/Java/wls-1035-dev/modules/javax.persistence_1.0.0.0_2-0-0.jar
   See the documentation for more details as needed:
   
   http://download.oracle.com/docs/cd/E17904_01/web.1111/e13720/using_toplink.htm#CIHDJHHI
   
   
3. The application is also using the Bean Validation specification which is not supplied with WebLogic Server 10.3.4.  To ensure that the JSF 2.0 and JPA 2.0 implementation in TopLink can see the Bean Validation implementation and automatically enlist it's services, I added it as an additional library to the PRE_CLASSPATH environment variable:
   
   $ export PRE_CLASSPATH=${PRE_CLASSPATH):/Users/sbutton/Java/glassfish-31/glassfish3/glassfish/modules/bean-validator.jar
   
   Note here I am just referencing the library from a local GlassFish installation I have.  I could copy this library out into a separate location or even download it independently and reference it.  Call me lazy if you will ... :-)
   
   
4. Start a WebLogic Server domain
   
   
5. Using the WebLogic Console, configure the required datasource (jdbc/sample) to point at the Derby database and test to ensure it is working.
   
   
6. Using the console, deploy the application.
   
   
   

Test the application

With the application deployed, it can be tested to observe the JSF 2.0, JPA 2.0 and Bean Validation uses working on WebLogic Server.

For instance, create a new Widget and specify an incorrect email address.  You'll see that JSF will automatically detect the invalid value based on the @Pattern constraint set on the Widget entity, and display the accompanying message as an error message on the page.

Correcting the email address value, the entry can be successfully be saved.

Looking at the stdout on the console where the WLS domain was started, the use of JPA 2.0 via EclipseLink and the automatic enlistment of the Bean Validation implementation can be seen in the lines below:

<May 16, 2011 3:58:26 PM CST> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>
May 16, 2011 3:58:40 PM org.hibernate.validator.util.Version <clinit>
INFO: Hibernate Validator 4.1.0.Final
May 16, 2011 3:58:40 PM org.hibernate.validator.engine.resolver.DefaultTraversableResolver detectJPA
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
<May 16, 2011 3:58:40 PM CST> <Notice> <EclipseLink> <BEA-2005000> <2011-05-16 15:58:40.781--ServerSession(1625943009)--EclipseLink, version: Eclipse Persistence Services - 2.1.3.v20110304-r9073>
<May 16, 2011 3:58:40 PM CST> <Notice> <EclipseLink> <BEA-2005000> <2011-05-16 15:58:40.782--ServerSession(1625943009)--Server: 10.3.5.0>
<May 16, 2011 3:58:41 PM CST> <Notice> <EclipseLink> <BEA-2005000> <2011-05-16 15:58:41.266--ServerSession(1625943009)--file:/Users/sbutton/Projects/Domains/wls1035/servers/AdminServer/tmp/_WL_user/Widget/qb0nwv/Widget-EJB.jar_Widget-EJBPU login successful>

If you forget to specify the JPA provider using the <provider> element in config.xml and deploy the application to a default WLS domain, then you may see the following error message when you try and access the application:

This exception indicates that an application is using the JPA 2.0 API, but WebLogic Server can't find a JPA 2.0 provider.  This is the default condition of a WLS domain where the Kodo/Open JPA 1.0 provider is supplied at runtime.
 
This can be easily modified as described above by specifying an explicit <provider> value for EclipseLink (or Hibernate if you are using that) or by altering the default JPA provider at the domain level using the WebLogic Console:



Summary

It proved to be quite straight forward to take the Java EE 6 CRUD application generated by NetBeans and alter it slightly to deploy and run successfully on WebLogic Server 10.3.4, using it's JSF 2.0 and JPA 2.0 support.

Using JAX-RS with WebLogic Server 10.3.4

There's been a flurry of blogs recently about using JAX-RS.

It may have slipped under the radar a little, but WebLogic Server 10.3.4 now also provides support for deploying applications that use JAX-RS Web Services.

Here's the documentation for it:

Programming RESTful Web Services

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13734/rest.htm#WSADV550

With WebLogic Server, the JAX-RS support is handled in the same manner as JSF, in that a set of optional shared-libraries are provided that can be deployed to the server, which makes the JAX-RS framework available for deployed applications to use. Applications then reference these shared-libraries using the relevant weblogic deployment descriptor.

What I'd like to do in this blog is to show JAX-RS working on WebLogic Server 10.3.4 and at the same time, how the NetBeans 7.0 Beta release supports WebLogic Server to make the development of JAX-RS based applications quick and efficient by removing some of the work required in deploying and referencing the libraries.  .

1. Launch NetBeans and register a WebLogic Server 10.3.4 instance.

I won't go through the individual steps as this is very straight forward. In my particular case, I have a brand new domain I am using, so there are no applications or shared-libraries deployed.

 

2. Create a new Java EE Web project

The next step is to create a new Java EE Web project using the NetBeans project wizards. This project will host our JAX-RS resource and is what we will deploy and test on WebLogic Server.

Create a new Java Web Project and fill in the project details.

For the Server, I specify the WebLogic Server domain that I registered earlier, leave the Context-Path and finish the project creation and click finish to create the new project.



3. Add a JAX-RS resource to the project.

With the Java Web project created, I can now add a new JAX-RS resource to it, again using a NetBeans wizard -- the simplest way to test this is to use the "RESTful Web Services from Patterns" wizard and select the "Simple Root Resource"option.

Select the “Simple Root Resource” option.



Fill in the details for the resource to be created. In this case, I am specifying a MIME Type of "text/html" to make the default end point easy to test from a browser.



On the last page of the wizard, I am presented with options for how to configure the project. NetBeans has knowledge of how WebLogic Server employs JAX-RS and presents them to you.

I select the option to have NetBeans automatically configure the JAX-RS servlet adapter in web.xml and then I select the "Use server bundled Jersey Library" option.

The JAX-RS resource is then created and added to the project.

Looking at the project, I can see a number of things have changed:

The existing web.xml descriptor has been modified to expose the Jersey Servlet adapter.



A new weblogic.xml deployment descriptor has been added, which references the required JAX-RS shared-library that will be deployed on the server.



And a new class has been added that represents the JAX-RS resource.



After editing the generated getHtml method to return a string I'll recognize, the project is ready to be deployed and tested.

4. Deploy and run the project

Selecting "Run" from the project menu, NetBeans will perform the task of compiling and deploying the project to the target WebLogic Server domain.



NetBeans performs the necessary deployment operations.

Now the interesting thing that happens as part of this "run" process (and why it takes 27 seconds most likely) is that NetBeans has recognized that the target WebLogic Server domain doesn't have the necessary shared-library that the project is using. To resolve this problem, it seamlessly deploys the required library from the $WL_HOME/common/deployable-libraries directory as part of the deployment process.

Once the deployment of the project has completed, looking at the registered WebLogic Server domain, I can now see the jersey-bundle#1.1.1@1.1.5.1 library present on the server.



We can now test the JAX-RS resource.

5. Test the JAX-RS Resource

Expanding the project, there is a "RESTful Web Services" folder that presents a view of the JAX-RS resources in the project. To test the end-point, I select the method and click the "Test Resource URI" option.



This opens a browser window and shows the results of successfully calling the getHtml method.



So there you have it, a JAX-RS resource created in NetBeans, deployed and running on WebLogic Server 10.3.4.

As a final piece to add to this blog, I'll also show off another new feature that NetBeans 7.0 has added to further support WebLogic Server. The new "local deployment" model deploys applications from an exploded, local directory. This means that deployment to WebLogic Server is now much better since a code change doesn't require a full packaging and "deployment" cycle to test. In fact, using NetBeans with WebLogic Server nows offer compile-on-save and test functionality!

6. Add another method and test

With the application deployed, I can now change the class to add more functionality. I'll add two new methods that sayHello and sayBye to a user. In these methods, I'll use the @PathParam and @QueryParam annotations respectively to extract the value from the URI and set it automatically on the method call.



To test these new methods, all I need to do is save the change, NetBeans automatically compiles the class and I can immediately test if from the browser, without needing to issue a redeployment operation!

First off, let's say hello. I use the path variable here to to specify my name:

http://localhost:7001/wls-rs-demo/resources/TestResource/hello/steve



Then I'll say goodbye, this time using a query parameter to specify my name:

http://localhost:7001/wls-rs-demo/resources/TestResource/bye?name=steve



And that's all there is to getting a basic JAX-RS resource up and running on WebLogic Server, developed and deployed in next to no time using NetBeans 7.0.

Installing NetBeans 6.9 Fails when XCode is Running

I've been trying to install the NetBeans 6.9 official release (netbeans-6.9-ml-java-macosx.dmg) but it kept on failing during the "Preparing Installation" phase.  No detailed errors were shown other than a generic statement to contact my software vendor.

Turned out, at least on my MacBook  Pro, that the cause seemed to be that XCode was running at the same time.  As soon as I quit from XCode and ran the NetBeans installer from the same installation package, it worked without any problems and installed NetBeans successfully.

Don't know if this is isolated to NetBeans or more generally to the installer technology used on the Mac, but it seems that there was some contention with Xcode, which resulted in the installer not working.