Tom's Blog

I got an obscure error message and stack trace from Sun's Java Web Service Developer Pack 1.6's wscompile tool. I tried to generate the server-side artifacts for a JSE web service using the following wscompile configuration file:

<configuration xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
    <service
        name="MyService"
        targetNamespace="http://ws.mcqueeney.com"
        typeNamespace="http://type.mcqueeney.com"
        packageName="com.mcqueeney.ws"
    >
        <interface
            name="com.mcqueeney.ws.MyService"
            servantName="com.mcqueeney.ws.MyServiceWS"
        />
    </service>
</configuration>

Running wscompile from Ant with -verbose and -Xprintstacktrace would display the methods of the endpoint interface, then come up with an exception and stack trace.

[wscompile] command line: wscompile C:\apps\j2sdk1.4.2_08\jre\bin\java.exe -classpath ...
    com.sun.xml.rpc.tools.wscompile.Main -d generated\wscompile -features:rpcliteral -gen:server
    -keep -model generated\wscompile\model.xml.gz -mapping generated\wscompile\event-mapping.xml
    -s generated\wscompile -verbose -Xprintstacktrace wscompile-config.xml
[wscompile] [creating model: MyService]
[wscompile] [creating service: MyService]
[wscompile] [creating port: com.mcqueeney.ws.MyService]
[wscompile] [creating operation: method1]
[wscompile] [creating operation: method2]
[wscompile] [creating operation: method3]
[wscompile] [creating operation: method4]
[wscompile] Naming conflict occurred: [com.mcqueeney.ws.MyService]
[wscompile] at com.sun.xml.rpc.processor.generator.nodes.TypeVisitor.preVisit(TypeVisitor.java:115)
[wscompile] at com.sun.xml.rpc.processor.model.ExtendedModelVisitor.visit(ExtendedModelVisitor.java:25)
[wscompile] at com.sun.xml.rpc.processor.generator.nodes.JavaWsdlMappingNode.write(JavaWsdlMappingNode.java:73)
[wscompile] at com.sun.xml.rpc.processor.generator.JaxRpcMappingGenerator.buildMapping(JaxRpcMappingGenerator.java:57)
[wscompile] at com.sun.xml.rpc.processor.generator.JaxRpcMappingGenerator.perform(JaxRpcMappingGenerator.java:48)
[wscompile] at com.sun.xml.rpc.processor.Processor.runActions(Processor.java:88)
[wscompile] at com.sun.xml.rpc.tools.wscompile.CompileTool.run(CompileTool.java:739)
[wscompile] at com.sun.xml.rpc.util.ToolBase.run(ToolBase.java:43)
[wscompile] at com.sun.xml.rpc.tools.wscompile.Main.main(Main.java:22)
[wscompile] java.lang.RuntimeException: Naming conflict occurred: [com.mcqueeney.ws.MyService]
[wscompile] at com.sun.xml.rpc.processor.generator.JaxRpcMappingGenerator.buildMapping(JaxRpcMappingGenerator.java:65)
[wscompile] at com.sun.xml.rpc.processor.generator.JaxRpcMappingGenerator.perform(JaxRpcMappingGenerator.java:48)
[wscompile] at com.sun.xml.rpc.processor.Processor.runActions(Processor.java:88)
[wscompile] at com.sun.xml.rpc.tools.wscompile.CompileTool.run(CompileTool.java:739)
[wscompile] at com.sun.xml.rpc.util.ToolBase.run(ToolBase.java:43)
[wscompile] at com.sun.xml.rpc.tools.wscompile.Main.main(Main.java:22)
[wscompile] error: java.lang.RuntimeException: Naming conflict occurred: [com.mcqueeney.ws.MyService]

The only mention of this error I could find was a June 14th posting on a JBoss forum. The posted solution from Thomas Diesler of JBoss was to rename the service endpoint interface. That solution, inexplicably, worked.

