Normally when a web application is deployed to WebSphere, the "exploded" .EAR file resides in a directory similar to
C:\Programs\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\<your computer name here>Node01Cell\<EAR file name here>\<WAR file name here>
Most changes to files underneath this directory structure are reflected in the application after the web application is re-started. However, making changes to web.xml here will not have any effect. Instead, WebSphere stores a copy of web.xml in
C:\Programs\IBM\WebSphere\AppServer\profiles\AppSrv01\config\cells\<your computer name here>Node01Cell\applications\<EAR file name here>\deployments\<context root here>\<WAR file name here>\WEB-INF\web.xml
that it actually heeds. Misleading, eh?
Building Air Castles
Quest for better software, faster
Labels
.net
(1)
*nix
(1)
administration
(1)
Android
(2)
Axis2
(2)
best practice
(5)
big-data
(1)
business-analysis
(1)
code re-use
(1)
continuous-integration
(1)
Cordova-PhoneGap
(1)
database
(2)
defect
(1)
design
(3)
Eclipse
(7)
education
(1)
groovy
(2)
https
(2)
Hudson
(4)
Java
(1)
JAX-RS
(2)
Jersey
(3)
Jetty
(1)
localization
(1)
m2eclipse
(2)
MapForce
(1)
Maven
(12)
MySQL
(1)
Nexus
(4)
notes
(4)
OO
(1)
Oracle
(4)
performance
(1)
Perl
(1)
PL/SQL
(1)
podcast
(1)
PostgreSQL
(1)
requirement
(1)
scripting
(1)
serialization
(1)
shell
(1)
SoapUI
(1)
SQL
(1)
SSH
(2)
stored procedure
(1)
STS
(2)
Subclipse
(1)
Subversion
(3)
TOAD
(3)
Tomcat
(4)
UML
(2)
unit-testing
(2)
WAMP
(1)
WAS
(3)
Windows
(3)
WP8
(2)
WTP
(2)
XML
(4)
XSLT
(1)
Thursday, January 22, 2015
Tuesday, December 2, 2014
WebSphere, ADMA5006E, and java.lang.NullPointerException
After compiling some code with the Oracle JDK,
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
I deployed to WebSphere I got the following error:
ADMA5006E: An error occurred configuring [my application name] in WebSphere Application Server repository: java.lang.NullPointerException
After adjusting my JAVA_HOME to point at the WebSphere Java,
java version "1.6.0"
Java(TM) SE Runtime Environment (build pwa6460_26sr7fp1ifix-20140220_01(SR7 FP1+
IX90136+IX90137))
IBM J9 VM (build 2.6, JRE 1.6.0 Windows 7 amd64-64 Compressed References 2013123
0_180580 (JIT enabled, AOT enabled)
I was able to deploy to WebSphere. While the javac command did not specify the target Java version, and the version 1.8 byte code may have problems running on a version 1.6 platform, getting a java.lang.NullPointerException doesn't seem like well-written error handling?
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
I deployed to WebSphere I got the following error:
ADMA5006E: An error occurred configuring [my application name] in WebSphere Application Server repository: java.lang.NullPointerException
After adjusting my JAVA_HOME to point at the WebSphere Java,
java version "1.6.0"
Java(TM) SE Runtime Environment (build pwa6460_26sr7fp1ifix-20140220_01(SR7 FP1+
IX90136+IX90137))
IBM J9 VM (build 2.6, JRE 1.6.0 Windows 7 amd64-64 Compressed References 2013123
0_180580 (JIT enabled, AOT enabled)
I was able to deploy to WebSphere. While the javac command did not specify the target Java version, and the version 1.8 byte code may have problems running on a version 1.6 platform, getting a java.lang.NullPointerException doesn't seem like well-written error handling?
Monday, August 11, 2014
xsi:type and XMLSpy support
As always, something new to learn, even when it is something old! xsi:type enables overriding the default type of an element with a derived type. See:
Using xsi:type
Using Derived Types in Instance Documents
Another example of how xsi:type is used, in Health IT: Combining time intervals in CDA and some more related discussion on combining time measurements.
In terms of Altova XMLSpy support though, my understanding is that with XMLSpy Enterprise Edition 2014, rel. 2 sp1, the Schema tab/view does not indicate that there are derived types available for an element's type, nor does it support switching to view the structure of these derived types. However the Text tab/view does support auto-completing with any of the derived types once we type xsi:type=
Wednesday, July 16, 2014
UMLet quick-start guide
UMLet is a simple but effective software design tool. It compares favorably against heavyweights such as Microsoft Visio. Some key things to know for the beginner or someone who hasn't used it in awhile:
- To duplicate an element, double-click the element
- Adjust the arrow head or line format by adjusting the text in the Properties pane
- To select, press Ctrl and then mouse-drag around the elements you want
Friday, June 27, 2014
Joel Test: Applicability in 2014?
I think the Joel Test is still very applicable in 2014, almost 15 years later. While organizations should be considering doing more than the list states in its brief yes/no questions, the Joel Test serves as a minimum baseline that organizations cannot dismiss or argue with. Therefore, I don't believe the Joel Test needs updating.
However, some worthy, relatively recent elaborations on the Joel Test include:
Being a consultant, I find the Joel Test applicable to new projects I join, rather than applying it to an organization. When leading a project, it is also a good checklist.
However, some worthy, relatively recent elaborations on the Joel Test include:
Being a consultant, I find the Joel Test applicable to new projects I join, rather than applying it to an organization. When leading a project, it is also a good checklist.
Wednesday, June 18, 2014
Where do you find WebSphere Application Server port information?
For WAS 8.5.5.2, to find port information, on the left-side of the admin GUI, Servers > Server Types > WebSphere application servers.
Then, on the main part of the GUI, choose your server, then Configuration tab > Communication sub-section > Ports
Then, on the main part of the GUI, choose your server, then Configuration tab > Communication sub-section > Ports
Wednesday, June 11, 2014
Notes on "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)"
- Joel Spolsky's blog post
- Unicode is a "character set", which does not state how it is stored
- Misconception: That Unicode is simply a 16-bit code where each character takes 16 bits and therefore there are 65,536 possible characters; Unicode is not an encoding
- In Unicode, letters map to "code points", e.g. U+0041 rather than bits, e.g. 0100 0001
- Different fonts display code points differently
- Unicode can define more than 65,536 characters
- In UTF-8, an "encoding" (how string is stored in memory, disk, etc.), every code point from 0-127 is stored in a single byte. Only code points 128 and above are stored using 2, 3, up to 6 bytes.
- UTF-16 stores in two bytes only, not more than 2 bytes
- It does not make sense to have a string without knowing what encoding it uses. You simply cannot display it correctly or even figure out where it ends
Subscribe to:
Posts (Atom)