Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: users@cxf.apache.org
Subject: Re: Problem with wsdl2java codegen tool & jaxb episodes
Date: Sat, 13 Mar 2010 21:33:12 -0500
User-Agent: KMail/1.13.1 (Linux/2.6.33-gentoo; KDE/4.4.1; x86_64; ; )
Cc: Marcel Casado <marcel@ucar.edu>
References: <27883012.post@talk.nabble.com>
 <201003121629.03785.dkulp@apache.org> <27884131.post@talk.nabble.com>
In-Reply-To: <27884131.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201003132133.12201.dkulp@apache.org>

On Friday 12 March 2010 6:43:16 pm Marcel Casado wrote:
> I've created a Jira and attached test case :
> https://issues.apache.org/jira/browse/CXF-2712

OK.  I can now see what is going on.   It's technically a "bug" (or missing 
API) in JAXB.   See:

https://jaxb.dev.java.net/issues/show_bug.cgi?id=514

Basically, for code generation, we need to know the class names that JAXB 
determined for the various wrappers and parameters.   We call a method on the 
JAXB model passing the QName in and get a special object back with the 
classname in it.   However, JAXB only passes back stuff it actually generated.   
In the case of episodes, it didn't generate anything.   Thus, null is returned 
and we cannot proceed.     Ideally, JAXB would return a proper object for us 
so we can get the information.    

I think this is why I've seen mixed results with episode files and CXF.    The 
use cases I've seen before use episodes for their domain schemas, but not for 
the "wrapper" schemas used for the wsdl/soap interactions.    For example, a 
"PurchaseOrder" object would be in the episode, but the "submitPO" and 
"submitPOResponse" schemas would be in the wsdl (which would import the domain 
schema).    That use case WOULD work fine.   JAXB would generate the SubmitPO 
object so null would not be returned.

Without that fix in JAXB, I'm not sure what options we have.   The ONLY thing 
I can think of is to parse and process the episode files ourselves and if jaxb 
returns null, start searching through them to see if a type is mapped or not.   
Quite a bit fragile.  

Dan


> Thanks,
> 
> -Marcel
> 
> dkulp wrote:
> > I've heard of mixed reports of people using episode files.  Some have
> > claimed
> > it worked fine.   Others have had issues.   The main problem I have is
> > that
> > no-one that has had problems have been able to provide a test case that
> > we can
> > debug.   If you could create a test case and attach to a JIRA, that would
> > be a
> > big help in getting any issues fixed.
> > 
> > Dan

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog