Thursday, July 29, 2010

<c:url> DANGER !

<c:url value="/foobar.jspx#fragment">
<c:param name="p1" value="v1" />
<c:param name="p2" value="v2" />

fragment is not recognized as fragment and taken as part of path:


JSTL Specification 7.5 for c:url
reffers to old
JSP 1.2 in JSP.2.2.1 "Relative URL Specification"
which refers to old RFC
Elements may use relative URL specifications, called “URI paths” in the Servlet
2.3 specification. These paths are as described in the RFC 2396 specification.
So it becomes very unclear
if the value can contain fragments and/or query.

I vote for YES it can, even if the JSTL would want to advocate NO,
as I developer I would request it.

Tested on Suns jstl-impl-1.2.jar, Tomcat 6.0,
and after decompilation and quick look in the code,
I have strong suggestion

DO NOT USE !!!!!
it is dangerous and combined with lax EL, it can lead to
serious "security troubles" (search CWE, OWASP or others).

I will post fixed reliable version of
ainthek:url when ported from my other libraries.
And it will use IRI (I have not found anything better so far).

OEPE, Eclipse helios & NoSuchMethodError at creating new WLS server

Here are some news from my friend:

Some theory first:
In order to have Oracle WebLogic Server 11gR1 PatchSet 2 (latest) runtime environment in Eclipse helios,
you need to have server adapter in your IDE for that.
We still think the best way to do this is through “Oracle Enterprise Pack for Eclipse” where this adapter is included.

From this pack you only need this software:
Oracle WebLogic Server Tools
Oracle Common Tools (dependency)

You can do that by adding another update URL in Eclipse:
“Oracle Enterprise Pack for Eclipse -”

Oracle web site ( )
contains this note:
“Note: Be aware that Eclipse 3.6 Helios is not final and this tech preview is based on the M6 milestone release of Eclipse 3.6.”

True. When you download latest eclipse it’s M7 milestone (from April 30, 2010).
Milestone M6 was API Freeze and latest M7 is Feature Freeze, Focus on Performance and Polish.

IMHO M7 is final 3.6 milestone.

Now to the point: when you try to add awesome WLS in latest Eclipse you will get nice server error

From Error log:

