Create a simple Java client to call that web service. Using the default Java SE 7u2 SDK + runtime downloadable from Oracle, you run wsimport to import the service WSDL and generate proxy classes. You write a little code to instantiate the service class and call the service, run the app, and see the output from the successful web service call. Done! Well, not exactly.

When you run the Java client console app, the calls to the web service work but are accompanied by rather nasty sounding warnings about unknown policy requirements.

Jan 04, 2012 12:10:46 PM [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector] selectAlternatives
WARNING: WSP0075: Policy assertion "{http://www.w3.org/2006/05/addressing/wsdl}UsingAddressing" was evaluated as "UNKNOWN".
Jan 04, 2012 12:10:46 PM [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector] selectAlternatives
WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "UNKNOWN"

How do we get rid of those warnings? There are certainly ways to suppress warning reports, but that’s not the right solution. The better question is how do we resolve the issue reported in the warning?

After a great deal of digging around, here’s what I’ve found:

1. WCF defaults to placing a wsaw:UsingAddressing WS-Policy assertion in your web service WSDL.
2. wsaw:UsingAddressing is not actually part of any SOAP standard, it’s some sort of WSDL extension to cover the gap until an official SOAP WS-Policy standard could be defined later.
3. Microsoft WCF supports wsaw:UsingAddressing.
4. Java’s JAX-WS reference implementation web service core framework (JAX-WS RI 2.2.4-b01) bundled with the JDK does not support wsaw:UsingAddressing. The rationalization seems to be that wsaw:UsingAddressing isn’t part of the WS-Policy spec, so “not our problem”. JAX-WS RI supports wsam:Addressing from the official WS-Policy spec.
5. This isn’t just Java folks thumbing their noses at Microsoft. This also causes interop problems with Java web service frameworks that support and use wsaw:UsingAddressing.
6. Java Metro is another web service framework, and one which does support wsaw:UsingAddressing. Metro is the result of Sun and Microsoft working together to resolve cross-platform web service interop issues.
7. Metro is easy enough to download, but how do you use it? Documentation is all about how to install Metro into an application server environment. Many app developers have asked “How do I use Metro in my Java client?”

As it turns out, Metro appears to do all of its magic at runtime. There is no IDE integration at all. All you need to do is reference the Metro .jar files in your Java project and the WS-Policy warnings will go away.

In the NetBeans IDE, this means adding each of the .jar files from the Metro/lib directory to the Libraries node in your Java project. Make sure they appear before the JDK reference. Make sure you select the actual .jar files, not just the Metro/lib directory.

In the IntelliJ IDE, this means:

1. Right click on the JDK node under “External Libraries” in the project tree
2. Click “Open Library Settings”
3. Click “Libraries” under “Project Settings”
4. Click the New Project Library tool button
5. Click “Java”
6. Select the Metro/lib subdir in the “Select Library Files” path selector dialog.

Note that in NetBeans, you have to select the actual .jar files; selecting only the Metro/lib directory won’t work in NetBeans.  Selecting only the Metro/lib directory works fine in IntelliJ.

To solve this UsingAddressing policy issue from the Java client end, use the Metro libraries. Period.

Another way to solve this interop issue would be to address the service end: Add wsam:Addresssing as an acceptable alternative to wsaw:UsingAddressing in the web service’s WSDL. With both addressing policies as siblings under an <ExactlyOne> element, clients that support wsaw:UsingAddressing will be happy and clients that support only wsam:Addressing will be happy. In theory, anyway.

However, I have yet to figure out how to add wsam:Addressing to the WSDL generated by a WCF service. Since I have a client-side solution I won’t be pursuing this further, but if anyone can provide a link to how to do this on the WCF WSDL side, I’d love to see that solution as well.

Share/Bookmark

The problem is that the data collection you’re returning doesn’t meet WPF’s data binding requirements, so WPF ignores the binding expression and goes on its merry way. I can understand why WPF doesn’t throw an exception for this situation, but could we at least get an error message logged to the Output window like other data binding errors?

For collection properties to work on WPF controls in XAML markup, XAML requires that the collection object instance implement the IList interface.  That means the data collection you’re binding to that property needs to implement IList also.

If your data collection is an IEnumerable, such as data returned by a yield return iterator, your control will display no data at runtime and you’ll see no error messages.

If your data collection implements IList<T>, your control will display no data at runtime and you’ll see no error messages.  A class that implements IList<T> does not automatically support IList.

