DougBreaux 270007SMYJ Visits (739)
While that second link really contains all the crucial information on those issues, I thought I'd also post it here.
WebSphere Liberty Core(?)
First, my RAD install came with an installation of WebSphere Liberty, I think "Core" Edition. (Liberty Features compares the Editions.)
And that didn't come with very many Features to enable. I didn't notice this until I went to generate JAXB Java classes from an XML Schema (XSD) file. Where I got the error:
Errors occurred during wsgen.
(Interesting, didn't even know I was using wsgen, eh?)
Well, that is the correct location of my Liberty install. But, hey, there is no jaxb folder there at all. I have a couple of other xjc instances on the system, but I have no idea how to make RAD use them. My project is a Web Project, pointed at a JRE that does have xjc, and the Liberty Runtime, but apparently that's not sufficient for the RAD configuration to connect the dots.
Liberty for Developers
So instead I uninstalled that copy of Liberty (with Installation Manager), and then added to Installation Manger the "IBM WebSphere Application Server Liberty for Developers (ILAN)" repository, from WebS
The ILAN versions are available for free with a DeveloperWorks ID and have the caveat:
This one let me install all kinds of Features, including ... JAXB support. Now the xjc tool is there where RAD wanted it.
"jar" access is not allowed
Except, now RAD generating JAXB from Schema produced the following error:
The xjc tool returned an error:
Also, it turns out I only got this message if I elected for the code-generation process to create Serializable classes. If I didn't select that option, the generation succeeded. Weird since I the only difference I noticed - after I got it working - is adding "implements Serializable" to the generated classes.
In any case, this StackOverflow link pointed at a very similar problem, with a definitely non-intuitive workaround, that eventually succeeded when I found the right place for it:
For me, this meant going to the /opt
# ... because "jar" access is not allowed"
Update: Not just Mac + Liberty
Now back on my primary Windows 10, with WebSphere 8.5.5 Full Profile, I had the same problem occur:
The Xjc tool has completed Web service artifact generation.
Same fix/workaround, this time in C:/Program Files (x86
(And yes, this seems to me like a bug in either RAD/WDT, or WebSphere, or the combination.)
I've recently been trying to get my secondary machine, a Mac, running Rational Application Developer at least close to how I have it running on my primary Windows machine. (While awaiting hardware fixes and system reload.)
Several things have not worked out-of-the-box, so I figured I ought to document the things I've had to address.
Update an existing installation
First, I already had RAD 9.6 installed and had used it a bit, so I know it was working. It also installs a copy of IBM Installation Manager, which is how you ought to be able to update to a new fix level. I knew 9.6.1 was available, so I tried the "IBM Installation Manager" option from within RAD, from the "Help" menu, but it never worked. I don't remember the exact behavior or error, but I think at one point the application just never appeared, and maybe at another it reported a generic, "An error has occurred... see the log file".
Nor did running the program directly, once I located it under /App
I then tried deleting IM, which under a Mac is not as intuitive to me as Windows, believe it or not. (And, apparently, simply sending those folders - InstallationManager and IMShared - to the Trash is insufficient for a full uninstall. I'll return to that in a moment.)
I then tried installing a new, standalone version of IM, but that found no packages either.
So... I concluded I needed to uninstall everything and start from scratch with 9.6.1. However, when running that installer, the IM installation portion complains that a newer version is still installed.
Now, attempting to run RAD right after installation resulted in the confusing error, "To open "Eclipse" you need to install the legacy Java SE 6 runtime".
Are you kidding me? An up-to-date version of a Java IDE surely isn't requiring an obsolete Java? Plus RAD provides its own version - Java 8 - I can see it right there in its installation directory. Plus 9.6 was running fine.
Web searches seem to indicate this is Mac message rather than an Eclipse or RAD one, which makes sense given that it's not even trying to use RAD's copy of Java yet.
(I also opened a Ques
DougBreaux 270007SMYJ Visits (3261)
Missing IBM Websphere SSL class
I was simply trying to install an Eclipse plugin from the Eclipse Marketplace into my RAD on one system and RSA on another, but I kept getting this error:
Some web searches find that text. After a few unsuccessful attempts, the "alternative" solution from Cann
I guess RAD started and loaded up the WAS SSL support, but RAD itself isn't fully able to use that.
Note also the warning to "reverse" that activity if you want to run WAS again under RAD.
Relevant but not successful
DougBreaux 270007SMYJ Visits (4795)
(I'm assuming this is the same in stock Eclipse, I don't have it installed right now to confirm.)
If you have any source code that is generated by tooling (say, JAX-WS proxy code), you might have compiler warnings for things that are not considered best-practice. (Maybe they were fine in an earlier version of Java that the tooling still supports but are redundant in a later version.)
If you're like me and you prefer to have clean packages & classes in your IDE, here's a small tip that I somehow missed until recently.
If you place your "generated" source code in a separate source folder, which I like for ease of build process as well as organizational utility, you can also tell RAD to ignore compiler warnings for that source folder.
To do this, right-click on the source folder and go to Properties. Under "Java Compiler", check the "Ignore optional compile problems" setting, and you're done.
DougBreaux 270007SMYJ Visits (6469)
As a follow-up to Part 1, here are some additional considerations for generating JAX-WS code.
The wsdlLocation property for wsimport (whether from the command-line or from Ant) is placed in the generated JAX-WS @WebServiceClient class. It's placed both in that class annotation and in the static initializer block.
If you do not specify this option, the generated code will reference the absolute "file:" path to the .wsdl file on the local machine, which obviously won't work when deployed anywhere else. Alternative ways to deal with this are:
Option 3 seems to me the cleanest and simplest with our current projects' directory conventions, so this is what I plan to use. For example:
Client vs. Server
wsimport will generate:
Of these, item 2 is not necessary for a JAX-WS service. In fact, the existence of a client class could be confusing.
An alternative to using wsimport for the service code is to generate it with RAD tooling, which if you specify that you're creating a service, will not create the client class. This will also create a "stub" service implementation class, which wsimport does not do.
The generated service implementation class will be annotated with @WebService with name and targetNamespace attributes that match those of the generated interface described in item 1. Additional attributes for the serviceName and portName will be added as well (matching the <wsdl:service> and <wsdl:binding> elements, respectively).
Strangely (to my thinking) this generated class does not actually implement the Java interface.
However, relying on RAD tooling rather than scripting may be considered to reduce the repeatability of future builds, so it might be preferable to use the wsimport approach, delete the generated client proxy, and manually create the @WebService class with the proper annotation attributes and proper methods.
In either case, the @WebService implementation class will have actual calls to business code manually added to it, so once it's generated it should not be overwritten by any future process. Thus, perhaps the better approach is to initially create the service with RAD tooling, then subsequently use wsimport if WSDL changes require code to be regenerated.
Generated Code and Source Control
An earlier convention on our project was to generate the JAX-WS client code as part of the normal build process, every time the application is built. This is a reasonable, "ideal" approach since none of this code is "source" in the conventional sense. That is, it doesn't need to be tracked for human edits or backed up for recovery purposes.
However, since theoretically behaviors could change with newer code generations, it does seem safer to version-control this code. This would also allow easy recovery of previous versions of generated code if that became necessary.
Doing so would also
Finally, even with version-controlled generated code, having scripted methods to generate the code is still useful. This ensures that code generation options are documented and repeatable. Thus, we will be creating Ant targets even if they're not used as part of the default target and automated build process.
DougBreaux 270007SMYJ Visits (8796)
I imagine most folks who use Eclipse or its variants already know about this, but just in case...
User Libraries are reusable groupings of jar files that compose a particular library to be used by an application. This is a much easier way to manage the jars needed by your projects than simply adding them one-at-a-time to the Build Path and/or the WEB-INF/lib directory for execution on a local server.
Creating and Managing User Libraries
Window > Preferences > Java > Build Path > User Libraries
Add as many User Libraries as your applications require. Name them so that you can distinguish versions from each other when you work with applications that use different versions of the same library.
Use the "New" button and type a meaningful name, then the "Add JARs" button to locate specific jar files to include.
You can attach a javadoc URL to a library, which will give you more useful help within Eclipse when you're using that library. Expand the added jar file (the small triangle), select the Javadoc location line, and click the "Edit" button. You can point at either local javadoc files or a remote URL.
Similarly, you can attach a source code file or folder to a library, which will enable you to trace into its source if necessary.
Adding User Libraries to the Build Path
Project > Properties > Java Build Path
Adding User Libraries to the Execution Path (JEE Deployment)
Project > Properties > Deployment Assembly