Find the article here.

I’m making a move today – away from this blog hosted on the WordPress.com domain to a different domain. I’ll be writing on the new site about the change and some of the tools and workflows that prompted the change (if not just for personal branding). In the meantime, I invite you to visit or subscribe to my new blog at:

ChadThompson.me

I’ll be talking about many of the same things – Oracle technologies, ADF, WebCenter and the occasional thing I like. I hope you’ll drop by!

NOTE: In the meantime, I’ll be leaving the content that was posted to this blog here, but have moved the content that is here to the new blog as well.

What is missing, however, is an easy way of saving the various links that you might get through e-mail or other web pages that you might just want to add to your Instapaper queue directly rather than opening a link, clicking a bookmark, etc. Fortunately, it’s pretty straightforward to roll your own OS X Service to do just that. Let’s take a look at how to create a simple service using OS X’s Automator and a dash of Perl.

Creating A Service With Automator

Creating a service with Automator is simple: when you open automator, simply choose “Service” as a new document type – Automator will make this service available system-wide. After you create one or two services, you’ll see that Automator is a great tool for customizing your OS X workflows.

Specifying Service Input

OS X Services also allow you to specify a specific context for a service – in our case, we want to have the abilty to have the system recognize a URL for submitting to Instapaper; OS X can determine that a string of text (or a link) is a valid URL and will only display our service if our selection is a URL, and not a simple text string.

Passing the URL to a Script

Another feature provided by Automator is the abilty to embed a Shell Script (either a traditional UNIX shell such as csh, bash, or even scripts written using perl, python or ruby). Here’s an example of a shell script added to an Automator workflow – in this case, a perl script that takes our selected URL as input (note the “Pass Input As Arguments” selection in the upper right hand corner), assembles a URL to submit to the [Instapaper Simple API][ipaperbasicapi] and submits to the service. The API will return more information if you want a more complex workflow – but in this demonstration we’ll simply submit our URL to Instapaper.

(You can search for the services provided by both OS X as well as application services that have been registered with the system in the “library” search.)

You’ll note that through the somewhat unnecessary use of ‘my’ variables that this script could be simple, or quite complex – a Perl script will be able to use any libraries that are availble to you systemwide if you have any CPAN libraries installed on your system.

Noting Success or Failure With Growl

To finish this service, we’ll also add a simple Growl notification that will notify the user that the service has run successfully. Simply add the Growl notifcation service to the automator workflow:

The notification in this case is also simple: merely a notification that the script has run. A more advanced workflow could also take actions based on the Instapaper API.

The service will now appear wherever OS X recongnizes a URL – in the case that I’m attempting to solve, I’d like to send links sent to me by e-mail to my Instapaper queue.

The article will then be added to your Instapaper queue for reading later – like the Instapaper client for iPhone:

This simple example demonstrates how easy (and quick!) it can be to customize your OS X system using Automator and shell scripting – once you create a few services you’ll find system-wide services easy to add to your personal workflows.

UPDATE:  Here’s the text of the perl block I used to create the service:

use LWP::UserAgent;
use HTTP::Request;
## Assemble the URL to submit to Instapaper
my $username='<username>';
my $password='<password>';
my $instapaper_api = 'https://www.instapaper.com/api/add';

my $URL = $instapaper_api."?username=".$username."&password=".$password."&url=".$ARGV[0];
my $agent = LWP::UserAgent->new(env_proxy=>1, keep_alive=>1, timeout=>30);
my $header = HTTP::Request->new(GET=>$URL);
my $request = HTTP::Request->new('GET', $URL, $header);
my $response = $agent->request($request);

I’m currently working on a full example of creating ADF Faces login pages using JDeveloper 11.1.2.2, but there are two key items that will help you develop your own ADF Faces login pages.

First, the section of the documentation titled ‘before you begin’ instructs you to import a few JAR files so that your ManagedBean methods can access WebLogic APIs for user authentication. The instructions here are incorrect for (at least) JDeveloper 11.1.2.2.

Instead, you’ll want to import the “WebLogic Remote Client” library into your JDeveloper project. Access the project libraries by selecting Application ->; Project Properties. In the library dialog, select “Add Library”:

In the “Add Library” dialog – choose the WebLogic Remote Client library:

This will allow you to import the proper libraries for your Managed Bean.

(Reference: forum posts by Frank Nimphius. Here’s one example of many.)

Second, you’ll want to update the login method to use the URLCallbackHandler rather than the deprecated SimpleCallbackHandler. Here’s an example method:


public String performLogin(){

_logger.info(“Login Requested For User: ” + _username);

String un = _username;
byte[] pw = _password.getBytes();
FacesContext ctx = FacesContext.getCurrentInstance();
HttpServletRequest request =
(HttpServletRequest)ctx.getExternalContext().getRequest();
CallbackHandler handler = new URLCallbackHandler(un, pw);
try {
Subject mySubject = Authentication.login(handler);

ServletAuthentication.runAs(mySubject, request);
ServletAuthentication.generateNewSessionID(request);
String loginUrl = “/adfAuthentication?success_url=/faces” +
ctx.getViewRoot().getViewId();
HttpServletResponse response =
(HttpServletResponse)ctx.getExternalContext().getResponse();
sendForward(request, response, loginUrl);
} catch (FailedLoginException fle) {
FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_ERROR,
“Incorrect Username or Password”,
“An incorrect Username or Password” +
” was specified”);
ctx.addMessage(null, msg);
} catch (LoginException le) {
reportUnexpectedLoginError(“LoginException”, le);
}
return null;

}

Reference: Andrejus Baranovskis’s Things You Must Know About ADF Faces Login Page.

You can see a working copy of this on GitHub, with the caveat (at this writing) that I haven’t fully verified everything in source control. Please let me know if you have problems.

Update: Frank Nimphius pointed me (see example) to a complete example created for 11.1.2.1 available here :

http://www.oracle.com/technetwork/issue-archive/2012/12-jan/o12adf-1364748.html

Viewlet:  Installling JDeveloper on OS X

The viewlet is a good overview of how JDeveloper expects certain JAR files from the Apple JDK and how to create symbolic links to allow JDeveloper to load expected JAR files.  (I expect this issue to vanish as the Apple JDK is phased out in favor of the Oracle JDK once JDeveloper makes the move to Java 7.)

I am going to note a nitpicky criticism  and a helpful tip:

Nitpicky criticism:  The tutorial describes the process for enabling the root user on OS X, which is both not necessary and also discouraged by Apple for security reasons.  You can accomplish the same results (creating symbolic links in files owned by the System user) by invoking the sudo command as an Administrative user.   To do this, you’ll open a terminal window as an administrative user (likely your normal login) and issue the symbolic link command using sudo, something like

sudo ln -s [real file name] [link to create]

This will create the link (after you are prompted to enter your administrative password) without enabling the root user.

Helpful Tip:  I’ve always found it useful to create an alias to the JDeveloper executable and placing that alias in the OS X “Applications” folder.  With an alias in the Applications folder you can launch JDeveloper from LaunchPad or your favorite keyboard assistant (I’m a devoted Alfred user) without having to modify system properties.  I tend to need a couple different versions of JDeveloper to support client projects, so I’ve created symbolic links from the various JDeveloper versions to the Applications folder, which allows me to access the version of JDeveloper that I need for various projects through a few simple keystrokes:

You can read the original post here.

The basic problem the original poster is having:  confusing “JSR 286″ (or even “JSR 168″) portlet development with Java Server Faces (JSF) development.  (You can read about some basic JSR 168 portlet development here.)  The important difference:  knowing what is controlling the application flow of your portlet.  In the JDeveloper way of developing standards-based portlets, the main point of entry and navigation is through JSP pages and associated action.  If you are creating a Java Server Faces application, the main point of entry and navigation is through the FacesServlet.  The navigation files (faces-config.xml) is a configuration of the FacesServlet.

Thus, it’s important that your JSF-developed portlet is controlled by FacesServlet, otherwise portlet navigation won’t work.  Fortunately, Oracle provides a few handy tools to help you create portlets from JSF applications using the “JSF Portlet Bridge”.     (The concept is also proposed to the Java Community Process through JSR 301 - so Apache MyFaces and others implements some of the same techniques.)

So in response to the forum post, I’m going to walk through a JDeveloper-based method for transforming a JSF Application into a portlet.

First, let’s take a look at a simple JSF application:  one that simply allows a user to navigate back and forth between pages in the application:

A Simple JSF Application

The design of the pages is fairly simple as well:  just a button that allows you to navigate (using an Application Action) to a second page.

The first page of the simple JSF Application

The second page:

Page Two of the Simple JSF Application

The application is controlled by the faces-config.xml file that all JSF applications use to configure the FacesServlet.  To transform this application into a WebCenter deployable portlet, we’ll use JDeveloper to create the needed portlet files for us.

1)  Transform the faces-config.xml file into an ADF Task Flow

Strictly speaking, we could also choose to create portlet entries from JSF pages, but ADF Task Flows offer us more flexibility in deployment.  If you were designing your portlet from scratch, you might choose to start with ADF from the beginning.  In our case, however, we can right-click on the faces-config.xml file within JDeveloper to Generate an ADF Task Flow.

Generate an ADF Task Flow From faces-config.xml

You’ll be prompted by a wizard to name the task flow, etc.  In this example, I’ve named the Task Flow “portlet-nav-taskflow”.  (Subtracting points for creativity…)

Once the task flow is created, right-click your new taskflow to create a Portlet Entry – what we need to insert into “portlet.xml” that will tell a portlet container how to handle our application.

Create A Portlet Entry From An ADF Task Flow

… and that’s it!  We can now package the application for deployment on a Portlet Container (perhaps a WebCenter portlet producer), but to test deployment locally, we can right click on the portlet.xml file and select “run”.  This will deploy our new portlet to a local container – particularly helpful if we’re developing the portlet side-by-side with a WebCenter Portal application.  If the portlet runs successfully, you’re presented with a test page:

WSRP Test Page For Our Deployed Portlet

In summary, the challenge in creating new portlets is to keep in mind the technology that you are using to create the portlet – it can vary, but it does help to be consistent.

Download the source (and JDeveloper project) for this example.