If your data collection is a Dictionary<K,V>, you can data bind to the dictionary’s Values collection property, which implements IList<T>.  You can probably guess where this is going…  The dictionary’s values collection type implements IList<T>, but not IList.  Your control will display no data at runtime and you’ll see no error messages.

Note that the type of the property that is providing the data collection is more or less immaterial.  What matters is whether the object that property returns implements IList.  WPF/XAML will query at runtime for the IList interface on whatever object is returned by the data bound source property.

List<T>, Collection<T>, and ObservableCollection<T> all implement IList, so if you’re using these as your underlying storage class you’re good to go.  If your underlying storage is anything else, you probably have some work to do.

In the Dictionary<K,V>.Values case, one simple solution is to return Values.ToList(). The List object returned implements IList so you’re good to go.

Before putting that code to bed, though, give some thought to the performance implications: ToList() will create a new list of references to all the data in the dictionary Values collection, and it will do that every time anything fetches the property value. The memory consumption is proportional to the number of items in the dictionary, but not to the size of those objects.  The objects in the dictionary are not copied, the list just contains references to the objects (as does the dictionary).

For a small collection of a few hundred entries or less, this is probably no big deal.  For a large collection with tens of thousands of items or more, creating a new list of N object references every time the property is fetched is probably not a good idea.

Share/Bookmark

(You do know that computers run on smoke, right?  ‘Cause if you let the smoke out, the computer don’t work no more!)

My experiments with Code First took a turn for the worse today as my test app deteriorated from working nicely to failing with murky error messages that seemed to have little to do with the source code changes I just made. How am I supposed to figure this stuff out if they keep rearranging the maze?

I had configured my domain service to always drop the database tables and reset the tables with test data (using DropCreateDatabaseAlways)  whenever the entity model changed. I knew I would be making lots of changes to the model/schema, so might as well just wipe the slate clean every time.

As the strange failures began to mount, I noticed that sometimes after modifying my POCO entity classes (and therefore changing the entity model) running the test app did not hit my breakpoints in the context’s OnModelCreating or the initializer’s Seed methods.

To figure out what I had changed to cause all this pain, I started commenting out non-essential parts of the POCO classes, eliminating associations and composite keys and so forth.  The weird failures continued.  The failures weren’t even consistent – sometimes the client app would run once just fine and create all the tables it needed, then fail mysteriously with an invalid metadata error on the second run or when the page was refreshed.  Sometimes the first run didn’t even survive the first web request data query.

By the time I had whittled the POCO classes down to a single class with no inheritance and no associations and still had the client fail, I decided it was time to take a lunch break.  It didn’t matter what time it was, I needed to put it aside, leave it alone for awhile so I could make a fresh start later.

When I came back from my lunch break there was an error message box on the screen that I hadn’t seen before.  It said the database could not be dropped because it was in use by another client.  I had left the debugger paused at a breakpoint in the test app and it had trapped this exception some time after I had left my desk.

After a moment of head scratching, I realized the other database client was the Server View in Visual Studio that I was using to inspect the tables created by EF to see how my changes to the POCO entities affected the SQL schema.  Close the database connection in VS, restart the app and poof! Everything worked as it should.  It even worked twice in a row, which at that point was a new record for the day.

What was happening was the domain service in my test app was actually attempting to drop the tables from the database and build everything anew, but Visual Studio’s open connection to the SQLExpress service was blocking the drop action. Apparently, dropping the tables is a asynchronous action with a very long timeout interval.  The client would make its first request for data, the domain service would receive the request and fire up the DbContext, realize that the model and database needed to be regenerated, and issue the database drop and create operation.

The drop and create didn’t complete immediately, but apparently other activities proceeded asynchronously and began to fail because the schema found in the database didn’t match the expected schema.  I would see these bizarre failure error messages while stepping through the domain service code as part of the initial data request.  What I didn’t see was the root cause – the drop tables failure – because it didn’t fail until long after I had killed the test app and gone back to wondering what I was doing wrong in my source code.

So, simple solution: Always close any open connections in the Server Explorer before running an app that will drop tables.

This is not the error you’re looking for

