Bob Peterson

Ranch Hand
+ Follow
since Jul 30, 2004
Merit badge: grant badges
For More
Cows 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 Bob Peterson

Wohoo, that did it! (putting directory "." in the classpath)

Thanks Paul! Thanks also to Martijn for his quick responses.
No, I'm just double-clicking on the executable jar in a windows explorer view.
I've got a project that I jar into an executable jar with ant. I then zip up the executable jar along with the dependent jars it needs as well as a couple text files it reads. I've got the dependent jars listed in the class-path of the manifest file, the program can read the text files, all that appears to be working. It is structured in the zip file so that the executable jar, the dependent jars, and the text files are all in the same directory, like so:

other jars, etc.

Now I'm trying to enable logging because the user is having issues that I can't reproduce, so I'd like to be able to create logs that he can send me.

The logging works fine when run from Eclipse (it's a swing app). But there's no logging when run from the executable jar. I've put log4j.xml into the same directory as everything else listed above, and added log4j.xml to the class-path of the manifest file.

What am I missing?

I'm not sure which forum is better for this question, this one or WebServices, since I'm running into this problem while using Apache CXF. But the core problem is with JAXB annotations.

I'm trying to eventually get my response to be a simple list of items, like so:

And here are my classes

I had to create the OrdMedList class because without it, the service interface was initially returning an array of OrdMeds, but there was no <OrdMedList> tag, even though I had a @WebResult(name="OrdMedList") annotation on that. I read that this was a problem with JAXB, and was recommended to create the OrdMedList class.

So now the problem is that the result xml is

I guess it grabs that 'ordMeds' name from the property of the OrdMedList class. So I tried annotating that with the @XmlElement(name="OrdMed") but that created a JAXB error that said:

Class has 2 properties of the same name "ordMeds"
this problem is related to the following location:
at public java.util.List
this problem is related to the following location:
at public java.util.List

How can I get the response formatted the way I want? Seems like this is much harder than it should be.

I'm using Tomcat 5.5.25 and log4j-1.2.15 on a WinXP system. I think I have my classpath issues resolved because log4j is writing to my log file that is defined in my log4j.xml file. However, it's writing it to $CATALINA_HOME\bin.

I remember when doing log4j in Websphere, we had to put in a kind of file prefix for our log files, something like '../opt/'. Is there a similar prefix that is needed in Tomcat, to direct it to my webapp directory? Ideally, I'd like it under /webapps/mywebapp/logs.

Here's the relevant snippet of my log4j.xml :

16 years ago
That makes sense. My app's code to find resources is pretty skimpy, so I'll give this a shot. Thanks for posting that.

But why would log4j not be finding the log4j.xml file? I've noticed I'm missing the log4j.dtd, would that do it? I've run some code in the test jsp that is supposed to write out to a log file defined in our log4j.xml and it's not creating that log file.
16 years ago
Galen, thanks for your reply

Our 'main' jar is built by a completely separate project. I'm trying to mock-up a web app that a customer of ours might construct, so I'm assuming they would put our 'main' jar along with other supporting jars (like log4j, or axis, db drivers, etc.) in WEB-INF/lib.

Yes, the resources (i.e. log4j.xml) are deployed in the classes directory. Yes, the classes that are trying to access those resources are packaged in our 'main' jar, which is in WEB-INF/lib. I'm able to successfully use various other classes from that main jar in the jsp.
16 years ago
By resources I mean log4j.xml and an xml config file we use to configure our DB connections/DataSources. I'm just trying to get a bare-bones web app up and running to test our main software product (a jar) in a web environment. I'm just doing the simple testing in a jsp. It's finding our main jar and other dependent jars in web-inf/lib. The simple jsp is working, although I haven't tried a servlet or any other class yet to see if it can find anything in WEB-INF/classes

I've been out of doing web-apps for a few months and apparently losing knowledge rapidly; is there something obvious I should be looking for?

16 years ago
My junit task running in ant can't find the right driver. The error is :

java.sql.SQLException: No suitable driver
at java.sql.DriverManager.getConnection(Unknown Source)

When I run the Junit in Eclipse, it works fine. I have the db drivers on the classpath, but I must be missing something.

We have a utility project (DataConn) for handling db connections. It contains examples that require the db drivers. When I compile this project earlier in the build script, it compiles fine. I tried commenting out the classpath ref that has the drivers on it, just to test it, and it fails.

For the junit classpath, I have a refid that points to the classpath used by the DataConn project. But apparently something is wrong.

I'll try to include relevant snippets of the build file

DataConn.lib is where the driver jars are. Again, I tested that this is working because the compilation of the DataConn project works with this classpath, and fails when it's commented out.

FYI, the test.compile target step is successful as well.

In the test suite, there is a static initializer method which sets the 'jdbc.drivers' System property with a semicolon-delimited list of the drivers. Then it does other calls to our DataConn project to set up the connection pool. This all works fine when running this suite from within Eclipse.

I'm using ant 1.7 on WinXP. Any gotchas in this area I should look for? Any ideas?

16 years ago
We're trying to design an API that will go out to external customers. I've jumped into a new API product that has been 80-90% designed and written, and I'm trying to decide whether or not to keep the few interfaces that have been written. I'm wrestling with the 'program to an interface, not an implementation' issue.

FYI, my perspective is keep it simple, concrete, program to what you know now, don't have interfaces where there is only one implementation, etc. In the last couple years I have repeatedly inherited projects that seem to me to be very overly complicated in their design. We refer to these as 'atomic baloney slicers' when all you need is a simple knife. So I am leaning towards eliminating the interfaces and keeping the single concrete implementations we have.

On the other side, there is the difficulty of trying to plan for an unknown future (version 2?) and unknown usage by the customers. For instance, our concrete implementation is MyProduct. They may want to create a FooCompanyProduct class, and then handle FooCompanyProduct and MyProduct objects together. But the problem is, we don't know how to define the contract of the Product interface in that scenario. Right now, it seems like ALL the methods we think should be in the proposed Product interface, are already in the MyProduct class.

After our last design session, we decided to get rid of the interface, push a lot of the methods in the MyProduct class into an AbstractProduct class, which the customer can then extend. Another facet of the issue is that the custom classes the customer may want to make, must be composed of our components. Maybe that will help explain the decision on the AbstractProduct class. It's hard to explain it w/out getting into trouble divulging company secrets and all that.

I've been reading design articles on this issue and have just been going round and round on it. Honestly, a lot of those articles are hard for me to fully digest in an abstract sense, even with examples. I think I understand the benefits of interfaces with multiple implementations. Maybe I just need to learn the hard way by doing it wrong, but I'm trying to avoid that.

Hope that didn't ramble too much. Thoughts? I wish there was a preview option on these forums
Initially, I thought my problem was similar to this one :

But I don't think so. We have an existing web service that's been running fine for awhile. I'm trying to create a new service within the same codebase/WAR, just at a different URL. I'm using Axis 1.2, WSAD 5.1, and Java 1.3 (yes, we're that far behind).

We have a WS client class that encapsulates the call to our own services, for testing purposes. I've added a new method to this class which uses a new request XML to call the new service. The 'old' calls to the old service, from within this same client class, work fine. The new call creates the exception below.

So since the old calls from within the same class work fine, I don't think it's the classpath issue mentioned in the thread above.

The new request XML validates and is very simple :

Any ideas? Thanks
17 years ago
I'm getting the following error while trying to Unmarshal a Document into the java objects that JAXB generated. The instance document does validate against the schema. Here's the error :

"unexpected root element (uri:"", local:"MyRootElement"). Expected elements are....

I Googled this and found a few responses, most of them pertaining to JAXB 2.0, with no clear answer. I suspect that it has to do with namespaces but don't know what to do. I tried a modification of my instance doc that removed all the 'xmlns="..."', 'xmlns:xsi="..."', and 'xsi:schemaLocation="..."' attributes and tried to Unmarshall that version but got the same error.

Since we're only using the one main namespace, none of the elements have any namespace prefixes.

Any suggestions?
Thanks, I already had jwsdp-1.3 downloaded so I was able to try that out fairly quickly and am now on to the next problem. It's different enough that I wonder if I should start a new topic...anyway here it is :

"unexpected root element (uri:"", local:"MyRootElement"). Expected elements are....

I Googled this and found a few responses, most of them pertaining to JAXB 2.0, with no clear answer. I suspect again that it has to do with namespaces but don't know what to do. I tried a modification of my instance doc that removed all the 'xmlns="..."', 'xmlns:xsi="..."', and 'xsi:schemaLocation="..."' attributes and tried to Unmarshall that version but got the same error.

Any suggestions?
Thanks for your reply, sheriff!

Do you know where I can find older versions of JAXB, either 1.0.1 or 1.1? I've already done some quick searches on it and can't find it, either on Sun's site or the Glassfish project. Glassfish has a link to JAXB 1.0, but I couldn't find any more incremental versions. I have this problem all the time with all kinds of Java APIs, be they Sun, Apache, etc.

<rant>Because of the retarded company I work for, we are STILL stuck using Java 1.3. It is getting harder and harder to find versions of APIs that work with this ancient version.</rant>
[ January 30, 2007: Message edited by: Brian Peterson ]