After playing around for a few minutes, I found a better solution, at least for the above problem: The naming conflict seems to be between the service name given in the wscompile configuration file and the class name of the SEI. They were both named MyService. My easier solution was to give the service a different name in the config file, for example: <service name="MyService_Service" ... >

I still don't know what causes the name conflict. I'm guessing the wscompile tool writes some artifacts using the service name, probably using a package name derived from the packageName or targetNamespace. I could find no documentation on wscompile on what it generates based on the service name from the configuration file. In looking at the classes wscompile generated, none seemed to conflict based on the service name. Is it generating an implementation of javax.xml.rpc.Service using the name attribute to the <service> element? If so, I couldn't find any such generated class.

Please leave a comment if you have knowledge of what artifact wscompile produces that cause the name conflict with the SEI. I figure I'll post this problem in case anyone else hits this "naming conflict" error.


Sunday July 03, 2005 Permalink Comments [1] I spent about a frustrating half-hour solving this one. Tomcat 5 has such a nice Windows installer, and good integration with Windows services, so I hate to rag on it. But for such a common situation, it seems this is a vast oversight in the Windows Tomcat installation program.

The problem was with installing Tomcat 5.5.9 on a Windows XP system. I'd run the Windows installer and get this error dialog:

Failed to install tomcat 5 service
Check your settings and permissions
Abort Retry Ignore

The above is accompanied by a warning to select Ignore at your own peril. I googled around and none of the suggestions worked. The most common situation that results in that error is not being logged in with administrative privileges, since the Windows installer installs Tomcat as a service. That wasn't my problem. My login privileges was the first thing I checked after the "check your settings and permissions" message. I even checked the Tomcat bugzilla site and got the "Zarro Boogs found" when looking for my particular problem.

It seems the problem was having Tomcat 5.0 installed on the box. It appears that the 5.5.9 installer tries to install Tomcat as a service using the same service name, and gets an error from Windows that a service with that name exists. Either that, or the installer tries to create a Windows registry key that already was in use by Tomcat 5.0. At least these are my guesses, because uninstalling Tomcat 5.0 made the 5.5.9 installer happy. After the Tomcat 5.0 uninstall, everything worked OK.

It seems too bad I can't have both versions installed at the same time, at least by using the Windows installer.

Sunday June 19, 2005 Permalink Comments [13] IBM says it is "making a major commitment to Apache Geronimo as the Open Source application server of the future." Sounds good. But what is the meaning of the?

If I said The Hitchhiker's Guide to the Galaxy is the movie of 2005, you might assume I'm recommending it, using the movie as a shorthand to mean "the best" movie. Is that what IBM means by "the Open Source application server of the future"? Or does IBM mean Geronimo is the open source application server of the future? That is, IBM will work to ensure Geronimo is never quite finished or stable so as not to eat into sales of WebSphere Application Server Express.

I'm sure IBM realizes its purchase of Gluecode Software last week -- and thus its acquisition of Gluecode's five staffers who have been key architects and contributors to Geronimo -- fomented discomfort in the open source community. IBM is the 500-pound gorilla. Geronimo contributors and potential Geronimo users are wondering just what are IBM's intentions toward Geronimo. Even Gartner said "some users will ... suspect IBM of attempting to control the open-source community" with its Gluecode purchase.

As of today, IBM has been mostly silent on its intentions. Last week, IBM said it will:

• Donate an Eclipse plugin to help developers target Apache Geronimo as their J2EE server
• Devote an unspecified number of IBM employees to work on Geronimo
• Keep the former Gluecode developers working on Geronimo

In addition, IBM has released some documentation aimed at Geronimo. These actions all benefit the Geronimo open source community.

On the optimistic side, IBM's goals for Geronimo will mesh with the goals of the current team of Geronimo developers and its users -- to create the best available open source J2EE application server. IBM will devote smart developers to working full-time on Geronimo, and Geronimo's features and capabilities will outshine the other two open source J2EE servers, JBoss and JOnAS. Many developers and companies would like an alternative to JBoss Application Server, especially those concerned about JBoss's restrictive license, so IBM's commitment to Geronimo could end up being beneficial to everyone, except perhaps JBoss Inc.'s consulting services.

On the pessimistic side, IBM could use its Gluecode brain trust to swing Geronimo in a direction that benefits IBM and not average users. IBM now controls, through its new Gluecode employees, about half of the active committers to the Geronimo project. The chairman of the Geronimo Project Management Committee, Geir Magnusson Jr., is one of the new IBM employees. The Geronimo PMC controls the direction of the Geronimo project, deciding what features are added and who may contribute to the project.

I think we all want to assume IBM's involvement will benefit all users, not just IBM customers. I think we all want to assume IBM wants Geronimo to be the best open source J2EE server on the market, not the best server for IBM Global Services consulting income. I think we all want to assume IBM will allow the former Gluecode employees to continue their excellent work on Geronimo.

To allay concerns, the solution for IBM is to announce just what it wants to do with Geronimo and what influence it will try to wield over the project. Do they plan to fork the Geronimo project to create a separate version aimed at IBM customers? Will IBM's commitment to Geronimo fade over time, similar to IBM's previously strong commitment to Apache Axis? Do they plan to create add-on tools to make Geronimo easier to use and deploy in the enterprise, and make them available only to IBM customers who purchase 1-year support contracts? Do they plan to restrain its employees from adding powerful features to Geronimo that would make it a WebSphere competitor?

If IBM is truly committed to open source software, it would do the open source community a favor by announcing its Geronimo strategy with a clearer statement. Saying IBM is committed to Geronimo as "the Open Source application server of the future" hasn't done much to quell unease.


Monday May 16, 2005 Permalink Comments [1] I think it's fair to say that Maven has yet to catch fire among Java developers. Maven is complicated to learn and its documentation is lacking. Most Java developers who are using Ant probably have heard of Maven and its promise of easier automated builds. In fact, a fair number of Ant users probably have it on their To Do List to check out Maven to see whether it will save them time.

But the Maven team's technology preview release last month of Maven 2.0 almost certainly will hurt Maven's adoption, at least in the short term. Maven 2 will slow Maven's adoption probably for at least six months, and probably into 2006 as the new Maven stabilizes.

