WLS: Nonsensical error message on web services HTTPS policy enforcement

Mostly a post to document something I keep on forgetting, hopefully useful to someone else.

Under WebLogic Server 10.3.1 (and maybe present in earlier versions of WLS?), on testing a deployed web service I occasionally get this HTTP response from WLS:

Error 500--Internal Server Error

javax.servlet.ServletException: unable to send error:
at weblogic.wsee.jaxws.HttpServletAdapter.sendAccessError(HttpServletAdapter.java:240)
at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:195)
at weblogic.wsee.jaxws.JAXWSServlet.doPost(JAXWSServlet.java:297)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
.. snip ..
Caused by: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: {http://www.w3.org/2003/05/soap-envelope}Client.Access is not a standard Code value
at com.sun.xml.internal.messaging.saaj.soap.ver1_2.Fault1_2Impl.checkIfStandardFaultCode(Fault1_2Impl.java:134)
at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:126)
at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:91)
.. snip ..

Note the message half way down the stack trace "Caused by". In turn in the WLS logs I receive the following error:

22/07/2009 12:15:46 PM com.sun.xml.internal.messaging.saaj.soap.ver1_2.Fault1_2Impl checkIfStandardFaultCode
SEVERE: SAAJ0435: {http://www.w3.org/2003/05/soap-envelope}Client.Access is not a standard Code value
<22/07/2009 12:15:46 PM WST>    <[ServletContext@23322757[app:MyWebServices module:MyWebServices path:/MyWebServices spec-version:2.5], request: weblogic.servlet.internal.ServletRequestImpl@61061d[
POST /MyWebServices/My.Service HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/soap+xml;charset=UTF-8;action="http://acme.com/com/my.service"
User-Agent: Jakarta Commons-HttpClient/3.1
Content-Length: 4948

]] Root cause of ServletException.
com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: {http://www.w3.org/2003/05/soap-envelope}Client.Access is not a standard Code value
at com.sun.xml.internal.messaging.saaj.soap.ver1_2.Fault1_2Impl.checkIfStandardFaultCode(Fault1_2Impl.java:134)
at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:126)
at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:91)
.. snip ..

You can see between the HTTP error and the WLS logs the same message:

com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: {http://www.w3.org/2003/05/soap-envelope}Client.Access is not a standard Code value

...followed by the SAAJ classes complaining about the SOAP Fault in the stack trace. In guessing what's occurring, the web service or WLS has thrown an error, but in transferring that error to a SOAP Fault response, the SAAJ classes don't think the SOAP fault itself is valid. In other words the real error is obscured because the error mechanism itself is bust.

So ignoring the error mechanism failure, what had I done wrong? After a lot of head scratching, I discovered my mistake.

I'd originally built a client to access my web service at the following URL:

http://MyWlsServer:7001/MyWebServices/My.Service

Subsequently I'd changed my web service to implement SSL via the WLS policy Wssp1.2-2007-Https.xml. To successfully access the web service thereafter I needed to access it at this new URL:

(Note the https delineator and port 7003, my configured WLS SSL port)

https://MyWlsServer:7003/MyWebServices/My.Service

...but in forgetting to change my client to the new URL, the error as above is thrown. Presumably the real error message would be "No such service" or "Service requires HTTPS" or "Chris, you've made another mistake!"

For reference I've tested this the other way around, where the web service isn't enforcing the WLS HTTPS policy, but the client access the https URL, and it works fine. This makes sense as the WLS policy is an enforcement of HTTPS traffic for that specific web service, not implementing HTTPS in general for WLS, that's left up to WLS which we've already preconfigured for WLS traffic. As such we can still use HTTPS for our web service even if the web service isn't enforcing HTTPS.

In addition note because of the generic error message returned here, readers should be careful to ascertain if what I describe in this post actually applies in their case. There's also the good chance this error will be for totally different reasons in different implementations of WLS.

And for the record I'll get around to logging an SR with Oracle Support soon. Anybody want to write the simple test case and steps to reproduce for me please? ;-)

JDev 11gR1: the most obscure new IDE feature

Each new release of JDeveloper brings an explosion of blog posts from the excited JDeveloper advocates and Oracle staff. Within a week or so all the major new features are identified and explained, leaving slow typers like me wondering what to cover to get readers excited.

So for the latest JDeveloper 11gR1 release, I've taken the opportunity to explore for the most obscure feature, the feature hardly anybody is likely to see, or possibly even care about until they discover it.

And today I think I found it. Small celebratory "woohoo!" on my part.

Take a look at this screenshot of the source code of a standard ADF Faces RC page in all its XML glory:


In the next picture I've deleted the af:inputText tag. Besides the removal of the tag, can you see the subtle change in the source code editor? Believe me you'll have to look really hard:


Spotted it? Let me point it out:


Can you see the little pastel pink colour in the new thin left margin that runs down the page? If you float the mouse over the colour you get:


...a little popup that shows the code you deleted. The new margin feature shows visually the addition and removal of code as tied to the IDE's undo history. If you right click on the small colour segment you get a context menu that lets you work with the change:


As promised, I believe this to be the most obscure new feature in JDev11gR1. I set a friendly challenge to readers to find an even smaller obscure new feature in the latest release.

Increasing/decreasing JDev 11g ADF Faces RC page font size at runtime

A feature seen on some web sites is buttons to increase and decrease the text font size. While most browsers supply this functionality by default (eg. In Firefox you can press Ctrl plus or minus), giving web page buttons to do this can assist less computer literate users who may not now about the browser's inbuilt functions.

The solution requires a javascript routine. A quick Google on "javascript increase fontsize" returns a number of useful hits including this one by White Hat Web Design.

White Hat's code is a fairly common example available on the internet for doing just this in a standard web page.

Providing this functionality in JDeveloper 11g's ADF Faces RC requires a bit of tweaking. The following describes the bits of code you'll need.

Javascript

The following code takes the White Hat javascript and tweaks it:

var fontMin=10;
var fontMax=36;
function increaseFontSize(event) {
   event.cancel();
   var p = document.getElementsByTagName('span'); // here
   for(i=0; i < p.length; i++) {
      if(p[i].style.fontSize) {
         var s = parseInt(p[i].style.fontSize.replace('px',''));
      } else {
         var s = 14;
      }
      if(s!=fontMax) {
         s += 2;
      }
      p[i].style.fontSize = s+'px';
   }
}

function decreaseFontSize(event) {
   event.cancel();
   var p = document.getElementsByTagName('span'); // and here
   for(i=0; i < p.length;i++) {
      if(p[i].style.fontSize) {
         var s = parseInt(p[i].style.fontSize.replace('px',''));
      } else {
         var s = 12;
      }
      if(s!=fontMin) {
         s -= 2;
      }
      p[i].style.fontSize = s+'px';
   }   
}

First tweaks to the original code, note that each method now takes an event object, and then cancels the event on executing the javascript. While I'm not entirely over the need for this, my understanding is it hooks into the ADF Faces RC javascript engine and we'll see a bit further down in this post the usage of the clientListener tags to invoke this javascript. (Some more documentation on the ADF javascript engine would be appreciated Oracle – hint hint).

Secondly note the two commented lines. The original code searched for <p> tags, while in ADF Faces RC pages we need to search for <span> tags, as this is where ADF Faces RC places raw text.

Load the javascript into JSF

In the page we wish to include the javascript we include the following code:

...assuming you stored the above javascript in the ViewController public_html/js subdirectory as fonts.js.

(Alternatively this tag could go into your JSF template so you only need to include it once)

Note that this is in fact a Apache Trinidad component, not ADF Faces RC. As such you also need to change your JSF page's <jsp:root> tag to include the Trinidad HTML tag library as follows:

  xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1" 
  xmlns:f="http://java.sun.com/jsf/core"
  xmlns:h="http://java.sun.com/jsf/html"   
  xmlns:af="http://xmlns.oracle.com/adf/faces/rich"
  xmlns:trh="http://myfaces.apache.org/trinidad/html">

Buttons

Next in order to provide buttons to call the javascript we include the following command controls on our page:

Note the use of the clientListener tag to invoke the javascript functions we defined above.

Near success

At this point if you run your page you should see the fonts scale up and down when you press the relevant commandLink button.

One thing you may notice is that if you have other text based command and go components on the page (eg. <af:commandLink> <goLink>), the text fails to grow or shrink on pressing your new buttons. This occurs because the command and go components are rendered in a HTML < href> tag rather than the <span> tag we coded in our javascript. An easy solution to this is to modify your components as follows:

Original

Fix

As the command control now uses a normal outputText component to render the text, this in turn is rendered as a HTML <span> tag in the end HTML page and will be subject to our javascript routines results.

One other thing you might notice, is in Firefox the font fails to shrink at all. Remember that Firefox has a user preference that stops this from occurring under Tools -> Options -> Content -> Fonts & Colours -> Advanced -> Minimum Font Size, a particularly useful feature on my laptop that runs at 1 sqwillion by 1 sqwillion resolution, where I can't see a d@mned thing.

Oracle ACE Director of the Year

I had the very pleasent surprise at the end of the ODTUG conference this year to be told that I've won Oracle Magazine's Oracle ACE Director of the Year award for 2009. With out a doubt this is an honour and I'm very appreciative to Oracle Corporation and its staff for this award, and especially to those who were kind enough to nominate me.

I was joking with Grant Ronald a few months back that I received my original ACE Director nomination when my first daughter was born, so was looking forward to becoming the grand-poo-bar when my second arrived. Apparently such flippant remarks become reality.

Thanks to everyone who has sent on their congratz via the other media channels including Twitter, LinkedIn, email and more.

I must also give a very special thanks to my "partner" in crime Jenny who gives her generous support and incredible patience in letting me pursue my Oracle activities. Mind you I've kept my side of the bargain and neither of my children yet know what an Oracle database is.