This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java and have Dr. Raoul-Gabriel Urma & Richard Warburton on-line!
See this thread for details.
Win a flower (🌹) or copy of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java (📚) this week in the Agile and Other Processes forum!

Gareth Anderson

+ Follow
since Feb 27, 2006
Apples and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Gareth Anderson

In the end this appears to be the way it should work:

Provided an answer eventually.
It would appear controlling WebSphere's SystemOut with Log4j is not possible, I consider this a good feature as you get log4j logs + the dynamic control over WebSphere's logging.
12 years ago
Hi JavaRanch,

As per my previous discussions on the IBM website and the JavaRanch website I've had various issues that are now resolved:

My new question is about *how* it should work, I'm 99% sure that this is how its supposed to work but I just want some confirmation.

I do have log4j working and logging to its own file, I will eventually customise this further.

My question is, WebSphere acts quite differently to Tomcat in regard to log4j logging, as in the use of ConsoleAppender does absolutely nothing in WebSphere.
WebSphere's JDK logging appears to still run for the SystemOut file, and it can be customised through the WebSphere interface.
AND the log4j logging also works to a file perfectly fine.

So my question is, is this the way log4j works through WebSphere?

We're logging to the commons-logging interface with log4j as an implementer but this application appears to log to both log4j (and the file specified in the properties) AND the JDK logger that WebSphere normally uses.

This is a good feature for us but I would like to confirm that we haven't done anything wrong here?

12 years ago
for further discussion of issue and solution.

I have found a solution for now...
[ February 11, 2008: Message edited by: Gareth Anderson ]
12 years ago
Hi everyone,

I've read all the documents and I still can't get log4j working using a commons-logging implementation.

With the

META-INF/services/org.apache commons.logging.LogFactory (and put org.apache.commons.logging.impl.LogFactoryImpl.Log4JLogger in that file)

trick, where does this particular META-INF file go into?

Also, I cannot change the class loader to PARENT_LAST as my entire application breaks, most of the documentation around this, even refers to changing the class loader.

Scott mentioned

Replaced the commons-loggin jars in websphere/lib

what exactly did you replace? The commons-logging-api jar file?
And why?

Currently we have a commons-logging-1.1.jar in the ear file, and a copy in the WEB-INF/lib directory of the war file.
There is a file in WEB-INF/classes.
I have tried putting files in many places but to no success, same with the META-INF/services/org.apache commons.logging.LogFactory trick.

How can I get this working on WebSphere 6?

12 years ago
Here's the reply I sent to my group about this, I was approaching the problem in the wrong way...

Thanks for those who replied with some advice or assistance about this, I found a way to resolve this and here is some information for anyone else who runs into the same issue.

I was thinking about the problem the wrong way, I was also not interpretting the Tomcat documentation correctly.

From it says:
"The web application used to process each HTTP request is selected by Catalina based on matching the longest possible prefix of the Request URI against the context path of each defined Context. Once selected, that Context will select an appropriate servlet to process the incoming request, according to the servlet mappings defined in the web application deployment descriptor file (which MUST be located at /WEB-INF/web.xml within the web app's directory hierarchy).

You may define as many Context elements as you wish. Each such Context MUST have a unique context path, which is defined by the path attribute. In addition, you MUST define a Context with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path."

Now you *must* have a default Context in a virtualhost if its going to work at all. But if you create a Context file in the META-INF directory as I was trying to do, then it is not going to relate to the default web application unless there is the application name in the URL (which is what I was trying to avoid).

In other words the way of specifying the virutal host was fine, for testing I created a virtualhost from my IP address of my computer, for example:

<Host name="" appBase="C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\Contact" unpackWARs="true" autoDeploy="true">
<Context docBase="" path="" debug="0" reloadable="true"/>

The above is fine for creating a virtual host but the context will be lost if the webapplication exists under the directory "Contact".

So what I did is create a context file that is default to the host in "C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\Catalina\", called "context.xml.default" (which is just a copy of the context file in META-INF/context.xml), however this time the context file is for any application on the virtualhost. Since the only application on the virtualhost will be my application there is no problem with this.

Here is the relevant section of the Tomcat manual:
"In addition to nesting Context elements inside a Host element, you can also store them:

in the individual $CATALINA_HOME/conf/context.xml file: the Context element information will be loaded by all webapps
in the individual $CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default file: the Context element information will be loaded by all webapps of that host
in individual files (with a ".xml" extension) in the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory
if the previous file was not found for this application, in individual file at /META-INF/context.xml inside the application files"
I'm using the second dot point there, this will work for my particular situation because a virtualhost only runs a single web application, the last dot point did not work for me as I expected, and I don't think the third dot point worked for me either but I haven't had time to re-test this.

Hope that helps someone.
Thanks everyone for your help!
13 years ago
Looks like the only way to do this is to perform a re-direct on the server as the "Contact" in the URL is required for the context to work as expected.

If I was not using a context file then I could have done without the re-direct (or I could use hibernate etc.).
13 years ago
Sorry, where are you referring to the work directory? And does this apply to tomcat 5.5 (quite different to Tomcat 5.0)

The only conclusion the group came to so far was to do a forward . Other staff members pages on the same server don't have this problem, but they use hibernate which does not require a context.xml to be used in the meta-inf directory.

So I'm the only one trying to do it this way...
[ August 05, 2006: Message edited by: Gareth Anderson ]
13 years ago
Had a look at more documentation and still can't figure out what to do or where to start

I'm not sure where to look anymore either, the tomcat documentation doesn't help, nearly every forum post tries to do it a different way (and I can't get any of them to work ).
[ August 03, 2006: Message edited by: Gareth Anderson ]
13 years ago
Read a little more documentation:

"The context path of this web application, which is matched against the beginning of each request URI to select the appropriate web application for processing."

Well the problem is my request URI is not going to have the context information in it because we don't want the customer to always have to type the "/ContextName" on the end of it.

So maybe I need to learn how to tell the virtualhost that its always in that context...
13 years ago
Hi everyone,

I'm using MyEclipse/Eclipse to build a JSF based application running on the Apache Tomcat 5.5 application server.

I have this sucessfully working as a project called "Contact", eclipse takes care of exploding the war file for me.

In the "META-INF" directory I have a "Context.xml" file which has the JNDI connection information.

Now if I access this file via http://localhost:8000/Contact/ it works perfectly (as expected).
The database queries occur etc. etc.

However, when this application goes into production, we don't want customers typing.

We want them typing:

Right? Well I can configure Apache 2.0 and Tomcat to do this by doing this in the server.xml of Tomcat:

<Host name="" debug="1" appBase="C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\Contact" unpackWARs="true" autoDeploy="true">
<!-- <Alias></Alias>-->

<Context docBase="" path="" debug="1" reloadable="true"/>

Now this sets up a host running off my local IP address (of course on the server the name will be a FQDN, a URL of the project).

And this is good and well, I can access the program via the IP address (where the x's are my static IP address).

However, if I try to do anything database related it throws a:
2006-08-03 15:25:03,801 [http-8000-Processor24] ERROR com.xxxx.backend.DatabaseUtils - Error trying to connect to database
javax.naming.NameNotFoundException: Name jdbc is not bound in this Context

The only reason why I can see this is not bound is because its not finding the context file correctly.

If I change the virtual host to have an appbase of one directory higher like this:

<Host name="" debug="1" appBase="C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps" unpackWARs="true" autoDeploy="true">
<!-- <Alias></Alias>-->

<Context docBase="" path="" debug="1" reloadable="true"/>

And then access the program via this will also work fine (no errors).

However I cannot seem to get the context information right when I don't have the /Contact there.

Is there something obvious I'm missing? I've spent about 7hours on this problem with no solutions so far

Context.xml looks like this:

<?xml version='1.0' encoding='utf-8'?>
<Context path="/Contact" reloadable="true">

<Resource name="jdbc/CLV" auth="Container"
type="javax.sql.DataSource" username="xx" password="xx"
driverClassName="oracle.jdbc.OracleDriver" url="jdbc:oracle:thin:urlgoeshere" connectionProperties=";;;"
maxActive="8" maxIdle="4" maxWait="5000" />

Where there is of course a real URL there.

And the lookup code is simply:
Context context = new InitialContext();
DataSource dataSource = (DataSource) context.lookup("java:comp/env/jdbc/CLV");

Any ideas here? Am I missing something obvious in my configuration file?

How do I get this context file to work correctly? I've tried renaming it to "Contact.xml" and putting it in the $CATALINA_HOME/conf/localhost but this only works for the method of accessing it with "/Contact" on the end.

I've tried adding the <resource-ref> etc. to web.xml, again this only works with the /Contact on the end. How do I get this context.xml to show up if there is no /Contact on the URL?

[ August 03, 2006: Message edited by: Bear Bibeault ]
13 years ago
Thankyou for the information.

Yes I noticed that unusual difference, I assume that the SCJP certification isn't going to have any questions with that much detail.

For anyone who is interested I'm reading SCJP, SCJD - Complete Java 2 Certification 5th ed. From Sybex.

Hopefully they will fix this next edition (although the people writing the book are apparently the on the examination board for java certification...)
14 years ago
Oh, here's the supporting text for the books answer (the opposite of my answer) from the chapter:

It�s important to be aware that different-package subclasses don�t have unlimited access to protected superclass features. In fact, different-package subclasses have only the following privileges:
They may override protected methods of the superclass.
An instance may read and write protected fields that it inherits from its superclass. However, the instance may not read or write protected inherited fields of other instances.
An instance may call protected methods that it inherits from its superclass. However, the instance may not call protected methods of other instances.

[ February 27, 2006: Message edited by: Gareth Anderson ]
14 years ago
Hi everyone,

Not sure which forum this was suited too so I'm posting it in intermediate, its not an easy question but I don't think my testing agrees with the answers in the study guide I'm reading for the Java 5.0 exam.

Anyway, this is an example question:
"True or false: If class Y extends class X, the two classes are in different packages, and class X has a protected method called abby(), then any instance of Y may call the abby() method of any other instance of Y."

Well the book is saying its false:
"An object that inherits a protected method from a superclass in a different package may call that method on itself but not on other instances of the same class.".

Well yes, I do realise from other programming (eg. C++) that protected means that subclasses have access to the method. But I disagree with the fact that it cannot be called on other instances of the same class.

I created this code to test it:

And this other class:

My testing is done in a new version of eclipse so it tells me if there are errors before I hit the compile button. There are no errors and it runs as expected printing:
"abby from x
abby from x"

And this is being run on a new instance of the same class. Does this contradict the question? (the answer would be true...)

These is similar text written in the chapter which says the opposite of what I'm thinking, and I'm confused (am I correct or misinterpreting things).

I have complied with java 5.0 compliance in eclipse (although I'm sure 1.4 is the same).

[ February 27, 2006: Message edited by: Gareth Anderson ]
14 years ago