Why my pessimism? Maven developers shot themselves in the foot by scrapping the goal of Maven 2's backwards compatibility with Maven 1, and introducing new technologies just as obscure as Maven 1's technologies. Barriers for Ant users to adopt Maven have always been Maven's steep learning curve, its scripting language (Jelly), and its semi-enforced ways of organizing a project's files. Now, Maven 2 will change Maven in drastic ways. Maven 2 scraps Jelly in favor of (I'm not kidding) Marmalade. And the favored way of writing Maven 2 plugins will be Mojos, which seems to be Java classes that get inserted into a Maven 2 Plexus IoC container. Not only does Maven 2 introduce an IoC container, it uses one that almost no one has heard of.

In short, why would an Ant user today even considering switching to Maven? If you aren't using Maven today, going to the trouble of learning Maven 1, only to be left with a tool that quickly becomes outdated as Maven developers leave it in the dustbin, would be a waste of time. For those who hate Maven to the point of bile or poetry, Maven's slower adoption won't mean anything. But for Ant users interested in learning Maven today, the Maven team seems to be saying "don't bother, wait for Maven 2."

If you think I'm exaggerating, here are quotations about Maven 2 from the Maven web site:

• "Maven 2.0 is a complete rewrite. It will not be backwards compatible with any of the Maven 1.x releases"
• "Maven 2.0 will feel very different to a Maven 1.0 user - and perhaps a little strange"
• "Plugins ... are the only way to script your builds"
• "...significant new features will not be added to the Maven 1.0 core"
• "Will my Maven 1.0 plugins be supported? Not directly"

On the positive side of Maven 2, once it matures it might help solve the complexities and slowness in Maven 1 and eventually win over more Ant users. That is, maybe they must kill Maven in order to save it.


Sunday May 08, 2005 Permalink Comments [4] When I was a high school senior, my English teacher assigned (my translation at the time: forced) me to read Henderson the Rain King by Saul Bellow.

Henderson is a book about an inherited millionaire in his mid-50s (the book was published when millionaire meant "great wealth," not "the guy next door") who is lost in life and takes it out on everyone around him: his wife, his children, a stray cat, his cleaning lady, his neighbors (he starts a pig farm in his front yard to spite them). Uncertain what to do next, he accepts an invitation to visit Africa with a honeymooning couple. He arrives in Africa and welcomely ditches them in search of undiscovered tribes, which he finds -- and he proceeds to make their lives miserable.

In other words, other than being lost in life and wondering who he wants to be when he grows up, this is not the sort of protagonist a high school kid can relate to. Yet read it we did.

Even more, we discussed it. We discussed life, what it means to discover who you are, "becoming" versus "being," "truth comes in blows," tragedy, joy, life, death. This was the first "serious literature" I read in high school that I can recall actually having semi-intelligent discussions about with fellow students and the teacher. Instead of the teacher expecting you to recite what students everywhere have been reciting about literary works for decades, our teacher wanted to hear what the book meant to us.

Our teacher, Mr. Montgomery (like most of my high school teachers, I am embarrassed to admit he exists in memory with only a last name) led us students on discussions of personal identity and the quest for meaning. He was the first teacher I recall who talked to us like we were adults, even when we didn't always deserve it, assuming we had thoughts in our heads that might be worth hearing.

Mr. Montgomery, or "Monty" as we sometimes called in class during light-hearted moments, was a school teacher who was so good at what he did they moved him into "management" writing curricula in the district office. Years later, lucky for me, he took a pay cut to return to the classroom to what he loved -- teaching kids. And his love for teaching showed. Mr. Montgomery exposed me to literature in a way no teacher had, and at a time when I was more able to appreciate it. Honestly, at that stage in life, I wasn't ready to love literature. I still thought our analysis of Henderson was way overblown, and "hero" Eugene Henderson was hard to relate to. But Mr. Montgomery changed my definition of literature; I no longer viewed it as "boring big books sadistic teachers force you to read."

In college, an unknown force compelled me to read Henderson -- gasp! outside of class. A few years later, I read it again. And again a few years after that. Each time I picked up the book, I saw Eugene Henderson and his quest for life's meaning in a different way, obviously because I was a different person. My respect for "literature" and the power of a good novel grew. My admiration for Saul Bellow grew -- even though I did put down The Dean's December almost in disgust, thinking the author just subjected me to hours of gray, bleak depression and death. More importantly, my respect and admiration for "Monty" Montgomery grew. On each reading of Henderson, I'd recall some of the book's themes we talked about in class, and I finally understood more of what they (Saul and Monty) were saying. Life even dealt me a "truth comes in blows" moment.

When I heard Saul Bellow died Tuesday at the age of 89, fond memories of Henderson and Mr. Montgomery returned. According to Bellow's New York Times obituary by Mel Gussow and Charles McGrath, the author won more literary honors than any other American writer. His awards included the Nobel Prize in Literature in 1976, a Pulitzer Price, three National Book Awards, a Presidential Medal. (If you don't want to register at the NYT web site, you can read an abridged version of the obituary on the International Herald Tribune's web site.)

This blog entry veers from my usual technical focus. It's my way of remembering two people who had an influential impact on my life: a novelist whose words could make me think about life in new ways, and a teacher who shared more of himself than he had to in order to teach me to think and not just parrot the Cliffs Notes.

To Saul and Monty, thank you.


Saturday April 09, 2005 Permalink