Another tip for working with Code First Entities:  if you get a compile error about “You can’t use this entity in a method of your domain service class because it has not been exposed in your DbContext”, but you look at your DbContext class and you can see you most certainly have exposed that entity as a DbSet<class> property, here’s what you do:  Ignore the error message.  It’s a red herring. Instead, go check that your entity class explicitly designates a property as the primary key, using the [Key] attribute.  Fluid API calls to define a key in OnModelCreate won’t do – VS will only be satisfied by a Key attribute.

I don’t claim to know why, but after a day of permutations and combinations, this is what I found cleared the problem for me.

Share/Bookmark

Error: There was an error processing 'xyz-schema.xml'.
  - DataSet cannot instantiate an abstract ComplexType for the node .

Here’s your solution: Rename your schema file from *.xml to *.xsd.

When you give XSD an input file with a .xml extension, it assumes you want to infer schema from data found in the xml file. If what you really want is for XSD to read the schema from the input file, the input file has to have a file extension of .xsd.

Since XSD schema is formatted as an XML document, its not uncommon to find XSD schema in files with a .XML extension, especially when downloading from the web. Just remember to rename them to .xsd before generating classes from them.

Share/Bookmark

Using no XML namespace at all when querying XML just doesn’t fly in the real world.  If you’re using any XML spec that isn’t your own, you will need to use namespaces to make sure the XYZ element you get back from the query is the brand or flavor of XYZ that you intended.  If you’re writing your own XML document schema, it’s critical to declare your namespaces!

The most nonintuitive aspect of working with XML is realizing that default namespaces are namespaces too, and apply to everything in the document or subtree that doesn’t have an explicit namespace.  Even though your XML document uses nice clean simple XYZ elements everywhere, if you try to query for XYZ using XPath you’ll get nothing but nulls back.  Your XYZ elements are under a default namespace in the document, so XPath will only return matches if you specify namespaces in your query as well.

What really kills me is when the sample code for making an XPath query using namespaces uses the same namespace prefix in the query as in the original XML document.  This gives the reader the impression that the namespace prefix strings in their queries have to match the original document.  That’s completely false.  The text of the prefix string is completely irrelevant – all that matters is what URI the prefix string represents, and that the URI of the namespace used in your query matches the URI of the namespace used in the XML document.

Take this C# example code offered up on none other than the MSDN documentation for XPathSelectElement:

string markup = @"
<aw:Root xmlns:aw='http://www.adventure-works.com'>
    <aw:Child1>child one data</aw:Child1>
    <aw:Child2>child two data</aw:Child2>
</aw:Root>";
XmlReader reader = XmlReader.Create(new StringReader(markup));
XElement root = XElement.Load(reader);
XmlNameTable nameTable = reader.NameTable;
XmlNamespaceManager namespaceManager = new XmlNamespaceManager(nameTable);
namespaceManager.AddNamespace("aw", "http://www.adventure-works.com");
XElement child1 = root.XPathSelectElement("./aw:Child1", namespaceManager);
Console.WriteLine(child1);

The “aw” namespace prefix used in the calls to AddNamespace and XPathSelectElement doesn’t need to match the “aw” prefix used in the original document.  The URI that the prefixes are associated with need to match, but that is all.

Here’s the sample again using different prefix strings:

string markup = @"
<aw:Root xmlns:aw='http://www.adventure-works.com'>
    <aw:Child1>child one data</aw:Child1>
    <aw:Child2>child two data</aw:Child2>
</aw:Root>";
XmlReader reader = XmlReader.Create(new StringReader(markup));
XElement root = XElement.Load(reader);
XmlNameTable nameTable = reader.NameTable;
XmlNamespaceManager namespaceManager = new XmlNamespaceManager(nameTable);
namespaceManager.AddNamespace("ns", "http://www.adventure-works.com");
XElement child1 = root.XPathSelectElement("./ns:Child1", namespaceManager);
Console.WriteLine(child1);

This second code snippet executes exactly the same as the first, but in my opnion is much clearer as to what’s going on because it doesn’t imply that the prefix strings must match in order for the query to work.

Why is this important?  Because when you’re processing an XML document, you usually know at compile time what namespace(s) you’re interested in working with elements of.  Just bind the URI of the namespace you care about to whatever prefix string you want and use that prefix string in your queries.  XPathSelectElement will figure out the mapping between your prefix string in the scope of your query and the equivalent prefix string in the scope of the XML document.

You don’t have to care what namespace prefix the document creator used to write the XML document, and you really don’t want to have to parse the XML document just to figure out what prefix string is bound to the namespace URI you care about.

Share/Bookmark