Tuesday, November 10, 2015

Making HTML readonly Attribute Look Like Disabled

A quick entry in case anybody else runs into this scenario. I have a form with some text boxes which need to display as disabled, but the values aren't being submitted with the form. As it turns out, this is native behavior for the 'disabled' attribute.

The workaround is to use the 'readonly' attribute instead, but the problem with that is it doesn't render with a grayed out background. After fiddling for a while I came up with the following script:

    dojo.query("[readonly]").forEach(function(node, index, arr){   
 dojo.attr(node.parentNode,"style", "background-color: #efefef !important");   

Maybe someone else will find this useful.

Thursday, April 30, 2015

Adding a Log4j Console to a Web Application

There's a popular open source jsp that allows changing the log4j levels for a web application called log4jAdmin.jsp that I've been wanting to use for troubleshooting, but using it poses a problem. Typically, deployable artifacts are built by an automated process and are not altered as they make their way through the different environments (development/integration/quality assurance/production). I definitely don't want a log4j administration console finding its way into a production environment as this would allow end users to access it.

So the ideal situation would be to add the jsp to the application after it has been deployed. I could have the system administrators add the file to the WebSphere installedApps directory, but this isn't recommended (and they would likely not agree to do this anyways).

A proper alternative is to use WebSphere's deployment process. Instead of updating an application using the default option, look further below on the page:

The contents of the zip should mirror the exploded folder structure in installedApps. In this case the zip contains a single JSP:

Any number of files can be injected into a deployed application using this technique, but in this particular instance I use it to manage Log4j log levels.

Thursday, February 26, 2015

Error Running

I've been making extensive use of as part of scripted WebSphere application installs to virtual machines, and today a script which I had written a long time ago started to throw the following error: ADMA0043E: /tmp/app9215861615159415312.ear does not exist for installation.

I didn't find any conclusive solution to the error on the web although some suggested there was a mismatch in the location of the temp folder. I changed the websphere variable (Environment > Websphere variables) from




Restarted the server and the problem went away. I have no idea why this worked before, but I guess it's fixed now.