at org.eclipse.wst.server.ui.internal.wizard.TaskWizard.performFinish(
at org.eclipse.jface.wizard.WizardDialog.finishPressed(
at org.eclipse.jface.wizard.WizardDialog.buttonPressed(
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(
at org.eclipse.swt.widgets.TypedListener.handleEvent(
at org.eclipse.swt.widgets.EventTable.sendEvent(
at org.eclipse.swt.widgets.Widget.sendEvent(
at org.eclipse.swt.widgets.Display.runDeferredEvents(
at org.eclipse.swt.widgets.Display.readAndDispatch(
at org.eclipse.jface.window.Window.runEventLoop(
at org.eclipse.jface.action.Action.runWithEvent(
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(
at org.eclipse.jface.action.ActionContributionItem.access$2(
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(
at org.eclipse.swt.widgets.EventTable.sendEvent(
at org.eclipse.swt.widgets.Widget.sendEvent(
at org.eclipse.swt.widgets.Display.runDeferredEvents(
at org.eclipse.swt.widgets.Display.readAndDispatch(
at org.eclipse.ui.internal.Workbench.runEventLoop(
at org.eclipse.ui.internal.Workbench.runUI(
at org.eclipse.ui.internal.Workbench.access$4(
at org.eclipse.ui.internal.Workbench$
at org.eclipse.core.databinding.observable.Realm.runWithDefault(
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(
at org.eclipse.ui.internal.ide.application.IDEApplication.start(
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(
at org.eclipse.equinox.launcher.Main.basicRun(
Caused by: java.lang.NoSuchMethodError: org.eclipse.wst.server.core.internal.UpdateServerJob.<init>(Lorg/eclipse/wst/server/core/IServer;)V
at org.eclipse.wst.server.core.internal.ResourceManager.fireServerEvent(
at org.eclipse.wst.server.core.internal.ResourceManager.registerServer(
at org.eclipse.wst.server.core.internal.ResourceManager.addServer(
at org.eclipse.wst.server.core.internal.Server.saveToMetadata(
at org.eclipse.wst.server.core.internal.Base.doSave(
at org.eclipse.wst.server.core.internal.Server.doSave(
at org.eclipse.wst.server.ui.internal.wizard.WizardTaskUtil.tempSaveServer(
at org.eclipse.wst.server.ui.internal.wizard.WizardTaskUtil$4.performFinish(
at org.eclipse.wst.server.ui.internal.wizard.TaskWizard.executeTask(
at org.eclipse.wst.server.ui.internal.wizard.TaskWizard$
at org.eclipse.jface.operation.ModalContext$

That is because underlying eclipse implementation had changed.
You see that signature?

It’s initialize method from UpdateServerJob class that returns void and takes IServer as an argument.

When you decompile latest M7 UpdateServerJob.class there really is no such method. It has only constructor that takes IServer array!

public UpdateServerJob(IServer servers2[])
servers = servers2;

And WlsUiPlugin$1 calls it with

public void serverAdded(IServer server)
if(WebLogicServerUtil.isWebLogicServer(server) && server.getServerState() == 0)
UpdateServerJob job = new UpdateServerJob(server);

Unfortunately that works for M6 version only. At that time UpdateServerJob constructor looked like this:
public UpdateServerJob(IServer server)
super(NLS.bind(Messages.jobUpdateServer, server.getName()), server);

Oracle developers, I think it is really a time to update your OEPE plugin because M7 is out there for 3 months now.
You have to change all calls of that constructor:
UpdateServerJob job = new UpdateServerJob(server);
UpdateServerJob job = new UpdateServerJob(new IServer[]{server});

Simple like that

This construction needs to be changed also in these files: -> package -> -> package -> WlsUiPlugin$ -> package ->

Or you can give us OEPE plugin sources and we will change it ourselves 


Decompiler info:
// Decompiled by Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov.
// Jad home page:
// Decompiler options: packimports(3)

Bundled M6 (oepe-helios-all-in-one) eclipse plugin jar: org.eclipse.wst.server.core_1.1.202.v20100315.jar
Latest M7 eclipse plugin jar: org.eclipse.wst.server.core_1.1.202.v20100518.jar

OL snipped (valid HTML from your JSP components, PLEASE !)

many component authors are lazy to read HTML specification,
and lazy to write extra if in the code as well.
One of the examples is title tag absence in code generated by
myfaces components (see older posts).
Proposal for correct list rendering:

<c:if test="${!empty files}">

<c:forEach var="file" items="${files}">
<li><c:out value="${}"/></li>

The point is that OL without child LI is nonsence from HTML point of view.
Later we will talk about what element
to generate instead for empty list
and if null and empty is the same (EL does not care of course).

Wednesday, July 28, 2010

Fix For WST (Web Standard Toolkit) template

This is just sick ;-)

<?xml version="1.0" encoding="UTF-8" ?>
<jsp:root xmlns:jsp="" version="2.0">
< language="java"
contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" />

<![CDATA[ <?xml version="1.0" encoding="UTF-8" ?> ]]>

<![CDATA[ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" ""> ]]>

<html xmlns="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Insert title here</title>


My proposed version is:

<?xml version="1.0" encoding="UTF-8" ?>
<jsp:root xmlns:jsp="" version="2.0">
< language="java"
contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" />
<jsp:output omit-xml-declaration="no" doctype-root-element="html"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN" />
<html xmlns="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Insert title here</title>


Do you think ther is a reason or just ignorance ?
Fist original WST code is buggy, outputed "XHTML" will have whitespaces before ?xml and whitespaces before doctype. (Authors, please read at least JSP.1.3.8 White Space) if not XML and HTML specs ;-))


somewhere from

Content-Type: text/html;charset=UTF-8
<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
<html xmlns:xhtml="">
<!-- *** powered by betterFORM, &copy; 2010 *** -->

Bug or feature ?

Monday, July 26, 2010

Oracle Web Tier Tools (OEPE)

Part of Oracle Enterprise Pack for Eclipse (OEPE)

I have commented on encoding issues in JDeveloper and today I have reached the same point in the Eclipse-OEPE environment.

First the good news is that OEPE let's you choose form many templates combining language (html,xhtml) of source markup, doctypes and final output doctype in
File/New/JSP Page/(Use JSP Template) and configure the templates the easy way
Window/Preferences/Web/JSP Files/Templates.

My chosen one the "New JavaServer Faces (JSF) Page (xhtml)"
will produce this:

<?xml version="1.0" encoding="${encoding}" ?>
<%@ page language="java" contentType="text/html; charset=${encoding}"
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="" xmlns:f="" xmlns:h="">
<meta http-equiv="Content-Type" content="text/html; charset=${encoding}" />
<title>Insert title here</title>

What is the ${encoding} in this template ?

In per project scope it is
Project/Properties(ALT+Enter)/Resource/Text file encoding.
Select UTF-8 of course.

Next step is to customize the predefined templates to more resonable markup
but at least,
you have an easy chance to do so.
In jDeveloper I'm quite missing (or did not find) this EASY WAY.

not every template uses the ${encoding} param,
for example this one:
"JSP with xhtml markup, xml style syntax and default view setup"
has ISO-8859-1 (windows-1252 ?) hardcoded ;-(

Thursday, July 22, 2010

Trinidad JavaScript

Trinidad JavaScript

In short ?
Bad,obsolete,space consuming,sub-optimal .... practices,
in the order discovered.....
judged by my average JS knowledge....

  1. everything in global scope
  2. using new Array()
  3. var; var; var;
  4. Browser detection (sniffing)

  5. Useless chars eg: typeof (elem) == "string"
  6. ... this makes no sence to continue.....
TrUIUtils.createCallback = function(thisObj, func) {
 // create a function that sets up "this" and delegates all of the parameters
 // to the passed in function
 var proxyFunction = new Function(var f=arguments.callee; return f._func.apply(f._owner, arguments);");

 // attach ourselves as "this" to the created function
 proxyFunction._owner = thisObj;

 // attach function to delegate to
 proxyFunction._func = func;

 return proxyFunction;
TrUIUtils._cssToJs = function(prop) {
 var jsProp = '';
 var upperNext = false;
 for (var c = 0; c < prop.length; c++) {
  if (prop.charAt(c) == '-') {
   upperNext = true;

  if (upperNext) {
   jsProp += prop.charAt(c).toUpperCase();
  else {
   jsProp += prop.charAt(c);

  upperNext = false;
 return jsProp;
I had to stop after while... ... since this could be book of "JavaScript antisamples". I have no idea about the libs origin, they mention IE 4 versions, however Trinidad claim support to 6+, I belive a lot of code is "ported" from some other languages with little JS knowledge or care, or comes from aged libs written in the dark and deep web history. I have to quote Mr.D:
There are no good texts on JavaScript programming. Most of the people on the web who are producing JavaScript programs learned it by copying really bad examples from bad books, bad websites, and bad tools. We have an amazingly good community of JavaScript programmers here, but still we can benefit from better practice of style.

META and Content-Type and Wisdom of JDeveloper

g define:wizard (first hit)
someone who is dazzlingly skilled in any field

Ok then this already mentioned
"JDeveloper New JSF Page" wizard is not skilled in HTML .

In HTML which the wizard is claiming to produce (and twice !, by duplicated DOCTYPE ;-)
the META tag should not be closed (NET-enabling start-tag requires SHORTTAG YES).

However in .jspx (which is XML) you need to close it.

Simple workaround, that should work:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

BTW: why this meta is not part of trh:head rendering and must be specified manually in jspx markup ?

How many additional steps I have to do to produce valid HTML with these RAD tools ?

HeadRenderer (org.apache.myfaces.trinidadinternal.renderkit.core.xhtml)

This is snipped from trinidad-1.2.12 source code.

String title = getTitle(bean);

if (title != null)

rw.startElement("title", null);
rw.writeText(title, null);

// Write the META generator tag

First is very wrong from HTML validity point of view:
Validation Error: end tag for "HEAD" which is not finished
....For instance, in HTML the head element must contain a title child element...

Second which is unconditional write of

<meta name="generator" content="Apache MyFaces Trinidad">

is at least "unwanted" from "security" point of view.
However trinidad JSF style is so obvious that underlying technology
does not have to bue guessed the hard - "metadata generator way".

Of course, this can be fixed by implementing custom renderer, but...
wasn't trinidad designed to save my time in "usual situations" (at least ) ?

Please change the "if order" and make possible to turn off META generator tag.

Double DOCTYPE, jsp:output, trh:html (trinidad) and JDeveloper wizards

This the result when you click "new JSF Page" "wizard"
and use "*.jspx" and "Render in mobile device" option.

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="" version="2.1"
<jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/>
< contentType="text/html;charset=UTF-8"/>

This however has one major problem,
produces invalid HTML markup with DOUBLED DOCTYPE.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
<html dir="ltr" lang="en-US">

This is because one is produced by
and another by
thr:html + org.apache.myfaces.trinidad.core renderkit
(which is default for JDeveloper and "ADF Mobile")
It seems just like coincidence that both are the same (read more...)

As far as I hnow, the thr:html does not have "none" option for "Mode"
So the best is to remove all doctype-* from jsp:output.
Actually if reading the JSP spec for omit-xml-declaration, you can remove whole
jsp:output because:
The default value for a JSP document that has a jsp:root element is “yes”.

To bring some more info: the actual DOCTYPES rendere for MSIE 7.0 with
various swiches are:

default (damned again ?):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

strict (this should be default in 2010 !!!):

The letters are modes for specific browsers taken from:

Wednesday, July 21, 2010

JDeveloper 11g and encodings (Damned Default)

After fresh instalation JDeveloper will produce new JSPX pages that may look like this.

<?xml version='1.0' encoding='windows-1252'?>
< contentType="text/html;charset=windows-1252"/>

This 1252 seems to me like "unwanted legacy".

Use to select an encoding value. The default is CP1252.
Once you have selected a value, all new files will be created with the new encoding, and the new encoding will be used to open and save files without encoding tags.
Note that XML files and JSP 2.0 documents (XML compliant files)
must include an appropriate XML encoding declaration on a per-file basis.
For details refer to the W3C XML specification.
You can expand the encodings
in this list by appending new
encoding definitions to the encodings.xml file, found in the jdev/bin directory. This XML file contains a list of mappings from Sun JDK to IANA encoding names.
Note that files already open in JDeveloper will not be opened with the new encoding. To change the encoding used to read open files, close the files and reopen them after changing the encoding value here. Also note that files with encoding tags will always be opened and saved using the specified tags, and not JDeveloper's encoding.

This is tricky, half true, or buggy ...
I have tried to make a new page in an existing project and again the 1252.
Then I have tried new page in different project and UTF-8.

There are two more "Character Encoding" (at least) in Project Preferences.
XML.encoding and JSP.charset in JSF pages seems to be controlled by
Project Preferences/Compiler/JSP.

So If you have already created projects change those, and
manualy fix text in files and if you have non ascii markup in the text, resave all files as UTF-8 as well ;-))

Damned Defaults

Under this "Label" I will try to mark
default settings,
configurations and so called
"convenience APIs"

that I personally consider

or in best case

ADF Rich client Demo - incomplete HTML, user agent detection


Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/, application/, application/msword, application/x-ms-application, application/x-ms-xbap, application/, application/xaml+xml, */*
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: xxxxxxxxxxxxx

Produces this incomplete markup:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" ""><html dir="ltr" lang="en-US"><head id="d1__xc_h"><title>ADF Faces Rich Client Demos</title><meta name="generator" content="Apache MyFaces Trinidad"><link rel="stylesheet" charset="UTF-8" type="text/css" href="/adf-richclient-demo/adf/styles/cache/blafplus-rich-desktop-bbz27h-en-ltr-hc-lf-cmp.css"><link rel="icon" type="image/png" href="/adf-richclient-demo/images/favicon.png"><link rel="apple-touch-icon" href="/adf-richclient-demo/images/touchicon.png"><script id="meta:metas1" type="text/javascript" src="/adf-richclient-demo/jsLibs/About.js"></script></head><body id="d1" onload="_checkLoadNoPPR()"><script type="text/javascript">var _AdfWindowOpenError='A popup window blocker has been detected in your browser. Popup blockers interfere with the operation of this application. Please disable your popup blocker or allow popups from this site.';</script><script type="text/javascript" src="/adf-richclient-demo/adf/jsLibs/Common1_2_12_1.js"></script><a name="top"></a><noscript>This page uses JavaScript and requires a JavaScript enabled browser.Your browser is not JavaScript enabled.</noscript><div id="tmplt"><form id="tmplt:ptf1" name="tmplt:ptf1" style="margin:0px" method="POST" onkeypress="return _submitOnEnter(event,'tmplt:ptf1');

Dig deeper, try to find docs....

ADF Rich Client Demo does not work in MSIE 7.0 with Native XHR disabled
Is this suposed to work in MSIE 7.0 ? I hope so but not with
Native HMLHttp request disabled in MSIE configuration ;-);
this.headers= new Object();
this.xmlhttp= new XMLHttpRequest();}

Any docs on this please ?

JSF, Trinidad, Oracle ADF Rich Client

I will start posting unsorted opinions about ADF in the next days
just to collect findings, subjective unproved hypothesis and mental shocks I'm ready to experience during my "late adoption".....

From JSF Specification:

Solving Practical Problems of the Web
JSF’s core architecture is designed to be independent of specific protocols and markup.
However it is also aimed directly at solving many of the common problems encountered
when writing applications for HTML clients that communicate via HTTP to a Java
application server that supports servlets and JavaServer Pages (JSP) based applications.

Or from ADF dev guide:

JavaServer Faces for Quick Learners
JSF 1.2 was chosen as the view layer of choice in Fusion web application development of Oracle
JDeveloper 11g. JSF is a Java EE standard since 2004 and in its current version 1.2 is part of the
Java EE 5 platform. JSF is designed to simplify web application development and changes the
programming model for building web pages from HTML markup development to the assembly
of reusable UI components that are declaratively linked to their data model and server-side event

But does this gives us mandate to produce

Bad html (suboptimal, not semantic at all, or event invalid ?)
Bad css (obtrusive, uneffective,....)
Bad JavaScript (obtrusive, large, old fassioned ?)
and ignore most of URI and HTTP principles ?

and i'm not commenting on backend Java code yet ;-(

Wednesday, July 14, 2010

Comparing window references

or "Evil twins" === vs. == in cross-windows communication

Comparing window references or "Evil twins" === vs. == in cross-windows communication.

As you may have read in meany sources
=== is preffered over ==
Mr.D calls the == variant The evil twin, but... MSIE (again) may surprise you:

Lets have two windows A and B

now in A lets call this wierd construction:

// in window A, "ask window B to create object"
new B.Object1();

// code inside window B looks like this
function Object1(p1,p2,p3)
//what DOES window mean:,
// a) is it wnd from "new wnd.Object1()" or
// b) is it callers window context ?
// see test case for answer ;-)
return this._ctx;

This construct will work
in all browsers
in all types of windows (iFrame,, modal, modeless dialogs)
but and WILL NOT WORK in MSIE modelessDialog and
and the call will end up with "Invalid procedure call or argument".

However in those working in explorer (iframe and tweaked modal dialog)
let's try to compare window references:

// remote window is opener or parent or self
// depending on the type of "popup" method used

var remote=new remoteWnd.Object1();
var remoteCtx=remote.getCtx();
asrt(remoteCtx===remoteWnd,"window refs broken ?");
return remoteCtx.location.href;

All browsers (Safari, FF, Opera, Chrome) pass this test for
all supported types of cross-referenced windows (iFrame,,showModalDialog)

MSIE (6,7,8) fails to compare window references with ===


// does not work
// seems to work but what is actually compared ? (TODO: see specs.)
// works but means something different right ?

Of course there is more XB magic in cross-window communication
(MSIE and Safari identified as trouble makers)
and I may return with more notes....