Fixes are available

Subscribe

You can track all active APARs for this component.

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.