Fixes are available
APAR status
Closed as program error.
Error description
Abstract: RAD v8.0.4 targeting WAS v7.0.0.19. Regenerating a Web service java bean skeleton from a WSDL results in an error dialog with an 'IWAB0014E Unexpected exception occurred.org.eclipse.emf.common.util.DiagnosticException: A problem was detected while parsing a Java file.'. The generated {SomeService}SOAPImpl.java has 'slashes' instead of 'dot' ( .') for package names. The targeted web project contained unsuccessfully generated java files from some previous web service generation. Problem To recreate: RC on WSDL ? Web services ? Generate Java Bean Skeleton (set for Deploy and defaults) The top-down web services wizard: 1. throws the following error and fail to proceed and has to be Cancel(led): IWAB0014E Unexpected exception occurred. org.eclipse.emf.common.util.DiagnosticException: A problem was detected while parsing a Java file org.eclipse.emf.common.util.WrappedException: org.eclipse.emf.common.util.DiagnosticException: A problem was detected while parsing a Java file at org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.cr eateCompilationUnit(ASTFacadeHelper.java:285) at ... .. org.eclipse.emf.codegen.merge.java.JMerger.createCompilationUnit ForInputStream(JMerger.java:317) at org.eclipse.jst.ws.internal.consumption.common.JavaMerger.merge( JavaMerger.java:174) at org.eclipse.jst.ws.internal.creation.ui.extension.PreServiceAsse mbleCommand.execute(PreServiceAssembleCommand.java:75) at org.eclipse.wst.command.internal.env.core.fragment.CommandFragme ntEngine.runCommand(CommandFragmentEngine.java:419) at ... at org.eclipse.equinox.launcher.Main.main(Main.java:1384) Caused by: org.eclipse.emf.common.util.DiagnosticException: A problem was detected while parsing a Java file ... 57 more AND, 2. generates a bad {SomeService}SOAPImpl.java containing 'slashes' instead of 'dot' ( .') for package names in the code. The other generated files are fine , and The cause of {SomeService}SOAPImpl.java being incorrectly generated from the WSDL, appears to be because of an {Some Java Utility Project:Types}.jar utility project on the Manifest Entries ( == MANIFEST.MF classpath) of the Assembly Deployment (hence Java Build Path) of the deployment target WebService Web project. Some Java Utility Project Types}.jar contains the same web service types as the web service being generated into the web project. This is in addition to the similar pre-existing web service class/java files in the project source folder. The {Some Java Utility Project:Types}.jar on the Deployment Assembly: Manifest Entries (MANIFEST.MF) of the target WebService Web project, ends up on the project Java Build Path and could leads to conflicts/confusion when generating the same web service types into this web project. It may not be a good practice to have a jar with duplicate web service java source and class files on the project Deployment Assembly: Manifest Entries (MANIFEST.MF) and hence the Java Build Path, when generating new similar class types. Regardless, the JAX-WS top-down web services wizard should not fail as it did and still generate the bad code. An outright clean failure by the wizard with a reasonable error message and without generating the bad code in {SomeService}SOAPImpl.java code should be expected. Warning:Even with a fix for the code generation error, the output of this whole process results in multiple copies of the same file on the classpath. There are files under WEB-INF/classes (which are compiled from what we generate) and then there is the user's library. This can result in unexpected behaviour depending on which class is expected to be loaded and if the implementations ever diverge. Workaround: 1. remove the {Some Java Utility Project:Types}.jar from the MANIFEST.MF of the Assembly Deployment of the WebService Web project. 2. remove the packages containing the generated web service code from the JavaSource folder of the WebService Web project. Actually it is enough to just remove the bad generated {SomeService}SOAPImpl.java file and do a project clean 3. Now it should be possible to repeatedly re-generate the web service from the WSDL without errors, using these steps.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * **************************************************************** * PROBLEM DESCRIPTION: * **************************************************************** * RECOMMENDATION: * **************************************************************** The fix is to ensure that the look up always finds the SEI class that is generated and in source form - not the one from the jar.
Problem conclusion
The fix for this APAR is included in Rational Application Developer v8.0.4.2.
Temporary fix
Comments
APAR Information
APAR number
PM68179
Reported component name
RATL APP DEV WI
Reported component ID
5724J1901
Reported release
804
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2012-07-04
Closed date
2012-12-15
Last modified date
2012-12-15
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
RATL APP DEV WI
Fixed component ID
5724J1901
Applicable component levels
R804 PSN
UP
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSRTLW","label":"Rational Application Developer for WebSphere Software"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0.4","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
15 December 2012